Open problems remaining:

• How to solve the issue with the tests not passing because the metal debug layer breaks acceleration structures if no window is present.
• When to call residency_set.endResidency()? Possibly when the next set_bind_group() call happens.
• What to do about a bindless usage of TLAS and its residency_set.

@Lichtso I think that we think of MTLResidencySets differently. I think you think of them like a encoder, where you stage commands and then commit them to run those commands. I think of them like an array of resources which get made resident when commit gets called, and requestResidency tells the driver that you are likely to try to make these resource resident, and to maybe try make them resident if it can so you don't have to block on residency commit.

I've drawn an image of what I think could happen based on my understanding of residency sets. I've used green to be user space and red to be device space.

Edit: it's not very clear, but the resources in the residency set are only made resident at queue submit (when it gets committed), not when they are added to the residency set

Yes, supposedly MTLResidencySet doesn't make a "shadow copy" whenever it is attached to anything. Instead commit() simply applies all the add/remove changes, that any command buffer to which it is attached can subsequently read to know which resources need to be made or kept resident. (Or the rest of the system can read to evict live resources when starved for memory, based on running command buffers?).

In other words it should be fine to remove live resources from a residency set, as long as those are not committed until all pending command buffers that are still referencing these resources have finished.

@Vecvec afaik the device space you have drawn isn't affected until a command buffer referencing a certain MTLResidencySet is submitted and starts running (and it'll reference the most recently committed state), or explicit residency is requested ahead of time using requestResidency() (which doesn't preclude attaching it to a queue or command buffer).

@Vecvec afaik the device space you have drawn isn't affected until a command buffer referencing a certain MTLResidencySet is submitted and starts running (and it'll reference the most recently committed state), or explicit residency is requested ahead of time using requestResidency() (which doesn't preclude attaching it to a queue or command buffer).

I don't think it was very clear that what is put in the residency set is not the same as what is made resident, I was meaning calling addAllocation which does happen in the encoder calls.

I recently also found out that residency set methods aren't thread safe, meaning that a mutex is needed around the residency set.

@Lichtso, just following up on this. Do you have any updates?

Haven't worked on this any further and objc2-metal is also not merged yet.
But yes, I think you are right that MTLResidencySet won't work in this way and we have to come up with a different approach or modify it somehow.

@Lichtso I would recommend putting the residency set in the HAL command buffer, and having a function to add to it (and possibly this could also request_residency). This allows wgpu-core to add to the set when it is in validate_acceleration_structure_actions before submit and so needs to be tracked (the unsafe function mark_acceleration_structures_built doesn't set this, so it might need to have a line stating that the BLAS must be resident on metal when being used).

Seems the objc2-metal PR was merged, time to rebase this then.

I would recommend putting the residency set in the HAL command buffer, and having a function to add to it

@Vecvec I think I found a workable solution. See last commit: 1a240b9