Latest OpenGL AMD/NV driver bugs (with repro code)

1. gl(Tex/Texture)Storage doesn’t work with any depth-format on AMD:

void Bug_AMD_TexStorage_Depth()
{
GLuint tex;
glGenTextures(1, &tex);
glTextureStorage2DEXT(tex, GL_TEXTURE_2D, 1, GL_DEPTH_COMPONENT24, 64, 64);

// BUG: err = GL_INVALID_OPERATION
GLenum err = glGetError();
}

2. gl(Tex/Texture)Storage doesn’t work with cubemaps on AMD:

void Bug_AMD_TexStorage_CubeMap()
{
GLuint tex;
glGenTextures(1, &tex);
glTextureStorage2DEXT(tex, GL_TEXTURE_CUBE_MAP, 1, GL_RGBA8, 64, 64);

// BUG: err = GL_INVALID_ENUM
GLenum err = glGetError();
}

3. gl(Tex/Texture)Storage will not work if PBO is active on AMD:

void Bug_AMD_TexStorage_PBO()
{
GLuint buffer;
glGenBuffers(1, &buffer);
glNamedBufferDataEXT(buffer, 1024, NULL, GL_STATIC_DRAW);

// NOTE: bug is here
// WORKAROUND: before TexStorage always do glBindBuffer(GL_PIXEL_UNPACK_BUFFER, 0)
glBindBuffer(GL_PIXEL_UNPACK_BUFFER, buffer);

GLuint tex;
glGenTextures(1, &tex);
glTextureStorage2DEXT(tex, GL_TEXTURE_2D, 1, GL_RGBA8, 64, 64);

// BUG: err = GL_INVALID_OPERATION
GLenum err = glGetError();
}

4. Calling glGenQueries between glBeginQuery/glEndQuery on AMD, leads to invalid operation:

void Bug_AMD_Query()
{
GLuint query1;
glGenQueries(1, &query1);

glBeginQuery(GL_SAMPLES_PASSED, query1);

GLuint query2;
glGenQueries(1, &query2);

// BUG: err = GL_INVALID_OPERATION
GLenum err = glGetError();

glEndQuery(GL_SAMPLES_PASSED);
}

5. textureGather<Offset>(samplerRECT…) is not work on NV:

any shader with this code will be compiled with this output:

target not supported by the TXG instruction
– internal assembly text –
// very long assemply here…

P.S. to be continued…

4. Calling glGenQueries between glBeginQuery/glEndQuery on AMD, leads to invalid operation:

I ran into this a while back, and it turns out this is the correct behaviour as stated by the extension (GL_ARB_occlusion_query, section 4.1.6A):

Calling either GenQueriesARB or DeleteQueriesARB while any query of any target is active causes an INVALID_OPERATION error to be generated.

However, this language isn’t in the OpenGL 3.3 specification, so it looks like it should be valid. It’s likely this feature was never updated to core in the AMD driver.

The official API reference for glGenQueries doesn’t reflect that as well.

[QUOTE=malexander;1240401]I ran into this a while back, and it turns out this is the correct behaviour as stated by the extension (GL_ARB_occlusion_query, section 4.1.6A).
However, this language isn’t in the OpenGL 3.3 specification, so it looks like it should be valid. It’s likely this feature was never updated to core in the AMD driver.[/QUOTE]
I would rather say it’s a specification bug. I don’t think it would be a good idea to allow GenQueries/DeleteQueries between BeginQuery/EndQuery, especially delete.

IMHO, I don’t think that glGenQueries inside a glBeginQuery/glEndQuery would be a problem because getting names for yet unused query and untyped query objects shouldn’t have any side-effects other than reducing the set of available IDs. What really looks like a bug though is that glDeleteQueries() also isn’t restricted from use while a query is active, at least according to the API reference. So you could simply try to delete an object which is currently active for a specific target.

Actually GL spec is pretty explicit that glDeleteQueries does work even if deleted query is active

If an active
query object is deleted its name immediately becomes unused, but the underlying
object is not deleted until it is no longer active

As there is nowhere any mention that glGenQuery is forbidden when there is an active query, the only possible outcome is that it has to work, ie ATI has a bug.

Ok, faulty API reference again. There’s no mention of this IMHO vital piece of information.

Damn, people are using these references for anything serious?
I lost track of number of errors/inconsistencies there - its good only as a quick reminder.

Well, yes. But even a quick reminder is supposed to be accurate. Alfonse maintains another version of the API reference in the wiki.

Which now has the correct info, BTW.

I just wish the links on this site would go to the Wiki version, since it’s much easier to fix bugs, rather than filing bug reports and waiting for someone on the ARB to get around to fixing them.

Actually, to be pendanic, probably the appropriate behavior should be the following: glGenQueriesARB and glDeleteQueriesARB should generate an error between glBeginQuery[ARB] and glEndQuery[ARB] (as those should respect the GL_ARB_occlusion_query spec, not the core spec). It doesn’t matter, however, whether you use the ARB or core version of begin and end query as the active state is aliased between the two.

The debate about glGenQueries and glDeleteQueries (the core functions) are more tricky as when these were originally introduced to the core spec they behaved like their ARB counterpart and only since version 3.0 they started to behave differently (at least according to the spec).

So the thing is, I still would say that this is a specification bug as it makes 3.0 non-backwards compatible with 2.1 (even though it should be as no features were actually removed there). However, if we really have to insist on it, then it means that from 3.0 glGenQueries and glDeleteQueries should behave differently than glGenQueriesARB and glDeleteQueriesARB.

This shouldn’t be a problem in general, but think of the following case:

  1. Somebody implements an application on a GPU supporting OpenGL 3.3 (compatibility profile).
  2. The application is meant to be backwards compatible as it doesn’t use any new features besides e.g. OpenGL 2.0.
  3. He/she puts a glGenQueries or glDeleteQueries call inside glBeginQuery and glEndQuery (this should work fine, according to the OpenGL 3.3 spec).
  4. Now somebody wants to execute the same application on a GPU supporting only OpenGL 2.1 (occlusion queries are in core there too so one might expect that it should work out-of-the-box, considering that compatibility profile should be fully backwards compatible).

So unintentionally, the developer made the application non-backwards compatible with OpenGL 2.1 despite he/she used compatibility profile and didn’t use any GL 3.x features.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.