Announcement

Collapse
No announcement yet.

Intel Linux Driver Still Working To Address Tearing

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

  • Intel Linux Driver Still Working To Address Tearing

    Phoronix: Intel Linux Driver Still Working To Address Tearing

    Open-Source Intel developers have long been working towards a tear-free Linux desktop with proper vsync support. For Sandy Bridge and Ivy Bridge hardware there's still been some tearing issues, but they hope to soon finally have it solved...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Will it eliminate tearing for multi-monitor setups, too?

    Because right now I get almost tear-free playback on my main monitor (DVI) via kwin vsync (except for a bug in 4.9) but lots of tearing on the second (HDMI).

    Comment


    • #3
      Originally posted by enteon View Post
      Will it eliminate tearing for multi-monitor setups, too?
      I don't think so. My workaround is to switch the primary display via xrandr to the display I'm actually using. So when I work or browse the internet I use 'xrandr --output DVI-0 --primary' to get no tearing with the DVI monitor and when I watch movies/videos I use 'xrandr --output HDMI-0 --primary' to get tearfree video output.

      Comment


      • #4
        Originally posted by enteon View Post
        Will it eliminate tearing for multi-monitor setups, too?

        Because right now I get almost tear-free playback on my main monitor (DVI) via kwin vsync (except for a bug in 4.9) but lots of tearing on the second (HDMI).
        No. The way to achieve that is to use pageflipping. Otherwise you will need to process a synchronized update on one pipe, then a synchronized updated on the second pipe, which is very likely miss the vblank every time and so lead to stuttering. Unlike pageflipping which is asynchronous and saves power. (The latter being a major issue on more recent chipsets.)

        Comment


        • #5
          Nice to know that I can switch tearing between monitors, thanks.


          Now my xorg.log states:
          (II) intel(0): Kernel page flipping support detected, enabling

          This might be a dumb question, but why do I see tearing then?
          Is page flipping simply not used by X/Kwin?
          Could I do something about it?

          Thank you.

          Comment


          • #6
            I don't like the idea of losing power savings, is this something that will be enabled by default, or is it just talking about the optional TearFree xorg conf option?

            From what I've seen this tearing issue is only a problem if you aren't using an opengl compositor. Compiz in ubuntu 12.10 seems to support pageflipping, because I get no tearing on my intel card even with vsync disabled in compizconfig, and I get no tearing in gnome-shell as long as I use the CLUTTER_DEBUG=disable-culling workaround, no tearing in kwin either.
            Last edited by bwat47; 21 October 2012, 11:43 AM.

            Comment


            • #7
              Originally posted by bwat47 View Post
              I don't like the idea of losing power savings, is this something that will be enabled by default, or is it talking about the optional TearFree xorg conf option?

              From what I've seen this tearing issue is only a problem if you aren't using an opengl compositor. Compiz in ubuntu 12.10 seems to support pageflipping, because I get no tearing on my intel card even with vsync disabled in compizconfig, and I get no tearing in gnome-shell as long as I use the CLUTTER_DEBUG=disable-culling workaround, no tearing in kwin either.
              First note that all Intel hardware up to SandyBridge has functional vsync support with no greater cost than stalling the GPU until the blit can proceed.

              The problem is that with the agressive powersaving of SandyBridge and the greater decoupling between the display engine and the GPU, the ability to delay rendering until a particular scanline had passed was assumed to be a legacy feature and the GPU commands to do so were removed. By presuming that all updates would then be through a compositor using pageflipping (i.e. their primary target, Windows Vista/7/8), they were then able to make further power savings. If you use an OpenGL (really DRI2) compositor that only pageflips (i.e. doesn't try to take "advantage" of MESA_copy_sub_buffer), you will not see any tearing, suffer very little jitter, and maximise the power savings of the GPU.

              The TearFree option (still in its infancy, and really only a proof-of-principle at this stage) is to make sure that even a bare X only ever pageflips. This is primarily because future hardware will have even more widespread aggressive power savings that assume a compositor, and worst case scenario, the display engine will only be functional with a pageflipping compositor.

              Comment


              • #8
                Originally posted by enteon View Post
                Nice to know that I can switch tearing between monitors, thanks.


                Now my xorg.log states:
                (II) intel(0): Kernel page flipping support detected, enabling

                This might be a dumb question, but why do I see tearing then?
                Is page flipping simply not used by X/Kwin?
                Could I do something about it?

                Thank you.
                So the good news is that you do indeed have a system that supports pageflipping. However, as you rightly surmise, it requires an OpenGL application or compositor to replace the entire scanout buffer in a single glXSwapBuffers() request, i.e. we can only pageflip to the new buffer if that buffer should replace every single pixel on the scanout. Using Kwin, you would need to enable Desktop Effects using OpenGL. Or if you only care about tearing in individual fullscreen applications, choose applications that use DRI2 to update their output (i.e. OpenGL or VA-API).

                Comment


                • #9
                  Yes I do use OpenGL with enabled VSync option. The remaining tearing I'm seeing seems to be a bug in Kwin (https://bugs.kde.org/show_bug.cgi?id=307965)

                  This is only on my main monitor, on the second there does not seem to be any synching.

                  Edit: Windows is fine as long as you use an Aero theme, with anything different everything tears (both monitors).

                  So this looks like another Kwin bug?
                  Last edited by enteon; 21 October 2012, 12:34 PM.

                  Comment


                  • #10
                    Originally posted by enteon View Post
                    Yes I do use OpenGL with enabled VSync option. The remaining tearing I'm seeing seems to be a bug in Kwin (https://bugs.kde.org/show_bug.cgi?id=307965)

                    This is only on my main monitor, on the second there does not seem to be any synching.

                    Edit: Windows is fine as long as you use an Aero theme, with anything different everything tears (both monitors).

                    So this looks like another Kwin bug?
                    Yes, the tearing you see in Kwin's compositor is because they use MESA_copy_sub_buffer rather than composite the whole framebuffer and swap. MESA_copy_sub_buffer was originally created as an optimisation and all the compositors were encouraged to use it. In retrospect, it was a bad idea, hurting the bandwidth constrained IGP devices the most. The very same devices that it claimed to be designed for. And now continued use of that extension is an extreme pessimation.

                    Comment

                    Working...
                    X