I've asked someone to check this problem. As I know, he was working on SPIR. Once I get any update, I'll share with you.
Hi, could you please as least verify that this is a bug? If not, we'd like to know what should we do to make the SPIR work.
That's what Dipak is working on - see if it's replicatable.
My apologies for this delayed reply. I have been working on SPIR for few weeks. I want to share my findings with you for the attached sample case.
I followed the procedure mentioned in the below github link to create binaries of llvm and clang.
One of the important thing is installation of proper version of clang. Initially I faced some problems to generate and consume the SPIR code, but latter discovered that it was due wrong version of clang. So, please make sure you've installed the right one. To check the version, you can use the following the command:
=> clang --version
I've attached the output which I got when ran for a compatible clang version. Kindly check it. If you have different version then try to use the right version. The clang source should be from khronosgroup.
Then I generated the SPIR binary with below option.
=> clang -cc1 -emit-llvm-bc -cl-std=CL1.2 -triple spir64-unknown-unknown -include opencl_spir.h MatrixTranspose_Kernels.cl -w
During the consume, I passed following flag in clBuildProgram.
-x spir -spir-std=1.2
The above steps worked fine for me.
I've attached the corresponding cl, llvm file and spir binary. Kindly check whether you get any difference (say, spir_kernel calling convention, kernel argument info metadata in your llvm file) compared to mine .
1 of 1 people found this helpful
So actually the problem is certainly they have a 64 bits application and were generating a 32 bits SPIR binary.
In their command line we can see -triple spir-unknown-unknown
While to build a 64 bits binary with SPIR we need to use this option
Our driver behaviour change with this new release and we now generate 64 bits ISA if the application is a 64 bits one.
Therefore a 64 bits application needs a 64 bits SPIR binary to run correctly.
Thanks to all of you for your suggestions. We will try and let you know in this thread.
On the other hand, we would like to avoid situations like this in the future. What happened is that we have released our code to our customers and after new omega driver release, it silently stopped working (OpenCL didn't emit any error code - it just didn't work). Is there anything we can do to assure forward compatibility for future drivers? I am thinking about some AMD's official SPIR guide, which would cover such situations. Is there anything like this?
I agree we should have noticed developers of such changes.
I believe you didn't get any errors from clBuildProgram, because the SPIR binary can still be built, but as it is a 32 bits one the address it is dealing with are incorrect in a 64 bits environment
What I would advise is to ship both the 32 bits and 64 bits SPIR binaries within your application.
Then in your OpenCL code you can check if the device is a 32 bits one or 64 bits one and thus load the correct binary :
Also if you look at SPIR documentation KhronosGroup/SPIR · GitHub, it talks briefly about the difference of 32 and 64 bits binaries
* <triple>: for 32 bit SPIR use spir-unknown-unknown, for 64 bit SPIR use spir64-unknown-unknown.
The above is true for any OpenCL implementation supporting SPIR