Hacker News Reader

Comment by bigbaguette | Hacker News Reader

Give it a couple years before Valve starts sponsoring someone to reverse-engineer it

I do not understand why vendors believe their software stack is a moat. It is an obstacle to me.

opens wikipedia (Emphasis mine:)

> Moats were excavated around castles and other fortifications as part of the defensive system as an obstacle immediately outside the walls.

Unfortunate wording?

Moats are supposed to be obstacles for your competitors, not your consumers.

It's akin to building a moat inside the castle.

That's called a Lazy River.

Moats are obstacles against something you're trying to avoid. It can be competitors coming in, or customers going out. A moat could surround a prison to keep prisoners in. Some companies just choose to treat their customers as prisoners.

The usual metaphor for keeping customers is a walled garden, right? I think it's useful to distinguish them by default.

Because most game developers aren't religious about APIs, they implement an abstraction layer in their engine, a practice since the heterogeneous 8 and 16 bit days, where all major games were mostly coded in Assembly, and move on.

Any conference talk schedule at one of these conferences (https://gameconfguide.com) will prove the point of how little they care.

It is all about gameplay, taking advantage of gaming IP, franchaises, how to squeeze the ultimate performance out of specific hardware, user engagement,....

You will find an occasional talk about open APIs, probably even done by some Khronos folks, and that's it.

If they open-sourced their userland drivers, and/or released their internal technical documentation, which would have a similar effect, they would open themselves to at least two big problems.

First, they would spill all of their secret sauce for others to "draw inspiration" from. And there is a lot of expensive secret sauce in there. Not all of it is protected by parents either; more on that below.

Second, they would make it a lot easier for competitors and patent trolls alike to seek litigation. One of the criteria thech companies have for filing a patent is how easy is it to detect when it is being violated. Open source your stuff, and you make it much easier for the competition to detect any violation.

And it is not like these companies are violating patents intentionally; much the opposite. But there are only so many ways to implement Vulkan or DirectX, and completely independent teams will come up with similar enough solutions, and with broad enough patents, that there will be overlap every now and then. That is why they file patents in the first place. Only the high cost of litigation and the risk of mutually-assured destruction keeps legitimate vendors from rattling sabers more often.

Then you have NVidia with their immense investment and advantage on the software side, from the CUDA runtime to countless libraries like CUBLAS and cuDNN. That investment goes much beyond a relatively simple Vulkan/DirectX driver.

So the question is less "why don't more of them open-source userland". The question is "why do any of them do it"?

Source: former insider with enough patents under my belt that I lost count.

Do you have any thoughts on the question you posed? Amdgpu and mesa is working out fairly well for amd, but yes, there is also still a proprietary userland for it too. Intel I think is using mesa code for their Windows drivers too. How are they different?

I genuinely don't know. They are smart people, they know the game. They must have figured out that there is an upside for them.

Just speculating here. Maybe they have big customers that communicated to them that they will choose them over the competition if they open more of their software stack. Maybe they are less afraid of being sued because they are the underdog and they believe that the authorities would not be kind to a behemoth suing them, or they believe that the behemoth would not sue them because of the bad press it would generate vs the settlement they would get.

I actually don't know. But I am sure they have good reasons, just like the corps that keep it closed also have good reasons. It is not "good" vs "evil".

Thank you for your input - it genuinely is very interesting.

>Maybe they have big customers that communicated to them that they will choose them over the competition if they open more of their software stack.

I do remember reading that that is the case for AMD, maybe one of their open source devs said it in an interview?

They've also been doing it for a long time now and the risks didn't seem to materialize, which surely helps with all the fears that you mentioned.

> If they open-sourced their userland drivers, and/or released their internal technical documentation, which would have a similar effect, they would open themselves to at least two big problems.

> First, they would spill all of their secret sauce for others to "draw inspiration" from. And there is a lot of expensive secret sauce in there. Not all of it is protected by patents either

Then why does Apple allow Asahi to reverse-engineer their low-level APIs? Are their lawyers not paying attention?

Relevant reply here:

https://news.ycombinator.com/item?id=49610136

Why?

I thought these GPU were open source with mainline kernel support?

All the mainline kernel support is reverse-engineered. No help from Arm.

Thus there is a considerable lag for the support of newer Mali generations.

Some Linux distributions for various embedded computers with Arm-based CPUs and GPUs use closed-source GPU drivers from Arm, not the reverse-engineered Linux drivers, when the Mali versions are newer than supported by the kernel and Mesa.

The Arm GPUs do not have public technical documentation, not even at the level of NVIDIA, much less something comparable with AMD and Intel.

>All the mainline kernel support is reverse-engineered. No help from Arm.

That's not true. Arm has been supporting the open source driver effort for the last couple years, but it's still behind the closed source one in terms of performance, features, and HW support.

I liked it better when electronic components which didn't have very thorough detailed documentation were instantly recognizable as completely unsuitable for a production BOM. :\

I think you are confusing Apple and Arm.

Mali drivers are contributed by Arm:

https://github.com/torvalds/linux/blob/master/MAINTAINERS

Most Mali drivers from the kernel are not contributed by Arm, but you are right that nowadays some contributors from Arm have appeared for the older reverse-engineered GPU drivers, like Panfrost and Panthor, and now there are also a few GPU-related drivers, like HDLCD and MALI-DP, which have indeed been contributed by Arm.

Besides the Mali generations that are supported in the mainline kernel, there are many other Mali generations for which Arm has not provided anything else except closed-source drivers for Android, in a few cases also closed-source drivers for Linux. However, there are many other reverse-engineered Mali drivers, besides those from the mainline kernel.

It is good that Arm has begun to contribute to the kernel DRM drivers, but these drivers do little else except providing the means to communicate with the GPUs. The complex work is done in the user-space GPU drivers from Mesa.

The Mesa Lima driver, for older generations of Mali, does not have any contribution from Arm.

In the past, Mesa Panfrost was also completely reverse-engineered. Seeing that now Arm has begun to contribute to the kernel Panfrost DRM, I do not know whether they have started to contribute also to the Mesa Panfrost.

In any case, while some contributions to the previously reverse-engineered drivers are much better than nothing, what would have been much better is to publish the technical documentation of the Mali GPUs, in which case it would not have mattered whether Arm contributes something or not, as anyone could have written the drivers.

Reply on news.ycombinator.com