Slashdot Mirror
OpenGL ES 3.2 & New Extensions Unveiled
An anonymous reader writes: With kicking off ACM SIGGRAPH '15, The Khronos Group came out with several big announcements, including the release of OpenGL ES 3.2 (which incorporates Android AEP functionality), confirmation that Google will support Vulkan on Android (when released), new desktop OpenGL extensions, and updates to the existing OpenCL 2.0 specification. They stopped short of releasing the heavily anticipated Vulkan Graphics API and also refrained from releasing a new desktop OpenGL version. They hope to have the Vulkan specification and its implementations released before year's end.
but with dx12 comes windows....
great pick
"developers can still use individual features if they’d like"
Third paragraph.
Feature sets are in addition to individual features. In any case, pushing the latest GPU hardware to the limit is the entire point of playing on a PC, instead of waiting several years for the next generation of console.
Maybe, though from the point of view of the engine devs pushing Vulkan, I think their goal here is to push GPU hardware to its limit in a way that GL made difficult, in particular by removing driver overhead and complexity that vendors couldn't ever hope to optimise.
Here's a quick demo we've written for SIGGRAPH that compares Vulkan and OpenGL ES performance for Android on a prototype driver.
Individual Features? Present or not-present?
Is OpenGL still focusing on being extensible as shit while being minimal, or are they playing the feature-creep game with DX12, which is what I'm implying?
It used to be games running OpenGL or 3Dfx GLide needed FAR LOWER requirements for the same game to run vs D3D. Unreal Tournament 1999, for example. With a 3Dfx or OpenGL card, you could haul ass on a shit 4 or 6 MB card, maxed everything, on a 133MHz Pentium MMX with 16MB RAM. And it looked great. For D3D, you needed a 233 MHz processor, 32MB RAM, equivalent RAM D3D card, and it looked like dithered ass.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
The whole draw of OpenGL was that developers could just add in the effects they wanted
It is also its greatest weakness. There are two independent sets of developers, the graphic driver developers and the developers who actually use the API. The graphic developers may love that they can extend OpenGL to make use of their random new fangled features in their graphics card, but the developers actually using the API now need to check for some huge number of custom extensions that may or may not exist.
The whole point of a standard API is for there to be a standard! either you follow the standard or you don't and everyone who implements the standard implements the exact same things.
Believe it or not, the world of graphics hardware and APIs has moved on substantially since 1999. What was a good API design then, is now far from it. These days, you can get an order of magnitude speed improvement from two major API changes from the current OpenGL one:
1) Drop the state machine, and require states to be specified (and hence verified, and compiled) up front, rather than via a series of changes during drawing.
2) Drop the inbuilt thread safety, and require the users of the API to implement correct thread safety themselves.
These two changes together make a very very significant difference to the performance you can get out of a CPU/GPU pair. There's a very good reason why Microsoft went that way with D3D, Apple went that way with Metal, AMD went that way with Mantle, and now Kronos is going that way with Vulkan.
The "whole draw" of OpenGL is API portability.
And yet, "write once, debug everywhere" applies even more to OpenGL than it does to Java.
Vulkan shouldn't need to be extensible. I'm sure there will be a few exceptions, but I don't expect nearly as many. The old API needed to do most of the work, so implementation was important. Vulkan now expect the game engine to do the implementation and to communicate near-directly with the GPU. Extending Vulkan would be akin to extending x86 to make your program work. Someone may want to may a new SIMD, but it should be very rare to need a new extension.
Vulkan is based on Mantle. They whole-sale lifted nearly all of the API signatures and just renamed them. Kronos explicitly stated that they do not create new APIs, the only define established ones. They are followers, not leaders.
2) Drop the inbuilt thread safety, and require the users of the API to implement correct thread safety themselves.
There was thread safety? I'm sure I remember OpenGL having "interesting" bugs if you used multiple threads in the same context even back in the 1.4 days.
SJW n. One who posts facts.
You are required to use a different context per-thread, so of course you got "interesting" bugs using the same context.
However even if you used different contexts there are bugs in the drivers (or hardware) so it did not work.
OpenGL has a bunch of implicit locks and blocking operations that do not need to be blocking. For example, if you have a font atlas, and you know that for frame 1, you only need to be able to access the glyphs for 'a', 'n' and 'd', but for frame 2, you know you'll also need 'y', 'u' and 'o', frame 2's texture upload would block any draw calls from accessing the texture (or it would block until those draw calls had completed). There is no way to avoid this in OpenGL, even if you yourself have knowledge that you are not going to modify anything that the shader will read.
OpenGL specification development continues to focus heavily (but not exclusively) on efficiency. Direct State Access is one of many examples of that - not yet present in ES, but expected for ES 4
When all you have is a hammer, every problem starts to look like a thumb.
The whole draw of OpenGL was that developers could just add in the effects they wanted and allow users to turn them on/off to improve looks/performance
Err. Are you just making stuff up? The "whole draw" of OpenGL is API portability.
Not just that. API continuity, efficiency, support for new hardware features, consistent feature support across all configurations, legacy profiles, safety profiles, much more. API portability is important and is an OpenGL superpower indeed, but it is far from the "whole draw".
When all you have is a hammer, every problem starts to look like a thumb.
The "whole draw" of OpenGL is API portability.
And yet, "write once, debug everywhere" applies even more to OpenGL than it does to Java.
Not in my experience. I tend to hit the occasional difference between hardware vendors, often due to relying on some undefined state behavior. More often I end up impressed at how much code just works across wildly different hardware (AMD vs nVidia vs Intel vs PowerVR)
When all you have is a hammer, every problem starts to look like a thumb.
Although I agree that OpenGL is an absolute mess right now, Vulkan will clear all of that away.
I disagree that OpenGL is an absolute mess. What are you comparing it to? (If you want to behold a real mess, look at the legacy garbage that Direct3D has.) A more accurate characterization: OpenGL has warts here and there, but mostly solid and spectacularly flexible. OpenGL is moving with the times, without breaking old code, pretty amazing that. I have every confidence that Vulkan will once again not break legacy OpenGL apps, just move them to a legacy profile.
When all you have is a hammer, every problem starts to look like a thumb.
As opposed to DirectX where you can only support Windows, Windows Mobile, and Xbox ??
OpenGL provides a cross-platform solution on non-Microsoft platforms. Wake me up when I can run DirectX on OSX, Android, or iOS.
I'm quite amazed that Vulkan will support all versions of Windows from XP onwards. So you can have the low overhead of DirectX 12 without forcing your users to upgrade to Windows 10.
I can see a lot of game developers migrating to Vulkan, just because they get more sales the more OS versions they support
The whole draw of OpenGL was that developers could just add in the effects they wanted and allow users to turn them on/off to improve looks/performance. You weren't reliant upon the static/unflexible capabilities of APIs like D3D.
Except that the world changed and most of the "effects" shifted away from the underlying fixed function pipeline and into the programmable hardware which removed the inflexibility.
Now they're just playing the copycat game, and ignoring their biggest strength, to truly push GPU hardware to the limit.
This is about pushing GPU hardware to the limit, they are removing the generic resource management implementations that reside in the driver and force applications to suffer significant overhead by being unoptimized (hence the reason drivers are so large and that driver releases often include optimizations for AAA titles). The GPU resources are now under the direct control and management of the application which can take full advantage of the GPU rather than relying on the generic driver implementations.
There are two independent sets of developers, the graphic driver developers and the developers who actually use the API.
And the OpenGL extension methodology serves both. Developers can utilize the new features of new GPUs when they know what they are targeting and developers targeting broader audiences use core profiles.
The graphic developers may love that they can extend OpenGL to make use of their random new fangled features in their graphics card
That's good, you don't want to have to wait until a new feature is incorporated into the standard before you can use it.
but the developers actually using the API now need to check for some huge number of custom extensions that may or may not exist.
No they don't, that's what the core profile is for. If you want to target a broad audience then use that.
DirectX may not be platform agnostic but don't pretend OpenGL is that much better.
No need to pretend. OpenGL is that much better, and then some. And now, also running on more machines than DirectX.
When all you have is a hammer, every problem starts to look like a thumb.
Revisionism much? Results showed that modern OpenGL can be many times faster than Direct3D 11
When all you have is a hammer, every problem starts to look like a thumb.
" And with them now doing their proprietary vendor-specific Metal API"
I bet the graphics company S3 has some serious issues with that little naming, right there, as they had a 3D API called MeTaL.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Every time I set out to learn OpenGL, I just get put off by how fucked up it is. Not necessarily just being low level, but the sheer disrespect of host programming language, standardization and modern design practices. It's OK to use float[] instead of ByteBuffer. Textures can be objects instead of integers. Modern GPUs can handle one modern standard compressed texture format with alpha. Maybe one day I will find a decent wrapper that takes away unnecessary grant work. Until then I will just look for more satisfying and less tedious problems to solve.