[maemo-developers] [maemo-developers] Re: Answer discovered @ http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/

[From: Ed Okerson]

What video codec are you trying to use?  Maybe I can try my hand at it.

Ed

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I didn't know how easy using the LCD hardware support for YUV was when
> I started working on this.
>
> Later on, when I did figure that out (when a Nokian finally posted
> something to the list), I revised my DSP code to do scaling only
> (YUV->YUV).   Even that was too slow on the DSP.     One issue I never
> resolved was how to get the DSP to write directly to the framebuffer
> memory.    I got it partially working, but I think I was hitting some
> variant of the 64k issue (see next paragraph).   So in the end, I
> reverted to having the DSP copy the scaled video to memory shared with
> the MPU, and then the MPU would copy it to the framebuffer.
>
> Although the DSP tools include a C compiler, there are issues that
> make porting existing C code far from trivial.   For starters, the
> fact that byte size on the DSP is 16 bits makes for a lot of grief.
> The other issue that kicked me in the teeth is that the DSP can not
> deal with data objects > 64kbytes (1 DSP page).   Actually, my
> impression is that this is not true anymore of the OMAP 1710 in the
> 770, but the free DSP tools are quite old and actually targetted to an
> older revision of the DSP, so the C compiler does not contain later
> revisions that removed that limitation.   I surmise that if I
> purchased an up to date CCS, this would have been fixed.   In
> hindsight, I should probably have done that.   As it was, I had to
> write some very ugly code to work around that 64k issue.    The
> workaround code probably is not without performance penalty either.
>
> My code is available in the maemo_dsp_yuv in case anyone wants to
> suggest how it might be improved.    My impression is that truly
> peformant DSP code requires a lot of actual expertise on the DSP
> architecture, including the ability to hand tune DSP assembly for the
> critical code.   I don't have the time to learn how to do that.
>
> Since I wasn't able to get a relatively simple task like YUV->YUV
> scaling to run with adequate speed on the DSP, I'm far from optimistic
> that porting my video codec to the DSP will be a fruitful exercise.
>
> - -- Buck
>
>
> Ed Okerson wrote:
>
>> If you have gone so far as to implement the YUV to RGB conversion,
>> why not go ahead and implement your codec on the DSP? You will get
>> much better throughput. For that matter why not send the YUV
>> directly to the display controller and let it do the RGB conversion
>> in hardware?
>>
>> Ed
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFE+IT9PrrWIMa4SMsRAuBJAJ9qcUq7LYEFEMYJqmuLAajWuUAneQCgosWr
> mtCyGPj8AdBJRuKIGUnMYqQ=
> =5qMN
> -----END PGP SIGNATURE-----
>
>