glGetProgramiv parameter <pname> has an invalid enum '0x8917' (GL_INVALID_ENUM);
glGetProgramiv parameter <pname> has an invalid enum '0x8918' (GL_INVALID_ENUM)
glGetProgramiv parameter <pname> has an invalid enum '0x8916' (GL_INVALID_ENUM)
It doesn’t matter if program in fact containsgeometry shader or not.
Also, it’s a bit shame that your (?) extension GL_ARB_sampler_object is still completely unusable. The sampler parameters are still read always from texture unit 0. You also need to specify filtering methods for images created with glTexImage* as opposed to glCompressedTexImage*. Otherwise all you got is incomplete texture object.
Last but not the least, As long as you call glGetProgramiv(name, GL_PROGRAM_BINARY_LENGTH, &length); only once it’s ok. But every next, consecutive call will get you 2x bigger value than previous one.
We are sorry that the GL_ARB_sample_object is still under investigation.
What exactly does it mean to be “under investigation?” Does it mean that you’re not sure the bug exists? Does it mean that you know it exists but don’t know how to fix it? Does it mean that a fix is currently being developed?
You’re willing to say that the geometry shader thing “will be fixed soon.” But sampler objects, a core feature that is broken to the point of uselessness, remains “under investigation.”
When the ARB ships their 3.3 conformance test at SIGGRAPH (the current plan), can we expect the investigation to finally be over and an actual fix implemented?
You make it sound like a “hen and egg” problem but it’s not. Production software will not used feature until they become “production ready”. So far AMD drivers are almost OpenGL 3.2 production ready which is not too bad compared anymore else expect nVidia which is almost OpenGL 4.1 ready.
Hopefully, that will change when Khronos eventually ships an OpenGL 3+ conformance test suite. The various ACID tests did wonders for browser implementers. Hopefully the same benefit will come from an OpenGL conformance test suite.
Harsh but fair; if a driver claims support for feature X, the least a developer can expect is that feature X will be (at least reasonably) supported. Otherwise how can you trust the driver with anything?
In OpenGL? You cant, seriously.
And im not saying just ATI. Cutting edge features were always lacking at release time from my experience (and probably always will, until mythical conformance tests happen:)
I wouldn’t call them mythical, but the conformance test should give driver developers visual feedback, rather than relying on their own interpretation of text documents. I’m guessing that’s the reason D3D drivers are better, as driver developers can always compare their result to the reference rasterizer to determine if they are implementing a feature correctly.
Look at the HTML4+CSS standards, which have been around for over a decade. Regardless of the implementation bugs, the ACID tests were seen as a goal for browser developers to pass. Even WebGL has conformance tests, and current implementations are deemed experimental until they pass all tests. Given that WebGL is a subset of OpenGL, and its conformance tests consists of over 5000 tests, I shudder to think of the number of tests that will be in an OpenGL 3+ conformance test suite.
Thanks, works like a charm, even throws errors when doing it for shader objects without GS (contrary to NV implementation).
I also played around with program_binary extension and came across an odd behavior. When you try to get the binary (or just a length) of shader object with glTransformFeedbackVaryings() call before it goes to infinie loop - debugger waits forever after call glGetProgramiv with GL_PROGRAM_BINARY_LENGTH as pname.
I’m guessing that’s the reason D3D drivers are better, as driver developers can always compare their result to the reference rasterizer to determine if they are implementing a feature correctly.
It’s more that the IHVs don’t have to do as much work. Microsoft implements much of the grunt-work, leaving the IHVs to spend their time with things that need the actual hardware know-how to optimize.
Regardless of the implementation bugs, the ACID tests were seen as a goal for browser developers to pass.
Except that they were terrible conformance tests. Indeed, Microsoft was specifically asked not to fully pass ACID3 with IE9 because the spec that some of those tests are based on is still in flux. And the last thing that W3C (and everyone else) wants is for the next IE to create another de-facto standard.
The ACID tests are very different from a legitimate conformance test. ACID2 only tested CSS2 functionality that was deemed “important” by some metric. And ACID3, as previously illustrated, is in part testing specifications that don’t actually exist yet.
The biggest issue with OpenGL is that it is rarely used. When it is used, more often than not, it is GL 2.1 or below. Name a major program, game or otherwise, that shipped with OpenGL 3.x or above support. 3.x has been around for several years now; you would expect something to offer support. But it doesn’t.
The reason AMD can get away with pretending to support 3.3 is because nobody uses it. So nobody’s applications break when, for example, sampler_objects is unusable.
Even WebGL has conformance tests, and current implementations are deemed experimental until they pass all tests.
Well, someone has to do the grunt work, and we’ve seen over the past decade that the majority of IHVs (Intel+AMD) prefer not to. So in effect, Microsoft’s hard work has paid off, with 99.9% of 3D applications on Windows using D3D. Thus …
When I said similar, the response has been:
Id Software had the clout to make IHVs fix bugs in their OpenGL implementations. Given that their games had millions of users (as opposed to hundreds for a tech demo), they got a rapid response from IHVs. However, now that their next engine will use D3D9 on Windows, they have made things much easier for IHV driver writers. Even WebGL is implemented with D3D on Windows (Google’s ANGLE project). OpenGL ES 2.0 (WebGL or otherwise) has more interest/support than desktop OpenGL 3.X.
Carmack said so 3 years ago. I seriously doubt that he changed his mind in the past 2 years, given that he has said that he loved developing on Xbox 360, and the article you mentioned stated that it would be rather simple for him to develop a DirectX executable.