HSA Foundation Formed By AMD, ARM, Ti, Imagination, and MediaTek

← Back to Stories (view on slashdot.org)

HSA Foundation Formed By AMD, ARM, Ti, Imagination, and MediaTek

Posted by Soulskill on Tuesday June 12, 2012 @10:58AM from the can-never-have-too-many-foundations dept.

New submitter Phopojijo writes "To wrap up his 'Programmers Guide to a Universe of Possibility' keynote during the 2012 AMD Fusion Developer Summit, Phil Rogers of AMD announced the establishment of the Heterogeneous System Architecture Foundation. The foundation has been instituted to create and maintain open standards to ease programming for a wide variety of processing resources including discrete and integrated GPUs. Founding members include ARM, Texas Instruments, Imagination, MediaTek, Texas Instruments, as well as AMD. Parallels can be drawn between this and AMD's 'virtual gorilla' initiative back from the late 1990s."

51 comments

Min score:

Reason:

Sort:

Ti by Anonymous Coward · 2012-06-12 11:06 · Score: 5, Funny

But tell me, does it include Texas Instruments?
1. Re:Ti by Anonymous Coward · 2012-06-12 11:13 · Score: 0
  
  It does! Twice!
2. Re:Ti by Anonymous Coward · 2012-06-12 11:15 · Score: 0
  
  Founding members include ARM, Texas Instruments, Imagination, MediaTek, Texas Instruments, as well as AMD. Oh and I almost forgot, Texas Instruments.
3. Re:Ti by c0lo · 2012-06-12 11:24 · Score: 1
  
  But no (i)nvidia which, I reckon, doesn't like to unleash the next era of computing innovation </grin>
  
  --
  Questions raise, answers kill. Raise questions to stay alive.
4. Re:Ti by Anonymous Coward · 2012-06-12 11:29 · Score: 0
  
  The other one might just be Texas Instruments' evil twin. That'd actually be a good sign, they haven't been talking to each other in decades.
5. Re:Ti by Phopojijo · 2012-06-12 11:29 · Score: 1
  
  Hah -- yeah I noticed that just after I clicked submit. Somehow I missed it while I was writing it and previewing it. Oh well.
6. Re:Ti by Phopojijo · 2012-06-12 11:32 · Score: 1
  
  Yeah... the list of major absentees is NVIDIA, Apple, Samsung, and Intel. Pretty big holes... but pretty big names present too. We shall see.
7. Re:Ti by Anonymous Coward · 2012-06-12 11:34 · Score: 1
  
  A fine contribution, sir, for I had failed to see the humor in the repetition until you repeated it with one additional repetition. Thank you, kind sir, for your additional repetition.
8. Re:Ti by LordLucless · 2012-06-12 12:27 · Score: 1
  
  nVidia and Intel I can see, but Apple and Samsung? They're widget makers, not chipset makers.
  
  --
  Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
9. Re:Ti by Phopojijo · 2012-06-12 13:14 · Score: 3, Informative
  
  Samsung is a big developer of processors and one of the world's few FABs actually. ((I actually forgot to mention Qualcomm as an absentee for some reason -- they're a big no-show too.)) Though Apple, I agree, is little love lost. They design chips... but barely; they would not really contribute much to this arrangement; and if they sink by excluding themselves then it will only be them to be hurt in that deal.
10. Re:Ti by CAIMLAS · 2012-06-12 13:25 · Score: 2
  
  Add to the list Motorola. Though, really, Samsung and Motorola are 'just' big (good) hardware intigrators, as opposed to being instigators of the actual core technologies. But if TI has signed on, I think they should certainly consider it.
  Apple? Most certainly they should be off the list, if for no other reason than the fact that they design their x86 hardware to not be fully compatible with other common x86 systems (thinking of their UEFI), seemingly for the sake of being different...
  
  --
  ~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
11. Re:Ti by Trogre · 2012-06-12 13:33 · Score: 1
  
  Yes it does, and yes.
  
  --
  "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
12. Re:Ti by forkazoo · 2012-06-12 13:39 · Score: 1
  
  To be fair, Apple basically invented OpenCL. AMD has been trying to push OpenCL as a valid alternative to CUDA for programming GPU's, and thus APU's. Apple certainly focuses on consumer electronics these days, but they do still have a lot of "core technology" people working in less visible rolls, and doing some very real work.
13. Re:Ti by Anonymous Coward · 2012-06-12 14:45 · Score: 0
  
  Intel would prefer if GPU woul just fucking go away. Reason? It's not x86 cores. See MIC, their supposed challenger to GPU, which is basically dozens/hundreds of old Pentium cores on a die. X86 über alles. It won't succeed of course. But that's why Intel ain't there.
14. Re:Ti by Tanktalus · 2012-06-12 15:20 · Score: 5, Funny
  
  That's okay. That's what /. has editors for.
15. Re:Ti by Anonymous Coward · 2012-06-12 16:51 · Score: 0
  
  [citation needed]
16. Re:Ti by Anne+Thwacks · 2012-06-12 21:24 · Score: 1
  
  Is the evil twin the one responsible for the documentation?
  
  --
  Sent from my ASR33 using ASCII
17. Re:Ti by Barefoot+Monkey · 2012-06-12 21:42 · Score: 2
  
  http://www.khronos.org/news/press/2008/06
  
  The Compute Working Group will follow proven Khronos processes and invite member contributions as a basis for standardization efforts. Apple has proposed the Open Computing Language (OpenCL) specification to enable any application to tap into the vast gigaflops of GPU and CPU resources through an approachable C-based language.
  Of course, "proposed" can mean different things, but it looks like Apple made the first draft.
18. Re:Ti by jamiesan · 2012-06-13 01:52 · Score: 1
  
  ... the list of major absentees is NVIDIA, Apple, Samsung, Intel and NVIDIA...
  FTFY
19. Re:Ti by Nadaka · 2012-06-13 02:52 · Score: 1
  
  That is a perfectly valid joke in context! No reason to mod down! Mod funny instead.
Me like by rrohbeck · 2012-06-12 11:27 · Score: 2

AMD needs to get on the ARM bandwagon. I want an APU with an integrated ARM core that works as a service processor and low power auxiliary CPU when the big CPU is powered off. Good enough for email and browsing and if the GPU has good power management the battery should last forever.

--
thegodmovie.com - watch it
1. Re:Me like by Anonymous Coward · 2012-06-12 13:33 · Score: 1
  
  They're already partway there, using ARM for the embedded controller in their south bridges.
2. Re:Me like by Anonymous Coward · 2012-06-12 15:01 · Score: 0
  
  Would a bobcat type of additional core do? Or many of them, with the main big cores sleeping while the parallel job is done on the low-power felines? Not that I would put that into a tablet anytime soon.
3. Re:Me like by Anonymous Coward · 2012-06-12 15:41 · Score: 1
  
  It seems more likely that they will eventually add a low-powered x86 core. Intel's Medfield shows that x86 can compete with ARM in the use cases you're suggesting (both in terms of power use and speed). Additionally, having a low-power x86 core would mean less concern about mixing ARM and x86 operating systems in some sort of weird, simultaneous mish-mash.
4. Re:Me like by Anonymous Coward · 2012-06-12 16:57 · Score: 0
  
  if the GPU has good power management the battery should last forever.
  Go check your Android phone (if you have one) and tell me what does the battery consumption report tells you. I'm guessing the screen is the one draining most of your power.
5. Re:Me like by rrohbeck · 2012-06-12 19:34 · Score: 1
  
  That would be nice but I doubt that any x86 CPU can ever be as power efficient as ARM.
  
  --
  thegodmovie.com - watch it
6. Re:Me like by FithisUX · 2012-06-12 20:12 · Score: 0
  
  I want an APU with an integrated ARM core that works as a service processor and low power auxiliary CPU when the big CPU is powered off. Good enough for email and browsing and if the GPU has good power management the battery should last forever.
  and having a unified standards compliant driver irrespective of the vendor (like USB)
7. Re:Me like by Anne+Thwacks · 2012-06-12 21:27 · Score: 0
  
  Intel's Medfield shows that x86 can compete with ARM
  Only if you use a Pentium for the calculations
  
  --
  Sent from my ASR33 using ASCII
What we programmer needs ... by Taco+Cowboy · 2012-06-12 12:00 · Score: 1

One of the main thing the programming community needs is getting to the innards of GPUs
We can sense the raw power of the GPU engines, the parallel structures, but, so far, there is no way we can tap into all those power buried inside with assembly language
We are forced to jump through official hoops such as CUDA (from Nvidia) and OpenCL (from ATi)
I am not saying that CUDA or OpenCL are craps, but they should let us, the programming community, the option of getting to the very guts of the graphic engines inside the GPU itself, with assembly language or C

--
Muchas Gracias, Señor Edward Snowden !
1. Re:What we programmer needs ... by Shag · 2012-06-12 12:13 · Score: 1
  
  We are forced to jump through official hoops such as CUDA (from Nvidia) and OpenCL (from ATi)
  You should fix Wikipedia, which thinks OpenCL originated with... Apple?
  I'm inclined to back the one with "Open" in its name, in hopes that it actually will be, but if everybody could get together and hash out a single thing including the best points of CUDA, OpenCL and this new HSA thing (how many times must we invent this particular wheel?) we'd probably all be better off.
  
  --
  Village idiot in some extremely smart villages.
2. Re:What we programmer needs ... by Taco+Cowboy · 2012-06-12 12:57 · Score: 1
  
  if everybody could get together and hash out a single thing including the best points of CUDA, OpenCL and this new HSA thing (how many times must we invent this particular wheel?) we'd probably all be better off.
  This lies the irony
  The more "committee" we set up, the more wheels get re-invented, and, this is the most important part, the programming community ends up waiting, and waiting, and waiting, with no end in sight
  The Intel X86 architecture became successful partly because it offers the programming community to tap into its raw power
  If the Intel X86 architecture hides itself behind layers upon layers of hardware/software obfuscations, I do not think it would be as successful as it is, today
  That is exactly why I ask for the opening up of the innards of the GPU engines, and let us, the programmers, do wonders with it
  
  --
  Muchas Gracias, Señor Edward Snowden !
3. Re:What we programmer needs ... by Phopojijo · 2012-06-12 13:24 · Score: 1
  
  Actually it is a bit bigger of a problem than that.
  
  There actually is a form of assembly language for GPUs. NVIDIA has PTX... I don't know what ATi/AMD's is called but I saw some of it in passing.
  
  The actual problem from my perspective is that the assembly language is modified and optimized by the drivers before it reaches the chip. The assembly-style PTX code you send to the drivers does not relate to the machine code which the GPU executes. That kind-of defeats the purpose of the assembly language.
  
  That seems to be one of the reasons why you see people like John Carmack who do unique things always complain about boxing GPU drivers... and why it is so difficult to virtualize a GPU. Maybe that will be solved starting with GK110? We will have to find out exactly what makes NVIDIA's latest part so easy to run through a VM to figure that out unfortunately. Hopefully it means the end of ridiculously complicated drivers.
4. Re:What we programmer needs ... by Phopojijo · 2012-06-12 13:34 · Score: 2
  
  The ironic part is that an X86 instruction hasn't been mapped to dedicated hardware for decades. It just signals a series of micro-ops to perform the calculation.
  
  That started back when we were still doing most of our applications in assembly... and people were begging Intel for the most arbitrary of operations in-silicon.
  
  Then of course when we switched to compilers only about 10% of those operations were used 90% of the time... which is why ARM got so efficient and cheap... because they built their committee around that Turing-complete small set of instructions that compilers would most likely use... rather than Intel's obfuscation to make assembly programmers not want to light themselves up in a gas fire.
  
  So I guess... sort of a bad example?
5. Re:What we programmer needs ... by Anonymous Coward · 2012-06-14 12:33 · Score: 0
  
  I recommend learning more about the characteristics of instruction sets. Several of the things you believe are wrong.
  For example, x86 is actually rather simple for a CISC instruction set, and ARM is one of the more complex RISCs. Also the distance between x86 opcodes, micro-ops, and hardware is not nearly as significant as you think. These days modern x86 processor frontends sometimes even fuse ops together into more complex ones for the backend.
6. Re:What we programmer needs ... by electrofelix · 2012-06-20 21:18 · Score: 1
  
  http://xkcd.com/927/
Slashdot, needs tweeked by Anonymous Coward · 2012-06-12 12:21 · Score: 0

So, how do articles with goofy errors with such goofy errors that have such goody errors make it to "prime time" on slashdot? Perhaps some peer review in order? Afterall, Slashdot is a commercial affair, is it not.
Too complex by gentryx · 2012-06-12 17:23 · Score: 1

AMD needs to get on the ARM bandwagon. I want an APU with an integrated ARM core that works as a service processor and low power auxiliary CPU when the big CPU is powered off. Good enough for email and browsing and if the GPU has good power management the battery should last forever.
So you would have a mix of instruction sets (ARM vs. X86). It's very unlikely that we'll see such a scenario, not just because of the hardware, but because of the software: porting an OS to run on two different architectures simultaneously is something (AFAIK) never done before. That would be coding hell. Too bad, because I like the idea, too.

--
Computer simulation made easy -- LibGeoDecomp
1. Re:Too complex by rrohbeck · 2012-06-12 19:31 · Score: 1
  
  No, two separate systems. For example Android on the ARM and full blown Linux or Windows on the main CPU. The ARM could manage power and thermals intelligently and do auxiliary things BIOS flash, CMOS RAM setting and IPMI like functionality.
  
  --
  thegodmovie.com - watch it
2. Re:Too complex by DarkOx · 2012-06-12 22:58 · Score: 1
  
  Umm see the Nintendo Wii, its ARM and PPC, no x86 in there, but it is two disparit architectures strapped to the same bus.
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
3. Re:Too complex by gentryx · 2012-06-12 23:15 · Score: 1
  
  Which chip in the Wii is an ARM chip? AFAIK it's just a PowerPC CPU + ATI GPU.
  
  --
  Computer simulation made easy -- LibGeoDecomp
4. Re:Too complex by gentryx · 2012-06-12 23:17 · Score: 1
  
  Got that already: Smartphone + Notebook. I switch to whatever device better suits my needs. ^^ Battery on the ARM device is indeed not an issue.
  
  --
  Computer simulation made easy -- LibGeoDecomp
5. Re:Too complex by khoonirobo · 2012-06-13 02:34 · Score: 1
  
  You mean like this :
  http://www.anandtech.com/show/6007/amd-2013-apus-to-include-arm-cortexa5-processor-for-trustzone-capabilities
  Seems it is used to implement "Trusted Computing".
6. Re:Too complex by Anonymous Coward · 2012-06-13 02:48 · Score: 0
  
  From what I can tell, this is an effort to make a standardized system and bus layout, regardless of the processor. hardware peripherals such as serial interfaces (UART, SPI, I2C, etc), audio accelerators, ADCs, timers, graphics accelerators, DMA controllers, Memory Protection Units/Memeory Management Units, cryptographic accelerators, I/O controllers, etc. are going to have the same address map, the same register interface, and the same behaviors regardless of the cpu architecture.
  This is a huge problem with all of the ARM-based (and, well, a lot of things that aren't x86) SoC's, is that all of the peripherals (and incidentally, the CPU's access to the outside world) have wildly varying address maps and behaviors. This essentially means an operating system can only run on an ARM chip if it has been directly configured for that exact chip's peripherals and address maps, causing driver hell and making life nearly impossible for systems that don't have published documentation (I'm looking at you, broadcom).
  It is seriously going to be really nice to develop for an embedded system and not have to rely on some dodgy vendor firmware driver or have to code up my own driver to use a dma engine or a damned UART. de-fragmentation of the embedded industry's hardware is going to be awesome!
7. Re:Too complex by Archibald+Buttle · 2012-06-13 02:52 · Score: 1
  
  The ARM chip inside the Wii is embedded in with the "Hollywood" GPU.
  See: http://en.wikipedia.org/wiki/Wii_system_software
8. Re:Too complex by gentryx · 2012-06-13 03:07 · Score: 1
  
  Interesting. Thanks!
  
  --
  Computer simulation made easy -- LibGeoDecomp
And what is the point? by mikelang · 2012-06-12 19:51 · Score: 1

Why don't they explain what is the foundation supposed to do and promote, that Khronos OpenCL doesn't yet promote? Without a clear, and well communicated mission this foundation will be just on paper, I am afraid. Anybody knows what they are supposed to do?
1. Re:And what is the point? by rrhal · 2012-06-12 20:32 · Score: 2
  
  From TFA (emphasis mine)
  
  The HSA (Heterogeneous System Architecture) Foundation is a not-for-profit consortium for SoC IP vendors, OEMs, academia, SoC vendors, OSVs and ISVs whose goal is to make it easy to program for parallel computing. HSA members are building a heterogeneous compute ecosystem, rooted in industry standards, for combining scalar processing on the CPU with parallel processing on the GPU while enabling high bandwidth access to memory and high application performance at low power consumption. HSA defines interfaces for parallel computation utilizing CPU, GPU and other programmable and fixed function devices, and support for a diverse set of high-level programming languages, thereby creating the next foundation in general purpose computing.
  One click in:
  
  Members of the HSA Foundation plan to deliver robust development solutions for heterogeneous compute to drive innovative content and applications with developer tools, software developer kits (SDKs), libraries, documentation, training, support and more.
  Basically they are going to maintain a set of open standards for platforms that allow programmers to integrate code that runs on the GPU with code that runs on the CPU's.
  
  --
  All generalizations are false, including this one. Mark Twain
About the gorilla by k(wi)r(kipedia) · 2012-06-12 22:33 · Score: 1

Okay, I had to Google for this, but for those curious about the simian reference in the summary, here's what Wikipedia has to say:

AMD ex-CEO and founder Jerry Sanders developed strategic partnerships during the late 1990s to improve AMD's presence in the PC market based on the success of the AMD K6 architecture. One major partnership announced in 1998 paired AMD with semiconductor giant Motorola. In the announcement, Sanders referred to the partnership as creating a "virtual gorilla" that would enable AMD to compete with Intel on fabrication capacity while limiting AMD's financial outlay for new facilities.
1. Re:About the gorilla by Epi-man · 2012-06-13 01:45 · Score: 1
  
  I had some friends who worked at AMD and were involved with this partnership. The thing I remember most was how different two companies could be. AMD and Motorola had two dramatically different design philosophies, polar opposites, it was not a pretty picture.
Texas Instruments AND Texas Instruments? by Nadaka · 2012-06-13 02:51 · Score: 1

Wow, its very rare to see both of them cooperating on the same project.