Compile in 32-bit mode

[syifan]

I wonder if there is a way to compile c++ amp program in 32-bit mode. I tried to use hcc 'hcc-config --cxxflags --ldflags' -m32 saxpy.cpp -o saxpy, but I got the error

warning: overriding the module target triple with x86_64-unknown-linux-gnu
1 warning generated.
ld: cannot find -lc++
ld: cannot find -lc++abi

How does hcc link HSA runtime? Is there a way we can link another implementation of the runtime library in 32 bit mode?

[whchung]

So far we only do 64-bit. To my knowledge HSA runtime implementation only has 64-bit version as of now

[whchung]

For missing dependencies, please make sure you apt-get these packages:

cmake git subversion g++ libstdc++-4.8-dev libdwarf-dev libelf-dev libtinfo-dev libc6-dev-i386 gcc-multilib llvm llvm-dev llvm-runtime libc++1 libc++-dev libc++abi1 libc++abi-dev re2c libncurses5-dev

[bensander]

Right, 64-bit only. Nearly all linux distress and apps have moved to 64-bit.

On Apr 23, 2016, at 8:26 AM, Jack Chung <notifications@github.commailto:notifications@github.com> wrote:

For missing dependencies, please make sure you apt-get these packages:

cmake git subversion g++ libstdc++-4.8-dev libdwarf-dev libelf-dev libtinfo-dev libc6-dev-i386 gcc-multilib llvm llvm-dev llvm-runtime libc++1 libc++-dev libc++abi1 libc++abi-dev re2c libncurses5-dev

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/40#issuecomment-213742740

[syifan]

I thought HSA is a public standard and all other devices can work with HSA runtime. The runtime implementation should not only be limited to the AMD version. We have a virtual device (our simulator) that only support 32-bit memory address mode, and we have an in-house HSA runtime implementation.
Clang should support m32 option natively. I wonder if HCC can link with another HSA runtime library?

[whchung]

@sunyifan112358 it's possible for hcc-clang to produce 32-bit. In fact it was the default option in the early days. It's just been disabled now, as the HSA runtime contributed by AMD is the only widely visible implementation, and it only supports 64-bit.

May I understand the HSA stack you're working on better? For example, its HSAIL finalization capability, and HSA runtime API version.

In HCC runtime we are gradually introducing more AMD extensions in AMD HSA runtime implementation, for the sake of performance. Those additions would have to be removed to support other HSA stacks.

[syifan]

@whchung Thank you for your prompt reply. We have been working on providing an intermediate language level emulator for HSA in Multi2Sim. The emulator should produce a vendor-independent HSA program execution result. Currently, we do not finalize HSAIL code but directly execute it. But later on, we may plan to finalize the code to GCN3 and simulate it in out timing simulator. Due to the limitation of emulated instruction set in our X86 emulator and our memory module, we can only execute 32-bit elf files. We have been using SNACK as our programming runtime without any problem. We are now considering the possibility to also support HC with HSAIL backend.

[whchung]

it seems SNACK/CLOC doesn't use any AMD-specific HSA runtime API, so that explains why it could be integrated with Multi2sim easily.

HCC runtime on the other hand depends on various AMD extensions to fulfill features yet ratified in HSA Standard. So there would be some gaps to make it work on a plain vanilla HSA runtime.

I'm currently in another cycle of refactoring HCC runtime, to leverage asynchronous behavior exposed in AMD implementation. You can find some initial works in hsa_async_copy branch. Though it may make the gap bigger, I can think about how to derive a vanilla HSA version from it.

[syifan]

@whchung Thanks a lot for your help. I wonder if there is a place to find the header files that includes the hsa runtime with AMD extension. We may want to include that in out simulator. If possible, it would still be very helpful if we can have an interface that links with another implementation of the runtime.

I am wondering what is the status of HSAIL? Is AMD going to give it up and fully move to direct compilation from high-level languages to the device ISA?

[bensander]

The project is open-source so both of these are avail : the amd extension header is alongisde the hsa.h and in our recent distributions is available in /opt/rocm/include/hsa/hsa_amd_ext.h. This file has doxygen comments that describe the new APIs in detail.
The HCC runtime which uses these is also open-source, in particular take a look at the HCC language runtime here:
https://github.com/RadeonOpenCompute/hcc/tree/master/lib/hsa

[aditya4d]

Hi @sunyifan112358 ,
Let me set it up for you the AMD compute stack in pieces so that you can stitch it together.
For using HSA on discrete GPUs, use ROCR and ROCK from here. Once you have them successfully installed, you can use AMD extensions of HSA to do memory transfers between GPU and CPU. You can use existing compiler tools to generate brig file and use it with HSA app.
Answering your questions,

1. HSAIL is supported on AMD GPUs (not all but some).
2. Direct to ISA compilation proved that there is a performance benefit from using HSAIL. You can still use HSAIL with discrete GPUs.