On Wed, Apr 2, 2014 at 2:05 PM, Thomas Hellstrom <thellst...@vmware.com> wrote: > On 04/02/2014 04:40 PM, Rob Clark wrote: >> On Wed, Apr 2, 2014 at 3:47 AM, Thomas Hellstrom <thellst...@vmware.com> >> wrote: >>> On 04/01/2014 05:04 PM, Rob Clark wrote: >>>> From: Rob Clark <robcl...@freedesktop.org> >>>> >>>> Otherwise it will trick the gallium driver into thinking that the render >>>> target has actually changed (due to different pipe_surface pointing to >>>> same underlying pipe_resource). This is really badness for tiling GPUs >>>> like adreno. >>> Rob, if we want to cache gallium surfaces like this, we need to >>> condition it on the same context being used. >>> We can't reuse a surface created with one context for rendering with >>> another context. (I know the mesa state tracker needs to >>> fix this up as well). >> oh.. ugg.. do we have any cases where multiple XA contexts are used? >> Or could we take the easy way out and somehow forbid that? > > Hmm. It was designed around the idea of multiple XA contexts so if at > all possible I think we should > continue to allow that.. > >> >>> While this can be done easily within XA for non-shared xa_surfaces, I >>> wonder what happens in the case of >>> shared xa_surfaces? More specifically, is rendering allowed to be cached >>> in the gallium surface until explicitly flushed to the texture? (I'm >>> unsure about gallium surface semantics here). >> I'm not quite sure either. I need to flush rendering whenever the >> render target actually changes (I'm just trying to prevent flushing >> when the render target doesn't change, but only the pipe_surface ptr >> does). If you are using that surface as a texture, then presumably >> you needed to change the render target. >> >> I'm less sure about other drivers. >> >> I suppose a different approach would simply be to cache the most >> recent pipe_surface. So whenever the render target does actually >> change, we create a new pipe_surface. But we avoid creating a new >> surface for the same render target when it doesn't change. >> >> BR, >> -R >> >> > > Something along the line of the attached patch? That would keep a > reference on the destination surface until context destruction, but I > guess the driver would do that anyway, since it's a render target...
Seems to do the job.. I got one segfault in my emit_textures() code (which I've not managed to reproduce yet).. but I guess that is unrelated, the refcnt'ing in this patch looks correct. BR, -R > /Thomas > > > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
