This is not about lazy game/graphics/cad-developers. This is about lazy mac-developers which are not able to support an applied standart (opengl).
Microsoft has their own graphics API (DirectX) and Apple is a bigger company that Microsoft, so why is Apple not allowed their own API?
For sure they can, but both microsoft and apple should support the opengl-standart. I don't take the depracation too seriously but it was a totally wrong sign and now big companies like autodesk stop supporting this plattform. I think this is totally understandable.
This is not about lazy game/graphics/cad-developers. This is about lazy mac-developers which are not able to support an applied standart (opengl).
Microsoft has their own graphics API (DirectX) and Apple is a bigger company that Microsoft, so why is Apple not allowed their own API?
For sure they can, but both microsoft and apple should support the opengl-standart. I don't take the depracation too seriously but it was a totally wrong sign and now big companies like autodesk stop supporting this plattform. I think this is totally understandable.
The main problem is Apple not supporting Vulkan, which is the cross-platform standard intended to replace OpenGL. There's a converter for Vulkan to Metal but Apple can support Vulkan, even if all they do is maintain their own translator to Metal. The good thing about companies developing their own products is they have complete control over the direction they go and can bring the best performance. With Metal at WWDC, they've been talking about how much better the draw calls are vs OpenGL. Vulkan does the same, as does DirectX 12:
It's not great having developers maintain multiple renderer implementations in OpenGL/DX12/Metal/Vulkan. Every OS manufacturer should fully support at least one open cross platform graphics standard just as they do for audio/video/networking etc. OpenGL is too old for modern hardware and can't be fixed according to the people who make it. Vulkan is its replacement and both developers and OS manufacturers should be migrating to it.
Apple is usually the one that deprecates things first and it keeps people moving e.g dropping 32-bit support. But they don't do a good job of migrating people over. When they rightly didn't support Flash on iOS, they didn't provide any tools for HTML5 so people were just left in the dark for about 5 years trying to figure out how to fix that. I don't want to see them just dropping a cross-platform standard and not support the emerging standard. People are having to resort to using 3rd party tools:
It works but it's not 100% like it could be if they supported it natively:
"The Vulkan Working Group at Khronos has analyzed and defined a subset of Vulkan that can be directly mapped to an underlying Metal or DX12 API with very little run-time overhead. Interestingly, only a very small percentage of Vulkan functionality cannot be mapped to Metal at native performance levels.
Additionally, a well-formed Vulkan application will be designed to minimize CPU overhead by batching GPU commands, submitting significant amounts of work to the GPU for each API call. Consequently, adding a thin runtime library between the application and the Metal API will typically have very little [effect] on application performance."
For cross-platform apps using OpenGL just now, using Vulkan plus the 3rd party tools is the best way to go but this doesn't solve the problem with WebGL. Apple has proposed a replacement called WebGPU:
This looks to be getting support from browser developers and interestingly, it requires native support of different APIs:
"The WebGPU API will be present on all six platforms, but creating WebGPUDevice will require the native platform to expose a modern graphics API:
Vulkan on Windows 7/8, Linux, Chrome OS, Android and Android WebView
Metal on Mac
Direct3D 12 on Windows 10"
So maybe Apple intends for this to be the way forward: some manufacturers having their own native APIs with an abstraction layer on top. This setup works, the EA Need for Speed game on iOS uses Metal on iOS and Vulkan on Android:
Once the core renderer is done, which is a very small part of the software, there's little to maintain beyond that. When a company has one core engine built, everything they make afterwards can be built on top of the same core engine. They don't have to keep rebuilding it. The people who make Doom/Wolfenstein have migrated to Vulkan:
There are going to be teething issues as always with major changes but this change needs to happen to allow software to run properly on modern hardware.
Marvin said: It's not great having developers maintain multiple renderer implementations in OpenGL/DX12/Metal/Vulkan. Every OS manufacturer should fully support at least one open cross platform graphics standard just as they do for audio/video/networking etc. OpenGL is too old for modern hardware and can't be fixed according to the people who make it. Vulkan is its replacement and both developers and OS manufacturers should be migrating to it.
Apple is usually the one that deprecates things first and it keeps people moving e.g dropping 32-bit support. But they don't do a good job of migrating people over. When they rightly didn't support Flash on iOS, they didn't provide any tools for HTML5 so people were just left in the dark for about 5 years trying to figure out how to fix that. I don't want to see them just dropping a cross-platform standard and not support the emerging standard.
THIS...
The problem is that as popular as iDevices are, the world of developers.... especially for scientific, 3D, CAD, etc. apps (who see as Apple becoming more obscure), aren't likely going to add Metal to a list of things they need to develop their software to support. At least not in the near-term. Maybe some see this mythical vision of the whole world using iPads, and decide that is indeed the future (but others - like me - are a bit skeptical of that).
But, that's a good point on replacements. Apple killed Flash, but didn't really provide a solution. Or, they are trying to kill ports like the 3.5mm, but have a convoluted, non-well-thought-through replacement (i.e.: wireless, expensive earbuds).
Like you, I don't care if it is OpenGL, but it needs to be something that such developers will get on board with. A great analogy might be the PS3 (from Sony). It was far technologically superior to the other gaming consoles, but few developers really utilized it or got on-board. Sony (with the PS4) had to go more back to a mainstream design, not for technical reasons, but for developer support reasons.
Marvin said: It's not great having developers maintain multiple renderer implementations in OpenGL/DX12/Metal/Vulkan. Every OS manufacturer should fully support at least one open cross platform graphics standard just as they do for audio/video/networking etc. OpenGL is too old for modern hardware and can't be fixed according to the people who make it. Vulkan is its replacement and both developers and OS manufacturers should be migrating to it.
Apple is usually the one that deprecates things first and it keeps people moving e.g dropping 32-bit support. But they don't do a good job of migrating people over. When they rightly didn't support Flash on iOS, they didn't provide any tools for HTML5 so people were just left in the dark for about 5 years trying to figure out how to fix that. I don't want to see them just dropping a cross-platform standard and not support the emerging standard.
The problem is that as popular as iDevices are, the world of developers.... especially for scientific, 3D, CAD, etc. apps (who see as Apple becoming more obscure), aren't likely going to add Metal to a list of things they need to develop their software to support.
What's strange with Autodesk is they were on the list for supporting Metal in 2015:
Maybe they changed their minds now that Vulkan has developed further or will only support it in bigger apps like Maya. Vulkan is a relatively new API so might not have been suitable for Apple when they decided to make their own API. There's a few games with Metal support:
The APIs are all trying to do the same thing and have a lot of overlapping functionality. It would be a better setup if they'd all (including Microsoft) use the same core that covers the overlap and then add their own functionality where they want. Perhaps OpenGL 5 (maybe best branded as Vulkan Core/Common or something) could be that overlapping API and can be used as the web API. This is like how the web APIs work where browsers have a common set of support and then they can add custom features that may or may not eventually migrate into the core.
As to whether developers will support Metal, Apple has a userbase of over 1 billion people and Macs over 100 million so it's not like it was 20 years ago when a few million users could be ignored. But I think developers will take the path of least resistance and for cross-platform developers that will be Vulkan plus a porting solution because it means avoiding manually maintaining multiple shaders ( https://moltengl.com/moltengl/ ).
The biggest concern is what happens to software where it's not feasible for the developers to rewrite their rendering engine, all the smaller hardware-acelerated utilities and apps for image editing and browsing,which applies to both Metal and Vulkan. A few thousand lines of code is pretty small for big developers who maintain hundreds of thousands to millions of lines but is a large effort for sole developers and open source developers. This is where the issue with tools and support comes in. There should be official resources for how to port OpenGL software to the newer APIs and porting tools where possible.
Marking OpenGL as deprecated is a reasonable move to make, its developers have said it's not a suitable API for modern hardware (7:25):
Apple only had the options to support Vulkan or make their own API. The motivation to make their own API might have been to do with integration with Swift. Vulkan is a C++ API so would probably have required some Objective-C to link with the API. Metal can be called directly from Swift. We'll see how it plays out but at the very least it would be nice to see more interest from software developers in adopting Vulkan, especially regarding 3D creation software. The draw call improvements should help with sculpting apps. These apps are so far behind in supporting the modern APIs because they prioritize compatibility. Apple should make it clear if this should change by stating a timeline for when or if OpenGL driver support will be removed like with 32-bit or if they are merely treating OpenGL as a legacy API. If the runtime won't be removed then companies don't need to worry about older software.
Marvin said: What's strange with Autodesk is they were on the list for supporting Metal in 2015:
Maybe they changed their minds now that Vulkan has developed further or will only support it in bigger apps like Maya. ... As to whether developers will support Metal, Apple has a userbase of over 1 billion people and Macs over 100 million so it's not like it was 20 years ago when a few million users could be ignored. But I think developers will take the path of least resistance and for cross-platform developers that will be Vulkan plus a porting solution because it means avoiding manually maintaining multiple shaders ( https://moltengl.com/moltengl/ ).
The biggest concern is what happens to software where it's not feasible for the developers to rewrite their rendering engine, all the smaller hardware-acelerated utilities and apps for image editing and browsing,which applies to both Metal and Vulkan. A few thousand lines of code is pretty small for big developers who maintain hundreds of thousands to millions of lines but is a large effort for sole developers and open source developers. This is where the issue with tools and support comes in. ...
Yeah, Autodesk now has such a broad collection of software, that it is a bit hard to say what support means... 1 app? Their whole collection? Some utility, or big apps like AutoCAD or Maya (it's still hard for me to believe Maya is an Autodesk app).
And, yes, it's a different situation with a lot more Mac users... but I wonder about when it comes to professional 3D, CAD, analysis, etc. software what the ratio is. What percentage of that kind of stuff is being done on Macs, or would be if they did the port?
My impression is that aside from a few big packages, a lot of the 3D and CAD world are done by solo or very small teams (3 or 4 people). Having to do such a re-write is a pretty big deal. I just fear how many apps will be lost.
I can't recall if it has been answered in this thread or not (or just went over my head, if it was)... but, is there any difference between something like Vulkan and Metal when it comes to how robust it is for things like 3D rendering vs games (i.e.: most games optimize low-polygon scenes, whereas 3D rendering often runs a lot more polygons, or stuff like that). I'm assuming something targeted at gaming might not necessarily be as good for high-end 3D apps. (And, if so, then is Metal aimed more at gaming? It seems Vulkan is aimed at the 3D apps.)
I can't recall if it has been answered in this thread or not (or just went over my head, if it was)... but, is there any difference between something like Vulkan and Metal when it comes to how robust it is for things like 3D rendering vs games (i.e.: most games optimize low-polygon scenes, whereas 3D rendering often runs a lot more polygons, or stuff like that). I'm assuming something targeted at gaming might not necessarily be as good for high-end 3D apps. (And, if so, then is Metal aimed more at gaming? It seems Vulkan is aimed at the 3D apps.)
The APIs are all just ways to more directly control the hardware to get the best performance by removing the overhead from the abstraction layer. This however means more work in some APIs because the developers now have to manage the memory. Managing memory comes with upsides like being able to duplicate things without using more memory or flushing items based on viewports without the system making the decision about what's important but it makes it less accessible to people who just want to focus on their software. Metal, Vulkan and DX12 don't have different priorities from each other, they are all intended to be close-to-metal APIs that let developers build whatever graphics apps they want and they support most of the same features:
If there could be a cross-platform version of that, which spoke to the relevant API on each platform, that would cover the needs of most developers. Few people want to deal with memory management and sorting out crashes with that because it means developers reinventing the wheel and wasting time solving problems that they shouldn't even have to think about. For most uses, it would be enough to be able to setup a 3D scene, drop in some geometry/textures and GLSL shaders and lights with a few lines of code, not thousands and have this API manage the memory and this is what would be used on the web to replace WebGL.
>If there could be a cross-platform version of >that, which spoke to the relevant API on each >platform, that would cover the needs of most >developers.
There exists such projects. Have a look at inventor-based scene libraries. Coin3d is open-sorce and cross Plattform, osg is another alternative. But both are based on OpenGL. With the deprecation of OpenGL Mac will also stall the development of these libraries. Reinventing the wheel is for sure also possible... But going Cross-Plattform and using open standards is the intelligent way. Removing OpenGL support is maybe an idealistic idea. But idealistic in a very local and stupid sense.
>If there could be a cross-platform version of >that, which spoke to the relevant API on each >platform, that would cover the needs of most >developers.
There exists such projects. Have a look at inventor-based scene libraries. Coin3d is open-sorce and cross Plattform, osg is another alternative. But both are based on OpenGL. With the deprecation of OpenGL Mac will also stall the development of these libraries. Reinventing the wheel is for sure also possible... But going Cross-Plattform and using open standards is the intelligent way. Removing OpenGL support is maybe an idealistic idea. But idealistic in a very local and stupid sense.
The people who make OpenGL will transition away from it to Vulkan and I doubt OpenGL will be heavily developed going forward. It looks like the people who make Open Scene Graph are making a Vulkan version, aiming for release sometime next year:
Apple is deprecating OpenGL just now, not removing it. Apple deprecated the Carbon APIs from the old OS and it took until the OS after High Sierra (17 years) before apps based on Carbon are being compromised. They haven't given a timeline or even a suggestion of removal of OpenGL and if it won't be for a while, it would be nice of them to say so, so that developers don't just have knee-jerk reactions and start dropping Mac support.
People should be adopting the emerging open standard, not sticking with the old one. Apple doesn't need to stick with OpenGL but some reassurance goes a long way and that can be achieved by giving an indication of when/if OpenGL is planned for removal and perhaps they can maintain an official API mapping between Vulkan and Metal to make cross-platform development easier.
It would be different if the makers of OpenGL were saying that it was a great API but they're not, they're saying it was broken beyond repair and it was time to start over. The OpenCL deprecation makes even more sense because the APIs are being converged:
"The OpenCL working group has taken the decision to converge its roadmap with Vulkan, and use Vulkan as the basis for the next generation of explicit compute APIs – this also provides the opportunity for the OpenCL roadmap to merge graphics and compute."
Another thing that could be provided is a basic core Vulkan engine, possibly with Vulkan Scene Graph support that gives developers needing a custom engine a few months head start. This would come with a memory manager. Then people who currently have apps with OpenGL engines can checkout that project and pull the parts they need over to the Vulkan one. Just now, every developer is going to have to figure out the engines from scratch again so the migration will take will over a year for each project. Maybe Bethesda/id would be willing to do that. It's a small part of their codebase (5000 lines) and would encourage other game devs to move to it.
Comments
https://www.anandtech.com/show/11223/quick-look-vulkan-3dmark-api-overhead
It's not great having developers maintain multiple renderer implementations in OpenGL/DX12/Metal/Vulkan. Every OS manufacturer should fully support at least one open cross platform graphics standard just as they do for audio/video/networking etc. OpenGL is too old for modern hardware and can't be fixed according to the people who make it. Vulkan is its replacement and both developers and OS manufacturers should be migrating to it.
Apple is usually the one that deprecates things first and it keeps people moving e.g dropping 32-bit support. But they don't do a good job of migrating people over. When they rightly didn't support Flash on iOS, they didn't provide any tools for HTML5 so people were just left in the dark for about 5 years trying to figure out how to fix that. I don't want to see them just dropping a cross-platform standard and not support the emerging standard. People are having to resort to using 3rd party tools:
https://www.computerworld.com/article/3257925/apple-mac/interview-khronos-brings-vulkan-applications-to-macs-iphones-ipads.html
It works but it's not 100% like it could be if they supported it natively:
"The Vulkan Working Group at Khronos has analyzed and defined a subset of Vulkan that can be directly mapped to an underlying Metal or DX12 API with very little run-time overhead. Interestingly, only a very small percentage of Vulkan functionality cannot be mapped to Metal at native performance levels.
Additionally, a well-formed Vulkan application will be designed to minimize CPU overhead by batching GPU commands, submitting significant amounts of work to the GPU for each API call. Consequently, adding a thin runtime library between the application and the Metal API will typically have very little [effect] on application performance."
For cross-platform apps using OpenGL just now, using Vulkan plus the 3rd party tools is the best way to go but this doesn't solve the problem with WebGL. Apple has proposed a replacement called WebGPU:
https://webkit.org/wp-content/uploads/webgpu-api-proposal.html
https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/dxqWTSvyhDg
This looks to be getting support from browser developers and interestingly, it requires native support of different APIs:
"The WebGPU API will be present on all six platforms, but creating WebGPUDevice will require the native platform to expose a modern graphics API:
So maybe Apple intends for this to be the way forward: some manufacturers having their own native APIs with an abstraction layer on top. This setup works, the EA Need for Speed game on iOS uses Metal on iOS and Vulkan on Android:Vulkan on Windows 7/8, Linux, Chrome OS, Android and Android WebView
Metal on Mac
Direct3D 12 on Windows 10"
Once the core renderer is done, which is a very small part of the software, there's little to maintain beyond that. When a company has one core engine built, everything they make afterwards can be built on top of the same core engine. They don't have to keep rebuilding it. The people who make Doom/Wolfenstein have migrated to Vulkan:
https://steamcommunity.com/app/612880/discussions/0/1479856439034259462/
There are going to be teething issues as always with major changes but this change needs to happen to allow software to run properly on modern hardware.
The problem is that as popular as iDevices are, the world of developers.... especially for scientific, 3D, CAD, etc. apps (who see as Apple becoming more obscure), aren't likely going to add Metal to a list of things they need to develop their software to support. At least not in the near-term. Maybe some see this mythical vision of the whole world using iPads, and decide that is indeed the future (but others - like me - are a bit skeptical of that).
But, that's a good point on replacements. Apple killed Flash, but didn't really provide a solution. Or, they are trying to kill ports like the 3.5mm, but have a convoluted, non-well-thought-through replacement (i.e.: wireless, expensive earbuds).
Like you, I don't care if it is OpenGL, but it needs to be something that such developers will get on board with. A great analogy might be the PS3 (from Sony). It was far technologically superior to the other gaming consoles, but few developers really utilized it or got on-board. Sony (with the PS4) had to go more back to a mainstream design, not for technical reasons, but for developer support reasons.
Maybe they changed their minds now that Vulkan has developed further or will only support it in bigger apps like Maya. Vulkan is a relatively new API so might not have been suitable for Apple when they decided to make their own API. There's a few games with Metal support:
https://en.wikipedia.org/wiki/Metal_(API)
There's a Vulkan subgroup to handle compatibility between different APIs:
https://www.khronos.org/blog/khronos-announces-the-vulkan-portability-initiative
The APIs are all trying to do the same thing and have a lot of overlapping functionality. It would be a better setup if they'd all (including Microsoft) use the same core that covers the overlap and then add their own functionality where they want. Perhaps OpenGL 5 (maybe best branded as Vulkan Core/Common or something) could be that overlapping API and can be used as the web API. This is like how the web APIs work where browsers have a common set of support and then they can add custom features that may or may not eventually migrate into the core.
As to whether developers will support Metal, Apple has a userbase of over 1 billion people and Macs over 100 million so it's not like it was 20 years ago when a few million users could be ignored. But I think developers will take the path of least resistance and for cross-platform developers that will be Vulkan plus a porting solution because it means avoiding manually maintaining multiple shaders ( https://moltengl.com/moltengl/ ).
The biggest concern is what happens to software where it's not feasible for the developers to rewrite their rendering engine, all the smaller hardware-acelerated utilities and apps for image editing and browsing,which applies to both Metal and Vulkan. A few thousand lines of code is pretty small for big developers who maintain hundreds of thousands to millions of lines but is a large effort for sole developers and open source developers. This is where the issue with tools and support comes in. There should be official resources for how to port OpenGL software to the newer APIs and porting tools where possible.
Marking OpenGL as deprecated is a reasonable move to make, its developers have said it's not a suitable API for modern hardware (7:25):
Apple only had the options to support Vulkan or make their own API. The motivation to make their own API might have been to do with integration with Swift. Vulkan is a C++ API so would probably have required some Objective-C to link with the API. Metal can be called directly from Swift. We'll see how it plays out but at the very least it would be nice to see more interest from software developers in adopting Vulkan, especially regarding 3D creation software. The draw call improvements should help with sculpting apps. These apps are so far behind in supporting the modern APIs because they prioritize compatibility. Apple should make it clear if this should change by stating a timeline for when or if OpenGL driver support will be removed like with 32-bit or if they are merely treating OpenGL as a legacy API. If the runtime won't be removed then companies don't need to worry about older software.
And, yes, it's a different situation with a lot more Mac users... but I wonder about when it comes to professional 3D, CAD, analysis, etc. software what the ratio is. What percentage of that kind of stuff is being done on Macs, or would be if they did the port?
My impression is that aside from a few big packages, a lot of the 3D and CAD world are done by solo or very small teams (3 or 4 people). Having to do such a re-write is a pretty big deal. I just fear how many apps will be lost.
I can't recall if it has been answered in this thread or not (or just went over my head, if it was)... but, is there any difference between something like Vulkan and Metal when it comes to how robust it is for things like 3D rendering vs games (i.e.: most games optimize low-polygon scenes, whereas 3D rendering often runs a lot more polygons, or stuff like that). I'm assuming something targeted at gaming might not necessarily be as good for high-end 3D apps. (And, if so, then is Metal aimed more at gaming? It seems Vulkan is aimed at the 3D apps.)
https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf
The vast majority of graphics developers won't want to go this low-level. The best thing for most developers would be something like SceneKit:
https://developer.apple.com/documentation/scenekit
If there could be a cross-platform version of that, which spoke to the relevant API on each platform, that would cover the needs of most developers. Few people want to deal with memory management and sorting out crashes with that because it means developers reinventing the wheel and wasting time solving problems that they shouldn't even have to think about. For most uses, it would be enough to be able to setup a 3D scene, drop in some geometry/textures and GLSL shaders and lights with a few lines of code, not thousands and have this API manage the memory and this is what would be used on the web to replace WebGL.
There exists such projects. Have a look at inventor-based scene libraries. Coin3d is open-sorce and cross Plattform, osg is another alternative. But both are based on OpenGL. With the deprecation of OpenGL Mac will also stall the development of these libraries. Reinventing the wheel is for sure also possible... But going Cross-Plattform and using open standards is the intelligent way. Removing OpenGL support is maybe an idealistic idea. But idealistic in a very local and stupid sense.
https://github.com/openscenegraph/VulkanSceneGraph
Apple is deprecating OpenGL just now, not removing it. Apple deprecated the Carbon APIs from the old OS and it took until the OS after High Sierra (17 years) before apps based on Carbon are being compromised. They haven't given a timeline or even a suggestion of removal of OpenGL and if it won't be for a while, it would be nice of them to say so, so that developers don't just have knee-jerk reactions and start dropping Mac support.
People should be adopting the emerging open standard, not sticking with the old one. Apple doesn't need to stick with OpenGL but some reassurance goes a long way and that can be achieved by giving an indication of when/if OpenGL is planned for removal and perhaps they can maintain an official API mapping between Vulkan and Metal to make cross-platform development easier.
It would be different if the makers of OpenGL were saying that it was a great API but they're not, they're saying it was broken beyond repair and it was time to start over. The OpenCL deprecation makes even more sense because the APIs are being converged:
https://www.pcper.com/reviews/General-Tech/Breaking-OpenCL-Merging-Roadmap-Vulkan
"The OpenCL working group has taken the decision to converge its roadmap with Vulkan, and use Vulkan as the basis for the next generation of explicit compute APIs – this also provides the opportunity for the OpenCL roadmap to merge graphics and compute."
Another thing that could be provided is a basic core Vulkan engine, possibly with Vulkan Scene Graph support that gives developers needing a custom engine a few months head start. This would come with a memory manager. Then people who currently have apps with OpenGL engines can checkout that project and pull the parts they need over to the Vulkan one. Just now, every developer is going to have to figure out the engines from scratch again so the migration will take will over a year for each project. Maybe Bethesda/id would be willing to do that. It's a small part of their codebase (5000 lines) and would encourage other game devs to move to it.