Laminar Research took to their X-Plane developer’s blog to announce their work on an exciting new feature named “Zink” in the new X-Plane 12.04 beta 3.
Sidney Just, a software developer at Laminar Research, states that the new feature, still in beta testing, aims to alleviate numerous long-standing issues for several users. Especially aimed at users with AMD GPUs, it hopes to provide a workaround for plugin flickering, such as EFIS screens that either flicker or are entirely missing. It is also aimed at providing potential improvements in performance by reducing driver overhead.
A screenshot provided by Mr Just showcases the massive improvements in performance, namely, frames per second increase and CPU usage. The FPS when using native Vulkan/OpenGL interop is 50, while when using Zink interop the FPS increases by an impressive 30 FPS to 80 FPS. The difference between Vulkan and Zink in terms of FPS increase and CPU usage decrease is staggering and has very exciting prospects.
Mr Just then goes on to elaborate on how the team got here and what it means for both users and developers. First off, Mr Just states that Zink is actually a graphics driver that is positioned between user plugins and X-Plane itself, translating plugin OpenGL rendering into native Vulkan commands that are executed by the same Vulkan device that X-Plane uses for rendering.
Although X-Plane itself no longer uses OpenGL, it is still very important for plugin development. Back when X-Plane was still OpenGL based and the SDK for plugins was first made, the team at the time felt the best option was to just expose X-Plane OpenGL context directly to plugins. This way, the plugins could handle all their drawing needs themselves, giving them greater control and flexibility. This also made the SDK super simple to use, as the need for fancy drawing routines was eliminated.
When X-Plane was ported over to Vulkan and Metal, an issue arose. Neither Vulkan nor Metal were OpenGL and there are now thousands of plugins that assume X-Plane is still OpenGL based. When OpenGL was killed, thousands of user-created plugins became unsupported, necessitating lengthy updates or simply not working if the creator had lost interest. Hence, in X-Plane 11.50, the team created an OpenGL context and shared some memory from within Vulkan to let plugins continue to draw how they used to previously. X-Plane itself would then take care of all synchronization and resource creation rules behind the scenes so that existing plugins could continue to work.
The issue with Vulkan/OpenGL interop
Vulkan/OpenGL relies entirely on the driver itself to support their workaround properly. But as it turns out, driver support is unreliable, especially for AMD users giving rise to a plethora of issues. A prominent one, flickering or missing rendering, in which plugin rendering is either completely missing or flickers in and out of existence, making it impossible for users to have a seamless experience in-sim.
Another issue that arises is performance, as the OpenGL context would create latency issues, adding almost 10 ms per frame and going as high as 30 ms per frame (33 ms is the time one frame can take at most to reach 30 FPS). Due to driver regressions, the performance-related issues further deteriorated, and despite various bug reports filed, the issues were never fixed. As a result, the team began looking for alternatives as early as version 11.50. One workaround suggested back then was to switch back to OpenGL, even though it meant a huge hit in terms of performance.
Although there are other OpenGL drivers developed by many companies and developers, none of those would work with X-Plane. This is because X-Plane uses a compatibility profile for OpenGL context, resulting in X-Plane and, by extension, plugins relying on OpenGL commands from the 90s. Most modern implementations of OpenGL ignore these commands as they are difficult to implement and do not map to modern hardware easily. Since a lot of plugins use these old features and rely on a fixed function pipeline, Vulkan and Metal were not exposed to developers. Writing Vulkan or Metal renderers requires lengthy testing, is error-prone, and is deeply complicated, which has allowed freelance developers to stay within the fixed function pipeline. This made plugin development much simpler and much more beginner friendly.
What is Zink?
Zink is a Gallium driver that leverages existing OpenGL implementations in Mesa to provide hardware-accelerated OpenGL only if and when a Vulkan driver is available. Implementing OpenGL on top of Vulkan simplifies the graphic stack, reduces the workload for graphic drivers, enables more integration, and supports application porting to Vulkan.
Gallium implements all OpenGL versions and does all of the heavy work so that OpenGL can work. Backends turn the intermediate data that Gallium produces into usable commands for a GPU. One of these backends is Zink, which takes all the Gallium-produced commands and builds Vulkan commands out of them. These commands can then be executed by any Vulkan-capable hardware.
How does it affect users?
Users can download and update to the new 12.04 beta 3 and enable Zink in the graphics options menu. By default, the native OpenGL backend still runs for compatibility reasons, but in the future, Zink will be used exclusively. Switching to Zink currently means there is a chance a lot of plugins may not work, although extensive testing by the team has been done. The immense number of plugins that exist means that plugins will break, and users are encouraged to file bug reports, switch back to OpenGL, and try again later.
As Zink is open source, the team is building the graphics driver for the application themselves. This will allow them to get a better look at what happens behind the scenes when issues arise and help the team track and solve them much more easily.
How does it affect developers?
As a developer, the team encourages you to thoroughly test plugins, file bug reports to the team, and to just be patient. Mr Just does emphasize other things to be aware of. Firstly, X-Plane will now allow debugging with GL context enabled. If X-Plane is run with –debug_gl, X-Plane creates a debug GL context and issues the necessary callbacks by itself. Shipping plugins with handlers enabled is discouraged, as other developers may not be able to set their own callbacks since there can only be one. If you want to test Zink as part of a CI solution, you can run X-Plane with –zink or –no_zink through the command line; it will override the graphics settings.
Since Zink is built on top of Vulkan, these features are only available to users on Windows and Linux; macOS and Metal are not applicable. In the long term, running Zink on macOS is also being considered but instead of on top of Vulkan, it will run on top of Metal. Although there are advantages and there are plans within the team to implement running plugins on top of Zink on top of MoltenVK on top of Metal, no code has currently been written or implemented.
This update given by Mr Just is an exciting one and has many wonderful prospects for both developers and users alike, but a complete implementation of this feature is a long way off. Mr Just’s insightful and detailed blog post can be found here, on X-Plane’s developer blog site.
