aboutsummaryrefslogtreecommitdiff
path: root/src/timestamp_pool.hh
diff options
context:
space:
mode:
authorNicolas James <nj3ahxac@gmail.com>2026-02-16 17:25:20 +1100
committerNicolas James <nj3ahxac@gmail.com>2026-02-16 17:25:20 +1100
commit5cf3e65a3904a5be0f080cd675da63f190ca58d2 (patch)
tree74d8b27e6df73325240c78c1fed4231a20c76143 /src/timestamp_pool.hh
parent4c1a11fdb9200a4a54b3b282b6acd10e6ec583ce (diff)
cleanup
Diffstat (limited to 'src/timestamp_pool.hh')
-rw-r--r--src/timestamp_pool.hh32
1 files changed, 4 insertions, 28 deletions
diff --git a/src/timestamp_pool.hh b/src/timestamp_pool.hh
index f69b06f..681c9e2 100644
--- a/src/timestamp_pool.hh
+++ b/src/timestamp_pool.hh
@@ -3,37 +3,13 @@
// The purpose of this file is to provide the definition of a 'timestamp pool'.
// It manages blocks of timestamp query pools, hands them out when requested,
-// and allocates more when (if) we run out. It also efficiently reads them back.
-// This class solves some key issues:
-//
-// 1. We need a potentially infinite amount of timestamps available to the
-// GPU. While I imagine most (good) applications will limit the amount of
-// times they call vkQueueSubmit, there's no bound we can place on the
-// amount of times this function will be called. Also,
-// the amount of frames in flight might vary, so really we need
-// num_queue_submits * max_frames_in_flight timestamps. Obviously, we don't
-// know what these numbers are at runtime and can't assume that they are
-// reasonable or even constant either. We solve this by allocating more
-// timestamps when necessary.
-
-// 2. We don't want to hammer vulkan with expensive timestamp read
-// operations. If we have hundreds of query pools lying around, reading them
-// back will take hundreds of individual vulkan calls. They
-// should be batched as to perform as few reads as possible. So if we allocate
-// multiple big query pool strips, then reading them will only require that many
-// calls. We then can cache off the result of reading as well so iterating
-// through later doesn't require any vulkan interaction at all.
-//
-//
+// and allocates more when (if) we run out.
// Usage:
// 1. Get handle with .acquire().
// 2. Write start/end timestamp operations with the handle's pool and index
-// into the provided command buffer.
-// 3. With the command buffer signalled completion via some semaphore /
-// fence, call .poll(). This will cache off all outstanding handles.
-// Retrieving with handles which have not been signalled are undefined.
-// 4. Retrieve timestamp results with .get_polled(your_handle).
-// 5. Destruct the handle to return the key to the pool.
+// into the provided command buffer. Will return nullopt if they're
+// not yet available.
+// 3. Destruct the handle to return the key to the pool.
#include <vulkan/utility/vk_dispatch_table.h>
#include <vulkan/vulkan.hpp>