<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3Ae8
<_whitenotifier-3>
[scopehal] azonenberg 22d4e03 - Waterfall: don't discard frequency bins that aren't at an integer pixel position. Fixes #472.
<_whitenotifier-3>
[scopehal] azonenberg closed issue #472: Make waterfall display do proper averaging when >1 FFT bin per pixel - https://git.io/J3NpS
<_whitenotifier-3>
[scopehal-apps] azonenberg 05bb70f - Added proper data file path resolution. Removed copying of data files to build directory and chdir to build directory. Fixes #302.
<_whitenotifier-3>
[scopehal-apps] azonenberg closed issue #302: Proper path resolution for data files - https://git.io/JLKUm
<d1b2>
<Darius> I thought Brew installed in /usr/local
<azonenberg>
xzcvczx: i dont know anything about osx, i put that directory in at darius's request
<d1b2>
<Darius> that was in the list
<azonenberg>
It wont run on mac yet, or at least glscopeclient won't
<azonenberg>
I would be interested to see if headless libscopehal code will
<azonenberg>
i have no reason to believe it would have problems
<azonenberg>
so ATE-type code on osx should work now
<xzcvczx>
whats the problem on mac? just the opengl stuff?
<azonenberg>
Yeah
<d1b2>
<Darius> I could try building it
<azonenberg>
We need GL 4.2 plus a bunch of extensions including GL_ARB_compute_shader
<azonenberg>
latest osx gl drivers i know of are 3.3
<xzcvczx>
i assume a couple of the bsd fixes might be needed too
<azonenberg>
But really, nobody has ever tried building on osx because we know it won't run
<azonenberg>
so it would not surprise me if there's more issues :p
<xzcvczx>
darius: i assume that Socket.cpp, UART.cpp will be the main issues you run into
<d1b2>
<Darius> wonders how to build
<azonenberg>
Long term it would be great if we had OpenCL and compute shader renderers so it could run on older GL as long as you had an OpenCL implementation available
<xzcvczx>
neither of which is a particularly hard fix
<azonenberg>
And it would be great if we had CUDA and OpenCL builds of all the accelerated filters and ffts
<azonenberg>
But again, manpower issues - there's only one me
<azonenberg>
and not enough other people contributing to that part of the code yet
<azonenberg>
I do have a friend who is getting a m1 mac in the near future so i might bug her to try and work on porting there :p
<d1b2>
<Darius> heh
<xzcvczx>
do you know what gen of intel igpu that opencl actually got good?
<azonenberg>
but basically all the compute shaders will have to be rewritten
<azonenberg>
I have not tested opencl on an igpu yet
<azonenberg>
only on my nvidia cards
<xzcvczx>
oh ok
<azonenberg>
It might work, i wouldnt know
<azonenberg>
Insufficient time and resources to test :
<d1b2>
<Darius> wonders what cmake is smoking
<d1b2>
<Darius> -- Could NOT find Boost (missing: program_options) (found suitable version "1.71.0", minimum required is "1.33.0")
<d1b2>
<Darius> 1.71.0 > 1.33.0 😕
<d1b2>
<Darius> also this code is a bit funky:
<d1b2>
<Darius> if( &envelope == NULL )
<azonenberg>
ok, that's done... next on the agenda is WAV import which will hopefully be fairly quick
<GenTooMan>
That's what they always says...
<xzcvczx>
what about mp3 import mp3 is now patent free so surely its better than wav being nice and compressed and all
<azonenberg>
lol
<azonenberg>
you can convert mp3 to wav if you really want
<azonenberg>
but the intended use case here is cheap sound card "oscilloscopes"
<xzcvczx>
i was trying to use audacity before you gave me the wonders of glscopeclient so head to deal with it as wavs there
<xzcvczx>
s/head/had/
<d1b2>
<Darius> hmm I am having some trouble with ffts
<d1b2>
<Darius> had to modify Makefile.am to add the include dir but now it's complaining about double_t
<xzcvczx>
darius: sse3?
<xzcvczx>
oh ok
<xzcvczx>
nvm then
<d1b2>
<Darius> ffts_trig.c:884:11: error: unknown type name 'double_t'; did you mean 'double'? const double_t *FFTS_RESTRICT hs;
<d1b2>
<Darius> changing to ffts_double_t worked..
<xzcvczx>
you just gonna def out all the cl stuff?
<azonenberg>
You should be able to just detect no opencl at cmake time
<azonenberg>
it's already optional
<azonenberg>
the problem is that the cl detection assumes having opencl at all implies having C++ bindings for it
<azonenberg>
so we need to fix that
<xzcvczx>
yeah i will try and work out what it is thats demanding avx today
<xzcvczx>
at buildtime
<d1b2>
<Darius> oh hmm, I thought it needed opencl so I gave up 🙂
<azonenberg>
darius: no, the opencl SDK is detected at build time and only enabled at run time if you have a compatible GPU. AVX2/AVX512 support is required in the compiler until we add ifdefs for non-x86, but again only enabled at run time if supported
<d1b2>
<Darius> OK
<azonenberg>
the main hard system requirement is opengl 4.2 plus compute shaders
<azonenberg>
which on a non-braindead OS means "any GPU made in the past 10ish years"
<azonenberg>
but apple is apple :p
<xzcvczx>
intel igpu back to ivy bridge
<d1b2>
<Darius> how do I disable opencl?
<xzcvczx>
azonenberg: so windows is braindead OS? :P
<azonenberg>
xzcvczx: windows supports opengl 4 on almost all compatible hardware
<azonenberg>
the one difference between windows and linux support is really old intel igpus, i think windows only supports gl4 in intel drivers starting around haswell or broadwell?
<GenTooMan>
I thought it support OGL4 through an emulation layer.
<xzcvczx>
but i *think* a few of the older intel igpus only get compute shaders under mesa on linux/bsd
<azonenberg>
Correct
<azonenberg>
that is the only different i'm aware of
<azonenberg>
any nvidia or amd card that does gl4 on linux will work just fine on windows
<xzcvczx>
then again windows must be braindead seeing as its not even posix
<azonenberg>
well thats a different issue :p
<xzcvczx>
i am rather surprised a lot of hte userland bsd code has become a whole lot cooler than its linux equivalent, i would have figured it would be the opposite
<xzcvczx>
like cmp is soooo much better on bsd...... hex ftw f*** octal and decimal
<azonenberg>
i mean i'm used to linux file modes at this point, it barely even registers that the numbers are actually octal
<d1b2>
<Darius> BSD has SIGINFO, so nice 🙂
<xzcvczx>
azonenberg: nah cmp compares files, gives differences in octal and offsets in decimal
<xzcvczx>
with a 1 index
<azonenberg>
wuut
<azonenberg>
i've never used it
<xzcvczx>
bsd offers an option to 0 indexed hex everywhere
<xzcvczx>
on linux you need a damn ugly awk thing to fix it
<d1b2>
<Darius> how do I tell cmake to not use OpenCL?
<d1b2>
<Darius> or should I just hack up CMakeLists.txt to not look for it?
<azonenberg>
darius: There's currently no way to opt out at compile time
<azonenberg>
if it sees it, it will try to use it
<d1b2>
<Darius> OK
<azonenberg>
The bug is that FindPackage(OpenCL) doesnt understand we need C++ bindings
<azonenberg>
comment out that line and it should avoid trying to use it
<d1b2>
<Darius> OK I just hacked it out for now
<azonenberg>
Let me file a ticket for that so we dont forget
<xzcvczx>
maybe just do a sanity check for CL2.hpp or whatever it is
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #341: FindPackage(OpenCL) reports found even if no C++ bindings installed - https://git.io/J3A6r
<azonenberg>
I tagged that as v0.2 for now, it's not critical for v0.1
<azonenberg>
but again, feel free to work on it sooner
<xzcvczx>
i am still surprised it ran on bsd
<xzcvczx>
(on this machine)
<azonenberg>
the version milestones are really for a) me to figure out how close we are to being able to release something and b) so people interested in helping with the release can focus efforts on stuff blocking it
<azonenberg>
nothing stops you from working on untagged or later-version tickets
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/J3xl2
<_whitenotifier-3>
[scopehal-apps] azonenberg f76ec02 - Refactored import code so common code was in a function instead of replicated. Added WAV import support.
<bvernoux>
the aim is to add nothing and it shall search in current path of where the exe is started correct ?
<bvernoux>
example when I build glscopeclient I have a new dir
<bvernoux>
glscopeclient_build_release
<bvernoux>
I copy in it glscopeclient.exe with dll ...
<azonenberg>
No
<azonenberg>
It will search in the directory you compiled it
<azonenberg>
the source directory
<bvernoux>
and the directories icons, gradients, masks, shaders, styles
<azonenberg>
you dont have to copy anything
<azonenberg>
as long as you don't move the source code it will work
<bvernoux>
I simulate a root dir with glscopeclient.exe and dependencies
<azonenberg>
Longer term the windows packaging will include an installer that sets a registry key to point to the install dir
<azonenberg>
so it can find the data under program files
<azonenberg>
it will probably also look under %appdata%/glscopeclient or similar
<bvernoux>
the aim is to build a directory with exe and files like a PortableApp
<bvernoux>
without any path dependencies
<bvernoux>
I think it is better to avoid such RegEdit cheat
<bvernoux>
and think about current dir for install
<azonenberg>
The directory of the executable is not the same as the current working directory
<bvernoux>
like that it can be like a PortabeApps and can be also installed in Program Files ....
<bvernoux>
for me it is
<azonenberg>
yeah but you cant assume that
<bvernoux>
why ?
<azonenberg>
But we can have it check the executable dir on windows. On POSIX unless you go in /opt the data is rarely near the binaries
<bvernoux>
yes but posix is not standard
<bvernoux>
MACOS work like that too
<bvernoux>
only Linux want cheat everywhere ;)
<bvernoux>
opt or other path ... which i clearly do not like as when you want to remove an app you have files which will be never deleted
<azonenberg>
ISO and IEEE would disagree with you re posix not being standard :p
<bvernoux>
in case of all in same dir you remove the dir and all is removed you do not have some parts somewhere in System ...
<azonenberg>
The only things i've found that install stuff under opt are proprietary software that doesn't integrate with distribution package managers
<azonenberg>
you're not supposed to just randomly delete files, you're supposed to uninstall the package
<d1b2>
<zyp> that can be the same thing 🙂
<bvernoux>
I'm ok with custom install like that
<azonenberg>
Distros will not accept that in their repositories
<azonenberg>
They expect you to install things in the standard locations
<bvernoux>
but I think we shall support by default "PortableApp" current dir search of dir/files
<bvernoux>
which can work on Linux too
<azonenberg>
If you want to do that on windows, sure. you can pull the code from src/glscopeclient/main.cpp a few commits back that finds the binary dir
<bvernoux>
if you unarchive all in a dir as you want to check a new version without replacing the stable ones installed in opt ...
<d1b2>
<zyp> I'm a fan of macos' app bundles -- the whole thing comes as a bundle that you can run as is or «install» by copying it to /Applications
<d1b2>
<zyp> and uninstalling is then a matter of deleting the bundle from /Applications
<bvernoux>
yes like zyp say it is the point to keep that simple for any OS ;)
<bvernoux>
archive with everything you extract and it run from the dir without install
<d1b2>
<zyp> I disagree there
<bvernoux>
like it is natively done on MacOS
<bvernoux>
and have option to do the "crappy" posix install in opt lib .... ;)
<d1b2>
<zyp> while I prefer the macos way, that's only suitable on macos
<azonenberg>
anyway, it doesnt run on osx
<azonenberg>
so let's ignore osx and focus on getting windows and linux packaging working soonish :p
<azonenberg>
My top priority is a working debian package that installs to standard distro locations
<azonenberg>
second priority is a windows install exe that sticks it in program files
<bvernoux>
yes here the idea is just to support basic current dir execution with dependencies (dir) in same place as exe
<azonenberg>
third is packaging for other distros like arch and redhat based
<d1b2>
<zyp> that sounds reasonable to me
<azonenberg>
as a minimum debian and windows packaging are on my v0.1 requirements list
<bvernoux>
you can check other project like sdrpp
<bvernoux>
all is done like that
<bvernoux>
just an archive you extract and it runs from dir without install by default
<bvernoux>
and it works on MacOS, Windows and Linux
<bvernoux>
you can easily test and package like that and huge advantage is you can have different version at same time
<azonenberg>
That's why the source code directory is the first search location
<azonenberg>
That's the problem, scopehal and glscopeclient are permissively licensed to allow interop with commercial tooling
<azonenberg>
so any GPL is out of the question
<azonenberg>
LGPL is OK as long as dynamically linked
<azonenberg>
FFTS was the only suitably licensed fft lib i was able to find. I may have to write one
<azonenberg>
and/or do a major updating of ffts for AVX and ARM64
<ericonr>
ah, this is what I get for skimming
<ericonr>
The FFTW package was developed at MIT by Matteo Frigo and Steven G. Johnson.
<ericonr>
I saw MIT and thought it was the license
<ericonr>
> We could instead have released FFTW under the LGPL, or even disallowed non-Free usage. Suffice it to say, however, that MIT owns the copyright to FFTW and they only let us GPL it because we convinced them that it would neither affect their licensing revenue nor irritate existing licensees.
<azonenberg>
it was the least bad non-GPL FFT library i could find
<azonenberg>
And it's generally abandonware
<azonenberg>
it still works fine, but has not been updated for modern intel CPUs with AVX/AVX2/AVX512 instructions so it could probably be made massively faster
<ericonr>
an avx512 backend would seem overkill to me
<ericonr>
avx2 would probably be worth it, though
<azonenberg>
I'd want to do some measurements
<azonenberg>
honestly, i think for multimillion point FFTs avx512 would really shine
<azonenberg>
that's the kind of big number crunching it was designed fore
<azonenberg>
for*
<ericonr>
oh, they added avx512 to rocketlake unconditionally
<ericonr>
I was considering it overkill because few CPUs would even have it; given that it's a tad more widely available now, it makes a lot of sense :)
<azonenberg>
My main workstation is xeon 6144s
<azonenberg>
(dual socket)
<azonenberg>
and i work with huge data all the time. if it can save me time i'll do it :p
<ericonr>
azonenberg: I think the only remaining issue with avx512 is that it downclocks the rest of the CPU, so if you're doing other things simultaneously, it can suck a bit :/
<azonenberg>
ericonr: Only if you do a lot of avx512 at a time. but even avx2 and other stuff does that, just not as much
<azonenberg>
there's actually some fairly complex power/thermal management algorithms in play
<bvernoux>
azonenberg, what is the comande line for Pico ?
<bvernoux>
I see my build/patch of ps6000d is working on my Pico3406DMSO
<azonenberg>
on the glscopeclient side? nickname:pico:lan:localhost:5025
<azonenberg>
assuming your bridge is on the same host as you're connecting from
<bvernoux>
thanks i have found it
<bvernoux>
i was confused as 127.0.0.1 does not work
<bvernoux>
and shall be replaced by localhost
<bvernoux>
but it work now with localhost
<bvernoux>
it works ;)
<bvernoux>
working at about 10WFM/s ;)
<bvernoux>
even 20
<bvernoux>
when I zoom as the issue is definitely on number of points displayed with my GFX card
<bvernoux>
with 2Chan 1Mpts it runs at >20WFM/s
<bvernoux>
but the limiting factor is clearly my GFX card I need to zoom to speed up WFM ...
<azonenberg>
Yeah. I'm going to be working on a less pretty but faster shader soon
<azonenberg>
that you can swap out
<azonenberg>
or possibly different settings on this one
<azonenberg>
but i want to have some speed/render quality tradeoffs
<bvernoux>
ha nice
<bvernoux>
because her I can reach >40WFM/s if I zoom out
<bvernoux>
It is first time I can check that realtime aspect in fact
<bvernoux>
as with my Rigol and 1WFM/s it is hard to see such limit ;)
<bvernoux>
Anyway it is very good Pico works congratulations !!
<bvernoux>
noopwafel, will be interesting to merge it I have not tested the Linux side but it shall always build
<bvernoux>
a nice things will be to change memory size ;)
<bvernoux>
on Pico it shall be quite fast with 100k especially because my GFX card suxx ;)
<bvernoux>
also why not rename dir ps6000d to something like pico-bridge ?
<azonenberg>
bvernoux: That's planned
<azonenberg>
originally i was going to have a common library and a server for each device family
<bvernoux>
yes it is just GUI/option I see it is already managed in the pico-bridge
<bvernoux>
yes a good refactor could be done to manage Pico family with switch case when required
<bvernoux>
and use common API
<bvernoux>
it is a shame Pico have not standardized that a bit more for common function ...
<bvernoux>
they could have done basic features with HAL with same API for all Pico
<azonenberg>
Yes that would have been a lot nicer
<azonenberg>
i'm going to push them to do that in the future
<azonenberg>
i've already had some chats with their engineers about various potential improvements
<bvernoux>
ha great
<bvernoux>
and also doing an open source driver with libusb on their side to avoid blob ;)
<bvernoux>
I have asked that to SignalHound too ;)
<bvernoux>
I do not know what they want to protect with their closed source API ...
<azonenberg>
long term i would like if pico used libscopehal as their official API and provided a libscopehal -> libusb driver
<azonenberg>
but we don't yet support all of their features so that isnt possible yet
<bvernoux>
yes but it will be nice
<bvernoux>
glscopeclient even in actual state is already 1000x better than Picoscope 6 GUI/App ;)
<bvernoux>
even if it miss some interesting advanced triggers ;)
<azonenberg>
Still need to finish MSO support and a few other things to really be where i want it
<azonenberg>
and yes, all of the nice triggers
<bvernoux>
yes MSO is clearly a must have for something fully usable
<azonenberg>
what i really want is protocol triggers
<azonenberg>
for things like 100baseTX
<bvernoux>
ha yes it will be amazing
<azonenberg>
They dont have that
<azonenberg>
but i think the hardware is capable
<bvernoux>
or even on UART/SPI...
<azonenberg>
would need new fpga firmware
<bvernoux>
ha yes to do that in HW (FPGA) will be very nice
<noopwafel>
yeah, it would be dreamy to get some more hw triggers
<noopwafel>
but just running them in streaming mode might be better than nothing
<azonenberg>
Yeah the other thing i want to do with the high update rates on the picoscope is make something along the lines of lecroy wavescan but probably better :p
<azonenberg>
to start one thing i would find useful is filtering for waveforms that meet a certain criteria in a decode
<azonenberg>
so streaming tens to hundreds of WFM/s and only displaying/saving in history ones with (say) a bad CRC
<azonenberg>
I also want to add a software post-trigger feature
<azonenberg>
where you can capture waveforms with a simple edge trigger
<azonenberg>
but then it will time-shift them based on a decode
<azonenberg>
so that a given protocol event happens the same time in each waveform
<azonenberg>
so for things like 8b10b that you cant trigger on natively without the scope having a serdes trigger
<azonenberg>
being able to have all the frames start at a given cursor position would be nice