Tag Archives: Vulkan

How-to video: Debugging a non-visible model in Vulkan using RenderDoc

One of the most common Vulkan related that I’m seeing a lot is about rendering stuff that somehow ends up being not visible on the screen, even though technically everything looks okay (no validation layer errors, correct buffer uploads, etc.).

Luckily there are debugging tools tools like RenderDoc that can help locating and fixing such problems. But not everyone knows about such tools or how to use them for debugging these kind of problems.

So I decided to upload a narrated video that shows how to debug non-visible models (in Vulkan) using RenderDoc:

If you’re interested in additional narrated, Vulkan related videos just drop me a line.

Vulkan glTF 2.0 C++ phyiscal based rendering

I have released the first working version of a separate (from the examples) Vulkan physical based rendering example that uses the glTF 2.0 model file format.

The repository can be found at https://github.com/SaschaWillems/Vulkan-glTF-PBR.

glTF is a royalty free format specification by the Khronos Group and is a new format for 3D models gaining lots of traction. With version 2.0 it also added several PBR extensions and definitions.

I decided to make this a stand-alone project instead of “just” another example in my Vulkan C++ example repository to make it easier getting into the code. While lots of people seem to learn from my examples they contain a lot of abstraction, and for this example I wanted the code to be very readable and verbose on purpose so those interested in doing PBR with Vulkan and glTF 2.0 get a closer look at the actual code without that much abstraction as was the case for my examples.

So while it still contains a few base classes from my examples, these have been stripped down (e.g. no more initializers) and the main class is pretty verbose and doesn’t do much Vulkan abstraction. I hope this makes it easier to actually get into the relevant Vulkan parts.

Vulkan Hardware Capability Viewer 1.4 released

A new version of the Vulkan Hardware Capability Viewer is now available for all platforms (Windows, Linux, Android). This is the biggest update since I released this tool, including lots of new features that also brought along a few changes to the online database. I also decided to drop the “beta” tag now that more than 1,300 reports have been uploaded, making this the first non-beta release of the Vulkan Hardware Capability viewer.

New features

  • Added support for new features and properties provided via VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2
    • Currently supported:
      • VK_KHR_push_descriptor
      • VK_EXT_discard_rectangles
      • VK_KHX_multiview
      • VK_NVX_multiview_per_view_attributes
  • Reports can now be saved to disk via command line using the -s argument (without invoking the UI)
    • Example : vulkanCapsViewer -s my_device.json
  • Added pipeline cache UUID
  • Exported JSON is now compatible with vkjson_info from LunarG SDK
  • Added Android platform info
    • Device model and manufacturer
    • Build information
  • UI improvements 
    • Updated layout and UI scaling 
    • Support for high DPI scaling
    • Touch scrolling for mobile devices (Android)


  • Fixed unauthorized access to SSL libraries message on Android 6.0 and newer

Continue reading

Physically based rendering and moving (hdr) assets out of the repository

The last days (and weeks) I’ve been working on a Vulkan example implementing physically based rendering with image based lighting (you can find a nice article with lots of details over at Trent Reed’s blog) and just pushed it to my public github repository.


While working on this demo I realized that putting all the binary assets (models and esp. textures) in the repository might not have been a great idea. They quickly bloat the size of the repository and once a binary asset is there you won’t be able to completely remove it (to shrink the repo again) unless you actually rewrite the history. But with the repository being public with almost 400 forks and numerous pull requests this pretty much a no-go.

Continue reading

Vulkan Hardware Capability Viewer 1.2 released

I have released an update to the Vulkan Hardware Capability Viewer. The new version (1.2) adds support for os-specific surface capabilities that are added to the reports and online database.

This adds a new category to the tool and reports at the online database (for example this one) containing:

  • Surface properties (extents, usage flags, transforms, etc.)
  • Surface Formats (incl. color spaces)
  • Present modes

You can download the new version from http://vulkan.gpuinfo.org/download.php, downloads are available for Windows, Linux and Android (arm and x86).

The Android version (for now arm only) is now also available at the google playstore.

New Vulkan example: Indirect drawing

I have added another example to my open source C++ Vulkan examples. The new one is about indirect drawing (including multi draw if supported). Contrary to their non-direct counterparts, the indirect drawing commands in Vulkan take their draw calls from a buffer that is ideally stored in device local memory. So instead of running single draw commands that get their index base, index count and instancing numbers passed by the host upon getting called, the indirect commands are backed by a buffer that stores an arbitrary number of draw commands.

The example renders a huge number of plants with different geometries only using one single draw call. All plants geometries are stored in one buffer, and each indirect draw command uses different index offsets and also does instancing.


This technique is the based for several GPU-based functions that have traditionally been handled by the CPU. As the draw commands are stored in a buffer that the GPU has access too, it’s now possible to have a compute shader manipulate the draw commands that are issued so the GPU can take on tasks like culling or draw command generation in general.


New Vulkan example: Deferred shading and shadows

Based on the recently updated deferred shading example, I have added a new example to my open source C++ Vulkan samples. This example adds dynamic shadows from multiple light sources, showcasing a few technologies that can be used to make rendering of multiple shadows more efficient. To achieve this, the example uses a layered depth attachment with one layer per light source that is sampled in the final scene composition. Traditionally one would do multiple passes to render the depth maps for the scene's light source, and to avoid this the example also uses shader instancing by doing multiple invocations in the geometry shader. The geometry shader then uses the invocation index to output into the different layers of the depth attachment, with the matrices from the different point-of-views of the light sources getting passed as an array. This is an approach that fits modern GPUs very well and allows for an arbitrary number of shadow casting light sources to be added without the need to add multiple render passes. https://www.youtube.com/watch?v=8rNl4A0qGao