<_whitenotifier-a>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JniaH
<_whitenotifier-a>
[scopehal-apps] azonenberg fa454f6 - OscilloscopeWindow: fixed one-shot trigger being treated as normal trigger in offline filter synthesis mode
<_whitenotifier-a>
[scopehal-apps] azonenberg commented on pull request #358: Windows portable zip/MSI package builds - https://git.io/Jnir6
<azonenberg>
someone--else: where are we on the windows MSI stuff?
<azonenberg>
fsedano: ping re the R&S driver. What's current status, what works on RTM3000, what doesn't?
<azonenberg>
The lack of recent activity could be either a good sign (no changes needed) or a bad one (you're too busy to touch it)
<someone--else>
azonenberg: I think is worked reasonably well, needs a rebase to current master
<someone--else>
the only problem I remember is an icon (tree open/closed indicator) missing in the prefs dialog
<azonenberg>
That's minor
<azonenberg>
If you rebase to current master i can merge
<azonenberg>
then we can close the ticket and do other minor fixes in the future
<azonenberg>
but having a functional windows binary package is a major step towards release readiness
<someone--else>
I'll try to rebase today
<azonenberg>
Great thanks
* azonenberg
goes through list of open v0.1 tickets again
<azonenberg>
"start auto trigger" will be straightforward-ish although figuring out how to do it for each driver might take a little bit, and i'll have to do the toolbar icon still
<azonenberg>
lecroy serdes trigger has been on my to-do list for quite a while now
<azonenberg>
that's just a matter of me sitting down and spending an afternoon on it
<azonenberg>
fx2lafw support is definitely going to be nice to have but i haven't touched it, still looking for someone to take that on
<azonenberg>
I2S protocol decode is still open
<azonenberg>
it should be easy but i havent touched it
<azonenberg>
WaveSurfer 3000 channel interleaving is on my list of things to test once i get back into the lab at $dayjob
<azonenberg>
since i sold my old wavesurfer 3000 to them
<azonenberg>
MIPI DSI ECC is also untouched, but shouldnt be hard
<azonenberg>
mso5000 timebase issues... Degi, bvernoux1, any motion on that?
<azonenberg>
digilent SDK - I have hardware and havent had time to write any driver code
<azonenberg>
siglent 1000x-e... was that GenTooMan working on it? any updates on that?
<azonenberg>
#433, crash if using wrong driver on instrument, that's gonna touch every driver and basically require sanity checking the IDN manufacturer string
<azonenberg>
but the best point for doing that check is kinda TBD still
<azonenberg>
i want to avoid aborting if that happens
<GyrosGeier>
FWIW, I still have no feedback for the preliminary packages
<azonenberg>
so i need to figure out a clean error handling path there
<azonenberg>
GyrosGeier: OK, keep me posted. It's not a huge rush, for v0.1 unofficial debs are fine as long as i can point people to a downloadable alpha package
<azonenberg>
I just wanted to get the ball rolling. Like i said, i don't plan on them being ready for integration w/ a stable repo until v1.0
<GyrosGeier>
sure
<azonenberg>
The key goal for v0.1 is to have something people can download and install that's prebuilt and functional
<GyrosGeier>
the thing is: the packages seem usable to me, but I have no clue if they are good for everyone
<GyrosGeier>
i.e. testing lacks breadth
<azonenberg>
Yeah. I'll try doing some more comprehensive testing on them in the runup towards v0.1 official release
<GyrosGeier>
what would be most interesting to me are things like "your CPU assumption is too conservative and you are missing optimizations" and "your CPU assumption is too aggressive and it fails on my machine"
<GyrosGeier>
can we somehow extract performance data?
<azonenberg>
Performance has been a huge focus from the start
<azonenberg>
The easiest way to get general end to end speed numbers is to just look at the waveforms per second counter in the status bar at bottom
<GyrosGeier>
exactly
<azonenberg>
More comprehensive analysis requires running a profiler, I use VTune heavily
<azonenberg>
as far as CPU assumptions go, the default configuration is to build without any specific C++ flags. So it should use gcc's default configuration which will run on anything
<azonenberg>
Many of the more numerically intensive filters have explicit AVX2, FMA, and AVX512 implementations that are selected at run time via __builtin_cpu_supports() checks
<azonenberg>
All implementations are compiled and present in the binary regardless of the CPU you're compiling on
<GyrosGeier>
my expectation right now would be that most early adopters would be using -mcpu=native
<GyrosGeier>
just because they are compiling from source
<azonenberg>
That's possible but the default cmake flags don't do that
<GyrosGeier>
hmmk
<azonenberg>
i imagine most folks don't modify the build config
<GyrosGeier>
then it's probably not as common
<azonenberg>
This is the intended, supported build configuration
<azonenberg>
one binary that runs anywhere, no use of anything beyond basic x86-64 ISA in the main application
<azonenberg>
then specific inner loops swapping in vectorized implementations if applicable
<GyrosGeier>
okay, so performance with the binary packages should be the same as when building from source
<azonenberg>
Correct. Using more advanced instructions elsewhere is likely going to happen if you use -march=native, but it shouldn't make a big difference
<azonenberg>
if it does, that means i missed an optimization opportunity but i'd handle that with an explicit avx intrinsics implementation
<azonenberg>
here's the eye pattern filter for example
<azonenberg>
at some point i'm gonna play with using scatter-gather instructions and see if i can make it any faster
<azonenberg>
(the loop on 630)
<azonenberg>
doing it right might need avx512 though, for the masked operations
<azonenberg>
i think masked scatter-gather would do that very well
bvernoux1 has quit [Quit: Leaving]
bvernoux has joined #scopehal
<bvernoux>
azonenberg, hi I have no progress so far as I need to rebase my modifications all the time I see the repo is very active those last weeks
<bvernoux>
azonenberg, do you plan to stabilize code for Picoscope stuff ?
<azonenberg>
bvernoux: xzcvczx is working on cleaning a bunch of stuff up and adding 5000 series driver support
<bvernoux>
ha ok
<bvernoux>
latest update from Rigol about an update on Rigol MSO5000 is
<bvernoux>
Firstly, the R&D has found the reason why the data transmission was so slow.
<bvernoux>
I will keep touching on them for the latest update.
<bvernoux>
Currently, they are not sure how faster the data transmission would be improved comparing with the original speed. They are evaluating the case in terms of the software and the hardware. They confirmed there would be a beta version of firmware to improve this issue.
<bvernoux>
Also about delivery
<bvernoux>
The progress looks good, but the R&D requested to extend the due day of the new firmware from Mid-May to the end of July to ensure a robust delivery.
<bvernoux>
So we shall wait to end of july to see at least a beta version of new Firmware for Rigol MSO5000
<_whitenotifier-a>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JnPk1
<_whitenotifier-a>
[scopehal-apps] azonenberg 4262fc5 - Fixed typo in comment
<_whitenotifier-a>
[scopehal-apps] azonenberg 5855e49 - WaveformArea: fixed bug causing second cursor location to not snap correctly when mouse button was released
<_whitenotifier-a>
[scopehal-docs] azonenberg pushed 1 commit to master [+3/-0/±5] https://git.io/JnPLi
<_whitenotifier-a>
[scopehal-docs] azonenberg 11fcbb0 - Lots of updates to "waveform views" section
someone--else has quit [Quit: Connection closed]
someone--else has joined #scopehal
<Degi>
Oh okay
<Degi>
I think I got about 100 Mbps with the scope
<azonenberg>
Also as you can probably see i'm going through the documentation the last few days updating a whole bunch of stuff