[Performance] Texture arrays with 1 slice vs 1 single texture2d
Author
I am thinking about modifying my texture manager so that every texture is actually loaded as a texture array, be it one single 2d texture or multiple slices (ie: textures grouped by usage, gui elements, animated texture frames etc.) - for a matter of generalization.
What I wonder is: is sampling a texture array slice considerably slower than sampling a single normal texture?
Author
I am bringing this question back after having performed some tests with weird results.
The setup: Windows 7 beta, Nvidia geforce 285gtx (driver 181.22), Cpu Q9700
Summarizing the data I've collected, accessing the 1st slice of a texture array with just 1 slice is 6 to 8 times slower than accessing a normal 2d texture, depending on the texture's size.
Doesn't this sound wrong and/or defeating the purpose of texture arrays (which should be performance gain, mostly, Imho)
Do you have any hints?
The setup: Windows 7 beta, Nvidia geforce 285gtx (driver 181.22), Cpu Q9700
Summarizing the data I've collected, accessing the 1st slice of a texture array with just 1 slice is 6 to 8 times slower than accessing a normal 2d texture, depending on the texture's size.
Doesn't this sound wrong and/or defeating the purpose of texture arrays (which should be performance gain, mostly, Imho)
Do you have any hints?
I'd suggest looking at shader tools that show you assembly. ATI has the GPU ShaderAnalyzer and NVIDIA also has something, which I'm too lazy to look for now :). I don't think these tools need actual cards, so ATI's should work well (for getting ATI results). This should show you if there's any significant change in the shaders between the two versions.
If you have a simple program to do this benchmark, I can try it on my Radeon 3870, if you want.
If you have a simple program to do this benchmark, I can try it on my Radeon 3870, if you want.
Author
Thanks, I'll extract that piece of code and make a benchmark tool out of it. Right now it's entangled in the bowels of a whole "engine". That would help me much since if the performance drop is actually like that I'll have to rethink a lot of stuff :\
Quote:Original post by resle
I am bringing this question back after having performed some tests with weird results.
The setup: Windows 7 beta, Nvidia geforce 285gtx (driver 181.22), Cpu Q9700
Summarizing the data I've collected, accessing the 1st slice of a texture array with just 1 slice is 6 to 8 times slower than accessing a normal 2d texture, depending on the texture's size.
Doesn't this sound wrong and/or defeating the purpose of texture arrays (which should be performance gain, mostly, Imho)
Do you have any hints?
First of all, don't benchmark beta operating systems! You never know what is in there or in its beta drivers. Try repeating this on a Vista system instead.
A texture array with a single slice can't possibly be faster than a dedicated normal 2d texture. Since, there will either be an overhead in looking up the texture from the array, or, the normal 2d texture will be implemented as a single element texture array anyways. You'd also be missing out on any optimizations that could be gained by telling d3d that it is truly a single texture and not a potential array of textures.
My understanding is that a texture array is only an optimization since it lets you index into an array of textures instead of having to do a bunch of conditionals to decide which sampler to use.
Author
Quote:Original post by andur
First of all, don't benchmark beta operating systems! You never know what is in there or in its beta drivers. Try repeating this on a Vista system instead.
Before having the W7 beta, I had Vista on the same machine. Same benchmark results.
Quote:A texture array with a single slice can't possibly be faster than a dedicated normal 2d texture.
Indeed! Nonetheless, I thought the overhead of looking up the texture from the array should have been minimal, not that heavy. Makes little sense..
Author
Done!
Well, I am amazed: looks like I had some debug code left in the shader files. Removed that, now accessing a texture array slice performms EXACTLY THE SAME as accessing a single Texture2d.
So I can't see a reason not to move my whole engine to assuming that every texture is actually a texture array, some of which will be single slice.
So in the end I get the following architecture:
- Meshes mapping is still made by U,V coords without a third value
- Every texture is actually a texture array of 1 to N slices
- When I draw a mesh, I pass to the shader a single float value which represents the slice to sample (tested the performance drop of doing that 1 million times per frame, and it's insignificant)
Well, I am amazed: looks like I had some debug code left in the shader files. Removed that, now accessing a texture array slice performms EXACTLY THE SAME as accessing a single Texture2d.
So I can't see a reason not to move my whole engine to assuming that every texture is actually a texture array, some of which will be single slice.
So in the end I get the following architecture:
- Meshes mapping is still made by U,V coords without a third value
- Every texture is actually a texture array of 1 to N slices
- When I draw a mesh, I pass to the shader a single float value which represents the slice to sample (tested the performance drop of doing that 1 million times per frame, and it's insignificant)
I'm pretty sure DirectX 10 treats a 1D texture array as a 2D array, and a 2D texture array as a 3D texture, internally...
(after all everything is "just a resource")
(after all everything is "just a resource")
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
