Announcement

Collapse
No announcement yet.

Intel X.Org Driver Now Handles Better Tear-Free

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

  • Intel X.Org Driver Now Handles Better Tear-Free

    Phoronix: Intel X.Org Driver Now Handles Better Tear-Free

    Chris Wilson of Intel this morning released an updated xf86-video-intel X.Org driver. With this latest 3.0 pre-release comes support for TearFree on transformed outputs. There's also been other changes...

    http://www.phoronix.com/vr.php?view=MTQ5Mjg

  • #2
    Sadly, the little black box corruption still exists with this. Wish they would finally fix it.

    https://bugs.freedesktop.org/show_bug.cgi?id=68410

    Comment


    • #3
      Any chance this fixes the tearing issues for which a workaround was to disable culling in Gnome Shell for example?
      http://phoronix.com/forums/showthrea...687#post359687
      Last edited by Bucic; 10-23-2013, 10:07 AM.

      Comment


      • #4
        Originally posted by deanjo View Post
        Sadly, the little black box corruption still exists with this. Wish they would finally fix it.

        https://bugs.freedesktop.org/show_bug.cgi?id=68410
        I will have a workaround of some form before 3.0.

        Originally posted by Bucic View Post
        Any chance this fixes the tearing issues for which a workaround was to disable culling in Gnome Shell for example?
        http://phoronix.com/forums/showthrea...687#post359687
        TearFree would prevent all of that - but really this is a bug in the compositor and DRI2 protocol and should be fixed there.

        Comment


        • #5
          Originally posted by ickle View Post
          I will have a workaround of some form before 3.0.



          TearFree would prevent all of that - but really this is a bug in the compositor and DRI2 protocol and should be fixed there.
          How do you know? Can you post me to any existing bug reports? I'm struggling with tearing for months now!

          Comment


          • #6
            And what is this tearfree you speak of? It doesn't seem to be a package or a tool.

            Comment


            • #7
              Originally posted by Bucic View Post
              How do you know? Can you post me to any existing bug reports? I'm struggling with tearing for months now!
              The crux of the issue is the attempt to "optimise" updates of the frontbuffer through the use of DRI2CopyRegion (called through MESA_copy_subbuffer). That operation is not specified as being synchronous wrt vrefresh, so it is allowed to tear. Furthermore as a tearing DRI2SwapBuffer itself calls the backend CopyRegion function, there is no way the backend can detect whether or not it should prevent tearing. It's a glorious snafu.

              However, if the compositor just does a plain old SwapBuffer, the update is tear free. (Of course that in itself has negative implications for prime and slaves like udl.)

              The root cause here is the inadequacy of the DRI2 protocol for efficient and tear-free compositing.

              Comment


              • #8
                I have no idea what you are talking about In Fedora 17 I had no tearing and now I have. I would just like to know against what package I report the bug and how should I title it.

                Comment


                • #9
                  Originally posted by Bucic View Post
                  And what is this tearfree you speak of? It doesn't seem to be a package or a tool.
                  It's a configuration option to remove screen tearing. From the Arch forums:

                  cat /etc/X11/xorg.conf.d/20-intel.conf
                  Section "Device"
                  Identifier "Intel Graphics"
                  Option "SwapbuffersWait" "true"
                  Option "AccelMethod" "sna"
                  Option "TearFree" "true"
                  EndSection

                  I've used these options myself and they work perfectly, I think I get better performance from switching to sna too.

                  Comment


                  • #10
                    when will opengl 3.3 and these feature get in xf86-video-ati

                    Comment


                    • #11
                      Originally posted by Bucic View Post
                      And what is this tearfree you speak of? It doesn't seem to be a package or a tool.
                      It is an Option for the driver:
                      Code:
                      Section "Device"
                        Identifier "Device0"
                        Option "TearFree" "true"
                      EndSection
                      Originally posted by sharan View Post
                      when will opengl 3.3 and these feature get in xf86-video-ati
                      -ati already offers something similar: Option "VSync". However, that causes the driver to stall the GPU prior to every operation that writes to the frontbuffer - potentially causing a severe performance degradation - and only working correctly for the primary output. As for OpenGL 3.3, your crystal ball is as good as mine.

                      Comment


                      • #12
                        I'd love for the annoying 'font glitch', where a random letter appears all garbled to go away on the gm 45 since it's pretty much the only i▀sue I came across using SNA, not sure it will happen tho since it's old hardware....


                        I ask the intel devs not to forget, or neglect, iron lake, gen4 and gma 950 .... I still use them daily

                        Comment


                        • #13
                          Originally posted by ickle View Post
                          As for OpenGL 3.3, your crystal ball is as good as mine.
                          Ickle, two questions for ya if you don't mind.

                          1) Any word, that you can speak of, from the higher ups about whether or not Intel is going to adopt Nvidia's new G-Sync tech?

                          2) As someone who hasn't worked with OpenGL an awful lot, I know that getting the higher OpenGL versions supported is important for features, but I was curious... Going from 3.0 to 3.3 or 3.3 to 4.0 or any other OpenGL version bump, do they actually yield performance improvements? 2.1 to 3.0 I'm sure had a lot of improvements just because of how much of a break it was. But from 3.0 forward has Khronos ever released an extension that was basically "This is the same as the old one...but we found a better way to do it, so its faster." or a similar situation wherein just by supporting a higher OpenGL spec the performance would increase.

                          Comment


                          • #14
                            Dear ickle,
                            I know it's enerving to get and answer all the questions about bugs but are there any updates regarding: https://bugs.freedesktop.org/show_bug.cgi?id=54226 ?

                            In the meantime i will give the new driver release a try

                            Comment


                            • #15
                              Thank you, Shirudo and Ickle!

                              Originally posted by Shirudo View Post
                              It's a configuration option to remove screen tearing. From the Arch forums:

                              cat /etc/X11/xorg.conf.d/20-intel.conf
                              Section "Device"
                              Identifier "Intel Graphics"
                              Option "SwapbuffersWait" "true"
                              Option "AccelMethod" "sna"
                              Option "TearFree" "true"
                              EndSection

                              I've used these options myself and they work perfectly, I think I get better performance from switching to sna too.
                              Excuse my ognorance but why, the fuck, TearFree is not enabled by default?! Does someone up there think tear-free image is a luxury in 2013 Linux?

                              I may well sound like a radical, but to me work on a module that introduced a regression causing tearing should be halted and all resources assigned to the task until the regression is removed. That would teach those interns. Sorry, but if the word 'tearing' comes up in 2013 this alone indicates a failure. And here we have Linus Torvalds ranting over Fedora not refreshing installation images. Adjust your freaking priorities!
                              Last edited by Bucic; 10-23-2013, 02:04 PM.

                              Comment

                              Working...
                              X