Pixel Shader Performance - UV Wrapping
Author
Hey,
i've created a terrain engine and would like to add some sort of multitexturing to create some interesting terrain. I'm am using one blend map and 4 textures. The blendmap is A8R8G8B8, the Alpha component is used to determine the blend factor of the first texture, the red component is used to determine the blend factor of the second texture and so on.
However if I used uv-coordinates in the range of 0-64 and enabled wrapping, so the texture would repeat, the performance was pretty slow (10fps on a Geforce 7600GS). However the performance increased significantly (Vsync limit, 60fps also on a Geforce 7600GS) when I used a uv-coordinates range of 0-1 and spread one texture over the entire terrain.
I'm not quite sure why the performance is so much higher if you don't wrap the the texture. I would appreciate it a lot if someone could enlighten me.
Kind regards,
Quinnie
It's probably not that it's wrapping, but that when it is larger you're using the texture cache better. For every texel you need to fetch now, you used to need to fetch 4096 texels (64*64). If your texture don't have mipmaps the slowdown will be even worse.
Don't use more texture res and repeats than necessary, and ensure you didn't ask for only 1 surface level when loading the texture (ask for 0, it means "all levels" for any size texture)
Don't use more texture res and repeats than necessary, and ensure you didn't ask for only 1 surface level when loading the texture (ask for 0, it means "all levels" for any size texture)
I have heard of a similar characteristic before, but to truly understand it you probably need to have a good knowledge of the underlying GPU architecture. As NTNBET suggsted, you could be killing cache utilization and therefore burning memory bandwidth unnecessarily.
If you're using a pixel shader, why not implement the wrapping calculations before you call tex2D()?
hth
Jack
If you're using a pixel shader, why not implement the wrapping calculations before you call tex2D()?
hth
Jack
Another killer, which take extra processing and forces usage of more detailed mip levels, would be anisotropic filtering. If you're using heavy aniso filtering, it requires extra texture fetching. Mix that with your wrapping, and you could be asking the card to look up a lot of information.
Quote:Original post by jollyjeffers
I have heard of a similar characteristic before, but to truly understand it you probably need to have a good knowledge of the underlying GPU architecture. As NTNBET suggsted, you could be killing cache utilization and therefore burning memory bandwidth unnecessarily.
If you're using a pixel shader, why not implement the wrapping calculations before you call tex2D()?
I've heard the same before and I just realized my terrain might have the same issue. On my ATI hardware there doesn't seem to be any severe performance penalty though, even if I use UV coordinates in the 0-128 range. But obviously I'd like my terrain implementation to be as robust as possible, so I'm wondering exactly what you mean with "implement the wrapping calculations before you call tex2D()".
Are you suggesting we should use texcoords % 1 to do our lookups?
Author
Well I tried implementing the wrapping calculations before the Tex2D() call but It would result into the same low fps performance.
My textures have the mipmap levels included and I'm pretty sure they are loaded
correctly. And I don't thinking I'm using any fancy anisotrofic filtering.
Thanks for your responses and kind regards,
Quinnie
My textures have the mipmap levels included and I'm pretty sure they are loaded
correctly. And I don't thinking I'm using any fancy anisotrofic filtering.
Thanks for your responses and kind regards,
Quinnie
You didn't say what format textures you're using (except for the blend map), but if you're not using compressed textures I'd suggest trying them. That should save on texture bandwidth, and might increase your frame rate significantly.
You could also try to verify the settings you think you have.
For example, anisotropic was mentioned, and though you say you're not using it, I think that just to make sure, check that the 7600GS isn't overriding this in its control panel.
You could also play with the zoom on the terrain and see how it affects frame rate. Try to reduce texture size, and see how it affects frame rate (then double-check the MIP-mapping to make sure it works, for example by tinting separate MIP levels in different colours).
You could also try to verify the settings you think you have.
For example, anisotropic was mentioned, and though you say you're not using it, I think that just to make sure, check that the 7600GS isn't overriding this in its control panel.
You could also play with the zoom on the terrain and see how it affects frame rate. Try to reduce texture size, and see how it affects frame rate (then double-check the MIP-mapping to make sure it works, for example by tinting separate MIP levels in different colours).
Author
Hey,
thanks for the advise I'll take a look at al my settings.
If I zoom into my terrain very close the framerate improves significantly, I'm not sure if that is relevant though.
My textures are stored in the .DDS format, would it help if I converted them into jpg or something?
Thanks a lot about the mipmap trick I'll try it right away.
Kind Regards,
Quinnie
thanks for the advise I'll take a look at al my settings.
If I zoom into my terrain very close the framerate improves significantly, I'm not sure if that is relevant though.
My textures are stored in the .DDS format, would it help if I converted them into jpg or something?
Thanks a lot about the mipmap trick I'll try it right away.
Kind Regards,
Quinnie
Quote:Original post by QuinnieNo, there is no point in doing this. Using compressed image formats might improve the HDD-footprint, but it's largely irrelevent for in-memory storage considerations. Lossless formats like PNG could be useful but they'd still be stored uncompressed in memory and you'd get the same image quality/performance...
My textures are stored in the .DDS format, would it help if I converted them into jpg or something?
Anyway, JPEG is a REALLY bad format to be storing texture data in!
hth
Jack
DDS can contain compressed texture data, or uncompressed (even cube maps, volume textures, and precomputed mip chains too). You want to use a DDS file with a DXT format texture to get data that is actually compressed on the graphics card. A DDS file that contains X8R8G8B8 data won't have any sort of compression, only the DXT formats. All other file formats are compressed on disk, but not in video memory, such as PNG, JPG, TGA, etc. Keep in mind DXT texture are lossy.
JPG compression is especially bad for textures because the data is discards is only meant to have no major visual difference when drawn 2D unscaled.
JPG compression is especially bad for textures because the data is discards is only meant to have no major visual difference when drawn 2D unscaled.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
