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