Hacker News Reader

Comment by wudangmonk | Hacker News Reader

Its great to have more Vulkan resources but unfortunately this one too suffers from the same problem as every other resource I've found on getting something on the screen with Vulkan.

They all introduce another layer of abstraction on top of Vulkan even before giving you the simple case without it. Its always use vk-bootstrap, volk, vma or someother library.

Is there a single resource anywhere that gives an example of doing the memory management manually because I havent found one, it seems like its either use vma or go figure out the spec are the only choices you are given. Is it too much to ask to just get the most basic example without having to add any libraries other than the Vulkan sdk itself?.

View on HN

there's a common gamedev practice of allocating a big chunk of memory up front, and then using a bump allocator inside of it

in most games, there are about 3 "lifetimes": - permanent/startup - per-level - per-frame

and they're nested. so, you can use a single stack allocator for all of them. at the end of the frame/level, pop back to where it started

there are more complicated patterns, but this one will get you pretty far. you can use it on the CPU and the GPU

where to read more? any books? articles?

game engine architecture, by jason gregory

there's a section on memory allocation patterns

i believe casey muratori talks about allocation patterns in the handmade hero video series, too

edit: ryan fleury has a talk: https://www.rfleury.com/p/enter-the-arena-talk

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.

Yes. It's too much to ask. Even the "official" examples by documentation do not do it. Reading the Vulkan specifications is an exercise in practicing technical bullshit.

When you're corroborating some random person's third-party instructions on initializing Vulkan and comparing those notes to what's done in Khronos Group repositories and reading the Vulkan 1.3 spec and realizing you have to read the specification out-of-order to get anything done, it's clear that they failed.

They failed. It's bad work by any other standard. But you'll do the work once and forget about it for the most part, so professionals don't complain too much.

Read my other comment in this thread for a portion of source code annotated with the specification chapters and sections.

It's a generic implementation that can be used with SDL and others.

Edit: As of the time of writing, the standard approach is to use VMA and Volk, both of which are included with the official Vulkan SDK. That should tell you enough about the state of the art.

Reply on news.ycombinator.com