Re: DRM Stuff

[Taylor R Campbell <campbell+netbsd-tech-x11%mumble.net@localhost>]

> Date: Sun, 25 Sep 2022 22:10:15 +0100
> From: Robert Swindells <rjs%fdy2.co.uk@localhost>
> 
> I think that the usage from linux_sgt.c needs to be able to keep the
> segments setup when converting between Linux and NetBSD memory pages so
> that they can be used in calls to bus_dmamap_sync(). To be able to
> use bus_dmamap_sync() I think would also need to change from using
> bus_dmamap_load_raw() to bus_dmamap_load().

Why do you think that?  The arm bus_dmamap_sync treats them the same
as far as I can tell.

Using bus_dmamap_load would require that we map every graphics buffer
into KVA before using it, which shouldn't be necessary for anything.

> My guess is that the lima driver needs to be able to sync memory after
> userland has written shaders to it before telling the GPU to run them.

Often there's an easy small command you can send to the GPU to write a
specified word of (GPU virtual) memory to confirm that something is
happening -- radeon uses this at boot (`ring test').  Have you tried
to find something like that?

> Does the i915 code still have problems that look like caches not getting
> flushed correctly?

Doesn't use bus_dmamap_sync (except in one place to zero a scratch
page), so that's not the issue here.

> 2) There was a bit of discussion on port-arm@ about the idea of getting
> userland and core DRM code changes needed for ARM GPU drivers into
> the tree now so that they will be in NetBSD-10.
> 
> I have added the lima and panfrost code to the gallium.old Makefile,
> some extra files to libglsl.mk, and some minor source changes to libdrm.
> 
> Should the gallium.old Makefile include libglsl.mk or libglsl.old.mk?
> 
> Any opinions on doing this?

Don't know about userland stuff, wait for someone who does to answer!

Are there any ABI changes that need to happen?  I would expect that
adding a *_dri.so loadable module wouldn't affect any ABI so would be
safe to pull up but I don't really know.