Seni (seniike.delete@this.hotmail.com) on August 1, 2016 12:25 pm wrote:
> Rob Clark (robdclark.delete@this.gmail.com) on August 1, 2016 10:12 am wrote:
> > Rob Clark (robdclark.delete@this.gmail.com) on August 1, 2016 9:44 am wrote:
> > > David Kanter (dkanter.delete@this.realworldtech.com) on August 1, 2016 7:25 am wrote:
> > > > Gionatan Danti (g.danti.delete@this.assyoma.it) on August 1, 2016 3:20 am wrote:
> > > > > The problem with tile based deferred rendering is that both applications
> > > > > and APIs are really meant for immediate mode rendering.
> > > >
> > > > This is a tile-based immediate mode rasterizer. Its not deferred.
> > >
> > > from the PoV of how the driver turns GL api into stuff the hw executes,
> > > tile based deferred and tile based immediate are the same thing.
> > >
> > > http://bloggingthemonkey.blogspot.com/2016/07/dirty-tricks-for-moar-fps.html
> > >
> >
> > hmm, that said, the test program used only seems to do a single draw. You can't really
> > conclude that the gpu is a tiler from that. It is a tiler if draw #1 for tile #2 happens
> > after draw #2 for tile #1. (Regardless of whether it is TBIM or TBDR.)
> >
>
> A tiler splits the screen into separate lock-regions and only
> enforces triangle ordering internally to each region.
>
> The 2nd triangle starts filling before the previous triangle completes.
> From the video, it's pretty clear that this is the case.

This is just how modern immediate mode GPU works. It just schedule tens/hundreds of concurent waves and writes pixels in "triangle order". On GCN you can ignore the triangle order.
http://gpuopen.com/unlock-the-rasterizer-with-out-of-order-rasterization/

Nowadays we have 4+ setup/rasterizers even on mainstream card.