Re: Tegra DRM device tree bindings

[Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>]

Am Freitag, den 29.06.2012, 16:20 +0300 schrieb Terje Bergström:
> 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.
> 
> 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.
> 
I understand that TTM looks like a big complex beast at first sight, but
trying to understand how it works avoids reinventing the wheel over and
over again. We still have to solve problems like cache invalidation,
synchronization and swap-out of dma buffers, which is a lot easier if we
go with a common framework. 

> 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.
> 
That's exactly the level we are providing to userspace from other
drivers using TTM like radeon or nouveau.

> 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.
> 
dma_buf at the current level is only a way to share buffers and does not
provide enough information about the buffer to be useful as an
abstraction level on top of multiple memory managers. But I agree that
we should try to get dma_buf integration right from the start, as the
zero-copy share a very useful thing to have.

Lucas