Alright, our next stack is porting a game engine render to Vulkan as an absolute beginner
by Dr. Carol Suprinovich.
Thank you, so hello everyone, and like on this stack I wanted to show, but maybe
this much of things like calling a lot, can we try that one?
So I wanted to show like my work on porting a game engine to Vulkan.
This will be very interesting perspective, because I didn't have like any previous experience in Vulkan at all
and also an experience with like a professional game engines.
So I did like some amateur programming in OpenGL area, but nothing can Vulkan.
And like the purpose of this talk is that probably right now there is like a lot of
a lot of open source projects that are using OpenGL right now.
And there's some difficulty to do to that and also describe that in a moment.
And also I just installed a laptop area.
And also that will benefit from porting to Vulkan.
There is it really that much about it.
So I would tell about my experience.
So first the game engine I was 14 people come, is for a game called OpenGL.
And that's like an open source social VR game or like social VR worlds game,
because it has both desktop mode and the VR mode.
And the game uses a completely custom agile, which is very nicely designed,
but right now it's supporting only, it was supporting only OpenGL and OpenGL.
And from the start, it looks like the engine was designed to have the multi-club backends.
It was done in a very clever way, I will show that in a moment.
So first of all, OpenGL has a very long history.
So it was first designed in 1980s.
It was called Irish G.L. at first.
And then in 1990s, I think in 1993, OpenGL was released.
And of course it felt that during the years.
But the problem was that a lot of that crashed from the previous,
like completely different, like GPU programming paradigms.
So the biggest problem with OpenGL was that it's single-traded.
And it's also state-based.
So for example, you've probably seen like the comments like your color,
or also you set a state.
And then like later comments raised that.
And it's also very high level, which is surprisingly.
That's also a problem.
So it's simple, like from the programmers perspective.
You can write a program that will render, for example, like a spinning triangle.
Like a few lines of code.
But the problem is of that complexity is hidden in drivers.
And that's the case when, for example, those drivers.
In different ways, or the performer.
And the work on the other hand is modern API for programming graphics cards.
And it's based on a previous API by AMD.
That was called a mantle.
And it's designed very much in the way you would expect it currently.
So you can program in multi-fledged way.
There are no internal states.
For example, you can build command buffers on separate threads.
You can utilize multi-core CPUs very efficiently to that.
And it's also very low level.
So it's very close to how GPU actually works.
And with the benefits.
So for us, like probably a big problem with OpenGL,
was that we had trouble with compatibility.
So on Windows, a mess ad drivers are amazing.
So for example, on AMD, on Windows, on Intel, it was very good.
But on Windows, there were times that the game was totally
unusual.
On AMD, due to the driver's.
And on Nvidia, there were also often personal messages.
And also on Mac OS, where like OpenGL got deprecated already in 2018.
It was also impossible to run the game due to broken OpenGL drivers.
So that was one problem.
Another thing is that this is a social VR game.
It requires a lot of, it's kind of very high performance application.
So there, like we had trouble with, we had trouble with,
for example, OpenGL was not utilizing GPU correctly,
especially if there was lots of draw calls.
Then there was like a serious performance loss.
And also in VR applications, it's very important to avoid
stutter.
And this is a pretty good trend.
So things like upload these textures to leave you or so,
with calls, stutter.
So that can be eliminated with full content.
You to like, multi-fed programming.
Then another thing was, it's a pretty big renderer.
We had trouble with, like, bugs in the renderer.
And that's where, like, we will kind of validation layers.
A lot.
I will tell about more later.
And one more thing was, in OpenGL,
you always provide shaders in GLS, GLS format.
And then they get, they get compiled to, to GPU specific format at runtime.
And the problem was that, that, the game was taking a lot of time to start.
It was sometimes like up to two minutes on OpenGL.
On OpenGL, it starts pretty much instantly.
Because on OpenGL, you have kind of binary representation.
That is much closer.
And easier to translate like GPU native format.
So we've challenges.
So probably the biggest problem with OpenGL is that it's totally different.
And, of course, the NoperGL.
And there is a lot of complexity.
So there is a lot of concepts such as render, passes, pipelines,
the speed, there is a lot of things happening there.
And also part of that, part of that complexity,
is also due to how long level blockad is.
So there is a memory management.
Also needs to be done, like, completely manually.
And so you need to, like, track all the resources.
And even, even, you cannot,
look, if memory just for a single resource,
you have to allocate bigger buffers,
because there is a much separate, like, the resources you can allocate.
So that's also a big problem.
And the last one is supporting custom shaders.
So the game supports custom shaders.
And that's a bit tricky.
In full can scenes, since then you would have to bank
a compiler for shaders to get a big game to download
shaders at runtime.
And we've, so to learn, like, there is a lot of different resources.
And the ones I can recommend, of course,
the third official resources for full can.
There is tutorial, samples, and so on.
And then another interesting resource is group can guide.
And that one is very interesting.
I think it's written by probably, by again, developer.
And it's very focused on the development.
And this one was useful, because it had a lot of, like,
practical advice.
For example, like, how to store, like, per frame,
data, how to manage objects for, for the vendors.
So it's amazing to use for.
And the last one is also amazing.
So there are a whole lot of examples by,
such a relapse.
And with those, it's very nice to start learning,
because normally we can.
You have to, like, spend a, like, a lot of, like,
kind of a bullet plate called for initializing things.
So for choosing GPU, and so on,
directly with extensions you need.
And with this, you can just download the samples.
And you can immediately start experimenting with them.
And even better, since a license for this is MIT,
you can reuse them in our code.
And when they started working on,
we can back in the format.
I just used, I just used the bullet plate called for,
from here.
Okay, so another tool is vendor doc.
So you can capture frames, device step,
and it's, it's awesome, amazing.
And you can even, when you have, like, some sort of rendering issues.
You can even edit shaders,
interactively in the capture frame, inside vendor doc.
And see, for example, you can fix the issue by editing them.
And here, there is space out from, from vendor doc,
running here, it's running for the,
it's a capture of frame from our,
a vocal vendor.
And it's also possible to analyze performance.
So you can see here, like, a duration in,
microseconds for each call.
And you can also analyze pipeline state.
And the way I was using it here,
I was using frame captures, from Vulkan, and from Virgil.
And then comparing them, site by site,
to see if Vulkan, there is working correctly.
And next part, so what is amazing about Vulkan,
is validation layers.
And with those, the way they work is, you render the program
normally, but you enable validation layers.
And then, it will point out pretty much all the issues
with, with program.
If there's, like, example of, like, one of such validation
validation layer, a message, of course, with the bugger,
you can put some breakpoints on them.
So then it's even easier to locate a very new program,
given issue is happening.
And, and that's amazing.
We've helped for pretty much, maybe, like, half of the work
was done through just fixing validation layers.
And then, when there were fixed, in general,
fixed immediately worked.
Vulkan memory, LK tower.
So that's why it's a very helpful library.
It's a single header library.
That manages memory allocation for you.
And it's used by, like, very big games studios.
And for example, I know that it's used in Ubisoft.
And it's also used by, by of the source projects.
So, for example, by Dolphin emulator.
And it has also very nice features for the bugging memory
use set.
And then, the next part is, like, most renders.
And the other renders, it was also, was based,
had a so-called render hardware interface.
And that means that it had a set of,
or set of kind of internally instructions.
And it first builds frame in that intermediate,
like set of instructions.
That can be interpreted by different rendering buttons.
And then, different backgrounds can interpret it.
And the cool part about it is that it can be civilized to a file.
So, then you have that intermediate format,
serialized to a file.
And you can replay it in different buttons.
So, for example, we could run a game in OpenGL,
save that intermediate, like, frame to a file.
And then, you play it in input parameter.
And that's, for example, we've, with a parting to new graphic APIs.
And here, there's a set of set of instructions
for render hardware interface.
So, as you see, the interface simple,
there's just 60 instructions in total.
And a lot of them are kind of repetitive.
Like, you can see, for example, those, like, really uniforms at the end.
So, it's mostly, like, the parting work is mostly,
parting those instructions.
And then also parting, you have to see,
adding, like, back-and-site representations of all the objects,
like, like, mesh, frame buffers, and so on.
And that's why, but they're rendering that.
So, rendering, like, interprets the,
the hardware interface commands.
It also, like, creates, like, back-and-site representations
of render objects, like, frame buffers, and textures, and so on.
And it also meant that, as we saw stuff loading,
and the generates, full-cam, command buffers,
which are, later, submitted to GPU to render.
Then, another thing that is very different from OpenGL
is that, on OpenGL, you just bind shaders,
and the rest of this, and then render.
And we can be, like, more complicated,
because that will be very inefficient.
And so, on OpenGL, you have pipelines,
and pipeline describes, like, all the,
the whole setup for given, given, a drop-hole.
And then, you can reuse pipelines from frame to frame,
and you can even save them to a file, and then, a cover later.
So, last part of that was making that pipeline cache.
And, other than that, there is also object-like time management.
So, since, you know, principally, class done automatically,
here, you have that, you have to do that manual, on your site.
And, you have to be special objects,
that have, like, shad pointers,
to objects used by given frame.
And then, it needs to be a recycler object,
because if the objects have deleted on a different thread,
then you need to go to the cycle, and then,
then, get, like, properly, this is what it looks
inside on, on the address.
Oh, yes.
Okay, and the one or thing is, of course,
is good to avoid writing shaders, like several times,
but the problem is that, while you can, of course,
write a GLSL, more form,
from, from, from a GL, it will be kind of problematic,
to maintain, like, several sets of shaders.
And so, the way we did that is,
there was separated headers, and there are also
processor macros for those.
And the way it works is, on work,
you have the script process, for different things.
So, for example, we used, like, separate the script process
for texture, textures, unique from buffers,
and for restores buffers.
And all of the, you don't have those.
And so, like, just a process of the files,
is possible to, to, to, to, to, to, to,
prepare, like, if, if, if they're, like, input enough,
with definitions.
Okay, and the, other than that, there is still a lot of
40 magic, so, right now, like, let there are shrubs,
and then, it's also one, that's quite nicely.
It's something, like, local bounce scenes.
We are getting, like, two and a half times,
the performance, and that's, like,
we very, you've, like, simple approach right now.
And yet, there is a lot of, of optimization,
meaning, so, first, like, we still have, like,
a lot of status, when texture is lost.
So, the, so, the textures, we, we apply
the ton, like, separate, like, transfer queue,
and separate, uh, thread.
And then, uh, there is, uh, more, like, work on memory,
management need that, uh, for,
GPUs, we, we've limited, uh, a mental video ram,
and then, like, like, long peak of meat maps,
so, starting from, uh, starting from, for example,
like, obviously there's a lot of textures,
so, probably, immediately in renderer.
And then, as, like, for, for the,
we have, like, stream, uh, from them, also.
There is still, uh, yes, a portal button,
but, that should be, probably pretty simple.
And then later, for, uh, like, standalone devices,
especially, or, like, headset,
with, like, eye tracking, uh, variable rate,
shading will be, uh, also, uh,
willing for prefer, for mass a lot.
And that's, uh, specifically, like, uh, will come
things, so, that's another benefit.
Also, uh, uh, uh, uh, do you have, uh, questions?
Uh, thanks.
Thank you.
It's, uh, I can't hear you well.
Uh-huh.
So, uh, thank you.
I guess I'm wondering, when, when doing something,
like, partying a game engine render,
like, how, how do you approach testing,
to make sure that, like, writing your things
doesn't introduce regressions?
Ah, so for that, uh, uh, uh, uh,
very useful part was that serialization, uh,
serializing the frame to, to a file,
because then, uh, you can have, like, special tool.
We have a tool called GPU frame player,
and then you can replay this same,
same file, uh, in, uh,
uh, same, like, intermediate format file, uh,
uh, for the frame in, uh,
an, uh, an, um, for example,
Vulkan or in different buckets,
and then you can compare it,
for example, St.P.
His missing or St.P.
Grandracing correctly.
So, uh, there's a special tool for that.
And for that, uh, it's a very important tool
to have that, uh,
uh, serialization of, uh, uh, uh,
or, uh, R-H-i, uh,
events and the, the frame.
Um, uh, thank you.
Thank you.