[PATCH v4] mmap on the dma-buf directly
tiago.vignatti at intel.com
Thu Aug 13 07:09:07 PDT 2015
On 08/13/2015 08:09 AM, Thomas Hellstrom wrote:
> I take it, this is intended to be a generic interface used mostly for 2D
yup. "generic" is an important point that I've actually forgot to
mention in the description, which is probably the whole motivation for
bringing this up.
We want avoid link any vendor-specific library to the unpriviledged
process for security reasons, so it's a requirement to it not have
access to driver-specific ioctls when mapping the buffers. The use-case
for it is texturing from CPU rendered buffer, like you said, with the
intention of passing these buffers among processes without performing
any copy in the user-space ("zero-copy").
> In that case, using SYNC is crucial for performance of incoherent
> architectures and I'd rather see it mandatory than an option. It could
> perhaps be made mandatory preferrably using an error or a one-time
> kernel warning. If nobody uses the SYNC interface, it is of little use.
hmm I'm not sure it is little use. Our hardware (the "LLC" capable) has
this very specific case where the cache gets dirty wrt the GPU, which is
when the same buffer is shared with the scanout device. This is not
something will happen in Chrome OS for example, so we wouldn't need the
SYNC markers there.
In any case I think that making it mandatory works for us, but I'll have
to check with Daniel/Chris whether there are performance penalties when
accessing it and so on.
> Also I think the syncing needs to be extended to two dimensions. A long
> time ago when this was brought up people argued why we should limit it
> to two dimensions, but I believe two dimensions addresses most
> performance-problematic use-cases. A default implementation of
> twodimensional sync can easily be made using the one-dimensional API.
two dimension sync? You're saying that there could be a GPU access API
in dma-buf as well? I don't get it, what's the use-case? I'm sure I
missed the discussions because I wasn't particularly interested in this
whole thingy before :)
Thanks for reviewing, Thomas.
More information about the dri-devel