[EMAIL PROTECTED] wrote:
The OMAP 1510 has a internal Framebuffer - the framebuffer in the N770 is external (I think) and has to be accessed via the 16-bit memory bus. There are internal caches, but program code and the data has also to be transported via the 16-bit memory bus. Maybe that's the bottle neck. The OMAP has also just a 16-bit bus, but has a internal frame buffer, which may be accessed faster without blocking the external 16-bit bus.
I think you are mixing words internal and external for the same thing here. If I would stick to the word external then OMAP 1510 on Tungsten T2 has external framebuffer. It is in main SDRAM together with program code and data. You can't fit 320x320x16bit into onchip memory even without double buffering. LCD refreshes are sharing memory bus with everything else needing RAM. That's why Nokia devs needed really external framebuffer because LCD refreshes for 800x480x16bit would take a lot of bandwith. This means memory situation on N770 is even better than on T2. Yet T2 can do better with less caches, older architecture (armv4t without l and e), slower clock and using ARM core only (except the equivalent of N770 pcm dsptask in PalmOS sound driver).
On N770 you have to copy data to external framebuffer but you need to do only once for each pixel change so it is still a win. And by the nature of mpeg decompression you should know exactly which pixels need to change so you don't need to copy whole framebuffer each frame.
* Video hardware accelerators for DCT, iDCT, pixel interpolation, and motion estimation for video compression
<snip>
Since the DSP has hardware accelerators for (i)DCT etc I really think it should perform faster than the ARM cpu.
I would be interested to know what this means. I suppose it is just marketing talk for software implementation running on DSP. There are no public datasheets for 1710 on omap site, only for 5910 so I am not sure about this.
When talking about possible bottlenecks and guessing wildly, I would guess the bottleneck is overusing the DSP. When playing compressed audio and video it is constantly switching between multiple dsp tasks to do the job. I would guess the context switches on DSP are very costly when you consider also switching MMU mappings for DSP and communication needed with main CPU. Yet I guess only the mp4 decompression task would need the DSP alone without constant interruptions by other tasks.
But these are just guesses. We may know more in the future if Nokia decides to include multimedia into Maemo release. I would be interested in the source of the ARM side of gstreamer plugins that communicate with DSP tasks on N770.
Frantisek _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
