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
Attachment:
signature.asc
Description: OpenPGP digital signature