AMD Fusion

It sounds like they have removed the overhead from switching back and forth between "compute" mode and normal graphics rendering mode.

They say "a pointer is a pointer" and you can pass a pointer allocated in the C++ code over to GPU code and the GPU can just dereference it directly.

These elements sound great to me, and actually make the chip interesting for me. From what I had read it was just a separate CPU and GPU on the same chip programmed separately.

Those points bring up some questions from me though. The GPU is DX11 class... Currently to use DirectX11 you have to program the CPU side of things using your chosen language like C# or C++ etc, and program the GPU side of things using HLSL in a separately compiled file. How is that compatible with being able to pass a pointer from CPU code to GPU code and dereference it directly in the GPU code? Will we be able to code the GPU using C++ or C#? That would be awesome imo.

So it sounds like this is a unified memory architecture??[/quote]

I guess it does!

What do you think about this architecture? Do you think NVIDIA will follow it?[/quote]

If the above is true then I hope it becomes the standard.

Do you think this gives the best graphics, or is it more optimized for general applications that want to easily use compute power of GPU.[/quote]

From what I've read the GPU is comparable to current GPUs for performance but the CPU is slow. I'm more than OK with that however if the above is all true. In fact if what I've surmised in this thread is correct then I may well be getting one.

Those points bring up some questions from me though. The GPU is DX11 class... Currently to use DirectX11 you have to program the CPU side of things using your chosen language like C# or C++ etc, and program the GPU side of things using HLSL in a separately compiled file. How is that compatible with being able to pass a pointer from CPU code to GPU code and dereference it directly in the GPU code? Will we be able to code the GPU using C++ or C#? That would be awesome imo.
[/quote]

I also have these questions and I am not sure how this works yet. There is a talk I haven't watched yet where they are talking about heterogeneous programming features coming soon to VC++. Maybe the dereference of a pointer on GPU will be added to next version of DirectCompute / OpenCL ?

Fusion is indeed a GPU/CPU hybrid chip which they are calling an APU; effectively you have a bunch of x86 cores and some GPU cores on the same die. They share memory interfaces which allows for a unified memory architecture but also means that there is some bandwidth issues to be overcome (iirc they will give the GPU priority over the CPU for memory access). These APUs also are designed to give 'the best graphics'; they will do a job and do it well but they are simply no match for having a card in your machine which has dedicated ram and more thermal and power overhead it can use. Don't get me wrong, APUs are cool, but I wouldn't trade in my HD5870 for one just yet ;)

The overhead for modes switches still exists simply because this is still, fundimentally, a graphics core. Nothing has changed in that respect on the GPU side of things; the big win right nows for mobile is that this performs 'well' but with a much reduced energy requirement, which means your laptops will last longer and your mainstream desktops will require less power.

(It should be noted that the current chips are NOT highend ones; Llano is mainstream at best, it isn't designed to compete with highend Intel offerings on the CPU side even if it does somewhat beat them pretty hard on the GPU side).

The architecture is good, it's something I've been looking forward to for a long time as the ability to have a nice close ALU core to the x86 cores opens up some ideas and removes the latency of drivers and GPU transport from things; for example you could have your APU running your physics via OpenCL while your GPU renders graphics. As to how well APUs go at the highend, well this depends on AMD's new x86/x64 core design in Bulldozer; if that can perform then when it gets combined into an APU next year they could be onto a winner.

Now, NV... put simply NV CAN'T produce an APU in the x86/x64 space because they don't have a license to support the tech and Intel have no intrest in selling them one it would seem. On the ARM side NV are basically doing the same thing but in the x86/x64 space it is all Intel and AMD.

Also, this is only the beginning; AMD have a new hardware design which I believe is coming out in their descrete GPUs this year which looks pretty cool and is quite a large departure from what they have done before so I'm looking forward to getting more details on that. (What I know so far is a few pictures of slides taken yesterday, which contain a lot of cool info which does need some explaining).

C++ coding IS coming to AMD GPUs and is already on NV GPUs, however as with all things using C++ features will come at a cost. It might be useful for some things but writing performance code means you won't be using virtual all over the place (Personally I'm in two minds about it; frankly most C++ programmers are hardly competent at writing code which doesn't do bad things to CPUs designed to flatter their coding ability, the thought of them getting that kind of access to the GPU makes me cry for the performance loss. On the flip side if the control goes 'lower' than DX/HLSL and OGL/OCL expose then it might well be intresting to play with it, even if it you do end up avoiding things like virtual functions, classes etc which I'm not 100% belong in what is effectively a functional paradigm.. but we'll see)

Sounds like AMD Fusion is a good step (especially the unified memory), but I'm excited for the future when there is no longer a difference between a GPU and a CPU. I want my CPU to be as good at multiple general purpose serial instruction threads as it is at SIMT-style streaming data parallelism. And I want c++ to be extended to support this architecture.

I want to write my vertex and pixel shaders in this extended c++ in the exact same way I'd write my parallel physics code.

Would this completely obviate Direct3D and OpenGL? Or would it relegate them to nothing more than an interface for writing a buffer to the screen?

You might find the Epoch language interesting ;-)

No where on that page is any of the parallel-related syntax described! If it's a core feature of the language, you should probably include some of it in the Newcomer's Guide.

C++ coding IS coming to AMD GPUs and is already on NV GPUs, however as with all things using C++ features will come at a cost. It might be useful for some things but writing performance code means you won't be using virtual all over the place (Personally I'm in two minds about it; frankly most C++ programmers are hardly competent at writing code which doesn't do bad things to CPUs designed to flatter their coding ability, the thought of them getting that kind of access to the GPU makes me cry for the performance loss. On the flip side if the control goes 'lower' than DX/HLSL and OGL/OCL expose then it might well be intresting to play with it, even if it you do end up avoiding things like virtual functions, classes etc which I'm not 100% belong in what is effectively a functional paradigm.. but we'll see

I only have one mind about it: keep C++ the **** off my GPU.

I think this slide sums it up?

[quote name='phantom' timestamp='1308250552' post='4824182']
C++ coding IS coming to AMD GPUs and is already on NV GPUs, however as with all things using C++ features will come at a cost. It might be useful for some things but writing performance code means you won't be using virtual all over the place (Personally I'm in two minds about it; frankly most C++ programmers are hardly competent at writing code which doesn't do bad things to CPUs designed to flatter their coding ability, the thought of them getting that kind of access to the GPU makes me cry for the performance loss. On the flip side if the control goes 'lower' than DX/HLSL and OGL/OCL expose then it might well be intresting to play with it, even if it you do end up avoiding things like virtual functions, classes etc which I'm not 100% belong in what is effectively a functional paradigm.. but we'll see

I only have one mind about it: keep C++ the **** off my GPU.
[/quote]I can second that opinion

I'm not all extatic about it. It's the same half-assed thing as Intel is doing, and each of them only does it because the other one does.

All in all, it will mean that manufacturers like Dell or Medion will soon puke a lot of cheap PCs onto the market with a pseudo-GPU that is supposedly DX11 capable and fails doing OpenGL 3.2. And you, as a developer, will have to cope with it.

It would be big win if you could use those on-chip GPUs for something sensible, for example as "free" OpenCL devices that don't hog cycles on your graphics card. But then again it won't be of any use, because you can't share contexts/buffers with the graphics card, so you need another round trip and it will be an ordeal to program.

[quote name='MJP' timestamp='1308259594' post='4824237']
I only have one mind about it: keep C++ the **** off my GPU.

I can second that opinion
[/quote]


Out of curiosity, why do you guys feel this way?

I'm not all extatic about it. It's the same half-assed thing as Intel is doing, and each of them only does it because the other one does.

Hardly 'half arsed'; AMD have had this on their roadmap for some time now.

Intel's solution suffers because Intel don't have any decent GPU tech to fall back on, but this isn't really a surprise.

All in all, it will mean that manufacturers like Dell or Medion will soon puke a lot of cheap PCs onto the market with a pseudo-GPU that is supposedly DX11 capable and fails doing OpenGL 3.2. And you, as a developer, will have to cope with it.
[/quote]

Erm, they ARE DX11 capable, they use the same core as the HD5 series with some of the upgrades which went into the HD6 series in the uncore UVD stuff. Yes, they are limited when compared to say a discrete card due to a lack of ALU units and memory bandwidth constraints, however they are miles ahead of existing IGP solutions.

Intel's SB isn't DX11, but then it never claims to be and lets face it Intel and OpenGL support is a joke anyway so no change there.

It would be big win if you could use those on-chip GPUs for something sensible, for example as "free" OpenCL devices that don't hog cycles on your graphics card. But then again it won't be of any use, because you can't share contexts/buffers with the graphics card, so you need another round trip and it will be an ordeal to program.
[/quote]

Well, you will be able to use them in that manner and there won't be 'another round trip' involved; it would be just the same as uploading a buffer from main memory as normal. I believe there are plans on the table to allow data sharing between contexts in that manner as well via an OpenCL extension and chances are it will become 'core' in the future.

Going forward the plan is to have Fusion devices and the graphics cards sharing the same address space, meaning these problems will vanish for the ISV and become solved by hardware.

[quote name='Jason Z' timestamp='1308340286' post='4824579']
[quote name='MJP' timestamp='1308259594' post='4824237']
I only have one mind about it: keep C++ the **** off my GPU.

I can second that opinion
[/quote]


Out of curiosity, why do you guys feel this way?
[/quote]

The main problem is that it allows C++ coders onto the GPU; as I mentioned above most C++ coders are hardly performance aware on x86 CPUs, which with their large caches and out of order execution engines flatter their code by covering up a multitude of coding sins, so letting them run riot over a GPU by crowbaring the C++ virtual machine (and C++ does target a VM, even if it looks somewhat like the x86 machine you are using) onto the GPU opens it up for a world of hurt. Things like 'virtual', while doable going forward, DO cost performance (yes, even on x86) and your average C++ coder is going to misuse this feature, cost themselves performance and generally eat GPU time.

That's not to say it's all bad; for those who know what they are doing the lower level access will probably provide a performance improvement and for certain problems, where the loss of performance will be offset by ease of production, the use of things like 'virtual' will probably help matters.

Even these days professional programmers do some very bad things to the SPUs of the PS3, which is a major source of it's power, and allowing access to the GPU in this manner is going to cause the same thing to happen there.

All I can hope is that there is a vast amount of education out there to help offset the problem, alas what I see happening is 'we scan stick this on the GPU' happening and other systems sucking resources away from the graphics side of things, and in some cases we have enough trouble fighting with the game play side of things for CPU resources as it is...

The main problem is that it allows C++ coders onto the GPU; as I mentioned above most C++ coders are hardly performance aware on x86 CPUs, which with their large caches and out of order execution engines flatter their code by covering up a multitude of coding sins, so letting them run riot over a GPU by crowbaring the C++ virtual machine (and C++ does target a VM, even if it looks somewhat like the x86 machine you are using) onto the GPU opens it up for a world of hurt. Things like 'virtual', while doable going forward, DO cost performance (yes, even on x86) and your average C++ coder is going to misuse this feature, cost themselves performance and generally eat GPU time.

That's not to say it's all bad; for those who know what they are doing the lower level access will probably provide a performance improvement and for certain problems, where the loss of performance will be offset by ease of production, the use of things like 'virtual' will probably help matters.

Even these days professional programmers do some very bad things to the SPUs of the PS3, which is a major source of it's power, and allowing access to the GPU in this manner is going to cause the same thing to happen there.

All I can hope is that there is a vast amount of education out there to help offset the problem, alas what I see happening is 'we scan stick this on the GPU' happening and other systems sucking resources away from the graphics side of things, and in some cases we have enough trouble fighting with the game play side of things for CPU resources as it is...

I fail to see the down-side.

C++ allows very low-level access, and also has higher-level constructs that are very easy to abuse, leading to poor performance. What's the down-side to this? Someone who isn't "performance-aware" doesn't end up with an application with high performance. This is as it should be, is it not?

Similarly with C++ on a shader. Someone who doesn't know how to get performance out of the language simply won't. Why does it bother you guys if others have performance-poor applications? Maybe they don't need the performance.

What you're saying is tantamount to saying, "Keep the interpreted languages off the CPU!" Why, because they aren't performance-friendly? Why should anyone care aside from the person who chose to use the interpreted language for his own reasons?

Should automatic transmissions not exist? Racecar drivers, who are performance-aware, demand manual transmissions. They don't seem to care, however, that others choose automatics. Why should they?

Why not simply choose to write your own performance-aware C++ on the shader (or not use C++ at all) and let others do what they want?

Personally I just think C++ is the totally wrong tool for the job when it comes to writing code on the GPU. Obviously it has benefits if it lets people quickly port large codebases to the GPU (assuming they actually get some sort of performance gain out of doing so), but it's just loaded with legacy baggage and commonly-used features that can quickly drag performance into the mud. A shader language like HLSL just naturally guides you towards writing code that respects a GPU's performance characteristics with regards to memory access, register usage, and inter-thread communication. Plus it can be aggressively optimized at compile time, since there are such few side effects due to the language being comparatively simple. At work we have some Cuda tools, and I remember being caught completely off-guard by how many temporary registers our programs. They ended up being caused by assignment operators and [] operators in some C++ classes that we were using out of convenience, as well as by some functions that were passing parameters by value. I got huge performance gains by stripping that stuff out, and writing careful C code that would compile similarly to how it would in HLSL. Surely part of that is just going to be the quality of the compiler, but some features (like virtual functions) are always going to be problematic on the GPU.

Anyway I obviously wouldn't care if I never had to write or optimize C++ code running on a GPU, but it's not something you're always going to have a choice in. If it becomes popular enough, then it's just a matter of time before you end up having to use it.

Personally any coding platform that does not require me to write an entire set of shaders independently is a win. Would be nice to see C, C++ or C[whatever] to have native SIMD, or GLSL/HLSL/CUDA -like support via GP-GPU.

Why so serious?

The stereotype of "GPU programmers who get agitated when other programmers want to make use of their precious GPU cycles" seems to be a common joke. MJP's choice of emoticon led me to believe he was playing into the stereotype deliberately.

If our AI programmer asked me if they could run their heat-map generation on my GPU, I'd tell em that we don't take kindly to their type around here and that they should get the hell back to their fancy CPU's and stay there!!! (and then if they've missed my humour I'll let them known that my hostility is in jest and tell them that I'll check our GPU budget...)

I do love C++ (as weird as that may be) and you can write very high-performance and highly-parallel systems with it... but to follow the tradition of misquoting Greenspun:
Any sufficiently parallel C++ program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of HLSL.

If our AI programmer asked me if they could run their heat-map generation on my GPU, I'd tell em that we don't take kindly to their type around here and that they should get the hell back to their fancy CPU's and stay there!!! (and then if they've missed my humour I'll let them known that my hostility is in jest and tell them that I'll check our GPU budget...)

"First they came asking to run particle calculations and I said okay since I had many cycles. Then they said they could run the physics calculations faster and I said okay again. Then they said their cloth would be better there and I didn't protest. Then they said the pathfinding could use a compute shader and by the then I had nothing left for lighting." I bet there is a poem in there.

Look, I just thought the GPU and I had an exclusive relationship. Then I find out that she's spending time with the physics guy and she's doing C++ now...it's like I hardly know her!