Hopefully this will offer some way forward for FOSS software like Blender running on macOS when Apple kill OpenGL off.
[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...