background
Vulkan is a “next generation” open graphical display API developed by the Khronos organization. Is a GPU API standard comparable to DirectX12.
Vulkan has evolved from AMD’s Mantle API, and now the Vulkan 1.0 standard has been completed and officially published. Here’s what Vulkan looks like:
The generation of OpenGL | ES will not be abandoned. Will also continue to develop, very likely OpenGL | ES to Vulkan simplified API.
The advantage of Vulkan
Compared with OpenGL | ES Vulkan’s advantage:
1. Simpler display driver layer
Vulkan provides a display driver abstraction layer that directly controls and accesses the underlying GPU. The display driver is just a thin encapsulation of the hardware, which can significantly improve the efficiency and performance of operating GPU hardware. OpenGL’s driver layer has previously hidden a lot of details from developers that are now exposed. Vulkan does not even include an execution-time error checking layer. With the driver layer doing less, there are fewer hidden bugs.
2, support multithreading
Vulkan no longer uses OpenGL’s state machine design, nor does it store global state variables internally. Display resources are entirely managed by the application layer. Including memory management, thread management, multi-thread drawing command generation, render queue submission and so on.
The application program can make full use of CPU’s multi-core and multi-thread computing resources, reduce CPU waiting and delay. The question is. Synchronization between threads is also the responsibility of the application, making it more demanding on the developer.
3. Precompile Shaders
The driver layer does not provide a front-end shader compiler. Only standard portable intermediate representation binaries (SPIR-V) are supported.
This improves the efficiency of Shaders execution and adds flexibility to future coloring languages.
So the current GLSL/HLSL can be directly converted to Spir-V through the tool. Used in Vulkan. This makes it possible to compile using an offline shader.
In addition. Pir-v also supports OpenCL!
4. Cross-platform
Desktop, mobile devices, game consoles, embedded… Just where you need to display it, it seems to work.
This also gives Vulkan an advantage over DirectX12.
Vulkan and multithreading
OpenGL | ES does not support multithreading has been widely criticized. Vulkan was designed with multithreading in mind from the very beginning, so to speak, for multithreading. Command buffering and command scheduling queue are the important parts of Vulkan to support multithreading. Opengl-like context state.
Vulkan’s command buffers are independent, non-interfering units. Supports creation in multiple threads. This allows multiple threads to create different draw commands. A separate thread manages the render command queue, which is uniformly submitted to the GPU for drawing, as seen in the following figure:
Vulkan forms system integration
Vulkan clearly separates the creation of display devices from the creation of forms systems.
The display device simply provides the interface that supports the visual display queue, and the application controls how the drawing results are displayed. For example, before and after display buffers are created and set by the application.
Vulkan provides a standard extension API to support multiform systems. Such as Android, Windows, X and other forms systems.
Vulkan evolution on Android
Android 7.0 added support for Vulkan. Vulkan is a low-overhead, cross-platform API for high-performance 3D graphics. Like OpenGL ES, Vulkan offers a variety of tools for creating high-quality real-time graphics in your applications. Vulkan’s advantages include lower CPU overhead and support for the Spir-V binary intermediate language. System-on-chip (SoC) vendors (such as GPU Independent Hardware Vendor (IHV)) can write Vulkan drivers for Android; Original equipment manufacturers (Oems) simply integrate these drivers for specific devices. For details on how the Vulkan driver interacts with the system, how you should install GPU-specific tools, and Android-specific requirements, see Implementing Vulkan. Application developers can leverage Vulkan to create applications that execute commands on gpus, dramatically reducing overhead. In addition, Vulkan maps more directly to functionality in current graphics hardware, minimizing driver error rates and reducing developer testing time (for example, Vulkan errors take less time to troubleshoot).
Android Vulkan components
Vulkan support includes the following components:
Vulkan validation layer (provided in the Android NDK). This is a set of libraries that developers use during the development of Vulkan applications. The Vulkan runtime library and Vulkan driver provided by the graphics vendor do not contain runtime error checking to keep the Vulkan runtime efficient, but instead use a validation library (only during development) to find errors when the application uses the Vulkan API. The Vulkan validation library is associated with the application during development and performs this error checking. After all API usage issues are identified, the application will no longer need to include these libraries.
Vulkan runtime (provided by Android). This is a native library (libvulkan.so) that provides a new public native API called Vulkan. Most functions are implemented by drivers provided by GPU vendors; The runtime encapsulates the driver, provides API interception (for debugging and other developer tools), and manages the interaction of the driver with platform dependencies such as BufferQueue. Vulkan driver (provided by SoC). Mapping the Vulkan API to hardware-specific GPU commands and interactions with kernel graphics drivers. The components have been modified to support Vulkan. Android 7.0 has modified the following existing graphics components:
**BufferQueue: the **Vulkan runtime interacts with the existing BufferQueue component through the existing ANativeWindow interface. Minor modifications (new enumeration values and new methods) were made to ANativeWindow and BufferQueue without any schema changes.
**Gralloc HAL: ** Adds a new optional interface for knowing if a specified format can be used for a particular producer/consumer combination without actually allocating buffers.
**Vulkan API: ** The Android platform includes an Android-specific implementation of the Vulkan API specification from Khronos Group. Android applications must use the Window System Integration (WSI) extension to output their rendered content.
Use on Fuchsia
Since 2016, Google has had a team of over 100 engineers secretly working on a new system called Fuchsia. The team is very expensive. There are core engineers from Android, iPhone, WebOS, Chrome, Flutter, and so on. It’s worth looking forward to. Fuchsia uses Zircon for its core, the Flutter framework for its UI layer, Escher for its underlying rendering, and Vulkan for its underlying Graphics API.
Google says it will push Vulkan in the coming years. Vulkan is a cross-platform, high-performance, low-cost graphical interface that performs better on mobile devices than OpenGL ES. Vulkan will be a future direction for Android, especially for games like The Honor of Kings Vulkan version.
Android Q
According to XDA, Android Q will start using Vulkan for default UI rendering, and Android UI will move to pure GPU rendering with an order of magnitude increase in smoothness.
