On Thu, May 19, 2016 at 6:21 PM, Eric Anholt <e...@anholt.net> wrote: > 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.
ok, yeah, I guess that solves the naming conflict (fd_batch(_state) sounds nicer for what it's purpose really is than fd_framebuffer_state) BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev