Re: [Mesa-dev] Error: unsupported relocations
I don't see the code question, but I do see uses of the "inline" keyword in
ImageMagick. C99 inline does not mean what everyone seems to think it means,
and is not really a demand or even request to inline the function.
For example at -O1 on x86, this gives:
inline void bar(global int* arg) {
*arg = 0;
}
kernel void foo(global int* kernarg) {
bar(kernarg);
}
_foo: ## @foo
.cfi_startproc
## %bb.0:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq%rsp, %rbp
.cfi_def_cfa_register %rbp
popq%rbp
jmp _bar## TAILCALL
.cfi_endproc
With no definition for bar emitted. The definition is only emitted for extern
inline or static inline.
On 2019-06-03, 3:43 AM, "Dave Airlie" wrote:
> > this is clearly inline not working, not relocs. We never get the
> > missing function to relocate it.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Sat, Jun 1, 2019 at 11:24 PM Marek Olšák wrote: > > clover is not supported by AMD officially, because AMD has its own OpenCL > driver called ROCm. > > Marek ROCm isn't a viable option for many. Official support only goes back to Fiji . Running without PCIe atomics support only applies to Vega, so what about everyone else? To some extent, it would be fine to just say old cards aren't supported. But, there's a critical difference here. Customers purchased your old cards and things worked using non-ROCm, and now they don't. With AMD having $6.5 billion (USD) in annual revenue, and now turning a profit, can't it spare a little bit of time to assist ensuring that AMD's customers can use its video cards the way they'd like, without absolutely hating the product? I'm not even talking about best performance, I'm just talking about being able to use the darn thing, whether it be in mesa, or amdgpu. I think many of your linux customers are using AMD because it's the lesser of two current evils. IMO, AMD should see Intel coming towards the discrete GPU market and start rethinking its behavior. I didn't use ROCm in the past, because it used to require a Xeon E5 be v3 or newer, and I have v1. I see now there's a way to run Vega 10 chips to run without PCIe atomics support, so I'll give it another try. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Mon, 3 Jun 2019 at 11:37, Jan Vesely wrote: > > On Mon, 2019-06-03 at 11:12 +1000, Dave Airlie wrote: > > On Mon, 3 Jun 2019 at 10:58, Jan Vesely wrote: > > > On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote: > > > > I've started a thread on the llvm mailing list. See > > > > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2F2019-June%2F132750.htmldata=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ce7c33507211c4512c6ad08d6e7c09d49%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636951211793224808sdata=lyayMkDxUbTCye%2BynlBZ8sp%2Fc4u5kS4pv%2B2MMeSegoM%3Dreserved=0 > > > > > > > > I don't know if it's needed, but if anyone has a commit in llvm that > > > > started this, that might be helpful. > > > > > > thanks. however most LLVM developers contributing to AMDGPU backend > > > are AMD folks. The ROCm based stack can handle relocations, so it's up > > > to a volunteer to step up and post a patch (either for mesa or llvm). > > > Fewer relocations should mean faster dispatch, so you they should be > > > interested in taking the LLVM fix. > > > > > > I've started looking, but the elf structure lists relocations against > > > a section (STT_SECTION), so I still don't know where to get target > > > address. > > > > Jan, > > > > this is clearly inline not working, not relocs. We never get the > > missing function to relocate it. > > The imagemagick issue might be missed inlining. > I'm working on call* piglits, which mark functions as 'noinline' to > force function calls. > the code clearly expects relative function address: > s_getpc_b64 s[8:9] > s_add_u32 s8, s8, i64_func_void@rel32@lo+4 > s_addc_u32 s9, s9, i64_func_void@rel32@hi+4 > s_mov_b32 s32, s10 > s_swappc_b64 s[30:31], s[8:9] > Inspecting the asm and symbol table, the callee functions are there. > It might be that relocations issued for amdgcn-mesa-mesa3d triple are > busted, I'd expect it to use single 4B relative pointer, but last time > I talked to Matt he said it looked correct. Okay so this doesn't appear to be that. commit 5d567dc137d20a9d9654076fbdab8ceddb6748dc (HEAD, refs/bisect/new) Author: Matt Arsenault Date: Thu Feb 28 00:40:32 2019 + AMDGPU: Enable function calls by default LLVM 8 release fails to inline some functions, this commit in llvm 9 fixes that for some reason. Which is totally the opposite of what i'd expect here. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Mon, 2019-06-03 at 11:12 +1000, Dave Airlie wrote: > On Mon, 3 Jun 2019 at 10:58, Jan Vesely wrote: > > On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote: > > > I've started a thread on the llvm mailing list. See > > > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2F2019-June%2F132750.htmldata=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ce7c33507211c4512c6ad08d6e7c09d49%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636951211793224808sdata=lyayMkDxUbTCye%2BynlBZ8sp%2Fc4u5kS4pv%2B2MMeSegoM%3Dreserved=0 > > > > > > I don't know if it's needed, but if anyone has a commit in llvm that > > > started this, that might be helpful. > > > > thanks. however most LLVM developers contributing to AMDGPU backend > > are AMD folks. The ROCm based stack can handle relocations, so it's up > > to a volunteer to step up and post a patch (either for mesa or llvm). > > Fewer relocations should mean faster dispatch, so you they should be > > interested in taking the LLVM fix. > > > > I've started looking, but the elf structure lists relocations against > > a section (STT_SECTION), so I still don't know where to get target > > address. > > Jan, > > this is clearly inline not working, not relocs. We never get the > missing function to relocate it. The imagemagick issue might be missed inlining. I'm working on call* piglits, which mark functions as 'noinline' to force function calls. the code clearly expects relative function address: s_getpc_b64 s[8:9] s_add_u32 s8, s8, i64_func_void@rel32@lo+4 s_addc_u32 s9, s9, i64_func_void@rel32@hi+4 s_mov_b32 s32, s10 s_swappc_b64 s[30:31], s[8:9] Inspecting the asm and symbol table, the callee functions are there. It might be that relocations issued for amdgcn-mesa-mesa3d triple are busted, I'd expect it to use single 4B relative pointer, but last time I talked to Matt he said it looked correct. Jan > > Dave. -- Jan Vesely signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Mon, 3 Jun 2019 at 10:42, Jan Vesely wrote: > > On Mon, 2019-06-03 at 09:14 +1000, Dave Airlie wrote: > > On Mon, 3 Jun 2019 at 09:13, Dave Airlie wrote: > > > On Sun, 2 Jun 2019 at 23:13, Jan Vesely wrote: > > > > On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote: > > > > > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen > > > > > wrote: > > > > > > On Sun, Jun 2, 2019 at 12:41 PM James Harvey > > > > > > wrote: > > > > > > > So, for people running amdgpu and wanting to run ImageMagick > > > > > > > convert > > > > > > > who get this error... Does this mean there is something > > > > > > > ImageMagick > > > > > > > could change to prevent the error? Or, in the meantime, is the > > > > > > > only > > > > > > > option to install the amdgpu-pro opencl userspace driver with > > > > > > > ImageMagick? (The pro opencl driver can be extracted from > > > > > > > amdgpu-pro > > > > > > > as a whole, and ran on top of the free amdgpu driver., without the > > > > > > > rest of amdgpu-pro installed - see Arch Linux AUR package > > > > > > > opencl-amd.) > > > > > > > > > > > > So, does imagemagick actually need OpenCL? If not, you can probably > > > > > > also uninstall you mesa opencl distro package? > > > > > > > > > > The mesa opencl package works fine on other programs for me and > > > > > others, so uninstalling isn't an option. Not sure actually without > > > > > any OpenCL if it does it a different way or not. ImageMagick must be > > > > > all that's trying to call something problematic. > > > > > > > > It's basically any function call that was not inlined. It might even > > > > be in a different kernel in the same module. > > > > > > > > Recent mesa requires some kind of ICD loader to provide opencl. if > > > > your distro uses ocl-icd package to provide ICD loader, you can use > > > > OCL_ICD_VENDORS env var to select ICD drivers. > > > > > > > > something like 'OCD_ICD_VENDORS=/var/empty' (any directory other than > > > > /etc/OpenCL/vendors will do) effectively disables OpenCL by reporting > > > > 0 available platforms. > > > > > > It looks like an llvm8 not inlining everything properly bug. > > > > > > with llvm9 I just get a gpu hang when it does inline everything, but > > > with 8 it fails to inline applyResizeFilter. > > > > > > llvm8 or some command line option passed to it might need a fix. > > > > Uggh changing the original CL C code in ImageMagic to static inline "fixes" > > it. > > sounds a bit like https://reviews.llvm.org/D62707. static inline > function might be internalized/marked alwaysinline. CLOVER_DEBUG=llvm > would tell more. > I'm not sure why it'd produce GPU hangs. It might be a llvm-git bug, > my daily testing only covers CL piglits. I tried backporting this to llvm8, didn't seem to help, going to dig deeper. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Mon, 3 Jun 2019 at 10:58, Jan Vesely wrote: > > On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote: > > I've started a thread on the llvm mailing list. See > > http://lists.llvm.org/pipermail/llvm-dev/2019-June/132750.html > > > > I don't know if it's needed, but if anyone has a commit in llvm that > > started this, that might be helpful. > > thanks. however most LLVM developers contributing to AMDGPU backend > are AMD folks. The ROCm based stack can handle relocations, so it's up > to a volunteer to step up and post a patch (either for mesa or llvm). > Fewer relocations should mean faster dispatch, so you they should be > interested in taking the LLVM fix. > > I've started looking, but the elf structure lists relocations against > a section (STT_SECTION), so I still don't know where to get target > address. Jan, this is clearly inline not working, not relocs. We never get the missing function to relocate it. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote: > I've started a thread on the llvm mailing list. See > http://lists.llvm.org/pipermail/llvm-dev/2019-June/132750.html > > I don't know if it's needed, but if anyone has a commit in llvm that > started this, that might be helpful. thanks. however most LLVM developers contributing to AMDGPU backend are AMD folks. The ROCm based stack can handle relocations, so it's up to a volunteer to step up and post a patch (either for mesa or llvm). Fewer relocations should mean faster dispatch, so you they should be interested in taking the LLVM fix. I've started looking, but the elf structure lists relocations against a section (STT_SECTION), so I still don't know where to get target address. Jan > > On Sat, Jun 1, 2019 at 10:56 PM Jan Vesely wrote: > > Hi, > > > > On Sat, 2019-06-01 at 18:21 -0400, James Harvey wrote: > > > On Sat, Jun 1, 2019 at 6:19 PM James Harvey > > > wrote: > > > > On Tue, Feb 19, 2019 at 7:52 PM james harvey > > > > wrote: > > > > > Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled > > > > > relocations". > > > > > > > > > > This has broken ImageMagick for many people using AMD graphics cards. > > > > > See https://github.com/ImageMagick/ImageMagick/issues/1366 > > > > > > > > > > ImageMagick responded: "It looks like this error message is created by > > > > > the mesa driver. I have no idea what causes this message and if there > > > > > is anything what we could do to prevent this from happening." > > > > > > > > > > And, hasn't responded back for requests for what additional > > > > > information I could tell mesa. > > > > > > > > > > I see the mesa commit is to prevent GPU hangs, so I'm all for the > > > > > commit. > > > > > > > > > > I'm just asking what would need to be done by who to get ImageMagick > > > > > working again, using opencl-mesa. Using opencl-amd has been a > > > > > workaround for some people. Not sure if this is something mesa just > > > > > hasn't implemented that opencl-amd has, or if it's something > > > > > ImageMagick needs to do differently. > > > > > > > > Ping? Mesa + ImageMagick convert is broken, affecting lots of people, > > > > but neither project is saying anything. > > > > > > Sorry all, please reply to this post rather than the last. Copy-paste > > > failure of email addresses of people listed in mesa patch, fixed. > > > > sorry I missed the previous email. The issues has been discussed at > > [0]. > > > > tldr; the referenced mesa commit prevents GPU hangs/crashes caused by > > changes in LLVM. > > > > longer story: > > AMDGPU llvm backend used to inline all function calls until llvm-6. > > llvm-6+ uses functions calls and issues relocations for each function > > invocation. unhandled relocations lead to GPU hangs/crashes. > > either clover/mesa needs to handle relocations, or LLVM needs to stop > > using relocations for internal symbols (they are not needed). > > > > I've neither time, nor energy, nor access to hw, to fix things up > > every time AMD changes break something in clover, and nobody else has > > stepped up. > > moreover, mesa made it clear that volunteer contributions and needs > > are inferior to corporate stakeholders (not even worth CI cycles). > > thus, clover on amd gpus is in damage mitigation mode; errors are > > better than crashes, crashes are better than hangs. > > > > Chances are that clover over NIR will work before the current issues > > are fixed. > > > > regards, > > Jan > > > > [0] https://bugs.freedesktop.org/show_bug.cgi?id=105113 > > > > > ___ > > > mesa-dev mailing list > > > mesa-dev@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > -- > > Jan Vesely > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Jan Vesely signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Mon, 2019-06-03 at 09:14 +1000, Dave Airlie wrote: > On Mon, 3 Jun 2019 at 09:13, Dave Airlie wrote: > > On Sun, 2 Jun 2019 at 23:13, Jan Vesely wrote: > > > On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote: > > > > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen > > > > wrote: > > > > > On Sun, Jun 2, 2019 at 12:41 PM James Harvey > > > > > wrote: > > > > > > So, for people running amdgpu and wanting to run ImageMagick convert > > > > > > who get this error... Does this mean there is something ImageMagick > > > > > > could change to prevent the error? Or, in the meantime, is the only > > > > > > option to install the amdgpu-pro opencl userspace driver with > > > > > > ImageMagick? (The pro opencl driver can be extracted from > > > > > > amdgpu-pro > > > > > > as a whole, and ran on top of the free amdgpu driver., without the > > > > > > rest of amdgpu-pro installed - see Arch Linux AUR package > > > > > > opencl-amd.) > > > > > > > > > > So, does imagemagick actually need OpenCL? If not, you can probably > > > > > also uninstall you mesa opencl distro package? > > > > > > > > The mesa opencl package works fine on other programs for me and > > > > others, so uninstalling isn't an option. Not sure actually without > > > > any OpenCL if it does it a different way or not. ImageMagick must be > > > > all that's trying to call something problematic. > > > > > > It's basically any function call that was not inlined. It might even > > > be in a different kernel in the same module. > > > > > > Recent mesa requires some kind of ICD loader to provide opencl. if > > > your distro uses ocl-icd package to provide ICD loader, you can use > > > OCL_ICD_VENDORS env var to select ICD drivers. > > > > > > something like 'OCD_ICD_VENDORS=/var/empty' (any directory other than > > > /etc/OpenCL/vendors will do) effectively disables OpenCL by reporting > > > 0 available platforms. > > > > It looks like an llvm8 not inlining everything properly bug. > > > > with llvm9 I just get a gpu hang when it does inline everything, but > > with 8 it fails to inline applyResizeFilter. > > > > llvm8 or some command line option passed to it might need a fix. > > Uggh changing the original CL C code in ImageMagic to static inline "fixes" > it. sounds a bit like https://reviews.llvm.org/D62707. static inline function might be internalized/marked alwaysinline. CLOVER_DEBUG=llvm would tell more. I'm not sure why it'd produce GPU hangs. It might be a llvm-git bug, my daily testing only covers CL piglits. Jan > > Dave. > > > Dave. > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Jan Vesely signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
I've started a thread on the llvm mailing list. See http://lists.llvm.org/pipermail/llvm-dev/2019-June/132750.html I don't know if it's needed, but if anyone has a commit in llvm that started this, that might be helpful. On Sat, Jun 1, 2019 at 10:56 PM Jan Vesely wrote: > > Hi, > > On Sat, 2019-06-01 at 18:21 -0400, James Harvey wrote: > > On Sat, Jun 1, 2019 at 6:19 PM James Harvey > > wrote: > > > On Tue, Feb 19, 2019 at 7:52 PM james harvey > > > wrote: > > > > Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled > > > > relocations". > > > > > > > > This has broken ImageMagick for many people using AMD graphics cards. > > > > See https://github.com/ImageMagick/ImageMagick/issues/1366 > > > > > > > > ImageMagick responded: "It looks like this error message is created by > > > > the mesa driver. I have no idea what causes this message and if there > > > > is anything what we could do to prevent this from happening." > > > > > > > > And, hasn't responded back for requests for what additional > > > > information I could tell mesa. > > > > > > > > I see the mesa commit is to prevent GPU hangs, so I'm all for the > > > > commit. > > > > > > > > I'm just asking what would need to be done by who to get ImageMagick > > > > working again, using opencl-mesa. Using opencl-amd has been a > > > > workaround for some people. Not sure if this is something mesa just > > > > hasn't implemented that opencl-amd has, or if it's something > > > > ImageMagick needs to do differently. > > > > > > Ping? Mesa + ImageMagick convert is broken, affecting lots of people, > > > but neither project is saying anything. > > > > Sorry all, please reply to this post rather than the last. Copy-paste > > failure of email addresses of people listed in mesa patch, fixed. > > sorry I missed the previous email. The issues has been discussed at > [0]. > > tldr; the referenced mesa commit prevents GPU hangs/crashes caused by > changes in LLVM. > > longer story: > AMDGPU llvm backend used to inline all function calls until llvm-6. > llvm-6+ uses functions calls and issues relocations for each function > invocation. unhandled relocations lead to GPU hangs/crashes. > either clover/mesa needs to handle relocations, or LLVM needs to stop > using relocations for internal symbols (they are not needed). > > I've neither time, nor energy, nor access to hw, to fix things up > every time AMD changes break something in clover, and nobody else has > stepped up. > moreover, mesa made it clear that volunteer contributions and needs > are inferior to corporate stakeholders (not even worth CI cycles). > thus, clover on amd gpus is in damage mitigation mode; errors are > better than crashes, crashes are better than hangs. > > Chances are that clover over NIR will work before the current issues > are fixed. > > regards, > Jan > > [0] https://bugs.freedesktop.org/show_bug.cgi?id=105113 > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- > Jan Vesely ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Mon, 3 Jun 2019 at 09:13, Dave Airlie wrote: > > On Sun, 2 Jun 2019 at 23:13, Jan Vesely wrote: > > > > On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote: > > > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen > > > wrote: > > > > On Sun, Jun 2, 2019 at 12:41 PM James Harvey > > > > wrote: > > > > > So, for people running amdgpu and wanting to run ImageMagick convert > > > > > who get this error... Does this mean there is something ImageMagick > > > > > could change to prevent the error? Or, in the meantime, is the only > > > > > option to install the amdgpu-pro opencl userspace driver with > > > > > ImageMagick? (The pro opencl driver can be extracted from amdgpu-pro > > > > > as a whole, and ran on top of the free amdgpu driver., without the > > > > > rest of amdgpu-pro installed - see Arch Linux AUR package opencl-amd.) > > > > > > > > So, does imagemagick actually need OpenCL? If not, you can probably > > > > also uninstall you mesa opencl distro package? > > > > > > The mesa opencl package works fine on other programs for me and > > > others, so uninstalling isn't an option. Not sure actually without > > > any OpenCL if it does it a different way or not. ImageMagick must be > > > all that's trying to call something problematic. > > > > It's basically any function call that was not inlined. It might even > > be in a different kernel in the same module. > > > > Recent mesa requires some kind of ICD loader to provide opencl. if > > your distro uses ocl-icd package to provide ICD loader, you can use > > OCL_ICD_VENDORS env var to select ICD drivers. > > > > something like 'OCD_ICD_VENDORS=/var/empty' (any directory other than > > /etc/OpenCL/vendors will do) effectively disables OpenCL by reporting > > 0 available platforms. > > It looks like an llvm8 not inlining everything properly bug. > > with llvm9 I just get a gpu hang when it does inline everything, but > with 8 it fails to inline applyResizeFilter. > > llvm8 or some command line option passed to it might need a fix. Uggh changing the original CL C code in ImageMagic to static inline "fixes" it. Dave. > > Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Sun, 2 Jun 2019 at 23:13, Jan Vesely wrote: > > On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote: > > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen > > wrote: > > > On Sun, Jun 2, 2019 at 12:41 PM James Harvey > > > wrote: > > > > So, for people running amdgpu and wanting to run ImageMagick convert > > > > who get this error... Does this mean there is something ImageMagick > > > > could change to prevent the error? Or, in the meantime, is the only > > > > option to install the amdgpu-pro opencl userspace driver with > > > > ImageMagick? (The pro opencl driver can be extracted from amdgpu-pro > > > > as a whole, and ran on top of the free amdgpu driver., without the > > > > rest of amdgpu-pro installed - see Arch Linux AUR package opencl-amd.) > > > > > > So, does imagemagick actually need OpenCL? If not, you can probably > > > also uninstall you mesa opencl distro package? > > > > The mesa opencl package works fine on other programs for me and > > others, so uninstalling isn't an option. Not sure actually without > > any OpenCL if it does it a different way or not. ImageMagick must be > > all that's trying to call something problematic. > > It's basically any function call that was not inlined. It might even > be in a different kernel in the same module. > > Recent mesa requires some kind of ICD loader to provide opencl. if > your distro uses ocl-icd package to provide ICD loader, you can use > OCL_ICD_VENDORS env var to select ICD drivers. > > something like 'OCD_ICD_VENDORS=/var/empty' (any directory other than > /etc/OpenCL/vendors will do) effectively disables OpenCL by reporting > 0 available platforms. It looks like an llvm8 not inlining everything properly bug. with llvm9 I just get a gpu hang when it does inline everything, but with 8 it fails to inline applyResizeFilter. llvm8 or some command line option passed to it might need a fix. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote: > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen > wrote: > > On Sun, Jun 2, 2019 at 12:41 PM James Harvey > > wrote: > > > So, for people running amdgpu and wanting to run ImageMagick convert > > > who get this error... Does this mean there is something ImageMagick > > > could change to prevent the error? Or, in the meantime, is the only > > > option to install the amdgpu-pro opencl userspace driver with > > > ImageMagick? (The pro opencl driver can be extracted from amdgpu-pro > > > as a whole, and ran on top of the free amdgpu driver., without the > > > rest of amdgpu-pro installed - see Arch Linux AUR package opencl-amd.) > > > > So, does imagemagick actually need OpenCL? If not, you can probably > > also uninstall you mesa opencl distro package? > > The mesa opencl package works fine on other programs for me and > others, so uninstalling isn't an option. Not sure actually without > any OpenCL if it does it a different way or not. ImageMagick must be > all that's trying to call something problematic. It's basically any function call that was not inlined. It might even be in a different kernel in the same module. Recent mesa requires some kind of ICD loader to provide opencl. if your distro uses ocl-icd package to provide ICD loader, you can use OCL_ICD_VENDORS env var to select ICD drivers. something like 'OCD_ICD_VENDORS=/var/empty' (any directory other than /etc/OpenCL/vendors will do) effectively disables OpenCL by reporting 0 available platforms. Jan -- Jan Vesely signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen wrote: > On Sun, Jun 2, 2019 at 12:41 PM James Harvey wrote: > > So, for people running amdgpu and wanting to run ImageMagick convert > > who get this error... Does this mean there is something ImageMagick > > could change to prevent the error? Or, in the meantime, is the only > > option to install the amdgpu-pro opencl userspace driver with > > ImageMagick? (The pro opencl driver can be extracted from amdgpu-pro > > as a whole, and ran on top of the free amdgpu driver., without the > > rest of amdgpu-pro installed - see Arch Linux AUR package opencl-amd.) > > So, does imagemagick actually need OpenCL? If not, you can probably > also uninstall you mesa opencl distro package? The mesa opencl package works fine on other programs for me and others, so uninstalling isn't an option. Not sure actually without any OpenCL if it does it a different way or not. ImageMagick must be all that's trying to call something problematic. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Sun, Jun 2, 2019 at 12:41 PM James Harvey wrote: > > On Sat, Jun 1, 2019 at 10:56 PM Jan Vesely wrote: > > On Sat, 2019-06-01 at 18:21 -0400, James Harvey wrote: > > > On Sat, Jun 1, 2019 at 6:19 PM James Harvey > > > wrote: > > > > On Tue, Feb 19, 2019 at 7:52 PM james harvey > > > > wrote: > > > > > Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled > > > > > relocations". > > > > > > > > > > This has broken ImageMagick for many people using AMD graphics cards. > > > > > See https://github.com/ImageMagick/ImageMagick/issues/1366 > > > > > > > > > > ImageMagick responded: "It looks like this error message is created by > > > > > the mesa driver. I have no idea what causes this message and if there > > > > > is anything what we could do to prevent this from happening." > > > > > > > > > > And, hasn't responded back for requests for what additional > > > > > information I could tell mesa. > > > > > > > > > > I see the mesa commit is to prevent GPU hangs, so I'm all for the > > > > > commit. > > > > > > > > > > I'm just asking what would need to be done by who to get ImageMagick > > > > > working again, using opencl-mesa. Using opencl-amd has been a > > > > > workaround for some people. Not sure if this is something mesa just > > > > > hasn't implemented that opencl-amd has, or if it's something > > > > > ImageMagick needs to do differently. > > > > > > > > Ping? Mesa + ImageMagick convert is broken, affecting lots of people, > > > > but neither project is saying anything. > > > > > > Sorry all, please reply to this post rather than the last. Copy-paste > > > failure of email addresses of people listed in mesa patch, fixed. > > > > sorry I missed the previous email. The issues has been discussed at > > [0]. > > tldr; the referenced mesa commit prevents GPU hangs/crashes caused by > > changes in LLVM. > > > > longer story: > > AMDGPU llvm backend used to inline all function calls until llvm-6. > > llvm-6+ uses functions calls and issues relocations for each function > > invocation. unhandled relocations lead to GPU hangs/crashes. > > either clover/mesa needs to handle relocations, or LLVM needs to stop > > using relocations for internal symbols (they are not needed). > > > > I've neither time, nor energy, nor access to hw, to fix things up > > every time AMD changes break something in clover, and nobody else has > > stepped up. > > moreover, mesa made it clear that volunteer contributions and needs > > are inferior to corporate stakeholders (not even worth CI cycles). > > thus, clover on amd gpus is in damage mitigation mode; errors are > > better than crashes, crashes are better than hangs. > > > > Chances are that clover over NIR will work before the current issues > > are fixed. > > > > regards, > > Jan > > > No problem at all! Truly, thanks for your time on the project. I've > had enough run-ins with AMD's frequent breakage as just an end user. > Can't imagine how much worse it is for you and all mesa dev's. > > So, for people running amdgpu and wanting to run ImageMagick convert > who get this error... Does this mean there is something ImageMagick > could change to prevent the error? Or, in the meantime, is the only > option to install the amdgpu-pro opencl userspace driver with > ImageMagick? (The pro opencl driver can be extracted from amdgpu-pro > as a whole, and ran on top of the free amdgpu driver., without the > rest of amdgpu-pro installed - see Arch Linux AUR package opencl-amd.) So, does imagemagick actually need OpenCL? If not, you can probably also uninstall you mesa opencl distro package? > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Sat, Jun 1, 2019 at 10:56 PM Jan Vesely wrote: > On Sat, 2019-06-01 at 18:21 -0400, James Harvey wrote: > > On Sat, Jun 1, 2019 at 6:19 PM James Harvey > > wrote: > > > On Tue, Feb 19, 2019 at 7:52 PM james harvey > > > wrote: > > > > Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled > > > > relocations". > > > > > > > > This has broken ImageMagick for many people using AMD graphics cards. > > > > See https://github.com/ImageMagick/ImageMagick/issues/1366 > > > > > > > > ImageMagick responded: "It looks like this error message is created by > > > > the mesa driver. I have no idea what causes this message and if there > > > > is anything what we could do to prevent this from happening." > > > > > > > > And, hasn't responded back for requests for what additional > > > > information I could tell mesa. > > > > > > > > I see the mesa commit is to prevent GPU hangs, so I'm all for the > > > > commit. > > > > > > > > I'm just asking what would need to be done by who to get ImageMagick > > > > working again, using opencl-mesa. Using opencl-amd has been a > > > > workaround for some people. Not sure if this is something mesa just > > > > hasn't implemented that opencl-amd has, or if it's something > > > > ImageMagick needs to do differently. > > > > > > Ping? Mesa + ImageMagick convert is broken, affecting lots of people, > > > but neither project is saying anything. > > > > Sorry all, please reply to this post rather than the last. Copy-paste > > failure of email addresses of people listed in mesa patch, fixed. > > sorry I missed the previous email. The issues has been discussed at > [0]. > tldr; the referenced mesa commit prevents GPU hangs/crashes caused by > changes in LLVM. > > longer story: > AMDGPU llvm backend used to inline all function calls until llvm-6. > llvm-6+ uses functions calls and issues relocations for each function > invocation. unhandled relocations lead to GPU hangs/crashes. > either clover/mesa needs to handle relocations, or LLVM needs to stop > using relocations for internal symbols (they are not needed). > > I've neither time, nor energy, nor access to hw, to fix things up > every time AMD changes break something in clover, and nobody else has > stepped up. > moreover, mesa made it clear that volunteer contributions and needs > are inferior to corporate stakeholders (not even worth CI cycles). > thus, clover on amd gpus is in damage mitigation mode; errors are > better than crashes, crashes are better than hangs. > > Chances are that clover over NIR will work before the current issues > are fixed. > > regards, > Jan No problem at all! Truly, thanks for your time on the project. I've had enough run-ins with AMD's frequent breakage as just an end user. Can't imagine how much worse it is for you and all mesa dev's. So, for people running amdgpu and wanting to run ImageMagick convert who get this error... Does this mean there is something ImageMagick could change to prevent the error? Or, in the meantime, is the only option to install the amdgpu-pro opencl userspace driver with ImageMagick? (The pro opencl driver can be extracted from amdgpu-pro as a whole, and ran on top of the free amdgpu driver., without the rest of amdgpu-pro installed - see Arch Linux AUR package opencl-amd.) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
clover is not supported by AMD officially, because AMD has its own OpenCL driver called ROCm. Marek On Sat, Jun 1, 2019, 10:56 PM Jan Vesely wrote: > Hi, > > On Sat, 2019-06-01 at 18:21 -0400, James Harvey wrote: > > On Sat, Jun 1, 2019 at 6:19 PM James Harvey > wrote: > > > On Tue, Feb 19, 2019 at 7:52 PM james harvey > wrote: > > > > Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled > > > > relocations". > > > > > > > > This has broken ImageMagick for many people using AMD graphics cards. > > > > See https://github.com/ImageMagick/ImageMagick/issues/1366 > > > > > > > > ImageMagick responded: "It looks like this error message is created > by > > > > the mesa driver. I have no idea what causes this message and if there > > > > is anything what we could do to prevent this from happening." > > > > > > > > And, hasn't responded back for requests for what additional > > > > information I could tell mesa. > > > > > > > > I see the mesa commit is to prevent GPU hangs, so I'm all for the > commit. > > > > > > > > I'm just asking what would need to be done by who to get ImageMagick > > > > working again, using opencl-mesa. Using opencl-amd has been a > > > > workaround for some people. Not sure if this is something mesa just > > > > hasn't implemented that opencl-amd has, or if it's something > > > > ImageMagick needs to do differently. > > > > > > Ping? Mesa + ImageMagick convert is broken, affecting lots of people, > > > but neither project is saying anything. > > > > Sorry all, please reply to this post rather than the last. Copy-paste > > failure of email addresses of people listed in mesa patch, fixed. > > sorry I missed the previous email. The issues has been discussed at > [0]. > > tldr; the referenced mesa commit prevents GPU hangs/crashes caused by > changes in LLVM. > > longer story: > AMDGPU llvm backend used to inline all function calls until llvm-6. > llvm-6+ uses functions calls and issues relocations for each function > invocation. unhandled relocations lead to GPU hangs/crashes. > either clover/mesa needs to handle relocations, or LLVM needs to stop > using relocations for internal symbols (they are not needed). > > I've neither time, nor energy, nor access to hw, to fix things up > every time AMD changes break something in clover, and nobody else has > stepped up. > moreover, mesa made it clear that volunteer contributions and needs > are inferior to corporate stakeholders (not even worth CI cycles). > thus, clover on amd gpus is in damage mitigation mode; errors are > better than crashes, crashes are better than hangs. > > Chances are that clover over NIR will work before the current issues > are fixed. > > regards, > Jan > > [0] https://bugs.freedesktop.org/show_bug.cgi?id=105113 > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- > Jan Vesely > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
Hi, On Sat, 2019-06-01 at 18:21 -0400, James Harvey wrote: > On Sat, Jun 1, 2019 at 6:19 PM James Harvey wrote: > > On Tue, Feb 19, 2019 at 7:52 PM james harvey > > wrote: > > > Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled > > > relocations". > > > > > > This has broken ImageMagick for many people using AMD graphics cards. > > > See https://github.com/ImageMagick/ImageMagick/issues/1366 > > > > > > ImageMagick responded: "It looks like this error message is created by > > > the mesa driver. I have no idea what causes this message and if there > > > is anything what we could do to prevent this from happening." > > > > > > And, hasn't responded back for requests for what additional > > > information I could tell mesa. > > > > > > I see the mesa commit is to prevent GPU hangs, so I'm all for the commit. > > > > > > I'm just asking what would need to be done by who to get ImageMagick > > > working again, using opencl-mesa. Using opencl-amd has been a > > > workaround for some people. Not sure if this is something mesa just > > > hasn't implemented that opencl-amd has, or if it's something > > > ImageMagick needs to do differently. > > > > Ping? Mesa + ImageMagick convert is broken, affecting lots of people, > > but neither project is saying anything. > > Sorry all, please reply to this post rather than the last. Copy-paste > failure of email addresses of people listed in mesa patch, fixed. sorry I missed the previous email. The issues has been discussed at [0]. tldr; the referenced mesa commit prevents GPU hangs/crashes caused by changes in LLVM. longer story: AMDGPU llvm backend used to inline all function calls until llvm-6. llvm-6+ uses functions calls and issues relocations for each function invocation. unhandled relocations lead to GPU hangs/crashes. either clover/mesa needs to handle relocations, or LLVM needs to stop using relocations for internal symbols (they are not needed). I've neither time, nor energy, nor access to hw, to fix things up every time AMD changes break something in clover, and nobody else has stepped up. moreover, mesa made it clear that volunteer contributions and needs are inferior to corporate stakeholders (not even worth CI cycles). thus, clover on amd gpus is in damage mitigation mode; errors are better than crashes, crashes are better than hangs. Chances are that clover over NIR will work before the current issues are fixed. regards, Jan [0] https://bugs.freedesktop.org/show_bug.cgi?id=105113 > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Jan Vesely signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Sat, Jun 1, 2019 at 6:19 PM James Harvey wrote: > > On Tue, Feb 19, 2019 at 7:52 PM james harvey wrote: > > > > Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled > > relocations". > > > > This has broken ImageMagick for many people using AMD graphics cards. > > See https://github.com/ImageMagick/ImageMagick/issues/1366 > > > > ImageMagick responded: "It looks like this error message is created by > > the mesa driver. I have no idea what causes this message and if there > > is anything what we could do to prevent this from happening." > > > > And, hasn't responded back for requests for what additional > > information I could tell mesa. > > > > I see the mesa commit is to prevent GPU hangs, so I'm all for the commit. > > > > I'm just asking what would need to be done by who to get ImageMagick > > working again, using opencl-mesa. Using opencl-amd has been a > > workaround for some people. Not sure if this is something mesa just > > hasn't implemented that opencl-amd has, or if it's something > > ImageMagick needs to do differently. > > Ping? Mesa + ImageMagick convert is broken, affecting lots of people, > but neither project is saying anything. Sorry all, please reply to this post rather than the last. Copy-paste failure of email addresses of people listed in mesa patch, fixed. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Error: unsupported relocations
On Tue, Feb 19, 2019 at 7:52 PM james harvey wrote: > > Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled > relocations". > > This has broken ImageMagick for many people using AMD graphics cards. > See https://github.com/ImageMagick/ImageMagick/issues/1366 > > ImageMagick responded: "It looks like this error message is created by > the mesa driver. I have no idea what causes this message and if there > is anything what we could do to prevent this from happening." > > And, hasn't responded back for requests for what additional > information I could tell mesa. > > I see the mesa commit is to prevent GPU hangs, so I'm all for the commit. > > I'm just asking what would need to be done by who to get ImageMagick > working again, using opencl-mesa. Using opencl-amd has been a > workaround for some people. Not sure if this is something mesa just > hasn't implemented that opencl-amd has, or if it's something > ImageMagick needs to do differently. Ping? Mesa + ImageMagick convert is broken, affecting lots of people, but neither project is saying anything. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Error: unsupported relocations
Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled relocations". This has broken ImageMagick for many people using AMD graphics cards. See https://github.com/ImageMagick/ImageMagick/issues/1366 ImageMagick responded: "It looks like this error message is created by the mesa driver. I have no idea what causes this message and if there is anything what we could do to prevent this from happening." And, hasn't responded back for requests for what additional information I could tell mesa. I see the mesa commit is to prevent GPU hangs, so I'm all for the commit. I'm just asking what would need to be done by who to get ImageMagick working again, using opencl-mesa. Using opencl-amd has been a workaround for some people. Not sure if this is something mesa just hasn't implemented that opencl-amd has, or if it's something ImageMagick needs to do differently. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
