Getting started with the Vulkan programming model

Let's discuss the Vulkan programming model in detail. Here, the end user, considering he or she is a total beginner, will be able to understand the following concepts:

• The Vulkan programming model
• The rendering execution model, which will be described using a pseudo step-by-step approach
• How Vulkan works

The following diagram shows a top-down approach of the Vulkan application programming model; we will understand this process in detail and also delve into the sublevel components and their functionalities:

Hardware initialization

When a Vulkan application starts, its very first job is the initialization of the hardware. Here, the application activates the Vulkan drivers by communicating with the loader. The following diagram represents a block diagram of a Loader with its subcomponents:

Loader: A loader is a piece of code used in the application start-up to locate the Vulkan drivers in a system in a unified way across platforms. The following are the responsibilities of a loader:

• Locating drivers: As its primary job, a loader knows where to search for drivers in the given system. It finds the correct driver and loads it.
• Platform-independent: Initializing Vulkan is consistent across all platforms. Unlike OpenGL, where creating a context requires working with a different window system API for each environment, EGL, GLX, and WGL. Platform differences in Vulkan are expressed as extensions.
• Injectable layers: A loader supports a layered architecture and provides the capability to inject various layers at runtime. The big improvement is that the driver need not do any of the work (or retain any of the states it would need to do the work) in determining whether the application's use of the API is valid. Therefore, it's advisable to turn on the selected injectable layers, as per application requirements, during the development stage and turn them off at the deployment stage. For example, injectable layers can offer the following:
  • Tracing the Vulkan API commands
  • Capturing rendered scenes and executing them later
  • Error and validation for debugging purposes

The Vulkan application first performs a handshake with the loader library and initializes the Vulkan implementation driver. The loader library loads Vulkan APIs dynamically. The loader also offers a mechanism that allows the automatic loading of specific layers into all Vulkan applications; this is called an Implicit-Enabled layer.

Once the loader locates the drivers and successfully links with the APIs, the application is responsible for the following:

• Creating a Vulkan instance
• Querying the physical device for the available queues
• Querying extensions and storing them as function pointers, such as WSI or special feature APIs
• Enabling an injectable layer for error checking, debugging, or the validation process

Window presentation surfaces

Once the Vulkan implementation driver is located by the loader, we are good to draw something using the Vulkan APIs. For this, we need an image to perform the drawing task and put it on the presentation window to display it:

Building a presentation image and creating windows are very platform-specific jobs. In OpenGL, windowing is intimately linked; the window system framebuffer is created along with context/device. The big difference from GL here is that context/device creation in Vulkan needn't involve the window system at all; it is managed through Window System Integration (WSI).

WSI contains a set of cross-platform windowing management extensions:

• A unique cross-platform implementation for the majority of platforms, such as Windows, Linux, Android, and other OSes
• A consistent API standard to easily create surfaces and display them without getting into the details

WSI supports multiple windowing systems, such as Wayland, X, and Windows, and it also manages the ownership of images via a swapchain.

WSI provides a swapchain mechanism; this allows the use of multiple images in such a way that, while the window system is displaying one image, the application can prepare the next.

The following screenshot shows the double-buffering swap image process. It contains two images named First Image and Second Image. These images are swapped between Application and Display with the help of WSI:

WSI works as an interface between Display and Application. It makes sure that both images are acquired by Display and Application in a mutually exclusive way. Therefore, when an Application works on First Image, WSI hands over Second Image to Display in order to render its contents. Once the Application finishes the painting First image, it submits it to the WSI and in return acquires Second Image to work with and vice-versa.

At this point, perform the following tasks:

• Create a native window (like the CreateWindow method in the Windows OS)
• Create a WSI surface attached to the window
• Create the swapchain to present to the surface
• Request the drawing images from the created swapchain

Resource setup

Setting up resources means storing data into memory regions. It could be any type of data, for example, vertex attributes, such as position, color, or image type/name. Certainly, the data has resided somewhere in the memory for Vulkan to access it.

Unlike OpenGL, which manages the memory behind the scenes using hints, Vulkan provides full low-level access and control of the memory. Vulkan advertises the various types of available memory on the physical device, providing the application with a fine opportunity to manage these different types of memory explicitly.

Memory heaps can be categorized into two types, based upon their performance:

• Host local: This is a slower type of memory
• Device local: This is a type of memory with high bandwidth; it is faster

Memory heaps can be further divided based upon their memory type configurations:

• Device local: This type of memory is physically attached to the physical device:
  • Visible to the device
  • Not visible to the host
• Device local, host visible: This type of memory is also physically attached to the device:
  • Visible to the device
  • Visible to the host
• Host local, host visible: This refers to the local memory of the host, but it is slower than the local device:
  • Visible to the device
  • Visible to the host

In Vulkan, resources are explicitly taken care of by the application with exclusive control of memory management. The following is the process of resource management:

• Resource objects: For resource setup, an application is responsible for allocating memory for resources; these resources could be either images or buffer objects.
• Allocation and suballocations: When resource objects are created, only logical addresses are associated with them; there is no physical backing available. The application allocates physical memory and binds these logical addresses to it. As allocation is an expensive process, suballocation is an efficient way to manage the memory; it allocates a big chunk of physical memory at once and puts different resource objects into it. Suballocation is the responsibility of an application. The following diagram shows the suballocated object from the big allocated piece of physical memory:

• Sparse memory: For very large image objects, Vulkan fully supports sparse memory with all its features. Sparse memory is a special feature that allows you to store large image resources; which are much larger than the actual memory capacity, in the memory. This technique breaks the image into tiles and loads only those tiles that fit the application logic.
• Staging buffers: The population of the object and image buffers is done using staging, where two different memory regions are used for the physical allocation. The ideal memory placement for a resource may not be visible to the host. In this case, the application must first populate the resource in a staging buffer that is host-visible...