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

161–170 of 268 posts

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

#161

Post by 0x1ceb00da »

dc443 wrote: post #116
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…

> 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 have any references? I thought all wgpu objects are wrapped with an Arc>.

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

#162

Post by tadfisher »

jms55 wrote: post #151
Animats wrote: post #141

Earlier quoted context omitted.

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.

Vulkan doesn't, but WebGPU does do synchronization and memory allocation for you.

WGPU or WebGPU? The former is the Rust crate being discussed in the quote.

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

#164

Post by Animats »

Ono-Sendai wrote: post #160
Animats wrote: post #146

Earlier quoted context omitted.

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

What I do currently is just limit the amount of data uploaded per frame. Not ideal but works.

That works better in game dev where you have control over the content. Metaverse dev is like writing a web browser - some people are going to create excessively bulky assets, and you have to do something reasonable with them.

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

#166

Post by tadfisher »

andrewmcwatters wrote: post #139
edflsafoiewq wrote: post #134

Earlier quoted context omitted.

Pushing the code into a user-space library used by many programs means bugs can be fixed once in the library, instead of being at the mercy of every vendor fixing their driver blobs.

Yeah, somehow I think putting this one on multi-million dollar companies with budgets to work on graphics work for products they sell and make actual money off of is better than having some podunkian whose popular graphics library gets consumed by a bunch of people while they make $5 each from less than 1% of their users off Patreon and GitHub Sponsors.

Those multi-million dollar companies working on graphics libraries exist. Their names are Epic Games and Unity. Unfortunately, multi-million dollar companies want to make a profit, not give away their product for free.

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

#167

Post by wilkystyle »

dynjo wrote: post #163

Highly recommend this guy’s channel, he livestreams building a Vulkan game engine and he has a crazy style too https://youtube.com/@tokyospliff?si=CMF53295xeETykbP

This is great, thanks for sharing! No kidding about the interesting style, too. Very entertaining.

For example, his quick sidebar to explain fundamental shader types was great even for me, as someone who is not that familiar with the topic (link goes to 11:20):

https://youtube.com/watch?v=azdjSi_9Xyc&t=11m20s

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

#168

Post by tadfisher »

edflsafoiewq wrote: post #153
cluoma wrote: post #55

Earlier quoted context omitted.

There is the Zink project[1]. It is an OGL to Vulkan translation layer. [1] https://docs.mesa3d.org/drivers/zink.html

But it's part of Mesa, it's not something you can drop into an app written against OpenGL to translate the calls to Vulkan right?

Where do you think comes from?

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

#169

Post by bmitc »

jokoon wrote: post #14

I think vulkan is great, but its only purpose is to take full advantage of advanced GPU features. It also leads to better performance when using advanced GPU features compared to OpenGL. Generally, I feel OpenGL is the recommended route if you don't really aim for advanced rendering techniques. There are plenty 2D /lowpoly/ps1-graphics games right now, and those don't need to use vulkan. Vulkan is an example of how t…

> Generally, I feel OpenGL is the recommended route if you don't really aim for advanced rendering techniques.

Unfortunately, Apple is holding every OpenGL app and dev hostage. It's officially deprecated by Apple. So OpenGL is not a viable cross-platform solution moving forward. Eventually, it will be completely removed from macOS, at which point it will just be an OpenGL to Metal converter that everyone uses, just like Vulkan with MoltenVK. So I feel it's better to use something like WebGPU moving forward that directly takes the stance that each OS will implement its own (perhaps multiple) backends. Unfortunately, it doesn't have the tutorials and learning material that OpenGL does. (This is from an inexperienced 3D person that's been looking into this a lot.)

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

#170

Post by bmitc »

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 a constant battle I fight with more junior programmers

This can go both ways, as senior devs can just want to use what they know.

Post reply on HN