Re: [PATCH v2 1/2] drm/shmem: add support for per object caching attributes

[Gerd Hoffmann]

  Hi,

> > I suspect for imported dma-bufs we should leave the mmap() to the
> > exporter instead of pulling the pages out of the sgt and map them
> > ourself.
> 
> Uh yes. If we still do that, then yes very much we shouldn't.

Looking again.  drm_gem_dumb_map_offset() throws an error in case
obj->import_attach is not NULL.  So the udl mmap code should not see
imported buffers in the first place, unless I missed some detail ...

> > Hmm.  Ok.  I guess I'm not going to try solve all that properly just for
> > the little virtio fix.
> > 
> > Just curious:  How do you tell your hardware?  Are there bits for that
> > in the gtt, simliar to the caching bits in the x86 page tables?
> 
> Brace for contact ...
> 
> - on amdgpu it's a bit in the gpu pagetable. I think (but not sure, not an
>   expert on these chips) that's the only way.
> 
> - on i915 it's a also a bit in the gpu pagetables, but userspace can
>   override the caching/coherency mode on a per-texture/render target/*BO
>   level in the command stream.
> 
> This is why gpus and dma-api don't mix well, since dma-api's goal is to
> hide all this even from the driver. gpus otoh leak it all the way to
> userspace. The trouble is as old as AGP from 1999 or so, I've become
> somewhat cynic at trying to fix this for real and not just with hacks. The
> disconnect between what we need and what dma-api kernel people want to
> give us is too big to bridge it seems.

Phew.  For vulkan support in virtio-gpu we are going to throw virtual
machines into that mix.  Fun ahead I guess ...

cheers,
  Gerd