Metal vs OpenCL/OpenGL

Nvidia supports CUDA AND other standards. Apple supports only Metal. If Microsoft came out tomorrow and said they’d be the sole arbiter of GPU drivers from now on and that developers would be forced to use DX12, they’d be crucified, and rightly so. Apple should be taken to task for their horrible decisions when they make them. Instead, people just can’t wait to lick those boots.

6 Likes

Vulkan is optimized for whatever you optimize it for. That’s basically the whole point of Vulkan: more power, steeper learning curve.

They do make their own hardware on mobile, which is where they started out with Metal. That’s also where some of the limitations come from, e.g. they never added geometry shaders or “classic” tesselation.

I’m pretty sure having their own hardware is their long-term strategy for Mac OS as well. X86 emulation on ARM is possible, just like PPC emulation was possible on X86, just like 68k emulation was possible on PPC.

They are already testing the waters with how much they can bother developers with notarizing and the new security mechanisms in Catalina.

1 Like

id Tech 5/6 using OpenGL/Vulkan exclusively on PC was a very bold undertaking, to say the least. They paid for it with a botched RAGE launch, because the drivers weren’t ready.

You really need to coordinate perfectly with hardware vendors, but if you’re not developing a major title like DOOM, you don’t get to do that.

As for “practically every major game engine” supporting Vulkan: Yes, but there’s only two such engines and they support lots of other (console-specific) APIs as well. That’s a huge effort in and of itself and Vulkan isn’t top priority.

1 Like

Okay. I guess I have to be more specific. I can count DCC applications that use Vulkan on one hand and have fingers to spare. Considering the conversation was about Blender I thought that was implied. I know the two major engines support Vulkan that’s not a surprise. They support Metal as well.

But that doesn’t negate that fact that you are advocating for one proprietary api over another. It doesn’t matter what Apple does or doesn’t support. CUDA is a proprietary api made to lock you into Nvidia’s hardware, period.

So I find it ironic that people here are talking about licking Apple’s boots but are willing to lick Nvidia’s balls because it’s more convenient to them. At the end of the day if you have an issue with Apple don’t buy their stuff. It’s really that simple.

I just find it hilarious that the only reason people complain about Nvidia support on macOS is because they can’t run apps that use a proprietary api. There is a cognitive disconnect there.

First of all, no one forces you to use CUDA on Nvidia’s hardware, that’s a decision left to technical leads and project managers after doing a cost-benefit analysis. Many decide that requiring Nvidia hardware is worth the added value that CUDA brings to the table, but plenty of developers have been successful using OpenCL and other GPGPU APIs across all supported hardware options including Nvidia’s, but even in situations where that’s not the case, it’s not Nvidia’s fault that they created a better option than the open standard. It’s literally their job to create tools that best benefit their customers. But it’s ALSO their job to allow people to use whatever compatible option they think is best for their goals.

Second, I’m not advocating for a proprietary API at all, Apple is. I’m doing the opposite and advocating that that decision should be up to the development team of a given product, not the OS or hardware vendor. Apple’s slavish adherence to their “walled garden” philosophy is so anti-open source, anti-consumer, and anti-developer that I’m shocked that anyone, especially here, would support it. Forcing developers to use special hardware, languages, APIs, and even to pay for the right to develop for a platform is a disgusting practice. The greed and hubris at Apple are absolutely nuts, even amongst other US megacorps. Luckily for them, they’ve fostered this cult of personality that will look at ridiculous development practices and dated hardware and still salivate at the thought of getting their fix.

6 Likes

Fair enough, and when apple makes that jump on their desktop hardware there will be a fairer comparison to Nvidia.

As it stands now, they are licensing hardware that is fully capable of supporting an open api, then locking that down. Kinda leaves a bad taste in users mouths.

This x1000. If ms did anything like this, how many users would be super stoked that blender now needed to rebuild it’s engine to support an arbitrarily enforced API, regardless of quality.

3 Likes

From the sound of things, though, people are upset because the Blender development team has basically followed this advice you’ve given. There’s an issue with writing to an API that is only available for a single operating system. Apple has chosen to withdraw support because Blender developers prioritize a cross-platform approach.

6 Likes

Only if you want to make some sort of ideological argument there. From a practical standpoint, CUDA is a very important API for GPGPU, especially concerning graphics and machine learning. NVIDIA earned that position.

Apple on the other hand just goes out and says:

“Here’s our new API for our little niche operating system, you will be using it from now on if you want our business”.

That’s fine, but if you want to be a diva, you better sing really well, and I just don’t hear it.

Of course there’s lots of Mac-exclusive developers that are doing just fine in the Apple niche. They can take the time to really take advantage of its APIs. That’s not Blender though.

4 Likes

Considering adoption of Metal vs Vulkan, maybe you are not listening hard enough. Apple is very good at getting developers to use their apis. All the teeth gnashing and complaining doesn’t really change that. They’ve done it countless times before with the same exact complaints from developer until they realize that despite being a “little niche OS” they also happen to have the users who are willing to spend the most money and they end up toeing the line in the end. Especially in the DCC market where Mac still have huge market share.

Apple is good at getting developers to use their apis because they leave the developers no other option. Not because their API is so much better than anything else.

Cuda is dominant in the GPGPU scene because it is a very good API. It performs well and is pretty stable. Just look at the day 0 cycles cuda compatibility. Cuda always worked with cycles. It took years for OpenCL to reach parity with Cuda.

Metal is dominant in the apple walled garden because nothing else is allowed on iOS and soon on MacOS as well, and as some of the benchmarks posted earlier indicate, it doesn’t even perform that much better than other API. The only reason to pursue metal is to bow down and kiss the king’s boots.

2 Likes

Niche - do you know how many iPhones Apple sells each year?

Let me know when Blender is running on an iPhone/iPad so I can say you have a point. After all these years of iOS dominance in mobile and Tablet markets is it not surprising that there are so very few true desktop level applications on the platform?

MacOS is a niche OS for many applications and Apple’s dictatorial behaviour has only made it more niche. I saw an exodus of C4D users from the Mac over the last few years because of the ongoing nVidia issue. The nVidia issue would’ve been a non event if Apple had fixed their own OpenCL bugs but they lost interest pretty quickly after making it open source and everything went into Metal. Developers can’t keep up with Apple’s manoeuvres and when only a small percentage of users are Mac users it means developers being pushed into making difficult decisions.

I am one of those who left the Mac for a PC because of the lack of new Mac Pro hardware and more freedom on the PC side, I can’t see me returning any time soon.

1 Like

Are they really? Why did it take them well over a decade to discontinue Carbon? Why did Catalina just break so many apps, including Adobe apps? Why did OpenCL fail so hard? Why are there things like MoltenVK, designed to allow developers to not use Apple’s API?

Apple doesn’t have a huge market share in the 3D DCC space, many apps have never been ported to Mac OS, few apps have adopted Metal so far, and at least one app has been discontinued because of OpenGL deprecation.

Granted, it may still make sense to support Metal from a business standpoint, but it’s not a no-brainer.

The context here is Mac OS and serious applications. iOS is a platform for games and toy applications, where users bring out the pitchforks if you dare charge more than five dollars.

I don’t know what the reasoning behind Apple’s boycott of open standards is, but I do know it’s to the users’ detriment.

As for 3D work, it seems Apple is becoming more and more irrelevant.

Adobe always has issues because Adobe doesn’t care. So that’s a bit of a bad argument. Carbon was deprecated for some time just like OpenGL is deprecated now. Apple gives developers time to move to the new stuff, but when the hammer comes down they gave fair warning. The issue in Catalina lies squarely on Adobe’s shoulders since there have been warnings from the OS even in Mojave letting users know that that app was not macOS compatible and could possibly break.

Apple donated OpenCL to the Khronos group and they did nothing with it because there were industry interests that got in the way (namely Nvidia). AMD, Intel, Nvidia all had broken OpenCL drivers and the Khronos Group is too slow to react or correct those types of issues. That’s probably why Metal exists in the first place. Apple does not want to be beholden to a slow standards group with special interest getting in the way of what they feel they need to do.

Here is my thing. MoltenGL exists. Just like MoltenVK it’s a translation layer of sorts from OpenGL ES2 to Metal. Why is no one talking about it? Why aren’t DCC app developers lining up to use it? Valve’s interest in MoltenVK is games not 3D DCC apps so they paid and opened sourced MoltenVK. Why isn’t Autodesk, SideFX, Maxon etc doing the same for MoltenGL?

If Adobe doesn’t care, how important can Mac OS really be as a DCC platform?

Yes, if it took that long, how can Apple be that successful at making developers adopt their APIs?

Of course, continuing to ship an inferior Mac OS version on outdated OpenGL is an option for the foreseeable future, for Blender and other apps.

If Apple breaks working software with an OS update, that’s Apple’s fault. No software vendor can be expected to arbitrarily support that, and often they don’t, because the costs don’t outweigh the benefits. That’s why you want a stable operating system, so your software keeps running.

Again, if Apple really is that great at making people use their APIs, why didn’t they in this case? Why didn’t those vendors make sure good drivers were available, why didn’t they prioritize for this amazing Apple technology?

The answer is: Apple isn’t that good at making developers do as they wish. Neither Mac OS nor iOS are highly lucrative platforms to develop serious software for, besides a few niches.

MoltenGL only does OpenGL ES2, which is even more limited than native Mac OS OpenGL, though perhaps less buggy. Until Apple truly drops support for OpenGL, that’s not a preferable solution for existing and working code.

Also, implementing full-fledged OpenGL on top of Metal is not going to be feasible, it would have to be some sort of weird subset. Similar limitations exists for Vulkan/MoltenVK, but that’s something you can take into account when writing a new Vulkan backend.

1 Like

People put far too much hope into MoltenVK, go and read the fine print and you’ll find that it’s nowhere near 1:1 with Vulkan in features and there are serious questions over its performance. Any shader that isn’t compiled has to be interpreted into Metal so it’ll be slower than a comparable PC running on native Vulkan drivers. How slow will depend on the complexity of the shader.

I look at the Prorender Hybrid render modes and the work the Godot engine is doing with Vulkan and I want that running as fast and as natively as possible not through some software bridge.

I think this a misunderstanding. Shaders need to be translated from Vulkan’s IR (SPIR-V) to Metal’s Shading Language. This translation step doesn’t necessarily have any runtime overhead, though some optimizations might be “lost in translation”. I’m not aware of anything requiring an interpreter for compatibility here, though.

This approach of translating between shading languages is pretty much what every major game engine does. UE4 or Unity use HLSL (Direct3D) for all platforms, for instance. There’s usually an option to write native shading language code, MoltenVK provides that option as well.

Optimizing shaders any further isn’t necessarily feasible from a production standpoint, because it’s very hardware specific, but also because many of your shaders will be autogenerated from artist-provided shader networks.

You can hope that after your game shipped, AMD/NVIDIA will patch the shaders in the driver for peak performance on their hardware. That’s how you get better performance on Windows.

In any event, DCC apps like Blender will never be in the same ballpark of performance optimization as a game.