<_whitenotifier-7>
[scopehal-apps] azonenberg 3691b4b - Begin work on Vulkan init
<azonenberg>
Any active users here - please try out this build and let me know if it works for you
<azonenberg>
it initializes some vulkan stuff and prints out GPU info but doesn't actually try to use the device yet
<azonenberg>
but that's a prerequisite of course to actually doing stuff with it
<azonenberg>
Ok so digging around a bunch it seems vulkan gives us a lot of nice low level control over memory regions and exactly where data is allocated and stored
<azonenberg>
I think we are ultimately going to want to create some sort of memory buffer wrapper class
<azonenberg>
which has pointers to both a CPU-side and GPU-side buffer
<azonenberg>
either of which may be null
<azonenberg>
and they may describe the same or different regions of memory
<azonenberg>
(ping lain)
<azonenberg>
Examples of possible scenarios
<azonenberg>
buffer is in CPU local memory at first, not readable by GPU (not pinned etc). We later allocate dedicated GPU memory and copy the data to it
<azonenberg>
buffer is allocated in pinned CPU memory, GPU can read it directly but it's slow (has to DMA each time)
<azonenberg>
buffer is allocated in pinned CPU memory, we know GPU will use it a lot, so we allocate a mirror copy in GPU local memory
<azonenberg>
we need to consider what happens if either side modifies the data (so every block handling said data has to be aware of which copy they're modifying and invalidate the other if needed)
<azonenberg>
ultimately the goal is to avoid excessive copies or repeated DMA transactions, keep things coherent, and ideally have GPU filter output stay on the GPU from compute directly to rendering without copies to CPU and back
<azonenberg>
Now the question is, is this something that we want to do before, during, or after the other planned major memory model refactoring
<azonenberg>
which is to revamp the Waveform class so that SparseWaveform and DenseWaveform are separate objects
<azonenberg>
derived from the same base
<azonenberg>
I feel like it might make sense to make this one huge refactoring and do it all at once
<azonenberg>
so a SparseWaveform and DenseWaveform both contain memory living in a MultiLocationMemoryBuffer (names are not final)
<azonenberg>
But this kind of refactoring would be messy and touch a lot of places. every filter, every scope driver, and the renderer
<azonenberg>
We're going to have to think carefully about how to make it atomic
<azonenberg>
and break it up into steps, none of which completely bork everything
<azonenberg>
Initializing the vulkan context fully and being able to allocate GPU memory is, at least, non intrusive
<azonenberg>
And then i guess we could make the memory buffer class and then fit it into the new waveform classes, but only ever have it be using the CPU memory backend to start