Le 11/07/2021 à 20:25, The Wanderer a écrit :
[...]cut
Mere minutes after filing a bug report with the Mesa tracker, I thought of something new (of course), and checked it. Sure enough: if I run vulkaninfo as root, it detects the GPU just fine. The issue turns out to have been that /dev/dri/renderD128 is owned by group render, and my user was not a member of that group. I don't know of anything which should have told me that it needed to be. I've added myself to that group, shut down to the (console) login prompt, and brought things back up, and now vulkaninfo detects the GPU as my ordinary user as well. There was no need for me to have pulled in packages from sid and experimental, but it doesn't seem to have done any harm in this instance, especially as testing is due to be released as stable (which should free up packages to migrate from sid to testing, and let packages in experimental which have non-release-safe changes safely enter sid) in the fairly near future.
I don't remember adding my user to the render group, and my bash history confirms that, but it is the same here. And /dev/dri/card0 belongs to root:video, so both video and render groups are necessary.
Right now with the deep freeze unstable packages are probably safer than usual, there is much less turnaround. experimental is another story and some of the packages there will break a system if you pull them on their own. Using experimental requires knowing quite a bit about packages co-dependencies (ie: if I pull mesa, do I need to update llvm too? Is this version of systemd working with my current initramfs-tools?...), reading changelogs, keeping backups and a bootable flash disk around. You seem to check all of those boxes but other reading this might not.
Regarding your original problem, it seems that you are down to your gpu not being recognized by or accessible to vulkan related processes? Or do you have problems with other graphical applications too?
On stock Debian like my kids are running (linux-image-5.10.0-8-amd64) it's working fine, and so is it on my custom upstream kernel. So I don't think packages version numbers are the problem. They use the firmware package available in Debian unstable, I pulled mine from git.kernel.org, and we are all doing fine, no noticeable difference.
Let me know if I can test anything or provide additional info.