No way to manually destroy memory blocks before Device is destroyed
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- rust
- Lĩnh vực
- computer-graphics
Hướng nghiên cứu
Bắt đầu từ điểm vào của Allocator và hành vi Drop của nó, sau đó theo dõi cách các khối bộ nhớ cuối cùng được giữ lại và giải phóng. Công việc được hoàn tất khi các bên gọi có thể giải phóng rõ ràng các khối trống trước khi hủy device, đồng thời vẫn giữ nguyên hành vi vòng đời hiện tại của Allocator.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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?
- Ngôn ngữ chính
- Rust
- Star
- 500
- Fork
- 87
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Traverse-Research/gpu-allocator
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Traverse-Research/gpu-allocator#286 · 1 reaction ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Traverse-Research/gpu-allocator#103 · 1 bình luận ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 52/100
Traverse-Research/gpu-allocator#313 · 2 bình luận · 1 reaction ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
Tất cả issue của Traverse-Research/gpu-allocator
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
ActivityWatch/aw-notify-rs#47 · 1 bình luận ·
-
`inverse()` of a controlled `CUGate` drops the phase parameter γCó thể đã có người làm @rupasri118 đã nhận hôm nay. Đang mởbug mod: circuit
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Qiskit/qiskit#17223 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 2 ngày
-
agent:triaged bug bughunt pm:bundler priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
SocketDev/socket-patch#1573 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
rustix::termios::Termios::OutputModes does not expost some const e.g. OLCUC for musl and macOSĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
bytecodealliance/rustix#1706 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 11 ngày