Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752486AbdFPSAy (ORCPT ); Fri, 16 Jun 2017 14:00:54 -0400 Received: from anholt.net ([50.246.234.109]:36924 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750873AbdFPSAx (ORCPT ); Fri, 16 Jun 2017 14:00:53 -0400 From: Eric Anholt To: Daniel Stone Cc: dri-devel , Linux Kernel Mailing List , Boris Brezillon Subject: Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls. In-Reply-To: References: <20170608001336.12842-1-eric@anholt.net> <20170608001336.12842-2-eric@anholt.net> <87y3svyjk2.fsf@eliezer.anholt.net> User-Agent: Notmuch/0.22.2+1~gb0bcfaa (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 16 Jun 2017 11:00:49 -0700 Message-ID: <87mv97byni.fsf@eliezer.anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2715 Lines: 59 --=-=-= Content-Type: text/plain Daniel Stone writes: > On 13 June 2017 at 16:49, Eric Anholt wrote: >> Daniel Stone 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAllEHNEACgkQtdYpNtH8 nuj97w//bhnBZJd25dYDWNnjfCdZIDCnrTCmLHI9GeMFRwDX20TlEvutEjcwpZ/E dzRQndArOXptx4EloJ91KE72sBgS/SlgT2pdj7VEAeSpgz5JFb5vJZBswPQ/am4d s7VaWd+IxWPYnA0XXlnmYncN0exktBc0tD/7hs25atdA2+wvQaaieKKY5d535ERj 7SwSx9M+gvafmu/s+5ZMm3UYwgICRv3quFY0djf3j0f0cK4J2YDZq7L9IlTuIK1u wVSAKp9VWHxzFMXjXqGK724NTiO6UQnVi7FWuIag5dOS8I2GuS7IygA/FI3lYTCU HhUL4LeCMl+sw1YlMA2M6Ck8evLtTbroqZeokOfRAdpLLY/GmkZDC9zn4YBFRgtn RSJZD/X7yh50TIKvwsGIUIqBmegAMiXCPD34qXCETbCayUqV67CCFmy6vzhEpTo5 P0UJEMqrML4xvlR3ZxuMKLjekuEiEkt+WE41+n1Fo7Gs4LpMh4y8HV9nrXffa4Jc X/exjDmROAWpUrfVf4HcrFulw71V1oLeAqrWqkOFB84WIZwQxnON5cm5QtCiwFAY 4QUZub+rypuJiPKCwiV06iR2jTMvZNKHCwA49cuUM7h+aW4/oQpHhp57cCZGwKQn 8BecR9FZKanekIUty0KjJvMISoAD4V/OonmvgSfA3ToctJc1YaM= =bSsp -----END PGP SIGNATURE----- --=-=-=--