For example, Metal compute shaders are C++14 and Khronos only adopted C++ in OpenCL after the beating they took from CUDA, which supported it since the beginning.

Well, some people refuse to use non-platform-native lowest-common-denominator libs, so there's that too...

Apple/Google/Microsoft/Mozilla and others are all participating

https://lists.w3.org/Archives/Public/public-gpu/

And maybe the same informal/external support model for OpenCL?

Performance will be diminished but not extinguished.

Doesn't seem cost-effective at scale to run on beefy Apple machines.

This is sort of like saying "people only do web serving workloads on Linux, we don't need web servers to run on Apple machines" to me.

Sadly, most companies won't have any choice but to port their app to Apple's proprietary APIs. It's really a net loss for consumers because most of these devs have better things to spend their time on than Apple breaking compatibility on a whim.

Pixelmator, at least, is based on Core Image, which Apple has probably already moved from OpenCL to Metal.

Almost all of my (and my lab's) time is spent tinkering with small numerical examples before sending it off to one of the lab machines to run overnight, and using the GPU on the MBP through OpenCL is a huge advantage.

I know this isn't what you're really complaining about, though.

You mean Objective-C++.

The only successful variants of it, actually do constrain devs with either Web or Java corporate frameworks, with a very tiny subset of native code allowed to take part into the whole game.

I also wonder what means for WebGL and its future. Right now, WebGL works in browsers on macOS, Linux, Windows, iOS, Android, which is incredible. There is no equivalent.

Sure, Apple has started working on WebGPU, but that’s not yet ready nor is it guaranteed to gain Linux, Windows, Android support.

https://twitter.com/Plagman2/status/1002324195135520768

https://www.phoronix.com/scan.php?page=news_item&px=Dota-2-I...

So that's pretty promising!

https://en.wikipedia.org/wiki/ANGLE_(software)

It's important to note that NXT isn't necessarily a replacement for ANGLE. It's an experimental replacement for WebGL as a whole, with a different API. There still needs to be a way to run WebGL programs on Mac if this deprecation leads to removal a few versions down the line.

https://lists.w3.org/Archives/Public/public-gpu/

Wow, does this mean Maya, Houdini, and basically every 3D package out there will no longer run on macOS? If so that seriously sucks for 3D pros.

I'm guessing you haven't used apps like Maya, Nuke, or Houdini. They were all written in the mid-90's on IRIX machines and later ported to Linux, Windows, and OSX. Surprisingly, 3d performance isn't always big goal of their's. My guess is the core features don't sell new versions, so even though they have annual releases those things don't get much attention. They'll have drawing issues and transparency sorting problems for years. Same with audio bugs.

Their Mac support was spotty and irregular until the past 5-10 years.

https://mobile.twitter.com/EvilBachus/status/100372239162797... https://mobile.twitter.com/tha_rami/status/10037287912173649... https://mobile.twitter.com/radiatoryang/status/1003732865648...

[1] at least the portion I follow on twitter

Metal and OpenGL two completely different APIs, shading languages and probably a whole host of other things.

I've ported my fair share of things from fixed-function to programmable shader pipelines and you'd be effing naive if you think you can do that in a couple weeks on anything more than a toy demo.

Getting pixels on the screen and shipping something to end users are to very, very different things, 90/10 rule and all that.

Vulkan also has the benefit of multiple platforms supporting it so you're not doing all that work for a minority(which is what OSX is in the graphics space) platform.

I develop an OpenGL-based video engine for a live media playback application, which is very nearly as simple an application of OpenGL as you can expect to find in the real world, and there's no way I could expect to port it to Metal in a week or two singlehandedly. Like others have mentioned, it's a completely different paradigm, not just a matter of changing around some function calls.

That said, I welcome this change with open arms (and secure in the knowledge that legacy code will continue to work for the foreseeable future). OpenGL is a fragmented, brittle, spaghetti-inducing pile of global state. Rewriting in Metal isn't anywhere near as small a project as Apple claims, but I'm perversely looking forward to it -- I'll be very happy to have OpenGL in my rearview mirror.

Make up your fucking minds. Developers aren't hamsters.

I now declare MacOS to be deprecated, if that's how it's going to be.

You could put money on how long this page gets forgotten and left up.

The fact they want to force game developers to use instead Metal is... ridiculous, especially considering the extremely low macos marketshare, particularly outside US.

It's so frustrating to read what the GPU is actually capable of (for example in the intel PRMs) and to know that there is absolutely no way to get the driver's compiler to do the right thing in a reliable way.

I mean imagine if icc was the only x86 compiler.

How ugly would the JAI code to need to be to interface with this?

I wish they had a simple Metal C API, but their new API comes with a bunch of Objective-C baggage.

In Metal the Obj-C abstraction is part of the design and used to eliminate any other abstraction people would want to introduce. The objects you get back from the API are implemented straight in the GPU vendor code, and the debug tools can swap the methods out for extra validation, recording, etc.

If you're worried about refcounting, use ARC (which you have to with Swift anyway). First, the compiler is very smart about optimizing away retain/release/autorelease calls whenever it can. Second, when those calls do have to be made, they're implemented using vtables, and never hit objc_msgSend() in the first place.

The key being that if you've got a technology that works on both server farms for production and workstations for development, you support that so that your OS is a viable candidate for the developer workstation. I don't see a Metal port coming to Linux in any reasonable way any time soon, and I don't see researchers giving up OpenCL or even OpenGL any time soon, so it just means that Apple is going to forego that business.

With the recent github purchase it gives the oddly dissonant experience of having Microsoft being the 'developer friendly' OS company and the MacOS being the 'developer hostile' OS company. Where, and this is important, support for cross platform tools determines hostility or support. I would not argue that Apple is not the best development environment for the Apple platform, or Windows for the Windows platform.

Everything is CUDA. Everything depends on the shitty unstable software designed by a hardware company (Nvidia). This sucks and I hope someone can disrupt it, but Apple has no influence in the field of GPU computing.

And I work in data science and nobody is using their own laptops when you have AWS.

I work in data science too, and who cares about laptops. Desktop computers with GPUs, SSDs, and a lot of RAM are what you need. You can thoroughly bling out the hardware and the entire computer will still cost less than your monthly AWS bill to access a GPU. (This is all getting pretty irrelevant to Apple, though, who doesn't make such computers.)

So I can't imagine this is going to hurt at all.

Edit: and XQuartz (X11) with OpenGL comes in handy once in a while too...

Also, it seems to me that the better option in the long run for legacy game support is to just run a VM for the highest degree of compatibility.

EDIT: As a follower of https://mesamatrix.net/ I don't think it would be unreasonable to say about 3 years to get something that kind of works, five for something semi reasonable, and 8 for something at modern open gl level.

I really hate to see such a focus on a platform lock-in API when viable alternatives(Vulkan) are available.

I can't say I'll be protesting by not buying a new Mac because I'm already devoid of any desire to do so.

A reasonable alternative would be to implement OpenGL on top of Metal for compatibility but this is a lot of work.

edit, ups just read it: Apps built using OpenGL and OpenCL will continue to run in macOS 10.14, but these legacy technologies are deprecated in macOS 10.14. Games and graphics-intensive apps that use OpenGL should now adopt Metal. Similarly, apps that use OpenCL for computational tasks should now adopt Metal and Metal Performance Shaders. [0]

[0]https://developer.apple.com/macos/whats-new/

macOS performance was already getting so poor on 2010/2011 MacBook Airs, so I think this is the right move. I recently downgraded my old 2GB 2010 MacBook Air back to 10.11 El Capitan and it runs much, much better than it did on High Sierra.

If you aren't in Rust, just use Vulkan. There are high-performance wrappers for it in various stages of development, such as MoltenVK[2] for macOS and iOS, and VulkanOnD3D12[3] for UWP. Non-UWP Windows, Linux, and Android should support Vulkan natively through their GPU drivers.

[1]: https://github.com/gfx-rs/gfx

[2]: https://github.com/KhronosGroup/MoltenVK

[3]: https://github.com/Chabloom/VulkanOnD3D12

This was never true for game consoles, regardless of urban myths regarding OpenGL support.

It’s the smaller scale developers and projects that might not have have such ability.

(Not intending to nitpick--just pointing out that Riot is a LOT bigger than many folks realize)

Games made by developers who've gone out of business are probably just going to stop working in a few versions of MacOS.

---

[0]: https://moltengl.com/moltengl/

How does this effect Qt iOS applications?

The low-level graphics APIs like Metal and Vulkan allow for much better performance, but they are much harder to use and require more work from the developer (hence, they’re usually used only by game engine makers). Higher-level graphics APIs like OpenGL are less efficient and have lower peak performance, but are easier to use for individual projects and have the benefit of having existing functional code (no need to rewrite a working project).

Also, OpenGL (and its mobile and web variants OpenGL ES and WebGL) are very portable (macOS, Linux, Windows, iOS, Android, both and native and in browsers), while Metal is macOS/iOS-only.

Maybe I'm biased - every time I looked at OpenGl code I shuddered and ran away to a higher level framework (I'm excluding shader code from this - that's concise enough for me not to mind getting that close to the metal)

Vulkan, you need to know exactly what you are doing. There are little to no handhelding. You are trying to squeeze out every last 10% of performance in exchange for lots more development time. You need to write a hell a lot more code to do something what you previously thought were simple.

OpenGL is higher level that should be compared to Direct3D 10, not 11. As a matter of fact I will go about saying compare to Direct 3D 9. And unless you are a OpenGL zealot, any sane game developers would have told you Direct X 9 already exceed OpenGL in most way.

Metal is offering what most of Vulkan can do and making it even easier then OpenGL.

Honestly I don't get / understand why all the backlash. OpenGL is deprecated, and it simply means Apple won't be updating OpenGL anymore. Stop asking every god damn year. They have been shipping other deprecated library and API for years! OpenGL is developed in such a way that no one really cares. And designed by committees for maximum backward compatibility. And if you want your App on iOS, you will have to use Metal anyway.

That's why I wasn't sure what Metal is offering instead.

A 3D modern API that acknowledges the time of pure C APIs is long gone, with C++14 as shading/compute language, providing math, 3D models, materials, fonts, textures support.

Whereas in OpenGL you are stuck with fishing for libraries, multiple execution paths depending on the extensions and bugs, compiling and linking shaders at runtime without library support, C style APIs and a plethora of deprecated APIs.

When it was introduced, the Core frameworks were updated to use Metal instead, with OpenGL left for backwards compatibility mode.

3.5 mm = 1) there is no way a wireless medium will ever have better throughput than a wired medium over a superb DAC - ever, 2) dongle, 3) extra battery worry now for BT.

OpenGL, I will grant you that one, since both Metal and/or Vulkan are a vast improvement on OpenGL.

I know that some people like to say this, but it's pretty clearly wrong, and it makes you look unobservant when you repeat it. It takes about five seconds and two phones to demonstrate this. The standard top section on every phone, Android and iOS alike, is a dedicated status section with little system icons with wide gaps of unused blank space between them. Every phone, every time. A notched phone just puts the camera directly between those icons instead of putting unused pixels there. It doesn't take a genius to see that un-notched phones have both larger top bezels and more pixels wasted in the status area. The notch doesn't cut into the screen. The screen extends up around the camera and puts the status icons on the horns.

> and is aesthetically displeasing

All of the tens of people I know who have notched phones say they love it and don't notice the notch. So, maybe to you, but it seems like the market is speaking.