Re: [Linaro-mm-sig] Buffer sharing proof-of-concept

From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: "Clark, Rob" <rob@ti.com>
Cc: Jordan Crouse <jcrouse@codeaurora.org>,
	"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
	Tomasz Stanislawski <t.stanislaws@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [Linaro-mm-sig] Buffer sharing proof-of-concept
Date: Thu, 4 Aug 2011 14:34:13 +0200	[thread overview]
Message-ID: <CAKMK7uG+UVynCQx-0AWXV8KM9Fe5unu0-9exaADTGrpAcMxHng@mail.gmail.com> (raw)
In-Reply-To: <CAO8GWq=6djefOgQGWf4fkRryWM2e7qOMA5qeZOGkUVx7VWf-wg@mail.gmail.com>

On Thu, Aug 4, 2011 at 13:14, Clark, Rob <rob@ti.com> wrote:
> hmm, there would be a dmabuf->private ptr in struct dmabuf.  Normally
> that should be for private data of the buffer allocator, but I guess
> it could be (ab)used for under the hood communication between drivers
> a platform specific way.  It does seem a bit hacky, but at least it
> does not need to be exposed to userspace.

An idea that just crossed my mind: I think we should seperate two
kinds of meta-data about a shared piece of data (dmabuf):
- logical metadata about it's contents, like strides, number of
dimensions, pixel format/vbo layout, ... Imo that stuff doesn't belong
into the buffer sharing simply because it's an a) awful mess and b)
gem doesn't know it. To recap: only userspace knows this stuff and has
to make sense of the data in the buffer by either setting up correct
gpu command streams or telling kms what format this thing it needs to
scan out has.
- metadata about the physical layout: tiling layout, memory bank
interleaving, page size for the iommu/contiguous buffer. As far as I
can tell (i.e. please correct) for embedded systems this just depends
on the (in)saneness of to iommu/bus/memory controller sitting between
the ic block and it's data. So it would be great if we could
completely hide this from drivers (and userspace) an shovel it into
the dma subsystem (as private data). Unfortunately at least on Intel
tiling needs to be known by the iommu code, the core gem kernel driver
code and the userspace drivers. Otoh using tiled buffers for sharing
is maybe a bit ambitious for the first cut. So maybe we can just
ignore tiling which largely just leaves handling iommus restrictions
(or their complete lack) which looks doable.

> (Or maybe a better option is just 'rm -rf omx' ;-))

Yeah ;-)
-Daniel
-- 
Daniel Vetter
daniel.vetter@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch