From the oneDNN documentation[1]:
> The library is optimized for Intel Architecture Processors, Intel Processor Graphics and Xe architecture-based Graphics.
Now, whether "optimized" means tuned for Intel architecture, or crippled for other architecture, is something to be figured out. Given the precedent set by MKL, I wouldn't trust it to be the 'tuned' option. Someone who speaks C++ may be able to better discern if such concerns exist with one-dnn.
Full disclosure, I work with the team behind Embree and OIDN. I've never personally worked with oneDNN. I'll just say that we test our code on Intel CPUs (obviously) and therefore optimize performance based on those tests. We don't have AMD CPUs readily available to test with (as you might imagine).
However, since all the code is open source, third parties often do benchmarks across platforms. Michael Larabel from Phoronix does a really good job of this.
> We don't have AMD CPUs readily available to test with (as you might imagine).
I mean, it makes perfect sense to me that Intel would only care about optimizing (or even supporting) their software on Intel chips, but I'm sort of surprised that you don't have AMD systems to test on just to compare performance.
Wouldn't it be something that you (or management, or whoever) would want to know if you were about to release a version that had much worse performance on AMD systems because of a regression ("Intel is intentionally crippling AMD CPUs!") or much better performance ("Intel released a new update but it runs better on AMD at half the price lol")?
If it's a small team then you may not have the budget (or want to spend it on that), but surely it would be nice to know either way?
Now, whether "optimized" means tuned for Intel architecture, or crippled for other architecture, is something to be figured out. Given the precedent set by MKL, I wouldn't trust it to be the 'tuned' option. Someone who speaks C++ may be able to better discern if such concerns exist with one-dnn.
[1] https://github.com/oneapi-src/oneDNN