10: The OpenGL Pipeline
08: Synchronisation
COMP5822M: High Performance Graphics
Synchronisation
The classic problem with parallelism
How to avoid read/write conflicts
Five basic approaches:
Single-thread programming
Programmer discipline
Locking primitives
Signalling primitives
Block & stream operations
COMP5822M: High Performance Graphics
Single-thread Programming
Often the easiest way
Only write one thread of control
But this only works for one core
And we have thousands
However, our setup code is single-thread
(although it doesn’t have to be)
Because it’s simpler
COMP5822M: High Performance Graphics
Programmer Discipline
The Vulkan Way
Always ensure that you force correct ordering
If anything goes wrong, it’s your fault
More seriously, this is at the heart of it
Everything else just helps you do it
Increasingly difficult in large code bases
COMP5822M: High Performance Graphics
Locking Primitives
Almost always use hardware / O/S privilege
Atomic operations
Complete as a unit
But this causes queueing in hardware
Semaphores / mutexes
Explicit variable for access privilege
Makes queueing explicit in software
COMP5822M: High Performance Graphics
Signalling Primitives
Usually use hardware / O/S privilege
Have threads wait at a given point
Until a signal releases them
Threads can sleep while they wait
Fences: everybody waits until all released
Events: explicit signals to another thread
COMP5822M: High Performance Graphics
Block & Stream Operations
Semaphores & locking are implicit
Block: compute “x” for all elements
Implicit synchronisation when all finish
Stream: compute “x” as you get elements
Implicit synchronisation on I/O buffers
These are the most powerful primitives
I.e. with the least overhead (typically)
COMP5822M: High Performance Graphics
Vulkan Synchronisation
Block & Stream operations are implicit
Fences & Events control the pipeline
Semaphores are available for the pipeline
Programmer discipline is assumed
Single-thread is used for control code
Unless you have a complex programme
COMP5822M: High Performance Graphics
Streams in Vulkan
Read from a buffer, write to a buffer
In the middle, perform a transformation
Notice the way I implemented it in code
That’s the underlying processing model
And most of it is done out of sight for you
This allows HW/SW optimisation
COMP5822M: High Performance Graphics
Blocks in Vulkan
Most GPGPU code is block-oriented
Parallel transformations of arrays
Not a huge change from buffers
Fewer synchronisation operations
Just one big one at the end of the block
Best for huge computations
But nothing we will worry about right now
COMP5822M: High Performance Graphics
Semaphores
Atomic flags that can be set/reset by hardware
Device waits until semaphore is unset
Then sets it and returns control
Guaranteed that only one agent gets it
Until semaphore is unset again
Set indirectly through vkQueueSubmit
With wait / signal semaphores
COMP5822M: High Performance Graphics
Signalling Primitives
Events
Host or device sends signal
Received at another point in the pipeline
Needs the plumbing to be set up
Fences
Host waits for device to complete tasks
Usually a large number of tasks
Notice the implicit large-scale stall
COMP5822M: High Performance Graphics
Vulkan Fences
An (optional) parameter to vkQueueSubmit
Main thread sets it up
Then (later on) waits at the fence
When devices finish, fence is released
Essentially, a semaphore with extra code
Makes waiting for results easier
Especially with multiple consumers
COMP5822M: High Performance Graphics
An Example
Suppose we want to have a ring buffer
A buffer with multiple segments
In this case, individual frames
We write into one segment at a time
Meaning that the other frames are readable
So we want a fence for each frame
COMP5822M: High Performance Graphics
Ring Buffer Creation
COMP5822M: High Performance Graphics
Fence Creation
COMP5822M: High Performance Graphics
Waiting For the Fence
COMP5822M: High Performance Graphics
Preparing Command Buffer
COMP5822M: High Performance Graphics
Submit the Job
COMP5822M: High Performance Graphics