Overall, I think people would have been less happy about the product. For example, we might have had 10% slower 3D performance, or we might have had to remove a 3D feature to make up for it. If we had spared a bunch of transistors for accumulation buffering, there would be a tradeoff. Maybe it’s a feature you want, but you have to have realistic expectations about our product design cycle, and we can’t satisfy everyone. If we had wanted to put accumulation buffering in it, we would have needed to decide that more than 2 years ago! The justification is pretty clear: supporting accumulation buffering would take quite a bit of effort, the technique would still be too slow for many real-time applications, there are no significant apps shipping now or any time in the next year that use the accumulation buffer, and no major developers are requesting it.Īnd further, remember that the GeForce architecture has been shipping for well over a year. In this particular case, we made the same decision everyone else did. The decisions behind what we decide to put in HW are complicated, and even when I do have influence, there is a 12-month lead time on anything I suggest showing up in a shipping product, sometimes much longer. The effectiveness of this technique depends on your scene, and it does cost precision, but it’s often a good way of getting a “good enough” approximation.

For example, you can draw an object using ONE/ONE blending four times at 1/4 the usual brightness to get a motion blur effect on a dark background. If you want a cheap approximation of the same kinds of effects, you also have the option of using blending. It’s much cheaper to have a 4-sample buffer and render 4 times into it, then do a single filter operation, than to have a high-precision buffer, render 4 times, do 4 fancy blends, and then still have to copy back to the main framebuffer. When you start adding up what it would take to implement it in HW, it’s pretty obvious why hacks like the T-buffer exist. 4 multipliers and 4 shifters would help, but you’re starting to talk about a fairly big unit then, more than anyone can afford to build into a consumer 3D chip.

Even then you’ll have an accumulation rate of 1 pixel per 4 clocks because you need to accumulate R, G, B, and A. It consumes huge amounts of memory, it uses tons of bandwidth and fill (you have to draw many times, and the accumulation operations may require a read from a 32-bit buffer and a read-modify-write on a 64-bit buffer), and you need, at the bare minimum, a pipelined 16x16 multiplier and a barrel shifter to implement it.

It is definitely an ultra-high-end OpenGL feature. Accumulation buffering requires 16-bit-per-channel precision (it’s not strictly required, but it is generally expected) and a signed buffer. Correct, it is a lot more than we can do with our 2D engine.

Accumulation buffer opengl es 2.0