<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JaH0f
<_whitenotifier-1>
[scopehal] azonenberg 4b3d282 - UARTDecoder: display nonprintable characters as "." in ascii decode
mikolajw has joined #scopehal
bvernoux1 is now known as bvernoux
<mikolajw>
hello
<azonenberg>
o/ mikolajw
<mikolajw>
question: is glscopeclient viable or will be viable for integration with KiCad?
<mikolajw>
there are some ambitious plans with FEM and SPICE simulations, this may require getting a better waveform viewer (current lacks some features)
<mikolajw>
I don't like the idea of duplicating features of another open source project, so if glscopeclient has capabilities that can be used in KiCad, then maybe something could be arranged
<mikolajw>
so far as I see glscopeclient is more dedicated to real-time data acquisition. KiCad does not have real time simulations so far, and I doubt we'll get them any time soon (but who knows). So one question is whether glscopeclient is suitable for browsing pre-generated waveforms
<mikolajw>
I've managed to run it on my PC, but after a few seconds of running the "demo" signal source my whole OS froze
<azonenberg>
Yes, glscopeclient is usable for offline data analysis. As well as simulation to some extent
<azonenberg>
for example you can generate an ideal unit step then apply a channel emulation filter to see what it would look like through an arbitrary 2-port network described by a touchstone file
<azonenberg>
in both the transmitted and reflected directions
<azonenberg>
The project is still very much a WIP and there's bugs, GPU hangs are one of the things I need to address
<azonenberg>
I suspect there's bugs in the shaders still that i need to track down
<azonenberg>
but debug at this level is... not easy
<mikolajw>
great
<azonenberg>
Fixing them is one of the things on the to-do before I make an official release
<mikolajw>
I see that OpenGL 4.2 or higher as well as some extensions are required, how much of a problem that may be?
<mikolajw>
I think the signals didn't render correctly on my screen, the waveform curves weren't continuous, there were some odd "holes"
<azonenberg>
So, the current rendering engine is entirely GPU compute based
<azonenberg>
you need OpenGL compute shader support
<azonenberg>
It is definitely possible to build a Cairo or OpenCL based renderer that loses some performance
<azonenberg>
(This would probably also avoid the GPU hangs with the current renderer, but the better solution of course is to fix the bugs)
<azonenberg>
All of the DSP under the hood does not require any special GPU features although some filters will take advantage of OpenCL if present
<azonenberg>
We actually have a pending to-do item of writing an OpenCL based renderer in order to enable Mac support
<azonenberg>
since no apple platform currently has OpenGL 4.3 support
<azonenberg>
i think the M1 has 4.1 but that's it
<mikolajw>
great, any ideas for possible caveats?
<azonenberg>
Performance is the main one, I don't know how fast it will be in comparison. A software renderer will definitely be a lot slower
<azonenberg>
but that really is less of an issue for simulation
<azonenberg>
glscopeclient was built for raw number crunching speed, being able to easily pan and zoom through a 100+ million point waveform
<azonenberg>
or stream waveform data into your PC over 10GbE
<azonenberg>
running a sim with a few thousand points is trivial by comparison
<mikolajw>
this is very good if KiCad will ever be used to run massive simulations
<mikolajw>
and having the same UI for displaying data from oscilloscopes and SPICE simulation sounds like a massive advantage
<azonenberg>
Yeah. You will also have access to the full complement of glscopeclient protocol decodes if we integrate it properly
<azonenberg>
so for example, you could simulate a PRBS through a circuit model
<azonenberg>
then use glscopeclient to recover a clock and display an eye pattern
<azonenberg>
There is almost certainly going to be a lot of work to do on the GUI side to make it easier to integrate with external tooling; so far I've only ever used glscopeclient itself standaline
<azonenberg>
The code probably will need some refactoring, but it's going to need that anyway
<azonenberg>
libscopehal and libscopeprotocols are highly modular and easy to plug into existing code already
<azonenberg>
or use in headless ATE systems etc
<mikolajw>
OpenGL 4.2 is too high for KiCad to require
<mikolajw>
is lowering the OpenGL requirements an option?
<bvernoux>
Will be nice to use OpenGL 2.1 or more
<bvernoux>
and of course to have max performance on something recent like today
<bvernoux>
But it clearly seems it is not an easy step ...
<bvernoux>
Using ImGui could help a lot I think but it is mainly to remove GUI dependency with native OpenGL UI
<GenTooMan>
what features do you require in KiCAD that require a higher order OpenGL, has this to do with the 3d view and export?
<GenTooMan>
I'm asking because not every platform that might run KiCAD supports OpenGL particularly well.
<azonenberg>
mikolajw: Not with the current renderer
<azonenberg>
like i said, all rendering right now is done in compute shaders
<azonenberg>
and those don't exist prior to 4.3, or 4.2 with extensions
<azonenberg>
The waveform renderer is however a fairly small portion of the overall codebase
<azonenberg>
A fallback renderer for systems with older GPUs is definitely on the wishlist
<azonenberg>
The cursors, decode overlays, etc are all done in Cairo
<azonenberg>
then the final compositor and tone mapping is super trivial shaders that probably run on opengl 2.x, definitely 3.x no problem
someone-else has quit [Quit: Connection closed]
<mikolajw>
GenTooMan: um, in KiCad we generally use older OpenGL, not newer
<mikolajw>
the default (non-raytracing) 3D viewer is OpenGL 2
<GenTooMan>
mikolajw, hence the asking :D
<GenTooMan>
mikolajw, scopehal is a different thing all together however :D
<mikolajw>
aaa, you're asking what is the highest OpenGL version feature we use
<mikolajw>
I think the hardware renderer in Eeschema and Pcbnew uses OpenGL 3.1 or 3.2
<mikolajw>
no, wrong, it uses OpenGL 2.1
<mikolajw>
#version 120
<mikolajw>
Thus, I can try to make an OpenGL 2.1 fallback renderer for GLScopeClient, but it will take time (and my knowledge of OpenGL is shallow)
<azonenberg>
mikolajw: the problem is that it's a complete rewrite not a port
<azonenberg>
there's no opengl polygon geometry
<azonenberg>
no vertex or fragment shaders
<azonenberg>
the compute shader takes in a vector of fp32 voltages and outputs a texture
<azonenberg>
That's not something you can trivially port to old GL
<azonenberg>
you'd need a completely different renderer, perhaps using GL_LINE_STRIP
<mikolajw>
then what is the lowest OpenGL version that GLScopeClient can support as a fallback?
<azonenberg>
As of right now? 4.2 + GL_ARB_compute_shader is non-negotiable
<azonenberg>
it simply won't run on anything older
<azonenberg>
the entire compute shader paradigm is nonexistent on older GL
<azonenberg>
This is a forward looking project, in another few years hardware without 4.2 support will be dinosaurs nobody cares about
<azonenberg>
i mean, even now... you know what doesn't support it?
<azonenberg>
intel integrated graphics earlier than broadwell
<azonenberg>
and discrete amd/nvidia cards more than about a decade old
<mikolajw>
wait, so are you saying that a rewrite of these features in a lower OpenGL version is not acceptable, or that it will take a lot of work?
<azonenberg>
I'm saying that it's architecturally incompatible and you would need a completely new renderer from scratch
<mikolajw>
ok, but this also applies to software rendering, yes?
<azonenberg>
The easiest way to get a basic fallback renderer is probably to skip GL entirely and do it in cairo
<azonenberg>
we already support rendering cairo to textures and then compositing uisng GL ~2.x
<azonenberg>
it would be horribly slow, but work on basically anything
<azonenberg>
(since that's what we do a lot of the UI chrome like graph axes and cursors in )
<azonenberg>
Then at some point in the future you could try writing an accelerated waveform renderer using older GL and/or OpenCL
<mikolajw>
ok, I can try to get it going in Cairo somewhere in the future (not before KiCad V6 is released)
<azonenberg>
Yeah i mean glscopeclient v0.1 is a ways off too
<azonenberg>
Was hoping to finish it before the baby came
<azonenberg>
That didn't happen
<azonenberg>
So now my availability is... more limited
<mikolajw>
let's stay positive about this
* GenTooMan
becomes positively negative.
<GenTooMan>
azonenberg, now if you can teach the baby c++ early on ...
<azonenberg>
lol
<azonenberg>
I already ordered a "computer engineering for babies" book
<azonenberg>
we'll start with hardware
bvernoux has quit [Quit: Leaving]
<GenTooMan>
LOL heh I'll have to tell my dad that one he'll laugh a long time on that thought.
<GenTooMan>
well their is also the issue with software that sometimes the lack of proper constraints can create utter chaos in development.
someone-else has joined #scopehal
<GenTooMan>
I always cringe when someone says "it's only software we can change it"
<azonenberg>
Also wooo AKL-AD3 amplifier board with ground plane shipped, ETA Weds
<azonenberg>
Enclosure should be coming Weds too
<azonenberg>
Which means i'll get to test it on the VNA, the scope with pulse generator, and also the Siglent SSG
<azonenberg>
I was afraid the amplifier would come after i had to give it back
<GenTooMan>
serendipitous I guess things came out just about right for you then.