cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

cgrant78
Adept III

Possible driver bug with glCopyImageSubdata

Tested with Catalyst 13.12 on a HD 6850. When using glCopyImageSubdata with both the source and destination having a compressed internal format ( NOTE: The source and destination texture were different in my test case ), a GL error is generated. If the source and destination format is not uncompressed, then there is not GL error. I retested using the glCopyImageSubDataNV ( this is implemented by the AMD driver ) and there is not GL error. I'm assuming the behavior of the 2 functions should be similar with the exception that glCopyImageSubDataNV is more restrictive as noted on the extension description page.

0 Likes
4 Replies
cgrant78
Adept III

Just an update to what I've mentioned before. Even though glCopyImageSubDataNV doesn't generate a GL error, the behavior doesn't seem to be correct. The destination texture is showing corruption due to what looks like an incomplete copy operation verified via CodeXL. Tested the same 2 function on Nvidia HW and the results of the copy is correct. The dimension of the textures exhibiting the issue is 1028 x 1028

src_texture.pngdest_texture.png

0 Likes

Anyone?

0 Likes

Hi !

Would you please provide some sample code to me ?  I think it will be helpful for us to discuss your issue.

0 Likes

I will see if I can get a simple example that illustrate the issue. The texture streaming code is somewhat tightly coupled to a larger code base so the simple thing would be to try to write a simple example when I get the chance. I haven't tested this with any driver later than what was posted since I went ahead and did manual uploads via glCompressedTextureSubImage. I will get you a sample as soon as possible. Thanks for the response.

0 Likes