<_whitenotifier-7>
[scopehal-apps] azonenberg ab3b85d - PowerSupplyDialog is now functionally complete, other than gracefully disconnecting the instrument during shutdown. Fixes #425.
<_whitenotifier-7>
[scopehal-apps] azonenberg 061962a - Removed psuclient because this functionality is now folded into ngscopeclient
<_whitenotifier-7>
[scopehal-apps] azonenberg 79bb795 - PowerSupplyDialog now cleanly disconnects when closed
<bvernoux>
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/home/bvern/glslang/build/install/lib/libSPIRV.a(SpvTools.cpp.obj):SpvTools.cpp:(.text+0x4 undefined reference to `spvContextCreate'
<bvernoux>
So it seems the one I'm building is not complete
<bvernoux>
also it is clear that on VulkanSDK the lib is present but it is a SPIRV lib built with Visual Studio so not found by mingw64 which want libSPIRV.a and what is available is SPIRV.A
<bvernoux>
not SPIRV.a but SPIRV.lib
<azonenberg>
yeah it would not suprise me if your crashes are related to that
<azonenberg>
mixing mingw and native libs
<azonenberg>
some linker screwup making you look in the wrong place for some data or somethign
<azonenberg>
johnsel is working on trying to get at least ngscopeclient building natively under visual studio without mingw
<azonenberg>
and once we remove the gtk dependencies on scopehal/scopeprotocols, we will then have a path to a future free of mingw
<bvernoux>
I confirm all lib in VulkanSDK for Windows are built with visual studio 2017
<bvernoux>
the issue is actual rebuild of glslang with mingw64 in Release mode have missing API when linked at end
<bvernoux>
at least now it is explicit error during link
<bvernoux>
which probably do the crash when using mingw package as it is a DLL ...
<bvernoux>
So VulkanSDK is a real mess for mingw64 so far
<bvernoux>
maybe we can just link with the VisualStudio lib with mingw64 to be checked
<bvernoux>
also an other point to check
<bvernoux>
is I have not used exactly same version as the one from VulkanSDK to rebuild it
<_whitenotifier-7>
[scopehal-apps] azonenberg 805a31e - PowerSupplyDialog: disable apply buttons if value hasn't changed
<_whitenotifier-7>
[scopehal-apps] azonenberg 0f1d412 - Fixed bug in resize handling
<azonenberg>
johnsel: i'm getting to the point in ngscopeclient that i have to copy the preferences system over. There's a lot of dependencies like GDK and pango that comes with that, but we can refactor those away when the time is right
<azonenberg>
(i.e. when we start writing the parts of the GUI that actually pull, say, font preferences out of the preferences manager)
<bvernoux>
azonenberg, Will be great to do a PowerSupply for EEZ BB3
<bvernoux>
azonenberg, it have also SCPI command over ethernet
<bvernoux>
azonenberg, could try to clone your ones as example to add EEZ BB3
<bvernoux>
the same with official glslang repo used with VulkanSDK
<bvernoux>
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/home/bvern/glslang/build/install/lib/libSPIRV.a(SpvTools.cpp.obj):SpvTools.cpp:(.text+0x413): undefined reference to `spvContextCreate'
<bvernoux>
with tons of other error undefined reference ...
<_whitenotifier-7>
[scopehal-apps] azonenberg 6f5ed73 - Initial import of preferences system from glscopeclient. Still using lots of gdk/pango types, so lots of baggage dragged along. No GUI preference editing support yet.
<_whitenotifier-7>
[scopehal-apps] azonenberg 6ecc343 - Added recent instrument support, can now reconnect to recent PSUs
<bvernoux>
hm if I hack (manually) the link lib it link
<bvernoux>
there is some inter dependencies which are not correctly managed in the Cmake too
<_whitenotifier-7>
[scopehal-apps] azonenberg a0b9356 - Initial skeleton UI for connecting to multimeters. Don't actually do anything useful with them yet.
<_whitenotifier-7>
[scopehal-apps] azonenberg 0ac78bb - PowerSupplyDialog: added lots of help tooltips
<_whitenotifier-7>
[scopehal-apps] azonenberg 3e9894d - Updated to latest scopehal
<azonenberg>
bvernoux: should be fixed, please test
<azonenberg>
no need to delete existing cache
<azonenberg>
the files were fine, we just were loading them wrong
<_whitenotifier-7>
[scopehal] azonenberg 0654703 - Use cache root dir not prefix to fix relative paths
<bvernoux>
I hope that break nothing for Linux
<bvernoux>
that all for today like that nothing crash when I exit and restart
<bvernoux>
I should test all filter stuff to be sure all is fine
<bvernoux>
but so far so good
<azonenberg>
That's all gated by a check in case we get a relative path when we expected an absolute
<d1b2>
<azonenberg> also @everyone reminder, Monday (tomorrow) at 10AM Pacific time there will be a developer Zoom meeting to go over recent changes, make plans for the next few weeks, etc
<d1b2>
<azonenberg> The primary intended audience is active contributors/developers, but anyone is welcome to join. PM me for the zoom link if you want to join
<d1b2>
<ᴇʀɪᴄ> please don't ping everyone
<d1b2>
<Triggered_Tux> ^
<d1b2>
<Delilah (Siabus)> ^
<d1b2>
<Greg> (FYI, using (at)here will just ping the members who have used this channel)
<d1b2>
<azonenberg> ah ok, sorry that was my intention
<d1b2>
<ᴇʀɪᴄ> nope, never used this channel
<d1b2>
<azonenberg> Didn't realize it would ping the whole server. oops
<d1b2>
<josuah> to help with people always puzzled with time zones like me
<d1b2>
<azonenberg> Yeah, this seemed to be the best option for getting US and western europe, which is where most of the active devs are
<d1b2>
<azonenberg> it's late morning here, lunchtime east coast, and evening in europe
<d1b2>
<azonenberg> and the middle of the night in eastern europe/asia but we don't have a lot of current devs there
<d1b2>
<david.rysk> Any reason this server doesn’t have a mechanism where people can subscribe to project specific notifications? @\here only notifies people who are non-idle
<d1b2>
<david.rysk> Several servers I’m on use a bot with roles to handle this
<d1b2>
<azonenberg> yeah i'm used to IRC land where it's not even possible to ping an entire server, and notifications just go to a channel
<d1b2>
<david.rysk> Or just roles, and then the role can be pinged
<d1b2>
<Makerprobe> That would leave people out who aren't in that role, but actively lurking
<azonenberg>
Not sure what the best option is that doesn't spam the whole server but also makes sure people who want to see updates get them
<d1b2>
<Hathor> 🅱️ruh
ehntoo has joined #scopehal
<ehntoo>
I guess I'm going to need to get a proper IRC client set up again. It's been a while.
<ehntoo>
For running ngscopeclient on macOS, I did have the UI drawing last night, but input handling was pretty messed up. Clicks and mouseovers were only processing on the viewport that didn't have focus. I was going to dig into it more this morning, but after a rebase I'm getting what's probably a more helpful assertion:
<ehntoo>
Assertion failed: ((g.FrameCount == 0 || g.FrameCount == g.FrameCountPlatformEnded) && "Forgot to call UpdatePlatformWindows() in main loop after EndFrame()? Check examples/ applications for reference."), function ErrorCheckNewFrameSanityChecks, file imgui.cpp, line 8927.
<ehntoo>
zsh: abort ./ngscopeclient
<azonenberg>
ehntoo: interesting. never seen any of those before
<azonenberg>
We call UpdatePlatformWindows() in the main loop
<azonenberg>
it might be something around window resize handling, i recently fixed a few bugs about that
<ehntoo>
yeah. my first naive try of hoisting UpdatePlatformWindows() and RenderPlatformWindowsDefault() directly below the call to ImGui::Render() explodes in other ways. I'll poke around for a while.
<azonenberg>
That shouldn't happen
<azonenberg>
UpdatePlatformWindows() etc should happen at the *end* of the frame
<azonenberg>
after we've drawn everything else
<azonenberg>
conjecture: it's something to do with the resize event pending logic around line 288
<azonenberg>
of VulkanWindow.cpp
<azonenberg>
and perhaps leaving something in an inconsistent state
<azonenberg>
We might have to do some cleanuup before we return
<azonenberg>
(the other abort-and-return scenarios near the end on line 342/349 are after UpdatePlatformWindows() is called)
<azonenberg>
Try calling UpdatePlatformWindws() and RenderPlatformWindowsDefault() before the Render() call on 288
<ehntoo>
that cures the assert. now the window opens and then immediately closes with a segfault.
<azonenberg>
New problem, yay
<ehntoo>
if the stack trace is to be believed, it looks like maybe the call to Render() around 288 is recurring infinitely?
<azonenberg>
That sounds like an event handling issue. it's supposed to only get to the recursion if the window size has changed
<azonenberg>
in which case we resize the buffer and call it again
<azonenberg>
check if the window size is something crazy like 0x0
<ehntoo>
nope, reporting 1280x720
<ehntoo>
`m_swapchain->acquireNextImage` is returning (vk::Result::eSuboptimalKHR, 0)
<azonenberg>
Ok so it's suboptimal but you resize and still suboptimal
<azonenberg>
interesting. Maybe we need to add some kind of a recursion check or something for that
<azonenberg>
Out of date = recurse
<azonenberg>
suboptimal = recurse, but if you get it again live with it
<azonenberg>
i had never seen that error in my testing
<d1b2>
<david.rysk> Is it properly taking into account HiDPI?
<azonenberg>
Good question. that might also be it
<azonenberg>
but at this stage my focus is making it work, not work optimally
<d1b2>
<david.rysk> (Because 1280x720 seems awfully low for a Mac screen)
<azonenberg>
once it's not crashing we can worry about the details :)
<azonenberg>
That's the default window size at startup
<azonenberg>
Not screen resolution
<azonenberg>
i had to pick a size, i figured 720p was as good a guess as any
<d1b2>
<david.rysk> Yeah but macOS by default does 2x or something close
<d1b2>
<widlarizer> (Better yet, there is a @ stream-watchers role to ping)
<ehntoo>
oh, I hadn't considered that. I seem to recall seeing some flags you can toss at glfw to get it to render without high dpi... let me see if I can find those
<d1b2>
<david.rysk> So you should get a fairly small window if you’re declaring 720p
<azonenberg>
i mean i have a 4K monitor on my desk
<azonenberg>
But it's 4K 43"
<azonenberg>
so DPI is roughly the same as a 22" 1080p
<d1b2>
<david.rysk> If not it might be in HiDPI mode but not allocating enough memory due to believing the resolution is half
<azonenberg>
Yeah it could be something like that
<ehntoo>
high dpi handling on macOS can lead to some very strange behaviors regarding sizing
<d1b2>
<david.rysk> azonenberg: how are you planning to handle UI scale?
<azonenberg>
I haven't got that far yet :)
<d1b2>
<david.rysk> It’s just something to keep in mind early on before designing everything in a way that assumes 1:1
<azonenberg>
At this point i'm not doing anything with coordinates at all
<azonenberg>
i'm just packing ui widgets into boxes
<azonenberg>
i set some default sizes for a few things but that's straightforward to scale if needed
<azonenberg>
in general i dislike the whole concept of ui scaling, i see it as a compatibility shim
<azonenberg>
i'd much rather just double the font sizes and such and draw 1:1
<ehntoo>
tossing a `glfwWindowHint(GLFW_COCOA_RETINA_FRAMEBUFFER, GLFW_FALSE);` at it doesn't change things. I'll have a longer poke around and report back.
<azonenberg>
Rephrasing: I wish I could say 'make this a 10 point font' and have it be however many pixels tall 10/72 inch on the display is
ehntoo has quit [Quit: Ping timeout (120 seconds)]
<ehntoo>
hooked up to an external monitor at 1:1 scale, still having the same issue, so this is not _strictly_ HighDPI related.
<ehntoo>
I've also experimented with modifying the resize event handling. If I just ignore the fact that acquireNextImage is returning eSuboptimalKHR, I can get to a state where the GUI will keep running but the cursor's just a beachball and all the window contents are squished into a corner.
<ehntoo>
still experimenting.
<ehntoo>
(after lunch)
<bvernoux>
For information I will try to push final fix for mingw64
<bvernoux>
it is the only way to have something working with mingw64 so far
<bvernoux>
and it seems to be a solution not only for short term as VulkanSDK is mainly built for Visual Studio so for glslang stuff (static lib) it is mandatory for us to rebuild all for mingw64
<bvernoux>
other work in progress is to fix the CI build for Ubuntu
<bvernoux>
For those interested I have found the solution to do recursive static lib link with cmake
<bvernoux>
using -Wl,--start-group -lOGLCompiler -lGenericCodeGen -lMachineIndependent -Wl,--end-group
<d1b2>
<Makerprobe> trying to build glscopeclient as per glscopeclient-manual, during glscopeclient-apps make: glscopeclient/scopehal-apps/lib/scopehal/VulkanInit.cpp:36:10: fatal error: glslang_c_interface.h: No such file or directory 36 | #include <glslang_c_interface.h> ` | ^~~~~~~~~~~~~~~~~~~~~~~
<azonenberg>
Is this on Linux or Windows?
<d1b2>
<Makerprobe> ubuntu 22.04 LTS
<azonenberg>
And do you have the Vulkan SDK installed?
<bvernoux>
I have documented it
<azonenberg>
(I suggest installing from the .deb packages, not the tarball - i think at one point hte manual said to use the tarball)
<d1b2>
<Makerprobe> yes I went through section 3 of the installation instructions (Vulkan SDK)
<azonenberg>
bvernoux: please assist since you seem to have solved this recently
<azonenberg>
I just installed the .deb SDK and it worked
<bvernoux>
I'm not sure the main repo is up to date
<bvernoux>
with the fixes for the build
<bvernoux>
I'm waiting the CI build finish for windows (I hope with success) and I will switch to my native Xubuntu 22.04 LTS to rebuild all
<d1b2>
<Makerprobe> well I'll just go through the ubuntu workflow now and keep you updated about ... things
<azonenberg>
bvernoux: i have not merged your most recent PR. i'll be reviewing that code after i finish the multimeter dialog work i'm doign right now
<bvernoux>
yes doc shall be not far from that
<bvernoux>
yes anyway latest PR is for Windows mingw64
<bvernoux>
for Ubuntu all shall work fine it just miss few steps in documentation
<bvernoux>
collect2: error: ld returned 1 exit status
<bvernoux>
it is like the lib path to VulkanSDK lib is not set
<bvernoux>
very strange
<d1b2>
<Makerprobe> I'm still getting the same error. How can I check if that include file is present on my system?
<bvernoux>
as GenericCodeGen lib are in vulkan\1.3.224.1\x86_64\lib
<bvernoux>
I have understood
<bvernoux>
the build with the CI is set to debug
<bvernoux>
so it search the debug lib which does not exist in VulkanSDK ...
<bvernoux>
so we shall change the default build to Release
<d1b2>
<Makerprobe> I did actually try to build release
<bvernoux>
as VulkanSDK does not include debug lib for Linux (like for WIndows)
<bvernoux>
do you have used latest git ?
<d1b2>
<Makerprobe> latest state of scopehal-apps you mean?
<bvernoux>
in your repo scopehal-apps\cmake\ you shall have FindVulkan.cmake ...
<d1b2>
<Makerprobe> yes it's there
<d1b2>
<Makerprobe> `-- Could NOT find Vulkan (missing: Vulkan_LIBRARY Vulkan_INCLUDE_DIR) (found version "")
<bvernoux>
@azonenberg, the advantage when building glslang is we can build both Release or Debug and so use the Release or Debug with glscopeclient ...
<bvernoux>
@azonenberg, with VulkanSDK it is a dead end for that
<_whitenotifier-7>
[scopehal-apps] azonenberg eb4f3eb - Fixed bug where minimizing a WaveformGroup called ImGui::End() twice
<_whitenotifier-7>
[scopehal-apps] azonenberg 4eab49d - Initial implementation of MultimeterDialog. Fixed rounding error in PSU/meter trend plots.
<_whitenotifier-7>
[scopehal-apps] azonenberg a8a8bc9 - MultimeterDialog: initial mode support
<bvernoux>
it seems the GitHub CI build has frozen ;)
<azonenberg>
ok, i've got a few chores to do but should have the multimeter functionality done in another half hour or so of work. i think all i have left to do is implement the autorange switch and start/stop mode
<bvernoux>
ha great
<bvernoux>
it will be a good POC to have something to test
<t4nk_fn>
I'm not sure about that, johnsel, because it says "This is not related with VulkanTools, part of the LunarG Vulkan SDK and currently not packaged on Gentoo."
<d1b2>
<johnsel> no that is fine you don't need that
<bvernoux>
In theory Ubuntu build shall be fine now
<bvernoux>
I will do a PR if all is good
<bvernoux>
then you can start optimization
<bvernoux>
Potentially Ubuntu build shall also build glslang to produce debug or release build for Ubuntu
<t4nk_fn>
johnsel, I am, and was getting "src/imgui/backends/imgui_impl_vulkan.cpp:1076: bool ImGui_ImplVulkan_Init(ImGui_ImplVulkan_InitInfo*, VkRenderPass): Assertion `info->Queue != nullptr' failed."
<bvernoux>
As so far only Release is supported as the lib are from VulkanSDK on Ubuntu build which contains only Release lib
<t4nk_fn>
(I had meanwhile installed vulkan-layers)
<d1b2>
<johnsel> I do see a problem with how we install Vulkan SDK now on ubuntu, you're just copying a big amount of unlisted files to system folders. how do you properly uninstall?
<t4nk_fn>
yeah, hhehe, that's my problem.. I'm not willing to do that
<t4nk_fn>
but maybe it is a bit easier on gentoo
<d1b2>
<johnsel> no it's also not the official instructions to do it this way
<bvernoux>
johnsel yes it is the issue of VulkanSDK install it is not clean at all
<t4nk_fn>
mmm, I was reading 'glscopeclient-manual.pdf'
<bvernoux>
johnsel it is ok for CI Build but for real computer it shall be modified to something cleaner ... (for information it is official build steps provided by VulkanSDK documentation ...)
<d1b2>
<johnsel> jeez, you're right
<d1b2>
<johnsel> can we modify it? you're already modifying path and ld searchpath
<bvernoux>
yes it can be part of the improvment
<d1b2>
<johnsel> then we can also put it in the docs and forget about it
<bvernoux>
yes clearly for the docs it shall be not like that
<d1b2>
<Makerprobe> I've tried to build again in a fresh terminal, all paths are exported, but I still get the same error (glslang_c_interface.h not found). It must be missing on disk, or something else is not set or not set correctly
<d1b2>
<johnsel> alright I do think we should keep CI and docs as much equal as we can but at least it is working now
<t4nk_fn>
so.. am I to understand that installing the vulkansdk by copying those files over to /usr/local/include and /user/local/lib and such.. is all that is needed for me to do? (step 3. install Vulkan SDK)
<bvernoux>
yes it is the crappy official way to install vulkansdk
<d1b2>
<johnsel> ideally, no, but it is what the process is now.
<d1b2>
<johnsel> they don't actually recommend it though bernoux
<d1b2>
<johnsel> there are scripts to just set up the environment with the right paths which should be enough
<t4nk_fn>
mmmm if that is really true then that is probably just fine for me here on gentoo. I'd have to ask to be sure, but things are probably well kept track of
<d1b2>
<johnsel> as well as you are doing that manually too, but also copying over the actual files to their default paths
<t4nk_fn>
if I create an ebuild for it that is ;)
<t4nk_fn>
I've been sort of religious about not running any make installs whatsoever
<d1b2>
<johnsel> do you have the sdk?
<d1b2>
<johnsel> you could just try running that env script first and see how far you get
<t4nk_fn>
euh, I can download it I guess, from https :// sdk . lunarg . com / sdk / download /1.3.224.1/ linux / vulkansdk -
<t4nk_fn>
linux - x86_64 -1.3.224.1. tar . gz or the likes?
<d1b2>
<Makerprobe> the exported path points to ~/vulkan/1.3.224.1/x86_64/vulkan/include which does NOT contain the missing header file. I do find that header in ~/vulkan/1.3.224.1/source/glslang/glslang/include though, but it doesn't look like the build environment knows about that location
<d1b2>
<Makerprobe> how would I run it? just executing glscopeclient gives me a missing .so error (a bit naive maybe, I admit that)
<d1b2>
<Makerprobe> `./glscopeclient: error while loading shared libraries: libscopeprotocols.so: cannot open shared object file: No such file or directory
<_whitenotifier-7>
[scopehal] bvernoux b9eec8e - Fix scopehal build for WIN32 (Windows mingw64) Fix scopehal build for WIN32 (Windows mingw64) To build successfully it is required to install VulkanSDK-1.3.224.1-Installer.exe and build glslang.git tags/sdk-1.3.224.1 with mingw64 - VulkanSDK-1.3.224.1-Installer.exe available on https://vulkan.lunarg.com/sdk/home - Build glslang.git tags/sdk-1.3.224.1 with mingw64 ``` #
<_whitenotifier-7>
Windows mingw64 glslang build (as it is not fully integrated in VulkanSDK-1.3.224.1 for Windows and built with Visual Studio 2017) cd ~ git clone https://github.com/KhronosGroup/glslang.git cd glslang git checkout tags/sdk-1.3.224.1 git clone https://github.com/google/googletest.git External/googletest cd External/googletest git checkout 0c400f67fcf305869c5fb113dd296eca266c9725 cd ../.. ./update_glslang_sources.py
<_whitenotifier-7>
[scopehal-apps] azonenberg 12e7490 - Updated to latest scopehal
<azonenberg>
bvernoux: ok update your local scopehal and push your fork and it should be ready to merge. i'll review after you get that done
<d1b2>
<Makerprobe> I added them temporarily by setting LD_LIBRARY_PATH accordingly, it now complains about libscopeexports.so which is not part of the build artifacts
<d1b2>
<Makerprobe> so since I don't really need glscopeclient (I was just curious), I'll leave it at that and hope that the problems I had on my system just magically disappear next time I give it a try
<bvernoux>
Just wait the merge
<bvernoux>
where CI Build and build are fixed for both Windows mingw64 & Ubuntu
<bvernoux>
so far I'm still using wsl2 without GUI
<bvernoux>
if you have any link to add GPU acceleration I'm interested
<bvernoux>
I know for VirtualBox it is a dead end since lot of years and nothing have changed in best case it support OpenGL 1.0 ;)
<ehntoo>
I wasn't making much further progress on my macOS troubleshooting, so I decided to do some lateral testing with the Dear ImGui GLFW+Vulkan example app. It _also_ has issues as soon as you enable `ImGuiConfigFlags_ViewportsEnable`, so this appears to be an upstream issue.
<d1b2>
<johnsel> I mean if you're up to date it should just work
<bvernoux>
will be great to avoid switching all the time from windows to linux
<ehntoo>
ok, never mind, I missed adding an extra call when enabling viewports. the upstream example works fine. cool, I've got a point of comparison now
<azonenberg>
ehntoo: ah great
<bvernoux>
haha the joke WSLg is for WIndows11
<bvernoux>
and my system does not meet minimal config
<bvernoux>
But on some page they say latest Windows10 support it
<d1b2>
<david.rysk> does not meet minimal config -- too old cpu?
<d1b2>
<david.rysk> pretty much any computer with 8th gen intel or 2nd gen ryzen or newer should run Windows11
<bvernoux>
ha ok I need build >= 21364
<azonenberg>
look who's talking with an ivy bridge cpu :p
<bvernoux>
and I have stable version Windows10 OS build 19044
<d1b2>
<david.rysk> I have a bunch of computers over here 😛
<bvernoux>
the issue is not the CPU
<d1b2>
<david.rysk> and yes the one that I'm primarily running off right now is a Thinkpad X230T with an i7-3520M
<bvernoux>
it is they requires the crypto shit
<d1b2>
<david.rysk> oh
<d1b2>
<david.rysk> that's easier to fix
<d1b2>
<david.rysk> update the BIOS then go into setup and turn it on
<d1b2>
<david.rysk> if the CPU is new enough, it will support a vTPM
<bvernoux>
(TPM) version 2.0.
<bvernoux>
it is really bullshit
<d1b2>
<david.rysk> from everything I can tell, all the CPUs in the Win11 supported device list support a vTPM version 2.o0
<d1b2>
<david.rysk> 2.0*
<bvernoux>
of course I have an old computer with TPM<2.0
<azonenberg>
why did they require that? are they trying to push 100% FDE or something?
<azonenberg>
(like android is)
<bvernoux>
yes they want to push user to buy new computer
<d1b2>
<david.rysk> some computers have a toggle where you can either turn on a vTPM or a dTPM, and the dTPM is usually 1.1
<d1b2>
<david.rysk> 1.2*
<d1b2>
<david.rysk> azonenberg: they already use it for office licensing where available
<azonenberg>
oh i was about to say
<azonenberg>
the only two things i see TPMs used for is DRM and FDE
<d1b2>
<david.rysk> but anyway, my point is that if you have a supported CPU, you should be able to enable TPM 2.0 using vTPM
<d1b2>
<david.rysk> however, that may require a BIOS update and going into setup and turning it on.
<azonenberg>
new multimeter UI is coming along nicely
<bvernoux>
I have disabled UEFI too ;)
<bvernoux>
it is bullshit
<bvernoux>
as anyone can bypass UEFI too
<d1b2>
<david.rysk> UEFI needs to be enabled, secure boot does not.
<d1b2>
<david.rysk> Win11 does not require secure boot to be enabled
<bvernoux>
so for the moment I will do not use WSL GUI
<bvernoux>
I do not want to be tracked by MS$ even more just for that
<d1b2>
<david.rysk> UEFI isn't secure boot, it's a more modern boot method where instead of jumping to code at the beginning of the drive, the firmware looks for a specific partition and then runs a specific file on it
<bvernoux>
they ask metering to be enabled to have access to latest update and so on
<bvernoux>
Yes I can enable UEFI it was disabled because years ago there was issue to boot Linux with UEFI
<bvernoux>
but it is solved since lot of time now
<bvernoux>
especially with distrib like Ubuntu
<azonenberg>
also holy moley it took 47 minutes for the ci build on ubuntu
<azonenberg>
we need to get some big iron doing the CI builds sooner rather than later lol
<azonenberg>
my workstation can build glscopeclient from nothing in about 3 minutes
<bvernoux>
yes the CI build time is awfull
<azonenberg>
sure i dont have to isntall packages first
<bvernoux>
on windows it take more than 2h ;)
<azonenberg>
johnsel is already looking into that. if we can get funding i want to just build a box and slap it in a rack somewhere
<azonenberg>
and dedicate either one machine running a bare metal version of each OS, or one machine with a hypervisor and a couple pcie passthru GPUs
<azonenberg>
and dedicated CI VMs
<bvernoux>
already 50min to build glslang
<bvernoux>
it is awfull
<azonenberg>
anyway so i have to add some tooltips to the multimeter dialog and then it will be done
<azonenberg>
at least, as done as it can get without me adding more features to the APIs
<azonenberg>
next up will probably be function generator as that's easy
<bvernoux>
I really think we will need to also build glslang for Linux to have something customizable especially for the Debug build
<azonenberg>
(this is me killing time building UI stuff because i can't do actual scope control until lain finishes the renderer rewrite... poke poke)
<bvernoux>
but it is not something which shall be built each time and it can be cached
<azonenberg>
Yes having an internal binary package in a repo/server we can just wget and install will help save time
<azonenberg>
bvernoux: anyway i'm still waiting for a PR to scopehal-docs to update the build instructions
<bvernoux>
it is WIP ;)
<azonenberg>
ok just making sure it doesnt get forgotten
<bvernoux>
Will need to validate it to be sure too
<bvernoux>
because of scopehal-apps/msys2/PKGBUILD which does not define the CBUILD so it is Debug by default
<electronic_eel>
aws also has windows and arm mac clients
<electronic_eel>
i haven't tried their open source sponsoring thing yet, but i just stumbled upon it while researching something else
<azonenberg>
electronic_eel: so the arm mac ones are expensive
<azonenberg>
because they have a 24 hour minimum per apple licensing requirements
<azonenberg>
you cant spin up spot instances
<azonenberg>
it ends up being better to just grab an older m1 machine from somebody who upgraded and shove it on a shelf with a cable coming out the back
<electronic_eel>
yeah, they are expensive to rent. but i don't know what kind of sponsoring aws offers. for some other projects they are quite generous
<azonenberg>
aws is an option but i suspect it would end up costing a lot of money. we dont need huge amounts of ultrafast disk and network bw and crazy high uptime
<azonenberg>
(assuming we werent sponsored)
<azonenberg>
what we need is a little bit of GPU and a lot of CPU, for short periods with a lot of downtime in between
<electronic_eel>
i don't think aws would make much sense if they don't sponsor it
<azonenberg>
yeah i was tempted to just slap an instance down on my xen server
<bvernoux>
yes lot of CPU mainly means lot of CPU in // to build quickly
<electronic_eel>
i just wanted to let you know that the option of sponsoring exists
<azonenberg>
although i need a better CPU on it first
<bvernoux>
with enough RAM of course ;)
<bvernoux>
Ryzen9 shall do the trick
<bvernoux>
I'm waiting the new Ryzen ;)
<azonenberg>
ehntoo: re the font texture in the left panes, that is normal and expected
<ehntoo>
gotcha
<azonenberg>
lain is still working on (hasn't started yet?) porting the opengl waveform rendering shader and infrastructure to vulkan
<azonenberg>
so until we have actual waveform data to draw, i'm drawing the first texture i had handy
<azonenberg>
and that was the font :p
<bvernoux>
yes the bitmap font ;)
<ehntoo>
'=D
<bvernoux>
so yes I confirm it is the same rendering on Windows/Linux
<azonenberg>
bvernoux: Imgui uses bitmap fonts for everything afaik. if you load a TTF it just gets rasterized to a bitmap and then treated the same, no?
<bvernoux>
no TTF are better
<azonenberg>
oh it does vector rendering of them?
<bvernoux>
yes
<bvernoux>
it is why it is a must
<azonenberg>
anyway, switching to better fonts is definitely important. just have to do it in a portable fashion
<bvernoux>
it use the vertex correctly with the TTF
<bvernoux>
as everything is already vector
<azonenberg>
might have to find a freely licensed font and redistribute it
<azonenberg>
to keep things simple
<bvernoux>
the bitmap are just faster/easier to use IIRC
<azonenberg>
yeah i skimmed things briefly but didnt have a chance to investigate in detail. that's something i can worry about later after we get the rest of the infrastructure set up
<d1b2>
<johnsel> you'd have to go to your org and go the runners in the org config
<d1b2>
<johnsel> there you can request access to the beta and set it up
<ehntoo>
got it! Somehow the call to `glfwInitHint(GLFW_COCOA_MENUBAR, GLFW_FALSE);` was responsible for both breaking input handling and preventing the
<ehntoo>
app from registering in the task switcher
<d1b2>
<johnsel> ooops
<azonenberg>
ehntoo: interesting
<azonenberg>
i just wanted to say "there is no top level menu" since we have our menu in the app
<azonenberg>
johnsel: any idea if they support GPUs?
<d1b2>
<johnsel> I do, they don't
<ehntoo>
I'm extremely puzzled by that interaction.
<ehntoo>
but :shrug:
<d1b2>
<david.rysk> "no top level menu" isn't great on macOS 😦
<azonenberg>
(if we can get something beefy enough, we should be fine using swiftshader)
<d1b2>
<johnsel> maybe, but it might also introduce a whole new can of worms with CI-only problems to fix
<d1b2>
<johnsel> but given the effort to move away from it I think it's worth attempting for sure
<azonenberg>
yes. I'm still open to deploying dedicated hardware and i think we can get budget
<azonenberg>
(using github actions still, just hosted endpoints)
<d1b2>
<johnsel> nothing beats an actual test
<azonenberg>
self hosted*
<azonenberg>
yeah we'd just need an actual github enterprise plan and a bunch of infrastructure set up around that
<d1b2>
<johnsel> yeah I gathered that, but we know self hosted Windows will be shitty w/ mingw to set up
<azonenberg>
(and that's a bit expensive - $231 *per user* per year)
<d1b2>
<johnsel> you don't need enterprise for self hosted though
<azonenberg>
no i meant for the hosted big runners
<azonenberg>
actually, it's uncelar
<azonenberg>
team or enterprise
<azonenberg>
the docs are contradictory
<d1b2>
<johnsel> well regardless I think downsizing the repo is best, there is no need to build everything in one
<d1b2>
<johnsel> just split it out to it's own repos
<d1b2>
<johnsel> we had that discussion for scopehal, which we can disagree on but keep monorepo but dependencies for sure can be moved out of the main repo
<azonenberg>
well as we refactor things, and transition to ngscopeclient, things should get lighter weight
<azonenberg>
ditching the opencl stuff already helped
<azonenberg>
ditching gtk and ffts should too
<azonenberg>
there is room to optimize global #includes wrt build time
<d1b2>
<johnsel> sure but same for vulkan etc, we should be able to just prepare and build our dependencies in some other repo and just have a tar.gz output that we pull back in in the main repo
<azonenberg>
i think we can cut a fair bit of time off the builds by some careful inspection and include-what-you-use deployment
<azonenberg>
yes caching some of that will help. i dont build the SDK in our normal build proecss, that is purely CI
<azonenberg>
having a cached artifact of the SDK should help enormously
<d1b2>
<johnsel> sure but the CI is at hours of build time, your local build isn't
<azonenberg>
well i also dont install the sdk anew and compile from source every build :p
<_whitenotifier-7>
[scopehal-docs] bvernoux ced1b3e - Update how to build On Debian/Ubuntu & Windows(MinGW64)
<_whitenotifier-7>
[scopehal-docs] azonenberg da62209 - Merge pull request #46 from bvernoux/master Update how to build On Debian/Ubuntu & Windows(MinGW64)
<ehntoo>
there's some nontrivial CMake modifications dealing with the way Vulkan libraries are linked in #687 - After staring into FindVulkan.cmake abyss for longer than I'd like, I'm _fairly_ confident it should be portable across platforms, but it'll be good to verify.
<azonenberg>
ehntoo: glscopeclient was compiling and running on osx as of a week or two ago thanks to lain's porting work. but it's not actually usable
<azonenberg>
in particular, it will fail as soon as you create a waveform plot
<ehntoo>
ahhh, gotcha
<azonenberg>
because it is attempting to use opengl 4.3
<azonenberg>
the key item left on her docket right now is getting the renderer converted from gl 4.3 to vulkan
<azonenberg>
once that's done, we can merge it into glscopeclient (using gl 2.x - which runs on osx - as the compositor) and get the basics operational
<ehntoo>
awesome
<azonenberg>
and then take the same converted shader and rendering logic and plug it into ngscopeclient as the future-facing path
<azonenberg>
which will skip a gpu-cpu-gpu copy and a bunc hof overhead plus all the baggage GTK drags along
<azonenberg>
and just take the output of the vulkan compute shader and plug it right into a texture imgui can render
<azonenberg>
the other known failure on osx (arm64 at least) at this point is FFTS
<azonenberg>
which is currently used in the FFT, de-embed, channel emulation, and CTLE filters as a fallback if you run --nogpufilter, and in the unit tests for cross checking results agianst vkFFT
<azonenberg>
it is also used in the spectrogram filter which is currently not gpu accelerated
<azonenberg>
fixing this is on my todo list
<azonenberg>
at that point it should be possible to do a pure vkfft build and maybe even make ffts a compile time option that's disabled if not present
<azonenberg>
(in which case --nogpufilter will result in these filters not running)
<azonenberg>
but that's fine as that is a developer/debug option intended for troubleshooting filters
<azonenberg>
not something an end user wouuld ever use
<azonenberg>
the intent is for as much processing as possible to be done on the gpu and ideally keep waveform data there indefinitely
<ehntoo>
would there be any short-term value in looking into the FFTS issues on arm64 macOS?
<azonenberg>
Minimal. You can't use glscopeclient until the renderer rewrite is done
<azonenberg>
after that, the only things affected are unit tests and the spectrogram filter
<azonenberg>
which is due for a gpu accelerated rewrite anyway
<azonenberg>
We are moving away from FFTS specifically because it's basically dead, the last commit was in 2017
<azonenberg>
i dont want to lift a finger to give it more life than needed at this point
<azonenberg>
that effort is much better spent elsewhere
<ehntoo>
makes sense to me.
<azonenberg>
(We also were leaving clFFT for the same reason, it's also abandonware, however that effort was successfully concluded and we're now using vkFFT everywhere we had been using clFFT)
<d1b2>
<david.rysk> Yeah and OpenCL is basically dead
<azonenberg>
my big problem was that nvidia's dev tools for it were literally nonexistent
<d1b2>
<david.rysk> Vulkan and Metal is where everything is going (and DX12 but that can be generally be ignored)
<azonenberg>
you couldnt profile it or anything
<azonenberg>
also major thread safety issues causing crashes i had worked around, and occasional garbage results i had not solved
<azonenberg>
despite various methods being documented as thread safe, some were in fact not
<d1b2>
<david.rysk> it got mostly abandoned after Apple pulled out of 2.0, and nvidia has an interest in keeping developers on CUDA
<azonenberg>
i do find it ironic that apple was one of the key players in opencl early on, if not the single biggest driving force
<azonenberg>
and then they ended up deprecating it
<azonenberg>
anyway, nvidia's tooling eats vulkan just fine
<d1b2>
<david.rysk> There is some serious private legal dispute going on between Apple and Khronos. I wish they would just settle…
<d1b2>
<david.rysk> And yeah Vulkan seems to be the way to go especially with MoltenVK seeming to be workable
<azonenberg>
Yeah
<azonenberg>
it's definitely the way of the future for cross platform gpu acceleration
<azonenberg>
My original plan had been to migrate to vulkan when we transitioned glscopeclient to gtk4
<azonenberg>
because gtk4 had at least some vulkan integration
<azonenberg>
over time it became clear that a) this was going to hold us back a lot on portability, b) gtk was slow, and c) gtk4 used vulkan on the backend but actually did not have a great way to integrate with it as an app rendering directly
<azonenberg>
and d) gtk4 wasn't going to hit stable distros until mid 2023 at the soonest
<azonenberg>
so if we were going to put that much work in, it made sense to change things up