Module Sarek_vulkan.Vulkan_api_event

module Device = Vulkan_api_device
module Stream = Vulkan_api_stream
type t = {
  1. fence : Vulkan_api_base.tracked_fence;
  2. device : Device.t;
  3. lock : Stdlib.Mutex.t;
}

An event is a tracked fence: pending from a successful record until a wait observes it signalled. An event that was never recorded, or whose record failed, is not pending, so synchronizing it returns at once. lock serializes the wait/reset/submit sequences on the fence across domains.

val create_with_device : Device.t -> t
val destroy : t -> unit
val record : t -> Stream.t -> unit

Signal event once all work launched on the device of stream before this call has completed: the open launch batches are submitted, then an empty submission carrying the event's fence follows them in the queue. A previous record still pending is waited for first, since a pending fence cannot be reset.

val wait_on : t -> Stream.t -> unit

All later work of stream waits for the work event covers: the single queue plus the barrier before every dispatch order it in memory (see Vulkan_api_barrier); the host-side half is that synchronising stream also waits for the event (Vulkan_api_batch.synchronize).

val synchronize : t -> unit
val query : t -> bool

true once the work covered by the last record has completed, or when the event was never recorded. Never blocks: a signalled fence is reaped (marked not pending) so a later record need not wait. While another domain holds the event's lock (it is recording or waiting), the work is still pending and the answer is false.

val elapsed : start:'a -> stop:'b -> 'c

Elapsed time needs timestamp queries, which this backend does not issue; answering a number here would be a fabricated measurement.