Bug 105200 - [r600g] Regression: ImageMagick OpenCL kernel no longer compiles
Summary: [r600g] Regression: ImageMagick OpenCL kernel no longer compiles
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 99553
  Show dependency treegraph
 
Reported: 2018-02-22 01:59 UTC by nixscripter
Modified: 2018-04-04 21:19 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
The ImageMagick OpenCL Kernel (64.41 KB, text/x-opencl-src)
2018-02-22 01:59 UTC, nixscripter
Details
clover debug imagemagick.ll (564.49 KB, text/plain)
2018-02-24 05:23 UTC, nixscripter
Details
clover debug imagemagick.link-0.ll (135.50 KB, application/gzip)
2018-02-24 05:28 UTC, nixscripter
Details
clover debug imagemagick.cl (129.44 KB, text/plain)
2018-02-24 05:31 UTC, nixscripter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nixscripter 2018-02-22 01:59:42 UTC
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.
Comment 1 Jan Vesely 2018-02-22 23:32:25 UTC
(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.
Comment 2 nixscripter 2018-02-23 02:00:26 UTC
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
Comment 3 Jan Vesely 2018-02-23 02:54:31 UTC
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.
Comment 4 nixscripter 2018-02-23 05:13:04 UTC
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.
Comment 5 Jan Vesely 2018-02-23 17:02:12 UTC
(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?
Comment 6 nixscripter 2018-02-24 05:23:29 UTC
Created attachment 137571 [details]
clover debug imagemagick.ll
Comment 7 nixscripter 2018-02-24 05:28:07 UTC
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.
Comment 8 nixscripter 2018-02-24 05:31:32 UTC
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.
Comment 9 Jan Vesely 2018-03-02 04:01:21 UTC
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)
Comment 10 Jan Vesely 2018-03-02 04:05:14 UTC
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?
Comment 11 nixscripter 2018-03-12 00:08:26 UTC
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.
Comment 12 Jan Vesely 2018-04-04 21:19:56 UTC
(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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.