Nicolas Capens (nicolas.capens@gmail.com) on 2/17/11 wrote:
---------------------------
>Hi David,
>
>David Kanter (dkanter@realworldtech.com) on 2/15/11 wrote:
>---------------------------
>>You don't understand anything I write, so I'm done discussing this with you.
>
>What exactly didn't I understand? That a high-end discrete GPU with almost three
>times more transistors having nearly an order of magnitude higher bandwidth over
>a CPU+IGP, really is relevant to the viability of having a >homogenous CPU take over the role of said IGP?

No, you don't understand circuit design or any of the fundamental trade-offs that come into play when designing hardware (let alone the economics of selling such hardware).

Not only that, but you consistently refuse to face reality and consider HARD metrics and data that is contrary to your beliefs.

>Don't be ridiculous. You're done discussing because you >ran out of arguments. You
>failed to look at the bigger picture and take the (triple) >convergence into account,
>and you failed to take the benefits of unification into >account (*).

You're certainly welcome to your near religious beliefs.

>And that's forgivable. The current gap between the CPU and IGP can easily lead
>one to disregard progress and believe CPUs can never adequately handle graphics.
>But I expected you would at least have the decency to admit I might have a few valid
>points about how that current situation will change in >favor of software rendering,
>instead of saying I don't understand anything you write.

I told you exactly when that would happen. When the % of CPU cycles required to do mainstream rendering* is <5% of the CPU cycles. That's what it took for us to get rid of sound hardware.

>That would be pretty terrible in and by itself. You're an >analyst so you're supposed
>to explain things in a way people can easily understand >it. So either you failed
>to make an engineer understand "anything" you wrote, or >some of the things you wrote are false or irrelevant.

Unfortunately, when you are faced with someone who:
1. Doesn't understand key relevant concepts
2. Refuses to learn
3. Cannot agree on basic and widely accepted metrics for comparing different approaches
4. Constantly pushes for hypothetical scenarios with no data or evidence

There's really not a lot to be done. I can't debate someone over beliefs that take on the nature of religious fervor and blind faith.

>So I kindly suggest you do take another look at my previous response, and either
>show how I misunderstood that big differences at the hardware level equally affect
>software rendering efficiency of future CPUs, or start putting some doubt into your
>premature conclusions. I believe we settled on using Crysis as a benchmark for effective
>throughput, so don't give me theoretical data unless you also prove that it's significantly
>relevant to the viability of a homogenous CPU doing >graphics.

I already explained, at length, repeatedly. Others have explained as well.

For instance, we all asked how many gate delays, power and area would the hypothetical gather/scatter cost to implement. How would it impact single threaded code (e.g. SPECint). I have yet to hear anything.

Moreover, you make utterly unsubstantiated (and simply wrong) claims about the applicability of gather/scatter to ordinary code and claims about performance implications for SW rendering WITHOUT any substantiation. How do you know that single cycle scatter/gather is achievable? You don't even know the number of gate delays required.

Trying to even examine this notion in detail was not possible and met with obfuscation on your part.

>Note that you'll have to look further ahead than you're used to. Instead of merely
>analyzing next generation hardware,

I look out much further than that.

>you'll have to look at long-lasting trends like
>compute density convergence, unification of programmable logic, and increasing application
>complexity. So far you've done none of that. I've proven that both the bandwidth
>and theoretical throughput of future CPUs suffices to make >the IGP redundant. It's
>your turn to prove that despite that it's never going to >work.

I never said it would never work. In fact, I clearly told you the necessary (but not sufficient) conditions. It's possible that within 10-15 years it might be reasonable, it's not likely within 5.

Moreover, the data you provided was simply WRONG and BAD and DISCREDITED by the author of the simulator you used. Merely presenting spurious data isn't helpful to the conversation.

>I could settle on agreeing to disagree, and just looking >at what the future brings,
>but I won't accept that you imply I don't understand >anything tout court.

Then demonstrate otherwise.

>(*) P.S.: Just in case you still don't see it, the benefit >of unification is that
>a homogenous CPU does not need to have the same compute >density as the IGP, to exceed
>its effective performance. You basically get area for >free, which would have otherwise
>remained largely idle (and you can trade it for power).

How do you know it would have remained idle? I agree it would be nice to have a unified architecture, but I think the reality is that processing in general is going to trend towards two distinct resources: latency optimized and throughput optimized, driven by the fundamental power and area efficiencies for separating the two.

Scatter/gather is necessary for large scale throughput processing (e.g. 16-wide vectors) and certainly beneficial for what I'd call a "GPU". However, it is largely anti-antithetical to the design principles of a CPU. If you look at how CPUs are designed, one of the most critical metrics is the absolute time of the three most common dependent operation pairs:

1. int-int
2. load-load
3. load-int
4. int-load (if your addressing is not sufficiently robust)

Everyone who designs CPUs for AMD, IBM, Intel, etc. is very open about the premier importance of this loop in hardware, yet you are openly dismissive. What other conclusion can I arrive at?

The problem with scatter/gather is that the hardware is large, slow and power hungry. Putting it in your critical path for a CPU is a bad idea. So to recap:

1. I am skeptical that mainstream graphics is likely to be <5% of cycles in the near future on a SW renderer. Your data is not even remotely convincing.

2. I am skeptical that the power and area efficiency of throughput and latency processors will narrow to the point where it only makes sense to have one (over the next 5 years). It is much more logical to first tightly integrate them (which has only just started to happen with SNB, and that's not a great representative of throughput processors).

2a. I also don't believe you understand the quantitative differences between throughput and latency processors (or the power and area implications thereof).

2b. We haven't even begun to discuss the outer layers of the memory hierarchy yet on latency vs. throughput.

3. I am skeptical that scatter/gather can be implemented in a CPU pipeline without causing significant problems.

4. The distinction between latency and throughput is far greater than scatter/gather alone, although that is one aspect.

The list goes on, but I have finite time.

David