This is needed to enable advanced material patching, where the material
can be picked up based on source type, render mode, surface number, etc
etc and all of the above combined if needed.
Previous scheme was picking up materials very late when all of this info
has been already lost.
Fixing pool allocator to properly signal allocation failure uncovered an
existing issue where we were lacking enough memory for dynamic model
BLASes on Linux/amdgpu. Erroneously the same memory region was used for
>1 BLAS. Surprisingly this hasn't led to any noticeable issues so far.
Increasing accels buffer size fixes the issue.
The intent is to manage long-vs-single-frame allocations better.
Previously long allocations were map-long bump allocations, and couldn't be freed
mid-map, as there was neither a reference to the allocated range, nor a
way to actully free it.
Add a two-mode block allocator (similar to previous debuffer alloc) that
allows making long and once allocations. But now long allocations are
backed by "pool" allocator and return references to the range.
This commit doesn't do the deallocation yet, so map chaning doesn't yet
work.
- explicitly group cache-related fields
- move kusochki allocation to where it's actually used
this makes a step towards better blas management from bottom up
Draft the new accel/blas apis. Consolidate everything accel-related into
vk_ray_accel.c. Start splitting into more atomic functions. Prepare for
blas-model+kusochki split. etc etc.
The new code isn't really used yet.
1. Rename models passed to TLAS to instances.
2. Remove BLAS validation: old, doesn't make sense anymore.
3. Draft general blas mgmt approach in NOTES.md
test_shaders_room3 has lots of sprites, and currently we create a new BLAS for each sprite.
This is not great, and a proper fix would probably mean consolidating all dynamic transparent things into BLASes per render mode or something. But for now we can just increase the limit
Ivan Avdeev
Ivan Avdeev
Ivan Avdeev