Announcement

Collapse
No announcement yet.

Nouveau Will Now Sync Buffer-Swaps To VBlanks By Default

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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.

    Comment


    • #12
      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.

      Comment


      • #13
        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.

        Comment


        • #14
          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.

          Comment


          • #15
            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.

            Comment


            • #16
              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.

              Comment


              • #17
                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.

                Comment

                Working...
                X