3 ms·
It's really just a matter of someone caring. I don't see finding myself with enough time to work on that any time soon, but if someone has a good use case for i
by marcan_42 5y ago
It's really just a matter of someone caring. I don't see finding myself with enough time to work on that any time soon, but if someone has a good use case for it and motivation to get it done I'm sure it'll happen (and I'll gladly help).
Some things are dodgier - e.g. though supporting the AMX CPU extensions is quite viable in a kernel fork, I'm not sure if that kind of thing would fly upstream. Same with security features like SPRR - not likely to happen. But these aren't really things the average end user has to care about; they're bonus features, not anything core.
- setpatchaddress 5y agoJust curious: if someone was inclined to build a set of good (correct style, well-documented, etc) patches to support those extensions, why would the kernel refuse them? (Put another way: I'm wondering whether you think the difficulty is technical or political.)
- marcan_42 5y agoIt's a bit of both. It basically boils down to it being an invasive change to core kernel code that doesn't have demonstrable benefit to users, and is specific to one platform. If we can point at a specific application and say "look, this speeds up 300% with AMX" then that might help convince people, but there would definitely be quite some political discussion, not in the least because what Apple did is a violation of the architecture. I'm hoping we can at least push through a prctl to turn on TSO mode for x86 emulation. I think that one will be simple enough and have enough benefits to convince people.
- amluto 5y agoGetting proper AMX support on _x86_ Linux merged is nasty because of state size issues. I know nothing about ARM64 extended state, but some of the same issues may exist. (The x86 xstate design is horrible. I doubt that ARM64 is anywhere near as bad.)