Cool, have been using vulkan video decoding via mpv for a while now and it seems fine with little or no performance hits. Glad it's made its way here as getting hardware decoding to actually work in ff has felt like a house of cards (more options are welcome). Does something need to be done to enable/switch to it?
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.
My 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.
There 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.
Yeah, 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.
Interesting, 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.
I 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 :)
I'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 :)
Nvidia 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.
> 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.)
That 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.
I 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.
I have used Linux equally long, Nvidia on my last 3 or 4 systems. They all had problems with very sporadic hard crashes (full system freeze so hard magic sysrq keys don't work, and nothing is visible in the logs. Sometimes with audio looping.) It doesn't happen often, rare enough that I sometimes fooled myself into thinking I'd found and solved the issue. But then 4 months down the road, often with a driver update, suddenly they're back.
I have also seen extremely rare cases of Linux freezes exactly like you described, and I have wondered if there can be any relationship between them and the NVIDIA drivers, mainly because they are the only closed-source drivers that I use.
Nonetheless, I have not seen any evidence about such a relationship. The freezes never occurred while the computer works alone and some program uses the GPU. In all cases the freezes happened right after some quick mouse movement.
The culprit is definitely somewhere in the device drivers, and it cannot be excluded that this may have something to do with NVIDIA, because I do not remember if I have ever seen identical freezes with AMD or Intel GPUs, but that could be just because I have spent less time using directly such computers, instead of using them remotely through SSH.
In any case, this bug is something that requires interactions with the mouse driver, perhaps also with the keyboard driver, and the X server might also have some role.
In such cases, network and HDD/SSD activities appeared to continue normally, only the display was frozen and the keyboard and mouse did not respond. While the initiator could have been something done by the X server, something was stuck in the kernel, because not even the keys that should be intercepted by the kernel worked, as you have also said.
This is certainly a bug whose cause has not be discovered for many years, but it is not yet clear whether it really has anything to do with NVIDIA, since its main effects are upon keyboard and mouse.
>They all had problems with very sporadic hard crashes
I had such an issue recently, on a laptop with an Intel igpu and an Nvidia primus card.
I'm not a coward, so I debugged the system, and found that the crash was caused by the Intel i915 driver trying to do some tricky hdmi related mumbo jumbo with the hdmi port that wasn't even connected to the igpu, it was connected to the nvidia gpu.
When I contacted intel bugtracker, they just said "ah, Nvidia... well, even though their kernel module is open, it's not on the mainline kernel, so go fsck.ext2fs yourself".
The primary advantage of dedicated hardware accelerators for the past ~15 years been power efficiency, rather than performance. Not much of a problem on a desktop, but very noticeable on mobile devices.
Do many people use Firefox on 50" 8K TVs as opposed to regular monitors? I wouldn't want such a large display on a computer unless the computer is being used as media server. And my experience when I got new monitors for work about 18 months ago, was that decent ones at higher than 1440p were more expensive than I felt was worth it.
Also, I expect one or more of the following from a 50" 8K TV at that price:
- Bundled with ad/spyware.
- Poor image and/or sound quality.
- Doesn’t last long, or image quality very noticeably degrades after a relatively short amount of use.
I also wonder if perhaps it’s still like back when HD was still new, where TVs would advertise “Full HD”, but were actually only referring to being able to accept a 1080p input signal which they would then downscale to their <720p LCD panels.
I understand this is important mainly for Nvidia GPUs.
Is there any benefit at all for this (vs the existing VA-API) on Intel and AMD graphics?
VA-API seems to work very well on both of these platforms, as far as I've tested.
It is important in the sense that many Linux programs did not bother to support both the Intel video API and the NVIDIA video API, so they work only with the Intel video API, which is also supported by AMD GPUs.
Programs that are converted to Vulkan should work with any GPUs.
VA-API works very well with the GPUs that support it, while the NVIDIA video API also works very well with the GPUs that support it, i.e. the NVIDIA GPUs.
The Vulkan video API has worked well for some time on NVIDIA, I switched my video player to it long ago.
Eventually the Vulkan video API should work well on all GPUs, so there will be a unified video API on Linux.
Word of caution though. I’ve found that on my machine (Linux/nvidia) unaccelerated video is way more power efficient. The second video is playing it kept the GPU in a high power state and that uses incrementally more power than the cpu doing software decoding
I had always assumed gpu would obviously be more efficient until I measured it
"All" really isn't true, most AM4 Ryzen chips don't have iGPU (unless they are specificly APUs), and a lot of Intel chips have popular 'F' SKUs without an iGPU.
The iGPU's video decoder could even be drastically less efficient than the dGPU's decoder, and it would still be better to use the iGPU, because just powering up the PCIe link and VRAM for the dGPU costs far more power than the video decoding itself.
Exactly, mpv logic causes it to pick up Nvidia for HW video even if renderer is on iGPU. There is special flag to choose device which solves the problem and Nvidia is kept down
What makes you think the unaccelerated path would use the accelerated iGPU path? Typically hardware decoding is disabled because of driver/reliability issues and thus would switch to software decoding to sidestep these concerns.
I assumed the OP/comment means "software vs. hardware accelerated rendering" when they say "it uses the CPU. And iGPU is still hardware accelerated rendering.
But some modern video codecs are designed to work quite okay with software rendering, especially if it's lower resolutions, and modern higher end dGPUs often have a pretty high "power overhead" on low utilization. To add to it the driver might keep it in a more high power state then strictly needed due to "expecting" more utilization, or similar.
Oh that’s interesting. I shall investigate thanks.
edit: very quick test with MPV seems to confirm this works - eliminates the gnarly additional GPU draw. Measuring draw at wall now puts CPU and GPU route on equal footing...both basically the machines idle draw. Tested both 264 and 265...same outcome. 3090.
If you really want to power optimize, there's a special dmabuf-wayland backend that hands off compositing to Wayland. You lose some post-processing but your power use can drop from 12-15w to 2-5w. This is also how the newer Linux video players attain really low power draws.
the story is kind of complicated, it's impossible to guess the culprit, you must profile. HDR content for example can sometimes incorrectly request a bespoke tonemapping instead of a video engine silicon one, like it does in libavcodec, or you have a privacy setting in your browser that breaks GPU compositing. so many little things can go wrong unfortunately.
through, from a pure power POV you probably would want to exclusively use the integrated graphics most CPUs have (1) with the external GPU powered down for most "daily/office-style" usage (browser, news, email, coding (not gamedev,etc.)) and only switch to external GPUs for Gaming, GPGPU, and I guess some edge cases like too many monitors or insisting on running a coding IDE at >240Hz ;)
EDIT, forgot the food note (1): Even the very very minimal GPU recent (non APU) AMD processors have are good enough for many peoples daily "office" needs.
No iGPU on my CPU (5800x3d). So was straight software decode (well maybe AVX2?) against GPU decode. GPU route was 80W more.
joebonrichie's comment was excellent though - there is a new nvidia tweak that eliminates the GPU going to a high power state the second it sniffs video. So now GPU & CPU get me the same draw.
>enough for many peoples daily "office" needs
Yeah been considering using my mac air for when not gaming / messing with LLMs, but frankly struggling with it on UX.
i am bit confused, what does it mean by vulkan video decoding? does it mean that it will be done via gpu or via hardware accelerator sepcific to decoder via some vulkan extension? if it is via extension gpu would be free to do gpu specific things?
Does this mean that AV1 on Youtube will finally not melt my CPU, while my nvidia GPU is asleep, or is this just an enabler that will require more work to build upon?
If the GPU is new enough to include a hardware AV1 decoder.
For NVIDIA, that means Ampere or newer (RTX 30xx or newer).
Turing or older (RTX 20xx or older) do not have support for AV1.
Vulkan has the advantage of providing a unified interface for video decoding.
Previously on Linux some programs were written to use only the Intel API or only the NVIDIA API. Fewer programs could use any of the 2 video APIs. (The AMD GPUs also supported the Intel API.)
With Vulkan, the same program should work with any GPU.
Vulkan has specific functions for different video codecs. To be able to use the hardware GPU support for AV1, the program that uses Vulkan for video decoding must also include support for AV1, i.e. it must invoke the corresponding Vulkan functions.
For now, it is not clear if Firefox already includes support for all codecs. In the initial version they could have included only partial Vulkan support, for instance only for H.264 video decoding, with the intention to add complete Vulkan support in some future version.
That's not the final release, that's an RC and tech blogs should stop reporting this as final. There were instances in the past where the RC had critical bugs.
Yeah but not the Phoronix one ("Firefox 153 Available", "Mozilla has uploaded the Firefox 153.0 release binaries today"). Shame because Phoronix was kinda good in the past.
How is the built-in website translation story in Firefox? To be honest, the only reason I'm forced to use Chrome is the way translate quite seamlessly works, both the detection (with mixed-language content in sites with English ads) and the actual translation.
I did try Bergamot but that was a year ago, and the experience was not as good as Chrome...
There are a couple built-in ways you can translate, all of them fully local. First is the full page translation and another that allows you to translate a selection (from the context menu.) Fully local nature, of course, reduces the translation capabilities, but I found the quality to be good enough to very rarely need an external service.
Really good. I use it frequently and haven't had any reason to switch to an external offering. It can translate the whole page or just a snippet that you highlight.
Support for in-place website translations has been introduced in FF 118, initially for a handful of western languages, now 50 languages. There is also support for translating highlighted text and user text with about:translations.
It's fully local, which means the translation might not be as good as what Google can do, but it's good enough to use, and in my experience it's usually faster, as there is no network latency (except for the first translation between a language pair, which takes a little while to download the weights).
Cool, have been using vulkan video decoding via mpv for a while now and it seems fine with little or no performance hits. Glad it's made its way here as getting hardware decoding to actually work in ff has felt like a house of cards (more options are welcome). Does something need to be done to enable/switch to it?
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.
> 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?
Blacklist of what? I don't understand what a blacklist would be used for in this context. Specific unsupported hardware?
Yes.
Well, supposedly. But in my experience, there was no consequence disabling the blacklist in order to enable hardware video encoding and decoding.
My 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.
There 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.
And in my experience, there was.
One person's lived experience is another person's “supposedly”.
Yeah, 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.
Interesting, 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.
I 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 :)
I'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 :)
Nvidia 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.
> 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.)
That 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.
I 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.
I have used Linux equally long, Nvidia on my last 3 or 4 systems. They all had problems with very sporadic hard crashes (full system freeze so hard magic sysrq keys don't work, and nothing is visible in the logs. Sometimes with audio looping.) It doesn't happen often, rare enough that I sometimes fooled myself into thinking I'd found and solved the issue. But then 4 months down the road, often with a driver update, suddenly they're back.
I have also seen extremely rare cases of Linux freezes exactly like you described, and I have wondered if there can be any relationship between them and the NVIDIA drivers, mainly because they are the only closed-source drivers that I use.
Nonetheless, I have not seen any evidence about such a relationship. The freezes never occurred while the computer works alone and some program uses the GPU. In all cases the freezes happened right after some quick mouse movement.
The culprit is definitely somewhere in the device drivers, and it cannot be excluded that this may have something to do with NVIDIA, because I do not remember if I have ever seen identical freezes with AMD or Intel GPUs, but that could be just because I have spent less time using directly such computers, instead of using them remotely through SSH.
In any case, this bug is something that requires interactions with the mouse driver, perhaps also with the keyboard driver, and the X server might also have some role.
In such cases, network and HDD/SSD activities appeared to continue normally, only the display was frozen and the keyboard and mouse did not respond. While the initiator could have been something done by the X server, something was stuck in the kernel, because not even the keys that should be intercepted by the kernel worked, as you have also said.
This is certainly a bug whose cause has not be discovered for many years, but it is not yet clear whether it really has anything to do with NVIDIA, since its main effects are upon keyboard and mouse.
>They all had problems with very sporadic hard crashes
I had such an issue recently, on a laptop with an Intel igpu and an Nvidia primus card.
I'm not a coward, so I debugged the system, and found that the crash was caused by the Intel i915 driver trying to do some tricky hdmi related mumbo jumbo with the hdmi port that wasn't even connected to the igpu, it was connected to the nvidia gpu.
When I contacted intel bugtracker, they just said "ah, Nvidia... well, even though their kernel module is open, it's not on the mainline kernel, so go fsck.ext2fs yourself".
The primary advantage of dedicated hardware accelerators for the past ~15 years been power efficiency, rather than performance. Not much of a problem on a desktop, but very noticeable on mobile devices.
8K decoding needs HW acceleration, unless having 8-16 cores with AVX-512.
Yes, but that's way out of budget for most consumers.
Actually not really, Lunar Lake chips with Xe2 graphics have VVC decoding in hardware which can do 8K.
https://en.wikipedia.org/wiki/Versatile_Video_Coding
They were likely saying that 8K displays are way out of budget for most consumers.
Where I live, we have 50 inch 8k TVs for 180 USD.
Do many people use Firefox on 50" 8K TVs as opposed to regular monitors? I wouldn't want such a large display on a computer unless the computer is being used as media server. And my experience when I got new monitors for work about 18 months ago, was that decent ones at higher than 1440p were more expensive than I felt was worth it.
Also, I expect one or more of the following from a 50" 8K TV at that price:
- Bundled with ad/spyware.
- Poor image and/or sound quality.
- Doesn’t last long, or image quality very noticeably degrades after a relatively short amount of use.
I also wonder if perhaps it’s still like back when HD was still new, where TVs would advertise “Full HD”, but were actually only referring to being able to accept a 1080p input signal which they would then downscale to their <720p LCD panels.
All of that is probably true, but playing YouTube on such a cheap TV is a very valid use-case for Firefox.
I could also imagine the decoded output being pluggable into Vulkan-based filters (mpv uses https://code.videolan.org/videolan/libplacebo) without slow device->host copying.
I understand this is important mainly for Nvidia GPUs. Is there any benefit at all for this (vs the existing VA-API) on Intel and AMD graphics? VA-API seems to work very well on both of these platforms, as far as I've tested.
VA API has some caveats and also requires one to disable sandboxing of the media process.
Sorry my comment was related to the nvidia vaapi driver
Considering Intel has vulkan video disabled in Mesa for recent chips, I’m guessing very little.
https://www.phoronix.com/news/Intel-Vulkan-Video-Disable-New
No, that is not true.
That link says that only the Vulkan video encode functions have been disabled, due to bugs.
Vulkan video decoding remains enabled also in the Intel GPU drivers.
It is important in the sense that many Linux programs did not bother to support both the Intel video API and the NVIDIA video API, so they work only with the Intel video API, which is also supported by AMD GPUs.
Programs that are converted to Vulkan should work with any GPUs.
VA-API works very well with the GPUs that support it, while the NVIDIA video API also works very well with the GPUs that support it, i.e. the NVIDIA GPUs.
The Vulkan video API has worked well for some time on NVIDIA, I switched my video player to it long ago.
Eventually the Vulkan video API should work well on all GPUs, so there will be a unified video API on Linux.
Interesting - will see if I can toy with it.
Word of caution though. I’ve found that on my machine (Linux/nvidia) unaccelerated video is way more power efficient. The second video is playing it kept the GPU in a high power state and that uses incrementally more power than the cpu doing software decoding
I had always assumed gpu would obviously be more efficient until I measured it
All modern CPUs come with an iGPU, so it's unlikely to be software decoding. Just iGPU driver's decoder being more efficient than dGPU one.
"All" really isn't true, most AM4 Ryzen chips don't have iGPU (unless they are specificly APUs), and a lot of Intel chips have popular 'F' SKUs without an iGPU.
The iGPU's video decoder could even be drastically less efficient than the dGPU's decoder, and it would still be better to use the iGPU, because just powering up the PCIe link and VRAM for the dGPU costs far more power than the video decoding itself.
Exactly, mpv logic causes it to pick up Nvidia for HW video even if renderer is on iGPU. There is special flag to choose device which solves the problem and Nvidia is kept down
What makes you think the unaccelerated path would use the accelerated iGPU path? Typically hardware decoding is disabled because of driver/reliability issues and thus would switch to software decoding to sidestep these concerns.
I assumed the OP/comment means "software vs. hardware accelerated rendering" when they say "it uses the CPU. And iGPU is still hardware accelerated rendering.
But some modern video codecs are designed to work quite okay with software rendering, especially if it's lower resolutions, and modern higher end dGPUs often have a pretty high "power overhead" on low utilization. To add to it the driver might keep it in a more high power state then strictly needed due to "expecting" more utilization, or similar.
Neither of the last two processors I've purchased in the last few years had any iGPU.
What were the models?
Two AMD's: A 6 core x, and an 8 core x3d.
Not all, most desktop have two options with or without igpu.
Are you using nvidia-vaapi-driver? If so, you'll need to set `CUDA_DISABLE_PERF_BOOST` in your environment.
Oh that’s interesting. I shall investigate thanks.
edit: very quick test with MPV seems to confirm this works - eliminates the gnarly additional GPU draw. Measuring draw at wall now puts CPU and GPU route on equal footing...both basically the machines idle draw. Tested both 264 and 265...same outcome. 3090.
Thanks!
Bonus discovery I just learned. Under nvtop -> F2 -> Processes -> Fields -> there you can make it show encode/decode. It's disabled by default
If you really want to power optimize, there's a special dmabuf-wayland backend that hands off compositing to Wayland. You lose some post-processing but your power use can drop from 12-15w to 2-5w. This is also how the newer Linux video players attain really low power draws.
I haven't been able to get Firefox GPU acceleration to work on Linux in forever.
Works out of the box for me on CachyOS, both amd and nvidia
the story is kind of complicated, it's impossible to guess the culprit, you must profile. HDR content for example can sometimes incorrectly request a bespoke tonemapping instead of a video engine silicon one, like it does in libavcodec, or you have a privacy setting in your browser that breaks GPU compositing. so many little things can go wrong unfortunately.
Interesting.
through, from a pure power POV you probably would want to exclusively use the integrated graphics most CPUs have (1) with the external GPU powered down for most "daily/office-style" usage (browser, news, email, coding (not gamedev,etc.)) and only switch to external GPUs for Gaming, GPGPU, and I guess some edge cases like too many monitors or insisting on running a coding IDE at >240Hz ;)
EDIT, forgot the food note (1): Even the very very minimal GPU recent (non APU) AMD processors have are good enough for many peoples daily "office" needs.
No iGPU on my CPU (5800x3d). So was straight software decode (well maybe AVX2?) against GPU decode. GPU route was 80W more.
joebonrichie's comment was excellent though - there is a new nvidia tweak that eliminates the GPU going to a high power state the second it sniffs video. So now GPU & CPU get me the same draw.
>enough for many peoples daily "office" needs
Yeah been considering using my mac air for when not gaming / messing with LLMs, but frankly struggling with it on UX.
i am bit confused, what does it mean by vulkan video decoding? does it mean that it will be done via gpu or via hardware accelerator sepcific to decoder via some vulkan extension? if it is via extension gpu would be free to do gpu specific things?
It's a Vulkan extension to use dedicated video decoders like QuickSync, NVDEC and VCN. It's not using shaders.
Does this mean that AV1 on Youtube will finally not melt my CPU, while my nvidia GPU is asleep, or is this just an enabler that will require more work to build upon?
If the GPU is new enough to include a hardware AV1 decoder.
For NVIDIA, that means Ampere or newer (RTX 30xx or newer).
Turing or older (RTX 20xx or older) do not have support for AV1.
Vulkan has the advantage of providing a unified interface for video decoding.
Previously on Linux some programs were written to use only the Intel API or only the NVIDIA API. Fewer programs could use any of the 2 video APIs. (The AMD GPUs also supported the Intel API.)
With Vulkan, the same program should work with any GPU.
Vulkan has specific functions for different video codecs. To be able to use the hardware GPU support for AV1, the program that uses Vulkan for video decoding must also include support for AV1, i.e. it must invoke the corresponding Vulkan functions.
For now, it is not clear if Firefox already includes support for all codecs. In the initial version they could have included only partial Vulkan support, for instance only for H.264 video decoding, with the intention to add complete Vulkan support in some future version.
Hopefully this will be supported on Intel Arc cards that have hardware encoding and decoding.
Previously: https://www.phoronix.com/news/Firefox-Vulkan-Video-Merged (https://news.ycombinator.com/item?id=48439348)
Note that Firefox 153 Stable and ESR are not released until tomorrow (Tuesday July 21). Mozilla generally uploads them to the servers the day before.
Related:
Firefox 153.0 Beta
https://news.ycombinator.com/item?id=48979110
Was there a link to the project on Github? I think that you've mistakenly shared Github's search tool/path
https://www.phoronix.com/news/Firefox-153-Downloads
That's not the final release, that's an RC and tech blogs should stop reporting this as final. There were instances in the past where the RC had critical bugs.
An RC justifies the "merges" title (compare "releases")
Yeah but not the Phoronix one ("Firefox 153 Available", "Mozilla has uploaded the Firefox 153.0 release binaries today"). Shame because Phoronix was kinda good in the past.
Here's the Bugzilla link which was closed last month: https://bugzilla.mozilla.org/show_bug.cgi?id=2021722
Yup, it's pointing to https://github.com/search
I expect it's the https://github.com/search?q=repo%3Amozilla-firefox%2Ffirefox... link that phoronix used in lieu of linking to an actual github issue.
How is the built-in website translation story in Firefox? To be honest, the only reason I'm forced to use Chrome is the way translate quite seamlessly works, both the detection (with mixed-language content in sites with English ads) and the actual translation.
I did try Bergamot but that was a year ago, and the experience was not as good as Chrome...
There are a couple built-in ways you can translate, all of them fully local. First is the full page translation and another that allows you to translate a selection (from the context menu.) Fully local nature, of course, reduces the translation capabilities, but I found the quality to be good enough to very rarely need an external service.
Really good. I use it frequently and haven't had any reason to switch to an external offering. It can translate the whole page or just a snippet that you highlight.
Support for in-place website translations has been introduced in FF 118, initially for a handful of western languages, now 50 languages. There is also support for translating highlighted text and user text with about:translations.
It's fully local, which means the translation might not be as good as what Google can do, but it's good enough to use, and in my experience it's usually faster, as there is no network latency (except for the first translation between a language pair, which takes a little while to download the weights).
>How is the built-in website translation story in Firefox?
It's broken.
The button is there and is clickable, and there even is an animation near the address bar, but it doesn't actually do anything.