[Mesa-stable] [Mesa-dev] [PATCH] i965: import prime buffers in the current context, not screen

[Martin Peres]

On 04/08/16 19:04, Eric Anholt wrote:
> Martin Peres <martin.peres at linux.intel.com> writes:
>
>> This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and
>> fixes many applications when using DRI3:
>>   - Totem with libva on hw-accelerated decoding
>>   - obs-studio, using Window Capture (Xcomposite) as a Source
>>   - gstreamer with VAAPI
>>
>> Cc: mesa-stable at lists.freedesktop.org
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759
>> Tested-by: Fabrice Bellet <fabrice at bellet.info>
>> Signed-off-by: Martin Peres <martin.peres at linux.intel.com>
>> ---
>>
>> I have been testing the patch on my main desktop for a day and did not
>> encounter any issue with it. This is however quite a corner case and
>> most people never had this issue anyway.
>>
>> If this patch is not accepted, then we will need to change the loader's
>> GetBuffers() method so as it either does not import the buffers or takes
>> the context as a parameter.
> Not sure if you've seen, but the gallium drivers are doing an fstat on
> the DRM fd, hashing the st_dev/st_ino/st_rdev, and reusing an existing
> screen when it matches.  This might be really useful for Intel, too.

Thanks, I did not know this :)

This is sort of what the first patch in bugzilla was proposing but it 
won't work when mixing DRI2 and DRI3 because they use different nodes on 
xf86-video-intel (not on modesetting, both use card0) and thus, we still 
cannot guarantee that an application will have only one bufmgr per GPU. 
However, it would still reduce the number of buffer managers, which is 
likely a good idea.

I could also do this in mesa, since this is where sharing buffers 
between contexts is actually happening. It still feels like a workaround 
though to rely on this. Not that this fix also feels like a workaround, 
but it is a workaround for the API of the DRI3 loader.