Re: DRM Stuff

> Date: Mon, 26 Sep 2022 09:40:15 +0100
> From: Robert Swindells <[email protected]>
> 
> Taylor R Campbell <[email protected]> wrote:
> > Date: Sun, 25 Sep 2022 22:10:15 +0100
> > From: Robert Swindells <[email protected]>
> > 
> >> 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.
> 
> On arm, bus_dmamap_sync crashes if you have used bus_dmamap_load_raw.

How does it crash?  Sounds like a bug.

> >Using bus_dmamap_load would require that we map every graphics buffer
> >into KVA before using it, which shouldn't be necessary for anything.
> 
> Ok, suggest some other way of doing a cache sync.

If you need to try this as a hack, you can just map the same pages in
with kmap or something and issue the CPU flush instructions you
suspect are necessary -- not fit for committing permanently but enough
to test a hypothesis.

What does Linux do in the place where you think we need
bus_dmamap_sync?

> >> 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?
> 
> The GPU is undocumented, the compiled Linux sources either work or they
> don't.

OK, but is there a small reproducer you can construct out of this, and
maybe submit from the kernel directly?

> >> 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.
> 
> I know it doesn't use bus_dmamap_sync, there were reports that the
> display didn't get updated, I was asking if this was still the case.

Sometimes yes, with the framebuffer, but it's not always clear if it's
a bug in the kernel driver, a bug in the userland driver, or an
unstated assumption that the rendering is going through a compositor
like xcompmgr or picom.