# str_view - null-termination-aware string-view class for C++
tl;dr I've written a small library, which I called "str_view - null-termination-aware string-view class for C++". You can find code and documentation on GitHub - sawickiap/str_view. Read on to see full story behind it...
Let me disclose my controversial beliefs: I like C++ STL. I think that any programming language needs to provide some built-in strings and containers to be called modern and suitable for developing large programs. But of course I'm aware that careless use of classes like
std::map makes program very slow due to large number of dynamic allocations.
What I value the most is RAII - the concept that memory is automatically freed whenever an object referenced by value is destroyed. That's why I use
std::unique_ptr all over the place in my personal code. Whenever I create and own an array, I use
std::vector, but when I just pass it to some other code for reading, I pass raw pointer and number of elements -
myVec.size(). Similarly, whenever I own and build a string, I use
std::string (or rather
std::wstring - I like Unicode), but when I pass it somewhere for reading, I use raw pointer.
There are multiple ways a string can be passed. One is pointer to first character and number of characters. Another one is pointer to first character and pointer to the next after last character - a pair of iterators, also called range. These two can be trivially converted between each other. Out of these, I prefer pointer + length, because I think that number of characters is slightly more often needed than pointer past the end.
But there is another way of passing strings common in C and C++ programs - just one pointer to a string that needs to be null-terminated. I think that null-terminated strings is one of the worst and the most stupid inventions in computer science. Not only it limits set of characters available to be used in string content by excluding
'\0', but it also makes calculation of string length O(n) time complexity. It also creates opportunity for security bugs. Still we have to deal with it because that's the format that most libraries expect.
I came up with an idea for a class that would encapsulate a reference to an externally-owned, immutable string, or a piece of thereof. Objects of such class could be used to pass strings to library functions instead of e.g. a pointer to null-terminated string or a pair of iterators. They can be then queried for
length(), indexed to access individual characters etc., as well as asked for a null-terminated copy using
c_str() method - similar to
Code like this already exists, e.g. C++17 introduces class
std::string_view. But my implementation has a twist that I'm quite happy with, which made me call my class "null-termination-aware". My
str_view class not only remembers pointer and length of the referred string, but also the way it was created to avoid unnecessary operations and lazily evaluate those that are requested.
c_str()trivially returns pointer to the original string.
length()trivially returns it.
c_str()creates a local, null-terminated copy of the string upon first call.
If you consider such class useful in your C++ code, see GitHub - sawickiap/str_view project for code (it's just a single header file), documentation, and extensive set of tests. I share this code for free, on MIT license. Feel free to contact me if you find any bugs or have any suggestions regarding this library.
# Porting your engine to Vulkan or DX12 - video from my talk
Organizers of Digital Dragons conference published video recording of my talk "Porting your engine to Vulkan or DX12":
PowerPoint slides are also available for download here: Porting your engine to Vulkan or DX12 - GPUOpen.
# Vulkan layers don't work? Look at registry.
If you program using Vulkan on Windows and you see that Vulkan layers stopped working (especially after updating graphics driver or Vulkan SDK), first thing to try is to uninstall Vulkan SDK and install it again. Also restart your computer, to be sure that environmental variables are updated. But sometimes it doesn't help or it even makes things worse.
If you are still not able to successfully find and enable
VK_LAYER_LUNARG_standard_validation in your code, or you try to enable
VK_LAYER_LUNARG_api_dump using environmental variable but can't see it working, or have problem with any other layer, first thing you can try is to issue
vulkaninfo console command. If you see some errors about "JSON", it clearly indicates that there is a problem with configuration of Vulkan in your system, regarding paths to layer DLLs and their JSON descriptions.
Either way, the thing I recommend is to launch
regedit (Registry Editor) and check values in following keys:
They should contain paths to valid JSON files that describe installed Vulkan layer DLLs. "ExplicitLayers" is the list of layers that can be manually enabled either programatically via
VkInstanceCreateInfo::ppEnabledLayerNames, or via environmental variable
VK_INSTANCE_LAYERS. "ImplicitLayers" is the list of layers loaded automatically by each Vulkan app (e.g. one added by Steam or RenderDoc). For further details see article: "Vulkan Validation and Debugging Layers".
It looks that the installer of Vulkan SDK can mess up these registry entries. Yesterday, after uninstalling old SDK and installing new one, I found there entries from both versions. Today, my colleague found these registry keys completely empty. So whenever you have problems with Vulkan layers on Windows, take a look at the registry.
# Human-friendly classification of Vulkan resources
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. if ((usage & (VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT | VK_BUFFER_USAGE_VERTEX_BUFFER_BIT | VK_BUFFER_USAGE_INDEX_BUFFER_BIT)) != 0) return class0; // Buffer is accessed by shaders for load/store/atomic. // Aka “UAV” else if ((usage & (VK_BUFFER_USAGE_STORAGE_BUFFER_BIT | VK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BIT)) != 0) return class1; // Buffer is accessed by shaders for reading uniform data. // Aka “constant buffer” else if ((usage & (VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT | VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT)) != 0) return class2; // Any other type of buffer. // Notice that VK_BUFFER_USAGE_TRANSFER_SRC_BIT and VK_BUFFER_USAGE_TRANSFER_DST_BIT // flags are intentionally ignored. else return class3; For images: // Image is used as depth/stencil “texture/surface”. if ((usage & VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT) != 0) return class0; // Image is used as other type of attachment. // Aka “render target” else if ((usage & (VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT | VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT | VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT)) != 0) 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. // Notice that VK_IMAGE_USAGE_TRANSFER_SRC_BIT and VK_IMAGE_USAGE_TRANSFER_DST_BIT // flags are intentionally ignored. else 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:
VK_IMAGE_TILING_OPTIMALshould be used wherever possible, so those with
VK_IMAGE_TILING_LINEARare 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.
# My upcoming 3 talks
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ö.
# A MAZE in Berlin - my impressions
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 :)
# Vulkan API - my talk at Warsaw University of Technology
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: https://www.facebook.com/events/185314825611839/
# Memory management in Vulkan and DX12: slides are online
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.
.net algorithms c++ commonlib competitions compo demoscene directx engine events flash fractals gallery games ggj gpu graphics gui hardware homepage humor ideas igk java libraries life linux literature math mobile music networking optimization origami philosophy photography politics productions psytrance redmond rendering scripts shopping software software engineering stl studies teaching tools video visual studio vj vulkan warsztat web webdev winapi windows