-
-
Notifications
You must be signed in to change notification settings - Fork 4k
Fixed memory leak in bindless material #19041
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
nice |
Does this also fix #18808 ? Or is this only touching materials? |
only materials |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"looks right"
@@ -1129,6 +1093,14 @@ where | |||
.expect("Texture array should exist") | |||
.insert(binding_resource_id, texture_view); | |||
allocated_resource_slots.insert(bindless_index, slot); | |||
|
|||
if let Some(pre_existing_slot) = pre_existing_slot { | |||
assert_eq!(*pre_existing_slot, slot); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these be debug_assert_eq!
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR makes pre_existing_slot
here kinda redundant. Its just a sanity check to make sure everything is working correctly.
I can make it a debug assertion if you think that would be better.
Instead of using the pre_existing_slot
ideally we want to know if a allocation has actually been made (we should get this from the insert API). The pre_existing_slot
is mostly a easy way to check that.
seems to have been fixed by another PR already |
|
MY BAD, my test (#19311) was wrong, it still exists |
# Objective Fixed #19035. Fixed #18882. It consisted of two different bugs: - The allocations where being incremented even when a Data binding was created. - The ref counting on the binding was broken. ## Solution - Stopped incrementing the allocations when a data binding was created. - Rewrote the ref counting code to more reliably track the ref count. ## Testing Tested my fix for 10 minutes with the `examples/3d/animated_material.rs` example. I changed the example to spawn 51x51 meshes instead of 3x3 meshes to heighten the effects of the bug. My branch: (After 10 minutes of running the modified example) GPU: 172 MB CPU: ~700 MB Main branch: (After 2 minutes of running the modified example, my computer started to stutter so I had to end it early) GPU: 376 MB CPU: ~1300 MB
# Objective Fixed #19035. Fixed #18882. It consisted of two different bugs: - The allocations where being incremented even when a Data binding was created. - The ref counting on the binding was broken. ## Solution - Stopped incrementing the allocations when a data binding was created. - Rewrote the ref counting code to more reliably track the ref count. ## Testing Tested my fix for 10 minutes with the `examples/3d/animated_material.rs` example. I changed the example to spawn 51x51 meshes instead of 3x3 meshes to heighten the effects of the bug. My branch: (After 10 minutes of running the modified example) GPU: 172 MB CPU: ~700 MB Main branch: (After 2 minutes of running the modified example, my computer started to stutter so I had to end it early) GPU: 376 MB CPU: ~1300 MB
Objective
Fixed #19035. Fixed #18882. It consisted of two different bugs:
Solution
Testing
Tested my fix for 10 minutes with the
examples/3d/animated_material.rs
example. I changed the example to spawn 51x51 meshes instead of 3x3 meshes to heighten the effects of the bug.My branch: (After 10 minutes of running the modified example)
GPU: 172 MB
CPU: ~700 MB
Main branch: (After 2 minutes of running the modified example, my computer started to stutter so I had to end it early)
GPU: 376 MB
CPU: ~1300 MB