Le 10/07/2021 à 17:41, The Wanderer a écrit :
On 2021-07-10 at 07:43, tv.deb...@googlemail.com wrote:
Le 09/07/2021 à 23:44, The Wanderer a écrit :
(Warning, this is fairly long, and the situation involved includes
a fair number of potentially-moving pieces.)
I've recently built a new computer, installed Debian, configured it
to largely match my previous setup, and migrated my data across.
Now, I'm trying to take advantage of one of the hardware
improvements over the system I migrated away from: a newer,
better-performing GPU. In particular, I want to run software which
makes use of the Vulkan API for improved graphics performance.
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
aptitude search '?narrow(?installed,?archive(unstable))' | egrep
'(mesa|vulkan)'
i A libglu1-mesa - Mesa OpenGL utility library (GLU)
i libglu1-mesa:i386 - Mesa OpenGL utility library (GLU)
i A libglu1-mesa-dev - Mesa OpenGL utility library -- development files
i A libvulkan-dev - Vulkan loader library -- development files
i A libvulkan1 - Vulkan loader library
i A libvulkan1:i386 - Vulkan loader library
i A mesa-utils - Miscellaneous Mesa GL utilities
i mesa-utils-extra - Miscellaneous Mesa utilies (opengles, egl)
i vulkan-tools - Miscellaneous Vulkan utilities
aptitude search '?narrow(?installed,?archive(testing))' | egrep
'(mesa|vulkan)'
i A libglu1-mesa - Mesa OpenGL utility library (GLU)
i libglu1-mesa:i386 - Mesa OpenGL utility library (GLU)
i A libglu1-mesa-dev - Mesa OpenGL utility library -- development files
i A libvulkan-dev - Vulkan loader library -- development files
i A libvulkan1 - Vulkan loader library
i A libvulkan1:i386 - Vulkan loader library
i A mesa-utils - Miscellaneous Mesa GL utilities
i mesa-utils-extra - Miscellaneous Mesa utilies (opengles, egl)
i vulkan-tools - Miscellaneous Vulkan utilities
I also run llvm-12 from unstable, but really this gpu has been running
fine almost from the start (more than two years ago), so I don't think
testing packages are outdated, baring a massive regression or bug it
should work.
(There was a time when I tracked sid. That computer wound up in an
inconsistent state, to the point that it wasn't worth fixing and would
have needed a full reinstall and possibly a few other things into the
bargain. I lived with it until I could build a replacement, then
migrated away to track testing and have never considered looking back.)
I have read such horror stories, and got into some troubles with buggy
libc6 or systemd migrations over time, but I never reinstalled on my
desktops/workstation. Booting into a live system and chrooting was the
most drastic steps I had to take, and no more often than a couple of
times in years across several computers. Maybe we should start a thread
and share our "frankensystems" setups to give nightmares to developers
and professional sysadmins out there? I just don't want to be
responsible for users copy/pasting verbatim and breaking their systems,
then blaming Debian for it...
If you want a G.U.I. vulkan test app you can use "goverlay", if you
want vulkan related info displayed in another game/programm you can
try "mangohud".
What exactly would you recommend as a Vulkan-functionality testing
procedure with goverlay? The program launches without issues both with
and without the explicit specifying of VK_ICD_FILENAMES, but doesn't
seem to show anything indicating what graphics adapters it's using or
seeing. I don't know it or its usage well enough to judge what needs to
be done from its interface in order to test (and while I could go
digging or do trial-and-error, that's not my focus right now), and its
man page says exactly the same thing as the package description, which
isn't useful for figuring out how to run or use the program.
It doesn't do anything special by itself, just offers a graphical
interface to set some parameters and run the "cubes" and "gears" tests
for vulkan and opengl, offering a few stats for both.
When setup and used as a startup parameter with programs it can apply
the settings to the output, and the overlay can give a quick view of how
well it's running. There's pre-built wrapper to run Steam, Lutris or
Heroic launchers with it.
I have to admit that this things are quite foreign to me, I just debug
it when something breaks on the kids setups.
(I just tested mangohud with glxgears, and bizarrely enough, it appears
to reduce FPS in that demo by a factor of about 3.5 - from about 30K to
about 8.5K. Not sure if that's got to do with the fact that Vulkan isn't
working correctly on my system or not, even though glxgears is using
OpenGL.)
Any overlay or video effect is going to have an impact, however minimal,
on the overall performances or resources used.
For wine you probably want to install i386 (32bits) vulkan libraries
too alongside the amd64 ones.
I am very familiar with multiarch considerations, especially for Wine.
Enabling i386 was one of the first steps I took in the software-side
build of my current machine, and I've been careful to check i386 package
versions in examining my Vulkan setup.
Here my sons (with the same setup, radeon 5700XT and Vega56 cards)
use the Steam "Proton" implementation of wine happily, vulkan games
run fine. Linux native games run in vulkan mode too.
I have given up on trying to get anything to run with plain wine
years ago, so can't help with this, but Steam "Proton" version or
"GloriousEggroll" (yes it's a real thing) run almost any Windows
games my kids throw at it, in vulkan mode when available, sometime
much better than native Linux versions (sadly).
I'm not likely to use Proton, because I have a bias against Steam; I
think it traces back in part to early-days "anything which wants you to
install it in a way that bypasses the system's package-management system
is bad"
[...] cut
I am not happier with Steam which is really proprietary overhead to run
games which are also totally closed source and proprietary, not to
mention the security and privacy issues that come with it, but I do give
them thanks for making my life much simpler by actively supporting
gaming on Linux, and almost making dual-booting Windows a thing of the
past. Only a couple of online games with stupid anti-cheat systems keep
me from being a Debian only shop.
GOG offers drm free games, they also have an optional "gamestore"
frontend available in Debian named "minigalaxy". HumbleBundle also does
offer some drm free titles, Feralinteractive did some good Linux ports,
some less convincing, but the choice is limited compared to a giant like
Steam, and setting up the games is often complicated, or just plain
impossible when the binaries get outdated and the editor doesn't care...
The proliferation of Windows only game stores like Origin, Uplay, Epic
store to name a few, who don't care at all about Linux isn't helping
either. So Steam is better than my kids thinking Linux is just for
bearded geeks and "boring" servers (even if ironically some of their
online games servers are running Linux, but don't support it as a client).
If I can help narrow down what package or version is causing you
trouble, I'll do.
At first glance, I think the most likely area of focus should be the
ICDs. What do you have under /usr/share/vulkan/icd.d/ (or in the
vicinity, named in a way that makes it look like it might be
ICD-related)? If you have anything there other than
{intel,lvp,radeon}_icd.{i686,x86_64}.json, does it come from
mesa-vulkan-drivers, or from somewhere else?
I never tinkered or changed anything there:
ll /usr/share/vulkan/icd.d/
-rw-r--r-- 1 root root 161 2 juil. 15:26 intel_icd.i686.json
-rw-r--r-- 1 root root 163 2 juil. 15:26 intel_icd.x86_64.json
-rw-r--r-- 1 root root 159 2 juil. 15:26 lvp_icd.i686.json
-rw-r--r-- 1 root root 161 2 juil. 15:26 lvp_icd.x86_64.json
-rw-r--r-- 1 root root 162 2 juil. 15:26 radeon_icd.i686.json
-rw-r--r-- 1 root root 164 2 juil. 15:26 radeon_icd.x86_64.json
dpkg -S /usr/share/vulkan/icd.d/radeon_icd.x86_64.json
mesa-vulkan-drivers:amd64: /usr/share/vulkan/icd.d/radeon_icd.x86_64.json
On some systems I tried getting Blender gpu hardware rendering to work
reliably with mesa/radeon icd but never really succeeded so far. But for
games and vulkan stuff I never had to.
Is there anything in /usr/share/doc/mesa-vulkan-drivers/changelog.gz (or
similar) which looks like it might represent the difference? I can see
changelog.Debian.gz on packages.debian.org, but at a glance I'm not
finding a way to view the full package changelog without at least
downloading the .deb.
I'm sure I should be thinking of other things to inquire about, but
nothing's coming quickly to mind, and I've got the last day of SGDQ
running in the other room; I'm missing part of a block of highly
entertaining runs right now, so I'd rather not be away from that screen
for too long today. With any luck, I'll be better able to brain about
this next time I check in.
