Tegra DRM device tree bindings
Thierry Reding
thierry.reding at avionic-design.de
Sat Jun 30 11:01:44 PDT 2012
On Fri, Jun 29, 2012 at 04:20:31PM +0300, Terje Bergström wrote:
> On 28.06.2012 20:19, Lucas Stach wrote:
> > TTM though solves more advanced matters, like buffer synchronisation
> > between 3D and 2D block of hardware or syncing buffer access between GPU
> > and CPU.
> > One of the most interesting things of TTM is the ability to purge the
> > GPU DMA buffers to scattered sysmem or even swap them out, if they are
> > not currently used by the GPU. It then makes sure to move them in the
> > contig space again when the GPU really needs them and fix up the GPU
> > command stream with the new buffer address.
>
> We preferably should choose dma_buf as a common interface towards
> buffers. That way whatever we choose as the memory manager, all dma_buf
> aware drivers will be able to use buffers allocated by other drivers.
>
> We probably need to accommodate multiple memory managers to take care of
> legacy and new drivers. If V4L2 and DRM projects all move to dma_buf, we
> have the possibility to do zero-copy video without forcing everybody to
> use the same memory manager.
I agree. Supporting DMA BUF also doesn't seem very difficult.
> As I understand, TTM is good for platforms where we have a separate
> frame buffer memory, as is the case with most of the graphics cards. In
> Tegra, graphics and CPU occupy the same memory, so I'm not sure if we
> require the level of functionality that TTM provides. I guess the level
> of functionality and the complexity that it brings is one reason why TTM
> hasn't really caught on in the ARM world.
>
> The synchronization primitives attached to TTM are slightly confusing.
> At the bottom level, it's operations which need to be synchronized
> between each other. That's the API level that we should to export from
> kernel to user space. It's then up to libdrm level (or whatever is doing
> the rendering in user space) to decide which operations it wants to have
> completed before a buffer can be reused/read/passed on to the next stage.
>
> Anyway, if we hide the memory manager behind dma_buf, we're free to muck
> around with multiple of them and see what works best.
Exactly. Other subthreads echo this as well. Using CMA seems the easiest
and most flexible for now but still covers everything we need. If it
turns out that it isn't suited for more advanced stuff once we start
supporting 3D then we can still opt for something like TTM.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120630/7a5a2f20/attachment.pgp>
More information about the dri-devel
mailing list