<bvernoux>
it is why I say 10Mpts on Rigol with SCPI is not really usable waiting more than 7s is crazy with an UI
<bvernoux>
7s is for 4chan ;)
<d1b2>
<ehntoo> 10Mpts is nowhere near 7.5s with my current setup. It's pretty variable, but somewhere in the neighborhood of 1s-4s. The ngscopeclient perf metrics report ~270mHz (emphasis on little m).
<d1b2>
<ehntoo> ah, I'm only on one channel
<bvernoux>
yes
<bvernoux>
it is about 5MBytes/s
<bvernoux>
the Rigol MSO5K cannot exceed 6MBytes/s ...
<bvernoux>
what a shame with 1Gbit Ethernet link or even USB2 HS
<bvernoux>
I have even tried 200MPts 1chan ;)
<bvernoux>
32.55s
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
<bvernoux>
ehntoo anyway if you have stabilized it with glscopeclient it will be usable
<bvernoux>
as it is very boring to use USB key ;)
<bvernoux>
as on my side the Rigol MSO5K was totally frozen sometimes depending on command burst
<bvernoux>
it was clearly a mutex locked somewhere ;)
<d1b2>
<ehntoo> I was just about to hop off the computer for the night, but I updated my scopehal-apps repo to master and am running into a new crash when trying to render the first waveform of a session on macos/moltenvk. I can grab some more diagnostics and/or bisect things tomorrow.
<d1b2>
<ehntoo> this was with only a 10kpt depth whereas before I'd updated I could work with 10Mpt capture depths (albeit slowly)
<lain>
ehntoo: this is expected, ngscopeclient isn't using the vulkan rendering fixes yet
<d1b2>
<ehntoo> It worked with the scopehal-apps code from last night though?
<lain>
ah, hm
<lain>
I'll let azonenberg figure it out then
<d1b2>
<ehntoo> I'm sure I can figure it out pretty quickly, it's probably something similar to the Vulkan queue management where the m1 hardware capabilities are a little unusual. I bet we're requesting buffer properties that are unsatisfiable in some way.
<d1b2>
<david.rysk> hmm, opencl is required ?
<d1b2>
<david.rysk> (trying to do an initial compile on mac)
<d1b2>
<david.rysk> err not opencl, but openmp
<d1b2>
<david.rysk> hmm I can't compile ffts
mikolajw has quit [Ping timeout: 248 seconds]
mikolajw has joined #scopehal
<d1b2>
<david.rysk> (got past that)
<azonenberg>
ehntoo: i am just beginning to deploy the new vulkan rendering in ngscopeclient
<azonenberg>
there is some code related to setup for that which i have not tested on mac
<azonenberg>
it *should* not break but if it does, i want to know
<d1b2>
<david.rysk> Are there Mac compile instructions yet? (Got it most of the way there)
<d1b2>
<ehntoo> Not yet - support is pretty early days, but I think it's going to be a priority pretty soon.
<azonenberg>
david.rysk: there will be once it's officially working and supported
<azonenberg>
lain is actively working towards that end, with some help from ehntoo
<azonenberg>
Don't waste too much time on FFTS compile/run issues. FFTS is goign to be deprecated from the codebase in the immediate future
<azonenberg>
we're going all in on vkFFT
<azonenberg>
ehntoo: ToneMapAnalogWaveform is the experimental function i'm working on right now
<azonenberg>
it does nothing user facing yet, and was pushed in part to see if anyone would have problems with it :p
<azonenberg>
It's safe to comment out the call to it in the near term, which should fix the problem for you
<azonenberg>
i'll investigate why it's failing
<azonenberg>
outofpoolmemory implies i might have run out of descriptors or not be using the right pool to allocate a descriptor, or something to that effect
<azonenberg>
ehntoo: wrt not being able to change settings except with the trigger running, a lot of siglents are like that too
<_whitenotifier-7>
[scopehal] ehntoo e260bf8 - Fix rigol MSO5000 waveform acquisition failures If we ask for waveform data too quickly after a trigger event, my MSO5074 won't respond with any data. Experimentally, I've found two ways to avoid this: 1. Stop using `SO_RCVTIMEO` on the MSO5000's LAN socket and re-send our :WAV:DATA? request on reception of no response following the header 2. Send a *WAI request prior to
<_whitenotifier-7>
sending :WAV:DATA?. The MSO5000 programming guide seems to suggest *WAI does nothing at all, but I have not been able to reproduce any waveform reception failures after adding it to the AcquireData sequence. This commit adopts approach 2, as it avoids polluting the code with any assumptions or special handling for certain SCPI transport methods. Thanks to @bvernoux for his nice standalone "rigol_mso5000" utility
<_whitenotifier-7>
which made verifying this change exceptionally simple.
<_whitenotifier-7>
[scopehal] ehntoo 0f5a8ca - Rigol MSO5000: Avoid stomping on BW limit on init The current rigol constructor for MSO5000 series scopes runs through an iterative process to determine what the actual bandwidth of a connected device is by setting progressive channel bandwidth limits and seeing if they take effect. We were not restoring the previously-set bandwidth limit after this process, which might cause
<_whitenotifier-7>
[scopehal] ehntoo 2612c65 - Add missing pool size for eStorageImage descriptor MoltenVK seems to validate the descriptors pretty strictly and this was returning eErrorOutOfPoolMemory due to the lack of a provided pool of eStorageImage.
<_whitenotifier-7>
[scopehal] azonenberg b340e57 - Merge pull request #697 from ehntoo/add-image-descriptors-to-pool Add missing pool size for eStorageImage descriptor
<d1b2>
<ehntoo> a low-priority API thing I hit while working on improving Rigol support - the existing "InterleaveConflict" interface with the "GetSampleRatesInterleaved" "GetSampleDepthsInterleaved" method isn't quite expressive enough to model all limitations.
<d1b2>
<ehntoo> The rigol scopes I'm familiar with (mso5000, ds1000z) have a multi-layered interleaving setup. If you have a single channel enabled, you get full sample rate. channel 1 or 2 can be used with one of channel 3 or 4 and get half of the available sample rate. If you use three channels at once or channel 1 with channel 2 or channel 3 with channel 4 you get 1/4 the available sample rate.
<azonenberg>
Correct. there is an open ticket for that
<d1b2>
<ehntoo> I suppose I should go read through the issues list, lol
<azonenberg>
my tentative thought is to not-solve this
<azonenberg>
the interleaved/non-interleaved model is base on instruments like LeCroy that have an explicit, user facing interleave switch
<azonenberg>
the rigols, as well as e.g. picoscopes, do not have this in the API
<azonenberg>
the set of available channels and sample rates scales w/ enabled channels
<azonenberg>
but that's somewhat hidden from the user
<azonenberg>
This is where things like CanEnableChannel() come in
<azonenberg>
where you'd add logic to prevent the user from enabling a second channel if you have the full rate selected
<d1b2>
<ehntoo> that could work. We'd always display the implicit interleaving sample rates in the timebase configuration, then?
<azonenberg>
no. you'd display rates that are valid with the currently active set of channels
<azonenberg>
so if you have 4 channels active the 1/2 and full rate would not show up
<azonenberg>
until you closed some of those channels
<d1b2>
<ehntoo> gotcha
<d1b2>
<ehntoo> the inability to add a channel could be a little confusing unless we add some user feedback about why, but I think it's a good approach.
<azonenberg>
this is what we already do in the pico drive
<azonenberg>
read that code and let me know what you think
<azonenberg>
if we want to make this a more official paradigm
<azonenberg>
if so we can close #64 as we now have a path forward for rigol etc too
<bvernoux>
For info I have a PR which fix the CI Build for WIndows (again)
<d1b2>
<ehntoo> the Pico code for constraint checking in CanEnableChannel looks like a nice framework, but I think I might be missing the code for providing user feedback.
<azonenberg>
That doesn't exist currently. we just call CanEnableChannel in the menu handler
<bvernoux>
but there is missing files like some new shaders that I'm trying to fix
<azonenberg>
and show/hide it
<bvernoux>
@azonenberg, also we should probably do a msi build for ngscopeclient to have feedback from user's ?
<azonenberg>
longer term yes that should be a thing. it's not yet to the point that i care about it. at least let me get the new renderer integrated
<azonenberg>
today/tomorrow hopefully
<bvernoux>
ha ok
<d1b2>
<ehntoo> the thing I think we might need to solve there is that it could be confusing if, for example, your scope first connects in full sample rate mode and you then don't see any additional channels in the channel list, or if they're grayed out. The solution there could be as simple as returning a failure reason enum and associating it with a hover tip, though.
<azonenberg>
Yes. Improving the UX of this is definitely something that would be nice to add
<azonenberg>
i've been working on adding tooltips and in-app documentation to ngscopeclient as you've probably seen
<d1b2>
<ehntoo> yes. I really like how nicely they work in imgui.
<azonenberg>
and its so little code too
<d1b2>
<david.rysk> at the moment I can't build for mac due to glfwGetRequiredInstanceExtensions failed
<d1b2>
<david.rysk> on mac*
<d1b2>
<david.rysk> (also fwiw some of you might have seen me before on irc as balrog)
<d1b2>
<ehntoo> that suggests your Vulkan SDK isn't set up quite correctly. I think lain hit the same yesterday and had to re-install the vulkan SDK as a system install rather than a user install
<d1b2>
<david.rysk> I installed it from homebrew
<d1b2>
<david.rysk> any reason we shouldn't vendor it?
<d1b2>
<ehntoo> I wasn't able to make the homebrew version work whereas installing the package from https://vulkan.lunarg.com/sdk/home just worked. Worth diagnosing properly at some point, but if you'd like to just get things working you can give that a try.
<d1b2>
<ehntoo> looking at it again, I'm not even seeing the vulkan sdk in homebrew. Do you know which packages you installed?
<azonenberg>
that still sounds like a very messed up SD install
<d1b2>
<david.rysk> SD?
<azonenberg>
SDK*
<d1b2>
<ehntoo> I'm not seeing shaderc, glslang, or vulkan-loader in homebrew...
<d1b2>
<ehntoo> wait. they do show up in a brew search but not in the search on brew.sh.
<d1b2>
<ehntoo> I'm not sure how this wouldn't be a compile failure rather than a runtime one, but do any of those homebrew packages provide the vulkan c++ headers? vulkan_raii.hpp is one example.
<d1b2>
<ehntoo> ok, looks like those should be coming in with vulkan-headers
<d1b2>
<ehntoo> yeah, I dunno. Looks like vulkan-headers got rev'd in homebrew a couple days ago. If you've been at this a while, maybe try a clean build?
<azonenberg>
yeah i know there are problems if the headers and binary you linked against are mismatched
<_whitenotifier-7>
[scopehal-apps] azonenberg e5faf6f - Tone mapping shader now runs and generates an all-pink output
<_whitenotifier-7>
[scopehal-apps] azonenberg 4e55597 - Tone mapping shader now appears to correctly tone map inputs
<_whitenotifier-7>
[scopehal-apps] azonenberg 9dabd12 - Tone mapping shader now has better alpha blending if we have multiple traces stacked
<_whitenotifier-7>
[scopehal-apps] ... and 2 more commits.
<azonenberg>
ok so i just pushed my working copy with a bunch of the fixes we were talking about
<azonenberg>
this does draw a test pattern in the background of ngscopeclient behind the actual waveforms
<azonenberg>
but i dont think that will be a big deal as nobody is actually (I hope) using ngscopeclient for real work yet
<azonenberg>
if for whatever reason this annoys you, comment out ngscopeclient/WaveformArea.cpp:338
<azonenberg>
that placeholder image will be the actual waveform and the immediate mode renderer on 342-360 will be deleted once the shader based renderer is fully integrated
<azonenberg>
just working on a few other minor issues first
<d1b2>
<ehntoo> I'll be using it for real work soon, I hope, but certainly not yet. 😉
<azonenberg>
yeah as a minimum file load/save support and history and filter graph stuff have to come first
<azonenberg>
anyway, it's coming along nicely and i dont think it will be THAT long
<d1b2>
<azonenberg> was that really only three years ago?
<bvernoux>
woo the Rigol MSO5K fixes are amazing
<bvernoux>
no crash anymore
<bvernoux>
so it is pretty usable even if the refresh rate is very slow (<1 FPS) because of crappy Rigol SCPI ...
<d1b2>
<ehntoo> that's great to hear. I've hit a couple other bugs and will be ironing out some other features in the near future.
<azonenberg>
Great
<azonenberg>
also i'm beginning to use VK_EXT_debug_utils to name objects
<bvernoux>
ha yes great
<azonenberg>
so future vulkan validation errors will be more comprehensible
<azonenberg>
using nice friendly names vs handles
<bvernoux>
azonenberg, ha very good things
<bvernoux>
oups a crash ;)
<bvernoux>
it is when I tried to move Y (Voltage) on a channel
<bvernoux>
the scope was not synchronized anymore with SCPI ...
<bvernoux>
so yes changing any settings on the scope from glscopeclient is not really usable with some huge delays
<azonenberg>
ehntoo: Is the Rigol driver using the queued command API?
<bvernoux>
which seems implied by glscopeclient UI with GTK
<d1b2>
<ehntoo> It is not at the moment. It's one of the updates I'm planning on making.
<bvernoux>
ha great I hope that will decouple more the UI with the waveforms which are ultra slow
<bvernoux>
my best hope is clearly for ngscopeclient without gtk
<azonenberg>
ok yeah that will definitely help
<azonenberg>
its just a big enough change i didnt want to make it blind without access to an instrument to verify against
<d1b2>
<ehntoo> I think there's also some caching bugs I'll need to squash.
<azonenberg>
Would not surprise me in the slightest
<d1b2>
<ehntoo> I can validate the "mso5" and "ds" support of the Rigol driver with instruments on-hand. I don't have an older Rigol for testing the "ds_old" support though. I'm making an effort to avoid any changes that would break it, but there may be some unintentional bit rot. 😑
<bvernoux>
fun bug the fullscreen does not want to do fullscreen ;)
<azonenberg>
Yeah fair enough
<azonenberg>
if someone complains we'll address it
<d1b2>
<david.rysk> are you trying “real” fullscreen or borderless window?
<azonenberg>
this is the only path forward short of having a dedicated hardware-in-loop CI cluster of every supported scope
<azonenberg>
bvernoux: is that with ngscopeclient?
<d1b2>
<david.rysk> (Real fullscreen is weird and messy)
<azonenberg>
glscopeclient fullscreen on windows is known broken
<azonenberg>
ngscopeclient i thought was fixed. but it wants to fullscreen on your primary monitor
<azonenberg>
i'd like to make it always use the monitor the window is currently on
<d1b2>
<ld;cd> I'm trying to build scopehal-apps on fedora using the distros headerfiles for vulkan and am getting the following error
<azonenberg>
i'll look into that. in the meantime, if you can let me know what SDK version you're using that will help
<azonenberg>
it might be too old
<azonenberg>
not that we can't potentially patch the code to handle the older SD too
<azonenberg>
SDK
<d1b2>
<ld;cd> 1.3.204
<azonenberg>
gaah is my K key failing? i keep doing that
* azonenberg
shakes keyboard
<d1b2>
<ld;cd> lol
<d1b2>
<ld;cd> ok so thats a little old
<d1b2>
<ld;cd> alright now we got this
<d1b2>
<ld;cd> /home/aled/Build/scopehal-apps/lib/scopehal/VulkanInit.cpp: In function ‘bool VulkanInit(bool)’: /home/aled/Build/scopehal-apps/lib/scopehal/VulkanInit.cpp:729:46: error: no matching function for call to ‘vk::DeviceCreateInfo::DeviceCreateInfo(<brace-enclosed initializer list>, std::vector<vk::DeviceQueueCreateInfo>&, <brace-enclosed initializer list>, std::vector<const char*>&, vk::PhysicalDeviceFeatures*, void*&)’ 729 |
<d1b2>
pNext); | ^ In file included from /usr/include/vulkan/vulkan.hpp:6770, from /usr/include/vulkan/vulkan_raii.hpp:11, from /home/aled/Build/scopehal-apps/lib/scopehal/scopehal.h:63, from /home/aled/Build/scopehal-apps/lib/scopehal/VulkanInit.cpp:35: /usr/include/vulkan/vulkan_structs.hpp:23444:5: note: candidate:
<_whitenotifier-7>
[scopehal-apps] azonenberg 61eba33 - Assigned names to a bunch of Vulkan objects
<d1b2>
<louis> Window, clip, pulse width
<d1b2>
<louis> BTW I need to add diff + +target_link_libraries(scopehal + SPIRV + SPIRV-Tools-opt + SPIRV-Tools +) to CMakeLists.txt to get it to link. Otherwise I get a bunch of undefined spv* symbols when linking glscopeclient
<azonenberg>
nice. and hmmm, i think lain and bvernoux were chasing a bunch of linker issues but *thought* that was solved
<lain>
azonenberg: we had some issues with compiled spv files not being found, that was a bug in my cmake changes which have since been patched. so I think what louis is talking about is unrelated to that
<azonenberg>
or was it ehntoo?
<azonenberg>
i distinctly remember in the apst week or two linker issues related to spirv
<_whitenotifier-7>
[scopehal-apps] azonenberg e38ec20 - Added some debug prints during shutdown. Fixed bug where WaveformArea objects were not actually destroyed during shutdown due to circular references to parent WaveformGroup. Fixes #679.
<azonenberg>
darius: correct
<azonenberg>
and yes but jit can play well with asan AFAIK. you just have to put the legwork in
<azonenberg>
darius: anyway we're going all in on vulkan and removing all cpu-based FFTs long term
<d1b2>
<Darius> I had a look at FFTS for work but it did seem a bit flaky unfortunately, seemed to be a bit abandoned 😦
<azonenberg>
Yes. FFTS and clFFT are both abandonware with last commits in 2017
<azonenberg>
i am not aware of any CPU-based FFT that is actively maintained and permissively licensed at this time
<azonenberg>
so we're just going to full vkfft for everything