azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal, https://github.com/azonenberg/scopehal-docs | Logs: https://freenode.irclog.whitequark.org/scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
azonenberg_work has quit [Ping timeout: 256 seconds]
azonenberg_work has joined #scopehal
electronic_eel_ has quit [Ping timeout: 258 seconds]
electronic_eel has joined #scopehal
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JUsBu
<_whitenotifier-f> [scopehal] azonenberg 6b2b874 - PacketDecoder: added packet merging
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JUsBz
<_whitenotifier-f> [scopehal-apps] azonenberg 917c956 - Implemented packet merging in protocol analyzer UI
<azonenberg> monochroma, noopwafel: https://www.antikernel.net/temp/flash-analyzer.png
<azonenberg> how's this look?
<azonenberg> so far only implemented in the spi flash protocol analyzer, you can collapse lots of packets that are semantically one higher level event
<azonenberg> some of these polling loops have 10+ polls in them which really clutters the view
<monochroma> nice
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
<Bird|otherbox> azonenberg: good news, I have my github account back
_whitelogger has joined #scopehal
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<Bird|otherbox> also: it compiled \o/. bad news: I can't get it to connect to my rigol via either lan or lxi (it hangs without rendering the UI after bleating an "invalid scope string" error to stdout)
<Bird|otherbox> (either that, or it's just bogged down doing GL things)
<Bird|otherbox> other bad news: it seems that it didn't compile the docs? (despite the fact I have texlive on this box)
<Bird|otherbox> also: I was wrong -- my scope is on USBTMC not LAN/LXI
<Bird|otherbox> once I figured that out, I was able to try to connect, but it puked an internal error about failing to load the waveform compute shader
<Bird|otherbox> (this is with a NV92 and the nouveau driver, so that might be why)
<Bird|otherbox> (ugh. nouveau only reports GL 3.3 with my card)
DanRoh has joined #scopehal
<Bird|otherbox> (so -- I think I need a new graphics card -- any suggestions given that I don't want to deal with blob drivers?)
<azonenberg> Bird|otherbox: yeah i have not done any testing w/ nouveau
<azonenberg> personally i have a 2080 Ti and use the blob
<azonenberg> AFAIK AMD linux drivers are open source so if you get an AMD card it should just work
<azonenberg> as are intel integrated card drivers
<azonenberg> Bird|otherbox: as far as docs, they are not compiled by default I think
<azonenberg> there's a cmake option to enable it
<azonenberg> Longer term i want to make it auto build docs if texlive is present
<azonenberg> feel free to send a PR for that
<Bird|otherbox> ah. found the cmake option, installing the font package I missed :p and then going to get the docs built
<Bird|otherbox> re: graphics cards: looking at a 4GB RX560 for $130
<azonenberg> any remotely recent card should work with the AMD/intel open source or NV blob driver afaik
<Bird|otherbox> okiedokie, and yeah, my current card is WAAAY too old lulz
<azonenberg> I'm also thinking of requiring GL_ARB_GPU_shader_int64 moving forward
<Bird|otherbox> (GF9800GTX+)
<azonenberg> ... oh
<azonenberg> yeah
<azonenberg> i think gtx 400 series is the oldest i support right now on the NV side
<azonenberg> anyway, ARB_GPU_shader_int64 should be well supported on anything with GL 4.3 which we need anyway
<azonenberg> And this will allow me to use int64's in compute shaders
<azonenberg> which is a core requirement for my longer term goal of moving some protocol decodes and math functions to the GPU
<azonenberg> I don't think it will change hardware support
<azonenberg> and this will eliminate all of the floating point rounding issues i'm having in rendering of deep (more than a few Mpoints) captures
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±6] https://git.io/JUsz5
<_whitenotifier-f> [scopehal-apps] azonenberg 181d444 - Now require ARB_GPU_shader_int64. Waveform compute shader now takes X positions as int64_t's.
<_whitenotifier-f> [scopehal-apps] azonenberg 2a4fb3e - Waveform rendering now performs the timebase offset with int64 precision before converting to float32 for actual rendering. Fixes #162.
<_whitenotifier-f> [scopehal-apps] azonenberg closed issue #162: Floating point precision issues (?) in rendering of very deep waveforms - https://git.io/JU3rl
<azonenberg> And this is also faster because it omits the very ugly int64-to-float32 conversion code on the CPU side and replaces it with a simpel memcpy
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUsgU
<_whitenotifier-f> [scopehal-apps] azonenberg 8d6cbcd - Cleanup of PrepareGeometry()
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #163: OscilloscopeWindow::LoadWaveformDataForScope() is slow, calling push_back vs allocating once and writing to buffer - https://git.io/JUsg3
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #163: OscilloscopeWindow::LoadWaveformDataForScope() is slow, calling push_back vs allocating once and writing to buffer - https://git.io/JUsg3
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #164: Optimize digital waveform generation loop in WaveformArea::PrepareGeometry() - https://git.io/JUsgZ
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #164: Optimize digital waveform generation loop in WaveformArea::PrepareGeometry() - https://git.io/JUsgZ
<azonenberg> welp, i have some more TODOs to make glscopeclient usable for large waveforms it seems
<azonenberg> My current test case is 64M points * 7 channels so just about half a billion points
<azonenberg> with 2x SPI, 1x QSPI, 1x SPI flash, 1x UART protocol decode running on that
bvernoux has joined #scopehal
_whitelogger has joined #scopehal
<Degi> Hmm
<Degi> What if you make a SERDES based DAC
<Degi> Using some kinda R-2R chain or so
<Degi> Or if you have 50 ohm output, you can just make a voltage divider with R_total = 50 Ohm and R_n=R_(n-1)*2
DanRoh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
DanRoh has joined #scopehal
DanRoh has quit [Client Quit]
<anuejn> when i try to start glscopeclient with the scopesession in https://www.antikernel.net/temp/usb-test.zip i get the error "Error: Failed to initialize GLEW" multiple times and glscopeclient segfaults
<anuejn> is that a... common error?
_whitelogger has joined #scopehal
<electronic_eel> anuejn: what kind of graphics card are you using? which drivers for the graphics card?
<electronic_eel> do other programs that use OpenGL work for you?
<azonenberg> anuejn: it sounds like there are two separate issues here
<azonenberg> one is something is wrong with your graphics driver/card setup
<azonenberg> two is that glscopeclient handles this case wrong and crashes rather than nicely displaying an error and quitting
<azonenberg> You say "segfault" which implies you're on linux, what distro/graphics card/drivers? can you pastebin a glxinfo?
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #165: Add progress dialog when loading files - https://git.io/JUGvL
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #165: Add progress dialog when loading files - https://git.io/JUGvL
<anuejn> ah yeah sorry for the bad report
<anuejn> I am on archlinux
<anuejn> with a fairly recent intel gpu (UHD Graphics 620)
<anuejn> other opengl software works fine for me
<azonenberg> Paste a glxinfo and let's see?
<azonenberg> glscopeclient should run on integrated graphics as old as, i think, haswell and broadwell
<azonenberg> i know as of a few weeks ago it worked on skylake integrated gfx
<anuejn> https://hastebin.com/tujatihome.py is my glxinfo output
<azonenberg> you have GL 4.6, GLSL 4.60, and GL_ARB_gpu_shader_int64. So it should work
<azonenberg> interesting
<anuejn> i am on kabylake so definitely newer
<anuejn> yeah thats what i figured when looking at the system requirements
<azonenberg> Give me a little bit to work on fixing some other graphics related stuff i'm fixing
<anuejn> no pressure
<azonenberg> Then i'll try and work on the GL init stuff so it prints a niec error message and aborts gracefully
<anuejn> okay nice :)
<azonenberg> that should eliminate the segfault and help us debug better
<electronic_eel> will an strace show something helpful?
<azonenberg> Doubtful
<azonenberg> there are specialized GL tracing tools that might be good for this
<azonenberg> but first step is to make it not crash. We should not segfault ever under any circumstances even if the system is too broken for us to *run* on
<electronic_eel> yeah, right. so gdb and backtrace?
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JUGvM
<_whitenotifier-f> [scopehal-apps] azonenberg 8f36d81 - Optimizations to file loading. Fixes #163.
<_whitenotifier-f> [scopehal-apps] azonenberg 56c99a5 - Don't re-render half loaded content many times and waste CPU time during file loading
<_whitenotifier-f> [scopehal-apps] azonenberg closed issue #163: OscilloscopeWindow::LoadWaveformDataForScope() is slow, calling push_back vs allocating once and writing to buffer - https://git.io/JUsg3
<miek> do you get reasonable output from `glewinfo`?
<azonenberg> electronic_eel: That won't help either. We will just see a bad pointer deref trying to use some buffer returned by GL when GL didn't initialize right
<azonenberg> I need to a) abort cleanly with an error if GL init fails
<azonenberg> and b) figure out why GL is failing to init on his system
<azonenberg> looking at the point of the crash won't tell us anything
<azonenberg> miek: didnt know that was a thing, but it's worth trying
<miek> also, try patching the glewInit call to print the error? something like this: https://github.com/nigels-com/glew/blob/6f31e134f66e05c02b15cb568d731700374bb91d/auto/src/glewinfo_tail.c#L58LL64
<anuejn> https://hastebin.com/unufifijaf.diff is the output of glewinfo
<miek> i guess 'MISSING' for the higher 'GL_VERSION_*'s is a bad thing, mine's got 'OK' all the way up to 4_6
<anuejn> oh that is wired
<azonenberg> It's also not seeing GL_ARB_gpu_shader_int64. Which was there in the glxinfo dump
<azonenberg> anuejn: Try running "glewinfo -profile core" and "glewinfo -profile compatibility"
<azonenberg> i don't know which one it defaults to
<anuejn> when i set MESA_LOADER_DRIVER_OVERRIDE=iris i get this glewinfo output: https://hastebin.com/katelinuda.diff
<azonenberg> And when you do that does glscopeclient run?
<anuejn> glscopeclient however doesnt start but gives a slightly different error
<azonenberg> What's the new error?
<anuejn> "ERROR: Error: Failed to initialize GLEWERROR: Error: Failed to initialize GLEWERROR: Error: Failed to initialize GLEWERROR: Error: Failed to initialize GLEW[1]"
<azonenberg> Interesting
<azonenberg> it's pritning the error 4 times, btw, because there is one GL context for each WaveformArea
<azonenberg> and each one is failing in turn (presumably you have a 4 channel scope or are loading a waveform from one)
<azonenberg> That's another bug, it should print a newline after each error :p
<miek> i thought that was the error you got before?
<anuejn> ah no it is the same error but the message was printed differently due to a different shell
<azonenberg> miek: previously it was printing one copy and crashing
<anuejn> sorry
<azonenberg> oh
<anuejn> the [1] is appearently added by my zsh
<azonenberg> Ok, i'm working on getting more info
<azonenberg> should have new code pushed momentarily
<anuejn> glewinfo -profile core results in https://hastebin.com/otecarogog.diff
<anuejn> glewinfo -profile compatibility results in https://hastebin.com/heloneruke.diff
<anuejn> (both without the driver override)
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±4] https://git.io/JUGf6
<_whitenotifier-f> [scopehal-apps] azonenberg 3422ab2 - WaveformArea: no longer stretch digital samples to 2 points. Halves GPU memory bandwidth/capacity requirement for digital traces and simplifies code.
<_whitenotifier-f> [scopehal-apps] azonenberg ff35f7e - Fixed bad styling on message dialogs making text hard to read
<_whitenotifier-f> [scopehal-apps] azonenberg 926ada6 - WaveformArea: display nicely formatted error and abort if GL init fails, rather than crashing
<_whitenotifier-f> [scopehal-apps] azonenberg commented on issue #66: Check Minimum System Requirements on glscopeclient startup - https://git.io/JUGfP
<_whitenotifier-f> [scopehal-apps] azonenberg closed issue #66: Check Minimum System Requirements on glscopeclient startup - https://git.io/JvEYP
<azonenberg> anuejn: Try rebuilding glscopeclient with these updates and see if you at least get a nice error rather than a crash
<anuejn> okay :)
<azonenberg> and hmmmm very interesting that even with -profile core you get a 3.0 context in glewinfo
<azonenberg> When you specify the driver override does glscopeclient run now?
<anuejn> regardless of the driver override
<miek> doh
<azonenberg> lol
<azonenberg> that's... very helpful
<azonenberg> It's not a crash though, which is something
<azonenberg> And when you close the error does it abort cleanly? no segfault?
<anuejn> yup
<azonenberg> I wonder if GL itself isn't initializing right because glscopeclient gets a 3.0 context when it asks for a 4.3
<azonenberg> let me add some more checks, sec
<miek> maybe print the error as an integer too, might point to something useful
<azonenberg> I'm printing more info now, gimme a bit
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUGJg
<_whitenotifier-f> [scopehal-apps] azonenberg 9d6dad9 - Added lots of additional GL debug info to WaveformArea
<azonenberg> anuejn: try glscopeclient with this and run with --debug
* monochroma smells a broken driver install
<azonenberg> this will let us know if we actually got a valid GL context and what version etc
<azonenberg> monochroma: it's intel integrated gfx though
<azonenberg> those normally are hard to break?
<monochroma> azonenberg: yes
<monochroma> i seem to remember something goofy with arch as well
<monochroma> i think there were 2 KOs that could get used, and one is for older GPUs
<Bird|otherbox> btw: RX560 is on its way over here (will take a little while to get here I reckon, but that's OK). also, going to give your error-handling fixes a looksee as a "known failure" case :)
<azonenberg> Bird|otherbox: great
<Bird|otherbox> and yeah, your error-handling stuff works :) prints what I expect (which is GL 3.3)
<azonenberg> to the console? then is there a nice popup saying it couldn't initialize and aborts?
<azonenberg> or what
<azonenberg> (the console print is just for investigating problems in more detail and isn't intended to be the main way users see the error)
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JUGUq
<_whitenotifier-f> [scopehal-apps] azonenberg 4648738 - Added GL_ARB_gpu_shader_int64 check to OpenGL init
<_whitenotifier-f> [scopehal-apps] azonenberg 82fa512 - Waveform rendering: improved display of digital signals
<azonenberg> Bird|otherbox: also try that
<Bird|otherbox> ah :) probably a moot point :p
<Bird|otherbox> but probably a good idea to have that anyway
<Bird|otherbox> to the console
<Bird|otherbox> btw
<azonenberg> Yeah the console print is intended for further troubleshooting of specific problems
<azonenberg> But i dont want to assume the user is running the app in a shell vs from a launcher icon or something
<azonenberg> especially on e.g. windows
<Bird|otherbox> *a nod*
<Bird|otherbox> the dialog boxes don't get a chance to render fully before the app aborts when I run it from a terminal
<azonenberg> Hmmm
<Bird|otherbox> but that might just be a function of my box
<azonenberg> that's interesting, it shouldn't abort until you press OK
<Bird|otherbox> ah, I don't actually get an error dialog in my case it looks like
<Bird|otherbox> but it's probably not a huge concern
<azonenberg> It is, because it means i still have a bug
<azonenberg> Lol
<azonenberg> i'm fixing something else but will work on it shortly
<anuejn> azonenberg: I get https://hastebin.com/joxatubaje.nginx
<azonenberg> anuejn: not working for me
<azonenberg> just looks like an empty file
juli965 has joined #scopehal
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 2 commits to master [+2/-1/±5] https://git.io/JUGT6
<_whitenotifier-f> [scopehal-apps] azonenberg 6acc20f - Refactoring: split analog and digital waveform rendering into separate shaders
<_whitenotifier-f> [scopehal-apps] azonenberg 1bea078 - Waveform rendering: now memcpy packed bools directly to GPU for digital waveforms, rather than doing messy bool to float conversion. Fixes #164.
<_whitenotifier-f> [scopehal-apps] azonenberg closed issue #164: Optimize digital waveform generation loop in WaveformArea::PrepareGeometry() - https://git.io/JUsgZ
<azonenberg> well that right there is about a 2x speedup, not a bad start
<azonenberg> but it still takes about 6 seconds to render a frame with this massive chunk of data
<azonenberg> and hmm it seems i have a significant performance regression from the int64 timestamps?
<azonenberg> the CPU side is a lot faster but the GPU side is slower
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±14] https://git.io/JUGI2
<_whitenotifier-f> [scopehal-apps] azonenberg 10b0e80 - WaveformArea rendering: don't push new Y axis values every time we scroll a little
<_whitenotifier-f> [scopehal-apps] azonenberg b11ddcb - Multithreading and better coordination of rendering
<_whitenotifier-f> [scopehal-apps] azonenberg 6fcae18 - Removed PrepareAllGeometry()
juli965 has quit [Quit: Nettalk6 - www.ntalk.de]
<azonenberg> oh derp
futarisIRCcloud has joined #scopehal
<anuejn> azonenberg sorry, next try: https://paste.debian.net/1162799/
<azonenberg> So you're using GL 4.6. And it still gives the error about glew failing to initialize?
<azonenberg> That is *weird*
<anuejn> yup
<anuejn> somehow glewinfo seems to be wrong?
<anuejn> s/glewinfo/glew/