Currently Gpu offloading is supported only with GLX DRI2.
You need to set it up with xrandr, and you need a DDX loaded for
the secondary device, even if it has no screen.
You use the DRI_PRIME env var to set up which Gpu the application
should use. Unfortunately it has some issues: Rendering to a pixmap
is unsupported, and you need either to be fullscreen, or to be in a
composited environment to not get a black content.
These patches add Gpu offloading support to GLX DRI3 and EGL Wayland.
Most of the limitations mentioned above are adressed.
The first three patches add the __DRIimageDriverExtension support
to gallium. It is needed for GLX DRI3 and to use a render-node
for EGL Wayland.
The next three patches add to Loader the support needed to change the
device EGL Wayland or GLX DRI3 would use, if the user specifies
another device via DRI_PRIME or via drirc device_id.
For example if drirc contains:
<driconf>
<device driver="loader">
<application name="Glmark2" executable="glmark2-wayland">
<option name="device_id" value="pci-0000_01_00_0" />
</application>
</device>
</driconf>
Then glmark2-wayland will use if possible the render-node of
ID_PATH_TAG pci-0000_01_00_0.
The ID_PATH_TAG of a device is filled by udev, and you can
get it with the command:
"udevadm info /dev/cardX"
DRI_PRIME can be set both to "1" (meaning 'another device
than the server') or to the ID_PATH_TAG.
If render-nodes are not enabled, or if the indicated device doesn't
exist, the server device is used.
There is no need to have a DDX loaded for the device we want to use,
nor you need to configure something with xrandr.
Two patches add blitImage specification and implementation to
gallium. It enables to blit two __DRIimage together.
The GLX DRI3 Gpu offloading implementation allows to render to a pixmap,
and will get in sync the back and front buffer with copies. There is no
need to be in a composited environment.
The last patch allows blitImage to use dma copy on radeonsi.
It gives a performance boost, especially in cpu limited benchmarks.
This makes for these cards Gpu offloading faster for DRI3 than for
DRI2.
Nouveau already has an optimised blitImage path because it uses
the 2D engine to copy.
Currently no official DDX release supports DRI3.
It's, I think, mainly because the Present DDX side API makes
it difficult to implement. If the DDX doesn't support Present,
the Xserver uses a fallback with copies. When rendering on the server
card, it's worse performance than Dri2, but since the copy is on the
server card, it won't affect the performance of Gpu offloading.
One proposition would be to add basic DRI3 support to the DDXs (without
Present support for now), but Mesa would use it only when DRI2 fails,
or if we want to use DRI3 Gpu offloading.
Axel Davy (8):
Loader: Add gpu selection code via DRI_PRIME.
drirc: Add string support
loader: Use drirc device_id parameter in complement to DRI_PRIME
DRIimage: add blitImage to the specification
Gallium/dri2: implement blitImage
GLX/DRI3: Add Gpu offloading support.
Wayland/egl: Add Gpu offloading support
Radeonsi: Use dma_copy when possible for si_blit.
Ben Skeggs (1):
gallium/dri: fix unsetting of format when encountering depth/stencil
Keith Packard (2):
gallium: Add __DRIimageDriverExtension support to gallium
gallium: Use base.stamp for all drawable invalidation checks.
include/GL/internal/dri_interface.h | 11 +-
src/Makefile.am | 4 +-
src/egl/drivers/dri2/egl_dri2.h | 5 +-
src/egl/drivers/dri2/platform_wayland.c | 171 ++++++++++---
src/gallium/drivers/radeonsi/si_blit.c | 15 ++
.../state_trackers/dri/common/dri_drawable.c | 4 +-
src/gallium/state_trackers/dri/drm/dri2.c | 281 ++++++++++++++++++++-
src/glx/dri3_glx.c | 235 ++++++++++++++---
src/glx/dri3_priv.h | 2 +
src/loader/Makefile.am | 21 +-
src/loader/loader.c | 215 ++++++++++++++++
src/loader/loader.h | 7 +
src/mesa/drivers/dri/common/xmlconfig.c | 29 +++
src/mesa/drivers/dri/common/xmlconfig.h | 9 +-
src/mesa/drivers/dri/common/xmlpool/t_options.h | 14 +
15 files changed, 933 insertions(+), 90 deletions(-)
--
1.9.1
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
