-
Notifications
You must be signed in to change notification settings - Fork 44
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
No way to manually destroy memory blocks before Device is destroyed #96
Comments
Hi! We use // ... more destructing here
ManuallyDrop::drop(&mut self.allocator);
ManuallyDrop::drop(&mut self.device);
ManuallyDrop::drop(&mut self.instance);
ManuallyDrop::drop(&mut self.entry); Perhaps we should list this usage in the readme examples :) |
I do this the other way around: I have wrappers for vk::Device, vk::Instance, etc that destroy them when they're dropped. That way I can use the regular drop order rules to free everything in the right order. You can even implement |
This is bit tangential, but since the last version (0.16.0) I faced memory freeing problem in my code as well. I use seemingly a similar approach as @danielkeller in which I use a wrapper for resources. I used to have a drop defined for individual buffers as well, as in here: https://github.com/periferia-labs/rivi-loader/blob/main/src/lib.rs#L744 However, since the last version the allocation cannot be owned anymore. As I have only a single memory allocator in the application, I cannot drop the allocator either because it would invalidate other buffers. I know this ask is maybe rather about Rust in general, but how would you in this case free the memory? Per this thread it is worth noting that personally I went with the Option type for the allocator itself. |
We have since cleaned up our handling of this as well (funny note: the Incidentally our
Depending on struct order to make sure the allocator is dropped before the device, etc?
We've only implemented |
@jhvst You can still own an Indeed, depending on your use-case you'll most likely have to switch to an
Note that this |
Thanks @MarijnS95 for the detailed comment! I really appreciate the help. I followed your advice and used Option. For posteriority, I also had to modify my mapping functions since in my approach these calls then caused the buffer to be dropped (I do not completely understand, nor do I really want to). I have the diff here: rivi-lang/rivi-loader@9a2b306 I'm sure there are better ways to fix this, but for now I don't have the time to make it elegant. |
At risk of explaining it against your will: I presume you wrote something along the lines of: if let Some(allocation) = self.allocation {
} That will move the if let Some(allocation) = &self.allocation {
} And all should be fine. |
Hi, I seem to have run up against a wall with how the allocator destroys memory blocks.
I have a
GfxCtx
struct that holds basically all of my Vulkan state. Contains stuff likevk::Device
,vk::Instance
,Allocator
, etc.I use the Drop trait on my
GfxCtx
struct to run the usual destruction code (eg.ash::device::Device::destroy_device
) and this is where my issue is. As far as I know, I have no way to manually destroy the last memory block for each memory type that supports general allocations, whichAllocator
keeps around until its Drop is run. So myGfxCtx::Drop
runs, frees all allocations, destroys all Vulkan state, when the device is destroyed I get aDeviceMemory
leak validation error becauseAllocator
doesn't get dropped until afterwards.Usually I would use
core::mem::take
orcore::mem::drop
, but that's not an option because Allocator doesn't implementCopy
orDefault
, respectively. Which it shouldn't!I'm no graphics programmer, but this also seems like it's not an unreasonable use case?
I could wrap it in an
Option
or something, but it seems reasonable enough to request adestroy_empty_blocks()
function for a little more control over when allocations are destroyed.Thoughts? Or am I missing something obvious?
The text was updated successfully, but these errors were encountered: