Lost 3D acceleration

A

Aminavy

Hello!
I have a Thinkpad X250 with Intel HD 5500 iGPU. sometimes (specially when I logout and login) OpenGL and (sometimes) Vulkan hardware acceleration not working and mesa use llvmpipe driver for rendering. If I remember correctlly I think I noticed this problem in the past.

When I run an OpenGL program (when problem appears):
Code: 
failed to authenticate magic 1
failed to load driver: iris
failed to authenticate magic 1
failed to load driver: iris

Note: I diden't see this problem in Wayland (I have hikari installed)
 
To test if you have this bug, the following instructions are the recreate testcase. On your hardware replace 'crocus' with 'iris'.

user@:~$ glxinfo -B | grep -i accel
Accelerated: yes
user@:~$ xdriinfo
Screen 0: crocus

# note from above output: GL acceleration is active and 'crocus' driver is loaded.

# perform manual vtswitch to a different VT and then back to X11 session
# ctrl-alt-F4, then ctrl-alt-F9

user@:~$ xdriinfo
failed to authenticate magic 1
failed to load driver: crocus
failed to authenticate magic 1
failed to load driver: crocus
Screen 0: swrast
 
blackbird9 said:
This sounds like a recreate of the following known problem. Making a VT switch from the gui and back to it breaks graphics accleration. Full details here.

267915 – x11-wm/mutter: after graphics/mesa-* 21.3.8 -> 22.2.3 update OpenGL compositing fails on Intel Iris Pro

bugs.freebsd.org bugs.freebsd.org
Click to expand...

Now I remembered... I had some problems in gnome-shell (with AMD graphics) but that solved with disabling DRI3 and use DRI2. (the first posts in your provided link is about this). I never had Intel graphics until now, but my ideapad (with amdgpu) is working without any problem.

And.....
1. VT switch isn't only way to break acceleration! logout and re-login can make graphics acceleration lost. (display manager is running in same vt as window manager, so that isn't a vt switch)
2. This problem occurr's randomly, with VT switch, logout/login or even with restarting xdm! sometimes repeating them will return graphics acceleration.

I think its more about Intel+Xorg rather than VT.
 
fmc000 said:
Try putting kern.vt.suspendswitch=0 in /etc/sysctl.conf and reboot. It worked for me.
Click to expand...
This prevents vt switch to ttyv0 when system goes to suspend or wakeup. not solves the problem.
Anyway you don't need to reboot when you changed /etc/sysctl.conf contents, just service sysctl reload
 
Aminavy said:
This prevents vt switch to ttyv0 when system goes to suspend or wakeup. not solves the problem.
Anyway you don't need to reboot when you changed /etc/sysctl.conf contents, just service sysctl reload
Click to expand...
It _definitely_ solved the problem for me, otherwise I would not have posted it. With this parameter set to "1" after resuming 3D accel is lost. With this parameter set to "0" I can suspend/resume infinite times and the 3D accel is kept.
 
Yeah I got that one set. One other thing you can do to completely inhibit accidental manual switching to a different VT is to run:-

$ setxkbmap -option srvrkeys:none

which will prevent the VT switch keypresses (ctrl-alt-F1...F9) being processed.

Of course this is just a workaround, you won't be able to do a VT switch at all with that set, but it does protect against doing it inadvertantly.

The real fix will come when we get a fix for freebsd bugzilla #267915, but from reading some of the comments in the defect, its a complex and difficult bug to fix and is unlikely to happen in a hurry.
 
You must log in or register to reply here.
Back
Top