On Tue, Mar 11, 2008 at 12:14 PM, Tim Chick <[EMAIL PROTECTED]> wrote: > On Tuesday 11 March 2008 08:08:32 Graeme Gregory wrote: > > On Tue, 11 Mar 2008 00:56:03 +0100 > > > > Stanislav Brabec <[EMAIL PROTECTED]> wrote: > > > PXA270 manual talks about 256kiB of RAM directly on the chip. Do > > > you know, whether it is used for any purpose just now and whether > > > it is faster than external memory? > > > > According to the manual it is, and they even give a suggestion of its > > use. Put the Y and U plane in SRAM and the V plane (because it doesnt > > fit) in DRAM. > > > > Richard Purdie has a patch in linux-rp that allows you to allocate > > SRAM, you just need to attach this to the pxa fb stuff. > > > That only works for 320x240 or so, and I've never seen a performance > problem at these resolutions anyway.
Well, it should still provide some speedup even for this resolution. Especially if you are trying to watch higher resolution videos downscaled to 320x240. > I think they were proposing to put the actual base fb in sram too: > > For YV12 320x240 you need 75kB for Y, and 18.75kB for each of U and V > > That's only 112.5kB > > If you had the main frame buffer of 320x240x16 bit that would be 150kB > > So if you had the base in SRAM, you would not be able to fit the base, > Y, U and V, so should put V in SDRAM. > > The system would probably be much happier like this - the whole problem > is the chip isn't really spec-ed to run at 640x480. If it was it would > have some more sram, Even putting just U and V planes to SRAM should improve performance somewhat. It would be interesting to see the impact on overall memory performance introduced by using 640x480 video mode. For example, you can benchmark standard memcpy function just copying data around (even not to or from the framebuffer). The difference between memcpy performance for 320x240 and 640x480 mode is interesting to see the effect of concurrency with screen update DMA. Also benchmarking mplayer with '-vo null' when different video modes active is interesting (to see the impact of screen update DMA on pure decoding performance). Such tests should provide some rough estimation of the potential benefit of moving some planes to SRAM. > and hardware scaling for the video. Software scaling can be very fast, and introduce only minor overhead (~10%). Having no hardware scaling support does not automatically make the device unsuitable for watching video. _______________________________________________ Angstrom-distro-users mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-users
