On 04/08/16 19:04, Eric Anholt wrote:
Martin Peres <martin.pe...@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-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759
Tested-by: Fabrice Bellet <fabr...@bellet.info>
Signed-off-by: Martin Peres <martin.pe...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
