[Mesa-dev] [PATCH 08/11] GLX/DRI3: Add GPU offloading support.

Michel Dänzer michel at daenzer.net
Mon Jun 23 01:48:19 PDT 2014


On 19.06.2014 12:27, Axel Davy wrote:
> 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.

If X doesn't know anything about the secondary card, the secondary card
must use the server side GLX information from the driver of the primary
card, right? That seems rather hackish to me, and like it can only work
as long as the cards / drivers are 'similar enough'...


Patches 1, 2 and 10 look good to me though FWIW. The radeonsi piglit
multisampling regressions with DRI3 compared to DRI2 can be addressed
later as far as I'm concerned.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer


More information about the mesa-dev mailing list