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

[Alex Deucher]

On Fri, Nov 22, 2013 at 8:52 AM, Axel Davy <davy at clipper.ens.fr> wrote:
> 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.
>

We can actually use 1D tiling across all families since R600 IIRC
since the tile size and alignment requirements are not asic dependent.
 Only 2D tiling as family dependencies.

Alex

>
>>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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev