Bug 105200

(In reply to nixscripter from comment #0)
> Created attachment 137519 [details]
> The ImageMagick OpenCL Kernel
> 
> LLVM svn version: 325439
> Mesa version: git fa8a764b62
> 
> The last version that worked was several weeks ago -- prior to the LLVM 6
> branch.
> 
> The log is so short, I can paste it in here:
> 
> build options: -cl-single-precision-constant -cl-mad-enable
> -DMAGICKCORE_HDRI_SUPPORT=1 -DCLQuantum=float -DCLSignedQuantum=float
> -DCLPixelType=float4 -DQuantumRange=65535.000000 -DQuantumScale=0.000015
> -DCharQuantumScale=1.000000 -DMagickEpsilon=0.000000 -DMagickPI=3.141593 
> -DMaxMap=65535 -DMAGICKCORE_QUANTUM_DEPTH=16
> <unknown>:0:0: in function AddNoise void (<4 x float> addrspace(1)*, <4 x
> float> addrspace(1)*, i32, i32, i32, i32, float, i32, i32, i32): unsupported
> initializer for address space
> 
> The unknown is because I have a stripped binary. I have not done all the
> manual rebuilds for the symbols yet.
> 
> The actual kernel being compiled is attached. Hopefully it should be obvious
> enough what the problem is.

well, not really. AS error suggests that this is a fallout of r325030 and you'll need to update and rebuild libclc.

It seems the libclc version I'm using was Feb 2nd. Good point

... and now that I've tried to compile SVN r325851, I see why it was held back.

First, I had to patch this:

And this is after I did my little patch to avoid an LLVM syntax error:

Index: utils/prepare-builtins.cpp
===================================================================
--- utils/prepare-builtins.cpp  (revision 325851)
+++ utils/prepare-builtins.cpp  (working copy)
@@ -105,7 +105,7 @@
     exit(1);
   }
 
-  WriteBitcodeToFile(M, Out->os());
+  WriteBitcodeToFile(*M, Out->os());
 
   // Declare success.
   Out->keep();


And then... more address space issues:

[...]
WARNING: Linking two modules of different data layouts: 'r600--/lib/relational/isnormal.cl.cayman.bc' is 'e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-A5' whereas 'llvm-link' is 'e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64'

WARNING: Linking two modules of different data layouts: 'r600--/lib/relational/isnotequal.cl.cayman.bc' is 'e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-A5' whereas 'llvm-link' is 'e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64'
[...]
Allocation instruction pointer not in the stack address space!
  %2 = alloca i32, align 4, addrspace(5)
Allocation instruction pointer not in the stack address space!
  %3 = alloca i32, align 4, addrspace(5)
Allocation instruction pointer not in the stack address space!
  %4 = alloca i32, align 4, addrspace(5)
Allocation instruction pointer not in the stack address space!
  %5 = alloca i32, align 4, addrspace(5)
Allocation instruction pointer not in the stack address space!
  %6 = alloca i32, align 4, addrspace(5)
[...]
Allocation instruction pointer not in the stack address space!
  %33 = alloca float, align 4, addrspace(5)
/usr/bin/llvm-link: error: linked module is broken!
make: *** [Makefile:3127: r600--/lib/builtins.link.cedar.bc] Error 1

you'll need the libclc build fixes from:
http://lists.llvm.org/pipermail/libclc-dev/2018-February/002796.html
and
http://lists.llvm.org/pipermail/libclc-dev/2018-February/002800.html

(all 5 of them).
Alternatively you can wait until they land.

Thanks to your quick response, I got libclc compiled successfully.

Now when I try to view an image, the OpenCL compile error is different:

<unknown>:0:0: in function ResizeHorizontalFilter void (float addrspace(1)*, i32, i32, i32, float addrspace(1)*, i32, i32, float, i32, i32, float addrspace(1)*, float, float, float, float, float addrspace(3)*, i32, i32, i32, <4 x float> addrspace(3)*, float addrspace(3)*, float addrspace(3)*): unsupported call to function applyResizeFilter

I'd call that progress, certainly.

applyResizeFilter is on line 78 of the kernel, and ResizeHorizontalFilter is on line 81.

(In reply to nixscripter from comment #4)
> Thanks to your quick response, I got libclc compiled successfully.
> 
> Now when I try to view an image, the OpenCL compile error is different:
> 
> <unknown>:0:0: in function ResizeHorizontalFilter void (float addrspace(1)*,
> i32, i32, i32, float addrspace(1)*, i32, i32, float, i32, i32, float
> addrspace(1)*, float, float, float, float, float addrspace(3)*, i32, i32,
> i32, <4 x float> addrspace(3)*, float addrspace(3)*, float addrspace(3)*):
> unsupported call to function applyResizeFilter
> 
> I'd call that progress, certainly.
> 
> applyResizeFilter is on line 78 of the kernel, and ResizeHorizontalFilter is
> on line 81.

that's weird. Probably a separate bug. All functions should be marked as always_inline. moreover the function in question is explicitly marked as inline.
The only thing I can think of is that the function signature does not match between definition and the call site
Does imagemagick use some form of kernel cache? if yes it needs to be cleaned.

what is the GPU that you're using?
Can you run CLOVER_DEBUG=llvm,clc CLOVER_DEBUG_FILE=imagick and attach the .cl and .ll dump files?

Created attachment 137571 [details]
clover debug imagemagick.ll

Created attachment 137572 [details]
clover debug imagemagick.link-0.ll

My GPU is:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Juniper PRO [Radeon HD 6750]

(Which is an Evergreen chipset, if I remember correctly.)

And I am pretty sure ImageMagick does not have an OpenCL cache. For better or worse, it has one giant blob of OpenCL, and re-compiles it when OpenCL is enabled -- whether you actually use any of it or not. I did try deleting the files, though, just in case.

Created attachment 137573 [details]
clover debug imagemagick.cl

And finally (sorry for the e-mail spam) here is the .cl file.

Sidenote: the last file was gzip'd, because trying to attach it directly resulted in a 500 Internal Server Error for some crazy reason... but that's a bug for an entirely different tracker.

did you by any chance run the DUMP commands twice? the files seems to contain duplicates.

Anyway I cannot reproduce the error.
running:
> clang -cc1 -x cl -triple=r600-- -target-cpu juniper -cl-single-precision-constant -cl-mad-enable -DMAGICKCORE_HDRI_SUPPORT=1 -DCLQuantum=float -DCLSignedQuantum=float -DCLPixelType=float4 -DQuantumRange=65535.000000f -DQuantumScale=0.000015 -DCharQuantumScale=1.000000 -DMagickEpsilon=0.000000 -DMagickPI=3.141593 -DMaxMap=65535 -DMAGICKCORE_QUANTUM_DEPTH=16 -I ./libclc/generic/include/ -include libclc/generic/include/clc/clc.h -emit-llvm -o magick-link.ll -mlink-bitcode-file libclc/built_libs/juniper-r600--.bc < magick.cl
> llc -march=r600-- -mcpu=juniper < magick-link.ll

Runs into:
llvm/include/llvm/MC/MCRegisterInfo.h:64: unsigned int llvm::MCRegisterClass::getRegister(unsigned int) const: Assertion `i < getNumRegs() && "Register number out of range!"' failed.

which is expected, since register spilling is not implemented (yet)

even running (after removing half of the lines:
> llc -march=r600 -mcpu=juniper < Downloads/imagemagick.link-0.ll/data

gives "Register number out of range!" assertion.

Can you try a more recent version of llvm?

I finally got back to this, and sure enough, upgrading LLVM to r327238 seems to have fixed it. Thanks for your efforts.

Marking as RESOLVED FIXED.

(In reply to nixscripter from comment #11)
> I finally got back to this, and sure enough, upgrading LLVM to r327238 seems
> to have fixed it. Thanks for your efforts.
> 
> Marking as RESOLVED FIXED.

Note that it will probably give wrong results if you compiled without assertions.