High geometry also allows really cool displacement mapping effects. Tessellation is a great way to get that geometry in there for more detail, shadowing, and smooth edges. There are also some effects than can only be done with more geometry. This requires extra work from both artists and programmers and costs a good bit in terms of performance.
Currently, artists need to create different versions of their objects for different LODs (Level of Detail - reducing or increasing complexity as the object moves further or nearer the viewer), and geometry simulation through texturing at each LOD needs to be done by pixel shaders. Now don't let this technical assessment of fixed function tessellation make you think we aren't interested in reaping the benefits of the tessellator. The majority of tasks will continue to be enabled in a flexible programmable way, and in the future we may see more flexibility introduced into the tessellator until it becomes fully programmable as well (or ends up just being merged into some future version of the Geometry Shader). This doesn't mean we'll start to see a renaissance of fixed function blocks in our graphics hardware just that significantly advanced features going forward may still require the sacrifice of programability in favor of early adoption of a feature. But the reason it makes sense is that the ROI (return on investment: what you get for what you put in) on those transistors is huge if developers do take advantage of the hardware: it's much easier to get huge tessellation performance out of a fixed function tessellator than to put the necessary resources into the Geometry Shader to allow it to be capable of the same tessellation performance programmatically. We do still have the problem that all the transistors put into the tessellator are worthless unless developers take advantage of the hardware. But that doesn't mean that fixed function hardware doesn't have it's place. This made a shift toward architectures where expanding the pool of compute resources that could be shared and used for many different tasks became a much more attractive way to go. The transistors put into specialized hardware just go unused if developers don't program to take advantage of it. As time went on, it became clear that adding in more fixed function hardware to graphics chips just wasn't feasible. In the beginning, fixed function was necessary to get the desired performance. The argument between fixed function and programmable hardware is always one of performance versus flexibility and usefulness. So while most everything has been moving towards programmability in the rendering pipe, we have sort of a step backward here. The Geometry Shader is the programmable block in the pipeline that is capable of tessellation as well as much more, but it just doesn't have the power to do tessellation on any useful scale.
Sure, the input to and output of the tessellator can be manipulated a bit through the Hull Shader and Domain Shader, but the heart of the beast is just not that flexible. Or is it really progressive? The tessellator itself is fixed function rather than programmable. We still aren't sold on the need for a tessellator on the desktop, but who's to argue with progress? Adding fixed function hardware to quickly and efficiently handle a task that improves memory footprint has major advantages in the living room. AMD jumped on the tessellation bandwagon long ago, and perhaps it does make sense for consoles like the XBox 360.
Microsoft and AMD tend to get the most excited about tessellation whenever the topic of DX11 comes up. Tessellation: Because The GS Isn't Fast Enough
0 kommentar(er)
