[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] Status quo

On Tue, Mar 31, 2015 at 11:57 PM,  <whygee@xxxxxxxxx> wrote:
> Le 2015-03-31 17:37, Cedric BAIL a Ãcrit :
>> On Tue, Mar 31, 2015 at 5:25 PM, Nikolay Dimitrov <picmaster@xxxxxxx>
>> wrote:
>>> DRI uses memory managed by DRM, which does exactly what you need.
>> Absolutely not ! The memory allocation sure, but it never provide a
>> simple way to adapt to the GPU memory layout. That's why uploading
>> texture is usually heavy on CPU as they have to memcpy every pixel in
>> a different layout before uploading them to the GPU or they endup on
>> the GPU in a format that will be noticably slower. I have never seen a
>> system where you could get a linear looking memory on the CPU side via
>> the MMU and a tile based one in physical memory.
> If I understand correctly, you need to map arbitrary rectangles in memory
> to a different memory layout. It's not the MMU's role, its role is to
> "manage" and protect memory. It is VERY hard to have pages that are not
> a power of two.

You don't need the support for arbitrary rectangle. You could
implement one that directly map the GPU needs or one that fit best
your CPU cache layout if you don't have a GPU associated. The benefit
of playing a trick on the MMU would be to also have this cache
improvement also available to 2D software renderer. As you point out
also, you want it to be a power of 2 and that's what all the GPU I
have been working with do (which make sense as they do that themself
on their side).

> I seem to remember that the RPi's Broadcom chip has several DMA channels,
> including one with "2D" capability, it might do what you seem to describe.
> It takes strips of equal sizes from one memory, and puts them with different
> spacings or strides somewhere else. Is that what you think of ?

Not really. It would help for the case of DMA from/to the GPU, but not
for all the 2D rendering case you could do on the CPU.
Cedric BAIL
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/