Announcement

Collapse
No announcement yet.

Intel Iris Pro Linux Performance Doubles With Driver Upgrades

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

  • Andereas
    replied
    Hi,
    I read here, the blue sky, a large number of similar machines throttling the CPU and GPU. System76 Galago throttle too pulled out? If so, you may also include a pull out the insert VS GPU benchmark performance tests, the laptop do?http://www.comebuy.com/tablet-pc-c-499

    Leave a comment:


  • Tyler_K
    replied
    Source: http://www.phoronix.com/scan.php?pag...ics_ddr3&num=4
    these results show that for even low-end Intel "Haswell" HD Graphics 4400 there is a great deal of performance that can be gained from going with DDR3-1600MHz (or higher) memory.
    Indeed! And just imagine what should happen when you add in a bit of eDRAM for an even more powerful adapter like, oh, I don't know, maybe an Iris pro

    Leave a comment:


  • Tyler_K
    replied
    Originally posted by curaga View Post
    Well clearly the edram is not properly used. Intel folks, is it supposed to be working?
    Michael's article (pushed today) which summarizes his experience with the Galago Ultrapro laptop reminded me of something.

    Specifically, I was initially thinking about the 4600 vs iris pro 5200 results in light of the fact that:
    • they were done using a 3.11 kernel on Ubuntu
    • kernel 3.12 is supposed to enable the eDRAM on the iris pro 5200
    • the recent kerfuffle about 3.12 benchmark results (initially w.r.t. for radeon) which exposed (at least, to me) that Ubuntu is currently not using the p-state driver for those intel CPUs for which it supports ... the consequence of that being that (under Ubuntu) the Haswell, IVB and SNB parts would be using the acpi_cpufreq ... and because Phoronix tests OOTB, the cpufreq ondemand governor was being utilized as opposed to the performance gov. ... the cpufreq ondemand governor change in the 3.12 kernel, as various Phoronix testing showed, evidently alleviates the previous restraining impact it (the ondemand gov behaviour) was having on gpu benchmark performance in some cases (notably for systems with gpu headroom but whom were being artificially cpu bound)

    In the APUs not afftected thread, I drew attention to the fact that even a relatively gpu bound adapter showed some benefit from the change. I further speculated that higher end iGPUs, such as the Intel iris pro, might also see better results on kernel 3.12 (when testing under Ubuntu). One would expect that the 5200's case for that would only be strengthened by the enabling of the eDRAM in the 3.12 kernel. And if you follow all that, it means that there might be an even greater disparity between the 4600 & iris pro results then what was originally reported back in that article linked above.

    However, looking back even further, to the parent article for this thread, I see that:
    • its benchmarks were also carried out using Ubuntu ... meaning (in the case of Phoronix) no p-state, but acpi_cpufreq with ondemand
    • a 3.12 kernel was used ... meaning that:
      - the ondemand gov would no longer negatively impact testing and
      - the eDRAM should have been enabled

    And yet ... the benchmark results under 3.12 were actually tending to be a little below those seen under the 3.11 kernel

    So, yes, indeed, what is the story with the eDRAM ?
    Last edited by Tyler_K; 20 October 2013, 07:00 PM.

    Leave a comment:


  • liam
    replied
    Originally posted by guido12 View Post
    Any thoughts on Windows 8's deferred thread execution technique? Does this really improve battery life without causing performance issues? If so, are there any work to do something similar In Linux?

    Thanks!
    Linux either has, or is working on, process deferrment/grouping through a power-aware scheduler. In the meantime we've had deferrable timers since 2.6.21 which lets the scheduler defer certain processes wakeup requests until the next wakeup caused by an event with a non-deferrable timer.
    As far as the cpu is concerned, the last thing we really need is to completely get rid of ticks (we look to be quite close to that with the recent 1hz kernel).
    Last edited by liam; 21 September 2013, 06:30 PM.

    Leave a comment:


  • guido12
    replied
    Originally posted by DavidC View Post
    Really low. Haswell ULT devices confuse users because it doesn't have a separate sleep mode at all. It's described as "S0 wake up times" with "S3 power use".

    The previous lowest power state, C7, goes to less than 1/2 of what it was on Ivy Bridge(2.2W vs 1W) and C10 power state allows for 50mW idle. The difference is actually greater than that because Haswell's figures are with the integrated PCH, while for Ivy Bridge its just the CPU. In web browsing that has Ivy Bridge devices using 7-8W on it while Haswell ones are at 5W. Not only that, iVRM and on package PCH saves significant thickness and area for allowing bigger battery if necessary.
    Any thoughts on Windows 8's deferred thread execution technique? Does this really improve battery life without causing performance issues? If so, are there any work to do something similar In Linux?

    Thanks!

    Leave a comment:


  • DavidC
    replied
    Originally posted by guido12 View Post
    Does this technique of scheduling task/threads together really give better battery life? It makes sense that deferring thread execution and grouping them would allow Haswell chips to go into the new S0ix state more often and longer. Allowing threads to execute on demand would likely prevent Haswell from going into S0ix. I can see issues of possible longer latencies but probably not noticeable for typical notebook use. I guess it depends on how low power this S0ix state is compared to the normal S0 active state.
    Really low. Haswell ULT devices confuse users because it doesn't have a separate sleep mode at all. It's described as "S0 wake up times" with "S3 power use".

    The previous lowest power state, C7, goes to less than 1/2 of what it was on Ivy Bridge(2.2W vs 1W) and C10 power state allows for 50mW idle. The difference is actually greater than that because Haswell's figures are with the integrated PCH, while for Ivy Bridge its just the CPU. In web browsing that has Ivy Bridge devices using 7-8W on it while Haswell ones are at 5W. Not only that, iVRM and on package PCH saves significant thickness and area for allowing bigger battery if necessary.
    Last edited by DavidC; 20 September 2013, 10:32 PM.

    Leave a comment:


  • guido12
    replied
    Originally posted by WorBlux View Post
    Linux has had this for a while, called NO_HZ in the config file, and often called dynticks or dynamic ticks. I believe some further enablement code was added to take advantage of the additional c-states available in haswell as well.
    That's not exactly the same. In addition to reducing the frequency of ticks (not just during idle), Windows 8 groups tasks so there are longer idle periods for the entire system which lets the CPU enter the new S0ix state more often. There are also tight requirements for the hardware itself. It's talked about here: http://www.anandtech.com/show/6355/i...architecture/3

    Does this technique of scheduling task/threads together really give better battery life? It makes sense that deferring thread execution and grouping them would allow Haswell chips to go into the new S0ix state more often and longer. Allowing threads to execute on demand would likely prevent Haswell from going into S0ix. I can see issues of possible longer latencies but probably not noticeable for typical notebook use. I guess it depends on how low power this S0ix state is compared to the normal S0 active state.

    Leave a comment:


  • semhustej
    replied
    Originally posted by WorBlux View Post
    The kernel is never going to enable something stupid like that by default. It's more efficient to run on high and then drop into an idle state that that to run longer at a lower frequency before dropping into idle.

    The throttling just protects you from piece of junk applications from running down your battery at full speed. Yes I'm looking at you adobe flash. Assuming all of your programs are well-behaved not throttling give you better battery life.

    Ubuntu doesn't do it by default either. If you feel that you must have it, then you can install the jupiter applet that will manipulate various power features by defined modes based on power supply or user selection.
    From what I understand from the review on notebookcheck, the throttling in this Clevo model is set in BIOS, so kernel cannot do anything about it. I know it would be stupid, but that's why I am asking if Galago throttles too.
    I thought throttling is in place not because of some nasty application and power-saving, but to prevent CPU from overheating.

    Leave a comment:


  • WorBlux
    replied
    Originally posted by guido12 View Post
    I don't play any PC games but I'm interested how the eDRAM performs as an L4 cache for the CPU. At least that's what I've read. I haven't read any tests.

    For the final review please do power consumption tests. The other major improvement of Haswell is the lower power consumption of the mobile chips so it's worth verifying Intel's claims. Also, does anyone know anything about Windows 8's task coalescing in order to have the CPU go into the new very low power active state more often? It's talked about here: http://www.anandtech.com/show/7047/t...4500u-tested/3 . Can the Linux CPU scheduler something similar so Haswell can enter this new lower power state more often?

    I also want to know how bad the keyboard is.
    Linux has had this for a while, called NO_HZ in the config file, and often called dynticks or dynamic ticks. I believe some further enablement code was added to take advantage of the additional c-states available in haswell as well.

    Leave a comment:


  • WorBlux
    replied
    Originally posted by semhustej View Post
    Hi,
    I read here, that a similar clevo machine throttles heavily it's CPU and GPU. Does System76 Galago throttle when unplugged too? If yes, could you also include a benchmark comparing plugged vs unplugged GPU performance when testing the notebook?

    The kernel is never going to enable something stupid like that by default. It's more efficient to run on high and then drop into an idle state that that to run longer at a lower frequency before dropping into idle.

    The throttling just protects you from piece of junk applications from running down your battery at full speed. Yes I'm looking at you adobe flash. Assuming all of your programs are well-behaved not throttling give you better battery life.

    Ubuntu doesn't do it by default either. If you feel that you must have it, then you can install the jupiter applet that will manipulate various power features by defined modes based on power supply or user selection.

    Leave a comment:

Working...
X