By: steve m (steve.marton.delete@this.gmail.com), May 17, 2017 8:35 pm
Room: Moderated Discussions
Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on May 17, 2017 5:43 am wrote:
> steve m (steve.marton.delete@this.gmail.com) on May 16, 2017 11:49 am wrote:
> Possibly load-balancing to prevent keeping the rasterizers from being idle while the pixels in the previous
> tile are being shaded. If the L2 can hold two tiles at the same time then it should be fine.
Yeah I still don't quite understand. Why not keep the same rasterizers busy filling in holes for the current tile? Why dispatch pixel shaders to future tiles, and finish them, all the way through ROP, when you still have holes in your earlier tile? Shouldn't your rasterizer prioritize pixels in the current tile first? It seems that the rasterizer has dispatched pixel shader work to future tiles before it finished dispatching the first tile. Or the work queue was not consumed in the intended order (the left hand doesn't know what the right is doing?).
The cache is a shared resource. Sure, more tiles will fit, but you don't want to thrash it unnecessarily, because you'll be slowing down your texture units and everything else.
I don't see why you would NOT want to dispatch and process all pixel work in a tile before you start dispatching the next tile. If you did that, presumably the work would be done in a much cleaner progression by tile, rather than what we're seeing in the video. Of course there would be some bleed between tiles, but I especially don't see any reason to get more than one tile ahead. I mean, the rasterizer output queue has no reason to be THAT big, does it?...
> steve m (steve.marton.delete@this.gmail.com) on May 16, 2017 11:49 am wrote:
> Possibly load-balancing to prevent keeping the rasterizers from being idle while the pixels in the previous
> tile are being shaded. If the L2 can hold two tiles at the same time then it should be fine.
Yeah I still don't quite understand. Why not keep the same rasterizers busy filling in holes for the current tile? Why dispatch pixel shaders to future tiles, and finish them, all the way through ROP, when you still have holes in your earlier tile? Shouldn't your rasterizer prioritize pixels in the current tile first? It seems that the rasterizer has dispatched pixel shader work to future tiles before it finished dispatching the first tile. Or the work queue was not consumed in the intended order (the left hand doesn't know what the right is doing?).
The cache is a shared resource. Sure, more tiles will fit, but you don't want to thrash it unnecessarily, because you'll be slowing down your texture units and everything else.
I don't see why you would NOT want to dispatch and process all pixel work in a tile before you start dispatching the next tile. If you did that, presumably the work would be done in a much cleaner progression by tile, rather than what we're seeing in the video. Of course there would be some bleed between tiles, but I especially don't see any reason to get more than one tile ahead. I mean, the rasterizer output queue has no reason to be THAT big, does it?...
