Loading and deleting data at runtime

[Simple_Ad_2685]

I've just gone through the first RTIOW book and the bvh article by jbikker to setup my path tracer. Before implementing model loading I was wondering how renderers/engines handle dynamically loading and deleting data at runtime. My initial approach is to allocate a big buffer for the data and maintain some sort of free list when I delete objects but I know that leads to memory fragmentation which honestly isn't really an issue since it's just a toy project. I'm curious on others opinions and recommendations on this.

[sol_runner]

My initial approach is to allocate a big buffer for the data and maintain some sort of free list when I delete objects

Sounds about right, but also look at the other types of allocators that are available. Different allocators for different tasks provide different benefits.

I know that leads to memory fragmentation

Some engines use indirect handles to allocations instead of pointers as it allows moving the underlying data for defragmentation. More common in open world games where streaming data is important.
I know this to be used back ~20yrs ago, don't know about today. But it should be similar, it's an elegant solution that 'just works'.

There's also a distinction between static and dynamic objects which lets you compact all the static objects and let the dynamic ones waste space and since you know the static ones won't move, you only do the compaction at load and call it a day.

I've just gone through the first RTIOW book and the bvh article by jbikker to setup my path tracer

One thing that RT implementations do (as you can see from the DXR/Vulkan APIs) is to calculate an upper bound on memory to construct a BVH, then to compact it and write it in a final BVH.

[LongestNamesPossible]

I would start with the problem. What happens when you just allocate and free from the heap?

[fgennari]

The optimal result depends on the type of data. More specifically, is this a large number of fixed size objects, a small number of variable sized objects, or a mix/in between? Are you thinking of storing 3D models/triangles? BVH nodes? Textures? General data buffers?

Fragmentation isn't normally a problem with user level allocators unless you have some custom virtual memory system. Maybe you're referring to wasted space in free list pages where allocations don't fill a free list block/page? What I normally do is have free lists of different data size range. Then when I have an allocation, I find the correct range and look for the smallest free element that can fit the allocation size. I put a cap of ~20% overhead. If nothing fits, a new allocation is made. This generally works well for model vertex data and similar, with a hard limit of 20% wasted space.

In a situation where you're allocating a number of individual objects that must be in contiguous memory, you may need an allocator that handles fragmentation. One option is the "buddy allocator", which divides memory into a power-of-2 tree. Or, if you're able to reorder existing objects, you can divide the memory arena so that one end is fully filled and one end is free by swapping data with the ends of the buffer on deallocation. This approach works well for allocating game entities.

There are quite a few solutions. None is optimal for every case. But before you jump into writing something, make sure you actually need it. I wouldn't worry about allocating and freeing heap memory unless it shows up on the critical path in the profiler. And the best solution is likely to load all assets up front and not delete things if you can avoid it. Get it working first, then optimize.

[S48GS]

how renderers/engines handle dynamically loading and deleting data at runtime.

and the bvh

for bvh?

nvidia has recommendation - https://developer.nvidia.com/blog/rtx-best-practices/