PDA

View Full Version : Official feedback on OpenGL 4.1 thread



Khronos_webmaster
07-26-2010, 09:11 AM
Khronos Drives Rapid Evolution of Cross-Platform 3D Graphics with Release of OpenGL 4.1 Specification

- New open API specification available immediately;
- Wide-ranging enhancements with full backwards compatibility;
- Enhanced integration with OpenCL for seamless visual computing;
- Integrates OpenGL ES functionality for desktop and mobile platform portability

July 26, 2010 –Los Angeles, SIGGRAPH 2010 – The Khronos™ Group today announced the immediate release of the OpenGL® 4.1 specification, bringing the very latest graphics functionality to the most advanced and widely adopted cross-platform 2D and 3D graphics API (application programming interface). OpenGL 4.1 is the sixth update to OpenGL specification in two years, continuing the rapid evolution of this royalty-free specification. This new version continues to maintain full backwards compatibility to enable developers to begin using new features whenever they choose, while portably accessing state-of-the-art GPU functionality across diverse operating systems and platforms.

The OpenGL 4.1 specification has been defined by the OpenGL ARB (Architecture Review Board) working group at Khronos, and includes the GLSL 4.10 update to the OpenGL Shading language and is accompanied by a number of extensions introducing cutting-edge functionality to the OpenGL standard. The full specification is available for immediate download at http://www.opengl.org/registry. (http://www.opengl.org/registry)

New functionality in the core OpenGL 4.1 specification includes:

Full compatibility with OpenGL ES 2.0 APIs for easier porting between mobile and desktop platforms; The ability to query and load a binary for shader program objects to save re-compilation time; The capability to bind programs individually to programmable stages for programming flexibility; 64-bit floating-point component vertex shader inputs for higher geometric precision; Multiple viewports for a rendering surface for increased rendering flexibility.


New ARB extensions introduced with OpenGL 4.1 include:

OpenGL sync objects linked to OpenCL event objects for enhanced OpenCL interoperability; The ability to set stencil values in a fragment shader for enhanced rendering flexibility; Features to improve robustness, for example when running WebGL applications; Callback mechanisms to receive enhanced errors and warning messages.

Lastly, Khronos has simultaneously released a set of ARB extensions to enable as much OpenGL 4.1 core functionality as possible on previous generation GPU hardware; providing maximum flexibility and platform coverage for application developers.

doublejay
07-26-2010, 09:24 AM
Loading binary shaders! I like that!

Eddy Luten
07-26-2010, 09:54 AM
Wow, that was pretty fast and some nice features too!

mfort
07-26-2010, 11:54 AM
Please correct glspec41.core.20100725.withchanges.pdf, chapter K1, page 448, second bullet:
... the binary represtation of a program

kyle_
07-26-2010, 12:01 PM
Maybe im misreading the spec, but it looks like conforming implementation is allowed to support 0 binary formats of shaders ... doh?

Booner
07-26-2010, 12:23 PM
There are actually two different types of binary formats added in GL 4.1

I believe the one you are referring to is the ShaderBinary API that is part of the ES2_compatibility (http://www.opengl.org/registry/specs/ARB/ES2_compatibility.txt) extension.

The other is the GetProgramBinary API that is part of the get_program_binary (http://www.opengl.org/registry/specs/ARB/get_program_binary.txt) extension.

The former is more intended for offline shader compilation, and latter is intended caching compiled programs from one run of a program to the next for quicker loading times.

Jan
07-26-2010, 12:30 PM
Nice!

I especially find the following stuff great:

* Program Binary Support - ie. "shader blobs"
* Debug Output Notification - one of the best API enhancements! With D3D11 and PIX it is soooo great when you get real error-messages, instead of the dreaded GL_INVALID_XXX. Now IHVs please make good use of this debug-functionality and give us detailed error-messages please!
* Shader Stencil Export - finally the stencil buffer becomes useful again (haven't been able to make much use of it lately, because of the missing support to manipulate its content through shaders).

In general the spec seems to become more and more mature. No drastic API changes, only few new/improved features, but ones that are really useful.


As far as i can tell the most important features for future releases would be:

1) direct state access
2) multi-threaded rendering support

Can't think of other important features at the moment.


Really great work from the ARB through the last 2 years!
(No, i haven't forgiven you the GL3 thing, i still would have preferred a clean cut.)

So, how many hours will it take nVidia and AMD this time to announce the "world's first GL 4.1 driver" ? :-D

Jan.

Eddy Luten
07-26-2010, 01:01 PM
According to Ars Technica (http://arstechnica.com/software/news/2010/07/khronos-group-releases-opengl-41-claims-to-leapfrog-direct3d-11.ars), NVIDIA will release some 4.1 drivers on or before Wednesday, AMD shortly.

Groovounet
07-26-2010, 01:38 PM
Niceeeeeeeeee!

Once again it's much more than what I was expecting. I can't way to play around with it!

Alfonse Reinheart
07-26-2010, 02:27 PM
# GL_ARB_get_program_binary
# GL_ARB_separate_shader_objects
# GL_ARB_debug_output


With StarCraft II landing tomorrow, there's really only one thing to say: "It's about time!"

Now I want to see these extensions implemented on the widest range of hardware possible. Everything that IHVs still support should implement extensions.

Also, does anyone know what the expected hardware limitations of stencil_export will be? Will 3.x hardware be able to run it, or will it be reserved for 4.x?


OpenGL 4.1 is the sixth update to OpenGL specification in two years

Fifth. GL 3.3/4.0 were a single update; some features were simply spread between different hardware levels.

Either way, good job. OpenGL feels mostly finished now, ugly though some parts of it remain.

Aleksandar
07-26-2010, 02:57 PM
Really, really great job!!!
My congratulations!

Groovounet
07-26-2010, 03:42 PM
I think there is just 2 extensions from OpenGL 4.1 that are actually limited to OpenGL 4 hardware:
GL_ARB_vertex_attrib_64bit and GL_ARB_viewport_array. I guess an OpenGL 3.4 specification would be nice even if we can still use the extension mechanism.

I had a lot of expectations with the separate shader but the extension feels quite limited in lot of senario so that we have to use a unified program. I still need to have a closer look.

ScottManDeath
07-26-2010, 04:29 PM
DX10 has viewport and scissor arrays, so it should work on 3.x hw

Simon Arbon
07-26-2010, 06:35 PM
The end of a sentence seems to be missing in glspec41.core.20100725.withchanges.pdf
2.11.3 Program Objects
Page 60

If a program object that is active for any shader stage is re-linked successfully, the LinkProgram command will install the generated executable code as part of the current rendering state for all shader stages where the Additionally, the newly generated executable code is made part of the state of any program pipeline for all stages where the program is attached.

Groovounet
07-26-2010, 08:58 PM
Some more not consistant stuff in the API:



void ViewportArrayv(uint first, sizei count, const float * v);
void ScissorArrayv(uint first, sizei count, const int * v);
void DepthRangeArrayv(uint first, sizei count, const clampd * v);


I'm not sure what to thing about that as the token "array" has always referenced "array buffer" in the past.

Simon Arbon
07-26-2010, 09:38 PM
Typo in glspec41.core.20100725.withchanges.pdf page 470

L.3.98 Shader Stencil Export
Sharder stencil export enables shaders to generate a stencil reference value, allowing
stencil testing to be performed against per-shader-invocation values.

Alfonse Reinheart
07-26-2010, 10:25 PM
I had a lot of expectations with the separate shader but the extension feels quite limited in lot of senario so that we have to use a unified program.

Limited in what way? It even gives you a choice of rendezvous by resource or by name. I don't know how it could be more flexible. Encapsulating combinations in state objects only makes sense.

Chris Lux
07-26-2010, 10:42 PM
Nice additions and great work.


But, personally I was expecting two more things this time:
- shader includes in core
- direct state access

Is there a larger problem with the shader include extension? After it is an ARB extension I expected its inclusion into 4.1 core.

Anyway, great work.
-chris

barthold
07-26-2010, 11:20 PM
Chris,

As far as I know there's nothing wrong with GL_ARB_shading_language include. However, as far as I know it hasn't been shipped yet by any of the OpenGL vendors. Before sticking it into Core, it will be nice to get some experience with it first.

Barthold
(with my ARB hat on)

Chris Lux
07-27-2010, 12:49 AM
Ok, that is reasonable.

I, in my impatient nature, always hope that core features get adapted by the vendors faster. There are plenty of good and old extensions some vendors still do not support. So with making something a core feature i thought/hoped they would be kind of forced to implement it (looking at ATi here, nvidia is usually very fast with implementing new extensions).

So that leaves me hoping that the vendors at least support new extensions faster.

Regards
-chris

kRogue
07-27-2010, 01:13 PM
I just want to say thank you to the people who made the GL 4.1 specification, and that it happened so quickly. A major thank you for putting separate shader objects in! The following is not a request for features, but just in the spec:

There are a lot of shaders running around now, I would love to see a diagram of the "pipeline" of such in the GL specification or maybe on the reference card? Something that is in GL_ARB_tessellation_shader.txt (http://www.opengl.org/registry/specs/ARB/tessellation_shader.txt) in the answer to Issue (1).

and again thank you!

Groovounet
07-27-2010, 01:58 PM
If we use transform feedback or glBindAttribLocation(is it a really problem?) and maybe a couple of other linking related cases... we can't use separate shader or with a big work around. As I am I Siggraph I didn't had time to actually have a deep look at everything so I might have missed something here.



I had a lot of expectations with the separate shader but the extension feels quite limited in lot of senario so that we have to use a unified program.

Limited in what way? It even gives you a choice of rendezvous by resource or by name. I don't know how it could be more flexible. Encapsulating combinations in state objects only makes sense.

barthold
07-27-2010, 03:35 PM
There are a lot of shaders running around now, I would love to see a diagram of the "pipeline" of such in the GL specification or maybe on the reference card? Something that is in GL_ARB_tessellation_shader.txt (http://www.opengl.org/registry/specs/ARB/tessellation_shader.txt) in the answer to Issue (1).

and again thank you!

Your wish is our command :-) Seriously, here is what I have right now (see attachment). Is this what you are after?

Barthold
(with my ARB hat on)

Alfonse Reinheart
07-27-2010, 04:17 PM
If we use transform feedback or glBindAttribLocation(is it a really problem?) and maybe a couple of other linking related cases... we can't use separate shader or with a big work around. As I am I Siggraph I didn't had time to actually have a deep look at everything so I might have missed something here.

I don't see any unpleasant interactions with either of these. The only potential problem is if you want to use glCreateShaderProgram all the time. Since it goes directly from source strings to linked program object, there's no chance to call any of the pre-link settings functions. However, separate shader objects doesn't require that you use glCreateShaderProgram; it's simply a convenience function for those who's needs are simple enough to allow them to use it.

It would however be great if there were a version of glCreateShaderProgram that didn't perform compiling or linking. That it returned some kind of object that you could call the pre-link settings functions on and the call another function to do the compiling and linking.

Either that, or set up transform feedback parameters in the shader source somehow.

Groovounet
07-27-2010, 09:43 PM
One other thing I wonder: would if a reasonable to release a project with just the shader binaries? For example: If a build an OpenGL 3.3 software with GLSL 3.3 shaders, could we just have one binary for AMD and one for nVidia? Would there still work over time... with newer drivers (and updated GLSL compilers)?

If not, is the use case scenario is more: build once when we install the software or build when the shader binary load fail for any reason (updated drivers, updated graphics card, ...)?

kRogue
07-27-2010, 10:52 PM
Yes! That is the kind of diagram I am looking for.. this looks familiar though, was it in a power point or something when GL4 was first released (just in March)?

Though, it is not exactly what I am begging for, but so close that chances are I am getting greedy:

What I would like, and the difference I am asking is really, really tiny is like this [so tiny I feel almost ashamed to ask].

For each shader stage:
explicit arrows (that pdf has this in the long line broken into 4 bits og pages 2 and 3), but the difference being that the arrows are marked as in, out, in patch, out patch, etc. The other bit (and that pdf has this too to some extent) is "something" when one of the optional shaders are not part of a GLSL program. Being so shader oriented, a diagram without the compatibility pipeline too.

I'd imagine the picture I am after might be more pages though and one can make a pretty strong case that what I am asking for is just a tiny, tiny (epsilon) difference to than what you just gave. The core of what I am begging for is some text for the arrows but the text being what one writes in GLSL (and to a lesser extent GL)..

Rob Barris
07-27-2010, 11:33 PM
One other thing I wonder: would if a reasonable to release a project with just the shader binaries? For example: If a build an OpenGL 3.3 software with GLSL 3.3 shaders, could we just have one binary for AMD and one for nVidia? Would there still work over time... with newer drivers (and updated GLSL compilers)?

If not, is the use case scenario is more: build once when we install the software or build when the shader binary load fail for any reason (updated drivers, updated graphics card, ...)?

The latter. The binary shader approach in GL 4.1 is not a distribution format. It enables you to cache a compiled shader for re-loading at a later time on the same machine. OpenGL is free to deny that request for any reason in which case you would need to resubmit source to compile the shader (and then you could re-query and re-save the binary).

Chris Lux
07-28-2010, 01:01 AM
Ok, i will be the first to call for updated header files on the registry page. I am itching to try some of the new features.

-chris

CrazyButcher
07-28-2010, 01:14 AM
great work, with the separate shaders and binary shaders finally around! Good to see the match of dx11 now, I guess the only major thing missing is the threaded resource manipulation.

someone please update GLEW ;)

ScottManDeath
07-28-2010, 02:05 PM
I am building glew bymyself from the SVN. It lackes 4.1 core functions, and I had to disable ARB_cl_event, as well as manually tewak the debug output callback. I'm fine with that, since I only care about the debug functionality :P

Also, is there a way to find out whether a context was created with the debug bit set?

It seems that glGetInteger(GL_CONTEXT_FLAGS) will only return the GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT (0x01) (which has a different value than WGL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT (0x02), so I cannot use the WGL_CONTEXT_DEBUG_BIT_ARB (0x01))

I am currently hacking QT to create a debug context, where they use GL_CONTEXT_FLAGS to see whether the requested context matches what they wanted to.

I think this might be also useful in cases where a middleware/ library has some debugging facilities, but doesn't control context creation.

Chris Lux
07-29-2010, 12:46 AM
You could check for the GL_ARB_debug_output extension. On a non-WGL_CONTEXT_DEBUG_BIT_ARB context this extension is/should be not supported.

-chris

Gedolo
07-29-2010, 03:26 AM
Congragulations for this release.

Especially the compatibility with OpenGL ES.
It will save a lot of people a huge amount of time.
And the callback mechanism.

Now for future versions new and important features would be (ARB'ed form):


- Direct State Access (glad to see it's coming)
- multithreading
- OIT Order Independent Transparency (with only using ARB extensions)

Tomasz Dąbrowski
07-29-2010, 05:18 AM
When can we expect updated reference pages on opengl.org for 3.x/4.x?

What is current shipping status of DSA? Is it going to be included with future OpenGL version? What about ATI support?

Booner
07-29-2010, 05:47 AM
When can we expect updated reference pages on opengl.org for 3.x/4.x?

Any day. They were announced at the BOF yesterday. Just waiting for the website to be updated.


What is current shipping status of DSA? Is it going to be included with future OpenGL version?
Can't speak to that one.. but it would certainly be a great thing to include!


What about ATI support?
Yes. See http://www.geeks3d.com/20100727/ati-catalyst-10-7-available-with-three-new-opengl-extensions/

Khronos_webmaster
07-29-2010, 07:54 AM
Updated reference pages are now online:

OpenGL 4.1 http://www.opengl.org/sdk/docs/man4/
OpenGL 3.3 http://www.opengl.org/sdk/docs/man3/
OpenGL 2.1 http://www.opengl.org/sdk/docs/man/

Rosario Leonardi
07-29-2010, 07:58 AM
Incredible O_O
Finally the update reference.
Thanks a lot!!

Groovounet
07-29-2010, 09:09 AM
Incredible O_O
Finally the update reference.
Thanks a lot!!

And this is the least to say! I enjoyed the OpenGL 4.1 release but I think that I enjoy event more all the ecosystem announcement.

It's goooood to be an OpenGL programmer these days.

barthold
07-29-2010, 09:18 AM
Yes! That is the kind of diagram I am looking for.. this looks familiar though, was it in a power point or something when GL4 was first released (just in March)?

Though, it is not exactly what I am begging for, but so close that chances are I am getting greedy:



Yes I have shown those slides in the past, and tweaked them a bit. If you want to give it a shot and improve upon them, I'll be happy to mail you the ppt file. The whole rasterization stage and below still needs to be added as well.

Barthold
(with my ARB hat on)

Tomasz Dąbrowski
07-29-2010, 09:57 AM
Yes. See http://www.geeks3d.com/20100727/ati-catalyst-10-7-available-with-three-new-opengl-extensions/


Wonderful news! Has anyone tested it yet?

And new reference pages are also a good thing. Good job!

But now I can see another valuable feature (apart from -- of course -- including DSA into core -- or maybe even removing all pre-DSA functions).

Maybe reference pages should be extended with (perhaps somehow standardised) debug_output errors? It would be much easier than relying only on INVALID_VALUE and others error enums.

Y-tension
07-29-2010, 10:15 AM
Had to stop by to say congrats for the new release. The new features are absolutely fabulous!

ScottManDeath
07-29-2010, 10:50 AM
You could check for the GL_ARB_debug_output extension. On a non-WGL_CONTEXT_DEBUG_BIT_ARB context this extension is/should be not supported.

-chris

That is what I'm doing right now, but a debug context doesn't have to have the GL_ARB_debug_output extension, it could have other debug functionality. A core GL inspection would be useful in that case.

randall
07-29-2010, 11:00 AM
Referance Pages for 4.1 does not work on IE (there is an error when selecting any function).

Khronos_webmaster
07-29-2010, 11:46 AM
Looking into this issue. Seems there are other issues in Safari and Firefox also. We are working on this.

Groovounet
07-29-2010, 12:53 PM
and Chrome :p

kyle_
07-29-2010, 12:55 PM
Updated reference pages are now online:

OpenGL 4.1 http://www.opengl.org/sdk/docs/man4/
OpenGL 3.3 http://www.opengl.org/sdk/docs/man3/
OpenGL 2.1 http://www.opengl.org/sdk/docs/man/
This is great news.
Imo even better than the actual features introduced by new spec.

Great job.

Now to port spec's to xml and we are pretty much set ;).

kRogue
07-29-2010, 01:57 PM
Is there any chance to restore creating man pages for Unix systems? I've been trying unsuccessfully to generate man pages from the the sources, the current state of the GL wiki: http://www.opengl.org/wiki/Getting_started/XML_Toolchain_and_Man_Pages gives how to generate the xml, mentions man pages, but, does not have an entry in the makefile. I follow the instructions to setup the catalog stuff, but running



docbook2x-man something.xml


or for bash lovers:



for i in *.xml; do docbook2x-man "$i"; done


generates bad man pages at times [glTexImage2D comes out really bad on me]. Is there a possibility to add to the makefile "make man"? Sometimes I just want to type man glSomething.

I really like that glGet family has hyperlinks to the function that sets the value, that is really nice, similar for glGetShader too.

One suggestion, though potentially a great deal of work: to add a reference (chapter(s), section(s) and subsection(s)) where a given API point is named, so that one can get the quickly where in the spec it is described.

Something I just noticed for the GL3 man pages:



glFramebufferTextureLayer — attach a face of a cube map texture as a logical buffer to the currently bound framebuffer


That is the description of glFramebufferTextureFace, I guess the text should be "glFramebufferTextureLayer — attach a face of a texture array as a logical buffer to the currently bound framebuffer" In all honesty, kind of nitpicking I am there.

xahir
07-30-2010, 06:57 AM
@Khronos

GJ for the new specs / man pages and all.

I want to comment on the spec versioning. Hardware brands are named under the version of DirectX (either we like it or not). So we have PreDx10HW, DX10HW, DX10.1HW and DX11HW.
Some of the specs released on 4.1 (especially multiple viewports) exists on DX10.1HW and some specs on 3.3 (sampler objects, GLSL33 attrib location layout ...) can be implemented on DX10HW.

When I want to release a product I try to handle the balance between graphics quality and spectrum of hardware supported. If OpenGL continue to release specs this way we are forced to think the worst and always try to check whether an extension is supported, implement both ways etc. It could be nice if we have some revision number on OpenGL versions so we may select a version with a revision. I guess minor version was there for this purpose but it is not being used this way.

@kRogue


That is the description of glFramebufferTextureFace, I guess the text should be "glFramebufferTextureLayer — attach a face of a texture array as a logical buffer to the currently bound framebuffer" In all honesty, kind of nitpicking I am there.


Actually, I cannot find any FramebufferTextureFace in specs, instead the FramebufferTextureLayer does the job for cubemaps (in specs, Table 4.12). Additionally, FramebufferTextureLayer can also attach level of a 2d-array or a 3d texture level.

randall
07-30-2010, 07:47 AM
For OpenGL 3 capable hardware, these new extensions are provided:

ARB_viewport_array (also in core OpenGL 4.1)

viewport array is DX10HW.

kRogue
07-30-2010, 08:29 AM
bash$ grep FramebufferTextureFace /usr/include/GL3/gl3.h
GLAPI void APIENTRY glFramebufferTextureFace (GLenum, GLenum, GLuint, GLint, GLenum);


I could not find FramebufferTextureFace is not in the specification either. For FramebufferTextureLayer, to use a face of a cube map you provide an integer 0<=i<=5, for the Face, it looks like you use one of the enums from the family GL_TEXTURE_CUBE_MAP_POSITIVE/NEAGTIVE_X/Y/Z

Oh well, spec bug or manpage bug?

Alfonse Reinheart
07-30-2010, 03:27 PM
some specs on 3.3 (sampler objects, GLSL33 attrib location layout ...) can be implemented on DX10HW.

All of GL 3.x should be implementable on DX10 hardware. That's the dividing line between GL 3.x and 4.x.


If OpenGL continue to release specs this way we are forced to think the worst and always try to check whether an extension is supported, implement both ways etc. It could be nice if we have some revision number on OpenGL versions so we may select a version with a revision.

Does it really matter? If the implementation didn't support a hypothetical GL 3.4, wouldn't you need to support a different codepath anyway? What's the difference between checking a version number and an extension?

Ultimately, all GL 3.3-capable hardware will support the various extensions they can. The only reason to create a version 3.4 would be to push a lazy implementer (I'm looking at you, ATI) to support something they should have been supporting.

xahir
07-31-2010, 01:18 AM
I was not aware that all features of DX10.1 is implementable on DX10HW (such as viewport arrays or blend state for each color attachment).

Versioning instead of extensions is favorable since we will have numVersion paths instead of numExtension^2 paths. That is we target a brand of hardware instead of vendor specific implementations. This was Microsoft's marketing for Dx10 (No Hardware Caps)

Alfonse Reinheart
07-31-2010, 06:42 AM
I was not aware that all features of DX10.1 is implementable on DX10HW (such as viewport arrays or blend state for each color attachment).

Which is why DX10.1-specific features are provided via extensions to 3.x. NVIDIA DX10 hardware can't handle 10.1, so in OpenGL those are extensions.


Versioning instead of extensions is favorable since we will have numVersion paths instead of numExtension^2 paths.

That assumes a combinatorial explosion of paths based on the number of extensions, which is not necessarily the case. Extensions that directly affect shaders may indeed have this problem.

Because an extension generally affects a small, localized section of code, the path for one extension generally does not intersect with the path for another extension. Take viewport arrays and separate shader objects. In general, these things don't directly interact. Your code for dealing with rendering to multiple attachments doesn't generally care about the shader objects.

The presence or absence of viewport arrays will allow you to render things in a certain way. But this will not affect the paths you have written for separate shader objects. The only difference between this and a hypothetical GL 3.4 is that it is theoretically possible to have one and not the other. But you don't code one specifically so that it requires the other, so the presence or absence of the other is irrelevant.

So while you do indeed have 4 potential paths, you did not specifically code 4 paths for each eventuality. You coded 2 paths dealing with program objects, based on whether separation was possible. And you coded 2 paths dealing with viewports and rendering to attachments, based on whether that functionality is available.

Literally, the only difference is what your paths check for. In the extension case, you have two separate if-statements, one for each extension. In the hypothetical 3.4 case, you still have two separate if-statements (or some other form of dynamic decision making, like virtual function calls), because the code for the paths is in two separate locations. It's just that in both cases, you're checking the version number.


This was Microsoft's marketing for Dx10 (No Hardware Caps)

Yeah, and we saw how well that worked out, what with DX10.1 and all. DX10.1 may as well be called, "Features we wanted in DX10, but NVIDIA wasn't supporting."

Chris Lux
08-01-2010, 02:49 AM
could someone please update the glext.h and gl3.h headers? or is there something more planned for the update (saw some mention of a glplatform.h)...

Dark Photon
08-01-2010, 09:26 AM
Updated reference pages are now online:

OpenGL 4.1 http://www.opengl.org/sdk/docs/man4/
OpenGL 3.3 http://www.opengl.org/sdk/docs/man3/
OpenGL 2.1 http://www.opengl.org/sdk/docs/man/

Would appreciate it if the web site guys could update the site menu so you can get to the 4.1/3.3 man pages.

From http://www.opengl.org, click Coding Resources -> OpenGL SDK. From here, select Documentation -> Reference Pages.

You always get OpenGL 2.1 ref pages now. Thanks to this post, I know the trick to "hack the URL", but it would be helpful (especially those not in-the-know) if there were an option for the newer versions.

Thanks.

Alfonse Reinheart
08-01-2010, 03:28 PM
Would appreciate it if the web site guys could update the site menu so you can get to the 4.1/3.3 man pages.

You can, but only from the main site menu. Under Documentation, you can see the three sets of documentation. For some reason, this doesn't extend to the forum Documentation menu.

Dark Photon
08-01-2010, 05:28 PM
Would appreciate it if the web site guys could update the site menu so you can get to the 4.1/3.3 man pages.

You can, but only from the main site menu. Under Documentation, you can see the three sets of documentation. For some reason, this doesn't extend to the forum Documentation menu.
Actually, neither was the case until just a few hours ago. Khronos_webmaster fixed the former, but yes I noticed the latter as well -- seems the Forums have their own menu that doesn't have the GL3/4 man page links.

kRogue
08-02-2010, 05:27 AM
I've been browsing the GL4 man pages, some appear to be missing, for example glUseShaderPrograms.


Maybe we should create a new thread "GL man page feedback"?

Khronos_webmaster
08-02-2010, 08:47 AM
The menus in the forums are now working as expected. Thanks for pointing that out also. For feedback on the spec, please follow the instructions on the homepage of each spec. We have either a feedback form, or preferably, bugzilla. Trying to track feedback in the forums is a bit difficult to do properly.

Many thanks for understanding.

Chris Lux
08-04-2010, 05:37 AM
You could check for the GL_ARB_debug_output extension. On a non-WGL_CONTEXT_DEBUG_BIT_ARB context this extension is/should be not supported.I am sorry, but i have to ask again: What about the headers?

-chris

Groovounet
08-04-2010, 07:20 AM
I agree Chris, working out the header ourselves is really not a great thing to do. :p

If it helps, my header:


// Declare OpenGL 4.1 enums
#define GL_VERTEX_SHADER_BIT 0x00000001
#define GL_FRAGMENT_SHADER_BIT 0x00000002
#define GL_GEOMETRY_SHADER_BIT 0x00000004
#define GL_TESS_CONTROL_SHADER_BIT 0x00000008
#define GL_TESS_EVALUATION_SHADER_BIT 0x00000010
#define GL_ALL_SHADER_BITS 0xFFFFFFFF
#define GL_PROGRAM_SEPARABLE 0x8258
#define GL_ACTIVE_PROGRAM 0x8259
#define GL_PROGRAM_PIPELINE_BINDING 0x825A

// Declare OpenGL 4.1 functions
typedef void (APIENTRYP PFNGLVERTEXATTRIBLPOINTERPROC) (GLuint index, GLint size, GLenum type, GLsizei stride, const GLvoid *pointer);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM1FPROC) (GLuint program, GLint location, GLfloat x);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM1FVPROC) (GLuint program, GLint location, GLsizei count, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM2FPROC) (GLuint program, GLint location, GLfloat x, GLfloat y);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM2FVPROC) (GLuint program, GLint location, GLsizei count, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM3FPROC) (GLuint program, GLint location, GLfloat x, GLfloat y, GLfloat z);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM3FVPROC) (GLuint program, GLint location, GLsizei count, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM4FPROC) (GLuint program, GLint location, GLfloat x, GLfloat y, GLfloat z, GLfloat w);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM4FVPROC) (GLuint program, GLint location, GLsizei count, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM1DPROC) (GLuint program, GLint location, GLdouble x);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM1DVPROC) (GLuint program, GLint location, GLsizei count, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM2DPROC) (GLuint program, GLint location, GLdouble x, GLdouble y);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM2DVPROC) (GLuint program, GLint location, GLsizei count, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM3DPROC) (GLuint program, GLint location, GLdouble x, GLdouble y, GLdouble z);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM3DVPROC) (GLuint program, GLint location, GLsizei count, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM4DPROC) (GLuint program, GLint location, GLdouble x, GLdouble y, GLdouble z, GLdouble w);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM4DVPROC) (GLuint program, GLint location, GLsizei count, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM1IPROC) (GLuint program, GLint location, GLint x);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM1IVPROC) (GLuint program, GLint location, GLsizei count, const GLint* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM2IPROC) (GLuint program, GLint location, GLint x, GLint y);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM2IVPROC) (GLuint program, GLint location, GLsizei count, const GLint* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM3IPROC) (GLuint program, GLint location, GLint x, GLint y, GLint z);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM3IVPROC) (GLuint program, GLint location, GLsizei count, const GLint* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM4IPROC) (GLuint program, GLint location, GLint x, GLint y, GLint z, GLint w);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM4IVPROC) (GLuint program, GLint location, GLsizei count, const GLint* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM1UIPROC) (GLuint program, GLint location, GLuint x);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM1UIVPROC) (GLuint program, GLint location, GLsizei count, const GLuint* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM2UIPROC) (GLuint program, GLint location, GLuint x, GLuint y);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM2UIVPROC) (GLuint program, GLint location, GLsizei count, const GLuint* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM3UIPROC) (GLuint program, GLint location, GLuint x, GLuint y, GLuint z);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM3UIVPROC) (GLuint program, GLint location, GLsizei count, const GLuint* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM4UIPROC) (GLuint program, GLint location, GLuint x, GLuint y, GLuint z, GLuint w);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORM4UIVPROC) (GLuint program, GLint location, GLsizei count, const GLuint* value);

typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX2FVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX2X3FVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX2X4FVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX3FVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX3X2FVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX3X4FVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX4FVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX4X2FVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX4X3FVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLfloat* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX2DVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX2X3DVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX2X4DVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX3DVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX3X2DVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX3X4DVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX4DVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX4X2DVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLdouble* value);
typedef void (GLAPIENTRY * PFNGLPROGRAMUNIFORMMATRIX4X3DVPROC) (GLuint program, GLint location, GLsizei count, GLboolean transpose, const GLdouble* value);

typedef void (GLAPIENTRY * PFNGLUSEPROGRAMSTAGESPROC) (GLuint pipeline, GLbitfield stages, GLuint program);
typedef void (GLAPIENTRY * PFNGLACTIVESHADERPROGRAM) (GLuint pipeline, GLuint program);
typedef GLuint (GLAPIENTRY * PFNGLCREATESHADERPROGRAMV) (GLenum type, GLsizei count, const GLchar **strings);
typedef void (GLAPIENTRY * PFNGLBINDPROGRAMPIPELINE) (GLuint pipeline);
typedef void (GLAPIENTRY * PFNGLDELETEPROGRAMPIPELINES) (GLsizei n, const GLuint *pipelines);
typedef void (GLAPIENTRY * PFNGLGENPROGRAMPIPELINES) (GLsizei n, GLuint *pipelines);
typedef GLboolean (GLAPIENTRY * PFNGLISPROGRAMPIPELINE) (GLuint pipeline);
typedef void (GLAPIENTRY * PFNGLPROGRAMPARAMETERI) (GLuint program, GLenum pname, GLint value);
typedef void (GLAPIENTRY * PFNGLGETPROGRAMPIPELINEIV) (GLuint pipeline, GLenum pname, GLint *params);
typedef void (GLAPIENTRY * PFNGLVALIDATEPROGRAMPIPELINE) (GLuint pipeline);
typedef void (GLAPIENTRY * PFNGLGETPROGRAMPIPELINEINFOLOG) (GLuint pipeline, GLsizei bufSize, GLsizei *length, GLchar *infoLog);

typedef void (GLAPIENTRY * PFNGLVIEWPORTARRAYV) (GLuint first, GLsizei count, const GLfloat * v);
typedef void (GLAPIENTRY * PFNGLVIEWPORTINDEXEDF) (GLuint index, GLfloat x, GLfloat y, GLfloat w, GLfloat h);
typedef void (GLAPIENTRY * PFNGLVIEWPORTINDEXEDFV) (GLuint index, const GLfloat * v);
typedef void (GLAPIENTRY * PFNGLSCISSORARRAYV) (GLuint first, GLsizei count, const GLint * v);
typedef void (GLAPIENTRY * PFNGLSCISSORINDEXED) (GLuint index, GLint left, GLint bottom, GLsizei width, GLsizei height);
typedef void (GLAPIENTRY * PFNGLSCISSORINDEXEDV) (GLuint index, const GLint * v);
typedef void (GLAPIENTRY * PFNGLDEPTHRANGEARRAYV) (GLuint first, GLsizei count, const GLclampd * v);
typedef void (GLAPIENTRY * PFNGLDEPTHRANGEINDEXED) (GLuint index, GLclampd n, GLclampd f);
typedef void (GLAPIENTRY * PFNGLGETFLOATI_V) (GLenum target, GLuint index, GLfloat *data);
typedef void (GLAPIENTRY * PFNGLGETDOUBLEI_V) (GLenum target, GLuint index, GLdouble *data);

PFNGLVERTEXATTRIBLPOINTERPROC glVertexAttribLPointer = 0;

PFNGLPROGRAMUNIFORM1FPROC glProgramUniform1f = 0;
PFNGLPROGRAMUNIFORM1FVPROC glProgramUniform1fv = 0;
PFNGLPROGRAMUNIFORM2FPROC glProgramUniform2f = 0;
PFNGLPROGRAMUNIFORM2FVPROC glProgramUniform2fv = 0;
PFNGLPROGRAMUNIFORM3FPROC glProgramUniform3f = 0;
PFNGLPROGRAMUNIFORM3FVPROC glProgramUniform3fv = 0;
PFNGLPROGRAMUNIFORM4FPROC glProgramUniform4f = 0;
PFNGLPROGRAMUNIFORM4FVPROC glProgramUniform4fv = 0;

PFNGLPROGRAMUNIFORM1DPROC glProgramUniform1d = 0;
PFNGLPROGRAMUNIFORM1DVPROC glProgramUniform1dv = 0;
PFNGLPROGRAMUNIFORM2DPROC glProgramUniform2d = 0;
PFNGLPROGRAMUNIFORM2DVPROC glProgramUniform2dv = 0;
PFNGLPROGRAMUNIFORM3DPROC glProgramUniform3d = 0;
PFNGLPROGRAMUNIFORM3DVPROC glProgramUniform3dv = 0;
PFNGLPROGRAMUNIFORM4DPROC glProgramUniform4d = 0;
PFNGLPROGRAMUNIFORM4DVPROC glProgramUniform4dv = 0;

PFNGLPROGRAMUNIFORM1IPROC glProgramUniform1i = 0;
PFNGLPROGRAMUNIFORM1IVPROC glProgramUniform1iv = 0;
PFNGLPROGRAMUNIFORM2IPROC glProgramUniform2i = 0;
PFNGLPROGRAMUNIFORM2IVPROC glProgramUniform2iv = 0;
PFNGLPROGRAMUNIFORM3IPROC glProgramUniform3i = 0;
PFNGLPROGRAMUNIFORM3IVPROC glProgramUniform3iv = 0;
PFNGLPROGRAMUNIFORM4IPROC glProgramUniform4i = 0;
PFNGLPROGRAMUNIFORM4IVPROC glProgramUniform4iv = 0;

PFNGLPROGRAMUNIFORM1UIPROC glProgramUniform1ui = 0;
PFNGLPROGRAMUNIFORM1UIVPROC glProgramUniform1uiv = 0;
PFNGLPROGRAMUNIFORM2UIPROC glProgramUniform2ui = 0;
PFNGLPROGRAMUNIFORM2UIVPROC glProgramUniform2uiv = 0;
PFNGLPROGRAMUNIFORM3UIPROC glProgramUniform3ui = 0;
PFNGLPROGRAMUNIFORM3UIVPROC glProgramUniform3uiv = 0;
PFNGLPROGRAMUNIFORM4UIPROC glProgramUniform4ui = 0;
PFNGLPROGRAMUNIFORM4UIVPROC glProgramUniform4uiv = 0;

PFNGLPROGRAMUNIFORMMATRIX2FVPROC glProgramUniformMatrix2fv = 0;
PFNGLPROGRAMUNIFORMMATRIX3FVPROC glProgramUniformMatrix3fv = 0;
PFNGLPROGRAMUNIFORMMATRIX4FVPROC glProgramUniformMatrix4fv = 0;
PFNGLPROGRAMUNIFORMMATRIX2X3FVPROC glProgramUniformMatrix2x3fv = 0;
PFNGLPROGRAMUNIFORMMATRIX2X4FVPROC glProgramUniformMatrix2x4fv = 0;
PFNGLPROGRAMUNIFORMMATRIX3X2FVPROC glProgramUniformMatrix3x2fv = 0;
PFNGLPROGRAMUNIFORMMATRIX3X4FVPROC glProgramUniformMatrix3x4fv = 0;
PFNGLPROGRAMUNIFORMMATRIX4X2FVPROC glProgramUniformMatrix4x2fv = 0;
PFNGLPROGRAMUNIFORMMATRIX4X3FVPROC glProgramUniformMatrix4x3fv = 0;

PFNGLPROGRAMUNIFORMMATRIX2DVPROC glProgramUniformMatrix2dv = 0;
PFNGLPROGRAMUNIFORMMATRIX3DVPROC glProgramUniformMatrix3dv = 0;
PFNGLPROGRAMUNIFORMMATRIX4DVPROC glProgramUniformMatrix4dv = 0;
PFNGLPROGRAMUNIFORMMATRIX2X3DVPROC glProgramUniformMatrix2x3dv = 0;
PFNGLPROGRAMUNIFORMMATRIX2X4DVPROC glProgramUniformMatrix2x4dv = 0;
PFNGLPROGRAMUNIFORMMATRIX3X2DVPROC glProgramUniformMatrix3x2dv = 0;
PFNGLPROGRAMUNIFORMMATRIX3X4DVPROC glProgramUniformMatrix3x4dv = 0;
PFNGLPROGRAMUNIFORMMATRIX4X2DVPROC glProgramUniformMatrix4x2dv = 0;
PFNGLPROGRAMUNIFORMMATRIX4X3DVPROC glProgramUniformMatrix4x3dv = 0;

PFNGLUSEPROGRAMSTAGESPROC glUseProgramStages = 0;
PFNGLACTIVESHADERPROGRAM glActiveShaderProgram = 0;
PFNGLCREATESHADERPROGRAMV glCreateShaderProgramv = 0;
PFNGLBINDPROGRAMPIPELINE glBindProgramPipeline = 0;
PFNGLDELETEPROGRAMPIPELINES glDeleteProgramPipelines = 0;
PFNGLGENPROGRAMPIPELINES glGenProgramPipelines = 0;
PFNGLISPROGRAMPIPELINE glIsProgramPipeline = 0;
PFNGLPROGRAMPARAMETERI glProgramParameteri = 0;
PFNGLGETPROGRAMPIPELINEIV glGetProgramPipelineiv = 0;
PFNGLVALIDATEPROGRAMPIPELINE glValidateProgramPipeline = 0;
PFNGLGETPROGRAMPIPELINEINFOLOG glGetProgramPipelineInfoLog = 0;

PFNGLVIEWPORTARRAYV glViewportArrayv = 0;
PFNGLVIEWPORTINDEXEDF glViewportIndexedf = 0;
PFNGLVIEWPORTINDEXEDFV glViewportIndexedfv = 0;
PFNGLSCISSORARRAYV glScissorArrayv = 0;
PFNGLSCISSORINDEXED glScissorIndexed = 0;
PFNGLSCISSORINDEXEDV glScissorIndexedv = 0;
PFNGLDEPTHRANGEARRAYV glDepthRangeArrayv = 0;
PFNGLDEPTHRANGEINDEXED glDepthRangeIndexed = 0;
PFNGLGETFLOATI_V glGetFloati_v = 0;
PFNGLGETDOUBLEI_V glGetDoublei_v = 0;

randall
08-04-2010, 11:59 AM
Pointer _definitions_ in a header file...?

ScottManDeath
08-04-2010, 03:02 PM
You could check for the GL_ARB_debug_output extension. On a non-WGL_CONTEXT_DEBUG_BIT_ARB context this extension is/should be not supported.I am sorry, but i have to ask again: What about the headers?

-chris

I updated glew from the svn, put the ARB_cl_event extension on the black list and then ran the build script which fetches the extension.txt files and builds everything. I had to massage glew.h for the debug output callback typedef, but that was trivial. I could provide the generated files, if required.

Chris Lux
08-05-2010, 12:55 AM
Thanks for the function pointer definitions.

I am not using GLEW or some other extension library anymore. I maintain a simple core-only lib for my projects, but parsing the spec files is still to much here ;).

Alfonse Reinheart
08-05-2010, 04:04 AM
I was updating my spec files for 4.1, and figuring out which extensions were core extensions and which weren't. Then, I ran into, well, this in the vertex_attrib_64bit spec:



void VertexArrayVertexAttribLOffsetEXT(uint vaobj, uint buffer,
uint index, int size,
enum type, sizei stride,
intptr offset);

(note: VertexArrayVertexAttribLOffsetEXT is provided only if
EXT_direct_state_access_memory is supported.)



What is EXT_direct_state_access_memory?

Groovounet
08-05-2010, 04:26 AM
I guess a subset of EXT_direct_state_access for buffer and texture DSA?

elFarto
08-05-2010, 02:05 PM
I was updating my spec files for 4.1, and figuring out which extensions were core extensions and which weren't. Then, I ran into, well, this in the vertex_attrib_64bit spec:



void VertexArrayVertexAttribLOffsetEXT(uint vaobj, uint buffer,
uint index, int size,
enum type, sizei stride,
intptr offset);

(note: VertexArrayVertexAttribLOffsetEXT is provided only if
EXT_direct_state_access_memory is supported.)

What is EXT_direct_state_access_memory?
What's even more interesting is the wording in the NV_vertex_attrib_integer_64bit extension:


void VertexAttribLFormatNV(uint index, int size, enum type, sizei stride);

(note: VertexAttribLFormatNV is provided only if
NV_vertex_buffer_unified_memory is supported.)
Which seems to imply that EXT_direct_state_access_memory is an analogue to NVIDIA's bindless extensions, although, I have to say there's something not quite right with that function if that is the case (why would you want a vaobj and buffer passed in?).

Regards
elFarto

Alfonse Reinheart
08-05-2010, 02:14 PM
Which seems to imply that EXT_direct_state_access_memory is an analogue to NVIDIA's bindless extensions.

I thought that at first too. But if that were true, VertexArrayVertexAttribLOffsetEXT is not the right definition for it. It takes both a buffer object (by name, not by 64-bit pointer) and an offset, which VertexAttribLFormatNV (and the other FormatNV calls) do not. Indeed, not taking these parameters is half the point of bindless. This function is not structured like bindless calls are; it's a pure analog to DSA's VertexArrayVertexAttribOffsetEXT.

Groovounet
08-06-2010, 02:00 AM
This function just look like the other DSA functions for VAOs.

Don't Disturb
08-16-2010, 02:57 AM
Just came back from holiday and found out about ARB_get_program_binary. After asking for it for a long time this has made my month. THANKYOU!!!!!!!!!!

tobindax
08-18-2010, 04:42 PM
The spec reads beautifully as an introductory text to the API for programming. However, it's pretty cryptic abruptly when it gets to 'projection'/transformation/viewports/"cameras". It could use an introductory paragraph or page about the way OpenGL sees things in that regard. I know it doesn't HAVE to, but it'd be nice.

Groovounet
08-19-2010, 02:21 AM
An OpenGL 4.1 review: http://www.g-truc.net/post-0320.html

Jacek Nowak
08-30-2010, 01:53 PM
I have used these new features such as separable shader objects, pipeline objects and direct state access for some time already and I have to say the API is sooo much cleaner now, also it's very easy to plug it into an OOP wrapper now. GJ everyone involved!

aqnuep
10-10-2010, 02:22 AM
I don't know whether anybody has already mentioned but we cannot talk about OpenGL 4.1 as a superset of DX11 until we get the following extensions in core:

GL_EXT_shader_image_load_store
GL_EXT_shader_atomic_counters

These are needed for example to implement DX11 linked list buffers.
They also come handy to create virtually any dynamic data structure on the GPU.

Btw, enabling RW textures also needs the spec to specify how depth testing is working as currently it is so that the GL officially puts the depth test after fragment shader but allows it to run before it (earlyZ).
This wasn't a problem previously as the only output of a shader was the fragment color and depth, but now as even a discarded fragment can write to buffers, there is need for a way to specify whether we would like to enable or disable earlyZ.

Groovounet
10-10-2010, 04:15 AM
For linked list it's GL_NV_shader_buffer_store ;)

t4ngu1
10-11-2010, 06:23 AM
GL_NV_shader_buffer_store is great, but it does not have all the functionalities of its DX11 equivalent.
In particular append/consume buffers. They can be emulated with atomics to a buffer in global memory but i am not sure how efficient that is compared to the DX11 implementation.

aqnuep
10-12-2010, 07:52 AM
For linked list it's GL_NV_shader_buffer_store ;)
Actually GL_EXT_shader_image_load_store is much more than GL_NV_shader_buffer_store + GL_NV_shader_buffer_load together.
It provides RW buffers, atomic counters and explicit early/late depth/stencil tests.

Off-topic, but besides these, what is also very interesting to me is GL_AMD_conservative_depth. It allows for the driver to sometimes perform early Z even in case the shader changes the Z value.

Groovounet
10-13-2010, 02:26 AM
It provides RW images but nothing about buffers.
Well, I guess the linked list could be implemented with image1d and actually I wonder about the difference between the too performance wise.

Also GL_AMD_conservative_depth early-z is actually part of GL_EXT_shader_image_load_store and take the form:
layout(early_fragment_tests) in;

Alfonse Reinheart
10-13-2010, 02:47 AM
Also GL_AMD_conservative_depth early-z is actually part of GL_EXT_shader_image_load_store and take the form:
layout(early_fragment_tests) in;

That's not the same thing. They solve two different problems.

The EXT_shader_image_load_store version commands the implementation to put the depth test before the fragment shader.

AMD_conservative_depth is all about retaining the behavior of early depth test transparently. With conservative depth, you're effectively making a contract: you're changing the depth, but you are doing so in such a way that some depth tests will always work.

With AMD_conservative_depth, you're making a contract with OpenGL, not telling OpenGL what to do. The spec specifically states that if you violate the contract, the results of rendering are undefined.

Which is better depends on how much control you want over these kinds of things vs. how much freedom the implementation should have to make your stuff faster. For example, if you force the implementation to do early-depth test, you can do some crazy things like writing depth values that would have failed the depth test had the test actually happened with those values. This is a full-fledged feature that you would use to create a special effect.

At the same time, forcing early-depth test does nothing for optimizing the case where you're biasing a fragment's depth smaller than the actual depth value. You have to do the depth test last; you can't force early-depth. However, if the hardware is capable of doing both early and late depth tests, then an implementation of AMD_conservative_depth would allow this with the "depth_less" version. The early depth test could cull some fragments that are obvious failures, while the late depth test could catch a few fragments here and there. Most of the fragments missed by the early test will actually be drawn, so little performance (outside of the double depth test) is lost.

This is purely an optimization; the meaning of the depth test is preserved in these cases.

aqnuep
10-13-2010, 03:34 AM
Agree with Alfonse Reinheart. GL_AMD_conservative_depth does not specify whether to use early or late depth test but rather it tells what can the GL assume about the depth modification done in the shader to provide optimum performance by using early depth test as often as possible.

Just think about the following. The GPUs usually use a hierarchical Z buffer to reject multiple fragments during depth test at once. This is usually set up to one direction, like the next mip in the hierarchy always contains the maximum of the corresponding depth values from the previous mip level (nowadays GPUs often use a two direction hierarchical Z buffer). In such a case if you specify "depth_greater" then you may get early Z even though you modify the depth value by increasing it in the fragment shader.

About GPU linked lists, it needs only a 2D RW image, a RW buffer and atomic counters (e.g. in case of order independent transparency). Actually there is no too much difference between images and buffers thus actually 1D image instead of a buffer will work as good and fast as a buffer on today's hardware. Think about, RW images are actually buffers, you don't have filtering and stuff like that, you can use only exact texel fetches like in case of buffer textures. So no real difference.

aqnuep
10-21-2010, 04:32 AM
I have another thing that I would like to be included in OpenGL 4.2, namely:

GL_ARB_draw_indirect2

Such an extension does not exist yet, however it would be good to have one that will include the followings:

1. First instance ID field. This is already mentioned in the GL_ARB_draw_indirect and it would define the first element ID to use from an instanced array.
2. MultiDrawArraysIndirect and MultiDrawElementsIndirect. The original extension says there would be little to no use of such a functionality. However, if hardware would be able to fetch the data transparently, this would allow for drawing loads of individual objects with a single draw call enabling full GPU based scene management. In order to properly introduce this, I would recommend also the introduction of indirect buffer objects as well as a VertexAttribPointer-like function to define the stride of the data in the indirect buffer.

What do you think about it?

Groovounet
10-21-2010, 06:39 AM
I think we will need updated hardware (OpenGL 5.0!) for such feature (2) but I follow it definitely.

To come back to the image1D != or == to buffer I would like to say that hardware doesn't necessary use the exact same wires (in the chip) to fetch images or buffers data... this is really implementation differences. An close example is uniform buffer vs texture buffer. Very close conceptually, could be identical in the use but there are performances.

aqnuep
10-22-2010, 01:59 AM
Uniform buffers are a bit different as they have such small size that they can fit in local memory (64KB).
RW buffers and RW textures are global memory objects thus they are very similar. I still stay at my statement as texture buffers are much like any other buffer object thus RW texture buffers and RW 2D textures are the way to go (I'm pretty sure that DX11 does this the same way even though the terminology is different).
The NVIDIA extension is also about global memory buffers.
I don't say that it wouldn't be nice to have a RW buffer type that allows local memory storage but (and I think it should work on current hardware, according to OpenCL spec). But anyway, that's a completely different issue.

kRogue
10-25-2010, 02:34 AM
Just an FYI: GL_NV_shader_buffer_store gives atomic read/write operations to data of a buffer object.

In my eyes GL_NV_shader_buffer_load/store give almost everything one could want in terms of accessing (read and write) of buffer objects (well almost everything atomic reads and writes are restricted to integer types).

But the bits about smaller, more local bits, I do not know of an extension that gives "arbitrary" read/write access as the NVIDIA extensions.

aqnuep
10-25-2010, 04:21 AM
Yes, I don't know such either. OpenGL never talks explicitly about shared local memory.

I think the only way to do such a thing is by using OpenCL and I hardly believe that OpenGL will include any soon explicit info and functionality related to shared local memory. It simply doesn't fit into the current design.

Foobarbazqux
10-26-2010, 02:45 PM
Yes, I don't know such either. OpenGL never talks explicitly about shared local memory.

In http://www.opengl.org/registry/specs/ARB/tessellation_shader.txt TESS_CONTROL shaders sort of have shared memory.

aqnuep
10-27-2010, 09:59 AM
In http://www.opengl.org/registry/specs/ARB/tessellation_shader.txt TESS_CONTROL shaders sort of have shared memory.

You are right, but this seems rather an exception than a rule. Anyway, I'm pretty sure soon there will be more and more talk about it.

Alfonse Reinheart
02-13-2011, 02:03 PM
There are a large (http://www.khronos.org/bugzilla/show_bug.cgi?id=433) number (http://www.khronos.org/bugzilla/show_bug.cgi?id=434) of (http://www.khronos.org/bugzilla/show_bug.cgi?id=435) issues (http://www.khronos.org/bugzilla/show_bug.cgi?id=436) with separate shader objects.

This is the "official" feedback thread, so I'm hoping that someone who's responsible for dealing with bugs will deal with these. Granted, there's likely going to be a new spec at GDC, if the previous pattern holds, so it's unlikely that these will be fixed by then. But

Also, it's clear that the ARB needs to slow down. They released a terrible spec in ARB_separate_shader_objects, one so bad that they didn't even get the state tables for it right. My guess is that SIGGRAPH was too soon after GDC. My suggestion is for the ARB to stop using these arbitrary deadlines and simply release versions when they're ready.

Don't forget that extensions exist for a reason. Functionality doesn't have to instantly jump from extension to core. It can live as an extension for a while, to make sure that it is specified well enough to make the jump to core. You know, work out the bugs in it before essentially fixing that functionality. If OpenGL is going to have backwards compatibility forever, then the ARB needs to be more selective about what it adds to the core.

malexander
02-21-2011, 08:04 AM
I agree with Alfonse on this one. I'd much prefer to see extensions released as EXT, trickling out as they are completed and then promoted to ARB with changes from developer feedback. Every once in a while, these ARB extensions could be wrapped into a new GL version as they reach critical mass. This would hopefully provide better specifications, and avoid the driver space-race that seems to happen every time a new GL version is released (resulting in drivers with new features that aren't useable for several versions).

I would much rather see stable, robust OpenGL drivers that perform well than new features every six months that take another six months to become usable. Constantly working around driver bugs/issues/peculiarities takes away from the otherwise relatively pleasant experience I have with GL.

mdriftmeyer
03-11-2011, 08:42 PM
I'd much rather see Nvidia, Intel and AMD expand their teams in OpenGL which affords them to maintain this release often approach but follow up every quarter with the secondary teams having squashed the bugs everyone is rightfully citing as show stoppers. No company moves in a quarterly manner so they have the window to release twice a year and update 4 times a years with refinements.

Then again, that would require investing in their companies and not sitting around trying to downsize and maximize their net profits in the short-term.

Gedolo
07-31-2011, 07:38 AM
Pasted text in wrong topic and forum.

aqnuep
07-31-2011, 08:13 AM
Now that OpenGL allows to store and load shader objects.

Do something about the big/little endian issue that can happen when transporting information from one to another machine.

You cannot transport the stored shader binaries from one computer to another, that's not what ARB_get_program_binary is for.
If you check the extension spec you can clearly see that it is primarily only for caching as there is no guarantee that the binary format will be the same across operating systems, hardware vendors or even driver versions.


On wikipedia there is an advantage to little endianness.
en.wikipedia.org/wiki/Endianness#Optimization (http://en.wikipedia.org/wiki/Endianness#Optimization)

Little endian seems to have a technical advantage here.
(Simpler circuit for doing the same.)

The best choice seems that every file would be best written in/with little endian.

(I find the bigger memory location is more significant byte very intuitive and logical.)

Why? What does "simper circuit" do with how you store a binary data on disk? Also the shader binary is just an array of bytes. Why endianness matter there?

Gedolo
07-31-2011, 08:29 AM
I have accidental pasted two unrelated pieces of text together that was supposed to be for other forums.