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

[Thomas Hellstrom]

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...

/Thomas




-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-st-xa-Cache-render-target-surface.patch
Type: text/x-patch
Size: 1956 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140402/7f4e44e2/attachment.bin>