[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPj87rMnpuC741rCKua3-qgafWLQTzwXLivds4q6bCdHg6Sy3w@mail.gmail.com>
Date: Fri, 16 Jun 2017 10:08:49 +0100
From: Daniel Stone <daniel@...ishbar.org>
To: Eric Anholt <eric@...olt.net>
Cc: dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Boris Brezillon <boris.brezillon@...e-electrons.com>
Subject: Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls.
On 13 June 2017 at 16:49, Eric Anholt <eric@...olt.net> wrote:
> Daniel Stone <daniel@...ishbar.org> writes:
>> I posted a DRI3 v1.1 patch series which can advertise and also transit
>> modifiers directly under X11, and have also typed up the support for
>> Wayland which is working just fine with Weston from git. If you
>> implement DRIimage v15 to advertise and import modifiers, then you can
>> transit them for free without a magic-back-channel ioctl. Would that
>> be enough to convince you to drop this series?
>
> Not really -- this patch is pretty small, and doesn't require updating
> the entire world.
The modifier interface is already landed in mainline for KMS, GBM, and
Gallium. It's supported in i965 and freedreno, and Lucas has patches
to support it for etnaviv/imx-drm as well.
While I get that the {get,set}_tiling interface is necessary to route
around the X11 support not existing until very recently, I'm unhappy
that it's now landed in mainline imposing a performance penalty on
everyone else (Wayland compositors, Kodi, etc etc), with no way to
route around it.
Being that the impetus was an upcoming Raspbian release, I'd have been
a lot happier if it were carried as a downstream patch. As it is,
mainline now has an end-run around generic infrastructure to benefit
one specific user, leaving everyone else to write and try to land VC4
modifier support, then explicitly filter out the tiling modifier in
their KMS code, so they can un-regress their performance.
Powered by blists - more mailing lists