5 ms·

> However more importantly, this is an advantage to Apple. By only letting their libraries use these special instructions Apple retains the freedom to radically

> However more importantly, this is an advantage to Apple. By only letting their libraries use these special instructions Apple retains the freedom to radically change how this hardware works later. They could remove or add AMX instructions. Depends on whether these instructions can be executed with unprivileged user-land code. Once the genie is out of the bottle, backward compatibility means imitating the old instruction set. Since a recompile is often cheap enough (and esp. if coprocessor calls can be remapped at the bitcode compilation time), this should be a non-issue.

saagarjha 6y ago
Apple isn't going to support your code using custom instructions.
- h0l0cube 6y ago
  I forget that this is how Apple's operates. I can just see a bunch of software that is really popular on Mac (e.g. image + video processing, 3d) that could get a massive speed boost with unfettered access to these instructions. Their library ain't going to cater for a fraction of the useful stuff that a matrix coprocessor can do.
TazeTSchnitzel 6y ago
When Apple have decided not to document an instruction set to give them freedom to change it, I don't think they will cry about breaking your application in the next hardware version. This is just like how (some) GPU vendors don't document their hardware's data structures and instruction set. You're living dangerously if you choose to rely on their exact behaviour. The vendors really only expect you to use their API (Vulkan/Metal/Direct3D/etc) because that abstraction layer allows them to radically and incompatibly change their hardware on a regular basis to improve performance or functionality.
- uncledave 6y ago
  Exactly this. You buy hardware for the API that ships with the software on it these days.
  - simonh 6y ago
    Or if you do choose to rely on implementation details of specific hardware, you have to take on responsibility for managing breaking changes yourself. e.g. Implementing your own compatibility checks and fallback code paths, or knowing you will have to tweak and recompile for each hardware version.
- h0l0cube 6y ago
  Problem is that these matrix instructions are way more useful that the use cases they've catered for in their library. You could have a library that has a function call for each matrix instruction, but that's not worth the penalty of a function call. If your game, graphics software, physics simulation, render farm, video encoder etc can get a boost from these commands, it should be permitted, not just the software that Apple makes. Not sure why people are hostile to this.
- h0l0cube 6y ago
  > This is just like how (some) GPU vendors don't document their hardware's data structures and instruction set. You're living dangerously if you choose to rely on their exact behaviour. The vendors really only expect you to use their API (Vulkan/Metal/Direct3D/etc) because that abstraction layer allows them to radically and incompatibly change their hardware on a regular basis to improve performance or functionality. GPUs are external processors, that require DMA transport, and can perform useful jobs in parallel with the CPU, and are produced by multiple vendors. This almost certainly requires a HAL, and there's little impact of making dynamic libraries calls compared to the benefit received. Compare this to a co-processor, that basically can be called directly from CPU instructions, without DMA and a remote instruction queue. Something like this gains great benefits from a compiler intrinsic, as a function call, particularly as a dynamic library is quite expensive. This compiler intrinsic can just map to bitcode, which can then map to whatever at compile-time on the app store deployment side. Why would people not want this option? Why should this only be available to Apple's internal products? Why should Photoshop/Lightroom/Blender/physics simulation/video encoding/AAA Games etc. run slower? There's no excuse for Apple not providing a way to use these instructions, either via bitcode, or providing a mechanism to detect relevant CPU metadata. At a minimum, I expect hackers to take advantage of this to speed up their own applications, as well as open source forks.
floatingatoll 6y ago
Apple doesn’t support macOS downgrades on their hardware, because macOS updates often incorporate firmware updates, and there’s no guarantee of backwards compatibility in those either. This almost never comes up, because they typically don’t need to break things, but I can absolutely envision them performing microcode updates that make the CPU incompatible with previous releases. They owe nothing to anyone regarding these instructions, and they will act accordingly. That’s what unsupported means here: not the PC or Android meanings where everyone has to kludge it in, but the Apple meaning where they will release without warning an OS point release version 15.2.7 that shatters an entire ecosystem built on unsupported APIs. These instructions are just unsupported APIs in Silicon. Use them at your peril.
- mantap 6y ago
  I admit it's been a while since I bought a new Mac but can you not boot older macOS from an external drive anymore?
  - barkingcat 6y ago
    No M1 Mac can boot any OS prior to Big Sur - there simply isn't any binaries for it to run. With intel macs you can boot and install older macOS's up to a certain point. Like the previous poster says, it's about what firmware versions you have. For example, if your mac came with Sierra, and through the regular usage and update, you patched it up to Mojave, and installed (or was forced to install by the way, there is no way to reject certain types of updates) firmware updates, you find that all of a sudden you can't re-install Sierra anymore. You'd need to install whatever version your firmware now supports. This behaviour is undocumented and it's case by case - for each mac hardware there is a firmware for it - there are lots of people online who have figured out patch levels are for each revision of hardware, etc - but it's more trial and error to see what older version of macOS you can downgrade to.
    - Wowfunhappy 6y ago
      > For example, if your mac came with Sierra, and through the regular usage and update, you patched it up to Mojave, and installed (or was forced to install by the way, there is no way to reject certain types of updates) firmware updates, you find that all of a sudden you can't re-install Sierra anymore. You'd need to install whatever version your firmware now supports. I have never seen any record of this happening. I'm really quite sure you've always been able to install the earliest OS that your model of Mac shipped with. The odd situation I mentioned above is the closest I've ever seen to a firmware update causing problems (if that's even the cause), and even then the OS runs fine.
socialdemocrat 6y ago
But if it is undocumented Apple has no obligation to support these instructions in user code. In fact you will most likely get a fail trying to submit this to the app store. Apple has always been merciless on this. If you use stuff they don't support and your software later breaks, that is your problem. This is different from say Microsoft which has added support for quirks and bugs in software in their OS updates to keep old software running. Apple doesn't do that, and I think it is the right decision. It makes developers used to following standards. But it is a tough call as it really pisses off people when their software breaks due to OS updates.
- mkr-hn 6y ago
  I wonder if Apple would be as concerned with backward compatibility if they had Microsoft's reach in governments and enterprise. Enormous organizations are probably not receptive to "it's your own fault for using undocumented behavior" when negotiating contracts.
  - temac 6y ago
    You don't negitiate contracts about OS promising backward compat. Not even MS, which has a quite good backward compat story for windows, does that. Plus pro apps are often specified and tested to run on a specific OS version.
- h0l0cube 6y ago
  > Apple doesn't do that, and I think it is the right decision. It makes developers used to following standards. But it is a tough call as it really pisses off people when their software breaks due to OS updates. But why not support it at the bitcode level? Matrix operations have broad applicability, so they are just slowing down the software for customers using third party products that could use those instructions beyond what the library offers.
masklinn 6y ago
> Once the genie is out of the bottle, backward compatibility means imitating the old instruction set. Since the instructions are completely unofficial and only available through what I assume is a dynamically linked system framework, there is 0 chance Apple will care. For prior art, when Apple silently decided to change the ABI of the syscall underlying gettimeofday(2) in Sierra, projects who made raw syscalls despite that never being officially supported (cough cough golang) had to fix their stuff.
- h0l0cube 6y ago
  That's fair. But i could see these instructions being useful for photoshop, lightroom, image magick, rendering software, video encoders, games physics etc. way beyond what their library offers. And if wager that Apple will be using those instructions under the hood of their own products.
  - masklinn 6y ago
    > But i could see these instructions being useful for photoshop, lightroom, image magick, rendering software, video encoders, games physics etc. way beyond what their library offers. So? > And if wager that Apple will be using those instructions under the hood of their own products. Which they can, whether through the public library they offer or through one of their private frameworks.

saagarjha 6y ago

Apple isn't going to support your code using custom instructions.

h0l0cube 6y ago
I forget that this is how Apple's operates. I can just see a bunch of software that is really popular on Mac (e.g. image + video processing, 3d) that could get a massive speed boost with unfettered access to these instructions. Their library ain't going to cater for a fraction of the useful stuff that a matrix coprocessor can do.

TazeTSchnitzel 6y ago

When Apple have decided not to document an instruction set to give them freedom to change it, I don't think they will cry about breaking your application in the next hardware version. This is just like how (some) GPU vendors don't document their hardware's data structures and instruction set. You're living dangerously if you choose to rely on their exact behaviour. The vendors really only expect you to use their API (Vulkan/Metal/Direct3D/etc) because that abstraction layer allows them to radically and incompatibly change their hardware on a regular basis to improve performance or functionality.

uncledave 6y ago
Exactly this. You buy hardware for the API that ships with the software on it these days.
- simonh 6y ago
  Or if you do choose to rely on implementation details of specific hardware, you have to take on responsibility for managing breaking changes yourself. e.g. Implementing your own compatibility checks and fallback code paths, or knowing you will have to tweak and recompile for each hardware version.
h0l0cube 6y ago
Problem is that these matrix instructions are way more useful that the use cases they've catered for in their library. You could have a library that has a function call for each matrix instruction, but that's not worth the penalty of a function call. If your game, graphics software, physics simulation, render farm, video encoder etc can get a boost from these commands, it should be permitted, not just the software that Apple makes. Not sure why people are hostile to this.
h0l0cube 6y ago
> This is just like how (some) GPU vendors don't document their hardware's data structures and instruction set. You're living dangerously if you choose to rely on their exact behaviour. The vendors really only expect you to use their API (Vulkan/Metal/Direct3D/etc) because that abstraction layer allows them to radically and incompatibly change their hardware on a regular basis to improve performance or functionality. GPUs are external processors, that require DMA transport, and can perform useful jobs in parallel with the CPU, and are produced by multiple vendors. This almost certainly requires a HAL, and there's little impact of making dynamic libraries calls compared to the benefit received. Compare this to a co-processor, that basically can be called directly from CPU instructions, without DMA and a remote instruction queue. Something like this gains great benefits from a compiler intrinsic, as a function call, particularly as a dynamic library is quite expensive. This compiler intrinsic can just map to bitcode, which can then map to whatever at compile-time on the app store deployment side. Why would people not want this option? Why should this only be available to Apple's internal products? Why should Photoshop/Lightroom/Blender/physics simulation/video encoding/AAA Games etc. run slower? There's no excuse for Apple not providing a way to use these instructions, either via bitcode, or providing a mechanism to detect relevant CPU metadata. At a minimum, I expect hackers to take advantage of this to speed up their own applications, as well as open source forks.

floatingatoll 6y ago

Apple doesn’t support macOS downgrades on their hardware, because macOS updates often incorporate firmware updates, and there’s no guarantee of backwards compatibility in those either. This almost never comes up, because they typically don’t need to break things, but I can absolutely envision them performing microcode updates that make the CPU incompatible with previous releases. They owe nothing to anyone regarding these instructions, and they will act accordingly. That’s what unsupported means here: not the PC or Android meanings where everyone has to kludge it in, but the Apple meaning where they will release without warning an OS point release version 15.2.7 that shatters an entire ecosystem built on unsupported APIs. These instructions are just unsupported APIs in Silicon. Use them at your peril.

mantap 6y ago
I admit it's been a while since I bought a new Mac but can you not boot older macOS from an external drive anymore?
- barkingcat 6y ago
  No M1 Mac can boot any OS prior to Big Sur - there simply isn't any binaries for it to run. With intel macs you can boot and install older macOS's up to a certain point. Like the previous poster says, it's about what firmware versions you have. For example, if your mac came with Sierra, and through the regular usage and update, you patched it up to Mojave, and installed (or was forced to install by the way, there is no way to reject certain types of updates) firmware updates, you find that all of a sudden you can't re-install Sierra anymore. You'd need to install whatever version your firmware now supports. This behaviour is undocumented and it's case by case - for each mac hardware there is a firmware for it - there are lots of people online who have figured out patch levels are for each revision of hardware, etc - but it's more trial and error to see what older version of macOS you can downgrade to.
  - Wowfunhappy 6y ago
    > For example, if your mac came with Sierra, and through the regular usage and update, you patched it up to Mojave, and installed (or was forced to install by the way, there is no way to reject certain types of updates) firmware updates, you find that all of a sudden you can't re-install Sierra anymore. You'd need to install whatever version your firmware now supports. I have never seen any record of this happening. I'm really quite sure you've always been able to install the earliest OS that your model of Mac shipped with. The odd situation I mentioned above is the closest I've ever seen to a firmware update causing problems (if that's even the cause), and even then the OS runs fine.

socialdemocrat 6y ago

But if it is undocumented Apple has no obligation to support these instructions in user code. In fact you will most likely get a fail trying to submit this to the app store. Apple has always been merciless on this. If you use stuff they don't support and your software later breaks, that is your problem. This is different from say Microsoft which has added support for quirks and bugs in software in their OS updates to keep old software running. Apple doesn't do that, and I think it is the right decision. It makes developers used to following standards. But it is a tough call as it really pisses off people when their software breaks due to OS updates.

mkr-hn 6y ago
I wonder if Apple would be as concerned with backward compatibility if they had Microsoft's reach in governments and enterprise. Enormous organizations are probably not receptive to "it's your own fault for using undocumented behavior" when negotiating contracts.
- temac 6y ago
  You don't negitiate contracts about OS promising backward compat. Not even MS, which has a quite good backward compat story for windows, does that. Plus pro apps are often specified and tested to run on a specific OS version.
h0l0cube 6y ago
> Apple doesn't do that, and I think it is the right decision. It makes developers used to following standards. But it is a tough call as it really pisses off people when their software breaks due to OS updates. But why not support it at the bitcode level? Matrix operations have broad applicability, so they are just slowing down the software for customers using third party products that could use those instructions beyond what the library offers.

masklinn 6y ago

> Once the genie is out of the bottle, backward compatibility means imitating the old instruction set. Since the instructions are completely unofficial and only available through what I assume is a dynamically linked system framework, there is 0 chance Apple will care. For prior art, when Apple silently decided to change the ABI of the syscall underlying gettimeofday(2) in Sierra, projects who made raw syscalls despite that never being officially supported (cough cough golang) had to fix their stuff.

h0l0cube 6y ago
That's fair. But i could see these instructions being useful for photoshop, lightroom, image magick, rendering software, video encoders, games physics etc. way beyond what their library offers. And if wager that Apple will be using those instructions under the hood of their own products.
- masklinn 6y ago
  > But i could see these instructions being useful for photoshop, lightroom, image magick, rendering software, video encoders, games physics etc. way beyond what their library offers. So? > And if wager that Apple will be using those instructions under the hood of their own products. Which they can, whether through the public library they offer or through one of their private frameworks.