Vulkan with Radeon RX 5700 XT

[The Wanderer]

(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.

However, I'm running into walls left and right; every time I find a way
around one, I hit another. Most of the solutions I find out there, based
on the error messages I'm encountering, seem to be aimed at people using
older graphics-card models; they should not, and as far as I can tell do
not, apply in my case.

As far as I can tell, Vulkan is simply not working at all on my system,
even though there doesn't seem to be any established/known reason why it
wouldn't / shouldn't. I've found a fair bit of discussion of ways to get
it to work for other distributions, but none at all for Debian, except
for ones that appear to be outdated or otherwise not applicable to my
hardware.

The specific problem I'm seeing seems to be that Vulkan does not seem to
be seeing my actual GPU, at all.


The specific graphics card I have is
https://www.amazon.com/gp/product/B07WNSP41M , which is a MSI-branded
Radeon RX 5700 XT.

lshw reports it as:
product: Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT]

'inxi -Fxxxz' reports it as:
Graphics:
Device-1: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT]
vendor: Micro-Star MSI driver: amdgpu v: kernel bus ID: 0d:00.0
chip ID: 1002:731f class ID: 0300
Display: server: X.Org 1.20.11 driver: loaded: amdgpu,ati
unloaded: fbdev,modesetting,radeon,vesa resolution: 2560x1600~60Hz
s-dpi: 96
OpenGL: renderer: AMD Radeon RX 5700 XT (NAVI10 DRM 3.40.0 5.10.0-7-amd64
LLVM 11.0.1)
v: 4.6 Mesa 20.3.4 direct render: Yes

Notably, both the above and 'lspci -k' report that the amdgpu driver is
being used. There are many online discussions from earlier AMD graphics
card generations in which the solution is to prevent the use of the
legacy radeon driver and force the use of the amdgpu driver instead, by
passing appropriate options to the kernel at boot time. I have not yet
specifically tried any of these, because the condition which they're
expected to produce - the use of the amdgpu driver - seems to already be
present.

It's also important to note that I *do* appear to be getting functional
3D acceleration. I haven't done much that would need it yet, but the
little I've done with native Linux software and OpenGL etc. has worked
seamlessly, 'vblank_mode=0 glxgears' is reporting something on the order
of 10x the FPS it did on my previous (ten-or-so years old) system, and
the output of 'glxgears -info' includes the model name of the GPU. I
don't find it plausible that I'd be seeing results like that if the
system just weren't using the GPU's acceleration capabilities at all.
It's just Vulkan that seems to be having problems.


As I understand matters, the baseline interface to test whether Vulkan
is functioning - and, if so, get information about it - is the
'vulkaninfo' command from the vulkan-tools package.

If I run that command unadorned, I get lengthy output, which does not
mention the above graphics card at all. Instead, it mentions two
different llvmpipe devices. I understand this to be effectively
software-based rendering, not actual hardware acceleration as such. This
is supported by the fact that the only deviceType entry in the "Device
Properties and Extensions" section iis set to PHYSICAL_DEVICE_TYPE_CPU.

If I run the included command 'vkcube', I get a window (somewhat larger,
I think, than the one produced by 'glxgears') which depicts an animated
3D cube. The cube spins so fast that I can't make out what the textures
on it are supposed to be. The system fans ramp up slowly while the
process is active. The message
WARNING: lavapipe is not a conformant vulkan implementation, testing
use only
is printed to the terminal. (I am given to understand that this message
is expected when the llvmpipe backend is used, and that it reflects the
fact that you really aren't supposed to use it for anything
production-level. Also, from what I've read, I think lavapipe is just
the current name for the Vulkan variant of llvmpipe.)

If I instead run the included command 'vkcubepp', I get a similar
window. The cube is spinning much slower at the start, but speeds up
over time. As it speeds up, the system fans ramp up much faster than
with plain 'vkcube'. The same message as before is printed to the
terminal. I do not know what the 'pp' may stand for, or what the
difference is supposed to be.


The program I'm specifically interested in trying to run is Final
Fantasy XIV, via Wine, and - to minimize configuration and setup
troubles, which have been bad enough even as it stands - via Lutris.

If I run that program via Lutris with Vulkan enabled (the default) and
with - as far as I recall - no special other configuration outside of
what Lutris itself applies, I get a crash, and a message that the
llvmpipe device was skipped. Running it with maximum-verbosity debug
output reveals that the crash error code apparently means that the
'dxvk' Vulkan backend for Wine did not find any adapters to use.

Online searching finds that one possible way around this, and/or other
issues which I encountered along the way, is to specify a different ICD
with the VK_ICD_FILENAMES environment variable (set to one or more full
paths, apparently colon-separated).

Appropriate ICD profile definition files are apparently stored / shipped
under /usr/share/vulkan/icd.d/. In that location, I have JSON files
defining profiles for 32-bit and 64-bit versions of Intel, Radeon, and
lavapipe ICDs, all of which come from the mesa-vulkan-drivers package.
Examining the Radeon ICD definition files shows nothing which would
obviously make it look as if this is specifically for e.g. the old,
legacy radeon driver; everything I've found seems to say that it should
also work with amdgpu.


If I specify one or both of the Radeon ICD definition files using that
environment variable, and try the above tests again, the results are
different but in no way better.

During launch of Lutris (not even of the Wine session to run the actual
program), the message "Vulkan is not available or your system isn't
Vulkan capable" is printed to the terminal. Trying to launch the actual
Wine session produces even less useful results.

If I run 'vulkaninfo' with that variable set, I get the following output:

ERROR: [Loader Message] Code 0 :
/usr/lib/i386-linux-gnu/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
ERROR at
/build/vulkan-tools-oFB8Ns/vulkan-tools-1.2.162.0+dfsg1/vulkaninfo/vulkaninfo.h:248:vkEnumerateInstanceExtensionProperties
failed with ERROR_INITIALIZATION_FAILED

If I run 'vkcube' with that variable set, I get the following output:

vkcube:
/build/vulkan-tools-oFB8Ns/vulkan-tools-1.2.162.0+dfsg1/cube/cube.c:3271: demo_init_vk:
Assertion `!err' failed.
Aborted

If I run 'vkcubepp' with that variable set, I get the following output:

vkcubepp:
/build/vulkan-tools-oFB8Ns/vulkan-tools-1.2.162.0+dfsg1/cube/cube.cpp:1247:
void Demo::init_vk(): Assertion `result == vk::Result::eSuccess' failed.
Aborted

At this point in my testing, I'm fairly sure all of these are reporting
the same problem: failure to find a graphics adapter to use. That would
seem to suggest that, perhaps, the Radeon ICD definition files involved
don't actually work with amdgpu and this GPU model.


I've found discussions which appear to report or imply success with
similar graphics card models using the 'amdvlk' Vulkan implementation.
That is available for various other distributions, including Ubuntu
(possibly even in the form of .deb files made available, as part of an
automated installer, by AMD themselves); however, it does not appear to
have been packaged for Debian. A set of RFPs was filed back in 2018, by
a DD, but it does not appear that anything ever got done to follow up on
it; see bug #916552 and the listed blocking bugs.

There's an unofficial "how to install the official AMD upstream driver"
procedure, which may or may not include amdvlk, at
https://wiki.debian.org/AMDGPUDriverOnStretchAndBuster2 - but it's
specifically focused on how to effectively backport this to earlier
Debian releases, not on how to get it to work with current Debian
testing. I'm reluctant to go mixing sources in that way, regardless.


If I try to run the Lutris setup with Vulkan disabled, I get what
appears to be an entirely different crash; that's another road, and
while I may try to walk it at some point, it is not the issue I'm
focusing on here. I'm currently focused on trying to figure out why
Vulkan doesn't seem to be working in a way that actually uses my GPU.


Does anyone have experience with using Vulkan with AMD graphics on
vaguely current Debian, using an even vaguely recent GPU? (Where
"vaguely current Debian" means Debian testing more recently than the
release of current stable, and a "vaguely recent GPU" means something
new enough that disabling the support for it in the legacy radeon driver
isn't necessary, because that driver doesn't support it to begin with.)

Any suggestions for ways to pursue getting this working, that don't
involve hybridizing or Frankensteining or otherwise messing up my
installed system?

--
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

[tv.d...@googlemail.com]

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.

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)
"

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".

For wine you probably want to install i386 (32bits) vulkan libraries too
alongside the amd64 ones.

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).

If I can help narrow down what package or version is causing you
trouble, I'll do.

All the best.

[Brian Thompson]

On Sat, 2021-07-10 at 13:43 +0200, tv.d...@googlemail.com wrote:
> Hi, Debian unstable with bits of experimental here

Is it (usually) wise to intermix different suites? I guess it wouldn't matter
that much for bits and pieces of experimental in unstable since you are already
in agreeance with having an unstable system to begin with.

I wanted to do the same thing with getting testing security updates into
unstable, but I didn't think that was wise (plus it's the other way direction).
--
Best regards,

Brian

[tv.d...@googlemail.com]

This is not the point of the OP message, so let's not derail, I
mention it because packages versions could be relevant to the OP
problems. There are plenty of threads and post around to tell you not to
do that, and they are right. I am "mixing" since Debian 4, all my
stations are "hybrids" of some sorts, sometimes it breaks, I fix it. I
don't recommend or advocate it, but I do it without much problem and for
new hardware it is often mandatory, unless you'd rather switch to
another distribution.

Me on Debian "melting pot", free to walk the wire. Who needs a big
corporation to botch updates and ruin your system when you can do it
yourself? ;-)

[Brian Thompson]

On Sat, 2021-07-10 at 14:57 +0200, tv.d...@googlemail.com wrote:
>
> This is not the point of the OP message, so let's not derail

I apologize for accidentally derailing. I should have started a new thread.
I'm still relatively new to the Debian community.
--
Best regards,

Brian

[tv.d...@googlemail.com]

Le 10/07/2021 à 15:13, Brian Thompson a écrit :

Don't worry, I am not from the list police! Lately I think a good 2/3 of
all thread ended up really far the original subject, sometimes with
complete disregard for the original person and his/her need for
assistance. Maybe it's fun & free, maybe it's abusive and disrespectful,
depends on your culture and standards I guess.

So, back to Vulkan, let's help The Wanderer get its setup up and running.

[Eike Lantzsch ZP6CGE]

No problem - AMTRAK always derails and still runs. If it is a matter of
tracks or a matter of running stock or a matter of cars or trucks
passing level passings with lights flashing is a moot question.
People here on debian-user use to derail all the time.
q.e.d.
Eike

--
Eike Lantzsch ZP6CGE

[Alexander V. Makartsev]

On 10.07.2021 02:44, The Wanderer wrote:

Does anyone have experience with using Vulkan with AMD graphics on
vaguely current Debian, using an even vaguely recent GPU? (Where
"vaguely current Debian" means Debian testing more recently than the
release of current stable, and a "vaguely recent GPU" means something
new enough that disabling the support for it in the legacy radeon driver
isn't necessary, because that driver doesn't support it to begin with.)

Any suggestions for ways to pursue getting this working, that don't
involve hybridizing or Frankensteining or otherwise messing up my
installed system?

While being a "nvidia-guy" myself (long before ATI was bought by AMD), out of curiosity, I've asked myself "what would I do" and looked into AMD driver support in Debian.
And to my surprise, I didn't found a simple way like "amd-driver" meta-package to install, as opposed to "nvidia-driver" package for nvidia-based VGAs.
So, if I were you, I would bite the bullet and use latest official driver [1] provided by AMD, simply because there are no other options.
Upon further examination "*.deb" packages they provide will be installed into paths with "*/opt/*" and because of that, they won't overwrite any Debian-native files, so there is little to none possibility to create "franken-debian" by installing them. And since they are packaged into ".deb" files you can always cleanly uninstall them.
The only thing I would do prior to driver installation is to enable i386 architecture support [2] on my system, if it wasn't enabled already:
    # dpkg --add-architecture i386

I wonder why a convenient "amd-driver" meta-package wasn't created yet...


[1] https://www.amd.com/en/support/graphics/amd-radeon-5700-series/amd-radeon-rx-5700-series/amd-radeon-rx-5700-xt
[2] https://wiki.debian.org/Multiarch/HOWTO

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀ 

[The Wanderer]

On 2021-07-10 at 07:43, tv.d...@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]

On 2021-07-10 at 11:14, Alexander V. Makartsev wrote:

> On 10.07.2021 02:44, The Wanderer wrote:
>
>> Does anyone have experience with using Vulkan with AMD graphics on
>> vaguely current Debian, using an even vaguely recent GPU? (Where
>> "vaguely current Debian" means Debian testing more recently than
>> the release of current stable, and a "vaguely recent GPU" means
>> something new enough that disabling the support for it in the
>> legacy radeon driver isn't necessary, because that driver doesn't
>> support it to begin with.)
>>
>> Any suggestions for ways to pursue getting this working, that
>> don't involve hybridizing or Frankensteining or otherwise messing
>> up my installed system?
>
> While being a "nvidia-guy" myself (long before ATI was bought by
> AMD), out of curiosity, I've asked myself "what would I do" and
> looked into AMD driver support in Debian.

I used to run NVIDIA - back in the days when G80-based cards were the
top of the architectural line. (A brother of mine, who does gaming on a
more regular basis and is at least as Linux-centric as I am, runs NVIDIA
to this day.)

I had enough times when I couldn't launch X (at least not with any
acceleration at all, even 2D acceleration) because an updated NVIDIA
driver which was compatible with the new X or kernel version hadn't been
released yet, and enough troubles trying to switch drivers etc. and
remnants left over on the computer afterwards, that it left me with an
antipathy towards using NVIDIA products.

The fact that NVIDIA's Linux support implementation is proprietary is
both the reason for those problems, and an entirely separate reason why
I decided that until that fact changes, I will never voluntarily buy an
NVIDIA card for a Linux system.

> And to my surprise, I didn't found a simple way like "amd-driver"
> meta-package to install, as opposed to "nvidia-driver" package for
> nvidia-based VGAs.

As I understand matters, this is another consequence of the fact that
the NVIDIA driver (stack) is proprietary - or rather, the only reason
why there's an nvidia-driver package is because it's not practical (or
necessarily even possible) to provide that functionality in a more
integrated way, because of the proprietary and opaque way the NVIDIA
drivers etc. are provided. In an ideal world, no such explicit separate
package(s) would be needed.

> So, if I were you, I would bite the bullet and use latest official
> driver [1] provided by AMD, simply because there are no other
> options. Upon further examination "*.deb" packages they provide will
> be installed into paths with "*/opt/*" and because of that, they
> won't overwrite any Debian-native files, so there is little to none
> possibility to create "franken-debian" by installing them. And since
> they are packaged into ".deb" files you can always cleanly uninstall
> them.

I'll take this under advisement; at the very least, it's my fallback if
other investigations don't produce any usable results. The examination
of those packages and the results they provide is appreciated.

> The only thing I would do prior to driver installation is to enable
> i386 architecture support [2] on my system, if it wasn't enabled
> already:
> # dpkg --add-architecture i386

I take this as such an obvious and necessary thing to do, during system
installation and setup, that it doesn't even occur to me to mention
having done it.

> I wonder why a convenient "amd-driver" meta-package wasn't created
> yet...

For one thing: because no one has found it worth the trouble to create
and undertake to maintain one.

For another - what would you suggest such a package do, and/or depend
on? Beyond maybe xserver-xorg-video-{amdgpu,ati,radeon} and
firmware-amd-graphics, I'm not sure what would be appropriate to pull
in, and at least some of that is going to be pulled in automatically
during installation of the OS anyway.

I certainly wouldn't mind having such a package exist, but I probably
wouldn't really use it, at the very least because
xserver-xorg-video-{ati,radeon} are not necessary for AMDGPU
functionality and I see no reason to keep them around taking up space.

[Andrei POPESCU]

On Sb, 10 iul 21, 06:51:43, Brian Thompson wrote:
> On Sat, 2021-07-10 at 13:43 +0200, tv.d...@googlemail.com wrote:
> > Hi, Debian unstable with bits of experimental here
>
> Is it (usually) wise to intermix different suites?

It depends :)

In my opinion I'd say the order from less to more dangerous would be:

1. stable + select packages from stable-backports

Generally quite safe, though security support for -backports is on
best-effort basis and could be delayed for various reasons.

2. oldstable + select packages from oldstable-backports-sloppy

Package versions in -backports-sloppy are also from testing, so an
upgrade from oldstable to stable is much more likely to run into
issues if you start with this mix.

Besides, oldstable only receives security support for one year after
the last stable release, to allow sufficient time to prepare the
dist-upgrade.

This mix makes sense e.g. if you intend to keep running a system on
oldstable for a very limited time (a few moths or so), that will then
be decommissioned, reinstalled etc. instead of dist-upgraded to
stable.

3. testing + select packages from unstable

Testing doesn't have any direct security support, but security fixes
should be migrated faster from unstable. Whenever this is not the
case (why?), it could make sense to upgrade specific packages.

Similar considerations for bug fixes, in expectation that the package
will eventually migrate to testing.

Be prepared to handle the situation where the package will not
migrate as expected (or ever).

4. unstable + select packages from experimental

Experimental is an incomplete suite (same as -backports), it can only
be used on top of something, typically unstable.

Packages in experimental can be everything from (surprise!)
experiments that will never make it to unstable, test packages long
forgotten that might not even install properly on any recent Debian,
pre-releases of newer upstream versions (yummy!), to release-quality
packages that are uploaded there instead of unstable during the
freeze (as per Release Team's policy).


The -backports (-sloppy probably as well) and experimental archives are
treated specially by APT, no additional configuration should be
necessary for the typical use case mentioned above.

For combination 3. you probably want to use a setup similar with
-backports for security upgrades and something similar to experimental
for bug fixes.

Understanding of APT pinning is a good prerequisite for such a setup,
which is why I'm intentionally vague. ;)

Of course, one way to learn is by actually trying it and breaking stuff
(as most of us probably did). At a minimum you should avoid doing this
in "production" (whatever that means for you).

> I guess it wouldn't matter
> that much for bits and pieces of experimental in unstable since you are already
> in agreeance with having an unstable system to begin with.

Experimental can be way more dangerous than unstable, see above. Most
(but not all!) packages in unstable are meant to eventually migrate to
testing and then become part of the next stable release.

> I wanted to do the same thing with getting testing security updates into
> unstable, but I didn't think that was wise (plus it's the other way direction).

It's unclear to me what exactly you meant with this, but I think I
addressed it above anyway.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[The Wanderer]

On 2021-07-10 at 14:18, Andrei POPESCU wrote:

> On Sb, 10 iul 21, 06:51:43, Brian Thompson wrote:
>
>> On Sat, 2021-07-10 at 13:43 +0200, tv.d...@googlemail.com wrote:
>>
>>> Hi, Debian unstable with bits of experimental here
>>
>> Is it (usually) wise to intermix different suites?
>
> It depends :)
>
> In my opinion I'd say the order from less to more dangerous would
> be:
>
> 1. stable + select packages from stable-backports

> 2. oldstable + select packages from oldstable-backports-sloppy

> 3. testing + select packages from unstable

> 4. unstable + select packages from experimental

I'm a little surprised to see that you don't even mention the mix which
I've been running for the last decade-plus: stable + testing, which
works out to testing + select packages from stable (the ones which are
no longer available in testing).

Do you consider that to be so dangerous as to not even be worth mentioning?

[Brian Thompson]

Thank you for the detailed response, Andrei.

On Sat, 2021-07-10 at 21:18 +0300, Andrei POPESCU wrote:
>    Testing doesn't have any direct security support

Is that 100% true? I was originally referring to
http://security.debian.org/debian-security/dists/testing-security
when I was talking about "testing security updates". I understand that most
mirrors don't contain this suite, but it seems to be working pretty well along
with the "main" mirror I am using for testing updates (i.e. one that is closer
in proximity).

Perhaps mixing mirrors is a bad practice, but I haven't run into any issues for
the past week since I started using this apt configuration.

>
> > I wanted to do the same thing with getting testing security updates into
> > unstable, but I didn't think that was wise (plus it's the other way
> > direction).
>
> It's unclear to me what exactly you meant with this, but I think I
> addressed it above anyway.

Yes, you did. Plus it wouldn't make sense to pull the testing-security suite I
mentioned above into unstable, would it?

--
Best regards,

Brian

[Brian]

On Sat 10 Jul 2021 at 14:38:39 -0400, The Wanderer wrote:

> I'm a little surprised to see that you don't even mention the mix which
> I've been running for the last decade-plus: stable + testing, which

Most likely an oversight.

--
Brian.

[Brian]

On Sat 10 Jul 2021 at 13:48:12 -0500, Brian Thompson wrote:

> On Sat, 2021-07-10 at 21:18 +0300, Andrei POPESCU wrote:
> >    Testing doesn't have any direct security support
>
> Is that 100% true? I was originally referring to

Almost, for most of the time and in normal circumstances.. It depends
on how serious the securuty breach is.

--
Brian.

[Greg Wooledge]

On Sat, Jul 10, 2021 at 01:48:12PM -0500, Brian Thompson wrote:
> Thank you for the detailed response, Andrei.
>
> On Sat, 2021-07-10 at 21:18 +0300, Andrei POPESCU wrote:
> >    Testing doesn't have any direct security support
>
> Is that 100% true? I was originally referring to
> http://security.debian.org/debian-security/dists/testing-security
> when I was talking about "testing security updates". I understand that most
> mirrors don't contain this suite, but it seems to be working pretty well along
> with the "main" mirror I am using for testing updates (i.e. one that is closer
> in proximity).

Several years ago, a decision was made to offer a repository for security
updates in testing. Perhaps some packages even appeared there, though I
cannot confirm that.

There have not been any packages there for a *really* long time. It's
just empty.

[idiot...@gmail.com]

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.

[The Wanderer]

(Just to confirm, are you the person who responded above under the name
Brian Thompson and with the E-mail address tv.d...@googlemail.com?
Because the E-mail address is different, and I don't want to make
assumptions in either direction.)

> "aptitude search '?narrow(?installed,?archive(experimental))' | egrep
> '(mesa|vulkan)'

> aptitude search '?narrow(?installed,?archive(unstable))' | egrep
> '(mesa|vulkan)'

> aptitude search '?narrow(?installed,?archive(testing))' | egrep
> '(mesa|vulkan)'

Thanks; that's at least a reasonable starting reference point. It
doesn't seem to provide package versions, though, although I'm not sure
whether that would be as helpful as I originally thought to expect it to be.

I just ran

$ apt-cache policy $(aptitude search
'?narrow(?installed,?archive(testing))' | egrep '(mesa|vulkan)' | cut -d
' ' -f 3 )

and while the output is somewhat lengthier than I'd like to paste here
without reason, it does seem to tell me the versions I have installed of
each matching package.

When I have time - probably either later tonight, or tomorrow morning,
depending on GDQ interestingness levels - I'll go looking at what's in
experimental and unstable, and start experimenting with installing
specific packages from one or both of those sources. Not my ideal
preferred approach, but the alternative is to wait till testing is
released as stable and new packages start to come into the new testing,
and I don't think I wait to wait that long unless I know for a fact the
result is going to make this work.

> 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.

ACK.

>> (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...

I'm honestly not sure I remember the details of that system well enough
to provide proper nightmares. I like the idea otherwise, though.

To be honest, I tend to just fall back on the standby advice line for
people running sid: "if it breaks, you get to keep the pieces". That
didn't scare me off originally, and I got to live with the result;
anyone who isn't scared off by it probably deserves to live with the
result just as much as I did.

>>> 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.

I hadn't even noticed the RUN button until I looked again after your reply.

Running with no special environment produces both vkcube and glxgears
windows.

Running with the VK_ICD_FILENAMES set to the Radeon profile definition
files produces a glxgears window, but no vkcube window, and no
noticeable error messages.

> 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'll have to keep it in mind to investigate if-and-or-when I have things
running usefully.

>>> 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"

> 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.

I can sympathize with that, although in your place I probably would (as
supported by the fact that, albeit less meaningfully so because of the
different practices in the era involved, I kind of did) choose to go
without them in support of my principles.

> GOG offers drm free games, they also have an optional "gamestore"
> frontend available in Debian named "minigalaxy".

I'm a (mostly-)happy GOG customer, have lost patience with waiting for
the promised Linux port of GOG Galaxy (that being part of why I started
using Lutris), and was not even aware that minigalaxy existed. Thanks
for pointing me to it!

(The last game I bought new, played, and enjoyed was Return of the Obra
Dinn. The last before that was Stardew Valley. I got both from GOG.)

> HumbleBundle also does offer some drm free titles,

I have a few games picked up from the original Humble Indie Bundle, and
maybe one or two more recent ones, but I basically stopped paying
attention to Humble Bundle around the time their successive new bundles
started to contain little or nothing that wasn't tied to Steam.

> Feralinteractive did some good Linux ports, some less convincing,

> but the choice is limited compared to a giant likeSteam, and setting

> up the games is often complicated, or just plain impossible when the
> binaries get outdated and the editor doesn't care...

I'm not sure I've ever heard of them; I'll have to have a look. My taste
in games is limited, but I've found good ones in odd corners.

> 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).

Full ACK.

>>> 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

That matches what I have, pretty much exactly, except for the
timestamps; mine are dated 2021-01-31 13:26.

My radeon_icd.x85_64.json contents are:
{
"ICD": {
"api_version": "1.2.145",
"library_path": "/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so"
},
"file_format_version": "1.0.0"
}

Are yours meaningfully different? I'd expect the only difference to be
the API version number.

>> 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.

I've had a thought about this. What do you have installed that looks
like it might be related to RADV? Either by package names, etc., or
installed files (and then the packages they come from).

On my system, 'apt-cache search radv' finds only a set of packages
related to 'radvd', which is a "Router ADVertisement Daemon"; if it has
anything to do with this context, the fact is well-hidden. I think I
tried 'apt-file search radv' at one point, and the rather more
voluminous result set still contained nothing apparently relevant.

[The Wanderer]

On 2021-07-10 at 19:08, The Wanderer wrote:

> On 2021-07-10 at 17:36, idiot...@gmail.com wrote:

>> There you go, some packages are at the same version in Testing and
>> Unstable, so you will see them in both.
>
> (Just to confirm, are you the person who responded above under the
> name Brian Thompson and with the E-mail address
> tv.d...@googlemail.com? Because the E-mail address is different,
> and I don't want to make assumptions in either direction.)

Argh. I checked this three times, and still managed to misread my
previous-mails list. The above name and E-mail address correspond to
different people; they're clearly not both you.

[Geoff]

The Wanderer wrote:
> (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.
>

I have an nvidia card but afaik the AMD driver is part of the kernel, what kernel version are you running? If your on stable and haven't already try getting a kernel from backports.

Regards
Geoff

[The Wanderer]

I think you're referring to the 'amdgpu' driver, correct?

As I indicated in my original post, that driver is already in use, and
in fact I already have (what appears to be) 3D acceleration via OpenGL.
It's just Vulkan that doesn't seem to see the card.

[Andrei POPESCU]

On Sb, 10 iul 21, 14:38:39, The Wanderer wrote:
> On 2021-07-10 at 14:18, Andrei POPESCU wrote:
>
> > On Sb, 10 iul 21, 06:51:43, Brian Thompson wrote:
> >
> >> On Sat, 2021-07-10 at 13:43 +0200, tv.d...@googlemail.com wrote:
> >>
> >>> Hi, Debian unstable with bits of experimental here
> >>
> >> Is it (usually) wise to intermix different suites?
> >
> > It depends :)
> >
> > In my opinion I'd say the order from less to more dangerous would
> > be:
> >
> > 1. stable + select packages from stable-backports
>
> > 2. oldstable + select packages from oldstable-backports-sloppy
>
> > 3. testing + select packages from unstable
>
> > 4. unstable + select packages from experimental
>
> I'm a little surprised to see that you don't even mention the mix which
> I've been running for the last decade-plus: stable + testing, which
> works out to testing + select packages from stable (the ones which are
> no longer available in testing).
>
> Do you consider that to be so dangerous as to not even be worth mentioning?

What I forgot to mention was that outside the common scenarios above you
are pretty much on your own and you should have a good understanding of
APT priorities and pinning (or be prepared to deal with problems).

The danger level also varies greatly on which is your "main" release.

While your testing + stable as needed mix is pretty simple[1] the
reverse mix stable + select packages from testing requires adequate
pinning and can quickly become problematic for anything but the simplest
packages packages (no or very few dependencies) pulled from testing.

You should be using -backports instead or backport packages yourself if
necessary[2].


[1] No pinning required, unless you want to have *very* good control
over what you install from stable. A similar reasonably safe and easy
setup is unstable + testing as needed, which is probably a good idea
anyway, even if not well documented.

[2] If you do that you might as well consider providing them via
-backports, with the help of a sponsor.

[Alexander V. Makartsev]

On 10.07.2021 20:54, The Wanderer wrote:

I had enough times when I couldn't launch X (at least not with any
acceleration at all, even 2D acceleration) because an updated NVIDIA
driver which was compatible with the new X or kernel version hadn't been
released yet, and enough troubles trying to switch drivers etc. and
remnants left over on the computer afterwards, that it left me with an
antipathy towards using NVIDIA products.

The fact that NVIDIA's Linux support implementation is proprietary is
both the reason for those problems, and an entirely separate reason why
I decided that until that fact changes, I will never voluntarily buy an
NVIDIA card for a Linux system.

I often read about problems with nvidia drivers others are having, but personally I haven't experienced anything like you described.
Probably because these kinds of problems only surface on platforms with Nvidia-Optimus technology, which every OEM out there making it in their unique way.
The only thing I do after installing an updated kernel is rebuild DKMS module by reinstalling "nvidia-kernel-dkms" package, to ensure it would be build using current kernel sources.

As I understand matters, this is another consequence of the fact that
the NVIDIA driver (stack) is proprietary - or rather, the only reason
why there's an nvidia-driver package is because it's not practical (or
necessarily even possible) to provide that functionality in a more
integrated way, because of the proprietary and opaque way the NVIDIA
drivers etc. are provided. In an ideal world, no such explicit separate
package(s) would be needed.

It is the matter of convenience, because nvidia drivers, even legacy ones, are in official Debian repos.
And installation of them is as easy as "apt install nvidia-driver", plus supplementary libraries like GL/GLX, EGL, GLES, OpenCL, VA, VDPAU, Vulkan, etc, all could be found by searching "nvidia-*"
Internally, by the looks of it, AMD drivers and Nvidia drivers look the same. Both of them consist of DKMS kernel module building suite, XOrg modules\extensions and all necessary libraries I've already mentioned.
I don't see any complications or barriers (other than maybe licensing) that prevent creation of "amdgpu-driver" metapackage and naming all other necessary packages "something-amdgpu-something" and "amdgpu-driver-something", in the same way nvidia drivers are made in Debian repos.

I'll take this under advisement; at the very least, it's my fallback if
other investigations don't produce any usable results. The examination
of those packages and the results they provide is appreciated.

I should've mentioned about official instructions for amdgpu driver.
They seem to distinguish between two stacks of drivers [1] and "All-Open" doesn't have Vulkan in it.
It is just a thought, but maybe only a truncated version of "All-Open" stack is available in Debian repos, which rely on Mesa Vulkan implementation instead of more recent variant from "Pro" stack.
Even looking through files from Mesa Vulkan package there is a difference:
    apt-file list mesa-vulkan-drivers | grep ".so"
    mesa-vulkan-drivers: /usr/lib/x86_64-linux-gnu/libvulkan_intel.so
    mesa-vulkan-drivers: /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
    mesa-vulkan-drivers: /usr/share/vulkan/icd.d/intel_icd.x86_64.json
    mesa-vulkan-drivers: /usr/share/vulkan/icd.d/radeon_icd.x86_64.json
And "amdvlk64.so" library file, along with ".json" files from "./vulkan-amdgpu*_amd64.deb" packages don't exist inside Debian repos:
    apt-file find amdvlk64.so
    apt-file find amd_icd64.json
Also file sizes of "libvulkan_radeon.so" and "amdvlk64.so" are far too different.



[1] https://amdgpu-install.readthedocs.io/en/latest/install-overview.html

[tv.d...@googlemail.com]

Le 11/07/2021 à 01:10, The Wanderer a écrit :
> On 2021-07-10 at 19:08, The Wanderer wrote:
>
>> On 2021-07-10 at 17:36, idiot...@gmail.com wrote:
>
>>> There you go, some packages are at the same version in Testing and
>>> Unstable, so you will see them in both.
>>
>> (Just to confirm, are you the person who responded above under the
>> name Brian Thompson and with the E-mail address
>> tv.d...@googlemail.com? Because the E-mail address is different,
>> and I don't want to make assumptions in either direction.)
>
> Argh. I checked this three times, and still managed to misread my
> previous-mails list. The above name and E-mail address correspond to
> different people; they're clearly not both you.
>

Sorry, my bad, I answered from a different device and screwed-up the
"from" field. It's an old address I retired when some unsavory (to my
taste) people adopted close enough aliases that I started getting
abusive or threatening messages that even gmail spam filter couldn't
parse...
But Brian is a completely different person.

[The Wanderer]

On 2021-07-11 at 04:45, Alexander V. Makartsev wrote:

> On 10.07.2021 20:54, The Wanderer wrote:
>
>> I had enough times when I couldn't launch X (at least not with any
>> acceleration at all, even 2D acceleration) because an updated
>> NVIDIA driver which was compatible with the new X or kernel version
>> hadn't been released yet, and enough troubles trying to switch
>> drivers etc. and remnants left over on the computer afterwards,
>> that it left me with an antipathy towards using NVIDIA products.
>>
>> The fact that NVIDIA's Linux support implementation is proprietary
>> is both the reason for those problems, and an entirely separate
>> reason why I decided that until that fact changes, I will never
>> voluntarily buy an NVIDIA card for a Linux system.
>
> I often read about problems with nvidia drivers others are having,
> but personally I haven't experienced anything like you described.
>
> Probably because these kinds of problems only surface on platforms
> with Nvidia-Optimus technology, which every OEM out there making it
> in their unique way.

If I recall correctly,the time when I used an NVIDIA card was before the
name "Optimus" had been coined. It certainly wasn't involved in the
platform I was using at the time.

> The only thing I do after installing an updated kernel is rebuild
> DKMS module by reinstalling "nvidia-kernel-dkms" package, to ensure
> it would be build using current kernel sources.

What about an updated X?

I suppose that problem could just not happen anymore, because X is
seeing so much slower a pace of development (to the point where I think
I understand that it's basically considered end-of-life, or at least
minimal maintenance-only, by X.org)...

>> As I understand matters, this is another consequence of the fact
>> that the NVIDIA driver (stack) is proprietary - or rather, the only
>> reason why there's an nvidia-driver package is because it's not
>> practical (or necessarily even possible) to provide that
>> functionality in a more integrated way, because of the proprietary
>> and opaque way the NVIDIA drivers etc. are provided. In an ideal
>> world, no such explicit separate package(s) would be needed.
>
> It is the matter of convenience, because nvidia drivers, even legacy
> ones, are in official Debian repos.

You're still talking about the proprietary binary driver and its related
software (e.g. the GL/GLX stack), right?

Yes, of course those are in Debian repos (though last I checked they
were all, or nearly all, in non-free). The fact that they're
proprietary, however, means that they *have* to be packaged separately
et cetera, rather than being able to be integrated; that naturally leads
to a separate install-it-all-at-once metapackage. With a non-proprietary
driver and stack, AMDGPU (and, to perhaps a lesser extent, the legacy
Radeon drivers) are susceptible of being better integrated, so the need
for such a metapackage is less.

I'm not looking at that, however. I'm not interested in using the
proprietary implementation unless there's absolutely no other option. If
I were to fall back on the official download-from-AMD driver stack, I
would be using the "All Open" one, not the "Pro" version, specifically
because the "Pro" version is apparently at least partly proprietary.

If that version wouldn't get me Vulkan support after all, then there's
even less reason for me to try using it.

> And installation of them is as easy as "apt install nvidia-driver",
> plus supplementary libraries like GL/GLX, EGL, GLES, OpenCL, VA,
> VDPAU, Vulkan, etc, all could be found by searching "nvidia-*"
>
> Internally, by the looks of it, AMD drivers and Nvidia drivers look
> the same. Both of them consist of DKMS kernel module building suite,

The AMDGPU kernel drivers don't need DKMS, because they're open; they
can be, and are, built and shipped with the kernel.

> XOrg modules\extensions and all necessary libraries I've already
> mentioned. I don't see any complications or barriers (other than
> maybe licensing) that prevent creation of "amdgpu-driver" metapackage
> and naming all other necessary packages "something-amdgpu-something"
> and "amdgpu-driver-something", in the same way nvidia drivers are
> made in Debian repos.

Certainly, nothing prevents it. There's just less need for it, so
apparently no one has bothered to do it yet.

>> I'll take this under advisement; at the very least, it's my
>> fallback if other investigations don't produce any usable results.
>> The examination of those packages and the results they provide is
>> appreciated.
>
> I should've mentioned about official instructions for amdgpu driver.
> They seem to distinguish between two stacks of drivers [1] and
> "All-Open" doesn't have Vulkan in it.

As I understand matters, that's not necessarily correct. If you look at
the page you linked to, the "Pro" stack includes "Pro Vulkan"; that does
*not* necessarily mean that the open stack does not include Vulkan at
all, just that it doesn't have the presumably-proprietary version that
comes direct from AMD.

> It is just a thought, but maybe only a truncated version of
> "All-Open" stack is available in Debian repos, which rely on Mesa
> Vulkan implementation instead of more recent variant from "Pro"
> stack.

Well, yes. What's wrong with that? (And why would it be considered
"truncated"? If the "All Open" stack doesn't include AMD's Vulkan
implementation, as your interpretation seems to indicate, then leaving
that out wouldn't involve truncating the stack.)

> Even looking through files from Mesa Vulkan package there is a difference:
> apt-file list mesa-vulkan-drivers | grep ".so"
> mesa-vulkan-drivers: /usr/lib/x86_64-linux-gnu/libvulkan_intel.so
> mesa-vulkan-drivers: /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
> mesa-vulkan-drivers: /usr/share/vulkan/icd.d/intel_icd.x86_64.json
> mesa-vulkan-drivers: /usr/share/vulkan/icd.d/radeon_icd.x86_64.json
> And "amdvlk64.so" library file, along with ".json" files from
> "./vulkan-amdgpu*_amd64.deb" packages don't exist inside Debian repos:
> apt-file find amdvlk64.so
> apt-file find amd_icd64.json
> Also file sizes of "libvulkan_radeon.so" and "amdvlk64.so" are far too
> different.

If you look back at my original post, I mentioned amdvlk, and pointed to
a set of RFP bugs about getting it packaged and made available.

However, since we have a report of this working just fine without need
for amdvlk, clearly that isn't *necessary* to get this working.

[The Wanderer]

I can see how it could become an issue for someone who's trying to stick
mainly with stable, but that's never been my goal. As soon as you
dist-upgrade against the combination of testing and stable, you're
primarily on testing, with stable present only as an "in case of
removal" backstop.

> You should be using -backports instead or backport packages yourself
> if necessary[2].

I hope this is general/generic "you", and not directed at me
specifically. I first read this as chiding me against running this mix,
and that came across as mildly offensive.

> [1] No pinning required, unless you want to have *very* good control
> over what you install from stable. A similar reasonably safe and
> easy setup is unstable + testing as needed, which is probably a good
> idea anyway, even if not well documented.

I used to track testing + unstable, which worked out to unstable +
select packages from testing.

That's the setup which blew up under my feet into an inconsistent,
unrepairable Debian installation, as I've mentioned elsewhere in this
thread.

However, I do not blame that on the fact of running a combination of
suites. I blame it on the fact of tracking unstable at all.

I absolutely do not recommend tracking sid on a production system, ever.
Installing specific packages from sid, carefully and only as needed, is
one thing; dist-upgrade against sid is something I very strongly
recommend against.

[Nicholas Geovanis]

On Sat, Jul 10, 2021, 9:53 AM Eike Lantzsch ZP6CGE <zp6...@gmx.net> wrote:

On Samstag, 10. Juli 2021 09:13:57 -04 Brian Thompson wrote:
> On Sat, 2021-07-10 at 14:57 +0200, tv.d...@googlemail.com wrote:
> > This is not the point of the OP message, so let's not derail
>
> I apologize for accidentally derailing.  I should have started a new
> thread. I'm still relatively new to the Debian community.

No problem - AMTRAK always derails and still runs. If it is a matter of
tracks or a matter of running stock or a matter of cars or trucks
passing level passings with lights flashing is a moot question.

Moot :-)

Amtrak derails because it doesn't own the rails it runs on. Except in the northeast corridor.

And the major railroads favor their traffic over Amtrak's.

[The Wanderer]

On 2021-07-10 at 17:36, idiot...@gmail.com wrote:

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]

On 2021-07-11 at 13:20, The Wanderer wrote:

> On 2021-07-10 at 17:36, idiot...@gmail.com wrote:
>
>> Le 10/07/2021 à 17:41, The Wanderer a écrit :

>>> 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)'

<snip>

> 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'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 some reason, Vulkan is still failing to detect the presence
> of any physical GPU.

> 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...

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.

[Andrei POPESCU]

On Du, 11 iul 21, 06:54:31, The Wanderer wrote:
> On 2021-07-11 at 03:31, Andrei POPESCU wrote:
> >
> > While your testing + stable as needed mix is pretty simple[1] the
> > reverse mix stable + select packages from testing requires adequate
> > pinning and can quickly become problematic for anything but the
> > simplest packages packages (no or very few dependencies) pulled from
> > testing.
>
> I can see how it could become an issue for someone who's trying to stick
> mainly with stable, but that's never been my goal. As soon as you
> dist-upgrade against the combination of testing and stable, you're
> primarily on testing, with stable present only as an "in case of
> removal" backstop.

Unless one has appropriate pinning in place ;)

> > You should be using -backports instead or backport packages yourself
> > if necessary[2].
>
> I hope this is general/generic "you", and not directed at me
> specifically. I first read this as chiding me against running this mix,
> and that came across as mildly offensive.

Indeed it was, apologies for the bad wording.

In my head it didn't apply to you because you aren't actually running
that mix.

[Andrei POPESCU]

On Du, 11 iul 21, 14:25:31, The Wanderer wrote:
>
> 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.

As far as I understand, this should be taken care of automatically via
systemd-logind. Might need some Desktop Environment integration as well.

[tv.d...@googlemail.com]

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.

[The Wanderer]

On 2021-07-12 at 03:49, Andrei POPESCU wrote:

> On Du, 11 iul 21, 14:25:31, The Wanderer wrote:
>
>> 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.
>
> As far as I understand, this should be taken care of automatically
> via systemd-logind. Might need some Desktop Environment integration
> as well.

I don't run systemd, in part specifically because I don't like
systemd-logind. (IMO, logging in should not automatically launch a
daemon.)

I have, somewhat reluctantly, accepted running elogind instead; I think
that's supposed to be functionality-identical to systemd-logind, just
standalone rather than integrated with the rest of the interconnected
tangle of systemd elements. In this case, it doesn't seem to have
adjusted group membership or device ownership or similar; I'm not sure
whether that's a bug in elogind, or a consequence of the fact that it
doesn't tie in with e.g. udev, or just a misconfiguration on my end.

That said, AFAIR it was never necessary to have a daemon like that in
order for my user to wind up being a member of group video (and having
access to the GPU via GLX), so for such a daemon to be necessary in
order for my user to be a member of group render (and have access to the
GPU via Vulkan) seems like an undesirable and unfortunate step backwards...

[The Wanderer]

On 2021-07-12 at 05:36, tv.d...@googlemail.com wrote:

> Le 11/07/2021 à 20:25, The Wanderer a écrit :

>> 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.

As Andrei points out, this is probably because I'm running sysvinit, and
you're probably running systemd. Debian nowadays is designed and
optimized around the complexity of systemd, so things which systemd
handles automagically by some unknown path won't necessarily be handled
under other, less complex, init systems.

> 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.

Yeah - that's one of the reasons why I was hesitant to go with even
packages from unstable, much less experimental, unless I had reason to
believe it'd make a difference.

> 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?

No; in fact, now that vulkaninfo recognizes the GPU, so do other
programs. (I was using vulkaninfo's ability to do so as a proxy for
other things. I just hadn't run the more heavy-weight tests again at the
time when I sent the previous mail.)

I've been able to get FFXIV to launch, and the benchmark to run (at what
seems like really good performance, although with one weird bug
involving fullscreen switching), without issues. That one
group-membership change seems to have been enough to resolve the Vulkan
issue and get things working.

[Andrei POPESCU]

On Lu, 12 iul 21, 06:08:27, The Wanderer wrote:
>
> That said, AFAIR it was never necessary to have a daemon like that in
> order for my user to wind up being a member of group video (and having
> access to the GPU via GLX), so for such a daemon to be necessary in
> order for my user to be a member of group render (and have access to the
> GPU via Vulkan) seems like an undesirable and unfortunate step backwards...

As far as I know the user created during install will be added to
various groups by the installer. In the traditional setup all other
users and / or groups that get added later must be managed manually by
the administrator.

I'm guessing either the 'render' group was added since your system was
last installed, or it wasn't in the installer's list of groups the first
user should be a member of (or both).

With systemd-logind some permissions are managed dynamically, e.g.
locally logged in users should automatically get permission to use the
available hardware (audio, video, etc.), reboot / shutdown the system if
no other users are logged in, etc.