> As you may recall, I was considering this back in August/September.
> I tried a few things, and reported some of my findings to this list.
> The code for all that is still available here:
> http://qstream.org/~krasic/770/dsp/
<snip>
> > 2. Try using dsp tasks that already exist on the device and
> are used
> > for dspfbsink. But the sources of gst plugins contain code
> that limits
> > video resolution for dspfbsink. I wonder if this check was
> introduced
> > artificially or it is the limitation of DSP scaler and it
> can't handle
> > anything larger than that. Also I wonder if existing video
> scaler DSP
> > task can support direct rendering [2].
>
> I tried direct rendering in the above mentioned
> experimentation. I never got it to work exactly correctly,
> i.e. I could get images fragments on the screen, but they
> were not the whole image, and never
> in exactly the correct screen position. I suspected this was tied to
> the baroque memory addressing constraints of the DSP (e.g. 16bit data
> item limitations). I tried very hard to work around them but was not
> successful.
Was this the demo_fb task, or something different? I see that demo_console
has been compiled (in dspgw-3.3-dsp/apps/demo_mod), but I can't see demo_fb
having been compiled in situ (dspgw-3.3-dsp/apps/demo). If it was something
different, could you point me to the code please?
I ask as I'm trying to get the demo_fb code to work. Demo_console works fine
and outputs the message to the screen, but demo_fb complains with the
following message:
# ./demo_fb fbadr=300000
open: Device or resource busy
Anyone have any ideas why this might be? I assume this is caused by the
open() call in the arm-side demo_fb app (see dspgw-3.3-arm/apps/demo):
fd = open("/dev/dsptask/demo_fb", O_RDWR);
I'm just not sure what would cause the busy message when the demo_console
runs fine before and after I try demo_fb.
I altered the demo_fb.c code slightly to add an if defined() statement for
the Nokia 770, which I hope should set the screen dimensions correctly. I
must add that I've not tried it without this modification, but will do so
this evening to check.
I also pulled the framebuffer address out of /lib/dsp/avs_kernelcfg.cmd on
the 770. Is this the address I should use?
> > 3. Try implementing a new DSP based scaler from scratch. The most
> > important thing to know is how to access framebuffer
> directly from DSP
> > and move data to it from mapped buffer without any overhead.
> > The first test implementation can just perform nonscaled planar
> > YV12 -> packed YUV422 conversion, if it proves to be fast
> and useful,
> > it could be extended to also support scaling.
> >
> This is what I did in August. I did YUV -> YUV scaling plus RGB
> conversion on the DSP. I think I did YUV->YUV scaling later. The
> results (performance) were abysmal. Maybe I committed some mortal
> DSP programming sins that dragged the performance down, but it was soo
> slow I gave up even hoping. I think my DSP code was maxed out on the
> DSP at like 20 fps, where the ARM was able to do 24fps with
> about 10-20% cpu.
>
> Anyway, my code is still there which may be a start if you want to
> attempt it. However, I think your first option is probably the most
> fruitful option. My little project made me very cynical of the
> value of the DSP. ;-)
Again, could you give me a pointer to the directory under which to find this
code?
Thanks,
Simon
_______________________________________________
maemo-developers mailing list
[email protected]
https://maemo.org/mailman/listinfo/maemo-developers
