Re: [PATCH] drm/vgem: implement virtual GEM

[Thomas Hellstrom <thellstrom@vmware.com>]

On 11/25/2014 02:08 AM, Zachary Reizner wrote:
> After looking into removing platform_device, I found that using
> dma_buf_attach with a NULL device always returns an error, thereby
> preventing me from using VGEM for import and mmap. The solution seems
> to be to skip using dma_buf_attach, and instead use dma_buf_mmap when
> user-space tries to mmap a gem object that was imported into VGEM. The
> drawback to this approach is that most drivers stub their
> dma_buf_ops->mmap implementation. Presumably mmap could be implemented
> for the drivers that this would make sense for. Are there any
> comments, questions, or concerns for this proposed solution?

I see now that this driver has entered -next, and I'm sorry this comment
didn't arrive before. I simply missed this discussion :(

My biggest concern, as stated many many times before, is that dma-buf
mmap is a horrible interface for incoherent drivers, and for drivers
that use odd format (tiled) dma-bufs, basically since it doesn't supply
a dirtied region. Therefore (correct me if I'm wrong) there has been an
agreement that for purposes outside of ARM SOC, we should simply not
implement dma-buf mmap for other uses than for internal driver use.

So assume a real driver implements dma-buf mmap, but it is crawling due
to coherency- or untiling / tiling operations. How do you tell a generic
user of the vgem driver *NOT* to mmap for performance reasons? Or is
this driver only intended for ARM SOC systems?

Thanks,
Thomas




_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel