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: Fri, 15 Mar 2019 09:05:38 -0700 Message-ID: <875zskrulp.fsf@anholt.net> References: <20190206131457.1072-1-yuq825@gmail.com> <20190206131457.1072-3-yuq825@gmail.com> <8be4643d-f6ba-3ba9-e0b1-ec0bd8119deb@gmail.com> <87bm2d3xcc.fsf@anholt.net> <804e0033-342e-09b9-2339-1bc8f717c024@amd.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0450511408==" Return-path: In-Reply-To: <804e0033-342e-09b9-2339-1bc8f717c024@amd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: "Koenig, Christian" , 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 , Andreas Baierl , Erico Nunes List-Id: dri-devel@lists.freedesktop.org --===============0450511408== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "Koenig, Christian" writes: > Am 14.03.19 um 23:28 schrieb Eric Anholt: >> 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. > > I can only advise to NOT do this. > > A address space manager in userspace is rather easily doable, but fixing= =20 > up UAPI without breaking existing applications isn't. Can you expand on what goes wrong with Rob's idea? The only thing I can come up with is maybe dmabuf imports don't have a flag for don't-automatically-map? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlyLzVMACgkQtdYpNtH8 nugdDRAApBViclKUyKB0drgVXuh+9Epj3rwFyBfDfcru+2p7KWyZL4V/X+NmeVFQ vqWjEE/ILJGOUB3NCKqXbRf/cyPWJLKUYkGluVtI7N3kJMs8Tehm21urP9cBE+h/ dwBzoR4lbrEQwHooY9ADGI5pYTyBmwc0CB44inOLO9LMDzK7tcM0at0KQK2KO9gT veHlByYl3Tg1BlIJdUM2KFDWG5HAXOGNvIj+2Ly0RGcfje4Jt3Pt/4CzG4yDSXmK j9KMY1DTUQss7HMjd8KxCg8fVPS+G9qF5IbSTDOA45E3hEG9LZw8rUR5qFYPx71T J6fEPbQNP8jWxbLnCcid5nA2gZnxPUoYw0IZDny+B4z5lFE89Wrh34x7YCIrRfbm XX8TQFw0gr7dxpK2LR6V1+UWwGBrLQUp5T8Z7HsoGOL8nMvTKzuTmBREV5tQbRQO yUlRPAQT4wodD/DrAo49sUUt6aq07RN+alMx3pWcjoSVlzLujsu22xF3f7s29bkt w/nusEn+mCq9FgxtLPdYTCiX1XFlZrf3NL1fupzoPhe9SMolOrXzDV+I/G8l11Zv RSYuB5A4ovALXz8/6rvayJkY7+O1rz0vXm7jzniw47LYuGp5Ue6B8Q7Bxm2ofMoa wYr1I7Jj8zvRHdlbYrD4wZpFE1CQVnixnxpSC+qJjNPJ+aEH4aM= =2pvu -----END PGP SIGNATURE----- --=-=-=-- --===============0450511408== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============0450511408==--