<_whitenotifier-7>
[scopehal-apps] azonenberg f333947 - ngscopeclient: download fonts, handle a bunch more init
<_whitenotifier-7>
[scopehal-apps] azonenberg b6e737f - ngscopeclient: initial imgui rendering works for demo window. Using lots of native Vulkan functions we have to replace w/ RAII versions, still using lots of demo helper methods. Doesn't handle resize yet.
<azonenberg>
Well that was actually a bit less painful than i thought. the test app can now display an imgui window and you can interact with it, as long as you don't attempt to resize the window
<azonenberg>
in which case it immediatly crashes because i havent implemented that handler yet
<azonenberg>
i need a bunch more work to get it to where i want
<azonenberg>
in terms of code structure and less stuff copied verbatim from example code
<azonenberg>
gotta pull the latest version and do the setup on our end
<azonenberg>
so far i'm liking the overall interaction flow and how the UI feels. the top level windows not being decorated the same as normal window manager windows is a bit odd, idk if there is a way to change that
<azonenberg>
when you draw a virtual window out of the main app and into a top level window, there is a slight lag. but not unreasonable
<_whitenotifier-7>
[scopehal] azonenberg 16cdb7f - Ask for KHR_SURFACE if needed
Johnsel has joined #scopehal
<azonenberg>
Hmm
<azonenberg>
So it seems that if i call glfwInit() in VulkanInit, as I currently do
<azonenberg>
it makes glscopeclient crash on the soldering bench workstation
<azonenberg>
but not the computer in the microscope bench or at my desk
<azonenberg>
if i remove the GLFW code in VulkanInit, glscopeclient runs (but of course ngscopeclient / vulkan graphics fails to work)
<azonenberg>
if i add the glfw code back, all of my code crashes
<azonenberg>
whether using gtk, glfw, both, or neither
<azonenberg>
So basically at this point i can't run anything on that one computer and i have no idea why. rebooted, updated gpu drivers, checked debsums on a bunch of packages
<azonenberg>
If anyone else has weird crashes in VulkanInit() or errors about not being able to find a render queue, let me know
<azonenberg>
so far no root cause and i cant make it happen on any other machine
<electronic_eel>
azonenberg: do you have some space on the disk left? you could try to install another distribution, for example fedora or arch. the other distro will probably have different library versions for mesa, x11/wayland etc.
<electronic_eel>
if it crashes with the different libraries too, then it is probably something in the kernel or nvidia driver
<azonenberg>
electronic_eel: the problem is that I have the most up to date kernel and nvidia driver on it, and i also tried reverting to the same 470.86 driver my other boxes are
<azonenberg>
different CPU
<azonenberg>
i dont have space for another distro. i'm more inclined to just leave it for now until i have time to spend
<azonenberg>
and maybe add a workaround argument to disable the GLFW code so i can still run gtk glscopeclient on that box
<azonenberg>
until the new frontend is ready
<azonenberg>
at which point hopefully i will have solved the issue
<electronic_eel>
how old is the gpu in this box? just a rough estimate
<azonenberg>
3070 Ti. lol
<azonenberg>
it's my newest rig
<azonenberg>
my 2080 Ti in the office and aging quadro on the microscope box work fine
<azonenberg>
the other weird bit is that the vulkan cube demo works
<azonenberg>
so its not that the graphics stack is totally borked
<azonenberg>
i've seen issues in the past where a kernel upgrade left the nvidia driver in an inconsistent state and any attempt to use opengl would segfault, for example
<azonenberg>
but it's not that
<electronic_eel>
maybe the driver does something for the newer gpus that the mesa or opengl libs on this box don't expect?
<electronic_eel>
that is something you could test with the different distro
<azonenberg>
I'm inclined to table this for a while, then upgrade it to debian testing around EOY
<azonenberg>
at which point testing should be close to release ready (they're aiming at a mid 2023 release for bookworm AFAIK)
<azonenberg>
and hope that fixes it
<electronic_eel>
if it weren't for the binary nvidia driver, i'd suggest to try a live cd. but i don't know of a live cd that ships the binary nvidia
<Johnsel>
irc<>discord seems broken
<Johnsel>
how do you point the scopehal submodule to a different commit azonenberg?
<Johnsel>
I'm a bit confused by how you have it set up
<azonenberg>
Johnsel: gaah
<azonenberg>
esden: poke ^
<azonenberg>
Johnsel: just cd to the submodule and do normal git operations to get it where you want
<azonenberg>
then commit the top level repo to update the pointer
<electronic_eel>
do you have to actually commit the submodule change? when you just want to build i don't think you have to do that
<Johnsel>
that ought to be the way but for some reason the lib folder is marked dirty and it won't pick up the scopehal commit change
<Johnsel>
eel: you don't but I need it because I want to see what the CI makes of it
<electronic_eel>
ah, ok, if you want to let the ci run on it then you have to commit in the top level repo
<Johnsel>
yep but with all the relative paths and submodules setup that is not doing what I want it to
<Johnsel>
but I'll figure it out
<Johnsel>
why is discord bridge not working though?
<Johnsel>
also I did solve the actual build/path issue on Windows wrt glslang
<azonenberg>
Johnsel: it goes down periodically for reasons which are not entirely clear to me
<azonenberg>
ping esden here and on discord and he'll reset it
<Johnsel>
I think you have some magic git configuration files + directory structure that make things work on your end but not anywhere else azonenberg
<Johnsel>
the actually in the repo defined config is a bit wonky
<azonenberg>
Johnsel: so the submodules use relative paths
<Johnsel>
yes that is not a good practice
<azonenberg>
this is annoying but necessary because we need to support cloning via HTTPS for anonymous users, or via SSH if you are going to be pushing changes etc
<azonenberg>
the end result is, if you want to work on a private fork, you need to fork all of the submodules too to make the paths work
<azonenberg>
I havent found a better way to do it but when i originally had absolute ssh paths, there was a lot of pushback
<azonenberg>
because you couldn't clone w/o a github account
<Johnsel>
I think we should seperate my immediate issue from the structure but there's some things to be said for the current approach because there are some definite anti-patterns in there. I do understand the need for anonymous cloning over https and I actually have to look how that is generally best approached
<Johnsel>
by the way, ng is also a prefix that is heavily associated with angular web apps
<Johnsel>
not sure if you care, but that would definitely be confusing to web devs
<azonenberg>
This is a very temporary working name
<azonenberg>
the intent is to replace it with an actual name chosen to be more permanent
<azonenberg>
even glscopeclient was a temporary name
<azonenberg>
i just suck at naming and nobody invented a better one
<azonenberg>
some folks are looking at actually throwing budget at branding for the project eventually though
<azonenberg>
including a better name, icon, etc
<Johnsel>
I assumed as much, but you never know
<azonenberg>
libscopehal etc will stay
<azonenberg>
as it's an accurate, useful name and not an end user facing component anyway. devs won't care :p
<Johnsel>
I think that is a very descriptive name indeed
<_whitenotifier-7>
[scopehal-apps] ... and 2 more commits.
<azonenberg>
anyway at this point i'm just trying to get a basic imgui frontend that can connect to a scope (but probably not render any waveforms yet) set up with all of the infrastructure i'm happy with
<azonenberg>
in time for the dev call on monday
<azonenberg>
so we can discuss progress to date and figure out if continuing on this track makes sense
<Johnsel>
ideally drawing conclusions is done after that has ran on all the platforms, no? or do you mean unless you run into some dealbreaker this early?
<Johnsel>
good, my immediate git issue was just my own incompetence
<azonenberg>
we're a long ways from having it tested on every platform but i'll poke lain and see if she can try it on moltenvk at least
<Johnsel>
and D:/a/scopehal-apps/scopehal-apps/lib/scopehal/ComputePipeline.h:90:29: error: '_mm_mfence' is not a member of 'vk'; did you mean '_mm_mfence'?
<azonenberg>
i have no idea whats up with that
<azonenberg>
seems like maybe a sdk setup issue?
<Johnsel>
I have the same thing locally so it seems platform related
<Johnsel>
C:/GitHub/scopehal-apps/lib/scopehal/AcceleratorBuffer.h: In member function 'void AcceleratorBuffer<T>::CopyToGpuNonblocking(vk::raii::CommandBuffer&)':
<Johnsel>
C:/GitHub/scopehal-apps/lib/scopehal/AcceleratorBuffer.h:884:29: error: '_mm_mfence' is not a member of 'vk'; did you mean '_mm_mfence'?
<Johnsel>
from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.1.0/include/x86intrin.h:32,
<Johnsel>
In file included from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.1.0/include/xmmintrin.h:1316,
<Johnsel>
from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.1.0/include/immintrin.h:31,
<Johnsel>
from C:/msys64/mingw64/include/winnt.h:1657:
<Johnsel>
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.1.0/include/emmintrin.h:1532:1: note: '_mm_mfence' declared here
<Johnsel>
1532 | _mm_mfence (void)
<Johnsel>
| ^~~~~~~~~~
<Johnsel>
looks like it's related to memory fencing
<Johnsel>
oh okay it's resolving that function call to a winnt.h defined MemoryBarrier
<Johnsel>
do you have a reference to some docs for MemoryBarrier?
<azonenberg>
oh hmmmm
<azonenberg>
so it's a namespace collision?
<Johnsel>
I think it's missing
<Johnsel>
you 'install' the Vulkan SDK in a fairly nonstandard way
<azonenberg>
vk::MemoryBarrier is defined in vulkan_structs.hpp
<Johnsel>
I think that's fair to say :p
<azonenberg>
iirc
<miek>
eww, it's just "#define MemoryBarrier _mm_mfence" in winnt.h
<azonenberg>
(so we might have to #undef that before including the vulkan headers)
<azonenberg>
and well, i didnt write the CI scripts
<azonenberg>
ideally for at least the ubuntu CI machine we'd install the .deb package
<Johnsel>
I am not sure where we best pull it from but at least running the installer is probably better lol
<Johnsel>
though it could be some Windows weirdness as well
<Johnsel>
I am not a big cpp guy
<Johnsel>
But I do know that the Vulkan SDK has lots of optional stuff
d1b2 has joined #scopehal
<azonenberg>
yay discord bot is back
<Johnsel>
hello other half
<Johnsel>
welcome back
<esden>
test
<d1b2>
<esden> ok
<azonenberg>
thanks :)
<d1b2>
<esden> yeah, well the bridge does not like netsplits it seems... sigh ... I wish there was a more reliable bridge implementation 😦
<Johnsel>
azonenberg did you run the Vulkan sdk installer locally?
<miek>
Johnsel: to clarify, the issue here is that winnt.h defines MemoryBarrier as a macro, so when trying to call vk::MemoryBarrier(...) it gets replaced with vk::_mm_mfence(...), which doesn't exist. it's not an issue with the vulkan install, it's just a naming conflict because winnt.h is doing something gross. i think the only fix is to add "#undef MemoryBarrier" just after including winnt.h
<Johnsel>
thanks miek, I think you're right, it's just annoying because most of those includes are random mingw dependencies
<Johnsel>
it also complains about the order of some files
<azonenberg>
Ok well dig into things and send a PR when you have fixes. I'm going to sleep, it's 2 in the afternoon and i've been up since about 7pm yesterday
<azonenberg>
aaaaaalmost on a normal sleep schedule :p
<Johnsel>
the question still stands, though azonenberg, or did you follow the CI?
<azonenberg>
Johnsel: my local install on all of my dev boxes was using the ubuntu .deb package
<azonenberg>
which seemed to install and work fine on debian
<Johnsel>
okay, that's good to know
<Johnsel>
the CI does not run any of the installer stuff
<azonenberg>
i'd like to update the docs to reference that as well
<azonenberg>
the docs right now i think have you use a tarball install
<Johnsel>
yes we need to do a good pass over the CI + docs
<Johnsel>
but you keep changing the code so we never get a working build :(
<azonenberg>
well glfw3 is the last dependency i will be adding in the near future
<Johnsel>
every time one thing is solved there is another problem after that prevents a full build
<Johnsel>
that will be good, I think it's necessary to get to a working build
<azonenberg>
yes agreed. this last few weeks has just been a lot of major changes landing one after another
<azonenberg>
that's why i started doing the regular dev calls
<azonenberg>
because the pace of major refactoring was so rapid i wanted people to be able to stay on top of things
<Johnsel>
good, it's starting to feel a bit like we're losing footing at
<azonenberg>
at this point my main development focus for the next couple weeks is going to be the vulkan stuff. writing gpu accelerated versions of filters, lain's opengl compute -> vulkan conversion, and bringing up the imgui test app
<Johnsel>
or at least for me it is
<azonenberg>
none of those are likely to be build breaking
<azonenberg>
it's new code, but using existing dependencies and infrastructure
<Johnsel>
yeah or we pick a build that should work and work towards getting that working
<azonenberg>
So, current git head builds fine for me on debian
<azonenberg>
and all of the changes i have planned for the next week or so should be relatively minor (mostly writing gui code in the test app)
<Johnsel>
alright should be good then
<azonenberg>
let's start by getting the ubuntu ci build to compile fully (but dont worry about unit tests)
<azonenberg>
then get the ci build compiling under windows
<azonenberg>
and then start thinking about swiftshader or llvmpipe or something so we can actually run the tests in the CI
<azonenberg>
(lain is looking into this a bit as well, she had problems running with swiftshader but didnt have time to investigate yet)
<Johnsel>
I think finishing things on the Windows end is better because it has a lot of bits scattered and I don't want to forget to combine them
<azonenberg>
ok
<azonenberg>
anyway yeah this crazy rate of major changes should not persist :)
<Johnsel>
but that's just the ordering, otherwise yep
<azonenberg>
in fact, we will see more stabilization because i am starting to shift my dev focus to the new vulkan frontend
<azonenberg>
meaning, the gtk frontend is going to be pretty stagnant for a while
<Johnsel>
I'm guilty of driving the changes too
<Johnsel>
I lobbyed hard for it :p
<azonenberg>
lol
<Johnsel>
you are starting to see the value?
<azonenberg>
of imgui? or vulkan in general? or what
<miek>
they've been separated into separate CI configs now anyway, so i'm not sure the ordering matters
<Johnsel>
imgui
<azonenberg>
it's too soon to say
<azonenberg>
as of about an hour ago, i got a glfw + imgui app fully operational in my C++ model
<azonenberg>
i had to rewrite the entire demo vulkan bringup code to use libscopehal's vulkan init, extend that a bit to request the extensions glfw needed, and then convert all of the raw c vulkan api calls to use the c++ wrappers i use elsewhere in the project
<azonenberg>
Which cut the number of lines of code in ~half, but it took a while to do
<azonenberg>
i am literally about to create my first actual imgui UI element in the test app right now
<azonenberg>
(so far i just call ShowDemoWindow() but have no actual ui outside of that)
<azonenberg>
so i know the libraries and vulkan are working, but it does nothing useful so far :p
<Johnsel>
hopefully that will build on Windows without too much problems too
<azonenberg>
well, everything is in the repo
<azonenberg>
I expect there will be a period of turmoil as things stabilize
<azonenberg>
but all of the major dependencies i was going to add are now here
<Johnsel>
yeah I can find out, except there isn't enough time in a day
<azonenberg>
and we actually completely removed OpenCL already
<Johnsel>
as you know
<azonenberg>
Yes i am very familiar :p
<azonenberg>
(so that was another big source of trouble removed)
<azonenberg>
i'm also gradually migrating some if not all openmp stuff to explicit threading
<azonenberg>
Most of the things i used openmp for either should be run on the GPU, or are best done with a better threading model
<azonenberg>
so while i'm not necessarily goign to remove it entirely, i am definitely going to be reducing my usage of it
<azonenberg>
(also in part b/c apple's compiler doesnt seem to have openmp support, so we lose the parallelism on osx)
<Johnsel>
oh that did turn out as problmeatic as it seemed then
<azonenberg>
here i was thinking openmp was free threading with almsot zero effort
<azonenberg>
lol
<azonenberg>
anyway good news is that c++ 11 or 14 added first class threading to the standard library
<azonenberg>
Which i make heavy use of already in e.g. the filter graph
<Johnsel>
aww, so the cake is once again a lie
<azonenberg>
and in fact, the new filter graph evaluator is better anyway
<Johnsel>
how is the Vulkanizing going on M1?
<azonenberg>
lain has been busy the last day or two but is expecting to be working close to full time on it starting i think this weekend
<azonenberg>
there was a lot of infrastructure and tooling work
<azonenberg>
the sdk doesnt have arm64 binary releases
<azonenberg>
so she had to compile a lot of stuff from source
<Johnsel>
that's weird
<azonenberg>
it works, they just dont have binaries to download
<Johnsel>
you know there a lot of optional components in the SDK right?
<azonenberg>
I havent looked into its internal structure
<Johnsel>
(like glslang)
<azonenberg>
i just did "apt install vulkan-sdk" after adding the lunarg repo
<azonenberg>
and well that is kinda important for our application
<Johnsel>
yeah I think it's different between platforms even
<azonenberg>
given that vkfft does jit shader generation
<azonenberg>
re the filter graph evaluator, the initial version with openmp did block based processing
<Johnsel>
yes and debug binaries
<Johnsel>
let me refer to the actual list
<azonenberg>
the problem is, if you had one filter blocking N others
<azonenberg>
and that filter finished
<azonenberg>
you wouldn't launch the other N until all of its siblings had finished executing
<Johnsel>
com.lunarg.vulkan.volkVolk (Vulkan Meta Loader) library
<Johnsel>
com.lunarg.vulkan.debugDebuggable shader API libraries
<Johnsel>
com.lunarg.vulkan.debug3232-bit debuggable shader API libraries
<Johnsel>
definitely relevant
<azonenberg>
now, we have a producer/consumer model where as soon as a fitler is unblocked it can run
<azonenberg>
we are not using VMA, we have our own version of it in the AcceleratorBuffer class
<azonenberg>
which adds something like file backed storage that are not exactly vulkan specific
<azonenberg>
some things*
<azonenberg>
we use glm in a few spots already
<Johnsel>
we might be using SDL2/GLM
<azonenberg>
and are not using sdl2
<azonenberg>
glscopeclient GTK is using GTKGLArea for opengl init and such
<Johnsel>
will you use it for the imgui?
<azonenberg>
no, i'm using glfw
<Johnsel>
I wonder if that will do weird things
<azonenberg>
glfw is what the sdk examples use iirc
<azonenberg>
so it better work :p
<azonenberg>
anyway glfw is simpler and more lightweight. the only difference i noticed of consequence between glfw3 and sdl2 is that glfw does not support ios/android while sdl does
<Johnsel>
SDL is also used in the examples
<Johnsel>
and is part of the SDK
<azonenberg>
This is a non issue to me, because any hypothetical mobile scope client is going to be a from-scratch touch optimized UI
<azonenberg>
so if we have to use something other than glfw there, big deal
<Johnsel>
yeah sure mobile is irrelvant
<azonenberg>
and then things like sound etc that we dont care about
<Johnsel>
but I do know SDL2 is pretty well supported cross platform
<Johnsel>
I'm not that sure of glfw
<azonenberg>
glfw runs on all major PC platforms
<azonenberg>
linux/windows/mac and i think even bsd
<Johnsel>
sure but there's runs and there's runs
<Johnsel>
SDL2 has to support games which by definition expect a 60fps constant at all platforms
<azonenberg>
Well, we have very little hard dependency on it. so it wouldn't be *that* hard to switch to another framework
<Johnsel>
GLFW does not have that expectation
<Johnsel>
and a lot more legacy
<azonenberg>
glfw is more legacy??
<azonenberg>
glfw seemed very simple and light and minimal fluff compared to sdl
<azonenberg>
in any case, i profiled the test app and it's stupidly fast so far
<azonenberg>
spends most of its time waiting for vsync iirc
<Johnsel>
it has more fluff because it is more generic but it still has a wide userbase that expect performance
<Johnsel>
and it delivers
<azonenberg>
anyway, i'm not all in on glfw at this point
<Johnsel>
there are many games written with it
<azonenberg>
the whole point of ngscopeclient at this time is a research testbed
<Johnsel>
no I think we should test it
<Johnsel>
measure it and shoot at it from actual experience
<azonenberg>
it may or may not end up being, or turning into, our final actual UI
<azonenberg>
Well, once we get the builds working on all target platforms
<azonenberg>
we can evaluate
<Johnsel>
yeah that's the only thing that matters really
<Johnsel>
does it do what it has to do
<azonenberg>
From my perspective, the milestone for ngscopeclient is that we can connect to a scope and display at least one channel of data, ideally with window management so we can drag waveform areas around and resize things etc
<azonenberg>
and then profile the heck out of it on every target platform
<azonenberg>
make sure it works and is fast
<Johnsel>
agreed
<azonenberg>
actually displaying that data is gated on lain's shader rewrite
<azonenberg>
so in the meantime i'm focusing on the imgui ui chrome
<Johnsel>
yep and I will slave away at getting everything to build properly on the non m1 platforms
<Johnsel>
I will need at least one fun task after, though, lol
<azonenberg>
lol
<Johnsel>
miek: you were right!
<Johnsel>
any idea what to do about this azonenberg?