[codedivine]

OpenGL 4.3 specifications are now up on the registry:
http://www.opengl.org/registry/

New addition: Compute Shaders! Wha?

[Broken Hope]

Nvida driver with support.

http://www.nvidia.com/content/devzon...river-4.3.html

[Ryan Smith]

Originally Posted by codedivine

New addition: Compute Shaders! Wha?

There are some pretty specific scenarios Khronos is targeting with OpenGL compute shaders, not to mention a desire to make OpenGL more approachable to DirectX developers.

http://www.anandtech.com/show/6134/k...pression-clu/3

[AlexV]

Originally Posted by codedivine

New addition: Compute Shaders! Wha?

CL-GL interop is not exactly a substitute for something that exposes similar functionality yet lives in the same API and employs the same scheduling mechanism. This was a reasonably big advantage for DX CS, IMHO.

[rpg.314]

Originally Posted by AlexV

CL-GL interop is not exactly a substitute for something that exposes similar functionality yet lives in the same API and employs the same scheduling mechanism. This was a reasonably big advantage for DX CS, IMHO.

True, but does that mean that OCL is a dead end and we'll see khronos adding more features into compute shaders going forward? So now we have two ways of doing the same thing.

WRT CL, what the bloody hell? 6 years after G80 and all they can offer is G80+CLU. The hw is miles ahead of what CL is offering. Pathetic.

[willardjuice]

WRT CL, what the bloody hell? 6 years after G80 and all they can offer is G80+CLU. The hw is miles ahead of what CL is offering. Pathetic.

But but but...extensions!!! and it's open!!!

[lanek]

Originally Posted by rpg.314

True, but does that mean that OCL is a dead end and we'll see khronos adding more features into compute shaders going forward? So now we have two ways of doing the same thing.

WRT CL, what the bloody hell? 6 years after G80 and all they can offer is G80+CLU. The hw is miles ahead of what CL is offering. Pathetic.

About OCL, not really, but OCL is far more generalist and dont concern directly gaming and general graphism, it is more flexible and aimed at "computing" on a large sense ... OpenGL, for graphic and games, need to bring a more suitable solution directly with it for some specific purpose.

[rpg.314]

Originally Posted by willardjuice

But but but...extensions!!! and it's open!!!

Where are the extensions for recursion, function pointers, dynamic dispatch, unified memory space....

[rpg.314]

Originally Posted by lanek

About OCL, not really, but OCL is far more generalist and dont concern directly gaming and general graphism, it is more flexible and aimed at "computing" on a large sense ... OpenGL, for graphic and games, need to bring a more suitable solution directly with it for some specific purpose.

Non sense argument. Besides, I could be wrong but compute shader seems like a crippled version of cl kernel.

[AlexV]

Originally Posted by lanek

but OCL is far more generalist and dont concern directly gaming and general graphism

Part of OCL's problem is that it doesn't concern anything directly, it's more like a hodge-podge of who pulled in which direction when. Another big part is that it doesn't have a proper arbiter to rap people over the knuckles and actually give it some direction.

[I.S.T.]

Hasn't that been a big problem for OGL as a whole for years now?

[rpg.314]

Originally Posted by I.S.T.

Hasn't that been a big problem for OGL as a whole for years now?

Yes.

[MJP]

Obviously GPU compute is useful for a lot of things outside of graphics, but it's also important to note that they're also really good for graphics! In that regard compute shaders have been a major advantage (IMO) for D3D compared to OpenGL. In D3D if I wanted to render to a texture and then use a compute shader to do some fancy maths on it with a compute shader, it was easy since compute shaders are a first-class citizen and no interop is required. Or if I wanted to to have a whole slew of shader code shared between a compute shader used for deferred rendering and a more standard forward rendering pixel shader, it was also easy since both shaders use the same language, compiler, and API.

[Rodéric]

Where's my OpenGL 2 Lean & Mean ?
Where's my OpenGL Long Peaks ?

Always promesses, never delivering...

[fellix]

What GLES 3.0 and GL 4.3 Means for Developers

[Rodéric]

It's way too little and it's too late.

What we need/want is a minimal standard command buffer API, standard texture layouts in memory, and good memory control too, gimme an ISA and it will be even better. (Not required for now, a GPU specific compiler is ok)

Alternatively, go higher level and make Chapel (http://chapel.cray.com/) work well with GPU/heterogenous compute.

[willardjuice]

Originally Posted by fellix

What GLES 3.0 and GL 4.3 Means for Developers

lol I love how there are still people convinced that extensions are a great thing. It really must be me...

[rpg.314]

Originally Posted by MJP

Obviously GPU compute is useful for a lot of things outside of graphics, but it's also important to note that they're also really good for graphics! In that regard compute shaders have been a major advantage (IMO) for D3D compared to OpenGL. In D3D if I wanted to render to a texture and then use a compute shader to do some fancy maths on it with a compute shader, it was easy since compute shaders are a first-class citizen and no interop is required. Or if I wanted to to have a whole slew of shader code shared between a compute shader used for deferred rendering and a more standard forward rendering pixel shader, it was also easy since both shaders use the same language, compiler, and API.

Cool. So can we please have all the CL functionality baked into GL compute shaders, pretty please?

[3dcgi]

Originally Posted by willardjuice

lol I love how there are still people convinced that extensions are a great thing. It really must be me...

Laughing at someone's opinion without explaining why it's funny isn't much of a contribution.

[willardjuice]

Originally Posted by 3dcgi

Laughing at someone's opinion without explaining why it's funny isn't much of a contribution.

Because you hear the same thing over and over. "Extensions are great! Now developers and end users don't have to wait for all the red tape! Everyone wins!"

But in reality, they just end up making a mess. Developers have to maintain a more complex code base (what if ihv x and y support extension w but ihv z doesn't? or what if ihv x, y, and z all implement extension w differently? what if it's changed again when it's officially added to the API?) for usually minor gains. Things are even worse in the embedded market. Extensions could work if somehow we could force all the relevant ihv's to agree on implementing the same feature in same manner in the same timeframe.

I'd much prefer D3D10+'s all or nothing approach. I can perform essentially one check and immediately know what the card is or is not capable of. I realize this is more of a personal preference thing (and my initial post was probably a bit too strong), but never will extensions (in their current form) make sense to me.

[3dcgi]

An API that's stagnant requires developers to use extensions and have a messy code base, but if an extension is truly useful it should show up in competing hardware about two years later. Since game development times are so long this means most games won't ship until a lot of hardware supports the feature. The problem comes when the API isn't updated frequently enough to pickup useful features.

It's hard to force IHVs to implement features in the same time frame and this removes a benefit of innovation by being first. It takes a gorilla like Microsoft to drag companies in a direction they wouldn't otherwise go.

[Ethatron]

Extension-capability also gives a HV to express a different opinion than either the standard-body or a API-owner, and that is a good thing. Besides supporting true evolution (instead of planning) it allows a HV to play it's strengths in a context of it's choosing. I don't know if it exists, but nVidia could for example provide OGL-CUDA interfaces via extensions, formally and well defined. As much as I respect the work of ATI in hacking up the DX9-API ("extending" it), it shouldn't be necessary to do it that way. Extendability is better.

[MJP]

Originally Posted by willardjuice

Because you hear the same thing over and over. "Extensions are great! Now developers and end users don't have to wait for all the red tape! Everyone wins!"

But in reality, they just end up making a mess. Developers have to maintain a more complex code base (what if ihv x and y support extension w but ihv z doesn't? or what if ihv x, y, and z all implement extension w differently? what if it's changed again when it's officially added to the API?) for usually minor gains. Things are even worse in the embedded market. Extensions could work if somehow we could force all the relevant ihv's to agree on implementing the same feature in same manner in the same timeframe.

I'd much prefer D3D10+'s all or nothing approach. I can perform essentially one check and immediately know what the card is or is not capable of. I realize this is more of a personal preference thing (and my initial post was probably a bit too strong), but never will extensions (in their current form) make sense to me.

Yeah I really have to agree regarding extensions. Don't get me wrong, I love making use of every feature available in the hardware, but only if there's enough user base for that particular hardware. For consoles it's almost a no-brainer: you know there will be millions of that hardware configuration in the wild, so it makes sense to add code paths that exploit its unique features. But if an IHV adds extension X that's only supported on GPU family Y and above...well that's less obvious to me. In fact it seems like in such cases the only party that stands to gain much is the IHV, and so I won't be very convinced by their urgings to use their super-awesome extension.

I really feel that the feature levels system is one of the best things that ever happened to D3D, since they let you easily partition your target hardware into large groups with a corresponding set of functionality. I'm actually pretty upset that they added some new caps for D3D11.1.

[homerdog]

Originally Posted by Ethatron

Extension-capability also gives a HV to express a different opinion than either the standard-body or a API-owner, and that is a good thing. Besides supporting true evolution (instead of planning) it allows a HV to play it's strengths in a context of it's choosing. I don't know if it exists, but nVidia could for example provide OGL-CUDA interfaces via extensions, formally and well defined. As much as I respect the work of ATI in hacking up the DX9-API ("extending" it), it shouldn't be necessary to do it that way. Extendability is better.

Extendability is great, but I'm not sure how you could logically argue against willardjuice here. It will never be practical for a developer to optimize its engine around extensions that only a small fraction of available hardware can support.

[Ethatron]

Once your in control of the target-hardware it is practical. Once the target hardware doesn't change for a while it is even a necessity to take advantage of all the unique capability.
I'm not arguing against willardjuice, I just remind you of the chance which is in extensions, and honestly as a developer I never bothered to have choice and exotic stuff if I wanted to, and I haven't been forced to support them all at point blank yet. I think it's a constructed argument which has no bearing in reality.
Code is an organic thing, it changes all the time, and API-changes are really very minor. Is deferred-shading now bad-bad-bad because I have to rewrite the whole core? Damn, they shouldn't have invented it.
The principle that extensibility is good per-se isn't invalidated by that a developer thinks a specific extension is a waste of time (of IHV resources). Wasting time on lamenting it, is the developer's problem.