Re: [git pull] drm for 5.8-rc1

From: Daniel Vetter <daniel@ffwll.ch>
To: Daniel Stone <daniel@fooishbar.org>
Cc: Karol Herbst <kherbst@redhat.com>,
	James Jones <jajones@nvidia.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Thierry Reding <treding@nvidia.com>
Subject: Re: [git pull] drm for 5.8-rc1
Date: Fri, 14 Aug 2020 19:25:17 +0200	[thread overview]
Message-ID: <CAKMK7uFsTP-tN49SKJhm9w49EF3Ars0c1bF4=iUrEtKHCLzCTg@mail.gmail.com> (raw)
In-Reply-To: <CAPj87rMXXTNntwYk=58tVRRkjvYJb-+a=bnzJZjWJv21v_+7KQ@mail.gmail.com>

On Fri, Aug 14, 2020 at 7:17 PM Daniel Stone <daniel@fooishbar.org> wrote:
>
> Hi,
>
> On Fri, 14 Aug 2020 at 17:22, Thierry Reding <thierry.reding@gmail.com> wrote:
> > I suspect that the reason why this works in X but not in Wayland is
> > because X passes the right usage flags, whereas Weston may not. But I'll
> > have to investigate more in order to be sure.
>
> Weston allocates its own buffers for displaying the result of
> composition through GBM with USE_SCANOUT, which is definitely correct.
>
> Wayland clients (common to all compositors, in Mesa's
> src/egl/drivers/dri2/platform_wayland.c) allocate with USE_SHARED but
> _not_ USE_SCANOUT, which is correct in that they are guaranteed to be
> shared, but not guaranteed to be scanned out. The expectation is that
> non-scanout-compatible buffers would be rejected by gbm_bo_import if
> not drmModeAddFB2.
>
> One difference between Weston and all other compositors (GNOME Shell,
> KWin, Sway, etc) is that Weston uses KMS planes for composition when
> it can (i.e. when gbm_bo_import from dmabuf + drmModeAddFB2 from
> gbm_bo handle + atomic check succeed), but the other compositors only
> use the GPU. So if you have different assumptions about the layout of
> imported buffers between the GPU and KMS, that would explain a fair
> bit.

Yeah non-modifiered multi-gpu (of any kind) is pretty much hopeless I
think. I guess the only option is if the tegra mesa driver forces
linear and an extra copy on everything that's USE_SHARED or
USE_SCANOUT.

> > Perhaps we can go and release X 1.21.0 with that modifier enablement
> > patch and that'll motivate desktops to adopt it as well as the default?
>
> Unfortunately we don't really have a good way out of this one. They
> were disabled because the non-modifier path on Intel can be linear or
> X-tiled (row-major), whereas the modifier path enables Y-tiled
> (column-major) and compressed layouts. Y-tiled is the most efficient,
> but Intel could only spare about six transistors for the global FIFO
> shared between all their plane fetch engines, and Y-tiled blows
> straight through it. Both X and Shell would thus fail to enable high
> resolutions or many heads (2x 4K is enough even on modern platforms
> IIRC), so they just turned modifiers off.
>
> The best solution would be to do a global atomic_check across all
> outputs and just blacklist modifiers until you find one which works,
> but Shell doesn't yet have that code, and -modesetting ... well,
> no-one's volunteered to do that yet, or probably ever.

Yeah best bet for modifiered X is Xwayland on top of weston right now :-/
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel