<d1b2>
<hansemro> Noticed this on a machine with AMD iGPU (Vega 10), but did not look further since it did not crash/hang my system.
sgstair has quit [Read error: Connection reset by peer]
sgstair has joined #scopehal
<d1b2>
<hansemro> I spent some more time experimenting with trigger polling and data acquisition in a trimmed-down siglent scope driver, but it seems impossible to exceed 3 WFM/s on a single channel. ~3 WFM/s comes from the 300-330 ms delay in acquiring data shortly after scope says it triggered. This is even after caching wavedesc (channel parameters) and building a kernel module to use a usb gigabit ethernet adapter (limited to USB 2.0 speeds at ~ 242
<d1b2>
Mbits/s).
<d1b2>
<hansemro> If the scope is not triggering on new data, but instead acquiring the same data, then max 30+ WFM/s is possible.
<_whitenotifier-3>
[scopehal] azonenberg 8e988d3 - CSV import: support arbitrary X and Y units (for now, same Y unit for all analog inputs). Fixed potential crash if X axis values were extremely large.
<azonenberg>
yes i figured it was trigger latency
<azonenberg>
that's because the delay seemed pretty constant regardless of memory depth
<azonenberg>
i don't think there is much we can do to improve performance short of the vendor fixing whatever that delay is on their side
<azonenberg>
conjecture: the normal scope app keeps all the waveform data in FPGA and renders in a hardware overlay but they are copying it from FPGA to CPU to do scpi downloads
<azonenberg>
and they copy the entire acquisition memory regardless of how deep the displayed memory is
<d1b2>
<hansemro> This seems to be the case. I was somewhat hoping we just a bad trigger polling implementation since requesting old waveform data is relatively quick (<40 ms). But if I try to request data as soon as the scope says it triggers, the query to fetch data just takes longer...
<azonenberg>
Yeah. i've optimized everything i could scopehal side already, that's why the pico and lecroy drivers are so fast lol
<azonenberg>
so unless you want to reverse engineer and optimize their firmware... :p
<azonenberg>
Not that I would entirely rule out the possibility if you were sufficiently crazy
<d1b2>
<hansemro> Well, I did build kernel module for mine
<azonenberg>
not sure if you heard the story about me and the em solver folks?
<d1b2>
<hansemro> No, I have not
<azonenberg>
tl;dr I got fed up with my em solver taking too long to run
<azonenberg>
so i took their closed source binary blob sse2 matrix solver and rewrote it in avx, complete with some very nice scripts that compiled the code and patched up all of the jumps to redirect the original function call to my new, faster implementation
<azonenberg>
also optimized some other stuff like refactoring termination conditions known a priori outside of loops vs bounds checking pointers against a constant bound each iteration
<azonenberg>
then i opened a support ticket with a "pull request" :P
<d1b2>
<johnsel> that's funny because it is now an avx implementation
<azonenberg>
sonnet?
<d1b2>
<johnsel> yes I believe so
<d1b2>
<johnsel> I can't find any proof for it but I think I've read that somewhere
<d1b2>
<johnsel> or you've told the story before and I misremember that is entirely possible too
<azonenberg>
anyway so tl.;dr i had a quick chat with a VP
<azonenberg>
(the owner's son and an alum of my alma mater, its a tiny company near where i went to school)
<d1b2>
<hansemro> got a job offer?
<azonenberg>
He very quickly decided suing me for violating the terms of the license and then handing them a massive performance boost (something like 40-70% depending on workload) would not be in either side's interest
<d1b2>
<hansemro> lol
<azonenberg>
Sent me a formal authorization on company letterhead giving me an exception from that EULA clause as long as i had an active support contract
<azonenberg>
Offered me a huge, i think 30%, standing discount off the cost of upgrading my license to the pro tier as well as future support contract renewals (this saved me something like $5K in license fees for a weekend of work, not a bad deal)
<azonenberg>
When i was visiting family in the area a few months later i stopped by the office, got to meeet the team, spent like two hours in their head software engineer's office going through code and making suggestions on both future features and performance
<azonenberg>
And I now have an NDA for partial source code access if my RE identifies anything else that we think could be beneficial
<azonenberg>
My AVX matrix solver implementation will be landing in the next release
<d1b2>
<johnsel> you can, but you will likely get a very limited source code package, not enough to rebuild the firmware almost certainly
<d1b2>
<hansemro> Right, I wouldn't get their main Qt-based app or useful headers.
<azonenberg>
yeah exactly
<d1b2>
<johnsel> generally you'd likely have to reverse your way into the running firmware and get root to play around
<azonenberg>
just all the lgpl libs
<d1b2>
<david.rysk> It’s easy to get root on these things
<d1b2>
<johnsel> and some way to inject new files into the system
<d1b2>
<johnsel> oh that helps
<d1b2>
<david.rysk> IIRC all you need is a USB drive with a script file on it and it will just autorun that
<d1b2>
<david.rysk> So you can have it start Telnet or something
<d1b2>
<johnsel> for the 7000 series?
<d1b2>
<johnsel> I'm aware of those scripts for lower versions
<d1b2>
<david.rysk> Im not sure about the 7000, idk if anyone tried
<d1b2>
<david.rysk> They all share architecture though I thought
<d1b2>
<johnsel> they might
<d1b2>
<miek__> i made a start on a driver for Agilent/Keysight Infiniium scopes today, got most of the basic timebase & channel setup done, and it's pulling in waveforms
<azonenberg>
miek: ooooh that has been on my wishlist for a long time
<azonenberg>
the last big scope family we dont support at all
<d1b2>
<johnsel> very nice indeed
<d1b2>
<hansemro> This method got patched in more recent firmwares. Patched on 1.5.2R1 for SDS2000X+. Patched on 1.4.4.1 for SDS6000, etc.
<azonenberg>
miek: which scope are you using?
<d1b2>
<azonenberg> @miek__
<d1b2>
<miek__> it's a DSO80204B (with upgrades to 13GHz). it's a fairly old one, but as far as i could see the SCPI commands should be compatible through to the modern ones
<d1b2>
<azonenberg> Nice
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 255 seconds]
Degi_ is now known as Degi
sgstair has quit [*.net *.split]
veegee has quit [*.net *.split]
sgstair has joined #scopehal
veegee has joined #scopehal
<azonenberg>
... Welp
<azonenberg>
So this is going to be fun
<azonenberg>
We've been doing gamma correction all along and i only noticed when i tried to use imgui to render a texture that had a spectral gradient in it
<azonenberg>
all wrong*
<azonenberg>
(gamma correction in textures specifically)
<azonenberg>
basically stuff was getting horribly munged between linear and sRGB
<azonenberg>
for now i'm switching everything to linear which should work well enough
<_whitenotifier-3>
[scopehal-apps] azonenberg 9131c83 - Initial work on spectrometer integration. Fixed bug causing textures to have weird color space conversions when moving from sRGB to linear. Fixes #656.
<_whitenotifier-3>
Update orchestrator-deploy.yml Now passing through secret to the orchestrator action * Update orchestrator-deploy.yml Fix syntax * Update orchestrator-deploy.yml More syntax errors