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