Nouveau Will Now Sync Buffer-Swaps To VBlanks By Default

[ickle]

I'm really curious as to why the different drivers have different switches for turning off/on vsync.

Ideally we only use these options as a last resort to work around driver bugs, and we do try to use an existing name from another driver if it already exists (at least I do). Controlling sync-to-vblank is actually up to the application (DRI2SetSwapInterval), except that DRI2 doesn't expose fine enough controls in its protocol (nor does Present) and DRI2 has a few well known implementation bugs in the Xserver.

[kalrish]

Ideally we only use these options as a last resort to work around driver bugs, and we do try to use an existing name from another driver if it already exists (at least I do). Controlling sync-to-vblank is actually up to the application (DRI2SetSwapInterval), except that DRI2 doesn't expose fine enough controls in its protocol (nor does Present) and DRI2 has a few well known implementation bugs in the Xserver.

Slightly off-topic, I would like to ask, who should be responsible for V-Sync, the application or the driver? If, as you say, it's the application, how should each game implement this? Why not do that from eglSwapBuffers and its GLX counterpart? I'm using LLVMpipe and, if swaps aren't held by myself, my application outputs as much frames as possible, which has sometimes hung my computer. FWIW, I'm using EGL.

[ickle]

Slightly off-topic, I would like to ask, who should be responsible for V-Sync, the application or the driver? If, as you say, it's the application, how should each game implement this? Why not do that from eglSwapBuffers and its GLX counterpart? I'm using LLVMpipe and, if swaps aren't held by myself, my application outputs as much frames as possible, which has sometimes hung my computer. FWIW, I'm using EGL.

How and when the swap is performed is outside of the specification for ordinary SwapBuffers. OML_sync_control allows the application to specify when the swap will occur, but it still doesn't mandate the method (and so whether to tear or not) and is based on a single fixed frequency output device. GLX_MESA_swap_interval allows the application to control vsync, and it is also exposed through driconf and the vblank_mode env var. Unfortunately, there is not a single solution that allows the application to have full control of the time and method of how a frame is presented to the user, and how rendering should proceed whilst the previous frame is pending display.

[kalrish]

How and when the swap is performed is outside of the specification for ordinary SwapBuffers. OML_sync_control allows the application to specify when the swap will occur, but it still doesn't mandate the method (and so whether to tear or not) and is based on a single fixed frequency output device. GLX_MESA_swap_interval allows the application to control vsync, and it is also exposed through driconf and the vblank_mode env var. Unfortunately, there is not a single solution that allows the application to have full control of the time and method of how a frame is presented to the user, and how rendering should proceed whilst the previous frame is pending display.

Thanks for your explanation. I will try eglSwapInterval when I can, and also read further about this topic and framebuffer objects. It's indeed unfortunate that there's no consensus.

[xeekei]

I really doubt competitive gamers use nouveau and I doubt they get frames high enough to need vsync with nouveau. I can barely run the desktop last time I tried them.

Then I'm sure you tried them before they got reclocking support. They should be much faster now. The desktop should definitely reach 60 FPS.

[BlackStar]

How and when the swap is performed is outside of the specification for ordinary SwapBuffers. OML_sync_control allows the application to specify when the swap will occur, but it still doesn't mandate the method (and so whether to tear or not) and is based on a single fixed frequency output device. GLX_MESA_swap_interval allows the application to control vsync, and it is also exposed through driconf and the vblank_mode env var. Unfortunately, there is not a single solution that allows the application to have full control of the time and method of how a frame is presented to the user, and how rendering should proceed whilst the previous frame is pending display.

Actually, that is not true!

I am just wrapping up a Linux DRM backend for OpenTK and this actually gives 100% control over the render/scanout framebuffer, including page flipping, vsyncing, single-/double-/multi-buffering and anything else you might ever need. This is way more powerful than anything available on any other operating system, including DXGI on Windows. The Linux kernel APIs never fail to impress me with their strength and design.

Of course, GLX/X11 expose exactly nothing of this functionality, so desktop applications are stuck with vsync on/off and little else, but the power is there if you ever need to go deeper.

[BlackStar]

How and when the swap is performed is outside of the specification for ordinary SwapBuffers. OML_sync_control allows the application to specify when the swap will occur, but it still doesn't mandate the method (and so whether to tear or not) and is based on a single fixed frequency output device. GLX_MESA_swap_interval allows the application to control vsync, and it is also exposed through driconf and the vblank_mode env var. Unfortunately, there is not a single solution that allows the application to have full control of the time and method of how a frame is presented to the user, and how rendering should proceed whilst the previous frame is pending display.

Actually, that is not true!

I am just wrapping up a Linux DRM backend for OpenTK and this actually gives 100% control over the render/scanout framebuffer, including page flipping, vsyncing, single-/double-/multi-buffering and anything else you might ever need. This is way more powerful than anything available on any other operating system, including DXGI on Windows. The Linux kernel APIs never fail to impress me with their strength and design.

Of course, GLX/X11 expose exactly nothing of this functionality, so desktop applications are stuck with vsync on/off and little else, but the power is there if you ever need to go deeper.