Hi,
I’ve been profiling my app and i’ve noticed that SDL_GL_SwapBuffers
takes the 40%!! of the running time, so i’ve noticed that, perhaps
SwapBuffering is blocking the execution (perhaps it does glFinish();
SwapBuffers();
As this is not the expected behavour i would like to know if:
a) i’ve settled the opgnl initialization incorrectly (atm the flags i
have are:
SDL_OPENGL | SDL_HWSURFACE | SDL_HWPALETTE| SDL_GL_DOUBLEBUFFER
or b) SwapBuffers really blocks the pipeline
I’ve been profiling my app and i’ve noticed that SDL_GL_SwapBuffers
takes the 40%!! of the running time, so i’ve noticed that, perhaps
SwapBuffering is blocking the execution (perhaps it does glFinish();
SwapBuffers();
As this is not the expected behavour i would like to know if:
a) i’ve settled the opgnl initialization incorrectly (atm the flags i
have are:
SDL_OPENGL | SDL_HWSURFACE | SDL_HWPALETTE| SDL_GL_DOUBLEBUFFER
or b) SwapBuffers really blocks the pipeline
Hi,
I’ve been profiling my app and i’ve noticed that SDL_GL_SwapBuffers
takes the 40%!! of the running time, so i’ve noticed that, perhaps
SwapBuffering is blocking the execution (perhaps it does glFinish();
SwapBuffers();
wglSwapBuffers is similar last I checked (y2k)
glXSwapBuffers man page:
glXSwapBuffers promotes the contents of the back buffer of
drawable to become the contents of the front buffer of
drawable. The contents of the back buffer then become
undefined. The update typically takes place during the
vertical retrace of the monitor, rather than immediately
after glXSwapBuffers is called.
glXSwapBuffers performs an implicit glFlush before it
returns. Subsequent OpenGL commands may be issued immedi?
ately after calling glXSwapBuffers, but are not executed
until the buffer exchange is completed.
Most video card drivers have a setting that disables this, but in
theorey this can lead to “tearing”. I’ve never seen that myself, not
for lack of trying. But that fact that monitors can refresh at only
85Hz kinda makes those “3000 frames per second of Quake” claims academic.> As this is not the expected behavour i would like to know if:
a) i’ve settled the opgnl initialization incorrectly (atm the flags i
have are:
SDL_OPENGL | SDL_HWSURFACE | SDL_HWPALETTE| SDL_GL_DOUBLEBUFFER
or b) SwapBuffers really blocks the pipeline
I’ve been profiling my app and i’ve noticed that SDL_GL_SwapBuffers
takes the 40%!! of the running time
SDL_GL_SwapBuffers() waits for the VBL (depending on your video driver
settings). If your app is going at the speed of the monitor vertical
frequency, then that’s the reason.On 21/03/2004, Toni, you wrote:
–
Please remove “.ARGL.invalid” from my email when replying.
Incoming HTML mails are automatically deleted.
SDL_GL_SwapBuffers() waits for the VBL (depending on your video driver
settings). If your app is going at the speed of the monitor vertical
frequency, then that’s the reason.
In theory i have disabled the vertical sync to get the maximum speed on
rendering having a first approximation on how fast my algorithms are
running,
Are you saying Oliver that i can’t use SDL because it will block on
every SDL_GL_SwapBuffers()?
In theory i have disabled the vertical sync to get the maximum speed
on rendering having a first approximation on how fast my algorithms
are running,
Are you saying Oliver that i can’t use SDL because it will block on
every SDL_GL_SwapBuffers()?
I’m just saying what I wrote :-). If your app’s FPS are the same as your
monitor’s vertical frequency, then the reason why SDL_GL_SwapBuffers()
blocks is very probably because it waits for the VBL.
If you want to profile your algorithms, you could time them precisely
instead of just looking at the FPS.
Alternatively, you could remove the call to SDL_GL_SwapBuffers().
Someone recently posted that; it might help if you are using MSWindows:
Use the following code to disable vsync waits in Windows:
Hi,
I’ve been profiling my app and i’ve noticed that SDL_GL_SwapBuffers
takes the 40%!! of the running time,
What is the size of the scene you are drawing ? How many
triangles/vertexes ?
so i’ve noticed that, perhaps SwapBuffering is blocking the execution
(perhaps it does glFinish(); SwapBuffers();
No.
As this is not the expected behavour i would like to know if:
a) i’ve settled the opgnl initialization incorrectly (atm the flags i
have are:
SDL_OPENGL | SDL_HWSURFACE | SDL_HWPALETTE| SDL_GL_DOUBLEBUFFER
This is not correct, but shouldn’t be a problem. You don’t need any
other flags than SDL_OPENGL. SDL_HWSURFACE & SDL_HWPALETTE are for 2D
stuff. SDL_GL_DOUBLEBUFFER isn’t meant to be used as a parameter to
SDL_SetVideoMode but as a parameter to SDL_GL_SetAttribute).
or b) SwapBuffers really blocks the pipeline
Swapbuffers blocking the pipeline or not is nothing related to SDL, it’s
really an OpenGL thing. The fact that SDL_GL_SwapBuffers blocks or not
depends on the underlying video driver implementation of the swapbuffer
call and is not an SDL side-effect.
What OS/video drivers are you using ?
SDL_GL_SwapBuffers() waits for the VBL (depending on your video driver
settings). If your app is going at the speed of the monitor vertical
frequency, then that’s the reason.
In theory i have disabled the vertical sync to get the maximum speed on
rendering having a first approximation on how fast my algorithms are
running,
Are you saying Oliver that i can’t use SDL because it will block on
every SDL_GL_SwapBuffers()?
I would say rather that your mechanism for measuring execution time is
inaccurate. Your video pipeline is hopefully long, which means its
working in || to your own code, for free. If you really want to profile
anyway, add a command line option and write something like:
I’m just saying what I wrote :-). If your app’s FPS are the same as your
monitor’s vertical frequency, then the reason why SDL_GL_SwapBuffers()
blocks is very probably because it waits for the VBL.
If you want to profile your algorithms, you could time them precisely
instead of just looking at the FPS.
Alternatively, you could remove the call to SDL_GL_SwapBuffers().
Yeah but i have vsync disabled and the app runs at 80 fps (when monitor
sync is 75) and, when i profiled my app i got that 40% of time it was
blocked in SDL_GL_SwapBuffers so it’s really strange.
Yeah but i have vsync disabled and the app runs at 80 fps (when monitor
sync is 75) and, when i profiled my app i got that 40% of time it was
blocked in SDL_GL_SwapBuffers so it’s really strange.
That is pretty strange. Are you getting hardware acceleration?
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
I’m just saying what I wrote :-). If your app’s FPS are the same as your
monitor’s vertical frequency, then the reason why SDL_GL_SwapBuffers()
blocks is very probably because it waits for the VBL.
If you want to profile your algorithms, you could time them precisely
instead of just looking at the FPS.
Alternatively, you could remove the call to SDL_GL_SwapBuffers().
Yeah but i have vsync disabled and the app runs at 80 fps (when monitor
sync is 75) and, when i profiled my app i got that 40% of time it was
blocked in SDL_GL_SwapBuffers so it’s really strange.
Not so strange. The swapbuffers call has an implicit flush in it. That
was posted earlier. The flush forces all queued operations to finish.
The wait for queued operations to finish could well be where the slow
down occurs. It breaks the parallelism of the pipeline.
If you are testing your algos on the basis of the performance of a
specific OpenGL implementation you are not doing a reasonable test. You
are basically testing and tuning for the peculiarities of a single
OS/OpenGL/Video Card combination. Not testing the general algorithm.
If you want to test a general algorithm decouple your code from OpenGL.
The easiest way to do that is to write a set of macros that will convert
your OpenGL calls to calls to empty functions. Functions that just
return. By including those macros you get code that is decoupled from
OpenGL that can be tuned and tested in the general case. By removing
those macros you get code that generates an image that you can see on
the screen so you can verify the visual correctness of your algorithms.
Then you can test your algorithm for its actual run time cost without
burying the real data under the effect of a particular OS/OpenGL/Video
Card.
Bob PendletonOn Mon, 2004-03-22 at 08:32, toni wrote:
Not so strange. The swapbuffers call has an implicit flush in it. That
was posted earlier. The flush forces all queued operations to finish.
The wait for queued operations to finish could well be where the slow
down occurs. It breaks the parallelism of the pipeline.
Yeah, could be that, that’s why i’m changing my pipeline from
UpdateFrameN();
RenderFrameN();
SwapBuffersFrameN();
To:
RenderFrameN();
UpdateFrameN+1();
SwapBuffersFrameN();
To paralelize CPU and GPU…
If you are testing your algos on the basis of the performance of a
specific OpenGL implementation you are not doing a reasonable test. You
are basically testing and tuning for the peculiarities of a single
OS/OpenGL/Video Card combination. Not testing the general algorithm.
Perhaps algorithms isn’t the best word i should use pipeline speed
(rendering speed or whatever). I’m getting slow frame rates (over 50-80)
for simple scenes even with acceleration, ok, my hardware isn’t the best
(athlon 1600 and a GFFX5200) but even with that, waiting so long til the
flush ends… i mean, i suposed newest cards could store up to 2 or 3
frames before blocking…
Not so strange. The swapbuffers call has an implicit flush in it. That
was posted earlier. The flush forces all queued operations to finish.
The wait for queued operations to finish could well be where the slow
down occurs. It breaks the parallelism of the pipeline.
Yeah, could be that, that’s why i’m changing my pipeline from
UpdateFrameN();
RenderFrameN();
SwapBuffersFrameN();
To:
RenderFrameN();
UpdateFrameN+1();
SwapBuffersFrameN();
To paralelize CPU and GPU…
If you are testing your algos on the basis of the performance of a
specific OpenGL implementation you are not doing a reasonable test. You
are basically testing and tuning for the peculiarities of a single
OS/OpenGL/Video Card combination. Not testing the general algorithm.
Perhaps algorithms isn’t the best word i should use pipeline speed
(rendering speed or whatever). I’m getting slow frame rates (over 50-80)
for simple scenes even with acceleration, ok, my hardware isn’t the best
(athlon 1600 and a GFFX5200) but even with that, waiting so long til the
flush ends… i mean, i suposed newest cards could store up to 2 or 3
frames before blocking…
Are you sending whole frames to the video card? If so that is the
problem.
Bob PendletonOn Tue, 2004-03-23 at 13:24, toni wrote:
Are you by any chance using an OpenGL driver that performs “flips” by
blitting from an offscreen buffer? Most drivers on most platforms do
that in windowed mode, and some - including most Linux drivers - do
it in fullscreen mode as well.
40% is still a lot of time for an accelerated back->front blit though,
especially if the unrestricted frame rate is around 80 fps… What
kind of hardware is this, what resolution are you using etc?
//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 Monday 22 March 2004 15.32, toni wrote:
Olivier Fabre wrote:
I’m just saying what I wrote :-). If your app’s FPS are the same
as your monitor’s vertical frequency, then the reason why
SDL_GL_SwapBuffers() blocks is very probably because it waits for
the VBL.
If you want to profile your algorithms, you could time them
precisely instead of just looking at the FPS.
Alternatively, you could remove the call to SDL_GL_SwapBuffers().
Yeah but i have vsync disabled and the app runs at 80 fps (when
monitor sync is 75) and, when i profiled my app i got that 40% of
time it was blocked in SDL_GL_SwapBuffers so it’s really strange.
Are you sending whole frames to the video card? If so that is the
problem.
Uh?, sorry that sentences has puzzled me… how could i send partial
frames to the video card and then make a swap buffers?.
I mean… what is the alternative to don’t send whole frames to the
video card?
Are you sending whole frames to the video card? If so that is the
problem.
Uh?, sorry that sentences has puzzled me… how could i send partial
frames to the video card and then make a swap buffers?.
Most of us send drawing commands to the video card and let it draw the
frame. We never send a frame to the video card. The whole idea of
having hardware accelerated video cards is to let them do the drawing.
Some times you have to draw the whole frame in main memory and transfer
it to the video card. That is the way it was done before we had hardware
accelerated video cards. If you are doing something like playing a movie
where the decompression of the video stream is done in software then you
still have to build the frame in main memory and copy it to the frame
buffer.
Sending whole frames to the video card takes a looooong time. A 1024x768
frame with 32 bits per pixel is 3,145,728 bytes long at 80 fps that is
4,194,304 bytes/second. That is a lot of bytes.
I mean… what is the alternative to don’t send whole frames to the
video card?
The question is, how are you drawing your frames now?
Toni
Bob PendletonOn Wed, 2004-03-24 at 02:27, toni wrote:
i should use pipeline speed