azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<wizardyesterday> azonenberg, Oh nice!
<wizardyesterday> My wife comes back the week after next.
<wizardyesterday> azonenberg, I noticed that the CMSIS filters take about 57% of the time to execute as mine do.. using the Linux time command
<wizardyesterday> I'll make more accurate measurements though... a cycle-accurate simulator is the best way to measure things.
<_whitenotifier-7> [scopehal] TiltMeSenpai opened pull request #656: Fix missing semicolon - https://github.com/glscopeclient/scopehal/pull/656
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 276 seconds]
Degi_ is now known as Degi
<_whitenotifier-7> [scopehal] azonenberg closed pull request #656: Fix missing semicolon - https://github.com/glscopeclient/scopehal/pull/656
<_whitenotifier-7> [scopehal] azonenberg pushed 3 commits to master [+0/-0/±2] https://github.com/glscopeclient/scopehal/compare/895c05aa4889...57baf3e11ab8
<_whitenotifier-7> [scopehal] TiltMeSenpai 294c418 - Fix missing semicolon
<_whitenotifier-7> [scopehal] TiltMeSenpai 9d37cb1 - Merge branch 'glscopeclient:master' into master
<_whitenotifier-7> [scopehal] azonenberg 57baf3e - Merge pull request #656 from TiltMeSenpai/master Fix missing semicolon
<azonenberg> wizardyesterday: yeah at this point i dont care about performance (and i doubt CMSIS has a PLL lol)
<azonenberg> i want someone who understands the math to help us get the core algorithms down
<azonenberg> i can optimize later
<wizardyesterday> azonenberg, Let me check
<wizardyesterday> Hmm LMS and NLMS, the usual FIR decimators and polyphase interpolators
<wizardyesterday> lattice structures so that you have lower coefficient sensitivity.
<wizardyesterday> Their C code looks almost like translated assembly language. That's good for speed though (loop unrolling 32-bit operations, etc)
<wizardyesterday> azonenberg, Anyway, you're welcome to look at my code.
<wizardyesterday> I do use circular buffers.
<wizardyesterday> Now you got me looking at the ARM code
<wizardyesterday> error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://github.com/glscopeclient/scopehal/info/refs
<azonenberg> My straight C++ code tends to be simple, readable, and portable
<wizardyesterday> ^ I hate https
<wizardyesterday> Oh good
<wizardyesterday> I tried cloning on the BeagleBone Black
<wizardyesterday> I'll clone it when I get my phone.. zip it and scp it to this system.
<azonenberg> Usually when i start doing crazy optimizations like that, i do it with platform specific SIMD intrinsics
<azonenberg> while keeping the portable implementation for comparison and testing
<wizardyesterday> azonenberg, I think that you'll find that my code is readable.
<azonenberg> you'll notice that in e.g. the FIRFilter class
<wizardyesterday> I'm interested to see how you did your FIR filter implementation.
<wizardyesterday> IIR isn't much different. You'll have a nonrecursive (FIR) portion and a recursive (IIR) portion.
<wizardyesterday> It's cool that you're just doing an inner (dot) product between coefficient vectors and state memory.
<wizardyesterday> azonenberg, Are you using floating point math or integer (signed fractional) math?
<wizardyesterday> I have both types.
<azonenberg> wizardyesterday: all waveforms in libscopehal are fp32
<azonenberg> typically y axis is volts, but in some cases it can be other units too
<azonenberg> there's a unit attribute associated with the data stream that you can check if needed
<azonenberg> X axis coordinates are 64-bit integers, the typical base unit for time domain waveforms is femtoseconds
<wizardyesterday> azonenberg, Okay cool.
<wizardyesterday> I should sleep.
<wizardyesterday> azonenberg, Good night.
<wizardyesterday> I'll so more LMS filter stuff tomorrow.
wizardyesterday has left #scopehal [#scopehal]
<_whitenotifier-7> [scopehal] bvernoux synchronize pull request #481: Add support of PicoScope 3000 series + MSO (16chan option) - https://github.com/glscopeclient/scopehal/pull/481
<_whitenotifier-7> [scopehal-pico-bridge] bvernoux commented on pull request #21: Add preliminary support for Pico 6000A/B/C/D - https://github.com/glscopeclient/scopehal-pico-bridge/pull/21#issuecomment-1193275220
<bvernoux1> What should be clearly checked is https://github.com/AlexandreRouma/dsp to be integrated in glscopeclient
<bvernoux1> It is the best DSP on Internet and OpenSource
<bvernoux1> It is used for SDR in SDRPlusPlus https://github.com/AlexandreRouma/SDRPlusPlus
<bvernoux1> Using the best hints for fast filter/decimations and contains also PLL ...
<_whitenotifier-7> [scopehal] bvernoux opened issue #657: Use AlexandreRouma dsp - https://github.com/glscopeclient/scopehal/issues/657
<_whitenotifier-7> [scopehal] bvernoux edited issue #657: Use/Integrate AlexandreRouma dsp - https://github.com/glscopeclient/scopehal/issues/657
bvernoux1 is now known as bvernoux
<azonenberg> bvernoux: i don't need "a PLL" I need specifically a CDR PLL with single pole lowpass response at a configurable fraction of the symbol rate
<azonenberg> as well as ones with higher order responses as specified in PCIe etc standards
<azonenberg> bvernoux: also reviewing your PR for the pico bridge
<azonenberg> please fix bracing style
<azonenberg> curly braces always go on their own line
<azonenberg> also "else" clause goes on its own line, not the same as the ending }
<azonenberg> ready to merge once that's fixed
<_whitenotifier-7> [scopehal-pico-bridge] TiltMeSenpai edited pull request #21: Add preliminary support for Pico 6000A/B/C/D - https://github.com/glscopeclient/scopehal-pico-bridge/pull/21
<_whitenotifier-7> [scopehal-pico-bridge] TiltMeSenpai commented on pull request #21: Add preliminary support for Pico 6000A/B/C/D - https://github.com/glscopeclient/scopehal-pico-bridge/pull/21#issuecomment-1193341077
<_whitenotifier-7> [scopehal-pico-bridge] TiltMeSenpai edited pull request #21: Add preliminary support for Pico 6000A/B/C/D - https://github.com/glscopeclient/scopehal-pico-bridge/pull/21
<_whitenotifier-7> [scopehal-pico-bridge] TiltMeSenpai synchronize pull request #21: Add preliminary support for Pico 6000A/B/C/D - https://github.com/glscopeclient/scopehal-pico-bridge/pull/21
<_whitenotifier-7> [scopehal-pico-bridge] TiltMeSenpai synchronize pull request #21: Add preliminary support for Pico 6000A/B/C/D - https://github.com/glscopeclient/scopehal-pico-bridge/pull/21
<bvernoux> azonenberg, I have fixed the bracing styles if you see other part where there is thanks to provide me the files
<bvernoux> azonenberg, do you have some clang-format or other similar tool with rules to apply ?
<bvernoux> That will simplify a lot things
<bvernoux> To be sure all is perfect
<bvernoux> I was using astyle also in my project
<bvernoux> and provided clear rules to clarify everything about code format
<bvernoux> It is much more clear that the one for glscopeclient
<bvernoux> I have simply used the most worldwide standard based on linux code format
<bvernoux> to do not reinvent the wheel again with something not standard
<bvernoux> linux style does not match glscopeclient especially towards the braces you want
<bvernoux> It seems your required code style is based on allman to be clarified see http://astyle.sourceforge.net/astyle.html#_default_brace_style
<bvernoux> it shall be equal to --style=bsd if your prefer
<bvernoux> to be clarified
<bvernoux> AStyle.exe -t --style=bsd --lineend=linux my_c_file.c
<bvernoux> seem to do the trick
<bvernoux> anyway it is a bit strange for switch case
<bvernoux> Could you check ? as the code before I change anything was already not respecting the styles for brackets ...
<_whitenotifier-7> [scopehal-pico-bridge] bvernoux synchronize pull request #19: Support Picoscope3000 series+MSO (missing AWG) - https://github.com/glscopeclient/scopehal-pico-bridge/pull/19
<bvernoux> I have pushed the fixes for curly braces... see https://github.com/glscopeclient/scopehal-pico-bridge/pull/19
<bvernoux> It seems you will probably prefer
<bvernoux> astyle -t --indent-switches --style=bsd --lineend=linux
<bvernoux> to be confirmed
<bvernoux> I think it a a good rules toward what you want with braces ...
<_whitenotifier-7> [scopehal-pico-bridge] bvernoux synchronize pull request #19: Support Picoscope3000 series+MSO (missing AWG) - https://github.com/glscopeclient/scopehal-pico-bridge/pull/19
<_whitenotifier-7> [scopehal] bvernoux synchronize pull request #481: Add support of PicoScope 3000 series + MSO (16chan option) - https://github.com/glscopeclient/scopehal/pull/481
<bvernoux> I have "fixed" all curly braces on the code I have modified using astyle -t --indent-switches --style=bsd --lineend=linux
<bvernoux> It seems it is what you want thanks to confirm
<bvernoux> Potentially you want to use -T (Indent using all tab characters, if possible) instead of -t (Indent using tabs for indentation, and spaces for continuation line alignment)
<bvernoux> @azonenberg, you clearly need to clarify the rules here
<bvernoux> especially if you want more and more PR to have something standard and clear for everyone
<_whitenotifier-7> [scopehal] bvernoux synchronize pull request #481: Add support of PicoScope 3000 series + MSO (16chan option) - https://github.com/glscopeclient/scopehal/pull/481
<_whitenotifier-7> [scopehal-pico-bridge] bvernoux synchronize pull request #19: Support Picoscope3000 series+MSO (missing AWG) - https://github.com/glscopeclient/scopehal-pico-bridge/pull/19
<azonenberg> bvernoux: ok i'll look shortly, was AFK
<azonenberg> My style is generally based on visual C++ / windows defaults
<azonenberg> allman bracing, one \t = one level of indentation
<bvernoux> @azonenberg, please check my proposal https://github.com/azonenberg/coding-policy/pull/1
<bvernoux> It will clarify everything
<bvernoux> It can be done automatically too in future
<bvernoux> to avoid to loose time with that ...
<azonenberg> bvernoux: ok yes the astyle rules look good. we can make small changes later
<_whitenotifier-7> [scopehal-pico-bridge] azonenberg pushed 9 commits to master [+2/-0/±17] https://github.com/glscopeclient/scopehal-pico-bridge/compare/a9844d302351...c9a5817cfb08
<_whitenotifier-7> [scopehal-pico-bridge] bvernoux bc20c7d - Support Picoscope3000 series(missing AWG) for test(do not build with MSYS2/Mingw64 need some fixes see also TODO PICO3000A)
<_whitenotifier-7> [scopehal-pico-bridge] bvernoux 2a064d8 - Better check of Picoscope 3000 series with MSO option
<_whitenotifier-7> [scopehal-pico-bridge] bvernoux dee6e72 - Fix MSYS2/Mingw64 error on max(triggerDelaySamples, 0L)
<_whitenotifier-7> [scopehal-pico-bridge] ... and 6 more commits.
<_whitenotifier-7> [scopehal-pico-bridge] azonenberg closed pull request #19: Support Picoscope3000 series+MSO (missing AWG) - https://github.com/glscopeclient/scopehal-pico-bridge/pull/19
<azonenberg> balrog, lain: ok so it seems like at this point there is significant interest in getting scopehal working on m1
<azonenberg> and glscopeclient
<azonenberg> it appears that the path forward is going to be:
<azonenberg> 1) Keep the existing OpenGL 3.x compositor for the time being, at least until gtk 4.x or whenever gtk/vulkan integration in stable linux distros is good enough
<azonenberg> 2) Migrate our OpenGL compute shader based renderer to Vulkan compute shader, drawing to an offscreen buffer, which then gets converted to an OpenGL texture for compositing
<azonenberg> 3) Migrate our OpenCL based accelerated filters to Vulkan compute shader
<azonenberg> 4) Migrate from clFFT to vkFFT. Look into replacing FFTS as well (if we can do *all* of our FFTs in vkFFT that would be awesome)
<azonenberg> 5) When on Apple, use MoltenVK to translate Vulkan calls to Metal
<azonenberg> 6) Add #ifdefs around all AVX optimizations so that we revert to the fallback C++ implementations on non-x86 platforms, we can look at adding NEON versions in the future if the situation calls for it
<azonenberg> Does that sound correct?
<azonenberg> this is probably the first issue to address
<azonenberg> such that we can even compile the code on non-x86
<azonenberg> i know several people have played with this privately but i have not seen a PR for it yet
<_whitenotifier-7> [scopehal] azonenberg opened issue #658: Convert OpenCL accelerated filters to Vulkan compute shaders - https://github.com/glscopeclient/scopehal/issues/658
<_whitenotifier-7> [scopehal] azonenberg labeled issue #658: Convert OpenCL accelerated filters to Vulkan compute shaders - https://github.com/glscopeclient/scopehal/issues/658
<_whitenotifier-7> [scopehal] azonenberg labeled issue #658: Convert OpenCL accelerated filters to Vulkan compute shaders - https://github.com/glscopeclient/scopehal/issues/658
<_whitenotifier-7> [scopehal] azonenberg labeled issue #659: Remove clFFT and replace with vkFFT - https://github.com/glscopeclient/scopehal/issues/659
<_whitenotifier-7> [scopehal] azonenberg labeled issue #659: Remove clFFT and replace with vkFFT - https://github.com/glscopeclient/scopehal/issues/659
<_whitenotifier-7> [scopehal] azonenberg opened issue #659: Remove clFFT and replace with vkFFT - https://github.com/glscopeclient/scopehal/issues/659
<_whitenotifier-7> [scopehal] azonenberg opened issue #660: Look into replacing FFTS calls with vkFFT - https://github.com/glscopeclient/scopehal/issues/660
<_whitenotifier-7> [scopehal-apps] azonenberg edited issue #344: Look into alternate (OpenCL based?) compute shader equivalents so we can support OSX - https://github.com/glscopeclient/scopehal-apps/issues/344
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #344: Look into alternate (OpenCL based?) compute shader equivalents so we can support OSX - https://github.com/glscopeclient/scopehal-apps/issues/344
<_whitenotifier-7> [scopehal-apps] azonenberg edited issue #344: Replace compute shader based renderer with Vulkan compute - https://github.com/glscopeclient/scopehal-apps/issues/344
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #344: Replace compute shader based renderer with Vulkan compute - https://github.com/glscopeclient/scopehal-apps/issues/344#issuecomment-1193415549
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #457: Create a Vulkan context at app initialization time - https://github.com/glscopeclient/scopehal-apps/issues/457
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #457: Create a Vulkan context at app initialization time - https://github.com/glscopeclient/scopehal-apps/issues/457
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #457: Create a Vulkan context at app initialization time - https://github.com/glscopeclient/scopehal-apps/issues/457
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #458: Add preferences for which Vulkan device to use - https://github.com/glscopeclient/scopehal-apps/issues/458
<_whitenotifier-7> [scopehal-apps] azonenberg labeled issue #458: Add preferences for which Vulkan device to use - https://github.com/glscopeclient/scopehal-apps/issues/458
<_whitenotifier-7> [scopehal-apps] azonenberg opened issue #458: Add preferences for which Vulkan device to use - https://github.com/glscopeclient/scopehal-apps/issues/458
<_whitenotifier-7> [scopehal-apps] azonenberg commented on issue #458: Add preferences for which Vulkan device to use - https://github.com/glscopeclient/scopehal-apps/issues/458#issuecomment-1193417956