Fair enough but they are very much the exception and their impact on the wider ecosystem is minimal. In general Arm’s controls on this happening are much stronger than for RISC-V.
On the x86 side generally one of the vendors makes a new extension and then once it's shown that there's value, their legal teams get together and cross license. The world hasn't fallen apart.
I agree that ARM has more controls, but disagree that those controls have value.
Isn’t x86 situation due to a legally enforceable cross licensing deal arising out of a long history of litigation? No reason why this would apply to any other architecture.
My understanding is that there's no existing cross licensing for new extensions. That's why vt-x and svm are totally different implementions for x86 hardware virtualization; most of the newer supervisor state extensions aren't worth the overhead of cross licensing because it's only kernels and hypervisors utilizing them anyway rather than the orders of magnitude more user code out there.
Also notice how there aren't any Zen cores with AVX512. Even Zen4 is backporting BF16 out of AVX512 to AVX2, and BF16 is just 'use the top 16 bits of a normalizd f32' and was designed specifically to probably be without too much IP overhead.
You probably have better sources than me so I’ll defer to your info on this.
Doesn’t this sort of make the point though that we’re seeing fragmentation in x86 ISAs with only two participants. I may be wrong but I do worry that without Arm like controls every big designer who has a good idea for their niche adds something proprietary on and before long we have a very messy situation.
I just don't see fragmentation as a problem, nor something that can be solved. Even under AArch64, there's close to a hundred FEAT_XXX bits that can even be different for the same microarchitecture, just the integrator was given an option at hardware instantiation time. The only archs without fragmentation are dead archs that no one cares to make new versions of and evolve. What matters is being able to depend on a standard core set so that your tooling can make sense of your code, but if there's cool optional features tacked on the side that's great too. So far RISC-V has been doing a great job defining that core feature set.
Fair enough but they are very much the exception and their impact on the wider ecosystem is minimal. In general Arm’s controls on this happening are much stronger than for RISC-V.