Programming, graphics, games, media, C++, Windows, Internet and more...
# Impressions from Vulkanised 2023 Conference
Thu
16
Feb 2023
Last week I attended Vulkanised conference. It is an official conference of Vulkan API. It took place 7-9 February 2023 in Munich, Germany. It was my first time at this conference. My attendance was part of my job at AMD and I co-presented with Valve about using Radeon Developer Tools on RADV (Linux AMD driver) and Steam Deck. Here, on my blog, I would like to share my personal impressions from the event.
Overall, it was well organized. There were over 200 attendees, 3 days full of talks, most of them short (20-30 minutes, some of them even 10 minutes!), happening on just one scene (apart from full-day Vulkan tutorial for beginners, happening on the first day in parallel with normal talks), with lunch break and coffee breaks in between, so everyone could see everything without a need to choose from the timetable which talks to attend. It was intense. Every evening we went for some good food and beer, which I enjoy a lot every time I visit Munich/Bavaria/Germany.
In terms of people attending, a conference like this differs completely from game developer conferences that I usually attend. On one hand, everyone there was a programmer who knows and uses Vulkan, so everyone was on the same page. On gamedev conferences, there are people from different fields, as game development is multidisciplinary - graphics and music artists, designers, programmers, business people etc. On the other hand, there were not so many people from game industry there, and if anyone, they were mostly from the world of mobile GPUs, not PC or console. It was interesting to talk with developers from various industries, using GPUs and Vulkan for different applications, like scientific computations and visualizations or even… software for cloth design for fashion business.
There were many interesting talks. I think the most valuable ones were about components of the Vulkan ecosystem that are useful to every developer, like Vulkan validation layers, VkConfigurator, Vulkan loader, or GFXReconstruct (which also added support for Direct3D 12 recently, by the way!). There were long and extensive talks teaching two recent big additions to the API: mesh shaders and Vulkan Video. Vulkan Video seems to be especially complicated, partially because it requires some knowledge of video encoding/decoding, which is something different from 3D rendering. I used to work for television, so it was not that obscure for me. But this new part of the API is also very low level. The decision to make encoding/decoding of every frame stateless, with all the state of the video stream managed by the user, makes the API surface very extensive.
Talk about Diligent Engine was interesting. I didn’t look at the project itself, but the presentation looked convincing that this is a good multi-platform 3D graphics library implemented on top of various graphics APIs. Another interesting project presentation was about VkFFT - a C library that calculates FFT on the GPU using one of many supported APIs (not only Vulkan) with state-of-the-art performance. It is implemented by assembling a string with the source code of a kernel optimized for a specific case.
Presentations about game optimization for mobile GPUs were very interesting to me. Optimizing games is what I do in my everyday job, although I work with “large” PC GPUs. I consider such talks with a collection of tips and recommendations exceptionally valuable. From these presentations, I could learn what things work fast on smartphone and tablet chips, which are different from PC and console chips. They said that on these platforms, energy consumption and bandwidth to and from memory is the most important. Because mobile GPUs are tile-based, a large amount of vertices or fat vertex format is very slow, which is not the case on PC. Also because of that, they recommend to group as many passes as possible as sub-passes of a single Vulkan render pass, even to a degree that rendering of 3D objects could be grouped together with screen-space postprocessing effects. Again, it isn’t a thing that we normally do on PCs. It was also interesting to see how they measure performance. While I always disable V-sync and just measure FPS in games, they seem to give multiple columns with results, including FPS, but also GPU utilization %, which is likely used when reaching 60 FPS with V-sync always enabled.
But more than any specific presentation, it was interesting for me to hear some general ideas about Vulkan, often repeated by multiple people. There were people from Khronos and LunarG there (the company that develops Vulkan SDK), so we could hear from and ask questions to people who really make this API. There was a discussion panel with many prominent participants who shared their voice on these topics. Noone said “what happens on Vulkanised stays on Vulkanised”, so here are some things I remember. Disclaimer: These are my personal, subjective impressions. I might remember something wrong. Please feel free to leave a comment with your own thoughts below this article.
Some profound things have been said about Vulkan. Someone said it’s not a graphics API, more like a Hardware Abstraction Layer (HAL) or an API for programming accelerators. They said it is a “design by compromise” rather than “design by committee”. They said we should think of Vulkan as not only the specification, by the entire ecosystem, including libraries, tools, code samples, learning materials, etc. I was pleased to hear that Vulkan Memory Allocator that I maintain was often mentioned as one of the examples. An open question is how many of these 3rd party components should be considered “canonical”. Many are already included in Vulkan SDK, but should official samples use them as well? Currently, they don’t, as they teach raw Vulkan. Someone also said that these ecosystem components should be properly funded. Another question was about the direction Vulkan should go. One person said it should probably become even more low-level, with app-space libraries on top of it more widely used.
It was surprising to see that there are solutions to run Vulkan above and below every other graphics API, which makes Vulkan a common ground across systems and APIs:
Among problems that developers have with using Vulkan and potential areas of development for the future, I noticed several common themes:
Overall, participation in Vulkansed conference was a great experience for me. I wish I will come back there. But Vulkan, even with its unprecedented openness, portability, and universality, is just part of the entire world of 3D graphics programming. On a conference dedicated to Vulkan I wouldn’t say loud that Direct3D 12 is more popular among PC game developers and it is not without a reason, or that maybe both these “explicit” APIs are at the worst possible level of abstraction - low level enough to be difficult to learn, to use, and easy to create bugs, while high-level enough to still hide hardware details crucial to squeezing maximum performance. But this is a separate topic…
When attending any event, I always pay attention to the quality of the audio-video system. On Vulkanised, it was very good. I especially liked the acoustics of the room, which clearly someone paid attention to when designing the interior. But there were some issues with presentation video that I don’t see too often. I blogged before about 3 Rules to Make You Image Looking Good on a Projector, where I mentioned potential problems with contrast, reproduction of colors or thin lines. Another time I described a possibility that edges of the screen may be cropped. But this conference had a different problem. Instead of connecting their laptops to a HDMI cable, speakers were asked to join an online meeting via Google Meet and share their screen there, with presentation on the big screen by another participant of that virtual call, streaming the content. We were in a Google office, after all :) This surely helped them record the presentations easily, but it also made any video or animation degraded to what looked like 2 FPS.
For more photos, see the official gallery 2023 Vulkanised by Khronos.
Comments | #rendering #vulkan #events Share
# Impressions After Global Game Jam 2023
Tue
14
Feb 2023
I usually write technical blog posts to educate readers on specific topics. However, this time, I wanted to share something more personal - my experience after participating in the Global Game Jam 2023. The event took place from February 3 to 5, 2023, but only now did I find the time to write this post, as I spent a week in Munich attending the Vulkanised conference right after GGJ.
For those unfamiliar with the Global Game Jam, it's a worldwide event where participants come together to create games for fun. Unlike Ludum Dare, GGJ is not just an online/remote event. It's an opportunity to spend the weekend in person at one of many sites around the world and develop a game based on a specific, globally-announced theme within the constrained time limit. In Poland alone, there were eight sites organized in major cities. I attended PolyJam 2023 (GGJ entry, FB event), which was organized by Koło Naukowe Twórców Gier Polygon, a game development interest group at Warsaw University of Technology that I still regularly attend even though I'm no longer a student.
The theme announced for this year’s GGJ was “roots”. A theme is something that games made during the jam should be related to, or at least be inspired by. But the theme can be interpreted freely. Roots of trees and other plants are the first association that comes to mind and that most teams followed (including us), but others are also possible, e.g. a heritage like genes or culture inherited from parents and ancestors, something about indigenous people, or even… calculating mathematical square root.
Our jam site was large and well organized. KNTG Polygon has long experience in organizing such events, after many years of doing local site of GGJ, as well as their custom Slavic Game Jam. Thanks to the work of volunteers and money from sponsors, a very low entry fee ensured not only space, access to the power and Internet but also unlimited coffee, other drinks, sweets, and full catering. GGJ website says there were 124 jammers registered on the site. Although GGJ as a whole isn’t a competition, there are no winners or prizes, our local site featured a competition.
When competitions are made on game jams, there are 2 general ways of doing them:
If a team wants to win, they should take different approaches depending on this. In option 1, the game is played only by the authors, so it is enough to prepare a good-looking show for a couple of minutes. However, they need to think beforehand about what to say and how to play their game to impress people. Option 2 is essentially like preparing a booth on a gaming expo – all about attracting people, showing and explaining the game to them, and making sure the build works fine and looks playable during these few minutes when other people play it. PolyJam 2023 went for option 1. Every team had 3 minutes to present their game on stage. There were over 40 different teams, but the presentation was well organized and went smoothly.
Back to my presence there… I didn’t take part in a game jam for 2 years, since before COVID. I wanted to go there to check if I still remember how to program :) Of course I work with code in my everyday job, but quickly hacking a game jam game, which is essentially like a prototype, is something different from writing production-quality code at work. The small 2D game we made is: Roots of Life and Death. Our team was 3 people: Michał Rudnicki “Mildanach” as graphics artist, Bartek Dramczyk “Voyager” who made music and sound effects, and myself as the programmer. We’ve developed everything on a public GitHub repository. I also hosted web version of the game that can be played online. The game is about resource management – by creating new nodes (left mouse button click) and transferring resources between them (left mouse button drag&drop), player can expand the system of underground roots, create new flowers to gather more sun at the top of the map and acquire more water at the bottom. Enemy plant is playing on the other side of the screen according to the same rules, controlled by the AI.
I know the game is not finished, not very dynamic or enjoyable. What is important to me is the way we made it. In past game jams I used different technologies, ranging from a custom engine in C++, Cocos2d-x library, to Unity and Unreal Engine, which are the most popular these days. I must admit I don’t know Unity or UE too well – not as much as I wish I knew, but for this year’s GGJ I decided to try something new: I used Cocos Creator. This is a Chinese game engine that looks somewhat similarly to Unity, provides a convenient editor, features a component-based scene graph, and supports all an indie game may need (2D and 3D graphics, collisions and physics simulation, UI, sound, etc.).
The programming language used in it is TypeScript. I didn’t know either Cocos Creator or TypeScript before. Having only basic knowledge of JavaScript, I started learning them 2 weeks before the jam. I enjoyed it a lot. It is long time since I learned a new programming language, while it is always a very mind-expanding experience. I like the way TypeScript introduces strong typing into JavaScript, which is by nature a very dynamic scripting language. For example, let a: string|number; defines a variable which can contain either string or numeric values, while let eventType: 'mouseDown'|'mouseUp'; defines a variable that can hold only a string with one of these two specific values. I was learning just from a first TypeScript tutorial I found on the Internet and the official TypeScript cheat sheets.
With our game, we didn’t win the competition at our site and we were far from winning, but this wasn’t the point. I am still happy about our performance. Things that went well:
What went wrong:
Overall, participation in Global Game Jam was a fun experience. I can recommend it to everyone who likes games and feels a need to do something creative. There is no need to have a team beforehand. Some people just come and team up with freshly meet people, some make their games alone as a 1-person team. I even met some people who came but didn’t plan to make any game! They just wanted to spend this time among nice, like-minded people and do something creative, e.g. to draw new things to their personal portfolio.