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
<azonenberg> ehntoo: and the bigger issue is that a native osx menu likely isnt going to play well with the imgui menus. so we'd have to write a bunch of platform specific marshalling code etc
<azonenberg> it would be essentially a completely new ui element
<azonenberg> So it will probably be a while before we did it
<d1b2> <ehntoo> agreed
<azonenberg> hmmm seems i still have a handle leak
<azonenberg> just not in the buffer pool anymore
<azonenberg> i'll work on that once i finish cursors
<_whitenotifier-7> [scopehal-apps] ehntoo synchronize pull request #509: WIP: macOS GitHub actions CI runner - https://github.com/glscopeclient/scopehal-apps/pull/509
<_whitenotifier-7> [scopehal-apps] ehntoo synchronize pull request #509: WIP: macOS GitHub actions CI runner - https://github.com/glscopeclient/scopehal-apps/pull/509
<_whitenotifier-7> [scopehal-apps] ehntoo synchronize pull request #509: WIP: macOS GitHub actions CI runner - https://github.com/glscopeclient/scopehal-apps/pull/509
<_whitenotifier-7> [scopehal-apps] ehntoo synchronize pull request #509: WIP: macOS GitHub actions CI runner - https://github.com/glscopeclient/scopehal-apps/pull/509
<_whitenotifier-7> [scopehal-apps] ehntoo synchronize pull request #509: WIP: macOS GitHub actions CI runner - https://github.com/glscopeclient/scopehal-apps/pull/509
<d1b2> <ehntoo> I think I am soundly defeated in my efforts to make AVX multiversioning cooperate and work on macOS clang on x86_64. clang is crashing now. https://github.com/ehntoo/scopehal-apps/actions/runs/3171091049/jobs/5164198243#step:7:348
<d1b2> <ehntoo> a short summary of what I've discovered so I (or someone else) can find it in the log: when given only a single instance of a function with attribute((feature)) on it, clang will only apply different cpu/arch/subarch feature flags for the compilation of that function, not treat that function as if it doesn't exist on architectures that don't support that feature flag, as GCC does. To make it do multiversioning dispatch, you need a second,
<d1b2> "default" implementation. These multiversioned implementations need to appear before any usage of them within a source file. clang seems to treat the feature attribute as part of the function signature, and will refuse to match a candidate in a class declaration without that feature. (https://github.com/ehntoo/scopehal-apps/actions/runs/3171025671/jobs/5164080164#step:7:289)
<d1b2> <ehntoo> oh, reference for the clang target behavior: https://releases.llvm.org/14.0.0/tools/clang/docs/AttributeReference.html#target
<d1b2> <ehntoo> if If find some time to look at this again tomorrow maybe I'll try without doing some of the gymnastics I was trying in order to support the existing software --noavx2/--noavx512f flags.
<azonenberg> ehntoo: we are not using gcc function multiversioning
<azonenberg> We are using the target attribute to say "use the flags for this function"
<azonenberg> then we ifdef to disable that function on ISAs lacking that feature
<azonenberg> we are also using different *names* for each of the alternate implementations, and then doing our own dispatch based on cpuid checks
<azonenberg> because this works on PE targets as well as ELF targets
<azonenberg> and with visual studio (althuogh this will likely need some vc++ specific pragmas instead of the __attribute declaration)
<d1b2> <ehntoo> hmm
<d1b2> <ehntoo> I guess it may just not be possible to do avx512f under clang then, since it errors on incompatible ABIs.
<azonenberg> so the thing that confuses me is, the immintrin stuff is all inlines
<azonenberg> there should be no abi for an inline function
<azonenberg> as it's not actually a call/return structure
<azonenberg> and i dont think we have any functions that return 512 bit vector types
<azonenberg> i'm not super concerned about that though because most of our linux builds are gcc and our primary mac targets are arm
<Bird|otherbox> @ehntoo: can you reproduce the crash with the llvm symbolizer on?
<d1b2> <ehntoo> not handily, I'd have to go fetch another machine.
<d1b2> <ehntoo> thinking about this more and staring at the original errors around avx512f's abi (https://github.com/ehntoo/scopehal-apps/actions/runs/3170302654/jobs/5162800012#step:7:1476), maybe the fact that it's throwing an ABI error is the real clang bug here?
<azonenberg> wow clang is not happy about us not using the "override" specifier everywhere lol
<d1b2> <ehntoo> yeah. I've just been putting up with it for now. I should put together some warning suppression flags.
<azonenberg> no, we should add that attribute :p
<azonenberg> its a good way to catch bugs
<azonenberg> i generally am a fan of turning on every warning we can, and making the code warning-clean
<d1b2> <ehntoo> 👍
<azonenberg> which it is on gcc
<azonenberg> except for half a dozen or so spots where it warns about an unused argument in a piec eof code that's incomplete
<azonenberg> i keep those warnings on purpose as a reminder to finish it
<azonenberg> anyway, try changing __attribute__((target("avx512f")))
<azonenberg> to __attribute__((target("arch=avx512f")))
<azonenberg> see if that changes anything
<azonenberg> it's saying "avx512 not enabled" which implies that it isnt recognizing the target attribute
<azonenberg> that said, the ngscopeclient version of that same code will probably be all vulkan and the glscopeclient version may or may not get vulkan-ized
<azonenberg> So dont beat yourself up too much over avx512 not working. we only use it in a handful of spots and i think many but perhaps not all of them can go to GPU
<azonenberg> Unrelated, i'm thinking of changing how cursors work in ngscopeclient
<d1b2> <ehntoo> yeah. come to think of it, I'm not sure any apple platforms ever shipped with avx512 support?
<d1b2> <ehntoo> anyway, build running: https://github.com/ehntoo/scopehal-apps/actions/runs/3171269559/jobs/5164546083 - going to log off for the night. have a good one.
<azonenberg> X axis cursors will continue to be group scoped (spanning multiple WaveformArea's within a group as needed)
<azonenberg> but i'm thinking of making Y axis cursors scoped to the plot
<azonenberg> This will also allow simultaneous x and y axis cursors which is something glscopeclient did not support
Degi has quit [Ping timeout: 252 seconds]
Degi has joined #scopehal
<azonenberg> ok, fixed a few bits of awkwardness and now have working x axis single cursors. no second cursor yet, no labels on the cursor yet
<azonenberg> That will happen tomorrow
<_whitenotifier-7> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±6] https://github.com/glscopeclient/scopehal-apps/compare/5f8adf25d3ba...1212cb5bced6
<_whitenotifier-7> [scopehal-apps] azonenberg 1212cb5 - Initial X axis cursor support in ngscopeclient. Incomplete, just a movable line with no readouts.
massi has joined #scopehal
nelgau has quit [Ping timeout: 250 seconds]
<azonenberg> So i'm thinking about how to do cursors in ngscopeclient now that we support arbitrarily many waveforms in a plot
<azonenberg> i no longer have a single analog waveform that i can display a value of right next to the cursor line
<azonenberg> So i'm wondering about maybe displaying the value next to the channel button?
massi has quit [Remote host closed the connection]
<azonenberg> lain: thoughts on this? ^
<azonenberg> also consider the case of multiple cursors and in-band power on fft traces
<azonenberg> how do we display this information usefully if we have six or eight channels in one plot?
<azonenberg> or do we give up and do what most scopes do, and have the concept of an "active" channel and only display the info for the active channel?
nelgau has joined #scopehal
bvernoux has joined #scopehal
<_whitenotifier-7> [scopehal] azonenberg commented on issue #679: Fix bug where some VkBuffer is not destroyed by the time we're shutting down - https://github.com/glscopeclient/scopehal/issues/679#issuecomment-1265824966
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #30: Allow multiple top level windows with waveforms in them - https://github.com/glscopeclient/scopehal-apps/issues/30
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #30: Allow multiple top level windows with waveforms in them - https://github.com/glscopeclient/scopehal-apps/issues/30#issuecomment-1265833412
<lain> hmm
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #161: Graphical filter graph viewer/editor - https://github.com/glscopeclient/scopehal-apps/issues/161
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #209: glscopeclient Fullscreen issue with dialog box - https://github.com/glscopeclient/scopehal-apps/issues/209#issuecomment-1265843466
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #209: glscopeclient Fullscreen issue with dialog box - https://github.com/glscopeclient/scopehal-apps/issues/209
<lain> azonenberg: I'm torn. on the one hand, I like having the trace information next to the cursor when I'm quickly examining a waveform, but on the other hand, it would get crowded fast if we put many values there...
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #218: Allow multiple analog waveforms to share a single WaveformArea - https://github.com/glscopeclient/scopehal-apps/issues/218#issuecomment-1265844192
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #218: Allow multiple analog waveforms to share a single WaveformArea - https://github.com/glscopeclient/scopehal-apps/issues/218
<azonenberg> lain: exactly
<azonenberg> another possible approach is to display next to the cursor if only one or two channels are active
<azonenberg> and if more than that, switch to next to the buttons?
<azonenberg> but that could be confusing
<lain> yeah I was thinking that also, but then it could be confusing because... yeah
<lain> "where'd they go?"
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #273: [Windows] Going into fullscreen mode and out again causes the window title bar to permanently disappear - https://github.com/glscopeclient/scopehal-apps/issues/273
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #273: [Windows] Going into fullscreen mode and out again causes the window title bar to permanently disappear - https://github.com/glscopeclient/scopehal-apps/issues/273#issuecomment-1265846305
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #293: Parallelize compute/download of Cairo over/underlays - https://github.com/glscopeclient/scopehal-apps/issues/293#issuecomment-1265846764
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #293: Parallelize compute/download of Cairo over/underlays - https://github.com/glscopeclient/scopehal-apps/issues/293
<azonenberg> We could also do a hybrid approach
<azonenberg> always display in both spots
<lain> make it obvious: animate the readings warping from the cursor to the buttons :P
<azonenberg> but limit display next to the cursor to two channels
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #303: glscopeclient chrome not drawn after changing applications - https://github.com/glscopeclient/scopehal-apps/issues/303#issuecomment-1265848869
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #303: glscopeclient chrome not drawn after changing applications - https://github.com/glscopeclient/scopehal-apps/issues/303
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #317: Large font sizes for infobox don't render correctly - https://github.com/glscopeclient/scopehal-apps/issues/317#issuecomment-1265849502
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #317: Large font sizes for infobox don't render correctly - https://github.com/glscopeclient/scopehal-apps/issues/317
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #353: On starting, set configuration to be the set of channels enabled on the scope - https://github.com/glscopeclient/scopehal-apps/issues/353#issuecomment-1265851832
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #353: On starting, set configuration to be the set of channels enabled on the scope - https://github.com/glscopeclient/scopehal-apps/issues/353
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #385: ERROR: Internal compile error, error code: E_SC_NOTSUPPORTED Shader not supported by HW - https://github.com/glscopeclient/scopehal-apps/issues/385#issuecomment-1265852822
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #385: ERROR: Internal compile error, error code: E_SC_NOTSUPPORTED Shader not supported by HW - https://github.com/glscopeclient/scopehal-apps/issues/385
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #387: Complie error on Windows X64, need help thanks! - https://github.com/glscopeclient/scopehal-apps/issues/387
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #432: Refactoring: split document/model state out of OscilloscopeWindow into separate class - https://github.com/glscopeclient/scopehal-apps/issues/432#issuecomment-1265854584
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #432: Refactoring: split document/model state out of OscilloscopeWindow into separate class - https://github.com/glscopeclient/scopehal-apps/issues/432
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #475: Trigger properties update for every digit entered - https://github.com/glscopeclient/scopehal-apps/issues/475#issuecomment-1265855634
<_whitenotifier-7> [scopehal-apps] azonenberg closed issue #475: Trigger properties update for every digit entered - https://github.com/glscopeclient/scopehal-apps/issues/475
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #511: ngscopeclient: marker support - https://github.com/glscopeclient/scopehal-apps/issues/511
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #511: ngscopeclient: marker support - https://github.com/glscopeclient/scopehal-apps/issues/511
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #512: ngscopeclient: file load/save support - https://github.com/glscopeclient/scopehal-apps/issues/512
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #512: ngscopeclient: file load/save support - https://github.com/glscopeclient/scopehal-apps/issues/512
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #513: ngscopeclient: trigger configuration support - https://github.com/glscopeclient/scopehal-apps/issues/513
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #513: ngscopeclient: trigger configuration support - https://github.com/glscopeclient/scopehal-apps/issues/513
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #514: ngscopeclient: scope sync wizard (w/ vulkan accelerated correlations) - https://github.com/glscopeclient/scopehal-apps/issues/514
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #514: ngscopeclient: scope sync wizard (w/ vulkan accelerated correlations) - https://github.com/glscopeclient/scopehal-apps/issues/514
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #515: ngscopeclient: filter support - https://github.com/glscopeclient/scopehal-apps/issues/515
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #515: ngscopeclient: filter support - https://github.com/glscopeclient/scopehal-apps/issues/515
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #516: ngscopeclient: digital channel rendering - https://github.com/glscopeclient/scopehal-apps/issues/516
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #516: ngscopeclient: digital channel rendering - https://github.com/glscopeclient/scopehal-apps/issues/516
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #517: ngscopeclient: protocol channel rendering - https://github.com/glscopeclient/scopehal-apps/issues/517
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #517: ngscopeclient: protocol channel rendering - https://github.com/glscopeclient/scopehal-apps/issues/517
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #518: ngscopeclient: eye pattern rendering - https://github.com/glscopeclient/scopehal-apps/issues/518
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #518: ngscopeclient: eye pattern rendering - https://github.com/glscopeclient/scopehal-apps/issues/518
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #519: ngscopeclient: persistence, allow trace/persistence alpha configuration - https://github.com/glscopeclient/scopehal-apps/issues/519
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #519: ngscopeclient: persistence, allow trace/persistence alpha configuration - https://github.com/glscopeclient/scopehal-apps/issues/519
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #520: ngscopeclient: handle waveforms arriving at >display update rate - https://github.com/glscopeclient/scopehal-apps/issues/520
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #520: ngscopeclient: handle waveforms arriving at >display update rate - https://github.com/glscopeclient/scopehal-apps/issues/520
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #521: ngscopeclient: allow creating new WaveformArea's within a group - https://github.com/glscopeclient/scopehal-apps/issues/521
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #521: ngscopeclient: allow creating new WaveformArea's within a group - https://github.com/glscopeclient/scopehal-apps/issues/521
<azonenberg> ok well that was a wall of text lol
<lain> lol
<azonenberg> lain: how far are we from ready to merge the queue allocator stuff?
<lain> some day I will be awake :P
<azonenberg> lol
* azonenberg opens a socket and pours coffee into it
* lain goes to poke the merge right now
<lain> ok wow we stepped on each other a lot here
<azonenberg> lol oh?
<lain> ehh ok not as bad as it initially seemed
<lain> it looks like you removed the global vkFFT queue, cmd pool, and cmdbuf, and instead are using the transfer buffers for that?
<azonenberg> Not exactly. we're using the transfer buffer for initializing vkfft
<lain> oh, hm
<azonenberg> the transfer queue*
<lain> I don't see any of the vkFFT globals being used?
<azonenberg> For actually running the fft we use whatever queue is passed in to Refresh()
<azonenberg> correct
<azonenberg> they got refactored out
<azonenberg> we now need one less queue
<azonenberg> they shouldn't be there at all anymore
<lain> or wait, hm
<lain> ah, yeah
<lain> ok yeah they're gone
* lain baps git merge
<azonenberg> tl;dr it was a misunderstanding of how vkfft actually worked
<azonenberg> they have a bunch of fields you can specify at creation time or when you actually run a fft
<azonenberg> many specified at creation time are not actually used until you run a transform,
<lain> oic
<azonenberg> so basically we never actually used many of those fields i was allocating. it was easier to get rid of them entirely
<lain> ok let's see if she builds now
<lain> the other big changes are in WaveformArea, for the tone mapping.. looks like you pulled a lot of that out and put it into the new DisplayedChannel class. not too bad, just a lot of shuffling
<azonenberg> yeah that was needed to handle multiple channels per waveformarea
<lain> yeah
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #522: ngscopeclient: preferences editor - https://github.com/glscopeclient/scopehal-apps/issues/522
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #522: ngscopeclient: preferences editor - https://github.com/glscopeclient/scopehal-apps/issues/522
<lain> hm, interesting
<d1b2> <Mughees> A general comment: I see that in tektronix scope we have an option of gating the signal. There is full record gating, screen gating (perform calculation only on what is visible in the oscilloscope window), custom gating etc. In the filters we perform full record gating. Do we have a way to perform other types of gating or is it planned?
<lain> ok well it's building and running, that's progress... it seems to have deadlocked while trying to render the waveforms, I'm sure that's a bug in my queue manager introduced in the merge
<azonenberg> mughees: we're going to be doing that with louis's new "extract region of waveform" filter
<d1b2> <Mughees> Cool!
<azonenberg> There will eventually be nice gui integration
<azonenberg> where you can drag start/stop of the extracted region or something
<azonenberg> but that's a ways out
<lain> correction: glscopeclient works fine, ngscopeclient is the one that is hanging on rendering waveforms, will debug in a moment.
<azonenberg> yeah ngscopeclient is more heavily multithreaded
<lain> hmmm
<azonenberg> glscopeclient i think runs the render compute shader in the gui thread
<lain> VUID-vkCreateDevice-ppEnabledExtensionNames-01387(ERROR / SPEC): msgNum: 307460652 - Validation Error: [ VUID-vkCreateDevice-ppEnabledExtensionNames-01387 ] Object 0: handle = 0x11e832a00, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x12537a2c | Missing extension required by the device extension VK_KHR_swapchain: VK_KHR_surface. The Vulkan spec states: All required device extensions for each
<lain> extension in the VkDeviceCreateInfo::ppEnabledExtensionNames list must also be present in that list (https://vulkan.lunarg.com/doc/view/1.3.224.1/mac/1.3-extensions/vkspec.html#VUID-vkCreateDevice-ppEnabledExtensionNames-01387)
<azonenberg> is that in glscopeclient or ngscopeclient?
<lain> gl
<lain> oh interesting, I am getting a validation error in ngscopeclient tho:
<lain> VUID-VkDeviceCreateInfo-pProperties-04451(ERROR / SPEC): msgNum: 976972960 - Validation Error: [ VUID-VkDeviceCreateInfo-pProperties-04451 ] Object 0: handle = 0x13f2c0230, type = VK_OBJECT_TYPE_PHYSICAL_DEVICE; | MessageID = 0x3a3b6ca0 | vkCreateDevice: VK_KHR_portability_subset must be enabled because physical device VkPhysicalDevice 0x13f2c0230[] supports it The Vulkan spec states: If the
<lain> VK_KHR_portability_subset extension is included in pProperties of vkEnumerateDeviceExtensionProperties, ppEnabledExtensionNames must include "VK_KHR_portability_subset" (https://vulkan.lunarg.com/doc/view/1.3.224.1/mac/1.3-extensions/vkspec.html#VUID-VkDeviceCreateInfo-pProperties-04451)
<lain> it.. should be adding the portability KHR o.o
<azonenberg> So KHR_portability_subset and KHR_portability_enumeration are not the same
<azonenberg> we're using the latter not the former right now
<lain> ohh
<azonenberg> also it looks like we were only requesting KHR_surface on x11 targets. fixing that
<azonenberg> gimme a few
<azonenberg> (this is testing on mac i assume?)
<lain> correct
<lain> ok we're gonna run and get coffee, then I'll finish debugging and patching this deadlock
<_whitenotifier-7> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/glscopeclient/scopehal/compare/264b9aa05915...b4cf3783ddae
<_whitenotifier-7> [scopehal] azonenberg b4cf378 - Vulkan init: Request KHR_surface on all targets. Request KHR_portability_subset if device has it.
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #523: ngscopeclient: use VK_EXT_memory_budget if available - https://github.com/glscopeclient/scopehal-apps/issues/523
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #523: ngscopeclient: use VK_EXT_memory_budget if available - https://github.com/glscopeclient/scopehal-apps/issues/523
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #524: Sin(x)/x interpolation within rendering shader - https://github.com/glscopeclient/scopehal-apps/issues/524
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #524: Sin(x)/x interpolation within rendering shader - https://github.com/glscopeclient/scopehal-apps/issues/524
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #523: ngscopeclient: use VK_EXT_memory_budget if available - https://github.com/glscopeclient/scopehal-apps/issues/523#issuecomment-1265972763
bvernoux has quit [Read error: Connection reset by peer]
<lain> ok the coffee run turned into a food run also
<lain> now, what's this deadlocking on...
<d1b2> <azonenberg> We have preferences! Only bools are functional so far
<lain> yaay
<azonenberg> one thing i need to think about very soon is how much to diverge from glscopeclient and whether to share the prefs storage location or not
<azonenberg> because the ui is different so some settings only make sense for one side or the other
<azonenberg> i think a clean split might be better
<lain> agree
<lain> OH
<lain> ok yeah, the deadlock is obvious, derp :3
* azonenberg watches lain's philosophers fall over from starvation one by one
<lain> wat lol
<lain> ehehehe
<lain> excellent
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #525: ngscopeclient: allow connecting to scopes from command line args - https://github.com/glscopeclient/scopehal-apps/issues/525
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #525: ngscopeclient: allow connecting to scopes from command line args - https://github.com/glscopeclient/scopehal-apps/issues/525
<lain> azonenberg: pushed my changes to macos branch, I'll merge master again either tonight or tomorrow
<lain> there's a handful of vulkan validation issues with the macos branch presently, haven't had time to assign blame for them yet but there's a decent chance most of them were introduced with QueueManager, will chase those down after I merge master again
<lain> azonenberg: but, given how much I'm diverging from master at this point, if you could test this branch and see how you feel about a PR, that'd be great
<azonenberg> yeah i dont want to diverge too far
<azonenberg> i'll pull and check later tonight and see. there's a few validation errors related to resources not freed at shutdown
<azonenberg> chased down a few and still have one ongoing