From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH 2/2] drm/lima: driver for ARM Mali4xx GPUs Date: Thu, 14 Mar 2019 15:28:03 -0700 Message-ID: <87bm2d3xcc.fsf@anholt.net> References: <20190206131457.1072-1-yuq825@gmail.com> <20190206131457.1072-3-yuq825@gmail.com> <8be4643d-f6ba-3ba9-e0b1-ec0bd8119deb@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1772569990==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Rob Herring , Dave Airlie Cc: Marek Vasut , Simon Shields , lima@lists.freedesktop.org, Neil Armstrong , Maxime Ripard , Christian =?utf-8?Q?K=C3=B6nig?= , dri-devel , Vasily Khoruzhick , David Airlie , Qiang Yu , Sean Paul , "Koenig, Christian" , Andreas Baierl , Erico Nunes List-Id: dri-devel@lists.freedesktop.org --===============1772569990== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rob Herring writes: > On Thu, Mar 14, 2019 at 3:45 PM Dave Airlie wrote: >> >> On Thu, 14 Feb 2019 at 19:12, Christian K=C3=B6nig via dri-devel >> wrote: >> > >> > Am 14.02.19 um 03:52 schrieb Alex Deucher via dri-devel: >> > > [SNIP] >> > >>>>> +static int lima_ioctl_gem_va(struct drm_device *dev, void *data= , struct drm_file *file) >> > >>>>> +{ >> > >>>>> + struct drm_lima_gem_va *args =3D data; >> > >>>>> + >> > >>>>> + switch (args->op) { >> > >>>>> + case LIMA_VA_OP_MAP: >> > >>>>> + return lima_gem_va_map(file, args->handle, args-= >flags, args->va); >> > >>>>> + case LIMA_VA_OP_UNMAP: >> > >>>>> + return lima_gem_va_unmap(file, args->handle, arg= s->va); >> > >>>> These are mapping to GPU VA. Why not do that on GEM object creati= on or >> > >>>> import or when the objects are submitted with cmd queue as other >> > >>>> drivers do? >> > >>>> >> > >>>> To put it another way, These ioctls look different than what other >> > >>>> drivers do. Why do you need to do things differently? My understa= nding >> > >>>> is best practice is to map and return the GPU offset when the GEM >> > >>>> object is created. This is what v3d does. I think Intel is moving= to >> > >>>> that. And panfrost will do that. >> > >>> I think it would be a good idea to look at the amdgpu driver. This >> > >>> driver is heavily modeled after it. Basically the GEM VA ioctl al= lows >> > >>> userspace to manage per process (per fd really) virtual addresses. >> > >> Why do you want userspace to manage assigning VAs versus the kernel= to >> > >> do so? Exposing that detail to userspace means the driver must supp= ort >> > >> a per process address space. Letting the kernel assign addresses me= ans >> > >> it can either be a single address space or be a per process address >> > >> space. It seems to me more flexible to allow the kernel driver to >> > >> evolve without that ABI. >> > > Having it in userspace provides a lot more flexibility and makes it >> > > easier to support things like unified address space between CPU and >> > > GPU. I guess it depends on the hw as to what is the right choice. >> > >> > To summarize we actually have tried this approach with the radeon and = it >> > turned out to be a really bad mistake. >> > >> > To implement features like partial residential textures and shared >> > virtual address space you absolutely need userspace to be in charge of >> > allocating virtual addresses. >> > >> >> I think for lima not having this is fine, but for panfrost it really >> should have it. >> >> If you can implement vulkan you probably want this, nouveau hasn't a >> vulkan driver because of exactly this problem in their uapi, so maybe >> adjust panfrost to do user-space managed vma. > > Wouldn't this just require an allocation flag to not map the BO up > front and then new ioctl's like above to map and unmap at specified > VAs? Seems like we could add that when we get there. Sounds pretty reasonable to me. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlyK1XMACgkQtdYpNtH8 nujy9g/+MSjLxiEIXdNhquz+/wZULXAzjlbPizo1M5fhFW1yyuXeecraKw7Q5QRG gGQLxwIrxx6tW92FUTZawd04sfo4AAMVbzUQIyluT7Hf+RB1xvhBqnoVqox32SVi sCvxq/eGvQfKhqq4rOr08S2Lo8JQeRiAL7fX3skRqbjmz2AxR1rtD8AS4Wk6H3g5 MZ6qCYqkiw/k8TQCMh/zwDa4A5A2F3NCt4nOa6P0pX6NaGPFDU8MzzHD1qM0J88b OorGidpQV+aZYs+3oP1pYf3gom/hFrN2Eevaqiw9XGK+CmhU5uATcd0Pj7wBVgVW CTnuD4D+lmb3CpBO1tZMepI3QmrmMA3V9CDyyfAHWBP+XiexfqQz4/v69C9rkViH TThm4gGEl5tIaZ06d5lwqBh706SZ6T4KQ5/OyIjM4jD17jxBvVRSaZJ7DDSj7wky mpK2QUFVORm7ou6vsYW3U9nelaAKmJoq+veqBblirQfdx4gjVHKAXpNnR8ZB68ZG O8RUB8r9rqOCyYYB6eA4vQERe7BRHXKM0U9TbbUckvdPPtxRg4xU0vKfEVWMAnYq uiuZ5Lo/EGDkxcD6x1DL3D2VpptIoyggJEj2sjskohFyCe9815RCIu8kl3nqnL6o fkCU5Wo42j4YoizmUKz/4FawnWaoBXdlXn2pFhJSn2HV+qWEK2E= =8x59 -----END PGP SIGNATURE----- --=-=-=-- --===============1772569990== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============1772569990==--