[PATCH v4] mmap on the dma-buf directly

[Tiago Vignatti]

On 08/13/2015 08:09 AM, Thomas Hellstrom wrote:
> Tiago,
>
> I take it, this is intended to be a generic interface used mostly for 2D
> rendering.

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.

Tiago