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

191–200 of 268 posts

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

#191

Post by johnnyanmac »

SR2Z wrote: post #91
pxtail wrote: post #79

Earlier quoted context omitted.

>starting with the problem they need to solve and focusing on the minimum needed to just solve that problem To be fair if held strictly to these principles their work would revolve mostly around gluing together various Apis, services and sometimes adjusting already written software to company's needs. So I'm not surprised they are using every possible opportunity to write something here and there, this menial digital…

Yeah, I am no longer a junior engineer. When I WAS the bane of my existence was senior and staff engineers hoarding all the fun, new work for themselves and forcing me into "bitch work" where I'm just cleaning up old, broken code and handling bugs. I finally got promoted because I explicitly ignored my manager to deploy changes that were needed for my company, and that was what finally got me promoted. Of course, at…

Not just politics, I almost feel it can hamper you as an engineer. If you just do basic plumbing for 10 years, are you really an engineer with 10 YOE or one with 2YOE 5 times over because everyone needs a plumber?

2-3 years seems to be where that valuable plumbing experience starts to plateu. I don't know how engineers these days that move companies every other year even get a chance to grow when you're doing a soft restart at every job hop.

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

#192

Post by MindSpunk »

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.

Then you mustn’t have much experience working with the drivers those multi million dollar companies were (and still are) shipping to customers. They are full of bugs, quirks and performance traps. Vulkan wasn’t created because of some theoretical future problem, Vulkan was born from the real struggle of developers at the time. Problems were still struggling now.

We don’t need to speculate whether hardware vendors can ship bullet proof drivers and API implementations, they have already proven they can’t. Vulkan was built based on industry experience from organisations big enough to sit at the Khronos table. They were trying to give the vendors as little rope to hang themselves on by reducing the complexity of driver implementation because these stakeholders (large AAA studios) were collectively expending massive resources working around vendors inability to ship good quality drivers. This problem is still ongoing even with Vulkan.

Vulkan drivers on Android are a complete joke. They barely work and I’m debugging and working around a new driver bug or performance trap every few weeks at this rate. If we can’t rely on quality Vulkan drivers, an API designed to make drivers easier to implement, how will vendors fare with a much more complex to implement API like OpenGL? (poorly, look up the history of OpenGLES3).

Desktop PC is the exception because it’s the only GPU market where hardware vendors have real market pressure to deliver working drivers. Just look at Intel’s Arc launch, a product where it’s single biggest criticism and flaw citied universally is driver issues. There is no other market where this same pressure has been applied. Nobody bought a phone specifically because it had “good GPU drivers”. Unless the hardware market a vendor is selling to cares garbage drivers are the default. Qualcomm and Arm provide more than enough proof for that.

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

#193

Post by account42 »

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…

> e.g. doing a spinning cube takes several hundred lines of code

This really doesn't mean much. The second cube (or another shape) isn't going to double the line count.

> OpenGL was never "easy" but it was at least something a regular person could learn the basics of in a fairly short amount of time.

The problem is that OpenGL no longer matches current hardware so the naive way to use it is very much suboptimal for performance. Once you move to zero driver overhead techniques for OpenGL then Vulkan is not that much harder.

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

Except current Intel/ARM/AMD chips don't support C or C++ and you already have to write assembly ... or use a third-party tool to do the translation from C or C++ for you. That's also the goal for Vulkan - to provide a low level standard interface for GPUs on top of which more user friendly abstractions can be layered.

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

#194

Post by mobiuscog »

sigseg1v wrote: post #106
cubefox wrote: post #101

Earlier quoted context omitted.

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…

Totally agree, it needs a careful balance. But is it possible to know when to use what? Anecdote: A couple years ago I migrated a 1M+ LOC application from one database to another, cutting the cloud hosting costs practically in half. This was absolutely massive for the company. It took a bit less than a year, but was possible because the people who designed the application didn't write any hardcoded queries, and every…

ORMs and query builders can also constrain the implementation from a performance and flexibility perspective though.

Your anecdote and reflections are all absolutely true in my experience, but I've found just as many problems with off-the-shelf ORMs.

The key is the clean boundaries/interfaces and keeping things simple - leaving the bridge intact so that your enemies may retreat.

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

#195

Post by pjmlp »

exDM69 wrote: post #182
tombert wrote: post #110

Earlier quoted context omitted.

No, I don't think that that's good reasoning. They could, if nothing else, make first-party libraries that have a high-level DSL or something that makes it less horrible to use. As it stands it creates a bunch of crappy libraries on top instead of an officially supported API that could also be standardized across operating systems and platforms. The terrible terrible Vulkan API just kind of feels gatekeepey. They got…

Please try again with Vulkan 1.3 and reassess how "terrible" the API is. And use some high level library like vk-bootstrap to do the boring init work. Because once it's set up, Vulkan 1.3 is about as easy as OpenGL (if you stick with OpenGL-level stuff). It is easier than WGPU because the RenderPass stuff required in Vulkan 1.0 (and hence WGPU) is gone, removing a lot of boilerplate code. Pipeline barriers are the on…

It has happened on Android, version 15 is now making ANGLE the official way to still have OpenGL, given the sore state of Vulkan drivers, it is a yet another move to force OEMs to improve their story.

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

#196

Post by pjmlp »

ChadNauseam wrote: post #18
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…

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…

Compute shaders aren't available in WebGL thanks to Google, OpenGL ES does them just fine.

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

#197

Post by Cloudef »

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?

Posted this in hn few days ago https://vkguide.dev/docs/gpudriven/gpu_driven_engines/

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

#198

Post by MindSpunk »

hgs3 wrote: post #87
ChadNauseam wrote: post #18

Earlier 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

My perspective is it’s a couple things. Mainly because it’s backed by several implementations with market pressure to deliver high quality working implementations (wgpu in Firefox, Dawn in Chrome). Not saying bgfx or others are bad, but the Chrome team will be putting in a lot of work for you to make sure Dawn works well everywhere Chrome needs to be. That plus it’s super portable. First time in a long time that we could truly be looking at a “write once run anywhere” GPU API. It also fills OpenGL’s niche by being much more approachable than Vulkan. I guess this really just adds up to it being the “OpenGL 2” a lot of people have been wanting in light of Vulkan’s complexity and weaker portability.

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

#199

Post by pjmlp »

mort96 wrote: post #52
Const-me wrote: post #48

Earlier quoted context omitted.

Another good option is Direct3D 11. It’s IMO even easier to use than OpenGL but still allows to implement pretty good visuals, see GTA 5 or Baldur’s Gate 3.

Eh that's really only an option if you want to only ever target Microsoft platforms. Which is fine for some people, sure, but in a lot of situations, closing the door on Linux (Steam Deck), macOS, iOS, Android and the non-xbox consoles is a tough sell.

Contrary to urban myths, non-xbox consoles aren't that found of Khronos standards either.

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

#200

Post by alexvitkov »

ncallaway wrote: post #172
alexvitkov wrote: post #70

Earlier quoted context omitted.

Vulkan, Direct3D, Metal and OpenGL are graphics APIs - the implementation comes with your GPU driver, and they're as close as you can reasonably get to writing code "directly for the GPU". When you call a Vulkan function you're directly calling driver code. wgpu is a regular library that uses the native APIs above and abstracts them from you. I don't like calling it a graphics API because it implies it's the same as…

> The relationship between wgpu and WebGPU is that they're basically made by the same people, and in Firefox WebGPU is implemented on top of wgpu. I think that’s understating the relationship a bit. The wgpu API follows the WebGPU spec quite closely. It’s like saying “taffy isn’t flexbox”. You can make a technical argument that it’s not identical, and to be flexbox it must be in a browser, but anyone working with taf…

That's fair, my comment did understate their relation quite a lot. They are very closely linked, to the point stuff has been added to the WebGPU spec pretty-much because "eh, it's already in wgpu".

But the "knowledge is transferable to WebGPU" is key. Even when you're compiling your wgpu code to WASM, you're not using WebGPU directly - for every API call, you're going through generated bindings on the Rust side and then generated bindings on the JS side where the actual call is made. The JS wrappers aren't trivial either - Rust structs need to be converted to the nested JS objects required by WebGPU spec, numeric enums need to be converted strings, etc.

Considering that WebGPU is supposed to be the low-level graphics API for the Web, DX12/VK/Metal equivalent, all this is at least worth a mention, and "wgpu == WebGPU" brushes over a all that, to the point where we're now casually throwing statements like "[WebGPU] is guaranteed to run anywhere, including the browser".

Post reply on HN