`simvx.graphics.gpu.sync`¶

Fences, semaphores, and frames-in-flight synchronization.

Module Contents¶

Classes¶

FrameSync

Per-frame synchronization primitives.

Functions¶

`wait_for_fence`	Wait until fence signals: patiently under load, and with a clear error if it never does.
`acquire_image`	The next swapchain image’s index, waiting for one patiently.

Data¶

`__all__`
`log`
`FENCE_PATIENCE_S`

API¶

simvx.graphics.gpu.sync.__all__¶: [‘FrameSync’, ‘acquire_image’, ‘wait_for_fence’]

simvx.graphics.gpu.sync.log¶: ‘getLogger(…)’

simvx.graphics.gpu.sync.FENCE_PATIENCE_S¶: 60.0

simvx.graphics.gpu.sync.wait_for_fence(device: Any, fence: Any, *, what: str = 'a frame') → None¶

Wait until fence signals: patiently under load, and with a clear error if it never does.

A frame can take longer than one slice on a loaded machine or a software rasteriser, which is slow and not a fault, so the wait goes on in slices, logging once when the first runs out. Only a fence still unsignalled after

Data:: FENCE_PATIENCE_S raises, naming what was being waited for, because at that point the GPU is not coming back.

simvx.graphics.gpu.sync.acquire_image(acquire: Any, device: Any, swapchain: Any, semaphore: Any) → int¶

The next swapchain image’s index, waiting for one patiently.

VK_TIMEOUT and VK_NOT_READY from vkAcquireNextImageKHR are not errors: no image is free yet, which a compositor that is busy or a loaded machine makes happen now and then. The frame’s fence is already reset by the time this runs, so giving up here would leave the next frame waiting on a fence nothing will signal; it asks again instead, logging once, and raises naming the swapchain only once :data:FENCE_PATIENCE_S has passed. The swapchain errors (out of date, suboptimal, surface or device lost) propagate to the caller, which handles each.

class simvx.graphics.gpu.sync.FrameSync(device: Any, image_count: int, frame_count: int = FRAMES_IN_FLIGHT)¶