Announcement

Collapse
No announcement yet.

Intel 2.21.13 Driver Fixes Performance Regressions

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

  • phoronix
    started a topic Intel 2.21.13 Driver Fixes Performance Regressions

    Intel 2.21.13 Driver Fixes Performance Regressions

    Phoronix: Intel 2.21.13 Driver Fixes Performance Regressions

    The xf86-video-intel 2.21.13 driver was released on Sunday by Intel's Chris Wilson. This latest Intel X.Org driver update has some performance regression fixes plus fixes the Intel X.Org driver to build on non-Linux systems...

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

  • mendieta
    replied
    Originally posted by mendieta View Post
    To me, it feels more like an intended downlocking in some code paths that have the MAX_FREQ different from the default one.
    Mondays are hard! I meant to say unintended

    Leave a comment:


  • mendieta
    replied
    Originally posted by ickle View Post
    GPU frequency scaling is a black art - the hardware is mostly a black box to us, we have a number of thresholds to program and then respond to the GPU's request for more or less power. What happens next is more or less up to the power control unit (which is getting more intelligent over time) and monitors thermals and power levels over the chip - and will throttle if need be.

    We know that mesa often struggles to keep the GPU busy enough to warrant upclocking, but given your symptoms that doesn't seem to be the case. Rather I think it will be related to throttling, even possibly diverting power from the CPUs and wasting it on the GPU.

    If we can figure out exactly what is going on, we expect to have some easy performance wins in the future. (I wish!)
    Oh, thanks. It doesn't have the feel of throttling, but I'm not positive. I'll try a modest 50mhx OC. I'll also try setting the MIN_FREQ to be the same as the max for testing. To me, it feels more like an intended downlocking in some code paths that have the MAX_FREQ different from the default one. I wonder if this patch actually made it to mainline kernel 3.10

    https://patchwork.kernel.org/patch/2305081/

    Anyways, cheers for all the great work. My i4670k is working great (incredibly fast both for GPU and CPU) with Mesa 9.2git and kernel 3.10.3!

    Leave a comment:


  • ickle
    replied
    Originally posted by mendieta View Post
    Ickle, in case you are still reading. What's the status of GPU overclocking? I can overclock my haswell (with a pretty current software stack) and see gains in glxgears proportional to the gain (1200Mhz ->1350Mhz). However, less trivial tests such as glmark2 actually work much slower (almost half the overall framerate) . Thanks!
    GPU frequency scaling is a black art - the hardware is mostly a black box to us, we have a number of thresholds to program and then respond to the GPU's request for more or less power. What happens next is more or less up to the power control unit (which is getting more intelligent over time) and monitors thermals and power levels over the chip - and will throttle if need be.

    We know that mesa often struggles to keep the GPU busy enough to warrant upclocking, but given your symptoms that doesn't seem to be the case. Rather I think it will be related to throttling, even possibly diverting power from the CPUs and wasting it on the GPU.

    If we can figure out exactly what is going on, we expect to have some easy performance wins in the future. (I wish!)

    Leave a comment:


  • mendieta
    replied
    Originally posted by ickle View Post
    I'm working on it! Option TearFree does it, just not elegantly yet, so still work-in-progress.
    Ickle, in case you are still reading. What's the status of GPU overclocking? I can overclock my haswell (with a pretty current software stack) and see gains in glxgears proportional to the gain (1200Mhz ->1350Mhz). However, less trivial tests such as glmark2 actually work much slower (almost half the overall framerate) . Thanks!

    Leave a comment:


  • ickle
    replied
    Originally posted by curaga View Post
    Come to the dark side and switch to radeon No tearing for something like seven years now. Not using a compositor either (come on Intel, we exist, implement support for that already!).
    I'm working on it! Option TearFree does it, just not elegantly yet, so still work-in-progress.

    Leave a comment:


  • curaga
    replied
    Under X, a compositor is an extra level of indirection. This has been discussed multiple times already, CBA to repeat more.

    Leave a comment:


  • Ericg
    replied
    Originally posted by curaga View Post
    Come to the dark side and switch to radeon No tearing for something like seven years now. Not using a compositor either (come on Intel, we exist, implement support for that already!).
    Why not use a compositor? Just helps to cover up the deficencies of X, don't have to be using 3D effects or anything like that. Also Keith Packard mentioned tearing on SandyBridge+ in his Linux.conf.au talk, said that it would take DRI3(000) to fix it so that may be the tearing he's talking about (compositor SHOULD cover up the tearing, hence ickle's first point about not using a compositor)

    Leave a comment:


  • Bucic
    replied
    Any chance this gets fixed by the release?
    https://bugzilla.redhat.com/show_bug.cgi?id=977391

    Leave a comment:


  • curaga
    replied
    Come to the dark side and switch to radeon No tearing for something like seven years now. Not using a compositor either (come on Intel, we exist, implement support for that already!).

    Leave a comment:

Working...
X