Chromium blacklists Nouveau
lists.freedesktop.org
lists.freedesktop.org
The current link says it as if Chrome was not being fair, but reading their reasoning it makes total sense. Key quote from said bug report:
> We thought about blacklisting nouveau driver long time ago, and decided to let more adventurous users to play around. Now that Ubuntu ships with nouveau on default, maybe it's time to blacklist it in Chrome.
> We received quite some bug reports on other rendering issues with Nouveau, and this bug is just one of them. So we will disable all GPU acceleration by default. If someone wants to bypass that, there are two options: 1) install proprietary NVidia drivers (see #24) 2) run Chrome with --ignore-gpu-blacklist, but be aware you are taking a risk here
> Unfortunately we don't have the resources to test every variation of every GPU/driver combination on linux, let alone investigate & fix bugs in drivers. We want a stable & secure browser first, a GPU-accelerated one second, only if possible.
> The default driver on Ubuntu LTS has severe issues, asking non-technical users to update their driver is just not acceptable as a prerequisite to use Chrome.
> If someone is interested in well-scoping the brokenness (version range and/or devices affected), we're happy to take a patch to the blacklist.
So the driver fails in some (common enough) cases, they let it run anyway but now it's default on ubuntu so a lot of non tech users are/will be affected, so they block it but you can still bypass the block if you want. And if newer version fix it and someone can help them figure out which versions work for what, they are willing to limit the blocking.
I don't get this. All linux distros under the sun ship with nouveau, and always have. It is a kernel driver afterall. What else are they going to ship ?
Otherwise, when using it in KVM VM, it can run the desktop compositor quite nicely.
Then are Nouveau users only losing performance and not functionality as a result of this Google decision?
The NVIDIA driver is the driver that yields the best performance and experience; AFAICT the only reason it's not shipped by default is because the kernel is then considered "impure" or something (because source isn't available to debug issues in the NVIDIA driver), hence bugs can't be filed upstream for any issues in the kernel if the NVIDIA driver is installed.
However, none of this is really the concern of the Chrome team. Their responsibility is to give the user the best experience, which they have defined as security, stability, and performance in that order. Since the nouveau driver is causing stability bugs, it's perfectly reasonable for them to fallback to software rendering and take the performance hit in order to preserve stability.
The term is "tainted".
Including Nvidia's binary driver by default. Obvs Debian, gNewSense, and GUIX can't do that, but since when have corps cared about them?
Like, don't get me wrong, I'm a FOSS or GTFO kind of guy, running Debian and Replicant, but shipping proprietary drivers by default is what chrome is hinting at obviously.
Chances are, that you are using modesetting X driver anyway (i.e. the KMS driver, the same driver/backed, that is used by Wayland).
AFAIK it works with Gnome's Wayland Implementation, but not with the one from KDE.
The combining of proprietary and GPL code has to be made by the user and the result is un-distributable. That's why distributions cannot ship it.
What they can do is to make the above step easy (which Ubuntu does).
And second, to answer your question, partly because Linux is sufficiently good and has wide enough hardware support that it's still easier to use Linux legally under the GPL than to use another operating system, and partly because if you're going to use another operating system with narrower hardware support you might as well use a tinier embedded one and ship cheaper hardware (which is what Linksys/Cisco did with the WRT54G, shipping VxWorks and less RAM, and then selling the more-Linux-capable WRT54GL as a higher-end product).
AFAIU, Nvidia's legal argument is that their driver can't be 'derived from' the Linux kernel even though it's linked into the kernel since it's older than their Linux port and only is linked against their GPLed (and if push comes to shove, dual licensed GPL and proprietary) kernel abstraction layer. Judges don't care about linkers and the GPL doesn't actually say anything about linking.
This is about GPL infrigment; you can combine GPL licensed code with differently licensed code, but only in your privacy, without distributing the result to others. Once you would distribute the result, you would be breaking GPL, thus having no right to distribute.
> The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.
The argument that I've is that even when linked together, the Nvidia binary driver isn't a 'derivative under copyright law' because it doesn't have Linux specific entry points, and is older than their Linux port, and therefore isn't part of "The 'Program'" as listed in the GPL.
Your argument is, why some piece of software should (or should not) be relicensed to GPL.
My argument is, that since that piece of software is currently not GPL licensed; avoids the relicensing topics and explores how to solve the current situation wrt distribution of the combined work. Use by the end-user is non-issue, due to freedom 0.
That's not the point. The point is that it results in brokenness, and the easiest way to mitigate that for the bulk of non-technical users is to use software rendering instead (i.e. blacklist it). They're open to more refined solutions, but these will take some effort.
The composition is GPU accelerated too. Chrome has it enabled by default, Firefox doesn't.
In the end, both browsers treat Linux as a second-class citizen. To make things even more weird, ChromeOS uses the same API (VA-API) and the same driver (for Intel GPUs) for video decoding acceleration that the stock Linux does, and the video decoding is supported on ChromeOS but not on Linux... And Firefox is just plain mess.
So Google doesn't have the resources to test the default driver on the most widespread linux distribution for one of the two most widespread GPU producers in the market.
It's not as simple as "one of the two most widespread GPU producers in the market".
Chrome team, on the other hand, does not have the resources. Which is to say that this is not the thing they believe is most important to work on at the margin, and given the amount of engineers Google will fund for the project.
they are also saying their that driver may work fine on some less common linux configurations, and the chrome team does not have the resources to test those.
you are literally saying they are saying the opposite of what they said, then blaming them for it.
And the test suite failed on a minor issue where the cause was uncertain, which gets in the way of checking for the bigger definitely-the-driver problem.
The common distribution was blacklisted not because it was not tested, but because it clearly has issues observed and reported by the users.
If a driver does not work in popular configs, and needs to be blacklisted in those configs, your solution is to still whitelist it in other configs and have the browser likely not work.
yes, "every company" does exactly what google did. you are being purposely dense, trying to catch a "technically correct" chance of not admitting the stupidity of your question. The problem is, you are not even technically correct - just purposely dense.
If Nvidia wants their cards to work well on an all-free-software stack, they can provide a free software driver. If users care about making an unofficial driver work, they can do the work or fund the work. Chrome is just trying to get web pages on the screen and it doesn't seem like it's worth the boil-the-ocean level of effort of taking responsibility for implementing a reverse-engineered graphics driver when they can just get web pages on the screen using software rendering.
Something doesn't add up to me there, and no one that I saw ever addressed that in more detail.
That's still less than a percent of the market I think. Maybe shave off another order of magnitude. So the economic argument is not the one to make. However, it sucks nonetheless.
Honestly, you could fill up the number of people using nouveau with chromium in a stadium more likely. From the small pie of linux users, you drill down to nvidia, and then further down to nouveau. All laptop users, even with nvidia cards, will only use the intel gpu unless they explicitly enable the discrete mode and not install the nvidia drivers. Desktop users obviously only buy nvidia if they want to use the binary driver. What do you think remains of the pie ? I haven't met a single person in real life who uses this stack. I love nouveau. That doesn't change the numbers though.
To save those users from themselves, Google now disabled GPU accelleration for all Ubuntu users.
Seems like a bit silly to me.
And in any case the reason nouveau sucks (and yes, folks, nouveau sucks) isn't Google's fault to begin with.
You seriously want to complain about Google's lack of support for an open source driver that barely exists because of NVIDIA's lack of support?
It's crazy to suggest they should give web access (not just webgl, but CSS styling) to a buggy GPU driver by default without an opt in by the user.
(Not bring cynical, I genuinely don't know.)
From reading more about it, it seems these are all benign (in the sense of Chromium couldn't ship h264 because it's licensed but Chrome can).
This just about sums up the problem with open source. The response is always "if you don't like it, fix it yourself". Because everybody is a developer with copious free time to learn how to fix the problem in their favorite product. It's not like cloning and building Chromium takes hours. Or like you would lose anything by using Chromium instead of Chrome.
It takes copious free time to learn how to run chromium with an --ignore-gpu-blacklist argument? What kind of strawman are you trying here?
Look. The open source NVIDIA driver is terrible, and Google doesn't want it messing up the experience of the people using its product. Who are you to demand that Google fix someone else's terrible driver (which is terrible through no fault of Google's -- NVIDIA would prefer it not exist at all)?
If you really cared about this at all, you'd be upset with NVIDIA. But you're not. You apparently don't even like open source software, which presumably means you're using the binary drivers and unaffected, right?
But that's the point. The response always works because it's proportional to the problem. For problems that are legitimately small and you could fix yourself, or pay someone to do it for an amount of money that a normal person could feasibly pay, it's a valid way to solve the problem.
And for problems bigger than that, it invites the user to consider what they're really asking for and who they're asking for it. Actually fixing nVidia's dumpster fire would be a huge ordeal for anyone other than nVidia. Asking a third party to do it without documentation... let's just say there is a reason nouveau is in the state that it's in, and it's not a general lack of interest in fixing it.
So in that case "go fix it yourself" means "if you think it's so easy then let's see you do it."
The driver is hopeless? Fine.
You don't want to spend money on people that will most probably install an ad blocker? Go ahead.
You don't have the resources? Come on.
> The default driver on the distribution we support is broken.
They do test the default driver on the distributions they support. The tests show that the driver is unacceptably unstable. It may work better on other distros/versions, but they don't have time to test those. They're happy for others to help out in testing these unsupported combinations, however:
> Again, if someone wants to spend the time to test thoroughly to narrow down the blacklist, we will accept patches.
I solved the Chrome/Chromium on Linux problem long ago by switching to Firefox. I'll still fire up Chromium for Google sites and a handful of other sites, but for the most part Firefox has been getting it done for me.
It's an Ubuntu/Nvidia problem, not a Google problem. AMD and Intel open source drivers work just fine.
> Please remove the blacklist as all Nouveau users expect this corrupted behaviour. If at all possible it may be worthwhile to let users know it doesn’t have to be this bad if they flip to the binary driver. Perhaps a pop up letting them know?
1) Nouveau is buggy and problematic (related more to performance and a lack of support for many features)
2) The Nvidia drivers are buggy and problematic (related more to setup and compatibility with the rest of the system)
Both of these problems can be traced back to the same root cause, which is simply that Nvidia refuses to do a good job of supporting Linux in any way. They could give Nouveau some funding and information about their hardware, but they don't do that. They could develop proper Linux drivers, but they don't do that either. Every way you look at it Nvidia is at the root of the problem.
The solution on the consumer side is to not buy Nvidia products, and to encourage other people to not buy Nvidia products. The solution on the producer side is to contribute to Nouveau (easier said than done unfortunately, your average web dev can't just jump in and reverse engineer graphics drivers on a weekend).
I really dislike the way Nvidia makes it difficult for projects like Nouveau to reverse engineer an open driver, however I don't understand what you mean by poor support for their Linux driver, it's probably the one thing I can't fault them for as it is performing very well and stable.
I'm with you on not buying NVidia products though, that is the best way to send a message.
All my experience has been on laptops and there are lots of reports of Optimus related problems on Linux so there's that. I gave up on the hope of having Optimus actually work years ago. I would like to just be able to enable the latest version of Nvidia's driver and see my laptop start using the discrete gpu. That would be a big step forward from the past 7 years.
FWIW there's Linus' famous Nvidia F-bomb :) "Nvidia has been the single worst company we ever dealt with" https://www.youtube.com/watch?v=IVpOyKCNZYw
There's a reason Microsoft shimmed the ability for the display driver to crash and restart without taking out the rest of Windows...
Aren't scientific farm servers running on Linux kernel with Nvidia cards ? It would not be used if it was that buggy, so I think that claim needs precision
Reproducibility in computational science is recognized as a huge problem: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3383002/
A lab or institution claiming a publishable result based on discounted hardware from the manufacturer running code that does who knows what for their TensorFlow/whatever calculations is engaged in something other than science. I wouldn't go quite so far as to say that they're just engaged in advertising demonstrations, but it's coming close.
Reproducibility doesn't necessarily mean every component of the system is completely open and inspectable.
I wonder what percentage of "Machine Learning" results are based on such shaky foundations and when they'll receive the same amount of skepticism and scorn we see heaped(deservedly) on the field of psychology.
That doesn't follow. They can (attempt to) reproduce with the same hardware, firmware, and drivers. They can reproduce with similar hardware from another vendor (AMD). If you're using OpenCL, you can reproduce on CPUs, albeit much slower and probably only for partial results. Maybe you want to break out some pen and paper to verify a few calculations of the CPU for even more partial results because you don't trust Intel's firmware blobs, even though you've presumably cross checked against AMD hardware, but you've gotten quite silly at that point.
Maybe some of these changes won't give you bitwise identical results - but then again, neither does most science. You check if the broad results and patterns are statistically similar. Maybe they are, and the results survive a large variety of similar but different test setups. Maybe they don't, and you discover an uncontrolled variable, like the exact chemical composition of the surface of your glass beakers being contaminated by impurities, or your AI being sensitive to the exact floating point rounding behavior of your GPU.
If anything, you want to see if your results survive variations in the uncontrolled variables, to make sure you've properly determined what factors are controlling the results.
If you cannot reproduce then you do not know whether it is due to the equipment/materiel varying or not and you have severely reduced options for investigating that.
If you look at the problems with even reproducing and testing the bugs that the specific situation under discussion exposes it is illustrative of the difficulties involved with working with a non-modifiable, unexaminable platform.
In your example, the researchers would be forbidden by IP laws from examining and testing the surface of the beakers for contaminants and publishing a description which allowed other researchers to make similar modifications.
It's the most sub-optimal situation in which to obtain something which starts to approximate reality. Not impossible, just difficult, and likely to lead to shenanigans.
Anyways, it would be good if NVidia and Ubuntu got together and at least made it easier to make use of the official driver.
I'm facing this problem and it's very annoying. I have to run Chrome with --disable-gpu-driver-bug-workarounds, which ironically makes it work perfectly---with the "driver bug workarounds", it's terribly broken. But now, any Electron app I run (e.g. VSCode, Postman, Discord, etc.) is also broken by default and needs the flag as well. Frustrating.
---
I've glanced at the HN discussion about this situation [...] and it does seem like people are focusing on the wrong thing... the important bit isn't that nouveau crashes and burns in some situations—everyone already knew that, including the users of nouveau who continue to use it nonetheless. It's that if every piece of software feels free to ignore a system integrator's or user's wishes, then the user now has to know how to override that behaviour separately in every application. The situation is that Distro X has decided that nouveau is the right thing for its users. A user can disable that by uninstalling or otherwise disabling nouveau if they wish. But now chrome comes along with its own set of rules. What if every application starts doing that?
It should also be noted that outside of a few pathological cases, like creating 2GB+ textures which never happens in practice, nouveau works just fine for me. For other people, it dies at random intervals, irrespective of whether they're using chrome or not. While this is a non-ideal scenario, chrome shouldn't be in the business of worrying about things like that. It just confuses the situation for everyone.
Yes, they do and they have very good reasons for it. Working with distros to ensure they ship the right libraries takes an infinite amount of effort so companies that what to ship a product to their users will work around it.
This also happens in the server space with the massive popularity of containers and language-specific package managers.
The traditional Linux Distro model is extremely flawed.
Things are getting far better for OSS you drivers. If you wanted any 3d acceleration in the past your only choice was the proprietary Nvidia driver or a broken proprietary ATI driver. (The ATI windows drivers were pretty buggy too during this period).
Back then the proprietary Nvidia driver kept much better Pace with their windows offering. Last I checked their proprietary Linux driver was almost a year behind (point release wise) the windows offering.
My next GPU will be an AMD GPU, as soon as my GTX 960 stops being sufficient (and no Wayland is certainly an issue).
Am I reading this right? Nvidia's drivers were never out of sync for a year with regard to the supported GPUs, OpenGL and Vulkan features. It's easy to see that looking at the Vulkan beta drivers page at https://developer.nvidia.com/vulkan-driver. (That's just a convenient example, non-beta drivers follow the same cadence but there no single page I can link.)
Back when I got that 7870 circa 2012 I was taking a major risk - at the time the 6870 was the premiere foss card and radeonSI was brand new with growing pains. The 290 was another risk being the first major architecture update to GCN. But I was validated in both purchases with usable cards at first that within a few months became excellent.
I've played a lot of the major Linux AAA releases on these cards shortly after release - Borderlands 2, Civ 5, Metro Last Light / Redux, Tomb Raider, etc. There used to be quite a few bugs at release and glitches. Nowadays everything is pristine. And I get about twice the framerate in BL2 today than I did four years ago on that 290.
I'm almost certainly going to buy a Navi card next unless we have another crypto bomb ruin the market again.
Don't set your expectations too high. Their next generation of consumer graphics cards, rumored to be announced at CES next week, are reportedly still going to be based on a new revision of their current GCN architecture (which originally debuted in 2011 and is very much showing its age these days). Rumored performance for the "high-end" model will be somewhere around the GTX 1080 or RTX 2070 (though reportedly at a much lower price compared to either of those cards).
If you're waiting for them to produce an all-new GPU architecture the rumors are that they are working on one to be launched in the 2020-2021 timeframe. That's also when Intel is rumored to be preparing to launch their own dedicated GPUs so hopefully we will be going from 0 properly high-end GPUs with open-source drivers to 2 by 2021.
It’s by far the best Linux GPU I’ve ever encountered, and that’s with open source drivers don’t set the kernel taint bit.
Its performance in benchmarks was much better than the comparably priced NVIDIA. It is also the quietest gamer GPU I’ve encountered (I bought one with slightly nicer fans).
Maybe things have changed (but the 1080 was certainly out back then), but this card wins on every metric other than CUDA support (nonexistent) and absolute performance (close enough to fastest, and certainly overkill for my Linux Steam collection at 4K).
Assuming you can't tell the difference between, say, 100fps and 150fps, isn't the 'performance bar' a bit arbitrary after a certain point if the hardware runs the vast majority of the software thrown at it?
AMD's GPU market share has been shrinking with the general gaming audience despite the fact that their mid-range cards have been very price-competitive with Nvidia's offerings during the same time period they've lacked serious competition at the high-end. While focusing on the mid-range where the highest volume of GPUs are sold is the rational market strategy it may not be a winning market strategy in the real world.
Aren't those still adequate to run like, 99.9% of all games on the market? I would (and do) gladly pay for hardware that isn't the absolute fastest if the manufacturer employs a Linux driver team to make that hardware work on Linux.
And in my experience, the NVIDIA driver landscape is just a mess. The state of Nouveau can be obtained from the article above and the proprietary driver causes all kinds of weird issues (e.g. UI spinners rotating at different speeds, fans turning faster than they are supposed to be, etc.). On the other hand, the (open source) AMD driver seems to have evolved quite well over the last years.
As a result, I hate my NVIDIA card and like my AMD card quite much. Every time I see those steam survey results I wonder why there are still so many people buying NVIDIA cards for their Linux boxes. They probably just trust the benchmarks and don't compare the experience first hand.
Needless to say I have an AMD card, with awesome open source drivers, sitting in a bin. While the horrid binary-blob Nvidia actually drives my display.
Most likely you aren’t using Display Port 1.2 MST, which is what the Dell UP3214Q requires for 60hz 4K.
My testing was with vanilla Ubuntu 18.04.
That is simply not true.
Various docs, provided based on requests by Nouveau developers: https://download.nvidia.com/open-gpu-doc/
Documentation released in the last year include e.g. https://download.nvidia.com/open-gpu-doc/MemoryTweakTable/1/... https://download.nvidia.com/open-gpu-doc/MemoryClockTable/1/... https://download.nvidia.com/open-gpu-doc/BIOS-Information-Ta...
The announcement of the first piece of documentation in 2013: https://www.mail-archive.com/nouveau@lists.freedesktop.org/m...
Commits with @nvidia.com addresses (including Reviewed-By tags etc.) to nouveau driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
You can also regularly see posts by NVIDIA employees on the nouveau mailing list.
Sure, they are contributing nowhere near as much as AMD or Intel, but to say they are not interacting at all or not providing any docs or not helping at all is clearly false.
You get 3x better performance with a GTX 780 Ti than a GTX 980 Ti. From reading the explanation from a Nouveau developer in the comments, I get the impression that NVIDIA just wants the open source drivers to work well enough that you can boot your computer and download the proprietary drivers.
This post from a Nouveau developer a year ago provides a summary, which I think is probably still accurate: https://www.phoronix.com/forums/forum/linux-graphics-x-org-d...
First, nvidia for not providing OSS drivers and second, the user who runs an OS on hardware that can't be properly supported on this OS at the moment.
For years I have the rule that I prefer hardware that has proper Linux support. Even going a bit further that I try not to buy hardware that doesn't have OSS drivers unless there really is no other option (nowadays, that means mostly smartphones).
It's worse than this. Nvidia does not merely not provide open source drivers, they actively preclude work on Nouveau.
Phoronix link: https://www.phoronix.com/scan.php?page=news_item&px=Nouveau-...
* Separated firmware that needed for basic and fully functional driver and given Nouveau only bits they wanted.
* Obfuscated and hidden firmware files within the driver binaries so they harder to extract.
* Changed loading process so GPU read it via DMA to make reverse engineering of firmware loading harder.
It's pretty clear that all of that was exclusively done to harm Nouveau.
I have a strong opinion on this as I was involved a few years ago in the Kindle homebrew community. After a while I decided that my time could be used better than on a product by a company that tries to prevent us from making his product better and more interesting to its users.
There is so much energy and time wasted when you have to fight against the manufacturing company and in the case of a graphics card, the result is that it just works as well as the other graphics card option that is fully supported OOTB. And then that's just for a piece of hardware that you can replace on average for a few hundred bucks.
Is that really worth the hassle?
I tell everyone I know not to buy Nvidia, I have built gaming computers both professionally and for family that I've actively advised against buying Nvidia parts for because of their business practices, and when I buy notebooks its a real PITA to get one without some Nvidia GPU in it but I do that too.
But Linux cannot "throw out" support for Nvidia. Nvidias driver is wholly independent of Linux, its why its such a PITA to work with. Its a DKMS blob driver and way too much other useful stuff depends on that interface to break it just to stop Nvidia. Fortunately nobody is going out of their way to support Nvidia either, such as their stupid attempt to fragment Wayland development with eglstreams nonsense.
The most valuable thing any of us can do is constantly decry Nvidia for being the reprehensible company they are and use what influence we have over those we know to distance them from buying their products the same way you should distance friends and family from buying Nestle or Exxon products or should avoid shopping at Walmart.
* Even decade ago they did a lot of shady stuff when they initially separated GeForce and Quadro series. There was time when you can make little hardware mod on Geforce product that make driver think you have Quadro and magically a FP64 become twice faster and CAD application performance was doubled and tripled.
* Their OpenGL implementation was ever non-standard and allowed both code and shaders to work in situation where it's clearly should not. As result games and apps that was debugged on Nvidia hardware would never work on more conformant Intel / AMD drivers.
* In terms of Nouveau back in 2014 Nvidia started to require signed firmware files [0]. They promised shortly after to provide Nouveau with the files with clear licensing, but it took years. When files were finally released everything related to power management was missing and still not released until this day. So Nouveau can't implement recloking. On top of that they intentionally obfuscate the way firmware files stored within driver binary and also make GPU load firmware via DMA to make extraction much harder.
* Sabotaging of OpenCL in general by not implementing spec for years and keeping it generally much slower that it's supposed to be.
* Several years ago Nvidia twice added checks to their Windows drivers to stop consumer GPU drivers to work when passed into virtual machines. Both bypassed by hiding KVM identifier and changing HyperV hv_vendor_id, but it's was annoying [1].
* Nvidia forbidden to use consumer hardware drivers in datacenters [2]
* Nvidia tried to push some crazy anti competitive program to make exclusive deals with GPU vendors so they can't sell AMD GPUs in any kind of "gaming" product lines [3]
Again it's not like AMD is perfect, but that's a lot of shady stuff and I likely not even listed half of it.
[0] https://hardware.slashdot.org/story/14/09/27/1254219/nvidia-...
[1] http://vfio.blogspot.com/2014/08/vfiovga-faq.html
Do you think that overclocking a CPU clock is "magic", too? You were just running the hardware out of spec! Yes, FP64 and CAD were a lot faster, whatever; are you going to trust these faster-reached results to be always correct? Or that the card isn't going to break down in the midst of some important workload? The whole point of labeling something "Quadro" is to say "these cards are good for that sort of critical stuff - they've been extensively tested for reliability".
This was at its worse in the late 1970s, but it seems the practice hasn't entirely stopped even today
And the usual reliance on Palm Tree Oil, as another example
If the noveau developers had true hacker spirit, they would move nouveau development into the darknet.
nVidia does provide perfectly working closed source drivers on Linux though - how is it their fault that some 3rd party implementation of the drivers doesn't work in a stable manner?
I didn't say that Nvidia is at fault for the state of the nouveau driver. I said they are at fault for not providing OSS drivers. Nvidia doesn't want to play by the rules of Linux development but they still want to be on Linux. That's legally possible but why should the user or distro manager give Nvidia a pass here when other companies play by the rules?
Think about it. Which components would you be willing to download drivers for if they weren't OSS? Your monitor? Your sound card? Your harddisk? Your network card (oops)? Your mouse or keyboard?
Some Linux distributions that do not hamper themselves artificially on philosophical grounds offer nvidia binary drivers in their package repositories like they do with every other driver they contain. Your focus on the kernel sources is too narrow.
There absolutely was a time when you had to download all these drivers you mention separately - for Windows. And people put up with it. I think even today the Windows installer is forced to offer an option to install 3rd party RAID controller drivers into the installation environment...
You can't compare Linux and Windows when it comes to drivers, they have different methods of providing those drivers.
- both are viable desktop operating systems
- nVidia successfully and consistently releases high quality video drivers for both
So to me it seems to work just fine.
Here is a very good post from one of the key Nouveau developers, about why you should do exactly that:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-d...
What's an AMF extension?
AMF == Advanced Media Framework.
AMF doesn't seem to have a Linux version to begin with, so not sure what you were testing exactly: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/4
This also illustrates why it's important to have alternatives to Chrome for anybody who cares about open source.
It could be working on FF only through a quirk in their rendering, rather than a testing. Chrome certainly has a test suite -- did anyone run it with nouveau and turn bugs into PRs? And arguably, that job belongs to the desktop owners, as well as the nouveau and chromium teams. Browsers are insanely complicated, and who is paying for this work?
If I could make my employer pay for a meaningful number of Ubuntu desktop licences I would, but TBH I need it to work with the nVidia driver not nouveau.
> I did run the WebGL CTS suite, but that resulted in some
> hangs from the the max-texture-size-equivalent test, and some
> browser-level weirdness after some tests where later tests all fail
> (due to what I have to assume is a browser bug).
Isn't it more likely that they are noveau bugs, and are part of the problem here?
I reported this bug back in 2015 and they have made no progress on it. It seems Nouveau just doesn't have the resources or man power. I can't really blame Google here. You don't want the browser to be able to hard lock system(not even a Magic SysRq will reboot it)
Wait, this isn't just rendering bugs a la "some WebGL things will show green instead of red", it kills your system entirely?
I thought the only effect this blacklisting had was making WebGL unavailable for everyone instead of buggy for a small minority. This just flipped my opinion.
Related, this might also explain the strange bluescreen bug my girlfriend had with Windows 8 + Firefox on her laptop. She switched to Google Chrome a few years ago because every time she used Firefox, her laptop would bluescreen within a few hours (either while Firefox was still running, or at some point later). I didn't know bugs outside of the OS could still do that kind of thing (I thought they started squashing such bugs with Windows 95 and finished somewhere around Vista) and wrote the Firefox thing off as triggering some extremely obscure Windows OS-level issue. Maybe I should check if there is a driver blacklisted by Chrome, though it seems more likely Chrome just doesn't happen to trigger it (like all other software running on it, it really is only Firefox).
Also, Chrome can render WebGL on the CPU. It's slower but will still work.
The bug for enabling hardware rendering by default on some systems appears to still be open: https://bugzilla.mozilla.org/show_bug.cgi?id=594876
Just set these in your $HOME/.profile
export MOZ_WEBRENDER=1
export MOZ_ACCELERATED=1Edit - will that work for the snap version BTW?
(I work on WebRender for Firefox)
WebRender is more raw indeed, but regular layers acceleration should surely be re-evaluated instead sweeping blacklisting like it happens now.
What? Don't do this - never do this. Regardless of whether or not you agree with Chromium's decision, it is their decision to make as the project maintainers; trying to trick the software with falsified data is overstepping your bounds, and both corrodes trust in your driver and leads to whitelists.
I thought we had moved past the days of fake user-agents.
The application decided by default not to offer support for it.
Who should absolutely not decide for the user is the unsupported driver itself so I think the hierarchy is just fine as it is.
The more rational behavior is for chromium to let the operative system decide what software and drivers they want to use, and do what they want with bugs from operative systems that they don't want to support.
Whitelists won't work since all that will happen then is that project will do what Internet explorer did, ie call it self "compatible" and use the GL_VENDOR string of that compatible driver.
Chromium isn't loading their own graphics drivers. They are deciding to fall back to software rendering if they determine that the card/driver/OS combination does not properly support the API that enables them to use the hardware-acceleration features of the card to render. They're still rendering using the noveau driver on the OS, they're just not using the APIs that they have determined to be not functioning properly. Detecting what the underlying graphics hardware and driver supports and falling back to what is functional is an incredibly common part of software using GPUs.
If you want to use hardware acceleration then go to about://flags and search for blacklist
"Override software rendering list: Overrides the built-in software rendering list and enables GPU-acceleration on unsupported system configurations. – Mac, Windows, Linux, Chrome OS, Android"
Simple and if you have telemetry logging on then you are possibly advertising that nouveau works for you.
Fwiw, I agree with this statement only because Chrome lets users override the default behavior.
In the hypothetical event that Chrome was closed-source and forcibly disabling acceleration under a driver, I'd consider fakery on the part of the driver to be perfectly warranted.
I don't understand the dramatics. Nouveau is great but being blacklisted on Chromium is not the biggest issue for it right now imo. A lot of Linux users (myself included) use Firefox anyways, and it's still a default in many operating systems. And you can of course override this. I would place lack of reclocking support much higher than this in terms of issues. And of course, the bugs that caused Chromium to decide to blacklist Nouveau in the first place are still going to affect other accelerated applications.
I'm a big fan of Nouveau, it is what I use on my laptop when in Linux. At the very least, it performs more than adequate for running a compositing desktop environment, and for many common configurations I've had few issues booting things up, the few issues I have had generally solved by using a newer kernel.
If we really want Nouveau to succeed though, the support needs to start coming from Nvidia. AMD and Intel both have in the past supported open source drivers to an extent and it really shows. Nvidia's contributions have been pretty piss poor, and unfortunately it seems they just don't care, which is sad.
I guess I do understand the frustration, but given the fact that this is in response to Ubuntu shipping Nouveau as a default, I think Nouveau's death is a bit overstated.
It _still_ doesn’t work with Pascal cards, which are 3 years old now. Not to mention newer Turing cards. It’s only good for some obsolete hardware more than two generations ago. The first thing I have to do before installing fresh Ubuntu or Fedora is looking up how to blacklist nouveau, as the system won’t even boot otherwise.
It’s time to deprecate it for good everywhere.
Nouveau and amdgpu were always barely working, just enough to get something on the screen — no state of the art 3D acceleration, no CUDA/OpenCL. But there is a big difference between “barely working” and “black screen on boot, always”.
Noveau has been almost close to usable at some point... Until Nvidia started the whole signed firmware nonsence. Then it quickly became intolerable due to Nvidia, supplying no signed firmware or heavily crippled firmware. These days you are actually better off using software renderer/llvmpipe (which at least might benefit from a powerful processor). "amdgpu" is a name of the modern AMD kernel driver, that replaced "radeon" driver. Both drivers were developed with direct help from ATI/AMD. Unlike it's older predecessor, current amdgpu versions include the "display core" code, that was designed to be shared between Linux and Windows AMD drivers (not sure, if that part has worked out yet). All Linux drivers for currently produced AMD cards are open-source, both kernel and userspace parts. AMD also has a "value-adding" package, that is based on their own userspace driver (which is open-source) and simply adds few closed-source components to it.
"amdgpu" is not barely working — AFAIK, it is the only currently available AMD kernel driver, and it worked great for me, both 2D and 3D.
AMD 0 - Nvidia 3
Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Out-of-process Rasterization: Disabled
Hardware Protected Video Decode: Hardware accelerated
Rasterization: Software only. Hardware acceleration disabled
Skia Deferred Display List: Disabled
Skia Renderer: Disabled
Surface Control: Disabled
Surface Synchronization: Enabled
Video Decode: Hardware accelerated
Viz Service Display Compositor: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated[1]: https://wiki.archlinux.org/index.php/Chromium#Hardware_video...
EDIT: Wait, there's an open source thing? Is Bumblebee any good? Optimus is such a pain in my ass that it's making me want to smash this laptop.
Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Out-of-process Rasterization: Disabled
Hardware Protected Video Decode: Hardware accelerated
Rasterization: Hardware accelerated
Skia Deferred Display List: Disabled
Skia Renderer: Disabled
Surface Control: Disabled
Surface Synchronization: Enabled
Video Decode: Hardware accelerated
Viz Service Display Compositor: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA controller])
And chrome://gpu says Video Decode: Unavailable
And it points to this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=137247
Arch has a PKGBUILD in the repo: https://aur.archlinux.org/packages/chromium-vaapi/ and I think there are builds for most popular distros out there nowadays.
If you are on Arch or one of its family you can get a -bin version in the AUR or use ArchlinuxCN that builds it in their repo.
They work on ChromeOS the same way they do on desktop Linux and I've been using them for months without issue.
You can get hardware video on Intel and AMD.
As a Linux user for over 15 years, this is one of the main reasons I am replacing Linux on my next machine, probably with Windows (sigh). Maybe it's just me getting old, but I'm done screwing around with computers to get them to do what they are supposed to do. It's frustrating and embarrassing.
It's not just that some drivers or hardware have obvious problems. It's virtually impossible to get a system where all of the components have vendor-supported open-source drivers, or, when they exist, that a distro supports them out of the box. Many components' drivers only officially support two operating systems. If they don't support your operating system (Linux), then when you have a problem, you're SOL. It's like buying a car that when the transmission blows, you need to hire a mechanical engineer to reverse-engineer it. Better start taking the bus to work, because this could take a while.
Some laptops (about 9 product lines from 3 vendors) make official Linux distro releases available. So you're stuck with a small selection of machines and basically only one distro. Even if that is ok with you, the drivers still won't all be vendor-supported open-source. And on top of that, Linux may have wacky, constantly changing ways of handling the hardware, like hybrid GPU support, or low power mode for Intel wifi chips. Your machine will always be an awkward stepchild.
A limited hardware selection isn't good. Laptops are hard to design. There are always design and procurement tradeoffs, and the less tradeoffs they make, the more expensive it gets. So to get a good experience on a good machine, you need to buy the most expensive one. At that point you might as well buy a Mac.
Finally, there's actual user experience. I've used several distros and environments the past few years, and they all had pitiful user experiences on my laptops. CPU scaling on battery/AC doesn't work out of the box, most of my media keys don't work, hybrid GPU takes a computer science degree to get working properly (with the right combination of drivers and software), echoing the wrong value to a /sys/ entry that had no kernel documentation permanently fixed the cpu fan at top speed, and the latest vanilla kernels with an old kernel config simply won't boot.
I know this isn't everyone's experience, but the only reason I'd recommend a Linux desktop is if they were looking for a complicated new hobby.
Not sure if this was just a typo and you meant "laptop", but I imagine most of the problems you're describing could be avoided on a self-built desktop, because you can choose all the hardware for compatibility.
I haven't used Linux seriously in years, but this is how I'm able to make Hackintosh work without constant fiddling, which all logic dictates should be more difficult than Linux.
Not wanting to play fanboy but I was a huge fan of Windows 10 throughout the prerelease and for a good while after release, but it seems to be going downhill in recent updates. It seems like now would be the absolute worst time to switch back.
I hope that this puts pressure on both Nvidia and Ubuntu to have a better default.
I also suspect, that they make use of multiple patented technologies, both in hardware and software. When Java has been re-licensed to GPL, one of the most prominent pain points, that caused endless whining on part of OpenJDK users, happened to be it's font renderer. And we all know, that font smoothing is tricky business, and all font-smoothing tech in existence is patended by MS/Apple/Adobe. When you start replacing closed-source code with free replacement, those patented pieces tend to quickly come up — especially when open-source projects go to great length to work around patent issues instead of shoving them under the carpet.
Did you read the bug report?
There is an arguably superior driver supplied by Nvidia. It is faster, has better hardware support, and is arguably more stable (1). However, it ships as a closed source binary blob with a source-based shim layer to integrate it into the kernel.
(1)My wife has 2 Linux desktops with Nvidia GPUS. She ran nouveau by default. However, on both machines, it would cause a kernel oops, and lock the screen up. My wife assumed it was her entire machine locking up, but I realized from the stack traces that were recorded that it was the GPU driver. I then switched the machines to the Nvidia driver, and they have been stable ever since.
I personally always buy hardware from Nvidia, because they provide a binary driver for FreeBSD. They are one of the few companies in the non-server space to provide good packaged drivers for FreeBSD.
Thank you! I think you might have just solved an issue for me that happens intermittently with my linux mint 18.3. At least we'll see once i dive into output of stack traces, etc.
AMD's performance is competitive dollar-for-dollar, and the top of their lineup is about 80% as good the absolute highest-tier competitor most of the time.
On a more serious note what is the motivation for Nouveau? The drivers provided by Nvidia are not good enough or we just need an opensource alternative?
Further, its not open source the nvidia drivers. Although, I dont understand why anyone would buy hardware from nividia and feel good about it
2. People like to run fully open source systems
3. Adding support for things like kms and wayland are really up to the whims of nVidia as to when it happens with the closed driver, while an open driver is more likely to do so (or at least can be forked to do so). In the past features like config-less X were also much later coming to nvidia drivers which made it harder for people to get started on Linux.
Point #3 is also really good. Who wants to wait around at the mercy of a corporation which has an active interest in NOT being transparent about "its" IP (as speculated elsewhere most of the GPUs probably infringe on some or other patent)?
Anyone buying an nvidia card for Linux should know exactly what they are doing: funding an anti-Free Software company, deeply entrenched in the ethos of secrecy, patents and bullshit; saddling themselves with a white elephant which will suck hours of their precious time.
Yup. By adding a Nvidia card (or, far less commonly, an ATI/AMD one) they can sell that laptop as a specialty "Gaming" machine - and with margins on commodity hardware being so razor-thin these days, that's exactly what shrewd marketers need!
The Nouveau driver was so bad here that I blacklisted all the drivers and just use the Intel GPU. It's the difference between 3 hours or 6 hours of battery.
It apparently ran the Nvidia power on even when no program wanted to use it.
Are you sure you didn't install nvidia drivers? That is a common symptom with nvidia binary drivers. Nouveau on the other hand is fine with powering the device off when not used. For nvidia drivers, the bbswitch method is more reliable, but is apparently deprecated by distros these days.
I'd always seen terrible power efficiency on battery with Fedora. It was much worse than any previous Thinkpad. I mostly treat it like a luggable, always plugged into the wall. I wasn't sure if it was the CPU or chipset, but it never got into deeper package-level idle states like other machines.
However, I recently discovered that if I suspend and resume the laptop right after I switch from AC to battery power, the laptop runs in a much more efficient mode. It gets into those deeper idle states and can get almost 6 hours of life out of its aging batteries for basic office/communication tasks with wifi. If I don't suspend it once, it will only get close to 2.5 hours even if almost completely idle the whole time.
Managing and multiplexing access to hardware is a core responsibility of the kernel. When video drivers are implemented in user space as X11 has traditionally done there are a bunch of issues: the program that includes them has to be setuid root to have the right access to the hardware, opening up the possibility of security bugs; only one such program can run at a time; and if something goes wrong in user space, it can bring down the system.
The newer kernel subsystem responsible for handling video cards is the Direct Rendering Manager, with the unfortunately confusing acronym DRM. [1] nVidia declined to support DRM in its proprietary driver for quite some time but eventually chose to do so.
They have some quibbles with GBM, one of the parts of the kernel API, but they didn't raise them until after the API was implemented in the kernel, was implemented in the AMD and Intel drivers, and had become a dependency for the Wayland reference compositor Weston. They refused to implement GBM and instead implemented their own alternative, EGLStreams, which is far more complicated. The open source world believes this is the wrong architecture and has had a lot of discussion about how to (reluctantly) support it. The current KDE and Gnome approach seems to be to accept patches from nVidia for EGLStreams support [2][3], but not everyone feels the same way. [4]
nVidia has implemented DRM already. They could implement GBM if they wanted to. I'm sure that having their proprietary driver in kernel space instead of user space makes licensing more complicated, but it hasn't stopped them yet.
[1] https://en.wikipedia.org/wiki/Direct_Rendering_Manager
[2] https://blog.martin-graesslin.com/blog/2017/10/plasmawayland...
[3] https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-K...
I believe this is because Firefox assumes it's the responsibility of the compositor you are running to properly vsync, but if you're not running a compositor you can turn on this option.
Also, as mentionned in the bug thread, if nouveau is actually stable on Newer versions, similar to User Agents, the newer nouveau versions could change their name to bypass the blacklisting. No need to pretend to be NVIDIA, just something different that nouveau, like 'nuevo' or something.
From: Drew DeVault <sir@cmpwn.com>
To: graphics-dev@chromium.org
Subject: nouveau blacklisted in Chromium
I'm writing to complain regarding the decision to blacklist nouveau in
Chromium. You're creating a hostile relationship with one of the most
important projects on Linux. If you do anything about this problem, you
should be using your influence to pressure Nvidia into being a better
citizen on Linux. Hell, you could even sponsor the nouveau developers
for a fraction of a fraction of a fraction of a percent of Google's
budget. Instead of doing any of the right things, you chose to become a
bad actor on Linux.
Closing bug reports from nouveau users and directing them to the
freedesktop bug tracker? Fine, you don't need to fix someone else's
bugs. Blacklisting the driver? Not even remotely okay.
I strongly condemn your decision and I expect it to be rolled back as
soon as possible.
--
Drew DeVaultI'm curious why you hold this position. I think it makes sense for the browser to attempt to deliver the best experience it can to users, and they may believe they get better performance and behavior from unaccelerated rendering. It's no different from websites looking at user-agent strings to work around known bugs, right? It's okay for a user to override their user-agent string, and fine for browsers to mention other browsers for compatibility, but uncool for a browser to not identify itself at all and steal another browser's user-agent string.
The OpenGL API includes vendor strings for a reason. Chrome isn't doing `strings` on the library or anything.
>I think it makes sense for the browser to attempt to deliver the best experience it can to users, and they may believe they get better performance and behavior from unaccelerated rendering.
So should they also blacklist Windows because it's spying on its users? No, of course not. They should do their best to deliver a good experience in the domains for which they are responsible.
>It's no different from websites looking at user-agent strings to work around known bugs
This is also a very dumb anti-practice.
If a Windows graphics acceleration component spied on its users, Chromium should absolutely blacklist that component, and use software rendering instead.
That's such silly rhetoric, no wonder you're in the situation you're in.
> This is also a very dumb anti-practice.
So is crashing users machines and then blaming Chrome for doing what's best for its users.
No. Its more like blocking the access to your website to some browsers.
At best they should give a warning that youre using an unsupported browser/driver so beware if unexpected issues.
>I'm curious why you hold this position.
Agreed. There are countless AAA titles (games) that do vendor checks on the GPU. Game developers are a bunch of people who have been working with GPUs for more than a decade, possibly approaching two decades. For some reason, GPUs are the one thing that the OS HAL isn't able to sort out. Windows (and Mac?) drivers are always proprietary, so different hardware vendors are all Windows developers have to worry about. I can't imagine the headache of dealing with differing hardware vendors (and families), on top of differing driver vendors.
Reality fucking sucks and I guess this is just Chromium acknowledging it. I doubt there's a grand conspiracy here.
The language you use is unnecessary. (Don't mean this in the blanket sense -- calling a SOB a SOB is fine -- but in this particular case.)
The Chrome team was receiving bug reports due to driver issues, and now this driver is the default. They can either compromise the experience for some Ubuntu users (with crashes, not slowdowns) or blacklist the driver or fix the driver.
If you don't mind the possibility of your driver crashing, you are free to instruct chrome to ignore the blacklist, something I personally did for some time.
Imagine if Google had blocked Tor users in China in favor of Project Dragonfly instead. The attitude of Chromium in this matter is directly supporting bad actors who actively do harm to their users and to the rest of the world around them. That's why they're sons of bitches.
And they do just that, quite often! Just take a look at the list of drivers/hardware/os/feature combinations that are blacklisted in their file at [1].
Tons of MacOS and Windows things on there (and Android, and Linux!)
[1] https://chromium.googlesource.com/chromium/src/+/5e87d14bfc6...
It's not? Isn't Chromium their code?
Also, with this email it seems it is you who is turning a routine technical decision into a hostile relationship. As they say, them fighting words.
Yeah, I don't get that. Does the author think that this'll make the Chromium project more willing to sponsor work on nouveau, or for that matter, to expend some of their influence on nouveau's behalf via Nvidia? It makes no sense to me.
This page disagrees:
https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drive...
My unmodified Firefox stable channel on Linux has WebGL enabled OOTB and my distro does not have any specific flags specified for WebGL (or GL in general) in the package.
> GL layers acceleration is not yet enabled by default (see bug 594876). You can enable it by setting layers.acceleration.force-enabled=true in about:config.
That means off by default. Also maybe relevant is that I'm on the Firefox Graphics team so I have some knowledge of this.
If you want to verify, download a stock Firefox build from Mozilla, run it on a new profile, and check what it says for Compositing in the Graphics section. OpenGL means acceleration, Basic means software.
By making Chrome significantly slower on nvidia systems they effectively are pressurizing nvida to act better. Trying to work around the problems would be more like supporting the status quo instead of driving change.
Chrome has the capability of adding all kinds of qualifiers to the blacklist, including explicit exceptions to the rules for a ton of things as well.
If enough people can show that some subset of Nouveau users are stable it can be safely enabled for them.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=876523
If you want to support nouveau, then you can put the work in. You have no right to demand that others do work for you. Especially when they already have a functioning alternative solution in software rendering.
Sure you are:
>If they find the nouveau driver lacking, they should improve it, not sabatoge it.
Not supporting a buggy driver is hardly "sabotaging it". It's not their job to make it work.
>If they don't want to put the work in, then they should just leave well enough alone.
And in doing so, their least-technical Linux users will suffer from sudden crashes that they don't understand. Now how does that help Linux?
>If they don't want to put the work in, then they should just leave well enough alone.
nouveau doesn't crash, but some cards may experience occasional glitches. That's something you need to take up with Ubuntu, not Chromium.
>The Nvidia driver does not "work" in my project. I have added no code which explicitly blacklists it, and the day Nvidia releases a driver which implements the required APIs it will work with no changes in my code.
No, it's not. If you encounter a bug in a piece of software, you should report it to the maintainers of that software. That's true even for, say, bugs found in the Nvidia proprietary driver. Expecting Chromium to fix it is expecting them to do more work, which is the exact thing others have railed on me for "expecting" from them (which I haven't, to be clear once again).
I mean, sure. But that's not really the whole of it here. Chromium has encountered multiple bugs in a piece of software, and they decided they don't want to expend the resources to reproduce those bugs and deal with them. In the meantime, those bugs mean that the driver is not properly implementing the functionality for all users, and so Chromium has decided to simply not use that part of the driver. They aren't doing anything to the OS, they aren't bypassing the OS, they're just rendering on the CPU because the driver doesn't properly implement the hardware acceleration features. There is no obligation whatsoever to use software that you know doesn't work just because the OS ships it.
[0]: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
How about the day when Nvidia releases a buggy (system-crashing?) implementation of the required APIs? How well will your code work without changes, and which course of action will you take?
Chromium chooses to prioritize users' experience over scoring ideological points. That means attempting to work around known external bugs instead of letting things blow up and sending users to pound sand on some unresponsive third-party mailing list.
I'm not sure how you can fault them for that, especially since pretty much all successful large-scale projects take the same approach -- including the Linux kernel.
Unless you are paying my salary, any emails sent to me with "I expect..." go straight into the trash.