Skip to main content
added 261 characters in body
Source Link
Ricket
  • 14.9k
  • 6
  • 68
  • 82

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.

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.

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.

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.

added 900 characters in body
Source Link
Ricket
  • 14.9k
  • 6
  • 68
  • 82

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.

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.

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.

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

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.

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.

Source Link
Ricket
  • 14.9k
  • 6
  • 68
  • 82

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.

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