AE SDK 26.5 — Metal synchronization and GPU world lifetime in PF_Cmd_SMART_RENDER_GPU

We are designing a SmartFX GPU backend for After Effects on macOS using SDK 26.5 and Metal. We plan to use the host-provided command_queuePV, input/output GPU worlds obtained through SmartFX checkouts, and temporary GPU worlds allocated through PF_GPUDeviceSuite1::CreateGPUWorld.

Our investigation has been limited to documentation and static code review; we have not executed GPU commands.

Is the following sequence supported inside PF_Cmd_SMART_RENDER_GPU?

1. Encode the required passes into an MTLCommandBuffer created from the host-provided Metal command queue, with appropriate resource retention.

2. End encoding and call commit.

3. Call waitUntilCompleted before returning from the callback.

4. Inspect the command buffer's terminal status and error.

5. Dispose of plugin-created temporary GPU worlds and check in input pixels.

6. Return success only if execution completed successfully.

We understand that commit does not establish completion. We also do not assume that Metal resource retention extends an Adobe GPU world's checkout lifetime or prevents the host from recycling its backing storage.

Could Adobe clarify the following points?

1. Synchronous completion and scheduler compatibility

Is waitUntilCompleted supported inside PF_Cmd_SMART_RENDER_GPU, including with Multi-Frame Rendering? Can blocking this callback create a dependency cycle with Adobe's scheduler, device-access locks, or previously enqueued work? What restrictions must the plugin observe?

2. Exclusive device access

Is exclusive device access already held for this selector, or must the effect call AcquireExclusiveDeviceAccess? Is waiting for Metal completion permitted while that access is held?

3. Temporary GPU world lifetime

Must all commands using a plugin-created GPU world complete before DisposeGPUWorld is called? Does the suite perform any synchronization or defer backing-storage recycling? What is the supported release point for temporary worlds and checked-out input resources?

4. Output delivery

Does AE require the callback to return before GPU execution completes, or is synchronous completion supported? If asynchronous return is required, what documented mechanism protects input/output lifetimes, establishes output readiness, and communicates late execution errors?

5. Execution errors and CPU fallback

After a Metal command buffer reaches a terminal error state, what PF_Err or other reporting mechanism should the callback use? Is CPU retry guaranteed for any GPU-render failure, or must CPU eligibility be negotiated before rendering through device setup and pre-render? How should cancellation be handled while commands remain pending?

6. Device teardown

What guarantees apply when PF_Cmd_GPU_DEVICE_SETDOWN is called? Are active render callbacks and GPU commands already drained, or must the plugin establish completion before releasing its device-specific resources?

Official SDK example

In the SDK 26.5 package we reviewed, the Metal branch of SDK_Invert_ProcAmp.cpp calls commit, checks the error immediately afterward, and subsequently disposes of its temporary GPU world without an explicit waitUntilCompleted or completion handler.

We do not infer a general synchronization or lifetime guarantee from that example.

Could you point us to the contract applicable to AE 26.5, or an official Metal example demonstrating the supported completion, error-reporting, and resource-release protocol?