Degi has quit [Ping timeout: 248 seconds]
Degi_ has joined #scopehal
Degi_ is now known as Degi
<
azonenberg>
Well, today was busy. Got a lot done but not as much scopehal related
<
azonenberg>
I did come up with some ideas on how to improve the AKL-PT1 though
<
azonenberg>
having a friend throw together some mechanical prototypes
<
azonenberg>
Also siglent engineering got back to me, there is an undocumented SCPI command to change the ADC from 8 to 10 bit mode on the SDS2000X+
<
azonenberg>
now i know what it is so i can add the switchable ADC mode to the siglent driver
<
azonenberg>
i havent had time to code it up but knowing the command was the hard part
nelgau_ has joined #scopehal
nelgau has quit [Ping timeout: 256 seconds]
massi has joined #scopehal
Stephie has quit [Quit: Fuck this shit, I'm out!]
Stephie has joined #scopehal
jacekowski has quit [Ping timeout: 245 seconds]
vup has quit [Remote host closed the connection]
vup has joined #scopehal
gruetzkopf has quit [Quit: No Ping reply in 180 seconds.]
jacekowski has joined #scopehal
kbeckmann has quit [Ping timeout: 240 seconds]
gruetzkopf has joined #scopehal
kbeckmann has joined #scopehal
massi has quit [Remote host closed the connection]
nelgau_ has quit [Ping timeout: 272 seconds]
<
balrog>
anyone here building in WSL2?
<
balrog>
and/or without installing ffts or catch2 in /usr?
<
balrog>
(I don't like polluting my /usr)
<
balrog>
oh I see what's up, catch in git is v3 now
<
azonenberg>
balrog: yeah you can disable testing for now
<
azonenberg>
we only have like 2 unit tests at the moment
<
azonenberg>
many more are needed :p
nelgau has joined #scopehal
<
balrog>
Probably might as well update to Ubuntu 22.04 anyway
<
balrog>
20.04 is getting old
<
azonenberg>
as far as wsl2, i dont know if anyone is tried. the current officially supported windows flow is via mingw/msys2
<
balrog>
if mingw/msys2 is supported then porting to MSVC/Visual Studio would be doable
<
balrog>
WSL2 should basically be linux
<
balrog>
but, ubuntu 20.04 mainly
<
azonenberg>
and yes lots of optinons for running on windows to explore
<
azonenberg>
but probably 95%+ of the userbase are on linux
<
azonenberg>
so the windows port doesnt get a ton of attention
<
azonenberg>
the main thing to be aware of is that right now we require opengl 4.3+ which is not available by any virtualized GPU i know of
<
balrog>
yeah, and with wsl2 it's less likely it needs that much attention
<
azonenberg>
so running in a VM is out
<
azonenberg>
unless you pcie passthru an entire GPU
<
balrog>
I think there's even gpu passthrough for wsl2 but I'm not sure
<
balrog>
hmm, maybe not
<
balrog>
could use llvmpipe but it will likely be slow
<
azonenberg>
yeah the main thing is just that compute shaders are a non negotiable requirmeent for the current renderer
<
azonenberg>
there is early experimentation wrt using an opencl based renderer
<
azonenberg>
which would only use opengl 3.x
<
azonenberg>
but it's incomplete and falls back to compute shaders for histograms and some other stuff
<
azonenberg>
this would theoretically allow you to run on any opencl capable gpu or even fall back to software in a pinch
<
balrog>
opencl or vulkan would be the way to go, but that means rewriting the whole renderer...
<
azonenberg>
yeah. and vulkan is off the table until gtk4 (at least) starts shipping in stable/LTS distros
<
azonenberg>
and well, the render is compositor based
<
azonenberg>
individual waveforms use a compute shader to draw the analog waveform data to a grayscale fp32 texture
<
azonenberg>
then i draw three full-viewport polygons for each plot
<
azonenberg>
one with software rendered grid/background
<
azonenberg>
another using a fragment shader to turn the fp32 texture into an rgba image
<
azonenberg>
and finally software rendered overlays like cursors and annotations
<
azonenberg>
That fp32 data can come from anywhere though
<
azonenberg>
including but not limited to opencl or vulkan
<
azonenberg>
the thing is, other than that one shader that renders the waveform
<
azonenberg>
all the rest is fairly basic opengl 3.x, maybe even 2.x
<
azonenberg>
but that one shader, and the host side support calls to set up the buffers etc for it, is complex
<
azonenberg>
for one, the shader is compiled with like six different sets of #defines in different permutations
<
azonenberg>
to support rendering lines only or lines with fill underneath
<
azonenberg>
linear interpolation or boxy rectangles (for histograms)
<
azonenberg>
and using software bignum for 64-bit integer math or native int64 support
<
azonenberg>
oh and boolean vs fp32 y-axis data
<
azonenberg>
for digital vs analog
<
azonenberg>
So depending on what kind of waveform is being drawn and what GPU you have you could be invoking several differnet sub-shaders
<
azonenberg>
although all are based on the same source tree
<
balrog>
works with llvmpipe :D
<
balrog>
then used MESA_LOADER_DRIVER_OVERRIDE=llvmpipe
<
balrog>
getting about 22 WFM/s with demo
<
balrog>
chewing up ~30% CPU
<
balrog>
so yep, you can run it in a VM using llvmpipe, it seems
<
azonenberg>
Oh interesting
<
balrog>
I'd also test on an M1 Mac but I don't have an M1 Mac at the moment
<
balrog>
though I expect software rendering on Asahi Linux to perform decently
<
balrog>
VM, probably less so
<
azonenberg>
Yeah. anyway, that's good to know wrt compatibility
<
azonenberg>
not everyone is working with massive ultra deep waveforms
<
azonenberg>
so an easy software fallback is handy to know about
<
balrog>
and being able to use it
*at all* on most any hardware is nice... yeah
<
azonenberg>
file a ticket against scopehal-docs with that info
<
azonenberg>
and if/when you get a chance see about sending a PR with more formal instructions?
<
azonenberg>
but for now i just want to have the info writtne down somewhere
<
balrog>
I'd like to fix some stuff with the docs too
<
balrog>
(the copy paste primarily)
<
azonenberg>
Yes, ideally i want pretty listings that are also copyable
bvernoux has quit [Read error: Connection reset by peer]