we actually also saw this historically with openGL. openGL comes from an ancient company whispered about by the elderly programmers (30 + year old) known as SGI. Originally it was CLOSED SOURCE and SGI called it "SGI-GL" for a computer codename IRIS which was cool looking with bright popping color plastic and faux granite keyboard. Good guy SGI open sourced SGI-GL to become what we called "openGL" (get it, now it's open), and then it stuck.

That's all to say NVIDIA could pull a SGI and open their stuff, but they're going more sony style and trying to monopolize. Oh, and SGI also wrote another ancient lore library known as "STL" or the "SGI Template Library" which is like the original boost template metaprogramming granddaddy

Also the XFS file system.

Nice story, but is it correct? Wikipedia says STL was first implemented by HP and later by the same authors at SGI.

STL started even earlier, obviously without using the name "STL", as a library of generic algorithms for the programming language Ada (David R. Musser & Alexander A. Stepanov, 1987).

Rumor is that STL stands for STepanov and (Meng) Lee.

Vulkan only matters on Android (from version 10 onwards) and GNU/Linux.

Zero impact on Switch, Playstation, XBox, Windows, macOS, iOS, iPadOS, Vision OS.

"Windows"

dxvk-gplasync is a game changer for dx9-11 shader stutter.

Sure, for the 2% folks that enjoy Windows games, written againt DirectX, on Linux Steam Store.

Which Android Studios can't even be bothered to target with their NDK engines, based on GL ES, Vulkan.

I'm on windows 11, if I see not dx12 in my afterburner overlay, I use it.

Even if there's no shader stutter, Vulkan tends to use less juice than DX.

Doesn't Intel now ship DXVK with their new graphic card on Windows as their DX11 drivers were "less than optimal"?

Their dx9 drivers seem to, so I wouldn't be surprised if they did it for 10-11 as well.

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

"We have seen this succeed multiple times: FreeSync vs GSync, DLSS vs FSR, (not AMD but) Vulkan vs DirectX & Metal."

I'll definitely agree with you on Sync and Vulkan, but dlss and xess are both better than fsr.

https://youtube.com/watch?v=el70HE6rXV4

OpenCL was released in 2009. AMD has had plenty of time to push and drive that standard. But OpenCL had a worse experience than CUDA, and AMD wasn't up to the task in terms of hardware, so it made no real sense to go for OpenCL.

AMD shouldn't push on anything. They have the wrong incentives. They should just make sure that software runs on their GPUs and nothing else.

Karol Herbst is working on Rusticl, which is mesa's latest OpenCL implementation and will pave the way for other things such as SYCL.

I agree with aspects of this take. In my original post I think that "should" is a strong word.

Realistically companies only have an obligation to make themselves profitable so really companies "should" only strive for profitability within the boundaries of the law above all else.

AMD have no obligation to drive an open standard, it's at their discretion to choose that approach - and it might actually come at the cost of profitability as it opens them up to competitors.

In this case - I believe that hardware & platform software companies that distribute a closed platform which cannot be genuinely justified as anything other than intending to prevent consumers from using competitor products "should" be moderated by regulator intervention as it results in a slower rate of innovation and poor outcomes for consumers.

That said, dreaming for the regulation of American tech giants is a pipe dream, haha.

A strategic and forward-thinking approach

> AMD should push/drive an open standard that can be run on any hardware.

AMD has always been notoriously bad at the software side, and they frequently abandon their projects when they're almost usable, so I won't hold my breath.