You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: include/nbl/video/utilities/SIntendedSubmitInfo.h
+85-75Lines changed: 85 additions & 75 deletions
Original file line number
Diff line number
Diff line change
@@ -17,101 +17,111 @@ namespace nbl::video
17
17
//! The "current recording commandBuffer" is returned by `getCurrentRecordingCommandBufferInfo` or updated via the pointer ref in beginNextCommandBuffer or overflowSubmit)
18
18
structSIntendedSubmitInfofinal : core::Uncopyable
19
19
{
20
-
public:
21
-
// This parameter is required but may be unused if there is no need (no overflow) to do submit
22
-
IQueue* queue = nullptr;
23
-
// Use this parameter to wait for previous operations to finish before whatever commands the Utility you're using records
// This semaphore is needed to ensure correct and valid usage of the command buffer used to record the next submit by ensuring they are not currently pending.
34
-
// The initial `scratchSemaphore.value` gets incremented and signalled on each submit, can start at 0 because an overflow will signal `value+1`.
35
-
// `[Multi]TimelineEventHandler` to latch cleanups on `scratchSemaphore` where this value, so make sure you're submitting by yourself manually and use the functions provided here.
36
-
// is a value that they expect to actually get signalled in the future.
37
-
// NOTE: To ensure deterministic behavior, do not attempt to signal this semaphore yourself.
38
-
// You can actually examine the change in `scratchSemaphore.value` to figure out how many submits occurred.
// Optional: If you had a semaphore whose highest pending signal is 45 but gave the scratch a value of 68 (causing 69 to get signalled in a popped submit),
41
-
// but only used 4 scratch command buffers, we'd wait for the semaphore to reach 66 before resetting the next scratch command buffer.
42
-
// That is obviously suboptimal if the next scratch command buffer wasn't pending with a signal of 67 at all (you'd wait until 70 gets signalled).
43
-
// Therefore you would need to override this behaviour somehow and be able to tell to only wait for the semaphore at values higher than 68.
44
-
size_t initialScratchValue = 0;
45
-
// Optional: Callback to perform some other CPU work while blocking for one of the submitted scratch command buffers to complete execution.
46
-
// Can get called repeatedly! The argument is the scratch semaphore (so it can poll itself to know when to finish work - prevent priority inversion)
// This parameter is required but may be unused if there is no need (no overflow) to perform submit operations (no call to `overflowSubmit` or `submit`)
79
+
IQueue* queue = nullptr;
107
80
108
-
// All prevCommandBuffers must be executable (ready to be submitted)
109
-
for (constauto& info : prevCommandBuffers)
110
-
if (cmdbufNotSubmittableToQueue(info.cmdbuf) || info.cmdbuf->getState()!=IGPUCommandBuffer::STATE::EXECUTABLE)
111
-
returnnullptr;
81
+
// Use this parameter to wait for previous operations to finish before whatever commands the Utility you're using records.
// A set of command buffers the Utility can use in a round-robin manner for its transient commands. All command buffers must be individually resettable.
89
+
// Command buffers are cycled through for use and submission using a simple modular arithmetic fashion.
90
+
// EXACTLY ONE commandbuffer must be in recording state! This is the one the utilities will use immediately to record commands.
91
+
// However, even though it's scratch, you can record some of your own preceding commands into it as well.
// This semaphore is needed to indicate when each sub-submit is complete and resources can be reclaimed.
95
+
// It also ensures safe usage of the scratch command buffers by blocking the CPU if the next scratch command buffer to use is in a PENDING state and not safe to begin.
96
+
// The initial `scratchSemaphore.value` gets incremented and signaled on each submit. It can start at 0 because an overflow will signal `value+1`.
97
+
// NOTE: You should signal this semaphore when doing your last/tail submit manually OR when not submitting the recorded scratch at all
98
+
// (in which case, signal from Host or another submit). Why? The utilities that deal with `SIntendedSubmitInfo` might use the
99
+
// `[Multi]TimelineEventHandler` to latch cleanups/deallocations on `scratchSemaphore`, and `getFutureScratchSemaphore()`
100
+
// is the value they expect to get signaled in the future.
101
+
// NOTE: Each overflow submit bumps the value to wait and signal by +1. A utility may overflow an arbitrary number of times.
102
+
// Therefore, DO NOT choose the values for waits and signals manually, and do not modify the `scratchSemaphore` field after initialization or first use.
103
+
// You can examine the change in `scratchSemaphore.value` to observe how many overflows or submits have occurred.
// Optional: If you had a semaphore whose highest pending signal is 45 but gave the scratch a value of 68 (causing 69 to get signaled in a popped submit),
107
+
// but only used 4 scratch command buffers, we'd wait for the semaphore to reach 66 before resetting the next scratch command buffer.
108
+
// This is obviously suboptimal if the next scratch command buffer wasn't pending with a signal of 67 at all (you'd be waiting until 70 gets signaled).
109
+
// Therefore, you would need to override this behavior to only wait for semaphore values higher than 68.
110
+
size_t initialScratchValue = 0;
111
+
112
+
// Optional: Callback to perform some other CPU work while blocking for one of the submitted scratch command buffers to complete execution.
113
+
// This callback may be called repeatedly! The argument provided is the scratch semaphore, allowing it to poll itself to determine when it can finish its work,
0 commit comments