AMD Adds Native Object Code Support To Clover/Radeon: Big Performance Win

[phoronix]

Phoronix: AMD Adds Native Object Code Support To Clover/Radeon: Big Performance Win

Tom Stellard announced his latest OpenCL-related improvements to the open-source Radeon Linux graphics driver...

http://www.phoronix.com/vr.php?view=MTgwNjE

[FutureSuture]

What implications does this have for gaming on AMD's open source driver?

[Ericg]

What implications does this have for gaming on AMD's open source driver?

None, unless the game engine makes use of OpenCL. This is strictly an OpenCL feature (though an awesome one).

[souenzzo]

With more gallium developers, maybe better general support/compatibility...

[schmidtbag]

How many non-benchmark applications out there support FOSS AMD openCL support without having to apply any special patches? I'm legitimately wondering - as long as crossfire isn't working, I'd like to put use to my 2nd GPU.

[DarkFoss]

Hmm, perhaps this may be enough to start running FAH on AMD Gpu's natively. It would be awesome considering the fglrx driver is still blacklisted.

[System25]

It can be cool for piglit, which runs a shitload of small tests but I doubt it would give too much benefit for usal apps, to be honest. Because most of apps compile CL kernel once and then just using it for a while. So I do not get how it would turn into big performance win.

[bridgman]

We are going to use this as an initial fully-open shader compiler for HSA as well.

The idea is to compile an OpenCL kernel to ISA binary then have the HSA runtime (now called HSAIL runtime) load & execute the binary in the HSA environment. The file formats are still being worked out so there'll probably be some post-processing between the steps. Finally a chance to dust off very old Perl skills

[Meteorhead]

We are going to use this as an initial fully-open shader compiler for HSA as well.

The idea is to compile an OpenCL kernel to ISA binary then have the HSA runtime (now called HSAIL runtime) load & execute the binary in the HSA environment. The file formats are still being worked out so there'll probably be some post-processing between the steps. Finally a chance to dust off very old Perl skills

Could you please elaborate on this a little more?

I am a very big fan of the "open" technologies of C++ GPGPU, and my group and I are also evaluating the possibilities of even higher level languages to target GPUs, such as Rust or Haskell (with Accelerate), two which show the greatest promise. Minimising entry cost to academics, C++ is already high-level enough to comprehend. (This is no insult to academics, it's just that people 35 year old today were still taught Fortran at university, as the de-facto language of HPC. Some learned C as well, and C++ is big enough of a jump. A purely functional language can be a lot to take in and often requires a different mindset. I have not wrapped my mind around the concept quite yet.)

SYCL is an awesome tool, though it is highly under development. It greatly accelerates GPU code writing, but in features it will only catch up once it reaches 2.0 . Clamp (the portable C++AMP compiler) yet again takes a big leap to extend the capabilities of an already promising language. Both of these provide nice template metaprogramming techniques.

How does this work fit into the greater picture of both coexisting with the proprietary Catalyst driver, and accelerating ADM HW or making way to using any existing GPGPU API/language on a wider range of devices?

[Marc Driftmeyer]

Could you please elaborate on this a little more?

I am a very big fan of the "open" technologies of C++ GPGPU, and my group and I are also evaluating the possibilities of even higher level languages to target GPUs, such as Rust or Haskell (with Accelerate), two which show the greatest promise. Minimising entry cost to academics, C++ is already high-level enough to comprehend. (This is no insult to academics, it's just that people 35 year old today were still taught Fortran at university, as the de-facto language of HPC. Some learned C as well, and C++ is big enough of a jump. A purely functional language can be a lot to take in and often requires a different mindset. I have not wrapped my mind around the concept quite yet.)

SYCL is an awesome tool, though it is highly under development. It greatly accelerates GPU code writing, but in features it will only catch up once it reaches 2.0 . Clamp (the portable C++AMP compiler) yet again takes a big leap to extend the capabilities of an already promising language. Both of these provide nice template metaprogramming techniques.

How does this work fit into the greater picture of both coexisting with the proprietary Catalyst driver, and accelerating ADM HW or making way to using any existing GPGPU API/language on a wider range of devices?

The core foundation of HSA is OpenCL and AMD's abstractions above the C/C++ OpenCL Kernels.

You can look at their projects here: https://github.com/HSAFoundation