Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Nouveau Will Now Sync Buffer-Swaps To VBlanks By Default

  1. #11

    Default

    Quote Originally Posted by ua=42 View Post
    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.

  2. #12
    Join Date
    Feb 2014
    Posts
    35

    Default

    Quote Originally Posted by ickle View Post
    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.

  3. #13

    Default

    Quote Originally Posted by kalrish View Post
    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.

  4. #14
    Join Date
    Feb 2014
    Posts
    35

    Default

    Quote Originally Posted by ickle View Post
    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.

  5. #15
    Join Date
    Oct 2012
    Location
    Sweden
    Posts
    342

    Default

    Quote Originally Posted by philip550c View Post
    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.

  6. #16
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote Originally Posted by ickle View Post
    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.

  7. #17
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote Originally Posted by ickle View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •