MTLSharedEventListener block called before command buffer scheduling and not in-flight

Question

I am using a MTLSharedEvent to occasionally relay new information from the CPU to the GPU by writing into a MTLBuffer with storage mode .storageModeManaged within a block registered by the shared event (using the notify(_:atValue:block:) method of MTLSharedEvent, with a MTLSharedEventListener configured to be notified on a background dispatch queue). The process looks something like this:

let device = MTLCreateSystemDefaultDevice()!
let synchronizationQueue = DispatchQueue(label: "com.myproject.synchronization")

let sharedEvent = device.makeSharedEvent()!
let sharedEventListener = MTLSharedEventListener(dispatchQueue: synchronizationQueue)

// Updated only occasionally on the CPU (on user interaction). Mostly written to 
// on the GPU
let managedBuffer = device.makeBuffer(length: 10, options: .storageModeManaged)!

var doExtra = true

func computeSomething(commandBuffer: MTLCommandBuffer) {
    
    // Do work on the GPU every frame
   
    // After writing to the buffer on the GPU, synchronize the buffer (required)
    let blitToSynchronize = commandBuffer.makeBlitCommandEncoder()!
    blitToSynchronize.synchronize(resource: managedBuffer)
    blitToSynchronize.endEncoding()
    
    // Occassionally, add extra information on the GPU
    if doExtraWork {
        
        // Register a block to write into the buffer
        sharedEvent.notify(sharedEventListener, atValue: 1) { event, value in
            
            // Safely write into the buffer. Make sure we call `didModifyRange(_:)` after
            
            // Update the counter
            event.signaledValue = 2
        }
        
        commandBuffer.encodeSignalEvent(sharedEvent, value: 1)
        commandBuffer.encodeWaitForEvent(sharedEvent, value: 2)
    }
    
    // Commit the work
    commandBuffer.commit()
}

The expected behavior is as follows:

1. The GPU does some work with the managed buffer
2. Occasionally, the information needs to be updated with new information on the CPU. In this frame, we register a block of work to be executed. We do so in a dedicated block because we cannot guarantee that by the time execution on the main thread reaches this point the GPU is not simultaneously reading from or writing to the managed buffer. Hence, it is unsafe to simply write to it currently and must make sure the GPU is not doing anything with this data
3. When the GPU schedules this command buffer to be executed, commands executed before the encodeSignalEvent(_:value:) call are executed and then execution on the GPU stops until the block increments the signaledValue property of the event passed into the block
4. When execution reaches the block, we can safely write into the managed buffer because we know the CPU has exclusive access to the resource. Once we've done so, we resume execution of the GPU

The issue is that it seems Metal is not calling the block when the GPU is executing the command, but rather before the command buffer is even scheduled. Worse, the system seems to "work" with the initial command buffer (the very first command buffer, before any other are scheduled).

I first noticed this issue when I looked at a GPU frame capture after my scene would vanish after a CPU update, which is where I saw that the GPU had NaNs all over the place. I then ran into this strange situation when I purposely waited on the background dispatch queue with a sleep(:_) call. Quite correctly, my shared resource semaphore (not shown, signaled in a completion block of the command buffer and waited on in the main thread) reached a value of -1 after committing three command buffers to the command queue (three being the number of recycled shared MTLBuffers holding scene uniform data etc.). This suggests that the first command buffer has not finished executing by then time the CPU is more than three frames ahead, which is consistent with the sleep(_:) behavior. Again, what isn't consistent is the ordering: Metal seems to call the block before even scheduling the buffer. Further, in subsequent frames, it doesn't seem that Metal cares that the sharedEventListener block is taking so long and schedules the command buffer for execution even while the block is running, which finishes dozens of frames later.

This behavior is completely inconsistent with what I expect. What is going on here?

P.S. There is probably a better way to periodically update a managed buffer whose contents are mostly modified on the GPU, but I have not yet found a way to do so. Any advice on this subject is appreciated as well. Of course, a triple buffer system could work, but it would waste a lot of memory as the managed buffer is quite large (whereas the shared buffers managed by the semaphore are quite small)

Answer 1

I think I have the answer for you, but I'm not sure.

From MTLSharedEvent doc entry

Commands waiting on the event are allowed to run if the new value is equal to or greater than the value for which they are waiting. Similarly, setting the event's value triggers notifications if the value is equal to or greater than the value for which they are waiting.

Which means, that if you are passing values 1 and 2 like you show in your snippet, if will only work a single time and then the event won't be waited and listeners won't be notified.

You have to make sure the value you are waiting on and then signaling is monotonically rising every time, so you have to bump it up by 1 or more.