<d1b2>
<Aleksorsist> Has anyone encountered this error on an intel system using integrated graphics: imgui/backends/imgui_impl_vulkan.cpp:1076: bool ImGui_ImplVulkan_Init(ImGui_ImplVulkan_InitInfo*, VkRenderPass): Assertion `info->Queue != nullptr' failed. ?
<azonenberg>
Not one i've seen before, no
<azonenberg>
aleksorsist: this is glscopeclient or ngscopeclient? and how recent?
<azonenberg>
we recently merged a bunch of lain's queue manager code which may have either caused or fixed that issue
<d1b2>
<Aleksorsist> ngscopeclient
<azonenberg>
oh derp of course its ngscopeclient the filename in question is imgui
<d1b2>
<Aleksorsist> glscopeclient starts up but crashes quietly with a seg fault though
<azonenberg>
interesting
<d1b2>
<Aleksorsist> So I suspect there's somthing deeper than just imgui
<azonenberg>
Yeah. it's only that one system it's failing on?
<d1b2>
<Aleksorsist> Building with the latest now
<d1b2>
<Aleksorsist> Yes, just my framework mobo, 11th gen i5, no discrete GPU
<azonenberg>
and linux or windows? or both?
<d1b2>
<Aleksorsist> Linux, haven't ventured into building on windows yet
<azonenberg>
Ok. Try running with --debug --trace QueueManager
<azonenberg>
see if either one gives you more interesting output
<azonenberg>
But make sure you're on latest version first
<azonenberg>
if you're running more than a week or two old, all bets are off on intel
<azonenberg>
or any system with less than a handful of vulkan queues
<d1b2>
<Aleksorsist> Ah, this was on a build a few weeks back
<d1b2>
<Aleksorsist> Currently building latest, will let you know the output when I run it
<azonenberg>
yeah so the tl;dr is that we assume we have a certain number of queues available and dedicate several to particular purposes
<azonenberg>
like drawing, host-device memory copies, and backend filter graph processing
<azonenberg>
if your hardware has less than this, older versions would just choke or give weird errors
<azonenberg>
lain's new code gives out handle objects which may be oversubscribed, and use mutexing as needed to synchronize if two need to use the same physical queue at once
<azonenberg>
it's brand new and may have bugs, so please test
<azonenberg>
but it's at least *intended* to solve your problems :)
<d1b2>
<Aleksorsist> Error'd out of the build: TRCImportFilter.cpp:64:36: error: ‘class vk::raii::Queue’ has no member named ‘m_family’ 64 | g_vkTransferQueue->m_family );
<d1b2>
<Aleksorsist> And that makes sense, the integrated graphics are a little less beefy than my main system 😛
<azonenberg>
That sounds like you're inconsistent WRT submodules
<azonenberg>
make sure you always pull recursively
<d1b2>
<Aleksorsist> I used git clone --recursive
<d1b2>
<Aleksorsist> only thing I swapped out was the scopehal folder, but this error is in scopeprotocols
<azonenberg>
Hmmmm
<azonenberg>
because g_vkTransferQueue is not a vk::raii::Queue after this refactoring
<azonenberg>
it's a std::shared_ptr<QueueHandle>
<azonenberg>
So if you still have it as the old type, somethign is inconsistent or out of date
<d1b2>
<Aleksorsist> I removed TRCImportFilter from the cmakelist and i'm at 73% through the build with no issues
<azonenberg>
oh wait
<azonenberg>
are you using louis's scopehal fork?
<azonenberg>
with current ngscopeclient?
<d1b2>
<Aleksorsist> Yup, but only the scopehal folder
<azonenberg>
yeah but still, scopehal had a lot of changes with that refactoring
<azonenberg>
That might be your problem. He might not have merged the PR
<azonenberg>
@louis: when was the last time you merged upstream scopehal to your fork?
<azonenberg>
aleksorsist: the queue manager stuff was only put in a few days ago
<azonenberg>
mixing and matching pre/post code is likely to end horribly
<azonenberg>
if it compiles, which it probably won't
<d1b2>
<Aleksorsist> Ah, I am getting quite a few errors now
<azonenberg>
yeah. you probably need to stick with older versions of ngscopeclient until louis merges these changes
<azonenberg>
the perils of being on the bleeding edge lol
<azonenberg>
unfortunately, this also means ngscoepclient probably won't work on your intel box in the meantime
<d1b2>
<Aleksorsist> Gotya
<azonenberg>
alternatively, you can build the *full* upstream version, without louis's fork
<azonenberg>
Which won't work with the thunderscope but will let you test with the demo scope to confirm at least that the queue manager code etc works on your box
<d1b2>
<Aleksorsist> I'm hoping to scrape together a demo for supercon, I have access to a laptop with an nvidia GPU so I can try that
<azonenberg>
how far out is that?
<azonenberg>
oh looks like you have a few days
<d1b2>
<Aleksorsist> This Friday!
<azonenberg>
there's a good chance we can get some of this new stuff merged by then
<azonenberg>
it would be really cool if you could show off some of the new filter graph code running by then
<azonenberg>
there have been some immense upgrades to ngscopeclient in the past few days. and i'm working on rendering of protocol decodes right now
<d1b2>
<Aleksorsist> Sweet! Protocol decode would be really cool to show off
<azonenberg>
yeah. the protocol analyzer view will likely not be ready
<azonenberg>
but the timeline view should
<d1b2>
<Aleksorsist> What kinda stuff do the filters do?
<d1b2>
<Aleksorsist> Oh and is the pico driver the only one updated with the new queue manager?
<azonenberg>
you mean the new memory allocation stuff?
<azonenberg>
lecroy and pico should be using it
<d1b2>
<Aleksorsist> Yah
<azonenberg>
at least
<azonenberg>
the queue manager, however, is deeper down in the vulkan stack
<azonenberg>
anything that does waveform rendering or gpu accelerated compute interacts with it
<azonenberg>
as far as filters, do you mean the graph editor? or the actual filter blocks themselves
<d1b2>
<azonenberg> this is a week-old demo of the graph editor
<d1b2>
<azonenberg> Great, i'll review and merge shortly after i finish the renderer stuff i'm doing
<d1b2>
<louis> It is largely a copy/paste of the DSLabs driver, so will be a good candidate for the great RemoteBridgeOscilloscope waveform transport unification at some point
<d1b2>
<Aleksorsist> Awesome, I got the new version built so I'll add the diff changes and try building again
<d1b2>
<Aleksorsist> (built and working btw, looks like the queue fix does do the trick on my platform)
<azonenberg>
Awesome
<d1b2>
<Aleksorsist> Works great, even on a weak quad core with no discrete gpu