On Friday 02 November 2007 09:07, Denis Oliver Kropp wrote: > Lloyd Sargent wrote: > > On Friday 02 November 2007 08:28, Denis Oliver Kropp wrote: > Which additional ideas do you have?
Sorry, they were application oriented, not driver oriented :) > Do you think the DMA engine would be faster than the DSP? I thought > memory throughput would be the bottleneck anyhow. For now it would be > easier to maintain one accelerator only. Syncing and maintaining command > ordering is not really supported yet for multiple accelerators. Yah, memory throughput is a bottleneck (we haven't run into it, but it is obvious it will be) - doesn't matter how many busses there are. Honestly, I only SUSPECT DMA is faster, but have no proof. It sounds like you did something that is independent of the T.I. DSP software - how compatible is it? Can I run DFB accelerator and MPEG decoder? Or is it one or the other? I have had conflicting stories from T.I. in regards to multiple DSP apps. > Does the DMA engine support anything beyond simple 2D block moves in > memory? Yes. It supports 3D block moves. It is actually pretty spiffy. I was talking to the T.I. engineer about it last year about moving a section of graphics and he said "oh, use the DMA". I jumped in and said "But DMA is 2D only it won't work!" Then he smiled and said "We made changes. It supports not only length, but width" Later I went back and he was right. It is a very spiffy bit of hardware (complex too!). Wish I'd looked at it before making an ass of myself <laughs>. > Maybe 8/16/32 bit wise compare/skip, i.e. color keying? Nooo, I don't recall THAT being in the DMA... or are you talking about something else? That would make the DSP the superior choice of course. Cheers, Lloyd _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
