[−][src]Trait vulkano::image::traits::ImageAccess

pub unsafe trait ImageAccess {
    fn inner(&self) -> ImageInner;
    fn initial_layout_requirement(&self) -> ImageLayout;
    fn final_layout_requirement(&self) -> ImageLayout;
    fn conflicts_buffer(&self, other: &dyn BufferAccess) -> bool;
    fn conflicts_image(&self, other: &dyn ImageAccess) -> bool;
    fn conflict_key(&self) -> u64;
    fn try_gpu_lock(
        &self, 
        exclusive_access: bool, 
        expected_layout: ImageLayout
    ) -> Result<(), AccessError>;
    unsafe fn increase_gpu_lock(&self);
    unsafe fn unlock(&self, transitioned_layout: Option<ImageLayout>);

    fn format(&self) -> Format { ... }
    fn has_color(&self) -> bool { ... }
    fn has_depth(&self) -> bool { ... }
    fn has_stencil(&self) -> bool { ... }
    fn mipmap_levels(&self) -> u32 { ... }
    fn samples(&self) -> u32 { ... }
    fn dimensions(&self) -> ImageDimensions { ... }
    fn supports_blit_source(&self) -> bool { ... }
    fn supports_blit_destination(&self) -> bool { ... }
    unsafe fn layout_initialized(&self) { ... }
    fn is_layout_initialized(&self) -> bool { ... }
    unsafe fn preinitialized_layout(&self) -> bool { ... }
    unsafe fn forced_undefined_initial_layout(
        self, 
        preinitialized: bool
    ) -> ImageAccessFromUndefinedLayout<Self>
    where
        Self: Sized,
    { ... }
}

Trait for types that represent the way a GPU can access an image.

Required methods

`fn inner(&self) -> ImageInner`

Returns the inner unsafe image object used by this image.

`fn initial_layout_requirement(&self) -> ImageLayout`

Returns the layout that the image has when it is first used in a primary command buffer.

The first time you use an image in an AutoCommandBufferBuilder, vulkano will suppose that the image is in the layout returned by this function. Later when the command buffer is submitted vulkano will check whether the image is actually in this layout, and if it is not the case then an error will be returned. TODO: ^ that check is not yet implemented

`fn final_layout_requirement(&self) -> ImageLayout`

Returns the layout that the image must be returned to before the end of the command buffer.

When an image is used in an AutoCommandBufferBuilder vulkano will automatically transition this image to the layout returned by this function at the end of the command buffer, if necessary.

Except for special cases, this value should likely be the same as the one returned by initial_layout_requirement so that the user can submit multiple command buffers that use this image one after the other.

`fn conflicts_buffer(&self, other: &dyn BufferAccess) -> bool`

Returns true if an access to self potentially overlaps the same memory as an access to other.

If this function returns false, this means that we are allowed to access the content of self at the same time as the content of other without causing a data race.

Note that the function must be transitive. In other words if conflicts(a, b) is true and conflicts(b, c) is true, then conflicts(a, c) must be true as well.

`fn conflicts_image(&self, other: &dyn ImageAccess) -> bool`

Returns true if an access to self potentially overlaps the same memory as an access to other.

If this function returns false, this means that we are allowed to access the content of self at the same time as the content of other without causing a data race.

Note that the function must be transitive. In other words if conflicts(a, b) is true and conflicts(b, c) is true, then conflicts(a, c) must be true as well.

`fn conflict_key(&self) -> u64`

Returns a key that uniquely identifies the memory content of the image. Two ranges that potentially overlap in memory must return the same key.

The key is shared amongst all buffers and images, which means that you can make several different image objects share the same memory, or make some image objects share memory with buffers, as long as they return the same key.

Since it is possible to accidentally return the same key for memory ranges that don't overlap, the conflicts_image or conflicts_buffer function should always be called to verify whether they actually overlap.

`fn try_gpu_lock( &self, exclusive_access: bool, expected_layout: ImageLayout ) -> Result<(), AccessError>`

Locks the resource for usage on the GPU. Returns an error if the lock can't be acquired.

After this function returns Ok, you are authorized to use the image on the GPU. If the GPU operation requires an exclusive access to the image (which includes image layout transitions) then exclusive_access should be true.

The expected_layout is the layout we expect the image to be in when we lock it. If the actual layout doesn't match this expected layout, then an error should be returned. If Undefined is passed, that means that the caller doesn't care about the actual layout, and that a layout mismatch shouldn't return an error.

This function exists to prevent the user from causing a data race by reading and writing to the same resource at the same time.

If you call this function, you should call unlock() once the resource is no longer in use by the GPU. The implementation is not expected to automatically perform any unlocking and can rely on the fact that unlock() is going to be called.

`unsafe fn increase_gpu_lock(&self)`

Locks the resource for usage on the GPU. Supposes that the resource is already locked, and simply increases the lock by one.

Must only be called after try_gpu_lock() succeeded.

If you call this function, you should call unlock() once the resource is no longer in use by the GPU. The implementation is not expected to automatically perform any unlocking and can rely on the fact that unlock() is going to be called.

`unsafe fn unlock(&self, transitioned_layout: Option<ImageLayout>)`

Unlocks the resource previously acquired with try_gpu_lock or increase_gpu_lock.

If the GPU operation that we unlock from transitioned the image to another layout, then it should be passed as parameter.

A layout transition requires exclusive access to the image, which means two things:

The implementation can panic if it finds out that the layout is not the same as it currently is and that it is not locked in exclusive mode.
There shouldn't be any possible race between unlock and try_gpu_lock, since try_gpu_lock should fail if the image is already locked in exclusive mode.

Safety

Must only be called once per previous lock.
The transitioned layout must be supported by the image (eg. the layout shouldn't be ColorAttachmentOptimal if the image wasn't created with the color_attachment usage).
The transitioned layout must not be Undefined.

Loading content...

Provided methods

`fn format(&self) -> Format`

Returns the format of this image.

`fn has_color(&self) -> bool`

Returns true if the image is a color image.

`fn has_depth(&self) -> bool`

Returns true if the image has a depth component. In other words, if it is a depth or a depth-stencil format.

`fn has_stencil(&self) -> bool`

Returns true if the image has a stencil component. In other words, if it is a stencil or a depth-stencil format.

`fn mipmap_levels(&self) -> u32`

Returns the number of mipmap levels of this image.

`fn samples(&self) -> u32`

Returns the number of samples of this image.

`fn dimensions(&self) -> ImageDimensions`

Returns the dimensions of the image.

`fn supports_blit_source(&self) -> bool`

Returns true if the image can be used as a source for blits.

`fn supports_blit_destination(&self) -> bool`

Returns true if the image can be used as a destination for blits.

`unsafe fn layout_initialized(&self)`

When images are created their memory layout is initially Undefined or Preinitialized. This method allows the image memory barrier creation process to signal when an image has been transitioned out of its initial Undefined or Preinitialized state. This allows vulkano to avoid creating unnecessary image memory barriers between future uses of the image.

Unsafe

If a user calls this method outside of the intended context and signals that the layout is no longer Undefined or Preinitialized when it is still in an Undefined or Preinitialized state, this may result in the vulkan implementation attempting to use an image in an invalid layout. The same problem must be considered by the implementer of the method.

`fn is_layout_initialized(&self) -> bool`

`unsafe fn preinitialized_layout(&self) -> bool`

`unsafe fn forced_undefined_initial_layout( self, preinitialized: bool ) -> ImageAccessFromUndefinedLayout<Self> where Self: Sized,`

Wraps around this ImageAccess and returns an identical ImageAccess but whose initial layout requirement is either Undefined or Preinitialized.

Loading content...