<azonenberg>
we don't prepare for CPU access when autoscaling. the new renderer doesn't pull waveform content to the CPU (that was one of the key performance improvements)
<azonenberg>
but to autoscale you do have to pull it to the CPU. or do the min/max on GPU which might make more sense to do in the future
<azonenberg>
but autoscaling is an infrequent enough operation for now i'll just pull it
<_whitenotifier-7>
[scopehal] azonenberg 9d5fcf6 - Filter: Fixed bug where AutoscaleVertical() could see garbage data if run on a GPU filter because it didn't pull data back
<lain>
btw, it looks like it wouldn't be too much effort to support multi-gpu down the line, other than the UX for actually configuring that might be complex
<azonenberg>
not just the UX
<azonenberg>
wrangling of buffers across GPUs would be nontrivial
<lain>
hm
<azonenberg>
and figuring out which gpu to schedule which job on based on availability, relative performance if heterogeneous, and which card(s) the input resides on
<lain>
my initial thought was to distribute the queues across the gpus; though I should clarify that I'm thinking of this mostly for dedicated DSP work using scopehal, not so much actual scope UI stuff
<azonenberg>
Yes. it's on the wishlist for long term
<lain>
aye
<azonenberg>
you cant just distribute queues
<azonenberg>
it's a very NUMA system
<azonenberg>
an AcceleratorBuffer will have to be aware of where the data lives
<azonenberg>
and potentially copy it to another card or something
<lain>
ah yes
<azonenberg>
and the scheduler has to know too
<azonenberg>
so you need a NUMA aware job scheduler
<azonenberg>
it's a hard but likely solvable problem. will probably require benchmarking each system to measure latency and BW and relative speed for various operations
<azonenberg>
and/or dynamic adaptive scheduling based on actual measured transfer times on real workload
<lain>
my use case will be a bunch of independent, parallel data streams. I guess a simpler solution to that would be to just run many instances of scopehal, one for each gpu :P
<lain>
but yeah
<lain>
definitely something I'd like to poke at much longer term
<azonenberg>
basically if we half-ass something it will likely run a lot slower
<azonenberg>
it needs to be numa aware and adaptive based on a lot of factors
<azonenberg>
including the amount of video ram the filter and its inputs will require
<azonenberg>
the relative speed of the two gpus
<azonenberg>
the expected performance gain from using another card relative to the cost of migrating data
<azonenberg>
the potential to have >2 cards
<lain>
oh yeah, I totally agree it needs to be done right, and not right now
<lain>
just musing out loud
<azonenberg>
File a ticket on the tracker. against scopehal probably since it's a core library feature
<azonenberg>
just so we have it as a formal todo item
<azonenberg>
lain: while you're here how's the queue manager stuff going?
<lain>
slept in late today and took a while to boot up, going to try wrapping up the refactoring shortly :3
<azonenberg>
woo
<azonenberg>
Sounds good
<azonenberg>
In other news, made good progress on the PT5 today. I realized it's possible to convert two of the three passives in the filter I designed the other day to PCB geometry
<lain>
:D
<lain>
sweet
<azonenberg>
so it's a hybrid distributed/lumped
<azonenberg>
two stage stepped impedance filter with a skinny section for 335 pH of inductance followed by a fat section for 386 fF of capacitance
<azonenberg>
then a discrete 2.2 nH inductor for the third stage
<azonenberg>
i'm kinda impressed i managed to do any sort of distributed element filter in the footprint i had to work with here lol
<lain>
lol
<azonenberg>
but the math and simulation checks out
<azonenberg>
its quite close in response to the discrete version but one 0201 to place instead of three
<azonenberg>
and it's now a proper microwave frequency probe now that it has some magic spells^hcarefully simulated geometry on it
<azonenberg>
I'm tempted to see about even making a higher order filter, if i go 4th order the initial L/C get even smaller (so less space, then L3 drops to 1.07 nH which translates to a 647 mrad or 2.3mm long inductor
<azonenberg>
still a little large, but also within the range of what's tractable to do discrete
<azonenberg>
and the final C would be 800 fF which is very doable discrete
<azonenberg>
But for now i think i'll stick with third order as it worked well in my initial prototype
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #scopehal
massi has joined #scopehal
bvernoux has joined #scopehal
<lain>
the queue manager is working, woo
<azonenberg>
lain: yay. almost ready to merge? or waiting on other stuff?
<d1b2>
<david.rysk> what should I be testing if on macOS? 🙂
<azonenberg>
lain's local working copy i don't think she's pushed yet? :p
<azonenberg>
she just sent me an exciting screenshot of glscopeclient rendering on M1
<azonenberg>
But we have a lot of work to do still
<_whitenotifier-7>
[scopehal-apps] azonenberg 5150db7 - Uppdated to latest upstream imgui with native GetGlyphRangesGreek() support
<azonenberg>
bvernoux: oh good news. looking at the vulkan headers
<azonenberg>
// Windows defines MemoryBarrier which is deprecated and collides
<azonenberg>
// with the VULKAN_HPP_NAMESPACE::MemoryBarrier struct.
<azonenberg>
#if defined( MemoryBarrier )
<azonenberg>
#endif
<azonenberg>
# undef MemoryBarrier
<azonenberg>
seems they hit the same problem :p
<azonenberg>
also i'm hoping i've now finally nailed the last of the "destroying a vulkan object while rendering thread is still using it" problems triggered by moving waveforms between areas/groups
<azonenberg>
well apparnetly i introduced a deadlock instead
<azonenberg>
working on thaaat... :p
<bvernoux>
hello ha interesting
<bvernoux>
will be great to comment the imgui Demo at same time
<bvernoux>
I have do that on my local repo
<bvernoux>
as it is annoying ;)
<bvernoux>
for ngscopeclient of course
<azonenberg>
yeah like i said it's gonna go away but for now i still reference it a lot for debug
<azonenberg>
it's also a reminder to anyone using it that ngscopeclient is still very much an active dev scene and should not be used for real work yet :p
<bvernoux>
yes anyway it is not really usable for real work so far as we cannot use any scope except demo
<bvernoux>
I have not tried with Rigol but I doubt all link are done in the background
<bvernoux>
Also does the demo is caped to 23fps or it is a limitation on my PC ?
<bvernoux>
as I see screen refresh rate is near 60Hz (59Hz)
<azonenberg>
the demo is not capped artificially, but it does a lot of heavyweight unoptimized math to synthesize the waveforms
<azonenberg>
20ish FPS is not unreasonable
<azonenberg>
You actually can use real scopes with ngscopeclient. it's fully hooked up to the driver layer and changing gain/offset and timebase settings plus all channel configuration works
<azonenberg>
as well as adjusting trigger level
<azonenberg>
trigger position cannot be adjusted, you cannot change trigger types, and you cannot create filters yet
<azonenberg>
there's no history, cursors, or markers
<bvernoux>
ha ok great I was not aware it was usable with real scope
<azonenberg>
But like, i do a lot of my dev these days against the picoscope
<azonenberg>
usable is perhaps a bit of a strong word
<bvernoux>
I could try on my Pico3000
<azonenberg>
but the subset of gui functionality that is implemented and works with the demo should work with a real scope
<azonenberg>
one big gotcha, which is on my list to address today
<bvernoux>
ngscopeclient does not seems to take into account the parameter in cli
<azonenberg>
It supports logtools arguments
<bvernoux>
yes only --debug
<azonenberg>
you cannot connect to instruments via cli args yet
<bvernoux>
ok I confirm that
<azonenberg>
nor open files, but you cant do that from the gui either :p
<azonenberg>
There's lots of missing pieces still
<azonenberg>
anyway so the big gotcha is that since all channels in a WaveformArea share the same vertical scale/offset
<azonenberg>
you can potentially get unexpected and hardware damaging gain/offset changes if you move a channel looking at a really weak signal into a group looking at a strong one or vice versa
<azonenberg>
by setting v/div out of range for thei nput
<azonenberg>
the plan is to detect and display some sort of warning for this
<azonenberg>
that's on my list of things to work on today
<azonenberg>
i'm not going to architecturally change that since having the per plot scale makes sense. but i do want to make it hard to shoot yourself in the foot
<bvernoux>
ha yes it can damage scope especially on 50Ohms Input I doubt it can damage scope with 1MHOhms input
<bvernoux>
as they are pretty well protected
<azonenberg>
yeah it's mostly for e.g. my SDA
<azonenberg>
where there's a 5V cap for inputs above a certain V/div
<azonenberg>
but i think 2V below
<azonenberg>
So the plan is to add a big warning over the plot starting as soon as you drag into it
<azonenberg>
and continuing until the v/div is next changed
<azonenberg>
saying that vertical axis scales are mismatched and to double check that it's safe to adjust channel X to match
<azonenberg>
but first i have to finish fixing all of these thread safety problems
<azonenberg>
the vulkan validation layers make it relatively easy but i keep finding new race conditions lol
<bvernoux>
yes it is a great things
<bvernoux>
I'm finalyzing my order on mouser does there is interesting stuff I could add ?
<bvernoux>
I have added the Analog Device
<bvernoux>
EVAL-ADUM4166EBZ it seems pretty amazing
<bvernoux>
it si an isolator for USB 2 LS/FS/HS
<bvernoux>
with their latest chipset
<bvernoux>
it is mandatory for EMI/EMC measurements with DUT with USB which is pretty common today ;)
massi has quit [Remote host closed the connection]
<_whitenotifier-7>
[scopehal-apps] azonenberg 8534e4f - Fixed a bunch of thread safety issues in rendering and waveform processing
<_whitenotifier-7>
[scopehal-apps] azonenberg 5734ada - Initial work on scale mismatch detectino. Fixed bug where timeline was scaled by DPI scale twice in the X axis
<azonenberg>
and yeah there's still a lot of work to do in ngscopeclient as you've probably seen. We're essentially rebuilding a project that took like five years to build the first time in a couple of months lol
<azonenberg>
sure we're copying a ton of code, but there's also a fair number of architectural changes etc
<azonenberg>
and just going by number of lines of code ngscopeclient is half the size of glscopeclient
<azonenberg>
which should give you a rough idea of how much more there still is to build :p
<d1b2>
<louis> immediate next is PR the pulse width filter, clip filter, window filter, and changes to histogram filter I'm carrying.
<azonenberg>
Great. let me know when you have those ready. and obviously make sure they include docs
<azonenberg>
i want to work on documenting our existing filter base more, but right now ngscopeclient is my bigger priority
<bvernoux>
I have found a way to crash ngscopeclient
<bvernoux>
what is strange is when we drag window
<bvernoux>
the channels are mixed
<azonenberg>
what do you mean , mixed?
<azonenberg>
it's processing false drag and drop events when you're not actually dragging?
<bvernoux>
yes
<bvernoux>
when dragging
<bvernoux>
the refresh is extremely strange
<bvernoux>
and if you insist left right quickly ngscopeclient crash
<bvernoux>
to reproduce drag performance metrics on right
<bvernoux>
then open demo
<bvernoux>
on center
<bvernoux>
during demo scroll the bar (between 4 chan & performance metrics on right)from left right
<bvernoux>
it is not scroll the bar but more drag the horizontal bar
<bvernoux>
during drag of the bar we see channel 4 jump to chan 1 and so on on other chan
<bvernoux>
like there is something ugly happen in GPU memory ...
<bvernoux>
when we stop grabing and moving to right or left all is normal
<azonenberg>
h/o still compiling latest after merge
<bvernoux>
and if you insit drag horizontal bar left then right then left then right quickly it crash
<bvernoux>
I'm using latest merge
<bvernoux>
before before latest merge it was the same
<bvernoux>
you shall open all performance metrics to add pressure on things and it crash
<bvernoux>
yes crashed
<bvernoux>
let check where it crash with gdb ;)
<azonenberg>
ok so, starting out with a new session
<bvernoux>
(gdb) bt
<bvernoux>
#0 0x0000000056f2f96b in vkGetInstanceProcAddr () from C:\Windows\System32\DriverStore\FileRepository\nvami.inf_amd64_a3d5bcc37ff12fed\nvoglv64.dll
<bvernoux>
#2 0x00007ff7256905f3 in ImGui_ImplVulkan_AddTexture (sampler=<optimized out>, image_view=<optimized out>, image_layout=image_layout@entry=VK_IMAGE_LAYOUT_GENERAL) at C:\msys64\home\bvern\scopehal-apps\src\imgui\backe
<bvernoux>
#1 0x0000000056f5ce72 in vkGetInstanceProcAddr () from C:\Windows\System32\DriverStore\FileRepository\nvami.inf_amd64_a3d5bcc37ff12fed\nvoglv64.dll
<azonenberg>
dock performance metrics window on right side?
<bvernoux>
nds\imgui_impl_vulkan.cpp:1175
<bvernoux>
#3 0x00007ff725721e7c in Texture::Texture (this=this@entry=0x1b9fea7d1c0, device=..., imageInfo=..., mgr=mgr@entry=0x1b9ff906470, name="DisplayedChannel.m_texture") at C:\msys64\home\bvern\scopehal-apps\src\ngscopecli
<bvernoux>
ent\TextureManager.cpp:183
<bvernoux>
#4 0x00007ff72572e9e5 in std::_Construct<Texture, vk::raii::Device&, vk::ImageCreateInfo&, TextureManager*, char const (&) [27]> (__p=0x1b9fea7d1c0) at C:/msys64/mingw64/include/c++/12.2.0/bits/stl_construct.h:119
<bvernoux>
.) at C:/msys64/mingw64/include/c++/12.2.0/bits/shared_ptr_base.h:1665
<bvernoux>
#13 0x00007ff72572f062 in WaveformArea::RenderWaveforms (this=this@entry=0x1b990aacc10, start=start@entry=..., size=size@entry=...) at C:\msys64\home\bvern\scopehal-apps\src\ngscopeclient\WaveformArea.cpp:433
<bvernoux>
#14 0x00007ff7257333cd in WaveformArea::Render (this=0x1b990aacc10, iArea=iArea@entry=1, numAreas=4, clientArea=..., clientArea@entry=...) at C:\msys64\home\bvern\scopehal-apps\src\ngscopeclient\WaveformArea.cpp:383
<bvernoux>
#15 0x00007ff725735016 in WaveformGroup::Render (this=this@entry=0x1b9ff9a4ae0) at C:\msys64\home\bvern\scopehal-apps\src\ngscopeclient\WaveformGroup.cpp:147
<bvernoux>
#16 0x00007ff7256e208e in MainWindow::RenderUI (this=0x1b9ff905d70) at C:\msys64\home\bvern\scopehal-apps\src\ngscopeclient\MainWindow.cpp:376
<bvernoux>
#17 0x00007ff7257273b5 in VulkanWindow::Render (this=0x1b9ff905d70) at C:\msys64\home\bvern\scopehal-apps\src\ngscopeclient\VulkanWindow.cpp:387
<bvernoux>
#18 0x00007ff72592fc0b in main (argc=<optimized out>, argv=<optimized out>) at C:\msys64\home\bvern\scopehal-apps\src\ngscopeclient\main.cpp:142
<bvernoux>
yes
<bvernoux>
with all performance counter visible
<bvernoux>
else the crash seems to do not appears
<bvernoux>
that seems to add pressure on something shared ;)
<bvernoux>
when you drag the central horizontal bar to left or right during dragging you see the weird effect of channels mixed The 4 Chan appears quickly on Chan1 ...
<bvernoux>
It was not the case 2 days ago
<azonenberg>
I don't see any of that
<bvernoux>
ha
<bvernoux>
I can do a video
<bvernoux>
I have tested that only on Windows10 so far
<azonenberg>
and crashing in vkgetinstanceprocaddr sounds like a GPU driver problem
<azonenberg>
the last few issues you've complained about seem to be driver related, like weird performance regressions in code nobody's changed
<bvernoux>
yes it is really possible it is only on my old GPU it is why I try to explain what I'm doing
<bvernoux>
and as you have added big pressure on stuff with optimizations queues ;)
<bvernoux>
I will launch the validator to check if it see something
<azonenberg>
lain's recent queue fixes should do the opposite, it's resulting in better synchronization
<azonenberg>
and yes definitely do that
<azonenberg>
(but her queue work is not yet merged)
<bvernoux>
my crash seems to be related to #11 DisplayedChannel::UpdateSize (this=0x1b9fd1b7620, newSize=..., top=0x1b9ff905d70) at C:\msys64\home\bvern\scopehal-apps\src\ngscopeclient\WaveformArea.cpp:112
<bvernoux>
as after it is not in ngscopeclient code
<azonenberg>
no, it still is. it drops into libstdc++, but #3 is in the Texture class
<bvernoux>
hmm also
<bvernoux>
#3 0x00007ff725721e7c in Texture::Texture (this=this@entry=0x1b9fea7d1c0, device=..., imageInfo=..., mgr=mgr@entry=0x1b9ff906470, name="DisplayedChannel.m_texture") at C:\msys64\home\bvern\scopehal-apps\src\ngscopeclient\TextureManager.
<bvernoux>
cpp:183
<bvernoux>
to be checked if all is normal
<azonenberg>
ultimately if you go all the way down it asks imgui to allocate a texture handle then it calls out to vulkan and the vulkan call then dies
<bvernoux>
yes
<azonenberg>
most likely what's happening is your driver is in some kind of bad state
<bvernoux>
it is reproduced by dragging hard ;)
<azonenberg>
(possibly, but not necessarily, as a result of something we're doing)
<azonenberg>
and this is a symptom, not the root cause
<bvernoux>
during drag you do not reproduce the weird effect of chan4 to be copied in chan1 ?
<bvernoux>
we see clearly that even if it is ultra quick during dragging
<bvernoux>
as the color as so different
<azonenberg>
no
<azonenberg>
that sounds like a driver bug messing up pointers somehow
<azonenberg>
also possible some kind of strange race condition on our side
<bvernoux>
ok so you do not reproduced any weird effect during dragging ?
<bvernoux>
even doing it fast ?
<azonenberg>
No
<azonenberg>
it works totally fine
<azonenberg>
no validation errors either
<azonenberg>
i spent a lot of time yesterday and the day before chasing thread safety issues, most of which only were detected by the validation layer (and i think some are false positives)
<azonenberg>
have not seen any since
<bvernoux>
hmm I have that big warning with Vulkan
<bvernoux>
YNC-HAZARD-WRITE_AFTER_READ(ERROR / SPEC): msgNum: 1261721012 - Validation Error: [ SYNC-HAZARD-WRITE_AFTER_READ ] Object 0: handle = 0x26bbd95b110, name = VulkanWindow.renderQueue, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0x4b3455b4 | vkQueueSubmit: Hazard WRITE_AFTER_READ for entry 0, VkCommandBuffer 0x26bc65434d0[MainWindow.m_cmdBuffer], Recorded access info (recorded_usage: SYNC_COMPUTE_SHADER_SHADER_STORAGE_WRITE, command:
<bvernoux>
= VK_OBJECT_TYPE_DESCRIPTOR_SET; | MessageID = 0x5a52c6ec | Cannot call vkUpdateDescriptorSets() on VkDescriptorSet 0x0[] that has not been allocated in pDescriptorWrites[0].
<bvernoux>
DLE, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; | MessageID = 0x5a52c6ec | Cannot call vkUpdateDescriptorSets() on VkDescriptorSet 0x0[] that has not been allocated in pDescriptorWrites[0].
<bvernoux>
Objects: 1
<bvernoux>
[0] 0, type: 23, name: NULL
<bvernoux>
Thread 1 received signal SIGSEGV, Segmentation fault.
<bvernoux>
0x0000000056f2f96b in vkGetInstanceProcAddr () from C:\Windows\System32\DriverStore\FileRepository\nvami.inf_amd64_a3d5bcc37ff12fed\nvoglv64.dll
<bvernoux>
in addition to previous ones of course I just copy the new ones produced with the crash
<bvernoux>
Something not allocated I'm not sure that help you
<azonenberg>
so i think we have two different issues
<bvernoux>
I will try on my native Xubuntu 22.04LTS on same PC too
<bvernoux>
will be interesting to see if I can reproduce same issue or not with exactly same HW/PC but XUbuntu with different GPU driver
<bvernoux>
Anyway except doing that crazy stuff all seems to works perfectly
<azonenberg>
So all of this is pointing to races between WaveformThread and the main thread
<bvernoux>
So full traces from start to crash with bt
<azonenberg>
well i have no idea how/why it would be crashing there
<azonenberg>
thats a separate issue from the data races
<bvernoux>
yes there is 2 issues
<azonenberg>
but likely related to the descriptor set issue
<azonenberg>
So the sync issue is that we call vkCmdDispatch which writes to a storage image, then a fragment shader later reads from it
<bvernoux>
the 1st one at start of demo it maybe just some warnings as it does not affect anything visible on the demo( when I do not drag horizontal center bar)
<azonenberg>
or actually no, wait
<azonenberg>
when you're not dragging you're redrawing less often
<azonenberg>
it's likely not hitting th erace
<azonenberg>
it's still displaying the texture on screen at 60fps but the texture isn't being modified often
<azonenberg>
dragging forces constant re-renders
<bvernoux>
ha yes
<azonenberg>
so that's expected if there's a data raec between the two threads
<azonenberg>
anyway so it looks like we're calling vkCmdDispatch early on, then vkCmdDrawIndexed later
<azonenberg>
and the compute dispatch is writing after the draw command has already read the image
<bvernoux>
and it probably appears because of my old CPU/slow GPU ;)
<azonenberg>
so we're missing a barrier
<azonenberg>
very likely, yes
<bvernoux>
it is always interesting to test on obsolete computer ;)
<azonenberg>
The problem is, like i said, we already had a barrier to prevent exactly this hazard
<azonenberg>
so i'm confused as to how we are failing to sync
<bvernoux>
it could be also a bug in the old driver ...
<bvernoux>
NVidia official driver version 425.31 as on that old GPU I cannot use a more recent one
<azonenberg>
ok so, in WaveformArea.cpp:653, 654
<azonenberg>
nvm
<azonenberg>
no, that looks good. so i'm confused
<azonenberg>
this is basically the exact exmple in the vulkan sdk docs
<azonenberg>
write in compute shader then read in frag shader
<bvernoux>
last event before crash seems related to TextureManager.cpp line 183
<bvernoux>
#5 0x00007ff725721e7c in Texture::Texture (this=this@entry=0x1d05bd7aa00, device=..., imageInfo=..., mgr=mgr@entry=0x1d05ed0db20,
<bvernoux>
name="DisplayedChannel.m_texture") at C:\msys64\home\bvern\scopehal-apps\src\ngscopeclient\TextureManager.cpp:183
<azonenberg>
yes the crash is deep inside vulkan though. in a way that implies some state is corrupted
<azonenberg>
imo
<azonenberg>
anyway i have some ideas for handling the other issue
<bvernoux>
there is also a call to
<bvernoux>
/ Register a texture
<bvernoux>
/ FIXME: This is experimental in the sense that we are unsure how to best design/tackle this problem, please post to https://github.com/ocornut/imgui/pull/914 if you have suggestions.
<_whitenotifier-7>
[scopehal-apps] azonenberg db5bedb - Fixed bug where "[DEBUG BUILD]" message was incorrectly shown in title bar of release builds
<_whitenotifier-7>
[scopehal-apps] azonenberg 9e485cd - Don't call RenderUI() until previous render has completed, to avoid possible races modifying textures last frame is still using
<azonenberg>
bvernoux: i moved a sync point a little bit earlier
<azonenberg>
let me know if that fixes the issues when panning horizontally
<azonenberg>
ngscopeclient itself should work under visual studio now, however i think there are a few gtk dependencies under libscopehal/scopeprotocols
<azonenberg>
which i am working to eliminate
<azonenberg>
But it's not my top priority at this time
<bvernoux>
ha ok
<bvernoux>
what is the next big step for ngscopeclient ?
<bvernoux>
ok built finished let's test your fix
<bvernoux>
so during vertical bar drag I have still the strange effect where all chan are super-imposed on Chan1
<bvernoux>
(Chan1=Tone)
<bvernoux>
I have reproduced the crash when dragging ultra fast ...
<azonenberg>
when you say vertical bar drag
<azonenberg>
do you mean adjusting vertical axis offset?
<bvernoux>
just dragging the window
<bvernoux>
as at left there is scope demo and at right perf
<bvernoux>
so I drag the Perf Window which Increase the size of Perf and decrease the size of Demo channels
<azonenberg>
So you're adjusting the split
<bvernoux>
anyway ngscopeclient demo is 2 times faster than latest glscopeclient in full screen
<bvernoux>
even more in fact if we take into account rendering speed
<azonenberg>
ok so while dragging the split a bunch i did reproduce the VK_NULL_HANDLE crash
<azonenberg>
i'll look at that after work, busy writing a report
<bvernoux>
ha ok interesting
<azonenberg>
Likely triggered by a background thread trying to render while a resize is in progress
<bvernoux>
what you do not reproduce is the strange refresh of demo channels when dragging the split ?
<azonenberg>
or something to that effect
<azonenberg>
No. when dragging the split i just see the images go blank briefly
<azonenberg>
this could be the same thing, it might be uninitialized memory
<azonenberg>
and you see old frames while i see blank
<azonenberg>
i'll investigate
<bvernoux>
ha ok me there is blank but also all chans on Tone chans ;)
<bvernoux>
briefly
<bvernoux>
until I stop dragging
<bvernoux>
after all is perfect of course
<bvernoux>
no any artifact or strange things when zoom in/out or just let running demo
<azonenberg>
yeah this is likely a race condition between the background rendering thread and the resize thread
<azonenberg>
the main thread doing resize events, i mean
<azonenberg>
we already have some sync between them but it might not be sufficient
<bvernoux>
I have rendering between 50 to 56Hz in full screen too
<bvernoux>
and Acquisition between 21 / 22 Hz
<azonenberg>
So it's not able to sustain 60 Hz rendering on your older CPU, interesting but not entirely surprising
<bvernoux>
with scope pending waveforms 0 or 1
<bvernoux>
so all is very good
<azonenberg>
but yes. overall ngscopeclient is performing massively better than glscopeclient
<azonenberg>
we just have to finish building it :)
<bvernoux>
yes framerate is quite random
<bvernoux>
between 52 to 58
<bvernoux>
more often between 56Hz
<bvernoux>
but it is night & day in comparison to glscopeclient especially I see the huge different with menu
<bvernoux>
in glscopeclient as it is something like 13fps menu are very slow to display
<bvernoux>
even more as it is done in gtk ...
<bvernoux>
so for a faire comparison I will say glscopeclient full screen <13fps when ngscopeclient full screen is about 55fps (I prefer to use Rendering frame rate as comparison vs Acquisition)
<azonenberg>
Well, they're different metrics. also completely different architectures wrt rendering
<azonenberg>
glscopeclient is an on-demand render model where every time something changes it runs the compute shaders then redraws the ui
<bvernoux>
So it is clearly a very huge improvement displaying exactly the same things except there is no opacity in nglscopeclient so far
<azonenberg>
ngscopeclient is an asynchronous, decoupled model where the renderer runs at a constant 60 Hz
<azonenberg>
and everything else runs in background threads
<azonenberg>
There actually is alpha blending on the traces
<azonenberg>
but it's hard coded to something like 0.8
<azonenberg>
there's no gui slider for adjusting it yet
<bvernoux>
Yes we see that even more on old CPU and old GPU ;)
<bvernoux>
ha ok so the channels are using same settings now like glscopeclient
<azonenberg>
yes channel settings should be fully functional if you double click the channel button box
<azonenberg>
all of the controls should work
<bvernoux>
so it shall be not slower in future which is a very good news
<bvernoux>
yes that things works too
<azonenberg>
timebase settings are done and working too
<azonenberg>
you can see trigger level and i think adjust it
<azonenberg>
i dont think i did trigger position yet
<azonenberg>
and trigger properties is unimplemented so far
<bvernoux>
it will be great to add WFM & fps in bottom in ngscopeclient too
<bvernoux>
to avoid using perf for that ;)
<azonenberg>
I removed it because i didn't see that as being relevant to non-developers
<bvernoux>
ha yes
<bvernoux>
for demo it is nice
<azonenberg>
also to display separate rendering and acquisition performance
<azonenberg>
now that the two are more loosely coupled in ngscopeclient
<azonenberg>
there's also more detailed performance metrics for the actual rasterization, tone mapping, etc
<bvernoux>
but yes perf window is more advanced it is just to compare with really full screen it is hard ;)
<azonenberg>
you can dock the perf window inside the app and fullscreen, no?
<bvernoux>
but it is clearly not very important it is more for the whaoo effect when comparing glscopeclient and ngscopeclient
<bvernoux>
yes I'm docking perf but it take some space to read the value
<bvernoux>
also the unit in V/mV are more clean on ngscopeclient
<bvernoux>
in glscopeclient they often overlap ...
<azonenberg>
yes i made some tweaks to how I calculate y axis positions in ngscopeclient
<azonenberg>
i want to improve more
<azonenberg>
but this is very much a full graphical revamp, not a simple port from gtk to imgui
<bvernoux>
I'm impatient to see the filter with right mouse button in ngscopeclient ;)
<azonenberg>
i'm more excited for the new filter graph editor
<azonenberg>
lol
<bvernoux>
yes clearly we feel it is a full revamp
<azonenberg>
but i have a lot of other things to do too
<azonenberg>
the history system is getting totally redone in particular
<bvernoux>
ha yes new filter graph will be amazing
<azonenberg>
one view, not one per instrument anymore
<bvernoux>
ha great
<azonenberg>
And the history subsystem will make much more efficient use of memory
<bvernoux>
the popup with ngscopeclient is also very nice
<bvernoux>
with explanation of things
<bvernoux>
on the ? too
<azonenberg>
yeah
<bvernoux>
clearly a must have which was impossible with GTK in glscopeclient
<azonenberg>
i wouldnt say impossible
<azonenberg>
but much more work
<bvernoux>
yes ;)
<azonenberg>
i'm trying to include help text everywhere in the app that it reasonably makes sense
<azonenberg>
so let me know if you find somewhere i missed
<azonenberg>
one challenge is making sure they dont interfere with dragging or other navigation
<azonenberg>
so sometimes i have slightly longer delaysd to make it easier to grab things without a tooltip getting in the way
<bvernoux>
yes I checked that in different place (mainly with demo) so far it is very nice clean and clear
<bvernoux>
also Play / Pause is instant now
<bvernoux>
not with 5s delay in glscopeclient even on the demo ;)
<bvernoux>
and the full screen work perfectly
<bvernoux>
things which was clearly not trivial to fix for Windows with glscopeclient
<azonenberg>
Yeah with glfw it just works
<azonenberg>
anyway, lots more work to do
<azonenberg>
speaking of which
<azonenberg>
lain: are you awake yet? :p
<bvernoux>
what is missing is change of volt div
<azonenberg>
not missing
<azonenberg>
mouse wheel on y axis
<bvernoux>
it change with mouse scroll but when demo is paused it does not refresh the chan
<azonenberg>
That's the bug i fixed in the latest commit
<bvernoux>
ha
<azonenberg>
42eb53f
<bvernoux>
yes it is fixed in demo Play
<bvernoux>
but if you stop it does not refresh
<azonenberg>
yes, that's the bug that commit fixes
<bvernoux>
you need to force a refresh doing horizontal things
<bvernoux>
ok let's check if I have it
<azonenberg>
What happened is, i converted full scale range from the driver layer to y axis units per pixel cached in the view object
<azonenberg>
at the start of the frame
<azonenberg>
late in the frame i'd check for mouse wheel events and dispatch a re-render request if you had changed scale
<azonenberg>
the re-render would then run in a background thread
<azonenberg>
with the old cached units per pixel
<azonenberg>
then next frame it would happily show you the "new" texture containing identical data
<azonenberg>
then update the cached units per pixel, but not actually pass *that* value to the shader until another re-render happened
<bvernoux>
ha yes there was a conflict ;)
<bvernoux>
with my local modification (commenting imgui demo in MainWindow.cpp)
<bvernoux>
so I have not few fixes
<azonenberg>
yeah like i said, the demo is eventually going to go away but i still refer to it very often
<azonenberg>
so i'm keeping it for a while
<azonenberg>
i do need to figure out why it won't go away when yo uclick close though
<bvernoux>
let's rebuild
<bvernoux>
so thing shall be fixed even the crash maybe
<bvernoux>
Updating 0daf7d1..42eb53f
<bvernoux>
Submodule path 'lib': checked out '6a582b0d69d6cff237dbdead82f91637e3570a7e'
<bvernoux>
Submodule path 'src/imgui': checked out '69beaa1d0b7fc8f4b448dcf1780b08cfc959da65'
<bvernoux>
also with new icons
<azonenberg>
the VK_NULL_HANDLE error when resizing the splitter i havent touched
<azonenberg>
and yes, the new icon is displayed when you try to drag a channel into one that has vastly different (more than 20% zoomed in) range
<azonenberg>
as a warning that if you try to set both channels to the same scale you might overdrive inputs
<bvernoux>
ha yes great but I will do not see that on demo
<bvernoux>
I will try ;)
<bvernoux>
it rebuild scopehal
<bvernoux>
For infor KiCad 6.0.8 is available
<bvernoux>
It contains mainly fixes
<bvernoux>
We shall convince KiCad team to switch to ImGui for KiCad 8 ;)
<bvernoux>
wxWidget is awfull ;)
<bvernoux>
full of multiplatform bugs and events are so awfully managed
<azonenberg>
kicad would be much more work to rewrite than glscopeclient. i'm skeptical they'd even attempt it
<bvernoux>
yes me too
<bvernoux>
anyway I'm clearly convinced the effort to do ngscopeclient is the best possible move for the project
<azonenberg>
ok so, i figured out the problem with the VK_NULL_HANDLE error
<azonenberg>
it's actually a resource leak. the descriptor pool for imgui has a 1000 total texture limit and the destructor for Texture never frees those handles
<azonenberg>
it frees the Vulkan memory object, image view, etc
<azonenberg>
everything but the descriptor set
<azonenberg>
which is allocated by imgui using the vulkan C API so our C++ RAII layer doesn't automatically free it
<bvernoux>
I have reproduced the crash with fast drag
<azonenberg>
It's not just fast drag
<bvernoux>
with latest build
<azonenberg>
every time you resize it creates N new textures for the N open waveform areas
<azonenberg>
once you've leaked a total of 1000 handles, future allocations return null
<bvernoux>
ha ok
<bvernoux>
so you have found a memory leak ?
<azonenberg>
So we just have to make Texture::~Texture() call vkFreeDescriptorSets
<bvernoux>
ha great news
<bvernoux>
so you will push the fix soon
<azonenberg>
Yeah. just figuring out how to do this as i'm used to the C++ wrapper layer
<azonenberg>
not the raw c
<bvernoux>
it's GPU memory leak ;)
<azonenberg>
driver memory actually
<bvernoux>
ok
<azonenberg>
a descriptor set is metadata, not the actual texture
<azonenberg>
we do free the VkDeviceMemory containing the pixels
<bvernoux>
I'm checking latest build with Vulkan
<bvernoux>
validation
<bvernoux>
I confirm I do not have any Vulkan Warning now
<bvernoux>
even when running demo
<bvernoux>
so you have fixed that issue I confirm
<bvernoux>
1st issue with strange warning/errors
<bvernoux>
so the remaining ones is the crash because of memory leak
<bvernoux>
the only strange things is the refresh when I drag the bar
<bvernoux>
when I have a window on right like performance metrics
<bvernoux>
which show an artifact with all chans on chan1 ...
<bvernoux>
ha nice the warning
<bvernoux>
I confirm when demo is paused
<bvernoux>
changing vertical scale refresh the chan too ;)
bvernoux has quit [Quit: Leaving]
nelgau_ has quit [Remote host closed the connection]