# Determining FPS vs Triangles Rendered

This topic is 3688 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have asked a similar, more specific question before, but I am posting this additional question to request more help. To recap: I have been given the task of determining an application's frame rate as a function of triangles rendered. The specification of the objects is done by tri strips. The object input file has a section which lists vertices, for example a quad:
vertices
1.0 1.0 0.0
0.0 1.0 0.0
1.0 0.0 0.0
0.0 0.0 0.0

and a section which lists the tri strip indices:
indices
4 0 1 2 3

Where the first number is the number of indices, followed by the indices. There are similar sections for surface normals and texture coordinates. This is a custom in-house (i.e. stupid) format. My plan was/is to make a single quad, with an increasing number of tri-strips, and determine the frame rate for each quad. The problem is that for any significant number of tri-strips, the creation of this input file becomes extraorinarily tedious (at least for me it does). The main thrust of this post is to basically ask: Is this a dumb way to do this and if so, what would be a better approach? There are some parameters which are immutable and these are as follows: 1. The end parameter I seek is fps vs tris. 2. The input format of the file. 3. The FPS is calculated by the app under test, and that is the parameter I must report, as opposed to an offline gl debugger. Alternatively, I would like to know if there is an easier way to generate the input file vertex index list. Creating the vertices is easy... I can whip out some C code to do that in about 5 minutes. The issue is generating the tri-strips from the vertex data. Will NvTriStrip or tri-stripper do this for me, without generating a tri-strip of only two triangles? Thanks for your patience and help, CD

##### Share on other sites
NvTriStrip or tri-stripper have the target of creating as few strips as possible, but they can't guarantee that there are strips of only 2 triangles. NvTriStrip, however, has a parameter that let's you say: create a single strip by inserting degenerate triangles (processed but not rendered), i.e. "stitching" the strips together.

##### Share on other sites
That's fine but in the end it's a meaningless test. FPS has vastly more to it than # of tris rendered. For instance, render the tri's with no overlap between them: super fast because no overdraw. Render exactly the same # of tri's stacked from far to near clipping plane: horrible framerate because of overdraw. In the first instance you're touching each pixel of the frame buffer once, in the latter you're touching it # of triangles times.

There a at least dozens of factors leading to FPS, generally least of which is # of tris. Very few applications these days are limited by # of triangles.

context switches (are you changing shaders, materials, lighting, etc)
overdraw
fill-rate

-me

##### Share on other sites
Good info, and I understand, but...when the customer asks for something, you give it to them...then explain why they need additional information....So I must forge ahead.....
CD

Quote:
 Original post by PalidineThat's fine but in the end it's a meaningless test. FPS has vastly more to it than # of tris rendered. For instance, render the tri's with no overlap between them: super fast because no overdraw. Render exactly the same # of tri's stacked from far to near clipping plane: horrible framerate because of overdraw. In the first instance you're touching each pixel of the frame buffer once, in the latter you're touching it # of triangles times.There a at least dozens of factors leading to FPS, generally least of which is # of tris. Very few applications these days are limited by # of triangles.context switches (are you changing shaders, materials, lighting, etc)overdrawfill-rate-me

1. 1
2. 2
3. 3
frob
12
4. 4
5. 5

• 13
• 14
• 65
• 14
• 15
• ### Forum Statistics

• Total Topics
632130
• Total Posts
3004286

×