This commit adds hints to control memory allocations strategies to device configuration options. These hints allow for automatic profiles such as optimizing for performance (the default, makes sense for a game), optimizing for memory usage (typically more useful for a web browser or UI library) and specifying settings manually.
The details of gpu allocation are still in flux. The goal is to switch vulkan and metal to gpu_allocator which is currently used with d3d12. gpu_allocator will also likely receive more configuration options, in particular the ability to start with smaller memory block sizes and progressively grow the block size. So the manual settings already provision for this upcoming option. Another approach could be to wait and add the manual option after the dust settles.
The reason for providing presets and defining values in the backends instead of in platform-independent code is that I am convinced that optimal configurations should take hardware capabilities into consideration. It's a deep rabbit hole, though, so that will be an exercise for later.
Testing
The examples have a mix of Performance and MemoryUsage presets which gives some very superficial coverage, however this can't properly be tested without large/realistic workloads.
Checklist
[x] Run cargo fmt.
[x] Run cargo clippy. If applicable, add:
[x] Run cargo xtask test to run tests.
[x] Add change to CHANGELOG.md. See simple instructions inside file.
Connections
Addresses #5869 See also https://github.com/Traverse-Research/gpu-allocator/issues/235
Description
This commit adds hints to control memory allocations strategies to device configuration options. These hints allow for automatic profiles such as optimizing for performance (the default, makes sense for a game), optimizing for memory usage (typically more useful for a web browser or UI library) and specifying settings manually.
The details of gpu allocation are still in flux. The goal is to switch vulkan and metal to gpu_allocator which is currently used with d3d12. gpu_allocator will also likely receive more configuration options, in particular the ability to start with smaller memory block sizes and progressively grow the block size. So the manual settings already provision for this upcoming option. Another approach could be to wait and add the manual option after the dust settles.
The reason for providing presets and defining values in the backends instead of in platform-independent code is that I am convinced that optimal configurations should take hardware capabilities into consideration. It's a deep rabbit hole, though, so that will be an exercise for later.
Testing
The examples have a mix of
PerformanceandMemoryUsagepresets which gives some very superficial coverage, however this can't properly be tested without large/realistic workloads.Checklist
cargo fmt.cargo clippy. If applicable, add:cargo xtask testto run tests.CHANGELOG.md. See simple instructions inside file.