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
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 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 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
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
Re: [Mesa-dev] [PATCH 1/2] st/nine: Fix issue with surface and volume dtors and csmt
Hi Axel,
EVE Online is no longer crashing for me with these patches.
Thanks!
Tested-by: James Harvey <lothmor...@gmail.com>
On 03/15/2017 02:56 PM, Axel Davy wrote:
> Surfaces and Volumes can be freed in the worker thread.
>
> This fixes these dtor.
> Especially if they were freed by nine_context_box_upload,
> the counter was decremented after the destructions, which
> lead to deadlock.
>
> Fixes bugzilla 99246.
>
> CC: "17.0" <mesa-sta...@lists.freedesktop.org>
> Signed-off-by: Axel Davy <axel.d...@ens.fr>
> ---
> src/gallium/state_trackers/nine/nine_csmt_helper.h | 2 +-
> src/gallium/state_trackers/nine/surface9.c | 10 --
> src/gallium/state_trackers/nine/volume9.c | 10 --
> 3 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/nine/nine_csmt_helper.h
> b/src/gallium/state_trackers/nine/nine_csmt_helper.h
> index b0bbc054fc..dc46bbd3a2 100644
> --- a/src/gallium/state_trackers/nine/nine_csmt_helper.h
> +++ b/src/gallium/state_trackers/nine/nine_csmt_helper.h
> @@ -233,8 +233,8 @@ name##_rx( struct NineDevice9 *device, struct
> csmt_instruction *instr ) \
> name##_priv( \
> device ARGS_FOR_CALL( __VA_ARGS__ ) \
> ); \
> -ARGS_FOR_UNBIND( __VA_ARGS__ ) \
> p_atomic_dec(args->counter); \
> +ARGS_FOR_UNBIND( __VA_ARGS__ ) \
> return 0; \
> } \
> \
> diff --git a/src/gallium/state_trackers/nine/surface9.c
> b/src/gallium/state_trackers/nine/surface9.c
> index 836369cafd..d917fa1f86 100644
> --- a/src/gallium/state_trackers/nine/surface9.c
> +++ b/src/gallium/state_trackers/nine/surface9.c
> @@ -204,9 +204,15 @@ NineSurface9_dtor( struct NineSurface9 *This )
> {
> DBG("This=%p\n", This);
>
> -if (This->transfer)
> -NineSurface9_UnlockRect(This);
> +if (This->transfer) {
> +struct pipe_context *pipe =
> nine_context_get_pipe_multithread(This->base.base.device);
> +pipe->transfer_unmap(pipe, This->transfer);
> +This->transfer = NULL;
> +}
>
> +/* Note: Following condition cannot happen currently, since we
> + * refcount the surface in the functions increasing
> + * pending_uploads_counter. */
> if (p_atomic_read(>pending_uploads_counter))
> nine_csmt_process(This->base.base.device);
>
> diff --git a/src/gallium/state_trackers/nine/volume9.c
> b/src/gallium/state_trackers/nine/volume9.c
> index 11236a02e7..62af3e6225 100644
> --- a/src/gallium/state_trackers/nine/volume9.c
> +++ b/src/gallium/state_trackers/nine/volume9.c
> @@ -142,9 +142,15 @@ NineVolume9_dtor( struct NineVolume9 *This )
> {
> DBG("This=%p\n", This);
>
> -if (This->transfer)
> -NineVolume9_UnlockBox(This);
> +if (This->transfer) {
> +struct pipe_context *pipe =
> nine_context_get_pipe_multithread(This->base.device);
> +pipe->transfer_unmap(pipe, This->transfer);
> +This->transfer = NULL;
> +}
>
> +/* Note: Following condition cannot happen currently, since we
> + * refcount the volume in the functions increasing
> + * pending_uploads_counter. */
> if (p_atomic_read(>pending_uploads_counter))
> nine_csmt_process(This->base.device);
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 0/5] r600/radeonsi/st/mesa: use DDIV instead of DRCP + DMUL
Hi Nicolai,
I tested your branch against mesa-13.0.3 on my CYPRESS HD5850. It's an
r600 with doubles, but looks like this code might be only for cayman and
up? Either way, all the fs-op-div tests pass.
./piglit -o -s -c run all -t fs-op-div*
summary:
name: fs-op-div-pre fs-op-div-post
- --
pass: 142142
fail: 0 0
crash: 0 0
skip:10 10
Thanks,
James Harvey
On 01/19/2017 05:59 AM, Nicolai Hähnle wrote:
> Hi all,
>
> here's a v2 without the pipe cap. Reminder: this requires DDIV support in
> nvc0, r600, and radeonsi.
>
> Ilia took care of nvc0, and I already did radeonsi. The thing is, it turns
> out I don't have an R600 that does double-precision. So testing would be
> very much appreciated, e.g. using
>
>
> piglit/generated_tests/spec/arb_gpu_shader_fp64/execution/built-in-functions/fs-op-div-*.shader_test
>
> You can find this series at https://cgit.freedesktop.org/~nh/mesa/log/?h=ddiv
> Otherwise, I may have to go back to the pipe cap variant :/
>
> Please review!
> Nicolai
>
> ___
> 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] [PATCH 0/2] r600g: Pair of small code clean ups with TGSI
Hi Rhys, I ran piglit on my Evergreen HD5850 with your patches. No regressions here. Tested-by: James Harvey <lothmor...@gmail.com> Thanks, James On 08/27/2016 09:05 AM, Rhys Kidd wrote: Having run Mesa through Clang on Eric Anholt's Travis harness, these small code clean ups improve readability of TGSI code in r600g and may avoid future problems. Series also can be found at: https://github.com/Echelon9/mesa/tree/fix/r600g-cleanup-tgsi-opcodes I don't have the hardware to test this so would appreciated Tested-by's. I do not have commit rights to fd.o so after R-B would appreciate if the reviewer(s) could push to master. Rhys Kidd (2): r600g: Avoid duplicated initialization of TGSI_OPCODE_DFMA r600g: Clean up defined magic numbers for TGSI opcodes src/gallium/drivers/r600/r600_shader.c | 18 +- src/gallium/include/pipe/p_shader_tokens.h | 1 + 2 files changed, 10 insertions(+), 9 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
