<_whitenotifier-3>
[scopehal-cmake] antikerneldev commented on issue #1: Change .gitmodules url in order to allow clone from anonymous user - https://git.io/JvEIb
<_whitenotifier-3>
[scopehal-cmake] antikerneldev reopened issue #1: Change .gitmodules url in order to allow clone from anonymous user - https://git.io/fjZb6
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JvEIA
<_whitenotifier-3>
[scopehal-apps] azonenberg b01f926 - WaveformArea: began refactoring of render code path for multiple GL traces per frame
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JvELZ
<_whitenotifier-3>
[scopehal-apps] azonenberg 7742f53 - Continued refactoring in preparation for digital trace rendering in GL
<_whitenotifier-3>
[scopehal-cmake] antikerneldev opened issue #8: Add support to disable building modules - https://git.io/JvELc
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #59: Rename "volts" to "Y axis units" in function names, e.g. VoltsToYPosition - https://git.io/JvELy
maartenBE has quit [Ping timeout: 258 seconds]
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JvEtE
<_whitenotifier-3>
[scopehal-apps] azonenberg 6c1977a - Digital waveform overlay rendering is now done on the GPU. Fixes #51.
<_whitenotifier-3>
[scopehal-apps] azonenberg closed issue #51: Digital waveform overlays should be done in GL, not Cairo, to improve performance - https://git.io/JvlUH
<_whitenotifier-3>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JvEtu
<_whitenotifier-3>
[scopehal-cmake] azonenberg 7ade46d - Updated to latest submodules
<_whitenotifier-3>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvEtK
<_whitenotifier-3>
[scopehal-docs] azonenberg 7ba8b82 - Updated LeCroy driver notes to reflect DDA series scopes tested and working
<_whitenotifier-3>
[scopehal-apps] azonenberg assigned issue #16: Add some kind of plugin interface for loading new protocol decoders and measurements from additional libraries - https://git.io/JvEt7
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #29: Shift-scroll on viewport should pan horizontally - https://git.io/JvEtd
m4ssi has joined #scopehal
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvEqB
<_whitenotifier-3>
[scopehal-apps] azonenberg 909b628 - OscilloscopeWindow: added menu items for file load/save (no logic backing them yet). See #3.
<_whitenotifier-3>
[scopehal-apps] lainy opened issue #60: Gracefully handle missing icons in GTK theme - https://git.io/JvEq2
<_whitenotifier-3>
[scopehal-apps] antikerneldev pushed 2 commits to master [+0/-0/±2] https://git.io/JvEq7
<_whitenotifier-3>
[scopehal-apps] antikerneldev df2e84e - chdir() to the glscopeclient binary directory Fixes #15
<_whitenotifier-3>
[scopehal-apps] antikerneldev closed issue #15: Proper working directory support - https://git.io/JvEq5
<tnt>
Arf: "ERROR: Compile of shader shaders/waveform-compute.glsl failed:" "0:13(4): error: embedded structure declarations are not allowed"
<azonenberg>
Hmmm it works fine on my box. Wonder if i didn't specify the version right or something
<azonenberg>
oh i see
<azonenberg>
it looks like i need to name the struct separately, then instantiate it in the layout block
<azonenberg>
GLSL doesn't support anonymous structs but nvidia's driver isn't pedantic enough to complain
<azonenberg>
File an issue against scopehal-apps and i'll get to it shortly
<azonenberg>
Working on something else right now
<azonenberg>
tnt: ^
<tnt>
Yup indeed that fixed it.
<azonenberg>
If you fixed it yourself, feel free to send a PR :)
<tnt>
yeah doing that now. GH is a bit of a pain to submit one little patch, I wish I could just paste a diff somewhere in the UI.
<_whitenotifier-3>
[scopehal-apps] smunaut forked the repository - https://git.io/JvEmZ
<azonenberg>
tnt: btw, what OS/GPU driver was this on?
<azonenberg>
would be nice to know for future testing if it's pickier than the nvidia 440.59 binary driver
<tnt>
azonenberg: Linux, Intel GPU (built in the CPU) using Mesa drivers. (19.2.8)
<azonenberg>
Good to know, thanks
<tnt>
lol, I upgraded to master in scopehalapps (to make the PR) but your chdir patch actually breaks the run for me since I build stuff in a build dir and not in the source tree ...
<azonenberg>
tnt: you are the lucky one halfway through commits
<azonenberg>
that one was pushed too soon
<azonenberg>
the next commit copies shaders etc to the build directory
<_whitenotifier-3>
[scopehal-apps] antikerneldev opened issue #61: Default window sizes don't work well on small screens - https://git.io/JvEmK
<_whitenotifier-3>
[scopehal-apps] smunaut opened pull request #62: glscopeclient: Fix up shader syntax to avoid embedded struct definitions - https://git.io/JvEm6
<_whitenotifier-3>
[scopehal-apps] azonenberg closed pull request #62: glscopeclient: Fix up shader syntax to avoid embedded struct definitions - https://git.io/JvEm6
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JvEmX
<_whitenotifier-3>
[scopehal-apps] smunaut d064b23 - glscopeclient: Fix up shader syntax to avoid embedded struct definitions This is a fix for the error : ERROR: Compile of shader shaders/waveform-compute.glsl failed: 0:13(4): error: embedded structure declarations are not allowed Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
<_whitenotifier-3>
[scopehal-apps] azonenberg 5d28cb8 - Merge pull request #62 from smunaut/shader_fix glscopeclient: Fix up shader syntax to avoid embedded struct definitions
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvEmN
<_whitenotifier-3>
[scopehal-apps] azonenberg 53b56db - WaveformArea: now use LogFatal when shaders can't be loaded, proper line breaks at end of error messages
<_whitenotifier-3>
[scopehal-apps] antikerneldev pushed 2 commits to master [+0/-0/±2] https://git.io/JvEY3
<_whitenotifier-3>
[scopehal-apps] antikerneldev 3aed00b - glscopeclient's CMake now copies resources to the build directory
<_whitenotifier-3>
[scopehal-apps] lainy opened issue #63: Attempting to add Eye pattern analyzer with NULL clock is a segfault - https://git.io/JvEYu
<_whitenotifier-3>
[scopehal-apps] lainy opened issue #64: Closing all waveform views causes segfault - https://git.io/JvEYw
<_whitenotifier-3>
[scopehal-apps] lainy opened issue #65: Sparse digital waveforms look wrong - https://git.io/JvEY6
<_whitenotifier-3>
[scopehal-apps] antikerneldev opened issue #66: Check Minimum System Requirements on glscopeclient startup - https://git.io/JvEYP
<tnt>
indeed works.
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #65: Sparse digital waveforms look wrong - https://git.io/JvEY1
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JvEYS
<_whitenotifier-3>
[scopehal-apps] azonenberg b887c96 - File save menu buttons now pop up a directory chooser dialog. No actual saving happens yet. See #3
<_whitenotifier-3>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JvEYH
<_whitenotifier-3>
[scopehal-cmake] azonenberg f4280ab - Updated to latest submodules
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvEYA
<_whitenotifier-3>
[scopehal-apps] azonenberg 75f6036 - Stretched digital samples into two, so that digital waveforms with far-spaced samples look sane. Fixes #65.
<azonenberg>
Ok that's it for tonight, i need to get to sleep
<tnt>
Oh, the UI is completely frozen while the scope downloads data :/
<tnt>
or just the context menu actually
maartenBE has joined #scopehal
<tnt>
miek: your driver actually works ... sort of with my scope. Options and model number processing obviously fails, but it can acquire data.
<tnt>
Sometime the acquisition doesn't get the full buffer though.
<tnt>
Instead of getting the full 2M points, it only gets 62500 points.
<tnt>
actually teh WAV:PRE returns 62500 but then the data has 1M points (instead of 2M). (and doing a second WAV:PRE just after the first then returns 1M). So scope is busy some time and I'm not sure how to check that
<miek>
yeah, i ran into something similar. i did a bunch of early dev remotely, then everything broke when i got home and the latency went away :p the latest commit was a workaround but it's still a bit odd, i haven't had a chance to investigate properly
<tnt>
The trigger polling condition is revered (at least for my scope), but that doesn't really help either.
<azonenberg>
miek, tnt: the context menu performs some queries for things like channel attenuation etc
<azonenberg>
if you are not caching those and hitting the scope each time, that will block
<miek>
i think it should be caching everything (i copied that from one of the existing drivers), but i might've missed one somewhere
<azonenberg>
yeah that would be the first thing i check
<azonenberg>
But hey, this is progress. Performance issues and bugs are better than not working at all :p
<miek>
indeed :) it's pretty great that it still (mostly) works on the X series
<azonenberg>
Yeah i'm hoping we can mostly have one driver per scope vendor
<azonenberg>
and just some quirks modes for particular models
<azonenberg>
Can you submit a PR or something with your current code so we can get it into mainline? I'd rather have an incomplete driver than none
<azonenberg>
Also when you get a chance, can you do a writeup in the documentation with info on known working/not working models, arguments, etc for your driver and send me a PR for that? Copy the format etc from the lecroy driver
<azonenberg>
also heading out to $dayjob, be back online in a bit
azonenberg_work has joined #scopehal
<_whitenotifier-3>
[scopehal-docs] azonenberg opened issue #1: Split glscopeclient-manual.tex up into multiple files - https://git.io/JvE0m
m4ssi has quit [Remote host closed the connection]
bvernoux has joined #scopehal
azonenberg_work has quit [Ping timeout: 240 seconds]
<miek>
just rebased on the latest master, this is running much better now :D also, tnt: i've added some missing caches, the context menu is instant now (after the first use)
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel_ has joined #scopehal
maartenBE has quit [Ping timeout: 258 seconds]
<miek>
tnt: also, just changed PollTrigger to query the run state instead (from an example in the programmers guide i'm looking at). this seems to fix all the issues around number of points, though mine is now super slow to download once it does trigger
maartenBE has joined #scopehal
<azonenberg>
miek: :)
<azonenberg>
as a general note i don't recommend using "run" mode as most scopes dont handle that well wrt consistency between channels
<azonenberg>
better to run single-shot trigger, download all channels and know they're from the same trigger
<azonenberg>
then retrigger after that
<azonenberg>
unfortunately most scopes dont seem to support pipelining of triggers with defined groups of data
<azonenberg>
When i build a scope of my own it will be a completely different architecture: one socket for control plane data with low latency
<azonenberg>
then a separate one for data plane. And instead of polling for triggers, it will be push based
<azonenberg>
you set up a session on the control socket, open the data socket, then whenever it triggers it will push waveform data to you
<miek>
ah yeah, it's using single trigger mode but you can still query the 'run' bit to see when it's stopped
<azonenberg>
Probably using TCP acks as flow control to prervent the scope from triggering faster than you can process the data
<azonenberg>
since the scope will easily be able to push line rate 10G/40G but it will probably be a while before glscopeclient can keep up with that much
<azonenberg>
(right now one of our biggest performance issues in terms of WFM/s is just how fast you can pull stuff off over SCPI from existing scopes)
<azonenberg>
miek: anyway, when are you gonna have a PR ready for me? :)
<miek>
working on it :)
azonenberg_work has joined #scopehal
<miek>
any preference for merging as-is vs. squashing it down to one commit to tidy up some of the messy history?
<azonenberg>
No preference, I mostly just want to get the code in mainline
electronic_eel_ has quit [Ping timeout: 255 seconds]
electronic_eel has joined #scopehal
<bvernoux>
azonenberg, whats is the actual speed of glscopeclient in term of WFM/s ?
<_whitenotifier-3>
[scopehal] miek opened pull request #91: Initial Agilent 5/6/7000 series support - https://git.io/JvEus
<azonenberg>
bvernoux: i've never come close to hitting it, because normally the scope has been the bottleneck
<_whitenotifier-3>
[scopehal-apps] miek forked the repository - https://git.io/JeGi3
<azonenberg>
With my HDO9204 and 1M points per waveform i average somewhere around 7 WFM/s i think?
<bvernoux>
ha ok
<_whitenotifier-3>
[scopehal-apps] miek opened pull request #67: Add Agilent support - https://git.io/JvEuC
<azonenberg>
but i can hit 20+ FPS with just rendering and no waveform downloads, and i've optimized a lot since then
<bvernoux>
I was thinking with 1GSPS Ethernet it could push more data/s
<azonenberg>
my HDO does not get close to saturating gig-e normally
<azonenberg>
Sequenced capture mode might be able to saturate it briefly
<bvernoux>
ok interesting
<azonenberg>
that's the only way i've found to get high WFM/s on a lecroy via scpi
<azonenberg>
there is some latency around triggers that seems difficult to work around
<azonenberg>
i.e.a 50x sequence of 1M point waveforms using 50M points of memory will be much faster than 50 triggers each of 1M points
<azonenberg>
but you won't get the first waveform until all 50 have been acquired by the scope
<azonenberg>
this is one of the things i want to fix with the push architecture of my proposed scopes
<bvernoux>
yes it is not interesting to wait all acquisitions are done
<azonenberg>
miek: reminder to also work on documentation for your driver. basically just what scopes you've tested it on and what arguments the driver takes
<bvernoux>
which Agilent scope ?
<bvernoux>
Interesting
<monochroma>
azonenberg: do you know if this is the specific extension name you are using/require ? GL_ARB_compute_shader
<_whitenotifier-3>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvEur
<_whitenotifier-3>
[scopehal-docs] azonenberg 85d277a - Added minimum system requirements section
<miek>
bvernoux: i'm using an MSO6034A (it should work with the other 5000/6000/7000 series models) and also looking like it'll work with MSOX with some minor changes
<miek>
azonenberg: yep, will do
<azonenberg>
monochroma: That sounds correct. It's possible some pre-GL4.3 implementations support it as an extension
<azonenberg>
So i think if you check for either 4.3 or, say. 4.0 plus that extension we should be good
<azonenberg>
i know some GL 1.x implementations supported GL_ARB_vertex_shader etc but didnt do the full 2.0 spec
<monochroma>
okay
<azonenberg>
at some point we should do some testing on various older hardware and make sure it degrades gracefully, and the actual system requirements match those we claim
<azonenberg>
i also need shader storage buffers
<azonenberg>
idk what the extension for that is pre gl4.3
<azonenberg_work>
(i think it's GL_ARB_shader_storage_buffer_object)
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 258 seconds]
bvernoux1 has quit [Quit: Leaving]
bvernoux has joined #scopehal
<monochroma>
azonenberg: where is the best place to insert my check code? i'm not super familiar with gtk GL usage and how the contexts get created
<azonenberg>
monochroma: Sooo that is a very good question. The contexts are created by the gtk::glarea stuff for WaveformArea automatically, and i don't want to do the check each time
<monochroma>
yeah that's kinda what it was looking like to me
<azonenberg>
For now I think it makes more sense to just do some text parsing on glxinfo output in a function you call early in main()
<azonenberg>
before the window is even created
<monochroma>
glxinfo is not a required tool for all installations, but i suppose it's a reasonable requirement
<azonenberg>
there are very few linux systems with working opengl and no glxinfo
<azonenberg>
i have no problems with requiring it
<monochroma>
it's not required on arch, you have to specifically install it (it's part of the mesa-demos package)
<azonenberg>
actually, hmm
<azonenberg>
just add a static member var to WaveformArea
<azonenberg>
and run the check the first time you create one
<azonenberg>
on_realize i think is the earliest point where you have a valid context to work with
<azonenberg>
then you can do gl api queries to check various properties
<monochroma>
(hmmm do the GLEW functions get imported via gtk?)
<azonenberg>
i dont think i am currently using glew
<azonenberg>
i should just be calling from gl.h directly?
<monochroma>
yeah i don't see it
<azonenberg>
for now just do a gl 4.3 version check
<azonenberg>
we can worry about being more permissive later
<azonenberg>
glGetString(GL_VERSION)
<monochroma>
yeah
<lain>
azonenberg: can on_realize be called from multiple threads simultaneously?
<lain>
though I'm guessing even if it is, locking isn't worth it here vs. just some % chance you wind up checking the version more than once
<azonenberg>
lain: all rendering should be single threaded
<azonenberg>
GL doesnt really do multithreaded gfx
<lain>
ah ok
<azonenberg>
i take that back. Within a single context
<azonenberg>
it's hypothetically possible that you could have two GL contexts from different threads active at once