By: --- (---.delete@this.redheron.com), May 23, 2022 6:56 am
Room: Moderated Discussions
Doug S (foo.delete@this.bar.bar) on May 22, 2022 8:46 pm wrote:
> --- (---.delete@this.redheron.com) on May 22, 2022 1:59 pm wrote:
> > Doug S (foo.delete@this.bar.bar) on May 22, 2022 11:01 am wrote:
> > > --- (---.delete@this.redheron.com) on May 21, 2022 6:59 pm wrote:
> > > > Maybe yes, maybe no, the devil is in the details.
> > > > JPEG XL has an option for ANS as the entropy coding and Apple's
> > > > version of NEON has ANS accelerator instructions...
> > > > https://patents.google.com/patent/US20210072994A1
> > >
> > >
> > > Apple's implementation of NEON has its own instructions that ARM hasn't defined?
> >
> > Why not?
> > There's a whole range of instruction encodings that can be used by
> > licensees as they wish. Apple uses it (as far as is known) for
> > - AMX
> >
> > - LZ engine (conceptually like AMX, associated with a cluster). Not as high
> > compression as SW LZ, but a lot faster, so used under conditions of either
> > + extreme memory pressure (so the priority is more on fast page encode than on 10% smaller pages)
> > + low power conditions (obv more relevant for mobile devices)
> >
> > - these NEON ANS extensions.
>
>
> I knew there were ranges of encodings that could be used as licensees wanted for new stuff like
> AMX, I just hadn't realized Apple was also extending existing facilities like NEON. Seems like
> that could get complicated if ARM extended NEON with similar but not quite identical facilities
> and Apple ended up forced to support two opcodes that do almost but not quite the same thing.
>
> Though I guess I've been operating under the assumption that since the release of SVE, ARM has not and does not
> plan to further extend NEON. Is that the case, NEON pretty much "done" at this time as far as future changes from
> ARM? If so, Apple extending NEON might indicate they have no plans to implement SVE2 anytime soon - since extending
> SVE2 could as above potentially more problematic if ARM is simultaneously extending it themselves.
It's two instructions to solve a very particular problem.You are building way too much of a case on it.
Apple will co-ordinate with ARM on future ISA extensions. OF COURSE.
And Apple will preserve their extensions behind specific APIs so that they can drop/modify them any time they like. OF COURSE.
Apple will not drop NEON the same year they ship SVE. OF COURSE.
And if Apple eventually drop NEON AND they continue to want to use these SVE instructions to accelerate LZ_FSE (rather than some other acceleration path) they will simply define two alternative, SVE-based instructions in the extension space. OF COURSE.
> --- (---.delete@this.redheron.com) on May 22, 2022 1:59 pm wrote:
> > Doug S (foo.delete@this.bar.bar) on May 22, 2022 11:01 am wrote:
> > > --- (---.delete@this.redheron.com) on May 21, 2022 6:59 pm wrote:
> > > > Maybe yes, maybe no, the devil is in the details.
> > > > JPEG XL has an option for ANS as the entropy coding and Apple's
> > > > version of NEON has ANS accelerator instructions...
> > > > https://patents.google.com/patent/US20210072994A1
> > >
> > >
> > > Apple's implementation of NEON has its own instructions that ARM hasn't defined?
> >
> > Why not?
> > There's a whole range of instruction encodings that can be used by
> > licensees as they wish. Apple uses it (as far as is known) for
> > - AMX
> >
> > - LZ engine (conceptually like AMX, associated with a cluster). Not as high
> > compression as SW LZ, but a lot faster, so used under conditions of either
> > + extreme memory pressure (so the priority is more on fast page encode than on 10% smaller pages)
> > + low power conditions (obv more relevant for mobile devices)
> >
> > - these NEON ANS extensions.
>
>
> I knew there were ranges of encodings that could be used as licensees wanted for new stuff like
> AMX, I just hadn't realized Apple was also extending existing facilities like NEON. Seems like
> that could get complicated if ARM extended NEON with similar but not quite identical facilities
> and Apple ended up forced to support two opcodes that do almost but not quite the same thing.
>
> Though I guess I've been operating under the assumption that since the release of SVE, ARM has not and does not
> plan to further extend NEON. Is that the case, NEON pretty much "done" at this time as far as future changes from
> ARM? If so, Apple extending NEON might indicate they have no plans to implement SVE2 anytime soon - since extending
> SVE2 could as above potentially more problematic if ARM is simultaneously extending it themselves.
It's two instructions to solve a very particular problem.You are building way too much of a case on it.
Apple will co-ordinate with ARM on future ISA extensions. OF COURSE.
And Apple will preserve their extensions behind specific APIs so that they can drop/modify them any time they like. OF COURSE.
Apple will not drop NEON the same year they ship SVE. OF COURSE.
And if Apple eventually drop NEON AND they continue to want to use these SVE instructions to accelerate LZ_FSE (rather than some other acceleration path) they will simply define two alternative, SVE-based instructions in the extension space. OF COURSE.