5 ms·
Yes, while the Chrome/Chromium hardware decoding, or any other uses of the GPU, like WebGL, was always impeccable on Linux, with Firefox that was always an adve
by adrian_b 3mo ago
Yes, while the Chrome/Chromium hardware decoding, or any other uses of the GPU, like WebGL, was always impeccable on Linux, with Firefox that was always an adventure, much more often not working than working (at least with an NVIDIA GPU).
So I also hope that Vulkan decoding might solve this behavior of Firefox on Linux.
- Matl 3mo ago> Yes, while the Chrome/Chromium hardware decoding, or any other uses of the GPU, like WebGL, was always impeccable on Linux Have you seen the massive blacklist Chromium maintains?
- RamRodification 3mo agoBlacklist of what? I don't understand what a blacklist would be used for in this context. Specific unsupported hardware?
- cwillu 3mo agoYes.
- nullify88 3mo agoWell, supposedly. But in my experience, there was no consequence disabling the blacklist in order to enable hardware video encoding and decoding.
- mey 3mo agoMy assumption would be, when there is a large corpus of crash reports for a certain configuration of hardware, knowing if it's a hardware failure, driver bug, or software incompatibly, is pretty hard. So it's probably easier to catch false positives and not get blamed for a faulty product, even if you aren't the cause. Drivers crash under the hood in windows all the time, even today, but once MS did a better job of just restarting the offending drivers where possible instead of BSODing, people thought windows was an unstable product. Which is technically true from the users perspective, even though it wasn't Microsoft's fault directly. You may have had a good combo that simply shouldn't have been on the list/was later patched/or your system is more stable that the average persons.
- nullify88 3mo agoThere was nothing special about my setup. Standard intel processor with i915 driver which I would imagine covers a fairly large chunk of installs out there.
- cwillu 3mo agoAnd in my experience, there was. One person's lived experience is another person's “supposedly”.
- roryirvine 3mo agoYeah, Chromium even blacklists perfectly ordinary 2020s "choose this for a quiet life" Intel igpus that work fine in Firefox (and, weirdly, Chrome itself). First thing to do with Chromium has always been adding various flags to force-enable things, followed by changing a bunch of chrome://gpu settings. Not sure why Chrome does better, but it's closed source so no reasonable way of knowing what it was up to. Firefox did go through a rough patch 4-5 years ago where it needed various things in about:config to get hw decode when running under Wayland, but it's gone back to working out of the box for me in whatever ESR version has come with the last couple of Debian releases.
- gucci-on-fleek 3mo agoInteresting, I've personally had the exact opposite experience: Chromium hardware decoding was always half-broken for me and nearly impossible to get working, whereas in Firefox, I had to modify a single setting in "about:config" 5 years ago and it's worked perfectly ever since.
- temp0826 3mo agoI guess my caveat always is that I use Fedora (which does not include hw codecs by default due to licensing) and have to manage mesa/ffmpeg stuff myself. Adds a bit to the frustration (though it's self-inflicted so I don't usually complain :)
- gucci-on-fleek 3mo agoI'm on Fedora too, so I probably should have said "getting hardware decoding to work in Firefox is no harder than getting it to work with any other Fedora program" rather than claiming that it's actually easy :)
- GreenVulpine 3mo agoNvidia drivers on Linux are not really display quality. The effort goes towards CUDA for headless rigs. They work great for AI and that's it. Pair them with an AMD and Intel card for display, graphics and video acceleration. Otherwise you end up with too many cases of booting into a black screen, random software breaking, games not working, bad performance and just jank in general.
- drnick1 3mo ago> booting into a black screen, random software breaking, games not working, bad performance and just jank in general. That has not been my experience at all, using either the old closed source drivers or the newer "open" drivers. (Note: I am referring to the open source Nvidia kernel drivers, not Nouveau.)
- csdreamer7 3mo agoThat has been my experience (blank screen and jank). Literally had to pull out the Nvidia card and run on the iGPU for my work because of suspend and resume issues.
- adrian_b 3mo agoI have heard frequently complaints about NVIDIA drivers on Linux, but I always wonder about which are the exact circumstances in which such problems can appear. I have used NVIDIA GPUs on Linux continuously since 2005, i.e. for 21 years. During this time I have been using more than a dozen different kinds of desktop NVIDIA GPUs, both GeForce and Quadro (I have multiple computers). I have also used several kinds of laptops with NVIDIA GPUs, both GeForce and Quadro, from Dell and from Lenovo. I have also used NVIDIA Jetson SBCs, with NVIDIA Volta GPUs. On all these many kinds of hardware and during these 21 years, I have never had any problem with the NVIDIA GPUs, either on Linux or on FreeBSD (NVIDIA is among the few hardware vendors who also provide FreeBSD device drivers). On the other hand, I have had various problems with my AMD GPUs, or, more rarely, with my Intel GPUs (OpenGL defects on both, while with certain AMD GPUs I had problems in multiple monitor configurations). Today I have more AMD GPUs than NVIDIA GPUs, but that is because I use the AMD GPUs for computational purposes, while the NVIDIA GPUs are used for graphics. I use many programs based on OpenGL, and the quality of the graphics has always been perfect with NVIDIA GPUs, while in the past it was quite bad on both AMD GPUs and Intel GPUs, regardless whether the "professional" closed-source AMD drivers were used, or their open-source drivers. By bad I mean that the AMD and Intel GPUs failed to render correctly some complex images drawn with OpenGL, unlike the NVIDIA GPUs, which were flawless. The quality of the AMD and Intel drivers has improved a lot in recent years, but I have not checked whether now they really match the NVIDIA drivers in all cases. While the above was about OpenGL, where there has never been any doubt that the NVIDIA device drivers are the best, regarding video, there is more than a decade since I have never used any monitors that are not 4k resolution, 10-bit per color component and P3-D65 (Display P3) wide color gamut. I frequently watch various high-resolution movies, using various kinds of video codecs on an NVIDIA GPU and the quality of rendering has always been impeccable. Though unlike with OpenGL, with video I also do not remember ever having any problem on Intel GPUs. I do not doubt that there must be cases when NVIDIA does not work well on Linux, but I am certain that those are never caused by the NVIDIA drivers alone, but by some interaction with other installed software that may have been written to work only with other GPUs. For example, even if some years ago Firefox had worked with my NVIDIA GPU, that got broken at some point and for the last few years Firefox claims to not detect any GPU, so WebGL and hardware video decoding do not work, and all efforts to force their enabling in the Firefox configuration have failed, even if other browsers like Chromium and Vivaldi work perfectly and a great number of other graphics or video programs also work perfectly. Firefox is the only program that I have ever used and that has not worked fine with NVIDIA GPUs. I certainly assign this bug to Firefox, not to the NVIDIA drivers, which also work perfectly with the programs that I write myself. Among the Linux kernel developers, there are some who for some weird reason have sabotaged the NVIDIA drivers from time to time for many years, by making various gratuitous changes in the Linux kernel API for device drivers, designed with the precise purpose of breaking the existing NVIDIA drivers. Every time when this happens, the NVIDIA drivers fail to work with the new Linux kernel version, but that is no fault of NVIDIA. This creates an additional work for the NVIDIA maintainers, who must release a new version of the NVIDIA device drivers, as soon as they succeed to design a workaround for the Linux API changes. The workaround may be difficult, because in many cases the Linux kernel has stopped exporting certain functions used by the NVIDIA driver, restricting their use to device drivers with different code licenses. This export conditioned by the license of the driver that imports it has no legal basis and no relationship whatsoever with the requirements of the GPL. This is the reason why some people claim that they could not boot some Linux system with certain NVIDIA drivers. I also assign this fault to the Linux kernel developers who had intentionally broken the NVIDIA device drivers, which I consider a childish and unprofessional behavior. There is no doubt that NVIDIA cannot be criticized when this happens. To be clear, I consider that it is extremely bad and undesirable to run on your computer any privileged code, e.g. a device driver, which is not open source. However, this policy should not be something that kernel developers enforce by artificial restrictions. They should try to educate their users to avoid unsafe closed source device drivers, but when a user has serious practical reasons to make an exception, that should be the user's decision, and it is not the role of a kernel maintainer to forbid this.