These patches can be divided in three parts: . Implement DRI_PRIME support for Wayland (patch 1) It is the v2 of the series here: http://lists.freedesktop.org/archives/mesa-dev/2013-November/047946.html
. Use drirc for choosing the gpu to use without using the DRI_PRIME env var. (patch 2 and 3) Using drirc instead of DRI_PRIME avoids the use of scripts or the console to launch an application with Prime. . When on a different device, instead of rendering to a linear buffer, have a mode to render to a tiled buffer, and copy to a linear buffer. (patch 4,5,6) While patch 1 is ready, I post patches 2-6 to get comments. They add new functionnalities that can be added afterward. With patch 1, you can use DRI_PRIME to use another device to render. DRI_PRIME="1" means 'choose any other device than the one of my compositor' but you use the ID_PATH_TAG udev field to choose the device to use. More explanation can be found with my last patch series. Since you render to a linear buffer (to share the content with another gpu), in order to get good performance, you have to: . launch an embedded Wayland compositor on the other card (with DRI_PRIME env var) . launch your applications inside. That way the applications render to a tiled buffer, and the compositor does a copy to a linear buffer. Instead of relying on DRI_PRIME, it is much more handy to tell to drirc that you always want your embedded compositor to run on the other card. Patches 2 and 3 introduce this possibility. But to totally avoid the embedded compositor, but still get good performance, you should integrate the copy that the embedded compositor does to egl. That's the goal of patches 4, 5, 6. Unfortunately, dma-buf fences are not ready yet: you get glitches if a card read a buffer made by another card, but whose rendering has not finished. That's why a flag is added to the blit function introduced, to finish the rendering before we commit the buffer to the compositor. This entirely removes the glitches, but has a severe performance hit. Ideally, the commit should be delayed until the blit is finished (and the application would continue rendering), and it is kind of what the embedded compositor does in the way to use prime introduced by patch 1. The comments I would like to get are: patch 2: would driconf work with this change? patch 3: drirc is not used like that outside of this patch. Is this acceptable to use drirc like that? Could there be some issues? patch 4: what are the alternatives to set a __BLIT_FLAG_FINISH flag here? But other comments are welcome! Axel Davy (6): EGL/Wayland: DRI_PRIME support drirc: Add string support EGL/Wayland drirc: Use drirc to complement DRI_PRIME DRIimage: add blitImage to the specification Gallium/dri2: implement blitImage EGL/Wayland: Use the DRIImage blit function (when available) for Prime configure.ac | 1 + include/GL/internal/dri_interface.h | 21 +- src/egl/drivers/dri2/Makefile.am | 12 + src/egl/drivers/dri2/egl_dri2.c | 5 + src/egl/drivers/dri2/egl_dri2.h | 3 + src/egl/drivers/dri2/platform_wayland.c | 366 +++++++++++++++++++++--- src/gallium/state_trackers/dri/drm/dri2.c | 49 +++- src/mesa/drivers/dri/common/xmlconfig.c | 24 ++ src/mesa/drivers/dri/common/xmlconfig.h | 7 +- src/mesa/drivers/dri/common/xmlpool/t_options.h | 5 + 10 files changed, 446 insertions(+), 47 deletions(-) -- 1.8.3.2 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev