All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 108272] [polaris10] opencl-mesa: Anything using OpenCL segfaults, XFX Radeon RX 580
Date: Thu, 01 Nov 2018 04:33:33 +0000	[thread overview]
Message-ID: <bug-108272-502-IBiHG7EVi1@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-108272-502@http.bugs.freedesktop.org/>


[-- Attachment #1.1: Type: text/plain, Size: 4448 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=108272

--- Comment #11 from jamespharvey20@gmail.com ---
When I originally filed this, I assumed it was 1 bug since I tried 2 things
with OpenCL, and both failed with opencl-mesa but worked with opencl-amd.

Jan Vesely was correct that there were two separate problems.

I'm hoping Jan Vesely can give guidance on whether to leave this bug open for
any of the reasons below, or if I should close it and potentially open up 1-2
new bugs.

The original luxmark bug (segfault) is solved, but that exposes 2 new
opencl-mesa bugs when running luxmark.

The original IndigoBenchmark bug (segfault) isn't solved, but as explained
below, I understand if we have to consider that unsolvable for now.

I don't think this affects any of these bugs, but I'll mention a few weeks ago,
I switched back to my Asus Radeon R9 390.  The same behaviors discussed in this
entire bug report occur.  (i.e. 18.2.3 and before crash luxmark.)  If someone
really wants me to do so, I can switch back to the RX 580 to test 18.2.4, but
I'm betting since it works properly with the R9 390 that the problem is fixed.

ORIGINAL LUXMARK BUG #1
-----------------------------------------

Using mesa 18.2.4, the luxmark segfault is solved.

NEW - LUXMARK BUG #2
------------------------------------

Jan Vesely's comment on 2018-10-09 mentions: "bumping MAX_GLOBAL_BUFFERS to 32
allows luxmark to run, albeit still with many incorrect pixels -- libclc
rounding conversions are incorrect."

That's what I'm seeing out of 18.2.4.  Using LuxBall HDR (Simple Benchmark):

MESA 18.2.4: 40626 (Image validation OK (65739 different pixels, 10.27%)

AMDGPU-PRO: 15739 (Image validation OK (5736 different pixels, 0.90%)

There's no typos there.  opencl-mesa scores almost unbelievably higher than
opencl-amd, but the different pixels percentage increases by a factor of 11.4.

As Jan's other comment on 2018-10-09 mentions, the image looks garbled and the
results are incorrect.

Not sure if this bug should be left open for this issue, or if I should create
a new bug.  (Or, if there is a bug already open for it.)  Or, if mesa will say
it's purely libclc's problem, and to go to them about it.

NEW - LUXMARK BUG #3
------------------------------------

Although luxmark can now benchmark, when doing so, all input becomes unusably
awful.  It reminds me of when Windows has too many things open, suddenly
decided it can't cope, and you're waiting to see if it's going to recover or
crash.  Keystrokes take too long to be printed, and the mouse becomes slow and
jumpy.  Top shows cpu and memory usage are fine, which was my first thought. 
BTW, running xf86-video-amdgpu 18.1.0, and when I upgraded mesa, it was both
mesa and opencl-mesa.

In comparison, if I use opencl-amd, input is not affected.  I wouldn't even
know the GPU is being slammed.

Using the program radeontop, I can see when using mesa, "Graphics pipe",
"Texture Addresser", and "Shader Interpolator" are between 95-100%, usually
98-100%.

When using opencl-amd, radeontop shows the same.  (Granted, Vertex Grouper +
Tesselator / Shader Export/Scan Converter/Depth Block/Color Block bounce
between 5-20% vs on opencl-mesa, they bounce between 1-5%.)

INDIGO BUG
------------------

I edited 18.2.4's si_get.c to be very short:

    snprintf(sscreen->renderer_string, sizeof(sscreen->renderer_string),
       "%s",
       chip_name);

And compiled/installed it, but it didn't affect the crash.

IndigoBenchmark said they're statically linking with LLVM 3.4, which is quite
old.  But, it runs fine with opencl-amd, and only crashes on opencl-mesa.  I
just posted a followup "where do we go from here"-ish comment there which has
to be moderator approved so isn't showing yet. 
 https://www.indigorenderer.com/forum/viewtopic.php?f=37&t=14986

Part of me thinks it needs to be given up on, being a closed-source precompiled
binary statically linked against LLVM 3.4.

Part of me thinks since it only crashes with opencl-mesa, and runs perfectly
fine with opencl-amd, there's probably (but not definitely) a bug in
opencl-mesa.

But, I understand since they don't seem to be paying this any attention, we may
have to give up on the Indigo Bug as being unable to be realistically
investigated further.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 5914 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2018-11-01  4:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-08  8:26 [Bug 108272] opencl-mesa: Anything using OpenCL segfaults, XFX Radeon RX 580 bugzilla-daemon
2018-10-08  8:27 ` bugzilla-daemon
2018-10-08  8:28 ` bugzilla-daemon
2018-10-08  8:28 ` bugzilla-daemon
2018-10-08  8:29 ` bugzilla-daemon
2018-10-08 21:08 ` [Bug 108272] [polaris10] " bugzilla-daemon
2018-10-08 21:10 ` bugzilla-daemon
2018-10-08 21:25 ` bugzilla-daemon
2018-10-09  2:54 ` bugzilla-daemon
2018-10-09  8:32 ` bugzilla-daemon
2018-10-09  8:34 ` bugzilla-daemon
2018-10-09 17:42 ` bugzilla-daemon
2018-10-19 18:00 ` bugzilla-daemon
2018-10-31 18:59 ` bugzilla-daemon
2018-11-01  4:33 ` bugzilla-daemon [this message]
2018-12-17 17:46 ` bugzilla-daemon
2019-09-25 18:10 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-108272-502-IBiHG7EVi1@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.