My understanding of this is that they have four parallel units, but those units may at times be stalled waiting for the results of other units. They've put a lot of work into attempting to make sure that these four parallel geometry units are used as optimally as possible, but in reality we can't expect a 4x increase in hardly any aspect of geometry performance.
I must say that left me severely disappointed too ! that means the chance of GF100 to improve it's overall performance due to enhanced geometric design is low ! in normal cases of course !
From the architecture layouts, it seems it should be able to do better than 1/clock. Because it has four parallel geometry units as opposed to one monolithic unit, it seems extremely doubtful that there could be any hardwired limitation to one triangle per clock.
For GF100, yes, but the aggregate rasterisation area is no bigger than prior hardware could rasterise in a clock.
I agree it's less bottlenecked with more (u,v) generation, but that's really a latency issue. If all the ALUs are needed to balance the DS and setup the one (u,v) per cluster option would take a little longer to reach steady state, but it would still reach it. How much of a performance impact this has will be determined by the amount of work done before switching to a workload that requires a different balance. This is still on the assumption that there's close to one new (u,v) per setup primitive.
It's unclear if GF100 can achieve full rate without tessellation, but it should be easy to test with a custom app. The potential limitation is that there is a single index buffer per draw call. So they need to parallelize processing of the index buffer to make a single draw command run faster than 1x. This is non trivial.
From the public docs ... sure. If the other IHVs weren't made aware of it, then in combination with the fact it's only at HLSL level (not the assembly level, where nothing can be hidden because it's used for drivers) then it becomes rather hard to believe.
I don't think DX11 engines are far enough in development for it to be an obstacle, especially if NVIDIA volunteers the work/code necessary to integrate it.
Thanks Mr.Rys , but I have to wonder : you guys said that the reason why no body cared to double the number of Hardware Rasterizers is that you have to figure out what to do when triangles overlap , or share vertices .. how is that different in GF100 situation ? how did Nvidia overcome this seemingly difficult obstacle ?
Basically it's a problem of out-of-order execution. Anand goes into it a little bit here:
