Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 6 May 2019 11:28:35 +0300
From:   Pekka Paalanen <ppaalanen@gmail.com>
To:     Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cc:     Nicolas Dufresne <nicolas@ndufresne.ca>,
        Alexandre Courbot <acourbot@chromium.org>,
        Maxime Ripard <maxime.ripard@bootlin.com>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        Tomasz Figa <tfiga@chromium.org>,
        Hans Verkuil <hverkuil@xs4all.nl>,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        Dave Airlie <airlied@redhat.com>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        linux-media@vger.kernel.org
Subject: Re: Support for 2D engines/blitters in V4L2 and DRM
Message-ID: <20190506112835.6d4ecf29@eldfell.localdomain>
In-Reply-To: <0df3d4b5178d8a37b67b275e0771741c6c268de3.camel@bootlin.com>
References: <0df3d4b5178d8a37b67b275e0771741c6c268de3.camel@bootlin.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/SpOK9UJGe5vSo3s9+A03Kje"; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--Sig_/SpOK9UJGe5vSo3s9+A03Kje
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 17 Apr 2019 20:10:15 +0200
Paul Kocialkowski <paul.kocialkowski@bootlin.com> wrote:

> There's also the possibility of writing up a drm-render DDX to handle
> these 2D blitters that can make things a lot faster when running a
> desktop environment. As for wayland, well, I don't really know what to
> think. I was under the impression that it relies on GL for 2D
> operations, but am really not sure how true that actually is.

Hi Paul,

Wayland does not rely on anything really, it does not even have any
rendering commands, and is completely agnostic to how applications or
display servers might be drawing things. Wayland (protocol) does care
about buffer types and fences though, since those are the things passed
between applications and servers.

In a Wayland architecture, each display server (called a Wayland
compositor, corresponding to Xorg + window manager + compositing
manager) uses whatever they want to use for putting the screen contents
together. OpenGL is a popular choice, yes, but they may also use Vulkan,
Pixman, Cairo, Skia, DRM KMS planes, and whatnot or a mix of any.
Sometimes it may so happen that the display server does not need to
render at all, the display hardware can realize the screen contents
through e.g. KMS planes.

Writing a hardware specific driver (like a DDX for Xorg) for one
display server (or a display server library like wlroots or libweston)
is no longer reasonable. You would have to do it on so many display
server projects. What really makes it infeasible is the
hardware-specific aspect. People would have to write a driver for every
display server project for every hardware model. That's just not
feasible today.

Some display server projects even refuse to take hardware-specific code
upstream, because keeping it working has a high cost and only very few
people can test it.

The only way as I see that you could have Wayland compositors at large
take advantage of 2D hardware units is to come up with the common
userspace API in the sense similar to Vulkan or OpenGL, so that each
display server would only need to support the API, and the API
implementation would handle the hardware-specific parts. OpenWF by
Khronos may have been the most serious effort in that, good luck
finding any users or implementations today. Although maybe Android's
hwcomposer could be the next one.

However, if someone is doing a special Wayland compositor to be used on
specific hardware, they can of course use whatever to put the screen
contents together in a downstream fork. Wayland does not restrict that
in any way, not even by buffer or fence types because you can extend
Wayland to deal with anything you need, as long as you also modify the
apps or toolkits to do it too. The limitations are really more
political and practical if you aim for upstream and wide-spread use of
2D hardware blocks.


Thanks,
pq

--Sig_/SpOK9UJGe5vSo3s9+A03Kje
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlzP8DMACgkQI1/ltBGq
qqd5DA//dXv9y+97awajCKuDmUaldHzEJQuyfyNzTw+d5g979ran569Nf0pqYTd3
pidYpINEGc/Fkt2+u1aSk+ozSN6yvXV0Noh7ZVNqhRhw/nsLSO22jvZtWWzJH4tk
JI+vR6D0zvA9B2+3MmnFlwDj0tnyxc5/ACABUvG4zMFYGMrL5o2wVQ9cdt81Ox83
mFm+NPy7mT/2aun+RfMp9SVqROMVnj/sN5t3gcuv/dmMwykIFQZRxlXt3IYRiRxW
+fOS6GdSVEf/aFwcOAv8P1VZW7uQlBSlYdXpAu/9ht4QY0/JX8K7uTsRfjQdVdD0
uofIYCVqUPbUFkBHcF3vMRXZBzCvgDPATd2PG8fiMT7csowmVyFPObnNFx7gfe/U
5z1b1yH9QuZ5YR0TrPDiZguaQsTtiYHn8GhMX0c1M6Ht46PzuVZ2qQfptVXSBlI/
vUK4VbgBHURQHmPkxsdW78inZgbP+aWWKr4sAOdLE0LchaEWEZzHErO1Ec0cicUT
1TCH0EhU3bcVdOax7ipZrJjyuLjwOvAC94/OcJx3OwU/LOWDqZ216R1JQxchjgWv
IF15KnUteeWBCJJmKVE+krfpz6dEBno+1uqpsAQIrCMZhIzuIAxXaFl1yvqne0Zn
v43ZqT89q1MBU28SDxh98M61HnA/hGZuJIqzOEmXSPH1khgBn1w=
=GYn9
-----END PGP SIGNATURE-----

--Sig_/SpOK9UJGe5vSo3s9+A03Kje--