linux-kernel - Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87mv97byni.fsf@eliezer.anholt.net>
Date:   Fri, 16 Jun 2017 11:00:49 -0700
From:   Eric Anholt <eric@...olt.net>
To:     Daniel Stone <daniel@...ishbar.org>
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.

Daniel Stone <daniel@...ishbar.org> writes:

> 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.

Is your wayland compositor planes-only?  Because if it's doing any GL
compositing, this will be a huge win for it.  I'd recommend actually
trying out the code to see.  (I considered this tradeoff when deciding
to make the change).

Kodi, yes, this will be a small performance hit for.  Given that we're
not even using hardware decode in the current Kodi pipeline, worrying
about this seems misplaced.  The fix would be pretty trivial, though:
make a new GBM_BO_USE_RENDER_TARGET as a subset of GBM_BO_USE_RENDERING
that sends that hint down to gallium, which already has that distinction
in its flags.

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)