Entries for tag "productions", ordered from most recent. Entry count: 115.
# 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.
# Debugging Vulkan driver crash - equivalent of NVIDIA Aftermath
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:
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:
VkDeviceMemoryfrom memory type that has
HOST_VISIBLE + HOST_COHERENTflags. (This is system RAM. Spec guarantees that you can always find such type.)
vkMapMemoryto get raw CPU pointer to its data.
VK_BUFFER_USAGE_TRANSFER_DST_BITand bind it to that memory using
vkCmdFillBufferto write immediate data with your custom "markers" to the buffer.
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:
vkCmdFillBuffermust be called outside render pass.
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.
# Vulkan Memory Allocator 2.0.0
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.
# Vulkan Memory Allocator 2.0.0-alpha.3
I just published new version of Vulkan Memory Allocator 2.0.0-alpha.3. I'm quite happy with the quality of this code. Documentation is also updated, so if nothing else, please just go see User guide. I still marked it as "alpha" because I would like to ask for feedback and I may still change everything.
I would like to discuss proposed terminology. Naming things in code is a hard problem in general, and especially as English is not my native language, so please fill free to contact me and propose more elegant names to what I called: allocator, allocation, pool, block, stats, free range, used/unused bytes, own memory, persistently mapped memory, pointer to mapped data, lost allocation (becoming lost, making other lost), defragmentation, and used internally: suballocation, block vector.
# Thoughts after Slavic Game Jam 2017
Slavic Game Jam 2017 ended today. I have not only given a talk as a representative of the sponsor company, but I was also allowed to participate in the jam itself, so I teamed up with my old friends, some new friends that I met there and we made a game :) The theme this year was "Unknown". Our idea was to create a game about a drone flying and exploring a cave. You can see it here: This Drone of Mine.
There were 2 developers in our team, 3 graphical artists and one sound/music artist. We decided to use Unreal Engine 4, despite we had no previous experience in making games with this engine whatsoever, so we needed to learn everything during the jam. We didn't do any C++ - we implemented all game logic visually using Blueprints. We also set up Perforce for collaboration, so some of us needed to learn that as well (I am fortunate to already know this tool pretty well).
We didn't win or even make it to the second round, but it's OK for me - I'm quite happy with the final result. We more or less managed to implement our original idea, as well as show almost all the graphics, sound effects, music and voice-overs, so the artists' work is not wasted. It was lots of fun and we learned a lot during the process.
You can browse all games created during the jam here: Slavic Game Jam 2017 - itch.io.
# Artykuł: Praca zdalna - 10 faktów i mitów
(Polish) Dziś Święto Pracy. Z tej okazji publikuję artykuł, który ostatnio napisałem, tym razem w języku polskim. Opisałem w nim, na podstawie mojego doświadczenia, zalety i wady pracy zdalnej. Rozmawiając ze znajomymi słyszę nieraz różne opinie na temat pracy z domu, spośród których nie wszystkie są prawdziwe. To zachęciło mnie do napisania tego artykułu:
(English) This time I publish an article I've written in Polish. Its title can be translated as "Remote Work - 10 Facts and Myths".
# Pixel Heaven and Bajtek Special Issue
Do you remember "Bajtek" magazine? I don't, because I was a little kid back then, but older colleagues told me that in 80's and 90's it was a popular Polish magazine about computers (like Atari, Commodore or Amiga - platforms that were in use at that time). Archival issues can be downloaded for free from atarionline.pl.
Now, 20 years after last one, a new issue has been released. It's a single, special issue - Wydanie specjalne: Bajtek. There is my article inside - "Programowanie grafiki dziś" ("Graphics Programming Today"). The article describes briefly a history of graphics cards (from first 3D games, through 3Dfx Voodoo and S3 ViRGE, cards from NVIDIA and ATI/AMD, appearance of OpenGL and DirectX, to invention of shaders), shows graphics pipeline of modern GPU-s and mentions the new generation of graphics API-s (Direct3D 12 and Vulkan).
Many people who were interested in graphics programming, games or demoscene at the time of Bajtek magazine, now have a more "serious" job, whether in software development or something completely different, and they no longer have time for this hobby, so they are not up-to-date with advancements in this technology. So I thought they may like a short update on this subject.
The new issue of Bajtek was first shown on Pixel Heaven - a party that took place 3-5 June 2016 in Warsaw. I've been there and I had a great time. There were many different activities, like indie games exhibition, retro gaming zone, lectures and discussion panels.
# Global Game Jam 2016 - Postmortem of our project
Last weekend, this year's edition of Global Game Jam took place all around the world. Just like in previous years, I participated in 3City Game Jam - a site in Gdańsk, Poland. It is a big one, with over 150 participants, organized by Playsoft company in their office. Theme this year was "Ritual". Regarding technology, Unity was most popular in our site, with just few games using something else: Unreal Engine, HTML5, GameMaker and C++ with SFML.
We have also used Unity. Our team consisted of 3 programmers. Here you can see our game: Bloody Eclipse, but it is far from being finished or playable. Honestly speaking, in my opinion the project on this jam went exceptionally poor. We didn't even make it to the top 10 best voted games to be presented on a big screen. That's why I'd like to share some conclusions, for you as well as for my future self.
First, it were not environmental issues that caused any problems. We all had our hardware and software set up before the jam, with Unity, Visual Studio, Git client and other tools already in place. Internet worked perfectly with transfer up to 80 Mbps in both directions. Second, it was not a lack of knowledge or skills. Our work in Unity went quite smoothly. We could deal with C#, 3D math and Git pretty well. Third, it was not because of the lack of artists in our team. Sure, graphics is very important for overall experience, but the guys who made The Bad Ritual also didn't have artists in their team and they somehow found a consistent visual style for their game, made it fun and pretty. There are many possibilities to make minimalistic and yet visually pleasant game, just like there are many free assets ready to use in Unity Asset Store.
The biggest thing that was missing in our team was management/leadership. I deliberately don't call it planning or design, because in a hectic environment like a game jam it's not enough to design the game at the beginning and then just execute. Things are changing fast, new ideas come to mind, time is running fast and new obstacles appear (like bugs or difficulties in development), so someone should have an authority to decide what to do next, keep the list of tasks "TODO" and update it constantly with priorities assigned so the most important things are done first. Noone took this role in our team. As the result, we've spent almost whole Saturday developing and polishing algorithm for enemy movement and around half an hour brainstorming and then voting for the game title, while our game used untextured, placeholder cubes and spheres as models until the very end :)
Conclusion: It's not enough to know how to code. It's also important to decide WHAT to code so that best possible result can be achieved with limited time and resources.
But the Global Game Jam as a whole is not a contest (despite our site actually was one, with PlayStation 4 for each team member as first prize) but just a fun, creative event. Despite all the problem we had I think it was fun. I had yet another opportunity to use Unity, which is a great technology. I realized I can handle Git pretty well, despite I don't feel like an expert knowing about "rebase" and such advanced stuff. I realized I still remember how to use the so much unintuitive inteface of Blender, which I learned many years ago to use in my master thesis. I could play many interesting games created on this jam, like my favorite: Witch Rite (it took 3rd place) or the one that won the contest: Acolytes: Ritual of Ascension. And finally, I've met many interesting people who do all sorts of crazy stuff, from running a company that produces medical software and hardware, to visiting escepe rooms and practicing celtic dances :)