OpenGL 4.3 - compute shaders and much more

Interesting!

For us lazy programmers, please give a short summary of the benefits or disadvantages, as you see it!

OpenGL compute shaders... or 'opps, we got it wrong and MS got it right... quick back track!'

I skimmed a few other things; basically bringing the features up to D3D11 level and continuing the OpenGL tradition of 'here are 101 ways to do things... good luck with that!'

In fact could someone give me an update on the state of Direct State Access in OGL? 4.3 doesn't seem to have it as a feature and last I checked it was a case of some things and not all things...

For us lazy programmers, please give a short summary of the benefits or disadvantages, as you see it!

I think people that are more involved with all this can give more competent insights. g-truc has a nice review: http://www.g-truc.net/post-0494.html#menu

I literally just saw this hours ago and have still to go through all of it. I am mostly excited for compute shaders. The other additions I looked into seemed to be some obvious fixes ("layout(location =...)" for uniforms, imageSize etc.) as well as improvements to memory related aspects that play nice with compute shaders (ARB_shader_storage_buffer_object).

Not much to be excited about it seems, i think most of it has been available as extensions for ages as usual, only thing i find interesting is the texture parameter queries and shader storage buffers allthough i guess its just the old ext_texture_buffer in a new package, ES3 compatibility might be nice if we get some ES3 capable devices to play with.

It would be nice if moderators didn't try to start an API flamewar though, i think we get enough of those.

Edit: To phantom, i never said you weren't correct. i've replied in a PM to you instead to avoid derailing this thread.

It would be nice if moderators didn't try to start an API flamewar though, i think we get enough of those.

Really?

Tell me what was wrong with my statements?

Computer Shaders - admission that OpenCL/GL interop has failed to work.
Features - brings it up to D3D11 standard but, with at least one extension, introduces yet another way to do things
DSA - genuine question about the state of it...

Note: no where did I say 'D3D11 is better!' - all I did was call them out on areas they are still lacking - which is the API interface in general and MAYBE the state of DSA, which I asked about..

So, yeah, if not fawning over a new release of an incremental update to an outdated API is 'starting a flame' war then fine, I started a flame war...

phantom is actually correct, although the wording chosen can certainly come across as "let's start a flame war" - but look beyond that at what the update actually does have to offer.

All the same, I'm feeling moderately stoked about this update, despite there being a high percentage of "things that should have been done ages ago" in it. There are some genuine API usability improvements in there, and the push for standardised and patent-free texture compression formats seems well-intentioned at least. Let's have the ability to use FBOs with the default depth/stencil buffer in the next one (if they didn't sneak in somewhere in this one), some DSA, and some solid drivers, and things will be really looking good.

Overall though I suspect that ES3 is going to turn out to be the more significant recent release.

Still waiting for OpenGL 2 Lean & Mean, and Long Peaks...

CL/GL interop didn't fail to work. It did work quite well. Despite this I have to admit that it is way more complicated than the DX11 compute shaders, BUT it DID work. In fact I could port DX11 compute shaders to OpenCL and make it work together with OpenGL. see:
http://www.gamedev.n...via-opencl-r233
I'm looking forward to trying out OGL compute shaders though, as it seems more reasonable to use it for processing textures / lighting.
The debugging feature is quite an improvement as such functionality was missing.

Computer Shaders - admission that OpenCL/GL interop has failed to work.
Features - brings it up to D3D11 standard but, with at least one extension, introduces yet another way to do things
DSA - genuine question about the state of it...
Note: no where did I say 'D3D11 is better!'

phantom is actually correct, although the wording chosen can certainly come across as "let's start a flame war" - but look beyond that at what the update actually does have to offer.

None of that is surprising, though. And indeed D3D11 is "better", except for the little detail that it's proprietary and Windows-only (which, as it happens, is the one important detail for me personally).

OpenGL is necessarily worse because it is designed by committee (ARB, Khronos, name it as you like). In addition to design by committee being always kind of troublesome, this particular committee has contained and contains members that have strong antipodal interests.

I won't say that Microsoft certainly has no interest in making OpenGL as good or better than their own product, because Microsoft is no longer involved (...at least officially). However, there's still Intel as a good example of an entity that is still officially involved.
Intel who already struggles supporting OpenGL 3.x on their Sandy/Ivy Bridge CPUs has a strong motivation not to add too many features too quickly. Promoting CPUs with integrated graphics is much harder if people have the impression that they don't support most modern features. Thus, advertising OpenGL and pushing its development forward lessens revenue.

Companies like AMD and nVidia on the other hand do have a (rather obvious) strong interest in pushing new features onto the market, because this allows them to sell new cards. But then again supporting both D3D and OpenGL means having twice as much driver development cost than actually necessary. If 90-95% of the software in their target market already uses D3D anyway, that's a bad deal. So again, even though there is some motivation, it is not necessarily overwhelming for OpenGL as such. If people buy the new nVidia 780 GTX Ultra because it supports D3D 12.1, which is needed to play Warcraft Ultimate, then that's just as good.

And indeed D3D11 is "better", except for the little detail that it's proprietary and Windows-only (which, as it happens, is the one important detail for me personally).

While I don't doubt the importance of this, once you get outside of Windows things get a bit ropey support wise - OSX, the largest of the non-Windows home computer platforms, lags OpenGL versions by some way with OSX10.7 supporting GL3.2, a standard released in 2009 on an OS only a year old.

I'm not sure about Linux support tbh; I tend to hear it swinging betweeen 'good' and 'bad' with a healthy dose of 'no closed source code in my linux!' kicking around.

CL/GL interop didn't fail to work. It did work quite well. Despite this I have to admit that it is way more complicated than the DX11 compute shaders, BUT it DID work. In fact I could port DX11 compute shaders to OpenCL and make it work together with OpenGL. see:
http://www.gamedev.n...via-opencl-r233
I'm looking forward to trying out OGL compute shaders though, as it seems more reasonable to use it for processing textures / lighting.
The debugging feature is quite an improvement as such functionality was missing.

I'd consider OpenCL to be more of an alternative to nvidias CUDA than to DirectCompute aswell, OpenCL works without a OpenGL render context and can also be used with Direct3D (atleast on nvidia hardware, which is quite an advantage if you want to use different renderers but still use the same GPGPU solution), OpenGL definitly needed built in compute shaders aswell but OpenCL still has its place). One can debate if the OpenCL interop should be in core rather than as an extension though. (it might have made more sense to keep the interop functions as an extension and pushed in compute shaders earlier)

I'm not sure about Linux support tbh; I tend to hear it swinging betweeen 'good' and 'bad' with a healthy dose of 'no closed source code in my linux!' kicking around.

For me, it has always "kind of" worked, but never really well as compared to how well it works under Windows.

This will (hopefully) drastically change in the near future, if Mr. Stallman doesn't prevent it. Linux becoming a Windows8-competing Steam platform would mean that some modern, advanced graphics API would have to be available and well-supported. What else could it mean but serious OpenGL support from IHVs?

What else could it mean but serious OpenGL support from IHVs?

Maybe, or it could take the same route that OpenGL on Windows takes to some extent; make it work for Game X.

For some time if you wanted performance you had to hit the same path as iD games, maybe the same will happen when it comes to following Valve's lead onto Linux? Do it their way or fall off the 'fast' path.

We'll see how it works out - I remember when Linux games appeared in the shops for a short while around 1999 with the iD games going on sale; at the time that failed to set the world alight as it seemed no one wanted to buy them. Maybe, 10+ years on Linux users (note: users. I maintain Stallman is a crazy person) as a little more pragmatic about things and Steam will work out and enough of a market share will be carved out for a good feedback loop to be generated with regards to market share, driver development and tool development going forward.

My only 'worry' about that is the continued involvement of the ARB who, historically, simply don't make good choices.
OpenGL2.0 and 3.0 are proof of this and nothing they have done since then has convinced me otherwise - if gaming on Linux makes it then it'll be down to Valve, NV and AMD working together and not the ARB.

I'm watching with intrest to see how this pans out, not least of all because it might well affect my day job

I think it's fair to say that both APIs have a healthy (or unhealthy, delete as appropriate) dollop of "worse is better" in them, so it really does come down to target platforms and personal preferences.

Regarding Intel, have you been following the Valve blog about porting Steam and L4D to Linux? Intel are definitely playing quite an active role, working with Valve, and taking feedback on board. Currently it's only the Linux driver, of course, but it seems reasonable to guess that some of the quality improvements coming out of this can also be fed into their drivers for other platforms.

The overall feeling here is definitely one of OpenGL coming into the ascendant again, while D3D appears to be languishing with a somewhat unknown/uncertain future. Can it be sustained? No idea, but the next few years sure won't be boring.

[quote name='samoth' timestamp='1344337679' post='4966978']
What else could it mean but serious OpenGL support from IHVs?

Maybe, or it could take the same route that OpenGL on Windows takes to some extent; make it work for Game X.

For some time if you wanted performance you had to hit the same path as iD games, maybe the same will happen when it comes to following Valve's lead onto Linux? Do it their way or fall off the 'fast' path.

We'll see how it works out - I remember when Linux games appeared in the shops for a short while around 1999 with the iD games going on sale; at the time that failed to set the world alight as it seemed no one wanted to buy them. Maybe, 10+ years on Linux users (note: users. I maintain Stallman is a crazy person) as a little more pragmatic about things and Steam will work out and enough of a market share will be carved out for a good feedback loop to be generated with regards to market share, driver development and tool development going forward.

My only 'worry' about that is the continued involvement of the ARB who, historically, simply don't make good choices.
OpenGL2.0 and 3.0 are proof of this and nothing they have done since then has convinced me otherwise - if gaming on Linux makes it then it'll be down to Valve, NV and AMD working together and not the ARB.

I'm watching with intrest to see how this pans out, not least of all because it might well affect my day job
[/quote]

The big problem with IDs Linux push was that there was essentially only one game you could find in stores (Quake3) and the number of stores carrying the Linux version was extremely limited, most Linux users ended up buying the Windows version and downloading the Linux binary anyway since that was the easiest option (The pragmatic users went with the path of least resistance)

With steam the big change is that everything is available for everyone at any time and buying a game for PlatformX usually lets you install and play the same game on PlatformsY and Z aswell (So even users of dualboot systems don't have to choose between buying for Windows and buying for Linux, they just buy it and play on whatever OS they happen to be logged into at the moment) (Personally i primarily buy Windows versions even though i use Linux aswell since it is far easier to get Windows games running in Linux than vice versa and having to reboot or switch machine to play a different game is far too annoying (With work there isn't much choice, Linux is simply the better OS for what i'm doing (apart from some legacy ASP.Net systems i have to maintain that just won't work properly with mono)).

As for what Valves Linux move will do for OpenGL i'd expect pretty much the same as AAA OpenGL use on Windows and Mac have done, IHVs will optimize the paths used by big AAA titles, it doesn't really matter that much though, indie titles will not push the limits far enough for that to matter and end users don't care if random indie title X runs at 3000 fps or 6000 fps (They will however care if expensive AAA title Y runs at 25fps or 60fps but as long as the IHVs optimize for the AAA titles its all good), The API is fine, you can complain about the ARB making bad or slow decisions but the API itself is fine(it might not be perfect but it doesn't have to be), it gives developers access to the features they need on the platforms they're targeting and according to Valve OpenGL also still performs better on both Windows and Linux than D3D9 does and they did manage to get better performance in Linux than on Windows so overall things are looking decent.

The main problems i see with gaming on Linux, (apart from the low number of available titles) is hardware support, There still isn't a really good solution for more advanced controllers, the soundsystem(s) are a bit of a mess and the desktop enviroments take far too much tweaking to get really good(Which really scares users away, Unity might be easy to use but its a real pain if you want to do anything even remotely advanced while Gnome/KDE have become quite a mess in the latest versions.

When it comes to OpenGL the biggest problem is Apple, they add support for newer versions at an extremely slow pace, 4.3 will not be relevant for another 2-3 years (The main reason to use OpenGL is to support OS X, and that means using OpenGL 2.1+extensions today or possibly 3.2)

The API is fine, you can complain about the ARB making bad or slow decisions but the API itself is fine(it might not be perfect but it doesn't have to be), it gives developers access to the features they need on the platforms they're targeting and according to Valve OpenGL also still performs better on both Windows and Linux than D3D9 does and they did manage to get better performance in Linux than on Windows so overall things are looking decent.

I disagree on the API - the bind to edit model is broken. The D3D model of 'operations on objects' is saner. The ARB put two years of work into a better API with these semantics (still C style, not C++ I might add) and then dumped it. Until DSA is the norm the API will remain broken.

The OpenGL vs D3D9 thing is a non-event.
I've commented on this else where; D3D9 is known to be slower on small batches than OpenGL, it's been public knowledge for some time.
The 'zomg fps difference!' reaction is also a non-event once you look closer at it;
Linux + OpenGL : 3.17ms/frame
Win7 + D3D9 (270fps): 3.7ms/frame
Win7 + D3D9 (304fps): 3.29ms/frame

Once you factor in differences in code due to being able to clean write the OpenGL backend to take more advantage of 'lessons learnt' on the D3D9 and probabl with a more modern slant on things (they uses a DX11 class device; how many D3D11 class feature extensions or NV extensions did they use?) and the D3D9 overhead 0.12ms/frame is... well, nothing. (The 0.6ms was worrying but they basically said in their post 'opps, we got the batching wrong' although apprently no one noticed this 'performance loss').

I suspect that if they gave the same treatment, a clean rewrite, using D3D11 and properly structured for it then on Windows the performance would be equal at worst, if not slightly better as a well structured D3D11 app will have less CPU overhead than a D3D9 application (or indeed a D3D11 application written in the D3D9 style).

In short; well done to Valve but nothing we didn't already know about D3D9 has been found.

You guys are no fun . I was having so much fun with compute shaders (actually, still have ).
gravitational n-body: https://github.com/progschj/OpenGL-Examples/blob/master/experimental/XXcompute_shader_nbody.cpp

Linux + OpenGL : 3.17ms/frame
Win7 + D3D9 (270fps): 3.7ms/frame
Win7 + D3D9 (304fps): 3.29ms/frame

The 303.4fps was Win7 + OpenGL, not D3D9. But yes, D3D9's high per batch overhead is old news, what isn't old news is that (nvidias) OpenGL drivers are still good enough to take advantage of this. (Most "recent" games with both OpenGL and D3D9 renderers have gotten far worse performance with OpenGL and it does show that OpenGL performance is "good enough"). As for what OpenGL version they're using it is quite likely that it is 2.x since they didn't make a clean rewrite, (its based on the Mac version afterall).

I think people are over-excited about Valve's contribution to all of this. Desura has already been providing a viable portal for Linux games for some time now. I don't see Valve's entry as groundbreaking; rather, they do not want to be left behind. The endorsement of Valve however is good for OpenGL because Desura doesn't have the brand name recognition or pull that Valve has.