Home  |  News  |  Reviews  | About Search :  HardWare.fr 

MiscellaneousStorageGraphics CardsMotherboardsProcessors
Advertise on BeHardware.com
Review index:
Intel Core i7 and Core i5 LGA 1155 Sandy Bridge
by Damien Triolet, Franck Delattre, Guillaume Louel et Marc Prieur
Published on March 21, 2011

We also tried to see what the impact was of the choices made by Intel in the integration of its GPU. While the memory controller is shared (this was already the case previously), the last level memory cache (LLC, L3 for CPU cores) is also shared via the ring bus.

We tried to observe the respective performances of the Sandy Bridge processor and IGP by running an application that puts heavy demands on the CPU on one side and a game that puts heavy demands on the GPU on the other. We opted for Cinebench + H.A.W.X.

We carried out three tests on each platform by varying the number of threads used by Cinebench. The values correspond to the percentage of threads in comparison to the number of physical cores on the chip. 200%, represents 8 threads on a quad core CPU with HyperThreading like the 2600K. On a dual core processor with HyperThreading (the Core i5 661) it represents 4 threads. We looked at the progression of performances across three platforms:

- Core i7 2600K + Radeon HD 5450
- Core i7 2600K + IGP
- Core i5 661

Hold the mouse over the graph to see perfs as an index.

Lets take a closer look at performance levels in H.A.W.X according to the number of threads. There’s no impact when you use a Radeon HD 5450 (the Windows scheduler correctly prioritises the game, which is in the foreground). On the Core i5 661, there’s a slight dip of 2.5% that can be put down to the shared memory controller. But what about the performances you get with the 2600K’s IGP? Note, for information, that we reproduced this behavior with a second game/application pairing (Far Cry 2 and Prime95).

We found, at least in part, one of the causes for the drop in performance by monitoring the IGP’s running clock. With 8 software threads in Cinebench, using hwinfo32 we noticed that the graphics core was being throttled, its frequency dropping from 1350 MHz to 850 MHz (2D frequency) in a few seconds. Although this explains a loss in performance, it doesn’t explain everything. Several hypotheses are possible and there are probably multiple factors coming into play here. Firstly, it’s logical that, like with the Core i5 661, some of the impact on performance comes from the fact that the memory controller is shared. This impact may even be bigger here because of the fact that the LLC is also shared with any of the problems that may be associated with this (saturated ring bus, snooping and so on). The final point is that we don’t know exactly what level the GPU clock is read at by the monitoring software we used. It’s probable that, depending on the register, it’s impossible to detect any throttling below 850 MHz.

Note also that, instead of being a cause, the throttling that we observed could well have been the consequence of another problem. In effect, the reduced clock could result from insufficient graphics load (upstream limit, at the level of the LLC for example), which wouldn’t force the graphics core to increase its maximum clock.

Independently of the cause, it’s abnormal to see such an impact from processor load on the graphics part, just as it’s abnormal to see such extreme throttling when our energy consumption readings seem to place the Intel processors quite some way off their announced TDPs (see following page). The Power Control Unit is probably playing a part in this situation.

<< Previous page
Intel HD Graphics, energy consumption, oc, perfs

Page index
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23
Next page >>
Intel HD Graphics, Video and Quick Sync  

Copyright © 1997- Hardware.fr SARL. All rights reserved.
Read our privacy guidelines.