Graphics developers need to know this stuff because certain operations can be very, very expensive on tile-based deferred renderers. Things like reading from the framebuffer, for example. On an immediate mode renderer, the GPU just has to queue up a DMA. On a tile-based deferred renderer, the previous commands have to be flushed first. And these differences are part of the motivation for new APIs like Metal and Vulkan.
Reading from the frame buffer is, in general, extremely cheap on TBDR architectures, not expensive. The frame buffer for the current render is stored in tile memory which is fast to access. Accessing the frame buffer with an immediate mode renderer will involve a load from main/global memory.
I think I was a bit ambiguous. I was imagining something like glReadPixels() with a PBO target, which won't work unless all of the tiles have been rendered, but is just a DMA or pack operation in an immediate mode renderer.
glReadPixels() forces you to synchronise with the CPU at the point you call it, and stops the driver from carrying on with further GL commands until it completes. Doesn't matter what you're rendering to. So even if it's cheap on the GPU, it stops the driver making forward progress which could be very beneficial to performance.
Really? I thought that was the whole point of reading into a PBO, that you're not synchronizing with the CPU yet, and you read from the PBO into system memory at some later point.
Graphics developers need to know this stuff because certain operations can be very, very expensive on tile-based deferred renderers. Things like reading from the framebuffer, for example. On an immediate mode renderer, the GPU just has to queue up a DMA. On a tile-based deferred renderer, the previous commands have to be flushed first. And these differences are part of the motivation for new APIs like Metal and Vulkan.