AMD: Error in atioglxx on a call to glGetTexImage

I’m experiencing a difficult problem on certain ATI cards (Radeon X1650, X1550 + and others).

The message is: “Access violation at address 6959DD46 in module ‘atioglxx.dll’. Read of address 00000000”

In this case it was tested on Radeon X1650 Series (driver 8.593.100.0).

It happens on this line:



[ul][li]Latest graphics drivers are installed.[*]It works perfect on other cards. [/ul][/li]Here is what I’ve tried so far (with assertions in the code):

  • [li]That the pointer P is valid and allocated enough memory to hold the image[]Texturing is enabled: glIsEnabled(GL_TEXTURE_2D)[]Test that the currently binded texture is the one I expect: glGetIntegerv(GL_TEXTURE_2D_BINDING)[]Test that the currently binded texture has the dimensions I expect: glGetTexLevelParameteriv( GL_TEXTURE_WIDTH / HEIGHT )[]Test that no errors have been reported: glGetError

I feel I’ve tried everything and have no more ideas.

Is this a driver bug? I can provide a link to an exe-file that produces the error if anyone wants to test.

It works perfect on other cards.

Yes, that often hints a driver bug, especially since 8.59 is a very old driver.

That the pointer P is valid and allocated enough memory to hold the image

Do you also respect GL_PACK_ALIGNMENT, so the written data never exceeds the end of your buffer? Also make sure, all other GL_PACK_XXX state (glPixelStorei) is matching your intended read back.

Texturing is enabled: glIsEnabled(GL_TEXTURE_2D)

That is not of importance for reading the data back.

But, is glActiveTexture actually pointing to the texture unit the texture is bound to?

Thanks for your reply.

I’m told this is the latest driver for that particular card. This would be much easier to debug if it was occurring my development computer but as it is now I’m sending debug exes to users with experience the error.

I’ll add checks for that but they should have the default setting because I don’t change that anywhere in my application. And since I request float rgba the data is 16-byte aligned already and P is also aligned because the memory allocator guarantees this.

Good point, I’ll add a check for that but if that is the problem it should cause problems on other cards as well?

Test for glActiveTexture and GL_PACK_ALIGNMENT also passes and the error keeps appearing.

I have found now that it is related to the use of glCopyTexSubImage2D. If I update a texture with pixels from the framebuffer using glCopyTexSubImage2D and then later try to read the pixels back with glGetTexImage it will crash.

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