NVIDIA Fermi: Architecture discussion
- Thread starter Rys
- Start date
It is not related per se, but is a push towards deferred rendering. It eliminates shading and lighting work done for fragments that are eventually discarded.
If you are measuring overdraw as a ratio of number of times the pixel shader runs vs no. of pixels actually drawn, then it has an overdraw of 1.
I'm not sure how. I'm pretty sure the z-checking is still done in the usual way.
How?
Does this link and the references contained in it help?
http://en.wikipedia.org/wiki/Deferred_shading
Jawed
Legend
Deferred is certainly relatively happy with high triangle counts (and the doubled fillrate is the key thing in Evergreen). But Z pre-pass (where the developer pre-populates Z with unshaded triangles) is a relatively simple major step in that direction. Marco's concept of a Z pre-pass before the main G-buffer write pass theoretically also applies
I'm not sure how tessellation affects the relative cost of the Z pre-pass and the shading pass - and there's a question of the degree to which the Z pre-pass is setup bound, or becomes setup bound with tessellation.
The D3D pipeline is flexible enough already in theory. Xenos's pipeline supports explicit markup for tile IDs on vertex buffer content (done by the CPU I think). Though there's a difference between tiling across 2 to 4 tiles like you might do with Xenos and tiling with typically hundreds and as many as thousands (2560x1600 with 32x32 tiles is 4000 tiles).And while your rendering has been deferred, why not render in tiles to increase bandwidth efficiency as well. LRB FTW
If only an IHV will take the initiative to include hw acceleration for sorting fragments in tiles and exposing it in OCL.
Tessellation amplifies triangle data - if that data is binned in memory then you've kinda lost one of the benefits of tessellation: memory space and bandwidth savings (though these benefits apply jointly to the main RAM/disk side as well as the GPU side, so the host side gains aren't lost). G-buffers can also be fairly expensive in memory consumption.
So then you have the question of whether the cost of binned triangles in memory is offset by the pixel shading coherency gain, bearing in mind that these traditional GPUs are designed around incoherent pixel shading (while they tile fragments during rasterisation, those tiles are only fleeting, so a given tile is visited repeatedly during a single frame).
Fermi architecture theoretically allows these fleeting tiles to live for longer in L2 before being evicted (because L2 is huge in comparison with the caches attached to ROPs in older architectures), increasing the chance that even in forward rendering these tiles will accelerate blending or MSAA a step beyond the older GPUs.
Some kind of die stacking seems inevitable to me. Larrabee should be here before die-stacking on this scale occurs for desktop GPUs...
Jawed
I am entirely familiar with deferred shading, but I still don't see how you think tessellation has anything at all to do with deferred shading.
Deferred shading is a way of storing the entire scene (or at least a significant portion of it) so that rendering can be done by ray casting through the triangles in the scene, only rendering a pixel from a triangle if that triangle is visible.
Tessellation is a way of dynamically subdividing and displacing triangles to improve detail.
What do the two have to do with one another?
They affect the trade-offs of using one vs. another. For instance, tesselation often implies smaller triangles which implies that forward rendering shading rates become somewhat less efficient (due to only partially-filled SIMD lanes) while deferred rendering can often recover this cost.
I agree though that tesselation itself isn't really a "push towards deferred rendering"... more that using it starts to provide additional benefits in also using deferred rendering.
I don't see how using SIMD lanes is a design decision that is necessarily tied to traditional rasterization as opposed to deferred rendering.
I think what he means is, in deferred renderer, it's easier to pack SIMD lanes from different triangles (because the necessary parameters for each pixel are already computed before), compared to a traditional renderer which may not be able to pack multiple small triangles into SIMD lanes efficiently.
Couldn't you do the same with a more powerful triangle setup engine and a little bit of caching? Should be reasonably efficient for tessellated triangles, at least, as neighboring triangles should be near one another in screen space.
The user can do a way better job of it than the graphics pipeline implementation (which has to be pretty conservative about when it can combine SIMD warps, interpolants or quantize derivatives or LODs to 2x2 quads).
Not sure what you mean... the geometry pass is pretty inexpensive in a deferred renderer. As Marco notes, one big advantage is getting the complicated (and often suboptimal) triangle renderer/rasterization scheduling decoupled from the bulk of the computation, which can often be more efficiently rescheduled in a deferred pass.
If you're talking about a tile-based or "binning" renderer, that's a different story. In that case yes, you get very large triangle bins for each tile unless you can do something clever (bin bounding boxes and tessellate on the fly or something). That said, this is more about a binning/tile-based renderer than deferred renderers... the latter operate similarly under both immediate-mode and tile-based renderers with respect to triangle counts - they just provide some additional benefits to tile-based renderers as well.
Last edited by a moderator:
Mintmaster
Veteran
No, my post was calculating setup (rather anything that runs at the same speed as on the HD5770 as opposed to 2x).
Those should still be twice as fast on the 5870, so I'm not quite sure what you're getting at.
Yeah, it's hard to say. Wireframe may not be saving a lot of rendering load when tesselated, because a breakdown of rendering times using that data would give unreasonable numbers.
I don't know what you're asking.
GPUs don't have an infinite buffer between the VS and PS. By and large a GPU will be near 100% utilization in either geometry/setup or pixel shading, and rarely pushing both simultaneously beyond 50% (which is the threshold at which my assumption breaks down). This is not due to lack of capability; it's just the nature of the workload.
"Portions of the scene" (maybe I should have said 'frame' instead of 'scene'?) refer to a sequence of polys that are limited one way or another. I then classify these portions as either pixel or geometry and add up their processing time. A small percent will be neither, but that's it.
Your math is assuming a setup rate of 16 tesselated triangles per clock, which simply isn't true. Four tris per clock is the maximum usable output of the geometry engine, whether tesselated or not. Take into account that it's closer to 3/clk, and tri:vertex ratio is under 2, it means vertex shading never has to happen faster than 2 per clock.
Mintmaster
Veteran
That's not much of a point.
The fact remains that it's a big bottleneck keeping the shader engines idle over one third of the time.Does it matter? Add up the numbers, invert for framerate, and you'll match the source data perfectly. Again, this is how I broke it down:
Part A - parts of the workload that run twice as fast on the 5870 than on the 5770 (hence the times being twice as long for the latter with this part of the workload)
Part B - parts of the workload that run at the same speed on both the 5870 and the 5770
For the most part, pixel/geometry is pretty apt for A/B. Pixel includes shader, BW, etc because all that is needed for each pixel.
But at least with low amounts of geometry you can lower the resolution (something that I think is overrated) to increase framerate. With high amounts of geometry it doesn't.
Why? Did you not notice that when tesselation was enabled I got larger numbers for the pixel load, too? The breakdown is very reasonable, and there's nothing dubious about it.
That's probably jumping to conclusions. If it processes the geometry limited parts 3.5x as fast and the pixel limited parts 15% faster due to 50% more BW, GF100 will get 1.6x the performance (with tesselation, 12.4ms pixel, 3ms geometry).
Well, I suppose I'd have to look more into the difficulties here, but I would tend to expect that with the limitations placed by tessellation in the first place, there's at least a possibility that this could be extended to tessellated triangles.
However, as a small addendum, let me add that tessellation might actually reduce the problem of having too many very small triangles, because it also allows for lower level of detail for far-away objects. You'd only have more of a problem with small triangles if you use a very high level of detail.
When primitives are rasterized, PS always runs on screen aligned quads. With a huge number of small primitives aligned in all sorts of odd ways, the PS cost/waste adds up pretty quickly. Not to mention that curved surfaces increase the percentage of occluded fragments.
Deferred rendering, does away with all of it.
Your post doesn't address my comment.
