Talk:Heterogeneous System Architecture

Proposed merge with HSA Foundation

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was no merge. — Dsimic (talk | contribs) 14:07, 21 January 2015 (UTC)

---

I think the article about the foundation would serve better as a section in the main one, to avoid duplication of content regarding the history and politics of HSA, and to simply aid navigation. QVVERTYVS (hm?) 10:54, 24 May 2014 (UTC)

• Support: Merging these two articles would provide a much better context, and would be generally more readable. — Dsimic (talk | contribs) 10:58, 24 May 2014 (UTC)
• Oppose: This article is supposed to be technical, while HSA Foundation is about the community. User:ScotXW^t@lk 15:26, 24 May 2014 (UTC)
• oppose per scottxw. two different subjects. -- Aunva6^{talk - contribs} 15:32, 24 May 2014 (UTC)

• Support (I guess can be split later): "This article is supposed to be technical, while HSA Foundation is about the community" Note how the other already has a template: "This article may be too technical for most readers to understand". I believe this article (HSA) will always be too technical for the general audience.. (not us :) The other will say what? List of members? Not sure an exhaustive list is appropriate.. comp.arch (talk) 10:27, 26 May 2014 (UTC)

That tag is mine. I actually already stripped some of the technical information from that article because either way technicalities belong in this page. I'll see if the tag can go now. QVVERTYVS (hm?) 10:49, 26 May 2014 (UTC)

• Oppose: There is a similar relationship between Android (operating system) and Open Handset Alliance to the relationship between HSA and HSA Foundation. BananaLanguage (talk) 13:42, 29 May 2014 (UTC)

OHA article is small, but can't be merged because Android is (problematically) big. HSA Foundation has stayed small, but I see good improvements in this one, but still both combined are small and I'm not expecting combined size will be a problem any time soon. And see my comment above about splitting later. Seeing how I split Itanium (more business as the article is, but not really on either side) and IA64 (pure architecture, why I wanted to separete) in two and regretting it kinda (and realizing it had previously been combined) but nobody cared enough, don't take my words on splits/mergers :) comp.arch (talk) 15:04, 24 July 2014 (UTC)

• Oppose: Two different subjects. HSA is about a system architecture while HSA foundation is about a community.--Chamith (talk) 20:58, 17 January 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

ARM big.LITTLE

Does anybody know (and can cite a source) if ARM big.LITTLE, especially the Global Task Scheduling (GTS)-variant is part of HSA? User:ScotXW^t@lk 00:48, 2 June 2014 (UTC)

Don't believe GTS or any of big.LITTLE is part of HSA (ARM the company is - for other reasons, not ARM CPU tech). They are in effect very close to SMP and solving a different problem than separate memory spaces or incompatible architectures. Isn't that what HSA is for? Then you will not find a source. I've wasted to much time googling for stuff that can't be found (because it doesn't exist), it's not fun, Google is not optimized for that.. Try Prolog or Wolfram Alpha.. for ungooglable stuff :) comp.arch (talk) 15:21, 24 July 2014 (UTC)

Yeah, ARM big.LITTLE in fact isn't heterogeneous as expected by the definition of Heterogeneous System Architecture, because it combines multiple cores of basically the same type. — Dsimic (talk | contribs) 05:15, 28 July 2014 (UTC)

AMD

I agree that AMD seems to be pushing the concept hard, but AMD is by far not the only contributor or stake holder. At least ARM designs both, CPUs and GPUs, see e.g. http://www.chipdesignmag.com/pallab/2011/06/30/arm-mali-gpu-unifying-graphics-across-platforms/ from 2011, mentioning cache coherency between CPU and GPU. AMD shipped Graphics Core Next-stuff mid-2011, so I do not see, that they were or are more advanced than the other contributors to HSA. Ergo, I think misleading to write stuff like "Heterogeneous System Architecture was designed by AMD as a successor to its Accelerated Processing Unit (APU) architecture". In fact, I even call BULLSHIT on it. I have no interest in this marketing distortion field crap what-so-ever. User:ScotXW^t@lk 00:57, 2 June 2014 (UTC)

I wrote that because practically all the technical info that I found came from AMD. Feel free to update the article with better information, but please keep the abuse to yourself. QVVERTYVS (hm?) 07:35, 2 June 2014 (UTC)

After reading some OpenCL docs where AMD also claims to have invented lots of stuff that it didn't, I decided to remove this claim. We need a third-party source to establish who invented what. QVVERTYVS (hm?) 13:37, 29 June 2014 (UTC)

hardware vs software

Author willing to contribute to the Wikipedia most probably lack the know-how, but it would be nice™, if we could keep the hardware and the software separate.

1. there is the hardware, like the memory controller, the MMU, etc. that have to be adapted/enhanced to make HSA possible
2. there is the Java-stuff they are going to enlighten us with...

There is not really much information about AMD's "uncore" available. Search for onion and garlic bus, and you'll dig something up, but then the relation of the uncore to HSA, especially zero-copy mechanism through pointer sharing is missing. "CoreLink" is mentioned in the Cortex-A15 article and here, but not at all in the current version of the AMBA article. Etc. User:ScotXW^t@lk 01:13, 2 June 2014 (UTC)

What is needed for HSA [on the hardware side]? Does KeyStone II have it?

[Seems I'm talking about Unified main memory assuming HSA requires it. Article seems to say any heterogeneous is HSA, meaning HSA is a software architecture only.. Introductions says GPU and then DSP, DSPs do not have to have any GPU function.]

In my last edit summary on the page I asked if shared memory is enough? You can have shared memory (eg. in Adapteva); without cache coherence. Keystone II added ARMs that have a cache and the TI DSPs have caches and all cores can share memory, I'm not sure if the caches (across ARM and DSP or in general) are coherent however. Is that enough for HSA? At least the hardware capable then? If memory not accessible unless with DMA (eg. the Cell) I guess could say "heterogeneous" but not "HSA", right? Adapteva has local memory that isn't cached so coherence isn't an issue with the memory but I guess is with ARM's cache. Not ok? Then again you can disable caching for a memory region in the ARM.. In case caches need to be coherent then it's a little unfair to system without caches.. Note the link I give for KeyStone II doesn't mention the fastest one but I think the same architecture:

"There are three levels of memory in the KeyStone architecture. For DSP cores, each C66x CorePac has its own Level 1 program (L1P) and Level 1 data (L1D) memory, as well as its own Level 2 cache/SRAM that can be independently configured as memory-mapped SRAM, cache or both. Each Cortex-A15 processor in an ARM CorePac has its own Level 1 instruction and data cache. A 4-MB Level 2 cache/SRAM is shared among all Cortex-A15 processors within an ARM CorePac. All Level 1 and Level 2 memories for ARM CorePacs are Error Correction Code (ECC) protected. Level 1 and Level 2 memories on the DSP CorePacs are also protected from soft errors. Level 3 shared memory is implemented via the KeyStone architecture’s high-performance shared memory subsystem called the Multicore Shared Memory Controller (MSMC). The MSMC allows the DSP and ARM CorePacs to dynamically share on-chip Level 3 SRAM and an off-chip DDR memory port. Details on Level 2/3 memory and the MSMC are described later in this paper in the “Path to Memory” section."[1] See also at Hotchips[2] comp.arch (talk) 21:36, 24 September 2014 (UTC)