[PATCH v2 1/2] drm/shmem: add support for per object caching attributes
Gerd Hoffmann
kraxel at redhat.com
Mon Dec 16 08:07:19 UTC 2019
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
More information about the dri-devel
mailing list