OK, nice post, you've carefully dodged all the references I made, failed to comment on any link I posted to real applications and somehow continued to push your "vision" without bringing any further proof of being somehow viable in the future. And on top of that you also avoided to post actual data that would allow us to compare performance/W from your current solution with current GPUs so for me the discussion is settled, you're not bringing anything new on this topic and repeating the same baseless argument over and over will not make things magically happen. So I stand by my point: GPUs will get more programmable, they will sport new features but they're not going away, we'll be getting more of them. But let me correct some *more* factual errors you posted.


Nicolas Capens (nicolas.capens@gmail.com) on 1/15/11 wrote:
---------------------------
>There would be no innovation whatsoever if an argument like this had any validity.
>Just because you haven't seen something yet doesn't mean it won't be viable in the
>future. Back in 2005 people had yet to see a consumer GPU with a unified vertex
>and pixel shader unit. That didn't stop it from becoming the dominant architecture really fast.

The ever-important pixel/vertex shader merge that obscures the fact we're getting GPUs ultra low-power in cellphones. OK, you seem very self-convinced by this argument.

>Sometimes I get the idea that the only impression people like you get when I speak
>the words "software rendering" is a memory of playing Quake at 320x200 at 8 FPS.
>There has been tremendous progress since those days! There is more tremendous progress
>coming! For the record, CPUs are hardware too, so software rendering is a bit of
>a misnomer. And shaders are software too. There are fewer architectural distinctions
>between CPUs and GPUs every generation.

Well, I happened to work on the topic so no, "software rendering" is not Quake in my book and yes GPUs and other hardware accelerators are processors with specialized instruction sets and specialized hardware. I already pointed this out *multiple* times. As such they may "seem" to be getting closer to CPUs but did you ever look at a GPU instruction set? Because if you did you'd know that they are miles away from a general-purpose ISA and there's very valid reasons for that.

>Once again you're stuck in today. Instead try to look at the past and project that
>progress into the future. Back when they were launched, a Core 2 Duo at 2.93GHz
>costed 1000 USD. Nowadays you can get a superior Core i3 at 3.06 GHz for 115 USD,
>consuming only a fraction of the power. And if it didn't include an IGP it would
>have costed even less. In the AMD camp 100 USD will even buy you a quad-core already.
>
>And with all due respect it's kind of lame that you have to use CULV systems as
>an example. It's pretty obvious they'll be the last to switch to software rendering.
>However, their low power consumption hasn't stopped them from using HD Audio codecs
>(despite high CPU usage), while as you pointed out earlier handheld devices have
>dedicated DSPs to lower the power consumption further. It indicates that they're
>just several years behind on the curve, but will surely follow.

CULV systems - like other mobile appliances - are a growing market, not shrinking. And yes, they will surely follow since many larger devices like tablets are getting ARM SoCs they will probably also get dedicated DSPs for hardware audio manipulation and current CULV systems with HDMI outputs already have hardware encoders for digital audio out. Thanks for proving my point once again. BTW there's another reason besides performance why you want to do that stuff in hardware: predictable latencies.

>Look at where it's heading. It's a 5x gap today but four years from now we could
>have gather/scatter and 8-core mainstream CPUs that don't break a sweat at 5 GHz.
>So that's roughly 3x the performance thanks to the full-featured AVX extensions
>and another 3x for the cores and clock frequency. Together with some fine-tuning
>of the software renderer we're looking at about 8000 3DMark06 points, on par with an 8800 GTS!

Let's get this straight: I am the one stuck in the "now" and you compare a non-existing processor to a graphics card that came out over 4 years ago? On a 5 years old benchmark? Yay!

>By then 3DMark06 will be showcased in musea next to dot-matrix printers though.
>The games of 2015 will require fully generically programmable GPUs that don't buckle
>when running long complex shaders. This requires technology found in CPU architectures...
>So you might as well use the actual CPU cores.

I've never bookmarked a post for long-term facts checking but I'm really tempted now.

>You probably meant four cores? Or six if you replace the IGP's die space with CPU cores.

No, because the IGP takes only two cores worth of die area so if you want to make a fair comparison that's what you get. If you want to compare 6 cores why not compare to a GPU the die-size of Sandy Bridge?

>StarCraft II is an interesting case because while it requires 3 cores or more to run optimally, the average CPU usage isnt't that high: http://www.pcper.com/article.php?aid=958.
>> And given that 30 FPS is plenty for a strategy game this leaves even more CPU
>power unused and the game is GPU limited. So to overcome Amdahl's Law you could
>give the CPU some other tasks to work on as well. If you move some of the graphics
>workload from the GPU to the CPU you could have a cheaper GPU and still achieve
>the same performance. If this trend continues, sooner or later you're best off running all graphics on the CPU.

I didn't ask for an analysis of StarCraft II performance profile which I know well enough, you know I can read articles too. I asked for numbers, the fact you failed to post them tells me they don't look good for you.

>The Crysis benchmark runs at 17 FPS on my Core i7 920 @ 3.2 GHz. On a 6-core Sandy
>Bridge it would be running at over 30 FPS. Still without making use of AVX (let alone gather/scatter).

Resolution? Quality settings? Texture-filtering level? Why not the SC2 numbers I asked for? Still trying to dodge my arguments?

>I don't see how VLIW is less complex than SIMD. It needs to route multiple control
>words to each unit, it needs support for horizontal operations, and it requires a shuffle network.

OK, that proves you have no idea what we're talking about. VLIW is a CPU architecture type while SIMD is a type of data-processing parallelism. You can have VLIW processors with SIMD instructions, that's what AMD shader processors are.

>But by keeping the clock frequency lower, AMD can push TSMC's 40 nm process to
>the integration density limit. They can have fewer pipeline stages, route the wires
>closer together with less fear of interference, and use smaller transistor gate
>widths. They also don't need buffers between the clock domains. All this was necessary
>to compensate for the VLIW complexity and lower utilization.

No, it's the other way around. AMD keeps GPU clocks low because they are power constrained. VLIW architectures are inherently simpler than RISCier equivalents - like nVidia SPs - and as such you can obtain higher compute densities and higher maximum throughput at the expense of less flexibility in the scheduling hardware. It's a design trade-off, not a compensation for some made up complexity.

>But on top of that
>they also decided on smaller caches, fewer ROPs and less bandwidth. This causes
>AMD's architectures to frequently become bottlenecked, further lowering utilization.

What does bus-width or number of ROPs have to do with CPU architecture?

> So let's not confuse these two.

Yeah, right.

>At first it might seem they succeeded at making a smaller chip perform the same,
>but it's not without compromises. Fermi is still more feature-rich and won't stall
>as easily. So if you take that into account they've created an equivalent at best.
>There's no such thing as a free lunch.

Did you notice that the latest Fermi incarnations actually removed some of that extra hardware to get better performance and less power? So yes, there's no such thing as a free lunch.

>So to get back to the actual point: NVIDIA proves that you can do with less GFLOPS, if you use them efficiently.

Sure, and having a larger die size and higher power consumption is "being more efficient".

>It does change things for graphics, because graphics becomes ever more irregular.
>NVIDIA's architectures have ever lower computing density (per transistor) but keep
>up with AMD's architectures. Amdahl's Law, a.k.a. the law of diminishing returns, makes AMD's approach less scalable.

AMD's latest GPUs also support multiple kernels in-flight, including from different host applications so I guess it's nVidia's approach which is less scalable right now by your standards.

>Dedicated sound processing came and went.

No, it's still there.

>Dedicated physics processing came and went.

Unfortunately not but that has to do more with nVidia's marketing dollars. I don't know if we'll see more physics done on GPUs using OpenCL/DirectCompute but I'd love too.

>Dedicated RAID controllers are also no longer a must and hybrid RAID and sofware RAID is taking its place...

Sure, I'm gonna tell that to our IT guys. Get rid of those expensive RAID cards in our servers, Nicolas Capens told me they're worthless, we just wasted money on them.

>Dedicated graphics has a much longer cycle because it's more complex and requires
>more performance for adequate support, but the end is getting nearer. Every stage
>of the graphics pipeline is becoming programmable. Programmability is the enemy of dedicated.

Oh really? Then why did Intel introduce instructions for AES encryption lately? Wouldn't it have been better to just do it using plain integer instructions? Why put an entire hardware block on the die just for a single purpose?

>There's actually a physical reason why everything that is programmable, eventually
>moves to the CPU. Every time the semiconductor feature size halves, you can have
>twice the number of wires, but up to four times the transistor density.

You may be a little bit off current trends in semiconductors. Just a little bit mind you.

> What this
>means is that eventually everything becomes bandwidth limited. On-die memory (registers
>and caches) delay the issue but it's starting to matter less and less what's doing
>the actual processing. This makes a single processor which is capable of all tasks,
>a lot more interesting than a heterogenous design which can't balance the workload.

Not a word about power efficiency which actually happens to be the biggest problem in current hardware trends, go figure...

>The average GPU in a typical desktop sytem isn't capable
>of running anything additional to the graphics workload, while achieving better
>performance than when making use of the CPU's idle cores instead.

But you're stuck in the now, it's the future that's relevant when typical desktop GPUs will also be able capable of running those additional workloads.

>And I've already given you examples of dedicated hardware which became irrelevant
>because the CPU became powerful enough to take over their role.

And was wrong about that.

>Register files are less dense than caches. But anyway, the real problem for GPUs is the number of threads (strands).
>
>Why does Fermi still not support recursion?

Fermi does support recursion:

http://developer.nvidia.com/object/cuda_3_1_downloads.html

"Support for function pointers and recursion make it easier to port many existing algorithms to Fermi GPUs"

Besides recursive algorithms can always be turned into iterative algorithms using an explicit stack, everybody knows that.

>Because it requires many kilobytes
>of stack space, per thread. On the CPU, 1 MB of stack space per thread is typical.
>Even in the worst case, that's still likely to fit in L3 cache. Even without recursion
>the call stack can get pretty deep for complex code. With thousands of threads in
>flight, a GPU just can't have the on-die storage (regardless of whether it's registers or slightly denser caches).

No GPU actually has thousands of threads in flight. That's a misnomer used for hardware SIMD lanes. The actual threads are much less than that.

>NVIDIA's GPU designers have added superscalar execution. This complicates the scheduler
>and actually creates the risk that they can't find two independent operations in
>the shader. So clearly some benefit outweighed these disadvantages...

Fermi (GF100) didn't have a superscalar scheduler nor does the GF110 have one, it's smaller incarnation (GF104) does. And that's a trade-off: less flexibility, higher compute density. The same trade-off AMD made when using VLIW.

>This is GPU designers telling me that threads need to be processed faster in order
>to avoid running out of register space.

Fermi has less registers per shader processor than its predecessor, what does this tell you?

>That said, why would it matter who's saying something, for it to make sense? I
>don't want GPUs to not support recursion. It's just a technical fact.

And a wrong one.

>If they did support it, I wouldn't be having this discussion and I would write software for
>the GPU.

Good, time to get started.

>And for your information, I have a masters degree in computer science and
>engineering, with a minor in embedded systems.

And cannot check your facts before posting.

>What other direction? The latest GPUs now have the ability to gather any of the
>four components of a 2x2 footprint and query the texture LOD, from within the shader!

Yeah, and it's implemented in the texture unit.

>They're also performing part of the addressing in the shader units. So it's already
>really close to being fully programmable.

For AMD GPUs it has always been that way. We already beat this particular topic to death before.

>The fact of the matter is that there's a massive number of shader units and they're
>frequently underutilized.

Because it's faster per area unit and more power-efficient per performance unit.