The numbers provided are purely theoretical. They are usually measured in a setup that allows the maximum performance, regardless of whether that situation is practical.

You could probably get closer to those figures if you:

1) Used an empty vertex and pixel shader (OUT.position = in.Position and that's it).
2) Used position only vertices.
3) Made sure to make few API calls, that draw a lot of vertices, which in turn draw very few pixels.

In addition to all that, there's a chance they decided they'd use an "average" hit rate on the Post-VS cache when they performed the test, increasing performance even further. They might have also done the same with clipping.

Finally, there's a chance they didn't actually do any tests, but just decided what the hardware "should be able to do", and released those figures instead.

Hope this helps.

Try to split up the test model and limit each single draw call to a few 100.000 vertices. There was a saying somewhere in the net that too many vertices per batch incur a performance hit as well. I haven't tried this for myself, so I'm only repeating a story here. But it doesn't cost any effort to try it out, so give it a try.

Quote:Original post by hunpro

I will concentrate on the tricount from now, and give up my original idea:
That was build on the vertex-speed of the GPU, to replace every pixel on the screen with a triangle (vertices with only pos, normal, diffuse and specular = 32bytes, the fastest vertex size..sigh).
This way, no need to uses textures, and bumpmaps, because diffuse & normals do the trick (lot more videoram for geometry, and no need to 'UV' the models.)
May be this idea is not THAT good.. :o)

Doing that would probably choke the life out of your GPU. GPU's are designed to render in quads of pixels (in parallel). A triangle that spans only one pixel would completely break this, and its likely the performance would be abysmal.