azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
* GenTooMan suggests unuseful prototypes be contributed to the Andy Warhol museums as "experimental objects in RF self torture".
<azonenberg> lol
<GenTooMan> well that came to mind from the number of experimental units made.
<_whitenotifier-7> [scopehal] azonenberg opened issue #668: Look at setting up CI builds of the library in isolation - https://github.com/glscopeclient/scopehal/issues/668
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #468: Add SwiftShader to github actions config - https://github.com/glscopeclient/scopehal-apps/issues/468
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #468: Add SwiftShader to github actions config - https://github.com/glscopeclient/scopehal-apps/issues/468
<_whitenotifier-7> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/glscopeclient/scopehal/compare/22f5d4388fbd...12a91af7e42a
<_whitenotifier-7> [scopehal] azonenberg 12a91af - Initial addition of Vulkan headers and link config to see what breaks in CI
<_whitenotifier-7> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/glscopeclient/scopehal-docs/compare/e28766aba66b...18a6375da248
<_whitenotifier-7> [scopehal-docs] azonenberg 18a6375 - Added note about Vulkan
<_whitenotifier-7> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://github.com/glscopeclient/scopehal-apps/compare/4a96248c588e...051303017ae5
<_whitenotifier-7> [scopehal-apps] azonenberg 0513030 - Initial checks for Vulkan at compile time. Let's see what this breaks!
<_whitenotifier-7> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/glscopeclient/scopehal-docs/compare/18a6375da248...c86d8e4842dc
<_whitenotifier-7> [scopehal-docs] azonenberg c86d8e4 - Added Vulkan packages to dependencies
<_whitenotifier-7> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://github.com/glscopeclient/scopehal-apps/compare/051303017ae5...3f9a6b0f7aa9
<_whitenotifier-7> [scopehal-apps] azonenberg 3f9a6b0 - Added Vulkan dependencies to CI build scripts
<azonenberg> Is there any reason not to move to C++ '14 at this point?
<azonenberg> It looks to be well supported everywhere we're targeting
<_whitenotifier-7> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/glscopeclient/scopehal/compare/12a91af7e42a...18042d3d44a5
<_whitenotifier-7> [scopehal] azonenberg 18042d3 - Initialize Vulkan context and print out physical device info. Don't actually initialize a device context yet. See #457.
<_whitenotifier-7> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://github.com/glscopeclient/scopehal-apps/compare/3f9a6b0f7aa9...3691b4b6f609
<_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