How much of a performance hit with many texture units?
Author
I currently have 13 texture units active and was wondering with 16 available how much of a performance hit am I taking by using so many? I tried reducing the number of polygons on the screen and seems to make no difference in FPS? How can one tell the different limitations you hit with hardware? CPU, GPU fillbound ect... Thanks
Author
BTW I am not sure on SLI but would SLI speed up all bottlenecks in an engine??? Thanks
I thought most hardware only had 8 texture units at the most... (Edit: It appears I'm somewhat mistaken. Look at this thread).
Anyway, if you're taking a performance hit from all those texture units really depends on your application, although I wouldn't be surprised if you were. Texture reads, (especially 13 per fragment!), are a moderately expensive operation.
I'm afraid I don't know what SLI is, so I can't answer your second question.
Read the OpenGL performance tuning document from ATI's GDC presentation for tips on how to find (and hopefully fix) bottlenecks in your application.
Anyway, if you're taking a performance hit from all those texture units really depends on your application, although I wouldn't be surprised if you were. Texture reads, (especially 13 per fragment!), are a moderately expensive operation.
I'm afraid I don't know what SLI is, so I can't answer your second question.
Read the OpenGL performance tuning document from ATI's GDC presentation for tips on how to find (and hopefully fix) bottlenecks in your application.
For the performance tuning people really should look at the Forum FAQ more [razz] (good link from James Trotter there as well).
As pointed out, texture reads are expensive and can consume memory bandwidth at a remarkable rate. Now, just having 13 texture units active wont hurt you but if you are sampling all of them per fragment well, that gonna much your memory bandwidth pretty damned quickly.
SLI might speed up the bottlenecks, but it all depends on where they are in the program, if you are CPU bound then no, best it'll do is allow you to run at a higher res with a higher framerate. With two cards sharing the work load it could speed up things a bit when it comes to GPU and memory bound operations however.
As pointed out, texture reads are expensive and can consume memory bandwidth at a remarkable rate. Now, just having 13 texture units active wont hurt you but if you are sampling all of them per fragment well, that gonna much your memory bandwidth pretty damned quickly.
SLI might speed up the bottlenecks, but it all depends on where they are in the program, if you are CPU bound then no, best it'll do is allow you to run at a higher res with a higher framerate. With two cards sharing the work load it could speed up things a bit when it comes to GPU and memory bound operations however.
Author
Yes I am doing 13 per fragment in a Fragment shader, boy does it look awesome!! :) As I said, reducing my polygon count does nothing to speed up, I haven't tried resolution or texture size/compression.
From what I've read on SLI lately it renders one frame to one card then the next frame is done on the other card. Basically doubling the FPS so you can do more complicated operations and still maintain speed. Transfering of data between the two cards is extremely fast and should not be a bottleneck with SLI. I could be totally wrong as I read articles not from nVidia, but from review sites of cards (looking at getting up to 8 7800s for development... Time to sell the house!)
Well if you want to see if fillrate is your bottleneck simply increase the resolution you're rendering at, if your performance is effected by this then you're fillrate bound (it does seem likely that you will be).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
