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

Delayed texture deletion (Fixes #28) #71

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

Conversation

thp
Copy link
Contributor

@thp thp commented Feb 10, 2019

Since I ran into a crash a few times already by now, here's a patch that delays the "real" deletion of the texture until a swap operation (or until vita2d_gc_textures() is called manually).

This way, a library user can just allocate and free textures normally and not have to worry about freeing textures too early, vita2d will take care of delaying the deletion until the next swap. Note that right now all free texture operations are delayed, even in cases where a texture wasn't used in the current frame (and could potentially be freed immediately).

Apart from the linked list overhead, the only situation when this would be bad is if an application allocates and frees textures while drawing, and these free operations are delayed until the swap. But for this case, the application developer can use vita2d_gc_textures() to explicitly flush the free operations before vita2d_swap_buffers().

@thp thp force-pushed the delayed-texture-deletion branch from d89c75e to 57da4f5 Compare September 17, 2022 19:04
@thp
Copy link
Contributor Author

thp commented Sep 17, 2022

Rebased against latest master branch.

@thp
Copy link
Contributor Author

thp commented Dec 20, 2022

@xerpi When you have a moment, can you have a quick look if this is something that can be merged?

@xerpi
Copy link
Owner

xerpi commented Dec 20, 2022

@Rinnegatamante what do you think?

@Rinnegatamante
Copy link
Contributor

Personally I don't like the approach, wait_rendering_done can be very expensive depending on the scene and putting CPU on wait for freeing textures can result in huge stutters. I'd suggest a more "delayed" approach like the one I used in vitaGL. In vitaGL, in order to avoid busy waiting for GPU, all resources that must be freed and are used at least once by the gpu get marked for garbage collection (if gpu never used it, it's instantly freed instead) and garbage collection works each frame in async on a separate thread (but i also have a preprocessor flag to make it run on main thread eventually) freeing textures marked for deletion 3 frames before. This ensures that we never end up freeing data still in use by the GPU and completely skips any busy wait.

Some references:

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.

3 participants