Frame Buffer Access in the Pixel Shader

There are often times when you’d like to append some calculations to an image, such as for digital grading, color correction, and/or tone mapping. With DirectX 9, however, you can not read the current value of the pixel you’re overriding on the frame buffer because for most immediate mode renderers, there’s no way of guaranteeing that the value has even been written yet. In practice, however, most graphics processors and drivers work fine when you read from the same texture that you’re rendering to; but because this is undefined behavior, it’s liable to break at any moment and hence developers are urged to not rely on this functionality. The alternative is to use two separate textures and alternate between the two, consuming twice as much memory. With DirectX Next, developers are finally getting the functionality they’ve been requesting for years now – direct access to the frame buffer (current pixel only) inside the pixel shader – maybe. Just because it’s now in the cards for DirectX Next doesn’t mean that it’s not still a problem for immediate mode renderers, and apparently vendors of said renderers are requesting for this feature to be dropped from the spec. Most likely this will end up being one of many optional features, which, unfortunately, means most developers are probably going to have to completely ignore it and do things the old way.

Had it been mandatory, however, you’d be able to do almost everything the current fixed function blenders do (such as accumulating lighting contributions from many lights in the frame buffer) completely in the pixel shader, without the overhead of an additional render target. In fact, it’s quite possible that some hardware vendors would’ve dropped their fixed function blenders and instead opted to emulate the functionality through pixel shading in much the same way that ATI dropped fixed function vertex processing and instead emulate the same functionality through vertex shaders. This would’ve meant there’d be more room in the transistor budget to improve those shader units and make everything a bit faster. It should be noted that tile-based deferred renderers have none of the problems that immediate mode renderers do in this department, so you can still bet on support from those hardware venders.

Conclusion

In fact, many of the major DirectX Next changes seem to be a perfect fit for tile-based deferred renderers. The new memory management model, which allows virtually unlimited resources, also allows the implementation of virtually unlimited geometry storage, which has always been a concern for the deferred rendering implementations. Access to current frame buffer values from the pixel shader is also very easy to do on a tile-based deferred renderer since all the data is already in the on-chip tile buffer. So there are no costly external memory accesses required or expensive pipeline and back-end cache flushes. The front-end changes to the vertex/geometry shader side are independent of the tile-based deferred rendering principle and are thus not as big of a problem to support on tile-based deferred renderers as they are for immediate mode renderers. It will indeed be very interesting to see whether PowerVR, who has been laying pretty low lately, will take this opportunity to put out a really awesome DirectX Next implementation.

It will also be fairly interesting to see exactly how the proposed features develop – it’s unclear, for example, where exactly in the pipeline the topology processor will reside. It has also yet to have been determined whether or not the new tessellator will be programmable, highly configurable, or simply purely fixed function.

Since the API is still in an extremely infantile state, much of this probably will not be known for some time, and much of what was discussed in this article will probably undergo several changes or be completely scrapped; but all in all the next few years of real-time computer graphics should prove to be quite interesting.

Special Thanks

A big “thank you” goes out to Dave Baumann, Conor Stokes and anyone else who provided input – thanks, guys. ?