<_whitenotifier-1>
[scopehal-apps] azonenberg cf9caf3 - Removed -Wunsafe-loop-optimizations since we don't use -funsafe-loop-optimizations and it just spams warnings that don't matter
<_whitenotifier-1>
[stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±5] https://git.io/Ji3A5
<_whitenotifier-1>
[stm32-cpp] azonenberg 5d75634 - Initial STM32F7 HASH support
<d1b2>
<Chuck> Did a pull and another cmake (I'm using 3.22 fwiw) and see this warning https://pastebin.com/qCQMsX40
<d1b2>
<Chuck> But it does seem to find the YAML package so there is that.
<d1b2>
<Chuck> Still not sure why there is no catch2.hpp in the Catch2 release
<d1b2>
<Chuck> make that catch.hpp which apparently is the "single include" version of catch2
<d1b2>
<Chuck> that said, apparently cat /usr/local/include/catch2/*.hpp > /usr/local/include/catch2/catch.hpp is sufficient
Bird|otherbox has quit [Remote host closed the connection]
Bird|ghosted has joined #scopehal
Degi has quit [Ping timeout: 244 seconds]
Bird|ghosted has quit [Ping timeout: 260 seconds]
Degi has joined #scopehal
Bird|otherbox has joined #scopehal
Bird|otherbox has quit [Remote host closed the connection]
Bird|otherbox has joined #scopehal
<d1b2>
<Chuck> hmm, no args to glscopeclient and I get "no platforms found, disabling OpenCL"
<d1b2>
<Chuck> not very promising
<d1b2>
<Chuck> followed by 'seg fault core dumped' hmm maybe the loop warnings were telling me something useful
<d1b2>
<Chuck> --debug tells me that OMP_WAIT_POLICY is not set and so it re-exec's with the "correct" environment, detects CPU features AVX2 and FMA, skips OpenCL (since --noopencl) and then dumps core.
<azonenberg>
Can you get a backtrace of where it's failing?
<azonenberg>
also no, the loop warnings are harmless
<azonenberg>
I pushed updated code to remove them
<azonenberg>
tl;dr -Wunsafe-loop-optimizations only means anything if you also have -funsafe-loop-optimizations, which I do not
<azonenberg>
So it's crashing deep in the guts of GTK
<azonenberg>
When we call show_all()
<d1b2>
<Chuck> Its running on an Intel chip with a built-in GPU and no CL support
<azonenberg>
Yeah that's fine, it detects that and disables CL
<azonenberg>
you're not even getting to the point it tries to initialize opengl
<d1b2>
<Chuck> Did you see the yaml warning I mentioned earlier with the cmake ../ step?
<azonenberg>
which one?
<azonenberg>
this isn't yaml related though
<azonenberg>
it's quite strange, it's dying trying to initialize an X11 cursor object
<d1b2>
<Chuck> Just complaining about the package might not be found, and then it finds it
<azonenberg>
and then hits a null mutex
<d1b2>
<Chuck> I am using lubuntu desktop
<azonenberg>
Yeah gimme a minute i'm thinking/investigating
<azonenberg>
While i'm looking into this, try doing cmake -DCMAKE_BUILD_TYPE=DEBUG -DSANITIZE=ON to enable asan
<azonenberg>
You will also need to export ASAN_OPTIONS=new_delete_type_mismatch=0 to suppress an error triggered somewhere in the bowels of GTK (which I think is unrelated to your crash)
<d1b2>
<Chuck> okay, just about done doing the MAKE_BUILD_TYPE=DEBUG but will restart shortly.
<d1b2>
<Chuck> currently rebuilding
<d1b2>
<Chuck> Okay, THAT build brought up a window and didn't crash.
<d1b2>
<Chuck> Did all three items (export ASAN_OPTIONS, change cmake to DEBUG and SANITIZE=ON)
<d1b2>
<Chuck> GTK whines: Gtk-Message: 20:39:36.031: GtkDialog mapped without a transient parent. This is discouraged.
<d1b2>
<Chuck> And I thought there was Digilent AD2/Analog Explorer support but perhaps that is in development?
<d1b2>
<Chuck> Sigh, trying to connect to my tektronix I get "No provider of glGenVertexArrays found." and a SIGABRT
<azonenberg>
That's in development, but not complete
<azonenberg>
(digilent waveforms support)
<azonenberg>
for the latter, that sounds like maybe your GPU is too old. you said integrated intel, what generation CPU?
<d1b2>
<Chuck> Intel Core i3-8109U
<d1b2>
<Chuck> So I've tried it two ways, one remoted via X11 to my threadripper and running on the native display. The latter gives a sanitize error
<azonenberg>
That's a coffee lake, it should easily handle the opengl requirements we have
<azonenberg>
minimum is like broadwell or something
<azonenberg>
Are you running wayland or x11 locally?
<azonenberg>
And what's the sanitize error?
<azonenberg>
We have ongoing issues getting it to work under wayland but are actively working on them
<azonenberg>
there's a pending PR i need to resolve
<azonenberg>
The sanitize error might be related to your crash
<d1b2>
<Chuck> So when running locally it's likely wayland, when remoted it is X11
<d1b2>
<Chuck> not sure how to ask the system what compositor it is using
<azonenberg>
Well we've never tried running over x forward so i have no idea how it would perform but my guess is poorly
<azonenberg>
wayland is known iffy
<azonenberg>
Have you tried locally on the threadripper box?
<azonenberg>
if that is running native x11?
<azonenberg>
or xwayland on your main machine?
<d1b2>
<Chuck> main box runs windows mostly because my CAD software requires it. Running on WSL is likely another variable I'd rather not add. I have a Core i7 box running Ubuntu 18.04 but it too uses the native Intel GPU
<d1b2>
<bob_twinkles> if by "remoted in to X11" you mean via "ssh -X", the likelyhood of that using anything but software GL is very low
<d1b2>
<Chuck> Correct Bob, software GL is likely.
<d1b2>
<Chuck> azonenberg: are you okay with PRs even if they rewrite big chunks of the graphics code to be more portable across platforms?
<azonenberg>
yeah software GL with compute shaders isnt going to happen
<azonenberg>
We support running on windows under mingw
<azonenberg>
as far as rewriting graphics code, I'm OK with alternate renderer implementations for fallback as long as there's a good way to switch between them
<azonenberg>
the actual GL rendering is a fairly small portion of the overall codebase
<d1b2>
<Chuck> k
<azonenberg>
it's basically one main shader and a trivial compositor that will run on ~anything
<azonenberg>
We actually will need that for OSX support because apple doesn't like open standards because they're apple
<d1b2>
<Chuck> The thing is the NUC box is my 'portable' box which I take with me on the road, typically driving a Digilent AD2, and it has compile environments for STM32 and RISCV and FPGA environments for Lattice and Xilinx FPGAs.
<azonenberg>
so none of their platforms support anything opengl past 4.1
<azonenberg>
Well, AD support is pending but not done yet
<d1b2>
<Chuck> Yeah, but looking around the code base will familiarize myself with how it gets stuff done. And I'm happy to send suggestions either as issues or PRs. But not everyone is open to PRs so I thought I would ask.
<d1b2>
<Chuck> Things like: //Assume hyperthreading is enabled and only use one thread per physical core
<d1b2>
<Chuck> on Intel boxes nearly everyone turns off hyperthreading because of the side channel attacks.
<d1b2>
<Chuck> So I'd put this code behind an option flag (as a suggestion)
<d1b2>
<Chuck> It will also segv if someone runs it on a VM and they have only turned on one core 🙂
<azonenberg>
That's just a performance optimization
<azonenberg>
worst case it will oversubscribe cores / not fully utilize them
<azonenberg>
as far as "nearly everyone turns off hyperthreading" the only box i have it disabled on is my xen server
<azonenberg>
which is ironically the one that would benefit most from it :p
<d1b2>
<Chuck> okay, you call omp_set_num_threads with 0 and it fails nicely? That's awesome.
<azonenberg>
thinking of replacing the cpu on that with something a gen or two newer so i can turn ht back on
<azonenberg>
I think so
<d1b2>
<Chuck> cool
<azonenberg>
oh wall in a VM, it will fail for other reasons anyway
<d1b2>
<Chuck> heh
<azonenberg>
because the vm won't have opengl 4.x support :p
<azonenberg>
Unless you have a pcie passthrough gpu
<azonenberg>
but then your probably have >1 core
<d1b2>
<Chuck> As I recall VirtualBox with VBoxExtensions has opengl 4 support but I haven't installed it in a while so I may be misremembering.
<azonenberg>
The latest i know is maybe 3.3-4.1
<azonenberg>
i'm not aware of any emulated gpu with compute shader support
<azonenberg>
and that isnt a "oh it makes things look prettier" nice to have
<azonenberg>
the entire renderer is one big compute shader
<d1b2>
<Chuck> "curly braces go on their own line" is something the guy who programmed using 80 x 24 line terminals cringes at 🙂
<_whitenotifier-1>
[scopehal] ChuckM forked the repository - https://git.io/JYTzK
<azonenberg>
Chuck: I got my start in borland C++ on win 3.1, but visual studio 98 is where i really solidified most of my habits
<_whitenotifier-1>
[stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JiGct
<_whitenotifier-1>
[stm32-cpp] azonenberg a384ec5 - Logger now uses 10 kHz timer instead of 1 kHz
bvernoux has joined #scopehal
someone-else has joined #scopehal
<Degi>
Ooh, you don't need to enable vernier scale on the Rigol MSO5000 to set it to any value
someone-else has quit [Quit: Connection closed]
<Degi>
Interesting, the FSR of the MSO5000 seems to be 10.1 to 10.5 divs instead of 8 divs
<d1b2>
<dannas> I'm trying to connect glscopeclient to my Siglent SDS1104X-E. According to https://github.com/azonenberg/scopehal/issues/341 the SDS1104x-e support should be in a workable state. Time to start wireshark.
<d1b2>
<dannas> Doh, and there's my time up for today. Man it's hard to be productive when you only got 30-45min of sparetime per day. 🙂
<d1b2>
<dannas> If I click on the x to quit the application, I get a notification from Ubuntu that the app does not respond, do you like to kill it. Will investigate that as well. Uhm, on friday when I'm back at home.
<sajattack[m]>
dannas, I'd like to follow in your footsteps, please continue sharing your progress :)
bvernoux has quit [Quit: Leaving]
someone-else has joined #scopehal
<miek>
azonenberg: i just noticed that the lecroy digital channels are marked as densepacked, is that correct?
<azonenberg>
miek: let me look at the driver, sec
<azonenberg>
Yeah that looks like a bug, they shouldn't be
<azonenberg>
let me fix that
<azonenberg>
That was probably an artifact from before we added deduplication
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JiZMA
<_whitenotifier-1>
[scopehal] azonenberg 20bcaef - LeCroyOscilloscope: don't mark waveforms as dense packed because they're deduplicated
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JiZMp
<azonenberg>
This probably won't break much because the digital filters normally sample on clock edges first, and then give you sparse upper layer waveforms
<azonenberg>
I don't think any digital filters (that we currently have) actually assume the channels are equal rate
<azonenberg>
however it would have become a problem once i implement things like bitwise operations on digital channels