<_whitenotifier-7>
[scopehal-apps] azonenberg 5005b2d - Preferenecs schema: commented out all prefs from glscopeclient that don't yet do anything in ngscopeclient, to avoid confusion. See #522.
<d1b2>
<Mughees> #0 0x00007fffe9ba2624 in () at /usr/lib/x86_64-linux-gnu/libvulkan_intel.so #1 0x00007ffff6487ba1 in vk::raii::Queue::submit(vk::ArrayProxy<vk::SubmitInfo const> const&, vk::Fence) const (fence=..., submits=<optimized out>, this=0x5555561fd2e0) at /home/mughees/vulkan/1.3.224.1/x86_64/include/vulkan/vulkan_raii.hpp:10417 #2 SubmitAndBlock(vk::raii::CommandBuffer&, vk::raii::Queue&) (cmdBuf=..., queue=...) at
<d1b2>
/home/mughees/scopehal-apps/lib/scopehal/scopehal.cpp:830 #3 0x00005555557f4cbd in WaveformArea::RenderTrace(WaveformRenderData ) (this=0x555556477000, data=0x555555a74060) at /home/mughees/scopehal-apps/src/glscopeclient/WaveformArea_rendering.cpp:657 #4 0x00005555557f37ba in WaveformArea::on_render(Glib::RefPtr<Gdk::GLContext> const&) (this=0x555556477000) at /home/mughees/scopehal-apps/src/glscopeclient/WaveformArea_rendering.cpp:406 #5
<d1b2>
0x00007ffff772202c in Gtk::GLArea_Class::render_callback(_GtkGLArea , _GdkGLContext ) () at /lib/x86_64-linux-gnu/libgtkmm-3.0.so.1 #6 0x00007ffff564eb21 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #7 0x00007ffff5ac2640 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x00007ffff5ac27a3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x00007ffff5472ebd in () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #10
<d1b2>
0x00007ffff77b1a8e in Gtk::Widget::on_draw(Cairo::RefPtr<Cairo::Context> const&) () at /lib/x86_64-linux-gnu/libgtkmm-3.0.so.1 #11 0x00007ffff77ab779 in Gtk::Widget_Class::draw_callback(_GtkWidget , _cairo*) () at /lib/x86_64-linux-gnu/libgtkmm-3.0.so.1 #12 0x00007ffff5606b64 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #13 0x00007ffff53e7825 in gtk_container_propagate_draw () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #14 0x00007ffff53e792d in () at
<d1b2>
/lib/x86_64-linux-gnu/libgtk-3.so.0
<azonenberg>
interesting, so it's dying in queue submit
<azonenberg>
In libvulkan
<azonenberg>
oh wait
<azonenberg>
this is an intel gpu
<azonenberg>
if you run with --debug how many queue families / queues does it show?
<azonenberg>
does it shows a single queue family with one queue in it?
<d1b2>
<Mughees> let me check
<azonenberg>
if so, this is likely how the intel driver handles (not at all) you trying to use a second or third queue when it only has one
<azonenberg>
lain's queue allocator work should fix this when it's merged to master
<azonenberg>
hopefully any day now
<d1b2>
<Mughees> yeah queue coun ti s1
<d1b2>
<Mughees> is 1
<d1b2>
<Mughees> *
<d1b2>
<Mughees> but it was working in my previous version of ubunntu 20 I guess
<d1b2>
<Mughees> My hard had dies so this is a new setup with latest ubunutu
<azonenberg>
Yeah that's odd. it might be undefined behavior where we got unlucky this time and not before
<azonenberg>
just to check, since it's dying in vulkan
<azonenberg>
run vkconfig, select the validation layer
<d1b2>
<Mughees> anything I can do to unblock myself?
<azonenberg>
turn on all of the validation areas including gpu assisted validation
<azonenberg>
select all message severities except info
<azonenberg>
and see if you get any errors on stdout
<d1b2>
<Mughees> I am not an expert on this stuff
<d1b2>
<Mughees> Doing Embedded for years does this to one 🙂
<azonenberg>
Here's how you should configure vkconfig. leave it open then relaunch glscopeclient
<azonenberg>
it won't fix the issue but will give us more info to investigate
<azonenberg>
and confirm if it is indeed the queue allocation problem or not
<d1b2>
<Mughees> where is this utility found?
<azonenberg>
vkconfig, it's part of the vulkan SDK
<d1b2>
<Mughees> i installed vulkan using getting started
<azonenberg>
should be in your path if you have the sdk installed
<d1b2>
<Mughees> doc
<azonenberg>
if it does indeed complain about you using nonexistent queues, there is a hack you can make to the code always use queue #0. this may result in threading race conditions and other problems when using GPU accelerated filters
<azonenberg>
but if you're not using any of them, it may unblock you
<d1b2>
<Mughees> ok
<azonenberg>
The fix is, patch AllocateVulkanComputeQueue() in lib/scopehal/VulkanInit.cpp to return constant zero
<azonenberg>
like i said lain has a proper queue allocator revamp landing soon but it's not ready to merge yet
<d1b2>
<ehntoo> I have a vague memory of @Mughees having to do the queue hack in the past.
<azonenberg>
ehntoo: how are things going on your end? working on anything in particular?
<d1b2>
<Mughees> no i did not do anything
<azonenberg>
mughees: anyway, try it and see if it fixes the crash
<d1b2>
<ehntoo> @azonenberg I discovered that the AVX512f issues are actually general clang issues and I'll be doing a little more debugging too wrap up the macOS GitHub CI runner in the next few days. Other than that I'm planning on working some more on the Rigol scope driver.
<d1b2>
<Mughees> yeah setting queue to zero worked. Thanks
<azonenberg>
mughees: great. just make sure to not include that change with any PRs you send
<azonenberg>
as it's very much a temporary workaround that will e.g. likely break the FFT or de-embed filters
<d1b2>
<Mughees> Yeah. Noted
<d1b2>
<Mughees> only my changes
<d1b2>
<Mughees> to filters
<azonenberg>
The proper solution lain is working on is an allocator that hands out queue handle objects that may outnumber physical queues on the hardware
<azonenberg>
and will use mutexing as needed when a physical queue is oversubscribed
<azonenberg>
so we can have each thread get a separate queue handle regardless of how many physical queues are present
<azonenberg>
Expecting to merge that in the next day or two
<bvernoux>
D:\a\_temp\msys64\tmp\cc8wjnWy.s: Fatal error: src/ngscopeclient/CMakeFiles/ngscopeclient.dir/WaveformGroup.cpp.obj: No space left on device
<azonenberg>
bvernoux: you can try building one target at a time then deleting object files form that build before moving on
<azonenberg>
e.g. build scopehal only. remove *.obj from the build directory
<azonenberg>
then build scopeprotocols. delete *.obj
<bvernoux>
ha yes
<azonenberg>
etc
<azonenberg>
also clean all of the objects from the vulkan sdk
<bvernoux>
the history is great in latest ngscopeclient
<azonenberg>
It's unified for all scopes now btw
<bvernoux>
cursor is very smooth too
<azonenberg>
if you're doing multiscope, one history window for everything
<bvernoux>
ha great feature
<azonenberg>
Y axis cursors are unimplemented and there's no readout of values on the cursors yet
<bvernoux>
with the way to pin some waveform it is great
<azonenberg>
so still more work to d
<azonenberg>
to do
<bvernoux>
to compare or for other purpose
<azonenberg>
you also can't do marking yet like you could in glscopeclient
<azonenberg>
where you can create a fixed cursor that stays with a waveform, and shows up as a label in history
<bvernoux>
yes it is not a big issue I'm impatient to see filters in realtime with the menu ;)
<azonenberg>
Coming :)
<bvernoux>
It will be the real game changer vs glscopeclient which was pretty slow for that
<bvernoux>
on my old GFX card ...
<azonenberg>
So one of the reasons it was slow is that right now it instantiates one of every filter when you right click
<azonenberg>
in order to check if the signal you're right clicking on is legal to use this filter with
<azonenberg>
refactoring that is high on my wishlist
<bvernoux>
the fact to do not have modal windows is also very nice thanks to ImGui with transparency
<azonenberg>
Yes, i'm trying to go modeless for everything
<bvernoux>
that allow very nice placement to customize the screen
<bvernoux>
ha great so the list of filter will be dynamic not like before
<bvernoux>
before it was just greyed
<azonenberg>
and no i'd like to still show the other stuff grayed out
<azonenberg>
the goal is just to make the "is X legal to feed to Y" check more efficient
<bvernoux>
also the preferences are really more customizable than before
<azonenberg>
i have to think about how to do this
<bvernoux>
I do not remember we could change all that stuff in glscopeclient
<azonenberg>
There were prefs for most of it
<bvernoux>
yes greyed out items is also interesting to see what is available
<bvernoux>
I have provided hints to have good backtrace with mingw64 ;)
<bvernoux>
as it is not so trivial to find some hints
<bvernoux>
especially winpty gdb ./glscopeclient.exe
<bvernoux>
which allow to have all traces in mingw64 console and support correctly break (Ctrl-C ...)
<bvernoux>
woo switching from ngscopeclient to glscopeclient with demo is really amazing in smoothness
<bvernoux>
amazing the progress done in ngscopeclient
<azonenberg>
yeah we just have to finish it :p
<bvernoux>
glscopeclient fullscreen <12fps and ngscopeclient full screen about 58fps ;)
<bvernoux>
with same old HW ;)
<bvernoux>
maybe on recent computer the difference is not so huge but I imagine you also feel the difference
<azonenberg>
I see the difference most notably with my picoscope, in terms of wfm/s throughput
<azonenberg>
but yes it's hugely faster. it also uses less cpu to do more work
<d1b2>
<DanielG> @bvernoux I don't have winpty installed - can I get a backtrace with just gdb?
<bvernoux>
install winpty
<bvernoux>
else it is a mess
<d1b2>
<DanielG> ok
<bvernoux>
as all tools are available in mingw64
<bvernoux>
so if you want to call mingw64 tools from windows command you will have issues
<bvernoux>
related to path and it is not really recommanded to put all bin/dll path from mingw64 to your cmd default path ...
<bvernoux>
pacman -S mingw-w64-x86_64-winpty
<bvernoux>
it is small
<bvernoux>
I have a doubt if you need also pacman -S winpty
<bvernoux>
I do not remember which one I installed
<bvernoux>
Your issue really feel like what we can have on Rigol MSO5K as it is dead slow
<bvernoux>
and sometimes you are desynchronized between SCPI and the Scope
<bvernoux>
I'm pretty sure SDS6204A is also dead slow to react to any SCPI command
<azonenberg>
bvernoux: we have a 20 Hz rate limiter on scpi commands going to siglent scopes
<bvernoux>
I see in your video 3.56fps
<azonenberg>
in the driver
<bvernoux>
ha ok
<azonenberg>
if you send any faster, the scope sometimes ignores the command
<bvernoux>
anyway I cannot really compare with Rigol as on Rigol there is huge issue how are managed SCPI command in the scope where it is really buggy internally in firmware
<bvernoux>
even if latest updates for Rigol MSO5K have really improved stuff and it is fully usable (just avoid changing vertical things in live...)
<bvernoux>
but now you have tools to do it yourself with your own build as the mess is to retrieve dll dependencies dynamically from different exe/dll
<bvernoux>
done by the magic of mingw-bundledlls which is a python3 script found on github and hacked
<azonenberg>
danielg: yeah we dont have much in the way of packaging or docs for ngscopeclient yet because it's very much still a development prototype missing most features like file load/save that you'd need for serious work
<bvernoux>
strange latest glscopeclient version crash when loading the spi-compressed.scopesession
<bvernoux>
what is not good is it crash in 0x0000000053cc5de9 in vk_optimusGetInstanceProcAddr () from C:\Windows\System32\DriverStore\FileRepository\nvami.inf_amd64_a3d5bcc37ff12fed\nvoglv64.dll
<azonenberg>
confirmed no crash on my end loading that same file
<azonenberg>
i do however see what looks like rendering issues
<azonenberg>
seems like only the first sample is being drawn?
<bvernoux>
yes I suspect
<bvernoux>
BT on main thread
<bvernoux>
#78 0x00007ff6d7b873da in ScopeApp::DispatchPendingEvents (this=<optimized out>) at C:\msys64\home\bvern\scopehal-apps\src\glscopeclient\ScopeApp.cpp:187
<bvernoux>
#79 0x00007ff6d7b484ce in OscilloscopeWindow::RedrawAfterLoad (this=0x1ffef3f8990) at C:\msys64\home\bvern\scopehal-apps\src\glscopeclient\OscilloscopeWindow.cpp:1130
<bvernoux>
#80 OscilloscopeWindow::OnInstrumentAdded (this=this@entry=0x1ffef3f8990) at C:\msys64\home\bvern\scopehal-apps\src\glscopeclient\OscilloscopeWindow.cpp:1114
<bvernoux>
#81 0x00007ff6d7b53100 in OscilloscopeWindow::OnLoadComplete (this=this@entry=0x1ffef3f8990) at C:\msys64\home\bvern\scopehal-apps\src\glscopeclient\OscilloscopeWindow.cpp:1139
<bvernoux>
#82 0x00007ff6d7b60234 in OscilloscopeWindow::DoFileOpen (this=0x1ffef3f8990, filename="spi-compressed.scopesession", loadWaveform=<optimized out>, reconnect=reconnect@entry=false) at C:\msys64\home\bvern\scopehal-apps\src\glscopeclient\OscilloscopeWindow.cpp:1087
<bvernoux>
#83 0x00007ff6d7b87fe7 in ScopeApp::run (this=this@entry=0x1ffec7d0f00, scopes=std::vector of length 0, capacity 0, filesToLoad=std::vector of length 1, capacity 1 = {...}, reconnect=reconnect@entry=false, nodata=nodata@entry=false, retrigger=retrigger@entry=false, quitA
<bvernoux>
fterLoading=quitAfterLoading@entry=false) at C:\msys64\home\bvern\scopehal-apps\src\glscopeclient\ScopeApp.cpp:80
<bvernoux>
#84 0x00007ff6d7c2cebc in main (argc=<optimized out>, argv=<optimized out>) at C:\msys64\home\bvern\scopehal-apps\src\glscopeclient\main.cpp:264
<azonenberg>
mughees: thoughts on renaming the block from "area under curve" to "integral" or "integrate" as that's really what it's doing?
<azonenberg>
also lain, louis: what d oyou think?
<d1b2>
<azonenberg> @louis since you didnt get tagged the first time
<d1b2>
<louis> No strong opinion. Area is what Tek calls it is why that name was being used
<azonenberg>
louis: also let's try and set up another dev call after i get back. How's some time the 18th to 21st sound to you?
<azonenberg>
i feel like we've done enough it's worth having another sync
<azonenberg>
also ping @mughees, @ehntoo, @johnsel, lain: any of those days better/worse for you?
<azonenberg>
and balrog / @david.rysk
<azonenberg>
i'm thinking probably same kind of time frame as before - 09:00 Pacific / 12:00 Eastern / 18:00 CET, give or take an hour or two either way
<azonenberg>
seems to work well for our predominantly NA / western Europe folks
<d1b2>
<ehntoo> No preference from me.
<d1b2>
<david.rysk> Definitely no earlier than the 18th lol
<_whitenotifier-7>
[scopehal] MugheesChohan ed9c960 - Adding initial implementation of Area under curve measurement
<_whitenotifier-7>
[scopehal] MugheesChohan 817636b - Switching summation to use Kahan summation algorithm
<_whitenotifier-7>
[scopehal] MugheesChohan dc45c99 - Adding a new unit as a hack to represent area under curve
<_whitenotifier-7>
[scopehal] ... and 2 more commits.
<azonenberg>
@david.rysk: i'll be busy until then anyway. so that's a given
<d1b2>
<johnsel> works for me, and I'll have audio set up this time 😒
<azonenberg>
Ok let's tentatively say Weds the 19th at 0900 Pacific? I've put that on my calendar but it's subject to change if lain or louis has a conflict
<azonenberg>
louis: BinarySearchForGequal came from the glscopeclient renderer i assume, right? Should this perhaps be moved up to be a global function in scopehal.h so we can use it everywhere? is this something you think we'd use more than once?
<_whitenotifier-7>
[scopehal-docs] azonenberg a3ee513 - Swapped USBTMC transport to correct alphabetical position. Fixed a few minor formatting issues.
<azonenberg>
louis: yeah makes sense. Go ahead and do that move then delete the implementation in WaveformArea so we dont have redundant duplicated code
<azonenberg>
also i just merged everything as you can see :p
<azonenberg>
with a few minor edits
<azonenberg>
lain: hmmmm, we have a renderer regression again it seems
<_whitenotifier-7>
[scopehal-apps] azonenberg 5bdfe09 - When loading sparse waveform that's actually uniform, convert it
<azonenberg>
lain: so it seems like we have a bug when rendering waveforms that are sparse and are de facto uniform
<azonenberg>
i've observed the bug with a bunch of old test case files that predate the modern densev1 waveform storage format and use sparsev1 to store uniformly sampled data
<azonenberg>
i dont know more than that at this point, but every file i've loaded from that era exhibits the bug
<azonenberg>
when using 5bdfe09 i convert the waveform to uniform at load time (leaving the original sparse file on disk untouched) and it renders fine
<azonenberg>
near term, i'm not worried as that patch mitigates the bug
<azonenberg>
but it's possible in the future that we'll find actual sparse waveforms that trigger it too
<d1b2>
<Mughees> I think most scopes call it area, and we have introduced a concept of treating negative area as positive (absolute area) so area seems appropriate.
<azonenberg>
My LeCroy calls it integral
<d1b2>
<Mughees> I am booked on 17th 18th and 19th
<azonenberg>
hence why i was wondering
<d1b2>
<Mughees> Oh
<d1b2>
<Mughees> Sorry i fired a random shot. I dont own any oscilloscope. But the absolute area concept can be a valid argument for calling it area…
<azonenberg>
Yeah
<azonenberg>
We'll keep it for the near term
<d1b2>
<Mughees> I guess guys at Lecroy are nerds
<azonenberg>
Lol
<d1b2>
<Mughees> I used their usb analyzers
<d1b2>
<Mughees> It was one hell of complex interface
<d1b2>
<Mughees> To work with
<d1b2>
<Mughees> Even Children should be able to play with oscilloscopes
<azonenberg>
I think the first scope I used was an analog Tek at my dad's work when I was... maybe 15 or so?
<azonenberg>
then i used a couple of cheap lowish BW DSOs, i think also Teks, at the RPI electronics club
<azonenberg>
saved up and bought a Rigol DS1102D when the club shut down so i'd have one for home
<azonenberg>
kept that all the way until i got my first LeCroy, a WaveSurfer 3034, in... 2016? 2017? something like that
<azonenberg>
mughees: I have calls most of the morning of the 20th. does the 21st work for you?
<d1b2>
<ehntoo> I have figured out the weird issues with avx512f feature'd functions in clang. It's an interaction with openmp - if I get rid of the #pragma omp parallel for in ScopeSyncWizard.cpp, I can finally get rid of the last compile errors on glscopeclient. 🙃
<d1b2>
<ehntoo> to clarify, specifically if I get rid of the omp pragmas in the avx512f-enabled functions