<monochroma>
we are currently transitioning to vulkan, and it is a requirement
<azonenberg>
Yes. vulkan is now a hard requirement. There are compatibility layers like SwiftShader you can use to do software emulation
<azonenberg>
@tnt: how old is your laptop?
<azonenberg>
when we were deciding about making the transition, we did a fair bit of research and couldnt find any major hardware less than a decade old that didn't do vulkan
<azonenberg>
we no longer use opencl as it's basically been deprecated by all the major GPU vendors
<azonenberg>
and GL compute shaders are not supported on apple platforms
<tnt>
azonenberg: Haswell on linux
<azonenberg>
Vulkan is the only GPU acceleration API that works on everything
<tnt>
Apparently there is "some" vulkan support, but incomplete & non-compliant and not updated anymore. And also not trivial to install (at least on my current setup), so I'm not too hot on doing a lot of work to try and get it running only to find out that the supported subset isn't good enough.
<azonenberg>
yeah thats 2013 era hardware
<azonenberg>
You might just need a new laptop :p
<azonenberg>
You can definitely try using SwiftShader
<azonenberg>
it will probably be slow, since it's CPU only and not gpu accelerated, but it should work
<tnt>
Yeah ... I actually got one (new laptop), but I wanted to repurpose my current one as the "lab workbench laptop" that would stay as permanent fixture there especially for controlling lab instrument stuff :)
<azonenberg>
ah i see
<azonenberg>
Yeah we had to make some difficult decisions around support due to limited dev resources
<tnt>
Yup, understandable.
<azonenberg>
fundamentally glscopeclient/ngscopeclient is a supercomputing application intended to process huge amounts of data
<azonenberg>
And our primary focus is driven by what the core devs or folks funding dev care about
<azonenberg>
which is to say, getting as much performance as possible on modern midrange to high end scopes (GHz bandwidth class) and relatively recent workstation/laptop hardware
<azonenberg>
We don't intentionally kill off support for legacy platforms, but if we have to make tradeoffs they're driven by what favors us getting our work done
<tnt>
Sure, but then again, the limit is how fast I can get data out of my scope.
<azonenberg>
Yeah
<azonenberg>
Basically what it came down to was, we needed to leave GTK because it was too slow
<azonenberg>
so we were doing a major refactoring for that reason anyway
<azonenberg>
we needed to leave opencl because it was a trainwreck of dev tool support
<azonenberg>
And we had tens of thousands of dollars of funding coming in to make macos support happe
<azonenberg>
happen*
<azonenberg>
macos does not support any opengl version past 4.1, but can do vulkan through moltenvk
<tnt>
Can the Vulkan and GL part run on different GPU ?
<azonenberg>
Sooo
<azonenberg>
glscopeclient right now has basically completely decoupled paths where 99% of the work (all gpu acceleration plus waveform rendering to texture) happens in vulkan
<azonenberg>
then the last little bit that displays a few textured polygons in the GTK window is GL
<azonenberg>
in principle yes, these can be separated. but there's not good code for GPU selection that would make that easy
<azonenberg>
the other thing is, glscopeclient should not factor into future plans
<azonenberg>
we intend to deprecate it in the next few months, ngscopeclient is the path forward
<azonenberg>
glscopeclient is getting zero new dev
<azonenberg>
the only reason it'
<azonenberg>
the only reason it's not already deleted is that ngscopeclient can't yet read/write .scopesession files and the multiscope sync wizard isn't ported over yet
<azonenberg>
at which point we'll be pure vulkan. and since things like waveform data memory are now allocated using vulkan APIs, and all rendering is vulkan, it's a core requirement
<azonenberg>
Given the modular architecture and the nice frontend/backend decoupling
<tnt>
Ack. Thanks for the explanation.
<azonenberg>
there is no reason in principle why someone couldn't make a completely software rendered GUI frontend
<azonenberg>
but you'd still have to use a vulkan compat layer so that vulkan APIs for memory allocation work on the backend
<azonenberg>
and some filter blocks like FFT are in the process of transitioning to a fully vulkan implementation (CPU fallback removed)
<azonenberg>
because ffts is a trainwreck
massi has quit [Remote host closed the connection]
<tnt>
I was just asking because I also have a NVIDIA GPU which works fine for compute stuff, but getting it to "display" anything on screen is challenging.
<azonenberg>
ah, interesting. So, longer term
<azonenberg>
we are looking at supporting a Primus-like architecture
<azonenberg>
where all compute happens on one GPU and the GUI chrome happens on another
<azonenberg>
the intended use case is to have an nvidia card wake up once per trigger to render waveforms and run the filter graph, then go back to sleep
<azonenberg>
while the intel gpu draws all of the menus and dialogs and stuff
<azonenberg>
so you can save power when running mobile