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

[From: Charles 'Buck' Krasic]

-----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-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: krasic.vcf
Type: text/x-vcard
Size: 389 bytes
Desc: not available
Url : http://lists.maemo.org/pipermail/maemo-developers/attachments/20060901/48a25818/attachment.vcf