On 2021-07-10 at 17:36, idiotein30@gmail.com wrote: > Le 10/07/2021 à 17:41, The Wanderer a écrit : > >> On 2021-07-10 at 07:43, tv.debian@googlemail.com wrote: >>> Hi, Debian unstable with bits of experimental here (because of the >>> freeze I pull some newer packages from experimental). Same graphic >>> card (5700XT), mesa drivers (21.1.4 at this precise moment, from >>> experimental). Here vulkan works afaik. >> >> For comparison, I have mesa-vulkan-drivers 20.3.4-1, from testing. >> >>> vulkaninfo reports my card as: >>> "Group 1: >>> Properties: >>> physicalDevices: count = 1 >>> AMD RADV NAVI10 (ACO) (ID: 0) >>> subsetAllocation = 0 >>> Present Capabilities: >>> AMD RADV NAVI10 (ACO) (ID: 0): >>> Can present images from the following devices: count = 1 >>> AMD RADV NAVI10 (ACO) (ID: 0) >>> " >> >> That's excellent news; it means that, at least in principle, this can >> work in (relatively-)clean Debian as currently constituted. (It also >> confirms that RADV is the relevant thing here; my reading wasn't >> conclusive as to whether or not that was specifically something for >> older card models.) >> >> Can you indicate exactly which Vulkan-related packages you're running >> from experimental? For that matter, a list of Vulkan-related packages >> and package versions from unstable too would probably be appropriate, >> since I track testing and am *highly* hesitant to upgrade against sid >> wholesale. > > There you go, some packages are at the same version in Testing and > Unstable, so you will see them in both. > > "aptitude search '?narrow(?installed,?archive(experimental))' | egrep > '(mesa|vulkan)' > > i A libegl-mesa0 - free implementation of the EGL API -- Mesa vendor library > i libegl-mesa0:i386 - free implementation of the EGL API -- Mesa vendor > library > i libegl1-mesa:i386 - transitional dummy package > i A libgl1-mesa-dri - free implementation of the OpenGL API -- DRI modules > i A libgl1-mesa-dri:i386 - free implementation of the OpenGL API -- DRI > modules > i A libgl1-mesa-glx - transitional dummy package > i A libglapi-mesa - free implementation of the GL API -- shared library > i A libglapi-mesa:i386 - free implementation of the GL API -- shared library > i A libglx-mesa0 - free implementation of the OpenGL API -- GLX vendor > library > i A libglx-mesa0:i386 - free implementation of the OpenGL API -- GLX > vendor library > i A libosmesa6 - Mesa Off-screen rendering extension > i A libosmesa6:i386 - Mesa Off-screen rendering extension > i mesa-opencl-icd - free implementation of the OpenCL API -- ICD runtime > i A mesa-va-drivers - Mesa VA-API video acceleration drivers > i A mesa-vdpau-drivers - Mesa VDPAU video acceleration drivers > i mesa-vulkan-drivers - Mesa Vulkan graphics drivers > i mesa-vulkan-drivers:i386 - Mesa Vulkan graphics drivers I now have all of these (except the dummy packages, which I skipped as irrelevant) installed from experimental. All the ones you listed from unstable seem to be at the same version in testing, and have no available version in experimental, so there's nothing to upgrade there. I've also gone so far as to upgrade my kernel to the one in experimental (it was only a Debian-packaging version upgrade: 5.10.0-7 to 5.10.0-8). The results, so far, are exactly the same as before: vulkaninfo reports only one "device", llvmpipe / lavapipe. I haven't gone so far as to upgrade the firmware-amd-graphics package to the one in experimental; the version number indicates that it's only one week newer than the one in testing (March 22nd rather than March 15th), which seems unlikely to make a difference. I'd be curious to know which of the two you've got installed, regardless. I've at least managed to confirm even more strongly than before that amdgpu does seem to be in use; not only is it referenced as loaded in dmesg, it appears prominently in /var/log/Xorg.0.log (where several other video drivers are tried, including radeon, and all the others seem to get unloaded while AMDGPU references continue to appear afterwards). Yet for sone reason, Vulkan is still failing to detect the presence of any physical GPU. I've gone so far as to build vulkaninfo locally, and have gone digging through the sources looking to figure out how it does detection. What seems to happen is that it calls vkEnumeratePhysicalDevices() on an instance of AppInstance; I've tracked that back through the mesa sources as far as device_select_layer.c, but been unable to identify where the relevant code in the tangle of that file gets the data from. I think at this point I probably need to report an issue with Mesa upstream, and see if they can at least advise me on how to troubleshoot it further. Hopefully the fact that I'm now mixing package versions between Mesa 20.x (a few -dev packages, at least, are still on that) and 21.x (the ones listed above) won't be an issue... I'm unhappy about having to interact with freedesktop.org in order to pursue this, but that's where Mesa keeps their bug tracker, so there's not much to be done about it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature