Slashdot Mirror

← Back to Stories (view on slashdot.org)

Twilight of the GPU — an Interview With Tim Sweeney

Posted by ScuttleMonkey on from the steady-march-of-progress dept.

cecom writes to share that Tim Sweeney, co-founder of Epic Games and the main brain behind the Unreal engine, recently sat down at NVIDIA's NVISION con to share his thoughts on the rise and (what he says is) the impending fall of the GPU: "...a fall that he maintains will also sound the death knell for graphics APIs like Microsoft's DirectX and the venerable, SGI-authored OpenGL. Game engine writers will, Sweeney explains, be faced with a C compiler, a blank text editor, and a stifling array of possibilities for bending a new generation of general-purpose, data-parallel hardware toward the task of putting pixels on a screen."

71 of 286 comments (clear)

  1. For once ... by Qbertino · · Score: 4, Informative

    For once I'm reading an 'xzy is going to die' article that doesn't sound like utter rubbish. Could it be that, for once, the one stating this actually knows what he's talking about?

    My last custom realtime GPU was a Geforce Ti4200. I'm now using a Mac Mini with GT950. Mind you, Blender *is* quite a bit slower on the 950, even though it runs with twice the sysclock, but I'm not really missing the old Geforce. I too think it highly plausible that the GPU and the CPU merge within the next few years.

    --
    We suffer more in our imagination than in reality. - Seneca
    1. Re:For once ... by Anonymous Coward · · Score: 5, Funny

      On a day when Lehman Brothers and Merrill Lynch, the backbone of our economy, "died", to make these kinds of heartless statements is just pandering to the prejudices of the liberal elite. Instead of buying a Mac you should buy a Dell (which is far more "American" in the truest sense of the word) and instead of irresponsible talk of combining CPU and GPU you should keep them well separated for the good of our nation.

      Our country is built on a strong consumer market; it is "progressives" like you who are causing this crisis, which might even result in a president with an Afro. Shame on you.

    2. Re:For once ... by juiceboxfan · · Score: 2, Informative

      No, that can't be it. Know why? Because...why would you put more processing and thus more heat in one place that already has problems with that?

      Cost. It's cheaper to build and install, on the MB, one chip with one die than it is to build two chips/dies on two boards (not to mention bypass caps, fans, RAM, etc.). With combined functions it may be that the one chip produces less heat than the total of the two, although it is all in one spot.

      And why install an overkill graphics processing unit inside the processor if most people won't use it anyway?

      Maybe two CPU grades? One with full graphics capabilities and the other with basic graphics (could be the same die one passes all graphics tests at full speed the other doesn't).

      And where would the VGA/DVI output go if there's no graphics card? If you put it somewhere else then why move the graphics processor further away from the outputs?

      You are already going to put a (relitively) long cable from the connector to the monitor, what's a few more inches?

    3. Re:For once ... by Antitorgo · · Score: 5, Interesting

      Except that you like everyone else reads "CPU" in the article to mean the Intel/AMD CPU and not think of it as current gen GPUs that are almost capable of massive parallel execution of general purpose code. With the advent of Shaders, more processing was able to be offloaded to GPUs and over the next couple of GPU generations. So his idea is that we'll see less of the OpenGL/DirectX specific API calls and everything being done in CUDA/Shaders. That way the folks who write graphics engines aren't limited to the current SGI implementation (here's a set of vectors describing my object -- draw it) and we'll see different rendering engines based on Ray Tracing for example (or whatever other methods the engine writers want to do it).

      This isn't anything new here -- he's basically saying what Intel has already said... You'll see less OpenGL/DirectX and more CUDA/Shader based implementations for rendering engines.

    4. Re:For once ... by vux984 · · Score: 5, Insightful

      No, that can't be it. Know why? Because...why would you put more processing and thus more heat in one place that already has problems with that?

      You mean how floating point units used to in a separate coprocessor?
      Or how L2 cache used to be on external chips? (And in some cases was even upgradable.)
      Or how modems used to have their own signal processors? But now most use the CPU.
      Or how we're moving the memory controller into the CPU right now.

      Hell, we've even stuck the majority of complete additional CPUs into the the CPU with our modern dual and quad core chips.

      Apparently the author doesn't know much about computers.

      Apparently you don't know much about computers either.

      The entire history of the personal computer is been one long slide of functionality moving towards the CPU. Sure every now and then something new comes along being done by an add-on processor - like the numeric coprocessor for example.

      Sure before the coprocessor you could accomplish the functionality of what a coprocessor does with an 'integer cpu', but a hardware optimized numerica coprocessor was a new feature, one that added tremendous floating point performance in dediated hardware. Within a couple CPU generations the coprocessor had been completely absorbed into the CPU.

      The author is speculating that the GPU will see the same fate eventually. And he's probably right.

      And why install an overkill graphics processing unit inside the processor if most people won't use it anyway?

      Once upon a time people said that about numeric coprocessors. "Only a research scientist would need that!"

    5. Re:For once ... by ZorbaTHut · · Score: 5, Insightful

      Man, you've got some awful, awful arguments here.

      Because...why would you put more processing and thus more heat in one place that already has problems with that?

      For the same reason that your CPU isn't spread up among thirty chips distributed throughout your laptop: efficiency and cost. Making one chip is generally cheaper than making two, and the amount of bandwidth inside a single chip is massively higher than what you can do with a northbridge.

      And why install an overkill graphics processing unit inside the processor if most people won't use it anyway?

      Every latest-generation operating system provides a 3d accelerated desktop. Every latest-generation computer provides the hardware to use it. Programs are going to be taking more and more advantage of that feature.

      And why attach it to a part that's waaaaaay harder to upgrade and usually either requires a reactivation or reinstalled of your OS?

      See question 1.

      And how much harder would graphics hardware driver updates be?

      Not at all. For one thing, there wouldn't *be* graphics hardware - it'd be more of a vectorized coprocessor. For another thing, why *would* it be any harder? It's not like people are having horrible trouble updating their USB drivers, even if the USB controller is part of another, larger chip.

      And would it overheat laptops a hell of a lot faster by putting more heat in one location? (spoiler alert: yes)

      Obviously, if they took existing laptop designs, and slapped a bigger heatsource in the CPU, yes. I'm assuming that computer manufacturers aren't functionally retarded, and they wouldn't do that. (Well, maybe some would, but their computers aren't going to be stable anyway.)

      And where would the VGA/DVI output go if there's no graphics card?

      The same place it already goes on motherboards that have integrated graphics? It's not like "computers without dedicated graphics cards" is a new concept, unless you've been living in a cave for the last decade.

      If you put it somewhere else then why move the graphics processor further away from the outputs?

      See question 1. Also, "why not?" - it's not like that extra four inches is going to be a serious problem.

      As near as I can tell, your argument comes down to the common logical fallacy:

      "They *could* do X. But if they do it the *stupidest way possible*, X is a bad idea. Therefore, X is a bad idea."

      When determining whether something is a good idea or not, you have to assume it's going to be done well. If the person in charge of integrating CPUs and GPUs is anything less than a complete unalloyed moron, they'll have come up with solutions to all of those issues of yours.

      --
      Breaking Into the Industry - A development log about starting a game studio.
    6. Re:For once ... by Goldberg's+Pants · · Score: 5, Funny

      what's a few more inches?

      The difference between "Is it in yet?" and "Dear god you're ripping me in two!"

    7. Re:For once ... by Mad+Merlin · · Score: 4, Interesting

      So wait, your integrated graphics is *slower* than a low end discrete graphics card that's now 6 generations (or ~6 years) behind... and you find that acceptable?

      At the current pace, it'll take them a decade to match a high end card from today with an integrated card, and video cards aren't standing still in the mean time.

      You can point at the current integrated market for video cards, but that's not terribly interesting due to the fact that a) current integrated video cards barely do more than send signals to monitor(s), and (as a corollary to a) b) current integrated video cards aren't very fast.

      Wake me up when integrated video cards are faster than discrete video cards.

      --
      Game! - Where the stick is mightier than the sword!
    8. Re:For once ... by Miamicanes · · Score: 5, Informative

      > Or how modems used to have their own signal processors? But now most use the CPU.

      Welllll... I'd say the move to HSP modems took place more because the ascent of DSL and cable internet relegated modems to the status of, "nice to have if I happen to need it once in a blue moon to send a fax or dialup in the middle of nowhere at some point over the next 2-4 years." Remember all those articles 3-5 years ago about how host signal processing absolutely DESTROYS CPU performance because it demands constant attention from the CPU, and the software overhead of having to keep stopping to service the modem caused the computer to run at least 20-30% slower? Well, not much has changed, except now with a multi-core CPU it can kill the performance of just ONE core instead of bringing the whole computer to its knees. But even with multicore CPUs, I can guarantee that if modems were still the primary way people got online, there would definitely be a thriving market for "performance" modems that offloaded at LEAST the signal-processing functions to a real DSP (like the Lucent "semi-Winmodems", that actually gave users the best of both worlds... offloading the stuff that really dragged the CPU down to its own DSP, but doing things like compression and error-correction that could be handled in discrete batches faster than even dedicated hardware could achieve).

      There's another thing to remember about discrete chips... in the early 3dfx days, the mainstream CPU makers (Intel, AMD, and Cyrix) had ZERO interest in giving even the slightest attention to 3D graphics. Unless you're IBM (who wasn't interested in 3D, either), building CPUs is probably way beyond your company's capabilities. HOWEVER, designing a 3D graphics chip with the complexity of the first ones used by 3dfx IS within the capabilities of a well-funded design company with the connections to get it manufactured. It doesn't even need a fab with the capabilities of one owned by Intel, AMD, etc. So discrete 3d cards were an elegant way to sidestep the deadweight lack of interest on the CPU side by shifting it to a chip that smaller companies could design and build. Now that "the big guys" have turned their attention to it, the smaller players don't have a prayer (ergo, the merger mania among CPU/mobo chipset makers and graphics chip makers).

      The same observation can be made regarding cache and memory controllers. In the First Pentium Era, volume manufacturers like Compaq (and their comrades at arms, Intel & AMD) regarded cache as a luxury the unwashed masses could live without, even if it only saved $5 and cut the effective performance in half. Hey, consumers only look at that "Mhz" number, anyway... Fortunately, performance-oriented mobo makers were able to take matters into their own hands, and once again do an end run around the CPU vendors' sloth and put cache directly on the mobo. Once CPU makers decided cache mattered, and put lots of it on-die, the marginal benefit of putting more, relatively expensive tertiary cache on the motherboard diminished. As for memory controllers, they got moved into the CPU because it was the only way to reliably achieve increased memory bandwidth (designing a 32-bit parallel interface for ANYTHING that has to run at 400+ MHz and communicate across traces on a circuit board is a hardcore engineering challenge; Serial is cheaper to implement and can be faster overall than a simpler parallel solution, but there's a point where you can't shove the bits any faster, and the only way to increase bandwidth is to go parallel. It's not a coincidence that PCI Express video cards communicate 16 bits at a time, but even the fastest fibre-channel disk or network interface is happy with a single bit.

      The sad irony, though, is that 5 years from now, games will probably have graphics about as good as you can get from the best and most expensive SLI solutions money can buy today... but overall performance will probably be less consistent (ie, if Windows decides that it might be a good time to reorganize its temp directory while y

    9. Re:For once ... by GleeBot · · Score: 2, Interesting

      "Only a research scientist would need that!"

      Only a research scientist does need that. Meanwhile, uninformed consumers are being suckered into buying way more than they need to check email and type their documents.

      Or, say, play Quake.

      The nice thing about functionality moving into the CPU standard is that it opens up that functionality for a lot more applications than originally intended. FPUs may have mainly been for scientific work early on, but because it's essentially ubiquitous, now a vast array of programs do floating point computation... probably including your word processor.

      The main reason I might have my doubts about this is that graphics performance has been advancing faster than CPU performance for a while. If that trend continues, I'm not sure people would want to be tied down to a single unit for a while. People on the cutting edge replace their CPUs a lot less often than their GPUs. In the long run, it's probably inevitable.

    10. Re:For once ... by kestasjk · · Score: 4, Insightful

      The key difference is that L2 cache, memory controllers, FPUs, they all need to interact closely with the CPU.
      GPUs generally just take data from the CPU and get rendering, so unless they start sending data back to the CPU much more there's no real reason for them to merge.

      Another difference; graphics cards benefit from being updated every now and then. Another; GPUs use a lot of transistors, and because of their parallel nature the more transistors the better, it's not something that will get so small that it can be tacked onto the CPU as a nice extra. There are probably more.

      --
      // MD_Update(&m,buf,j);
    11. Re:For once ... by dnoyeb · · Score: 4, Interesting

      Not if AMD can help it. Obviously this is not their path or they would not have purchased ATI. They sell two products, one of them is enormously expensive, the other is reasonable. I cant see why any graphics card manufacturer would give up all that profit!?

      Also consider that GPU upgrades are much more frequent that CPU upgrades. I don't think the dollars favor integration of the two. I don't think there is enough competition for force it either.

      The only company that may achieve this is VIA. For completely different reasons.

    12. Re:For once ... by LoRdTAW · · Score: 3, Interesting

      He does make a good point and its a throwback to the old days before GPU's existed. Look back to the days of Doom or Duke3D, You had to hand code and entire rendering engine for the game. No API's or 3D hardware was available, only a single CPU and a frame buffer and compiler. With current and upcoming technology like multi-core and stream processors, there will be plenty of new options for developers to take advantage of. IBM Cell, Intel's Terrascale and Larabee are three of those technologies but I still highly doubt the GPU is done for yet.

      3D rendering isn't the only thing going on in games or other programs. You have physics which is used in both games and simulators. We also have AI, which in games is still severely lacking. 3D sound is still simply how far is player from object and attenuate the sound as necessary. So those areas could definatly use those multi core CPU's or Stream processors.

      We cant forget about really exciting stuff like real time ray tracing that is well suited for multi core and stream processing but its ways off. I don't think the GPU will disappear in the next five years but I do see it evolving to adapt to new rendering technologies. Instead of a very discreet GPU we will have a very fast accelerator chip that can do more general work. It not only will handle the 3D rendering pipe but also lend itself to tasks like video processing, DSP, audio processing and other compute intense tasks like physics. It is already happening with Nvidia's CUDA and ATI's Stream SDK. We still need a general purpose CPU to manage the OS and I/O but like the IBM cell it could very well move on die. Multi-core X86 CPU's are not the future. Instead we need one or two cores to manage resources and run legacy code.Then you let the stream processors (for lack of a better term) do all the compute intense dirty work. Hell we could even get rid of X86 and go with a more efficient and compact CPU like ARM or something else entirely.

      Funny as I am typing this I realize I am pretty much describing the IBM cell processor and Intel Larabee. But still I doubt developers will be the ones holding the ball for interfacing with this new hardware. Hardware vendors and developers will (or rater should) come together and standardize a new set of API's and tools to deal with the new tech. If developers have a breakthrough that is better than ray tracing, they will definitely have the hardware to do it. Welcome to the future.

    13. Re:For once ... by Anonymous Coward · · Score: 2, Informative

      Apparently the author doesn't know much about computers.

      From Tim Sweeney's wikipedia page:

      Tim Sweeney is a computer game programmer and the founder of Epic Games, and is best known for his work on ZZT and the Unreal engine.

      Sweeney established Epic as a shareware company while he was a student majoring in mechanical engineering at the University of Maryland.

      From your wikipedia page:

      No content.

      Hmmmmmmm.... A mechanical engineer versus a guy named after a noodle. I wonder who knows more about computers...?

      (Seriously, mods, the parent got modded Insightful? The parent seems to know nothing about electrical engineering. Mods: if you know nothing about a subject, don't mod posts about that subject!!!)

    14. Re:For once ... by ceoyoyo · · Score: 2, Informative

      It's very slightly (pennies) cheaper to put one chip on the motherboard rather than two. It's MUCH more expensive to merge two big CPU/GPU type chips into one. Manufacturing flaws become more common fast with bigger chips.

      If we could break CPUs into pieces now we'd do it, both for that and heat reasons. We can't because all the parts currently located in a CPU need to talk to each other very fast. The GPU is something that usually doesn't need to talk to the CPU much. So it's separate.

    15. Re:For once ... by Dahamma · · Score: 2, Informative

      I'm sorry to be blunt, this post is almost entirely inaccurate! Informative, jeesh.

      1) There is no GT950 - Mac Minis use the Intel GMA 950.

      2) the GMA 950 has NOTHING to do with merging the CPU and GPU - it merges the motherboard chipset with the GPU.

      3) the GMA 950 is the same old special-purpose GPU concept as anything from NVidia or ATI (er, AMD) - just slower and using system memory instead of dedicated RAM.

      The article is talking about rendering graphics on a high-performance, parallelized general purpose processor, not a crappy GPU embedded on the motherboard. Think a future generation of the Sony Cell architecture, not the Intel GMA!

    16. Re:For once ... by amdpox · · Score: 2, Interesting

      Yes, it's much better to be told "you're not allowed to do that" than "you are not being allowed to be doing that".

    17. Re:For once ... by famebait · · Score: 2, Interesting

      Doesn't matter. There are basically 2 big point here:

      1) The special-puropose GPU will morph into a more generalized co-processor for handling all sorts of massively parallel stuff.
      This is just bleeding obvious, and I can prove that, because it is already happening. As more and more of it becomes programmable, it only makes sense that the built-in rendering microcode is replaced with libraries that ou may or may not chose to hack yourself.

      2) Once the generalization is done, it will make sense to merge the two processors. Might sound weird, but we are already doing multicore designs in stead of separate CPUs, which would be the logical choice if density were such an issue. Turns out the benefits outweigh the cost of advanced cooling.

      You are right, though, that it will not be a small "nice extra" tacked onto the CPU. It will be a very large part of thte CPU, and of its total working capacity.

      --
      sudo ergo sum
    18. Re:For once ... by Guspaz · · Score: 3, Insightful

      If the performance degradation 5 years ago was 20-30% because the things were pumping out a ton of interrupts, one would expect the resurgence of multithreaded CPUs to further reduce the impact. They should help with context switches. When you've got eight logical cores, that 30% is suddenly 4%, and much less important.

      US-Robotics still sells "hardware" modems, although they're not all that cheap. But back in the day, they did cut 50-100ms of latency off a dialup connection when compared to a winmodem (or controllerless).

    19. Re:For once ... by Guspaz · · Score: 2, Insightful

      You're exaggerating. Modern Intel integrated graphics fully support DirectX 10, and full onboard video decoding. They're comparable to discrete GPUs from about three years ago.

      Do these things scream when it comes to games? No, but they don't need to. For the vast majority of people, serious gaming isn't in the cards. These GPUs need to display a 3D accelerated UI with decent performance, and help out with media decoding. Casual gaming is a plus, although businesses aren't interested in that.

      By these accounts, integrated graphics are more than sufficient for the vast majority of users.

      Besides, from reading most of the comments above, people are missing the point here; this article isn't talking about merging the GPU into the CPU, it's talking about how discrete graphics are becoming increasingly CPU-like, and how we're going to eventually reach the point where GPUs are so general-purpose, they're actually specialized CPUs. This is, infact, exactly what Larrabee is going to be; a very simple massively multicore CPU sitting on an add-in board. Sweeney's prediction is that AMD and nVidia are both going to take their GPUs to similar places eventually.

    20. Re:For once ... by juiceboxfan · · Score: 5, Informative

      It's very slightly (pennies) cheaper to put one chip on the motherboard rather than two. It's MUCH more expensive to merge two big CPU/GPU type chips into one. Manufacturing flaws become more common fast with bigger chips.

      I don't think your estimate is correct for packaging and placing a single chip vs. two chips but in high volume manufacturing even pennies make all the difference. What about the cost of the second fan and other infrastructure for the GPU? There is also the issue of real estate - two chips take up more room than one so your etch routing becomes more of a challenge requiring smaller etch geometries resulting in a more expensive PCB.

      If we could break CPUs into pieces now we'd do it, both for that and heat reasons. We can't because all the parts currently located in a CPU need to talk to each other very fast. The GPU is something that usually doesn't need to talk to the CPU much. So it's separate.

      No, it will always be cheaper to integrate at the chip level. Look at system prices, dual core is cheaper than dual CPU (if you can even find one these days) of similar performance. The trend in embedded systems (even more cost sensitive than PCs) is to integrate everything into a single package (SOC). As others have pointed out cache and the FPU were once separate chips from the CPU they are now all integrated into one package.

    21. Re:For once ... by Molt · · Score: 3, Interesting

      A modern GPU, such as the current flagship GeForce GTX 280, is a relatively specialised piece of hardware. It has optimised support for things such as matrix operations which are used a lot in graphics and yet has no real support for integers which aren't. It has a very fast and entirely dedicated memory bus capable of pushing 140GB/s at maximum for processing geometry and textures. It's highly parallel having two hundred and forty stream processors to process the millions of seperate shader runs which make up a single frame of a high-resolution 3d scene as quickly as possible. It is also a very complex piece of technology having 1400 million transistors compared to a Core 2 Extreme QX9650's 820 million processors.

      There's no way that a current CPU could replace that in anything other than a very slow emulation mode even if fully dedicated to the task. If you do want to see the difference download either nVidia's FX Composer or ATI's RenderMonkey which are both shader authoring tools. These will allow you to load a shader and preview it using your 3d card and then drop down to software rendering. Watch as a smoothly-animated complex shader suddenly grinds to a halt, often taking literally seconds to render a single frame. It's not a pretty sight.

      In the future with CPUs getting more and more cores and graphics programming getting more generic to support different algorithms without needing to work against the silicon's basic design it's likely we'll see them being more suitable to the rendering task as the article covers but for now trying to substitute the CPU for the GPU would be like entering a bulldozer into a Formula 1 race on the basis that it has a large engine.

      --
      404 Not Found: No such file or resource as '.sig'
    22. Re:For once ... by crhylove · · Score: 4, Funny

      Your mom's basement sounds WAY more fun than mine.

      --
      I hold very few opinions. I hold information based on observation and fact. If you wish to disagree, please use facts.
    23. Re:For once ... by Molt · · Score: 2, Insightful

      Since this is the developer who wrote the Unreal 3d engine, which is one of the best in the world at the moment, you'll have to excuse me if I think he knows a little bit about graphics APIs.

      Both DirectX and OpenGL are entirely dedicated to the "Here is a triangle-based polygon mesh, some textures, and a few shaders- go draw me a pretty picture won't you?". This is a good approach to a lot of general 3d work but it is not the alpha and omega of 3d rendering.

      As a couple of examples it doesn't have good support for voxel-based volumatic rendering which is perfect for cloudy scenes and also could give better support for fractally-defined terrains, it also doesn't support any rendering method which actually uses the equations of curves to render them properly as opposed to turning them into a series of small triangles. Many of these can be shoe-horned into the existing APIs, but when you do so you find you're actually going round the API much of the time and so losing any advantage they give you. There are a number of other examples of rendering methods which won't fit into the existing APIs in the article.

      If the article is right and this did come about then there probably would be a series of APIs coming out for the different methods of 3d rendering. Those such as the article's author who're writing the graphic engines for the AAA games almost certainly won't be using them though- they'll be still be hand-crafting their own APIs specific and optimised for the current engine's features and now they'll be building them on top of very low-level graphics APIs with limited features like setting screen resolution and drawing a single pixel as opposed to the polygon-mesh with shaders level of complex APIs today.

      --
      404 Not Found: No such file or resource as '.sig'
    24. Re:For once ... by Antitorgo · · Score: 2, Interesting

      Umm... what? Why the namecalling?

      There's CUDA and FireStream which are programming the shaders w/o going through DirectX/OpenGL.

      As far as D3D11 -- I think the only support there which is similar is the compute shaders which I'm unsure if it will apply. There's also the Apple OpenCL initiative which aims to accomplish a similar thing. AFAIK, none of the GPGPU bare-to-the metal APIs allow you to render to a texture so I think it might not be possible to accomplish a pure Stream based rendering engine (yet).

      In any case, I think his original point stands -- that the monolithic SGI based APIs are going to still be used (OpenGL/DirectX), but the hardware under the covers will be more exposed to allow programmers to be more creative with how they want to utilize the highly parallel processing that the new chips provide. Thus allowing programmers to do things in software that were previously done with dedicated hardware.

    25. Re:For once ... by ceoyoyo · · Score: 2, Interesting

      In embedded system-on-a-chip stuff you're talking about putting a few components on a chip. The feature count is WAY smaller than a CPU (or a GPU). That can be done fairly cost effectively because the CPU makers have already led the way. Even then, many system-on-a-chip products are really system-in-a-package, where different bits of silicon are put together inside a single package. Here's a conference paper that talks about it: http://www.acreo.se/upload/Publications/Proceedings/OE00/00-COLLANDER.pdf

      Merging a modern CPU/GPU is a whole different ball game. The various bits of the CPU has been integrated because that's the only way we could keep making them faster. The parts that are actually on the same piece of silicon with the CPU are there because they need high bandwidth to the CPU. The GPU does not, at present.

      Why do we have 8 processor computers made up of two quad core chips? Because it's not yet practical to put 8 cores on one chip. We will, but we don't now. CPUs and GPUs might merge, but they'll be low power, slower versions of both. Nvidia and AMD won't be putting their latest and greatest GPU on a chip with the fastest processor out there.

    26. Re:For once ... by ceoyoyo · · Score: 2, Interesting

      Why wasn't the FPU integrated with the CPU right away? Because it didn't make sense. Then, as clock rates went up, the FPU had to be integrated to keep up.

      The GPU and the CPU don't talk to each other that way. The GPU needs MEMORY bandwidth. It doesn't really care what's in the CPU registers.

      I don't think this guy ever says that the GPU and CPU are going to merge. What he does think is that the GPU is going to go away, to be replaced by a general purpose vector/stream/dsp type processor. When or if that happens, THAT kind of coprocessor would probably be worth integrating into the CPU. In fact, it's already been done with Cell.

      But a GPU? There's no reason to integrate a high power GPU with a high power CPU, and lots of reasons not to.

    27. Re:For once ... by LordKazan · · Score: 2, Interesting

      GPUs are also very expensive to make due to their large die size.

      In fact die size may be the single biggest thing that SHOULD prevent the combination of the GPU and CPU. As the mm^2 of the die grows, the cost grows even faster.

      In fact the biggest differences (other than a few tweaks to correct errors) between the disaster Radeon HD2k series and the vastly superior Radeon HD3k series was a die shrink - they're all R600 series units. It went from a total bomb (HD2k series) to a very competative card - the die shrink increased yields, decreased cost per unit, decreased voltage required and heat output. The HD2900 was 420mm^2 while the HD3800 was 192mm^2.

      Simply shrinking from 80nm to 55nm turned an non-profitable card into a profitable one. Their new flagship product - the HD4870 based on the R700 core is also 55nm but has 50% more transistors than the HD3800. The differences in the core architecture resulted in more than 2x the performance for only a 50% increase in transistors. Saving their butts from the disaster that was the 80nm R600 by shrinking the R600 to 55nm gave them the time to develop the R700 without being buried by their competition.

      If die size is that important and can be THAT expensive I doubt die size issues will EVER allow them to combine the CPU and GPU.

      --
      If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
  2. Wrong summary by Anonymous Coward · · Score: 5, Informative

    He talks about the impending fall of the fixed function GPU.

  3. I hope not! by jhfry · · Score: 5, Interesting

    I just browsed the article and it looks like what he's saying is that as GPU's become more like highly parallel cpu's we will begin to see API's go away in favor of writing compiled code for the GPU itself. For example, if I want to generate an explosion, I could write some native GPU code for the explosion, and let the GPU execute this program directly... rather than being limited to the API's capabilities.

    So essentially, we will go back to game developers needing to make hardware specific hacks for their games... some games having better support for some cards, etc.

    API's are there for a reason... lets keep em and just make them better.

    --
    Sometimes the best solution is to stop wasting time looking for an easy solution.
    1. Re:I hope not! by MarkvW · · Score: 4, Interesting

      I read it differently than you did. He's projecting a world where everything is standardized and faster (less 'bus plumbing' GPUs). In such a world you won't need APIs because you'll have libraries that you can include in the compile process.

      APIs reduce code bulk at the cost of reduced code speed, don't they?

    2. Re:I hope not! by Emperor+Zombie · · Score: 2, Insightful
      Actually, he's saying the opposite:

      TS: I expect that in the next generation we'll write 100 percent of our rendering code in a real programming language-not DirectX, not OpenGL, but a language like C++ or CUDA. A real programming language unconstrained by weird API restrictions. Whether that runs on NVIDIA hardware, Intel hardware or ATI hardware is really an independent question. You could potentially run it on any hardware that's capable of running general-purpose code efficiently.

      --
      I'm so excited I just made water in my pantaloons!
    3. Re:I hope not! by Anonymous Coward · · Score: 5, Informative

      In such a world you won't need APIs because you'll have libraries that you can include in the compile process.

      A library you include in the compile process is an implementation of an API.

      APIs reduce code bulk at the cost of reduced code speed, don't they?

      No.

    4. Re:I hope not! by GleeBot · · Score: 4, Insightful

      I read it differently than you did. He's projecting a world where everything is standardized and faster (less 'bus plumbing' GPUs). In such a world you won't need APIs because you'll have libraries that you can include in the compile process.

      No, you won't need APIs because you'll have a standard instruction set. Current graphics APIs are oriented around things like pushing triangles and running shaders on them. Why bother with the complexity of the graphics APIs, if you can create a standardized instruction set for GPUs?

      We essentially already have that, but it's wrapped in the paradigm of shader programming. Stop treating the GPU as a graphics processor, and as just this really parallel coprocessor, and you get what Sweeney is talking about.

      The basic point is that GPUs aren't really for graphics anymore, and as we move away from a graphics fixation, we'll come to realize that they're just specialized computers. Using graphics APIs to program them would be as stupid as using OpenGL to write a word processor. Sure, with modern capabilities, it's actually possible, but it's a bad conceptual fit.

    5. Re:I hope not! by jd · · Score: 2, Informative

      At the deep RISC level, they probably wouldn't be. In fact, they'd certainly not be, or you'd simply have an SMP cluster with some emulation on top. If you're going for the migrating code, you'd need binary compatibility at the emulated mode (think Transmeta or IBM's DAISY project) but the underlying specialization would give you the improvement over a homogeneous cluster. If you're going for the totally heterogeneous design - basically the Cell approach but on a far, far larger scale - you need endian compatibility and bus protocol compatibility but nothing more.

      This Cell-like approach gives the greatest room for innovation but also imposes the greatest development costs and greatest purchase costs. It also makes ABI backwards compatibility extremely hard or impossible, so you'd end up with a proliferation of builds of the same code for any binary packages (including all closed-source) and a far more complex build and optimization process for all source packages (gentoo users beware). It also makes bus design far more complex, as the more specialized the decentralized processor units (DPUs) get, the more synchronization headaches you will get.

      A DPU cluster should logically give the best performance, for the same reason pure RISC outperforms pure CISC - fewer overheads, tighter logic and also (in consequence) more real-estate for optimizations, parallelizations, cache and other goodies. Distances would be greater between processing units, which will have an impact, but so long as the mean gain across the DPUs exceeded the mean loss due to extra distance and extra communication layers, you'd gain overall. This means a DPU computer cannot be flat beyond a certain scale. As SMP clusters cannot exceed 16 processors due to locking issues with shared resources, DPU computers cannot exceed 16 DPUs for a single resource and would probably avoid sharing resources if at all physically possible. This means a DPU computer must be heavy on duplicate resources. But for duplication to beat the deadlocking issue, bus bandwidth needs to be extremely high and bus latency needs to be almost non-existent.

      Cell processors are much too basic to run into these sorts of problems, but if you wanted to scale the concept up by, oh, an order of magnitude and beat the design limitations in the Cell processor, you'd need to be spending serious time and money. I expect further "specialist" *PUs to be developed for some time, but the truly RISC, truly distributed DPU is unlikely to exist outside of theory or maybe a research lab or two for at least a decade and I don't expect DPU home machines for at least 30+ years.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  4. Software rendering on the GPU by KalvinB · · Score: 4, Insightful

    Somehow I don't think there's going to be lack of a standardized API much like OpenGL or DirectX even if it's possible to write code for the GPU as easily as the CPU.

    The APIs at the most basic level allow Joe and Bob to build their own system, throw whatever graphics card they can find in it and have the same game run on both systems.

    As soon as you start coding for a specific GPU you're going to be treating PCs like consoles. I don't care to have to buy multiple graphics cards to play various games.

    APIs are for compatibility and general purpose use. The option of flexibility is great for industry use where you're running rendering farms all running identical hardware and custom software.

    --
    Work Safe Porn
    1. Re:Software rendering on the GPU by Pedrito · · Score: 3, Interesting

      As soon as you start coding for a specific GPU you're going to be treating PCs like consoles. I don't care to have to buy multiple graphics cards to play various games.

      I got the impression that they're expecting C++ compilers for all the GPUs, eventually, so then they'd simply have rendering libraries for each GPU. I also got the impression that they'd be waiting until most gamers had one of the compatible GPUs. Let's face it, most gamers usually don't buy the cheapest graphics card and now the two major players, ATI and nVidia have GPUs that are easily accessible. It won't be too long until you can't buy a video card from them that doesn't support CUDA and whatever the ATI equivalent is.

      I think it's a pretty safe gamble for video game developers, certainly the 1st Person 3D game developers.

    2. Re:Software rendering on the GPU by Hortensia+Patel · · Score: 4, Insightful

      You're missing the point entirely. GPUs in the near future will essentially be general-purpose massively-multicore processors. (Not entirely so, but close enough for "GPU" to become a misnomer.)

      You don't need separate binaries for Intel versus AMD processors, and you don't have to write to an API to achieve portability between such different CPUs. Given sufficiently general hardware, there's no inherent reason why GPUs should be any different. There will still be a place for libraries, but their role will be more like C libraries than like GL/DX.

  5. Re:Obvious by jacquesm · · Score: 3, Informative

    gpu's aren't really parallel in that sense, they are parallel in the SIMD sense.

    --
    MP3 Search Engine
  6. New market opportunity for render engines? by compumike · · Score: 2, Interesting

    For the last decade or so, it seems like the rendering side was abstracted away into either DirectX or OpenGL, but if the author is correct, those abstractions are no longer going to be a requirement.

    While I don't know a lot more about the various other rendering techniques that the article mentions, it seems like there might be an opportunity emerging to develop those engines and license them to the game companies.

    I suspect that game companies won't want to get into the graphics rendering engine design field themselves, but there's real possibility for a whole new set of companies to emerge to compete in providing new frameworks for 3D graphics.

    --
    Hey code monkey... learn electronics! Powerful microcontroller kits for the digital generation.

    1. Re:New market opportunity for render engines? by mikael · · Score: 3, Insightful

      Before the advent of 3D accelerators, game companies wrote their own low-level renderers. These did the vertex transformation, lighting, clipping and texture-mapped triangle and line rasterization (some companies even explored the use of ellipsoids). Wolfenstein 3D, Quake and Descent as examples.

      The low-level graphics rendering part is a very small part of the game engine - rasterizing a textured primitive with some clipping, Z-buffering and alpha blending. But getting this as fast as possible requires a good deal of profiling and analysis to get it as optimized as possible (Brian Hook did a software version of OpenGL for SGI).

      3D chip makers gradually took over this area by designing hardware that could do this task far faster than the CPU. First they took over the rasterizing part (3Dfx piggyback boards), then took over the vertex transformation, lighting and clipping through the use of high performance parallel processing hardware (Nvidia TNT). There are other optimisations such as deferred rendering which optimise the order of rendering primitives to save on framebuffer writing.

      Initially, all stages of the pipeline were fixed functionality, but this was replaced by programmable vertex transformation (vertex programs in assembler, then vertex shaders in a shading language) needed for matrix-blending in character animation. Fixed functionality for pixel processing was replaced by register combiners (for baked shadows), then by fragment programs and fragment shaders. Geometry shaders were also introduced to handle deformation effects.
      There are also feedback features where the output of the rendering can be made to a texture, and thus used as an input texture for the next frame.

      All the latest DirectX and OpenGL extensions relate to setting up the geometry/vertex/fragment shaders for this functionality.

      That is what Intel and software renderers have to compete against. They would be to implement a set of 3D CPU instructions that allow textured triangles, line and points to be rendered with fully programmable shaders from one block of memory to another (specified by pixel format, width, height, etc...). They could use the memory cache for this purpose, but would have to replace the FPU with hundreds of DSPs to achieve this. Otherwise they would have to provide free access to the framebuffer with hundreds of threads or cores.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
  7. you wish by heroine · · Score: 3, Insightful

    GPUs are going to be driven by the same things that drive game consoles & set top boxes. You can copy pure software, but you can't copy dedicated chips. You can copy video rendered by a CPU but not video rendered on a dedicated chip. Dedicated chips are going to stay cheaper than CPUs for many years. Just because you can decode HDTV in software doesn't mean there still isn't huge momentum behind set top boxes and DTCP enabled GPU's.

  8. abolish standards based programming? Never by heroine · · Score: 3, Insightful

    Standards based programming isn't going anywhere. That's crazy. We need Direct X, OpenGL, JMF, & MHP if only to outsource large chunks of the programming to cheaper divisions. How great it would be if everyone could base their career on hand optimizing ray tracing algorithms for SSE V, but the economy would never support it. These things have to be outsourced to select groups, firewalled behind a standard & higher paid programming done to the standard.

  9. Um, says who? I don't see it at all by spoco2 · · Score: 3, Insightful

    I just don't get how they can be saying this at all.

    Ok... so from the article we have:

    Take a 1999 interview with Gamespy, for instance, in which he lays out the future timeline for the development of 3D game rendering that has turned out to be remarkably prescient in hindsight:

            2006-7: CPU's become so fast and powerful that 3D hardware will be only marginally beneficial for rendering, relative to the limits of the human visual system, therefore 3D chips will likely be deemed a waste of silicon (and more expensive bus plumbing), so the world will transition back to software-driven rendering. And, at this point, there will be a new renaissance in non-traditional architectures such as voxel rendering and REYES-style microfacets, enabled by the generality of CPU's driving the rendering process. If this is a case, then the 3D hardware revolution sparked by 3dfx in 1997 will prove to only be a 10-year hiatus from the natural evolution of CPU-driven rendering.

    Which they say is remarkably true.

    HUH?

    So, all these new GPUs really don't speed up your machine? So I can take my nvidia 8800 OUT of my box, leave it to an onboard graphics chipset and I'll be getting the same performance will I?

    Yeah.

    Right.

    I don't see AT ALL how they're getting this right?

    Please someone enlighten me, as I'm not seeing it from where I'm sitting.

    1. Re:Um, says who? I don't see it at all by Antitorgo · · Score: 2, Insightful

      It says it right there in the article.

      Current generation GPUs are to the point where you can basically run arbitrary code on the GPU (as shaders) in high vectorizable code. So instead of the monolithic APIs such as OpenGL/DirectX, we'll see custom rendering engines that take advantage of the parallel cores running in GPUs and future CPUs (if Intel has their way).

      So in a sense, he was correct. If you take CPUs in his 1999 interview to mean current GPU processors. Which is becoming somewhat of a misnomer nowadays with the CUDA/Firestream SDKs out now.

      In the end, his point is that OpenGL/DirectX will probably go away in favor of custom rendering engines based on other techniques that will, in the long run, result in much better/different rendering techniques. (Ex: Voxel based rendering, Real-time ray tracing etc).

    2. Re:Um, says who? I don't see it at all by GameMaster · · Score: 4, Insightful

      And, I would argue that even that part of his statement is absurd. Most game developers don't even want to have to write their own game engines much less do it from scratch. Even the ones that do write engines (id, Epic, etc.) will, for the most part, never give up their graphics APIs. APIs don't just give programmers access to specialized hardware, they also provide the developer with a raft of low level tools that he/she has no, reasonable, justification or wanting to spend the time re-developing. What will happen, is that APIs like Direct3D and OpenGL will change (as they have been all along) and simplify, as they won't have to handle all the quirky hardware anymore. The idea that engine writers will completely throw out APIs and will go back to writing everything from scratch in C/C++ is almost as absurd as suggesting that they'll go back to writing everything in Assembly language.

      --

      Rules of Conduct:
      #1 - The DM is always right.
      #2 - If the DM is wrong, see rule #1
    3. Re:Um, says who? I don't see it at all by Antitorgo · · Score: 3, Insightful

      Actually, I think he says in the article that you'd see APIs like Direct3D and OpenGL staying around and leveraging the CUDA/FireStream APIs instead of relying on hardware specific features (at least, that is what is already happening at the driver level).

      I think he envisions that new engines/APIs will come about (such as those that could be Voxel based or based on Ray Shaders, etc.) once the CUDA/FireStream APIs become more mature and the hardware gets faster.

      Also, by breaking out of the hardware specific implementations of the SGI-based implementations (OpenGL/Direct3D) it would provide more flexibility for programmers to insert their own customizations into the rendering pipeline. With the hardware designed around one specific rendering design, programmers were limited. With the evolution of GPUs turning into highly parallel GPGPUs and CPUs turning into 80+ core beasts, it opens a whole realm of possibilities.

    4. Re:Um, says who? I don't see it at all by FuturePastNow · · Score: 2, Insightful

      But integrated graphics aren't about gaming. They're about driving a desktop display with minimal power, heat, and cost. Believe it or not, those three things are actually pluses for non-gamers.

      So no shit, a Geforce 6600 (which is what, three years old?) outperforms Intel GMA. No one at Intel cares.

      --
      Give a man fire, and you warm him for the night. Set a man on fire, and you warm him for the rest of his life.
    5. Re:Um, says who? I don't see it at all by jjohnson · · Score: 2, Insightful

      Part of Sweeney's point that you're missing is that programmers are already writing raw shader code for DX10, and making more general use of CUDA. But more than that, DX and OpenGL are APIs to a particular model of 3D rendering that was, ten years ago, a good match to the benefits of the 3D hardware presented. Now that the GPU is a general purpose processor, the triangles pipeline model for renderers need no longer limit programmers, and they can implement different engine models (like Voxels) because it's all being done in software on a general purpose chip, whether that chip is called a CPU or a GPU.

      --
      Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
  10. If we are going back to the "old" days... by Brynath · · Score: 5, Interesting

    If we are going back to the "old" days...

    Why can't we skip all this OS nonsense, and just boot the game directly?

    After all that will make sure that you get the MOST out of your computer.

  11. Re:For once Ivan Sutherland Wheel of Re-invention by elwinc · · Score: 4, Interesting

    See Ivan Sutherland's Wheel of Reincarnation. The idea is that CPUs get faster and graphics move there; then busses get faster and graphics moves to dedicated hardware; rinse and repeat. http://www.anvari.org/fortune/Miscellaneous_Collections/56341_cycle-of-reincarnation-coined-by-ivan-sutherland-ca.html

    --
    --- Often in error; never in doubt!
  12. Re:Poor title by David+Greene · · Score: 3, Interesting

    I think the point of the article is that computing paradigms are merging. You won't have a CPU and a GPU. You'll have one thing that looks like both. In other words, you'll have a multicore, parallel, vector machine.

    And that, absolutely, positively, will happen. Larrabee, or something like it, is the future. If you hold AMD stock, sell now, because Fusion doesn't sound anything like Larrabee and is going to seem positively draconian by the time it comes out.

    In some ways, these new processors will look like a Cray YMP on your desktop. It's a rough analogy but suitable for illustration. Of course there are all sorts of differences in the way the memory systems will work and that's a huge part of the performance equation.

    It seems to me that Tim puts a bit too much faith in compilers. He talks about language extensions but only in CUDA-like terms of "where things will run." A compiler needs a lot of information to be able to vectorize. The user often has to provide that information in a language like C because of its loose typing, aliasing and side-effect rules.

    My prediction is that some APIs will go away, but many of the low-level ones will stay because it's often faster to call into a hand-coded library than rely on the compiler to have enough information to automatically optimize the code. Eventually compilers will start pattern-matching to these APIs. Higher-level APIs will be developed to save developer time, not CPU time. They will exist almost purely for code reuse purposes.

    I disagree with Tim that hardware vendors will differentiate on performance. At least, in the way he's thinking. It won't be hardware gadgets, vector length or number of pipes that matter. It's going to be the compiler, programming environment and libraries. To the extent that the hardware supports those in its ISA, hardware will matter. But the bulk of the muscles of the chip won't matter so much as their placement and utility (by the compiler). The inflection point is leading to a world where software is king.

    --

  13. Er, no by Renraku · · Score: 2, Interesting

    I disagree.

    Direct hardware programming has always been the best in terms of performance. However, it is the worst in terms of compatibility. If you're programming consoles, this is just fine. If you're programming for PCs, not so much.

    It will never go back to programming for specific pieces of graphical hardware. I'd say that each vendor MIGHT make a major chipset, and that those chipsets would be coded for, and everything else gets API'd, but even this is unlikely. If a company had to have two or three sets of programmers for their graphics, each team for a different major chipset, we'd see more expensive games or prettier games with crappier gameplay.

    Even the OpenGL/DirectX split takes a heavy toll on programming resources for game developers.

    --
    Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
    1. Re:Er, no by Narishma · · Score: 2, Insightful

      You missed the point entirely. You don't write different code depending on whether the CPU is from AMD or Intel. In the same way, you won't be writing different code depending on whether the processor (CPU or GPU) is from AMD or Intel or nVidia. You will be writing in a high level language like C++ and it will be compiled to run on the CPU/GPU, not unlike CUDA. So you won't need API's like OpenGL or DirectX anymore.

      --
      Mada mada dane.
  14. Re:Tim sweeny said the same thing 10 years or so.. by blahplusplus · · Score: 3, Interesting

    "Not sure why Tim Sweeney gets so much flack, he is the lead developer for a pretty popular 3d rendering engine..."

    Just because he's a good programmer doesn't mean his statements about other things will be true, each statement must be taken individually.

    Tim sweeney said 10 years or so ago the GPU would be integrated into the CPU, it hasn't happened.

    Not only that the bandwidth requirements are off the charts for modern GPU computing. Sometimes I wonder if these programmers are even aware of wtf it is they are saying. I know lots of programmers who know dick all about the relationships in hardware. Tim sweeney borders on being one of those types of programmers. It's like he's so focused on development he's not seeing the forest from the tree's.

    Also game engine's are many man projects, tim sweeny would be just one single dude on a team, nothing notable IMHO.

  15. Poor Intel by Ostracus · · Score: 2, Funny

    "It seems to me that Tim puts a bit too much faith in compilers."

    Itanium

    --
    Shai Schticks:"You don't make peace with friends, you make peace with enemies"
  16. Re:Obvious by Hortensia+Patel · · Score: 5, Informative

    gpu's aren't really parallel in that [traditional multithreaded] sense, they are parallel in the SIMD sense.

    Actually, they're somewhere in between. Some current hardware can reallocate individual processors between fragment and vertex processing depending on the current workload profile. Even at the level of an individual processor lots of "threads" may be running simultaneously; this is to hide latency when a shader program blocks on memory (texture or framebuffer) access.

    If you look at NV's descriptions of their 8xx-series drivers, they talk about *hundreds* of threads in flight at any given time. These aren't threads in the classical sense - there's no preemption, for a start - but they're much, much more advanced than SIMD-style "apply this instruction to all these values" parallelism.

  17. Re:Tim sweeny said the same thing 10 years or so.. by blahplusplus · · Score: 4, Interesting

    "Take a 1999 interview with Gamespy, for instance, in which he lays out the future timeline for the development of 3D game rendering that has turned out to be remarkably prescient in hindsight:

    2006-7: CPU's become so fast and powerful that 3D hardware will be only marginally beneficial for rendering, relative to the limits of the human visual system, therefore 3D chips will likely be deemed a waste of silicon (and more expensive bus plumbing), so the world will transition back to software-driven rendering."

    Nuff said.

  18. You are quite wrong by Anonymous Coward · · Score: 3, Informative

    You are very, very wrong. The history of computer hardware has been one where extra functionality is moved from the cpu for speed, folded back in a few years later for efficiency, and farmed out to an add-on card for speed some time later...

    See http://catb.org/jargon/html/W/wheel-of-reincarnation.html for details.

    1. Re:You are quite wrong by sricetx · · Score: 2, Informative

      The last PC I had that had a slot for external cache was a 486. This was around 1994, and even then COAST modules http://en.wikipedia.org/wiki/Cache_on_a_stick were a little difficult to find -- It's not like you could just walk in to the local Futureshop and pick one up.

      It will be good riddance to video cards if that functionality moves to the CPU as far as I'm concerned. Especially if Intel and AMD continue with their recent trend of developing open drivers for their chips. Unlike other companies in the market, who only release binary blob drivers and deny serious problems with their current generation of laptop graphics chips http://www.theinquirer.net/gb/inquirer/news/2008/07/09/nvidia-g84-g86-bad.

    2. Re:You are quite wrong by Goaway · · Score: 2, Informative

      and what would be an example for this?

      How about, say, specialized graphics hardware being implemented in separate chips for home computers, and then later being discarded in favor of using faster CPUs to do the rendering instead?

      Like what happened in the 80s and 90s.

  19. As Good as it Gets by Sponge+Bath · · Score: 4, Funny

    ...a C compiler, a blank text editor, and a stifling array of possibilities

    Assuming he means Emacs, then this is the way God intended it to be.

  20. Re:Tim sweeny said the same thing 10 years or so.. by blahplusplus · · Score: 4, Interesting

    "Ok so you state that memory bandwidth requirements for GPUs are off the charts. Where do you propose to get more memory bandwidth than on the CPU itself? Seems to me if you want memory bandwidth there is no better place to be than on the cpu die..."

    Again you're missing the point, "the jack of all trades, master of none" problem, not to mention the space requirements. GPU's complexity is nothing like the old style co-processor units that were integrated into the core. They require ridiculous amounts of cutting edge ram to get that kind of performance, and they need a lot of ram to output the results of those calculations.

    I don't see CPU's integrating 512MB to 2GB of ram in the near term future given heat and die size considerations, and we haven't even touched the extremely low bandwidth between modern cpu's and main memory in PC's (which is much much less then a modern GPU).

    The GPU will play it's part for as long as is necessary. I don't rule out that perhaps one day it will be technically feasable but it is nowhere near that day, it's at least a decade or more away.

    We've seen this time and time again, processors go through evolutions of integrating and seperating. We went from mainframes to PC's and with the net 'back to mainframes' but notice how each device play's their role, each one didn't totally obsolete the other, they just have become more specialized at their tasks.

  21. Re:Hello world without OpenGL or DirectX? by Narishma · · Score: 2, Insightful

    Then why aren't commercial games already distributed as C++ source code so that they can be recompiled for AMD or Intel CPUs?

    This doesn't make any sense. I didn't say they would release the source code. Only that they would write directly to the CPU/GPU, without using API's like OpenGL, just like they currently do for everything that is not graphics rendering.

    Then what will computer graphics programming students use to write a demo of rotating Platonic polyhedra textured with "Hello World"?

    The same things they used before OpenGL/DirectX became prevalent. The same things they used during the DOS era.

    --
    Mada mada dane.
  22. What architecture? by tepples · · Score: 2, Interesting

    Developers will use [future coprocessor cards] just like they use CPU's at the moment.

    Which means they'll have to both be x86, or both be ARM, or both be some other architecture that NV and ATI can agree on. goodluckwiththat.

  23. Mr. Carmack are you still around? by icedcool · · Score: 2, Interesting

    I want to hear what John Carmack thinks about this.
    Does he agree/disagree and why?

    I always like seeing two giants in the industry debate on high level topics. It gives some insight into trends... and I just plain dig gaming anyway...

    --
    Most people aren't thought about after they're gone. "I wonder where Rob got the plutonium" is better than most get.
  24. What about audio? by serodores · · Score: 2, Insightful

    How long has audio been around? Have you ever seen an audio chip integrated into the CPU? Most of them are done by onboard chips, not on the CPU.

    1. Re:What about audio? by vux984 · · Score: 2, Informative

      How long has audio been around? Have you ever seen an audio chip integrated into the CPU? Most of them are done by onboard chips, not on the CPU.

      They've moved from being standalone cards to being predominantly integrated into the mainboard and using the cpu for processing... rather like HSP modems, really.

  25. Imagine That by nick_davison · · Score: 3, Interesting

    In other news...

    A man whose company makes its money writing game engines says, "APIs are going to go away. It's going to be very, very hard to build a game engine in the future when you can't rely on the APIs anymore. So everyone'll have to switch to the few companies that build game engines instead. Like mine. I recommend you start now and save yourself the headache."

    Hmm, I detect no bias whatsoever.

    Well, almost as little as when nVidia tells the world that they have seen the future and it's in GPGPUs replacing CPUs. Amazing how everyone has seen the future, it supports their business model and the rest of us can save ourselves a lot of pain if we jump on what pays them well.

  26. Special vector unit? by marcovje · · Score: 2, Interesting

    Call me stupid, but from what I saw from Larrabee it centers around a new specialized very wide vector unit to do most of the work. So far for a any plain old C compiler

  27. Tim Sweeney has vested interest for this by jokkebk · · Score: 4, Insightful

    It's also interesting to note that the guy being interviewed is in the business of making 3D engines.

    Now ask the question: would 3D engine makers perhaps have something to gain if OpenGL and DirectX would be scrapped, as the interview suggests?

    Most game dev labs wouldn't have the resources to build their own engines from the scratch using a C++ compiler, making them to - wait for it - licence a 3D engine like the one this guy is selling.

    So in summary, the article paints a picture from the future which would be very beneficial to interviewee, so I'd take it with a grain of salt. Either we'd get some de facto 3D engines replacing OpenGL and DirectX, or the game developers will waste time recreating each new graphics technology advancement into their own engines.

    --
    http://codeandlife.com