Mailing List Archive

SDL, tearing, X overhead and direct framebuffer gfx
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
- significant overhead due to X server
(rendering pipe is : SDL -> X -> Framebuffer)

[.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?

==

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?

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

/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.

Q: Where can I find the sources to the OS2008 SDL?

Thx and cheers,

tgo

=========================================
SDL Test

===> Makefile:

##
## 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

##
## SDL compile/link flags
##
SDL_FLAGS = `sdl-config --cflags` `sdl-config --libs`

##
## compiler command
##
CC = gcc -Wall $(OPT_FLAGS) $(SDL_FLAGS)


all: sdl_timer

sdl_timer: sdl_timer.c
$(CC) sdl_timer.c -o sdl_timer

===> 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)
//

/*

Mem: 90376K used, 36452K free, 0K shrd, 716K buff, 42956K cached
Load average: 1.01 0.64 0.44
PID USER STATUS VSZ PPID %CPU %MEM COMMAND
756 root SW< 11368 338 21.8 8.9 Xomap
1831 root SW 12532 1365 7.3 9.8 sdl_timer
1815 root RW 1960 1799 3.0 1.5 top
78 root SW< 0 6 2.7 0.0 OMAP McSPI/0
1032 user SW< 32052 957 2.1 25.2 maemo-launcher
376 root SW< 0 6 1.6 0.0 cx3110x
...

*/


#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include "SDL.h"

#define HRES 800
#define VRES 480
#define BPP 16


//
// frame render callback
//
Uint32 renderFrame (Uint32 interval, void *param)
{
static int col = 0;

// get screen surface from parameter
SDL_Surface *screen = (SDL_Surface*) param;

// lock surface if needed
if (SDL_MUSTLOCK(screen))
{
if (SDL_LockSurface(screen) < 0)
{
fprintf (stderr, "unable to lock surface\n");
exit(1);
}
}

// "render" whole frame in single color
memset(screen->pixels, ++col, HRES * BPP / 8 * VRES);

// unlock surface if needed
if (SDL_MUSTLOCK(screen))
{
SDL_UnlockSurface(screen);
}

// update whole screen
SDL_UpdateRect(screen, 0, 0, HRES, VRES);

// continue firing
return interval;
}


int main (int argc, char** argv)
{
// initialize SDL
if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER) < 0)
{
fprintf (stderr, "unable to initialize SDL : %s\n", SDL_GetError());
exit(1);
}

// register SDL cleanup
atexit (SDL_Quit);

// set mouse pointer invisible
SDL_ShowCursor (SDL_DISABLE);

// set video mode to fullscreen
SDL_Surface *screen = SDL_SetVideoMode(HRES, VRES, BPP, SDL_SWSURFACE
| SDL_FULLSCREEN);

if (screen == NULL)
{
fprintf (stderr, "unable to initialize video : %s\n", SDL_GetError());
exit(1);
}

// setup frame renderer at rate 17 frames/s (every 60ms)
SDL_TimerID tid = SDL_AddTimer (60,
(SDL_NewTimerCallback) renderFrame,
screen);

// run for 60 secs
sleep (60);


// shutdown frame renderer
SDL_bool ret = SDL_RemoveTimer (tid);

if (!ret)
{
fprintf (stderr, "could not shutdown timer : %s\n", SDL_GetError());
exit(1);
}

// finished
return 0;
}
===



=========================================
Framebuffer Test

===> Makefile:

##
## 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

##
## compiler command
##
CC = gcc -Wall $(OPT_FLAGS) -lX11


all: fb_minimal

fb_minimal: fb_minimal.c
$(CC) fb_minimal.c -o fb_minimal

===> Source:

//////////////////////////////////////////////////////////////////////////
//
// Test for direct framebuffer graphics bypassing X. (tested on N800)
//
//////////////////////////////////////////////////////////////////////////


/*


Mem: 89132K used, 37696K free, 0K shrd, 716K buff, 42116K cached
Load average: 0.80 0.25 0.18
PID USER STATUS VSZ PPID %CPU %MEM COMMAND
1686 root RW 3124 1685 6.1 2.4 fb_minimal
1032 user SW< 32052 957 2.2 25.2 maemo-launcher
1687 root RW 1960 1365 2.1 1.5 top
756 root SW< 10492 338 1.1 8.2 Xomap
78 root SW< 0 6 0.9 0.0 OMAP McSPI/0
376 root SW< 0 6 0.3 0.0 cx3110x
346 root SW 776 338 0.1 0.6 bme_RX-34
987 user SW< 27532 957 0.0 21.6 maemo-launcher
...


Nokia-N800-50-2:/home/oberstet# time ./fb_minimal
real 1m 48.01s
user 0m 6.31s
sys 0m 0.33s
Nokia-N800-50-2:/home/oberstet#


*/



#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <asm-arm/arch-omap/omapfb.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>

//
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/usr/include/asm-arm/arch-omap/omapfb.h
//
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/arm-none-linux-gnueabi/sys-include/asm-arm/arch-omap/omapfb.h


#define HRES 800
#define VRES 480
#define BPP 16
#define LOOPN 1000

#define OMAPFB_FORMAT_FLAG_TEARSYNC 0x0200
#define OMAPFB_FORMAT_FLAG_FORCE_VSYNC 0x0400


int main (int argc, char** argv)
{


//////////////////////////////////////////////////////////////////////////
//
// 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).
//

//////////////////////////////////////////////////////////////////////////

// setup display, screen and window
Display *display = XOpenDisplay (getenv ("DISPLAY"));
if (display == NULL)
{
fprintf (stderr, "cannot open X display\n");
exit (1);
}

int screen_num = DefaultScreen (display);

Window win = XCreateSimpleWindow(display,
RootWindow (display, screen_num),
0,
0,
720,
420,
0,
WhitePixel (display, screen_num),
BlackPixel (display, screen_num));

XMapWindow (display, win);
XSelectInput (display, win, ExposureMask);
XFlush (display);

XEvent xev;
XWindowEvent (display, win, ExposureMask, &xev);

// bring window to fullscreen
xev.xclient.type = ClientMessage;
xev.xclient.serial = 0;
xev.xclient.send_event = True;
xev.xclient.message_type = XInternAtom (display, "_NET_WM_STATE", False);
xev.xclient.window = win;
xev.xclient.format = 32;
xev.xclient.data.l[0] = 1;
xev.xclient.data.l[1] = XInternAtom (display,
"_NET_WM_STATE_FULLSCREEN", False);
xev.xclient.data.l[2] = 0;
xev.xclient.data.l[3] = 0;
xev.xclient.data.l[4] = 0;

if (!XSendEvent (display,
DefaultRootWindow (display),
False,
SubstructureRedirectMask | SubstructureNotifyMask,
&xev))
{
fprintf (stderr, "cannot bring X window to fullscreen\n");
exit (1);
}
XSync(display, False);



//////////////////////////////////////////////////////////////////////////
//
// setup framebuffer stuff
//

//////////////////////////////////////////////////////////////////////////

// open framebuffer device
int fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd)
{
fprintf (stderr, "cannot open framebuffer device\n");
exit (1);
}


// screen size
size_t ssize = HRES * BPP / 8 * VRES;


// map framebuffer
char* fbp = (char*) mmap (0, ssize, PROT_READ | PROT_WRITE,
MAP_SHARED, fbfd, 0);
if ((int) fbp == -1)
{
fprintf (stderr, "failed to memory map framebuffer\n");
exit (1);
}

// setup fullscreen update info struct
struct omapfb_update_window update;

// copy full screen from fb to lcd video ram
update.x = 0;
update.y = 0;
update.width = HRES;
update.height = VRES;

// request native pixel format, tearsync and vsync
update.format = OMAPFB_COLOR_RGB565 | OMAPFB_FORMAT_FLAG_TEARSYNC |
OMAPFB_FORMAT_FLAG_FORCE_VSYNC;



//////////////////////////////////////////////////////////////////////////
//
// render loop
//

//////////////////////////////////////////////////////////////////////////

int n;

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);
}



//////////////////////////////////////////////////////////////////////////
//
// cleanup
//

//////////////////////////////////////////////////////////////////////////

// cleanup framebuffer stuff
munmap (fbp, ssize);
close (fbfd);

// cleanup X stuff
if (display)
{
XCloseDisplay (display);
display = NULL;
}

// finished
return 0;
}

===


_______________________________________________
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 [ In reply to ]
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 <mflaig@pro-linux.de>
PROLinux.de
Re: SDL, tearing, X overhead and direct framebuffer gfx [ In reply to ]
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 [ In reply to ]
>>> 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
30000 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 [ In reply to ]
> 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 [ In reply to ]
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
Re: SDL, tearing, X overhead and direct framebuffer gfx [ In reply to ]
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 [ In reply to ]
On Feb 17, 2008 9:56 PM, Tobias Oberstein <tobias.oberstein@gmail.com> 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_docman&task=cat_view&gid=38&Itemid=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 [ In reply to ]
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_docman&task=cat_view&gid=38&Itemid=40

And for 770 (S1D13742) here
http://vdc.epson.com/index.php?option=com_docman&task=cat_view&gid=36&Itemid=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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
On Feb 18, 2008 9:39 AM, Tapani Pälli <tapani.palli@nokia.com> 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 [ In reply to ]
Hello;

ext Siarhei Siamashka wrote:
> On Feb 18, 2008 9:39 AM, Tapani Pälli <tapani.palli@nokia.com> 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 [ In reply to ]
On Feb 18, 2008 1:28 PM, Tapani Pälli <tapani.palli@nokia.com> 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 [ In reply to ]
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 [ In reply to ]
Hello;

ext Siarhei Siamashka wrote:
> On Feb 18, 2008 1:28 PM, Tapani Pälli <tapani.palli@nokia.com> 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