HSA and foundation membership growing rapidly

[MisterMac]

In that case, good luck busting that inertia and actually managing to outperform Intel's x86 implementation for general purpose computing....

However, that's not what this appears to be about, and would more compete with the GPGPU space.

So not exactly HPC .....but HTPC people of actual current sellable markets?


I'm having trouble imagining 16core PD\Kaveri designs - that works better than a XeonPhi\CUDA + CPU Big Core solution.

 

[MisterMac]

As it is now, HSA looks more to be another Java.

You are certainly not getting rid of x86 without an unacceptable performance penalty

Except it'll be hardware supported and ported(technicly less overhead- but still overhead) - and it's meant to open up more resources that would else be idle.

Java is just intended to open more platforms - not more resources.


It's not a fair comparison.

 

[ShintaiDK]

Except it'll be hardware supported and ported(technicly less overhead- but still overhead) - and it's meant to open up more resources that would else be idle.

Java is just intended to open more platforms - not more resources.


It's not a fair comparison.

HSA can only open up for the maginal abilities of the GPU compared to the CPU. Yet apply a large overhead, unless its gets very system specific. Its OpenCL dreams all over again. It works fine for a tiny selection of applications. For the rest...

Also having the GPU manipulate data directly in CPU allocated memory yields a whole new set of issues. Since the quality of GPUs are far from the quality of CPUs.

 

[MisterMac]

HSA can only open up for the maginal abilities of the GPUs. Yet apply a large overhead. Its OpenCL dreams all over.

...but you admit and agree it's to open up more resources.


Wether it's effective or not - is any mans geuss.

 

[ShintaiDK]

...but you admit and agree it's to open up more resources.


Wether it's effective or not - is any mans geuss.

Depends, more resources compared to CUDA, OpenCL, DirectCompute? Not really. Its just another method.

Performance wise it goes terrible wrong when you do this:

 

[piesquared]

While I suppose it's possible, I find it more likely (and probable) that it is simply a design (aesthetic) effect. The honeycomb style looks nice, and it would look imbalanced if they omitted one hexagon just because there are only 7 founders so far. Theorizing a "secret" or "yet-to-be-named" founder just because of a graphic layout (and no press release / text / direct indication / caption whatsoever) seems rather far-fetched.

There were 3 empty placeholders before Samsung and Qualcomm filled in 2 of them. I don't think it's far-fetched at all but rather logical that there is 1 remaining founding member.

At any rate HSA could revolutionize computing. There are all kinds of advantages from unified memory space and low latency access to low power consumption and dedicated IP blocks/fixed function hardware from 3rd parties to low programming complexity/increased performance. There's a ton of information about HSA at AFDS'11 and AFDS'12 that is well worth a look.

 

[cytg111]

As it is now, HSA looks more to be another Java.

You are certainly not getting rid of x86 without an unacceptable performance penalty

- Another Java ?? That requires some explanation? Java and HSA -> totally different beasts. Or are you saying that HSA is plaqued by "virtual machine overhead and garbage collection stalls" ?

 

[cytg111]

..Also having the GPU manipulate data directly in CPU allocated memory yields a whole new set of issues. Since the quality of GPUs are far from the quality of CPUs..

Isnt that excatly what console devs needs/wants ? Why go anti-sense here ...

 

[ShintaiDK]

Isnt that excatly what console devs needs/wants ?

Is it? Where did they say so?

 

[ShintaiDK]

- Another Java ?? That requires some explanation? Java and HSA -> totally different beasts. Or are you saying that HSA is plaqued by "virtual machine overhead and garbage collection stalls" ?

Both are meant to be hardware independent in their purest forms, right?

HSAIL -> HSA Finalizer

 

[cytg111]

Still not the same beast

Runtime <> VirtualMachine, by a whole lot in terms of reliable performance. One is native, the other is not(until hotspotted or equal).
I might have gotten this wrong, but I think of it in terms of C.
Say you have this ansi-c code, c89, and then you have the platform specific implementation ie. for windows msvcrt.dll .. Any c89 code will compile to all platforms, but the final layer is platform specific.

edit : looks like i'll have to backpedel on that one .. :/ Time will tell how this pans out... I must admit, instinctively i'm thinking no! (where is this bytecode stored, translated bytcode, what compiler, where compiler etc .. maintainability, readability, debugging .. oh crap.)

 

[ShintaiDK]

Still not the same beast

Runtime <> VirtualMachine, by a whole lot in terms of reliable performance. One is native, the other is not(until hotspotted or equal).
I might have gotten this wrong, but I think of it in terms of C.
Say you have this ansi-c code, c89, and then you have the platform specific implementation ie. for windows msvcrt.dll .. Any c89 code will compile to all platforms, but the final layer is platform specific.

edit : looks like i'll have to backpedel on that one .. :/ Time will tell how this pans out.)

np

 

[Ferzerp]

edit : looks like i'll have to backpedel on that one .. :/ Time will tell how this pans out... I must admit, instinctively i'm thinking no! (where is this bytecode stored, translated bytcode, what compiler, where compiler etc .. maintainability, readability, debugging .. oh crap.)

It does appear as more of a pipe dream than anything else. Most technologies that rely on a special sauce that has to work for your particular application in order to not fall on their face tend to fall in to this bucket.

 

[MightyMalus]

It does appear as more of a pipe dream than anything else. Most technologies that rely on a special sauce that has to work for your particular application in order to not fall on their face tend to fall in to this bucket.

I wouldn't call CUDA a failure. I wouldn't call Xeon Phi design failures.
But HSA is both of them in one. CPU and GPU, not just one.
How is this not a better solution?

Its C++.
Its unified memory.
Its x86, GCN and ARM all in one.

 

[Ferzerp]

I wouldn't call CUDA a failure. I wouldn't call Xeon Phi design failures.
But HSA is both of them in one. CPU and GPU, not just one.
How is this not a better solution?

Its C++.
Its unified memory.
Its x86, GCN and ARM all in one.

CUDA and Xeon Phi are not similar at all. They aren't sold as the solution to everything. It is widely understood that there are problems that they are good for, and problems that they are poorly suited for. This, however, is being presented as an everything to everyone type solution. That is a pipe dream that appears motivated more by the market position of AMD than reality.

AMD has a hammer. Instead of making a wrench, they appear to be trying to take every bolt and turn it in to nail instead, ignoring that at the end of the day, a bolt is a bolt. A hammer can never properly insert a bolt, but a big wrench sure will drive a nail if it has to and is sturdy enough.

 

[sontin]

I wouldn't call CUDA a failure. I wouldn't call Xeon Phi design failures.
But HSA is both of them in one. CPU and GPU, not just one.
How is this not a better solution?

Its C++.
Its unified memory.
Its x86, GCN and ARM all in one.

And what's the difference to CUDA?
Cuda is C, C++, Fortan, OpenCl, DC, OpenACC...
Cuda is able to create a "unified virtual memory adress space". And with Project Denver nVidia will have a integrated CPU core, too.
Cuda it's x86, GPU down to G80, ARM...

But the only thing which matters: Cuda is real.

HSA exists on power point slides. There are no specifications, no hardware implementations, no software tools, no liberies. There is nothing.

You can go and buy a K20(x) card and start working. Or you wait 2 years and get your first HSA hardware implementation...

 

[MightyMalus]

CUDA and Xeon Phi are not similar at all. They aren't sold as the solution to everything. It is widely understood that there are problems that they are good for, and problems that they are poorly suited for. This, however, is being presented as an everything to everyone type solution. That is a pipe dream that appears motivated more by the market position of AMD than reality.

AMD has a hammer. Instead of making a wrench, they appear to be trying to take every bolt and turn it in to nail instead, ignoring that at the end of the day, a bolt is a bolt. A hammer can never properly insert a bolt, but a big wrench sure will drive a nail if it has to and is sturdy enough.

CUDA is being use in servers, the advantage? Performance. Xeon Phi is going to be used in servers, the advantage? C++. HSA, both+more and consumers will benefit from it.

AMD has friends, lots of them. Those friends seem to think that being able to use the whole hardware at once is much better than separately.
I actually agree.

You brought AMD, I just mentioned the first HSA product which will come out this year on GCN2 cards.

 

[MisterMac]

CUDA is being use in servers, the advantage? Performance. Xeon Phi is going to be used in servers, the advantage? C++. HSA, both+more and consumers will benefit from it.

AMD has friends, lots of them. Those friends seem to think that being able to use the whole hardware at once is much better than separately.
I actually agree.

You brought AMD, I just mentioned the first HSA product which will come out this year on GCN2 cards.

Meaning what?

You can HSA a SR\Kaveri Core with a HD8970 GCN2 core?
Didn't we establish that dGPU cannot be used for this already, per virge?

In that term - Kaveri (not this year??) will be the first HSA product along with perhaps other makers of tech.

HSA per idealogy is great - but it still has to gain massive adoption.
And it's prime target Intel\CUDA sits heavy on - it's not exactly straight forward.

 

[NTMBK]

Well AMD can't do this on their own. They don't have enough market share or enough clout among developers. If they don't bring on partners then this would never take off. So they've essentially formed an anti-Intel coalition.

As for how this benefits AMD, it's as I've said before: HSA is about making software that can fully exploit GPUs. AMD expects their iGPUs will outperform Intel's for at least the next couple of years, which if HSA took off and everything else went according to plan for AMD, would mean they'd have a leg-up on performance over Intel for at least a couple of years.

AMD intends to rewrite the rules of the game. They can't win when it comes to x86 CPUs, so they intend to make the battle over GPU performance where they at least stand a chance.

Plus don't forget- AMD could happily license out GCN designs to other companies if they wanted to (unlike their x86 designs). If there is suddenly a massive demand for GPU designs which are powerful at compute tasks, AMD could do an ARM and focus on selling their IP.

 

[NTMBK]

In that term - Kaveri (not this year??) will be the first HSA product along with perhaps other makers of tech.

Kaveri- this year.

 

[Gideon]

Kaveri- this year.

While I certainly hope it's true, I wouldn't necessarily count on it. It might very well slip a quarter (as AMD products have done in the past) OR they might do a paperlaunch or a semi-paperlaunch.

AMD promised Steamroller for 2013, therefore even if they know full well that they probably cannot achieve it, it would save some face, if they kept it on the roadmap as long and possible. It's not like they haven't delayed most of their CPU products in the near past (Bobcat being a rare exception that was put foward AFAIK) and usually letting us know a quarter or two before the presumed "launch".