Originally posted by guido12
View Post
Announcement
Collapse
No announcement yet.
Intel Iris Pro Linux Performance Doubles With Driver Upgrades
Collapse
X
-
Originally posted by WorBlux View PostThe 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.
I thought throttling is in place not because of some nasty application and power-saving, but to prevent CPU from overheating.
Comment
-
Originally posted by WorBlux View PostLinux 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.
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.
Comment
-
Originally posted by guido12 View PostDoes 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.
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.
Comment
-
Originally posted by DavidC View PostReally 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.
Thanks!
Comment
-
Originally posted by guido12 View PostAny 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!
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.
Comment
-
Originally posted by curaga View PostWell clearly the edram is not properly used. Intel folks, is it supposed to be working?
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.
Comment
-
Source: http://www.phoronix.com/scan.php?pag...ics_ddr3&num=4these 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.
Comment
-
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
Comment
Comment