Re: ZigZag (was Re: [f-cpu] Status quo)

[Cedric BAIL <cedric.bail@xxxxxxx>]

On Fri, Apr 3, 2015 at 1:51 PM, Nicolas Boulay <nicolas@xxxxxxxxxxx> wrote:
> 2015-04-01 22:37 GMT+02:00 Cedric BAIL <moa.bluebugs@xxxxxxxxx>:
>> I think I wasn't really clear in my previous description of this
>> topic. The reason why I did bring up this idea is because the same zig
>> zag concept can be used in two case. The first one being when you use
>> a GPU and you upload the texture. Here that is a pretty self contained
>> piece of code and will usually be manually optimized. So an
>> instruction is fine for it.
>>
>> The second case is that actually having that kind of memory layout is
>> also going to help a software implementation that are typically used
>> to do 2D graphics. But in that case the burden on the toolkit doing
>> the 2D graphics is so high to use a special instruction and change
>> their own rendering pipeline that it wont be worth it at all for them
>> to do it. That's where actually making the operation transparent to
>> the software by flagging some entry in the TLB would pay much more.
>
> And what about to split the problem in 2 ? One is done by a specific DMA or
> instruction to copy texture from/to cpu memory to GPU memory.
>
> The second is to have an other "load/store" instruction that optimise 2D
> pattern, by changing cache behavior.
>
> You avoid  MMU flag, but you loose the nice feature of sharing texture
> memory between gpu and cpu..

The problem is that you are back to square one and need a way to
propagate that information everywhere in your rendering pipeline
making any patch quite intrusive and difficult to do. Instead of just
playing with the memory allocator.
-- 
Cedric BAIL
*************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/