As I suspected, Linux will get the HSA stack and compiler tools first. There is little incentive for MicroSoft to do much since Intel is not supporting HSA (as yet or if ever). But server apps will surely benefit hugely from HSA. As to the development of OpenCL 2.0, the pace depends on niche players like Altera, AMD and kronos group members. AMD has to champion the HSA runtime themselves for Kaveri. It seems like a couple of quarters away at best.
I've been reading it for years. Normally it reads as a short news piece. Since AMD bought custom branding for a stream of its contents, I've felt that the pipeline items that appear from AMD Center have been below average quality; but this is a farce and a disgrace.
Yes. Physics in iGpu via HSA stack and rendering on dGpu (via OpenCL or direct). Other fp-Ops can be on the iGpu has well with HSA depending on the compiler targets for CU resources. Potentially I see the HSA Runtime unit maybe tunable on each config so it can be manually optimized for some really heavy games like Crysis.
AMD must have somthing for Linux gamers. They are shipping Linux benchmarking website crew (and authors of nice benchmarking framework), to the GDC this year.
While they failed to ship any hw in recent years...
hUMA is just ***** great. For everyone. And gamed do use some heavy phisical calculations that can be done swiftly on GPU... When You remove roadblocks, like those nasty memory transfers)
Yeah but advantage is for only AMD since they have the only implementation with Kaveri. One can see that there are a couple of serious improvements needed to increase the Ram controller bandwidth of AMD's core compared to the Intel RAM bandwidth speeds. ALso, it is possible to mix GDDR5 RAM (like in PS4) with DDR3-2400 in a later iteration where the hUMA switch manages the ram segments for all the CUs to use. That would really super-charge the gpu cores. Looking even further, I can see AMD changing PCIe slot0 to a hUMA-Port so dGPU will be part of the APU as a full and equal CU. If you look back at AGP development, it is almost the same method. Sure if Nvidia wants to make hUMA-Port dGPU in future, they should be able to do so. This would be interesting when Arm 64bit server chips with HSA comes and has dual sided, hUMA-port connects. ie serious GPU compute clusters at low cost. I can hope since the HSA architecture has legs beyond they traditional design. It is a greater leap than many people thinks.
I should be working about of box in all main compiler and without change of simple line of code, after that it have change, otherwise it will next Nvdia / Ati dead project..
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
22 Comments
Back to Article
fteoath64 - Monday, March 3, 2014 - link
As I suspected, Linux will get the HSA stack and compiler tools first. There is little incentive for MicroSoft to do much since Intel is not supporting HSA (as yet or if ever). But server apps will surely benefit hugely from HSA. As to the development of OpenCL 2.0, the pace depends on niche players like Altera, AMD and kronos group members. AMD has to champion the HSA runtime themselves for Kaveri. It seems like a couple of quarters away at best.Klimax - Tuesday, March 4, 2014 - link
Vendor specific stacks are rarely pushed by Microsoft, that's up to vendor themselves.Note: Intel supports properly OpenCL and HSA-like apps (CPU+GPU) are running very well...
http://techreport.com/review/24879/intel-core-i7-4...
I doubt HSA will do any good to AMD...
przemo_li - Tuesday, March 4, 2014 - link
hUMA alone is great boost to everything. Other unified ways of doing things only make HSA-stack more atractive.And HSA spread development costs.
PS HSA is no about CPU+GPU, its about making that difference go away. OpenCL is side addition to HSA. (Development in similar direction?)
DanNeely - Monday, March 3, 2014 - link
This reads like a press release not an article, and has no business on the front page.A5 - Monday, March 3, 2014 - link
Pipeline has been around for a few years now. Have you just never read it before?DanNeely - Monday, March 3, 2014 - link
I've been reading it for years. Normally it reads as a short news piece. Since AMD bought custom branding for a stream of its contents, I've felt that the pipeline items that appear from AMD Center have been below average quality; but this is a farce and a disgrace.HisDivineOrder - Thursday, March 6, 2014 - link
My take as well.Homeles - Monday, March 3, 2014 - link
Pipeline has nothing to do with this.DanNeely - Monday, March 3, 2014 - link
On the home page, this stinker is displayed with the other pipeline stories.Homeles - Tuesday, March 4, 2014 - link
What I'm saying is that the fact that this is a Pipleline article is irrelevant. It doesn't matter where it's posted.I think you're being a bit harsh, but I do see what you're saying.
pidgin - Monday, March 3, 2014 - link
will HSA benefit games that from off from dGPU?pidgin - Monday, March 3, 2014 - link
*runsamlebon2306 - Monday, March 3, 2014 - link
It would benefit games in the following scenario:- Physics implemented on HSA on the iGPU
- Rendering on the dGPU.
AMD is working on this configuration.
fteoath64 - Tuesday, March 4, 2014 - link
Yes. Physics in iGpu via HSA stack and rendering on dGpu (via OpenCL or direct). Other fp-Ops can be on the iGpu has well with HSA depending on the compiler targets for CU resources. Potentially I see the HSA Runtime unit maybe tunable on each config so it can be manually optimized for some really heavy games like Crysis.przemo_li - Monday, March 3, 2014 - link
AMD must have somthing for Linux gamers. They are shipping Linux benchmarking website crew (and authors of nice benchmarking framework), to the GDC this year.While they failed to ship any hw in recent years...
przemo_li - Monday, March 3, 2014 - link
hUMA is just ***** great. For everyone. And gamed do use some heavy phisical calculations that can be done swiftly on GPU... When You remove roadblocks, like those nasty memory transfers)fteoath64 - Tuesday, March 4, 2014 - link
Yeah but advantage is for only AMD since they have the only implementation with Kaveri. One can see that there are a couple of serious improvements needed to increase the Ram controller bandwidth of AMD's core compared to the Intel RAM bandwidth speeds. ALso, it is possible to mix GDDR5 RAM (like in PS4) with DDR3-2400 in a later iteration where the hUMA switch manages the ram segments for all the CUs to use. That would really super-charge the gpu cores.Looking even further, I can see AMD changing PCIe slot0 to a hUMA-Port so dGPU will be part of the APU as a full and equal CU. If you look back at AGP development, it is almost the same method. Sure if Nvidia wants to make hUMA-Port dGPU in future, they should be able to do so.
This would be interesting when Arm 64bit server chips with HSA comes and has dual sided, hUMA-port connects. ie serious GPU compute clusters at low cost. I can
hope since the HSA architecture has legs beyond they traditional design. It is a greater leap than many people thinks.
przemo_li - Monday, March 3, 2014 - link
@Rahul GargOpenMP 4.0 should land in GCC 4.9, and that is based on GOMP branch (Red Hat seam to be moving into merging it at last).
So AMDs work should be based on this.
(So GCC 4.9 it should be :) and at least acceleration of some of OpenMP)
ruthan - Monday, March 3, 2014 - link
I should be working about of box in all main compiler and without change of simple line of code, after that it have change, otherwise it will next Nvdia / Ati dead project..duffie - Wednesday, March 5, 2014 - link
Looking forward to AMD's beta HSA software stack for Linux in Q2 2014! I wish AMD would have released it already when they launched Kaveri...spigzone - Wednesday, March 5, 2014 - link
... as a compiler for HSAIL and ***an*** HSA runtimekonroh77 - Thursday, March 6, 2014 - link
Anyone have any update on when the A8-7600 will be available? AMD says Q1-2014, but that ends at the end of March...