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

Questions about Defragmentation Thread Safety #45

Closed
rbertin-aso opened this issue Sep 23, 2022 · 7 comments
Closed

Questions about Defragmentation Thread Safety #45

rbertin-aso opened this issue Sep 23, 2022 · 7 comments
Labels
question Further information is requested

Comments

@rbertin-aso
Copy link
Contributor

Hello Adam !
Small question regarding defragmentation.

In the documentation it is written :

What it means in practice is that you shouldn't free any allocations from the defragmented pool since the moment a call to BeginPass begins.

One solution that you give is :

A solution to freeing allocations during defragmentation is to find such allocation on the list pass.pMoves[i] and set its operation to D3D12MA::DEFRAGMENTATION_MOVE_OPERATION_DESTROY instead of calling allocation->Release()

However, it is only possible to set the operation after having the pass moves (after the return of the call). Do I need to keep track of allocations that want to be released during computation time or won't it be an issue if releasing occurs ? Could it be simpler to just add a reference to allocations that ends up being part of a move and remove a reference at the end of the pass ?

Hope those questions are not stupid :)
Have a nice day !

@adam-sawicki-a adam-sawicki-a added the question Further information is requested label Sep 26, 2022
@adam-sawicki-a
Copy link
Collaborator

You are right. Just as the documentation says, allocations that can be defragmented shouldn't be released since the moment a call to BeginPass starts. I recommend to store the list of allocations to be released and defer this release to the time after the defragmentation pass is complete.

I think calling AddRef and Release to manage reference counter of all the defragmented allocations would add too much of unnecessary performance overhead.

@rbertin-aso
Copy link
Contributor Author

Thanks for those answer. I will then prefer the list of allocations.

@rbertin-aso
Copy link
Contributor Author

rbertin-aso commented Oct 3, 2022

Hello again Adam. Sorry for reopening this ticket. After reading again the documentation to be sure, I noticed this sentence :

Otherwise, a thread performing the allocation->Release() would block for the time BeginPass executes and then free the allocation when it finishes, while the allocation could have ended up on the list of allocations to move.

Is it okay to keep every allocation that need to be release into a list (that will be released after the EndPass) between the beginning and the end of BeginPass and after the end of BeginPass to keep in the list only allocations that are into the pass movements ?
To rephrase, is releasing allocations that aren't pass movements an issue if BeginPass is done ?
(I'm trying to optimize the number of allocations that go into that list because between Begin and End, it can be a lot ! )

Have a nice day !

@rbertin-aso rbertin-aso reopened this Oct 3, 2022
@adam-sawicki-a
Copy link
Collaborator

You are right, this optimization is correct. After BeginPass call finishes, only allocations that ended up on the list of movements should not be released. Other allocations can be released and new allocations can be made between BeginPass and EndPass.

@rbertin-aso
Copy link
Contributor Author

rbertin-aso commented Oct 4, 2022

Okay thanks a lot !

new allocations can be made

I'm afraid of this :). Do you mean allocations must not be made during BeginPass or just that they will be blocked by the mutex ?

@adam-sawicki-a
Copy link
Collaborator

They will just be blocked by the mutex and then execute after BeginPass, which is fine.

@rbertin-aso
Copy link
Contributor Author

Okay ! Thanks a lot for those answers !
I'm closing until next questions :D

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

No branches or pull requests

2 participants