azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://freenode.irclog.whitequark.org/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3leY
<_whitenotifier-3> [scopehal] azonenberg e90ef48 - EthernetProtocolDecoder: initial decoding of LLC/STP frames. Fixes #401.
<_whitenotifier-3> [scopehal] azonenberg closed issue #401: EthernetProtocolDecoder: correctly display old-style 802.3 framing without EtherType field in protocol analyzer view - https://git.io/JYKFc
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±5] https://git.io/J3l0D
<_whitenotifier-3> [scopehal-apps] azonenberg 06e5336 - Initial implementation of progress dialog for saving waveforms. Fixes #166.
<_whitenotifier-3> [scopehal-apps] azonenberg 2e1777b - Significant improvements (3x or more typical) to performance of waveform serialization by batching data in RAM then writing interleaved data vs lots of tiny fwrite() calls.
<_whitenotifier-3> [scopehal-apps] azonenberg closed issue #166: Add progress dialog when saving files - https://git.io/JUZle
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3lEP
<_whitenotifier-3> [scopehal-apps] azonenberg 6ad13bb - OscilloscopeWindow: redraw timeline after new waveforms arrive. Fixes #331.
<_whitenotifier-3> [scopehal-apps] azonenberg closed issue #331: Trigger Position in time only updates when time ribbon is moved - https://git.io/J3WZK
<azonenberg> fsedano: getting CI build issues in your latest R&S patch on Windows https://github.com/azonenberg/scopehal-apps/runs/2484883275
<azonenberg> first off you're using %ld instead of %zd for size_t values
<azonenberg> but something is also failing to compile
<azonenberg> ah sorry my bad
<azonenberg> mubes: the compile error is your fault
<azonenberg> SiglentSCPIOscilloscope.cpp:2076 you used usleep rather than std::this_thread::sleep_for
<azonenberg> usleep is a posix function that doesnt exist on windows
<azonenberg> also in 2543
<azonenberg> fsedano: my comments about %ld stand but that's not the cause of the CI failures
<GenTooMan> and MS said it was going to work on POSIX compatibility.
<d1b2> <mubes> I'll send a patch later today after testing.
<d1b2> <mubes> I'm going to have to build out a 'doze instance somewhere to pretest this stuff.
<azonenberg> Yeah i have no local windows testing, i just rely on the CI builds to tell me i broke something
<azonenberg> a local test box would be nice
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/J38ml
<_whitenotifier-3> [scopehal-apps] azonenberg bbcf5ae - Various bug fixes to ProtocolTreeModel. Still some known problems.
<_whitenotifier-3> [scopehal-apps] azonenberg 965cf9c - ProtocolAnalyzerWindow: fixed some crashes
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/J38Of
<_whitenotifier-3> [scopehal-apps] azonenberg 5c07024 - OscilloscopeWindow: don't add new packets to protocol analyzers any time a filter is reconfigured. Fixes #329.
<_whitenotifier-3> [scopehal-apps] azonenberg closed issue #329: Protocol analyzer view gets duplicate packets added when changing spectrogram settings - https://git.io/J3nYm
Tost has joined #scopehal
<xzcvczx> wow seems that nv is adding compute shader support to rather old nvidia gpus
<azonenberg> xzcvczx: They're supported on stuff as old as geforce 600 iirc
<xzcvczx> well its nv50 so "series 8 through 300"
<azonenberg> series 8 meaning geforce 8800 and ki?
<azonenberg> kin*
<azonenberg> those were the first gen to support CUDA
<azonenberg> so it makes sense, compute shaders and CUDA generally use about the same resources
<azonenberg> you could probably compile GLSL to CUDA easily enough
juli9610 has joined #scopehal
<xzcvczx> tbh i am not familiar with the abomination of an nvidia naming scheme i just thought it was relevant in here :)
<azonenberg> I've been doing gpu programming since that era
<azonenberg> Just mostly for number crunching rather than graphics
<azonenberg> a freshman year class paper i wrote on password cracking is still my most cited work, something like 12 years later lol
<xzcvczx> and i thought you were a good boy not a dirty hacker who used pasword1 for all his passwords
<azonenberg> lol
* azonenberg checks
<azonenberg> it's up to 41 citations now
<xzcvczx> link?
<azonenberg> not too bad for freshman year homework
<xzcvczx> freshman is first year?
<azonenberg> yeah
<azonenberg> the original link is dead
<azonenberg> let me try to find it to reupload
<xzcvczx> very impressive
<azonenberg> I got in at the right time, GPGPU was just starting to get hot
<azonenberg> this predated hashcat and all the modern tools
<azonenberg> The professor for that class later ended up being on my PhD committee
Tost has quit [Ping timeout: 240 seconds]
Tost has joined #scopehal
<xzcvczx> i am not surprised wit hthe quality of what you produced in first yera
<GenTooMan> it's best not to get GPU's hot but if you really want to cook eggs on them, I guess it's OK.
<GenTooMan> random question is the trigger channel used / kept information or is it fine to ignore?
<GenTooMan> in class Oscilloscope
<miek> like for an external trigger input channel on the scope?
<GenTooMan> external internal channel trigger etc.
<GenTooMan> it appears to be needed for a number of SCPI commands hence my real question is "shouldn't we 'know' this?"
<miek> i still don't understand exactly what you're asking
Bird|ghosted has quit [Ping timeout: 246 seconds]
Bird|otherbox has joined #scopehal
Tost has quit [Ping timeout: 240 seconds]
Bird|ghosted has joined #scopehal
Bird|otherbox has quit [Ping timeout: 240 seconds]
<_whitenotifier-3> [scopehal-docs] mubes opened pull request #27: Documentation updates to support Siglent driver - https://git.io/J34xA
bvernoux has joined #scopehal
<_whitenotifier-3> [scopehal] mubes opened pull request #447: Fix windows compilation error due to lack of usleep - https://git.io/J3BTj
<d1b2> <mubes> @GenTooMan Do you mean "Should we be caching these data?" then the answer, IMHO, is probably no for most trigger parameters. They're only needed (at the moment) for the interactive setting new trigger types and we can afford the 'expense' of geting the true values from the scope, as opposed to cached values which could be out of date. There's nothing stopping any individual driver implementation from caching if it wants to, but it's generally
<d1b2> best to cache things that are going to have a visible impact on performance. Caching is a necessary evil 😦 OTOH trigger channel and level are used pretty often so it would be nice to have those available. Trigger position is delivered as part of the wavedesc so that can be automatically updated when a new set of waveforms arrive. I dunno if that was exactly the question though....
<d1b2> <GenTooMan> @mubes after reviewing the code some more it appears SiglentSCPIOscilloscope::PullTriggerSource stores the channel ID in m_trigger, and then when the information is needed the method m_trigger->GetInput(0).m_channel->GetIndex(). The likely source for my embafflement is the SDS1/2 series does NOT have a trigger source query command but includes the source information in all trigger queries. The SDS5/6 have a more complex system that requires
<d1b2> separate queries for each point of data. So one must query the trigger source separately based on the mode.
<d1b2> <mubes> So what's the issue? We pretty much expect scopes to be different (unfortunately 😦 )
<d1b2> <mubes> If we've got live versions of the parameters that's all to the good....and preferable to cached ones.
<miek> the trigger stuff probably should be cached, it's used constantly by the ui
<d1b2> <GenTooMan> @mubes sadly it's shamefully easy to get confused by the differences between the two command sets. Not that it's difficult for me to be confused apparently. The only command set that might be similar is potentially the waveform related ones.
<d1b2> <mubes> Yup. I think that's where we entered this whole conversation :-) they are not the same.
<d1b2> <GenTooMan> @mubes sad to say but sufficiently true. I suppose the words are "press on" and hope the results are cleanable. I feel dread much like that feeling of ripping apart a car and then putting it together (purposefully) wrong.
Tost has joined #scopehal
<d1b2> <mubes> If it gets too hefty then yell up. It's on my list to do anyway, but until Orbuculum is out the door it's a lower priority given that the sds2000x+ is complete enough to be usable at the moment.
<azonenberg> the index of the trigger channel, and the level, are used every frame by the UI
<azonenberg> to display the trigger arrow
<azonenberg> more complex trigger parameters don't have to be cached
<azonenberg> but those two definitely need to be
<miek> but it's all one structure, there isn't a choice to cache some bits of it is there?
<azonenberg> Yeah I don't think there is
<_whitenotifier-3> [scopehal-docs] azonenberg pushed 2 commits to master [+2/-0/±4] https://git.io/J3B69
<_whitenotifier-3> [scopehal-docs] mubes 5cb07d5 - Documentation updates to support Siglent driver
<_whitenotifier-3> [scopehal-docs] azonenberg 4b8d5f5 - Merge pull request #27 from mubes/sig_docs Documentation updates to support Siglent driver
<_whitenotifier-3> [scopehal-docs] azonenberg closed pull request #27: Documentation updates to support Siglent driver - https://git.io/J34xA
<_whitenotifier-3> [scopehal] azonenberg closed pull request #447: Fix windows compilation error due to lack of usleep - https://git.io/J3BTj
<_whitenotifier-3> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/J3B6F
<_whitenotifier-3> [scopehal] mubes 39198cd - Fix windows compilation error due to lack of usleep
<_whitenotifier-3> [scopehal] azonenberg 0a77082 - Merge pull request #447 from mubes/doze_compile_error Fix windows compilation error due to lack of usleep
<_whitenotifier-3> [scopehal-docs] azonenberg pushed 3 commits to master [+1/-0/±4] https://git.io/J3Bik
<_whitenotifier-3> [scopehal-docs] azonenberg 4ecd754 - Added skeleton Digilent header
<_whitenotifier-3> [scopehal-docs] azonenberg 109b66f - Updated copyright page for 2021 and "and contributors"
<_whitenotifier-3> [scopehal-docs] azonenberg 0a8de02 - Merge branch 'master' of github.com:azonenberg/scopehal-docs
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/J3BiO
<_whitenotifier-3> [scopehal-apps] azonenberg 7b0f7b2 - Updated submodules
bvernoux has quit [Quit: Leaving]
<_whitenotifier-3> [scopehal] azonenberg opened issue #448: Support for Pico offset limits - https://git.io/J3BhK
<_whitenotifier-3> [scopehal] azonenberg labeled issue #448: Support for Pico offset limits - https://git.io/J3BhK
<_whitenotifier-3> [scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/J3Bjx
<_whitenotifier-3> [scopehal-pico-bridge] azonenberg 8055591 - Various improvements and bug fixes. Added recovery from PICO_HARDWARE_CAPTURING_CALL_STOP error condition. Fixed inverted offset sign.
<_whitenotifier-3> [scopehal-pico-bridge] azonenberg commented on issue #3: Crash when setting negative trigger level - https://git.io/J3Ree
<_whitenotifier-3> [scopehal-pico-bridge] azonenberg closed issue #3: Crash when setting negative trigger level - https://git.io/J3WyY
<_whitenotifier-3> [scopehal-pico-bridge] azonenberg opened issue #4: Support for moving trigger location within capture window - https://git.io/J3ReU
<_whitenotifier-3> [scopehal-pico-bridge] azonenberg opened issue #5: Support for digital channels - https://git.io/J3Rek
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/J3Ret
<_whitenotifier-3> [scopehal] azonenberg edf41bd - PicoOscilloscope: switched from SCPISocketTransport to raw Socket for data plane socket as we don't use any SCPI functionality there. Removed timeouts since indefinite blocking is expected and desired when scope is stopped.
<d1b2> <fsedano> Thx I'll fix
<_whitenotifier-3> [scopehal-pico-bridge] azonenberg opened issue #6: Offsets seem to be scaled incorrectly - https://git.io/J3Re8
<_whitenotifier-3> [scopehal-pico-bridge] azonenberg labeled issue #6: Offsets seem to be scaled incorrectly - https://git.io/J3Re8
<azonenberg> yeah sorry i didnt notice sooner. The current setup does not have CI builds on libscopehal, only scopehal-apps
<azonenberg> So things that break the windows build don't get noticed until i sync scopehal-apps to pull a new version of scopehal
<d1b2> <fsedano> my bad, not yours 😉
<azonenberg> I'm just always a fan of catching issues sooner rather than later :p
<azonenberg> Any progress on troubleshooting the intel GPU issues? and do you have a box with a non-intel GPU you can use for R&S driver dev?
<d1b2> <fsedano> fully agree
<azonenberg> in the meantime
<d1b2> <fsedano> No box with non-intel 😦
<d1b2> <fsedano> So I'm kinda stuck, working with the shader workaround you mentioned
<d1b2> <fsedano> which produces no output but at least does not crash
<azonenberg> So there's a hack you can do that will give better results than just disabling all rendering
<d1b2> <fsedano> I can provide VNC or any other tool that might be useful
<azonenberg> Rather than commenting out the entire loop in waveform-compute-core.glsl
<azonenberg> add a "break" at the end of the parallel fill loop on line 188-198
<azonenberg> this will process a max of one sample per pixel
<azonenberg> you'll lose intensity grading and might see some broken lines on sharp changes in signal amplitude
<azonenberg> but it's better than crashing or getting no output at all
<azonenberg> (after the fill loop, breaking out of the parent loop)
<d1b2> <fsedano> (y) let me try
<azonenberg> That should at least make it usable for debug purposes until we find a roto cause
<azonenberg> root*
<azonenberg> and if bob_twinkles has time to work on the new renderer we were discussing, that might fix it entirely
<_whitenotifier-3> [scopehal-pico-bridge] azonenberg opened issue #7: Add software trigger jitter reduction - https://git.io/J3RvI
<azonenberg> fsedano: if that works for you we might want to think about adding this as a "safe mode" renderer feature if other people have similar issues. or who just have really wimpy computers compared to the size of the dataset they're working with
<_whitenotifier-3> [scopehal] fsedano opened pull request #449: Add proper parameter format specifier for size_t - https://git.io/J3RfC
<d1b2> <fsedano> That would be great - But on this case I don't think it's related to the dataset size. Let me try this workaround
<azonenberg> Yeah it's entirely possible you have a driver bug or something too
<azonenberg> Are you running the most up to date kernel available?
<azonenberg> that would be my next suggestion
<_whitenotifier-3> [scopehal] nshcat commented on pull request #449: Add proper parameter format specifier for size_t - https://git.io/J3RJJ
juli9610 has quit [Quit: Nettalk6 - www.ntalk.de]
<_whitenotifier-3> [scopehal] fsedano commented on pull request #449: Add proper parameter format specifier for size_t - https://git.io/J3RJS
<d1b2> <fsedano> Yes running Ubuntu 20.04 with 5.8.0-50
<azonenberg> Do you have another computer, even if still using an intel gpu but a different generation, you can compare against?
<azonenberg> And does this happen with the demo scope or only the R&S?
<azonenberg> conjecture: the R&S driver has a bug causing it to sometimes spit out bogus data that the shader handles poorly
<azonenberg> the demo scope always produces valid waveforms so we can exclude that possibility
<_whitenotifier-3> [scopehal-apps] fsedano edited issue #325: GPU hang on iris Plus driver - https://git.io/J3k5U
Tost has quit [Quit: Nettalk6 - www.ntalk.de]
<d1b2> <fsedano> Good point - with the demo it seems stable
<d1b2> <fsedano> Also might be due to timing? Rs is slow
<d1b2> <fsedano> Trying also with Agilent