<azonenberg>
also vkFFT upstream just added a fix for the thread safety issue
<azonenberg>
i will probably continue to run a fork just in case we have to make other patches
<azonenberg>
but i'll sync it with upstream periodically
<Degi>
Neat
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<d1b2>
<johnsel> I see that we are all on the same page w.r.t. GTK now lol
<azonenberg>
Yeah. Initially we had a lot of vague complaints but no hard reasons to leave, but it would be a major engineering effort to transition to something else
<azonenberg>
but as of yesterday's experiments, while evaluating performance of some new GPU code
<azonenberg>
i now have strong evidence that GTK is limiting us
<azonenberg>
And for a HPC type application, it's worth that extra effort. Gotta go fast </sonic>
<d1b2>
<johnsel> I think it's a really reasonable plan though and direction that you propose/decided, I have some thoughts but Its pretty late so I will formulate them better tomorrow, only building upon what is already proposed
<d1b2>
<johnsel> and I thought it was self-evident, you measured what I jokingly called Pidgin performance
<azonenberg>
johnsel: There will be another developer zoom call some time later this month
<azonenberg>
Feel free to drop in and give your thoughts then as well
<d1b2>
<johnsel> yes I read everything back, I will definitely be there
<azonenberg>
Just need to get some of the current action items straightened out (e.g. ditching openCL/clFFT fully) and then write up agenda etc for the meeting
<d1b2>
<johnsel> We might also want to rethink build automation etc in the context of the future direction. E.g. w.r.t. working in the same repo vs another
<azonenberg>
Yeah. I think keeping it in one repo makes sense, as a new binary within scopehal-apps. this will let us, for example, maintain history as we move/copy source files from the existing code into the new app
<d1b2>
<johnsel> but also more general, define an 'ideal' setup from that perspective and work back to what is realistic
<azonenberg>
There are also some other utilities within scopehal-apps, like psuclient (for power supplies)
<azonenberg>
which eventually are planned to merge into a single unified app
<d1b2>
<johnsel> yeah we can argue about it some other time, I think there's a lot of value in having it in a separate repo to start fresh and e.g. having the old repo as a submodule w.r.t. build speed and losing the CI baggage
<azonenberg>
So there's no reason we can't "make foo" vs just "make" to not build the other stuff. i can even make it opt-in in cmake
<azonenberg>
that said, i want CI builds as early as possible of the test app
<d1b2>
<johnsel> sure but from a repo standpoint, you kick off the builds from all commits to old & new
<d1b2>
<johnsel> which are still in pretty bad shape, we can do a 1 minute build on the clean app and perfectly define dependencies from the start
<azonenberg>
it's not a 1 minute build. it will depend on libscopehal and libscopeprotocols
<azonenberg>
and those are the majority of the build time
<azonenberg>
glscopeclient proper is only ~30K of the ~140K lines of code in the project
<d1b2>
<johnsel> those should have their own builds really
<azonenberg>
still a lot of stuff we need to add, and some bits are probably out of date
<azonenberg>
it has trouble keeping pace with development at times
<benishor>
thanks azonenberg
<azonenberg>
but it should be a good start
<benishor>
let's hope it will get me started
<benishor>
I managed to connect to my scope but don't know what to do next
<azonenberg>
(what scope?)
<benishor>
SDS2104X+
<benishor>
(siglent)
<azonenberg>
yeah that should work well, although it's likely going to be slow because of their firmware not being the most efficient. are you having a specific problem?
<benishor>
none so far, trying to understand what I can do with glscopeclient
balrog has quit [*.net *.split]
d1b2 has quit [*.net *.split]
jacekowski has quit [*.net *.split]
<azonenberg>
welp, i like the vkFFT developer already :p
<azonenberg>
Two new bugs filed, plus upping the priority of an existing issue that was not understood to be as severe as it was
<azonenberg>
all fixed within hours
<azonenberg>
I'm keeping a fork but i expect it will track upstream pretty closely at this rate