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 2 of 2 — ← Prev page 1 [2]

#237183

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

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

> On 2021-07-10 at 17:36, idiotein30@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.debian@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.

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

#237195

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

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

#237205

[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.
> 
> "aptitude search '?narrow(?installed,?archive(experimental))' | egrep 
> '(mesa|vulkan)'
> 
> i A libegl-mesa0 - free implementation of the EGL API -- Mesa vendor library
> i  libegl-mesa0:i386 - free implementation of the EGL API -- Mesa vendor 
> library
> i  libegl1-mesa:i386 - transitional dummy package
> i A libgl1-mesa-dri - free implementation of the OpenGL API -- DRI modules
> i A libgl1-mesa-dri:i386 - free implementation of the OpenGL API -- DRI 
> modules
> i A libgl1-mesa-glx - transitional dummy package
> i A libglapi-mesa - free implementation of the GL API -- shared library
> i A libglapi-mesa:i386 - free implementation of the GL API -- shared library
> i A libglx-mesa0 - free implementation of the OpenGL API -- GLX vendor 
> library
> i A libglx-mesa0:i386 - free implementation of the OpenGL API -- GLX 
> vendor library
> i A libosmesa6 - Mesa Off-screen rendering extension
> i A libosmesa6:i386 - Mesa Off-screen rendering extension
> i  mesa-opencl-icd - free implementation of the OpenCL API -- ICD runtime
> i A mesa-va-drivers - Mesa VA-API video acceleration drivers
> i A mesa-vdpau-drivers - Mesa VDPAU video acceleration drivers
> i  mesa-vulkan-drivers - Mesa Vulkan graphics drivers
> i  mesa-vulkan-drivers:i386 - Mesa Vulkan graphics drivers

I now have all of these (except the dummy packages, which I skipped as
irrelevant) installed from experimental. All the ones you listed from
unstable seem to be at the same version in testing, and have no
available version in experimental, so there's nothing to upgrade there.

I've also gone so far as to upgrade my kernel to the one in experimental
(it was only a Debian-packaging version upgrade: 5.10.0-7 to 5.10.0-8).

The results, so far, are exactly the same as before: vulkaninfo reports
only one "device", llvmpipe / lavapipe.

I haven't gone so far as to upgrade the firmware-amd-graphics package to
the one in experimental; the version number indicates that it's only one
week newer than the one in testing (March 22nd rather than March 15th),
which seems unlikely to make a difference. I'd be curious to know which
of the two you've got installed, regardless.

I've at least managed to confirm even more strongly than before that
amdgpu does seem to be in use; not only is it referenced as loaded in
dmesg, it appears prominently in /var/log/Xorg.0.log (where several
other video drivers are tried, including radeon, and all the others seem
to get unloaded while AMDGPU references continue to appear afterwards).

Yet for sone reason, Vulkan is still failing to detect the presence of
any physical GPU.


I've gone so far as to build vulkaninfo locally, and have gone digging
through the sources looking to figure out how it does detection. What
seems to happen is that it calls vkEnumeratePhysicalDevices() on an
instance of AppInstance; I've tracked that back through the mesa sources
as far as device_select_layer.c, but been unable to identify where the
relevant code in the tangle of that file gets the data from.

I think at this point I probably need to report an issue with Mesa
upstream, and see if they can at least advise me on how to troubleshoot
it further. Hopefully the fact that I'm now mixing package versions
between Mesa 20.x (a few -dev packages, at least, are still on that) and
21.x (the ones listed above) won't be an issue...

I'm unhappy about having to interact with freedesktop.org in order to
pursue this, but that's where Mesa keeps their bug tracker, so there's
not much to be done about it.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#237211

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

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

> On 2021-07-10 at 17:36, idiotein30@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.

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

#237230

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

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.

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

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

#237240

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

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

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]

#237254

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

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.

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

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

#237236

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.

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

#237241

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

On 2021-07-12 at 05:36, tv.debian@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.

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

#237165

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

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
⠈⠳⣄⠀⠀⠀⠀

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

#237167

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

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.

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

#237192

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

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

-- 
With kindest regards, Alexander.

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

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

#237196

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

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

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]

#237187

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

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

#237188

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

On 2021-07-10 at 21:30, Geoff wrote:

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

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.

-- 
   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] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web