The Significant Corporate Importance & Pressure Around Mesa Open-Source Linux 3D Drivers

It has taken many years but the Mesa 3D open-source graphics drivers have proven very successful from the open-source AMD Vulkan and OpenGL drivers proving they can be capable of competing with the closed-source drivers not only for gaming but also workstation tasks, the Windows vs. Linux graphics driver performance gap largely closed, Microsoft even leveraging Mesa for their translations to the D3D12 API, vendors like Imagination developing once unthinkable open-source drivers, etc. But with the increasing importance to corporations, so has the responsibilities and concerns of Mesa driver developers.

Mesa has evolved from often reverse-engineered, community-developed 3D driver solutions to most major hardware vendors employing driver developers to work directly on the Mesa code. It's been phenomenal to watch over the past two decades with Phoronix but with that maturity of Mesa so has come the concerns of the developers involved.

The most recent example is a now-merged merge request to revert an earlier change bumping the Zlib dependency for Mesa. The basis for that revert is that it breaks SPECViewPerf.

Due to Mesa dynamically linking Zlib and how SPECViewPerf is handled, the update happens to break SPECViewPerf that is a popular benchmark for workstation graphics and one commonly used by hardware vendors and other stakeholders. Ultimately it's an issue with how SPECViewPerf is setup as an application bug but it could also be argued that Mesa could statically link it or better handle its dependencies. In any event, it's a regression for Mesa and breaks SPECViewPerf. And SPECViewPerf is important to vendors.

So the immediate solution that's now been merged is to revert that Zlib update commit. But ultimately doesn't solve the issue at hand. In any event some notable messages were raised by well known AMD Mesa developer Marek Olšák:

"I don't know [about being able to update Zlib or other solutions]. This is the only workaround that works with how the linking works now. If Viewperf doesn't work, our executives will start recommending closed source for any serious use case. You can propose a better workaround."

And some further comments by the veteran Mesa developer:

"You would need to patch Viewperf on all machines where it's installed right now."

"We can permanently remove the zlib dependency or vendor it, but requiring the latest zlib with a dynamic linker breaks compatibility with apps."

"RE: Why is this not a Viewperf bug instead?

It works with other drivers. That's the internal and public perception Mesa will get. It's our job to make sure apps work with Mesa, not the other way around. Always has been."

Some comments have suggested statically linking Zlib moving forward or perhaps switching to Zstd or alternatives instead. Marek then summed it up best as:

"I don't think some people understand what's going on here. They think it's a technical issue. It's not. It's a political and strategic issue for the Mesa community. If you prevent something from working that the industry finds important, you risk destroying real jobs in this community and shrinking it, regressing Mesa's reputation, making it more inferior in the industry, and thus less important. What this revert does is that it preserves existing jobs (i.e. existing stuff keeps working) and opens the door for creating new jobs and growing this community in a sustainable manner by showing others what it can do. You need capital and business interests to grow the community, and to get that, Mesa must be the best because it's always competing with alternatives.

If you thought this is only about dependencies, well, you're mistaken, and if you want to hurt the future of Mesa because your stupid zlib dependency is more important than anything else, including the livelihood of other people, you're just a foolish bikeshedder."

I fully agree with all of Marek's comments in this merge request. This update was a regression in Mesa for an industry-standard benchmark (SPECViewPerf) that is particularly important for workstation customers, etc. Expecting SPEC to suddenly adjust SPECViewPerf or similar is unlikely and failure to fix this would have been poorly reflected on the open-source Mesa OpenGL drivers... Hell the AMD Mesa drivers with SPECViewPerf are extremely competitive to the proprietary AMD alternatives or the NVIDIA competition on consumer cards. Yes, a better solution needs to be devised for dealing with Mesa's dependencies long-term, but this revert was rightfully needed all things considered.

Just imagine the screams if this wasn't a SPECViewPerf issue but rather a similar change breaking Steam support... Gamers would be protesting, Valve would be rightfully upset and surely having their developers working on an immediate revert, and would have further potential reverberations if it wasn't immediately addressed. Mesa these days has a significant corporate presence from the developers involved and increased customer demand more than ever, but ultimately it's a good thing for the benefit of the ecosystem. Just imagine how much further Mesa would be behind without the significant contributions over the years by Intel, AMD, VMware (Tungsten), Valve, etc.