Slashdot Mirror
Twilight of the GPU — an Interview With Tim Sweeney
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."
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
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.
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.
I just don't get how they can be saying this at all.
Ok... so from the article we have:
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.
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!"
Man, you've got some awful, awful arguments here.
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.
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.
See question 1.
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.
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.)
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.
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.
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
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);
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.
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
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).