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.

Comments

Re:Yippie

[Anonymous Coward]

Helluva phone you got there.

OpenGL has lost its way

[Khyber]

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:OpenGL has lost its way

[Anonymous Coward]

"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.

Re:OpenGL has lost its way

[Xrikcus]

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:OpenGL has lost its way

[Anonymous Coward]

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.

It's doing that with fair success given its widespread use today.

Re:OpenGL has lost its way

[Khyber]

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.

Re:OpenGL has lost its way

[Bengie]

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.

Re:OpenGL has lost its way

[beelsebob]

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:OpenGL has lost its way

[Anonymous Coward]

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:OpenGL has lost its way

[Bengie]

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.

Re:OpenGL has lost its way

[Bengie]

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.

Re:OpenGL has lost its way

[Anonymous Coward]

The vast majority of video card memory is spent on textures, something that is not going to be that different between either API. Another moderate sized chunk is going to be things like geometry and intermediate buffers, things that can be somewhat reduced by an API supporting more features, like tessellation or shaders doing a better job on the fly. But the resources for that are not going to be reduced by making an API leaner, and the gain from doing a good job at reducing those resources is going to be minor. Expecting there to be some magic bullet for reducing such resources seems to miss fundamentally what the resources are being used for, like complaining about the disk space taken up by a database engine binary after the data itself has grown into the TB territory.

Re:OpenGL has lost its way

[serviscope_minor]

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:OpenGL has lost its way

[spitzak]

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:OpenGL has lost its way

[beelsebob]

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.

Re:OpenGL has lost its way

[Tough Love]

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:OpenGL has lost its way

[Anonymous Coward]

Wait until Vulkan comes out. If you've read the Mantle documentation (I have), you'll see that now the developer will be responsible for adding in effects and turning them on/off to improve performance. Even better, that performance will be an order of magnitude greater than current OpenGL for applications that are performance limited by things like draw calls, thread mutexes and so on.

Although I agree that OpenGL is an absolute mess right now, Vulkan will clear all of that away.

Re:OpenGL has lost its way

[Tough Love]

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:OpenGL has lost its way

[Tough Love]

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:OpenGL has lost its way

[Tough Love]

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:OpenGL has lost its way

[Anonymous Coward]

The API and its dark binding ways were never good design even in 1999. Sure, you could get your first flat-shaded triangle up with minimal typing, but extending to textures made life so miserable.

(Otherwise I agree completely)

Re:OpenGL has lost its way

[Anonymous Coward]

Most OpenGL drivers are themselves multi threaded, that implies synchronisation between your application and the OpenGL driver, within the driver itself and the hardware. The points where syncs happen can cause stalls, since either your application or the driver has to wait for the other (worse if something tries to read back GPU state). In modern OpenGL there are a lot of ways to reduce stalls, however these still involve synchronisation between application, driver and hardware. A lower level API makes this explicit and may allow you to avoid it when code is optimized for a specific case.

NVIDIA Nsight for example can profile an OpenGL ( or DirectX ) application and show which parts of the graphics stack are stalled at a specific time.

Re:OpenGL has lost its way

[Anonymous Coward]

"Write once, debug everywhere" is an issue for every useful, sane, multi-platform API.

The alternative is to specify even the most minute detail of every operation, and forbid outright anything which cannot be so specified (e.g. behaviour with respect to multiple threads). A corollary of this is that every lower limit must also be the upper limit.

The only situations where "write once, debug everywhere" doesn't apply are either limited APIs (e.g. no multi-threading) on perfectly homogeneous hardware, or when you have programmers who actually understand the difference between specified behaviour and "works on my system".

Re:OpenGL has lost its way

[UnknownSoldier]

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:OpenGL has lost its way

[Anonymous Coward]

The 90's called. They say that Java dig wasn't even valid then so you're a tool for continuing to use it.

Re:OpenGL has lost its way

[exomondo]

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.

Re:OpenGL has lost its way

[Anonymous Coward]

OpenGL provides a cross-platform solution on non-Microsoft platforms. Wake me up when I can run DirectX on OSX, Android, or iOS.

DirectX may not be platform agnostic but don't pretend OpenGL is that much better. Apple's support for OpenGL in OSX is pathetic, the latest supported version is the ancient 4.1 spec from 5 years ago. And with them now doing their proprietary vendor-specific Metal API it is even less likely Apple will catch up to the rest of the world with their OpenGL implementation.

Then of course the OpenGL that does run on Windows, OSX and Linux is not the same as the one that runs on Android and iOS either. The latter platforms run the ES variant so the idea that it is a genuine cross-platform solution is pretty disingenuous when you consider reality.

The best cross-platform solution at the moment for most cases is OpenGL ES 2.0 (and soon 3.0) with Google ANGLE to target DirectX platforms. That only leaves OSX out in the cold.

Re:OpenGL has lost its way

[exomondo]

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:OpenGL has lost its way

[Tough Love]

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:OpenGL has lost its way

[Anonymous Coward]

No need to pretend. OpenGL is that much better, and then some.

Even the most anti-Microsoft person isnt going to lie to themselves that much, maybe you can fool yourself but you wont fool anybody else. Perhaps you just dont know very much about this topic so I will explain more:

If we look at performance OpenGL is far worse than DirectX primarily due to excessive driver overhead and poor CPU threading, this should change with Vulkan but is not the case yet. Multi-platform is not that advantageous given that Apple is now focusing on Metal for its mobile platforms, Google is using ES in Android but that isnt the same version of OpenGL you see on Windows, Linux and OSX, it is a different OpenGL. The latest OSX version is 5 years old and OSX is moving toward Metal rather than OpenGL so the portability aspect is practically limited to Windows and Linux. The upshot is you get portability with Windows and Linux but sacrifice performance...at least for now. Again this should change with Vulkan which should ultimately also subsume the ES variant at which point you can shout your anti-Microsoft so and so from the treetops, but not just yet.

Re:OpenGL has lost its way

[Tough Love]

Revisionism much? Results showed that modern OpenGL can be many times faster than Direct3D 11

Re:OpenGL has lost its way

[Khyber]

" 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:OpenGL has lost its way

[Anonymous Coward]

Revisionism much? Results showed that modern OpenGL can be many times faster than Direct3D 11

Nope, not revisionist at all. As I said, you don't know much about this topic so again I need to educate you: DirectX11 was released back in 2009 and suffered the same issues of driver overhead and poor multi-threading support that OpenGL still does today. However we have DirectX12 now which eliminates much of the driver overhead and the issues around writing multi-threaded rendering code. It is a similar theory to what AMD did with its Mantle API that is forming the basis for the yet-to-be-released glNext (now known as Vulkan).

Now as I already said, the performance problems of OpenGL will be alleviated with Vulkan -- as a contributor I am quite certain of this -- however my vested interest is in OpenGL therefore I prefer to acknowledge the problems (particularly when a competitor has similar ones and has resolved them) and help to get them fixed rather than pretend they don't exist.

Re:OpenGL has lost its way

[Anonymous Coward]

Revisionism much? Results showed that modern OpenGL can be many times faster than Direct3D 11

Did you even read that? Putting aside the fact that you're looking at Direct3D11 (we're on Direct3D12 now) if you have a look at the presentation that that link is citing you will see that it is talking only about persistent buffers in a highly specialized situation. For example the sentence directly before the one you quoted reads:

"During the presentation, apitest, a new tool for microbenchmarking specific solutions for given problems emphasizing exploration of fast paths in current APIs, was introduced."

Now if we take a look at the reference you will see that the sentence you quoted is based on just one microbenchmark of a very specific solution. But this is not representative of the performance of the APIs overall. So let's take a look at a more realistic and general scenario, we'll even accommodate OpenGL and DirectX from before Direct3D switched gears to the low-overhead and threading improvements.
You can see here that on the gaming cards DirectX11 comes out on top of OpenGL in almost all cases and often by a wide margin. And this is DirectX11, not the most recent and much-improved 12.

Re:Yippie

[Anonymous Coward]

but with dx12 comes windows....
great pick

Vulkan demo on Android

[alexvoica]

Here's a quick demo we've written for SIGGRAPH that compares Vulkan and OpenGL ES performance for Android on a prototype driver.

Re:Vulkan demo on Android

[Anonymous Coward]

"The demos are not using instancing either..."

Yes, and if you used instancing in the OpenGL ES code you would probably see similar performance!

"...each draw call could be a different piece of geometry with a different material or texture and the CPU performance would be very similar."

The demo would hit a GPU performance wall with the texture changes (because of memory bandwidth, cache thrashing etc.) long before it hits a CPU barrier. Vulkan and DX12 solve an edge case situation by rewriting the entire API. Instancing in OpenGL already solved the majority of the real-world uses cases (vegetation rendering etc.) so it's even less of a win.

Vulkan's biggest benefit will be the theoretically simpler API model (less crazy hidden state) and maybe less garbage drivers (since it reduces the burden on vendors to optimize at a high-level in the driver stack). It remains to be seen if those benefits are worth it to most GPU programmers.

The end of DirectX?

[edxwelch]

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:The end of DirectX?

[Tough Love]

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:The end of DirectX?

[Anonymous Coward]

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.

Re:The end of DirectX?

[Tough Love]

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.

Re:Yippie

[Anonymous Coward]

but with dx12 comes windows....

Who cares? I want my programs to run well and effectively utilize my hardware, if Windows provides that then why would I care what the operating system is?

How about sendmail.cf 3.2?

[iamacat]

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.

Re:How about sendmail.cf 3.2?

[exomondo]

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.

Re:Yippie

[Anonymous Coward]

Because Windows 10 is full of ads?