Okay, our next speaker in live talk session will be Vladislav Bilo.
We talk about 080 game, the Vulcan API.
Welcome here.
Hi, before I get started, how many of you does know 080 as you hand?
Wow, I haven't expected that.
And by any chance, has someone seen my previous talk in 2021?
One? Really? Wow.
That's great actually.
Welcome to my lightning talk.
Thank you for attending it.
I'm Vladislav. I'm a senior graphics engineer and in my free time I'm working as a volunteer on 080.
I'm going to talk about Vulcan API, a little story how I added it to the game.
080 is a free and open source real time strategy game.
If you like games like Age of Empires, Warcraft or Starcraft, then you might find this game interesting as well.
The game supports single and multiplayer modes, so you can play with your friends.
We are internet or a local network.
Also we have plans for campaigns.
080 is a history based game about ancient times.
So many in-game buildings, units, maps, names, based on real historical documents.
We even have recorded voices for such times.
0DS a year doesn't exist in Julian or Gigaurian calendars, so 1AD goes straight after 1BC.
Interesting fact, the only 0 is used as a successful exit status on most platforms.
And also a big plus that 0 as a character is on top of the alphabetical order.
So like in most repositories, it's also a plus for us.
It's not intended, but it's a plus.
0 is a cross-platform game. It works on Linux, Mac OS and Windows.
Some users even run the game on Raspberry Pi.
The one of the strongest features of 0AD is mod support.
The main game itself is also a mod.
It's possible to customize and recreate different things from UI to gameplay, from sound to textures.
There are mods that add new civilizations, different timeframes like medieval or even fictional worlds like Legend of Zelda.
A mod structure itself is an example of a folder with the main game mod.
It has the same structure. It's transparent and doesn't require any special knowledge to make a mod.
Also, the big plus that each mod works on every platform the game works on.
So you need to compile something or pre-build some binaries.
Because besides art or maps, we use JavaScript for scripting.
By the way, all those pictures that I've shown you are screenshots from the game, so they are not post-processing.
Let's focus on that picture.
How we can achieve that? We need two key points.
First, for a beautiful art made by our artists.
The second one is the engine which draws a scene like that to the screen.
So, what did we have back in 2021 before I started refocusing our engine?
We have mods. We have a engine, a pyogenesis engine.
It's our custom game engine. It's written in C++ and it runs mods.
We are a library called Spider Monkey. It's a JavaScript library.
It was calling on the JL driver directly. It was really tightly coupled.
So you might meet different calls to OpenGL from different systems.
There were a lot of implicit relations.
That's an example of our old code.
You might see on top that just direct OpenGL call.
The next two calls are high-level calls, then three middle-level to reset bound textures,
and then again OpenGL calls. That's not great for modern GPUs and modern architecture.
So, which problems OpenGL have?
CPU performance and unpredictable cost of some function calls.
OpenGL was designed really, really long time ago.
It's still evolving. So we have OpenGL 4.6 that was released back in maybe 2018.
But it still has a lot of legacy.
There is no way to query for supported features, at least standard way to query for supported features
or GPUs. We can disable something if we see that GPU isn't capable of.
We don't have validation or debug things. We have some extensions that might provide some feedback,
but it's not enough.
Another big problem that OpenGL is single threaded.
It's pretty noticeable problem these days.
Just an example how OpenGL reports a version.
It's the same build, the same platform.
So it can be reported. It depends only on driver version.
So that's not so bad because you have major and minor versions in front of that.
So at least we can parse that. But if we're going to talk about GPU name,
that would be more complicated thing.
That's the same GPU, the same platform and the same build, but different drivers,
I mean different drivers of open source or not open source like different versions.
And they all can report the same card with different names.
So we have this structure. What we can do?
We have three options. Switch the engine. It's really monstrous way to do things.
It would be impossible for us.
The second one use third party library like Libangl or BGFX.
And the third one that I've chosen is adding an abstraction layer between our engine
and OpenGL to cover OpenGL driver and be able to switch different backends.
So how it would look like. The dashed line is the abstraction,
which is used by the renderer code of the engine.
OpenGL backend is our code that converts this abstraction to driver
and driver interacts with GPU directly.
And with that thing, we have interface like that.
If you know C++, you might know what's going on here.
It's actually pretty simple. No big brain here.
But it allows us to do various things.
Like it simplifies our renderer code.
Do you remember how many low level or middle level calls we had before?
And now we have only high level code.
That simplifies renderer code a lot.
So we're adding Vulkan backend and we added Dami backend for tests.
So now because we have an abstraction layer, we can easily switch backends
and we can now run tests with renderer code but on the server
because now we don't require to have like a window manager or GPU at all.
So by the way, about the size of rectangles, it's not by mistake that they are different.
It's really they are because OpenGL is pretty simple in terms of interacting with driver.
And Vulkan is much more explicit and you have to do many things manually.
But I've designed the abstraction layer dashed line in such a way that it's going toward Vulkan.
So actually Vulkan backend is smaller than it could be.
And OpenGL backend against is bigger than it could be
because it needs to work around some ideas that present in Vulkan and not present in OpenGL.
So in OpenGL backend we have about 4K lines and Vulkan about 8K plus VMA.
VMA is a third party library. It's a header only. It's used for resource management.
So 8K is all our code and we use some part of those 17K lines of code.
So about the results from 2021 to 2023 in total, if we sum up all the work we have done,
it's about one, like one and a half or two months of all time work.
It's just only factoring and adding an abstraction because adding Vulkan is pretty fast.
Another way to work fast because Vulkan has a really great feature called validation layers.
It simplifies developing for Vulkan a lot.
I would say that it could take like one month without validation layers or maybe more.
Now we have proper information about GPU because Vulkan itself provides all this information.
Also it provides driver version and a lot of different information we can use to detect features, disable them.
Also we don't have yet but we plan to add a multi-threading support.
So about performance, it's the demo time.
That's the game.
It works.
Let me check on the...
This checkbox is not visible from this angle.
So...
It's a sample map we have.
And what I'm going to show you.
You might see the FPS counter and in OpenGL it states 30 FPS.
And if we were to take a look at performance, the font is pretty small,
but I can tell you that it says 32 milliseconds per frame.
It's not a GPU time, it's per CPU time.
And if we switch to Vulkan...
By the way, we need to reload the game because we don't support real-time switching.
It would be too complicated.
And we're starting the game.
And as you may see, the FPS counter is 60 and it's bound by a reset.
If we were to take a look at the render now, it's only about 12 milliseconds per frame.
So that's pretty.
It's about three times faster.
And again, that's only about CPU.
So was it worth it?
Yes, performance up to time and more stable frame times.
We have a more predictable and stable behavior because not every platform game up to three times,
but other just get a more smooth and stable performance.
So do we need to Vulkan at all?
Of course.
If you can enable, just enable it.
If you can easily switch to another library, do it.
There should be a picture with ShiaLaBuff.
And if you use an own custom engine, it's questionable currently because if it's enough for you to use OpenGL, that's great.
But if you have a passionate graphics programmer like I am, maybe, then I would choose to switch to Vulkan.
So thank you.
And feel free to reach me after if you need some technical details or feel free to write me this email.
Thank you very much.
Thank you.