# Human-friendly classification of Vulkan resources

Jun 2018

In graphics programming we deal with different kinds of resources. Their specific types and names depend on graphics API. For example, in Direct3D 9 we have vertex buffers, index buffers, constant buffers, textures etc. OpenGL equivalent of constant buffer is uniform buffer object (UBO).

Vulkan has only two types of resources: buffers and images. This may be the only thing that is simpler in Vulkan than in other APIs :) When creating such resource, we specify usage flags that define how do we intend to use it. For example, VK_BUFFER_USAGE_VERTEX_BUFFER_BIT means that a buffer may be used as vertex buffer. VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT means that an image may be used as color attachment (which is Vulkan name for “render target”).

Such flags may be combined together, so a single buffer can contain data to be used as vertex buffer, index buffer, and uniform buffer. I’m not 100% sure if this is guaranteed by the specification (theoretically some drivers could return disjoint sets of VkMemoryRequirements::memoryTypeBits for different usage flags), but I think that every real implementation allows that. It means we cannot clearly classify buffers and images into categories. Despite that, I decided to develop a human-friendly classification of Vulkan resources into several categories, starting from most “special”, and ending with most “common/generic” ones. I propose following algorithm:

For buffers:
  // Buffer is used as source of data for fixed-function stage of graphics pipeline.
  // It’s indirect, vertex, or index buffer.
    return class0;
  // Buffer is accessed by shaders for load/store/atomic.
  // Aka “UAV”
    return class1;
  // Buffer is accessed by shaders for reading uniform data.
  // Aka “constant buffer”
    return class2;
  // Any other type of buffer.
  // flags are intentionally ignored.
    return class3;

For images:
  // Image is used as depth/stencil “texture/surface”.
    return class0;
  // Image is used as other type of attachment.
  // Aka “render target”
    return class1;
  // Image is accessed by shaders for sampling.
  // Aka “texture”
  else if ((usage & VK_IMAGE_USAGE_SAMPLED_BIT) != 0)
    return class2;
  // Any other type of image.
  // flags are intentionally ignored.
    return class3;

I needed this because I wanted to introduce better coloring to VMA Dump Vis. Vulkan Memory Allocator (VMA) is a C++ library that simplifies GPU memory management in Vulkan applications. VMA Dump Vis is a Python script that can visualize JSON dump from this library on a picture. As I updated the library to remember usage flags of created resources, I wanted to use them to show more information on the picture. To do this, I defined following color scheme:

Example visualization of Vulkan memory in some game:

This color scheme is carefully designed. I based it on following principles:

  1. Brightness: Details too small to be shown as filled rectangles are black. Borders of rectangles representing allocations are dark gray. Fill colors of all allocations must be visually brighter than this.
  2. Saturation: Memory of unknown purpose (small details, free space, allocation of unknown type) is black/gray. Allocations of known type have specific color. Additionally, buffers and images with no special usage flags use more desaturated (brighter) color.
  3. Warm/cool colors: Buffers use warm colors: red, orange, yellow. Images use cool colors: purple, blue etc.
  4. Hue (1): Classes of buffers, from most special to most generic, use colors from red, through orange, to yellow. Classes of images, from most special to most generic, use colors from purple, through violet, to cyan.
  5. Hue (2): Vulkan images with VK_IMAGE_TILING_OPTIMAL should be used wherever possible, so those with VK_IMAGE_TILING_LINEAR are just marked with green. Images of unknown tiling have color between cyan and green.

You can already visualize your Vulkan memory with all these colors if you grab Vulkan Memory Allocator from development branch. I think that this classification of GPU resources and accompanying color scheme could also be useful for other graphics APIs.

Comments | #vulkan #libraries #productions Share

# My upcoming 3 talks

May 2018

I'd like to invite you to my upcoming talks:

Tuesday 15 May at Czestochowa University of Technology, Faculty of Electrical Engineering, I will talk about computer graphics. Topic is: "Grafika komputerowa jako kreatywna dziedzina informatyki".

One week later I will give more advanced talk, in English this time. At Digital Dragons conference in Kraków I will talk about "Porting your engine to Vulkan or DX12". Later that week I will discuss the same subject at Nordic Game conference in Malmö.

Comments | #teaching #events Share

# A MAZE in Berlin - my impressions

May 2018

Last week I've been on A MAZE - an event in Berlin advertsed as "7th International Games and Playful Media Festival". I went there together with a large group of people from Polygon - gamedev interest group from Warsaw University of Technology. I liked it a lot because it's something different from what I've attended before, and I've been on many events, like gamedev conferences (e.g. GDC), demoscene parties (e.g. Revision), gaming expo (e.g. Poznań Game Arena), cybersport events (e.g. World Cyber Games), or events decated to retro computers.

A MAZE could be described as independent games festival. Majority of events took place between Thursday and Saturday. Its main part was game exhibition, where booths with many games were available for visitors to play or talk to their developers. They were indie games, so either very artistic, containing some original gameplay ideas, unusual controller, or somehow politically involved. Contrary to expo at GDC, there were no AAA titles, no big publishers, IHVs or middleware developers. There were some really polished and commercially successful games though, e.g. SUPERHOT.

Second big part of the event were talks happening on two stages. Again, they were very "alternative", often delivered by artists or academics. They either discussed some ideas or artistic vision behind some game, touched politics (of course all from the left side of political scene, e.g. about helping migrants, women, and other minorities), or they were purely fun. There was very little about programming and nothing about advanced rendering technology. Most of indie developers use Unity. I attended one of the workshops about Unity, but it was very basic - speaker explained what is bool, int etc.

Besides, there were concerts every evening with bands or DJs playing, VJs making visualizations, lots of beer and other festival fun :) I recommend attending A MAZE at least once to anyone interested in games or game development, just because it's so different from other events. Plus it happens in Berlin, and I love the atmosphere of this city :)

Comments | #events Share

# Vulkan API - my talk at Warsaw University of Technology

Apr 2018

On Wednesday 16 April, around 8 PM, at Warsaw University of Technology, during weekly meeting of KNTG Polygon, I will give a talk about "Vulkan API" (in Polish). Come if you want to hear about new generation of graphics APIs, see how Vulkan API looks like, what tools are there to support it, what are advantages and disadvantages of using such API and finally decide whethere learning Vulkan is a good idea for you.

Event on Facebook:

Vulkan API.pdf
Vulkan API.pptx

Comments | #graphics #gpu #vulkan #teaching Share

# Memory management in Vulkan and DX12: slides are online

Apr 2018

Slides from my talk at Game Developers Conference (GDC) 2018: "Memory management in Vulkan and DX12" are now available online, as part of materials from Advanced Graphics Techniques Tutorial. Access to this PDF is open to anyone, not behind GDC Vault paywall. I've put some additional information in "backup" slides at the end that I didn't show during my presentation. The slides are designed the way that you can learn from them even without seeing the talk.

Update 2018-05-04: Slides from my talk in PPTX format with additional notes are now available (together with many other GDC 2018 presentations) on page: GDC 2018 Presentations - GPUOpen.

Comments | #events #teaching #gdc #directx #vulkan Share

# Debugging Vulkan driver crash - equivalent of NVIDIA Aftermath

Mar 2018

New generation, explcit graphics APIs (Vulkan and DirectX 12) are more efficient, involve less CPU overhead. Part of it is that they don't check most errors. In old APIs (Direct3D 9, OpenGL) every function call was validated internally, returned success of failure code, while driver crash indicated a bug in driver code. New APIs, on the other hand, rely on developer doing the right thing. Of course some functions still return error code (especially ones that allocate memory or create some resource), but those that record commands into a command buffer just return void. If you do something illegal, you can expect undefined behavior. You can use Validation Layers / Debug Layer to do some checks, but otherwise everything may work fine on some GPUs, you may get incorrect result, or you may experience driver crash or timeout (called "TDR"). Good thing is that (contrary to old Windows XP), crash inside graphics driver doesn't cause "blue screen of death" or machine restart. System just restarts graphics hardware and driver, while your program receives VK_ERROR_DEVICE_LOST code from one of functions like vkQueueSubmit. Unfortunately, you then don't know which specific draw call or other command caused the crash.

NVIDIA proposed solution for that: they created NVIDIA Aftermath library. It lets you (among other things) record commands that write custom "marker" data to a buffer that survives driver crash, so you can later read it and see which command was successfully executed last. Unfortunately, this library works only with NVIDIA graphics cards and only in D3D11 and D3D12.

I was looking for similar solution for Vulkan. When I saw that Vulkan can "import" external memory, I thought that maybe I could use function vkCmdFillBuffer to write immediate value to such buffer and this way implement the same logic. I then started experimenting with extensions: VK_KHR_get_physical_device_properties_2, VK_KHR_external_memory_capabilities, VK_KHR_external_memory, VK_KHR_external_memory_win32, VK_KHR_dedicated_allocation. I was basically trying to somehow allocate a piece of system memory and import it to Vulkan to write to it as Vulkan buffer. I tried many things: CreateFileMapping + MapViewOfFile, HeapCreate + HeapAlloc and other ways, with various flags, but nothing worked for me. I also couldn't find any description or sample code of how these extensions could be used in Windows to import some system memory as Vulkan buffer.

Everything changed when I learned that creating normal device memory and buffer inside Vulkan is enough! It survives driver crash, so its content can be read later via mapped pointer. No extensions required. I don't think this is guaranteed by specification, but it seems to work on both AMD and NVIDIA cards. So my current solution to write makers that survive driver crash in Vulkan is:

  1. Call vkAllocateMemory to allocate VkDeviceMemory from memory type that has HOST_VISIBLE + HOST_COHERENT flags. (This is system RAM. Spec guarantees that you can always find such type.)
  2. Map the memory using vkMapMemory to get raw CPU pointer to its data.
  3. Call vkCreateBuffer to create VkBuffer with VK_BUFFER_USAGE_TRANSFER_DST_BIT and bind it to that memory using vkBindBufferMemory.
  4. While recording commands to VkCommandBuffer, use vkCmdFillBuffer to write immediate data with your custom "markers" to the buffer.
  5. If everything goes right, don't forget to vkDestroyBuffer and vkFreeMemory during shutdown.
  6. If you experience driver crash (receive VK_ERROR_DEVICE_LOST), read data under the pointer to see what marker values were successfully written last and deduce which one of your commands might cause the crash.

There is also a new extension available on latest AMD drivers: VK_AMD_buffer_marker. It adds just one function: vkCmdWriteBufferMarkerAMD. It works similar to beforementioned vkCmdFillBuffer, but it adds two good things that let you write your markers with much better granularity:

  • It can be called both inside and outside render pass, while vkCmdFillBuffer must be called outside render pass.
  • It performs its write after specified pipeline stage finished executing.

I created a simple library that implements all this logic under easy interface, which I called "Vulkan AfterCrash". All you need to use it is just this single file: VulkanAfterCrash.h.

Update 4 April 2018: In GDC 2018 talk "Aftermath: Advances in GPU Crash Debugging (Presented by NVIDIA)", Alex Dunn announced that a Vulkan extension from NVIDIA will also be available, called VK_NV_device_diagnostic_checkpoints, but I can see it's not publicly accessible yet.

Comments | #vulkan #graphics #libraries #productions Share

# Vulkan Memory Allocator 2.0.0

Mar 2018

At Game Developers Conference (GDC) last week I released final version 2.0.0 of Vulkan Memory Allocator library. It is now well documented and thanks to contributions from open source community it compiles and works on Windows, Linux, Android, and MacOS. Together with it I released VMA Dump Vis - a Python script that visualizes Vulkan memory on a picture. From now on I will continue incremental development on "development" branch and occasionally merge to "master". Feel free to contact me if you have any feedback, suggestions or if you find a bug.

Comments | #vulkan #libraries #productions #graphics Share

# Switchable graphics versus D3D11 adapters

Feb 2018

When you have a laptop with so called "switchable graphics" (like I do in my Lenovo IdeaPad G50-80), you effectively have two GPUs. In my case, these are: Intel i7-5500U and AMD Radeon R5 M330. While programming in DirectX 11, you can enumerate these two adapters and choose any of them while creating a ID3D11Device object. For quite some time I was wondering how various settings of this "switchable graphics" affect my app? Today I finally figured it out. Long story short: They just change order of these adapters as visible to my program, so that the appropriate one is visible as adapter 0. Here is the full story:

It looks like the base setting is the one that can be found in Windows Settings > Power options > edit your power plan > Switchable Dynamic Graphics. (Not to confuse with "AMD Graphics Power Settings"!) When you set it to "Optimize power savings" or "Optimize performance", application sees Intel GPU as first adapter:

When you choose "Maximize performance", application sees AMD GPU as first adapter:

I also found that Radeon Settings (the app that comes with AMD graphics driver) overrides this system setting. If you go to System > Switchable Graphics and make configuration for your specific executable, then again: choosing "Power Saving" makes your app see Intel GPU as first adapter, while choosing "High Performance" makes AMD graphics first.

It's as simple as that. Basically if you always use the first adapter you find, then you follow recommended settings of the system. You are still free to use the other adapter while creating your D3D11 device. I checked that - it works and it really uses that one.

It's especially important if you meet a strange bug where your app hangs on one of these GPUs.

Update 2018-05-02: Microsoft plans to add an API for enumerating adapters based on a given GPU preference (minimum power or high performance). See IDXGIFactory6::EnumAdapterByGpuPreference.

Comments | #directx Share

Older entries >


Pinboard Bookmarks


Blog Tags

[Stat] [STAT NO AD] [Download] [Dropbox] [pub] [Mirror] [Privacy policy]
Copyright © 2004-2018