[Freedreno] tilers and out-of-order rendering..

[Eric Anholt]

Rob Clark <robdclark at gmail.com> writes:

> So some rendering patterns that I've seen in apps turn out to be
> somewhat evil for tiling gpu's.. couple cases I've seen:
>
> 1) stk has some silliness where it binds an fbo, clears, binds other
> fbo clears, binds previous fbo and draws, and so on.  This one is
> probably not too hard to just fix in stk.
>
> 2) I've seen a render pattern in manhattan where app does a bunch of
> texture uploads mid-frame via a pbo (and then generates mipmap levels
> for the updated texture, which hits the blit path which changes fb
> state and forces a flush).  This one probably not something that can
> be fixed in the app ;-)
>
> There are probably other cases where this comes up which I haven't
> noticed yet.  I'm not entirely sure how common the pattern that I see
> in manhattan is.
>
> At one point, Eric Anholt mentioned the idea of tracking rendering
> cmdstream per render-target, as well as dependency information between
> these different sets of cmdstream (if you render to one fbo, then turn
> around and sample from it, the rendering needs to happen before the
> sampling).  I've been thinking a bit about how this would actually
> work, and trying to do some experiments to get an idea about how
> useful this would be.

My plan was pretty much what you laid out here, except I was going to
just map to my CL struct with a little hash table from the FB state
members since FB state isn't a CSO.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/freedreno/attachments/20160519/8f4f27a3/attachment.sig>