Re: DRM Stuff

[Robert Swindells <rjs%fdy2.co.uk@localhost>]

Taylor R Campbell <campbell+netbsd-tech-x11%mumble.net@localhost> wrote:
> 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.

On arm, bus_dmamap_sync crashes if you have used bus_dmamap_load_raw.

>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.

>> 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.

>> 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.