> > Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren: > > > On 06/28/2012 05:12 AM, Thierry Reding wrote: > > > > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote: > > > >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding: > > > ... > > > >>> In the ideal case I would want to not have a carveout size at all. > > > >>> However there may be situations where you need to make sure some > > > >>> driver can allocate a given amount of memory. Having to specify > > > >>> this using a kernel command-line parameter is cumbersome because > > > >>> it may require changes to the bootloader or whatever. So if you > > > >>> know that a particular board always needs > > > >>> 128 MiB of carveout, then it makes sense to specify it on a > > > >>> per-board basis. > > > >> > > > >> If we go with CMA, this is a non-issue, as CMA allows to use the > > > >> contig area for normal allocations and only purges them if it > > > >> really needs the space for contig allocs. > > > > > > > > CMA certainly sounds like the most simple approach. While it may > > > > not be suited for 3D graphics or multimedia processing later on, I > > > > think we could use it at a starting point to get basic framebuffer > > > > and X support up and running. We can always move to something more > > > > advanced like TTM later. > > > > > > I thought the whole purpose of CMA was to act as the infra-structure > > > to provide buffers to 3D, camera, etc. in particular allowing > > > sharing of buffers between them. In other words, isn't CMA the memory > manager? > > > If there's some deficiency with CMA for 3D graphics, it seems like > > > that should be raised with those designing CMA. Or, am I way off > > > base with my expectations of CMA? > > > > > CMA is just a way of providing large contiguous address space blocks > > in a dynamic fashion. The problem CMA solves is: we have a system with > > relatively low amounts of sysmem (like 512MB), now to ensure we can > > always get large contiguous buffers for use by GPU or VIDEO blocks, we > > need to set aside a relatively large contiguous pool (like 128MB). So > > we are stealing 128MB of memory from the system while we may or may not > use it, which is bad. > > Now CMA allows to say: I may need 128MB of contig space, but the > > system is free to use it as normal memory as long as I don't really > > need it. If the space is really needed, CMA purges pages from the area > > and may even swap them out. So yes CMA is a memory allocator for contig > memory. > > > > 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. > > > > IMHO the best solution would be to use CMA as a flexible replacement > > of the static carveout area and put TTM on top of this to solve the > > needs of graphics drivers. We certainly don't want to reinvent the > > wheel inside CMA. We have solutions for all those things in the kernel > > right now, we just have to glue them together in a sane way. > > > > That is a great explanation. So could you explain what's the relation between > IOMMU api and TTM(or GEM)? > Terje said DMABUF api sits on top of IOMMU api. So for normal device > drivers(such as drm), can forget iommu apis, just use dmabuf api is OK. If so, I > wanna know does TTM/GEM and IOMMU are related? Or TTM/GEM uses > dmabuf apis which calls iommu api to do memory allocation/mapping? > Sorry for my stupid question. DMA mapping api sits on top of IOMMU api, not DMABUF. DMABUF is used to share buffers. So please ignore what I said. > > Thanks, > > Lucas > > > > -- > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
