Active Topics

 


Page 2 of 2 1 2
Reply
Thread Tools
Serge is offline Serge
2007-11-18 , 16:40
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#11
Originally Posted by Moonshine View Post
Any chance you could explain the last sentence a bit more? I'm not sure I understand.
It's just 'lower != low'.

CPU performance becomes a limiting factor even for resolutions lower than 800x480, for example 640x480 or 704x400. And these video resolutions stress graphics bus less than 800x480. So while graphics bus does not have any 'margin of safety', we are at the point where video output performance is (barely) enough to sustain needed framerate.

Are you saying that now that the framebuffer driver is fixed, the CPU become the limiting factor most of the time? Even on low resolution video (ie. 320x240)
I'm saying that video output is not introducing any troubles for low video resolutions at all. While CPU power may be or may be not sufficient depending on the codec, the settings used for encoding and bitrate.
 

The Following 3 Users Say Thank You to Serge For This Useful Post:
jmk is offline jmk
2007-11-18 , 16:57
Posts: 144 | Thanked: 21 times | Joined on Mar 2007 @ Finland
#12
Serge, what is the status of Mplayer port for OS2008? I bet it is one of the most wanted apps.
 
Serge is offline Serge
2007-11-18 , 17:05
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#13
Originally Posted by jmk View Post
Serge, what is the status of Mplayer port for OS2008? I bet it is one of the most wanted apps.
I hope to release a package for OS2008 in a few hours. Have been tweaking code since morning today. MPlayer is basically working, but there are still numerous small issues. I'll post a separate thread with announcement once the package is ready to test.
 
dblank is offline dblank
2007-11-18 , 18:09
Posts: 465 | Thanked: 149 times | Joined on Oct 2007
#14
Originally Posted by igor View Post
Where did you get this information from? We are already using speed-binned processors to get 400MHz and I'm not aware of TI providing any higher option.
http://focus.ti.com/pdfs/wtbu/TI_omap2420.pdf

Isn't that what the N800 uses? I also seem to remember posts about it in the forums.
 
igor's Avatar
igor is offline igor
2007-11-18 , 22:25
Posts: 198 | Thanked: 273 times | Joined on Jan 2006 @ Helsinki, Finland
#15
Originally Posted by dblank View Post
http://focus.ti.com/pdfs/wtbu/TI_omap2420.pdf

Isn't that what the N800 uses? I also seem to remember posts about it in the forums.
And if you read the pdf from the link you sent, you can see that the highest standard frequency is 330MHz.

As I said we are using a speed sorted type of 2420, which is validated for using the ARM core @400MHz, but that's it. Higher core frequencies would also end up forcing higher dividers on the L3 bus and that would lower the memory clock.

Of course you can play with the dividers and I'll probably setup a page about it when I have some spare time and the code is officially out, but there are quite good chances to wipe the flash and without the means to coldflash the device, you end up with a nice brick.

The most interesting change would probably be to run the system at the (unsupported) configuration ARM@400, DSP@266, which would make it possible to avoid the current weird op selection mechanism.
 

The Following 2 Users Say Thank You to igor For This Useful Post:
dblank is offline dblank
2007-11-19 , 05:03
Posts: 465 | Thanked: 149 times | Joined on Oct 2007
#16
Originally Posted by igor View Post
And if you read the pdf from the link you sent, you can see that the highest standard frequency is 330MHz.
The pdf doesn't seem to say much, but I don't see where it says the highest standard freq is 330MHz, I just saw this:
"ARM11 architecture from 330 MHz to 1 GHz"

but this brief document doesn't mention anything more about 1GHz, or what kind of drawbacks there are running at this speed.
 
Serge is offline Serge
2007-11-19 , 07:55
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#17
Originally Posted by ragnar View Post
The CPU and DSP speeds are (effectively) tied together. A faster CPU speed drops the available DSP speed. So you would see in some DSP heavy applications the CPU speed going back to 330mhz.
Does CPU speed go back to 330MHz only for dsp tasks which really require DSP core running at more than 133MHz? For example dsppcm task will be running for any application producing sound output but it is hardly computationally intensive on DSP side. Are there many dsp tasks which require more than 133MHz?
 
ragnar is offline ragnar
2007-11-19 , 08:34
Posts: 631 | Thanked: 1,123 times | Joined on Sep 2005 @ Helsinki
#18
Originally Posted by Serge View Post
Does CPU speed go back to 330MHz only for dsp tasks which really require DSP core running at more than 133MHz? For example dsppcm task will be running for any application producing sound output but it is hardly computationally intensive on DSP side. Are there many dsp tasks which require more than 133MHz?
Igor can probably answer this one best, but afaik it's done so that 400/133mhz is the default in which OS2008 runs and then certain applications can call for the higher DSP value, for instance some RTCOMM apps seem to do this. So yes, I think it's not for all DSP usage.
 
lardman is offline lardman
2007-11-19 , 10:05
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#19
The most interesting change would probably be to run the system at the (unsupported) configuration ARM@400, DSP@266, which would make it possible to avoid the current weird op selection mechanism.
This sounds interesting, I look forward to seeing your page on the dividers.

Are there many dsp tasks which require more than 133MHz?
We could always work it out by testing I suppose. If Nokia could tell us the dsp cpu load profile that would be even better
 
Reply
Page 2 of 2 1 2

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 21:12.

Contact Us - Home - Archive - Top