Sign in to follow this  
Quinnie

Pixel Shader Performance - UV Wrapping

Recommended Posts

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

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by Quinnie
My textures are stored in the .DDS format, would it help if I converted them into jpg or something?
No, 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...

Anyway, JPEG is a REALLY bad format to be storing texture data in!

hth
Jack

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this