Those kitties are so cute!
Thanks! :D
I learned Vulkan and wrote a small game engine with it
121–130 of 268 posts
Re: I learned Vulkan and wrote a small game engine with it
#122life was a pleasure writing programs in IrisGL and then OpengGL :(
Yeah. Even though it might seem I’m 100% enjoying Vulkan, I still wish there was something closer to OpenGL and which was supported by GPU manufacturers. Other 3d party graphics frameworks are not bad, but you don’t feel the same confidence in their future in the same way as you did about OpenGL.
Re: I learned Vulkan and wrote a small game engine with it
#123This minimalism is very effective. I took the opposite approach, and it has cause great pain. I've been writing a metaverse client in Rust. Right now, it's running on another screen, showing an avatar riding a tram through a large steampunk city. I let that run for 12 hours before shipping a new pre-release. This uses Vulkan, but it has WGPU and Rend3 on top. Rend3 offers a very clean API - you create meshes, 2d text…
> All those layers create problems. WGPU tries to support web browsers, Vulkan, Metal, DX11 (recently dropped), DX12, Android, and OpenGL. So it needs a big dev team and changes are hard. WGPU's own API is mostly like Vulkan - you still have to do your own GPU memory allocation and synchronization.
The first part is true, but the second part is not. Allocation and synchronization is automatic.
Re: I learned Vulkan and wrote a small game engine with it
#124I tried learning Vulkan a little more than a year ago and I have no desire to ever touch it again. It really bothers me that we're deprecating OpenGL and replacing it with something that's ridiculously hard to do anything simple (e.g. doing a spinning cube takes several hundred lines of code). OpenGL was never "easy" but it was at least something a regular person could learn the basics of in a fairly short amount of…
It really bothers me that we're deprecating OpenGL and replacing it with something that's ridiculously hard to do anything simple
OpenGL is only deprecated on MacOS, AFAIK, it will exist for many years to come.
I'm sure Vulkan is better in some regards but is simply not feasible to expect someone to learn it quickly.
Vulkan is often said to be more of a “GPU API” than a high level graphics API. With that in mind, the complexity of Vulkan is not surprising. It’s just a difficult domain.
Like, imagine the newest Intel/ARM/AMD chips came along and instead of being able to write C or C++, you're being told "We are dropping support for higher level languages so you can only write assembly on this now and it'll be faster because you have more control!" It would be correctly labeled as ridiculous.
IMO, it’s more like single threaded C/C++ vs multithreaded C/C++ programming. There is a massive increase in complexity and if you don’t know what you are doing, it’ll blow up in your face and/or give you worse performance. However, it’s the only practical path forward.
Anyway, OpenGL can basically be implemented on top of Vulkan. Perhaps it is regrettable that the OpenGL standard is no longer being actively developed, but nothing lasts forever.
Re: I learned Vulkan and wrote a small game engine with it
#125Earlier quoted context omitted.
Indeed. vk-bootstrap is a bit better with 600 lines of code, though: https://github.com/charles-lunarg/vk-bootstrap/blob/main/exa... Vulkan initialization and basic swapchain management is very verbose, but things get much better after you do it for the first time and make some handy abstractions around pipeline creation/management later.
For sure. They just move the roughly 300 lines of code elsewhere so you don't have to do it, though. I'd like to see them move nearly all 900-ish lines of SLOC back down into the near 90-ish you'd need to initialize OpenGL. There's so much overlap in basically everyone's graphic usage of Vulkan that you realize after doing it yourself they should have done some simple optimization for the 99% use case, and allowed ot…
I guess libraries like bgfx, sokol and The Forge are kinda like that. But I just feel like it’s either all or nothing if you’re already doing your own game engine.
I’m okay with using middleware/3rd party libraries for things which I don’t care too much about (e.g. physics), but graphics is such a core component that I want to handle it myself.
In a way, OpenGL drivers were such middleware libraries written for you by GPU vendors (or open source community). But now they stopped doing that and now you’re either writing your own graphics abstraction layer or using someone else’s.
In this case, I choose the hard way. And it seemed to have worked out so far. I definitely won’t recommend it to everyone (especially if they want to make a game in less than a year!), but as a learning experience it was fun.
Re: I learned Vulkan and wrote a small game engine with it
#126I tried learning Vulkan a little more than a year ago and I have no desire to ever touch it again. It really bothers me that we're deprecating OpenGL and replacing it with something that's ridiculously hard to do anything simple (e.g. doing a spinning cube takes several hundred lines of code). OpenGL was never "easy" but it was at least something a regular person could learn the basics of in a fairly short amount of…
Vulkan is for writing OpenGL-type libraries against. It's advantage is largely that much of the library-level code is moved out of opaque and buggy device drivers and into user-space libraries.
Khronos keeps pushing this in their promotional materials for the standard, and it's not an advantage. Now instead of vendors writing this correctly once for everyone, everyone can do it poorly. Go read a few Vulkan initialization implementations across a few repositories. It's all the same code, and some people miss portions of it here and there.
I don't know how this lie caught on so well, but it doesn't pass the smell test.
Re: I learned Vulkan and wrote a small game engine with it
#127Earlier quoted context omitted.
Indeed. I used as little CSS as I could because I love minimalist websites. And the lack of syntax highlighting was inspired by Go blog, for example. :) Raw HTML definitely looks much uglier, sadly (“Reader mode” in most browsers makes websites without CSS easily readable, though!).
Your site looks nice and is quite readable! The thing I most dislike about sites that just use raw HTML is the lack of `max-width` on the text containers (which makes using reader mode necessary), so thanks for including that
Thank you! :)
Re: I learned Vulkan and wrote a small game engine with it
#128Earlier quoted context omitted.
> WGPU doesn't support multiple threads updating GPU memory without interference, which Vulkan supports. This is really helpful for me to learn about, this is a key thing I want to be able to get right for having a good experience. I really hope WGPU can find a way to add something for this as an extension.
Do you know if these things I found offer any hope for being able to continue rendering a scene smoothly while we handle GPU memory management operations on worker threads? https://gfx-rs.github.io/2023/11/24/arcanization.html https://github.com/gfx-rs/wgpu/issues/5322
The actual issue is not CPU-side. The issue is GPU-side.
The CPU feeds commands (CommandBuffers) telling the GPU what to do over a Queue.
WebGPU/wgpu/dawn only have a single general purpose queue. Meaning any data upload commands (copyBufferToBuffer) you send on the queue block rendering commands from starting.
The solution is multiple queues. Modern GPUs have a dedicated transfer/copy queue separate from the main general purpose queue.
WebGPU/wgpu/dawn would need to add support for additional queues: https://github.com/gpuweb/gpuweb/issues?q=is%3Aopen+is%3Aiss...
There's also ReBAR/SMA, and unified memory (UMA) platforms to consider, but that gets even more complex.
Re: I learned Vulkan and wrote a small game engine with it
#129Earlier quoted context omitted.
Yes, over engineering solutions is a constant thorn in my side. The end result is you get a lot of additional complexity for basically no benefit. In my experience, if new requirements do come down the pipeline at some later time, the generic solution you previously built will be completely inadequate and will need to be redone anyway. Solve the problem in front of you, not some unknown future problem.
On the other hand, often a "quick and dirty" solution unexpectedly becomes the foundation of a lot of other stuff, which can be a persistent pain in the future, while the cost of rewriting the whole thing increases the more other stuff depends on it. There are two poles: On the one side is making everything an unmaintainable pile of quick hacks, on the other side is over engineering everything. You want to be somewhe…
> On the other hand, often a "quick and dirty" solution unexpectedly becomes the foundation of a lot of other stuff
This is how Access "databases" and Excel spreadsheets often become mission-critical in SMBs. "We'll deal with needing a database server down the road..."
Re: I learned Vulkan and wrote a small game engine with it
#130Earlier quoted context omitted.
A middle ground is webgpu. It is much less verbose than Vulkan and is guaranteed to run anywhere, including the browser. At the same time, it has access to "modern" features like compute shaders which would not be available in webgl. It also doesn't have much legacy cruft leading to multiple ways of doing the same thing, unlike opengl. The main advantage is that it's new, so there are many fewer tutorials available f…
Not to downplay it or anything, but I'm curious why webgpu is receiving so much attention? There have been many low-level cross-platform graphics abstractions over the years. The bgfx [1] project had its first commit ~12 years ago and it's still going! It's much more mature than webgpu. I'm guessing being W3C backed is what's propelling it? [1] https://github.com/bkaradzic/bgfx
webgpu is a modern graphics API for modern GPUs to replace/complement these two APIs in the browser: WebGL (a very limited outdated subset of OpenGL) and Canvas (basically WinAPI drawing from 2000s)
It's heavily influenced by Metal (based on original work by Apple and Mozilla).
People are talking about it because it's on the web and it's finally something modern to work with.