Ana Rodriguez (ana_rodriguez_riano.delete@this.protonmail.com) on October 19, 2022 1:27 pm wrote:
> Ana Rodriguez (ana_rodriguez_riano.delete@this.protonmail.com) on October 19, 2022 1:20 pm wrote:
> > Chester (lamchester.delete@this.gmail.com) on October 19, 2022 12:11 pm wrote:
> > > Ana Rodriguez (ana_rodriguez_riano.delete@this.protonmail.com) on October 19, 2022 11:12 am wrote:
> > > > If someone were to build a Linux system with proprietary,
> > > > private (undocumented) ISA extensions, how would they
> > > > do it given Linux is open source? Are there any examples of this being done? Would it be possible at all?
> > > >
> > > > I got inspiration from this (https://github.com/corsix/amx) and I wondered if someone has done
> > > > it before on a Linux-based system. I understand a userspace library could be created to access
> > > > those instructions from userspace, but how would then they be implemented in the kernel? Through
> > > > a proprietary kernel module built using a custom compiler? Or is that not needed at all and the
> > > > library could just run on the processor taking advantage of the proprietary extensions?
> > >
> > > If the instructions don't create any extra state that the kernel needs to save or be aware
> > > of, then you could use the instructions in userspace without any modification to the kernel.
> > > However, if you need the kernel to save extra state, you do need a kernel change.
> > >
> > > Example of something that doesn't need a kernel change: MMX. Intel specifically aliased the MMX registers
> > > to the x87 ones, so an OS doesn't even need to know that MMX is supported. It saves the x87 registers on
> > > a context switch, and by doing so it would also save the MMX registers (because ST0-7 == MM0-7).
> > >
> > > Example of something that does need a kernel change: SSE. SSE adds a set of separate vector/FP registers
> > > (xmm regs). The kernel has to save and restore those on a context switch, and thus needs a change.
> > >
> > > In Apple AMX's case, they introduce an extra 80 registers, each of which are 64 bytes wide.
> > > The kernel needs to save and restore these on a context switch. So, you need a kernel change.
> >
> > I see. Thank you for your response!
> >
> > I unfortunately this is one limitation of the GPL...
>
> I wonder, though. I thought Darwin was open source. How did Apple manage to keep it hidden if they're
> releasing the source code of their kernel and given the kernel had to explicitly support it?

What exactly are you worrying about?
IF Linux (or at least someone creating a particular Linux build) wished to modify the context switching code so as to save and restore the AMX registers, they can do so. I know of no legal theory by which Apple could stop them (not to mention there's no particular reason why Apple should care). There is the issue of learning what the appropriate commands are, but that's no different from (and a whole lot simpler than) reverse-engineering the GPU. Most, if not all, the work has already been done, by people like dougall and corsix.

The next question is: why bother? This gets into what's the next step in this plan? Is it expected that FOSS will create the equivalent of Apple's Accelerate library or update existing BLAS and FFT libraries? Again I suspect Apple has no particular interest in stopping this, though FOSS may want to be sure that no-one decides to sneak a peak into the Accelerate libraries just how to see how something is done, then remembers what they saw a little too accurately...
Alternatively, or in addition to this, GCC and/or LLVM could be modified to emit AMX instructions.

The problem at this point (problem for FOSS, not Apple) is that Apple has made it extremely clear that they regard absolutely no aspect of AMX usage as fixed and to be relied upon by developers. As I have documented in substantial detail, every version of AMX has brought large, and sometimes unexpected, modifications and updates. I think the version in the M1 is v2, and the version in the A15/M2 is v3. The A16 may well have a v4, though there's no data yet to indicate either way.
Apple's story for this compatibility is that they will take care of it via updating Accelerate.lib and ensuring the correct version of that dylib is installed via macOS; but FOSS doesn't have a great track record with handling this sort of thing...

(BTW I personally don't think Apple are doing this just to be dicks. I think they genuinely have ambitious, rapidly changing, plans for AMX; and abstracting the HW behind Accelerate is the easiest way to keep those plans moving fast without being weighed down by slow painful baggage. Some of the early AMX ideas, for example, look sub-optimal compared to later cleaner generalizations, and it's possible that already a bad v1 or v2 idea has been dropped by v3 or v4, something not possible once the opcodes, memory layout, etc become part of the developer contract.)

Oh, as for Darwin, while much of Darwin is Open Source, Apple never pretended or claimed the whole thing is. There's plenty of stuff (many drivers for example) that is not released as source. Like looking at LLVM, you can see some of what Apple has done by looking at that code that is available, but not everything is released via that channel, and what is released is often a year or more behind the publicly-released OS and chips.