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.

 src/mesa/drivers/dri/i965/intel_screen.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index ae51c40..169d578 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -702,8 +702,11 @@ intel_create_image_from_fds(__DRIscreen *screen,
                             int *fds, int num_fds, int *strides, int *offsets,
                             void *loaderPrivate)
 {
+   GET_CURRENT_CONTEXT(ctx);
    struct intel_screen *intelScreen = screen->driverPrivate;
+   struct brw_context *brw = brw_context(ctx);
    struct intel_image_format *f;
+   dri_bufmgr *bufmgr;
    __DRIimage *image;
    int i, index;
 
@@ -744,8 +747,26 @@ intel_create_image_from_fds(__DRIscreen *screen,
          size = end;
    }
 
-   image->bo = drm_intel_bo_gem_create_from_prime(intelScreen->bufmgr,
-                                                  fds[0], size);
+   /* Let's import the buffer into the current context instead of the current
+    * screen as some applications like gstreamer, totem, or obs create multiple
+    * X connections which end up creating multiple screens and thus multiple
+    * buffer managers. They then proceed to use a different X connection than
+    * the one used by the currently-bound context to call GLXBindTexImageExt()
+    * which should then import the buffer in the current bound context and not
+    * the current screen. This is done properly upstairs for texture management
+    * so we need to mirror this behaviour if we don't want the kernel rejecting
+    * our pushbuffers as the buffer would not have been imported by the same
+    * buffer manager that sent the pushbuffer referencing it.
+    *
+    * If there is no context currently bound, then revert to using the screen's
+    * buffer manager and hope for the best...
+    */
+   if (brw)
+       bufmgr = brw->bufmgr;
+   else
+       bufmgr = intelScreen->bufmgr;
+
+   image->bo = drm_intel_bo_gem_create_from_prime(bufmgr, fds[0], size);
    if (image->bo == NULL) {
       free(image);
       return NULL;
-- 
2.9.2

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to