[Mesa-dev] [PATCH 4/4] xa: reuse surfaces

[Rob Clark]

On Wed, Apr 2, 2014 at 2:05 PM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
> On 04/02/2014 04:40 PM, Rob Clark wrote:
>> On Wed, Apr 2, 2014 at 3:47 AM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
>>> On 04/01/2014 05:04 PM, Rob Clark wrote:
>>>> From: Rob Clark <robclark at 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...

yup, that looks like it should do the trick.. I'll give it a try shortly..

BR,
-R

> /Thomas
>
>
>
>