<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"
<_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
<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
<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