Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
The migration is almost done, at least the rest should happen in the background. There are still a few technical difference between the old cluster and the new ones, and they are summarized in this issue. Please pay attention to the TL:DR at the end of the comment.
After reading many many many pages around the web and trying everything I could try I have got some config that doesn't crash with white/blank screen or background screen.
Looks like there is no guide for people new in debugging mesa3d, so I had to spend lot of time looking on the web and trying to get tips to know what I can try here.
I have put the first command I tried, but still don't know what should I really use.
Probably the issue is with MESA_GL or MESA_GLES not fully implemented for the version automatically recognized for the driver (from glxinfo not using the vars to force the version):
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
Is there any documentation that could help me assign the bug-free GL version should I use?
I will be trying different versions until get the bigger and will comment again.
I got blank screen also watching youtube videos, it seems to be some random bug that I couldn't identify yet but hope this information could help some other more familiar with mesa3d could.
Up to GL 3.0, everything works fine and stable, glmark2 and gnome session.
With 3.1 or any other higher glmark2 shows only black content on the window opened when I use MESA_GL_VERSION_OVERRIDE=3.1 glmark2 in same session that I openned using /etc/environment.
If I change to:
MESA_GL_VERSION_OVERRIDE=3.1 in /etc/environment, then also gnome session (after login in gdm) got "gdm background" with screen freezed video.
Up to GL 3.0, everything works fine and stable, glmark2 and gnome session.
With 3.1 or any other higher glmark2 shows only black content on the window
opened when I use MESA_GL_VERSION_OVERRIDE=3.1 glmark2 in same session that
I openned using /etc/environment.
If I change to:
MESA_GL_VERSION_OVERRIDE=3.1 in /etc/environment, then also gnome session
(after login in gdm) got "gdm background" with screen freezed video.
after new tests I got error also with 3.0, still doing more tests.
also tested game Insurgency that had same problem as glmark2 and it works now!
seems that dpm is buggy on this radeon card, probably is better to disable it by default or put it on high performance for a more stable usage for users.
You will notice now /sys/class/drm/card0/device/power_dpm_force_performance_level doesn't exist.
For months I though the problem was somewhere else, and was looking for many combinations without success, without this workaround I had a very annoying experience working, playing videos, whatever, because randomly I had freezed display and had to restart. I couldn't play any game before, now tested with many games and everything is perfect.
Could be good to apply this workaround by default? so users doesn't experience the annoying bug?
I'm against disabling DPM altogether from the kernel driver code. That'd be
far from ideal.
Thanks Marc!
Is great to have some feedback now.
After looking again into the files of the card0, I have noticed that dpm is enabled by default! (I have been confused because the file changed its place).
Now it is here:
cat /sys/class/drm/card0/power/control
auto
uname -a
Linux powers11 4.16.1-300.fc28.x86_64 #1 (closed) SMP Mon Apr 9 15:29:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Also their outpus have same files:
/sys/class/drm/card0/
card0-DP-1/ card0-HDMI-A-1/ device/ subsystem/
card0-DVI-D-1/ dev power/ uevent
So it is really fixed for fedora 28!! (kernel 4.16.x)
I have been using this for weeks and not noticed this bug!
Also tested glmark2 and some game just to see if something crashes.
This issue hasn't had any activity since 2019-11-19. The AMD driver stack changes rapidly and contains lots of shared code across products so it's possible that it has already been fixed. Please upgrade to a current stable kernel and userspace stack and try again. If you still experience this issue with the latest driver stack, please capture relevant logging and open a new issue referring back to this one.