I don't think there is any Rust (or any Rust on the roadmap) in Blender -- they would most likely use MoltenVK on macOS, similar to the path the Qt folks are taking [0].
I think -- and I could be wrong here -- that gfx-rs aims to eventually implement Vulkan on D3D12 in addition to Metal, while MoltenVK only aims to work on Metal.
Technically Windows doesn't support Vulkan at all, but the openness of the win32 platform allowed Khronos to define a "backdoor" interface where the application ignores the Windows graphics stack and instead gets a Vulkan context by talking to the graphics driver directly. The UWP sandbox makes this impossible so you're stuck with the native Direct3D APIs.
Statistically, nobody actually builds real UWP apps, so it is largely an academic point. But if you're out of the sandbox, I fail to see a good reason not to just build a regular old Win32 app the way it has always been done.
If you are on Windows on ARM then there is no option other than UWP apps. Why would anyone buy an ARM laptop if they have to rely on emulation for everything anyway. It's not like the ARM laptops are any cheaper than the intel ones. (they actually have worse specs and cost more)
I don't know about the MoltenVK branding specifically, but Khronos does plan a "Universally portable subset" of Vulkan with tools to target both Metal and D3D12 from one rendering codebase and common SPIR-V shaders.
The project is call Vulkan Portability Initiative:
If I understood correctly, gfx-rs aims to provide an implementation for that initiative. Khronos only announced it in concept, they didn't implement it.
Given that it was already on a very old version, not doing further development counts as "killing it off" in my book. I'm bummed because I did an OpenGL based text renderer in xi-editor, and now have to decide whether to go back to CoreGraphics (assuming they've fixed the performance problems there) or forward with something like this.
In this year’s WWDC I asked the same question one of the GPU software engineers and he claimed that Apple is going to completely remove support for OpenGL in about two years from now.
Regardless, “deprecated” means “no longer maintained”, meaning that if any regressions will appear in the near future, it’s possible no one will fix them, as these issues will not be prioritized.
I'd take that with a grain of salt. Apple likes to threaten removal of technologies they have deprecated as a way to increase adoption of their replacements but rarely if ever go from deprecation to removal so aggressively, at least on the Mac.
They might exclude deprecated APIs from the pre-announced iOS-MacOS portable platform (Marzipan). That is the move that makes them unsuitable for future use.
This also includes UIWebView and other quite popular pieces of the SDK.
A clean cut - good opportunity to shed some weight, actually.
Note that Apple is still committed to supporting WebGL in Safari, so OpenGL ES will at least be supported that way going forward.
So it's arguably not so much "OpenGL is going away" as it is "OpenGL is going to be maintained by the Safari team, and JS will be the only interface to it" :)
Application software doesn't necessarily want to be using low-level stuff like Vulkan just yet:
the reason being is that these low-level APIs with more direct access/control to the hardware don't (currently) provide load-balancing between multiple applications, which all OpenGL implementations (via the drivers) do currently do fairly well. i.e. so you can have two differential applications open which both fairly heavily utilise the graphics card (for drawing, not compute), and both get a fair share (depending on which has focus in some cases depending on driver settings) of the GPU.
For desktop applications where you're multi-tasking with potentially multiple applications using the graphics card this is often quite important.
For games it's obviously less so.
It's definitely a reason we're not jumping on the new low level APIs in the VFX industry currently.
> It's definitely a reason we're not jumping on the new low level APIs in the VFX industry currently.
While the big studios on Linux (people like Pixar) probably don't care about the lower level APIs, the major vendors like Autodesk and SideFX are going to have to if they still want to target macOS.
Possibly, but I bet they'll hold out on OpenGL for ages, and I wouldn't be surprised if push comes to shove that macOS gets dropped for VFX in the future - as a developer who used to work at The Foundry years ago, it causes so much trouble to develop for compared to Linux, and in relation to the number of people who used it I'm not sure it's worth it any more... Quite a few individuals are still using it, but there's been quite an uptick in Linux users in that area, at least where the software allows...
"According to a note posted on Autodesk's support website, while older Alias versions can run on High Sierra or earlier, "no versions of VRED will run on that operating system due to the OpenGL deprecation."
While openGL is not going to stop working on Mojave, it has served as a good excuse for autodesk to stop bothering with the work of developing mac versions and refusing to provide any support or patching of any future issue that might arise on current releases being run on mojave.
Apple is working very hard at killing the mac both because of what they've done to the hardware and what they're doing to their OS for any user that's not some grandma that does nothing outside browsing facebook on a $1500 macbook..
Just to offer a counterpoint (and I'm happy to discuss), Vulkan has much better load-balancing and resource-sharing potential than OpenGL.
Resource Sharing:
--------------------
Vulkan requires the application provide verbose information about the features being used. Vulkan also reports the number and types of heaps, their sizes, and detailed information on the max number of each type of resource the application can allocate.
OpenGL allows the application to just "go for it," allocate resources without bound [1], and the driver will attempt to "make it work." The only way the application knows it has reached a limit is when the driver finally fails with GL_OUT_OF_MEMORY.
When the driver and OS need to move resources around, such as if the GPU's memory is exhausted, Vulkan applications are much easier to manage. A Vulkan application's memory will be clearly structured so that the driver can identify little-used resources and relocate them so that the next application can get the resources it needs.
Load Balancing:
-------------------
Vulkan requires the application to be much more explicit about which queues and devices the application will be using, and even what priority the application places on different loads.
OpenGL again has no such concept. An application can only access OpenGL from a single thread, and OpenGL just lets the application "go for it."
When the driver and OS need to load balance, a Vulkan application is much easier to load balance. Any rendering or compute in Vulkan is explicitly defined with clear fences, transitions and barriers. The OpenGL application's only mode of operation is "why didn't this run faster?" The GPU vendor's OpenGL driver contains hundreds of application-specific tweaks to the OpenGL API to try to accomodate one particular application. The GPU vendor's Vulkan driver has not been around long enough to accumulate much of that bitrot.
In summary, neither API explicitly triggers load-shedding behavior in the application. The Android app lifecycle is a completely different story.
On desktop machines, Vulkan and OpenGL applications are designed with very few constraints. They mostly are expected to be the main or only application running, and expect to run on machines with medium or high-end specs. The OS and driver manage load-sharing and resource-sharing silently behind the scenes. With Vulkan, however, the OS and driver have a much easier time for the reasons discussed above.
I recommend Vulkan strongly for all new development.
Correct me if I'm wrong:
1) this is an effort to provide an abstract graphics API for any OS/CPU instruction set
2) it is rust and therefore usable from rust and C(++).
If so, great news! Maybe we'll one day be free from tyranny of Windows when it comes to gaming. In my ideal world, operating systems should be interchangeable like web browsers and competing to provide the best implementation of an open standard rather than trying to trap developers and users by providing the most enticing proprietary API.
Have there been any previous attempts to do this? Any success?
> Have there been any previous attempts to do this? Any success?
Many over the years, and largely not. Unreal and Unity are probably the closest to successful to date, but they are full-blown game engines, at a higher level of abstraction, rather than just graphics APIs. OpenGl mostly failed as a multi-platform solution, because vendors provide varying levels of compatibility in their drivers, not to mention unholy extension soup, and you still have to deal with all the platform nastiness of everything else besides sending triangles to the GPU.
The extensions are just that. They are essentially proposals or hardware specific items not meant for broad adoption. Those that are get drafted into the proper specs.
And variable driver support is common across all big graphics APIs. If anything, the feature per driver coverage here is better than DX12.
And hardware vendors are and will be very eager to add hardware specific quirks, tons of it.
So there is no point to "abstract graphics API for any OS/CPU instruction set" then, when most of the work - and we are talking about graphics acceleration, where performance is everything - is and increasingly will be handling all of that quirks.
That's not how it works. Most games and apps are just fine with leaving some amount of graphics performance on the table. That's why engines like Unity are so popular: sure, you could always go a bit faster writing your own engine, but in most cases it isn't worth the trouble. Likewise, with graphics APIs, you have to weigh the significant benefits of greater compatibility against the benefits of using vendor-specific extensions. For most apps, the benefits of going wild with extensions are marginal, while the obvious drawbacks are significant.
I think a lot of people have mistaken ideas about how performance sensitive games are. They care about performance, but not so much that it trumps all other considerations. Games really aren't that different from other apps.
> I think a lot of people have mistaken ideas about how performance sensitive games are. They care about performance, but not so much that it trumps all other considerations. Games really aren't that different from other apps.
Beyond that, even where performance is the priority, a generic performance win is usually more interesting unless the IHV is buying the developer time.
It is not going wild with extensions, rather having to deal with extensions for feature X, because everyone does it differently, and when X becomes part of the core, it is just another additional path, as naturally not all GPU drivers do update to the version that has X in the core.
And even then, there are the workarounds to deal with hardware or driver specific bugs.
Meanwhile, vendors work hand-in-hand with sponsored developers to patch their in-driver Direct3D implementation flaws up for specific games before release.
There's always going to be nonsense like this but —so far— there has been very little in Vulkan. Everybody is working towards a shared good, pushing the idea that a common framework that works the same is just less work for everyone.
Raytracing is going to test that because we already have fundamental differences in approach (Nv has a published extension, AMD are pushing a userspace compute library). It'll be interesting to see what emerges at the end.
> it is rust and therefore usable from rust and C(++).
They want to provide C bindings (vulkan.h).
> Have there been any previous attempts to do this? Any success?
MoltenVK translates Vulkan into Metal. Looks like gfx-rs has a potential to break these lock-ins one step further with translating Vulkan into DirectX 12. They should also consider making GNM backend for completeness.
Is there any hardware that supports only DX12 and not Vulkan?
My understanding is the only extant device is the Xbox One, which doesn't support Vulkan not because the hardware lacks the ability or drivers (since its an AMD SoC shared with the PS4 and using GCN 3 tech) but because of politics trying to lock developers into their API over the industry standard.
Trying to fight politics with software rarely ends well, especially with hobbyist software. Microsoft has complete control over their console and are probably willing to take moves to prevent the use of transpilers on their platform in the same vein Apple has.
Both recent Xbox and PlayStation hardware should support Vulkan just fine, so it is dirty political and anti-competitive tactic not to support it there.
But if MS will try banning things like translation layers, they already can get some anti-trust pushback. Apple while being complete lock-in jerks, so far didn't prevent usage of MoltenVK on their systems. Recent incident with using private APIs was resolved, and Apple allowed applications that use MoltenVK back on iOS.
67 comments
[ 3.8 ms ] story [ 135 ms ] thread[0] http://blog.qt.io/blog/2018/05/30/vulkan-for-qt-on-macos/
The Xbox One uses a variant of D3D12 and doesn't support Vulkan at all.
Why is this/how do they enforce that?
The Xbox is hardly a surprise, but then again you're only going to target that for games so it's less of a problem.
Technically Windows doesn't support Vulkan at all, but the openness of the win32 platform allowed Khronos to define a "backdoor" interface where the application ignores the Windows graphics stack and instead gets a Vulkan context by talking to the graphics driver directly. The UWP sandbox makes this impossible so you're stuck with the native Direct3D APIs.
The next Office for Windows 10 being store only is already an indication how things will go from now on.
https://github.com/KhronosGroup/Vulkan-Docs/issues/366
It doesn't exist now though for sure, so for all practical purposes UWP locks developers out of using Vulkan.
The project is call Vulkan Portability Initiative:
https://www.khronos.org/blog/khronos-announces-the-vulkan-po...
Regardless, “deprecated” means “no longer maintained”, meaning that if any regressions will appear in the near future, it’s possible no one will fix them, as these issues will not be prioritized.
This also includes UIWebView and other quite popular pieces of the SDK.
A clean cut - good opportunity to shed some weight, actually.
So it's arguably not so much "OpenGL is going away" as it is "OpenGL is going to be maintained by the Safari team, and JS will be the only interface to it" :)
Most browsers on Windows use DirectX instead and the games consoles also only have their own 3D APIs.
The GL spec doesn't require that the hardware or OS manufacturers are the ones to implement it. :)
the reason being is that these low-level APIs with more direct access/control to the hardware don't (currently) provide load-balancing between multiple applications, which all OpenGL implementations (via the drivers) do currently do fairly well. i.e. so you can have two differential applications open which both fairly heavily utilise the graphics card (for drawing, not compute), and both get a fair share (depending on which has focus in some cases depending on driver settings) of the GPU.
For desktop applications where you're multi-tasking with potentially multiple applications using the graphics card this is often quite important.
For games it's obviously less so.
It's definitely a reason we're not jumping on the new low level APIs in the VFX industry currently.
While the big studios on Linux (people like Pixar) probably don't care about the lower level APIs, the major vendors like Autodesk and SideFX are going to have to if they still want to target macOS.
https://apple.slashdot.org/story/18/07/29/1939212/autodesk-d...
"According to a note posted on Autodesk's support website, while older Alias versions can run on High Sierra or earlier, "no versions of VRED will run on that operating system due to the OpenGL deprecation."
While openGL is not going to stop working on Mojave, it has served as a good excuse for autodesk to stop bothering with the work of developing mac versions and refusing to provide any support or patching of any future issue that might arise on current releases being run on mojave.
Apple is working very hard at killing the mac both because of what they've done to the hardware and what they're doing to their OS for any user that's not some grandma that does nothing outside browsing facebook on a $1500 macbook..
Resource Sharing:
--------------------
Vulkan requires the application provide verbose information about the features being used. Vulkan also reports the number and types of heaps, their sizes, and detailed information on the max number of each type of resource the application can allocate.
OpenGL allows the application to just "go for it," allocate resources without bound [1], and the driver will attempt to "make it work." The only way the application knows it has reached a limit is when the driver finally fails with GL_OUT_OF_MEMORY.
When the driver and OS need to move resources around, such as if the GPU's memory is exhausted, Vulkan applications are much easier to manage. A Vulkan application's memory will be clearly structured so that the driver can identify little-used resources and relocate them so that the next application can get the resources it needs.
Load Balancing:
-------------------
Vulkan requires the application to be much more explicit about which queues and devices the application will be using, and even what priority the application places on different loads.
OpenGL again has no such concept. An application can only access OpenGL from a single thread, and OpenGL just lets the application "go for it."
When the driver and OS need to load balance, a Vulkan application is much easier to load balance. Any rendering or compute in Vulkan is explicitly defined with clear fences, transitions and barriers. The OpenGL application's only mode of operation is "why didn't this run faster?" The GPU vendor's OpenGL driver contains hundreds of application-specific tweaks to the OpenGL API to try to accomodate one particular application. The GPU vendor's Vulkan driver has not been around long enough to accumulate much of that bitrot.
In summary, neither API explicitly triggers load-shedding behavior in the application. The Android app lifecycle is a completely different story.
On desktop machines, Vulkan and OpenGL applications are designed with very few constraints. They mostly are expected to be the main or only application running, and expect to run on machines with medium or high-end specs. The OS and driver manage load-sharing and resource-sharing silently behind the scenes. With Vulkan, however, the OS and driver have a much easier time for the reasons discussed above.
I recommend Vulkan strongly for all new development.
[1] https://stackoverflow.com/questions/6354208/glgentextures-is...
Is there a plan to support GNM backend in gfx-rs?
I'd love to get started on GNM but licensing is tricky, given that gfx-rs is a community project.
If so, great news! Maybe we'll one day be free from tyranny of Windows when it comes to gaming. In my ideal world, operating systems should be interchangeable like web browsers and competing to provide the best implementation of an open standard rather than trying to trap developers and users by providing the most enticing proprietary API.
Have there been any previous attempts to do this? Any success?
Many over the years, and largely not. Unreal and Unity are probably the closest to successful to date, but they are full-blown game engines, at a higher level of abstraction, rather than just graphics APIs. OpenGl mostly failed as a multi-platform solution, because vendors provide varying levels of compatibility in their drivers, not to mention unholy extension soup, and you still have to deal with all the platform nastiness of everything else besides sending triangles to the GPU.
Get ready to play extension and version golf.
http://www.vulkan.gpuinfo.org/listextensions.php
http://www.vulkan.gpuinfo.org/vulkansupport.php
And variable driver support is common across all big graphics APIs. If anything, the feature per driver coverage here is better than DX12.
So there is no point to "abstract graphics API for any OS/CPU instruction set" then, when most of the work - and we are talking about graphics acceleration, where performance is everything - is and increasingly will be handling all of that quirks.
I think a lot of people have mistaken ideas about how performance sensitive games are. They care about performance, but not so much that it trumps all other considerations. Games really aren't that different from other apps.
Beyond that, even where performance is the priority, a generic performance win is usually more interesting unless the IHV is buying the developer time.
And even then, there are the workarounds to deal with hardware or driver specific bugs.
There's always going to be nonsense like this but —so far— there has been very little in Vulkan. Everybody is working towards a shared good, pushing the idea that a common framework that works the same is just less work for everyone.
Raytracing is going to test that because we already have fundamental differences in approach (Nv has a published extension, AMD are pushing a userspace compute library). It'll be interesting to see what emerges at the end.
They want to provide C bindings (vulkan.h).
> Have there been any previous attempts to do this? Any success?
MoltenVK translates Vulkan into Metal. Looks like gfx-rs has a potential to break these lock-ins one step further with translating Vulkan into DirectX 12. They should also consider making GNM backend for completeness.
My understanding is the only extant device is the Xbox One, which doesn't support Vulkan not because the hardware lacks the ability or drivers (since its an AMD SoC shared with the PS4 and using GCN 3 tech) but because of politics trying to lock developers into their API over the industry standard.
Trying to fight politics with software rarely ends well, especially with hobbyist software. Microsoft has complete control over their console and are probably willing to take moves to prevent the use of transpilers on their platform in the same vein Apple has.
But if MS will try banning things like translation layers, they already can get some anti-trust pushback. Apple while being complete lock-in jerks, so far didn't prevent usage of MoltenVK on their systems. Recent incident with using private APIs was resolved, and Apple allowed applications that use MoltenVK back on iOS.
https://www.intel.com/content/www/us/en/support/articles/000...