[Libre-soc-bugs] [Bug 251] Initial 3D MESA non-accelerated software-only driver is needed

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=251

--- Comment #29 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #28)
assembly.
> 
> There are other reasons not to go with an AMDVLK fork, such as Mesa being
> well known to accept contributions, being friendly to Libre-software, having
> a good community, generally being developed in the open (transparency), and
> being installed on most Linux distros in the default install.

what we do not want is to end up in a situation where LibreSOC is the sole
exclusive location where libraries are found, and we really, *really* do not
wish to hard fork and become the sole maintainer of massive codebases such as
LLVM, AMDVLK, MESA and so on.

attempting such *will* run into difficulties with distros because nobody will
accept a replacement package from an arbitrary source other than the distro
itself.

even if we tried that the problems it causes for users are immense.  examples
are the deb-multimedia archive which provides "alternative" versions of debian
packages.

the archive is maintained by only one person who does not have sufficient
resources to keep fully up-to-date recompiling packages at the same rate and
with the same options as the entire debian team of a thousand people.

if we are not "upstream" we create the exact same problem due to being a hard
fork of critical low level software.

not only that: any security issues and security patches in the hard forked
software become *our problem to drop everything and provide*.

the patching process to try to keep uptodate will consume all resources leaving
no time for actual maintenance and development.

consequently, leveraging upstream is critically important.


> AMDVLK, by contrast, has effectively zero contribution other than AMD
> employees, is developed in a closed manner (they publish new code every once
> in a while, but the actual development process is mostly private), and it is
> unknown if they will accept a port to a non-AMD GPU upstream (I'm guessing
> not).

similarly, we decided not to go with SwiftShader because google is the only
controlling contributor.

we would therefore become the de-facto exclusive maintainer of a hard fork of
AMDVLK which is too much of a burden and as explained above has detrimental
ramifications.

leveraging the collaboration inherent in MESA is in many ways far more
important than whether the code is, in its initial release, optimally
performing or even feature complete.

-- 
You are receiving this mail because:
You are on the CC list for the bug.