gallium: Add __DRIimageDriverExtension support to gallium

__DRIimageDriverExtension is used by GLX DRI3 and Wayland.

This patch is a rewrite of
http://lists.freedesktop.org/archives/mesa-dev/2014-May/060318.html
and
http://lists.freedesktop.org/archives/mesa-dev/2014-May/060317.html

Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák<marek.olsak@amd.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>

Previous patches were:
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Makes DRI3 use invalidate.

This doesn't change anything to the intel DRI3 implementation,
but enables the gallium implementation to use dri2.stamp instead
of relying on the stamp shared with the st backend.

Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Loader: Add gpu selection code via DRI_PRIME.

v2: Fix the leak of device_name
v3: Rebased

It enables to use the DRI_PRIME env var to specify
which gpu to use.
Two syntax are supported:
If DRI_PRIME is 1 it means: take any other gpu than the default one.
If DRI_PRIME is the ID_PATH_TAG of a device: choose this device if
possible.

The ID_PATH_TAG is a tag filled by udev.
You can check it with 'udevadm info' on the device node.
For example it can be "pci-0000_01_00_0".

Render-nodes need to be enabled to choose another gpu,
and they need to have the ID_PATH_TAG advertised.
It is possible for not very recent udev that the tag
is not advertised for render-nodes, then
ones need to add a file containing:

SUBSYSTEM=="drm", IMPORT{builtin}="path_id"

in /etc/udev/rules.d/

Signed-off-by: Axel Davy <axel.davy@ens.fr>
drirc: Add string support

Signed-off-by: Axel Davy <axel.davy@ens.fr>
loader: Use drirc device_id parameter in complement to DRI_PRIME

DRI_PRIME is not very handy, because you have to launch the executable
with it set, which is not always easy to do.
By using drirc, the user specifies the target executable
and the device to use. After that the program will be launched everytime
on the target device.

For example if .drirc contains:

<driconf>
    <device driver="loader">
        <application name="Glmark2" executable="glmark2">
            <option name="device_id" value="pci-0000_01_00_0" />
        </application>
    </device>
</driconf>

Then glmark2 will use if possible the render-node of
ID_PATH_TAG pci-0000_01_00_0.

v2: Fix compilation issue
v3: Add "-lm" and rebase.

Signed-off-by: Axel Davy <axel.davy@ens.fr>
DRIimage: add blitImage to the specification

It allows to blit two __DRIimages.

Signed-off-by: Axel Davy <axel.davy@ens.fr>
Gallium/dri2: implement blitImage

V3: call flush_resource before flush
V4: Add new flags

Signed-off-by: Axel Davy <axel.davy@ens.fr>
GLX/DRI3: Add GPU offloading support.

The differences with DRI2 GPU offloading are:
. There's no logic for GPU offloading needed in the Xserver
. for DRI2, the card would render to a back buffer, and
the content would be copied to the front buffer (the same buffers
everytime). Here we can potentially use several back buffers and copy
to buffers with no tiling to share with X. We send them with the
Present extension.
That means than the DRI2 solution is forced to have tearings with GPU
offloading. In the ideal scenario, this DRI3 solution doesn't have this
problem.
However without dma-buf fences, a race can appear (if the card is slow
and the rendering hasn't finished before the server card reads the buffer),
and then old content is displayed. If a user hits this, he should probably
revert to the DRI2 solution (LIBGL_DRI3_DISABLE). Users with cards fast
enough seem to not hit this in practice (I have an Amd hd 7730m, and I
don't hit this, except if I force a low dpm mode)
. for non-fullscreen apps, the DRI2 GPU offloading solution requires
compositing. This DRI3 solution doesn't have this requirement. Rendering
to a pixmap also works.
. There is no need to have a DDX loaded for the secondary card.

V4: Fixes some piglit tests

Signed-off-by: Axel Davy <axel.davy@ens.fr>
Wayland/egl: Add GPU offloading support

This is easier than GLX DRI3 GPU offloading support,
because applications are not allowed to read the front
buffer.

We just need to send to the server buffers it can read,
and for that we use for every back buffer an intermediate
buffer with no tiling to which we copy before sending
the buffer to the compositor.

Signed-off-by: Axel Davy <axel.davy@ens.fr>
Radeonsi: Use dma_copy when possible for si_blit.

This improves GLX DRI3 GPU offloading significantly on CPU
bound benchmarks particularly.
No performance impact for DRI2 GPU offloading.

v2: Add missing tests

Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák<marek.olsak@amd.com>
nvc0: fix dri3 prime buffer creation

We need to place shared buffers into GART.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
GLX: Add an env var to enable the support of GLX extensions needing both client and server support, in case of client support and direct rendering.

In the case of XWayland, there's no accelerated indirect rendering.
For example GLX_ARB_create_context is not advertised by the server,
and according to the spec, we are not allowed to advertise it
to the application because of that.

This env var makes Mesa ignore this restriction, and
a GLX extension is advertised whenever the client supports it.

Signed-off-by: Axel Davy <axel.davy@ens.fr>