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. 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. Terje -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
