Either licensing issues (maybe they don't own all parts of the closed source shader compiler) or fears that Nvidia/Intel could find out things about the hardware that AMD wants to keep secret (the fears being Unfounded doesn't make the possibility of them being a reason any less likely). Or alternatively they considered it not worth releasing it (legal review isn't free) because the LLVM back-end was supposed to replace it anyway.

▲

AnthonyMouse 5 days ago | parent | next [-]

> or fears that Nvidia/Intel could find out things about the hardware that AMD wants to keep secret (the fears being Unfounded doesn't make the possibility of them being a reason any less likely)

When the fears are unfounded the reason isn't "Nvidia/Intel could find out things about the hardware", it's "incompetence rooted in believing something that isn't true". Which is an entirely different thing because in one case they would have a proper dilemma and in the other they would need only extricate their cranium from their rectum.

▲

mschuster91 5 days ago | parent [-]

> When the fears are unfounded the reason isn't "Nvidia/Intel could find out things about the hardware"

Good luck trying to explain that to Legal. The problem at the core with everything FOSS is the patent and patent licensing minefield. Hardware patents are already risky enough to get torched by some "submarine patent" troll, the US adds software patents to that mix. And even if you think you got all the licenses you need, it might be the case that the licensing terms ban you from developing FOSS drivers/software implementing the patent, or that you got a situation like the HDMI2/HDCP situation where the DRM <insert derogatory term here> insist on keeping their shit secret, or you got regulatory requirements on RF emissions.

And unless you got backing from someone very high up the chain, Corporate Legal will default to denying your request for FOSS work if there is even a slight chance it might pose a legal risk for the company.

	▲	AnthonyMouse 5 days ago \| parent \| next [-]
		> Hardware patents are already risky enough to get torched by some "submarine patent" troll, the US adds software patents to that mix. Software patents are indeed a scourge, but not publishing source code doesn't get you out of it. Patent trolls file overly broad patents or submarine patents on things they get included into standards so that everyone is infringing their patent because the patent covers the abstract shape of every solution to that problem rather than any specific one, or covers the specific one required by the standard. They can still prove that using binary software because your device is still observably doing the thing covered by the patent. Meanwhile arguing that this makes it harder for them to figure out that you're infringing their patent actually cuts the other way, because if plaintiffs are clever they're going to use that exact reasoning to argue for willful infringement -- that concealing the source code is evidence that you know you're infringing and trying to hide it. > And even if you think you got all the licenses you need, it might be the case that the licensing terms ban you from developing FOSS drivers/software implementing the patent, or that you got a situation like the HDMI2/HDCP situation where the DRM <insert derogatory term here> insist on keeping their shit secret, or you got regulatory requirements on RF emissions. To my knowledge there is no actual requirement that you not publish the source code for radio devices, only some language about not giving the user the option to exceed regulatory limits. But if that can be done through software then it could also be done by patching the binary or using a binary meant for another region, so it's not clear how publishing the code would change that one way or the other. More relevantly, it's pretty uncommon for a GPU to have a radio transceiver in it anyway, isn't it? On top of that, this would only be relevant to begin with for firmware and not drivers. And the recommended way of implementing DRM is to not, but supposing that you're going to do it anyway, that would only apply to the DRM code and not all the rest of it. A GPU is basically a separate processor running its own OS which is separated into various libraries and programs. The DRM code is code that shouldn't even be running unless you're currently decoding DRM'd media and could be its own optional tiny little blob even if the other 98% of the code is published.
	▲	garaetjjte 4 days ago \| parent \| prev [-]
		>Good luck trying to explain that to Legal Don't let Legal run the company. It's there to support the company, not the other way around. (unless it's Oracle, I guess)

▲

shmerl 5 days ago | parent | prev [-]

> the LLVM back-end was supposed to replace it anyway.

Is this still the case? I.e. why shut down the open amdvlk project then? They could just make it focused on Windows only.

▲

kimixa 5 days ago | parent [-]

The open source release of amdvlk has never been buildable for windows as all the required Microsoft integration stuff has to be stripped out before release.

So at best it'll be of limited utility for a reference, I can see why they might decide that's just not worth the engineering time of maintaining and verifying their cleaning-for-open-source-release process (as the MS stuff wasn't the only thing "stripped" from the internal source either).

I assume the llvm work will continue to be open, as it's used in other open stacks like rocm and mesa.

▲

shmerl 5 days ago | parent [-]

I see, but I still don't get why any of that had to be stripped, aren't they using public APIs? Nothing there has to be in any particularly way secret.

▲

kimixa 4 days ago | parent [-]

From what I remember a lot of the code provided by Microsoft was not publicly available or permissively licensed.

Though I think a lot of it might be considered "Legacy" - it still existed.

	▲	shmerl 4 days ago \| parent [-]
		Huh, interesting. Very MS style of problem. Why can't they develop public OS interfaces for that? I.e. you don't need the full code for that, just interface libraries. Not having public interfaces in this day and age is simply dumb.