Re: Xsp pixel-doubling solutions for Nokia 770?
On Monday 30 April 2007 12:26, Frantisek Dufka wrote: > Daniel Stone wrote: > > Specifying that pixels must be exactly _doubled_ is a > > hack around both the performance issues and a lack of resolution > > independence. Apparently an important one, if you happen to like SDL > > games, but a hack nonetheless. > > Yes limiting ourselves to doubling is bad. Why not to add custom ratio > if N800 can do that. > > This all leads to request to have some more advanced gaming API. Sadly > this is probably not what internet tablets are currently designed for. > Gamers are big target group and this device is meant for entertainment > so maybe extending target audience to gamers in not that bad idea. > Gaming devices are moving online too so this is direct competition. Why > to buy internet tablet if better Sony or Nintendo device in future will > do this too plus gaming. Unfortunately gaming business has complicated > rules similar in complexity to devices with GSM radio. BTW are internet > tablets in same Nokia multimedia division as N-Gage? Well, SDL is to some extent this advanced gaming API, its current implementation for Nokia 770/N800 is just poor. As for pixel doubling, a practical solution would be just to support 400x240 fullscreen resolution in SDL so that no extra hack would be required when porting each game or emulator in particular. N800 hardware probably makes it possible to set any resolution up to 800x480, with all this available using standard SDL API. Having support for both pixel doubled and normal graphics in the same game may be useful, but it will require extra efforts when porting games, while low resolution may already work out of the box without doing any tweaks to the sources. Let's try the simple solution first. The very first step would be to take Nokia 770 xserver and SDL sources and tweak them until setting 400x240 fullscreen resolution works transparently for any SDL applications. Anybody up to this task? Also it would be a good idea to benchmark SDL, identify maemo or ARM architecture related bottlenecks and try to fix them. Many older generation games worked perfectly on hardware way slower than Nokia 770. So Nokia 770 may be a good platform for mobile gaming if properly optimized (though I'm not sure about realtime games because of unsuitable controls). I could probably do these optimizations myself, but have quite a limited amount of free time available for free software development. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote: Looks like I have to reply to myself. > On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote: > > Applied and build without problems for me. > > Thanks a lot for building the package and putting it for download, > everything seems to be fine, but more details will follow below. [snip] > Anyway, the new xserver package works really good. If we do some tests with > the standard Nokia_N800.avi video clip, we get the following results with > the patched xserver: > > # mplayer -benchmark -quiet -noaspect Nokia_N800.avi > BENCHMARKs: VC: 29,764s VO: 7,666s A: 0,468s Sys: 64,635s = 102,534s > BENCHMARK%: VC: 29,0287% VO: 7,4767% A: 0,4565% Sys: 63,0381% = 100,% > BENCHMARKn: disp: 2504 (24,42 fps) drop: 0 (0%) total: 2504 (24,42 fps) > > # mplayer -benchmark -quiet -noaspect -dr -nomenu Nokia_N800.avi > BENCHMARKs: VC: 30,266s VO: 5,490s A: 0,467s Sys: 66,286s = 102,509s > BENCHMARK%: VC: 29,5255% VO: 5,3554% A: 0,4560% Sys: 64,6631% = 100,% > BENCHMARKn: disp: 2501 (24,40 fps) drop: 0 (0%) total: 2501 (24,40 fps) > > Results with unpatched xserver and some more explanations can be found in > [3]. > Yes, now N800 is faster than Nokia 770 for video output performance at > last :) Well, still not everything is so good until the following bug gets fixed: https://maemo.org/bugzilla/show_bug.cgi?id=1281 The patch for optimized Xv performance will not help to watch widescreen video which triggers this tearing bug. If you see tearing on the screen, you should know that the YUV420 color format conversion optimization patch does not get used at all and xserver most likely uses a slow nonoptimized YUV422 fallback code with software scaling. Fixing this bug is critical for video playback performance. I hope it will be solved in the next version of N800 firmware too. But it we get some patch to solve this problem for testing earlir, that would be nice too. > Video output overhead on N800 is really at least halved. Of course, video > output takes only some fraction of time in video player. So overall > performance improvement for Nokia_N800.avi playback is approximately 20% > but not 250%-300% which can be observed for 'omapCopyPlanarDataYUV420' > function alone. Before anybody noticed, correcting myself :) This 'omapCopyPlanarDataYUV420' has 2.5x-3x improvement which is equal to 150%-200% in percents. Elementary arithmetics is tough when you are tired ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Standard widget spacing and padding?
On Mon, 2007-04-23 at 16:39 +0300, ext Murray Cumming wrote: > Did you discover anything? Sorry to bug you, but I still feel sure > that > some document exists somewhere. Let's move this to Documenting widget spacing requirements https://maemo.org/bugzilla/show_bug.cgi?id=1280 Murray, please CC yourself there. Thanks. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
On 5/1/07, Daniel Amelang <[EMAIL PROTECTED]> wrote: On 5/1/07, Daniel Amelang <[EMAIL PROTECTED]> wrote: > > about using ldmia/stdmia instructions to cluster sequential that was supposed to be "ldmia/sdmia", sorry. Gah, "ldmia/stmia", final answer. Dan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
On 5/1/07, Daniel Amelang <[EMAIL PROTECTED]> wrote: about using ldmia/stdmia instructions to cluster sequential that was supposed to be "ldmia/sdmia", sorry. Dan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
On 4/30/07, Daniel Stone <[EMAIL PROTECTED]> wrote: > There are two important optimizations in this code: > 1. Cache prefetch with PLD instruction (added in '_armv5' version) which > boosts performance to 70 megapixels per second. Inner loop is unrolled > to process 32 pixels per iteration (cache line size is 32 bytes on ARM, so > such unrolling is convenient). This is the most important improvement. > You can try using __builtin_prefetch() from C code to do the same > optimization. Ah, sounds useful. From what Dan Amelang's been saying on xorg@, gcc should coalesce four 32-bit reads into one 128-bit read, but this sounds promising as well. To expand on this: I was referring to fact that gcc is pretty smart about using ldmia/stdmia instructions to cluster sequential reads/writes. I see that Siarhei is already using this technique in his assembler code, so nothing new here. Dan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Documenting maemo pearls (was Re: N800 & Video playback)
On Tue, 2007-05-01 at 03:29 -0300, ext Gustavo Sverzut Barbieri wrote: > Daniel, Siarhei, Eero: I always find your mails to provide great deal > of tech information about N800. What a coincidence, me too. ;) > However we do not have a central place > with these information, it would be great if you guys setup a wiki > page with tech details about drivers, optimizations and weakness of > current implementations so others could base work on. Indeed. But knowing about the day to day of these busy guys I kind of understand why things they write instantly in an email can't be easily reproduced by themselves in a more formal way. But we do want to have all these pearls available in a structured way in maemo.org. Easing web publishing is a step, partially covered now by the Midgard CMS integration. Providing an appropriate content structure is a next step (I'm responsible of). Having that doc manager in place will definitely help, as well, as making sure that every relevant component in our architecture is officially covered by someone of the team (still working on this). Until then we will keep getting busy developers really sensitive to openness and dialog, finding some spare time to answer questions and fill indirectly the gaps in our documentation. ... Said that, there is nothing stopping anyone from collecting these pearls in the maemo.org wiki. ;) -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Next steps in the future of our beloved Nokia 770
Hi, On Mon, 2007-04-30 at 21:55 +0200, ext Frantisek Dufka wrote: > So what is the future, do you want just fix bugs or can this be used as > a test bed of future device vs OS independence? > > As there are probably more devices in the pipeline and some will > definitely run same major version of OS but have different hardware this > problem must be solved in future anyway. Yes, in fact we are working already on device vs OS independence (i.e. integrating HAL or Hildon scalability), being IT OS 2007 and the N800 our targets. There are other technical processes going on around the improvement of the IT OS & maemo architecture. This is one of the reasons why the story of the N800 will be different than 770's. It is really out of my scope and technical knowledge how much of this work done for the IT OS 2007 can be made available in the Hacker edition. Carlos (and probably also prominent maemo hackers like yourself) will know much better. My blind guess is that the community effort will be important to make all this happen in the 770 & hacker edition. > How we can reflect this with > maemo SDK and repository structure? Looks like there are such things as > subarchitecture and flavors in Debian. > http://www.debian.org/releases/stable/powerpc/ch02s01.html.en Looks like we have some Debian developers in the house and we are familiar with this paradigm. :) It is not trivial to incorporate this (or a similar repository-based structure) to our current setup, though. It has remarkable technical challenges per se, and it has also additional challenges for our current development process and business context. The question is how far we can and want to go (and how). This is an uneasy discussion we are having now. But well, it is not a coincidence that we are using Debian as upstream project, packaging system, APT, etc. The public roadmap already lists features like system meta package and automatic codec installer that go in this direction of flexibility in system components compared to the release of monolithic FIASCO images. So we are progressing. > I have reported the top of the iceberg as a bug here > https://garage.maemo.org/tracker/index.php?func=detail&aid=804&group_id=164&atid=681 > But it needs some thinking. How can developers target specific devices > with same OS but different hardware? Some developers may already take > eqaution Bora = N800 as granted which means some packages will not run > on n770 due to compiler flags and other hw specific assumptions. I guess this shows that the software architecture needs some fixes and improvement, as well as some of our processes. Again, it is out of my scope and current knowledge how much of this have we already solved and are aware of. I tend to be optimistic but filing bugs is always a good method to make sure your points are taken. Again, we want to provide one day this software vs hardware detachment. This means your points are fully on topic. It is probably too early to know how much of this will end up benefiting the 770, though. I hope we are able to build a story of collaboration together. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
Frantisek Dufka wrote: [sbox-SDK_ARMEL: ~/x/xorg-server-1.1.99.3] > patch -p1 <../xomap_yuv420patch.diff patching file hw/kdrive/omap/Makefile.am Hunk #1 FAILED at 1. Hunk #2 FAILED at 34. 2 out of 2 hunks FAILED -- saving rejects to file hw/kdrive/omap/Makefile.am.rej patching file hw/kdrive/omap/omap_colorconv.h patching file hw/kdrive/omap/omap_colorconv.S patching file hw/kdrive/omap/omap_video.c Hunk #1 FAILED at 39. Hunk #2 FAILED at 468. Hunk #3 FAILED at 491. 3 out of 3 hunks FAILED -- saving rejects to file hw/kdrive/omap/omap_video.c.rej Sorry, my fault, mystery solved. Saved attachement in Thunderbird in Windows XP, then moved to Ubuntu inside VMware. The problem was caused by DOS CR+LF line endings, patch doesn't like it. Recoded to unix linefeeds and now it applies cleanly. I'm using Windows a lot, it is strange this never happened to me yet. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: qemu gentoo based cd
Hello It has been an while but I did not give up yet! Here is the first version of the qemu image http://box.mmapps.net/~keesj/qemu_maemo_gentoo/ It supports both the 2.2 sdk and 3.1. I hope it will help ease the development of 770 and n800 supporting apps. greetings On 4/7/07, Kees Jongenburger <[EMAIL PROTECTED]> wrote: On 3/31/07, Kees Jongenburger <[EMAIL PROTECTED]> wrote: > Hi > > I am creating a gentoo based qemu image for maemo development > I want to support at least version SDK 2.1 and 3.1 of the maemo sdk. > The rationale is quite simple I want it for the MUD project so we can > build binaries Hello I have now setup a demo of a web based qemu based maemo sdk (2.2 and 3.1) on http://mud.mmapps.net/ I guess that the idea is to provide a build environment for mud packages where people can test if the package can build in a clear environment. I did not give it much testing yet, But I think it works :) Next steps would be to setup kernel targets.This "distro" was created with scripts and uses a cow file system to keep the original image intact so feel free to poke around but don't expect speed (I have a broken wireless network) greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote: > > OK, here is this untested a patch for xserver to add ARMv6 optimized > > YUV420 color format conversion. Theoretically it should compile > > (I did not try to build xserver myself though) and work. If it refuses to > > compile, fixing the patch should be not too difficult. > > Applied and build without problems for me. Thanks a lot for building the package and putting it for download, everything seems to be fine, but more details will follow below. > For testing, I fabricated some video with gstreamer: > > which resulted in [EMAIL PROTECTED] and [EMAIL PROTECTED] videos. For some > reason 320x240 and 352x288 refused to play with: > > X11 error: BadValue (integer parameter out of range for operation) > MPlayer interrupted by signal 6 in module: flip_page while gstreamer did > play them just fine. Also the Nokia_N800.avi and NokiaN93.avi died in the > same way. This X11 error on video playback start and also sometimes on switching fullscreen/windowed mode is a known problem [1] reported in this mailing list. If MPlayer dies on start, usually trying to start it again succeeds. So these 320x240 and 352x288 videos could be played as well if you were a bit more persistent :) As Daniel replied in one of the followup messages, it is most likely some race condition. The question is which code is a suspect. Is it MPlayer Xv video output code that has been around for ages and worked fine on different systems or relatively new Xv extension code from N800 xserver? In addition, a previous revision of N800 firmware had a serious bug [2] related to video playback. It should be noted, that MPlayer needed only about 1 minute to freeze on the initial N800 firmware. So the problem could be identified much more easily if MPlayer was included in the standard set of tests done by Nokia QA staff before each new IT OS release. Surely, Nokia is only interested in a properly working xvimagesink for the software included in IT OS by default. But testing with more client applications can improve overall xserver quality. With all that said, I don't know if MPlayer Xv code is bugfree, it wasn't me who developed it. > My mplayer is compiled from the svn > trunk of the garage project, with some additional cflags I use (so > maybe those were the problem...). Do you have a set of cflags settings which work better than the default set? Can you share this information? > There's something fishy in the decoding or something as the color bars > in the test video were broken (yellow and cyan to be precise), but > that seemed to be the case in a "vanilla" image too so nothing to do > with this patch. I could not see any other glitches in the output. > > But on to the results: > > VIDEO: [DX50] 640x480 24bpp 30.000 fps 1597.6 kbps (195.0 kbyte/s) [snip] > VIDEO: [DX50] 800x480 24bpp 30.000 fps 1976.5 kbps (241.3 kbyte/s) [snip] > There is a clear drop in amount of time used to output the videos for > 800x480 (the numbers were stable trough multiple runs). > > So I gather from the >10s benchmark time that we didn't get to real > time yet, but close to it? And of course this is just video, audio > decoding should be considered for real video playback performance > measurement. These videos are way too heavy for N800 to decode and play in realtime. We may expect playback for videos up to 640x480 resolution with <1000kbps bitrate and 24fps. This is probably current realistic limit which can be achieved. Some minor variations to these parameters are possible (for example we can get 30fps, but should also reduce resolution or bitrate, etc.). If you want a guaranteed video playback with divx/xvid/mpeg4 codecs, you should restrict to 512x384 resolution or lower and keep bitrate reasonable. The results for these 'insane' videos you have posted are somewhat weird, a complete statistics would require also a number of frames dropped, otherwise we don't know how much work was done by the player. Probably missing audio track resulted in MPlayer not being able to provide a proper report. Don't know. Also it is strange that you did not see any improvement at all for 640x480 video, are you sure you really tested it with the patched xserver? Anyway, the new xserver package works really good. If we do some tests with the standard Nokia_N800.avi video clip, we get the following results with the patched xserver: # mplayer -benchmark -quiet -noaspect Nokia_N800.avi BENCHMARKs: VC: 29,764s VO: 7,666s A: 0,468s Sys: 64,635s = 102,534s BENCHMARK%: VC: 29,0287% VO: 7,4767% A: 0,4565% Sys: 63,0381% = 100,% BENCHMARKn: disp: 2504 (24,42 fps) drop: 0 (0%) total: 2504 (24,42 fps) # mplayer -benchmark -quiet -noaspect -dr -nomenu Nokia_N800.avi BENCHMARKs: VC: 30,266s VO: 5,490s A: 0,467s Sys: 66,286s = 102,509s BENCHMARK%: VC: 29,5255% VO: 5,3554% A: 0,4560% Sys: 64,6631% = 100,% BENCHMARKn: disp: 2501 (24,40 fps) drop: 0 (0%) total: 2501 (24,40 fps) Results with
Re: Next steps in the future of our beloved Nokia 770
Am Montag, 30. April 2007 21:55 schrieb Frantisek Dufka: > How we can reflect this with > maemo SDK and repository structure? Looks like there are such things as > subarchitecture and flavors in Debian. > http://www.debian.org/releases/stable/powerpc/ch02s01.html.en Good point, Frantisek. I found it quite frustrating when I found out the maemo-mapper (bora version) illegal instruction was because it used some arm11 features and was not running for that reason on my n770. A debian like repository structure would help here a lot. Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Localhost unavailable when wi-fi offline or not connected
Hi, I have a Wiki running on my N800 using the usual configuration (for many applications) of a TCP/IP server running on the local host address (127.0.0.1) and an TCP/IP client on the same device. (In this case an HTTP web server and the Opera browser.) While trying to test this on an aeroplane at the weekend -- with Wi-Fi offline, of course -- the browser would not connect to the server. I've since experimented further and find a similar (or the same) problem occurs online if no Wi-Fi connection is active. This is a showstopper for my application as it means I cannot easily view my data unless online and connected -- is there a fix/workaround? Thanks -- mfc ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
2007/5/1, Kalle Vahlman <[EMAIL PROTECTED]>: The server *should* be compiled with '-mcpu=arm1136j-s -mfpu=vfp -mfloat-abi=softfp -O2', but as I had troubles with the SBOX_EXTRA_COMPILER_ARGS env var being honored some time ago I'm not guaranteeing it at the moment ;) Actually seems that I had added the env var to the rules file so it *is* built with those options. I can produce a build without them if need be (it does affect performance in my experience, so if one wants to see the impact of that patch on a more "normal" version...). -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
2007/5/1, Siarhei Siamashka <[EMAIL PROTECTED]>: On Tuesday 01 May 2007 13:36, Kalle Vahlman wrote: > 2007/5/1, Siarhei Siamashka <[EMAIL PROTECTED]>: > > OK, thanks. It may take some time though. I'm still using old scratchbox > > with mistral SDK here (did not have enough free time to upgrade yet). > > Until I clean up my scratchbox mess, I can only provide some patch > > without testing, if anybody courageous can try to build it :) > > Given that I fear not the perils of building a X server with > nonstandard options[1], I shall be more than happy to conduct such > adventurous acts :) > > And unless Mr. Kulve has objections, the results could be installed > from a repository as well. > > [1] > http://syslog.movial.fi/archives/47-Shadows-for-everyone-well,-not-really.html OK, here is this untested a patch for xserver to add ARMv6 optimized YUV420 color format conversion. Theoretically it should compile (I did not try to build xserver myself though) and work. If it refuses to compile, fixing the patch should be not too difficult. Applied and build without problems for me. For testing, I fabricated some video with gstreamer: gst-launch-0.10 videotestsrc num-buffers=300 \ ! "video/x-raw-yuv, width=640, height=480" \ ! ffenc_mpeg4 ! avimux \ ! filesink location=640x480.avi which resulted in [EMAIL PROTECTED] and [EMAIL PROTECTED] videos. For some reason 320x240 and 352x288 refused to play with: X11 error: BadValue (integer parameter out of range for operation) MPlayer interrupted by signal 6 in module: flip_page while gstreamer did play them just fine. Also the Nokia_N800.avi and NokiaN93.avi died in the same way. My mplayer is compiled from the svn trunk of the garage project, with some additional cflags I use (so maybe those were the problem...). Anyway, then I shut down af-base-apps and matchbox (to avoid scaling the video) and ran "mplayer -benchmark ". In the worst case only video playback may be broked. But if everything works as expected, video output performance should become a lot better. Video output performance can be tested by mplayer using -benchmark option, 'VO:' stat shows how much time was used for video output, 'VC:' stat shows how much time was used for video decoding. There's something fishy in the decoding or something as the color bars in the test video were broken (yellow and cyan to be precise), but that seemed to be the case in a "vanilla" image too so nothing to do with this patch. I could not see any other glitches in the output. But on to the results: VIDEO: [DX50] 640x480 24bpp 30.000 fps 1597.6 kbps (195.0 kbyte/s) Original: V: 10.0 300/300 44% 74% 0.0% 0 0 0% BENCHMARKs: VC: 4.387s VO: 7.436s A: 0.000s Sys: 0.482s = 12.305s BENCHMARK%: VC: 35.6503% VO: 60.4311% A: 0.% Sys: 3.9185% = 100.% Patched: V: 10.0 300/300 42% 72% 0.0% 0 0 0% BENCHMARKs: VC: 4.213s VO: 7.265s A: 0.000s Sys: 0.381s = 11.859s BENCHMARK%: VC: 35.5296% VO: 61.2604% A: 0.% Sys: 3.2100% = 100.% --- VIDEO: [DX50] 800x480 24bpp 30.000 fps 1976.5 kbps (241.3 kbyte/s) Original: V: 10.0 300/300 54% 114% 0.0% 0 0 0% BENCHMARKs: VC: 5.466s VO: 11.456s A: 0.000s Sys: 0.366s = 17.287s BENCHMARK%: VC: 31.6179% VO: 66.2677% A: 0.% Sys: 2.1144% = 100.% Patched: V: 10.0 300/300 53% 70% 0.0% 0 0 0% BENCHMARKs: VC: 5.346s VO: 7.043s A: 0.000s Sys: 0.449s = 12.838s BENCHMARK%: VC: 41.6414% VO: 54.8602% A: 0.% Sys: 3.4984% = 100.% There is a clear drop in amount of time used to output the videos for 800x480 (the numbers were stable trough multiple runs). So I gather from the >10s benchmark time that we didn't get to real time yet, but close to it? And of course this is just video, audio decoding should be considered for real video playback performance measurement. If any of you can build xserver package with this patch, please put it for download somewhere or send directly to me. I put the deb up at: http://iki.fi/zuh/xserver-xomap_1.1.99.3-0.zuh2_armel.deb until I get it to the repository. This version also has the composite extension enabled, but AFAIK it does not depend on the libs or change server behaviour if composite is not specifically used. The server *should* be compiled with '-mcpu=arm1136j-s -mfpu=vfp -mfloat-abi=softfp -O2', but as I had troubles with the SBOX_EXTRA_COMPILER_ARGS env var being honored some time ago I'm not guaranteeing it at the moment ;) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
Siarhei Siamashka wrote: OK, here is this untested a patch for xserver to add ARMv6 optimized YUV420 color format conversion. Theoretically it should compile (I did not try to build xserver myself though) and work. If it refuses to compile, fixing the patch should be not too difficult. It does not apply for me but should be trivial to fix. [sbox-SDK_ARMEL: ~/x/xorg-server-1.1.99.3] > patch -p1 <../xomap_yuv420patch.diff patching file hw/kdrive/omap/Makefile.am Hunk #1 FAILED at 1. Hunk #2 FAILED at 34. 2 out of 2 hunks FAILED -- saving rejects to file hw/kdrive/omap/Makefile.am.rej patching file hw/kdrive/omap/omap_colorconv.h patching file hw/kdrive/omap/omap_colorconv.S patching file hw/kdrive/omap/omap_video.c Hunk #1 FAILED at 39. Hunk #2 FAILED at 468. Hunk #3 FAILED at 491. 3 out of 3 hunks FAILED -- saving rejects to file hw/kdrive/omap/omap_video.c.rej Will try this evening. I wonder who has older x server version. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
On Tuesday 01 May 2007 13:36, Kalle Vahlman wrote: > 2007/5/1, Siarhei Siamashka <[EMAIL PROTECTED]>: > > OK, thanks. It may take some time though. I'm still using old scratchbox > > with mistral SDK here (did not have enough free time to upgrade yet). > > Until I clean up my scratchbox mess, I can only provide some patch > > without testing, if anybody courageous can try to build it :) > > Given that I fear not the perils of building a X server with > nonstandard options[1], I shall be more than happy to conduct such > adventurous acts :) > > And unless Mr. Kulve has objections, the results could be installed > from a repository as well. > > [1] > http://syslog.movial.fi/archives/47-Shadows-for-everyone-well,-not-really.html OK, here is this untested a patch for xserver to add ARMv6 optimized YUV420 color format conversion. Theoretically it should compile (I did not try to build xserver myself though) and work. If it refuses to compile, fixing the patch should be not too difficult. In the worst case only video playback may be broked. But if everything works as expected, video output performance should become a lot better. Video output performance can be tested by mplayer using -benchmark option, 'VO:' stat shows how much time was used for video output, 'VC:' stat shows how much time was used for video decoding. Built-in video player also should become faster. I don't know if this improvement can be 'scientifically' benchmarked, but it should drop less frames on high resolution video playback. If any of you can build xserver package with this patch, please put it for download somewhere or send directly to me. Thanks. diff -u -r -N xorg-server-1.1.99.3/hw/kdrive/omap/Makefile.am xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/Makefile.am --- xorg-server-1.1.99.3/hw/kdrive/omap/Makefile.am 2007-03-05 16:17:32.0 +0200 +++ xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/Makefile.am 2007-05-01 15:04:43.0 +0300 @@ -1,5 +1,5 @@ if XV -XV_SRCS = omap_video.c +XV_SRCS = omap_video.c omap_colorconv.S omap_colorconv.h endif if DEBUG @@ -34,4 +34,4 @@ $(TSLIB_FLAG) \ $(DYNSYMS) -EXTRA_DIST = omap_video.c +EXTRA_DIST = omap_video.c omap_colorconv.S omap_colorconv.h diff -u -r -N xorg-server-1.1.99.3/hw/kdrive/omap/omap_colorconv.h xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/omap_colorconv.h --- xorg-server-1.1.99.3/hw/kdrive/omap/omap_colorconv.h 1970-01-01 03:00:00.0 +0300 +++ xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/omap_colorconv.h 2007-05-01 15:06:13.0 +0300 @@ -0,0 +1,45 @@ +/* + * Copyright © 2007 Siarhei Siamashka + * + * Permission to use, copy, modify, distribute and sell this software and its + * documentation for any purpose is hereby granted without fee, provided that + * the above copyright notice appear in all copies and that both that + * copyright notice and this permission notice appear in supporting + * documentation, and that the names of the authors and/or copyright holders + * not be used in advertising or publicity pertaining to distribution of the + * software without specific, written prior permission. The authors and + * copyright holders make no representations about the suitability of this + * software for any purpose. It is provided "as is" without any express + * or implied warranty. + * + * THE AUTHORS AND COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO + * THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND + * FITNESS, IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR + * ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER + * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF + * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + * + * Author: Siarhei Siamashka <[EMAIL PROTECTED]> + */ + +/* + * ARMv6 assembly optimized color format conversion functions + * (planar YV12 to some custom YUV420 format used by graphics chip in Nokia N800) + */ + +#ifndef _OMAP_COLORCONV_H_ +#define _OMAP_COLORCONV_H_ + +#include + +/** + * Convert a line of pixels from YV12 to YUV420 color format + * @param dst - destination buffer for YUV420 pixel data, it should be at least 16-bit aligned + * @param src_y - pointer to Y plane, it should be 16-bit aligned + * @param src_c - pointer to chroma plane (U for even lines, V for odd lines) + * @param w - number of pixels to convert (should be multiple of 4) + */ +void yv12_to_yuv420_line_armv6(uint16_t *dst, const uint16_t *src_y, const uint8_t *src_c, int w); + +#endif diff -u -r -N xorg-server-1.1.99.3/hw/kdrive/omap/omap_colorconv.S xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/omap_colorconv.S --- xorg-server-1.1.99.3/hw/kdrive/omap/omap_colorconv.S 1970-01-01 03:00:00.0 +0300 +++ xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/omap_colorconv.S 2007-05-01 15:06:36.0 +0300 @@ -0,0 +1,244 @@ +/* + * Copyright ©
Re: N800 & Video playback
2007/5/1, Siarhei Siamashka <[EMAIL PROTECTED]>: On Monday 30 April 2007 17:49, Daniel Stone wrote: > It's completely safe to upgrade from a deb if it's not broken. If you > set up a standard Maemo build environment and run apt-get source > xorg-server and apt-get build-dep xorg-server, it should work just fine, > in theory. > > I don't have any tips, per se. Once I get it all integrated it'll be in > git, but for now, the only public source is the packages. OK, thanks. It may take some time though. I'm still using old scratchbox with mistral SDK here (did not have enough free time to upgrade yet). Until I clean up my scratchbox mess, I can only provide some patch without testing, if anybody courageous can try to build it :) Given that I fear not the perils of building a X server with nonstandard options[1], I shall be more than happy to conduct such adventurous acts :) And unless Mr. Kulve has objections, the results could be installed from a repository as well. [1] http://syslog.movial.fi/archives/47-Shadows-for-everyone-well,-not-really.html -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
On Monday 30 April 2007 17:49, Daniel Stone wrote: > > ARMv6 optimized YV12->YUV420 convertor is about 2.5x faster > > than current code used in N800 xserver. So it should provide a nice > > improvement for video :) > > Indeed. Unfortunately this is slightly misleading in that it only shows > the raw write speed. RFBI can't deal with the sorts of speeds that your > hyper-optimised version is pumping out, e.g. So it's mainly just about > cutting the latency into the critical path to low enough that it makes > no difference. The 'framebuffer' is just the ordinary system memory, converting color format and copying data to framebuffer will be done with the same performance as simulated in this test. RFBI performance is only critical for asynchronous DMA data transfer to LCD controller which does not introduce any overhead and is performed at the same time as ARM core is doing some other work (decoding the next frame). RFBI performance matters only if data transfer to LCD is still not complete at the time when the next frame is already decoded and is ready to be displayed. When playing video, ARM core and LCD controller are almost always working at the same time performing different tasks in parallel. I think I had already explained these details in [1] Well, as xomap server is probably compiled for thumb, tried to compile this test program for thumb instructions set as well and got the following results (thumb is slower than normal ARM), also fixed some bug in test program which resulted in memory throughoutput statistics being slightly off, so the following results should be final now: # gcc -o test_colorconv -O2 -mthumb test_colorconv.c arm_colorconv.S # ./test_colorconv test: 'yv12_to_yuv420_xomap', time=9.493s, speed=25.394MP/s, memwritespeed=38.091MB/s test: 'yv12_to_yuv420_xomap_nobranch', time=8.516s, speed=28.306MP/s, memwritespeed=42.460MB/s test: 'yv12_to_yuv420_line_arm_', time=4.736s, speed=50.895MP/s, memwritespeed=76.343MB/s test: 'yv12_to_yuv420_line_armv5_', time=3.395s, speed=71.011MP/s, memwritespeed=106.517MB/s test: 'yv12_to_yuv420_line_armv6_', time=2.876s, speed=83.817MP/s, memwritespeed=125.726MB/s If you remember the information posted in [2], mplayer used 12 seconds for video output when playing Nokia_N800.avi (it contains the same number of frames of the same size as used in this test for benchmarking). Color format conversion code taken from xserver and compiled for thumb uses 9.5 seconds for doing the same amount of work. So now the results of the tests are consistent - when doing video output, most of ARM core cycles are spent in this 'omapCopyPlanarDataYUV420' function. Optimizing it using 'yv12_to_yuv420_line_armv6' will definitely provide a huge effect, video output overhead when using Xv will be at least halved providing more cpu resources for video decoding. > > That's fine. Now I'm waiting for further instructions :) Should I try to > > prepare a complete patch for xserver? I'm really interested in getting > > this optimization into xserver as it would help to play high resolution > > videos. If you have any extra questions about the code or anything > > else (for example I wonder what free license would be appriopriate > > for it), don't hesitate to contact me. > > If you wanted to prepare a complete patch for the server, that would be > great, as I don't have time to get to it right now (trying to finish off > the merge with upstream, among others). As for the license, just the > standard MIT boilerplate in hw/kdrive/omap/* is fine, but replace Nokia > Corporation/Daniel Stone with Siarhei Siamaskha, obviously. > > > I did not try to build xserver sources yet as I did not have enough time > > for that and xserver requires quite a number of build dependencies. Can > > you share some tips and tricks about maemo xserver development. Is it > > difficult to compile (do I need any extra build scripts, tools, or > > configuration options) and install on N800 (is it safe to upgrade > > xserver on N800 from .deb file)? > > It's completely safe to upgrade from a deb if it's not broken. If you > set up a standard Maemo build environment and run apt-get source > xorg-server and apt-get build-dep xorg-server, it should work just fine, > in theory. > > I don't have any tips, per se. Once I get it all integrated it'll be in > git, but for now, the only public source is the packages. OK, thanks. It may take some time though. I'm still using old scratchbox with mistral SDK here (did not have enough free time to upgrade yet). Until I clean up my scratchbox mess, I can only provide some patch without testing, if anybody courageous can try to build it :) > > I also tried to use YUV420 on Nokia 770, but it did not work well. > > According to Epson, this format should be supported by hardware. Also > > there is a constant OMAPFB_COLOR_YUV420 defined in omapfb.h in Nokia 770 > > kernel sources. But actually using YUV420 was not very successful. Full > > screen update 800x48
