[Mesa-dev] [RFC] loader: Automatic PRIME detection

[Axel Davy]

On 02/01/2017 15:32, Thierry Reding wrote:
> On Tue, Dec 27, 2016 at 01:57:21PM +0100, Axel Davy wrote:
>> Hi Thierry,
>>
>> Could you explain why in this situation default_fd would be a non-renderable
>> device node ?
> This is preparatory work to allow drivers for split display/render
> setups to be tied together within Mesa. If you want accelerated
> rendering on those setups, you currently need to patch applications so
> that they can deal with two separate devices (patches exist to allow
> this for Weston and kmscube, and possibly others).
>
> In order to avoid having to patch applications, the renderonly (the name
> is slightly confusing) drivers (Christian Gmeiner sent out patches a few
> weeks ago) open two devices internally and contain some magic to share
> buffers between the two devices.
>
> So the typical use-case would be that you have two separate DRM devices,
> one representing the scanout device and another representing the GPU. In
> most cases the scanout device will be display-only, so it will have a
> /dev/dri/cardX node, but no corresponding /dev/dri/renderDY node. On the
> other hand the GPU will have a "dummy" /dev/dri/cardX node that doesn't
> expose any outputs and a corresponding /dev/dri/renderDY node that is
> used for rendering.
>
> A bare-metal application (kmscube, Weston, ...) will have to find a node
> to perform a modeset with, so it will have to find a /dev/dri/cardX node
> which exposes one or more outputs. That will be the scanout device node.
> But given that there's no render node there's no way to accelerate using
> that device.
>
> Composite drivers will bind to the scanout device node and find a render
> node for the GPU (these are usually ARM SoCs, so it's fairly easy to
> find the correct render node) and bind the GPU driver to that node. Then
> the GPU driver will export buffers used for scanout and have the scanout
> driver import them. That way the application can transparently use those
> buffers for DRM/KMS.
>
>> In my understanding, for X11 DRI3 the Xserver is supposed to give you a
>> renderable device node,
>> and for Wayland, the device path advertised is the one used by the server
>> for compositing.
> Both X11 and Wayland will try to use the device used by the server for
> compositing. In both cases they will receive the /dev/dri/cardX device
> node for the scanout device.
>
> Effectively X11 and Wayland will call back into the scanout driver for
> acceleration. However with a minimal renderonly driver that's not going
> to work. I had posted a complete wrapper driver a long time ago which I
> think could be improved to allow even this use-case to work, but I got
> significant pushback.
>
> Anyway, both X11 and Wayland use the loader_get_user_preferred_fd()
> function that this patch modifies to allow overriding the final file
> descriptor to use. Currently the only way to override is by providing
> the DRI_PRIME environment variable or by setting up a dri.conf
> configuration file.
>
> loader_get_user_preferred_fd() returns a file descriptor (same as the
> default_fd by default, or the one referring to the DRI_PRIME node) and a
> flag that specifies whether or not the devices are the same. This is
> used in order to determine if DMA-BUF or FLINK should be used to share
> buffers.
>
> X11 has special code paths to deal with the PRIME use-case involving an
> extra blit, which is somewhat unfortunate because on many devices that's
> not going to be necessary.
>
> For Wayland the EGL platform code checks for availability of a render
> node to determine whether or not DMA-BUF should be used. That breaks for
> this particular case as well because we do have a cardX node without a
> corresponding renderDY node.
>
> I suspect that with a full wrapper driver this could be solved more
> nicely, including avoiding the extra blit in X11 DRI3. However it's a
> lot more code to maintain than piggy-backing on top of PRIME support,
> and a lot more complicated to get right (and more potential for breaking
> existing use-cases).
>
> Thierry
>
>
 From what you say, I understand the following, please correct if wrong:

Tthe issue is that you need some special format/placement in order to 
display on the screen.

A patch serie was proposed to handle that with some specific handling 
long ago, but received bad comments.

Because a linear buffer is ok to display, you want to force the 
"different device is rendering" path to enforce a copy to a linear 
buffer before presentation.

In the proposed scheme, X11 DRI3 open returns an fd of the device used 
for display (but which cannot render) and Wayland gives the path of the 
device used for display but which cannot be used for rendering.


This seems something that should really be discussed with the devs of 
#xorg-devel and #wayland.


My opinion is that is feels contrary to the spirit of X11 DRI3 to give 
an unusable device fd, and of Wayland to give the path of the device 
used for display by the server instead of the device the server uses for 
rendering.

What you seem to want is some sort of constraints 
format/placement/tiling on the buffers shared with the server (X11 or 
Wayland). There has been several discussions on this topic, and my 
understanding is that some work is being done to have universal 
description for tiling, and have the client reallocate with different 
constraints when the server feels it would be a good idea. If I 
understand for Wayland it could be done via wl_drm, or via some other 
ways. X11 DRI3 can be extended to have similar things.


The proposed patch looks like a hack to me, and I suggest to move to the 
Xorg and Wayland mailing lists to discuss the proper solution.


Yours,


Axel Davy