Big question about fill-rates
Author
Alright I''ve done pretty much everything I can here. I''ve optimized my terrain with both Octrees and CLOD (which reduced the number of triangles on the screen down to 1/10 of what it was before). Despite those two optimizations, my engine runs at a pathetic 30 FPS on my 2.8gHz P4 (crap gfx card though, 32MB VRAM), and that''s at a good place. The rate goes down to 15 FPS in spots where only 5000 polygons exist (7000 is about the max since I implemented CLOD). My theory is that the speed of drawing is being limited by the fill-rate. Is there any way to get around this? If i scale down my terrain, velocity, collision distance, etc, can I create the illusion of a much larger terrain? (I have an 8192m view distance right now)
How did you conclude it was the fill rate? Check this paper on the way to tune for performance:
www.ati.com/developer/gdc/PerformanceTuning.pdf
www.ati.com/developer/gdc/PerformanceTuning.pdf
Author
Well I made the conclusion based on:
1. my world is huge given my graphics card
2. the poly count is low (7000 is about the norm)
3. the FPS goes down only by 50% if I scale the entire world down to fit in one view (over 1 million polygons)
4. If I scale the world down by any small increment (double or so), the FPS actually goes up a bit
5. I only know of Polygon and fill-rate as limiters
6. I don't want to think it was inefficiency in my implementations
[edited by - uber_n00b on June 2, 2004 1:24:31 PM]
1. my world is huge given my graphics card
2. the poly count is low (7000 is about the norm)
3. the FPS goes down only by 50% if I scale the entire world down to fit in one view (over 1 million polygons)
4. If I scale the world down by any small increment (double or so), the FPS actually goes up a bit
5. I only know of Polygon and fill-rate as limiters
6. I don't want to think it was inefficiency in my implementations
[edited by - uber_n00b on June 2, 2004 1:24:31 PM]
First make sure that your app is fill-limited.
Does inceasing the size of your window affect your FPS?
If it does then, your probably fill-limited.
It''s best to profile before making assumptions about where
your bottleneck is.
Does inceasing the size of your window affect your FPS?
If it does then, your probably fill-limited.
It''s best to profile before making assumptions about where
your bottleneck is.
Read the paper first and go through the investigation process it describes. Use VTune or another profiler to make sure you are trying to hit the right bottleneck.
Author
To answer your suggestion, I changed the resolution from 640x480 to 320x240 and the FPS went up to over 60. Is that
'affect' enough? Edit: I am reading the paper now.. is rasterizer fill-rate?
[edited by - uber_n00b on June 2, 2004 1:28:58 PM]
'affect' enough? Edit: I am reading the paper now.. is rasterizer fill-rate?
[edited by - uber_n00b on June 2, 2004 1:28:58 PM]
Author
Hrm OK I''m about to go nuts One of the first things the stupid thing suggested I must have removed a long time ago: mipmapping. Argh ^^
One of the first things the stupid thing suggested I must have removed a long time ago: mipmapping. Argh ^^
Then the problem is the rasterizer and beyond. Too much texture filtering? Too detailed texture data? Wacky pixel shaders? Inefficient multipass rendering? Too many render-to-texture passes?
Author
UGH that was the problem. The FPS just tripled. When I converted the code over from a previous version I must have set GL_MIN_FILTER to GL_LINEAR on accident
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
