On 12/07/2012 02:44 PM, Terje Bergström wrote: > On 07.12.2012 07:38, Mark Zhang wrote: >> On 12/06/2012 07:36 PM, Terje Bergström wrote: >>> This is about the hardware, and the correct verb is "copy". HOST1X >>> hardware pre-fetches opcodes from push buffer and contents of GATHERs to >>> a FIFO to overcome memory latencies. The execution happens from FIFO. >> Okay, so the command FIFO is not a part of memory we need to allocate. >> It's inside in every host1x clients. > > Almost - it's part of HOST1X itself, not clients. Got it. > >> Yeah, I have known the idea. What I'm confused before is that why we >> need this reloc table because all mem are allocated from us(I mean, >> tegradrm/nvhost) so ideally we can find out all buffer related infos in >> the driver while userspace doesn't need to provide such informations. > > For lots of buffers, there's no need to map them to user space at all, > so user space can treat the buffer as just an abstract region. For > example, getting handle to frame buffer and passing it to 2D for > rendering doesn't require user space to map the memory. > > Second point is that as long as we haven't pinned memory, there's a > possibility to move the pages around to do defragmenting etc. As soon as > you get a device virtual address to a page, you need to pin it and can't > move it anymore. So we want to build the APIs and sequences so that the > pages can be pinned as late as possible. > Great, these are another two strong evidences. Big thanks. :) > Naturally, in CMA, the second point isn't that relevant, but I want the > API to tolerate IOMMU support, too. > > Terje > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
