cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

shalayka
Journeyman III

AMD 6310 GLSL/FBO copy causes corruption in the few lowest order bits (but only sometimes?!)

Hello,

I am using OpenGL 2.0 and an FBO to copy some data from an RGBA texture to an RGB texture, and I ran into an issue where sometimes it "corrupts" the first few lowest order bits of some (but not all) of the pixel components during the copy. I whittled down the real program that I was writing into a small test program (attached below).

The texture copy is broken up into several steps, and I'm resizing the FBO.

At first I thought perhaps it was a problem related to the way that I was resizing the FBO, or with the way the the texture is being sampled, but the problem doesn't always occur, and when it does, it never occurs for every pixel copied nor does it ever occur for all of the components of each problematic pixel. In other words, it seems nearly random, except that it is indeed deterministic insomuch that the same error(s) occur if the same input float values are used during each run of the program.

Also, the problem never, ever occurs if I always use an FBO size of 1x1 (which is kind of misleading to know, because it made me think that it was a sampling issue, but, again, that is probably not the case since not every component of every problematic pixel is "corrupted"). Unfortunately, using an FBO size of 1x1 is absolutely useless in the real world where I'm going to be copying a texture containing anything more than a few pixels.

The problem happens on Windows 7 and Ubuntu, and the problem happens when I use MSVC++ or g++'s std rand() or Mersenne Twister to generate the input texture values  (not that how I generate the values should matter, since copy operations are by definition independent of how the data to be copied was generated beforehand).

I wrote a test program (see code below) where nothing changes between runs of the program other than the input texture values.

Does anyone have an AMD 6310 (or any other kind of hardware, really) that they can run this test program on? You'll have to run it a few times, as sometimes it produces an error, and sometimes it does not. I'm just curious if it ever produces the error on your hardware. I just can't spot the pattern, and my naive thinking is that this should either work all of the time, or never -- not so sporadically.

I'm also totally wiling to accept that it might, in the end, have something to do with the way that I'm using OpenGL to do the copy. This would be relieving actually, since it would mean that there's an easy and reliable solution. I hope this is the case.

I probably have some extraneous calls to glTexParameteri in there somewhere, but I was trying the "better safe than sorry" method while working on this test program.

In any case, the problem results in some of the pixel components having error that's on the order of like ~1e-8. Yes, that's a very small error, but it's totally unacceptable for what I'm doing (in my real program it causes major problems with the next stages of the computation).

0 Likes
4 Replies
shalayka
Journeyman III

The problem does not occur on the Intel HD GPU in the HP Envy 23.

I am left wondering if my AMD 6310 is defective, or if this is a general 6310 hardware or driver problem.

0 Likes
sanpol
Adept I

Please, post the full solution for msvc (with libs, headers etc), if you want your sample to be tested. It is bothersome to figure out all headers and libs your cpp needs and putting it all together. My hardware is AMD 5145 Catalyst 13.1 Legacy driver, if you're interested.

Thank you for your interest, and I do understand that it's a bit annoying. The app requires the GLUT and GLEW libraries, both of which are pretty well-known. I no longer pass along files containing compiled executable code of any kind (.lib, .dll files), because virus scanners are not absolutely effective -- and so you must obtain those kinds of files yourself, directly from their authors. I've included the download URLs below, for Win32.

As well, solution/project files can also possibly contain malicious 'code' in the form of executed commands, and so I no longer provide those either. Visual C++ Express will warn you about this when you upgrade solutions/projects, and it will ask you to make sure that the solutions/projects come from a trusted source.

It's annoying, but it's better to be safe than sorry. If you do not wish to go through the hassle, I will understand.

Downloading GLEW:

Generally, the GLEW library can be obtained from the following website, or with your OS's package manager:

http://glew.sourceforge.net/

For Win32, a direct link to the GLEW .h, .lib and .dll files is:

https://sourceforge.net/projects/glew/files/glew/1.9.0/glew-1.9.0-win32.zip/download

Downloading GLUT:

Generally, the GLUT library can be obtained from your OS's package manager.

For Win32, a direct link to the GLUT .h, .lib and .dll files is:

http://user.xmission.com/~nate/glut/glut-3.7.6-bin.zip

Message was edited by: S Halayka

0 Likes

For what it's worth, I've since established that the low order bit corruption only occurs when the input and output texture formats are not identical (in terms of their number of channels).

For instance, the original test program copied the first three components of an RGBA texture to an RGB texture. If it's instead set up to copy an RGBA texture to an RGBA texture, then there is no low order bit corruption -- likewise for RGB to RGB and Alpha to Alpha.

So, I am now able to temporarily work around the problem in my real program, although the 'solution' is not optimal since it involves eating up some extra time and space because I must add in an extra pixel component that is never ever used.

0 Likes