Im using the NPOT function of opengl 2.0, that is only call glteximage2d as normal but with non power of 2 values for width and height.
I get really strange bugs in the textures after loading several small images ( 120160px) and one bigger. Guess many different combinations might work the same here, but on my bigger images, 15361024, they doesnt appear.
The bug looks like this (bug)
and it seems to be some problem with overwrites in the memory (just load one texture works fine, but with more textures i get more of these problems )
instead of using just NPOT then i dont get the same artifacts… but if i make my window very small (60*8 pixels or so of clientarea) the drawn image becomes very disturbed again.
I got similar disrupted textures (mainly cube maps) on X300 (PCI-Express) and 9600 mobility (notebook) systems (at least for driver versions 5.1 to 5.5). Will try to create some snapshots on monday at work, since I have no small repro-case handy yet…
The disruption often happens after enlarging the viewport (e.g. during maximizing the window); you also can see that some of the VBO vertex arrays are lost at the same time…
The cubemaps are certainly not NPOTs , but the aerial images draped over the terrain are NPOTs (or to be more precise: GL_EXT_texture_rectangle textures).
I´m suffering from a similar problem. In my case I create a number of pbuffers (3 different contextes get shared among groups of them). The first time the pbuffers get created, everything is ok. Then I delete all of them and re-create the whole thing again. During this, no GL Errors or other wgl-related problems occur. Unfortunately, then I get problems looking like the ones depicted in this thread. No GL-errors occur, everything seems to work fine, except it looks horrible.
Might this bug be related to the npot bug? When is the fixed driver available?
It could be the related, but I wouldn’t be too sure. If you have a repro-case I’d like to look at it to see if it’s been fixed.
From fix to public release you can count on a few months.
@Humus: the error still exists in the Catalyst 5.10 driver. Can you check, if the fix should be contained in the 5.10 driver or do we have to wait for the 5.11? Any release date yet?