You need to explicitly use the DGA driver by setting the environment variable
SDL_VIDEODRIVER=dga
Ah, thanks. Why isn’t this enabled by default?
Also, I just tested it and apart from double buffering not looking
functional the result is also not very promising. I get about 83 fps
compared to the 180 fps I get with my own dga backend.
Any ideas?–
Regards
Abraham
Q: Why are Unix emulators like your right hand?
A: They’re just pussy substitutes!
Also, I just tested it and apart from double buffering not looking
functional the result is also not very promising. I get about 83 fps
compared to the 180 fps I get with my own dga backend.
it sounds like SDL is waiting for vertical refresh
Ah, that explains it. The strange thing then is why it flickers.
Did you check that SDL_DOUBLEBUF was actually set by SDL_SetVideoMode()?
Perhaps there were no sufficiently big video modes available, or not the
requested depth so you got a software emulation instead. Trace through
the SDL library code and you will get a clearer picture of what is going
on
Is there
any way to disable waiting for vertical refresh so I can just compare
framerates?
It beats me why you want higher frame rate than your screen refresh frequency
[ I CC: this to the list, since it is of general interest and I can’t test
anything with DGA in it anyway ]
No, I check everything before and after I call SDL_SetVideoMode(). It uses
all the hardware acceleration, uses double buffering (you can actually see
the difference when disabling SDL_DOUBLEBUF as well - strangely enough it
STOPS flickering - go figure) and everything is in video memory, not system
memory, so all that’s left is that it’s waiting for the vertical refresh…
So DGA_FlipHWSurface() in SDL_dgavideo.c should be called. Check that
it does what it should. Try changing the XFlush there to an XSync
instead, and see if that improves matters
After all, how on earth are you going to do profiling if most of the time is
spent on waiting for the vertical refresh?
There is no point in providing unsynchronised page-flipping in SDL just for
some artificial benchmarks, and some hardware might not even support it
No, I check everything before and after I call SDL_SetVideoMode(). It uses
all the hardware acceleration, uses double buffering (you can actually see
the difference when disabling SDL_DOUBLEBUF as well - strangely enough it
STOPS flickering - go figure) and everything is in video memory, not system
memory, so all that’s left is that it’s waiting for the vertical refresh…
So DGA_FlipHWSurface() in SDL_dgavideo.c should be called. Check that
it does what it should. Try changing the XFlush there to an XSync
instead, and see if that improves matters
This presents me with a problem. How do I get the display pointer since SDL
doesn’t provide me with a way to access that? (Remember I’m using SDL_Flip()
at the moment to get the screen to update).
As for making sure DGA_FlipHWSurface() is called - It seems the ggi debian
maintainer messed up (there’s not library to link against statically) so I
can’t compile the binary statically so I can do profiling and thus see if
that is called. I’ll mail the maintainer and get this fixed and then try it…
After all, how on earth are you going to do profiling if most of the time is
spent on waiting for the vertical refresh?
There is no point in providing unsynchronised page-flipping in SDL just for
some artificial benchmarks, and some hardware might not even support it
There is: Benchmarking your code. The only other alternative is to actually
not write anything to the screen (and therefore you can skip all screen
stuff) and measure the framerates then, but of course this is unrealistic if
you have some interactive application.
The question remains. Is it possible to disable waiting for the refresh rate
or not?–
So DGA_FlipHWSurface() in SDL_dgavideo.c should be called. Check that
it does what it should. Try changing the XFlush there to an XSync
instead, and see if that improves matters
This presents me with a problem. How do I get the display pointer since SDL
doesn’t provide me with a way to access that? (Remember I’m using SDL_Flip()
at the moment to get the screen to update).
I meant that you should change DGA_FlipHWSurface(), called by SDL_Flip()
As for making sure DGA_FlipHWSurface() is called - It seems the ggi debian
maintainer messed up (there’s not library to link against statically) so I
can’t compile the binary statically so I can do profiling and thus see if
that is called. I’ll mail the maintainer and get this fixed and then try it=
I’m not sure what you need ggi for. Build SDL with debug info and run gdb
on it, insert printf()s, hook up a scope, whatever you prefer
The question remains. Is it possible to disable waiting for the refresh rate
or not?
The question remains. Is it possible to disable waiting for the refresh rate
or not?
For benchmarking purposes, you can simply remove the waitvbl call in the
SDL DGA driver. There is no way to alter the sync behavior in the SDL 1.2
API, but there may be finer control in SDL 1.3.
BTW, don’t use XSync() instead of XFlush() in the DGA driver. XSync()
adds a stop-and-wait round-trip to the X server, while the current code
makes sure the X server is performing the requested operations and then
waits for them to complete on the next lock or accelerated operation.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
BTW, don’t use XSync() instead of XFlush() in the DGA driver. XSync()
adds a stop-and-wait round-trip to the X server, while the current code
makes sure the X server is performing the requested operations and then
waits for them to complete on the next lock or accelerated operation.
This is a question of intended semantics. There is no guarantee when the X
server will be scheduled after calling XFlush(), so if the user expects the
display to be updated when SDL_Flip() returns then XSync() is needed. On
the other hand, other drivers have made similar trade-offs so perhaps it’s
acceptable, but it should be documented.
I see that several DGA1 calls do an implicit XSync(), but none of the
DGA2 calls. XDGASync() does wait for a reply so it has the same effect.
I agree that this cannot be the reason for his observed flickering though.
Abraham, since you seem to know both xlib and dga I, trust you to find the
DGA problem and send us a patch if you find a bug. Everyone would benefit