Not really because how the else can a company with less than 500 employees afford to create an entirely new shader compiler ?
By hiring established driver developers (including the RADV head dev), I literally just went over this.
As for the afford part, you do realise they own Steam right?
They made $4.3 billion in 2017.
Pause and think about that.
Their first party games are basically an afterthought now, their revenue stream is 100% Steam.
Documentation isn't the only part that's important since Intel has better open source documentation than AMD does but you don't see anybody producing a 3rd party shader compiler for Intel GPUs now, do you ?
Intel is doing pretty well on their own over the last few years, they literally just announced another GPU compiler project of their own called IBC, and they have plenty of other work coming forward towards their OneAPI efforts.
Unlike AMD, Intel has pleeeeenty of money to afford driver dev efforts, so while I imagine that Valve is certainly in contact with them, they aren't as concerned, not to mention there is less wasted potential with current Intel iGPU's compared to AMD discrete cards.
The hiring of Raja Koduri will ensure that Intel drivers are well addressed, he did so well at AMD in that department with such a meager budget that he can't fail given Intel's deeper pockets - I wouldn't even be surprised to find him in communication with the people at Valve about ongoing work.
As for ACO, nobody really cares about driver stack compatibility since AMD's proprietary shader compiler is likely superior to the community project. ACO has very good hardware compatibility which is arguably the bigger challenge but the fact that they were able to overcome it that easily means that AMD is nowhere near as aggressive as Nvidia are in terms of breaking binary compatibility and then there's the fact that AMD's architecture doesn't have anywhere near as complex scheduling rules compared to Nvidia architectures so compiler designers for AMD have it very easy compared to the Nvidia folks ...
No, no, no. AND NO.
I literally just told you that ACO hardware compatibility is low, only encompasing 2 generations in high Vulkan CTS percentage of success.
It will get better in time certainly, it was only announced very recently.
As for the breaking binary compatibility part, I would argue that AMD's GCN/SI architecture (while having significant FLOPS to FPS issues) was well designed from the start to be extensible with minimum breaking changes to an established code base.
nVidia's on the other hand, while very optimised in what it does, was not well designed for extensibility, hence the oft broken binary compatibility you mentioned.
Basically AMD paid for easy extensibility with a loss of efficiency - which given their lesser budget for driver development was probably better for them.
nVidia also has more money to make aggressive hardware changes in this fashion.
Make that ALOT more money x10 - people often underestimate just how much of a gulf this is for AMD to cross, it forces them (or it did) to take the most budget efficient approach possible in design.
www.semiaccurate.com
Facebook
Twitter