Dio said:If the pipeline doesn't have logic in to sort out overlapping read/writes, then it is faulty. Essentially, each pixel has to be 'checked out' and 'checked in' - it can't be read if it's checked out. Therefore, overlapping rendering generates pipeline bubbles, not incorrect rendering.DemoCoder said:Of course, given that 8 concurrent pixels are being evaluated, and that the order of evaluation is not guaranteed during rasterization, it's probably of no use anyway since if you try to smple read from a framebuffer pixel, it could have either not been evaluated yet, is currently being evaluated by a neighboring pipeline, has been evaluated but not written over by an occluder (yet), or has been evaluated but written over by an occluder, etc.
It's not the issue of overlapping writes, the the issue of not being guaranteed an evaluation order. If I write a pixel shader and I try to utilize the value of the pixel that is to the left of the current pixel as a piece of dependent data, I can't be guaranteed the state of that pixel.
Imagine trying to use the frame buffer to compute a fibonacci sequence, but reading the two frame buffer pixels before you, and using that to output the current pixel.
So what's the use trying to read from the current framebuffer you are rendering to? It breaks the stateless model of no-interdependencies between the pipelines.