[Mesa-dev] [PATCH 0/3] Implement DRI_PRIME support for Wayland

[Axel Davy]

On 11/22/2013 01:16 AM, Kristian Høgsberg wrote:
> I'm not sold on the nested compositor for this use case.  It
> introduces another context switch between the game and the main
> compositor and more input and output lag.  Instead I think we need to
> consider whether we want a new __DRIimage entry point like:
>
>   (*blitImage)(__DRIcontext *ctx, __DRIimage *src, __DRIimage *ctx)
>
> and then do the copy in platform_wayland.c when we have non-matching
> tile-formats.
>
> Kristian
>

Thanks for the comments.

There are advantages to both possibilities:
using a nested compositor or doing the copy inside Mesa.

I imagine doing a blit could be the default,
and rendering directly to the linear buffer could be an option
set by an env var, or driconf.

I'm deeply convinced we should allow to render to the linear
buffer without copy, and the nested compositor use-case makes sense.

For the blit, a function

(*blitImage)(__DRIcontext *ctx, __DRIimage *src, __DRIimage *dst)

makes sense, but we would need another function
(not related specifically to Prime):

(*throttle) (__DRIcontext *ctx)

Because rendering something heavy on non-intel card (intel cards to
throttling automatically)
cause input lag (and It is solved by forcing throttling at every swap).

And ideally, we could have more control on tiling,
for example if the computer has two AMD cards of the same
generation with same tiling modes, we could always use tiling.


>I would like the compositor to still send the classic drm device in
>the wl_drm.device event.  The client can then use stat(2) to stat it
>and defer the corresponding render node from that by adding 128 to the
>minor.  This way we don't break older mesa versions by sending them a
>render node that they'll then fail to authenticate.

I do not agree on this: if the compositor does run under a render-node,
there are high chances it can't authenticate clients wanting to run
on the not-render-node device.
Moreover, I believe clients shouldn't use render-nodes by default if
they can avoid it.

I don't get the point of older mesa versions: why would you use an older
Mesa version inside a more recent Mesa version?


Some arguments in favor of allowing the nested compositor case to render
without copy
on another card:

. XWayland inside would run as if the main device is the device of the
nested compositor. (I can't say how X dri3 will support Prime, so I
can't say yet if this is a big advantage or not). For example if Xrender is
slow on the main card, you can with this system use Xrender on the other
card.

. In case you are under system compositors (like would KWin), you would
like to be able to render your whole desktop on the card you want,
without an additional copy.
. We could imagine having outputs on different card, the compositor
under system compositors would connect to multiple system compositors
running on each card (and giving access to different outputs). The
compositor would use card X: the system compositor on card X would have
tiled buffers without copies, whereas the other system compositors would
have untiled buffers without copies.

. The nested compositor could allow the user to choose between capping
the compositing to 60 fps
or not. When we would cap the compositing to 60 fps, we would avoid some
useless copies (while adding a very small latency between when the frame
is sent and when it is displayed)

(. The nested compositor could have additional features like recording
using the acceleration of the other card )

All these arguments can be put in short in: "more flexibility"


For an heavy game < 60 fps, I agree it makes much more sense to do the
copy inside Mesa, than using a nested compositor.


Axel Davy