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.
"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.
Here's a quick demo we've written for SIGGRAPH that compares Vulkan and OpenGL ES performance for Android on a prototype driver.
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.
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.
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.
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