Even if you try to only allocate one buffer (for example) to split up and use for all your logical vertex buffers, you still have to manage memory within that buffer, which ends up leading to pretty much the same kinds of complex reasoning you need for ordinary dynamic allocation. Failure to do this properly results in resource leaks on both the GPU and CPU side which can be really nasty.
Of course, this all depends on the complexity of your renderer. For simple usecases you might be able to get away with no deallocation until exit. But they'd have to be really simple.
Exactly. You can just bulk allocate all the memory for the frame at the beginning and drop the entire thing after the frame is finished. This is a very easy case for manual memory management where you have one allocation and one deallocation per frame.
Or you can do one better, and keep an arena for each framebuffer, and then just recycle them and never deallocate at all. If you really need some level of dynamism in terms of memory usage, you can just double the size of the arena every time you fill it, and you still don't need to deallocate, since chances are you will need that space again for some frame in the future.
I think maybe it would be helpful if you would go look at the actual implementation of a nontrivial renderer and try to find one that doesn't allocate. Because the strategies you're describing don't match my experience working on renderers, at all.
> GPU resources in particular need to wait on fences and therefore can't have a neatly defined lifetime like what you're proposing unless you block your whole program waiting for these fences, while other GPU resources are (like I said) immutable and need to live for multiple frames.
I don't quite understand why fences are a problem here. As long as you know what frame a resource corresponds to, you just to have to guarantee that the entire frame is finished before reusing. You don't need to know what's happening at a granular detail within the frame.
As far as static resources, that's easy: another arena for static resources which grows as needed and is shared between frames. Most of that data is living on the GPU anyway, so you just need to keep a list of the resource handles somewhere, and you're going to want a budget for it anyway, so there's no reason not to make it of finite size.
> More generally, how do you track resources other than the framebuffer, which are usually managed very dynamically and often appear and disappear between frames?
See the whole issue is trying to solve the issue "more generally". In many cases, you can know exactly the resources you will need (or at least the upper limit) when you start rendering a given scene. If you need to do any memory management at all, you can do it at neatly defined boundaries when you load/unload a scene.
The only time when you need some kind of super dynamic renderer is when you are talking about an open world or something where you are streaming assets.
Most of the serious renderers are written in C++ using custom allocators, which are just some kind of arena allocator under the hood anyway.
(1) You are manually managing an allocator on top of the GPU resources in the arena (reintroducing the usual use after free problems). (2) You have written a highly specialized renderer that cannot be reused across programs, as it requires all GPU resources used in any scene to fit into memory at once (and for their exact quantity to be known).
Once you acknowledge that asking for dynamic GPU resource allocation, the rest of what I asked about follows; for instance, you can't reuse whatever portion of the already-allocated resources were freed at the end of the frame unless you can track used resources across frames; you can then either trace the open command buffers each frame or whatever (tracing all the live resources) or use something like reference counting and free once the fence is done (tracing all the dead resources). Hopefully you will acknowledge neither of these is the same as arena allocation.
"dynamic GPU resource application isn't needed for a useful renderer" certainly sounds good, but again does not jive with my experience with renderers (admittedly, most of this involves rendering an open world with streaming assets, but most examples I've seen that aren't super tightly constrained examples require resource reuse of some sort).
Zero the buff and reuse this same frame as the new frame.
Look at all the very smart people that tried and completely failed to write libraries that do such basic things as copying strings.
In practice this pretty much cannot be done unless you use a formal verification framework, which almost no one does. Even the most well-resourced projects written in C tend to have trouble with low-level bugs. Same goes for C++. Both the Linux kernel and Chromium have plenty of these issues.
You can also live forever, if you have right combination of genetics and environment.
There should be a list of these language snowball avalanches somewhere. They work every time.
I mean it is possible. In the same way all molecules of air could bunch up in one corner of the room suffocating you. It's a possibility.
It is possible to write safe C, only if one uses static analysis tools and undefined behaviour sanitizers. In the case presented by the article, as it is related to game, safety does not matter much, unlike device drivers, operating systems or embedded systems where C bugs can introduce security vulnerabilities.
Regarding the compile-time complaint, it is possible to reduce the compile-time by using forward declarations; forward template declarations; template forced instantiation and isolating large parts of a project in a static library using CMake.
I don't know about that... C++ (both the language and the library) is orders of magnitude more complex, and the opportunities to make mistakes have grown almost proportionally. (Two characteristic examples recently discussed here on HN: auto references and iterator invalidation.)
However using C in the case of the original poster does not matter much as the application is game-related not subject to untrusted input.
It is pity there is no alternative "standard library" with safer data struct and operations.
There are some attempts, for example, relatively wildly known klib: https://github.com/attractivechaos/klib
C++ on the other hand has good expressivity that can better deal with complexity of programs (eg. just simply having string, vector, etc) at the expense of some added language complexity. But unfortunately most of that is due to backward compatibility.
My opinion is that program complexity is inherent for anything interesting, so the C++ tradeoff is worthwhile. Also, by sticking to a good subset of C++, one can minimize the “bad” complexity of the language, imho.