First version of host1x intro

Mark Zhang nvmarkzhang at gmail.com
Thu Dec 6 23:05:20 PST 2012


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
> 


More information about the dri-devel mailing list