Retrace sync. in Linux

SDL Development
1

I’ve done some more experimenting, and found out some more things (again, only
for people with little to no experience with sdl/graphics under linux
programming I guess).

The tearing in my scrolling example posted a while ago stops completely when I
use the DGA driver and runs the program as root. My framrate drops from about
120-130 to 85, which is my refresh rate on the monitor. So my tearing problems
is because there is no waiting for retrace it seems.

Is there any way to do this without having to use suid programs? I can’t use
the DGA driver without being root, so that’s not a good idea it seems.

I found this old post by Olofson:
http://www.libsdl.org/pipermail/sdl/2001-January/032774.html

Do anyone know if there has been some progress on the matter? Without having
to run as root.

Regards
Henning

2

No, DGA still requires you to setuid your programs.
In Linux if you want hardware acceleration and to
run your application as a normal user your only
soluction is OpenGL.

eddie at odense.kollegienet.dk wrote:>I’ve done some more experimenting, and found out some more things (again, only

for people with little to no experience with sdl/graphics under linux
programming I guess).

The tearing in my scrolling example posted a while ago stops completely when I
use the DGA driver and runs the program as root. My framrate drops from about
120-130 to 85, which is my refresh rate on the monitor. So my tearing problems
is because there is no waiting for retrace it seems.

Is there any way to do this without having to use suid programs? I can’t use
the DGA driver without being root, so that’s not a good idea it seems.

I found this old post by Olofson:
http://www.libsdl.org/pipermail/sdl/2001-January/032774.html

Do anyone know if there has been some progress on the matter? Without having
to run as root.

Regards
Henning

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

3

No, DGA still requires you to setuid your programs.

Don’t ever setuid your programs. This will lead to a false sense of security
on the part of the user… “Of course it’s safe, I’m not running it as root”…

What I typically do is make DGA an option in the program, but default to use
X11. Then, if the user feels comfortable running the program as root, they
can do so for added benefits.

BTW, the version of the DGA library that’s built into SDL has support for
using DGA as a normal user if the framebuffer console is properly configured.
I don’t think the patch ever made it into XFree86, but it’s handy just for
this particular problem.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

4

Whats so stupid is, X already has root (usually). DGA was badly designed, and
I wish someone would replace this with a better method. XImage supposibly is
that better method, but Ive yet to see anything really good come out of it.On 24-Sep-2003, Sam Lantinga wrote:

BTW, the version of the DGA library that’s built into SDL has support for
using DGA as a normal user if the framebuffer console is properly configured.
I don’t think the patch ever made it into XFree86, but it’s handy just for
this particular problem.

–
Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." – Kristian Wilson, Nintendo, Inc, 1989
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20030924/496d37d5/attachment.pgp

5

BTW, the version of the DGA library that’s built into SDL has support for
using DGA as a normal user if the framebuffer console is properly configured.
I don’t think the patch ever made it into XFree86, but it’s handy just for
this particular problem.

I don’t really understand the benefit of making a graphics library (or
extension, or whatever DGA is) that can only be used as root. I don’t know how
DGA is implemented, but I read in an article (from SDL’s article links) that
Loki had created their own version of DGA that did not need root priviledges
to run, for some game. Also it seems that OpenGL apps has acces to hardware
acceleration (don’t know whether or not retrace sync could be called
acceleration).

I don’t understand why some libraries are allowed to acces hardware, while
others are not.
But if it’s possible to do it at all, then I guess I could just go ahead and
write my own code for doing a retrace sync. I have absolutely no idea how to
do that yet, tho.

Regards
Henning

6

[…]

I found this old post by Olofson:
http://www.libsdl.org/pipermail/sdl/2001-January/032774.html

Do anyone know if there has been some progress on the matter?
Without having to run as root.

Dunno if anything is done to fix DGA, but I’m quite sure it could be
done. However, there’s one major difference between DGA and other low
level “direct video” APIs, and OpenGL; the latter is asynchronous,
while the former are synchronous. This means that in the case of
OpenGL, the driver is the only part that has to be in strict “hard
sync” with the retrace, whereas with DGA, the application has to be
sync’ed as well. This turns out to be a real PITA in general purpose
OSes. You basically need an RTOS to do that kind of stuff properly.

Anyway, OpenGL is the way to go. It’s the only remotely portable
solution that can reliably provide serious h/w acceleration. OpenGL
also provides asynchronous rendering, which cuts the applications
some more slack, allowing for more scheduling jitter without dropping
frames. Finally, the best part: Most OpenGL drivers for current
hardware (ie the closed source ones…) support retrace sync.

IMNSHO, “traditional” 2D acceleration is effectively obsolete, and s/w
2D rendering directly into VRAM has been an absolute last resort for
a good while. There are many different 2D APIs, most of which are
platform specific and/or have serious limitations and/or very few -
if any - accelerated drivers. As to “pure” s/w rendering, that’s
practically useless for high quality animation due to performance
issues with CPU transfers through PCI and AGP. If you really want s/w
rendering, you should use busmaster DMA to transfer the output to the
screen - but unfortutately, virtually no targets, apart from
DirectDraw on reasonably well supported hardware, support this.

That said, s/w 2D rendering can still be useful for less demanding
applications. It allows the applications to run on pretty much
anything, and even though this method scales very poorly (ie your 3+
GHz CPU and 500 MHz GPU won’t help much at all), there are ways to
add full h/w acceleration very easily to most such applications.

glSDL (the “compile-in” wrapper) is one way (which is used by Kobo
Deluxe: http://www.olofson.net/kobodl ), and in a not too distant
future, we (the Not So Secret Backend Team :wink: hope to get a true
backend version into SDL, so users can make use of OpenGL without
even recompiling applications.

glSDL/wrapper:
	http://olofson.net/mixed.html

Another way is to think twice (or more :wink: when designing your
application, so you can snap in an alternative rendering backend
which uses OpenGL natively. There’s a very simple demonstration of
that technique in my smoothscroll example:

smoothscroll:
	http://olofson.net/examples.html

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 24 September 2003 12.11, eddie at odense.kollegienet.dk wrote:

7

[…]

Also it
seems that OpenGL apps has acces to hardware acceleration (don’t
know whether or not retrace sync could be called acceleration).

Right. However, there is one important difference: As opposed to DGA
apps, OpenGL apps do not have direct access to VRAM or texture RAM.
That makes things quite a bit easier for drivers, and it also
eliminates the dreadfully inefficient situations that occur when
people try to mix s/w rendering and accelerated rendering.

I don’t understand why some libraries are allowed to acces
hardware, while others are not.

No libraries are allowed to access hardware. (Well, not unless you’re
root, or the lib has a friend that is root or lives in kernel space.)

The OpenGL lib on a Linux box doesn’t mess with the hardware. Instead,
it just sends commands to the low level OpenGL driver, which lives in
the X server (which means it’s root). OpenGL drivers usually have a
helper kernel module as well, that provides some very low level
services to the X server driver module.

But if it’s possible to do it at all, then I guess I could just go
ahead and write my own code for doing a retrace sync. I have
absolutely no idea how to do that yet, tho.

I have some code that does, but there’s that problem again: You have
to be root to get access to the ports. What I had in mind was to hack
a retrace sync daemon that applications could get retrace info and
events from, but I doubt that would perform very well without
preemptive lowlatency kernels. I’m quite sure it would perform very
well with such kernels though, given that that approach works great
for audio (JACK), which deals with an order of magnitude higher
"frame rates" and much stricter requirements. (Drop-outs are not
tolerated at all.)

Either way, you don’t want to go there. Doing the sync on the
application side is not only hard to get right; it’s the wrong
answer! This is particularly true if you render using OpenGL or some
other asynchronous rendering system. OpenGL doesn’t flip when you
tell it to SwapBuffers; it enqueues a “flip here” mark and then lets
your application go on with the next frame - instantly. No blocking
until the command buffer is full, or you’re more than one or two
frames ahead of the rendering. (The latter is very important. I
once had a driver that didn’t do that, and it was completely useless
for animation…)

So, if you hard-sync your app to the retrace while rendering with
OpenGL (using a driver w/o retrace sync), all you do is concentrate
the tearing to a fixed area of the screen, which usually looks worse
than not sync’ing at all.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 24 September 2003 17.41, eddie at odense.kollegienet.dk wrote:

8

glSDL/wrapper:
http://olofson.net/mixed.html

Oh my!
This is really neat. My framerate jumps from something like 150 to 1150fps. Now I see, how they make games so fast. I must say I really had no idea that my gfx card was utilized so badly before.
I think the tearing is still there, but as you said earlier it might get less visible with higher framerates.

A funny thing is this. If I set __GL_SYNC_TO_VBLANK=1 my driver will make the retrace sync. This drops my framerate to 60, which is okay, since I guess then that this is my monitors refresh rate at whatever screen mode glSDL gives me.
What I don’t understand about this however, is that enabling this makes the lower part of the screen (about half I’d say) seem like its some frames “ahead” of the upper part. That is, the image looks something like this:

<----image scrolls that way##**********
##**********
**********##
**********##

Don’t know if it’s important, but I could mention that using DGA my frame rates (monitor refresh rates) are depending on bpp:
8 or 16bpp = 60fps
24 or 32bpp = 85fps

Using glSDL and enabling vsync always puts my frame rate at 60. I dont know if this is because GL ignores my color depth setting passed to SDL_SetVideoMode or what.

Regards
Henning

9 
glSDL/wrapper:
  http://olofson.net/mixed.html

Oh my!
This is really neat. My framerate jumps from something like 150 to 1150fps. Now I see, how they make games so fast. I must say I really had no idea that my gfx card was utilized so badly before.
I think the tearing is still there, but as you said earlier it might get less visible with higher framerates.

A funny thing is this. If I set __GL_SYNC_TO_VBLANK=1 my driver will make the retrace sync. This drops my framerate to 60, which is okay, since I guess then that this is my monitors refresh rate at whatever screen mode glSDL gives me.
What I don’t understand about this however, is that enabling this makes the lower part of the screen (about half I’d say) seem like its some frames “ahead” of the upper part. That is, the image looks something like this:

<----image scrolls that way
##**********
##**********
**********##
**********##

Don’t know if it’s important, but I could mention that using DGA my frame rates (monitor refresh rates) are depending on bpp:
8 or 16bpp = 60fps
24 or 32bpp = 85fps

Using glSDL and enabling vsync always puts my frame rate at 60. I dont know if this is because GL ignores my color depth setting passed to SDL_SetVideoMode or what.

When using OpenGL with SDL only the GL attributes you set have anything
to do with the frame buffer depth. The values passed to
SDL_SetVideoMode() are always ignored. Even the attributes are only a
minimum requirement. SDL may give you any visual that has Attribute
values equal to or greater than the attribute values.

	Bob PendletonOn Thu, 2003-09-25 at 11:34, Henning wrote:

Regards
Henning

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±----------------------------------+

10

Henning wrote:

glSDL/wrapper:
http://olofson.net/mixed.html
Oh my!
This is really neat. My framerate jumps from something like 150 to 1150fps. Now I see, how they make games so fast. I must say I really had no idea that my gfx card was utilized so badly before.

Wierd - is SDl slow? Any idea what caused the delay?
(Sorry if I ask questions already answered previosly in this thread, but
I just joined the list)

A funny thing is this. If I set __GL_SYNC_TO_VBLANK=1 my driver will make the retrace sync. This drops my framerate to 60, which is okay, since I guess then that this is my monitors refresh rate at whatever screen mode glSDL gives me.
What I don’t understand about this however, is that enabling this makes the lower part of the screen (about half I’d say) seem like its some frames “ahead” of the upper part. That is, the image looks something like this:

<----image scrolls that way
##**********
##**********
**********##
**********##

Don’t know if it’s important, but I could mention that using DGA my frame rates (monitor refresh rates) are depending on bpp:
8 or 16bpp = 60fps
24 or 32bpp = 85fps

In Windoze I believe SDL uses the settings that is set in DirectX - this
is set independently per colordepth. In Linux, you probably use the
vidmodes specified in your /etc/X11/XF86Config (-4). You shouldn’t
experience any kind of tearing when flipping the buffer, though? Are you
using double-buffering? You might just have set it up for single-buffer :slight_smile:

glSDL probably just chooses a default setting of 60Hz as it is just a
"proof of concept" :slight_smile:

Regards,
\Mikkel Gjoel

11 
glSDL/wrapper:
  http://olofson.net/mixed.html

Oh my!
This is really neat. My framerate jumps from something like 150 to
1150fps. Now I see, how they make games so fast. I must say I
really had no idea that my gfx card was utilized so badly before. I
think the tearing is still there, but as you said earlier it might
get less visible with higher framerates.

Yeah. If you get multiple tears per frame, each tear will be smaller
and less visible. With “normal” scrolling speeds, the tearing may not
ever be visible if you get a really insane frame rate.

This is really a tremendous waste of blitting power, rendering the
whole screen over and over, while only a fraction of every frame is
ever seen - but that’s what you get with a broken framework and/or
crappy drivers… heh

A funny thing is this. If I set __GL_SYNC_TO_VBLANK=1 my driver
will make the retrace sync. This drops my framerate to 60, which is
okay, since I guess then that this is my monitors refresh rate at
whatever screen mode glSDL gives me.

Yeah, sounds reasonable - and it sounds like you should hack your
configuration, unless you’re fine with 60 Hz. (I’m not, on any CRT
monitor I’ve seen so far. Stroboscope…)

What I don’t understand about
this however, is that enabling this makes the lower part of the
screen (about half I’d say)

Half! That’s really bad… I get it somewhere near the top of the
screen. (P-III 933, ATI FireGL 8800, XFree86 4.2.1, fglrx 2.5.1.)

seem like its some frames “ahead” of
the upper part. That is, the image looks something like this:

<----image scrolls that way
##**********
##**********
**********##
**********##

That’s because double buffering us done with the off-screen buffer +
blit method. The position of the tearing indicates where the
back->front blit passes the rays. This shouldn’t really happen, but
unless you have RTLinux, RTAI or similar installed, it’s virtually
impossible to avoid, since the retrace only lasts for a tiny fraction
of the duration of a video fram.

Apparently, your driver doesn’t even bother to wait for the rendering
to finish before sync’ing and starting the blit, which makes it even
worse, as the sync-to-blit latency becomes dependent on what you’re
rendering. If the tear is bouncing around when playing 3D games, I’m
95% certain this is the problem.

Now, there is a solution that might work (most of the time) without
RTLinux or RTAI: “Half Buffering”. Use a timer to start blitting the
upper half of the screen when the ray is in the middle of the screen
and then start blitting the lower half after sync’ing with the
retrace and setting up the timer for the next frame. However, this
requires ms accurate timers, so it still won’t work on 100 Hz kernels
without some high-res timer patch…

Either way, I’d be surprized if any driver vendor bothered
implementing something like this, or proper pageflipping (the Right
Way™). H*ll, they don’t even bother enabling retrace sync by
default. :frowning:

Don’t know if it’s important, but I could mention that using DGA my
frame rates (monitor refresh rates) are depending on bpp: 8 or
16bpp = 60fps
24 or 32bpp = 85fps

Using glSDL and enabling vsync always puts my frame rate at 60. I
dont know if this is because GL ignores my color depth setting
passed to SDL_SetVideoMode or what.

Could be something funny with your modelines and/or the DGA driver.
Did you forget to list your preferred modelines in the config for 16
bpp? (Each bpp has a separate configuration…)

Anyway, yes; your depth setting is most probably ignored, since OpenGL
drivers generally don’t use DGA, and thus, are not able to change the
display bit depth.

(Instead, they set up a window the normal way and have the 3D
accelerator render directly into the area occupied by that window.
Fullscreen is done by creating a borderless window of the right size
and then switching the display resolution and disabling panning and
resolution switching shortcuts.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 25 September 2003 18.34, Henning wrote:

12

[…]

Using glSDL and enabling vsync always puts my frame rate at 60. I
dont know if this is because GL ignores my color depth setting
passed to SDL_SetVideoMode or what.

When using OpenGL with SDL only the GL attributes you set have
anything to do with the frame buffer depth. The values passed to
SDL_SetVideoMode() are always ignored. Even the attributes are
only a minimum requirement. SDL may give you any visual that has
Attribute values equal to or greater than the attribute values.

That doesn’t apply to glSDL applications, since (gl)SDL_SetVideoMode()
translates most of the relevant flags into GL attributes. glSDL
applications are not really aware that they’re running on OpenGL, so
it just wouldn’t work without this feature.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 25 September 2003 19.34, Bob Pendleton wrote:

13

Henning wrote:

glSDL/wrapper:
http://olofson.net/mixed.html

Oh my!
This is really neat. My framerate jumps from something like 150
to 1150fps. Now I see, how they make games so fast. I must say I
really had no idea that my gfx card was utilized so badly before.

Wierd - is SDl slow? Any idea what caused the delay?

On most targets, it’s not accelerated, and even when it is, it’s using
more or less obsolete 2D APIs, which often have poor driver support.

OpenGL OTOH, is a major 3D acceleration API that many of the current
commercial games use, so drivers tend to be solid (well, relatively
speaking :wink: and fast, and make full use of the capabilities of the
video cards.

[…]

Don’t know if it’s important, but I could mention that using DGA
my frame rates (monitor refresh rates) are depending on bpp: 8 or
16bpp = 60fps
24 or 32bpp = 85fps

In Windoze I believe SDL uses the settings that is set in DirectX -
this is set independently per colordepth. In Linux, you probably
use the vidmodes specified in your /etc/X11/XF86Config (-4).

Yep.

You
shouldn’t experience any kind of tearing when flipping the buffer,
though?

If he’s actually flipping, that is…

Are you using double-buffering?

Most probably yes…

You might just have set it
up for single-buffer :slight_smile:

…because I doubt he would fail to notice the hysterical flickering
that single buffering would result in. :wink:

(Yes, you really get single buffering if you ask for it with glSDL,
even on X11/Linux, unless you have some weird OpenGL driver that
doesn’t support it.)

glSDL probably just chooses a default setting of 60Hz as it is just
a “proof of concept” :slight_smile:

glSDL doesn’t chose anything. It just forwards the request to SDL,
with the addition of the SDL_OPENGL flag, if the application sets
SDL_GLSDL.

SDL does chose on some targets, I think, but even so, it’ll have to
pick from the list of available modelines in the configuration, so I
my guess is that 16 bpp has a different set of modelines in his
configuration.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 25 September 2003 19.43, Mikkel Gj?l wrote:

14

rendering. If the tear is bouncing around when playing 3D games, I’m
95% certain this is the problem.

Not really tried any 3d games on linux. Apart from… chromium, which uses openGL but is not 3d in the traditional sense, I’d say.

Way™). H*ll, they don’t even bother enabling retrace sync by
default. :frowning:

Which suddenly seems to be a good thing, as it’s not very nice to look at that constant tear in the middle. Suddenly I prefer it the other way around.

Did you forget to list your preferred modelines in the config for 16
bpp? (Each bpp has a separate configuration…)

I’m using XFree4.something, and I can’t find any modelines in my XF86Config file. I don’t know how to change the refresh rate.

I’m really grateful for your help, I’ve learned a lot about all this already.

Regards
Henning

15

In X they render to some offscreen video memory location, which then is
clip blitted to the window. This can be clearly seen if one runs
glxgears without retrace sync in it’s default window size.

Let it run sya 10 seconds after the last output switch to another
desktop for 10 seconds. If you get about double of the seen frame rate
version, then it is simply because the driver needs to blit the rendered
GFX to the X screen. This part can be avoided, but that needs Quatro
class HW, because they can render directly to windows, if the Nvidia
driver settings are enabled.

I think this same problem persist in all Linux and I think in Windows
drivers as well, because the rendering to window can’t clip those parts
that are covered by another windows.

Sadly this same condition is still present in the fullscreen in SDL,
because the fullscreen is simply a borderless window. I don’t know if
it could be possible to use randr and get the root windows gc in
fullscreen situations. This would eliminate the need for the extra
blit, but I don’t know if the drivers support this correctly.On Thursday 25 September 2003 21:08, David Olofson wrote:

(Instead, they set up a window the normal way and have the 3D
accelerator render directly into the area occupied by that window.
Fullscreen is done by creating a borderless window of the right size
and then switching the display resolution and disabling panning and
resolution switching shortcuts.)

16

rendering. If the tear is bouncing around when playing 3D games,
I’m 95% certain this is the problem.

Not really tried any 3d games on linux. Apart from… chromium,
which uses openGL but is not 3d in the traditional sense, I’d say.

If you’d like to have some for reference and/or fun, there are
playable demos of Q3, RTCW etc. If you have the full versions for
Windows or Mac, you can just download the latest updates for Linux,
install them and grab the data files from the Mac/Windows versions.

Way™). H*ll, they don’t even bother enabling retrace sync by
default. :frowning:

Which suddenly seems to be a good thing, as it’s not very nice to
look at that constant tear in the middle. Suddenly I prefer it the
other way around.

Right, that’s probably it; they can’t get the flipping right, so they
disable retracy sync to spread the tearing… heh

Did you forget to list your preferred modelines in the config for
16 bpp? (Each bpp has a separate configuration…)

I’m using XFree4.something, and I can’t find any modelines in my
XF86Config file.

That is, you’re using the default, and perhaps whatever XFree might
get out of your monitor through the PnP stuff. That, however, should
be independent of resolution, except for the highest resolutions,
which could have refresh rate restrictions due to internal bandwidth
limitations in the video card.

I don’t know how to change the refresh rate.

It’s an integral part of each modeline. You can either hack modelines
manually (there’s a HOWTO somewhere), or tweak them “live” with
xvidtune. There are modeline calculators and lists of sensible
modelines as well, but I can’t really point you at any single
complete resource…

I have a small collection of modelines for weird low resolution modes
for arcade games as well as extreme highres modes, and a bunch of
modes I collected from the standard configurations from various Linux
distros. I can make them available if anyone’s interested.

Anyway, I’m not sure it will help in your case, considering that your
X server somehow does get the right modelines. It just doesn’t use
the ones you want when you go 16 bpp. If there are no modelines in
you config, I honestly have no idea why this happens. (It’s the wrong
way too; if anything, the higher bpps would have lower refresh
rates.)

I remember some thread about SDL scanning modes and stuff, and that
some version started scanning them in reverse order or something, to
find the highest refresh rates first, instead of te lowest. Might
have something to do with it…

I’m really grateful for your help, I’ve learned a lot about all
this already.

Well, that’s what mailing lists are for. :slight_smile:

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 25 September 2003 21.00, Henning wrote:

17

In SDL under what?

Windows fullscreen windows are borderless windows that cover the screen;
Windows notices this and drivers are able to page flip instead of blit.
There’s really no special flag as such that tells Windows to do this;
I’ve been able to get fast page flipping in Windows without changing the
video mode at all, only making the application cover the whole desktop.

There is a CDS_FULLSCREEN flag for ChangeDisplaySettings, but the main
effect of that is to tell Windows to revert the settings when the
program loses focus, not to enable page flipping (you can use that flag
and not actually make a fullscreen window).

(Of course, be very careful when taking advantage of these properties–I’m
sure there are plenty of undocumented exceptions, and drivers that don’t
do things the right way, and some parts of this might well be special
optimizations of my own nVidia drivers.)

I think Direct3D operates in an overlay, which could, in theory, allow
fast page flipping in a window; I don’t know if it actually has that
effect, or why OpenGL implementations don’t do this.On Thu, Sep 25, 2003 at 10:06:20PM +0300, Sami N??t?nen wrote:

On Thursday 25 September 2003 21:08, David Olofson wrote:

(Instead, they set up a window the normal way and have the 3D
accelerator render directly into the area occupied by that window.
Fullscreen is done by creating a borderless window of the right size
and then switching the display resolution and disabling panning and
resolution switching shortcuts.)

In X they render to some offscreen video memory location, which then is
clip blitted to the window. This can be clearly seen if one runs
glxgears without retrace sync in it’s default window size.

Let it run sya 10 seconds after the last output switch to another
desktop for 10 seconds. If you get about double of the seen frame rate
version, then it is simply because the driver needs to blit the rendered
GFX to the X screen. This part can be avoided, but that needs Quatro
class HW, because they can render directly to windows, if the Nvidia
driver settings are enabled.

I think this same problem persist in all Linux and I think in Windows
drivers as well, because the rendering to window can’t clip those parts
that are covered by another windows.

Sadly this same condition is still present in the fullscreen in SDL,
because the fullscreen is simply a borderless window. I don’t know if

–
Glenn Maynard

18

(Instead, they set up a window the normal way and have the 3D
accelerator render directly into the area occupied by that
window. Fullscreen is done by creating a borderless window of the
right size and then switching the display resolution and
disabling panning and resolution switching shortcuts.)

In X they render to some offscreen video memory location, which
then is clip blitted to the window.

I know some drivers do this all the time, but some do indeed render
directly into the window if you tell them to. ATI’s FireGL drivers
do, obviously, as that’s what I’m using here.

This can be clearly seen if one
runs glxgears without retrace sync in it’s default window size.

Let it run sya 10 seconds after the last output switch to another
desktop for 10 seconds. If you get about double of the seen frame
rate version, then it is simply because the driver needs to blit
the rendered GFX to the X screen.

That tells you whether the card is using true pageflipping or
back->front blits.

True single buffering is a lot easier to detect: If everything that
moves flickers like h*ll, you have single buffering. :slight_smile:

Frankly, I don’t think single buffering is useful for anything but
debugging, or as a poor man’s progress indicator when rendering still
images of extremely complex scenes.

This part can be avoided, but
that needs Quatro class HW, because they can render directly to
windows, if the Nvidia driver settings are enabled.

Most cards can render directly into a window, if the driver supports
it. All it takes is changing the frame buffer address and pitch.
However, without hardware support, complex region clipping is going
to be rather slow and awkward to implement.

Dunno’ if a FireGL 8800 has complex region clipping, but the driver
I’m using certainly has a few bugs:

Bug #1: When using single buffering + retrace sync, the maximum
frame rate is half the refresh rate. Seems like each
rectangle takes two retrace syncs…

Bug #2: Looks like every rectangular blit is retrace sync’ed
separately, as the resulting frame rate is exactly the
CRT refresh rate divided by the number of rectangles
needed to draw the partially occluded window. Divide
that by 2 again, in single buffer mode. (2 syncs/rect.)

Bug #3: Rectangle subdivision is suboptimal. A corner of another
window results in 3 rects, while 2 would have been
enough. (Easy to conclude after having spotted the two
bugs above.)

Guess I’ll try the latest driver some time and see if some of this has
been fixed, though it hasn’t annoyed me too much so far… (I don’t
use single buffering, and I don’t have OpenGL windows partially
occluded by other windows when using them.)

I think this same problem persist in all Linux and I think in
Windows drivers as well, because the rendering to window can’t clip
those parts that are covered by another windows.

It sure can (or I’m hallucinating here ;-), but it’s hairy and
possibly slow, unless there’s hardware support for it.

I think I’ll disable retrace sync and do some more tests to see how
the FireGL performs…

Sadly this same condition is still present in the fullscreen in
SDL, because the fullscreen is simply a borderless window. I don’t
know if it could be possible to use randr and get the root windows
gc in fullscreen situations. This would eliminate the need for the
extra blit, but I don’t know if the drivers support this correctly.

Well, all you need is some way of setting up two “windows” and a way
to flip between them…

How about using two single buffered windows and desktop panning (h/w
scrolling)? Requires a desktop big enough to fit two screens of the
desired resolution, but it might actually be possible to do on the
application level, at least with cards that support true single
buffering.

Anyway, that’s just a quick/fun hack, though it demonstrates one of
the issues with XFree86 and drivers that want to do this sort of
stuff; you have one display buffer, and that’s it.

DGA seems to be able to get around that, but I don’t know if it’s of
much help to OpenGL drivers as it is.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 25 September 2003 21.06, Sami N??t?nen wrote:

On Thursday 25 September 2003 21:08, David Olofson wrote:

19

If you have 4.3.x xfree and SDL is not 1.2.6 then the problem is the
automatic modelines that 4.3.x X versions produce. The newer X will
list multiple instances of different resolutions in descending refresh
rate order. The older X versions simply listed only the highest refresh
rate mode. This leads to the problem in the earlier SDL versions,
because those SDL verisions traversed the list in reverse order and
thus picked the lowest matching refresh rate line.

If this doesn’t work out for you with the 1.2.6 version, then I simply
got lucky, because the Gentoo package maker has provided the patch with
the 1.2.6 version as they did with the 1.2.5. :)On Thursday 25 September 2003 22:00, Henning wrote:

Did you forget to list your preferred modelines in the config for
16 bpp? (Each bpp has a separate configuration…)

I’m using XFree4.something, and I can’t find any modelines in my
XF86Config file. I don’t know how to change the refresh rate.

20

[…OpenGL, windowed mode & clipping…]

Sadly this same condition is still present in the fullscreen in
SDL, because the fullscreen is simply a borderless window. I
don’t know if

In SDL under what?

No, this is about XFree86, which is what most people use on Linux,
FreeBSD and other Unix- and Unix-like systems.

It’s possible that some Windows drivers use similar methods, but I
think most of them just take over the display hardware (killing the
desktop) and set up a display. That means they can use true page
flipping if you ask for double buffering, since they manage all
resources directly.

Windows fullscreen windows are borderless windows that cover the
screen;

There’s one difference from XFree86: Windows changes the desktop size
(which means the display surfaces is reallocated - potentially with
multiple pages), whereas XFree86 sticks with the desktop it allocated
when it was fired up.

Windows notices this and drivers are able to page flip
instead of blit. There’s really no special flag as such that tells
Windows to do this; I’ve been able to get fast page flipping in
Windows without changing the video mode at all, only making the
application cover the whole desktop.

Interesting… That is, DX automatically starts to flip between the
visible part of the desktop (where your window is) and it’s back
surfaces, when it discovers that you can’t see anything but the
client area of the window? That’s a rather cool hack! :slight_smile:

There is a CDS_FULLSCREEN flag for ChangeDisplaySettings, but the
main effect of that is to tell Windows to revert the settings when
the program loses focus, not to enable page flipping (you can use
that flag and not actually make a fullscreen window).

…but then it will (normally) blit instead of flip?

(Of course, be very careful when taking advantage of these
properties–I’m sure there are plenty of undocumented exceptions,
and drivers that don’t do things the right way, and some parts of
this might well be special optimizations of my own nVidia drivers.)

Right. Just for starters, what happens when the window is partially
occluded? Then it can no longer serve as one of the pages - or can
it…?

I think Direct3D operates in an overlay,

Now, that would certainly explain things. :slight_smile: However, that’s
obviously a hardware feature - and I suspect it’s one with certain
limitations, such as a limit to the number of overlays you can have
on-screen. Many cards have such a h/w overlay that’s normally used
for video playback, but the ones I’ve seen so far seem to support
only one h/w overlay. Maybe this is a generalization and extension of
that stuff?

which could, in theory,
allow fast page flipping in a window; I don’t know if it actually
has that effect, or why OpenGL implementations don’t do this.

Well, it could definitely be used for that purpose, since flipping an
overlay is just like flipping the whole screen; change a pointer and
the RAMDAC DMA will do the rest…

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 25 September 2003 22.40, Glenn Maynard wrote: