<GenTooMan>
src/glscopeclient/glscopeclient --debug --trace SCPITMCTransport myscope:siglent:lan:192.168.1.151 is what I am using but it's not echoing the SCPI commands so I was trying to remember what I used before.
<xzcvczx>
my bad then
<miek>
it needs to match the transport you're using, TMC is USB
<GenTooMan>
hmm that's a start (makes a quiet duh sound)
<miek>
you probably want SCPISocketTransport
* xzcvczx
hides
<GenTooMan>
xzcvczx, hey I made the same mistake :D
<GenTooMan>
I think I will update the FW on my scope it crashes way to often.
<xzcvczx>
yeah but i was trying to be useful
<GenTooMan>
heh more than I was LOL
<xzcvczx>
are siglent good at releasing updates that dont break more than they fix?
<GenTooMan>
I'll find out after finishing recalibration. My scope tended to hang if it got a lot of SCPI commands or I sent the menu off SCPI command.
<xzcvczx>
oh was it you that was complaing about that in here some time ago? i vaguely remember something about menu/SCPI/hanging
<xzcvczx>
but not having a siglent myself i paid very little attention
<GenTooMan>
xzcvczx, that's OK I don't expect you to pay attention. So you lived up to expectations! :D
<xzcvczx>
perfect
<GenTooMan>
in any case yeah that was me, self calibration takes a while hmm.
<GenTooMan>
glscopeclient sort of works with wave capture (sort of LOL)
<xzcvczx>
is it consistant "sort of"?
<xzcvczx>
consistent*
<GenTooMan>
well considering everything it is quite slow but it doesn't hang at the moment, so that's much better.
<xzcvczx>
lol a lot of my early tests on my old machine was using a loaded single channel csv so it was quite a shock to load the demo without OMP and find performance was rather lacking
<xzcvczx>
but with the OMP=PASSIVE thing it was definitely usable again
<GenTooMan>
it does explain the 3.5 seconds between captures though.
<GenTooMan>
great using single capture to dumps the trace dara into memory until it fills
<GenTooMan>
so ... yeah of course it will be huge (sigh)
<xzcvczx>
just steal azonenberg's computer..... you should be good with 192GB of ram
<GenTooMan>
xzcvczx, at 100T it's limited to ~10mb/s so grabing 4 traces at 3.5M each is 14M it will take at least 1.4 seconds (it takes 3.5 in this case) so probably doesn't matter.
<GenTooMan>
well can't fix it tonight
<xzcvczx>
oh thats not too bad then
<xzcvczx>
i have a trace stuck in sigrok at the moment that is trying to produce a 10ish GB csv file
<xzcvczx>
but thats more due to my incompetence than anything
<xzcvczx>
and sigrok not putting out the timestamps properly
<xzcvczx>
i will probably just end hacking in the timestamps i can see in pulseview the time between samples
<GenTooMan>
let me quote a politician "incompetent? try it sometime!"
<d1b2>
<GenTooMan> @mubes So it seems I'm getting monster samples by using single capture. I guess this is something to ask Siglent about too.
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
ericonr has quit [Ping timeout: 240 seconds]
ericonr has joined #scopehal
monochroma has quit [Read error: Connection reset by peer]
monochroma has joined #scopehal
ericonr has quit [Ping timeout: 252 seconds]
<azonenberg>
GenTooMan: how many points are you trying to do per waveform?
<azonenberg>
3.5 MB sounds like 3.5 million samples at 8 bit adc resolution
<d1b2>
<mubes> What are you getting back at the start of each waveform? 75000? What do you have the sample depth set to (that effectively sets the actual sample length up to the max that you've given).
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JstcR
<_whitenotifier-1>
[scopehal-apps] azonenberg bee2381 - Forcibly exec if OMP_WAIT_POLICY is not PASSIVE. Only works on POSIX for now, TODO find a Windows-compatible solution
<_whitenotifier-1>
[scopehal] azonenberg commented on issue #453: Pico bridge crashes with error 0x181 when selecting an inactive channel as the trigger source - https://git.io/JstCv
<_whitenotifier-1>
[scopehal] azonenberg closed issue #453: Pico bridge crashes with error 0x181 when selecting an inactive channel as the trigger source - https://git.io/J30jp
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JstBs
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JstuQ
<_whitenotifier-1>
[scopehal-apps] azonenberg a1bbbee - Clicking on a packet in the protocol analyzer now does a better job of centering packets in the view
bvernoux has joined #scopehal
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±16] https://git.io/Jst6b
<_whitenotifier-1>
[scopehal] azonenberg 91805e8 - Refactored all AVX optimized implementations to use gcc/clang function multiversioning. Fixes #475.
<_whitenotifier-1>
[scopehal] azonenberg closed issue #475: Switch to GCC function multiversioning for AVX forks of functions - https://git.io/JsTbM
<bvernoux>
will be great you check all work fine on your side too on Linux
<bvernoux>
on mys side it is "perfect" with MSYS2 mingw64
<noopwafel>
right, let me see
<bvernoux>
it will requires some refactoring like using switch() for the Pico ...
<bvernoux>
but it can be done later
<bvernoux>
azonenberg, I'm rebuilding your latest push lib ...
<bvernoux>
hmm build is broken
<bvernoux>
from C:\msys64\home\Ben\scopehal-apps\lib\scopehal\Oscilloscope.cpp:36:
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\Oscilloscope.h:791:7: error: multiversioning needs 'ifunc' which is not supported on this target
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\Oscilloscope.h: In member function 'void Oscilloscope::Convert16BitSamples(int64_t*, int64_t*, float*, int16_t*, float, float, size_t, int64_t)':
<bvernoux>
791 | void DoConvert16BitSamples(
<bvernoux>
| ^~~~~~~~~~~~~~~~~~~~~
<noopwafel>
that does .. not work for me
<bvernoux>
C:\msys64\home\Ben\scopehal-apps\lib\scopehal\Oscilloscope.cpp:822:1: error: use of multiversioned function without a default
<bvernoux>
noopwafel, ha ?
<noopwafel>
you changed the include paths I guess
<noopwafel>
on Windows are they just in one huge directory?
<azonenberg>
Hmmm
<azonenberg>
Digging a bit more
<azonenberg>
it seems multiversioning is ELF specific
<azonenberg>
so i'm going to have to revert that
<bvernoux>
noopwafel, they are intended to be included
<bvernoux>
noopwafel, with ref in CMake it is why I have removed this absolute path
<noopwafel>
yes, but you removed all the path :D
<noopwafel>
so now /opt/picoscope/include/libps6000a/ps6000aApi.h is ps6000aApi.h but you only add /opt/picoscope/include/ in cmake
<noopwafel>
so there's a whole path component vanished
<bvernoux>
noopwafel, they are intended to be defined in src\ps6000d\CMakeLists.txt => include_directories(${PICO_SDK_PATH}/include/)
<noopwafel>
so that's why I wonder, on Windows is there just one huge directory with everything in it?
<noopwafel>
because that is not the case on Linux
<bvernoux>
see
<bvernoux>
# Linux specific Picoscope SDK Path
<bvernoux>
set(PICO_SDK_PATH "/opt/picoscope")
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±16] https://git.io/Jst1B
<_whitenotifier-1>
[scopehal] azonenberg 50c0c23 - Reverted last commit because it causes build failures on non-ELF targets like Win32. Apparently gcc can't multiversion on anything non-ELF.
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jst1R
<bvernoux>
noopwafel, it is not portable to provide full path it shall work using include_directories() in CMakeLists.txt like it work on MSYS2 mingw64
<noopwafel>
bvernoux: read what I say ;p
<noopwafel>
I can fix the paths fine, but then it will presumably break for you
<bvernoux>
noopwafel, so maybe add other directories for linux if any
<noopwafel>
since the obvious fix is to change the include to "libps6000a/ps6000aApi.h"
<noopwafel>
but I guess on Windows this is not where the header is?
<bvernoux>
you are only speaking about
<bvernoux>
#include "ps3000aApi.h"
<bvernoux>
#include "PicoStatus.h"
<bvernoux>
#include "ps6000aApi.h"
<bvernoux>
#include "PicoVersion.h"
<bvernoux>
correct ?
<noopwafel>
yes
<noopwafel>
these are *not* in the same directory on Linux
<noopwafel>
and there are filename collisions
<bvernoux>
hmm
<noopwafel>
I am trying to work out if it matters, it seems like maybe the files are identical, and I can just add /libps3000a etc to the path
<bvernoux>
On windows all is in C:/Program Files/Pico Technology/SDK
<bvernoux>
C:\Program Files\Pico Technology\SDK\inc contains all
<noopwafel>
it does seem like they are identical
<noopwafel>
I have 10 copies of PicoStatus.h but they all have the same shasum
<bvernoux>
yes it is crap ;)
<noopwafel>
jeez
<azonenberg>
Lol
<bvernoux>
are you sure you are using latest install of PicoSDK ?
<bvernoux>
as there is not such mess on Windows SDK
<noopwafel>
it's probably ~legacy~
<bvernoux>
which in theory shall be the same for headers
<azonenberg>
reminds me of xilinx installations
<azonenberg>
where the linux install of either ise or vivado, i forget, included windows binaries too
<noopwafel>
you have individual package for each driver
<noopwafel>
but yeah it's a good question, let's check
<azonenberg>
and there were firmware files for the jtag dongles under 32 and 64 bit subdirectories
<azonenberg>
which were sha identical
<noopwafel>
the picoscope packages actually fail to install for me
<noopwafel>
I had to unpack one of the debs and fix it
<noopwafel>
I should .. probably actually report that, come to think of it
<bvernoux>
I have used latest PicoSDK_64_10.7.21.207.exe for Windows for info
<noopwafel>
I did not have latest SDK
<noopwafel>
but latest SDK is the same
<noopwafel>
so I just add paths
<azonenberg>
xzcvczx: so multiversioning is not the solution
<bvernoux>
in worst case we will have different include for WIN32 or else ...
<azonenberg>
it breaks windows/osx builds since it's ELF specific
<azonenberg>
So we need to find another solution to your clang woes
<bvernoux>
azonenberg, you could probably do automatic build to check that with new PR, commit ?
<bvernoux>
azonenberg, build with MSYS2 mingw64 is pretty simple
<azonenberg>
bvernoux: I have CI builds. They caught it right around the time you complained
<azonenberg>
that commit was like 20 minutes old lol
<noopwafel>
bvernoux: merged, thx
<noopwafel>
or rather, rebased on top of master and force-pushed :p will tidy it sometime soon and then yes we should upstream
<noopwafel>
also I guess I should TRY IT since that was the point, jeez
<noopwafel>
my head is in a maze of Ghidra windows
<noopwafel>
it does, in fact, still work.
<azonenberg>
Lol
<azonenberg>
noopwafel: Let's try and get the bridge code cleaned up and refactored before xzcvczx gets his 5000 series
<bvernoux>
noopwafel, great job !!
<bvernoux>
noopwafel, you can do a PR to azonenberg now ;)
<azonenberg>
What needs to be done for that? also did you make any changes to the PicoOscilloscope class or just the bridge?
<noopwafel>
I have minor changes to the PicoOscilloscope class to stop it complaining, but NFC
<noopwafel>
since the unknown path works
<noopwafel>
I think it's just removing some debug things and some coding style pass
<noopwafel>
although actually maybe it's a good idea to also get rid of the extra global we don't actually need
<bvernoux>
then azonenberg could rename the ps6000d dir to something else like pico-bridge ;)
<noopwafel>
right, thankfully that's a simple one :)
<noopwafel>
I think some more thought may be needed for some other scope series, but that's a Future Problem
<bvernoux>
yes
<bvernoux>
a refactor will be required
<bvernoux>
but it is a first draft "working"
<bvernoux>
and it is clearly a big advance as glsclopeclient is very usable with Pico even the low cost Pico3000
<bvernoux>
with 20WFM/s or more even on old computer/GFX card
<azonenberg>
Yep, now we just need some open hardware that's as performant
<bvernoux>
I imagine 100kSPS shall reach more than 40WFM/s
<azonenberg>
even if low bandwidth etc
<noopwafel>
👀
<bvernoux>
azonenberg, Pico3000 is the first "low cost" HW to be fast with glscopeclient ;)
<bvernoux>
I doubt Rigol MSO5000 will be as fast even if they shall push fixes for SCPI in few days (next week in theory)
<azonenberg>
Yeah pico stuff is designed for PC-attached operation
<azonenberg>
most of the rest is not
<bvernoux>
azonenberg, do you want I create an issue about Oscilloscope.cpp:822:1: error: use of multiversioned function without a default ?
<bvernoux>
azonenberg, fast fix could be to add #if WIN32 ...
<azonenberg>
I reverted those commits
<azonenberg>
it should build fine
<bvernoux>
ok great
<bvernoux>
azonenberg, about all the mess with %z maybe a good things will be to rewrite all using https://github.com/mpaland/printf
<bvernoux>
it support %z ...
<bvernoux>
for long term that will avoid all the crazy warnings on any platform ...
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-2/±2] https://git.io/JstFP
<_whitenotifier-1>
[scopehal-apps] azonenberg 93fcf26 - Unified dense pack shaders to use same GLSL source as normal ones with a different #define
<xzcvczx>
azonenberg: my bad, i didn't notice it was elf only
<azonenberg>
i'm a bit annoyed because it would have been so easy to implement in a portable manner using dynamic dispatch, like vtables
<azonenberg>
and it would have worked on any platform and executable format
<azonenberg>
So i naturally assumed thats what they did
<azonenberg>
just have libc startup code figure out the cpu flags then prior to main() update a global function pointer for each multiversioned function to the correct target
<GenTooMan>
azonenberg, mubes dump of log from scope to give you an idea of what was/is happening. https://pastebin.com/K5bnw3Ab
<azonenberg>
Aaand just found a regression in my shader tweaks
juli9611 has joined #scopehal
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JsqIr
<_whitenotifier-1>
[scopehal-apps] azonenberg 22f1355 - Fixed regression in last commit
ericonr has joined #scopehal
<d1b2>
<mubes> @GenTooMan It looks like all your reads are for 1400000 octets of data...is that what you expect?
<GenTooMan>
azonenberg, it appears to consume 135ms to redundantly read the information for each channel every acquisition cycle. In single trigger mode the scope wants to grab a full depth of data. Keysite / Agilent scopes don't do this unless you set it to. Another "interesting" issue is that the code turns on all channels instead of checking what the settings are first. Obviously when shut down it turns all channels off. So that's
<GenTooMan>
"fun". Would it make sense to "get" the scope state first then start messing with it? Does it make sense to force on channels not being used (currently done)?
<azonenberg>
As of now, we add all channels to the UI during startup
<azonenberg>
We can change this default later on
<d1b2>
<mubes> So....what is your problem at the moment?
<d1b2>
<mubes> Have you reduced the sample depth at all?
<GenTooMan>
Actually I haven't found a way to do the latter.
<GenTooMan>
In single acquisition mode it just grabs as much as possible as far as I can tell.
<d1b2>
<mubes> On mine you push the Aquire button and then you can set the 'Mem Depth'...is there any similar option?
* GenTooMan
looks, "well msiz command seems to do that. Sorry brain was seeing polar bears in a snow storm apparently."
<d1b2>
<mubes> It doesn't look like you're caching any infomration from the scope (attenuation, gain etc.) so it's requesting those each time. You've got an INR command....oh what I'd give to have an INR command. Luxury.
<GenTooMan>
It would be nice to more directly control the acquisition depth to be honest.
<d1b2>
<mubes> It would be nice if I had a private island. We're 2-0 down 😦 😁
<d1b2>
<mubes> You can only set a max depth...it may give you less at low time/div settings I'm afraid
<GenTooMan>
the INR command is mandatory as they have no other way to know if the scope as acquired anything. I did notice that the code for acquiring wave forms doesn't check for a waveform acquired.
<azonenberg>
Yeah that's where the PollTrigger() function comes in
<azonenberg>
AcquireData() only gets called if there's something to see
* GenTooMan
has a list of things he missed now.
<d1b2>
<mubes> Some scopes (mentioning no names) don't have it. Then it gets interesting to figure out when you've got a waveform. AcquireData can't do that test.
<d1b2>
<mubes> If you're collecting 1.4MPoints/channel that's going to take some time. Reducing to 10K should help, but perhaps not as much as you might hope. Take a look in the manual for the SDS2000X+ for a graph of sample aquisition vs. depth for comparison purposes.
<GenTooMan>
Well the scope "auto-magically" sets the depth it appears as last night it was 3.5MPoints/channel and it took 3.5 seconds to get captures instead of 1.39 like at 7am
<d1b2>
<mubes> You can set the max. It may use less (assuming it's similar to the 2KX+)
<d1b2>
<mubes> If you extend the timebase it'll probably return more samples
<bvernoux>
azonenberg, latest updates work fine with MSYS2 mingw64
<bvernoux>
does there is some plan to improve speed of shader/opengl stuff with lot of points on old GFX card ?
<bvernoux>
nice the new center stuff is very good
<bvernoux>
to compare different protocol data like spi....
<d1b2>
<GenTooMan> @mubes The SDS1XXX X-E and below have a completely different SCPI API. It would be nice to set the sample "size". Well there is a lot to work on at the moment.
<bvernoux>
what is the speed of SDS2000X+ in WFM/s for 1Mpoints on 4 chan ?
<d1b2>
<mubes> Yes, we're aware they're pretty different (the whole reason I hadn't started it) but we can use 'clues' from one scope to inform us about the other. You're making pretty good progress so far!
<d1b2>
<mubes> so 1M on 4 ch would be about 2 secs/aquisition
<bvernoux>
ha ok 10 times slower than Pico ...
<bvernoux>
and with 100k ?
<bvernoux>
woo so SDS is a slow as Rigol MSO5000 ...
<azonenberg>
bvernoux: i'm actively working on shader code speedups right now
<bvernoux>
azonenberg, ha great !!
<bvernoux>
azonenberg, I can do the test when you have something ready
<d1b2>
<mubes> 100K is about 0.9/sec
<bvernoux>
azonenberg, especially on my old GFX card/CPU it could be interesting to see improvement as on your PC IIRC you have too fast GFX card to see major differences ;)
<bvernoux>
yes like Rigol MSO5k so unusable in realtime
<GenTooMan>
bvernoux, it's all relative, slower in this case is measuring how fast frozen molasses is flowing.
<azonenberg>
bvernoux: i'm using the nviida profiler, i can see 10us differences in shader runtime
<bvernoux>
RIgol shall provide a new Firmware to improve SCPI speed
<bvernoux>
they have promised it for middle of May ;)
<bvernoux>
so on monday I will contact the engineers to have news
<bvernoux>
it will be amazing if they could improve it to reach something like 10WFM/s over GigabitEthernet with 1Mpts on 4 Chan
<azonenberg>
That would be picoscope level speeds
<bvernoux>
azonenberg, Do you have worked on decoupling UI from WFM slowness ?
<azonenberg>
or nearly so
<d1b2>
<mubes> The Rigol has GbE? That's a big advantage
<azonenberg>
Not right now
<azonenberg>
mubes: it has it, but the firmware is too slow to use it :p
<d1b2>
<mubes> ha ha
<azonenberg>
i dont recall having seen more than like 30 Mbps actual throughput
<bvernoux>
azonenberg, as I remember on my Rigol when it reach 1WFM/s everything is slow the GUI to compute anything runs at 1WFM/s too
<azonenberg>
in any test data people have sent me
<d1b2>
<mubes> for 100K on 4 channels with overhead the link is something like 35% used on 100MBit, so best you'll see without compression is 3 wf/sec
<bvernoux>
yes Rigol have GbE (MSO5k) but it is clearly not used correctly so far ;)
<d1b2>
<mubes> I've never seen it written if the SDS2K has 100Mb or Gb. Let's try an experiment
<azonenberg>
do you not have a managed switch or something that will show you the link speed?
<d1b2>
<mubes> yeah, but I can't be bothered to look up which port its on
<bvernoux>
the good point if Rigol improve a lot the SCPI speed for data you can push Siglent to do the same on their SDS1xxx o 2xxxx
<d1b2>
<mubes> Its 100MBit
<d1b2>
<zyp> the siglent doesn't?
<bvernoux>
anyway even with only 100Mbit it shall reach 8MBytes/s so 2WFM/s on 4 chan ;)
<azonenberg>
ok that's a big limitation then
<d1b2>
<mubes> No, It's the first BIG advantage I've seen to the rigol
<d1b2>
<zyp> the price difference still has me leaning towards the rigol
<bvernoux>
yes even if the Rigol GbE runs only at 500Mbits (as it is maybe not very optimized) it is still 5x better than 100Mbits ;)
<bvernoux>
I need to do a test ;)
<bvernoux>
will need to build an app to test the GbE throughput
<bvernoux>
the bad things is latest Firmware have removed SSH ...
<d1b2>
<zyp> it's still hackable, right?
<bvernoux>
it will need bigger hack to integrate SSH mainly change busybox running
<bvernoux>
yes it is hackable and some binaries can be signed and loaded
<bvernoux>
the AES keys have been fully leaked
<d1b2>
<mubes> I'm assured by people who know such things that its un-securable
<bvernoux>
yes it is impossible to secure it
<bvernoux>
even if they change the AES keys it can be hacked again
<bvernoux>
it is why they have never changed anything related to that
<bvernoux>
except they have removed SSH from busybox for security reasons ....
<bvernoux>
On Siglent when you are using SCPI does the screen of the scope enter in a special mode and freeze the display with a message ?
<bvernoux>
like it is the case on high end scope which switch to SCPI mode without any refresh on the screen (to speedup things too with exclusive access I think)
<d1b2>
<mubes> You can lock out the front panel
<d1b2>
<mubes> TBH I don't know if it stops updates, but I don't think it does
<bvernoux>
as on Rigol it is crazy but the scope still display things like if nothing have changed so it runs SCPI commands and UI is working like nothing changed which is clearly an issue and probably slow down lot of things and have border effect
<bvernoux>
azonenberg, on your Lecroy scope with screen does the UI is stopped when using SCPI ?
<d1b2>
<mubes> I'm intrigued to see this new Rigol FW
<d1b2>
<zyp> wonder how much work it'd be to reverse engineer the software and replace it with something simple that just grabs the data and throws it on the network
<bvernoux>
some guys started doing that but now news since few years
<d1b2>
<mubes> Thats the tangle the SDS2000X+ can get itself into when running over SCPI
<d1b2>
<GenTooMan> @mubes I think I will add a "save_state" and "restore_state" method to SiglentSCPIOscilloscope class so I won't be so freaked out when the scope channels get all turned off. It also will be good for getting all the repeated data used when doing waveform capture.
<d1b2>
<mubes> A good idea...check you haven't already got one, on the 2K+ its :SAVE:SETUP INT,x
<d1b2>
<GenTooMan> @mubes a quick scan of the code says "no" I'll have to see what the SDS1XXX X-E does to save state information (if anything).
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 8 commits to master [+0/-0/±8] https://git.io/Jsq2S
<_whitenotifier-1>
[scopehal-apps] azonenberg 9086353 - Refactored bounds check to end of main shader loop for about 7% speedup
<_whitenotifier-1>
[scopehal-apps] azonenberg 9e6b6d3 - Hard coded cols per block to 1
<azonenberg>
Ooook i'm gonna say that is probably a good start
<_whitenotifier-1>
[scopehal-apps] azonenberg 863cf13 - Changed block status to be vectors per Y coordinate
<_whitenotifier-1>
[scopehal-apps] ... and 5 more commits.
<_whitenotifier-1>
[scopehal-apps] azonenberg closed issue #327: Waveform compute shaders get really slow if too many points per X coordinate - https://git.io/J3OzC
<azonenberg>
bvernoux: how's this perform?
<bvernoux>
woo let's test
<bvernoux>
you have fixed the different things ?
<bvernoux>
it is in Added parallel output store ?
<bvernoux>
i'm testing it with my Pico3000
<azonenberg>
bvernoux: well i made a bunch of fixes, that's the most recent commit
<bvernoux>
woooooooo
<azonenberg>
faster? :
<azonenberg>
:)
<bvernoux>
it is like night & day
<bvernoux>
full screen > 13WFM/s
<azonenberg>
:D
<bvernoux>
with 1Mpts 4 chan
<azonenberg>
I still think i can squeeze more performance out of it but that's a good start
<bvernoux>
before it was less than 8WFM/s
<bvernoux>
full screen
<azonenberg>
I'm actually going to bump the no-intensity-grading shader out to v0.2 now
<azonenberg>
it's much less critical now
<bvernoux>
now zoom out or in do not change the WFM/s
<bvernoux>
which was clearly limited by my GFX card GPU
<_whitenotifier-1>
[scopehal-apps] azonenberg commented on issue #338: Add speed optimized rendering shader with no intensity grading for low end GPUs - https://git.io/JsqVq
<bvernoux>
I think lot of guys with old GPU will love this new version ;)
<azonenberg>
It's not just old GPUs
<azonenberg>
on my 2080 Ti it's far more performant too
<azonenberg>
It's just that i'm complaining about things being slow with 128M point waveforms and you're complaining about 1M point :p
<bvernoux>
ha great
<bvernoux>
yes your 2080TI is probably 128x faster than mine ;)
<azonenberg>
Building on my work machine now to test on the intel integrated gfx
<bvernoux>
I do not see any artifact or glitch too
<bvernoux>
all is smooth and nice
<azonenberg>
Yeah there were some bugs causing artifacts in the middle of that chain of commits
<azonenberg>
but i found and fixed them before pushing
<bvernoux>
very nice job
<azonenberg>
The real challenge was planning memory access patterns to the working buffer
<azonenberg>
so i can integrate stuff in as many threads as possible
<azonenberg>
But without having any possibility of two threads trying to increment the same address at once
<azonenberg>
Because that would require atomics which are slow
<azonenberg>
So it's a kind of multipass architecture
<bvernoux>
with 1 chan 1Mpts I'm at more than 20WFM/s
<azonenberg>
That is probably limited by the scope now, not your gpu
<azonenberg>
(or at least the pico driver)
<azonenberg>
For each pixel, 64 threads fetch one sample each from GPU memory
<azonenberg>
They do a bit of math and interpolation to find the min and max Y coordinate for that line segment within this pixel
<bvernoux>
if I zoom I even reach 26WFM/s
<bvernoux>
zoom in max
<azonenberg>
ah ok so still some gpu limiting
<azonenberg>
Then I loop over all 64 samples, one at a time
<azonenberg>
and do the intensity graded fill in parallel
<azonenberg>
with each thread incrementing a different address
<bvernoux>
yes zoom out max it jump between 22WFM/s to 28WFM/s
<azonenberg>
at some point i will probably patch the zoom code in the UI
<azonenberg>
so you cant zoom out more than 100%
<bvernoux>
strange with Zoom max it is stable at 25WFM/s
<azonenberg>
i.e. you cant make the waveform any smaller than the entire FOV
<azonenberg>
that slows things down a lot, and doesnt really help anything
<bvernoux>
yes it will be great to limit zoom out to 100% to be full
<bvernoux>
as it is useless
<bvernoux>
to be checked if there is not some improvements to do on pico-bridge side too
<azonenberg>
The bridge is pretty simple but the PicoOscilloscope class now uses AVX2 optimized waveform conversion if available
<azonenberg>
going from int16's to float32s
<bvernoux>
the only things a bit slow is the contextual menu
<bvernoux>
which is maybe because it does not use OpenGL and have some extra refresh ...
<bvernoux>
ha ok so the AVX2 optimization shall work with Pico3000 too
<bvernoux>
except I doubt my CPU support it ;)
<azonenberg>
how old is it? i think it was added in Haswell
<bvernoux>
Core I7-3630QM is quite old i doubt it support AVX2 ...
<azonenberg>
Yeah it doesnt, it only has original AVX
<azonenberg>
Which i dont currently use
<bvernoux>
it support AVX ;)
<bvernoux>
does there is any advantage of AVX ?
<bvernoux>
so i see only optimisation towards GPU shaders
<azonenberg>
I havent used AVX1 much, AVX2 adds a lot of instructions that are useful for what we do (mixed integer and floating point)
<azonenberg>
iirc avx1 didnt have much for integer stuff
<bvernoux>
ha yes :(
<azonenberg>
oh and the broadcast instruction
<azonenberg>
i use that heavily
<bvernoux>
anyway it is very impressive with 1Mpts ;)
<azonenberg>
and the permute/shuffle
<bvernoux>
I see slow down with 2 or 4CH anyway
<bvernoux>
because my GFX card is quite slow
<bvernoux>
and it overheat quickly after 5minutes ;)
<bvernoux>
a good test is to load a rigol file ;)
<bvernoux>
before it was not usable
<bvernoux>
strange import of Rigol bin file crash when I zoom out now
<bvernoux>
even small file
<bvernoux>
hmm that directly crash the GFX driver ;)
<bvernoux>
maybe not an issue with glscopeclient but my GFX card ;)
<bvernoux>
I will reboot to test again to be sure
<d1b2>
<mubes> Much nicer 'feel' here.
<azonenberg>
bvernoux: I'm sure there's still bugs :p
<azonenberg>
But probably not in these optimizations, i'm reasonably confident they're fine
<d1b2>
<mubes> At 10MS with a static waveform I'm surfing around in I get 'pauses' which I didn't get before. These are when I'm reasonably well zoomed in.
<bvernoux>
I never reached 40WFM/s with 1 chan 1Mpts before with my Pico3k ;)
<bvernoux>
it was something like 18WFM/s with zoom in max IIRC
<azonenberg>
bvernoux: also FYI you dont have to manually black out serial numbers in screenshots anymore
<azonenberg>
there's a preference under privacy to show it as *s except for the last digit or two
<bvernoux>
yes I shall choose the option ;)
<azonenberg>
For exactly this reason
<d1b2>
<mubes> yay
<bvernoux>
yes it works ;)
<d1b2>
<mubes> deffo getting rendering pauses here
<azonenberg>
mubes: interesting
<azonenberg>
Is it possible they're not new, and were just lost in the noise because rendering took so much longer before?
<azonenberg>
That seems more plausible than new stuttering from some of the changes I made
<azonenberg>
But i could be wrong
<d1b2>
<mubes> Using the scroll wheel to zoom in and out, there can be a 1s pause sometimes when the whole gui locks out. These weren't present before
<bvernoux>
I need to add some options for Pico
<azonenberg>
wow that's slow
<bvernoux>
like how many SMPS ;)
<azonenberg>
ok, i'll keep on debugging
<bvernoux>
and also fix the trigger delay it is always 800 us
<d1b2>
<mubes> running it as OMP_WAIT_POLICY=PASSIVE gdb --args ~/B....etc
<bvernoux>
azonenberg, do you have same issue with Trigger Offset on Pico6000 ?
<bvernoux>
it does not change here
<d1b2>
<mubes> If I spin the wheel to zoom in it'll do 2-3 steps, pause for perhaps 1 sec, then the rest of the steps
<azonenberg>
bvernoux: trigger delay is currently hard coded to midpoint of the waveform
<azonenberg>
that's next on my list of things to fix after i finish digital channels
<bvernoux>
ha ok
<bvernoux>
the same for pico memory it is 1 MS by default not configurable
<azonenberg>
mubes: see if you can track down the function that's slow in a profiler, make sure it's the rendering and not some other recent changes?
<azonenberg>
bvernoux: in the 6000 series memory depth and sample rate are fully configurable
<bvernoux>
azonenberg, ha ok I need to check the code specific to Pico3000 in that case
<azonenberg>
Did you not implement the RATES? command on the bridge?
<azonenberg>
or DEPTHS?
<bvernoux>
I have not implemented anything new on my side I have just fixed noopwafel code to work on MSYS2 mingw64 so far
<bvernoux>
the most interesting parts will be MSO ;)
<bvernoux>
to do a demo capture digital stuff with analog stuff in //
<azonenberg>
Yeah, don't touch any 3000 series MSO stuff until i finish the 6000 series
<azonenberg>
i'm still reworking that code
<azonenberg>
but I took a detour today to finish 1553 and do the rendering optimizations
<bvernoux>
yes I will wait
<bvernoux>
noopwafel, shall also push the PR
<bvernoux>
before you do too much modifications
<bvernoux>
noopwafel, could you push a PR for pico-bridge before azonenberg modify too much things ?
<bvernoux>
I consider the pico3000 support very stable so far
<bvernoux>
azonenberg, do you have think about a nice feature too to remove negative part on Analog part for some use case ?
<bvernoux>
azonenberg, it could be great for digital stuff too as digital stuff are never negative
<bvernoux>
and some signal which are never negative too like monitoring 1.8V, 3.3V, 5V ...
<d1b2>
<mubes> @azonenberg Looks like user error. That OMP_WAIT_POLICY=PASSIVE doesn't seem to get passed to the inferior by gdb 😕 Profiler doesn't show anything too scary. libnvidia-glcore and inferiors are about 23% of the CPU use.
<azonenberg>
So if you set passive manually it works without any stuttering?
<d1b2>
<mubes> Yes, seems fine again
<azonenberg>
So just to be clear, current state from everyone who's tested the new shader is that it's significantly faster with no known problems?
<d1b2>
<mubes> Hang on....just investigating something
<d1b2>
<mubes> Not sure if this will make any sense.
<d1b2>
<mubes> 10MS static sampled buffer. Can zoom in and out freely and it's much more responsive than it used to be.
<d1b2>
<mubes> Tried it for perhaps a minute with the spin wheel. No issues.
<d1b2>
<mubes> Added a 1V5 Thresh to Ch 1 and started getting these delay issues again
<azonenberg>
Sounds like there might be a bug or missed optimization in digital rendering then
<azonenberg>
i'll look into it
bvernoux has quit [Quit: Leaving]
<d1b2>
<mubes> Just got control back
<d1b2>
<mubes> over time it locked up the entire gui. Had to log in remotely.
<d1b2>
<mubes> Connected via gdb and there was nothing unusual happening. Was in GI_poll
<d1b2>
<mubes> Killing scopehal didn't get rid of the window. Had to kill the shell it had been started from, which was showing 100% CPU
<d1b2>
<GenTooMan> @mubes I've had to do that periodically, when LAN IO gets into contention issues Linux acts like the kernel is using ALL the processing power of the system. I had a lan port on my switch go bad and my computer froze (literally). Linux has some issues that RECENTLY (in the last 5 years) have come into being. I've been running linux since version 0.9 I think.
<d1b2>
<mubes> Well, lets hope its something in the latest patches rather than something systenmic, otherwise that could hurt for a while
<azonenberg>
mubes: try 9e6b6d3 and see if you have the problem still
<azonenberg>
or 22f1355
<azonenberg>
or 8134764
<azonenberg>
if you have problems in all 3, it's not my reecnt changes
<d1b2>
<mubes> building 9e6b6d3
<d1b2>
<mubes> (Cleanly)
<d1b2>
<mubes> 9e6b6d3 has artifacts
<d1b2>
<mubes> zooms cleanly with no digital
<d1b2>
<mubes> zooms cleanly with digital
<d1b2>
<mubes> I'll rebuild head and make sure the problem is still there
<azonenberg>
I think i just reproduced
<azonenberg>
i dont understand it yet but i have jerky scrolling with digital waveforms in this test
<d1b2>
<mubes> That was quick, normally takes 9 months
<azonenberg>
:P
<d1b2>
<mubes> Clean building master
<d1b2>
<mubes> zooms cleanly with no digital
<d1b2>
<mubes> yep, same problem.
<d1b2>
<mubes> deffo different between those two builds
<azonenberg>
Ok, hmm
<azonenberg>
How about b0dfef5
<d1b2>
<mubes> building
<d1b2>
<mubes> I have to go inflict a piano lesson on my daughter shortly....should be OK to get this test done
<d1b2>
<mubes> That one freezes.
<d1b2>
<mubes> My test data is 4x10MS channels with a load of clocks in Ch1. I'm thresholding those at 1v5 and then zooming in and out on one specific 36 bit sequence. It locks after about 10-12 iterations.
<azonenberg>
Ok. I'll dig around after work
<d1b2>
<mubes> no worries. I'll be back about 21:00 BST
<d1b2>
<GenTooMan> I was considering modifying ProcessAnalogWaveform, with the thought of passing a structure (class?) to it containing the information it needed instead of a waveform descriptor reference, as the waveform descriptor is only supported by 3(4?) Siglent models. That may be a cleaner approach. Enjoy time with your daughter with tintinnabulation of the ivorys.
<d1b2>
<mubes> Just build what you need for your scope family. We'll worry about how we square it all away once its working. There are only a few parameters we pull out of the wavedesc anyway, so it sould be possible to do that in an intermediate routine if need be.
<azonenberg>
mubes: so it looks like the problem is related to displaying the area left of the start of a digital waveform
<azonenberg>
probably a boundary condition on the left side
<d1b2>
<mubes> Well, at least we've found it before the 'user community' does 😁
<azonenberg>
I don't have a root cause but things seem to get slow when i have a digital waveform and i scroll way before it starts
<azonenberg>
analog don't do that
<azonenberg>
Which is weird as the two shaders are literally the same code just with a few #define's set different
<azonenberg>
the actual delta between them is very minimal
<d1b2>
<mubes> A lot of my stuff does...probably gets tickled by the SWD decode as thats only present when there's valid data;
<azonenberg>
No, it has nothing to do with decode overlays
<azonenberg>
those are software rendered in Cairo
<azonenberg>
they only touch GL as bitmaps in the final compositing pass
<azonenberg>
I plan to GPU accelerate them eventually but it hasn't happened yet
<azonenberg>
It's logic waveforms that are causing the problem for sure
<d1b2>
<mubes> ok!
<azonenberg>
I don't know *how*
<azonenberg>
there's literally seven lines of code in the analog path not in the digital
<azonenberg>
and and twelve in the digital not in the analog
<azonenberg>
and of those twelve, four are curly braces
<d1b2>
<mubes> So...only other clue might be that at the moment my analog traces start before 0fs on the time scale due to a hiccup in the calculation in the wavedesc which I haven't got around to fixing yet...could that tickle something?
<azonenberg>
No, that should be fine. everything is signed offsets
<azonenberg>
i'm reproducing it in a file that used to work fine
<azonenberg>
oho, i think i understand... maybe
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±4] https://git.io/JsmIh
<_whitenotifier-1>
[scopehal-apps] azonenberg 8bb6ba1 - Refactoring: added GetProgramForWaveform() to figure out the correct shader for a given type of signal
<_whitenotifier-1>
[scopehal-apps] azonenberg ef87dab - Minor cleanup of rendering shader
<_whitenotifier-1>
[scopehal-apps] azonenberg 6045fd3 - Early out in shaders that end before the first pixel. Fixed bug causing last sample to not be rendered.
<azonenberg>
mubes: does that fix it?
<d1b2>
<mubes> Sorry, it'll be a couple of hours before I can test.
<azonenberg>
No worries, just letting you know it's on deck
<azonenberg>
So i think there's more potential for optimization in the rendering when panning waveforms
<azonenberg>
I'm pretty sure we map and unmap buffers every frame even if we don't actually need to write to them
<azonenberg>
Which probably means lots of pointless pcie traffic and cache flushing
bgamari has quit [Ping timeout: 260 seconds]
bgamari has joined #scopehal
Tost has joined #scopehal
<d1b2>
<mubes> @azonenberg Current master appears to fix the freezing bug. I'll be using it for a couple of hours now so it'll get a good test.
<azonenberg>
Great
<d1b2>
<mubes> It is hugely faster. I think its now at the point where I really wouldn't want to be without it for doing the sort of stuff I'm playing with at the moment. Interested to see how the Pico 3000 driver comes along.
<d1b2>
<mubes> OK, after a whole evening, no gliches or issues. Consider it closed I think.