For resizable BAR, we don't want to endlessly promote UPLOAD heaps to
BAR since VRAM is precious. The aim is to set a fixed budget where we
can keep allocating until full, at which point we fall back to plain HOST.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
With BAR budgets, what will happen is that
- Small allocation is requested
- A new chunk is requested
- try_suballocate_memory will end up calling allocate_memory, which
allocates a fallback memory type
- Subsequent small allocators will always end up allocating a new
fallback memory block, never reusing existing blocks.
- System memory is rapidly exhausted once apps start hitting against
budget.
The fix is to add flags which explicitly do not attempt to fallback
allocate. This makes it possible to handle fallbacks at the appropriate
level in try_suballocate_memory instead.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
We will need to consider some form of budgeting, so make sure that all
allocation and freeing is done in a central place.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Need to consider that based on host visibility requirements, we need to
select either LINEAR or OPTIMAL image types, and those tiling modes can
have different memory requirements.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Adds the "upload_hvv" config flag, which will make D3D12_HEAP_TYPE_UPLOAD attempt to use host-visible VRAM for allocations.
This takes advantage of large or resizable BAR if available.
I see a perf delta of 83-84 -> 92-94 (~12%) when using this in Horizon Zero Dawn.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
We cannot use the memory requirement output, since we will zero-clear
memory with a size that might be larger than the VkBuffer size.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
When building acceleration structures, we need to have an
VkAccelerationStructureKHR object, but the D3D12 API just uses a plain
VA = ID3D12Resource::GetGPUVA() + offset.
For this to work, we need to resolve the VA back to VkBuffer + offset.
The only VkBuffer we can lookup is the original backing memory
allocation in the VA map, and that allocation itself must own a view
map, since we cannot tie the VA to any specific ID3D12Resource.
Since creating an RTAS is not the common path, we allocate the view map
on-demand with CAS.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
The difference between a range's offset and the aligned
offset may be greater than the size of that range.
Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>
This is still useful as a low-level memory allocation function when
we don't want to bother with buffer offsets or D3D12 validation.
Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>
Our clear code assume that this is NULL for allocations owned
by a chunk, so we should actually do it that way. Fixes some
issues where we do not wait for clears to complete if a chunk
gets destroyed.
Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>
This is necessary to keep the amount of allocated memory manageable
in games that allocate a lot of small heaps or committed resources.
Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>