opengl g400 vsync

[gavril0]

I am trying to vsync a program that I am developing to
present stimuli in an experimental psychology lab. Controlling
the timing and duration (nb. of frames) of stimuli is of
utmost importance for this application.

I have WK2000/MilleniumDHG400Max/DELLM990 monitor
with last matrox drivers (package 5.93), graph BIOS and
utility (Mtstu50204) installed.

My programming environment is VisualC/C 6.0 and GLUT/OpenGL.
I have glutPostRedisplay() in the Idle function and
glutSwapBuffers() at the end of the display function. Drawing
in the display function is very quick (<2ms).

The problem is that the Display function does not wait for the
vertical blank. My timing measurments show that this function
is called at a much higher rate (>500Hz) than the monitor
refresh rate (85Hz). I would have expected that glutSwapBuffer
would not return before vertical blank when Vsync is enabled.

I tried to set Page Flipping always on with the utility without
success. It looks like changing the setting on the Opengl tab
has no effect.

I have also tried to use wglSwapIntervalExt(1) to set
vsync but WGL_EXT_swap_control extension is not implemented
in Visual C/C++ 6.0 implementation of OpenGL.

Any comment/suggestion appreciated.

Regards,

Gabriel

PS: The question already came several times (in general
in relation with gaming). This is NOT however a question
about making an opengl game work. In fact, I am not
a gamer and I have not idea what Quake2 or Quake3
looks like . This is a question about finding out if g400
really has this capacity and how to set it up. I have
some doubt about it given the large number of gamers
for whom it has been impossible to make it work
(see 1999 thread by Ed Braga).

[dZeus]

you should ask on the forum of beyond3d.com. If it's not a card specific problem, they will be able to help you.

[gavril0]

I think the problem lies with the driver of the g400 card
which have (perhaps undeserved?) reputation of not being
well designed for opengl.

The problem is most likely related to the card (hence,
my question to this forum). If not, I would love to have
a proof that swapping buffers in an opengl application
occurs in sync with the vertical blank as it should when
vsync is enabled. Other people with different
cards have confirmed that glutSwapBuffers should wait
for vertical blank before returning.

To put it in another way, my questions are:

1) does matrox g400 provide WGL_EXT_swap_control
support (as NVIDIA cards do)? Note that for a Windows
OpenGL implementation, extensions are usually dynamically
loaded from the DEVICE DRIVER (i.e, the g400 driver),
rather than statically linked. Function pointers to extension
APIs are obtained from wglGetProcAddress and use to invoke
the extension (which is what I am doing). For more info
about extensions,

http://oss.sgi.com/projects/ogl-sample/registry/doc/rules.html

2) if not, is there a way to set vsync that would provide
the desired behaviour (i.e., glutSwapBuffers would
wait for vertival blank before returning)? (see my
first post to see what I have already tried).

3) if not, can somebody explain me what is the intended
behavior of the matrox g400 driver in this case? and
how can I detect when the vertical blank occured?

Anybody has programing experience or authoritative info
from matrox on the subject? Seeing no tearing in an
opengl game is not a proof (I don't see any tearing
in my application but it still does not behave as it
should when Vsync is enabled).

Thank you for your help,

Gabriel

[gavril0]

I confirm that it is a problem with g400 driver. I tried on
another system (NVIDIA 5700 Ultra) and, for this card,
1) WGL_EXT_swap_control opengl extension is supported
2) glutSwapBuffers waits for vertical blank when Vsync
is enabled (frequency of my display function == monitor
refresh rate).

Conclusion: even with the newest driver, g400 does not
implement vsync with opengl as expected. It would
be nice if Matrox provided precise and detailed information
on its opengl support (especially on a issue like vsync
which, from what I can set in various forums, has popped
up many many times).

Gabriel

[Maggi]

you mean the last MTSTU doesn't work for forcing VSync on ?

surprises me quite a bit, cos it used to work for ages ...

[gavril0]

I don't think it is an issue of older versus more recent
drivers. It also did not work with the older driver
that came with the card. Of course, I haven't tried
all drivers . But before somebody tells me that
vsync works with some driver, let me be very specific
about the question/problem that I have identified:

When programing, there are two ways of getting your
application to synchronize with vsync that I know of:

1) WaitForVerticalBlank() and some associated functions
if you are using DirectX

2) wglSetSwapIntervalEXt() that is part of the
WGL_EXT_swap_control extension of opengl (OpenGl 1.1
that is implemented by Miscrosoft does not include this
extension). It must be provided by the device driver and,
in OpenGl, there is a mechanism by which you can make
these functions available (see the link in a previous post).

I believe that opengl support of Matrox latest device driver
for the G400 card does not include the WGL_EXT_swap_control
extension. The older driver that came with the card also
did not support it. Thus, it is impossible to do VSYNC with the
G400 with OpenGL However, it may still be possible that
Vsync works with the G400 driver if you use DirectX's function
WaitForVerticalBlank() in your program (I don't know, I
haven't tried since I want to remain with OpenGL).
I have now changed my G400 card with an NVIDIA
FX 5700 Ultra the driver of which supports the
WGL_EXT_swap_control extension and now my application
works as desired.

My guess is that Matrox G400 drivers never supported
the WGL_EXT_swap_control extension but I could not
get answer from Matrox Tech Support.

If somebody has succeeded using WGL_EXT_swap_control
extension in a program, it would still be interesting to
know with which card and driver (To my knowledge,
Matrox website does not list OpenGl extension supported
by their drivers as does NVIDIA and perhaps others).

Gabriel