No way to manually destroy memory blocks before Device is destroyed
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- rust
- Ambito
- computer-graphics
Direzione di ricerca
Inizia dal punto di ingresso di Allocator e dal suo comportamento di Drop, quindi traccia il modo in cui gli ultimi blocchi di memoria vengono mantenuti e rilasciati. Il lavoro è completato quando i chiamanti possono rilasciare esplicitamente i blocchi vuoti prima di distruggere il dispositivo, preservando al contempo il comportamento esistente del ciclo di vita di Allocator.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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 like vk::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, which Allocator keeps around until its Drop is run. So my GfxCtx::Drop runs, frees all allocations, destroys all Vulkan state, when the device is destroyed I get a DeviceMemory leak validation error because Allocator doesn't get dropped until afterwards.
Usually I would use core::mem::take or core::mem::drop, but that's not an option because Allocator doesn't implement Copy or Default, 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 a destroy_empty_blocks() function for a little more control over when allocations are destroyed.
Thoughts? Or am I missing something obvious?
- Lingua principale
- Rust
- Stelle
- 500
- Fork
- 87
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Traverse-Research/gpu-allocator
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Traverse-Research/gpu-allocator#286 · 1 reazione ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Traverse-Research/gpu-allocator#103 · 1 commento ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 52/100
Traverse-Research/gpu-allocator#313 · 2 commenti · 1 reazione ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
Tutte le issue di Traverse-Research/gpu-allocator
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
loongarch64: `unsupported linker arg: --no-rosegment` with rustc 1.100Forse già presa @monosans l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
rust-cross/cargo-zigbuild#503 ·
I maintainer di solito rispondono entro 1 giorno
-
bug good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
rust-lang/a-mir-formality#472 ·
I maintainer di solito rispondono entro 1 giorno
-
agent:iq3-xxs area: cli duplication enhancement priority: P3 ready-for-agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno