Bug 93748 - [r600g]OpenCL driver causes ImageMagick display command to segfault
Summary: [r600g]OpenCL driver causes ImageMagick display command to segfault
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:
 
Reported: 2016-01-18 00:39 UTC by nixscripter
Modified: 2016-05-30 20:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Output of /usr/bin/display (2.28 KB, text/plain)
2016-01-18 00:39 UTC, nixscripter
Details
GenerateNoiseImage kernel (2.35 KB, text/plain)
2016-01-19 02:33 UTC, nixscripter
Details
AddNoise backtrace for IMv7 Git (2.23 KB, text/plain)
2016-05-30 17:44 UTC, nixscripter
Details

Description nixscripter 2016-01-18 00:39:47 UTC
Created attachment 121096 [details]
Output of /usr/bin/display

If I compile ImageMagick with OpenCL support, and use the display utility to view any image, the program segfaults before anything is rendered with the attached LLVM error.

I'm using ImageMagick 6.2.9.6, though it has failed on several previous versions also.

The relevant piece of source code is in magick/accelerate.c, a gigantic list of OpenCL stuff (which I must admit I am ill-equipped to read). The function it complains about, GenerateNoiseImage, seems to start on line 428.

I'm using LLVM r254897 from SVN, and Mesa commit 9214664 (r74971).

My card is:
Advanced Micro Devices, Inc. [AMD/ATI] Juniper PRO [Radeon HD 6750]

Please let me know if you need more information.
Comment 1 Jan Vesely 2016-01-18 15:57:06 UTC
Hi,

I had trouble locating the kernel. There's a git repo nd 6.9.X.Y release tarballs. Unfortunately imagemagick does not tag releases. Do you know the git commit that corresponds to to 6.2.9.6?

posting the corresponding __kernel function would suffice too.
Comment 2 nixscripter 2016-01-19 02:33:51 UTC
Created attachment 121124 [details]
GenerateNoiseImage kernel

Here is their kernel. It's rather ugly.

It has a lot of macros (like ClamptoQuantum) and functions running on the host (mwcGenerateDifferentialNoise is elsewhere in the same file), but perhaps if it's an LLVM assembler bug those don't matter.

The initialization code for the OpenCL context, by the way, is entirely separate and also rather ugly (I presume so they can load it early and "drop it in" when needed).

Here is a link to the source of my exact version (which I know is old, sorry about that) so you can look at any surrounding context necessary:

http://distfiles.icmpv6.org/distfiles/ImageMagick-6.9.2-6.tar.xz

Note that this kernel can be found in magick/accelerate-private.h -- the error pointing to magick/accelerate.c is where the kernel is initialized.
Comment 3 nixscripter 2016-05-30 17:44:24 UTC
Created attachment 124178 [details]
AddNoise backtrace for IMv7 Git

In order to assist with this issue, I tried upgrading to the Git Version of Imagemagick, available on GitHub:

https://github.com/ImageMagick/ImageMagick

ImageMagick master commit 5fb7d58 still fails with LLVM revision 264388 and Mesa commit 511ce29. (I upgrade to the latest revisions every week or two, just in case this issue could be fixed without me noticing.)

However, the traceback is now quite different, and the image does display -- for just a moment while they do some operation subsequently which makes it segfault. Now it's in the AddNose kernel.

Hopefully the source version will make the issue easier to reproduce/debug.
Comment 4 nixscripter 2016-05-30 17:48:57 UTC
Oh, and before I forget, The AddNoise kernel is in MagickCore/accelerate.c, starting on line 499.
Comment 5 nixscripter 2016-05-30 17:56:48 UTC
Correction, make that MagickCore/accelerate-kernels-private.h, starting on line 798. (Argh...)
Comment 6 Jan Vesely 2016-05-30 18:34:47 UTC
based on the LLVM dump something is trying to do v2 load.

Do you know what noise type is used?
Guassian noise in that kernel uses sinpi and cospi which use v2float (float load is the same as int).

can you try newer llvm version?
proper constant address space loads were implemented in r269481. it fixed builtin functions that rely on tables, like sinpi/cospi.
Comment 7 nixscripter 2016-05-30 20:27:15 UTC
I upgraded LLVM to r271203, past the version you suggested, and it does indeed fix the issue! Thanks!

Closing as FIXED.


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.