According to the SD problem: As far as I know emdete has noticed exactly what you assume. Reading from the SD while using the display heavily (in his case this was a VGA Edje/Evas gui) isn't really possible - the display will work, but the SD won't get any bandwith, so transfer will be extremely slow or stop completely.
On 4/24/08, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > On Thu, 24 Apr 2008 09:24:26 +0200 polz <[EMAIL PROTECTED]> babbled: > > > > On Thursday 24 April 2008 05:52:52 Carsten Haitzler wrote: > > > On Wed, 23 Apr 2008 18:28:40 +0200 thomasg <[EMAIL PROTECTED]> > babbled: > > > > > > yup. those 7m/sec (that's write to video ram) is also shared with SD > card > > > IO. > > Correct me if I'm wrong, but it seems to me that this means it should be > > impossible to playback videos in full-screen from an SD card on a gta02. > > 640*480*25 = 7680000 and that's with 8bpp. > > > > Has anyone tested video playback on a GTA02 yet ? > > > correct. yuv will be w * h * 1.5 bytes for 1 frame (standard video yuv). > so > 3240x240*1.5*30 (320x240 @ 30fps) = 3.4m/sec - BUT... when u are copying > you > have ZERO cpu cycles to decode the next video frame. so that means 50% of > cpu > cycles will be spent ONLY copying video data to video ram. the other 50% u > have > left to decode the mpeg1/2/4 or whatever video in system ram to a yuv > buffer. i > would say this is the realistic highest resolution you will get. > [EMAIL PROTECTED] > is the MOST you will get (6.9m/sec), but u have ZERO (or almost) cpu > cycles to > actually decode the video into yuv. > > remember here i am assuming use of xvideo and the yuv to rgb conversion > and > scaling on the glamo - which xglamo does support. if you do software > yuv->rgb + > scale then its even less fun. with software. the best u will get is 11fps > at > 640x480 - and this is NO cpu cycles to actually decode the video, convert > it to > 16bit rgb and scale. in reality i expect you to see 2-5fps in this > scenario, > maybe eve 1fps. > > this is ONLY playback if the video data is already in ram - ie the mpeg > data is > cached. if it is read off internal flash you will pay an IO cost - but > it's not > shared with the glamo bus. if it is on SD card - you will basically have > to now > share the IO between SD and graphics. i believe the graphics IO takes > precedence over SD card IO, so as long as u keep the glamo gfx bus busy, > sd > will be on hold until u stop. then some sd io can get through. > > with the glamo you need to be careful what you do and how you do it. if > you can > keep something entirely within the glamo - it should be ok. so things like > uploaded pixmaps and then blitting them around is ok. video decode is > another > matter entirely. the glamo has an mpeg4 decoder on it - but we don't have > any > api to access that directly/sanely and just feed it an mpeg4 stream. any > other > codec has to be done on the cpu anyway and uploaded across the bus as yuv > data. > > > -- > Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> > > > _______________________________________________ > Openmoko community mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/community >
_______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
