Rasterisation is fundamentally bandwidth limited because it's pixel shading (with other bottlenecks such as texture rate at times). Or if the pixel shader has no texturing and is very short then the ROPs are likely to be running at full speed. The count of ROPs is usually limited by design to what's meaningful for the available bandwidth (not if it's R600) which is why ROPs scale with MCs, generally (though ATI's at it again with the peculiarities of Redwood).
I'd say the question mark is on ALU capability. But as I've queried before, we don't know if DS is more typically TEX limited than math limited.I could rather question if GF100 future architecture will be used in the near future or u will need another generation till the rest of the chip will catch up with the rasterizers (bandwith,number of cores)
HD5870 with tessellation is faster than HD5770 without tessellation, with tessellation and setup running at the same rate in both GPUs. If HD5870 is tessellation/setup limited in this test, what's going on there?
It's not 10% anymore. It was probably somewhere in that neighborhood before unified GPUs came around (with some games a lot more than others), but now they just blast through vertex shaders. A cache-friendly mesh approaches two triangles per vertex transformation, so if you look at Cypress, you'd need 3200 MADs per vertex before the VS becomes a factor. Remember that portions of the scene that are geometry limited have very little pixel load at the same time.
Except bear in mind that nVidia is using this process months later, which likely means higher yields. Since they are using the same fab, it's going to have (more or less) the same level of maturity for both of them by the time the GF100 starts shipping. So while ATI's yields are likely to improve as well, nVidia is just less likely to have the same problem, despite the larger chip size.
It'd be nice if you could use whole words, but the fact is that with tessellation, you can dynamically change the density of polygons, such that you never get too many triangles per pixel. I'm not sure what the current targets are for GF100-level hardware, but it is certainly reasonable to have it target, for example, one triangle per pixel.What if u have a realy long brick wall and u watch it from a smal angle. U will get insane amount of triangles in a single pixel.
Anyway i think that tesselation should be used for increasing complex details from close and not wasted on roof tiles, facing stones that could be modeled in 3d with much less triangels. Also using tesselation on such basic things like brick walls is quite overkill. What if u have a realy long brick wall and u watch it from a smal angle. U will get insane amount of triangles in a single pixel.
Just because this test has setup limitations doesn't mean that it's purely setup limited. If we assume that the 5870 is twice as fast as the 5770 at pixel loads but equal at geometry, then those scores suggest the following:
GF100 has fast setup speed, but let's not get carried away. One pixel triangles would mean pixel shading power is cut by more than four due to each triangle occupying four threads (a quad) in the shaders.
Apparently it's about 23% in Unigine with tessellation off on HD5870 according to your follow up post. But other bottlenecks are in play, i.e. HD5870 isn't ALU limited for geometry here - it could be vertex bandwidth limited or fillrate (Z rate) limited.
Does that take account of multi-pass geometry, shadow buffer rendering passes, overdraw, transparency passes and shrinking triangles?
I don't understand what you mean by portions of the scene.
I'm assuming this is the scenario you're painting: that VS is setup limited, that's 4 triangles per SM clock or 2 vertices per SM clock. There are 1024 ALU instructions per SM clock (hot clock is 2x SM clock), so 512 ALU instructions per vertex per clock is the limit for 100% VS usage of the GPU. I wasn't thinking of 100% usage, I was contemplating VS becoming the dominant shading workload (>50%) after tessellation (4x multiplier of triangles), which is 64 instructions per vertex.
That was my point. There's a suggestion that tessellation/setup rate limit is what's occurring here, but at worst this is not a continuous bottleneck.
How are you calculating this?
I agree, the resulting framerates are troublingly low. Even without tessellation they're troublingly low. But then, that's what synthetic benchmarks do.
Which is why I'm dubious of the pixel/geometry balance you've derived above, as well as other factors.
Huh what? In what way is tessellation in any way related to deferred rendering?
