[Mesa-dev] [PATCH] gallium/swrast: fix front buffer blitting. (v2)

[Dave Airlie]

On 8 November 2015 at 02:47, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hi Dave,
>
> On 9 October 2015 at 01:38, Dave Airlie <airlied at gmail.com> wrote:
>> From: Dave Airlie <airlied at redhat.com>
>>
>> So I've known this was broken before, cogl has a workaround
>> for it from what I know, but with the gallium based swrast
>> drivers BlitFramebuffer from back to front or vice-versa
>> was pretty broken.
>>
>> The legacy swrast driver tracks when a front buffer is used
>> and does the get/put images when it is mapped/unmapped,
>> so this patch attempts to add the same functionality to the
>> gallium drivers.
>>
>> It creates a new context interface to denote when a front
>> buffer is being created, and passes a private pointer to it,
>> this pointer is then used to decide on map/unmap if the
>> contents should be updated from the real frontbuffer using
>> get/put image.
>>
>> This is primarily to make gtk's gl code work, the only
>> thing I've tested so far is the glarea test from
>> https://github.com/ebassi/glarea-example.git
>>
>> v2: bump extension version,
>> check extension version before calling get image. (Ian)
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91930
>>
>> Signed-off-by: Dave Airlie <airlied at redhat.com>
> Seems that you've added the mesa-stable tag just prior to pushing.
>
> Thus as I picked it up was welcomed by some 200 regressions (and three
> front buffer rendering fixes) on softpipe and for llvmpipe
> hiz-depth-test-window-stencil1 was consistently going into a deadloop,
> and killing it was dragging down the whole piglit run :(
> Are you seeing a similar thing or there is something funny with my setup ?
>
> I've removed the patch from the queue for now, and if we cannot
> resolve the regressions I will have to drop it from 11.0.

Drop it for now. threads and xlib fun by the looks of it. I'll have to
revisit asap.
I've disabled it upstream for llvmpipe for now.

Dave.