Expose gpu allocation configuration options #5875
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nical
force-pushed
the
memcfg
branch
5 times, most recently
from
b224d38
to
c50b4f2
Compare
This commit adds hints to control memory allocations strategies to the 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 is that I am convinced that optimal fonigurations should take hardware capabilities into consideration. It's a deep rabbithole, though, so that will be an exercise for later.
nical
commented
Jul 3, 2024
Wumpf
reviewed
Jul 7, 2024
There was a problem hiding this comment.
looking good overall, great to start to expose this!
The Manual configuration is indeed a bit unforunate that it doesn't map well to either backend 🤔 . Not too strong feelings about it since the path forward is pretty clear (switch to gpu_allocator and expose its config more or less verbatim)
Co-authored-by: Andreas Reich <r_andreas2@web.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Connections
Addresses #5869
See also Traverse-Research/gpu-allocator#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.