lkml.org 
[lkml]   [2019]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/2] drm/shmem: add support for per object caching attributes
  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

\
 
 \ /
  Last update: 2019-12-16 09:07    [W:0.057 / U:1.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site