-
Notifications
You must be signed in to change notification settings - Fork 31
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
Temporary buffers #12
Comments
Somewhat addressed by 36109ea with the addition of |
I've been prototyping this a bit, and still haven't found a concise and efficient solution. I believe, something like
The lack of access to memory is still a problem. We could refactor it to have access to memory by adding an indirection, which is probably OK. What bothers me is that this approach wouldn't be most efficient anyway. The most efficient one is to do a buffer belt, basically. Now that's mostly backend-agnostic, and is already exposed. But it's not as nice to use. There is a reduced scope function that we can expose though - something like |
There is often a need to create a buffer knowing that it's going to perish on the next submit. Exposing a nice API for this is, however, not trivial. I could see at least 3 different approaches:
temporary: bool
flag tostruct BufferDesc
and allocate accordingly. This helps with performance of small allocations, but it doesn't have with ergonomics: the user still has to know when to delete the buffers.CommandEncoder::create_temporary_buffer
, which would automatically manage its lifetime and destroy whenever the underlying command pool is reset. As nice as this sounds from the ergonomics point of view, it has implementation caveats:- the logic of tracking temporary buffers is backend-agnostic. We could try moving it into a shared implementation, it's not a lot of code.
- when inside a transfer pass (or any other), we can't borrow
CommandEncoder
even immutably... We could re-expose this method on the encoders.- in Vulkan backend, the command encoder doesn't have access to memory. Could be exposed?
The text was updated successfully, but these errors were encountered: