I've been redirected here from Intel support, the case ID is 8001269420. They said "a graphics agent can pull up all your information and continue helping you with your issue." I'd be really grateful if such an agent would turn up and help, as I'm trying to solve this problem since about 2 months now. I can reproduce all the information regarding the issue here, but would prefer not to do so f it's not needed.
The Intel® HD Graphics 530 can run at a frequency of 1.15 GHz which is the graphics max dynamic frequency, as mentioned this a dynamic frequency meaning that is a parameter that will be reach whenever the system needs it, if you are running any software that needs 1.15 GHz the system will easily reach it, the system will run at any frequency depending on the needs. They only way to reach this frequency is if your BIOS allows you to overclock this frequency without even need it.
thank you for trying to help me. Apparently the case ID didn't help, so I'll list my problem detailed again.
The GPU reaches 1150 MHz momentarily, but the average clock speed is 1100 MHz +/- 5 MHz, depending on the application. The GPU load is 96 - 99%, depending on the application. Performance drops when I manually lower the GPU clock to 1050 MHz, so it's safe to say that it would increase at 1150 MHz. The problem appears in 5 of 5 tested applications:
- Unigine Heaven Benchmark
- Intel Extreme Tuning Utility Benchmark / Stress Test
HWiNFO64 can read the detailed "throttling reasons" given by your turbo mechanism. The only one triggered is "Fuses Limit", but so far nobody could tell me what this means and why it is triggered. I think your answer "frequency depending on needs" aims at a too low GPU usage, which would probably result in "Inefficient Operation" as the throttling reason.
- i7 6700
- MSI Z170A PC Mate, current BIOS (A.50)
- GSkill DDR4-3200 @ 3066
- Win 8.1 x64 and Win 10 x64
- Intel GPU driver x.4279 and x.4300
- MSI replicated the issue with a mainboard from a different manufacturer and a i7 6700, so it's not their fault
- MSI found the issue did not appear with an i7 6700K.
- The issue does not depend on other CPU load (varied over wide range)
- The issue does not depend on main memory bandwidth or the applications need of it (the tested apps differ wildly in this aspect)
- No other performance limiting conditions are triggered, as far as I know (temperature, power, current)
- The average GPU clock does not depend on the GPU voltage (I tested with 160 mV below default, resulting in 10 W less power draw at the wall)
- Tried different Win power settings without any effect
Maybe I forgot to list something else.. but to me it's pretty clear that this "Fuses Limit" throttling reason is the key. And if you haven't guessed by my choice of apps: my CPU runs 24/7 number crunching, so I do care about performance for a good reason.
That's a screenshot of 2 minutes of regular use. You can see the moderate CPU load, temperatures and power consumption and average GPU speed of 1100 MHz. In this case 1150 MHz was not reached, but I know it sometimes happens. In the section "performance limit reasons" the CPU (IA) remains at "Max Turbo Limit", which is OK at 3.7 GHz on all cores. The ring runs at full core speed and shows no throttling reasons.
Everything in the "GT" section refers to the GPU. It's min and max value are "Yes" for "Fuses Limit", i.e. this performance limit is constantly applied. It would switch to "No" if I would interrupt the computations. All other possible performance limits are "No" in the min and max columns. Apart from that I can't tell you anything about this "Fuses Limit", as even Google finds nothing but my own text. I'm sure it's something that HWiNFO64 reads from your driver. I could contact the author, but I expect your own engineers know this best.
I have searched on the processor and graphics documentation and I just cannot find Fuses Limit feature. This seems to be part of the HWiNFO64 utility program. I would recommend contacting http://www.hwinfo.com/forum/ http://www.hwinfo.com/forum/ for more details.
Now, I investigated about the frequency of your processor and the behavior you're having is completely expected. In fact adding more power when is not needed won't increase performance of the processor.
Right. Outside from Intel we can only guess what this means.
"GT_PERF_LIMIT_REASONS" seems to be some state or variable which describes which factor is limiting the performance (=clock speed) of the GPU (GT).
"": in HWiNF64 there are 13 entries in the section "Performance Limit reasons", and "Fuses Limit" is the last one.
If the GPU load was too low, so that a higher clock speed would not increase performance, the 12th entry GT: "Inefficient Operation" would probably be triggered. But it's not at 96 - 99% GPU load.
Searching in Google for "IBP Intel" reveals as the 2nd hit:
The Intel® Business Link (IBP) is an external portal that provides Intel customers with customized access to confidential Intel information and applications.
So please check document number 559338 over there. I would do it myself, if I could... but I don't have that access.
From support level that information is not available, it seems to be confidential documentation you might consult with the https://embedded.communities.intel.com/ Forum: Embedded Community | Embedded Community, once there you will have to register as an Intel Embedded Developer and then apply for extras with privileged access to the Intel® EDC.
thank you for trying to help me, but I don't think I as a paying customer should have to go this far to get support. I don't want to know any of this confidential information and neither am I an Intel Embedded Developer. I just want to know how I can use my shiny new 330€ CPU at the speed it is advertised at.
And keep in mind that MSI was able to replicate the issue with another CPU in another mainboard from another manufacturer. This tells me this may be a wide spread issue. It could be intentional (due to what ever strange reason) or it could be a serious bug. In the latter case I'd help you by pointing it out. And if you don't fix it or at least understand what your own product is doing, you will very likely get many more similar service requests once Skylake ships in appreciable quantities. If I were you I'd want to avoid that!
This case was reviewed by one of our graphics engineers and as I mentioned before based on the the numbers you provided the chipset is performing as expected. You mentioned that MSI tested the processor on a different board and now you are reporting this problem, I do not think this issue is widespread, it seems to me an isolated case.
So you are saying that it's expected that the GPU runs at full load but reduced frequency in 4 of 4 test cases, irregardless of power, temperature and main memory bandwidth and need for bandwidth? Then why is it advertised as 1150 MHz?
Well, you say the chip does not clock up because it wouldn't improve performance. Do you have anything to back that claim up, except "as far as I know it should be this way"? Is there anything I can do to check this? I've got the counter argument that the performance changes measurably going from 1050 to 1100 MHz. For now, whatever I do, I can not make the chip run at its advertised clock speed for more than extremely brief moments.
And you say it's an isolated issue, but as far as I know 2 of 2 tests showed this symptom.
And sorry for the harsh tone. I'm a scientist and to me the data obviously screams "something seems to be wrong, you have to check". And to have the manufacturer claim that a supposedly underperforming product is perfectly normal is.. frustrating. Especially without any means to verify that rather bold claim.
Hi Herr S,
I'll start by saying that what you observed is normal behavior for a non-overclocked CPU, If you overclock, this FUSES limitation will disappear.
The limit is saying that the frequency is limited by the fused (default) frequency of the GT cores.
In the Skylake processor, the graphics is split into a fixed function part (called unslice) and the GT cores which are called a 'slice' (can be more than one slice in some models). A slice is a group of cores.
These 2 parts have different maximum frequencies.
As an owner of an i7-6700K, you can overclock both to 1150MHz or even 1300mHz and this warning will disappear.
Also notice that a similar warning is visible in the IA (Max Turbo Limit). It's basically the same warning but relevant for the core. The cores are running at the fused/default 4-core IA frequency. Overclocking the 4-core frequency will remove this warning too.
Note that Intel does NOT guarantee running at maximum/turbo frequencies all the time. Never did and never will. Turbo frequencies are opportunistic. The guaranteed frequency is often called the base frequency.
thank you for your answer. It's the best explanation attempt so far. However, I'm not quite convinced:
- Are you sure the unslice and slice have different maximum frequencies? I've read a lot about Skylake, yet noone mentioned this. It's neither listed in Intels official specs (although these do not even list the turbo frequencies vs. number of loaded cores..) nor in any diagnosis tool that I know.
- Can you set the frequencies of slice and unslice seperately? How, In your BIOS?
Unfortunately I can't test "If you overclock, this FUSES limitation will disappear" but will have to trust you on that. It sounds like you actually tested this.. did you?
If what you're saying is true, the i7 6700 has 1150 MHz for the unslice and 1100 MHz for slice, right? And I only see 1150 momentarily because that requires situations with a GPU load but no load on the shaders / slice. I tried to check by comparing the maximum GFlops Intel states for that GPU. I find 442 GFLOPS, which would equal 1.15 GHz on the shaders / slice:
1.15 = 442/(24 EUs * 16 instructions per cycle via MAD)
Unfortunately I can't find any official spec from Intel regarding the performance of that GPU. The number I'm quoting is from reviews around the web and may well be calculated from the expected 1.15 GHz clock speed.
"Note that Intel does NOT guarantee running at maximum/turbo frequencies all the time. Never did and never will. Turbo frequencies are opportunistic. The guaranteed frequency is often called the base frequency."
Yeah, I know that. But not reaching the supposed full frequency even at 96+% load, 50°C chip temperature and 1/2 the power limit? With 17 W GPU and similarly 10 W GPU power? Those numbers are very far off the usual turbo limits. Reaching the maximum multiplier is so far the only sound explanation, despite a bug. And if it's actually a different maximum multiplier, it's been communicated extremely poorly (well, not at all). So far I have talked to at least 3 support people, and none of them had a clue of this.
Eric, you're right. I found http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/desktop-6th-gen-core-family-d... this document (note: it would be nice if Intel would link to such documents on the http://ark.intel.com/de/products/88196/Intel-Core-i7-6700-Processor-8M-Cache-up-to-4_00-GHz CPU information page!) with more detailed specs. On page 35, table 2-13 it says that if only the unslice is being used, "GT Max Dynamic frequency" can be reached. However, if the slice is active the maximum allowed frequency is "[GT Unslice only] - (1or2)BIN", i.e. 50 or 100 MHz lower.
So it seems like I *should* be grateful that the CPU is only slowing down by 1 bi instead of 2. However, I actually feel cheated because the slice is needed for any GP-GPU calculation and hence the GPU realistically never reaches its full advertised frequency. I've got a hard time to think about workloads where the slice wouldn't be needed. Maybe Quick Sync? It's a bit like saying "this car performs really well as long as no driver is sitting in it"
@Amy: I'm convinced now that this is extremely wide spread (in fact it applies to every non-K CPU) . And that it's not a bug but rather the intended operation mode. I also think that's quite stupid (*)... but am sure Intel doesn't care. And finally I'm upset Intel doesn't communicate this (not even to you as support!) openly so I'm left with a slower GPU than I thought I'd get. But I consider this case closed, finally.
(*) Because I've got plenty of power headroom and the slice can actually take higher frequencies than the unslice.