AMD Is Prepared To Release A Complete User-Space Open-Source Stack For HSA

[mmstick]

link?

http://www.phoronix.com/scan.php?page=news_item&px=MTEyNTE

[A Laggy Grunt]

I think China wanted the source code so that they could be sure the NSA didn't secretly install a backdoor into the driver.

Who says it's not in hardware somewhere? Lots of places in those billions of transistors where one could be hidden.

[odedgabbay]

Having to pre-compile my openCL code is a bit of a nuisance when I'm dynamically generating the openCL code at runtime, but I'm excited nevertheless.

Hoping for a compliant libOpenCL.so in the not too distant future

Yes, we are trying to also open source our finalizer, which creates HW ISA from OpenCL kernels at runtime.
However, I don't expect that to happen before 2015.

- Oded

[Nille]

link?

http://www.phoronix.com/scan.php?page=news_item&px=MTEyNTE

-----------------------------------------------------------------

Its very nice that it step by step land upstream. But as a demo i had the dream we see a image decoder library with HSA Support.

[valeriodean]

Could HSA be used by Intel and Nvidia too?

I find vendor-specific technology utterly boring and uninteresting.

Look here.
It's exciting. Maybe the industries start to understand that the open-source and the open collaboration are the best way to share the cost and the maintenance burden of those new technologies/approaches.
Everyone can contribute (even a single developer) every one can spot bugs, every one can enhance the code.

[Nille]

Could HSA be used by Intel and Nvidia too?

Yes, but if they do is a other thing. But there are other Big Players like ARM, TI or Meditak are in the HSA Boat.

I find vendor-specific technology utterly boring and uninteresting.

AMD is not well known for vendor specific stuff. But you can ask Nvidia about multivendor CUDA

[TheLexMachine]

I think China wanted the source code so that they could be sure the NSA didn't secretly install a backdoor into the driver.

That's part of it. China didn't want to use Nvidia's proprietary CUDA hardware/software that uses code that Nvidia cannot and will not divulge in order to protect their IP, so they went with AMD, who uses straight-up OpenCL, which Chinese institutions have been teaching to their students for several years now.

[TheLexMachine]

It's been a solid choice for a very long time. Linux is the best platform for AMD CPUs. They also provide great open source drivers.

If that were the case, we would see more vendors that offer Linux systems pushing AMD instead of only offering Intel/Nvidia and we wouldn't be seeing tons of forum posts about problems with AMD's hardware and drivers. It seems like there is a handful of AMD GPUs that work well on Linux and a bunch of AMD APUs and GPUs that don't work too well.

[89c51]

WIll this release mean usable OpenCL on AMD cards?

[bridgman]

This particular release is about providing an initial (and sustainable) fully open userspace that can make use of the HSA kernel driver (aka KFD, amdkfd) by using some of the existing OpenCL implementation (specifically the r600 llvm back-end), but it is also a useful stepping stone towards running the open source OpenCL code over the HSA stack...

step 1 - offline compile of CL kernels to HW ISA, load into HSA runtime & execute

step 2 - add HSA runtime calls to clover OpenCL runtime, so offline compile becomes JIT compile and regular OpenCL apps can run over HSA

step 3 - add option for generating HSAIL from clover then running through HSA finalizer (HSAIL to HW ISA), basically stop bypassing HSAIL so resulting OpenCL implementation can run on any HSA implementation rather than just AMD HW

... so this release on its own won't do anything to improve OpenCL execution but it's a useful step along the way.