Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 51

Thread: Intel Haswell HD Graphics 4600 Performance On Ubuntu Linux

  1. #21
    Join Date
    Sep 2010
    Posts
    76

    Default 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 ?

  2. #22

    Default

    Quote 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.

  3. #23

    Default

    Quote 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.

  4. #24
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    137

    Default

    Quote 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.

  5. #25
    Join Date
    Jan 2009
    Posts
    1,479

    Default

    Quote 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.

  6. #26
    Join Date
    Sep 2010
    Posts
    76

    Default

    Quote 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).

  7. #27

    Default

    Quote 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.

  8. #28

    Default

    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).

  9. #29
    Join Date
    Apr 2009
    Posts
    565

    Default

    Quote 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

  10. #30
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,541

    Default

    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.

Posting Permissions

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