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

151–160 of 268 posts

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

#151

Post by jms55 »

Animats wrote: post #141
jms55 wrote: post #123

Earlier quoted context omitted.

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

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

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

#152

Post by andrewmcwatters »

Waterluvian wrote: post #89

Are there any examples of an academic attempt at putting as much of a game into the GPU as possible? Like, architecting a game in a way that pretty much everything, including game logic, could be implemented as a shader?

Shadertoy is your best bet. There are a few people doing it there.

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

#153

Post by edflsafoiewq »

cluoma wrote: post #55
fire_lake wrote: post #53

Earlier quoted context omitted.

Could someone write an OpenGL to Vulkan layer as a library so that we can target Vulkan but at a higher level of abstraction? Then gradually we can replace that library with routines optimised for the use case?

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?

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

#154

Post by bitwize »

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…

I've had to fight this battle with a Principal Engineer. He created a framework encrusted with DI malarkey that turned building a standard Koa microservice into a twisty maze of module dependency declarations and configuration objects. Just complexity on top of complexity, all for the sake of what, pulling some rows out of a database?

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

#155

Post by tombert »

SubjectToChange wrote: post #124
tombert wrote: post #103

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

Everything you said is fine, and I'm ok with OpenGL being killed/downplayed/deprecated.

What I would have really preferred is Apple releasing Metal as a standard that anyone could use. Metal is a pretty nice API that's fairly fun and easy to use. I feel like if we need a "next gen" version of a graphics API, I would have had Vulkan for super low-level stuff, and Metal or DirectX for higher-level stuff.

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

#156

Post by [deleted] »

tombert wrote: post #103

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

[deleted]

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

#157

Post by troad »

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…

OpenGL is being sunset, no one cares about Metal, and the only people who voluntarily write Vulkan are bearded code wizards taking the weekend off from writing the kernel.

There's no end of frameworks and engines out there, most unfinished, and all extremely opinionated about what your code must look like. ("You will build scene trees that hold callbacks. Actually no, you will write entity and component classes and objects. Wait, forget that, everything is immediate mode and functional and stateless now!")

Add all the platform nonsense on top (push notifications for a mobile game? In-app purchases? Mandatory signing via Xcode?) and it's all just a hot mess. There's a reason Unity has the market share it does, and it's not because it's a fantastic piece of software. It's because cross-platform for anything more complex than a glorified web view (which is, to be fair, most non-game apps) is still a massive pain.

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

#158

Post by wmil »

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…

OpenGL is deprecated on MacOS, so there's an argument that it's on it's way out and may not be supported in the future.

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

#159

Post by Ono-Sendai »

Animats wrote: post #148
jms55 wrote: post #128

Earlier quoted context omitted.

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…

I believe you can do loading texture data onto the GPU from another thread with OpenGL with pixel buffer objects: https://www.khronos.org/opengl/wiki/Pixel_Buffer_Object

I haven't tried it yet, but will try soon for my open-source metaverse Substrata: https://substrata.info/.

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

#160

Post by Ono-Sendai »

Animats wrote: post #146
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

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.
Post reply on HN