Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Rich Freeman]

On Sun, Dec 18, 2016 at 3:23 AM, Daniel Campbell <zlg@g.o> wrote:
>
> Thankfully the kernel seems to have sane management; as long as Linus is
> around, anyway. Just recently AMD had some of their code rejected, so
> with a vigilant-enough team, you can effectively protect your project
> from monied interests (be it poor code or an attempt to manipulate). Now
> picture what might have happened if AMD was employing Linus or had some
> other sort of contract. (For the record, I use an AMD CPU and like it;
> they just happened to be the most recent corporation who's rejected code
> popped on my radar. No bias intended.)
>

I think this is an oversimplification of the issues involved in the
AMD situation, which as with so many of these things people just
jumped on picking sides.  And I think what has gotten lost is an issue
that actually comes up somewhat often in FOSS.

Let's step back and look at the reality in the gaming on Linux domain:
there are basically two GPU manufacturers in the game (AMD/NVidia),
and neither one has their best GPU drivers in the mainline kernel.
Both of them contribute to drivers which ARE merged into the kernel,
but in both cases these lack features found in the out-of-mainline
module.

AMD has been attempting to merge their better driver into the mainline
kernel.  As far as I'm aware (I could be wrong) Nvidia hasn't really
tried to do this for the most part and are content to just keep
shipping a blob.  AMD's reasons are certainly at least somewhat
selfish, as maintaining all that code out-of-tree is expensive since
linux doesn't have a stable API for drivers.

Ok, AMD wants to add a more capable driver to the kernel, and
obviously Linux users would prefer a more capable driver in the
kernel, so what is the problem?

And this is where we come to an issue that happens from time to time
in FOSS: the needs of the kernel maintainers are not aligned with the
needs of the AMD driver maintainers.

The AMD and NVidia out-of-mainline drivers both use an abstraction
layer to map the kernel APIs to an internal set of APIs used by the
driver, because their drivers are multi-platform.  I'm not sure
exactly how their internal APIs work in both cases.  They might
internally target the Windows APIs, or they might even target a
virtual API and use a translation layer on every platform.  This
allows them to use one set of code for their core logic across all
platforms, at the cost of overhead on Linux (and possibly on other
platforms as well).  On most platforms this is no big deal because the
APIs on those platforms are stable.  On Linux this is not the case,
and the maintainers prefer to have the freedom to modify their
internal APIs and not maintain their own translation layers for
backwards compatibility.

IMO both sides are basically "right" in their designs, because they
have different priorities.

The AMD driver code isn't "poor code" - it just isn't natively written
for Linux and so it has a lot of code that is theoretically
unnecessary (in a world where all devices run Linux).  And that is of
course more code for the Linux maintainers to deal with if they accept
the driver into mainline.  On the other hand, writing a driver that
purely targets Linux means having to change the core part of the
driver anytime the Linux APIs change, which then means changing the
translation layers on every OTHER platform out there, when those
platforms otherwise feature stable APIs, or having a 3-layer solution
(Linux to single virtual API to various stable platform APIs).

Now, if the Linux maintainers wanted to have a stable API but wanted
to refactor their code internally, then you could actually have a
multiple-layer situation as well.  You could have Linux internal APIs
to Linux stable API to AMD virtual API translation going on (which I
suspect is what happens on Windows).  As far as I'm aware Microsoft
doesn't care if vendors use translation layers, because they don't
touch those modules other than testing them (which they get paid to do
anyway).

Both sides of this debate can legitimately cite maintainability as a
reason to not give in.  The Linux guys don't to have to maintain a
de-facto stable API (which is what the translation layer turns into).
The AMD (and NVidia) guys don't want to write a different driver on
every platform.  Keep in mind that besides Windows and Linux, they may
have multiple test harnesses that they need to map into their drivers,
and probably other OSes as well.  There is also a huge benefit to
having the same bug list on every platform for the most part.  And
Linux users benefit when the "Optimized for <AAA title here>" work
done for Windows automatically hits Linux as well, which gives the
publisher more incentive to spend the extra few bucks to release a
Linux version of the game.

So, saying that this is about moneyed interests trying to somehow
corrupt the "purity" of FOSS isn't really right here.  Ultimately
issues like this become a bit of a tragedy for all.  And mind you, I'm
not trying to say that the Linux maintainers should ignore their own
interests and just merge the code.  If one side was right and the
other was wrong it wouldn't be the problem that it is.

And stuff like this is what leads to this thread.  Did the Firefox
maintainers HAVE to require Pulseaudio?  Of course not.  Are they
going to be bothered to not require it for the sake of the 0.1% of
Linux users who want to use a web browser but don't have Pulseaudio
running?  Probably not.  The universe of Linux systems that are
running Firefox but not Pulseaudio is fairly small at this point.
From their standpoint requiring it costs them nothing and makes their
life a tiny bit easier.

I'd love to live in a world where all the code that everybody wants
exists for free and any subset of it is interoperable with any other
subset of it.  However, that just isn't going to happen because all
the necessary translation layers needed to make that happen are a pain
to maintain.  And so in a sense the same reasons that drove the Linux
maintainers to reject the AMD code are the same sorts of reasons that
are going to drive the Firefox maintainers to reject any patches that
let their software work without Pulseaudio, which brings us full
circle...  :)

-- 
Rich