[Jawed]

OpenGL is pretty dominant in the non-gaming realtime 3D rendering sector of the market. D3D has mostly failed there as far as I can tell.

[Andrew Lauritzen]

Originally Posted by Jawed

OpenGL is pretty dominant in the non-gaming realtime 3D rendering sector of the market. D3D has mostly failed there as far as I can tell.

True, but that has almost nothing to do with the API. In fact, those folks are still mostly stuck on OGL 1.x. I'll also note that the folks that choose "open" APIs for philosophical reasons (like academics) are besides the point of this discussion. While that's great and all, it's unrelated to which API is actually more practically useful for shipping a game on a wide variety of hardware and earning money.

[Ethatron]

Originally Posted by Andrew Lauritzen

But that said, the reality is that the core concept of GL (design by democracy) has just proven far less effective than DX's "benevolent dictator" model.

I disagree that OpenGL is democratic in any way. The extension mechanism is anarchic (non-hierarchical, non-authoritive and voluntary), the core I wouldn't call the result of a democratic process as it's not shaped by consensus, if consesus would have been enough to get features into the core it'd have been a very different story. Instead it's plutocratic, members with enough power set the rules.

In my opinion it's part of the reason why the ideal doesn't coincide much with reality is that there is a great deal of authoritarian acceptance on the suppose consumer (developer) side. They a) accept that change has to be approved, b) supported by hardware vendors, c) comes from the board and or hardware-vendor.

It certainly isn't clear to most who are connected to it, that they can think as much out-of-the-box as they want to and are collectively able to contribute to the shape of it.

Let's take an example. If you know as a software vendor that hardware supports something in a way you need it and an interface doesn't exist, it would be smart to conceptualize and isolate a possible interface and off-load it into extension-form, do a reference implemention and submit it to the database. Other software vendors can pick it up, and in the end even hardware vendors may pick it up.

This of course is idealistic. Put you'll recognize a lot of the cathedral vs. bazaar philosophy discussions from open-source. As long as people believe in the authoritive component in all of OpenGL it can't become the rich hub of experimental evolution which is certainly imaginable with the current structure of the board and the openness to any kind of extension.

In the end of the day, OpenGL+ext fails the way it fails not because of a technical limitation, but because of the mental model and actions of all the individuals involved in it. OpenGL didn't manage what Linux managed.

[rpg.314]

Originally Posted by Andrew Lauritzen

I have to agree that I think OpenGL - while slowing improving - has been in a unique position to actually change up the landscape of rendering APIs by doing truly forward-looking stuff like moving to explicit command buffer creation, dependencies, etc. But yet they seem to content to just follow DX (almost exactly), which is kind of sad at this point. And with all of their adding checkbox features, they still haven't addressed some of the basic problems in the API (direct state access is a good example, but I want to see far more than just that done)!

But that said, the reality is that the core concept of GL (design by democracy) has just proven far less effective than DX's "benevolent dictator" model. In the GL space there is no one that can really force people to standardize on hardware and features and quite frankly, that's why they end up following as well: because they can count on the features in DX being available on all GPUs as that is the primary design target.

Secondarily but not less important is the fact that no one writes good software infrastructure around GL and drivers. The Khronos conformance tests are a joke in terms of actually testing the entire API (including failure mode testing), which directly impacts driver quality. I shouldn't harp on GL too much here though as CL is 100x worse.

Regarding extensions, it's nice in theory that they exist formally in GL but it doesn't really matter much in practice. GL itself is already dicey enough that you can't really trust it to be fully portable (due not really knowing if you've inadvertently relied on a non-standard feature that just "happens to work" on one implementation), and once you add extensions you might as well be programming directly to a card's command buffer format.

Extensions are a proof of concept to allow key stakeholders to fool around with and then pressure the relevant standards, but none of these uses require a public mechanism like GL has. And let's not forget that all of the big GPU vendors have "unofficial" DX extension APIs as well that actually get used in games, unlike a lot of GL extensions.

I think GL's stagnation is just a sign of Khronos' inability to agree on anything. That and the gradual decay of desktop as a platform.

First the latter. If you have to use Linux/Mac, then there is no option whatsoever. Even on Mac, if and when Apple deigns to upgrade to a ~3 year old API, we'll get what has been available to every DX client for 3 years now.

And even on desktop, I see MS as gradually focussing away from it. Next gen consoles will be DX11 class and when they come out every one will switch to DX11 as their primary platform, leaving evolution of the API in nobody's hands.

As for the former, GL's bind to use model is atrocious. While extensions are talked up all the time, the good ones are languishing. Nvidia has been the real innovator here. Direct state access, bindless graphics are great extensions, have been around for several years and why the hell aren't they in core?

The situation on CL front is worse. The hw is miles ahead of CL and all CL has to offer is G80 class programmability. It's API is far better than GL, but the lack of updates is showing. Some years ago, IIRC, there was a presentation going around saying OCL will be here in 2012. Well, it's 2012 by my watch and.... It's telling that AMD decided to not work with Khronos for HSA. Let's hope they will have better luck.

Finally, Khronos has never developed/evolved a major standard as far as I can tell. GL was donated by SGI. CL was donated by Apple. GL has just been following DX since ~2000 and CL has nobody to follow so it is stuck.

The sad reality is, IMO, the only people who use GL are those who are out of choices.

[rpg.314]

Originally Posted by Andrew Lauritzen

True, but that has almost nothing to do with the API. In fact, those folks are still mostly stuck on OGL 1.x. I'll also note that the folks that choose "open" APIs for philosophical reasons (like academics) are besides the point of this discussion. While that's great and all, it's unrelated to which API is actually more practically useful for shipping a game on a wide variety of hardware and earning money.

Universities have to support a student body that is increasingly turning to Macs, ruling out DX. There's more than just philosophy there.

[Andrew Lauritzen]

Originally Posted by rpg.314

Universities have to support a student body that is increasingly turning to Macs, ruling out DX. There's more than just philosophy there.

Maybe today, but GL has always been in wide use in academia, regardless of platform limitations. It was definitely philosophical at my university, although part of it was of course that universities still by and large teach immediate mode OpenGL 1.0 :S

Which actually is another part of the problem... OpenGL doesn't know whether it wants to be a high or low level API. While DX has been driving as quickly towards being low-level as possible and somewhat dragging OpenGL along with it, there are still a vocal minority of people who think that how "easy" something is to write in GL should factor into it (I am not one of them obviously). That sort of fundamental disagreement on where to target the API certainly contributes to its current state.

[rpg.314]

Originally Posted by Andrew Lauritzen

Maybe today, but GL has always been in wide use in academia, regardless of platform limitations. It was definitely philosophical at my university, although part of it was of course that universities still by and large teach immediate mode OpenGL 1.0 :S

Which actually is another part of the problem... OpenGL doesn't know whether it wants to be a high or low level API. While DX has been driving as quickly towards being low-level as possible and somewhat dragging OpenGL along with it, there are still a vocal minority of people who think that how "easy" something is to write in GL should factor into it (I am not one of them obviously). That sort of fundamental disagreement on where to target the API certainly contributes to its current state.

I doubt such people sit on the committee.

[rpg.314]

If anybody has gone through the compte shader spec, is there anything you can do in CL but not with the compute shader?

I couldn't find anything in a quick pass.

[Andrew Lauritzen]

Originally Posted by rpg.314

I doubt such people sit on the committee.

You'd be surprised...

And yes there are a few things you can do in CL but not compute shader, but it's sort of hard to tell for sure since it's unclear what exactly is legal in CL from the spec... it's not the best written spec, which is another part of the problem.

[rpg.314]

Originally Posted by Andrew Lauritzen

And yes there are a few things you can do in CL but not compute shader, but it's sort of hard to tell for sure since it's unclear what exactly is legal in CL from the spec... it's not the best written spec, which is another part of the problem.

Care to speculate?

[Andrew Lauritzen]

Originally Posted by rpg.314

Care to speculate?

In CL you have "pointers" but it's not totally clear what is legal to do with them... can you store a linked list and traverse it in global memory? Can you even store a pointer from one kernel and reload it in the next? Unclear from the spec. NVIDIA has claimed that this is disallowed in their OCL whitepaper but people do it. Likely the answer is no to these, but it "tends to work" on most implementations which is part of the reason why I have zero faith in CL kernels being portable without testing.

There are a pile of things you can query in CL as well like hardware warp size, etc. that technically allow you to write stuff like persistent threads style code while being semi-"safe". This is impossible in DX of course as you never know the hardware SIMD size. That said even in CL it's a bit dicey because I don't believe the spec guarantees that operations across a "warp" are atomic even if it exposes the size to query. It's a bit of a mess.

[Blazkowicz]

meanwhile, Mesa supports opengl 3.0 ; and in the news was Valve playing with an opengl 2.1 renderer for left4dead 2.
dunno what Intel on Windows is up to.

but adoption of opengl versions is slow, maybe because opengl is foremost the code that "runs everywhere". such as minecraft.
opengl 4.x would get adoption if high end windows games used it (this is the platform where you can install a driver by clicking setup.exe)

[codedivine]

Originally Posted by rpg.314

If anybody has gone through the compte shader spec, is there anything you can do in CL but not with the compute shader?

I couldn't find anything in a quick pass.

AFAIK the basics are all there but this document (http://www.opengl.org/registry/specs...ute_shader.txt) says that numerical precision is "somewhat relaxed" compared to OpenCL. Also, AFAIK the full set of numerical functions for fp64 (such as sin, cos) is not provided in GL but is required in CL if an implementation supports cl_khr_fp64 I believe.

OpenCL is also far more flexible in terms of task queueing whereas everything in GL looks synchronous with no event system.

I don't really see a reason to use OpenGL compute shaders over OpenCL for people not doing graphics. I would have preferred to see Khronos work on improving OpenCL faster, and provide better CL/GL interop, instead of reinventing CUDA v1.0 the n-th time.

[Andrew Lauritzen]

Originally Posted by codedivine

I don't really see a reason to use OpenGL compute shaders over OpenCL for people not doing graphics. I would have preferred to see Khronos work on improving OpenCL faster, and provide better CL/GL interop, instead of reinventing CUDA v1.0 the n-th time.

Sure, no reason to use GL compute for non-graphics work, but frankly a large portion of the work that is run on GPUs - even in compute APIs - is graphics-related. Interop is a bad direction since having separate handles, schedulers, queues, etc. never ends up working efficiently in practice, even in the case where it's all on one GPU and set of drivers. Compute shader/GL compute is just a far better solution for games.

[codedivine]

Originally Posted by Andrew Lauritzen

In CL you have "pointers" but it's not totally clear what is legal to do with them... can you store a linked list and traverse it in global memory? Can you even store a pointer from one kernel and reload it in the next? Unclear from the spec. NVIDIA has claimed that this is disallowed in their OCL whitepaper but people do it.

Well, speaking from limited knowledge here, but I am with Nvidia here that it is not legal to store a pointer and reload it from a different kernel invocation.

The thing to understand is that in OpenCL (at least for 1.1), the physical location of buffer objects is not guaranteed to be constant between one kernel invocation and the next. It is simplest to understand this in the context of a discrete GPU. Lets say you have discrete GPU with its own GPU memory and you allocate a buffer on the device. The driver is free to swap the buffer in and out of the device as it pleases in between kernel invocations. It is not really different than GL in that regard. So storing pointers simply does not make sense and is not legal. Some implementations, which don't move the buffer objects, might offer this functionality but is not portable.

However, some types of data structures CAN be portably implemented by carefully storing and using byte/element offsets to buffer rather than true pointers.

[Andrew Lauritzen]

Sure, I'm well aware of how the hardware and driver model works, but the CL spec - and more importantly, the implementations - are really unclear. In practice it's probably only legal to use index-based data structures as you note, but the fact that pointers "tend to work" in most implementations is *a bad thing*. It means people write code that may work while they are testing it but is actually undefined/illegal and might blow up on other CL implementations, or even just if the wind is blowing in a different direction that day.

If it is indeed stuck with indexed-based structures, it may not actually even be more powerful than DirectCompute, etc. It just lets you shoot yourself in the foot more seriously

[Davros]

If doing certain things with pointers isnt legal, why are compilers allowing it

[Andrew Lauritzen]

Originally Posted by Davros

If doing certain things with pointers isnt legal, why are compilers allowing it

"Because they can" - the conformance tests are pretty awful, as I mentioned. Some of these things are legitimately hard or impossible for a compiler to provably disallow (due to the poor way that the spec is written mostly), so it's easier just to allow it all and say some of it is "undefined". That said, I wouldn't be surprised if that vast majority of OCL kernels written to date unknowingly rely on undefined behaviour, which is exactly the problem.

[silent_guy]

Originally Posted by Andrew Lauritzen

"Because they can" - the conformance tests are pretty awful, as I mentioned. Some of these things are legitimately hard or impossible for a compiler to provably disallow (due to the poor way that the spec is written mostly), so it's easier just to allow it all and say some of it is "undefined". That said, I wouldn't be surprised if that vast majority of OCL kernels written to date unknowingly rely on undefined behaviour, which is exactly the problem.

Also: it's not as if you can't hang yourself with C or C++...

[Andrew Lauritzen]

Originally Posted by silent_guy

Also: it's not as if you can't hang yourself with C or C++...

Yup, but 1) much less easily and 2) you don't ship C++ code to run on a random JIT somewhere that you've never tested on and expect it to work...

[Rodéric]

I don't see why the PS4 would waste any time on OpenGL, whichever version.

[Davros]

Then what api is viable for them, Dx11 the api of microsoft ?

[MJP]

Consoles don't need to use PC API's, they can use their own API that's tailored to the specifics of their hardware.

[Silent_Buddha]

Originally Posted by Davros

Then what api is viable for them, Dx11 the api of microsoft ?

For PS3 that would be LibGCM or PSGL. For X360 that would likely be a derivative of DirectX.

Regards,
SB

[Simon F]

Note: Texture compression and Quality Metrics related posts have been moved here: http://forum.beyond3d.com/showthread.php?t=63495