I ve been sitting here for around 5 hours now trying to figure why my second-last mipmap level always shows incorrect information (as debugged using gdebugger).
The problem is very specific.

What i do is uploading my image data to all mipmap texture levels with the glTexImage2D command, for example like this:
glTexImage2D(textureTarget, level, GL_RED, newSize, newSize, 0, GL_RED, GL_UNSIGNED_BYTE, newMipMap);

It works fine for all texture levels from 1 to the last one, except for the SECOND LAST one, so the one that has 2x2 pixels dimension. This appears independently of the size of the original texture level, it is just always this specific texture level that has this problem.

What happens is that the data from newMipMap isn't taken, however it takes the values outside the array, like the next 2 values in memory (could be something random) So effectively that means that the lower 2 pixels are correct, the upper two are incorrect.

Again this only happens for the 2x2 mipmap, and i use power of two textures, the 1x1 mipmap is correct and all others are correct as well. I tried to initialize the texture with no data, then call the glTexSubImage2D command and got the same result.

I also updated my drivers to the latest nvidia beta drivers, assuming it is a driver bug, that also didnt help... I found no hints toward that anyone had this issue before me, so i am not sure about that at all.

Very interestingly, the data generated by glGenerateMipmaps() does NOT suffer this problem. so i doubt it is a problem related to gdebugger reading wrong values.

Also i tried to initialize my image data with a gradient from 1 corner to opposite corner, and also tried it with a fixed value. In both cases the mipmap level 2x2 suffers the issue again, while all other texture levels are correct.

I m pretty much done with my ideas here.

Ident

01-13-2012, 07:06 AM

Ok i also have another completly seperate mipmap generation technique in use for other textures (SRGB) and i just checked its results: the thing that happens here is that for the 2x2 mipmap level the lower line of pixels is wrong as debugged by gdebugger.

So the problem is flipped. I am getting more and more confused and angry. I am about to test this on another machine..

mbentrup

01-13-2012, 07:27 AM

GL_UNPACK_ALIGNMENT is 4 by default, so the start address of your second row is aligned to the next 4-byte address.

This doesn't matter for all the other mip levels as they are either 4-byte aligned already or they don't have a second row.

You can fix this by calling glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

Ident

01-13-2012, 09:11 AM

GL_UNPACK_ALIGNMENT is 4 by default, so the start address of your second row is aligned to the next 4-byte address.

This doesn't matter for all the other mip levels as they are either 4-byte aligned already or they don't have a second row.

You can fix this by calling glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

Thanks a lot for your quick response. This solved my problem.

Now I want my 6 hours of lifetime back.

It is unimaginable to my why this is set to 4 by default. As far as i understand it allows faster packing/unpacking of images when set to 4, however as it can lead to wrong results in cases like mine, i dont see why the default isn't set to 1.

mhagain

01-13-2012, 09:39 AM

It's one of those things where the value has to have some default, and for better or worse the default chosen is 4. That's enshrined in the spec and driver behaviour and can't be changed without incurring a risk of breaking existing programs.

Aside from which, I can guarantee you that for every 5 people who want a default of 1 you will find another 5 who want a default of 4.