2015-10-08 13:26 GMT+08:00 Ian Romanick <i...@freedesktop.org>:
> On 10/07/2015 08:05 PM, Dave Airlie wrote:
>> From: Dave Airlie <airl...@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
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91930
>>
>> Signed-off-by: Dave Airlie <airl...@redhat.com>
>> ---
[snip]
>> static const __DRIswrastLoaderExtension swrastLoaderExtension = {
>> .base = {__DRI_SWRAST_LOADER, 2 },
>
> Doesn't this need to get changed to 3? And shouldn't something,
> somewhere check that version? What happens if you use a newer
> swrast_dri.so with an older libGL.so? And vice versa?
>
Our EGL also defines its own swrastLoader in several platforms. The
current form will surely break EGL even if swrast_dri.so and libEGL.so
are the same version.
Regards,
Boyan Ding
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
