<_whitenotifier-7>
[scopehal] azonenberg 42bb583 - Vulkan init: use up to Vulkan 1.2 if available. Detect and enable 8/16 bit uniform and SSBO access if available.
<_whitenotifier-7>
[scopehal] azonenberg 6237ace - SubtractFilter: don't do redundant copies since ComputePipeline does that for us when binding
<_whitenotifier-7>
[scopehal] azonenberg ba5a9e6 - Initial Vulkan version of sinc upsample filter. 4x speedup over CPU version in early tests.
<azonenberg>
sin(x)/x upsampling filter is now GPU accelerated, has a unit test which it passes, and is about 4.5x faster than the CPU version (on a benchmark of 10M random points)
massi has joined #scopehal
<azonenberg>
oh and that's 4.5x faster than a heavily multithreaded CPU version. not scalar
<d1b2>
<Darius> nice
<d1b2>
<Darius> any accuracy difference?
<azonenberg>
My pass/fail criteria for all of my unit tests so far is, when the filters are presented with 10M points of random input uniformly distributed in [-1, +1]
<azonenberg>
the absolute delta between the CPU and GPU implementations for any given sample is not allowed to be more than 1e-6
<d1b2>
<Darius> cool
<azonenberg>
I didn't try to quantify the error further, that was an arbitrary cutoff that i figured was small enough to not matter
<d1b2>
<Darius> yeah
<azonenberg>
but it's the same exact algorithm basically copy pasted
<azonenberg>
they might well be bitwise identical
<d1b2>
<Darius> would depend on how your transcendental functions are implemented I imagine
<azonenberg>
No
<azonenberg>
because the filter kernel is calculated CPU side and passed as a SSBO to the filter
<azonenberg>
the actual GPU-side kernel is basically just a FIR filter
<azonenberg>
some quick bounds checks and then a buttload of FMAs
<d1b2>
<Darius> ahh
<d1b2>
<Darius> I thought you were benchmarking it against libc 🙂
tiltmesenpai7 has joined #scopehal
tiltmesenpai has quit [Ping timeout: 248 seconds]
tiltmesenpai7 is now known as tiltmesenpai
<azonenberg>
also i just ran a quick profiling test of the latest code, one 5M point waveform off a picoscope and a 50M point waveform upsampled off it
<azonenberg>
most of the CPU time, by far, was spent in memcpy()
<azonenberg>
mostly in WaveformArea::PrepareGeometry()
<azonenberg>
Once we transition the compute shader rendering to vulkan we'll no longer be spending a ton of time shuffling data to/from the card
<azonenberg>
so that should go away
<azonenberg>
i really wish there was a way to get a good parallel CDR
<azonenberg>
also woo just got tracking notice from digikey
<bvernoux>
But Test is broken
<azonenberg>
my ADL5569 backorder shipped
<bvernoux>
maybe we shall disable it ?
<bvernoux>
Ha great news
<azonenberg>
yeah now i can make more progress on diff probesd
<azonenberg>
i was down to one unused chip
<azonenberg>
And no, if tests fail that means the CI builder has problems with its Vulkan configuration. we want to be running unit tests of the vulkan shaders
<azonenberg>
we may have to deploy swiftshader or similar since the instance almost certainly lacks a GPU
<bvernoux>
A good thing is to separate Linux & Windows build
<bvernoux>
it is a mess
<bvernoux>
are you ok ?
<bvernoux>
as I cannot cancel the Linux or Windows build independently
<bvernoux>
do you confirm I disable the test so far ?
<bvernoux>
they are broken
<bvernoux>
on Linux too I think to be confirmed
<bvernoux>
at same time I can do 2 job
<bvernoux>
1 for linux and one for windows
<bvernoux>
and later you could also create osx
<azonenberg>
do not disable tests
<azonenberg>
fix them :)
<azonenberg>
like i said, swiftshader or similar may be needed
<azonenberg>
it exists for this exact purpose
<azonenberg>
we have an open ticket for that
<azonenberg>
it's not the highest priority, merge the "make it compile" fixes first
<bvernoux>
all is built with success
<bvernoux>
so it is ok to have 2 build.yml ?
<bvernoux>
build-windows.yml
<bvernoux>
build-ubuntu.yml
<azonenberg>
I'm not an expert on github actions and how its put together
<azonenberg>
Do what it takes to make it build on both platforms
<bvernoux>
it is transparent
<bvernoux>
the good point is they are independant
<bvernoux>
so we can build for windows or ubuntu independently
<bvernoux>
and they are launched in // anyway
<bvernoux>
it is just we can cancel on or the other
<bvernoux>
and we can also relaunch only one
<azonenberg>
Yeah thats fine. We'll be adding a mac osx builder in the future
<bvernoux>
yes
<bvernoux>
so you will create an other one without breaking the others ;)
<bvernoux>
especially as if anyone fail nothing is pushed at end
<azonenberg>
another thing we will likely be doing in the indefinite near future is setting up locally hosted build nodes and moving away from the github azure cloud instances
<azonenberg>
especially as we start adding shader-heavy unit tests etc
<azonenberg>
having test nodes that actually have GPUs on them etc is going to become more necessary
<bvernoux>
I could not really help about that
<bvernoux>
I hope you will keep the GitHub CI
<bvernoux>
without shader heavy stuff ...
<azonenberg>
well my point is, GPU is becoming a more and more core part of the project
<azonenberg>
to the point that there's already debate about removing the CPU versions of some filter blocks (since as of later this month you wont be able to render anything without vulkan anyway)
<azonenberg>
so unit tests that don't cover that functionality are basically worthless
<azonenberg>
in this proposed model we'd still be using github actions
<azonenberg>
but the actual builds would not execute on azure instances provided by github
<azonenberg>
they'd run on bare metal hardware that project members hosted
<azonenberg>
(and/or AWS/azure GPU instances)
<azonenberg>
but the point is, a gpu would be available when the CI build executes
<azonenberg>
this has always been the long term goal for the project
<bvernoux>
ha yes
<bvernoux>
so the CI will be 100% identical ?
<bvernoux>
The GitHub workflow
<azonenberg>
Yes. same script, just not running on github's infrastructure
<bvernoux>
Advantage if you have dedicated one is it will be really faster than what we have "freely" on GitHub which is limited as it is free
<bvernoux>
I was afraid the CI stuff will be totally different
<azonenberg>
yes. the other rereason we're looking into this is that we are starting to be very close to maxing out the free minutes
<azonenberg>
they cap how much time you can spend per month on CI jobs
<bvernoux>
As it is a real headach to let it work correctly and understand the subtility ;)
<azonenberg>
and windows/mac nodes are billed at a higher rate
<azonenberg>
one minute on a windows instance is charged as 2 minutes
<azonenberg>
and one on a mac is charged as 10
<bvernoux>
ha interesting
<azonenberg>
(and i think the mac instances are x86 not arm anyway)
<azonenberg>
so as the codebase grows and needs more compiles, and the compiiles take longer, and we add more test cases, etc
<azonenberg>
we will reach a point where we've hit the cap and they stop launching new CI jobs unless we move to a paid plan
<bvernoux>
yes at end GitHub free CI is a non sens
<azonenberg>
and yes, the slow response from the single/dual core wimpy cloud instances is the other issue
<bvernoux>
as it will be too slow and will stop as you exceed allowed time/resource for free project ...
<azonenberg>
if we can get a few kUSD in funding to put together dedicated hardware, and someone willing to host it
<azonenberg>
then we can have dozens of cores dedicated to the builds
<azonenberg>
and a GPU for running tests
<azonenberg>
and be completely free from such resource limits
<azonenberg>
So that is the long term path forward
<bvernoux>
yes clearly
<miek>
the latest releases of the self-hosted runner have arm64 support now btw
<bvernoux>
I'm not sure arm64 is a good things vs x64
<bvernoux>
as arm64 are always slower
<azonenberg>
miek: yes. someone here already looked into that
<bvernoux>
it could be great to check the native build for arm64 is working if it is planned for a future version of glscopeclient
<azonenberg>
and did test runs on an m1
<azonenberg>
the github runners do not offer m1
<azonenberg>
but if you have your own hardware you can run their agent
<miek>
aha ok, i hadn't seen that
<bvernoux>
only m1 is survitamined ARM64 ;)
<bvernoux>
But please do not do that on a RPI4 ;)
<bvernoux>
it is so slowwwwwwwww
<bvernoux>
and the GPU of any RPI is so bad too
<bvernoux>
and so locked
<azonenberg>
We plan to test on pi4 as a stepping stone to M1
<azonenberg>
if it runs on a pi4, great
<azonenberg>
but that is not a primary target
<azonenberg>
it's more "oh cool it works"
<azonenberg>
for actual end user work, M1 is what we're interested in
<azonenberg>
and that is the primary reason we're working on arm64 support. i'm actually going to be getting together with lain later today specifically to get started on that
<bvernoux>
grr the persistence on Ubuntu is not working
<bvernoux>
this CI build is really awfull to understand how it work depending on the target
<darthrake>
azonenberg: irt to mac os: whats the idea here, using MoltenVK? there is no official vulkan support that I would be aware of
<azonenberg>
Correct
<azonenberg>
vulkan + moltenvk was the best path forward we could find to get mac support for GPU acceleration without a complete rewrite of everything in Metal
<azonenberg>
which we can't justify the engineering effort for
<darthrake>
ok. looking forward to this.
<azonenberg>
We are going to be moving away from opengl 4.3 and opencl as well
<azonenberg>
opencl will be replaced with vulkan compute and we will completely stop using it
<azonenberg>
and while we are keeping opengl for the final rendering/compositing stage for a while (long term plan is to go 100% vulkan but that's quite a ways off for complicated GTK reasons)
<azonenberg>
that will be basic opengl 2.x
<azonenberg>
the only GL 4.x feature we use now is compute shaders and those are being replaced with vulkan compute too
<azonenberg>
So it will be unifying things from 3 down to 2 and eventually one GPU API
<darthrake>
GTK and opengl on mac os is a complicated relationship as well...
<bvernoux>
let's move to Dear ImGUI to remove GTK ;)
<azonenberg>
Not happening soon, if ever
<bvernoux>
It is fully supported on OSX
<bvernoux>
also on Android
<bvernoux>
and Windows, Linux of course
<bvernoux>
it works natively with Vulkan too IIRC
<bvernoux>
there is tons of backend supported officially
<bvernoux>
Which seems to be not really an error as the build continue and do not fail
<azonenberg>
So what's probably happening there is that the test cases create a vulkan context early on before calling the catch2 arg parsing code
<azonenberg>
and ctest invokes the test binary during catch_discover_tests
<azonenberg>
which is when the error is being thrown
<azonenberg>
that is likely going to lead to tests not running or being skipped
<azonenberg>
incompatibledriver sounds like something we've seen in the past with old nvidia drivers, or (also likely) lack of a vulkan driver outright on the test system
<d1b2>
<johnsel> I'm glad you brought it up first so I don't have to be the one. The combo of gtk/gl/vulkan in one project is just contradictory and (definitely on Windows) bad architecture. After seeing it is literally only used to render windows and menus (gtk) and render a few triangles (gl) it makes even less sense to me to drag a couple 100MB of very badly supported unix userland dependencies across platforms in a supposed high performance application. I
<d1b2>
think too lightly is thought of the complexity this adds, especially if there are cross-platform GUI libraries that offer the same and more, and are far better supported.
<darthrake>
on smth entirely different: I got the chance to have a look at a TEK (TD)P7700 Browser probe. The tips are quite interesting. Socketed pogopins with series resistors: https://dsh.re/a9069https://dsh.re/8c139b
<azonenberg>
darthrake: That looks very much like how the LeCroy D1605 browser probe is built
<azonenberg>
but it looksl ike they're using rod resistors and not carbon fiber
<azonenberg>
(which makes sense because lecroy has a patent on carbon fiber for that purpose)
<azonenberg>
this is the same reason i'm looking into various ways of tip mounting resistors for the AKL-PT1
<azonenberg>
johnsel: "only rendering windows and menus" is the whole purpose of a cross platform gui toolkit
<d1b2>
<johnsel> and furthermore azonenberg I am not sure if it was clear but self-hosting Windows GitHub Action Runners (and specifically the msys2) is a nightmare, you'll probably be able to easily set up an Azure hosted one, but entirely self-hosted is a pretty frustrating thing because the runner has all kinds of dependencies that are very badly defined in scripts that expect an Azure environment. GitHub has long term goals to add GPU instances but they
<d1b2>
are far out in the future.
<d1b2>
<johnsel> which gtk isn't
<azonenberg>
cutting opengl is far more likely in the nearish term than gtk
<azonenberg>
yes it is
<azonenberg>
once the renderer rewrite is done, those few triangles will be the only thing keeping us hanging on to GL
<azonenberg>
so moving to pure gtk+vulkan would not be implausible longer term
<d1b2>
<johnsel> it is cross-platform because msys2 lets you drag in an entire unix userland
<azonenberg>
but replacing GTK would mean a much more major rewrite
<azonenberg>
no, gtk has native windows support, as used in e.g. Pidgin on windows
<azonenberg>
we're just not building full native windows yet
<azonenberg>
moving away from msys2 and building a more pure windows app is on the longer term todo
<azonenberg>
you can build gtk apps in a fully windows/microsoft flow
<azonenberg>
it's work, but it's doable
<d1b2>
<johnsel> And then you get pidgin performance
<azonenberg>
meaning?
<azonenberg>
(and who cares, because none of the gtk widgets are on the critical path wrt rendering/performance)
<d1b2>
<johnsel> assuming that you can indeed make the conversion, and update it, and none of the other dependencies have issues with the native build process
<azonenberg>
the single thing that is most likely to make us upgrade is the treeview widget that we use in the protocol analyzer view
<azonenberg>
i could honestly see potential for upgrading that, and only that, to something faster like imgui while keeping window chrome and such GTK based
<d1b2>
<johnsel> what you should do is dump GTK and everything around it so you can use something more modern that is properly supported
<d1b2>
<johnsel> and has more than 3 people supporting it
<azonenberg>
So i looked at the alternatives
<darthrake>
johnsel: is there something apart from QT?
<azonenberg>
qt has horrible licensing
<azonenberg>
imgui is afaik only a rendering library and doesn't abstract all of the platform differences in things like how to handle mouse input etc
<azonenberg>
i could see turning the app into a bunch of gtk chrome for windows and user input and rendering more of the things like the protocol analyzer with e.g. imgui in the 2023-2024 time frame
<azonenberg>
as that actually is a performanc ebottleneck with large (tens or more of megapackets) pcie traces and such
<d1b2>
<johnsel> the problem isn't even just the performance, it's also building the thing, let's not forget that part
<azonenberg>
but things like the preference dialog, configuring a channel or timebase, etc are totally not performance critical at all
<azonenberg>
johnsel: like i said what do you propose replacing it with
<azonenberg>
keep in mind the cost of a migration will not be low
<azonenberg>
tens of thousands of lines of code would basically have to be ripped out and rewritten
<azonenberg>
even more if you wanted to replace all of the Cairo based software rendering of things like protocol overlays, cursors, the timeline, etc
<d1b2>
<johnsel> but as for alternatives, dear imgui has been offered by bvernoux. wxwidgets has the ability to abstract away per platform
<azonenberg>
wxwidgets is the most likely place to migrate to but is it any better than GTK wrt building on windows?
<bvernoux>
for long term Dear ImGui is clearly a must have and I do not see anything better
<azonenberg>
(and like i said, the port would be extensive and time consuming)
<bvernoux>
It is perfect for that use case
<bvernoux>
@azonenberg, maybe there is some donator who could pay for the port
<d1b2>
<johnsel> there are definitely more that I don't know off hand, but I definitely think we would be happy to spend a few hours listing the alternatives and their up and downsides and then we can all shoot at it with our views of what is may cause
<d1b2>
<johnsel> would you not bvernoux?
<azonenberg>
but like i said, imgui doesnt hide all of the platform related stuff for window creation and input handling
<azonenberg>
we'd need something else for that even if we used imgui to draw to said windows
<bvernoux>
I have no time and there better guy than me to do the port for Dear ImGui
<d1b2>
<johnsel> I understand that, but I have spent hours on basic bs relating to gtk, bvernoux has spent hours on it, it's always a tradeoff
<bvernoux>
I'm speciliazed in embedded sw stuff not opengl/shader which I know nothing
<bvernoux>
But we can ask for a founding and hire some guy which can do the job "quickly"
<azonenberg>
This is a complete rewrite of 20-30K lines of gui code
<bvernoux>
yes
<azonenberg>
it's not something quick
<d1b2>
<johnsel> I think taking a step back and at least look at what options there are that might make a full vulkan-only build with all the GUI needs possible
<bvernoux>
Quickly depends on how many guys and if they work full time ;)
<darthrake>
but you just shift issues. from building to using it. non native file dialogs, no drag and drop, no pasteboard. all those issues. and a total "alien" interface
<azonenberg>
darthrake: exactly. if anything moving to wxwidgets would make more sense wrt native file dialogs and such
<azonenberg>
which they actually do better than gtk does on windows
<bvernoux>
darthrake, all what you describe is present in Dear ImGui
<azonenberg>
(gtk does things its way on windows)
<d1b2>
<johnsel> wxwidgets can use gtk for linux and native for windows
<azonenberg>
we don't use drag/drop or clipboard in glscopeclient at all, other than moving channels around which doesn't leave the application
<d1b2>
<johnsel> which might go a long way if that means we don't need to build gtk on windows
<azonenberg>
Yeah. I would not be fundamentally opposed to transitioning to wxwidgets in the 2023-2024 time frame
<d1b2>
<johnsel> but sure, how much effort an actual rewrite would take is as -if not more- important
<bvernoux>
You know the fun Dear ImGUI can even work in Chrome browser ;)
<d1b2>
<bob_twinkles> it can but you need to do all the platform plumbing
<d1b2>
<johnsel> that's just -a- file selection dialog
<d1b2>
<bob_twinkles> ImGUI provides a sort of meta-framework -- it needs you to feed it mouse/DnD/clipboard/etc. and it spits out a list of tris and textures
<darthrake>
azonenberg: https://dsh.re/46e14 the MSO6B series has changed the output of the SCPI commands again, slightly. once "the merge" is through...
<azonenberg>
darthrake: i merged all of the big refactoring
<azonenberg>
bvernoux: honestly that node editor is actually the biggest reason i've seen so far to move to imgui
<azonenberg>
as the current filter graph editor is in need of a total rewrite
<azonenberg>
perhaps a good intermediate point would be to have the filter graph editor only switch to imgui
<azonenberg>
keeping gtk for everything else
<bvernoux>
yes and the node editor is just an example
<azonenberg>
and we could do the port gradually, one window at a time
<bvernoux>
there is tons of other addons amazing like that
<azonenberg>
yes my point is that it's code that exists
<bvernoux>
Which is rock stable since more than 2 years
<bvernoux>
yes the look and feel is very modern and can be customized too if required
<azonenberg>
Ok so here's my proposal
<azonenberg>
As i see it, the project has fundamentally three types of UI
<d1b2>
<bob_twinkles> that's tracy right, you can export to tracy using just its stubs
<azonenberg>
the first is the waveform rendering and overlays. This is full custom anyway and largely independent of gui toolkit
<azonenberg>
and will be transitioning to 100% vulkan in the long term regardless of what happens elsewhere gui wise
<azonenberg>
Second is things like the filter graph dialog, which is also full custom but currently software rendered using cairo as it's less performance critical. but it's architecturally just one window with a big gtk widget in it
<azonenberg>
and third is everything else - menu chrome, file chooser dialogs, scope sync wizard, etc
<azonenberg>
Waveform rendering is already transitioning from opengl to vulkan, will be a mix for a while but eventually full vulkan is happening
<azonenberg>
I want to move away from Cairo and GPU accelerate some of the things like protocol decode event bubbles. imgui may be a way to do that, but that's a separate topic for discussion
<azonenberg>
Most of the work in a hypothetical imgui port would be the category 3 stuff, things that are classic GUI and not too performance critical or complex, but there's a lot of it
<bvernoux>
there is tons of AddOns to manage everything with nice UI
<azonenberg>
anyway so, where i see potential benefit in the near term is the category 2 stuff
<azonenberg>
the filter graph editor in particular
<bvernoux>
with License MIT
<azonenberg>
it's relatively self contained, it needs a total rewrite anyway
<bvernoux>
yes it is why I insist to do not drift to far on gtk ...
<bvernoux>
and it will be too late
<azonenberg>
i think it would not be unreasonable to replace the filter graph editor with the imgui node editor, keeping it as a GTK window and using GTK for mouse/keyboard input etc, at least for the time being
<azonenberg>
We would probably build it in a GtkGlArea to start then transition the backend to vulkan once gtk+vulkan plays better together
<bvernoux>
yes you can do the transition in a smooth way
<azonenberg>
but that's minor
<bvernoux>
it is not required to remove all directly
<bvernoux>
step by step keeping gtk until the end
<azonenberg>
Yeah. if that works well - we'll evaluate once we have the graph editor done
<d1b2>
<johnsel> I'd counter that with a let's first investigate if that does not put us in a deeper hole first
<azonenberg>
we can explore a more extensive transition
<bvernoux>
yes a POC shall be done first of course
<azonenberg>
if not, it's easy to revert the small experiment
<bvernoux>
to evaluate the time required and advantages
<d1b2>
<johnsel> because my argumentation is to get to a simpler whole, this moves into a direction of more complexity
<azonenberg>
johnsel: well the idea would be for that to be a transitive state
<azonenberg>
with complete removal of GTK being a long term goal if we decided to go that route
<d1b2>
<johnsel> sure but managing that transitive state means you still get to solve all the problems
<azonenberg>
but as "GTK for input handling, but all content of the GTK windows drawn by imgui" as an intermediate state, transitioning on a per dialog/window basis
<d1b2>
<johnsel> make sense?
<azonenberg>
Yes. And windows may suffer for a while during that transition
<azonenberg>
but i doubt it will be worse than it already is
<d1b2>
<johnsel> lol
<azonenberg>
imgui is a pretty small, self contained library
<azonenberg>
and the gtk dependency won't be any worse
<azonenberg>
The bigger longer term issue is, if we were to completely leave GTK
<azonenberg>
what would we use for windowing and input handling?
<azonenberg>
as imgui still needs that handled outside of itself
<bvernoux>
potentially SDL
<bvernoux>
to be discussed
<d1b2>
<johnsel> I think it's a good idea, but I also think we should put our most complex potential issues in writing and work to solve them
<azonenberg>
Yes
<bvernoux>
something simple and working well on all platform
<azonenberg>
this is all hypothetical at this point
<bvernoux>
sdl_vulkan work perfectly
<d1b2>
<johnsel> like that, like how m1 fits in that
<bvernoux>
sdl just for events
<azonenberg>
I would want to do a bunch of refactoring and cleanup of the GUI code - sorely needed anyway
<azonenberg>
Well, we'll know more soon. lain is coming over today and we're gonna have a big hackathon dedicated to the vulkan renderer port and getting everything compiling on arm64
<bvernoux>
But I do not know if it is better or not
<azonenberg>
bvernoux: also, i reviewed your PRs
<azonenberg>
i cannot merge them as is, because they don't set Vulkan_GLSLC_EXECUTABLE on Linux when using CMake <3.24
<azonenberg>
meaning it won't build on my system
<bvernoux>
do you have tested ?
<bvernoux>
it requires a variables to be passed in Cmake
<d1b2>
<johnsel> I think it would be useful to compile those links in a place somewhere by the way bvernoux
<azonenberg>
Yes. that is a no-go
<d1b2>
<johnsel> an issue, or something
<azonenberg>
johnsel: there is a pending issue for imgui already
<azonenberg>
marked as tabled, meaning we will not be proceeding with it soon if ever
<azonenberg>
but the issue exists as a place to discuss it and make long term plans
<azonenberg>
so please do dump all of this info in there
<bvernoux>
@azonenberg, Vulkan_GLSLC_EXECUTABLE is not a big issue until we import/use FindVulkan or older CMake
<bvernoux>
or->on
<d1b2>
<johnsel> I think azonenberg is on older cmake
<azonenberg>
bvernoux: yes, except we are importing FindVulkan today (scopehal-apps/CMakeLists.txt:58)
<d1b2>
<johnsel> or I might have misread his message
<azonenberg>
and debian stable ships cmake 3.18
<azonenberg>
I'm not merging any PRs that break the build on my own workstation for obvious reasons
<bvernoux>
azonenberg, but we can add FindVulkan.cmake for older CMake
<bvernoux>
azonenberg, and that will be solved
<azonenberg>
Yes, if we can package that check up in a way that it runs on 3.18 that's fine
<bvernoux>
azonenberg, workaround is to do like I do in the CI
<azonenberg>
or ideally 3.16. as that is currently the minimum we require. but a bump from 3.16 to 3.18 wouldn't be awful i think
<bvernoux>
azonenberg, add Vulkan_GLSLC_EXECUTABLE as parameter of cmake
<bvernoux>
azonenberg, does it is a show stopper to do that ?
<azonenberg>
bvernoux: like i said, i'm not merging a PR that requires me to explicitly override variables in my own build tree
<azonenberg>
make it detect glslc automatically. this is not up for debate
<azonenberg>
i don't care how you do it, but that's a must
<bvernoux>
so yes at least it shall do basic detection
<bvernoux>
as it is the only things we need
<bvernoux>
I'm very bad for cmake script
<azonenberg>
A last resort would be to simply declare minimum required 3.24 and force anyone on an older OS, myself included, to install cmake 3.24 from source
<azonenberg>
but that is not something i want to do lightly
<azonenberg>
our build is complex enough as it is
<azonenberg>
hell one of the reasons i want to move away from FFTS is to ditch an annoying dependency that has been hell to deal with
<darthrake>
azonenberg: WFMO? Response no has 23 or 24 components, the new one beeing point or line rendering. the bug with the missing WFId is still there though. for now i sloppy fixed it, but I don't have access instrument to properly fix it.
<darthrake>
now*
<azonenberg>
darthrake: please coordinate with @louis as he's been maintaining the tek driver lately
<bvernoux>
I have cmake version 3.18.1
<bvernoux>
on my Ubuntu 20.04 LTS
<bvernoux>
and I have no any issue to rebuild the fork
<bvernoux>
like it is on GitHub
<bvernoux>
ok just remove that variable ;)
<bvernoux>
I can test it anyway
<darthrake>
azonenberg: ok, will do.
<bvernoux>
cmake is such a headache ;)
<darthrake>
irt GTKGLArea: this is what you want to avoid if you want to have a chance of using it on macos. it is just broken in gtkmm3
<azonenberg>
darthrake: all of our current rendering uses it
<azonenberg>
even after opengl compute -> vulkan transition, we'll be using gtkglarea for the final compositing step
<darthrake>
the GL part works okayish. everything else breaks.
<d1b2>
<johnsel> I still think you should look at drawing those triangles with Vulkan only, straight on the window
<darthrake>
as soon as you change the window size everything distorts.
<azonenberg>
johnsel: that is the longer term plan. it's just a lot more work to set up because now we need a whole vulkan render pipeline and have to handle platform specific init code
<azonenberg>
i was planning on delaying that until GTKVulkanArea existed
<azonenberg>
and was available in a gtk version debian stable shipped
<darthrake>
on windows without GTKGLArea, this does not happen
<darthrake>
GTK4 is supposed to fix all those issues
<azonenberg>
yes. but gtk3->4 is a major enough port that we might as well think about a new gui toolkit instead :p
<d1b2>
<johnsel> you're asking other people to solve a lot of problems with sharing GPU memory and references and whatnot for something that is very easy to solve with your very minimal requirements
<d1b2>
<johnsel> you'll need to initialize that pipeline anyway
<azonenberg>
well with opengl in gtk3, you can forget about it and just have a context handed to you
<azonenberg>
i was hoping something like that for gtk4 would become a thing
<azonenberg>
where i could just have a commandqueue passed to me that i could push command buffers to
<azonenberg>
and it would magically show up on the screen
<d1b2>
<johnsel> hah yes, they will have to set up both the gl and vulkan context and sync them
<azonenberg>
anyway, if this is going to be a problem for us with the mac port
<darthrake>
anyhow, thanks for all your work on glscopeclient. I gladly continue to use the linux machine for glscopeclient...
<azonenberg>
this might be a "next week" priority not a "next year"
<azonenberg>
as we have actual budget and scheduling moving for that
<d1b2>
<johnsel> they by design can't share a lot of things because the gl abstracts it away
<azonenberg>
johnsel: why would we need a GL context at all?
<azonenberg>
why couldn't we simply have a vulkan context for whatever the backing store of the Gdk::Window is?
<d1b2>
<johnsel> you undoubtedly can, but the general GTK framework surely has cross-contextual 'things' that will require it to be synced
<d1b2>
<johnsel> think of a mouse click vs release in one to another context
<d1b2>
<johnsel> all that kind of lovelyness
<d1b2>
<johnsel> and probably far worse examples that I can't think of
<d1b2>
<bob_twinkles> you need something that can composite into the window
<d1b2>
<bob_twinkles> in principle you can offload that to the system compositor but I wouldn't trust it
<d1b2>
<bob_twinkles> so either GTK would need a full VK backend or at some point you need to interop with a GL context
<azonenberg>
GTK4 has a VK backend
<azonenberg>
which is another reason i was planning to table a lot of this until gtk4 :p
<d1b2>
<bob_twinkles> huh, they've been busy over there 🙂
<azonenberg>
(but afaik there isnt anything exposed that lets you use vulkan directly to draw to a window, or at least wasn't last time i checked)
<d1b2>
<johnsel> The Apple macOS port of GTK is an implementation of GDK (and therefore GTK) on top of the Quartz API.
<d1b2>
<johnsel> gtk4 that is
<d1b2>
<johnsel> so there you'd still have the same problem
<azonenberg>
So there's a couple of ways to deal with this. the simplest, ugliest route is to ditch GL and switch to software compositing
<azonenberg>
in particular, replace GtkGLArea with GtkDrawingArea
<azonenberg>
and use Cairo to render Vulkan-generated textures to the window
<bvernoux>
ok solved FindVulkan it requires 2 other cmake script
<d1b2>
<johnsel> I meant more Especially after you actually try to use MoltenVK on macOS and realize it’s a giant maze
<azonenberg>
Well, we're going to have to deal with that
<d1b2>
<johnsel> and Second, it’s likely that Zink will be a viable (and well funded) alternative soon
<azonenberg>
because it's the most viable path to get gpu accelerated compute on mac without a complete rewrite
<d1b2>
<johnsel> I haven't the slightest idea what Zink is supposed to be
<azonenberg>
it's a mesa driver that runs opengl on top of vulkan, as far as i can see
<azonenberg>
i don' see that being at all useful to us
<azonenberg>
as it assumes there is vulkan support on the platform
<azonenberg>
Vulkan is the forward looking GPU API, we needed to move to it regardless. If moltenvk has issues, they will be fixed in time
<azonenberg>
that blog post is a year and a half old
<azonenberg>
moltenvk is actively developed and funded
<azonenberg>
Near term, if we have issues resizing windows, we'll just create the window with a fixed aspect ratio and disable resizing or something :p
<d1b2>
<johnsel> sure but that still doesn't solve GTK on Windows problems (and potentially osx)
<d1b2>
<johnsel> Based on their backlog of things related to 3.x not even being done I would expect GTK4 support to be even worse
<d1b2>
<johnsel> though nothing speaks volumes more than an actual test, so given that that seems like a strongly preferred direction for you I think it's fair that we think both ways on how to enable GTK4+Vulkan on Windows. Then with your progress next week on m1 we should get a much better actual picture of how things stand if we would move in that direction
<azonenberg>
gtk3/vulkan is more what i was thinking
<azonenberg>
gtk3 -> gtk4 is a major transition
<azonenberg>
before we do that we need to decide if we're going to do it, or switch to e.g. imgui + something else for input
<azonenberg>
in particular i do not want to require linux users to compile gtk4 from source and gtk4 isnt out on stable distros
<azonenberg>
So it's not going to be gtk3 -> gtk4 -> someting else
<azonenberg>
it's going to be gtk3 -> gtk4 or gtk3 -> something else
<d1b2>
<johnsel> sure but I believe in something else
<d1b2>
<johnsel> you believe in gtk4
<azonenberg>
gtk3 -> gtk4 cannot happen utnil next debian release at the soonest
<azonenberg>
no i dont
<d1b2>
<johnsel> let's try both
<azonenberg>
i believe either port would be a major effort
<d1b2>
<johnsel> you believe in the gtk ecosystem
<d1b2>
<johnsel> since it's the default
<azonenberg>
So i want to stay with gtk3 as long as possible
<azonenberg>
and carefully consider where to move to from there
<d1b2>
<johnsel> ok, but deciding if you might go for GTK4 eventually would be dependent on the effort and problems it will cause as compared to an alternative, hence making a toy GTK4 on Vulkan on Windows example to see how things stand gives us the data to carefully consider
<d1b2>
<johnsel> right now we have no data on it at all
<d1b2>
<johnsel> just expectations
<d1b2>
<johnsel> does that make sense?
<azonenberg>
At this point my near term priority is to get as far as we can with a gtk3 + opengl + vulkan port for osx
<azonenberg>
if/when we run into insurmountable problems we'll decide the best course of action
<darthrake>
if im bored in the near future, i'm gonna start compiling on macos...
<azonenberg>
well like i said me and lain will be spending all night on that whenever she gets here
<azonenberg>
so we should have at least status updates after a few hours
<d1b2>
<johnsel> alright well if it's not a priority to you I won't make it one of mine
<azonenberg>
even if it's just muffled swearing and a bunch of #ifdef's around AVX code
<azonenberg>
pi4 is going to be a stepping stone to m1
<azonenberg>
getting it working with vulkan and gtk on arm64 *linux*
<darthrake>
there are two issues here: architecture and mac os / bsd specific issues