[Bug 99013] [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for fs interpolation" makes system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=99013
Bug ID: 99013 Summary: [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for fs interpolation" makes system unusable Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: alexandre.f.demers@gmail.com QA Contact: dri-devel@lists.freedesktop.org
Using an R9 280X kernel 4.8.12 (radeonsi driver)
LLVM 4.0.0svn r288795 Latest drm from git latest ddx ati from git
When compiling mesa commit 4c8c13b3, the system is unusable. Reverting to the previous commit fix the behavior.
My screen displays a fixed background followed by a black flash and a refresh every few seconds once logged in Gnome 3.
Switching to a terminal shows rings hanging and diving into systemd's journal, I see a lot of the following:
déc 06 23:23:47 Xander kernel: ------------[ cut here ]------------ déc 06 23:23:47 Xander kernel: WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/radeon/radeon_objec déc 06 23:23:47 Xander kernel: Modules linked in: fuse nls_iso8859_1 nls_cp437 vfat fat kvm_am déc 06 23:23:47 Xander kernel: ehci_hcd libata usbcore scsi_mod usb_common i8042 serio i915 i déc 06 23:23:47 Xander kernel: CPU: 1 PID: 650 Comm: Xorg Tainted: G D W 4.8.12-2-A déc 06 23:23:47 Xander kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5 déc 06 23:23:47 Xander kernel: 0000000000000286 00000000e7a1a4fc ffff880406243b40 ffffffff812 déc 06 23:23:47 Xander kernel: 0000000000000000 0000000000000000 ffff880406243b80 ffffffff810 déc 06 23:23:47 Xander kernel: 0000005400000001 ffff8803e57f5468 ffffffffffffffff ffff8803e57 déc 06 23:23:47 Xander kernel: Call Trace: déc 06 23:23:47 Xander kernel: [<ffffffff812fde90>] dump_stack+0x63/0x83 déc 06 23:23:47 Xander kernel: [<ffffffff8107c85b>] __warn+0xcb/0xf0 déc 06 23:23:47 Xander kernel: [<ffffffff8107c98d>] warn_slowpath_null+0x1d/0x20 déc 06 23:23:47 Xander kernel: [<ffffffffa00ff09a>] radeon_ttm_bo_destroy+0xea/0xf0 [radeon] déc 06 23:23:47 Xander kernel: [<ffffffffa006b7fb>] ttm_bo_release_list+0xcb/0x220 [ttm] déc 06 23:23:47 Xander kernel: [<ffffffffa0073780>] ? ttm_bo_man_put_node+0x40/0x50 [ttm] déc 06 23:23:47 Xander kernel: [<ffffffffa006c5bf>] ttm_bo_unref+0x1af/0x220 [ttm] déc 06 23:23:47 Xander kernel: [<ffffffffa00ff5d9>] radeon_bo_unref+0x39/0x70 [radeon] déc 06 23:23:47 Xander kernel: [<ffffffffa01124f7>] radeon_gem_object_free+0x57/0x70 [radeon] déc 06 23:23:47 Xander kernel: [<ffffffffa00048a9>] drm_gem_object_free+0x29/0x70 [drm] déc 06 23:23:47 Xander kernel: [<ffffffffa000492a>] drm_gem_object_unreference_unlocked+0x3a/ déc 06 23:23:47 Xander kernel: [<ffffffffa0004a55>] drm_gem_object_handle_unreference_unlocke déc 06 23:23:47 Xander kernel: [<ffffffffa0005025>] drm_gem_object_release_handle+0x55/0xa0 [ déc 06 23:23:47 Xander kernel: [<ffffffff812fe912>] idr_for_each+0xb2/0x110 déc 06 23:23:47 Xander kernel: [<ffffffffa0004fd0>] ? drm_gem_object_init+0x40/0x40 [drm] déc 06 23:23:47 Xander kernel: [<ffffffffa0005820>] drm_gem_release+0x20/0x30 [drm] déc 06 23:23:47 Xander kernel: [<ffffffffa00047c2>] drm_release+0x2c2/0x380 [drm] déc 06 23:23:47 Xander kernel: [<ffffffff8120b4ff>] __fput+0x9f/0x1e0 déc 06 23:23:47 Xander kernel: [<ffffffff8120b67e>] ____fput+0xe/0x10 déc 06 23:23:47 Xander kernel: [<ffffffff8109a0d0>] task_work_run+0x80/0xa0 déc 06 23:23:47 Xander kernel: [<ffffffff810806e2>] do_exit+0x2c2/0xb50 déc 06 23:23:47 Xander kernel: [<ffffffff81003016>] ? ___preempt_schedule+0x16/0x18 déc 06 23:23:47 Xander kernel: [<ffffffff81080feb>] do_group_exit+0x3b/0xb0 déc 06 23:23:47 Xander kernel: [<ffffffff81081074>] SyS_exit_group+0x14/0x20 déc 06 23:23:47 Xander kernel: [<ffffffff815f8032>] entry_SYSCALL_64_fastpath+0x1a/0xa4 déc 06 23:23:47 Xander kernel: ---[ end trace 44dfe616ce5e8b1c ]---
https://bugs.freedesktop.org/show_bug.cgi?id=99013
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTABUG Status|NEW |RESOLVED
--- Comment #1 from Michel Dänzer michel@daenzer.net --- (In reply to Alexandre Demers from comment #0)
LLVM 4.0.0svn r288795
The Mesa commit you bisected requires LLVM SVN r288865 ("AMDGPU: Add llvm.amdgcn.interp.mov intrinsic") or newer.
https://bugs.freedesktop.org/show_bug.cgi?id=99013
--- Comment #2 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to Michel Dänzer from comment #1)
(In reply to Alexandre Demers from comment #0)
LLVM 4.0.0svn r288795
The Mesa commit you bisected requires LLVM SVN r288865 ("AMDGPU: Add llvm.amdgcn.interp.mov intrinsic") or newer.
Isn't there a check done against LLVM's version? Does it have the needed granularity to point to a given a commit/revision?
https://bugs.freedesktop.org/show_bug.cgi?id=99013
--- Comment #3 from Marek Olšák maraeo@gmail.com --- Older LLVM from svn is officially unsupported. Latest LLVM from svn usually works with Mesa git, but not always.
https://bugs.freedesktop.org/show_bug.cgi?id=99013
--- Comment #4 from Christoph Haag haagch@frickel.club --- Which makes bisecting a lot harder, but understandable that the devs don't want to have the burden of having many intermediate workarounds in the code that's not used for any of the actual llvm releases.
But what I came here to say is that I have llvm 3.9.0 from the Archlinux Repos and this commit breaks everything for me too.
https://bugs.freedesktop.org/show_bug.cgi?id=99013
--- Comment #5 from Michel Dänzer michel@daenzer.net --- (In reply to Christoph Haag from comment #4)
Which makes bisecting a lot harder, but understandable that the devs don't want to have the burden of having many intermediate workarounds in the code that's not used for any of the actual llvm releases.
It's not about what we want — there's simply no way to know which SVN revision of LLVM we're building against. So it's not possible for Mesa to work with LLVM SVN snapshots both before and after incompatible API changes. All we can try to ensure is that current Mesa Git master works with current LLVM SVN trunk.
But what I came here to say is that I have llvm 3.9.0 from the Archlinux Repos and this commit breaks everything for me too.
Fixed in https://cgit.freedesktop.org/mesa/mesa/commit/?id=26ba8c920d2727cae8ab45096d... .
https://bugs.freedesktop.org/show_bug.cgi?id=99013
--- Comment #6 from Christoph Haag haagch@frickel.club --- The build system already uses llvm-config --version which contains the revision for svn versions. Of course it breaks when you update llvm without rebuilding mesa, and you probably don't want to run llvm-config --version every time the mesa libraries are loaded, so yea...
Anyway
Fixed in https://cgit.freedesktop.org/mesa/mesa/commit/ ?id=26ba8c920d2727cae8ab45096db70e4691b00245 .
Thanks, that fixed it on my llvm 3.9.
https://bugs.freedesktop.org/show_bug.cgi?id=99013
--- Comment #7 from Michel Dänzer michel@daenzer.net --- (In reply to Christoph Haag from comment #6)
The build system already uses llvm-config --version which contains the revision for svn versions.
That just prints "4.0.0svn" for me, using the LLVM Git mirror.
https://bugs.freedesktop.org/show_bug.cgi?id=99013
Alexandr Zelinsky mexahotabop@w1l.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mexahotabop@w1l.ru
--- Comment #8 from Alexandr Zelinsky mexahotabop@w1l.ru --- *** Bug 99026 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=99013
--- Comment #9 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to Michel Dänzer from comment #7)
(In reply to Christoph Haag from comment #6)
The build system already uses llvm-config --version which contains the revision for svn versions.
That just prints "4.0.0svn" for me, using the LLVM Git mirror.
Same here, so sadly no revision info.
However, just to be clear (since I'm unable to test it right now): am I understanding from Christoph's comment that we are allowing the driver to be built against LLVM 3.9? If we rely on features included after the 3.9 release, shouldn't mesa check for 4.0.0svn (at least, beginning from 4c8c13b3)?
https://bugs.freedesktop.org/show_bug.cgi?id=99013
--- Comment #10 from Marek Olšák maraeo@gmail.com --- Mesa only checks for LLVM 4.0. There is no distinction between LLVM 4.0 and 4.0svn.
If you want LLVM git, you always have to update Mesa from git along with LLVM and hope for the best. Or you can stick with LLVM 3.9 and only use Mesa git.
https://bugs.freedesktop.org/show_bug.cgi?id=99013
--- Comment #11 from Michel Dänzer michel@daenzer.net --- (In reply to Alexandre Demers from comment #9)
If we rely on features included after the 3.9 release, shouldn't mesa check for 4.0.0svn (at least, beginning from 4c8c13b3)?
The commit you bisected to does that, grep for HAVE_LLVM. However, there was a typo in the intrinsic name used with LLVM 3.9 and older.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org