GPU clock

[Xone]

Hey all,

This is kind of graphics related, so I thought I should ask in here.
Is there any way of telling how many tris or verts will run smooth (30fps mininum) based on a GPUs clock speed ?
I presume a GPUs clock speed govorns the rate which a tri or polygon is built   

[hellfire]

No.
The number of polygons you can pass to the rasterizer also depends on:
- number of parallel vertex-shader cores
- vertex-size (total amount of data to be transfered)
- vertex-shader complexity
  (if the fixed-function-pipeline has many light-sources enabled you can think of it as a complex vertex-shader, too)
- cache-efficiency of the vertex-stream
  (how many vertices per triangle need to be processed by the vertex-processor)

Basically the same applies to the rasterization step (I suggest reading some papers if you want to go into detail here).
More complex pixel-shaders usually require more complex vertex-shaders, too. So in the average case both grow somewhat balanced.
Pixel-throughput varies if the shader contains more arithmetic (requires gpu-clock) or texturing (requires memory-clock) instructions.

[Xone]

thanks hellfire. It's flat shaded (raw) geometry that I'm trying to gauge, no pixel shader or texture info.
I'm searching for some kind of rule that I can refer to when designing 3d content to run on specific gfx cards.
Close estimate only.

Re: "number of parallel vertex-shader cores"

Is this also known as stream units ?

[Jim]

The architecture names seem to change with pretty much every generation of the hardware.  It did used to be that we had dedicated vertex units, rasterisers and texture units, but now the whole thing is more generic and we have units that are able to transform or texture depending on demand.  This kind of reallocation of resources makes it almost impossible to work out maximum throughput.  You might find that not textured, not pixel shaded gives you a reasonable transformation/rasterisation measure on some cards, but there are so many variables.  I remember seeing the 15million poly a second demo on a GeForce 256, but they were like 4 pixels each, non textured, triangle stripped.  You could never get anywhere even vaguely near that for real life scenes.  Possibly only 50,000.

Jim

[Xone]

"This kind of reallocation of resources makes it almost impossible to work out maximum throughput."

Yeah, almost looks to me like they're hiding certain details in the architecture as a marketing ploy.
I've personally noticed a decline in gaming card quality (regarding transform especially). These days, you only really
purchase them to get the fancy pixel shader support. Whereas you can actually pick up some older
gaming cards (beleive it or not), for a quarter of the price that will run crysis on high (but you have to look
past the shader aspect). Anyhow, despite my gripes about that.
If there's no way of fully determining what they can do, it looks like it's going to be largely trial and error.

As the technology gets more powerful, 3d artists (and I presume the same for some coders) are getting sloppy regarding
dedication to quality (well optimised) development practices, and instead are relying on what hardware can do - this is also
becoming a by product of stricter deadlines in industry. The importance of optimisation is definately something which should be emphasised more.
The better your optimisation, the more bang you can get from the work you make 

[hellfire]

If you pick coordinates and order carefully, you can bring even the strongest badass-gpu to its' knees with only a handful of polygons.
So it doesn't make sense to conjecture about bottlenecks before they're actually happening.