> Denis Oliver Kropp dok at directfb.org
>
> Lloyd Sargent wrote:
>> On Friday 02 November 2007 09:07, Denis Oliver Kropp wrote:
>>> 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.
We've implemented a driver to support BLTs from user-space. I'll post the
driver under separate cover. We're in a position to test if you have a
fast CPU-based implementation for comparison.
Denis is right about synchronization, though. Doing DMA-based
blts on the ARM-side would require waiting for DSP completion
to allow pipelining of graphics ops.
>>
>> 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.
>
> It is completely independent of TI's DSP software, no dsplink/bios etc.
Sweet! I read in another post that you may have an assembler as well
http://mail.directfb.org/pipermail/directfb-users/2007-October/000088.html
Is that what you're basing things on?
>
> You cannot run any other DSP code, e.g. TIs video codec, but we're
> working on our own MPEG decoder and have command queues to manage
> multiple DSP 'apps', i.e. commands issued by DFB or the video code.
>
(How) are you planning to release this? Through Direct-FB?
>>> 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"
>
> Why 3D? Traditional DMA would be 1D with start and length. 2D would
> be start, line length, actual width and number of lines.
>
The 3rd dimension seems designed to do translations between YUV420 and 422.
>>> 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.
>
> I really meant comparing each word to be copied with a reference value
> before actually writing it to the destination. Simple rectangular fills
> and copies would not be enough to fully accelerate a GUI.
>
Not enough, but still helpful. Using the DMA should at least prevent
polluting the CPU's cache when doing the common BLT-to-screen operation
or copy-back when the frame buffer is double or triple-buffered.
_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
