9 ms·

The same vendors that can’t be bothered to port their software to a macOS released in the past three years, require us to run 32-bit apps for plugins and DRM do

The same vendors that can’t be bothered to port their software to a macOS released in the past three years, require us to run 32-bit apps for plugins and DRM dongles, and refuse to implement platform-native Metal in games because twice the performance of OpenGL isn’t worth it to them since they perceive Macs as being slow? Somehow I doubt it. But hey. Maybe M1 will change their minds. Maybe something more powerful will. A 27” iMac that can play FPS games at 60fps/5K/HDR with virtual Atmos surround out of the box? Near-effortless console porting to a future Silicon AppleTV, with gameplay compatibility across both devices? They’ll realize what they’re missing out on eventually :) But they’re not going to code M1 assembler until they do, and it’s easier for them to use Apple’s frameworks than play games with the CPU. (Yes, ffmpeg will probably do this. Good for them! And I’m sure Adobe will give it serious consideration - and then reject it, since it would get their apps rejected from the app stores and harm their relationship with Apple.)

h0l0cube 6y ago
First, let's leave games aside, because Mac isn't a profitable target for game publishers. Same with engineering. As for 3d rendering, video editing, compositing though, there's some scope for Mac to reclaim lost market share. > it’s easier for them to use Apple’s frameworks than play games with the CPU The things I'm talking about are broader than what their accelerated libraries support. Matrix operations are ubiquitous across heavy-weight computation, including stress analysis, physics simulation, machine learning, video and sound processing, compression, ray-tracing.. why would Apple limit their market? There's a whole host of 3rd party applications that would be augmented with this co-processor. And it should be trivial to add a compiler intrinsic that compiles to some bitcode primitive that can ensure it works across all devices and OS's... or just provide a mechanism to detect the extension. > And I’m sure Adobe will give it serious consideration - and then reject it, since it would get their apps rejected from the app stores and harm their relationship with Apple. This is bad for Apple. And bad for the consumer. Final Cut Pro isn't the only tool that video professionals need to use, and you can bet FCP will be using the coprocessor directly under the hood.
- floatingatoll 6y ago
  > Matrix operations are ubiquitous across heavy-weight computation, including stress analysis, physics simulation, machine learning, video and sound processing, compression, ray-tracing.. why would Apple limit their market? Apple offers frameworks that accelerate the relevant operations, and has over time shown an ongoing willingness to limit their market, even when that’s seen as unpalatable or unprofitable or unhelpful to themselves or their users. I assume that the frameworks offering acceleration will expand their uses somewhat over time. I expect those frameworks to be the only compelling solution for having portable matrix acceleration across the complete spectrum of Apple Silicon hardware revisions over time, especially if Apple revises their undocumented operations and updates their frameworks annually (which they can easily do, since each year’s hardware release already demands the latest macOS to boot at all).

h0l0cube 6y ago

First, let's leave games aside, because Mac isn't a profitable target for game publishers. Same with engineering. As for 3d rendering, video editing, compositing though, there's some scope for Mac to reclaim lost market share. > it’s easier for them to use Apple’s frameworks than play games with the CPU The things I'm talking about are broader than what their accelerated libraries support. Matrix operations are ubiquitous across heavy-weight computation, including stress analysis, physics simulation, machine learning, video and sound processing, compression, ray-tracing.. why would Apple limit their market? There's a whole host of 3rd party applications that would be augmented with this co-processor. And it should be trivial to add a compiler intrinsic that compiles to some bitcode primitive that can ensure it works across all devices and OS's... or just provide a mechanism to detect the extension. > And I’m sure Adobe will give it serious consideration - and then reject it, since it would get their apps rejected from the app stores and harm their relationship with Apple. This is bad for Apple. And bad for the consumer. Final Cut Pro isn't the only tool that video professionals need to use, and you can bet FCP will be using the coprocessor directly under the hood.

floatingatoll 6y ago
> Matrix operations are ubiquitous across heavy-weight computation, including stress analysis, physics simulation, machine learning, video and sound processing, compression, ray-tracing.. why would Apple limit their market? Apple offers frameworks that accelerate the relevant operations, and has over time shown an ongoing willingness to limit their market, even when that’s seen as unpalatable or unprofitable or unhelpful to themselves or their users. I assume that the frameworks offering acceleration will expand their uses somewhat over time. I expect those frameworks to be the only compelling solution for having portable matrix acceleration across the complete spectrum of Apple Silicon hardware revisions over time, especially if Apple revises their undocumented operations and updates their frameworks annually (which they can easily do, since each year’s hardware release already demands the latest macOS to boot at all).