4 ms·

In my experience, Apple doesn't like any standards it doesn't control with an iron fist I mean, on one hand, the Metal/Vulkan/OpenGL situation is unfortun

In my experience, Apple doesn't like any standards it doesn't control with an iron fist I mean, on one hand, the Metal/Vulkan/OpenGL situation is unfortunate and I don't understand Apple's motivation there. On the other hand I'm sitting here typing on a Mac with nothing but USB-C ports that is connected to half a dozen peripherals and a big ol' monitor over those standard ports using standard protocols. In general I feel that Apple prefers open standards when they actually suffice. USB2 couldn't do a lot of the things that Lightning did, so they invented that. Now that USB-C exists, they embraced it immediately on the Mac and iPad but are unfortunately dragging their feet w.r.t. the iPhone.

ribit 3y ago
> the Metal/Vulkan/OpenGL situation is unfortunate and I don't understand Apple's motivation there. I don't think it's hard to understand. Apple wanted an easy to use API that could be extended and updated easily. Vulkan is an extremely complex API that foregoes all and any developer ergonomy to facilitate quick driver development on as many hardware targets as possible. Consequently, Vulkan's design choices are driven by the least common denominator. The goals are just too different. There is at least some evidence that Apple was interested in supporting and shaping Vulkan (they were member of the initial working group), but I suspect that it very quickly became clear that the committee is going into a direction they were not interested in, so they noted out. Still, I don't think it's correct that Apple is opposing any kind of standardisation in this domain, they just want something more aligned with their vision. They have been very active with WebGPU, which is shaping up to be a very nice API, and it has inherited a lot of good design decisions from Metal.
- fayalalebrun 3y ago
  Indeed Apple has been very active in shaping WebGPU, and that is why we can't use a bytecode representation for shaders. Instead, we have to repeat OpenGL's mistakes and store shaders as strings. WebGPU specifically has to be the lowest common denominator among the APIs it supports. And there are several features very useful in GPGPU's which are supported in Vulkan and CUDA, but cannot be included in WebGPU due to the lack of Metal support. One such example is floating point atomics.
  - ribit 3y ago
    I am sure that bytecode representation of shaders will come in a future revision. It’s not a first priority. SPIR-V is a poor choice for portable shaders for reasons outlined by the WebGPU group on multiple occasions. And WebGPU shading language finally goes away with some poor legacy design choices that are still stuck in GLSL and HLSL (such as shader bindings via global variables). Regarding floating point atomics, I think you got it confused? Metal fully supports floating atomics on all recent devices, while in Vulkan it’s an optional extension. According to gpuinfo database only 30% of implementations support float atomics, and only 10% support more advanced operations like min/max. If you are looking for cross-platform float atomics support, Apple is the least of your worries (what they suck at are 64-bit int atomics though).
dwaite 3y ago
> I mean, on one hand, the Metal/Vulkan/OpenGL situation is unfortunate and I don't understand Apple's motivation there. OpenGL is a dead end - while vendors (including Apple) still support their respective GL stacks, there is not really active investment anymore either in those stacks or in the standards. Metal came out years before Vulkan, and Apple has tight integration between the graphics API and their underlying first-party graphics hardware designs. If Apple did have first party support for Vulkan, it would basically be MoltenVK anyway. Apple tends to push anything which isn't a first party framework to be third-party sourced and bundled as much as they can. They likely think MoltenVK as a third party library is the best scenario for Vulkan support.
- MattSteelblade 3y ago
  "Years" is overstating it a bit; Vulkan's SDK came out a little more than a year and a half after Metal was available on iOS and 8 months after it was available on Macs.
  - dwaite 3y ago
    Ahh you're right, I thought it was 2017 for the Vulkan 1.0 release. My understanding is still that Metal was released on iOS months before AMD's Mantle API was accepted as the start of Vulkan work.
rasz 3y ago
>On the other hand I'm sitting here typing on a Mac with nothing but USB-C ports that is connected to half a dozen peripherals and a big ol' monitor over those standard ports using standard protocols. cool, now try two monitors https://www.kensington.com/en-au/news-index---blogs--press-center/docking--connectivity-blog/differences-between-sst-and-mst-modes/ https://www.kensington.com/en-au/news-index---blogs--press-c...
- lloeki 3y ago
  I have two 4K 60Hz monitors plugged in my work MBP (M1 Pro, or is it Max?) via DP over USB-C (not TB) basically every day. The MagSafe and HDMI ports sit unused, and I wish these were more USB-C ports instead. My personal Mini M1 can't handle two DP over USB-C displays but can handle one DP over USB-C + one USB-C to HDMI. I also wish the two USB-A ports were USB-C as well.
- paulmd 3y ago
  MST has been a dead letter since day 1 because nobody puts a more expensive monitor controller board in a monitor than it actually needs. 4K60 monitor? cool, it gets DP1.2. So MST means dropping to 1440p or 1080p resolution (splitting DP1.2 across two monitors). crappy dell office monitor? it gets DP1.1, so MST means dropping to 720p or 540p. absolutely no company in their right mind is going to haul off and put a DP1.4 in a bottom-shelf monitor or whatever, such that MST actually had extra resolution to play with. So the only places it matters are (a) stocktrader type people who want 8 monitors and don't care about visual quality/running non-native resolution, and (b) office situations and other places where the ability to run a single cable is more important than visual quality. so de-facto nobody has ever cared about MST, and docks fill this use-case much better. Thunderbolt/USB4 doesn't care about what monitor controller board is behind it. It just cares that you have one DP1.4 stream and the dock can allocate that into as many physical ports as the dock physically allows. Have the bandwidth but need more ports? Cool, just daisychain more docks/adapters. (and this does work on m1 pro/max btw - this guy for example did eventually find a dock that worked for him.) https://www.derekseaman.com/2021/11/my-journey-for-dual-displays-with-my-m1-pro-mac.html https://www.derekseaman.com/2021/11/my-journey-for-dual-disp... -- the big gotcha with M1 is really that the base M1 is actually a crossover chip between high-performance tablet/ultraportable laptop and so Apple doesn't want to waste the space for multiple PHYs that won't be used. So it gets 1x HDMI PHY (normally used for the internal screen, on tablets/laptops) and 1x DP PHY for an external monitor. The Pro/Max support 2 and 3 external displays respectively. I do agree this is a major limitation on the "just buy macbook air" approach, although you can use displaylink (video compression+USB+active adapter) or use an ultrawide monitor (it's a fast connection, you just only get 1 of them). In particular the 15" MBA really needed a "Pro" CPU option like the Mac Mini family, because that's actually a very nice ultrabook other than the single display, and I absolutely think the chassis is big enough to handle it for normal "interactive" use-cases (not bulk video processing/etc). And of course the 13" MBP doesn't get one either but lol fuck that thing anyway, let the touch bar/old-style chassis die already please

ribit 3y ago

> the Metal/Vulkan/OpenGL situation is unfortunate and I don't understand Apple's motivation there. I don't think it's hard to understand. Apple wanted an easy to use API that could be extended and updated easily. Vulkan is an extremely complex API that foregoes all and any developer ergonomy to facilitate quick driver development on as many hardware targets as possible. Consequently, Vulkan's design choices are driven by the least common denominator. The goals are just too different. There is at least some evidence that Apple was interested in supporting and shaping Vulkan (they were member of the initial working group), but I suspect that it very quickly became clear that the committee is going into a direction they were not interested in, so they noted out. Still, I don't think it's correct that Apple is opposing any kind of standardisation in this domain, they just want something more aligned with their vision. They have been very active with WebGPU, which is shaping up to be a very nice API, and it has inherited a lot of good design decisions from Metal.

fayalalebrun 3y ago
Indeed Apple has been very active in shaping WebGPU, and that is why we can't use a bytecode representation for shaders. Instead, we have to repeat OpenGL's mistakes and store shaders as strings. WebGPU specifically has to be the lowest common denominator among the APIs it supports. And there are several features very useful in GPGPU's which are supported in Vulkan and CUDA, but cannot be included in WebGPU due to the lack of Metal support. One such example is floating point atomics.
- ribit 3y ago
  I am sure that bytecode representation of shaders will come in a future revision. It’s not a first priority. SPIR-V is a poor choice for portable shaders for reasons outlined by the WebGPU group on multiple occasions. And WebGPU shading language finally goes away with some poor legacy design choices that are still stuck in GLSL and HLSL (such as shader bindings via global variables). Regarding floating point atomics, I think you got it confused? Metal fully supports floating atomics on all recent devices, while in Vulkan it’s an optional extension. According to gpuinfo database only 30% of implementations support float atomics, and only 10% support more advanced operations like min/max. If you are looking for cross-platform float atomics support, Apple is the least of your worries (what they suck at are 64-bit int atomics though).

dwaite 3y ago

> I mean, on one hand, the Metal/Vulkan/OpenGL situation is unfortunate and I don't understand Apple's motivation there. OpenGL is a dead end - while vendors (including Apple) still support their respective GL stacks, there is not really active investment anymore either in those stacks or in the standards. Metal came out years before Vulkan, and Apple has tight integration between the graphics API and their underlying first-party graphics hardware designs. If Apple did have first party support for Vulkan, it would basically be MoltenVK anyway. Apple tends to push anything which isn't a first party framework to be third-party sourced and bundled as much as they can. They likely think MoltenVK as a third party library is the best scenario for Vulkan support.

MattSteelblade 3y ago
"Years" is overstating it a bit; Vulkan's SDK came out a little more than a year and a half after Metal was available on iOS and 8 months after it was available on Macs.
- dwaite 3y ago
  Ahh you're right, I thought it was 2017 for the Vulkan 1.0 release. My understanding is still that Metal was released on iOS months before AMD's Mantle API was accepted as the start of Vulkan work.

rasz 3y ago

>On the other hand I'm sitting here typing on a Mac with nothing but USB-C ports that is connected to half a dozen peripherals and a big ol' monitor over those standard ports using standard protocols. cool, now try two monitors https://www.kensington.com/en-au/news-index---blogs--press-center/docking--connectivity-blog/differences-between-sst-and-mst-modes/ https://www.kensington.com/en-au/news-index---blogs--press-c...

lloeki 3y ago
I have two 4K 60Hz monitors plugged in my work MBP (M1 Pro, or is it Max?) via DP over USB-C (not TB) basically every day. The MagSafe and HDMI ports sit unused, and I wish these were more USB-C ports instead. My personal Mini M1 can't handle two DP over USB-C displays but can handle one DP over USB-C + one USB-C to HDMI. I also wish the two USB-A ports were USB-C as well.
paulmd 3y ago
MST has been a dead letter since day 1 because nobody puts a more expensive monitor controller board in a monitor than it actually needs. 4K60 monitor? cool, it gets DP1.2. So MST means dropping to 1440p or 1080p resolution (splitting DP1.2 across two monitors). crappy dell office monitor? it gets DP1.1, so MST means dropping to 720p or 540p. absolutely no company in their right mind is going to haul off and put a DP1.4 in a bottom-shelf monitor or whatever, such that MST actually had extra resolution to play with. So the only places it matters are (a) stocktrader type people who want 8 monitors and don't care about visual quality/running non-native resolution, and (b) office situations and other places where the ability to run a single cable is more important than visual quality. so de-facto nobody has ever cared about MST, and docks fill this use-case much better. Thunderbolt/USB4 doesn't care about what monitor controller board is behind it. It just cares that you have one DP1.4 stream and the dock can allocate that into as many physical ports as the dock physically allows. Have the bandwidth but need more ports? Cool, just daisychain more docks/adapters. (and this does work on m1 pro/max btw - this guy for example did eventually find a dock that worked for him.) https://www.derekseaman.com/2021/11/my-journey-for-dual-displays-with-my-m1-pro-mac.html https://www.derekseaman.com/2021/11/my-journey-for-dual-disp... -- the big gotcha with M1 is really that the base M1 is actually a crossover chip between high-performance tablet/ultraportable laptop and so Apple doesn't want to waste the space for multiple PHYs that won't be used. So it gets 1x HDMI PHY (normally used for the internal screen, on tablets/laptops) and 1x DP PHY for an external monitor. The Pro/Max support 2 and 3 external displays respectively. I do agree this is a major limitation on the "just buy macbook air" approach, although you can use displaylink (video compression+USB+active adapter) or use an ultrawide monitor (it's a fast connection, you just only get 1 of them). In particular the 15" MBA really needed a "Pro" CPU option like the Mac Mini family, because that's actually a very nice ultrabook other than the single display, and I absolutely think the chassis is big enough to handle it for normal "interactive" use-cases (not bulk video processing/etc). And of course the 13" MBP doesn't get one either but lol fuck that thing anyway, let the touch bar/old-style chassis die already please