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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
