OpenGL ES 3.2 & New Extensions Unveiled 46
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.
Re: (Score:1)
but with dx12 comes windows....
great pick
OpenGL has lost its way (Score:1, Flamebait)
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.
Now they're just playing the copycat game, and ignoring their biggest strength, to truly push GPU hardware to the limit.
What a fucking joke.
Re: (Score:2, Informative)
"developers can still use individual features if they’d like"
Third paragraph. [anandtech.com]
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.
Re: (Score:2)
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
Re:OpenGL has lost its way (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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 tha
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:1)
The "whole draw" of OpenGL is API portability.
And yet, "write once, debug everywhere" applies even more to OpenGL than it does to Java.
Re: (Score:3)
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)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Revisionism much? Results showed that modern OpenGL can be many times faster than Direct3D 11 [wikipedia.org]
Re: (Score:1)
" 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.
Re: (Score:2)
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".
Re: (Score:2)
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 standa
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Vulkan demo on Android (Score:2)
The end of DirectX? (Score:2)
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
Re: (Score:2)
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
I can see Sony caving and going with Vulkan for their next box instead of doing their own thing once again. By that point Direct3D is going to be looking just a little bit funky, being the last roll-yer-own funky API standing.
Re: (Score:2)
They are in the Khronos Group working on Vulkan. Not for the next box but for this one. All they need is a driver update, the hardware already supports it.
Great, now just need brain transplants for a couple of key managers and its a done deal.
How about sendmail.cf 3.2? (Score:2)
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 s
Re: (Score:2)
It's OK to use float[] instead of ByteBuffer
Well the underlying datatype is an array of floating point values, if you have a language-specific wrapper around OpenGL then maybe for your language a ByteBuffer makes sense and nothing precludes doing that.
Textures can be objects instead of integers.
But what you are referring to isn't a texture, it is a texture id which is why it is an integer.
Modern GPUs can handle one modern standard compressed texture format with alpha.
Not sure what you mean there.