You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Over the years we've gotten quite a few PRs to reduce the memory consumption in gpu-allocator on the CPU side and we are trying to understand why we're getting these PRs since for most use-cases we have in mind the CPU side overhead of gpu-allocator for us has been a non-issue and sometimes these PRs introduce some kind of maintenance or API burden in terms of more complex or less straightforward code.
🙋 Question to the community
What we're trying to figure out then, is why these PRs come up and what kind of use-cases folks are having where they have a need to address this general overhead. Because I'm trying to understand if this is a side-effect of gpu-allocator being a memory allocation library (and will thus attract memory focussed developers), or if there are some use-cases which we just don't see, where this is inherently a problem.
Can folks that have filed these kinds of PRs, or are planning to file some of these PRs do us 2 small favors that will make it significantly easier for us to accept these kinds of changes:
In the PR description please provide concrete measurements of the overhead from a memory profiling tool
In the PR description also provide their use-case of gpu-allocator, ideally in a way that we can understand the allocation patterns behind it
In this issue weigh in on the relevance and need for these reductions.
🔮 Going forward
We love serving this community and we think gpu-allocator is a valuable addition to the Rust community in general so we want to serve folks right, however we also have to balance maintenance cost of the library itself. Solving memory allocation is a difficult enough problem, solving it with memory constrained data structures is even harder and so some of these PRs require a careful trade-off, and understanding use-cases of gpu-allocator will only help understand if some of these trade-offs are worth it.
The text was updated successfully, but these errors were encountered:
Jasper-Bekkers
changed the title
Request For Feedback: gpu-allocator CPU side memory consumption
🥑 Request For Feedback: gpu-allocator CPU side memory consumption
Jan 9, 2025
⛰️ Background
Over the years we've gotten quite a few PRs to reduce the memory consumption in
gpu-allocator
on the CPU side and we are trying to understand why we're getting these PRs since for most use-cases we have in mind the CPU side overhead ofgpu-allocator
for us has been a non-issue and sometimes these PRs introduce some kind of maintenance or API burden in terms of more complex or less straightforward code.🙋 Question to the community
What we're trying to figure out then, is why these PRs come up and what kind of use-cases folks are having where they have a need to address this general overhead. Because I'm trying to understand if this is a side-effect of
gpu-allocator
being a memory allocation library (and will thus attract memory focussed developers), or if there are some use-cases which we just don't see, where this is inherently a problem.Can folks that have filed these kinds of PRs, or are planning to file some of these PRs do us 2 small favors that will make it significantly easier for us to accept these kinds of changes:
gpu-allocator
, ideally in a way that we can understand the allocation patterns behind it🔮 Going forward
We love serving this community and we think
gpu-allocator
is a valuable addition to the Rust community in general so we want to serve folks right, however we also have to balance maintenance cost of the library itself. Solving memory allocation is a difficult enough problem, solving it with memory constrained data structures is even harder and so some of these PRs require a careful trade-off, and understanding use-cases ofgpu-allocator
will only help understand if some of these trade-offs are worth it.🧚♀️ Some related PRs
Arc<Backtrace>
in Option, saving memory when backtraces are disabled #252The text was updated successfully, but these errors were encountered: