I use it for a fairly simple task and I often run in to compiler bugs. Const buffers over 64k get truncated on NVidia gpus, using half4 broke the optimizer on some iMac gpus, and sometimes I have to split up functions until the optimizer on some gpu I don’t own stops doing crazy things. I am terrified of writing MSL because of this.
Yeah, to add to that, I've hit bugs in blending where certain blend modes just don't work and silently render transparent black. Also, the Metal debugger crashes most of the time and tells me "file a Radar". I'm likewise dealing with reported segfaults on hardware I don't own. And there are missing features: timer queries, for instance, aren't really supported and you have to hack them up in an unreliable way, useful extensions supported by the hardware like conservative rasterization are unavailable (Vulkan has this problem too), etc.
I suspect things are better on iOS, but Metal has not been a great experience on macOS for me. There's an argument to be made for proprietary APIs if they're better than the alternatives, but not if they're worse...
> Const buffers over 64k get truncated on NVidia gpus
This is an advertised limit in the feature set tables [0] (See "Maximum function memory allocation for a buffer in the constant address space") for non-Apple GPUs (though there are cases where it might work despite the advertised limit). Do you get a warning if you enable API validation (METAL_DEVICE_WRAPPER_TYPE=1)?
While Im not a graphics pipeline dev, Im curious given the foundational nature of these technologies like DirectX, openGL and Metal, besides platform lock in and bug/performance counting, do these technologies provide any lasting benefit outside of the inherent peculiarities of a given OS/graphics card combination?
At what point should this have been built into the OS vs creating a monopolistic os-driver-driven platform. Or as an improvement remove the OS from the picture entirely if possible.
Creating your own graphics pipeline based on OS and graphics card permitted integrations sounds alot like creating a proprietary bitcoin wallet for oneself.
>do these technologies provide any lasting benefit
While there are downsides to having these different targets, there are upsides as well. For instance on any given platform, be it Metal for IOS or DirectX for Windows, the "native" options has usually been the most bug free and best performing option. It helps when you can build something like DirectX and know that this will only run in windows. Making something cross platform like Vulkan is more effort and complexity.
The other benefit is you have different groups exploring this space. While things might have been simpler in some ways if there had only been OpenGL, OpenGL might not have been forced to evolve as much as it did. vulkan might not have happened as soon as it did, etc.
Obviously the statement is about building your application using a cross-platform library like Vulkan or OpenGL versus using a native library like Metal or DirectX. This has nothing to do with Microsoft or Apples vendor locks.
> At what point should this have been built into the OS vs...
Metal is built in to the OS. It’s the name of the macOS API to access GPU capabilities (and potentially other kinds of processing capabilities). Likewise DirectX for Windows.
I realize you’re objecting to the current state of affairs, but I’m not sure exactly how.
> like creating a proprietary bitcoin wallet for oneself.
What's the analogy to creating graphics pipeline for iOS/Linux/Windows? Do you want to create one for what? For numerous GPU chips? You are not forced to develop different softwares for different OS, you are saved by different OSes from developing for many orders of magnitude more hardware...
