Bug 109177 - Blender 2.8 triggers GPU lockup when entering Edit Mode
Summary: Blender 2.8 triggers GPU lockup when entering Edit Mode
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: 18.3
Hardware: Other All
: high major
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-29 22:25 UTC by MirceaKitsune
Modified: 2019-01-26 12:21 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Screenshot of the graphical corruption (1.10 MB, image/png)
2018-12-29 22:28 UTC, MirceaKitsune
Details
dmesg.txt (88.18 KB, text/plain)
2019-01-03 00:52 UTC, MirceaKitsune
Details
Xorg.0.log (64.37 KB, text/x-log)
2019-01-03 00:52 UTC, MirceaKitsune
Details
Xorg.0.log.old (51.45 KB, application/x-trash)
2019-01-03 00:53 UTC, MirceaKitsune
Details

Description MirceaKitsune 2018-12-29 22:25:25 UTC
The problem is observed in and can be tested with the latest development build of Blender 2.8 (7c438e5366b2) compiled on 29-12-2018. I tested and can confirm it does not occur with Blender 2.79b. I did not experience it with Blender 2.8 either last month, meaning the issue was introduced recently by either Blender or an OS package upgrade.

https://builder.blender.org/download/blender-2.80-7c438e5366b2-linux-glibc224-x86_64.tar.bz2

Issue: When entering Edit Mode on an object, a GPU lockup occurs almost immediately, requiring a hardware restart. This seems to happen for objects with a high enough amount of vertices (no problem with the default cube). The image freezes, mouse cursor cannot be moved, NumLock / CapsLock keyboard leds can't be toggled. The HDD led does not flash meaning the hard drive isn't busy.

Steps to reproduce: Download the latest development version of Blender 2.8 from the https://builder.blender.org/download page, ideally the version linked above granted the link remains available. Delete the default cube, press Shift + A to add a new object, then add an UV sphere. Upon doing this you should see a popup in the lower-left corner of the screen; Set the Segments to 128 and the Rings to 64. Now press Tab to go into Edit Mode with the sphere selected.

Results: You should begin to see graphical corruption on the screen. In my case I see lines stretching from each vertice to the edge of the screen. Within a few seconds if not instantly, the entire system will freeze up.

OS and hardware: Linux openSUSE Tumbleweed x64 (KDE). Kernel 4.19.11. Mesa 18.3.1 (amdgpu module). Radeon R9 390 (GCN 2.0).
Comment 1 MirceaKitsune 2018-12-29 22:28:18 UTC
Created attachment 142918 [details]
Screenshot of the graphical corruption

A screenshot of the graphical corruption which can be observed moments before the crash.
Comment 2 MirceaKitsune 2019-01-02 14:22:10 UTC
In the meantime I've preformed a test which was recommended to me by another user. The crash seems to be unaffected by booting with either "amdgpu.dc=0" or "amdgpu.dc=1" and will occur identically in both cases.
Comment 3 Alex Deucher 2019-01-02 19:47:25 UTC
Please attach your xorg log and dmesg output.
Comment 4 MirceaKitsune 2019-01-03 00:52:40 UTC
Created attachment 142947 [details]
dmesg.txt
Comment 5 MirceaKitsune 2019-01-03 00:52:54 UTC
Created attachment 142948 [details]
Xorg.0.log
Comment 6 MirceaKitsune 2019-01-03 00:53:11 UTC
Created attachment 142949 [details]
Xorg.0.log.old
Comment 7 MirceaKitsune 2019-01-26 12:21:02 UTC
This does seem to have been solved in either the latest Blender 2.8 build or Mesa version: I can now go into Edit Mode on meshes with a lot of vertices, no longer getting either the graphical corruption or any GPU crashes.

As the issue appears to be fixed and I no longer have a test case, we can close this. Will reopen in case the same issue surfaces again anytime soon.


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.