Am Samstag, den 30.06.2012, 20:01 +0200 schrieb Thierry Reding: > 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. > As working code is the primary goal, I would say go for it. I still think TTM is the way to go, even for simple things like a DRM framebuffer driver, but as CMA and TTM won't collide in their goals it should be easy to put TTM in there after we have something going with CMA. Lucas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
