Whoa, GL3 finally sees the light of the day. Whoa-whoa, the response to that was… well… “interesting”.
So just to recap, what I was expecting from GL3 (link, link, link):
Major cleanup of the runtime, resulting in simpler drivers, hence more stability and possibly even performance. Fail.
Make GLSL actually useable. Precompiled binary shaders, one offline compiler that does basic optimizations. Fail.
Without those two, OpenGL/GLSL is still quite unusable in the real world. Yeah, promoting some extensions to core is a nice gimmick (driver support is still an open question), thinking about “some quite possible deprecations that maybe perhaps someday we’ll most likely do” is sure nice, yeah. And spectacular handling of public relations of the whole thing.
“Keep up the good work”, what else can I say. Me back to fighting driver bugs.
Simon that strikes me as a way to mitigate the profusion of errors going forward.
The glStringi API and the new tokens for retrieving the major an minor version numbers together I think’ll make it harder to do the wrong thing and play into the deprecation hand quite nicely.
“Scattered writes” - OpenCL will be covering this I’m sure. Cross platform GPGPU is not a fully solved problem yet, even DX11 prototypes only are seeing a 2x performance improvement (out of say the 4x or 8x which is possible in theory) with this type of “compute shader” functionality (which is what scattered writes are for). So don’t expect this to be figured out yet, and thus isn’t core in GL or anywhere else.
“Geometry shader” - Is supported in extensions by Apple and NVidia. However wasn’t the fast path on the hardware (in fact very slow). Other methods, such as Hystopyramids, showed much faster performance for similar functionality. Also NVidia’s hardware only recently (200 series) made the updates to support better geometry shader performance. So really not as useful as you would think, and understandably out of core spec to make it easier for vendors to build GL3 drivers.
“Tesselator” - Lack of current cross platform hardware support, no reason to think about this now.
“Blend shader” - Lack of hardware support period. Not even in DX11 I believe.
“Seperate pre and post Z-discard shaders” - You can do this yourself with a branch in a shader. Or with stencil if you want a more hardware friendly path (due to 2x2 pixel quad packing into vectors for hardware).
“Post-rasterisation instancing (for multipass deferred shaders)” - What? I think you need to describe what you are looking for here, any why you cannot do this type of thing with current GL3 functionality.
“Updatable resolution LOD textures” - What do you mean here?
“ByteCode GLSL, Precompiled binary save/restore” - If you really get into the internals of both the order and (especially) newer hardware you will see that a common byte code for all vendors is a bad idea because hardware is way too different. All vendors would still have to re-compile and re-optimize into the native binary opcodes. So all you would be saving is parsing strings into tokens which really isn’t much of a savings. Due to all the different hardware, shaders in the form of pre-compiled binaries really only makes sense in the form of caching on a local machine after compile, and perhaps might be something to request as a new feature.
“Multi-threaded background buffer loading” - You can map as many buffers as you want and fill them from whatever threads you want, so this is currently easy to do.
“A way to query if wanted functionality is hardware supported or emulated in software” - The GL3 standard provides a listing of required functionality (especially in texture formats) to the route forward for knowing what is supported seems rather clear. Now it is onto the vendors to create correct drivers.
Also cubemap arrays (different post) are not hardware supported on (many of the) NVidia cards?, so I wouldn’t expect that to be core, but rather an extension if ATI sees that as worth while.
You’re forgetting the #1 advantage of the token approach: Updated drivers will not break your shader compiles. Currently, nVidia can fix a bug in its parsing that renders a previously parsable program illegal, or a program can be illegal on ATI but legal on nVidia, while using just basic features but slightly out of spec syntax. This problem, which is a major one, DOES SIMPLY NOT EXIST on D3D and is the major reason why D3D has you compile the shaders into tokens first.
perhaps might be something to request as a new feature
Request as a new feature?
We have been requesting this for years!!!
The GL3 standard provides a listing of required functionality (especially in texture formats) to the route forward for knowing what is supported seems rather clear. Now it is onto the vendors to create correct drivers.
Longs Peak was going to give us real (implicit) checks. If you created a vertex array object with a certain format, you were assured that it would work in hardware. If the VAO failed to create, it wouldn’t work in hardware.
Trying to find something good about all of this, at least I have no more reasons <i>not</i> to buy that 4870x2 now…
I haven’t had time to read it all yet, but it seems that what was delivered as OpenGL 3.0 now, would have been nice had it been released as OpenGL 2.0.
How do I get into this driver mode? Do you need to call a new version of wglCreateContext()? And for me I use SDL so I am going to assume that SDL will need to be updated to allow this?
3/ A 3.0_Forward_Compatible Context which is the “Real” version 3.0 with the legacy stuff removed.
What are you all talking about when glMatrixMode() and what about using glTranslatef() glRotatef() ect… do we need to keep track of matrices ourselves now? Like DX?
Looks like most (if not all) fixed function vertex stuff is going away in the future including glMatrixMode(), etc. Best to read the spec, on page 404 (section E.1. PROFILES AND DEPRECIATED FEATURES OF OPENGL 3.0). So if you want to do matrix math you do it application side outside GL. Then either pass the matrix in as a uniform, fetch it via vertex texture fetch, or have it sent to you via vertex buffer (ie if you had one matrix per vertex).
HGLRC wglCreateContextAttribsARB(HDC hDC, HGLRC hshareContext, const int *attribList);
“If the WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB is set in WGL_CONTEXT_FLAGS_ARB, then a <forward-compatible> context will be created. Forward-compatible contexts are defined only for OpenGL versions 3.0 and later.”
I would like to preface this post with “I know nothing.”
It seems like the ARB is not doing a good job. How difficult would it be to fork like the xorg folks did when the oversight organization lost it’s mind?
How difficult would it be to fork like the xorg folks did when the oversight organization lost it’s mind?
Um, very?
ATi, nVidia, and Intel are holding all the cards here. You can’t just end-run around them like with Cairo.
They’re the ones with the in-depth knowledge of how to write graphics drivers. They’re the ones with the ability to provide certified drivers, which are the only kinds of drivers that Vista64 will accept (for good reason, mind you). Likely, Windows7 will not accept uncertified drivers of any kind, again for good reason.
We’re beholden to these three companies for their interface to their hardware. Yes, even for Larrabee; I doubt a few hobbyists are going to come close to Intel’s drivers in performance.
OpenGL 2.2?
You mean 1.8. We’ve been through “major version” once allready.
[/QUOTE]
Well, GL 2.0 delivered some major improvements, most important shaders. IMO using the number 2.0 was okay. However 3.0 isn’t. It doesn’t even give geometry shaders. 2.2 would have been the right number for this. A long time ago would have been the right release date.
I wonder why everyone is so obsessed with geometry shaders, if it was stated multiple times that the hardware just isn’t good enough yet, also think of the game consoles being fixed at pseudo sm3 level for a few years to come, and that will be the main relevance for games.
I’d rather see gl3.0 possible on sm3 hardware for that reason, than cutting to the smaller market of sm4+ only. However I have no idea whether texturearrays and all that would be possible on sm3.
I wonder why everyone is so obsessed with geometry shaders, if it was stated multiple times that the hardware just isn’t good enough yet
Personally, I don’t care. Transform feedback was the part of geometry shaders that I ever cared about. It’s the lack of uniform buffers (which is something that implementations could lie about and “implement” in non-conformant hardware) that honks me off.
However I have no idea whether texturearrays and all that would be possible on sm3.
They aren’t. The ARB picked the most meaningless D3D 10 features (seriously, I have no idea why anyone cares about integer textures) to give to GL “3.0”, while missing the most important (uniform buffers).