Re: [PATCH v4] mmap on the dma-buf directly

From: Daniel Vetter <daniel@ffwll.ch>
To: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: daniel.vetter@ffwll.ch, daniel.thompson@linaro.org,
	Thomas Hellstrom <thomas@shipmail.org>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4] mmap on the dma-buf directly
Date: Thu, 13 Aug 2015 16:51:49 +0200	[thread overview]
Message-ID: <20150813145149.GC17734@phenom.ffwll.local> (raw)
In-Reply-To: <55CCA503.1090600@intel.com>

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx