<_whitenotifier-7>
[scopehal] azonenberg 4266649 - Removed OpenCL window functions that are no longer being used
<_whitenotifier-7>
[scopehal] azonenberg 77d6f46 - FFTFilter: now use full Vulkan based pipeline. clFFT no longer used, FFTS kept as fallback for testing
<azonenberg>
i merged your arm64 work from the other day as well as initial vkFFT integration
<azonenberg>
as of now, only the FFT (and jitter spectrum, which is a subclass of FFT) filter uses vkFFT. We still use clFFT in the de-embed and channel emulation filters
<azonenberg>
and FFTS is still a dependency, but is only actually used in the new code if you do --nogpufilter or are running unit tests
<azonenberg>
in the near term I plan to remove clFFT, but keep FFTS so i have a reference implementation to compare vkFFT against in unit tests
<azonenberg>
in particular we spend almost as much time in glXGetVisualFromFBConfig as we do in WaveformArea::OnRender() for my current test case
<azonenberg>
So unless we want to fork GTK, there seems to be a ceiling in how much more performance we can squeeze out - at least with gtk3
<azonenberg>
and gtkglarea
<azonenberg>
Note that this is primarily a ceiling on FPS for simple filter graphs that are bottlenecked on the O(1) overhead per frame (the more waveformarea's you have, the worse the overhead is)
<azonenberg>
in particular you can have arbitrarily complex processing pipelines and rendering and will quickly get bottlenecked on that
<lain>
hmm
<azonenberg>
Which is suddenly making the imgui route look more attractive long term
<azonenberg>
it's still not a 2022 priority, i think
<azonenberg>
and i think it would make sense, if we do switch, to do so gradually
<azonenberg>
a few dialogs etc at a time will turn into a gtkglarea full of imgui widgets
<azonenberg>
and once they're all gone, we can switch the core easily
<azonenberg>
lain: anyway, please pull latest code, fix anything you need to wrt libglslang and such so it compiles
<azonenberg>
and let me know if "make test" is working on your x86 linux dev box (especially the FFT)
<lain>
kk
<azonenberg>
also, what is the status of building/testing on the pi4? i know you got it to compile on arm64 VM when you were over
<lain>
ah yeah
<lain>
I'll plug the pi4 in and resume that on monday
<lain>
it *should* work on pi4, at least to the same degree that it works on arm64, but I'll verify it monday
<azonenberg>
well in particular i want to know status of the unit tests
<azonenberg>
glscopeclient won't run on either the pi or the vm yet (at least, actually let you create a WaveformArea) because of the gl 4.3 dependency
<azonenberg>
but the tests should work fine with only vulkan
<lain>
ah ok
<lain>
I'll plug it in right now and get it building, will check on it periodically :P
<azonenberg>
yeah. it shouldnt need much of your time given the compile on the VM
<azonenberg>
please pull latest from git as of now
<azonenberg>
since it has vkFFT set up
<azonenberg>
and use that as your baseline
<azonenberg>
(this has your arm fixes merged)
<lain>
true, I can compile on my laptop and just copy it over
<lain>
azonenberg: lots of narrowing conversion errors in base64.cpp
<lain>
which is weird, hrm
<lain>
ok yeah it looks like it's not treating char as signed, lemme see what broke
<lain>
oh, it helps if I remember to pull the latest code >_<
sajattack[m] has joined #scopehal
mikolajw has joined #scopehal
bvernoux has joined #scopehal
<bvernoux>
So I checked on Ubuntu 20.04 LTS
<bvernoux>
same error as with MinGw64
<bvernoux>
36 | #include <glslang_c_interface.h>
<bvernoux>
| ^~~~~~~~~~~~~~~~~~~~~~~
<bvernoux>
with sudo apt-get -y install glslang-dev
<bvernoux>
installed
<bvernoux>
so the include dir/lib path are missing
<bvernoux>
full error
<bvernoux>
home/ben/scopehal-apps/lib/scopehal/VulkanInit.cpp:36:10: fatal error: glslang_c_interface.h: No such file or directory
<bvernoux>
| ^~~~~~~~~~~~~~~~~~~~~~~
<bvernoux>
36 | #include <glslang_c_interface.h>
<bvernoux>
@azonenberg, how are you building so far ?
<bvernoux>
Also I'm not sure sudo apt-get -y install glslang-dev is a good idea
<bvernoux>
as it shall match with the VulkanSDK
<bvernoux>
we are mixing things and it could finish very badly
<bvernoux>
For me it seems clear we need a specific scopehal-apps\cmake\Findglslang.cmake to add the correct include dir/lib path
<bvernoux>
for all platform Linux/Windows
<bvernoux>
Any other idea are welcome like always
<azonenberg>
yes we may have to add some custom cmake scripts for that
<azonenberg>
good news is, this should be the last major dependency we're adding for some time
<azonenberg>
Like i said, my plan is to incrementally transition one window at a time, starting with the graph editor
<bvernoux>
even if you do not plan to use docking at start
<azonenberg>
perhaps even dual track the graph editor with tabs or something
<bvernoux>
that will avoid some potential refactor after
<azonenberg>
I'll look into it
<bvernoux>
as anyway Dear IMGUI will merge the docking in main repo
<azonenberg>
We might just wait until that's merged to main
<azonenberg>
i'm not in a hurry
<azonenberg>
But the transition has, based on that profiling data, moved from "never/years out" to "probably aim for 2023"
<bvernoux>
yes it is great
<bvernoux>
I'm convinced it is a winner solution for long term in all cases
<azonenberg>
well lain likes it, so that's a plus
<bvernoux>
Even KeySight and Tek will be interested as it is a major update on how to manage oscilloscope and more with very advanced UI
<bvernoux>
They are far far away with their Gui which are in best case some ugly 2D blitter with Qt ;)
<azonenberg>
Ultimately i would like to transition the waveform over/underlays from Cairo to hardware rendering as well
<azonenberg>
but that's also a low priority
<bvernoux>
Yes it is good to convince all guys working on the project
<azonenberg>
imgui might make that easier
<azonenberg>
lain says she was already a fan of it
<bvernoux>
at start I was thinking I was the only one to be fan of Dear ImGui ;)
<bvernoux>
I was convinced even more when seeing SDR++
<bvernoux>
Which is used for Realtime display of SDR so it if very good to see how it is smooth with realtime SDR at more than 20MSPS
<bvernoux>
It clearly beat everything in the area
<bvernoux>
even SDR# which was one the best before
<azonenberg>
Yeah. Well, previously my concern was mostly the effort to refactor it
<azonenberg>
But i'm now seeing that the main thing limiting us to 20-30 FPS usable data rate is GTK
<azonenberg>
i want to be able to do 60fps with multi Gbps of streaming waveforms
<bvernoux>
yes it is an important point
<bvernoux>
or even more for bigger GPU/Computer ;)
<azonenberg>
well we'll be limited to 60fps with typical displays :p
<azonenberg>
But my dream is to be fast enough, one day, that we can do digital phosphor persistence within single GPU frames
<azonenberg>
i.e. if we have waveforms coming off the scope at 120 Hz, we can stack two per 60FPS video frame
<azonenberg>
The docking features WRT being able to split WaveformArea's is definitely attractive. i could completely remove most/all of my existing splitter based window management
<azonenberg>
Actually, thinking a bit more (ping lain)
<azonenberg>
I guess there's a more fundamental question
<azonenberg>
Does it even make sense to structure this as a port of glscopeclient in its current form?
<azonenberg>
or would it makes sense to use this as an opportunity to do a more clean rearchitecture of the project
<azonenberg>
and create a clean slate new frontend application, copying the shaders and other interesting bits from glscopeclient proper
<azonenberg>
it would initially lag behind in feature set, but the intent would be to eventually transition everything over to it and then deprecate the GTK version
<azonenberg>
my thought being that glscopeclient itself is essentially all GUI frontend code while the majority of the stuff that isn't gui toolkit specific is already in libscopehal/libscopeprotocols
<azonenberg>
so how much of what's currently in glscopeclient would make sense to keep??
<azonenberg>
there's definitely bits to keep - the shaders, most of the file format load/save code, the scope sync wizard backend
<azonenberg>
but it's starting to look like the question is more "how much do we keep" than "how much do we rewrite"?
<azonenberg>
lain: anyway, i'm wondering if it makes sense to create a new experimental app, say called "glscopeclient-imgui"
<azonenberg>
start with basically the minimal UI chrome and allow you to connect to a scope and display waveforms
<azonenberg>
(likely starting this after the vulkan refactor is done, so we can use imgui with the vulkan backend and then draw imgui widgets and waveforms seamlessly into a single app)
<azonenberg>
get a feel for the performance and ease of working with it
<azonenberg>
and then make a decision of whether we should cherry-pick glscopeclient into it, refactor glscopeclient a bit at a time, or axe the idea and look at alternative options
<azonenberg>
in particular, complex filter graph support and file load/save support are explicitly *not* going to be supported in the test app
<azonenberg>
maybe not even filter graph overlays at all
<azonenberg>
just connecting to a single instrument, timebase configuration, a simple menu, adding/removing channels
<bvernoux>
yes a restart to a clean glscopeclient-imgui seems to be clearly the best
<azonenberg>
This would also be an excuse to fix a bunch of other things i've wanted to do, like a more clean document/view or MVC architecture vs the bit of spaghetti we have now as it organically grew over a couple of years
<bvernoux>
To fully take advantage of ImGUI and avoid loosing time to port things and comparing GTK stuff to be converted to ImGUI ...
<bvernoux>
It is why I say switch directly to imgui docking
<bvernoux>
as it is really stable and it support docking & multi-view
<azonenberg>
Yeah exactly. but like i said, the bigger issue is that we need to do some other refactoring and we really wouldn't be *keeping* a lot of code
<lain>
azonenberg: I really like this idea also
<azonenberg>
Ok so i think we're in agreement. Roadmap is as follows
<azonenberg>
1) finish porting renderer to Vulkan
<azonenberg>
2) finish replacing OpenCL with Vulkan
<azonenberg>
3) create minimum viable proof of concept UI
<azonenberg>
with imgui and SDL
<azonenberg>
4) decide next course of action based on findings from 3
<azonenberg>
lain: sound good?
<bvernoux>
at same time as 4) you could check the Mac build too
<lain>
yus!
<bvernoux>
as it seems to be a dead end in actual glscopeclient
<azonenberg>
bvernoux: lain is already working on the mac build, the vulkan renderer rewrite is a necessary prerequisite for that
<lain>
bvernoux: I'm on the mac build, specifically apple silicon but I'll be testing on macos x86 as well
<azonenberg>
we've already got everything compiling on arm64
<bvernoux>
lain, do you have also standard PC with x86_64 to check the build is not broken ?
<lain>
bvernoux: yep
<bvernoux>
ha ok perfect
<bvernoux>
at least to check Ubuntu x86_64 build ;)
<bvernoux>
Windows is an other step but it is not far from Ubuntu x86_64 with mingw64 anyway
<lain>
I'm testing arm64 and x86_64 linux, and for the macos work I'm testing x86_64 and arm64 (M1) mac
<lain>
:3
<bvernoux>
Do you are full time on that project ?
<lain>
half time, ~20hr/wk, but yeah
<bvernoux>
ha great
<azonenberg>
Well, i guess 2022 is going to be the year of major shakeups in glscopeclient lol
<bvernoux>
yes clearly
<bvernoux>
You can also add a Sponsor icon for the project
<azonenberg>
major data model rewrite, opengl compute -> vulkan, opencl -> vulkan, first paid developers, and now looking at leaving GTK too
<azonenberg>
bvernoux: i'm actually talking w/ matt over the past few days about spinning up a legal entity for the project
<azonenberg>
so we have a name people can write checks to
<bvernoux>
ha great
<bvernoux>
it could be also part of GSOC
<azonenberg>
i dont want to do too much sponsorships before then. but absolutely we will be soliciting outside funding over time to pay more developers
<azonenberg>
That is already on the todo for summer 20243
<azonenberg>
2023*
<azonenberg>
if we can get things stable enough and a good cadre of experienced devs
<azonenberg>
i cant mentor a bunch of gsoc folks myself
<azonenberg>
so we need several core developers regularly contributing and who are familiar with the code to support that
<bvernoux>
Yes it will be amazing to arrive quickly to a version 0.9 or even 1.0 ;)
<azonenberg>
and better internal developer documentation
<lain>
:D
<azonenberg>
Anyway, from a high level i see the 2022 goals for the project to be all of the infrastructure work we need to really take off in 2023
<azonenberg>
expanding the dev team, fixing key architectural limitations that are holding us back in legacy land, securing funding, getting more users in industry, building out relationships with T&M vendors, etc
<azonenberg>
that is all in progress and proceeding nicely
<lain>
extremely looking forward to all of this :3
<bvernoux>
Have founding from Tek & Keysight ;)
<azonenberg>
Lol
<bvernoux>
IIRC they never have provided any founding in any open source projects
<azonenberg>
That might be a stretch. but we are getting some pretty nice relationships solidified with smaller players
<bvernoux>
but they are using tons of in their scope
<azonenberg>
so far no budget, but several vendors are providing hardware for us to play with
<bvernoux>
without open source their oscillscope will not exist at all
<azonenberg>
I see our main source of funding not being T&M vendors, but users in industry and academia
<azonenberg>
companies who are tired of spending millions of dollars a year on software options and getting awful UIs out of it
<bvernoux>
yes T&M vendors have already their stuff and they want to keep them very closed ...
<azonenberg>
as well as academic labs and research organizations
<azonenberg>
CERN is definitely a place to reach out to, when the time is right
<bvernoux>
yes clearly
<azonenberg>
But we need to move slowly and carefully and plan things so we don't bite off more than we can chew
<azonenberg>
bvernoux: anyway, i think i'm probably going to set up another developer zoom session some time later this month. I'll make an announcement in the channel a day or so in advance so people can ask for the link
<azonenberg>
feel free to join and chime in next time
<bvernoux>
ha yes great
<bvernoux>
On my side I have very low value as my contribution are small and I have not (enough) time to work on glscopeclient
<bvernoux>
But yes with pleasure
<azonenberg>
Yeah i meant more jsut to sit in and watch
<azonenberg>
not necessarily participating
<bvernoux>
If I can bring something to the project I'm always happy to add my small contribution
<azonenberg>
anyone here is welcome to sit in, although the intent is for it to mostly be a place for the active dev team to coordinate what's going on
<bvernoux>
Vulkan(OpenGL/Shader) is clearly not my domain of expertise
<azonenberg>
i'm brand new to Vulkan but have a decent bit of OpenGL experience and have done a lot of CUDA and OpenCL acceleration work in the past
<azonenberg>
Ok so, in parallel with all that
<azonenberg>
there is definitely room for someone to contribute on the documentation side
<azonenberg>
i know lain said she was interested, but she's got other work on her plate at the moment
<azonenberg>
So if anyone wants to work on that in the nearer term let me know
<azonenberg>
in particular, documenting filter graph blocks
<azonenberg>
Which is of course independent of any future gui rearchitecture we might be doing
<azonenberg>
Also, wow we actually did not have that many opencl filters
<bvernoux>
On actual state at least adding Vulkan SDK stuff
<bvernoux>
for Linux & Windows
<azonenberg>
Great
<azonenberg>
looking at the list of kernels remaining it looks like just de-embed/channel emulation and FIR filter
<bvernoux>
anyway so far the build is broken so it will requires an update
<azonenberg>
so in the next few days, it's very possible we could completely remove the OpenCL / clFFT dependency
<azonenberg>
then we'll just have opengl/vulkan and ffts
<azonenberg>
and i expect in the fairly near future, FFTS will be relegated to test code. we'll still keep it around for cross checking stuff at least for a while
<azonenberg>
but it will never be used unless you use developer arguments to disable the vulkan filters
<azonenberg>
I don't push code unless it compiles and runs for me
<azonenberg>
and i don't intentionally break things on other platforms, but of course this often happens by accident
<bvernoux>
especially if the big refactor start
<bvernoux>
to be in an other branch or even an other project
<bvernoux>
to keep the old one working
<azonenberg>
all of the big refactoring is done. the imgui stuff will be a completely separate application
<bvernoux>
even if there will be no evolution in the old one
<azonenberg>
within the same repo, so we can more cleanly copy code into the new app
<bvernoux>
I just ask that to avoid breaking actual version for all platform
<azonenberg>
yes, agreed
<bvernoux>
the idea is they build with the CI
<azonenberg>
glscopeclient won't be going anywhere until and unless the imgui version is completely usable as a replacement
<azonenberg>
including fully compatible file format
<bvernoux>
yes I know
<electronic_eel>
when ffts is moved to testing only, will it be able to build glscopeclient completely without it? i would prefer that, because ffts is usually not available as package on most distros. so the option of leaving it out would ease packaging glscopeclient
<azonenberg>
electronic_eel: Yes. that is very much a plan
<azonenberg>
it will become an opt-in dependency at compile time. in that situation, if you run glscopeclient with --nogpufilter and try to do a filter requiring an FFT you'll get an error message
<azonenberg>
and unit tests that do FFTs will fail
<azonenberg>
Longer term still, we might move the CPU-only FFT code to the unit test itself (i.e. not in glscopeclient/libscopehal)
<electronic_eel>
very nice, that makes dependencies easy
<azonenberg>
at which point it would be OK to use e.g. fftw
<azonenberg>
idgaf if our unit test binaries are GPL
<azonenberg>
as long as we keep copyleft out of the actual app code and core libs
<electronic_eel>
are all the interfaces into the fft libraries so similar that this much variability is feasible?
<azonenberg>
For the most part it's a method you call to set up a plan object
<azonenberg>
then a method you call to actually run a forward or reverse transform
<azonenberg>
which takes a memory buffer for input and output data
<azonenberg>
and there's a few different formats, most of what we do is real to complex forward and complex to real inverse
<azonenberg>
with complex stored as interleaved real/imag real/imag pairs of fp32
<azonenberg>
clFFT, vkFFT, and FFTS all work with the same memory layout and the APIs while not identical are pretty trivial to refactor. especially the CPU side ones
<azonenberg>
the GPU side ones have more baggage wrt setting up command queues, not being able to just pass a raw pointer to the data but having to use a device memory handle, etc
<azonenberg>
i have not used FFTW but i would imagine it would be trivial to drop in
<azonenberg>
also, as things proceed further i would like to be able to create more extensive unit tests with better pass/fail criteria
<azonenberg>
right now for the most part what the tests are doign is verifying that the GPU and CPU versions of a filter produce identical output within some epsilon
<azonenberg>
but not necessarily that the algorithm both implement is correct
<electronic_eel>
so you don't compare against a known good data dump?
<azonenberg>
The subtract filter generates two random waveforms (with a constant seed - everythign is deterministic, or should be) and subtracts them with the generic CPU, AVX (if available), and GPU implementations of the filter
<azonenberg>
and checks them all against literal subtraction in the unit test
<azonenberg>
i also have a few basic assertions like input and output waveform length are equal, etc
<azonenberg>
but for say the sin(x)/x upsampling, i just verify the two implementations match
<azonenberg>
having known good data is a nice idea in theory, but we'd have to be very careful to avoid massive bloat of the repo
<azonenberg>
especially since the tests double as benchmarks and typically work with megapoint scale inputs
<electronic_eel>
couldn't many of the blobs be reused for many tests?
<azonenberg>
For low level math functions, input could be reused. output would have to be separate per filter of course
<azonenberg>
thats the issue
<electronic_eel>
also i wouldn't mind an optional extra repo with the tests. you just have to download it if you want to run the tests
<azonenberg>
So there is a scopehal-testdata repo now (i think thats the name)
<azonenberg>
that contains a series of test/demo scopesession's
<azonenberg>
including it as a submodule would not be unreasonable at some point
<azonenberg>
but we'd have to also store golden output for each input
<azonenberg>
right now a scopesession only stores the raw waveforms, not filter output
<azonenberg>
(they're lazily evaluated at load time)
<azonenberg>
so i'd need to export the golden waveform output from a filter to some interchange format and store that as well
<azonenberg>
anyway, that's a later problem
<azonenberg>
(and of course protocol input would have to be separate, although we could reuse some like e.g. a pcie waveform could be used for threshold, cdr, 8b10b, and each layer of pcie)
<azonenberg>
basically as far as i'm concerned any tests are better than no tests
<azonenberg>
right now the main thing i'm doing is writing gpu versions of existing filters
<azonenberg>
so my pass criteria is "gives same answer as the existing filter"
<azonenberg>
this will also catch regressions if we optimize something wrong, unless we make the same bug in both versions of the filter at once
<azonenberg>
Better coverage is always a good thing
<bvernoux>
azonenberg, I still have issues with latest glscopeclient to restore a session correctly with offset/position of the different view
<bvernoux>
It seems it affect only WIndows
<bvernoux>
Question do you think it is a good idea to install Ubuntu 22.04 LTS on a dedicated disk (with multi boot) or to use the older Ubuntu 20.04 LTS ?
<bvernoux>
I speak about a native install especially to test glscopeclient with HW acceleration(and check the support of my old GeForce GT 680M)
<bvernoux>
It is always interesting to have a reference on a low end (old GPU) I think
<azonenberg>
I would use more recent
<azonenberg>
and i think we should, in theory, be able to run on hardware as far back as GTX 400 series
<azonenberg>
wrt minimum for vulkan support
<bvernoux>
yes the idea is just to do not accept issues specific to the old HW
<bvernoux>
but until it works it is interesting to have idea of performances
<bvernoux>
until it is not usable at all
<azonenberg>
Yeah. At this point, my target minimum requirements are a 64-bit CPU and a GPU with vulkan 1.0 support
<bvernoux>
just for fun so far my Asus CoreI7 + GeForce GT650M is faster in 3D and everything compared to brand new Dell Precision 5550...
<azonenberg>
with vulkan 1.2 preferred as it enables acceleration of some stuff that we otherwise will have to do on the cpu
<bvernoux>
Especially on Windows10
<bvernoux>
my old GeForce GT650M seems supported with vulkan 1.2
<bvernoux>
for info my Dell Precision 5550 have 64GB of RAM and a Intel SSD (the fastest available)
<bvernoux>
but it is bloated by tons of IT stuff
<bvernoux>
that I cannot remove of course
<bvernoux>
as it is my company PC
<electronic_eel>
bvernoux: how about dual booting some sane os on your dell. maybe plug in an additional ssd so you don't have to touch the partitioning of the original one
<bvernoux>
I cannot install an other OS on it
<bvernoux>
all is restricted
<bvernoux>
and forbidden by IT
<bvernoux>
I use wsl2 for that ...
<bvernoux>
I do not want to hack it also of course
<bvernoux>
Also adding an other external SSD over USB3 will work but BIOS is locked
<bvernoux>
and I do not want to hack it and to have issues with my job ...
<bvernoux>
It is just fun that on paper it is a beast but in reality with all bloated stuff installed by It/Company it is slower than my old Asus computer
<bvernoux>
the most funny is even USB3 is slower
<bvernoux>
Dell have done a very bad job with their HUB too
<bvernoux>
Anyway we all know that latest Intel 12000 is bullshit and there is not 30% more speed on each new series since maybe serie 3 with CoreI7
<bvernoux>
they have never changed anything on their CPU since 10 years stuck on their 14nm process
<electronic_eel>
in my experience the intel alder lake series isn't that bad anymore. amd is currently still better in available core count and efficiency, but there are some workloads where the intel alder lakes are better
<electronic_eel>
so it is not that clear cut anymore as it was a year or two ago
<electronic_eel>
but my experience is only with desktop processors, not notebook ones
<d1b2>
<Darius> you have to be pretty careful comparing note book CPUs because of the thermal limits imposed by the chassis they are in
<d1b2>
<Darius> plus also old stuff doesn't have spectre et al mitigations
<Degi>
Ooh, did we change from OpenGL to Vulkan?
<benishor>
I can't believe I got it to build \o/. let me start first interaction with glscopeclient
* benishor
fires up his SDS2104X+
<benishor>
now to learn how to use glscopeclient
<bvernoux>
Yes in my case I clearly compare laptop Intel CPU with different configuration
<bvernoux>
@Degi, Yes big migration in progress to Vulkan
<Degi>
Oh neat
<bvernoux>
Lot of big development are coming
<bvernoux>
also for mid/long term remove GTK and replace it with Dear ImGui and potentially SDL2
<bvernoux>
@Degi, if you can check the history of IRC @azonenberg have added all details of the roadmap
<bvernoux>
mainly
<bvernoux>
<azonenberg> Ok so i think we're in agreement. Roadmap is as follows
<bvernoux>
<azonenberg> 1) finish porting renderer to Vulkan
<bvernoux>
<azonenberg> 3) create minimum viable proof of concept UI
<bvernoux>
<azonenberg> 2) finish replacing OpenCL with Vulkan
<bvernoux>
<azonenberg> with imgui and SDL
<bvernoux>
<azonenberg> 4) decide next course of action based on findings from 3
<azonenberg>
Degi: So we are transitioning both rendering and compute from opengl/opencl to vulkan long term
<azonenberg>
it's being done in a few phases
<azonenberg>
right now, lain is rewriting the waveform renderer from opengl compute to vulkan compute and i'm converting all of the accelerated filters from opencl to vulkan compute
<azonenberg>
at this phase we're keeping the compositor as GL and the GUI chrome as GTK
<azonenberg>
I did some profiling yesterday which provided strong evidence that one of our biggest performance hits is GTK overhead now
<azonenberg>
and it's limiting our framerate significantly
<azonenberg>
in particular GTKGLArea is very inefficient
<azonenberg>
so we did a bit of thinking and are looking at transitioning away from GTK longer term. several folks seem to like imgui and it has some really nice looking features so that's a strong candidate, but we havent made a final decision yet
<azonenberg>
imgui is only a ui rendering library and doesnt handle window creation or input handling. for that, candidates are GLFW and SDL2
<azonenberg>
glfw seems a bit more lightweight and doesnt include a lot of the fluff like audio handling that SDL2 provides which we don't need
<azonenberg>
but at this point i don't have strong feelings one way or the other
<azonenberg>
anyway, so then the remaining topic, to be brought up on the next dev call probably, is how to do the migration. I'm beginning to lean towards a from-scratch rewrite cherry-picking features from the GTK glscopeclient codebase
<azonenberg>
basically, libscopehal/libscopeprotocols are all gui/platform agnostic for the most part. but glscopeclient proper is pretty much all GTK code
<azonenberg>
which raises the question of how much of that code is plausible to keep
<azonenberg>
there's some bits for sure, like the preference manager and rendering shaders
<azonenberg>
but i expect ~80% will need to be rewritten