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.

I guess the article describes it as tile based rasterization.. to me that sounds more like clever thread scheduling than actual tiled rendering (ie. where you execute draws 0..N for one tile, and then again for next tile and so on). Perhaps just semantics.