Gabriele Svelto (gabriele.svelto@gmail.com) on 1/11/11 wrote:
---------------------------
>Nicolas Capens (nicolas.capens@gmail.com) on 1/5/11 wrote:
>---------------------------
>>Do you happen to have any sources which explain just how complex it is? I'm sure
>>it's not trivial, but given that LRBni already has many other features which I'd
>>consider relatively complex, I'd be surprised if gather/scatter took a disproportionately
>>large area. Intel was able to fit 32 of these feature rich cores with 512-bit vectors
>>onto a chip roughly double the transistor count of Sandy Bridge...
>
>Unfortunately Intel didn't disclose details on LRB die AFAIK so we don't know what
>was the weight of every single feature. Yet the fact that LRBni doesn't include
>a full-vector permute tells you that doing a crossbar of that size is prohibitive.

Somehow it does have full-vector gather/scatter support, so it's not prohibitive if it's valuable enough to add. Expensive, definitely, but not prohibitive. And as I pointed out earlier, with two 128-bit load units you'd only need two 128-bit permute crossbars so it should be very feasible.

>>What I meant is that the two 128-bit load units could each have their own 4x32-bit
>>crossbar. It means they sometimes load the same cache line, but that's ok. I assume
>>that's what already happens anyway with vmovaps, and it considerably simplifies
>>the crossbar. So while Larrabee requires one massive 16x32 crossbar an architecture
>>based on Sandy Bridge would have a near optimal gather/scatter implementation with two simpler 4x32 crossbars.
>
>Yeah, that sounds feasible to me.

See? ;-)

>>At the same or higher image quality level. On a Core i7 965 SwiftShader scores
>>620 3DMark06 points. That's more than a GMA X3100.
>
>It is nice to hear that 3DMark06 can be run in software but an i7 965 is a pretty
>high end processor and beating a an old and lowly GMA X3100 doesn't tell me much.
>At 1280x1024 decent IGPs are already scoring in the thousands and will have vastly
>better performance/W, performance/$ and performance/area than an i7 965 doing software rendering.

For the record, I have an i7 920 clocked at 965 speeds. As you certainly know, CPUs get ridiculously more expensive for a small increase in performance. But it also works the other way around! You don't have to lose a lot of performance when you opt for a cheaper CPU. Plus, any system needs a CPU anyway, so you got to take that into account when comparing CPUs against GPUs. The latter still needs a CPU or it's worthless...

This weekend I had the opportunity to run SwiftShader on an i7 2600. It scored 820 3DMark06 points at stock speed. So that's 32% faster than my overclocked 920! What's more, the 2600 is considered a mainstream CPU and it's price is expected to drop fast once AMD launches Bulldozer. And it comes with a ridiculously small heatsink. Note that the GMA X4500, still sold in massive numbers, only scores about 950 3DMark06 points.

So while I won't deny there's still a gap in performance and power consumption, it's getting smaller every generation!

But that's not all. Sandy Bridge wastes die space on a GPU. It could have had two extra cores instead, exceeding the X4500's performance. Furthermore, SwiftShader doesn't take advantage of AVX yet. And with gather/scatter support lots of graphics operations would become a whole lote more efficient.

So it's already well within reach to have a GPU-less system and still have ample 3D graphics performance for the same market that APUs target. Last but not least, with extra generic CPU cores developers can create other diverse and demanding applications.

>> (...)
>You could also say that AMD managed to create an architecture which matches NVIDIA's
>with vastly lower die area and transistor count. The differences between their hardware
>boil down to the fact that AMD is using VLIW shader processors which by design will
>have lower achievable throughput but being simpler much higher compute density.

Actually I believe AMD's GPUs have a higher transistor count, on a smaller die. This is probably due to NVIDIA's architecture using a higher clocked shader domain, requiring faster and thus larger transistors. Furthermore, depending on the exact chips you're comparing, NVIDIA has higher double-precision performance. Together with the new Fermi capabilities this means NVIDIA is way ahead of AMD in the HPC market. It's obvious this comes at a bit of an extra die size cost.

But clearly that difference is insignificant in comparison to what I pointed out: It achieves the same actual performance with half the GFLOPS! The importance of this is that efficiency is critical, even for graphics, which was previously regarded as "ridiculously parallel". And since there are lots of GPGPU applications which don't even achieve 10% of the theoretical performance of the GPU, while they use the CPU to it's fullest, it's clear that CPUs are really efficient at juggling tasks around and keeping the data flowing.

So how AMD and NVIDIA compare today is pretty irrelevant to the discussion. What matters in the long term is that applications, including graphics applications, are getting more complex and a CPU architecture is more suited for this.

Note that software rendering frees game engine developers from the graphics API restrictions, which in turn results in higher performance in practice: http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf

>>GPUs need ever larger caches, reduced branch granularities, ALUs with more generic
>>operations, support for call stacks, etc. Mark my words, one day they'll need speculative
>>execution just to prevent the register file from growing out of proportion.
>
>Speculative execution will not cause the register files to shrink, it will cause
>them to grow. The larger the instruction window the more physical registers you
>need to store results of not yet retired instructions.

Retirement buffers are pretty small. But instead of speculative execution, GPUs opt for massive simultaneous multi-threading, which means they need register space for all these extra threads. Shaders which use more registers than what the hardware was designed for, can really decimate performance. Developers also want a true call stack, so you need massive caches to store all this context.

This situation is not sustainable. Some really drastic measures need to be taken to reduce the thread count. But you don't need to look any further than CPU architectures. Speculative execution, branch prediction, forwarding, register renaming, etc. can come to the rescue. But when GPUs sacrifice computing density for higher efficiency at complex generic tasks, it's obviously also a really interesting option to just start with a multi-core CPU architecture and give it powerful graphics capabilities by adding gather/scatter.

>>Likely
>>before that we'll also have programmable texture filtering, which means the texture
>>units become more like generic gather/scatter units and the actual filtering is
>>done at full FP32 precision in the shader cores (AMD already does the texel address
>>calculations in the shader).
>
>Texture address calculation has always done partly in the shader core and partly
>in the TU since R6xx IIRC, and technically speaking you could consider the TU a
>coprocessor of the shader processor being completely tied to it. Add to this that
>both nVidia and AMD continuously improved the filtering speed of their TU as well
>as adding specialized functionality (like Gather4) to accelerate in hardware common
>parts of custom filters. Besides TUs also implement on-the-fly decompression of
>compressed textures, not just addressing and they often have specialized caches
>(very granular, often with fully associative addressing). That is not something
>you can easily merge with a more generic architecture. Doing so would certainly
>yield lower throughput, and higher power at the same performance level.

While texture sampling is a highly specialized operation (it's the only thing Larrabee really has dedicated hardware for), the general trend is still to generalize them into load/store (gather/scatter) operations. There are several reasons for this:

Shaders need ever fewer texture samples (TEX:ALU ratio). So the amount of die area use on texture samplers has steadily decreased. But this means that TEX heavy shaders become bottlenecked, and for ALU heavy shaders they are underutilized...

But while the TEX:ALU ratio decreases, the shaders do make more unfiltered memory accesses. So modern GPUs also have specialized access to local memory, shared memory, global memory, etc. Each of these can again be a bottleneck!

Also, filtering is useless for GPGPU, while graphics on the other hand wants full FP32 filtering (possibly even FP64). These diverging needs are hard to combine into texture units or other highly specialized load/store units.

So it becomes very tempting to just slap all these different forms of memory access together, have generic load/store units, and let the cache hierarchy take care of local and temporal coherence.

If only CPUs had gather/scatter support, SwiftShader would have no real bottlenecks, no matter what you throw at it. The CPU might not be the be the most efficient piece of hardware for any particular task, but the fact that in practice GPUs are always bottlenecked by something means you can still get high average efficiency.

As for compressed textures, they're not as critical as they may seem. Due to licensing issues, popular S3TC based formats are still not part of core OpenGL. Loads of applications don't bother using them. And low-end and mid-end hardware have higher bandwith:computing ratios so it's not that helpful. Ironically people with high-end hardware tend not to like the quality loss of texture compression so they sometimes disable it. The general trent is toward higher quality. Where compression does help significantly is to fit everything in VRAM. But for software rendering that's far less of an issue since you typically have about four times more system RAM. Note also that an i7 2600 has lower memory bandwidth than an i7 920 yet it's significantly faster so software rendering isn't bandwidth limited.

>>The only reason we haven't seen a sign of Larrabee as a GPU yet, is because it's
>>too soon, and because it approaches the market from the wrong end. It's too soon
>>because despite the enormous opportunities a generic architecture like that offers,
>>developers aren't just going to invest in developing applications for it if it has
>>too little market share. And it has too little market share because Intel tried
>>to sell it as a high-end GPU. It's an architecture with huge potential but it's
>>facing a massive chicken-and-egg problem. We first need the rest of the GPU landscape
>>to evolve in the same direction before developers will take the plunge. There's
>>simply no strong software ecosystem yet for things that go beyond the classic graphics
>>APIs. OpenCL and such are cautious first steps but it will take many more years
>>before you can write code in the language of your liking and have it run on either
>>a CPU or a GPU. It takes more steps toward full convergence for this to become a reality.
>
>I agree with this POV but I don't think that software rendering will ever be viable,
>even in the low end, but more on this later.
>
>>Software rendering for the low-end market on the other hand is viable today. There's
>>bound to be people who rather have a more powerful CPU instead of an on-die GPU.
>>And these powerful CPUs are attractive to developers because they can safely extend
>>the existing software ecosystem without big risky investments. This software further
>>increases the demand for powerful CPUs, and these will be capable of more than just low-end graphics...
>
>I don't think so. Basing ourselves on your 3DMark06 number means that most of the
>casual games available lately on services like Steam wouldn't be able to run at
>playable frame-rates even at the lowest setting and resolutions. And that would
>be on high-end, quad cores, what would this mean for people with CULV laptops?

Why not try it instead of "basing" yourself on the 3DMark06 score? I have yet to find a game in Steam's casual section which doesn't run fine with SwiftShader on a quad-core CPU. Some even run smoothly with anti-aliasing. 3DMark06 is a synthetic stress test designed to benchmark the hardware at the time of release, and still offer a challenge to future graphics solutions. Even today's casual games are nowhere near as complex as 3DMark06. And that's not likely to change fast. Causal games are designed to run on the lowest common denominator, which includes older IGP's like the X3100.

For your information, SwiftShader will be used in future versions of Flash to enable 3D casual games on the web, when you don't have adequate graphics hardware: http://blogs.adobe.com/flashplatform/2011/01/digging-more-into-the-molehill-apis.html

But that's one outer end of the application area. You appear to be stuck thinking about what's possible with today's systems. Sandy Bridge's performance per Watt is already double that of the previous generation: http://www.pcper.com/article.php?aid=1057&type=expert&pid=12. Now imagine that in two more generations we will have four times higher performance per watt, and gather/scatter support, and tell me again it will never be viable to have GPU-less systems even for the low-end market.

Even if it doesn't happen in four years, it's still bound to happen one day. Every single parameter is evolving in favor of software rendering.

>>If all this still seems unlikely to you, just look at what happened to sound processing.
>>In the early days, mixing and modulating multiple channels at high quality was a
>>heavy task for the CPU to perform. So your best option was to get a discrete sound
>>card. Then this sound processor migrated to the chipset. And nowadays it has been
>>reduced to just an I/O chip and the actual processing takes place in an audio codec
>>run by the CPU, thanks to its vastly increased performance. Not even power efficiency can reverse that trend.
>
>Well, in fact it already did and I am glad that you brought up the topic. Look
>at mobile phone SoCs, almost all of them have CPUs with excellent performance/W
>yet except for the cheapest ones they all sport a custom DSP for sound decoding
>and processing, usually coupled with a custom path to the DAC so that large portions
>of the chip can be powered down. The net result is vastly longer battery life when
>doing the common activity of playing back an MP3. Also SoCs are a pretty good example
>of custom hardware growing instead of shrinking, video hardware decoders have been
>growing in functionality and are now augmented by encoders. A peek at the schema
>of a BluRay-player SoC will also show you a disproportionate amount of hardware
>accelerators. The reason for this is very simple: as far as performance/W and performance/area
>go nothing beats custom hardware and that is becoming ever more important with the
>continuous growth of power-constrained devices.

Systems with fixed functionality, ask for dedicated hardware. No argument there. But consumer systems can take on many roles. Graphics is increasingly becoming less of a focus. Once you can run a wide range of casual games (and beyond) on the CPU, which is there anyway, there's very little demand for a piece of dedicated hardware.

Let me put it this way: Professional DJ's will always buy dedicated sound cards. But nowadays it's clear that's a worthless argument against audio codecs for the consumer market. Likewise, mobile phones may have dedicated DSPs for sound today, but with an ever wider range of applications a powerful CPU is needed and so in several years it will be a lot cheaper to have an audio codec for these power-constrained devices as well.

Dual-core CPUs for phones have only barely started to hit the market, but much against some people's expectations they're more power efficient. Two cores at 800 MHz consume less power during everyday use than one core at 1000 MHz, and can deliver higher peak performance when it matters. It's the MHz race to multi-core revolution all over again. Multi-core wins at performance per Watt.

>>The same thing will happen with graphics. Sandy Bridge already makes the GPU share
>>the CPU's caches and memory controllers. So it's not that big a step to perform
>>the actual processing on the CPU cores.
>
>Well, actually it *is* a big step. The only thing that changed is that now the
>IGP can access the L3 in a non-coherent manner, the memory controller was already
>shared as the IGP was on the northbridge. The IGP is still a processor of its own,
>with a specialized instruction set and hardware.

Clarkdale/Arrandale didn't have an on-die memory controller like Nehalem, but was connected to the GMCH with a QPI link. Nehalem didn't have a GPU. So with Sandy Bridge for the first time the CPU and GPU use the same memory hierarchy. Let me put it this way; the (logical) distance between two CPU cores is the same as the distance between a CPU core and a GPU core. You could say they do exactly the same thing: processing data. For as second, think of Sandy Bridge's GPU as a CPU core with a graphics-oriented instruction set.

That's a huge leap toward fully uniform CPUs doing software rendering. At a hardware level it may only seem like juggling things around, but it's a new milestone at a conceptual level. Previously the GPU was considered a device you send some data and some graphics commands and it did its magic. Fire and forget. It may as well have been on a different planet. But with Sandy Bridge these heterogenous cores are sitting side by side.

It opens up the possibility to really look at what sets them apart, and combine their strengths into a homogenous device. Previously this wasn't imaginable. Even if somehow it was reasonably efficient to replace the GPU with generic CPU cores, the communication distance between the two would make it impossible to take advantage of the homogenous instruction set.

By replacing Sandy Bridge's GPU with CPU cores, and adding gather/scatter support, you get a more powerful CPU and a more versatile GPU into one. That is not a big step, at the hardware level, but revolutionizes software development.

>>Once the CPU can run Crysis at high quality,
>>which I expect to happen well within this decade, the number of people willing to
>>pay for a GPU will have reduced considerably.
>
>Really? Even if running Crysis on the CPU will consume 100-1000X as much power
>as running it on a GPU for a similar performance level?

It doesn't consume anywhere near 100 times as much power. Buy yourself an i7 2600 and measure the wall socket power consumption while running Crysis with SwiftShader. It should be about 150 Watt. Next, find a system with the same performance in Crysis, but using the GPU. The closest thing I can think of is an ASUS N10 netbook, with a GeForce 9300M GS (http://www.youtube.com/watch?v=GqzhtI_xhPY). It consumes up to 30 Watts, so that's only a 5x difference.

So while today there is still a gap, it's not nearly as big as you think it is. You really have to keep in mind that GPUs are worthless without a CPU and the rest of the system.

And once again, it's only going to get better. Gather/scatter and a complete set of integer AVX instructions will considerably improve the performance. Also note that not nearly as many man-hours have been spent on SwiftShader compared to the development of GPUs and their drivers, so there's still room for some improvement. And finally, games are getting ever more complex so future GPUs will need more registers and caches and such so they'll burn more Watts to keep the efficiency up.

So this 5x gap is going to close from both ends. It's still considerable, but note that software rendering is very cheap in comparison so even today there's already a market for it.

>>And this entices more developers to
>>make use of the powerful generic capabilities the CPU offers, meaning that this
>>software doensn't run very efficiently on a GPU unless it evolves even closer to
>>the CPU's architecture. It's an unstoppable spiral which will cause the GPU to go
>>the way of the dodo in the long end, just like sound cards are exhaling their last breath.
>
>See above for the sound card analogy, as for the GPU-going-to-the-CPU code I beg
>to differ. For a long time I have been skeptical of the possibility of offloading
>non-rasterized workloads on GPUs but with the impressive stride of ray-tracing,
>path-tracing and full radiosity implementations coming to the GPUs it seems to me
>that it's going the other way around. GPUs are simply better for graphics, no matter how you slice it.

Wrong: http://www.youtube.com/watch?v=4bITAdWvMXE

>>The DLP for graphics workloads is stagnating. The motto "batch, batch, batch" has
>>reached its limits and to efficiently run more diverse applications you need to
>>take advantage of more than just data level parallelism.
>
>The way graphics workloads have been evolving DLP is actually becoming less and
>less of a problem. With deferred rendering and virtual texturing many recent engines
>can actually draw an entire scene with only a minimal number of API calls.

Deferred rendering and virtual texturing are nice techniques but they're not silver bullets by any means. The number of ALUs still grows and despite these techniques today's games use more API calls per frame than those five years ago. So I wouldn't say that DLP is becoming less and less of a problem at all. Like I said, the situation is stagnating (at best), and to achieve higher performance it's useful to start looking at more than just data level parallelism.

The writing on the wall is that both NVIDIA and AMD have released architectures capable of task level parallelism. Clearly they don't trust DLP enough for the foreseeable future and are willing to invest transistors in logic to exploit other types of parallelism.

>>And like I said before we don't want dedicated hardware for filtering. Everything
>>is pointing towards more generic gather/scatter units and filtering in the shaders.
>>Neither do we want dedicated hardware for rasterization. Tesselation is an early
>step toward programmable rasterization.
>
>I suggest you dig a little deeper LRB's demise as a GPU, lack of hardware rasterization
>and poor filtering performance had both an important part in it.

The causes for Larrabee's demise are not an argument against the viability of software rendering on the CPU. Here's why: Larrabee is an expensive piece of additional hardware they attempted to position against fierce competition in the high-end market. In the end what really killed Larrabee is performance per dollar. For Larrabee single digit percentages mattered a lot. So big investments into brilliant architectural changes which only start to pay off in five years when developers take advantage of the new possibilities, are a big no-no.

But that's the situation you get when the hardware is given only one purpose. If Larrabee doesn't perform as a GPU, you can't sell it as a GPU.

Anyhow, this doesn't affect software rendering on the CPU nearly as much. That's because you're already paying for one anwyay. If it's not used for graphics, it's still performing an indispensable purpose for other applications. So unlike with Larrabee which initially would be just for graphics so you expect it to be worth every penny when it's performing its single purpose, it's ok to buy a less-than-perfect architecture for graphics if it has also has many other tricks up its sleeve.

>>None of this is happening overnight and indeed it's not an easy task, but if you
>>look what GPUs were like several years ago, and extrapolate that several years into
>>the future, it's readily apparent that not a single graphics-specific feature will survive the test of time.
>
>Customized hardware will always beat software-based methods on generic hardware
>in every possible metric so no matter what happens, if a workloads is regular enough
>and gobbles enough processing time it will be a candidate for hardware offloading.
>Just look at IBM's wire-speed processor presentation, the thing has encryption,
>regexp and XML parsing accelerators on die (which on a side note tells me our whole
>industry is going down the drain, I never though I would see the XML acronym slapped on a piece of a die micrograph).

Again, systems with a single purpose ask for dedicated hardware. It's not an argument against audio codecs for the consumer market, and it's not an argument against software rendering.

>>Please name one co-processor on the same die, which after many years still remains a heterogeneous component.
>
>Well, I guess it depends on what you define as heterogeneous. FPUs still have separate
>instructions and register files, that sounds heterogeneous to me. A plethora of
>other hardware accelerators have been living on the same die as the CPU in SoCs
>without being absorbed (and some of them actually gained a customized CPU in the meantime).

A heterogenous architecture is generally considered to use separate instructions streams with a different ISA. You use an API to communicate with the slave components. So the FPU is not a heterogenous component, except maybe in the early days when it was a separate chip you could consider x86 and x87 to be different ISAs and the instruction steam is separated by the ESC prefix (which caused an interrupt which you could consider a very low level API call). But regardless of where you put the dividing line it proves my point that it became fully homogenous.

A customized CPU is not a heterogenous architecture either.

And that's the beauty of it. Just because we call something a CPU doesn't mean we can't give it a customized instructions set to make it efficient at processing graphics!

You could even add complete texture sampling instructions. You may even find some use for them outside of graphics. But personally I don't think this is a good idea. As I detailed above things are evolving toward generic gather/scatter operations anyway, which are a lot more useful outside of graphics as well.

>>The fact of the matter is that no developer really likes heterogenous architectures.
>>Software development is complex enough as it is to avoid having to deal with multiple
>>programming models.
>
>I wholeheartedly agree with that. Yet it's not going away, in fact it's getting
>more complex. Die area matters, and power even more so even if we developers don't like it.

It does go away. We used to have vs_1_1 and ps_1_3 instruction sets which were physically implemented in separate vertex and pixel processing pipelines. So if die area and power matter so much, why did they eventually unify? Simple. They were already on the same die (which wan't true prior to hardware T&L), with somewhat overlapping functionality, and the possibility to allow new applications. Unifying them resulted in an architecture which was faster due to removing the balancing bottleneck, and enabled developers to explore new horizons.

Before unified architectures were launched, vertex processing and pixel processing was still very different. Vertices needed full FP32 precision and complex operations, while pixels first and foremost needed texture sampling and at the most a bumpmap operation. Arguments based on die area and power consumption were used to ridicule anyone who even remotely considered the possibility of unifying them. After all, what would a vertex shader do with texture sampling, and what would a pixel shader do with FP32, right? And as for the balancing bottleneck, geometry LOD was the obvious silver bullet...

Sounds familiar? I think we both know who ended up being dead wrong. Note that this happened less than ten years ago. So again, just how certain are you that die area and power consumption will prevent a complete unification of the CPU and GPU (i.e. a completed vector instruction set), and a return to software rendering? They're on the same die today, using the same memory subsystem, you'd be removing a balancing bottleneck, you'd enable the CPU to run other existing and new/unknown compute intensive applications, and as a graphics processor you'd gain endless possibilities...

>>Also keep in mind that the GPU's programming models haven't
>>even settled down. Supporting multiple brands and even multiple generations from
>>the same manufacturer is a huge pain. So together with the 100 fold difference in
>>performance between the high-end and low-end, we're nowhere near using the GPU as
>>a reliable vector co-processor. Targetting SSE and AVX offers a lot more guarantees.
>
>That I also agree with, however we went from being completely unable to use GPUs
>for other workloads to being able of using them. As far as content creation goes
>I've been seeing more and more CPU-only applications offering GPU-assisted offloading
>which is something that (pleasantly) surprised me as I think it's the field where GPGPU makes more sense.

There's an article on this very site which shows that offloading anything other than graphics to modest GPUs is a bad idea and you need to cheat to make it look even remotely interesting: http://www.realworldtech.com/page.cfm?ArticleID=RWT070510142143

Also, what sort of content creation are you talking about? If it's graphics realated, it's not GPGPU.

>>The only thing missing to make the CPU's SIMD support complete, is gather/scatter.
>>Once that's available, the GPU makes little chance as a co-processor.
>
>Honestly, you seem to be ignoring what happened with LRB and that's a piece of
>hardware on which some very fine hardware designers and programmers worked on and
>it tanked exactly because bolting gather/scatter to a CPU is not enough to replace a GPU, far from it.

I'm not ignoring what happened to Larrabee at all. It has become a prime example of what not to do; trying to compete with high-end dedicated hardware when every dollar worth of hardware not spent on achieving higher framerates for today's games results in halving your potential GPU market share.

Eventually GPUs will support fully generic code and have more independent cores and explicit SIMD instruction sets with gather/scatter and a coherent cache hierarchy, just like Larrabee, but you can't jump to that in one go since the software needs to evolve too. If NVIDIA released a GeForce GT 430 back in 2007 instead of the GeForce 8800 Ultra (same transistor count), it would have failed miserably, despite the DirectX 11 features, CUDA 2.1 capabilities, and large caches. It sacrifices raw computing power and bandwidth per transistor, and this trend will slowly but surely continue.

But Larrabee's mistakes don't apply to CPU software rendering. With only minor changes the CPU can become a more attractive processor for a wider range of applications, while also providing adequate support for graphics. The first iteration may only interest people who want a powerful CPU and don't care much about graphics as long as it can support simple games and 3D interfaces. But as things continue to converge and the advantages of generic graphics programming become apparent it will make mid-end and eventually high-end GPUs redundant. People who want powerful graphics will simply buy CPUs with more cores.