6
\$\begingroup\$

Since the early days of accelerated graphics, programmers were obligated to use hardware-supported libraries like directX or OpenGL.

If we wanted to explain someone what happened by introducing a graphic chip, the simple thing to say is "we just copy the 3D data into a new memory, where another processor will take care of it, because this one processor is just faster at it".

During this period, the processors have never ceased to evolve in term of speed and power. Today with the upcoming of multiple core processors, x86 is still there, graphic card get more power, and are now taking the role of a CPU with tools like OpenCL and CUDA.

Back in the year, the AGP port speed was quite important, and PCI-express gave another big boost.

I didn't heard a lot about AMD Fusion, but the idea might have come into the mind of any computer engineer: Since the heavy calculations made in a computer are either graphical or not, we separate them into 2 dedicated chips.

But nowadays, any computer power is needed for both, especially in 3D games: to put it simply, at the beginning computer were just dealing with text, but today they all deal with at least 2d graphics, so why not design one chip that would take the role of both a CPU and a GPU ? Instead of having two memory block and having to copy all the textures and models into the graphic memory when a game loads, the "CGPU" would have some GDDR3, instead of having two separate memories, again cutting costs.

I still wonder how this AMD fusion will have to be used from a programmer viewpoint, but I wonder that the graphic library would be somewhat easier to deal with that directX or OpenGL, since we would program just one processor.

Is it right to think that this kind of dedicated hardware would also potentially just be faster for 3D games ?

Pro: Single memory, no more AGP transfers, simple for the 3D programmer, cheaper to build. Cons: Complicated to come with such hardware, long and expensive research because of both new hardware AND software standards.

What are you thinking ? Is it a new incoming step for computers, or just scifi ?

EDIT: Since I got an appropriate answerm I leave the question as I wrote it, I just add something to it:

Since all computers, and especially consoles, require graphics acceleration, and since it requires a lot of transistor, and with the upcoming of tools like CUDA and OpenCL, why no industrial has yet come with a "gaming chip", some sort of processor with an integrated graphic card, but nothing like a low-end chip; something more like an all-in-one processor unit, with the GPU and the CPU on the same die, but still clearly separated ?

Since the playstation 3 has dedicated chips and since games requires that extra power desktops or servers don't, can it reduce costs and give a little boost ?

\$\endgroup\$
1
  • \$\begingroup\$ There used to be a time when FPU and ALU is separated into a dedicated chip; it shouldn't be too long now for GPU to merge back into CPU. Also, here is a good article about why we often choose to put features into their own chips: arstechnica.com/hardware/news/2008/09/moore.ars the short version is that due to imperfection in the silicons, it's sometimes cheaper to manufacture into separate chips to mitigate risks. \$\endgroup\$ Commented Sep 10, 2011 at 2:01

2 Answers 2

Reset to default
7
\$\begingroup\$

Since the heavy calculations made in a computer are either graphical or not, we separate them into 2 dedicated chips.

It's not really because they're graphical or not, it's that there are 2 distinct types of computation, which I shall term 'branching', being heavy on choices, loops, and conditionals, and 'linear' which has few or no conditionals and is a long line of predictable instructions.

Typical computer operation is 'branching', and consists of algorithms require lots of "if this, do that, otherwise do something else". This means a lot of jumping around in different parts of the code based on what data you have. This makes it hard to optimise the hardware since you have to wait until one instruction has finished to know which instruction to handle next.

By contrast, computer graphics are one example of 'linear' code. You have a long block of data and you do exactly the same thing to each piece. Transform each vertex into the new coordinate system, iterate between the vertices for each pixel, perform a predictable number of lighting steps to render each pixel. This procedure is so straightforward by comparison that you know exactly which operations you'll need and in which order, so you can hard-wire that into your hardware. Each piece of data can be processed by one instruction and automatically shunted to the next instruction, while the next piece of data is being shunted in. This means you can have massive amounts of data being processed in parallel, one piece per instruction, whereas a traditional algorithm is performing just 1 instruction at any one time.

Before anybody jumps on me, this is of course a simplification - these days the two types of processing have converged significantly. But, the fundamental fact remains that hardware that supports complex branching code is necessarily slower than hardware that primarily or exclusively supports linear code.

so why not design one chip that would take the role of both a CPU and a GPU ?

Hopefully the above has explained why a dual-purpose processor is not the optimal route, in terms of performance.

Instead of having two memory block and having to copy all the textures and models into the graphic memory when a game loads

You are assuming this separate memory is a performance hit. In fact, it's a performance gain. The memory on your video card is essentially a very large high speed cache which allows the GPU to get very quick access to it. Not only that, but it doesn't have to compete with the CPU over that access. If it had to use main memory all the time, you'd not have that initial cost of uploading but every access would be slower, and it would have to be carefully coordinated with the rest of the system to ensure it isn't reading memory that another process is trying to write.

What are you thinking ? Is it a new incoming step for computers, or just scifi ?

In future, when computers are so fast that top graphics are not a significant performance problem, it may well be better to have it all on one chip, for ease of development. Until then, I think we're going to be sticking with the different approaches, except for low end systems.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Your last paragraph sums it very well thank you ! I also read that kind of allusion from an interview I can't exactly remember. To say it simply, we need graphic acceleration, just because graphics need a lot of computationnal power. And since most operations in graphics can be simplified because they are linear, unlike unpredictable algorithms, we build special chips ! \$\endgroup\$ Commented Sep 16, 2010 at 11:07
7
\$\begingroup\$

AMD Fusion is the next logical step in onboard graphics; the first step was of course "why don't we take the video card, and stamp it onto the motherboard instead!" - of course, greatly reducing the power in the process. Now they're thinking "why don't we take that onboard graphics chip, and built it into the processor". It will be low-powered, just like onboard graphics. But at the same time, integrated graphics chips have come a long way; today's integrated graphics chips can play World of Warcraft smoothly at a decent resolution, for example. I get the feeling that discrete (video card) graphics chips will remain faster than these integrated solutions (whether motherboard integrated or CPU integrated), mainly since they can be separately cooled so there isn't as strict of a constraint on the power.

From a programming standpoint, the libraries and methods will not change. DirectX and OpenGL will still be the two standard low-level libraries.

Regardless of how the architecture is, you still need to take some 3D data and draw it to the screen. OpenGL doesn't have a "copy some data into graphics memory" operation, it has "draw this buffer" or "draw this array". The copying is all implied and handled by the library. So in your case, if the whole system memory is GDDR and no copying is necessary, then the OpenGL driver for the chip will not copy and just draw the buffer; that's perfectly fine, and it doesn't change our programming methods at all.

For a long time now there has been an abstraction layer between CPU and graphics. Long gone are the days when we, as programmers, literally copied memory from one area to another in order to see it on the screen. So now as GPU and CPU merge, we won't have to change a thing. The hardware guys can worry about the merge, and we programmers can keep on moving forward with development.

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.