I am currently developing an application that relies on the use of NPOT 3D textures. Recently I have observed that whenever my 3D texture becomes bigger (RGBA8, 1-16 MB), OTHER data randomly becomes corrupted. Usually it is the highest mipmap level of some texture. Once it was some VBO content.
As you can see there is a “line-pattern” on the highest mipmap-level. Also the corrupted data is not entirely “static”. If a texture is corrupted, the corrupted part is sometimes flickering, though maybe that’s just the shader-math producing weird outputs with strange input data.
Interestingly enough the 3D texture itself is always absolutely correct. On nVidia I have not yet observed any similar behavior, though I will test it again soon.
Hardware: ATI Mobility Radeon HD 5600/5700 series, 1GB.
Tested Drivers: Catalyst 10.8 and 10.12
I can run my engine in D3D 11 and there it doesn’t happen, all data is correct.
Does anyone made have similar observations? Does anyone use NPOT 3D textures ?
Hi,
Yeah I have used NPOT 3D textures. From my experience with ATI hardware, it tends to favour POT textures more. I got sluggish performance for NPOT textures. So my solution was to zero pad the 3D texture data to the nearest POT.
Now for the line pattern, I suspect that the data is not properly copied to your texture. This may be due to wrong format and/or the pixel data being not completely written to the texture. The flickering that you see is due to the garbage in the memory. One more thing, are you putting data manually or loading data from an external file. If you are putting data manually then I can suggest u create a simple texture and just
memcpy(pData,0,data_size);
This should not give u the flickering that u are observing.
the reference in that book mentions a non-AMD product, and it is about data upload speed, not rendering speed.
there can be difference in upload speed based on sizes/alignment and format conversion; if you can give data about such a significant drop on specific test for AMD, we would be glad to investigate or give feedback about better workarounds.
I haven’t done any performance tests, because that’s not my concern right now, though I didn’t “feel” any difference with POT or NPOT textures.
Due to the size of the 3D textures, padding to POT sizes is out of the question, though.
From my observations the corruptions seem to happen less, the more axis’es (???) of the 3D texture are power-of-two. So for example a 3278 texture is less likely to cause (visible) corruptions than one with all three values being NPOT. Maybe the driver just copies the data in power-of-two batches and thus sometimes overwrites too much memory? Since it is always just ONE texture that becomes corrupted (I load ONE 3D texture), it appears to be a very localized issue.
Hi Pierre Boudier,
Thanks for the info. We have used datasets (acquired from laser scanning confocal endomicroscope) having resolution 1024x1024x13 (very low z resolution) and the dataset is streamed from the scanning device to the rendering station. We used PBO for data transfer to GPU and we noticed the performance lag as u mentioned pertaining to the format conversion and alignment as u mentioned. IN addition when GPU volume rendering (raycasting /texture slicing) such volumes the performance is generally low as compare to the POT volumes. I cannot share the dataset since its strictly confidential. I think my reply is straying this thread away from its topic. If u need to talk more on this u may PM me.
Thanks
The only time I’ve experienced something a bit like this (weird lines appearing in larger textures - though not 3d ones), I solved it by setting the pixel store alignments to 1.
Yes, I know that problem, and I have set the pack/unpack alignment to 1 (just checked it to be sure). Though since it is an RGBA texture, it should be aligned to 4 byte anyway.
Btw, I forgot to mention, that this is also an Win 7 64 Bit.