Hi David,

David Kanter (dkanter@realworldtech.com) on 2/25/11 wrote:
---------------------------
>Nicolas Capens (nicolas.capens@gmail.com) on 2/24/11 wrote:
>---------------------------
>>>>You're wrong about that. The IGP consumes considerable power: http://www.legionhardware.com/articles_pages/intel_core_i5_2500k_and_core_i7_2600k_sandy_bridge,14.html
>>>
>>>Hey - I told you before and I'll tell you again. That data does not even remotely
>>>support any point you are trying to make. It in no way isolates the power consumption of the IGP.
>>
>>I couldn't find any post where you told me this before.
>
>Well, I've only mentioned it two times before. But now you know, so you can simply stop pretending.

I'm not pretending. I honestly can't find where you told me this twice before. Could you get me the links? Thanks.

>>But anyway, this data doesn't
>>have to isolate the power consumption of the IGP itself to >"even remotely" support
>>any point I'm trying to make.
>
>You wrote: "The IGP consumes considerable power."
>
>You offered that link as evidence, despite the fact that it lacks any data which remotely supports your claim.

It shows that a system with an i7-2600K consumes 96 Watt when running Crysis, 57 Watt higher than running idle. Given that Crysis is single-threaded, and it is going to be frame-rate limited by the IGP anyway, this does suggest that a significant amount of power is consumed by the IGP. Note that the CPU test shows a 90 Watt delta, which is nearly this CPU's TDP so there's no indication anything else is burning all this power. Also, while 90 Watt is higher than 57 Watt, it wouldn't require a lot of downclocking to lower it to the same level. For reference, mobile Sandy Bridge chips have a TDP of 45 Watt.

>You simply do not have any facts to back up your claim. i.e. you are full of it.

I have the data from that review, while IntelUser2000 claimed the IGP consumes "10W or so at max" based on absolutely no data whatsoever. So don't call me full of it.

>>The fact of the matter is that playing Crysis consumes
>>nearly 100 Watt. So if software rendering can get reasonably close to the same performance
>>within the same power envelope, while offering a cost advantage or generic computing
>>advantage, it's commercially viable.
>
>That has nothing to do with what you said or the point you made.

It was an additional observation to bring this data into the bigger picture, the only thing that ultimately counts. Even when using the built-in probes to get exact readings for the IGP's power consumption, that's not the power consumption for running Crysis. The IGP silicon is completely helpless on its own. It needs the L3 cache and memory controller, and it needs the CPU cores to run the driver. Also, the power plane for the CPU cores includes the L3 cache, so you can't directly compare this to the IGP's power plane either.

>Moreover, SW
>rendering cannot get close in performance or in power.

GPU architectures continue to evolve toward software rendering, while CPUs are catching up in performance/Watt. You have yet to shown any indication of strong divergence which would counteract this and support your claim.

>>So even though some of that is required
>>to implement fixed-function operations, if necessary the >CPU cores can be downclocked
>>to become more power efficient. And as I've explained to Seni (http://www.realworldtech.com/forums/index.cfm?action
>=detail&id=117385&threadid=113145&roomid=2),
>>gather/scatter would offer plenty of texture sampling capability. Also, software
>>rendering should have higher utilization (it doesn't leave any fixed-function hardware
>>idle), which again in theory means a lower clock frequency >could suffice.
>
>You are crazy. Intel's LRB team concluded very quickly that texturing hardware
>is needed for a competitive level of performance. I trust their studies far more
>than any specious arguments you can make.

I'm not crazy. My mother had me tested.

Seriously now, Larrabee's studies are not directly relevant to achieving IGP-level performance on a homogeneous CPU. You get about three times more area to do the job. Gather/scatter largely suffices to get the necessary texture sampling rate.

Larrabee has vectors that are twice as wide and there's only one load unit per core, so its gather implementation takes a higher average of clock cycles to complete. Furthermore, its in-order architecture would block on every cache miss. So dedicated texture samplers make a lot more sense for Larrabee than a Sandy Bridge descendant.

Cheers,

Nicolas