The slides from the GDC session OpenGL 4.0 are now available on the Khronos site.
Be optimistic, sampler object is the first DSA API!
That's a good sign for OpenGL 4.1
I had to design a renderer for a 10 years old software full of glBegin(*); glPushAttrib(ALL); reset(everything); selector; OpenGL context switchs when lost; etc...
Most of this was the result of programmers working with OpenGL without much of an understanding of it as OpenGL was not critical or a limitation until then. I'm not saying they were bad programmers, the WORSE OpenGL code I saw, has been written by the BEST programmer I worked with: A serious C++ god. The code was an absolute piece of art as a C++ code but an absolute piece of trash as an OpenGL code. He used OpenGL not as a main tool and didn't thought it could be much of a cost:"After all OpenGL is a standard, it should be good if people agreed?".
That's why I disagree with nVidia that's state that the deprecation mechanisium is useless. I'm not saying I don't want to see the deprecated functions anymore, I'm saying that I feel more confident to go the see developers and say: "Here is OpenGL core, basically, you can rely on that to be efficient. On other hand, there are more features with OpenGL compatibility but...". A simple guideline than anymore can understand.
With DSA, it's the same level of idea. DSA is a concept that any good programmer will understand and be able to work on a "good" software design.
Also, I think that the spec major version by hardware level allow to simplify a lot the support of a large amount of platforms. It's quite easy to understand to anyone not just heavy OpenGL fan seeking for extensions all the time.
"A great solution is a simple solution. DSA for OpenGL 4.1." (My campaign slogan for DSA! )
Ah...MT driver + library that must reset state = terrible performance, I can see that.
For item (b), background loaders, is this a problem if the background loader is on a shared context on its own thread? I would [hope] that the background loader isn't inducing a reconfiguration of the pipeline within the rendering context.
Of course, I am assuming that my limited set of GL calls to do background loading isn't using the GPU at all, otherwise there is a hidden cost to async loading. That is, I am assuming that a glTexImage2D in a "loader context" without a real drawing of triangles won't cause the driver to go through and actually update the pipeline configuration. This is a completely unvalidated assumption. :-)
OpenGL calls are collectionned in a command lists and can theorically stack up to 1 frame latency. That's a usual strategy used for conditional rendering with occlusion query so that the CPU never stall waiting for the GPU to process something.
Queries and glGet are likely to imply a stall, not glTexImage2D.
That's an other why DSA saves us! We don't have to use the save (which imply a glGet) / restore paradigm anymore.
There are several discussion over this forum about why we love DSA, I'd like to hear why some people don't?
A code sample that shows the problem:
Code :GLuint Texture = 0; // Some code glBindTexture(GL_TEXTURE_2D, Texture); // Some code GLint ActiveTexture = 0; glGetIntegerv(GL_TEXTURE_BINDING_2D, &ActiveTexture);
The full command list need to be processed to be sure that Texture == ActiveTexture. Maybe in "some code" another texture as been binding.
If DSA is all about capturing/restoring state, why not providing "state block objects"?
Code :GLint stateblock=0; glGenStateBlocks(1, &stateblock); ... ... glCaptureState(GL_COLOR_BUFFER_BIT|GL_FRAMEBUFFER_BIT, stateblock); ... glBindFramebuffer(GL_FRAMEBUFFER, myFBO); glColorMask(1,1,1,1); glClearColor(0,0,0,0); glClear(); ... glRestoreState(stateblock);
This lets you interact nicely with "external" code without ever needing to call glGetXXX(). Additionally, stateblocks may be a very quick way to set complex state really fast, just like Display Lists once did:
Code :GLint savestate=0, mystate=0; glGenStateBlocks(1, &savestate); glGenStateBlocks(1, &mystate); glBindFramebuffer(GL_FRAMEBUFFER, myFBO); glColorMask(1,1,1,1); glClearColor(0,0,0,0); glCaptureState(GL_COLOR_BUFFER_BIT|GL_FRAMEBUFFER_BIT, mystate); ... //then the actual execution might look this way glCaptureState(savestate); glRestoreState(mystate) glClear(); glRestoreState(savestate);
@Shynet: It looks like glPushAttrib ... I'm not sure.
I submit few times a state object but more like to replace display lists. I sometime use display list as state object wish is more efficient than not using them. For that I design some "macro objects". When I "bind" those, I call the list.
It's possible that my design is efficient only because I work at macro object level which probably imply more calls that I could do be still: Nice and handy!
The thing is just that display list are deprecated and it would be nice to replace them!
Actually sampler object are king a step forward on that way.
(Like VAO? ouchhh)
Something is bothering me: GL_ARB_gpu_shader_fp64 is part of OpenGL 4.0 specification... That's mean that my Radeon 5770 is not an OpenGL 4.0 card...
I went through the spec to check if there is a rule to relax double support... but it doesn't seams to be the case.
Considering that double are not that useful yet, I'm quite sceptical about this choice. It might slow down OpenGL 4.0 adoption and make quite some developers using OpenGL 3.x + a large bunch of extensions.
The good thing with OpenGL major version per hardware generation is:
- 1 code path for OpenGL 2.1 for GeForce 6 >, Radeon X >
- 1 code path for OpenGL 3.x for GeForce 8 >, Radeon HD >
- 1 code path for OpenGL 4.x for GeForce GT* 4** >, Radeon 58** >
Because of this we end up with an extra code path. OpenGL 4.WEAK which will be OpenGL 3.x + load of extensions for GeForce GT* 470 < and Radeon 57** <=.
If the idea was to make OpenGL 4.0 for high-end graphics only, maybe a high-end profile for Quattro and FireGL and high-end GeForce and Radeon would have been great. OpenCL have such option in the spec that I quite like.
Maybe the RHD57xx do support doubles, but in DX's nature it's not a mentionable/marketable feature?
(disclaimer: I haven't checked any in-depth docs on 57xx)
Maybe there's a glGetIntegerv() call to check precision, just like gl_texture_multisample num-depth-samples in GL3.2 ?