On 2021-07-10 at 07:43, tv.debian@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 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.)
> 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.
(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.)
> 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" (though that's also a concern that could apply to Lutris), and
in part to an adamant stance in opposition to DRM. (And yes, unless
Steam isn't required for a given game - meaning, unless you can download
and install and run the game without needing Steam installed at any
point in the process - then Steam is DRM. Lutris, being just a
convenience method for gaining access to the installer and providing the
correct install-time and run-time environment configurations, doesn't
have that problem.)
I think I've vaguely heard of GloriousEggroll, but nothing beyond that.
Fortunately, Lutris is documented to run FFXIV just fine, at least with
Vulkan functional. (I think it's supposed to also run it without Vulkan,
but I get crashes in that scenario too; I haven't dug very deep into
investigating them yet, because not only is that not my preferred
scenario to run the game, I also want to get Vulkan working independent
of using it for FFXIV.)
> 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?
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.
--
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