I'm not going to comment on the economics as I don't know enough about it (although I would guess they are inflated a bit), but the benefits of multithreading must be weighted and determine if it is a good fit for the application. Video compression needs it, a simple text editor less so.

As for the "death" of GPUs, I doubt that will happen anytime soon. Far off in the future, probably.

C++ or CUDA? Is Nvidia sponsoring this guy? If CUDA was so freaking wonderful in it's present state, there'd be more applications that use it. The fact of the matter is that 99.999% of applications run fast enough on a modern CPU without any good reason to run it on GPGPU.

What's more absurd is him making that ridiculous rant without giving a nod to OpenCL, which aims to do everything he talks about...

Well, he has a valid point, where programming in a simple way for a CPU is much simpler than writing for an API like Direct X and Open GL. They do provide a good way of hiding the hardware video cards and providing a common interface. So, a major con and major pro for video cards and their API's.

Until processors are fast enough to replace all that the video cards of today can do now, at the same speed, I don't see video cards going anywhere anytime soon. At the same time, when CPU's are fast enough, GPU's will also have advanced enough that they will still make a difference big enough. They progress together. Where games are concerned, I can see that the CPU would go away or be less significant than the video card.

There already is technology that allows higher level languages to run efficiently on multiple platforms. It's called a compiler. Besides you can't kill something (GPGPU) that really hasn't been born yet. Unless something can be done to address the horrific latencies of CUDA, et al, it will only be useful as a niche, non-interactive, batch-oriented tool.

Reminds me of the CEO of my last company. He tells us that he has no clue what we do every day and then goes on to tell us that it must be faster and cheaper.

Sweeney obviously has no clue what DirectX and OpenGL are, but is convinced there are better ways to do graphics processing. I know how the programmers at Epic feel.

I would rather listen to John Carmack talk the state of gaming technology than to listen to Tim Sweeney's baseless talks.

I think Tim is just wrong, I mean maybe(!) when CPU's have 32 cores (2016?) you could afford to gobble up 20 or so for rasterazation and vertex setup. Doesn't that though kind of push into the area of programming for a GPGPU? I thought that's what Directx and OpenGL was for so they didn't need to keep reinventing the wheel... This is the perfect time for a small team of highly motivated young programmers to spend a few summers in their basement and bang out the next generation engine for GPGPU's.

Well for starters you have a slow PCI bus that is just well slow. The significance of this is a developer needs to write instructions(ie code) that takes this into account and then call the API to do stuff(shader code etc...). To complicate matters further you have PPU code(physics code which is really just glorified collision detection) which may sit on the graphics card but not necessarily. Also their is the sound card which will call positional acoustic events in 3d space. All of the code of the game itself in a effect has to be load balanced with the PCI bus working overtime.

Going back to the GPU compiler topic what would be nice is to just use C++ templates or the CLR of .net and just stick some templates and very quick load balance CPU/GPU code churned out however regardless of the language at hand the developer will still have to construct a good object design which will take some time. The worst case is a bit of code duplication because of different languages which is what we have right now but honestly it's not really that bad unless you don't understand the architecture then creep sets in. For example within DirectX you have constant buffers and vertex types where you can set the structures which will communicate the type of information back and forth between CPU mobo and GPU land since the primitive types are standardized(IEEE32 bit floats) it's pretty trivial for a programmer to know what's going where however I must agree it's quite annoying to try to integrate physics api with gpu.

This all goes to a lack of understanding of the underlying architecture. I worked at a company that was enforcing what they called 3-View design. The only problem with this design system was that determining what the system should do, and determining what the system should be made of (i.e. hardware) were independant processes. This meant you developed a system without knowing the limitations of the hardware its running on. I pointed this out to the instructor who was teaching the class they offered at work, and he couldn't even respond.

A good example of this is Crysis. How much money did the producers put into that game to give it cutting-edge graphics and effects, only to find out consumers needed a multi-thousand dollar computer to benefit from that hard work, thus most people would never see it?

CEOs tend to be business people with degrees in Business Administration that rarely know the details of what they manage. This guy clearly doesn't understand code, he's taking "recommendations" and "data, in an executive format" that have been regurgitated up the chain of command a few times, combined with some arrogance and self-importance.

We used to be a nation where inventors founded a company to create and sell their invention, now we have a bunch of spoiled, rich-kid schmucks running "established, brand name" companies. It's nearly impossible to start a new company now, and any person with brilliant ideas has to find a job at an established company, and then have their ideas "managed" by a bunch of ignorant MBAs. Then we wonder what happened to America...

Frozenlead: Developers too lazy to learn to multithread/GPGPU optimize code.

Since when in the tech field do people complain about moving forward? If you can't keep up with the train, you lose.

Oh it's the guy from Epic Games, no wonder GoW was so buggy, they have a idiot in charge.

For a company that develops the most used engine in videogames. Thats a poor idealogy. 2 cores is too much money. If a competitor develops a GPGPU version, they will definetly face a backlash in engine sales.

That's a tough call. I'll choose option 3 if I can: ignore both.

http://en.wikipedia.org/wiki/Tim_S [...] developer)

Not exactly someone who I would consider a clueless CEO.

Well I can tell you first hand that when I enable CUDA in Coreavc for my HD movies, CPU utilzation drops from about 10-20% to mostly 1%. Yes, same speed - but why not utilize the power of the GPU for tasks that it can very easily perform?

Carmack has a unique position, he surrounds himself with the most elite programmers, and is one of the most eilite programmers himself. I get the impression that Sweeney has more business acumen, and thus aproaches the situation from that perspective.

In the end, I agree with Sweeney... having a unified programming architecture is more cost effective... and I see larrabee's architecture ultimately dominating mainstream PC gaming.

Having done some GPGPU work myself, I can agree that it's a significant amount of work to port general purpose code to the GPU. The amount of effort depends on exactly what you're trying to do, and sometimes the whole exercise can end up producing a much smaller speedup than expected.

The biggest hurdle is the fact that GPGPU is still not standardized (DirectX 11/compute & OpenCL are just starting out), so there are several standards to work with. The algorithm still needs to be written for the CPU, as there are still users out there without proper GPGPU hardware support. All of that adds up to a lot of risk, which the financial guys don't like much - so the 10x figure doesn't seem too crazy.

Of course, when a GPGPU'd algorithm works well, it's pretty incredible.

GPGPU is the future. OpenCL will be the greatest programming standard that ever happened to linux and windows.

Sweeney's still pissed at ATI for pre releasing Quake 3

asH

Sweeney can only be talking about Larabee, which is conceptually a bunch of cpu's strapped together..if i7's are $500 and up that one will cost $3000 in lots of 1000- reduced wafer size or not, its hyperthreading and all that overhead thats costly- and I dont see signs of Intel spending on R&D lately.
asH

right, cause larrabee will be made of a bunch of their most expensive processors. I'm pretty sure it is actually a bunch of shrunk P1s or P2s isn't it?

This is one way of telling why there are so few games that support "new" technologies like multi core support etc. They are too costly to make... Hmmm... This is great new for companies like AMD and Intel who will put their GPGPU products in line sooner or later. Nice new technology that nobody wants to support for many years. Just like AMDs' 64 bit support that is now starting to see some light after what 10 years? waiting...

mamiya0taru: Larrabee will be a bunch of Atom CPUs on a single die. It's funny how they come up with their Tflop/Gflop numbers for Larrabee, if you factor in the slight increase in clockspeed, multiply the Gflops of Atom by the number of cores, then they're claiming that somehow what are essentially Atom cores wind up being as fast as indvidual Nehalem cores, and at a lower clockspeed. Synergy, brilliant design, or outright lies?

Today's CPUS are pretty fast. They may be specifically geared towards more general purpose tasks but that is a response to the market. If and when they see that dedicated graphics processor are overkill for most users in both power consuptions and processing power I think we will start to see more SSE3/SIMD/3DNOW/OPENCL whatever type decoder units in CPUs. Considering that NVidia is the only real stand alone GPU maker you can see that the technologies to integrate the CPU and GPU into a single unit and the shift to in-CPU graphics processing have already begun.

I would go so far as to say that modern CPUs could dump a lot of the logic they currently carry and absorb some GPU tech that does the same but better and then release the new instructions as an extention like sse or 3dnow to give direct access to it from opencl libraries.

In theory, if you could get equal CPU power as is in modern GPUs you could eliminate a lot of the bottleneck/latency that is the PCIe bus. Something like hypertransport between general instruction execution units and gpu-type execution units.

Companies are already looking at this and the GPU's day will come, but it will be a borg like assimilation, not extinction.

If it cost's so much then why are so many companies developing code for it???

1. GpGPU is 2-100 times faster then the cpu, so I suppose it depends on what you are using it for and how long u plan to run it. Cuz the longer you run it on a gpu the more it pays off. Folding@home for example has been around for years, and hundreds of thousands of computers run that code.. So it would be well worth it to develop for the gpu instead of the cpu for that application. But, if you just need a code for a small company for a small project, obviously it wouldn't be cost effective.

2. For games, if the code is developed mainly on the cpu, like GTAIV, then obviously it's gonna bottleneck the game and people are gonna be pissed off and avoid the game because they don't have the cpu to run it. But if they coded it better to take advantage of the gpu more in my opinion the game would have sold much better and the developing costs would have payed off in the long run.

3. I am not gonna say anything on larabee since it's taking Soooo long to develop who knows what the gpu is gonna be like when it's finally out. By then it might be obsolete.

4. The gpu processing power increases exponentially compared to the cpu because of parallelism so if this continues then developing on the cpu is gonna hurt in the long run. The gpu is just way more powerful.

I really want to say that for a game developer i believe it is smartest to learn to code taking advantage of all the hardware any platform has to offer So choosing just the cpu or the gpu as the primary focus of the programming is not very wise. They should really focus on both of them to get the best performance and stay out of the cpu gpu battles and just let whatever happens happen. As for scientific of other purposes it depends on the program they are gonna use, how long they are gonna use it, and the cost, so you can't just say gpgpu is dead cuz it sound's like he is getting paid by the cpu manufacturers to say that... (lol)

The gpu is here, it's in it's prime, and is not going anywhere. If anything the cpu and gpu are gonna combine into one big mega chip, probably with ray tracer, dsp, all built in, and actually i can forsee a futer will it will take on all the fuctions of the motherboard and the psu and will become modular and "completely" wireless including being powered by wireless means. This will be a superchip that will do anything and everything. I'm going to name it,( remember you heard it here first lol), I'll call it the "UMPU"- for Universal Mega processing Unit

The hard part about what you are suggesting is that we take 2 completely different architectures, mash em up and hope for the best. This is like saying take a CISC processor and combine it with the properties of RISC processor.



Other companies are using it for applications that never originally used the GPU, examples include video transcoders, CFD simulators, and other math applications. Since the GPU is a number crunching monster (ADD, MADD, etc) it is a good fit for these applications.



Folding@Home is not a general-purpose application, it is a highly mathematical application and would benefit from any number crunching hardware. FAH is a perfect app for the GPU since it knows all the data beforehand (since the data sets would probably be small), and you just feed the data and your formula and just wait for the result. The GPU performance drops if you need to take a look at some derived data which is in the VRAM, RAM or HDD of your PC.



I'm not really sure about the application of GPGPU with games, because if the GPU today is already busy drawing everything does it really have enough free time to do other tasks? Let's face it, if the GPU is an underused resource during gaming, then why is a 9400GT not good enough to play recent titles at high settings.



I think Intel is going to try to do that before the guys in green and maybe before AMD. Remember the 80-core thing Intel did before (and what it was actually meant to show)?

Thats why I chose gtaiv, if you look at the benchmarks you will see that u get similar performance with midrange cards as you do with top end cards. And yes, in most games the graphics chips are used to there full potential, but in gtaiv the graphics cards are only being partially used while most of the coding is taking advantage of the cpu. Hence the reason u need a quad core just to play the game. If you can play at the same settings on an 8800gt that you can play on 285gtx, then I would say yes, the video card does have enough processing power left over to tackle the extra tasks. That is also the reason why a xbox 360 or ps3 can play the game at decent frame rates is because it's a port from those systems one wich is a tri-core and the cell unit is an 8 core. If they optimized gtaiv for the gpu then ported it to the console, i doubt it would run well at all, which is probably why it was only supposed to be out for the console until pc gamers complained and then they had to recode it. just my opinion though.



No, im not suggesting we just mash them together and hope for the best. What I am saying is that that it is going to be the normal evolution of computer chips. Instead of having everything separate, somewhere along the line they are gonna figure out how to put everything together in one package, wether it be just combining them all together in one package, or weather they come up with an entirely new design that does it all. I'm betting on the latter. And, I bet it's gonna be soon. Technology advances so quick these days. In 10 years I bet cyborgs are gonna be a common thing..

^ oops, guess i should have proof read for spelling errors ()

Wow the level of ignorance I'm seeing here is really astonishing. I'm glad to see someone posted a Wikipedia link to Tim Sweeney...I hope a few people actually read it.
My belief is that he is correct in saying that soon we'll see an end in the seperation of GPUs and CPUs. Its already been happening, and this is the course that was set in motion ever since DirectX 8 and OpenGL 2.0 introduced programmable pixel and vertex shaders. Over the last several generations the GPU has been becoming more and more robust and coming closer and closer to being able to run 'general purpose' code. Larabee is the essentially the culmination of the GPU and CPU (being highly parallel like today's GPUs yet compatible with everyday x86 instructions) and it IS the natural progression of things. The benefits of this are numerous. It frees the programmer from the restrictions of the hardware...instead of having to know which functions a piece of hardware can execute, he needs to know how FAST it can execute them. It's truly a game changer. An example of what this means...take a look at Crysis. It's a great looking game. But, it's and engine created for and restricted by the capabilities of the hardware (DirectX 10 specifically). Now imagine a hypothetical future game engine. It's written totally with a custom software renderer. The implications of this is that the renderer is limited to the imagination of the programmer more than the capabilities of the hardware. DirectX 11 may be the last version before this happens (as it introduces a vast amount of general purpose capabilities and lifts many restrictions...bringing it closer to compliance with the more common CPU). AMD and Intel are both in a great position for this, and NVidia would like you to think it's not happening, but it is:
http://www.theinquirer.net/inquire [...] s-x86-chip

I use gpu based video conversion software its 500x faster than cpu with my current rig setup, then next dx version should have built in support for gpu based offloading that would eliminate the need for programming in cuda.

Windows 7 makes use of gpu for things like encoding sound and video and imaging thus gpu usage will be in windows 7 they should be getting ready for that.