Trait wgpu::hal::Queue

source ·

pub trait Queue: WasmNotSendSync {
    type A: Api;

    // Required methods
    unsafe fn submit(
        &self,
        command_buffers: &[&<Self::A as Api>::CommandBuffer],
        surface_textures: &[&<Self::A as Api>::SurfaceTexture],
        signal_fence: Option<(&mut <Self::A as Api>::Fence, u64)>
    ) -> Result<(), DeviceError>;
    unsafe fn present(
        &self,
        surface: &<Self::A as Api>::Surface,
        texture: <Self::A as Api>::SurfaceTexture
    ) -> Result<(), SurfaceError>;
    unsafe fn get_timestamp_period(&self) -> f32;
}

Available on wgpu_core only.

Required Associated Types§

source

type A: Api

Required Methods§

source

unsafe fn submit( &self, command_buffers: &[&<Self::A as Api>::CommandBuffer], surface_textures: &[&<Self::A as Api>::SurfaceTexture], signal_fence: Option<(&mut <Self::A as Api>::Fence, u64)> ) -> Result<(), DeviceError>

Submit command_buffers for execution on GPU.

If signal_fence is Some(fence, value), update fence to value when the operation is complete. See Fence for details.

If two calls to submit on a single Queue occur in a particular order (that is, they happen on the same thread, or on two threads that have synchronized to establish an ordering), then the first submission’s commands all complete execution before any of the second submission’s commands begin. All results produced by one submission are visible to the next.

Within a submission, command buffers execute in the order in which they appear in command_buffers. All results produced by one buffer are visible to the next.

If two calls to submit on a single Queue from different threads are not synchronized to occur in a particular order, they must pass distinct Fences. As explained in the Fence documentation, waiting for operations to complete is only trustworthy when operations finish in order of increasing fence value, but submissions from different threads cannot determine how to order the fence values if the submissions themselves are unordered. If each thread uses a separate Fence, this problem does not arise.

Valid usage:

All of the CommandBuffers were created from CommandEncoders that are associated with this queue.
All of those CommandBuffers must remain alive until the submitted commands have finished execution. (Since command buffers must not outlive their encoders, this implies that the encoders must remain alive as well.)
All of the SurfaceTextures that the command buffers write to appear in the surface_textures argument.