Skip to content
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

Trait-based allocator API #60

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Fuzzyzilla
Copy link
Contributor

First attempt at the custom allocators proposed in #57, including a default implementation providing memory sharing for multi-window apps and a much smaller VRAM allocation footprint (~72MiB combined for demo_app).

The change was rather intrusive and introduced an <Alloc> generic throughout a lot of the code, both library and client side. Not everything is implemented (namely, command buffer + descriptor allocators are not shared nor user configurable, and there is no support for the user callback API so several examples simply fail with not yet implemented).

I've stopped short because I am not sure how happy I am with this. I think I went too far in making the requirements concrete, to the point that it spills a lot of the implementation details into public view - such as the exact Image/BufferUsage needed for different operations...

@hakolao
Copy link
Owner

hakolao commented Jan 23, 2024

I've stopped short because I am not sure how happy I am with this

Might have to sit on it.

I also think this doesn't maybe quite fit what we want for the api, yet at least. If the allocator customization complicates the api too much, letting the user to configure the sizes will also be enough in the short term.

@Fuzzyzilla
Copy link
Contributor Author

My concern with simply providing sizes is the lack of sharing between user code and the Gui renderer, or between multiple Gui renderers. In my usecase, the texture staging arena will spend all of it's time unused by the Gui except in the first fraction of a second, when it could have been used for any of my app's staging needs.

I am not fully sure how egui 0.24.0 multiwindow functionality works, but if it requires multiple renderers then the ability to share memory between them seems mighty important!

I suppose the sharing between Gui instances could be solved with opaque allocator objects that implement Clone, not far from what's currently in master, keeping encapsulation. But as I've found here, sharing with the user does complicate things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants