Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I learned Vulkan and wrote a small game engine with it

edw.is

Post reply on HN
Print view View original

141–150 of 268 posts

Re: I learned Vulkan and wrote a small game engine with it

#141

Post by Animats »

jms55 wrote: post #123
Animats wrote: post #93

This 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.

Vulkan does not allocate GPU memory for you. Well, it gives you a big block, and then it's the problem of the caller to allocate little pieces from that. It's like "sbrk" in Linux/Unix, which gets memory from the OS. You usually don't use "sbrk" directly. Something like "malloc" is used on top of that.

Re: I learned Vulkan and wrote a small game engine with it

#142

Post by jaggederest »

_nist wrote: post #97
proc0 wrote: post #94

Earlier quoted context omitted.

This is in context of a one person team. The next advice makes this evident: > Remember that you can always rewrite any part of your game/engine later. This isn't the case in medium to large organizations. Usually you will just move on and rarely have the time to revisit something. This is unfortunate of course, but it means you need to build things properly the first time around and make sure it won't have a chance…

I agree with this. In a large organization, if you have risen to a level where you are being relied upon at a regular intervals, it is imperative that you have a well architected solution that you can readily change and this is where you separate your program from spaghetti code to something useful. Sure, its nice to write unmaintainable junk when toying around, but I to have seen too many codebases where people were…

The contrast to this is to put in tickets specifically for refactoring and reorganization, but I've rarely seen that work since they often don't have any sweetener included to encourage e.g. product organization to sign off on the work.

Re: I learned Vulkan and wrote a small game engine with it

#143

Post by exe34 »

proc0 wrote: post #94
spicyusername wrote: post #10

Lots of good advice in this article. One that stuck out to me: Don’t implement something unless you need it right now This is a constant battle I fight with more junior programmers, who maybe have a few years of experience, but who are still getting there. They are often obsessed with "best-practices" and whatever fancy new tool is trending, but they have trouble starting with the problem they need to solve and focus…

This is in context of a one person team. The next advice makes this evident: > Remember that you can always rewrite any part of your game/engine later. This isn't the case in medium to large organizations. Usually you will just move on and rarely have the time to revisit something. This is unfortunate of course, but it means you need to build things properly the first time around and make sure it won't have a chance…

> it means you need to build things properly the first time around and make sure it won't have a chance to create bugs or side effects. I

yes! and this means you need to know everything about what you're building upfront! so now you have to do waterfall, but hide all the actual effort and pretend you're just figuring it out in the moment because agile.

Re: I learned Vulkan and wrote a small game engine with it

#144

Post by jms55 »

andrewmcwatters wrote: post #126
edflsafoiewq wrote: post #107

Earlier quoted context omitted.

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 s…

> Now instead of vendors writing this correctly once for everyone, everyone can do it poorly.

_Vendors_ did it poorly, which is why everyone wanted to get away from them. You could argue they over-corrected and left _too_ much to the user, but better safe than sorry.

Sure users can write bad code as well, but at least it's _consistently_ bad, and fully under their control. There are so many fewer problems nowadays like "oh it works on my desktop, but on this older intel GPU for a user with outdated drivers it segfaults in the driver, and there's nothing we can do to fix it ourselves".

Re: I learned Vulkan and wrote a small game engine with it

#145

Post by [deleted] »

spicyusername wrote: post #10

Lots of good advice in this article. One that stuck out to me: Don’t implement something unless you need it right now This is a constant battle I fight with more junior programmers, who maybe have a few years of experience, but who are still getting there. They are often obsessed with "best-practices" and whatever fancy new tool is trending, but they have trouble starting with the problem they need to solve and focus…

[deleted]

Re: I learned Vulkan and wrote a small game engine with it

#146

Post by Animats »

dc443 wrote: post #117
dc443 wrote: post #116

Earlier 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

Short version: hope, yes. Obtain now, no.

Long version: https://github.com/gfx-rs/wgpu/discussions/5525

There's a lock stall around resource allocation. The asset-loading threads can stall out the rendering thread. I can see this in Tracy profiilng, but don't fully understand the underlying problem. Looks like one of three locks in WGPU, and I'm going to have to build WGPU with more profiling scopes to narrow the problem.

Very few people have gotten far enough with 3D graphics in Rust to need this. Most Rust 3D graphics projects are like the OP's here - load up a mostly static scene and do a little with it. If you load all the content before displaying, and don't do much dynamic modification beyond moving items around, most of the hard problems can be bypassed. You can move stuff just by changing its transform - that's cheap. So you can do a pretty good small-world game without hitting these problems. Scale up to a big world that won't all fit in the GPU at once, and things get complicated.

I'm glad to hear from someone else who's trying to push on this. Write me at "nagle@animats.com", please.

For a sense of what I'm doing: https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ

Re: I learned Vulkan and wrote a small game engine with it

#147

Post by proc0 »

exe34 wrote: post #143
proc0 wrote: post #94

Earlier quoted context omitted.

This is in context of a one person team. The next advice makes this evident: > Remember that you can always rewrite any part of your game/engine later. This isn't the case in medium to large organizations. Usually you will just move on and rarely have the time to revisit something. This is unfortunate of course, but it means you need to build things properly the first time around and make sure it won't have a chance…

> it means you need to build things properly the first time around and make sure it won't have a chance to create bugs or side effects. I yes! and this means you need to know everything about what you're building upfront! so now you have to do waterfall, but hide all the actual effort and pretend you're just figuring it out in the moment because agile.

I agree, and would add that agile is bad because it's used to iterate along the product vertical, so first create an MVP, then add features. Instead it could be used to iterate from a technical standpoint, first adding the helper functions, then the interfaces, then some of the core functionality.. but the problem there is that most orgs prefer immediate "business value" at the cost of long term good engineering. In some cases, when the application is meant to be short-lived this makes sense, but more often than not I've seen teams suffer from this approach, not realizing they have been digging their own hole for years.

Re: I learned Vulkan and wrote a small game engine with it

#148

Post by Animats »

jms55 wrote: post #128
dc443 wrote: post #117

Earlier quoted context omitted.

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 ge…

> The solution is multiple queues. Modern GPUs have a dedicated transfer/copy queue separate from the main general purpose queue.

Yes. This is the big performance advantage of Vulkan over OpenGL. You can get the bulk copying of textures and meshes out of the render thread. So asset loading can be done concurrently with rendering.

None of this matters until you're rendering something really big. Then it dominates the problem.

Re: I learned Vulkan and wrote a small game engine with it

#149

Post by rychco »

I’ve been lurking & following your project for months in the Graphics Programming discord as I work on my own hobby Vulkan engine. It’s been inspiring seeing all the progress you’ve made. I especially admire your willingness to ask questions & share your work-in-progress so openly. Keep up the great work

Re: I learned Vulkan and wrote a small game engine with it

#150

Post by exe34 »

proc0 wrote: post #147
exe34 wrote: post #143

Earlier quoted context omitted.

> it means you need to build things properly the first time around and make sure it won't have a chance to create bugs or side effects. I yes! and this means you need to know everything about what you're building upfront! so now you have to do waterfall, but hide all the actual effort and pretend you're just figuring it out in the moment because agile.

I agree, and would add that agile is bad because it's used to iterate along the product vertical, so first create an MVP, then add features. Instead it could be used to iterate from a technical standpoint, first adding the helper functions, then the interfaces, then some of the core functionality.. but the problem there is that most orgs prefer immediate "business value" at the cost of long term good engineering. In…

> so first create an MVP, then add features.

It seems to guarantee technical debt starts to build as soon as possible and as fast as possible!

(I.e. I'm referring to agile as it is practised, not the true scotsman's agile. We apply the same rigour towards socialism.)

Post reply on HN