Announcement

Collapse
No announcement yet.

Intel Haswell HD Graphics 4600 Performance On Ubuntu Linux

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

  • #21
    Is it tearing ?

    I understand this is not performance related but still it's very important for day to day use, from HD1000 to HD4000 intel HD graphics are more or less tearing.

    I was told it was an hardware problem and can't be 100% solved, testing the xorg "tear free" option effectively suppress it but the performance drop is too important,
    the only effective way I found to reduce it to something acceptable is using UXA but it is still here.

    If you have tested it can you tell me if haswell graphics also have this problem ?

    Comment


    • #22
      Originally posted by rafirafi View Post
      I understand this is not performance related but still it's very important for day to day use, from HD1000 to HD4000 intel HD graphics are more or less tearing.

      I was told it was an hardware problem and can't be 100% solved, testing the xorg "tear free" option effectively suppress it but the performance drop is too important,
      the only effective way I found to reduce it to something acceptable is using UXA but it is still here.

      If you have tested it can you tell me if haswell graphics also have this problem ?
      TearFree is still work-in-progress. I need to get it finished in order to improve power management on systems not running a compositor, and the copy-on-write support was a step towards that. That it hurts performance at the moment is known, and will soon be fixed (within reason, it will always be lower performance than not enabling it for obvious reasons).

      Only UXA tears. SNA supports vsync'ed rendering with Haswell on all kernels, and vsync'ed rendering with Sandybridge/Ivybridge since kernel v3.8. However, there are circumstances (such as when the client is too slow) that the driver forces a potentially tearing path in a technique that is known as Adaptive Vsync (in order to not stall the already too slow client). Hopefully, we can get fine control of which presentation methods the driver should use into the DRI3/Present protocol.

      Comment


      • #23
        Originally posted by ObiWan View Post
        The are still the HD4200 and HD4400 models that are slower, but the Iris Pro 5x00 are faster.
        Not consistent with the Windows reviews that show the 4600 still coming in behind the 7660D across the board.
        http://www.xbitlabs.com/articles/cpu...-4770k_10.html
        http://www.techpowerup.com/reviews/I...ell_GPU/3.html


        Also the AMD A10-6800K has been out for several days now, it's faster still. It is supposed to be paired with at least DDR3 2133 at stock speeds, DDR3 2133 and even DDR3 2400 is very cheap.

        Larabel also didn't state what speed of ram was used in these tests.

        Comment


        • #24
          Originally posted by shmerl View Post
          Is Intel going to put Iris Pro chips in their desktop CPUs? I'm hesitant to buy the Haswell CPUs when their integrated GPUs aren't the best. But if they'll never do it - no point to wait may be.
          Yes! You can find product information like this at ark.intel.com. In particular, the i7-4770R appears to have the Iris Pro 5200.
          Free Software Developer .:. Mesa and Xorg
          Opinions expressed in these forum posts are my own.

          Comment


          • #25
            Originally posted by Newfie View Post
            Shouldn't Haswell be faster than is being demonstrated here? Were the performance improvements exaggerated by Intel or is the driver not quite ready yet?
            The benchmarks seem to be showing ~40% improvement over hd4000 with the hd4600. So, this is a linux issue.
            Still, not bad considering they've only just been released.

            Comment


            • #26
              Originally posted by ickle View Post
              TearFree is still work-in-progress. I need to get it finished in order to improve power management on systems not running a compositor, and the copy-on-write support was a step towards that. That it hurts performance at the moment is known, and will soon be fixed (within reason, it will always be lower performance than not enabling it for obvious reasons).

              Only UXA tears. SNA supports vsync'ed rendering with Haswell on all kernels, and vsync'ed rendering with Sandybridge/Ivybridge since kernel v3.8. However, there are circumstances (such as when the client is too slow) that the driver forces a potentially tearing path in a technique that is known as Adaptive Vsync (in order to not stall the already too slow client). Hopefully, we can get fine control of which presentation methods the driver should use into the DRI3/Present protocol.
              Hi ickle,
              Thanks fot the explanations.

              Does moving a terminal window on the desktop background from right to left is a case where "the client is too slow" for the intel driver could happen ?

              I ask you because I'm certainly going to test again and if you tell me it should not tear I may open a bug report but if this is the expected behaviour I will keep the radeon plugged (and use watts when I don't really need to).

              "SNA supports vsync'ed rendering with Haswell on all kernels, and vsync'ed rendering with Sandybridge/Ivybridge since kernel v3.8."

              Oh, this was the first thing I tested : up-to-date xorg stack, 3.8 kernel, SNA and window manager's vsync disabled. Or do you mean using the "tear free" option, because I tested it 3 weeks ago and it was not usable (I mean it doesn't tear but it's a little like a stop motion movie).

              Comment


              • #27
                Originally posted by rafirafi View Post
                Hi ickle,
                Thanks fot the explanations.

                Does moving a terminal window on the desktop background from right to left is a case where "the client is too slow" for the intel driver could happen ?
                No, likely that is a compositor using MESA_copy_subbuffer which in turn uses DRI2CopyRegion which is not specified to be vsync'ed - a protocol bug. And due to an implementation bug in DRI2 cannot be performed synchronous without severe consequences.

                I ask you because I'm certainly going to test again and if you tell me it should not tear I may open a bug report but if this is the expected behaviour I will keep the radeon plugged (and use watts when I don't really need to).
                Expected behaviour. Though note that this mode of operation of the compositing manager is less power efficient than page flipping - on some hardware, page flipping is a requirement for us to enter low power package states.

                "SNA supports vsync'ed rendering with Haswell on all kernels, and vsync'ed rendering with Sandybridge/Ivybridge since kernel v3.8."

                Oh, this was the first thing I tested : up-to-date xorg stack, 3.8 kernel, SNA and window manager's vsync disabled. Or do you mean using the "tear free" option, because I tested it 3 weeks ago and it was not usable (I mean it doesn't tear but it's a little like a stop motion movie).
                TearFree is proof-of-concept code. When it is ready, it will be documented and included in the release notes.

                Comment


                • #28
                  ickle, since you are here, may you please take a look at this issue? http://trac.videolan.org/vlc/ticket/7405 (example of same issue in driver bugtracker: https://bugs.freedesktop.org/show_bug.cgi?id=47858)
                  According to Intel Media SDK developer Dmitry Serkin issue in driver, not in hardware or video player: http://habrahabr.ru/company/intel/blog/181902/ (Ctrl+F, search for my nickname, use Google Translate). He describe solution in this article http://software.intel.com/ru-ru/blog.../05/07/2001208 (unfortinatly this article in Russian, but I sure you may contact with Dmirty and get details if you going to fix that).

                  Comment


                  • #29
                    Originally posted by brosis View Post
                    Incorrect!
                    1) Linux catalyst often performs faster than windows catalyst. But it does have less features!
                    2) Linux OS is 100%-70% of Linux catalyst. "factor 2 to 3" was a year ago, before Vadim's patches, before ondemand bottleneck discovered, with older mesa library, before driver optimizations from Marek.
                    As for item 1, look here, the geometric mean of windows catalyst is 23% faster than linux catalyst:
                    http://openbenchmarking.org/result/1...ro=y&obr_nor=y

                    And for item 2: linux opensource can be up to 5 times slower than linux catalyst (35% in the median of the chosen tests)
                    http://openbenchmarking.org/result/1...mw=y&obr_imw=y

                    Just adding the two medians, windows is 50% faster than linux opensource. Anyways, I can't believe I put some much time hunting all this info, lol

                    Comment


                    • #30
                      I suspect the Windows-to-Linux comparison is picking up some DX-to-OpenGL differences as well. The games with the biggest differences seem to be the ones which use DX by default on Windows. If you compare with OpenGL renderer on both OSes the delta is usually much smaller, and sometimes goes the other way as others have mentioned.

                      That said, I suspect the difference in GPU clocks (open source driver defaults to low clocks on Trinity IIRC) makes a bigger difference than everything else.

                      Comment

                      Working...
                      X