azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | Online hackathon December 19th all day | https://github.com/azonenberg/scopehal-apps | Logs: https://freenode.irclog.whitequark.org/scopehal
<agg> azonenberg: I've just tried building glscopeclient again after a while, but I'm only getting glitches in the waveform render area, https://imgur.com/a/CO1tOr1 sort of thing
<agg> the debug info isn't hugely promising either, it says (null) for vendor/renderer/version/shading_language_version, and GL_ARB_gpu_shader_int64 not supported
<agg> the latter is correct, this is an AMD RX550 and glxinfo doesn't contain GL_ARB_gpu_shader_int64, but everything else on the system seems to do hardware accelerated GL properly at least
<azonenberg> agg: gimme a sec
<azonenberg> Very interesting. Did you pull latest from git as of today? or was this yesterday/older
<azonenberg> it should not have said null, it should have valid text there
<agg> today, b1116fb, with all submodules up to date too
<azonenberg> What distro and is this under x11 or wayland?
<agg> ubuntu 18.04, X11
<azonenberg> Very strange. What i find especially odd is that not even the background, axes, etc are showing up
<azonenberg> What happens if you comment out the call to RenderMainTrace() in WaveformArea_rendering.cpp:422?
<azonenberg> you should not see any analog or digital waveform data but the axes, cursors, protocol decodes, etc should still be visible
<agg> no change in behaviour
<agg> glitch pattern has more of my browser in it this time :p
<azonenberg> Yeah this is screaming "uninitialized memory" or "bad pointer"
<azonenberg> the question is how
<azonenberg> I wonder if it's a libglvnd issue
<agg> https://dpaste.com/6VZQ2ZSQY is the glscopeclient and (cut) glxinfo output if it's useful
nelgau has quit [Remote host closed the connection]
<Bird|otherbox> hm, maybe worth throwing ASAN at?
<azonenberg> Bird|otherbox: not likely to be useful if this is in video drivers
<Bird|otherbox> that is fair
<azonenberg> the weirder bit is that i'm getting null for all of the strings
<azonenberg> that suggests i dont actually have a gl context at all
<azonenberg> and we're just rendering stale x server memory
<azonenberg> And yet glewInit() did not report any errors
<azonenberg> and the context object wasn't null
<azonenberg> agg: what happens if you add "context->make_current()" before WaveformArea.cpp:453?
<agg> no change
<azonenberg> ok the other thing to try is in src/glscopeclient/CMakeLists.txt:3
<azonenberg> change NEW to LEGACY
<agg> OLD, maybe
<azonenberg> interesting, seems like cmake docs are a bit contradictory lol
<azonenberg> ok what does OLD do?
<agg> fixes it
<agg> debug info now prints correct vendor/renderer/version, and screen renders correctly
<agg> still no GL_ARB_gpu_shader_int64 support on my 3 year old GPU though, alas
<azonenberg> So my conclusion from this is that your libglvnd installation is broken
<agg> typical
<agg> I'll investigate
<azonenberg> you can undo whatever other tweaks you made to debug this
<agg> thanks for the help!
<_whitenotifier> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLefq
<_whitenotifier> [scopehal-docs] azonenberg 1f19536 - Added troubleshooting section to "getting started"
nelgau has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
nelgau has quit [Remote host closed the connection]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 272 seconds]
nelgau has joined #scopehal
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
bgamari_ has joined #scopehal
miek has quit [Ping timeout: 260 seconds]
juli966 has joined #scopehal
nelgau has quit [*.net *.split]
marshallh has quit [*.net *.split]
Kliment has quit [*.net *.split]
tnt has quit [*.net *.split]
miek has joined #scopehal
marshallh has joined #scopehal
tnt has joined #scopehal
nelgau has joined #scopehal
Kliment has joined #scopehal
<azonenberg> noopwafel: looks like we've got another picoscope owner interested in writing a driver
miek has quit [Ping timeout: 264 seconds]
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+2/-0/±5] https://git.io/JLUxN
<_whitenotifier> [scopehal] azonenberg 7ecc7ce - Initial implementation of FIRFilter. No AVX optimizations. Fixes #51.
<_whitenotifier> [scopehal] azonenberg closed issue #51: Add some DSP FIR filters - https://git.io/JLUxx
<_whitenotifier> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JLUhR
<_whitenotifier> [scopehal-apps] azonenberg db8543b - WaveformArea: now redraw downstream filters' waveform areas properly when reconfiguring a filter
miek has joined #scopehal
miek has quit [Ping timeout: 260 seconds]
<_whitenotifier> [scopehal] azonenberg pushed 4 commits to master [+0/-0/±5] https://git.io/JLTc3
<_whitenotifier> [scopehal] azonenberg 979db5f - Initial AVX2 implementation of FIRFilter. 1.57x speedup vs baseline.
<_whitenotifier> [scopehal] azonenberg 065e1c5 - Unrolled FIRFilter inner loop. 2.78x speedup vs baseline.
<_whitenotifier> [scopehal] azonenberg 576d477 - 4.47x speedup of FIRFilter vs baseline. Aren't roll loops fun? ;)
<_whitenotifier> [scopehal] azonenberg 5b0af42 - Roll loops just keep getting more fun. 4.81x speedup vs baseline.
<azonenberg> Well, i think i've done pretty well with this FIR implementation. I'm keeping it to AVX2 for now, no AVX512 or FMA
<azonenberg> 225 tap FIR on 800K samples in 9.6 ms, or 83M points/sec throughput
<azonenberg> 0.396 average CPI
<azonenberg> Let me see if i can do better with AVX512
jn__ has quit [Ping timeout: 246 seconds]
bvernoux has joined #scopehal
<noopwafel> azonenberg: beyond myself+bvernoux?
<noopwafel> I'm in that weird zone where I've been working for all my waking hours for a couple of months and now I .. don't have anything urgent to do.
<azonenberg> Yes, somebody else is interested, i tagged you in his tweet
<azonenberg> i'm planning a glscopeclient hackathon next weekend if you want to join up with him and work on it
<azonenberg> (see topic)
<noopwafel> \o/
<azonenberg> my focus is going to be write queueing for SCPITransport
<noopwafel> would be nice
<bvernoux> azonenberg, at same time could you add a FPS counter ?
<bvernoux> to check performances of the UI
<noopwafel> looks like I'm definitely stuck at home, so I don't have much else to do
<bvernoux> if you speak about PicoScope 3000 series support I'm very interested to help also
<noopwafel> oh and I have my midi controller to :D
<bvernoux> as it shall be amazing in speed I'm pretty sure the WFM are faster than Lecroy high end scope ;)
<noopwafel> yeah my hacky bridge driver is zooom
<azonenberg> bvernoux: re FPS counter, i'm not sure how useful that is because the UI doesnt continually re-render like a game
<azonenberg> it only renders when stuff changes
<azonenberg> maybe logging time per frame is more useful?
<azonenberg> realistically i do most of my performance tuning in nsight or vtune
<bvernoux> azonenberg, but when demo is running it render frequently
<azonenberg> i've removed most of the in-app instrumentation because it was redundant
<bvernoux> azonenberg, to check performances with refresh always on especially for demo or fast scope
<bvernoux> in some case it shall be faster than WFM
<bvernoux> could be a good indicator to show that UI is well decoupled to WFM/scope speed
<azonenberg> bvernoux: when running the demo it still renders once per waveform
<bvernoux> ha not more ?
<azonenberg> why would you? waste of time
<azonenberg> The demo is capped at 50 WFM/s as well
<noopwafel> last time I tried this I ran straight into RAM limits
<azonenberg> i actually have sleep calls in the waveform generator
<bvernoux> some maybe adding WFM/s in demo will be interesting in that case to check the speed of the PC/GFX card and also check potential improvements in future depending on things displayed (FFT ...)
<noopwafel> I need to catch up on all the stuff that changed I guess :)
<azonenberg> also i'm continuing to tweak performance on my FIR filter now
<azonenberg> I am keeping the AVX2 implementation, but now there's an AVX512F version too
<azonenberg> 8.55x faster than the unoptimized C++ so far
<azonenberg> 5.4 ms to do a 225 tap FIR on 800K samples
<azonenberg> Or 148Msa/s
<bvernoux> azonenberg, do you have a proper implementation of MSO chan too ?
<azonenberg> bvernoux: mso chans on what?
<azonenberg> i dont have digital channels on the demo scope
<bvernoux> for normal scope
<azonenberg> but they work fine on lecroy or tek mso5/6
<azonenberg> no idea what the status of other drivers is
<bvernoux> I ask to be sure it is supported
<bvernoux> to add it on Rigol/PicoScope later ...
<bvernoux> ok so in core it is well supported it was just to be sure it was not a draft API for MSO chan ...
<bvernoux> and reference driver for that is tek mso5/6 ? or maybe even better Lecroy driver ?
<azonenberg> I'd actually use Tek as the reference
<azonenberg> because their scpi api for downloading MSO data is much cleaner
<bvernoux> ok great to know
<azonenberg> lecroy mso data is base64 inside xml or something equally absurd
<azonenberg> i forget how many layer of encapsulation there is, but it's really ugly
<bvernoux> ha really not raw data ?
<bvernoux> and Tek have raw data ?
<azonenberg> Pretty much
<bvernoux> ha great yes
<bvernoux> Rigol MSO are strange also
<bvernoux> I need to check where are mapped the MSO chan in their ugly 16bits data
<bvernoux> as anyway there is only 8 chan on 16bits data ...
<bvernoux> in 2 group of 8bits MSO chans
<azonenberg> Tek was a little messy because they dont have dedicated MSO
<azonenberg> you can connect a mso probe to any of the analog channels
<azonenberg> but it disables the analog channel
<azonenberg> as if that wasnt confusing enough
<azonenberg> if you accidentally issue a scpi command to the analog channel while a mso probe is connected, the entire scpi stack hang
<azonenberg> meanwhile lecroy's stack is super stable
<bvernoux> yes I remember that "feature" which remove analog chan to be used as MSO 8bits ;)
<azonenberg> Tek's API is very clean, but the implementation leaves something to be desired
<azonenberg> anything less than perfectly formed commands makes it freeze up
<azonenberg> and the way to query errors is rather awkward
<bvernoux> yes SCPI commands are crap also it remember me the Modem/GPRS horrible AT commands
<bvernoux> when all could be so simple with binary data ...
<bvernoux> as anyway nothing is really standard on scope except few commands which anyway shall be used in very specific context / place so not usable on all scope ...
<azonenberg> Yeah
<azonenberg> *IDN? is about the only scpi command that's truly universal :p
<bvernoux> ha yes ;)
<bvernoux> to speak about picoscope side
<bvernoux> the most complex stuff is to have a libusb driver supporting it
<bvernoux> I do not know anyone working on that instead of using the binary blob from Pico
<azonenberg> That's the nice thing about the external bridge
<azonenberg> we can just replace that with one that uses libusb
<bvernoux> the famous external bridge is a local TCP/IP socket which bridge to the Picoscope USB interface/lib (using SDK blob) ?
<bvernoux> it is a very good stuff anyway as long term to do a rewrite of picoscope blob to libusb is a big work
<noopwafel> yes, and it probably differs substantially between different models
<_whitenotifier> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±3] https://git.io/JLT7U
<_whitenotifier> [scopehal] azonenberg 737dc57 - FIRFilter: initial AVX512F implementation
<_whitenotifier> [scopehal] azonenberg 8e53486 - FIRFilter: use fmadd
futarisIRCcloud has joined #scopehal
maartenBE has quit [Ping timeout: 272 seconds]
maartenBE has joined #scopehal
miek has joined #scopehal
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLkWN
<_whitenotifier> [scopehal] azonenberg 7368341 - FIRFilter: added automatic order calculation
maartenBE has quit [Ping timeout: 260 seconds]
maartenBE has joined #scopehal
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
juli966 has quit [Quit: Nettalk6 - www.ntalk.de]
<azonenberg> bvernoux: also not sure if you saw but we now have FIR notch, LPF, HPF, BPF
<azonenberg> Using a Kaiser-Bessel window, selectable attenuation in the stopband
<azonenberg> you can specify the kernel size or leave it at zero to auto select
maartenBE has quit [Ping timeout: 265 seconds]
maartenBE has joined #scopehal
jn__ has joined #scopehal
<bvernoux> re
<bvernoux> ha yes very nice to have LP, HP, BP filters
juli966 has joined #scopehal
balrog has quit [Ping timeout: 258 seconds]
<d1b2> <DuncanHaldane> Nice to know that the Inhibit-B-Gone stuff works. Innovative polymers has a good line of low-viscosity RTV rubbers if you wanted to try a few different options. I think they'll send out a sample set of cured rubbers to help get the material properties right.
balrog has joined #scopehal
sorear has quit [Read error: Connection reset by peer]
sorear has joined #scopehal
snx90 has joined #scopehal
snx90 has quit [Ping timeout: 245 seconds]
snx90 has joined #scopehal
snx90 has left #scopehal [#scopehal]
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
maartenBE has quit [Ping timeout: 246 seconds]
maartenBE has joined #scopehal
<azonenberg> DuncanHaldane: Oh interesting. Yeah sample sets seem to be a little hard to find
<azonenberg> i was actually eyeing dildo manufacturers, as silly as it may sound
<azonenberg> they tend to have hardness samples for purchase and you can usually get shore hardness values out of them (or from users who have done their own testing)
<azonenberg> Sounds a little ridiculous but they *do* know their silicone
<azonenberg> Also just checked tracking... AKL-PT2 v0.4 board is in my mailbox, gonna go get it shortly
juli966 has quit [Quit: Nettalk6 - www.ntalk.de]
<azonenberg> Hmmm
<azonenberg> For some reason the bottom side of the castellations is soldermasked. not sure if my fault or theirs
<azonenberg> also the holes are filled with soldermask
<azonenberg> i can manaually cut the hole out, it seemsd to be bottom side tented only
<azonenberg> But overall it looks good, i can definitely do some testing with it
<_whitenotifier> [scopehal-apps] sbabic44 commented on issue #295: Issue with FFTS for Windows with MSYS2 mingw64 (Keysight 3000T) - https://git.io/JLtaq
<_whitenotifier> [scopehal-apps] sbabic44 edited a comment on issue #295: Issue with FFTS for Windows with MSYS2 mingw64 (Keysight 3000T) - https://git.io/JLtaq
<_whitenotifier> [scopehal-apps] azonenberg reopened issue #295: Issue with FFTS for Windows with MSYS2 mingw64 (Keysight 3000T) - https://git.io/JInZu
<_whitenotifier> [scopehal-apps] azonenberg commented on issue #295: Issue with FFTS for Windows with MSYS2 mingw64 (Keysight 3000T) - https://git.io/JLtVf