Safe Haskell | None |
---|---|
Language | Haskell2010 |
Synopsis
- createDeferredOperationKHR :: forall io. MonadIO io => Device -> ("allocator" ::: Maybe AllocationCallbacks) -> io DeferredOperationKHR
- withDeferredOperationKHR :: forall io r. MonadIO io => (io DeferredOperationKHR -> (DeferredOperationKHR -> io ()) -> r) -> Device -> Maybe AllocationCallbacks -> r
- destroyDeferredOperationKHR :: forall io. MonadIO io => Device -> DeferredOperationKHR -> ("allocator" ::: Maybe AllocationCallbacks) -> io ()
- getDeferredOperationMaxConcurrencyKHR :: forall io. MonadIO io => Device -> DeferredOperationKHR -> io Word32
- getDeferredOperationResultKHR :: forall io. MonadIO io => Device -> DeferredOperationKHR -> io Result
- deferredOperationJoinKHR :: forall io. MonadIO io => Device -> DeferredOperationKHR -> io Result
- data DeferredOperationInfoKHR = DeferredOperationInfoKHR {}
- type KHR_DEFERRED_HOST_OPERATIONS_SPEC_VERSION = 2
- pattern KHR_DEFERRED_HOST_OPERATIONS_SPEC_VERSION :: forall a. Integral a => a
- type KHR_DEFERRED_HOST_OPERATIONS_EXTENSION_NAME = "VK_KHR_deferred_host_operations"
- pattern KHR_DEFERRED_HOST_OPERATIONS_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a
- newtype DeferredOperationKHR = DeferredOperationKHR Word64
Documentation
createDeferredOperationKHR :: forall io. MonadIO io => Device -> ("allocator" ::: Maybe AllocationCallbacks) -> io DeferredOperationKHR Source #
vkCreateDeferredOperationKHR - Create a deferred operation handle
Parameters
device
is the device which ownsoperation
.
pAllocator
controls host memory allocation as described in the Memory Allocation chapter.pDeferredOperation
is a pointer to a handle in which the createdDeferredOperationKHR
is returned.
Valid Usage (Implicit)
device
must be a validDevice
handle
- If
pAllocator
is notNULL
,pAllocator
must be a valid pointer to a validAllocationCallbacks
structure pDeferredOperation
must be a valid pointer to aDeferredOperationKHR
handle
Return Codes
See Also
withDeferredOperationKHR :: forall io r. MonadIO io => (io DeferredOperationKHR -> (DeferredOperationKHR -> io ()) -> r) -> Device -> Maybe AllocationCallbacks -> r Source #
A convenience wrapper to make a compatible pair of calls to
createDeferredOperationKHR
and destroyDeferredOperationKHR
To ensure that destroyDeferredOperationKHR
is always called: pass
bracket
(or the allocate function from your
favourite resource management library) as the first argument.
To just extract the pair pass '(,)' as the first argument.
destroyDeferredOperationKHR :: forall io. MonadIO io => Device -> DeferredOperationKHR -> ("allocator" ::: Maybe AllocationCallbacks) -> io () Source #
vkDestroyDeferredOperationKHR - Destroy a deferred operation handle
Parameters
device
is the device which ownsoperation
.
operation
is the completed operation to be destroyed.pAllocator
controls host memory allocation as described in the Memory Allocation chapter.
Valid Usage
- If
AllocationCallbacks
were provided whenoperation
was created, a compatible set of callbacks must be provided here
- If no
AllocationCallbacks
were provided whenoperation
was created,pAllocator
must beNULL
operation
must be completed
Valid Usage (Implicit)
device
must be a validDevice
handle
operation
must be a validDeferredOperationKHR
handle- If
pAllocator
is notNULL
,pAllocator
must be a valid pointer to a validAllocationCallbacks
structure operation
must have been created, allocated, or retrieved fromdevice
See Also
getDeferredOperationMaxConcurrencyKHR :: forall io. MonadIO io => Device -> DeferredOperationKHR -> io Word32 Source #
vkGetDeferredOperationMaxConcurrencyKHR - Query the maximum concurrency on a deferred operation
Parameters
device
is the device which ownsoperation
.
operation
is the deferred operation to be queried.
Description
The returned value is the maximum number of threads that can usefully
execute a deferred operation concurrently, reported for the state of the
deferred operation at the point this command is called. This value is
intended to be used to better schedule work onto available threads.
Applications can join any number of threads to the deferred operation
and expect it to eventually complete, though excessive joins may
return THREAD_IDLE_KHR
immediately, performing no useful work.
If the deferred operation is currently joined to any threads, the value returned by this command may immediately be out of date.
Implementations must not return zero.
Implementations may return 232-1 to indicate that the maximum concurrency is unknown and cannot be easily derived. Implementations may return values larger than the maximum concurrency available on the host CPU. In these situations, an application should clamp the return value rather than oversubscribing the machine.
Valid Usage (Implicit)
See Also
getDeferredOperationResultKHR :: forall io. MonadIO io => Device -> DeferredOperationKHR -> io Result Source #
vkGetDeferredOperationResultKHR - Query the result of a deferred operation
Parameters
device
is the device which ownsoperation
.
operation
is the operation whose deferred result is being queried.
Description
If the deferred operation is pending, getDeferredOperationResultKHR
returns NOT_READY
. Otherwise, it
returns the result of the deferred operation. This value must be one
of the Result
values which could
have been returned by the original command if the operation had not been
deferred.
Return Codes
See Also
deferredOperationJoinKHR :: forall io. MonadIO io => Device -> DeferredOperationKHR -> io Result Source #
vkDeferredOperationJoinKHR - Assign a thread to a deferred operation
Parameters
device
is the device which ownsoperation
.
operation
is the deferred operation that the calling thread should work on.
Description
The deferredOperationJoinKHR
command will execute a portion of the
deferred operation on the calling thread.
The return value will be one of the following:
- A return value of
SUCCESS
indicates thatoperation
is complete. The application should usegetDeferredOperationResultKHR
to retrieve the result ofoperation
. - A return value of
THREAD_DONE_KHR
indicates that the deferred operation is not complete, but there is no work remaining to assign to threads. Future calls todeferredOperationJoinKHR
are not necessary and will simply harm performance. This situation may occur when other threads executingdeferredOperationJoinKHR
are about to completeoperation
, and the implementation is unable to partition the workload any further. - A return value of
THREAD_IDLE_KHR
indicates that the deferred operation is not complete, and there is no work for the thread to do at the time of the call. This situation may occur if the operation encounters a temporary reduction in parallelism. By returningTHREAD_IDLE_KHR
, the implementation is signaling that it expects that more opportunities for parallelism will emerge as execution progresses, and that future calls todeferredOperationJoinKHR
can be beneficial. In the meantime, the application can perform other work on the calling thread.
Implementations must guarantee forward progress by enforcing the following invariants:
- If only one thread has invoked
deferredOperationJoinKHR
on a given operation, that thread must execute the operation to completion and returnSUCCESS
. - If multiple threads have concurrently invoked
deferredOperationJoinKHR
on the same operation, then at least one of them must complete the operation and returnSUCCESS
.
Valid Usage (Implicit)
device
must be a validDevice
handle
operation
must be a validDeferredOperationKHR
handleoperation
must have been created, allocated, or retrieved fromdevice
Return Codes
See Also
data DeferredOperationInfoKHR Source #
VkDeferredOperationInfoKHR - Deferred operation request
Description
The application can request deferral of an operation by adding this
structure to the argument list of a command or by providing this in the
pNext
chain of a relevant structure for an operation when the
corresponding command is invoked. If this structure is not present, no
deferral is requested. If operationHandle
is
NULL_HANDLE
, no deferral is
requested and the command proceeds as if no DeferredOperationInfoKHR
structure was provided.
When an application requests an operation deferral, the implementation
may defer the operation. When deferral is requested and the
implementation defers any operation, the implementation must return
OPERATION_DEFERRED_KHR
as the
success code if no errors occurred. When deferral is requested, the
implementation should defer the operation when the workload is
significant, however if the implementation chooses not to defer any of
the requested operations and instead executes all of them immediately,
the implementation must return
OPERATION_NOT_DEFERRED_KHR
as the
success code if no errors occurred.
A deferred operation is created complete with an initial result value
of SUCCESS
. The deferred operation
becomes pending when an operation has been successfully deferred with
that operationHandle
.
A deferred operation is considered pending until the deferred operation
completes. A pending deferred operation becomes complete when it has
been fully executed by one or more threads. Pending deferred operations
will never complete until they are joined by an application thread,
using deferredOperationJoinKHR
. Applications can join multiple
threads to the same deferred operation, enabling concurrent execution of
subtasks within that operation.
The application can query the status of a
DeferredOperationKHR
using the
getDeferredOperationMaxConcurrencyKHR
or
getDeferredOperationResultKHR
commands.
From the perspective of other commands - parameters to the original command that are externally synchronized must not be accessed before the deferred operation completes, and the result of the deferred operation (e.g. object creation) are not considered complete until the deferred operation completes.
If the deferred operation is one which creates an object (for example, a
pipeline object), the implementation must allocate that object as it
normally would, and return a valid handle to the application. This
object is a pending object, and must not be used by the application
until the deferred operation is completed (unless otherwise specified by
the deferral extension). When the deferred operation is complete, the
application should call getDeferredOperationResultKHR
to obtain the
result of the operation. If getDeferredOperationResultKHR
indicates
failure, the application must destroy the pending object using an
appropriate command, so that the implementation has an opportunity to
recover the handle. The application must not perform this destruction
until the deferred operation is complete. Construction of the pending
object uses the same allocator which would have been used if the
operation had not been deferred.
Valid Usage
- Any previous deferred operation that was associated with
operationHandle
must be complete
Valid Usage (Implicit)
sType
must beSTRUCTURE_TYPE_DEFERRED_OPERATION_INFO_KHR
See Also
DeferredOperationInfoKHR | |
|
Instances
pattern KHR_DEFERRED_HOST_OPERATIONS_SPEC_VERSION :: forall a. Integral a => a Source #
type KHR_DEFERRED_HOST_OPERATIONS_EXTENSION_NAME = "VK_KHR_deferred_host_operations" Source #
pattern KHR_DEFERRED_HOST_OPERATIONS_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a Source #
newtype DeferredOperationKHR Source #
VkDeferredOperationKHR - A deferred operation
Description
This handle refers to a tracking structure which manages the execution state for a deferred command.
See Also
DeferredOperationInfoKHR
,
createDeferredOperationKHR
,
deferredOperationJoinKHR
,
destroyDeferredOperationKHR
,
getDeferredOperationMaxConcurrencyKHR
,
getDeferredOperationResultKHR