PDA

View Full Version : Few driver bugs from AMD



kozmo
03-16-2011, 01:54 PM
So I've come across few bugs (Catalyst 11.2) that aren't present on NVIDIA gfx cards.
1) The code below


GLint params[16];
glGetProgramiv(name, GL_GEOMETRY_INPUT_TYPE, params);
glGetProgramiv(name, GL_GEOMETRY_OUTPUT_TYPE, params);
glGetProgramiv(name, GL_GEOMETRY_VERTICES_OUT, params);


gives:

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, &amp;length); only once it's ok. But every next, consecutive call will get you 2x bigger value than previous one.

frank li
03-16-2011, 06:45 PM
These geometry enums are not promoted from ext to arb. You could use GL_GEOMETRY_XXX_XXX_EXT instead for the workaround. It will be fixed soon.

We are sorry that the GL_ARB_sample_object is still under investigation.

The bug for arb_get_program_binary is a known issue and is fixed. But the fix does not get into the latest public release.

Alfonse Reinheart
03-16-2011, 07:31 PM
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?

Groovounet
03-17-2011, 03:55 AM
And OpenGL 3.3 (with sampler object) has been release a year ago!

DarkGKnight
03-17-2011, 06:35 AM
Given that so few apps use it (except maybe tech demos), I'm guessing it never became a priority for AMD. Even the CAD discussions I see in here seem to focus on OpenGL 2.X techniques.


And OpenGL 3.3 (with sampler object) has been release a year ago!

Groovounet
03-17-2011, 08:33 AM
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.

Alfonse Reinheart
03-17-2011, 01:44 PM
Given that so few apps use it (except maybe tech demos), I'm guessing it never became a priority for AMD.

It was enough of a priority for them to claim to ship OpenGL 3.3 drivers. It was enough of a priority for them to "implement" it in the first place.

But it wasn't enough of a priority to actually do it correctly?

DarkGKnight
03-17-2011, 03:35 PM
But it wasn't enough of a priority to actually do it correctly?
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.

Groovounet
03-17-2011, 06:02 PM
Given that so few apps use it (except maybe tech demos), I'm guessing it never became a priority for AMD.

It was enough of a priority for them to claim to ship OpenGL 3.3 drivers. It was enough of a priority for them to "implement" it in the first place.

But it wasn't enough of a priority to actually do it correctly?

I must say your are such a harsh person Alfonse that it becomes a proper art! But it's true.

Also the all claiming thing is a shame shared by every vendor, Intel being probably the worse. Conformance tests is the only answer!

frank li
03-17-2011, 07:52 PM
I asked the status of GL_ARB_sample_object. There is a good solution for it right now and it's being developed. We are very sorry for the inconvenience.

DarkGKnight
03-18-2011, 06:27 AM
There is a good solution for it right now and it's being developed. We are very sorry for the inconvenience.
Given that Direct3D uses the same model for samplers, I'm surprised that implementing it on OpenGL is taking so long. Anyways, we hope to see it in Catalyst 11.5 :D.

mhagain
03-18-2011, 06:52 AM
I must say your are such a harsh person Alfonse that it becomes a proper art! But it's true.
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?

Groovounet
03-18-2011, 07:57 AM
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?

We can't and we should not! That's why we need conformance tests.

kyle_
03-18-2011, 12:39 PM
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:)

DarkGKnight
03-18-2011, 03:14 PM
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.

kozmo
03-18-2011, 03:42 PM
These geometry enums are not promoted from ext to arb. You could use GL_GEOMETRY_XXX_XXX_EXT instead for the workaround. It will be fixed soon.
Thanks, works like a charm, even throws errors when doing it for shader objects without GS (contrary to NV implementation).


I asked the status of GL_ARB_sample_object. There is a good solution for it right now and it's being developed. We are very sorry for the inconvenience.
Looking forward.

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.

Alfonse Reinheart
03-18-2011, 03:47 PM
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.

They just used the OpenGL ES tests, recoded in JavaScript.

DarkGKnight
03-18-2011, 05:48 PM
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. ...

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 ...


The reason AMD can get away with pretending to support 3.3 is because nobody uses it.
When I said similar, the response has been:


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".


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.

ZbuffeR
03-18-2011, 06:12 PM
now that their next engine will use D3D9 on Windows
Really ? What is your source ?
Because the latest I read on the subject, it was still OpenGL, and no push to switch to D3D :
http://www.bit-tech.net/news/gaming/2011/03/11/carmack-directx-better-opengl/1

DarkGKnight
03-18-2011, 06:43 PM
Really ? What is your source ?

Carmack said so 3 years ago (http://www.beyond3d.com/content/news/462). 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.

ZbuffeR
03-18-2011, 06:59 PM
1) your article is older
2) when your article said "Rage will be a DX9 game" it really meant "Rage will be a DX9-level game", ie. working on older cards.
3) in 2011 "OpenGL still works fine,' said Carmack, 'and we wouldn’t get any huge benefits by making the switch"

DarkGKnight
03-19-2011, 02:08 AM
Isn't it possible that he uses the same OGL tools when developing his code for the Xbox 360, given that OGL has many extensions to mimic D3D behaviour? Also, he could have stated that Rage will use OGL on Windows. Anyways, let's not argue about unreleased products. In September, we will know if Rage uses D3D on Windows or not.

EDIT: Btw, if Id Tech 5 does not include an OpenGL 3 renderer (much like some D3D games that include both D3D9 and D3D11 render paths), then it follows the theme of this thread: no one uses OpenGL 3.