<azonenberg>
P-525 silicone arrived. Mixed up a batch, now curing in the test mold
<azonenberg>
It's significantly more viscous and actually degasses slightly easier as the bubbles are larger
<azonenberg>
it injection molds fine under syringe pressure but sucking it up from the jar with a pipette is a bit slow. Might switch to a plastic spoon or something
<azonenberg>
Got good results with 5 grams of total silicone... 2.5 grams each of base and catalyst. It filled the mold nicely with a comfortable amount left over
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #scopehal
<d1b2>
<theorbtwo> Oooh, just saw the scopehal/glscopeclient hackathon thing. When is it starting? It's already been the 19th here for almost 4 hours!
<azonenberg>
Whenever you wanna start working on stuff :p
<azonenberg>
Got a specific feature/ticket you wanted to work on?
<azonenberg>
It's still the 18th here in PST but that won't stop me from coding on stuff
<azonenberg>
theorbtwo: I can get you test waveforms of lots of stuff if you don't (yet) have a supported scope
<d1b2>
<theorbtwo> Still thinking on it. I've not actually used it yet. I might have to start by struggling with build systems... or am I blind and the "actions" thing will give me artifacts? I don't see them.
<azonenberg>
I would start by getting it to build locally. I think we have some build artifacts from the CI builds but if you're going to be doing any sort of development you need to be able to compile locally
<d1b2>
<theorbtwo> ...I am blind, yes.
<azonenberg>
Section 3.4 of the manual is a good starting point to get it building on your system
<d1b2>
<theorbtwo> So far, fwiw, my thoughts are that it would be nice to have a bit on the manual for quick getting started with a few different scopes, preferably with both usb and ethernet. A packaged-up windows binary. A way of integrating / feeding wireshark or ... blast, open source logic analyzer that I forget the name of, for when you want to go extreme full stack. Heck, while I'm thinking of it, a way of taking your scope session and compiling it to a
<d1b2>
library, or fpga, or something like that ... OK, that last one might be too crazy.
<azonenberg>
We already have a way of streaming to wireshark for all Ethernet protocol decodes
<azonenberg>
USB is i believe the only other protocol that both glscopeclient and wireshark have decodes for
<azonenberg>
there is an open ticket for adding the bridge
<d1b2>
<theorbtwo> Ah, cool.
<azonenberg>
The tl;dr is that it's just pcap export
<azonenberg>
except you mkfifo a pipe and export to that
<azonenberg>
then have wireshark stream from it
<d1b2>
<theorbtwo> I figured it was something like that.
<azonenberg>
so basically it's something the user does
<azonenberg>
from scopehal's perspective it's pcap export
<d1b2>
<theorbtwo> Is mostly a matter of documenting that, and showing it off a bit, maybe.
<azonenberg>
Makes sense. But I think before we do that, it's more important to have complete documentation of all the decode blocks used in the chain
<d1b2>
<theorbtwo> Fair.
<azonenberg>
i believe right now 9 of the 90 filter classes actually have complete documentation
<azonenberg>
I would *love* if you wanted to work on that. I can provide you with test waveforms for using most of them on
<azonenberg>
so you can fool around, get an idea for how they work
<azonenberg>
there should be enough templates in the documentation that you can easily write docs for additional filters
<azonenberg>
honestly that is one of my highest priorities for an initial release
<azonenberg>
Have all major features documented
<azonenberg>
the core of the UI is decently well documented now, the filters are not
<d1b2>
<theorbtwo> Hmm. Tex. I keep thinking I ought to learn some of that. No time like the present, I suppose.
<azonenberg>
The syntax used in the filter documentation is pretty simple. you can mostly cut and paste from other filters to figure out the stuff we're using
<d1b2>
<theorbtwo> I figured, though I suspect I will want to add some other bits that aren't templated yet, and maybe another feature or two.
<azonenberg>
anyway first step is to get it building and running locally
<azonenberg>
you can use the demo driver to start
<d1b2>
<theorbtwo> It would be great to replace the hand-curated pngs in the docs with a session file + a wav file and build the images.
<azonenberg>
So the challenge there is composition
<azonenberg>
cropping, do you show just the input channel or several for context
<d1b2>
<theorbtwo> Yep, I'm working on it while I read the manual and chat here.
<azonenberg>
does the timeline or y axis need to be visible to understand what the filter does, or should it be removed to focus attention on the decode
<azonenberg>
I think hand cropped screenshots is the better choice for now
<azonenberg>
If we do major refactoring of a single decode that changes the appearance drastically, it's not hard to grab a new screenshot
<d1b2>
<theorbtwo> If all of that isn't specifiable in a session file, it probably should be anyway, but yeah, not a good thing to do right now .
<azonenberg>
and massive changes to the UI as a whole aren't super likely
<azonenberg>
also you wouldnt need a wav
<azonenberg>
a saved session can include waveform data
<d1b2>
<theorbtwo> Oh, good.
<azonenberg>
the foo.scopesession is just yaml metadata but there's an accompanying foo_data directory with waveforms and another yaml metadata file for each one
<azonenberg>
you can choose to export a light session with only the UI/instrument config, or include the data
<azonenberg>
depending on what you want to do with it later
<azonenberg>
you can also decide to only import data, ui settings, or both
<azonenberg>
a scopesession does include info about filter config, window size, position and zoom of each waveform group, etc
<azonenberg>
But it doesn't include the kind of crop info you'd need for autogenerating screenshots
<azonenberg>
as far as what portion of the app window is of interest for the documentation
<d1b2>
<theorbtwo> I wasn't thinking of crop so much as hiding UI elements.
<azonenberg>
Oh. Not as of now. Generally these are critical things that need to be there to interact with the scope
<azonenberg>
like, if you remove the Y axis you have no way to change gain/offset
<azonenberg>
as that is simultaneously the display and the control
<d1b2>
<theorbtwo> Yeah, it's the sort of function that would be useful in very limited circumstances ... like generating screenshots for documentation.
<d1b2>
<theorbtwo> ...but also full-stack tests of your UI.
<azonenberg>
I mean veeeery long term having scripted firefox-style pixel checking tests to find rendering regressions would be great
<azonenberg>
We're a long ways from being stable enough that we *need* such techniques to find bugs :p
<d1b2>
<theorbtwo> Not great tests, because validating them is a matter of "is the output of this pixel-identical to it was before", but it's better than nothing.
<azonenberg>
It's a regression testing tool, not more
<azonenberg>
you define X as "good" then change "good" as the UI evolves
<d1b2>
<theorbtwo> I love "...to prevent causality violations", BTW. It wouldn't do at all to accidentally destroy the universe with your oscilloscope.
<azonenberg>
lol
<d1b2>
<theorbtwo> Is there no "arbitrary arithmetic" filter? Are the various ethernet filters similar enough to each-other that they should have their own sub-tree of documentation, with a long section on what they have in common followed by a small section each on what they have different?
<azonenberg>
There is no "arbitrary arithmetic" filter, no. Right now i believe we have "subtract one waveform from another", "add scalar to a waveform", and "multiply one waveform by another"
<azonenberg>
an arbitrary math filter would be nice to have the trick would be making it fast. We might want to consider some sort of JIT
<azonenberg>
because the existing filters are all hand tuned AVX
<d1b2>
<theorbtwo> Yow.
<azonenberg>
i mean there's generic C++ versinos too
<azonenberg>
but the ones that are used most of the time are heavy AVX2 or AVX512 intrinsics
<d1b2>
<theorbtwo> I'm surprised there's not computation-on-GPU on the mix as well.
<azonenberg>
The AVX512 version of the FIR filter block for example is unrolled to do 64 samples per iteration
<azonenberg>
16 way SIMD * 4-way unrolling
<azonenberg>
And is about eight times faster than the generic C++ version with -O3
<azonenberg>
Pushing compute to GPU is on the long term roadmap. It always has been
<azonenberg>
There's just challenges around logistics especially marshaling data to and from the gpu and figuring out when it makes sense to do so
<azonenberg>
there are latency costs involved with jumping to the gpu
<azonenberg>
ideally i'd like to do some profiling at startup or even silently in the background as the app runs
<azonenberg>
and figure out if the throughput gains from going from AVX to GPU on a given filter exceed the latency costs to give a shorter end to end run time
<azonenberg>
The tradeoff will likely vary with each specific system, from one filter to another, and also depending on the number of samples in the waveform
<d1b2>
<theorbtwo> Hm. Other then the one you just mentioned, the other thing would be average of two signals. I've been thinking about gvif lately, which is a bidirectional signal over a single shielded twisted pair. One direction is common, the other direction is differential.
<azonenberg>
So you mean extracting the common mode from a differential signal, essentially?
<d1b2>
<theorbtwo> Yeah.
<azonenberg>
Yeah that sounds good. File a ticket and we'll figure out what to call it and how generic to make it
<azonenberg>
for example should it support arbitrarily many inputs or only two
<d1b2>
<theorbtwo> Potentially also useful for things like "do I need to put shielding on this twisted pair or not".
<azonenberg>
Yes i agree
<azonenberg>
It's good to have
<azonenberg>
I've just never needed it yet
<azonenberg>
Anyway, there are a few other issues around pushing compute to gpu
<azonenberg>
for example. right now all of the gpu compute is rendering related and is using opengl compute shaders
<d1b2>
<theorbtwo> Yeah, that was more a random thought then an actual feature request.
<azonenberg>
Which make it super easy to exchange data with opengl rendering
<azonenberg>
But on the flip side, it requires you have an active opengl context
<azonenberg>
So the question is, what happens if we want to use libscopehal headless? On a system that may or may not have a GPU or an X server?
<azonenberg>
Do we silently fall back to software compute? refuse to run at all?
<azonenberg>
create a GL window in the background and use it?
<azonenberg>
none of these are impossible or even ultra difficult problems, they've just never been top of the priority list
<d1b2>
<theorbtwo> Yeah, it becomes yet another arch to write a different impl of the same algo in to optimize it.
<azonenberg>
oh also, some filters just don't parallelize well. Like clock recovery
<azonenberg>
so that adds another wrinkle to the choice of whether to GPU or not to GPU
<azonenberg>
ideally we'd know what the latency and bandwidth of pushing data between the two is
<d1b2>
<theorbtwo> Especially since clock recovery will often be an early stage that you are going to be doing more on top of.
<azonenberg>
and perhaps dynamically decide which version of a filter to use based on where the input data is currently located and what filters are going to use our output
<azonenberg>
in order to minimize the number of copies
<azonenberg>
And well often preprocessing like de-embeds, subtracting halves of a diffpair, etc comes first
<azonenberg>
Those are very data heavy operations that would benefit from going to GPU. FFT is actually one of the first things that going to GPU would likely benefit from
<Bird|otherbox>
theorbtwo: learning LaTeX is definitely worthwhile, if nothing else for the quality of printed output you can produce with it -- it's not a substitute for a DTP tool, but it's still bloody awesome nonetheless
<azonenberg>
Which is used by channel emulation and de-embedding
<azonenberg>
anyway, so ideally i would like to be able to look at a complex filter graph
<azonenberg>
maybe run one or two iterations of it with different configs
<azonenberg>
and dynamically determine which to run on CPU and which on GPU
<azonenberg>
Considering that some blocks may only exist for one or the other
<azonenberg>
e.g. right now, protocol decodes that output complex samples ("ethernet frame segment") are rendered in Cairo in software
<azonenberg>
so you have less latency of that final decode happens on the CPU
<azonenberg>
while anything that outputs an analog or digital waveform is rendered in shaders
<azonenberg>
so it's most efficient if the last filter in the chain is on the GPU and we don't have to copy the data off
<azonenberg>
What happens if we have a filter whose output needs to go to both? how do we maintain coherency?
<azonenberg>
I think pushing compute to GPU is going to be a post v1.0 feature. It's going to be a massive game changer in terms of performance we can get, and it's going to be crucial for keeping up with the FPGA accelerated scopes I'm planning that will push out many Gbps of waveform
<azonenberg>
But it's also going to be a LOT of work
<azonenberg>
to do it right
<azonenberg>
I think OpenCL is probably also going to be the way to go as far as gpu compute is concerned
_whitelogger has joined #scopehal
<d1b2>
<theorbtwo> The win32 install instructions don't include installing git. Am tempted to suggest that the documentation for filters can be partly generated by the code. Finished writing the bottom part of "Clock Recovery (D-PHY HS Mode)".
<azonenberg>
And yes we definitely could script part of it. But again, unlikely to be worth the time given that once the initial build-out is done, we won't be doing any more mass documentation
<azonenberg>
the hope is that all new PRs with filters include a matching PR for the docs
<d1b2>
<theorbtwo> It will keep the documentation automatically up to date.
<azonenberg>
Up to a point, but there's still going to be things like detailed descriptions of filter theory of operation, what the inputs do, etc that has to be done by hand
<azonenberg>
and realistically once a filter is created, what are the odds the inputs will change significantly?
<azonenberg>
we might optimize or fix bugs in the decoding
<azonenberg>
but the interface is likely to remain stable
<d1b2>
<theorbtwo> Inputs, maybe not. Parameters seems more likely, or adding extra outputs.
<azonenberg>
i would not expect to add outputs after the fact either. Parameters i could see
<azonenberg>
but again if you add a new parameter you need to add a description as that's not going to be present in the source anyway
<azonenberg>
is adding one line of text to the docs really so hard in that case?
<azonenberg>
If anything i think what would make more sense is an automated checker that reports undocumented stuff
<azonenberg>
A few air bubbles, in large part due to me screwing up and pushing the syringe plunger down all the way and injecting some air at the very end of the run
<azonenberg>
(that huge bubble is right next to the sprue)
<azonenberg>
but easily solved with better technique and some practice. I have a procedure now that seems to work well for removing mold flash so that worked out nicely
<azonenberg>
The A25 rubber is much better feeling than the A8 for this purpose. I think i'm going to stick with it
<azonenberg>
theorbtwo: how's it going? I'm probably going to go to sleep since it's almost 23:00 Friday for me, then resume first thing in the morning
<azonenberg>
Which would be mid afternoon for you probably
<azonenberg>
pepijndevos: I have a preliminary implementation of write queueing in the Tek driver. Reads still are blocking
<azonenberg>
I'd like to do some wider scale testing of it and see how things perform
<azonenberg>
Would you be interested in experimenting with adding this write queueing API to the Rigol driver and seeing how it works?
<d1b2>
<theorbtwo> I wrote some docs, but have failed to compile either under linux or windows, so they are untested even as far as compiling.
<azonenberg>
Failed to compile the docs or everything?
<d1b2>
<theorbtwo> I'm taking a break at present, and will probably go to bed myself as soon as I deliver this load in-game. See you tomorrow.
<azonenberg>
What failed in particular? Did you follow the linux build procedure?
<azonenberg>
ah ok
<d1b2>
<theorbtwo> Linux problem isn't the build instructions, it's my damn system deciding it doesn't want to install texlive-fonts-extra for some reason.
<azonenberg>
Oh
<d1b2>
<theorbtwo> I hate build systems. And sysadmin. Don't mind me.
__dre has joined #scopehal
<azonenberg>
o/ __dre
<__dre>
Hello! This is @CyberpunkDre on twitter, setting up my IRC for tomorrow
<azonenberg>
Great
<azonenberg>
Just making sure everything is good before I go to bed
<azonenberg>
Also FYI theobrtwo has been doing a bit of documentation work too, so please coordinate with them to make sure you don't duplicate effort
<__dre>
Sounds good, will do! Still reading through the documentation which seems to be building daily?
<azonenberg>
I try to update the version in /temp/ fairly frequently
<azonenberg>
there isn't an official release yet, that's a dev draft
<__dre>
Yeah I saw, honestly the scope of the protocols is quite large. I am also interested in looking at Tektronix drivers, I have a model thats not on your supported list
<__dre>
TDS3054
<azonenberg>
And yes there are a lot of protocols. It should be easy to avoid colliding
<azonenberg>
just don't start alphabetically and pick the next undocumented one without making sure nobody else is working on it :p
<azonenberg>
As far as Tek stuff, great. I have a MSO64 on loan for the holidays and have been doing a lot of work on that driver
<azonenberg>
Unsure how much of the protocol is shared with older Tek models
<__dre>
Nice, hopefully shares enough to make it easy but should be fun part to add that seems unclaimed
<__dre>
I'll probably try focusing a bit more tomorrow when more people are on and I see what's being worked on though :P
<__dre>
Need to go get more stuff ready here, but glad I caught you on :) nite!
<azonenberg>
Yeah to my knowledge nobody else is working on Tek stuff. there is an open ticket for i believe DPO7000 series but nobody is currently working on that
<azonenberg>
there is a guy in another channel who has one and can probably arrange VPN access for dev
<azonenberg>
But definitely best to start with what you have in front of you
__dre has quit [Quit: Dre has quit the channel]
CyberDre has joined #scopehal
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
__dre has joined #scopehal
CyberDre has quit [Ping timeout: 260 seconds]
<azonenberg>
So i'm beginning the early stages of exploring OpenCL integration for filter computation
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+1/-0/±2] https://git.io/JLENh
<_whitenotifier>
[scopehal] azonenberg 66971d5 - Initial CMake OpenCL detection. Not used for anything yet.
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JLEAf
<_whitenotifier>
[scopehal-apps] azonenberg 59877f5 - Initial OpenCL CMake detection. Not used for anything yet.
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JLExF
<_whitenotifier>
[scopehal] azonenberg e83f65d - Set default paths if no OpenCL found
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLEpY
<_whitenotifier>
[scopehal] azonenberg 29b52e9 - Set OpenCL version 1.2 since nvidia doesn't do 2.0
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JLEpG
<_whitenotifier>
[scopehal-apps] azonenberg 20332e0 - Print OpenCL support present/absent message during startup
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLEhc
<_whitenotifier>
[scopehal] azonenberg 5db4455 - Fixed HAVE_OPENCL being defined even if value is 0
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLEhC
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+1/-0/±5] https://git.io/JLuOD
<_whitenotifier>
[scopehal] azonenberg cb4eb5b - Initial OpenCL kernel creation logic. Seems to work. Test kernel doesn't actually do anything yet and is never called.
<_whitenotifier>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLuOj
<_whitenotifier>
[scopehal-docs] azonenberg 4386dcd - Initial mention of OpenCL in documentation
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JLu3k
<_whitenotifier>
[scopehal-apps] azonenberg f513d99 - Copy kernels when building
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLuCU
<azonenberg>
lain, monochroma, marshallh: Very early stage OpenCL filter support is in. So far very manual buffer management
<azonenberg>
Long term plan is to do some smart stuff and only copy buffers when necessary
<azonenberg>
I'm also doing the final min/max reduction for display bounds calculation on the CPU still
<azonenberg>
anyway... test system is 2x Xeon 6144 + RTX 2080 Ti
<azonenberg>
800K points at 40 Gsps, 511 tap FIR LPF
<azonenberg>
Generic C++: 103 ms
<azonenberg>
AVX2: 17.1 ms
<azonenberg>
AVX512F: 11.1 ms
<azonenberg>
Unoptimized OpenCL (allocating a new buffer each call, etc): 8.1 ms
<azonenberg>
So basically this very naive implementation with blocking-everything and probably lots of unnecessary copying of data back and forth is about 30% faster than a Xeon with AVX512, and twice as fast as a less fancy CPU with only AVX2
<monochroma>
:D
<azonenberg>
Once *most* processing is done on the GPU i expect lots of the copy overhead to vanish
<azonenberg>
ideally i would copy raw 8 bit ADC samples to the GPU, use an opencl kernel to convert that to fp32, and keep everything i can in GPU memory
<azonenberg>
only copying to the CPU for filters that don't parallelize well like upper layer protocols
<azonenberg>
I think long term what i will need to do is have each waveform contain both gpu and cpu output buffers
<azonenberg>
and validity flags
<azonenberg>
then have each filter set a gpu or cpu flag
<azonenberg>
so if a gpu filter needs an input without a gpu output it will make a gpu buffer and copy it
<azonenberg>
and if a cpu filter needs an input that is only resident on the gpu it will copy off
<azonenberg>
etc
<tnt>
azonenberg: not sure about all your requirements, but you might also want to look into opengl compute if you ever need to actually display the data. Sharing CL/GL sucks (from experience) and there is also much better support for GL compute than CL.
<azonenberg>
tnt: meanwhiel i'm seeing the opposite
<azonenberg>
CL seems to be more widely supported than GL, especially since it can potentially run in generic software rather than only GPUs
<azonenberg>
right now rendering is all done in gl compute
<azonenberg>
but i'm actually thinking of moving everything to CL and then using GL for the final compositing step
<tnt>
lol ok, I guess the grass is always greener on the other side, I'm been doing CL/GL and thinking of moving everything to GL compute because of all the issues.
<tnt>
Nvidia still being at CL 1.1 with no update coming and no support ever coming for the embedded chips. AMD drivers fragmented in like 3 implementations, none of which I managed to get CL/GL buffer sharing working. My intel GPU support GL compute but no meaningful CL, etc ...
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLuwI
<_whitenotifier>
[scopehal] azonenberg 925addb - FIRFilter: optimizations to buffer handling
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLuws
<monochroma>
a friend who does a lot of compute stuff was saying the same that CL is basically dead, in that none of the big "3" are actually keeping up and supporting it
<azonenberg>
That's what i'm using
<tnt>
yeah sorry 1.2, but I meant not CL 2.0
<azonenberg>
Well, I'm still experimenting to see. also i got the CL version down to 5.9 ms with some very trivial changes to buffer handling
<tnt>
Well AMD and Intel supposedly support it, but my experience with their official supported stuff has been worse than with NVidia trying to bury it.
<tnt>
(which tbh sucks because I kind of like CL's model)
<azonenberg>
So that's now a 17.4x speedup vs the generic C++
<azonenberg>
And 1.8x vs reasonably well tuned, loop-unrolled AVX512F
<tnt>
Nice.
<tnt>
Not everyone has a RTX2080 Ti though :D
<azonenberg>
honestly i dont think i am close to saturating the gpu. i showed 5-10% utilization
<azonenberg>
i think most of the bottleneck was actually just pulling data off everything
<azonenberg>
i.e. limited by pcie latency
<azonenberg>
About to fire up nsight compute and see what it says
<d1b2>
<daveshah> I couldn't get that working for OpenCL when I tried
<d1b2>
<daveshah> but maybe I was doing something wrong
<azonenberg>
Well the good news is worst case if i have to copy off
<azonenberg>
if i move rendering all to opencl
<azonenberg>
the only thing i have to pull off is essentially one fullscreen framebuffer worth of pixels
<azonenberg>
then shove right back into a texture and do opengl compositing
<azonenberg>
So it wouldnt be THAT much overhead
<azonenberg>
also the massive advantage of opencl is it doesnt require a window on screen
<azonenberg>
Which means it can be used in headless compute
<azonenberg>
very important for some planned libscopehal use cases
<azonenberg>
That was actually the #1 reason i wanted to look at CL in the first place
<azonenberg>
getting compute shaders running headless is a pain
<ericonr>
there's also vulkan, OpenCL 3.0 was going to be about inter operation there
<ericonr>
no idea if anyone's implemented it
<azonenberg>
GTK on debian stable does not have vulkan integration
<azonenberg>
It might be worth considering in several more years
<azonenberg>
Also it looks like AMD has a decent looking opencl fft library
<azonenberg>
Now down to 4.4 ms on the same test
<azonenberg>
notbad.jpg
jevinskie[m] has joined #scopehal
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JLuyC
<_whitenotifier>
[scopehal] azonenberg cfe08ff - FIRFilter: now do first stage of reduction on the GPU too
<azonenberg>
and 4.1
<azonenberg>
Ok i think i'm done tweaking. it's already 25x faster than the generic C++ and 2.7x faster than the AVX512F
ericonr has quit [Ping timeout: 240 seconds]
ericonr has joined #scopehal
pd0wm has joined #scopehal
pd0wm has quit [Client Quit]
pd0wm has joined #scopehal
<azonenberg>
o/ pd0wm
<_whitenotifier>
[scopehal] azonenberg commented on issue #146: Support for HiSLIP - https://git.io/JLudJ
pd0wm has quit [Remote host closed the connection]
<_whitenotifier>
[scopehal] azonenberg edited issue #341: Split Siglent driver off from LeCroyOscilloscope as they've diverged too much - https://git.io/JksiG
<_whitenotifier>
[scopehal] azonenberg labeled issue #341: Split Siglent driver off from LeCroyOscilloscope as they've diverged too much - https://git.io/JksiG
<azonenberg>
So i'm thinking it would be nice to add CSV export (scopehal-apps:#77)
<azonenberg>
the question is how we want to handle the case of signals that aren't regularly sampled
<azonenberg>
like protocol decodes
<azonenberg>
Exporting a single channel to CSV is trivial
<azonenberg>
but exporting *everything* is hard
<azonenberg>
and it's not like i can just resample an ethernet frame to match whatever the base sample rate is :p
<azonenberg>
I suppose one option would be to loop over all selected channels
<azonenberg>
Emit a CSV line for every unique timestamp found in any channel
<azonenberg>
but only put a value in the cell on a change?
<azonenberg>
i don't want to repeat a sample for its entire duration because then you'd see repeated bytes in decodes
<azonenberg>
although stretching might work for analog samples
<azonenberg>
those might make more sense to resample?
__dre is now known as CyberDre
CyberDre has quit [Quit: Dre has quit the channel]
Cyber_Dre has joined #scopehal
<azonenberg>
o/ Cyber_Dre
<Cyber_Dre>
heyo, this is still CyberpunkDre, actually need to afk for a bit but will be back later
<azonenberg>
miek: My lecroy scopes have "qualified triggers"
<pd0wm>
Done!
<azonenberg>
So I can arm the trigger on either an edge on one channel, or a parallel digital pattern across some/all channels being present
<azonenberg>
Then I can do an interval trigger wfter that
<azonenberg>
not quite what you're lookin for
<azonenberg>
The other thing i can do is cascaded triggering
<azonenberg>
so i can arm on a dropout, then skip N edges, then actually trigger on an edge
<azonenberg>
You can cascade up to four levels of triggering
<azonenberg>
I've never used it, and the libscopehal API does not support it
<miek>
ok, cheers. i'm gonna implement it for the keysight/agilent and just wanted to get naming right if it was gonna be shared, but it doesn't sound like there'll be any crossover
<azonenberg>
pd0wm: Looks good, thanks and congrats on your first contribution :)
<miek>
on the agilent (and some rigols i think) it's a standalone trigger type, so i'll just make it a simple class along the same lines as the existing triggers https://i.imgur.com/MZNd4XW.png
<azonenberg>
pd0wm: I'm also going to add you to the list of contributors... would you prefer to be listed by your real name, your github handle, or something else?
<azonenberg>
miek: yes that looks much less general and best done as its own trigger type
<azonenberg>
with lecroy it's basically a state machine wrapping all of the simple trigger types
<azonenberg>
MAXWELL's trigger engine is going to be similar to this too
<miek>
btw, i'm not able to build with the CL changes - cmake sets OpenCL_INCLUDE_DIR but not OpenCL_INCLUDE_DIRS, are you definitely getting DIRS on your end?
<azonenberg>
Yes i am getting dirs on my end. It just defaults to /usr/include
<azonenberg>
oh wait
<azonenberg>
no
<azonenberg>
it's DIR not DIRS, that's a typo
<azonenberg>
and i get away with it because /usr/include was already in my search path
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLzYL
<_whitenotifier>
[scopehal] azonenberg 2a26351 - Fixed typo in variable name
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLzYq
<_whitenotifier>
[scopehal-apps] azonenberg 00d7d08 - Updated to latest scopehal
<azonenberg>
miek: try that
<miek>
cheers
<miek>
ahh, i was also missing the opencl-clhpp-headers package
dre_afk is now known as Cyber_Dre
<pd0wm>
azonenberg: github handle is fine!
<azonenberg>
miek: but cmake detected CL anyway? so you have half an install and it got confused because no headers?
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLzYj
<_whitenotifier>
[scopehal-apps] azonenberg 8bb0b61 - OscilloscopeWindow: added another contributor to about dialog
<azonenberg>
pd0wm: Great, done. Planning to work on anything else today?
<miek>
yeah, it's a bit weirdly packaged
<pd0wm>
It's already pretty late over here. I'll see if I can get my Rigol to work tomorrow.
<azonenberg>
Ok great
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLzOS
<_whitenotifier>
[scopehal] azonenberg d9772b6 - scopehal: fix bug in handling of no-OpenCL systems
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLzO9