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

181–190 of 268 posts

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

#181

Post by exDM69 »

ReleaseCandidat wrote: post #179
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 WGPU uses WebGPU and AFAIK no browser so far supports "threads". https://gpuweb.github.io/gpuweb/explainer/#multithreading https://github.com/gpuweb/gpuweb/issues/354 And OpenGL never supported "threads", so anything using OpenGL can't either.

OpenGL can do threads with shared contexts but caveats apply so it is not popular.

But even more common is mapping memory in "OpenGL thread" and then letting another thread fill the memory. Quite common is mapping buffers with persistent/coherent flags at init, and then leave them mapped.

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

#182

Post by exDM69 »

tombert wrote: post #110
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.

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 only "complex" thing remaining but even they are somewhat simplified with the right defaults (sharing mode) and simplifications (set stage masks to all commands, overhead is negligible on desktop devices).

Use push descriptors for "bindful" textures, set all your pipelines states dynamic (except blending), and timeline semaphores for sync.

For simple stuff (OpenGL level) it's a pleasure to work with, and you get rid of all the OpenGL quirks.

Complex stuff like bindless texturing and GPU driven rendering is still complex, but that's the same in all APIs.

It can still be a bit verbose and the init code is too much work (but you do it only once), but after it is set up it's quite okay.

And if you want OpenGL, use OpenGL. Zink (OpenGL on Vulkan) guarantees that it will be supported, even if GPU vendors stop keeping their GL drivers up to date (has not happened yet).

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

#183

Post by johnnyanmac »

tombert wrote: post #119
edflsafoiewq wrote: post #114

Earlier quoted context omitted.

It doesn't really make sense to have Khronos maintain nice high-level libraries. There's no evidence they'd be good at it and if you look at their GitHub, they're not particularly good at maintaining actual codebases in the first place. Their commitee/standard-based process works for specs, but I don't think it will work very well for the needs of day-to-day application programmers. Why do you need Khronos to "bless"…

> It doesn't really make sense to have Khronos maintain nice high-level libraries. I guess we'll have to agree to disagree on that. > There's no evidence they'd be good at it and if you look at their GitHub, they're not particularly good at maintaining actual codebases in the first place. Well that's another complaint then, but it doesn't detract away from my initial complaints. > Why do you need Khronos to "bless" a…

>now we're going to have a million different wrapper libraries to do everything, or you're going to be stuck with the absurd Vulkan API.

The more things change...

Fact is that most people will never directly touch such things unless they are a) a graphics programmer at a handful of companies or b) someone like this author doing something more for education than to produce raw business value. our "high level libraries" are Unity and Unreal if you're makinig a game (and some smaller engines), and BGFX et al. if you're making your own small engine. The work is already done without Khronos lifting a finger for implementation.

the recipients of a) are the ones who asked for more control. They are paid pretty well so they have plenty of time to grok the specs compared to a small time creator, so rapid prototyping isn't prioritized.

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

#185

Post by johnnyanmac »

andrewmcwatters wrote: post #171
tadfisher wrote: post #166

Earlier quoted context omitted.

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.

Those aren't graphics libraries.

They have a graphics library inside of a larger engine. And for 99% of devs they don't care about directly modifying such code, so they are fine with the stipulation of "use our tool to get graphics" approach.

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

#186

Post by torginus »

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…

Honestly, this might be a bit of a conspiracy theory, but the practical use-case of Vulkan's low-level access isn't because of PCs and consoles - it's because of smartphone manufacturers that make absolutely abysmal mobile drivers.

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

#187

Post by johnnyanmac »

beautron wrote: post #180
andrewmcwatters wrote: post #171

Earlier quoted context omitted.

Those aren't graphics libraries.

Didn't Unity and Epic have people working directly on the Vulkan specification? I remember reading a comment (maybe here!), way back during Vulkan's original release, where someone was screaming about how Vulkan was a conspiracy to make us dependent on giant, multi million dollar game engines. I don't know about any conspiring, but I've thought about that comment often, because the result appears the same: The barrie…

I know Unity does, I forget if Epic does but I'd be surprised if they didn't.

Not really a conspiracy so much as the fact that Unity/Epic have much more opinions on what a graphics library can/should be than a small engine developer. The former don't care if it takes longer to release games, they have staff around the clock working on the engine.

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

#188

Post by torginus »

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…

I don't think this is true. You can pretty much implement everything in OpenGL that you can do in Vulkan. The magic's in the shaders usually and I think there's pretty much feature parity there.

Performance isn't an issue either - with the advent of GPU-resident drawing ,meaning a compute shader filling buffers with draw parameters and drawing multiple objects with complex materials in a single draw call means there isn't much of a CPU bottleneck. Look up OpenGL AZDO if you are interested in this.

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

#189

Post by johnnyanmac »

jokoon wrote: post #136
MajimasEyepatch wrote: post #24

Earlier quoted context omitted.

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

gameplay matters, but graphics sell. Look no further at the modern state of hardcore reviewers and hyper nitpickers on social media. See how every switch game is criticized for not being 1080p60 on 2017 mobile hardware. People demand that kind of quality.

That's a loud minority, but it's not like the biggest games aren't selling more and more every year en large. So non-vocal gamers do seem to be drawn to it.

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

#190

Post by johnnyanmac »

jms55 wrote: post #131
cogman10 wrote: post #75

Earlier quoted context omitted.

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…

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

That's more on the community then, no? Same issue as OpenGL; most of the market is Windows or consoles, Windows/consoles have their own graphics api and professional suppport, the devs choose convinience over control and cross-compatibility.

Seems like a self-furfilling prophecy if devs relinquish their control to the corporations.

Post reply on HN