Rob Clark <robdcl...@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.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
