You mentioned that there is information embedded in the header of the memory block to trace the source of the allocation, but what specific information is embedded?
It contains information such as the size of the memory block, the size of the alignment adjustment, the call stack ID, the segment it belongs to, and the nature of the memory block (e.g., whether it is an in-engine object or memory shared with scripts).
By call stack ID, do you mean a common ID for each C++ call stack?
Or is it a virtual call stack that is held by the script?
A unique ID is assigned and managed for each call stack captured when the memory allocation function is reached.
Regarding the format of call stack information, only C++ is available as raw call stack information, but it is reinterpreted in a form that fuses script call stacks.
Therefore, the memory allocated in the engine can also be tracked to see if its origin is a script or not.
Street Fighter 6 was introduced as a title that is relatively less prone to fragmentation. Were there any advantages or disadvantages (due to performance degradation of detailed memory allocation, etc.) gained by introducing a virtual memory allocator?
Street Fighter 6 consists of a fighting game mode, which is less prone to fragmentation, and multiple game modes with open-field and online elements.
Although the conventional allocator is sufficient for the fighting game mode alone, the virtual allocator was introduced to solve the problem of memory allocation failure due to fragmentation mainly in the game modes with open field elements.
Performance degradation when allocating small amounts of memory did not affect the fighting game mode, as the necessary memory is almost always resident in the game.
In the open field, there were some situations where performance was inferior to the conventional allocator, but there was no significant performance degradation for allocations in the sizes most frequently used.
You mentioned that VRAM was already supported. Are resources deployed in VRAM, such as textures, included in the scope of allocators in this presentation? Or were memory allocators such as render targets and textures integrated afterwards?
Resources deployed in VRAM, such as textures, are handled by a memory allocator for VRAM that we already had.
The allocator introduced here handles only CPU-side memory.
As for combining them, it was not part of the scope of the title we discussed.