Memory Overcommitment
Opened this issue · 2 comments
Currently, on devices with >1GiB of VRAM, 512MiB is eagerly allocated. On other devices, this number is smaller at 128MiB. On the demo_app example, these numbers are further doubled due to the existence of two renderers. Measuring the true usage of these allocations in a pessimistic case (opening every possible window in demo_app) true usage for a single renderer is around 5MiB, a 100x overcommitment!
This is due to the use of StandardMemoryAllocator::new_default in util::Allocators::new_default, which is not user-configurable and assigns these default heap sizes. It would be fairly unobtrusive to reduce these to a more reasonable size with the ability to grow (For apps which need large amounts of images for example, or user callbacks that allocate a lot).
However I think an inversion of control for the allocators would be a much better solution - allowing the user to optionally provide the allocators, pre-informed with block sizes for Vertex+Index, Image Stage, and Image memory. This would further allow the user to specify an allocator that they are already using, allowing better sharing of resources between this crate and user code and allow the user code to choose block sizes that match their egui usecase.
I am prepared to make either change myself, but would like feedback on the API change that the inversion of control would bring and if that fits the ethos of this project! ^^
However I think an inversion of control for the allocators would be a much better solution - allowing the user to optionally provide the allocators, pre-informed with block sizes for Vertex+Index, Image Stage, and Image memory. This would further allow the user to specify an allocator that they are already using, allowing better sharing of resources between this crate and user code and allow the user code to choose block sizes that match their egui usecase.
This sounds good to me!
I would also prefer the memory allocators being controlled by the user