Re: SDL, tearing, X overhead and direct framebuffer gfx
Tapani Pälli wrote: Hello; ext Tobias Oberstein wrote: Hello tableteers, I've done some initial experiments hacking my N800/OS2008 and ran into a couple of issues: When using the supplied SDL library for doing timer-based frame rendering, there seems to be - heavy tearing Tearing unfortunately happens because there is no vsync available for framebuffer driver to use. with direct fb access there is ioctl flag OMAPFB_FORMAT_FLAG_TEARSYNC that should take care of it and schedule the update at right time. But still I think there is not enough time to do full screen 800x480x16bit update even if it starts at right time. In the example Tobias posted it is this part // wait for fb-lcd video ram transfer complete ioctl (fbfd, OMAPFB_SYNC_GFX); // render whole frame in single color memset (fbp, n, ssize); // wait for vsync ioctl (fbfd, OMAPFB_VSYNC); // request transfer of fb- lcd video ram for whole screen ioctl (fbfd, OMAPFB_UPDATE_WINDOW, update); and basically it looks correct to me except maybe 'ioctl (fbfd, OMAPFB_VSYNC);' may do nothing but won't hurt. Q: Is this expected behaviour? What could I do about the tearing? What about the Xomap overhead? This was discussed here in the list and there are timing results posted by Siarhei Siamashka. I think you can only solve it by updating smaller region and/or use 12 bit YUV format. There was also discussion about 'accelerated' SDL with direct fb access. I think it would be a nice hack to use direct fb access when SDL X window is on the top or full screen and fall back to using X in other cases. But due to hackish nature and HW dependency on features of Epson chips in 770 and N8x0 it won't be accepted to nokia version of SDL. I think the hint was that that future generation of devices will not use similar chip so there is no future for this code. But true that there are present and past devices so it may make sense to make hacked community version of SDL for current game ports. Also such version could safely take advantage of pixel doubling which is impossible to use safely with Xsp extension. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
On Feb 17, 2008 9:56 PM, Tobias Oberstein [EMAIL PROTECTED] wrote: [...] I've read a lot of bits on the web 'bout mplayer, vsync, omapfb etc. and tried to assemble a minimal example of using direct framebuffer access for gfx output. Q: I can't get the tearing away (only fixed at certain line positions). What am I doing wrong? Transfer framebuffer-videoram must be fast enough to complete for the period of two LCD refresh cycles, also see http://lists.maemo.org/pipermail//maemo-developers/2007-March/009202.html Using smaller source rectangle in the framebuffer will reduce data transfer time and the tearing line at the bottom will disappear (using 'new' screen update ioctl which was introduced in N800 kernel, this rectangle can be upscaled to fullscreen). You can calculate the resolution which can be used without tearing either theoretically or in an experimental way. I wondered if there would be any plans to make SDL run directly on framebuffer .. if not, I'd maybe give it a try. Q: Where can I find the sources to the OS2008 SDL? AFAIK, SDL is used pretty much unmodified. My guess is that you can get it here: http://repository.maemo.org/pool/chinook/free/source/ As for some practical solution on N800/N810, I think it makes sense tweaking xserver to add support rgb color format in Xv and tweaking SDL to use Xv for the emulation of setting arbitrary screen resolutions (setting low resolution will eliminate tearing and will be useful for games). For those interested in the topic, documentation for the Epson LCD controller used in N8x0 (S1D13745) is available here: http://vdc.epson.com/index.php?option=com_docmantask=cat_viewgid=38Itemid=40 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Siarhei Siamashka wrote: those interested in the topic, documentation for the Epson LCD controller used in N8x0 (S1D13745) is available here: http://vdc.epson.com/index.php?option=com_docmantask=cat_viewgid=38Itemid=40 And for 770 (S1D13742) here http://vdc.epson.com/index.php?option=com_docmantask=cat_viewgid=36Itemid=99 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Hi,
I'll comment things others haven't yet commented on.
ext Tobias Oberstein wrote:
Q: btw - how can I shutdown Maemo Launcher/Hildon/Matchbox/Xomap?
Whenever I do one of
/etc/init.d/maemo-launcher stop
/etc/init.d/x-server stop
the device will automatically reboot.
Yes, the SW watchdog does that. You can disable that with Flasher.
I wondered if there would be any plans to make SDL run directly on
framebuffer .. if not, I'd maybe give it a try.
That's not really useful for maemo (see below for usability issues).
Q: Where can I find the sources to the OS2008 SDL?
Where all the other sources are i.e. from the maemo.org repository:
http://repository.maemo.org/pool/maemo4.0/free/source/libs/
## produce ARM11 target optimized code
## use hardware FP, but use soft FP ABI for math lib
##
OPT_FLAGS = -O3 -fomit-frame-pointer -mcpu=arm1136j-s -mfpu=vfp
-mfloat-abi=softfp
To get best performance, it's better to test the options to see what
produces best results (-O3 vs. -O2 vs. -Os, VFP). O3 bloats code
size which can be bad considering the caches, whether VFP helps depends
on whether you use it on cross-library calls to libraries that are
non-VFP.
=== Source:
//
// minimal timer based SDL fullscreen test for N800
//
// the test seems to indicate 2 problems:
//
// 1) heavy tearing
// 2) significant overhead due to X server (rendering pipe is : SDL -
X - Framebuffer)
You do just memset to shared memory area whereas X needs first to blit
that area to window with clipping before requesting framebuffer to
transfer the changed area to LCD.
//
//
// setup X stuff (we pull up a pseudo X window in fullscreen, so our
// framebuffer graphics will not be overwritten by X server - otherwise
// we had to shutdown X server).
//
//
Or you could switch to a different VT. Writing directly to framebuffer
is really ugly when you're running X server. If user presses power or
Home key, or there's some system banner, you'll be overwriting the
window that came on top. Or if uses switches to Home with long press
of Home key, user will be very confused...
(There's a good reason why X needs to copy your changed data to
the screen window with clipping.)
for (n = 0; n LOOPN; ++n)
{
// wait for fb-lcd video ram transfer complete
ioctl (fbfd, OMAPFB_SYNC_GFX);
// render whole frame in single color
memset (fbp, n, ssize);
// wait for vsync
ioctl (fbfd, OMAPFB_VSYNC);
// request transfer of fb- lcd video ram for whole screen
ioctl (fbfd, OMAPFB_UPDATE_WINDOW, update);
}
As there's no real VSYNC, the framebuffer itself could be discarding
some of your updates (at least it did it earlier (in 770), I'm not sure
about the latest releases) which affects the perceived performance.
- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: SDL, tearing, X overhead and direct framebuffer gfx
Tobias wrote: Q: Where can I find the sources to the OS2008 SDL? Eero wrote: Where all the other sources are i.e. from the maemo.org repository: http://repository.maemo.org/pool/maemo4.0/free/source/libs/ Or you could search for them: http://timeless.justdave.net/mxr-test/os2008/find?string=sdl or http://mxr.maemo.org/os2008/find?string=sdl if you have http://timeless.justdave.net/maemo/mxr-maemo-org-dns-0.1.deb installed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
On Feb 18, 2008 9:39 AM, Tapani Pälli [EMAIL PROTECTED] wrote: When using the supplied SDL library for doing timer-based frame rendering, there seems to be - heavy tearing Tearing unfortunately happens because there is no vsync available for framebuffer driver to use. Could you please verify and confirm this information? Framebuffer driver from OS2007 supported tearsync (via OMAPFB_FORMAT_FLAG_TEARSYNC flag as Frantisek mentioned), and it was used at least for video. Well, I have noticed some tearing in mplayer with OS2008 though. Q: I can't get the tearing away (only fixed at certain line positions). What am I doing wrong? Nothing, you cannot get away from tearing. Still what about trying different LCD panel timings? For example, reducing LCD refresh rate to something like 40Hz should allow 20 full resolution fullscreen rgb updates per second with perfect tearsync. I don't dare trying such experiments myself as I'm afraid to kill LCD panel of my N800 :) Can any HW expert tell if it can be possible? Link to LCD controller docs is available earlier in this thread. On the other hand, reducing refresh rate may introduce problems for 25 and 30 fps video playback (for high resolution video only, when the time to transfer frame data over graphics bus is larger than one LCD refresh cycle). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Hello; ext Siarhei Siamashka wrote: On Feb 18, 2008 9:39 AM, Tapani Pälli [EMAIL PROTECTED] wrote: When using the supplied SDL library for doing timer-based frame rendering, there seems to be - heavy tearing Tearing unfortunately happens because there is no vsync available for framebuffer driver to use. Could you please verify and confirm this information? Framebuffer driver from OS2007 supported tearsync (via OMAPFB_FORMAT_FLAG_TEARSYNC flag as Frantisek mentioned), and it was used at least for video. Well, I have noticed some tearing in mplayer with OS2008 though. This is what I've heard from our kernel team members, maybe they could share some more light to this. AFAIK the hardware itself does not offer sync. Q: I can't get the tearing away (only fixed at certain line positions). What am I doing wrong? Nothing, you cannot get away from tearing. Still what about trying different LCD panel timings? For example, reducing LCD refresh rate to something like 40Hz should allow 20 full resolution fullscreen rgb updates per second with perfect tearsync. I Hmm, but how do you know when to start drawing? don't dare trying such experiments myself as I'm afraid to kill LCD panel of my N800 :) Can any HW expert tell if it can be possible? Link to LCD controller docs is available earlier in this thread. On the other hand, reducing refresh rate may introduce problems for 25 and 30 fps video playback (for high resolution video only, when the time to transfer frame data over graphics bus is larger than one LCD refresh cycle). // Tapani Pälli -- Software Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
On Feb 18, 2008 1:28 PM, Tapani Pälli [EMAIL PROTECTED] wrote: Could you please verify and confirm this information? Framebuffer driver from OS2007 supported tearsync (via OMAPFB_FORMAT_FLAG_TEARSYNC flag as Frantisek mentioned), and it was used at least for video. Well, I have noticed some tearing in mplayer with OS2008 though. This is what I've heard from our kernel team members, maybe they could share some more light to this. AFAIK the hardware itself does not offer sync. Is it possible to invite kernel team members to join this discussion? :) At least it would be nice if they had a look at this thread. N800 hardware definitely supports tearsync. It worked fine in OS2007 (I'm not telling that OS2008 does not support it anymore, I just can't check this till I get home). When I looked through xserver sources last time, tearsync was used for video planes, but was disabled for normal rgb updates. This can be easily explained. Video usually has lower resolution than 800x480, requires less graphics bandwidth and it is possible to display it with perfect tearsync. With tearsync enabled for rgb updates, we get an ugly tearing line at a fixed location in the bottom of screen when doing 800x480 rgb update (the first OS2008 firmware had this problem btw). Without tearsync flag set, we also get tearing, but at random locations on screen, and it is less noticeable/annoying. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Siarhei Siamashka wrote: N800 hardware definitely supports tearsync. And 770 should too according to the schematics floating on the net. Only the code never made to official 770 kernel but is/was part of released N800 kernel. Sadly last time I tried and ported this code back to 770 kernel it just hanged the device and the interrupt on TE pin never arrived. I'm suspecting the sossi TE pin needs to be enabled somehow via some platform specific (omap1) initialization code that was not part of N800 kernel. The failed attempt is here http://fanoush.wz.cz/maemo/2.6.16.yuv420+tearsync-not-working.diff Got no reply here http://lists.maemo.org/pipermail/maemo-developers/2007-May/010156.html but something here http://www.gossamer-threads.com/lists/maemo/developers/22701#22701 Also on the similar 'banging my head against the wall' kernel topic - some weeks ago I downgraded my N800 back to OS2007 (as I have N810 with it, the N800 touchscreen is much worse in OS2008 and I like speed of Opera and the system i general). Also since I boot from mmc I flashed only initfs and kernel (i.e. not bootloader). Then I noticed my external mmc slot does not work. Flashed to OS2008 back - it worked again, flashed back to OS2007 - no luck even with original Nokia kernel. I spent some time digging in kernel source and even backporting changes in mmc stack from 2.6.21 to 2.6.18 with no luck. Finally I had an idea to flash bootloader too (over USB, kernel and initfs can be done on the fly from the device so one could sort of dual boot between OS2007 and 8). After doing this my external mmc slot magically works again in OS2007 (NOLO is downgraded from 1.1.7 to 1.1.6). This was a bit discouraging and tells me something about chances of getting tearsync code working without proper HW initialization and bootloader sources :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Hello; ext Siarhei Siamashka wrote: On Feb 18, 2008 1:28 PM, Tapani Pälli [EMAIL PROTECTED] wrote: Could you please verify and confirm this information? Framebuffer driver from OS2007 supported tearsync (via OMAPFB_FORMAT_FLAG_TEARSYNC flag as Frantisek mentioned), and it was used at least for video. Well, I have noticed some tearing in mplayer with OS2008 though. This is what I've heard from our kernel team members, maybe they could share some more light to this. AFAIK the hardware itself does not offer sync. Is it possible to invite kernel team members to join this discussion? :) At least it would be nice if they had a look at this thread. They should be reading this :-) N800 hardware definitely supports tearsync. It worked fine in OS2007 (I'm not telling that OS2008 does not support it anymore, I just can't check this till I get home). When I looked through xserver sources last time, tearsync was used for video planes, but was disabled for normal rgb updates. This can be easily explained. Video usually has OK, maybe this is the reason, I was not familiar with such setting. Fortunately tearing does not really matter with individual small rects. When implementing animation with large elements, you will see tearing though :/ lower resolution than 800x480, requires less graphics bandwidth and it is possible to display it with perfect tearsync. With tearsync enabled for rgb updates, we get an ugly tearing line at a fixed location in the bottom of screen when doing 800x480 rgb update (the first OS2008 firmware had this problem btw). Without tearsync flag set, we also get tearing, but at random locations on screen, and it is less noticeable/annoying. // Tapani Pälli -- Software Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Hi, sorry can't say much about the other things... Q: btw - how can I shutdown Maemo Launcher/Hildon/Matchbox/Xomap? Whenever I do one of /etc/init.d/maemo-launcher stop /etc/init.d/x-server stop the device will automatically reboot. There is a watchdog in place. I believe you can disable it with the flasher utility... HTH, Michael -- Michael Flaig [EMAIL PROTECTED] PROLinux.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Michael Flaig wrote: Hi, sorry can't say much about the other things... Q: btw - how can I shutdown Maemo Launcher/Hildon/Matchbox/Xomap? Whenever I do one of /etc/init.d/maemo-launcher stop /etc/init.d/x-server stop the device will automatically reboot. There is a watchdog in place. I believe you can disable it with the flasher utility... Never tried but I think it should be possible to stop (almost) everything in reverse order without triggering reboot. In this case reboot may mean x-server was stopped before stopping other services that depend on it. Try to go over /etc/rc2.d/ and stop stuff in reverse order. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Q: btw - how can I shutdown Maemo Launcher/Hildon/Matchbox/Xomap? Whenever I do one of /etc/init.d/maemo-launcher stop /etc/init.d/x-server stop the device will automatically reboot. There is a watchdog in place. I believe you can disable it with the flasher utility... Never tried but I think it should be possible to stop (almost) everything in reverse order without triggering reboot. In this case reboot may mean x-server was stopped before stopping other services that depend on it. Try to go over /etc/rc2.d/ and stop stuff in reverse order. good idea! unfort. it doesn't work;( I can do: #/etc/init.d/zzinitdone stop /etc/init.d/ttyusb0 stop /etc/init.d/metalayer-crawler0 stop /etc/init.d/mediaplayer-daemon stop /etc/init.d/hulda stop /etc/init.d/hildon-update-notifier stop /etc/init.d/alarmd stop /etc/init.d/obexsrv stop /etc/init.d/osso-systemui stop /etc/init.d/af-base-apps stop #/etc/init.d/osso-ic stop #/etc/init.d/wlancond stop /etc/init.d/btcond stop /etc/init.d/bluez-utils stop /etc/init.d/libgpsbt stop /etc/init.d/gpsdriver stop /etc/init.d/dnsmasq stop /etc/init.d/hildon-desktop stop /etc/init.d/af-startup stop /etc/init.d/maemo-launcher stop /etc/init.d/product-code stop /etc/init.d/ke-recv stop /etc/init.d/osso-systemui-early stop /etc/init.d/esd stop /etc/init.d/multimediad stop /etc/init.d/bme-dbus-proxy stop /etc/init.d/dsp-init stop all fine (osso-ic/wlancond I had to keep running, since I'm ssh'ing via WLAN into the device). but then, when I Nokia-N800-50-2:~# /etc/init.d/af-services stop Protecting UIDs 30001 30002 3 from the memory allocation denial. Stopping media-server Stopping Matchbox window manager Stopping Sapwood image server Stopping D-BUS session bus daemon Stopping GConf daemon sh: cannot kill pid 752: Operation not permitted Stopping Periodical temporary file purging daemon Nokia-N800-50-2:~# and the device will reboot. The rest of reverse init would have been /etc/init.d/x-server stop /etc/init.d/mce stop #/etc/init.d/ssh stop /etc/init.d/osso-applet-display stop /etc/init.d/dbus stop /etc/init.d/fb-progress.sh stop #/etc/init.d/zzinitdone stop greets tgo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
sorry can't say much about the other things... Q: btw - how can I shutdown Maemo Launcher/Hildon/Matchbox/Xomap? Whenever I do one of /etc/init.d/maemo-launcher stop /etc/init.d/x-server stop the device will automatically reboot. There is a watchdog in place. I believe you can disable it with the flasher utility... Ah, ok. I'll check that out as soon as I got started with the flasher tool .. greets, tgo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Hello; ext Tobias Oberstein wrote: Hello tableteers, I've done some initial experiments hacking my N800/OS2008 and ran into a couple of issues: When using the supplied SDL library for doing timer-based frame rendering, there seems to be - heavy tearing Tearing unfortunately happens because there is no vsync available for framebuffer driver to use. - significant overhead due to X server (rendering pipe is : SDL - X - Framebuffer) The overhead here is probably not as big as you expect. SDL uses shared memory extension to create and update image(s) so all it passes to X is pointer and then X copies the data to framebuffer driver. [Note: yes, I'm aware that doing full screen blits is evil on the N800 due to limited framebuffer - video RAM bus bandwidth.] Q: Is this expected behaviour? What could I do about the tearing? What about the Xomap overhead? You cannot help the tearing, you might want to try with different timer values etc. to make end result look better. If you are planning to develop a game you could take a look at : http://maemo.org/community/wiki/gamedevelopment/ You should try to minimize the amount of updated area and redraws. == I've read a lot of bits on the web 'bout mplayer, vsync, omapfb etc. and tried to assemble a minimal example of using direct framebuffer access for gfx output. Q: I can't get the tearing away (only fixed at certain line positions). What am I doing wrong? Nothing, you cannot get away from tearing. Q: Also, frame rate is sluggish, though CPU load is much lower than SDL/X. Ok, my FB example is not threaded like the SDL timer example .. is that the reason for framerate even 15/s? Q: btw - how can I shutdown Maemo Launcher/Hildon/Matchbox/Xomap? Whenever I do one of Quite likely this won't really help you with the performance issues. /etc/init.d/maemo-launcher stop /etc/init.d/x-server stop the device will automatically reboot. == I wondered if there would be any plans to make SDL run directly on framebuffer .. if not, I'd maybe give it a try. I would be interested in these results too but I wouldn't expect so much performance boost from there. Q: Where can I find the sources to the OS2008 SDL? I wish I knew. Anyway, there is not significant changes in our SDL, you can safely browse the upstream source at http://libsdl.org/ Thx and cheers, tgo // Tapani Pälli -- Software Engineer Open Source Software Operations ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
