Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #237141 > unrolled thread

Vulkan with Radeon RX 5700 XT

Back to article view | Back to linux.debian.user

Contents

  Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-09 23:50 +0200
    Re: Vulkan with Radeon RX 5700 XT "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2021-07-10 13:50 +0200
      Re: Vulkan with Radeon RX 5700 XT Brian Thompson <brian@hashvault.io> - 2021-07-10 14:00 +0200
        Re: Vulkan with Radeon RX 5700 XT "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2021-07-10 15:00 +0200
          Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT) Brian Thompson <brian@hashvault.io> - 2021-07-10 15:20 +0200
            Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT) "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2021-07-10 15:30 +0200
            Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT) Eike Lantzsch ZP6CGE <zp6cge@gmx.net> - 2021-07-10 17:00 +0200
              Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT) Nicholas Geovanis <nickgeovanis@gmail.com> - 2021-07-11 17:20 +0200
        Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan  with Radeon RX 5700 XT] Andrei POPESCU <andreimpopescu@gmail.com> - 2021-07-10 20:20 +0200
          Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan  with Radeon RX 5700 XT] The Wanderer <wanderer@fastmail.fm> - 2021-07-10 20:40 +0200
            Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan  with Radeon RX 5700 XT] Brian <ad44@cityscape.co.uk> - 2021-07-10 20:50 +0200
            Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan  with Radeon RX 5700 XT] Andrei POPESCU <andreimpopescu@gmail.com> - 2021-07-11 09:40 +0200
              Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan  with Radeon RX 5700 XT] The Wanderer <wanderer@fastmail.fm> - 2021-07-11 13:00 +0200
                Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan  with Radeon RX 5700 XT] Andrei POPESCU <andreimpopescu@gmail.com> - 2021-07-12 09:50 +0200
          Re: Un/Safe mixtures for Debian releases and suites [was: Re:  Vulkan with Radeon RX 5700 XT] Brian Thompson <brian@hashvault.io> - 2021-07-10 20:50 +0200
            Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan  with Radeon RX 5700 XT] Brian <ad44@cityscape.co.uk> - 2021-07-10 21:00 +0200
            Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan  with Radeon RX 5700 XT] Greg Wooledge <greg@wooledge.org> - 2021-07-10 21:00 +0200
      Re: Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-10 17:50 +0200
        Re: Vulkan with Radeon RX 5700 XT "idiotein30@gmail.com" <idiotein30@gmail.com> - 2021-07-10 23:40 +0200
          Re: Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-11 01:10 +0200
            Re: Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-11 01:20 +0200
              Re: Vulkan with Radeon RX 5700 XT "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2021-07-11 12:40 +0200
          Re: Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-11 19:30 +0200
            Re: Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-11 20:30 +0200
              Re: Vulkan with Radeon RX 5700 XT Andrei POPESCU <andreimpopescu@gmail.com> - 2021-07-12 10:00 +0200
                Re: Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-12 12:10 +0200
                  Re: Vulkan with Radeon RX 5700 XT Andrei POPESCU <andreimpopescu@gmail.com> - 2021-07-12 14:30 +0200
              Re: Vulkan with Radeon RX 5700 XT "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2021-07-12 11:40 +0200
                Re: Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-12 12:20 +0200
    Re: Vulkan with Radeon RX 5700 XT "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-07-10 17:20 +0200
      Re: Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-10 18:00 +0200
        Re: Vulkan with Radeon RX 5700 XT "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-07-11 10:50 +0200
          Re: Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-11 12:50 +0200
    Re: Vulkan with Radeon RX 5700 XT Geoff <unit735@bigpond.com> - 2021-07-11 04:00 +0200
      Re: Vulkan with Radeon RX 5700 XT The Wanderer <wanderer@fastmail.fm> - 2021-07-11 05:50 +0200

Page 1 of 2  [1] 2  Next page →

#237141 — Vulkan with Radeon RX 5700 XT

[Multipart message — attachments visible in raw view] — view raw

(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

[toc] | [next] | [standalone]

#237159

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.

[toc] | [prev] | [next] | [standalone]

#237160

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2021-07-10 at 13:43 +0200, tv.debian@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

[toc] | [prev] | [next] | [standalone]

#237161

Le 10/07/2021 à 13:51, Brian Thompson a écrit :
> On Sat, 2021-07-10 at 13:43 +0200, tv.debian@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).
> 
  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? ;-)

[toc] | [prev] | [next] | [standalone]

#237162 — Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT)

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2021-07-10 at 14:57 +0200, tv.debian@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

[toc] | [prev] | [next] | [standalone]

#237163 — Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT)

Le 10/07/2021 à 15:13, Brian Thompson a écrit :
> On Sat, 2021-07-10 at 14:57 +0200, tv.debian@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.
> 
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.

[toc] | [prev] | [next] | [standalone]

#237164 — Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT)

On Samstag, 10. Juli 2021 09:13:57 -04 Brian Thompson wrote:
> On Sat, 2021-07-10 at 14:57 +0200, tv.debian@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.
People here on debian-user use to derail all the time.
q.e.d.
Eike

--
Eike Lantzsch ZP6CGE

[toc] | [prev] | [next] | [standalone]

#237201 — Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT)

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jul 10, 2021, 9:53 AM Eike Lantzsch ZP6CGE <zp6cge@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.debian@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.

People here on debian-user use to derail all the time.
> q.e.d.
> Eike
>
> --
> Eike Lantzsch ZP6CGE
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#237168 — Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Multipart message — attachments visible in raw view] — view raw

On Sb, 10 iul 21, 06:51:43, Brian Thompson wrote:
> On Sat, 2021-07-10 at 13:43 +0200, tv.debian@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

[toc] | [prev] | [next] | [standalone]

#237169 — Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Multipart message — attachments visible in raw view] — view raw

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.debian@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?

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

[toc] | [prev] | [next] | [standalone]

#237171 — Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

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.

[toc] | [prev] | [next] | [standalone]

#237191 — Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Multipart message — attachments visible in raw view] — view raw

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

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

[toc] | [prev] | [next] | [standalone]

#237197 — Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Multipart message — attachments visible in raw view] — view raw

On 2021-07-11 at 03:31, Andrei POPESCU wrote:

> On Sb, 10 iul 21, 14:38:39, The Wanderer wrote:
> 
>> On 2021-07-10 at 14:18, Andrei POPESCU wrote:

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

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.

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

[toc] | [prev] | [next] | [standalone]

#237227 — Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Multipart message — attachments visible in raw view] — view raw

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.

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

[toc] | [prev] | [next] | [standalone]

#237170 — Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#237172 — Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

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.

[toc] | [prev] | [next] | [standalone]

#237173 — Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

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.

[toc] | [prev] | [next] | [standalone]

#237166

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#237176

Le 10/07/2021 à 17:41, The Wanderer a écrit :
> 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 you go, some packages are at the same version in Testing and 
Unstable, so you will see them in both.

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

i A libegl-mesa0 - free implementation of the EGL API -- Mesa vendor library
i  libegl-mesa0:i386 - free implementation of the EGL API -- Mesa vendor 
library
i  libegl1-mesa:i386 - transitional dummy package
i A libgl1-mesa-dri - free implementation of the OpenGL API -- DRI modules
i A libgl1-mesa-dri:i386 - free implementation of the OpenGL API -- DRI 
modules
i A libgl1-mesa-glx - transitional dummy package
i A libglapi-mesa - free implementation of the GL API -- shared library
i A libglapi-mesa:i386 - free implementation of the GL API -- shared library
i A libglx-mesa0 - free implementation of the OpenGL API -- GLX vendor 
library
i A libglx-mesa0:i386 - free implementation of the OpenGL API -- GLX 
vendor library
i A libosmesa6 - Mesa Off-screen rendering extension
i A libosmesa6:i386 - Mesa Off-screen rendering extension
i  mesa-opencl-icd - free implementation of the OpenCL API -- ICD runtime
i A mesa-va-drivers - Mesa VA-API video acceleration drivers
i A mesa-vdpau-drivers - Mesa VDPAU video acceleration drivers
i  mesa-vulkan-drivers - Mesa Vulkan graphics drivers
i  mesa-vulkan-drivers:i386 - Mesa Vulkan graphics drivers

aptitude search '?narrow(?installed,?archive(unstable))' | egrep 
'(mesa|vulkan)'
i A libglu1-mesa - Mesa OpenGL utility library (GLU)
i  libglu1-mesa:i386 - Mesa OpenGL utility library (GLU)
i A libglu1-mesa-dev - Mesa OpenGL utility library -- development files
i A libvulkan-dev - Vulkan loader library -- development files
i A libvulkan1 - Vulkan loader library
i A libvulkan1:i386 - Vulkan loader library
i A mesa-utils - Miscellaneous Mesa GL utilities
i  mesa-utils-extra - Miscellaneous Mesa utilies (opengles, egl)
i  vulkan-tools - Miscellaneous Vulkan utilities

aptitude search '?narrow(?installed,?archive(testing))' | egrep 
'(mesa|vulkan)'
i A libglu1-mesa - Mesa OpenGL utility library (GLU)
i  libglu1-mesa:i386 - Mesa OpenGL utility library (GLU)
i A libglu1-mesa-dev - Mesa OpenGL utility library -- development files
i A libvulkan-dev - Vulkan loader library -- development files
i A libvulkan1 - Vulkan loader library
i A libvulkan1:i386 - Vulkan loader library
i A mesa-utils - Miscellaneous Mesa GL utilities
i  mesa-utils-extra - Miscellaneous Mesa utilies (opengles, egl)
i  vulkan-tools - Miscellaneous Vulkan utilities

I also run llvm-12 from unstable, but really this gpu has been running 
fine almost from the start (more than two years ago), so I don't think 
testing packages are outdated, baring a massive regression or bug it 
should work.

> 
> (There was a time when I tracked sid. That computer wound up in an
> inconsistent state, to the point that it wasn't worth fixing and would
> have needed a full reinstall and possibly a few other things into the
> bargain. I lived with it until I could build a replacement, then
> migrated away to track testing and have never considered looking back.)
I have read such horror stories, and got into some troubles with buggy 
libc6 or systemd migrations over time, but I never reinstalled on my 
desktops/workstation. Booting into a live system and chrooting was the 
most drastic steps I had to take, and no more often than a couple of 
times in years across several computers. Maybe we should start a thread 
and share our "frankensystems" setups to give nightmares to developers 
and professional sysadmins out there? I just don't want to be 
responsible for users copy/pasting verbatim and breaking their systems, 
then blaming Debian for it...

> 
>> If you want a G.U.I. vulkan test app you can use "goverlay", if you
>> want vulkan related info displayed in another game/programm you can
>> try "mangohud".
> 
> What exactly would you recommend as a Vulkan-functionality testing
> procedure with goverlay? The program launches without issues both with
> and without the explicit specifying of VK_ICD_FILENAMES, but doesn't
> seem to show anything indicating what graphics adapters it's using or
> seeing. I don't know it or its usage well enough to judge what needs to
> be done from its interface in order to test (and while I could go
> digging or do trial-and-error, that's not my focus right now), and its
> man page says exactly the same thing as the package description, which
> isn't useful for figuring out how to run or use the program.
It doesn't do anything special by itself, just offers a graphical 
interface to set some parameters and run the "cubes" and "gears" tests 
for vulkan and opengl, offering a few stats for both.
When setup and used as a startup parameter with programs it can apply 
the settings to the output, and the overlay can give a quick view of how 
well it's running. There's pre-built wrapper to run Steam, Lutris or 
Heroic launchers with it.
I have to admit that this things are quite foreign to me, I just debug 
it when something breaks on the kids setups.

> 
> (I just tested mangohud with glxgears, and bizarrely enough, it appears
> to reduce FPS in that demo by a factor of about 3.5 - from about 30K to
> about 8.5K. Not sure if that's got to do with the fact that Vulkan isn't
> working correctly on my system or not, even though glxgears is using
> OpenGL.)
Any overlay or video effect is going to have an impact, however minimal, 
on the overall performances or resources used.

> 
>> For wine you probably want to install i386 (32bits) vulkan libraries
>> too alongside the amd64 ones.
> 
> I am very familiar with multiarch considerations, especially for Wine.
> Enabling i386 was one of the first steps I took in the software-side
> build of my current machine, and I've been careful to check i386 package
> versions in examining my Vulkan setup.
> 
>> Here my sons (with the same setup, radeon 5700XT and Vega56 cards)
>> use the Steam "Proton" implementation of wine happily, vulkan games
>> run fine. Linux native games run in vulkan mode too.
>>
>> I have given up on trying to get anything to run with plain wine
>> years ago, so can't help with this, but Steam "Proton" version or
>> "GloriousEggroll" (yes it's a real thing) run almost any Windows
>> games my kids throw at it, in vulkan mode when available, sometime
>> much better than native Linux versions (sadly).
> 
> I'm not likely to use Proton, because I have a bias against Steam; I
> think it traces back in part to early-days "anything which wants you to
> install it in a way that bypasses the system's package-management system
> is bad"
[...] cut

I am not happier with Steam which is really proprietary overhead to run 
games which are also totally closed source and proprietary, not to 
mention the security and privacy issues that come with it, but I do give 
them thanks for making my life much simpler by actively supporting 
gaming on Linux, and almost making dual-booting Windows a thing of the 
past. Only a couple of online games with stupid anti-cheat systems keep 
me from being a Debian only shop.
GOG offers drm free games, they also have an optional "gamestore" 
frontend available in Debian named "minigalaxy". HumbleBundle also does 
offer some drm free titles, Feralinteractive did some good Linux ports, 
some less convincing, but the choice is limited compared to a giant like 
Steam, and setting up the games is often complicated, or just plain 
impossible when the binaries get outdated and the editor doesn't care... 
The proliferation of Windows only game stores like Origin, Uplay, Epic 
store to name a few, who don't care at all about Linux isn't helping 
either. So Steam is better than my kids thinking Linux is just for 
bearded geeks and "boring" servers (even if ironically some of their 
online games servers are running Linux, but don't support it as a client).
> 
>> If I can help narrow down what package or version is causing you
>> trouble, I'll do.
> 
> At first glance, I think the most likely area of focus should be the
> ICDs. What do you have under /usr/share/vulkan/icd.d/ (or in the
> vicinity, named in a way that makes it look like it might be
> ICD-related)? If you have anything there other than
> {intel,lvp,radeon}_icd.{i686,x86_64}.json, does it come from
> mesa-vulkan-drivers, or from somewhere else?
I never tinkered or changed anything there:

ll /usr/share/vulkan/icd.d/

-rw-r--r-- 1 root root 161  2 juil. 15:26 intel_icd.i686.json
-rw-r--r-- 1 root root 163  2 juil. 15:26 intel_icd.x86_64.json
-rw-r--r-- 1 root root 159  2 juil. 15:26 lvp_icd.i686.json
-rw-r--r-- 1 root root 161  2 juil. 15:26 lvp_icd.x86_64.json
-rw-r--r-- 1 root root 162  2 juil. 15:26 radeon_icd.i686.json
-rw-r--r-- 1 root root 164  2 juil. 15:26 radeon_icd.x86_64.json

dpkg -S /usr/share/vulkan/icd.d/radeon_icd.x86_64.json

mesa-vulkan-drivers:amd64: /usr/share/vulkan/icd.d/radeon_icd.x86_64.json

On some systems I tried getting Blender gpu hardware rendering to work 
reliably with mesa/radeon icd but never really succeeded so far. But for 
games and vulkan stuff I never had to.
> 
> Is there anything in /usr/share/doc/mesa-vulkan-drivers/changelog.gz (or
> similar) which looks like it might represent the difference? I can see
> changelog.Debian.gz on packages.debian.org, but at a glance I'm not
> finding a way to view the full package changelog without at least
> downloading the .deb.
> 
> I'm sure I should be thinking of other things to inquire about, but
> nothing's coming quickly to mind, and I've got the last day of SGDQ
> running in the other room; I'm missing part of a block of highly
> entertaining runs right now, so I'd rather not be away from that screen
> for too long today. With any luck, I'll be better able to brain about
> this next time I check in.
> 

[toc] | [prev] | [next] | [standalone]

#237182

[Multipart message — attachments visible in raw view] — view raw

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

> Le 10/07/2021 à 17:41, The Wanderer a écrit :
>
>> On 2021-07-10 at 07:43, tv.debian@googlemail.com wrote:

>>> Hi, Debian unstable with bits of experimental here (because of the
>>> freeze I pull some newer packages from experimental). Same graphic
>>> card (5700XT), mesa drivers (21.1.4 at this precise moment, from
>>> experimental). Here vulkan works afaik.
>> 
>> For comparison, I have mesa-vulkan-drivers 20.3.4-1, from testing.
>> 
>>> vulkaninfo reports my card as:
>>> "Group 1:
>>>        Properties:
>>>          physicalDevices: count = 1
>>>          AMD RADV NAVI10 (ACO) (ID: 0)
>>>          subsetAllocation = 0
>>>        Present Capabilities:
>>>          AMD RADV NAVI10 (ACO) (ID: 0):
>>>          Can present images from the following devices: count = 1
>>>          AMD RADV NAVI10 (ACO) (ID: 0)
>>> "
>> 
>> That's excellent news; it means that, at least in principle, this
>> can work in (relatively-)clean Debian as currently constituted. (It
>> also confirms that RADV is the relevant thing here; my reading
>> wasn't conclusive as to whether or not that was specifically
>> something for older card models.)
>> 
>> Can you indicate exactly which Vulkan-related packages you're
>> running from experimental? For that matter, a list of
>> Vulkan-related packages and package versions from unstable too
>> would probably be appropriate, since I track testing and am
>> *highly* hesitant to upgrade against sid wholesale.
> 
> There you go, some packages are at the same version in Testing and 
> Unstable, so you will see them in both.

(Just to confirm, are you the person who responded above under the name
Brian Thompson and with the E-mail address tv.debian@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

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web