On Thu, Aug 13, 2015 at 11:09:07AM -0300, Tiago Vignatti wrote:
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.
2 more ioctls per upload should be bearable, imo we should make this mandatory.
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 :)
Most of the things I've seen that use subranges for up/download use linear buffers where individual images are just packed in a queue, each with their own stride. Adding a notion of 2d to dma-buf would be a big departure from the "dma-buf doesn't track metadata" design. If there's a real need I guess we can do it, but only after careful consideration, and imo it shouldn't be in basic dma-buf mmap support. -Daniel