Highest triangle count?

Quote:

Original post by ttdeath I had made some tests, but I couldn't get anywhere near the number of triangles/sec NVidia claims for this type of cards. (some 70% like).

The numbers that nVidia and ATI give are absolute maximums. You're very unlikely to be able to actually get those sort of numbers in a real world application. Do you mean you managed to get about 70% of the number nVidia says? That sounds about right, you might be able to squeeze a bit more out of it, but probably not if you're using pixel shaders.
The numbers that are published probably use as little detail in the scene as possible, in order to get the triangle counts up.

Quote:

Original post by Evil Steve The numbers that are published probably use as little detail in the scene as possible, in order to get the triangle counts up.

My understanding is that sometimes they quote the numbers from working out the theoretical throughput of the hardware - based on the case that the GPU is being utilized perfectly at 100%. Even if that isn't actually possible in software, let alone a "real world" application [rolleyes].

Anyway, as Evil Steve said, it very much depends what sort of geometry you're trying to render. You need to specify this before you'll get any sort of meaningful answer [smile]

Also, it's not necessarily a single-variable system - that is, the pixel throughput (and others such as the CPU load) could add latency to the system such that you can't reach your peak geometry throughput.

hth
Jack

Quote:

jollyjeffers said:Anyway, as Evil Steve said, it very much depends what sort of geometry you're trying to render. You need to specify this before you'll get any sort of meaningful answer

Ok, so to make it clear:

I am interested in any form of geometry organisation and rendering techniques and shading techniques, ranging from raw separated triangles to pixel shaded complex models, as long as all the triangles get actually rendered.

I am mostly trying to see how much better my algorithms have to become and I can't do that without non-marketing bull...t. 70% from the tri/sec count, seems a little low at this time. This number is for raw separated triangles rendering with difuse coloring only. So, not even texturing thrown into the mix.

It doesn't matter if you don't have exactly the cards. I can figure it out, from whatever results you've got.

Thanks.

Quote:

Original post by ttdeath I am interested in any form of geometry organisation and rendering techniques and shading techniques, ranging from raw separated triangles to pixel shaded complex models, as long as all the triangles get actually rendered.

I don't wish to be difficult, but couldn't I throw you pretty much any number/percentage and it'd match up to one of those cases? [smile]

For your example, it sounds fairly reasonable - but probably with some room to go a bit higher.

For good performance with "fixed function" geometry, you want to make sure that the draw calls and vertex cache are going to be used as effectively as possible. Typically that means having as few Draw..() calls as possible, and using index buffers and/or reordering your triangles so as to allow the hardware to make best use of it's pre/post transform cache's.

A trick that you might want to try to verify your performance (and it's a classic bit of optimization/profiling) is to scale all of your geometry to the extent that it DOES NOT appear on the screen.

In doing this, it'll still get through the T&L/vertex processing stages, but have little (if any) processing done during the rasterization stage. With this in mind then you should remove that as a possible bottleneck. The resultant throughput should be representative of the maximum geometry throughput.

In summary... if keeping the amount of geometry constant and increasing/reducing the number of pixels alters the framerate, you will be fill-rate limited. If you're fill-rate limited you (probably) won't be hitting the peak geometry throughput, thus any results you get will be at best a guideline - but not very meaningful.

If changing the number of pixels does nothing to your frame rate, you're probably already transform-limited, and the results you are getting are accurate.

hth
Jack

Quote:

Original post by jollyjeffers I don't wish to be difficult, but couldn't I throw you pretty much any number/percentage and it'd match up to one of those cases? [smile]

Quite. So i suppose I'll lay low for a while and then come up with a topic like:
"Simple Shading with pixel shaders, N triangles of size X. XXX FPS. Can anyone beat this? Anyone at all?" :) Maybe this would atract attention and a rating penality.

Quote:

For your example, it sounds fairly reasonable - but probably with some room to go a bit higher.

Not to me, I'd very much like to squeze all the performance available from any given card. Also I'd very much like to get a test scenario from Nvidia where their numbers aren't just sMarketing.

Quote:

For good performance with "fixed function" geometry, you want to make sure that the draw calls and vertex cache are going to be used as effectively as possible. Typically that means having as few Draw..() calls as possible, and using index buffers and/or reordering your triangles so as to allow the hardware to make best use of it's pre/post transform cache's. A trick that you might want to try to verify your performance (and it's a classic bit of optimization/profiling) is to scale all of your geometry to the extent that it DOES NOT appear on the screen. [...]

Excellent! Didn't know this trick. Thanks. I rated you up for this.

Bogus numbers don't scare me, I'll make a weighted average / bet on programmer's sincerity :). So, if you wish.. just shoot.

Tudor