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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
