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

131–140 of 268 posts

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

#131

Post by jms55 »

cogman10 wrote: post #75
Keyframe wrote: post #68

Earlier quoted context omitted.

I think Vulkan was a mistake. Maybe I should say OpenGL Next should've been a (priority) thing and Vulkan could still happen on the side.. and not this, push towards everything Vulkan. It's not for everybody and not everybody needs it (nor deserves it).

I don't think it's a mistake, I think it's targeted and leveraged poorly. Vulkan is a great idea for a general game engine or backing something like OpenGL. It's a low-level abstraction that should allow you to do something like use OpenGL 8.0 on a GPU that has long lost support for from its manufacturer.

Exactly this. Vulkan, especially Vulkan 1.0, was never really meant directly for graphics developers. It was meant specifically for engine developers that didn't want to have to deal with buggy and inconsistent drivers, e.g. Nvidia vs AMD vs crappy Android phones.

The solution Vulkan came up with was "make everything as explicit and user-controlled as possible", and leave "implementing a more user friendly driver" up to user-space, so that it could be tweaked by users, wouldn't be tied to driver updates users would never do, would be consistent across platforms, etc.

Except that never really happened. There are some graphics-driver-as-a-library projects (daxa, nabla, etc), but none with a large amount of community support.

Meanwhile GPU's evolved over time (AMD RDNA1, Nvidia Turing, Intel Arc, Apple Silicon), and it turns out that some of the choices Vulkan 1.0 bet on weren't great (explicit extensive pipeline state, binding model, render passes).

Vulkan 1.2/1.3 cleaned up a lot of this (dynamic state, descriptor indexing, sync v2), which also happens to improve ergonomics a lot to the point that it's much less painful to use Vulkan directly nowadays, as long as you're ok dropping support for older platforms.

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

#132

Post by stouset »

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…

Most importantly, you need to get interfaces right. The right interface that allows the caller to express their underlying intent allows you to rewrite bits of the implementation as-needed without forcing a rewrite from your downstream consumers.

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

#133

Post by dc443 »

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…

Thank you. I hope to see progress in these areas when I visit later. I was hoping to be able to go all in on wgpu but if there are still legitimate reasons like this one to build a native app, then so be it.

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

#134

Post by edflsafoiewq »

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…

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.

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

#135

Post by stouset »

cubefox wrote: post #101
xedrac wrote: post #67

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

In my 25-year career I’ve experienced easily fifty times as much pain from underthought and hastily-implemented systems than I have from overengineered ones.

Sure, build user-facing stuff cheaply and ready to be thrown away as requirements change. But libraries, tooling, and infrastructure that everything else is built on top of should have thought and care invested in it. This will return dividends.

We spend so much time as an industry worried that somebody might put five percent more effort into a project than it’s worth, that the overwhelming majority of engineers have no idea whatsoever of how to build something to be reliable, to be easily iterated on, and to last. And so we spend tens of times more effort trying to build on top of a mountain of crap.

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

#136

Post by jokoon »

MajimasEyepatch wrote: post #24
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…

> Vulkan is an example of how the AAA gaming industry is skewed towards rendering quality and appearance. AAA game studios justify their budget with those very advanced engines and content, but there is a growing market of 2D/low poly game, because players are tired and realized they want gameplay, not graphics. I think the driver here is more likely the financial reality of game development. High-fidelity graphics a…

Yes, I agree.

With current hardware and tools, it becomes much cheaper to reach graphics quality that is 10 or 15 years old, so such game would be just enough and be profitable enough.

I think that high quality rendering is reaching a tipping point where it's mostly of diminishing returns, this means AAA studios could differentiate with good graphics, but this becomes less and less true.

Gameplay matters, and the innovation is not the on the side of AAA studios.

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

#137

Post by jms55 »

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

Thank you. I hope to see progress in these areas when I visit later. I was hoping to be able to go all in on wgpu but if there are still legitimate reasons like this one to build a native app, then so be it.

It depends on your requirements and experience level. Using WebGPU is _much_ easier than Vulkan, so if you don't have a lot of prior experience with all of computer graphics theory / graphics APIs / engine design, I would definitely start with WebGPU. You can still get very far with it, and it's way easier.

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

#138

Post by jms55 »

exDM69 wrote: post #23
galangalalgol wrote: post #11

Earlier quoted context omitted.

Interesting, for a while the guidance for a while was to learn webgpu instead unless you needed all that extra control. Do you think these changes modify that guidance?

With WebGPU/wgpu you don't get mesh shaders, ray tracing or shader subgroup/wave/warp operations. Its feature set is comparable to Vulkan 1.0, and Vulkan has progressed a lot since. And WebGPU still requires all the RenderPass setup code which is a lot of boilerplate that Vulkan no longer requires.

Subgroups have actually been added very recently. The rest, sadly missing (along with multi-queue and bindless) :(

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

#139

Post by andrewmcwatters »

edflsafoiewq wrote: post #134
andrewmcwatters wrote: post #126

Earlier quoted context omitted.

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…

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.

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

#140

Post by izacus »

tombert wrote: post #105
izacus wrote: post #98

Earlier quoted context omitted.

Vulkan was always designed to be extremely low level API and with an idea in mind, that libraries would be required to get it up to level of OpenGL/DX11 and others. So in this respect, extensively using libraries on top of it is very normal, just like you don't write your software against syscalls these days.

That's what bothers me though; why not have an official higher level API that's less awful to use? Instead you get a bunch of third party libraries bolted on top of everything.

Why though? Khronos doesn't have the best record of API design and there's plenty of other projects that are much higher level and simpler to use for a newbie developer. You can scroll just a bit up and see just how many webdevs end up using webgpu which is closer to the abstraction they prefer.
Post reply on HN