You're assuming that the hardware can put multiple triangles into a hardware thread or even that multiple triangles can occupy a fragment-quad.
I'm not assuming the latter at all (hence my use of quads/clk throughout my post), and the former is a solid assumption. Remember that Xenos is able to do this, and it's more closely related to R600 onwards than R520. What's so hard about it? All Cypress has to do is store vertex indices for each quad so that the interpolation routine can fetch the correct data. With RV770 and earlier, the shading engines had no idea which triangle the quads came from because interpolation was done earlier and stuffed into the registers.
Why, in this era, would ATI support multiple triangles per hardware thread, when hardware threads are small and when there's so few small triangles, ever?
Because they already did the minimal work required in Xenos and probably earlier.
You're wrong about "so few small triangles, ever". I'm having trouble finding public information about triangle size distributions, but here's an old one with GLQuake II information:
http://citeseerx.ist.psu.edu/viewdo...CAA817BB2?doi=10.1.1.56.8726&rep=rep1&type=ps
They do glide interception, but don't mention the rendering resolution (let's assume 640x480). They find
41% of the visible triangles are 1-25 pixels in size. How is this possible if 640*480/1300 = 307? Well, that's the area-weighted average triangle size and says nothing about the distribution. Nowadays we have 10x the pixels and well over 100x the triangles, so that likely means even more triangles are tiny. Still think triangles are big?
It's just plain stupid not to have multiple triangles per hardware thread.
Look, it's very easy to test this. Draw a fullscreen mesh with a 10,000 cycle pixel shader and no AA, and see what happens as triangle edge length decreases from 100 pixels down to 0.1. If you're right, it will bottom out at 1/64th of large triangle performance. If I'm right it will bottom out at 1/4th.
Since I believe that single-pixel triangle tessellation is a strawman, I wonder why I'm here, frankly.
Do you have split personality?
You are the one that proposed >10M visible triangles per frame, not me. You are the one that brought up one pixel triangles, not me.
If you have a 40 cycle shader (up to 400 flops, 10 bilinear fetches), ATI's tesselator will avoid idling the SIMDs only if the rasterizer generates a buffered average of six quads per triangle. Note that I'm counting wavefronts with as little as one visible sample in each of its 16 quads as keeping an SIMD busy.
The tessellator is a bottleneck for triangles with an area of 5, 10, even 15 pixels. One-pixel triangles are completely irrelevent. Do you get it yet?
As I explained earlier, a shadowmapped game with 4M triangles per frame will work out to around 300k visible triangles in the final rendering view. That's an average of 5-10 pixels per triangle, depending on resolution, and thus is
not comparable to your strawman case of single pixel polygons. Heaven shows us that 4M triangles is enough for tessellation performance to be a major factor.
Just because IHVs have under 50% quad-filling efficiency for <10 pixel triangles doesn't mean that they'll throw in the towel and let wavefront efficiency drop to <10%.
The B3D graph shows that the longest draw call is ~28% of frame time. I don't know the frame rate at that time, but let's say it was 20fps, 50ms.
Why are you assuming 20 fps when B3D provides perf numbers much higher than that? You don't know how much that state (which can have multiple draw calls, BTW) changes without tessellation, so you're going about it the wrong way. That's why I looked at total frame time, because we have differential data in the review.
On a close-up of the dragon the frame rate is about 45fps without tessellation. That implies a very substantial per-pixel workload - something like 260 cycles (2600 ALU cycles) per pixel assuming vertex load is negligible
That's a dumb assumption. Why do you think vertex load is negligible? Only the objects that the programmer bothered to cull with the CPU will be eliminated, and this is a demo.
One of the factors here is we don't know what Heaven's doing per frame. Their site talks about advanced cloud rendering, for example. That'd be a workload that's unaffected by tessellation.
And this is why I use render time differential. All the assumptions you're making are grossly flawed and unnecessary with my approach. The difference in render time that I'm highlighting is due only to the difference in workload brought about by enabling tessellation.
Ah yes, it was so easy and obvious, it's a feature of Cypress
Stop putting words into my mouth AGAIN. I never said doubling setup was easy. I said the rasterizer, shading engine, and render backend could be left untouched. You said it needs to be overhauled to take advantage of faster tessellation, and that's just plain wrong.
Leaving the setup and just improving to one tessellated triangle per clock, on the other hand, is very easy, and I'm baffled as to why Cypress can't do that. Laziness? A bug? Planned obsolescence?
Has anyone timed how many triangles per clock we see from R600 onwards when creating tri-strips in the geometry shader? Maybe they just left the geometry amplification hardware unchanged.
