<cyborg_ar>
my scope doesnt have per-channel bandwidth limiting, it is a global setting for the whole scope
<d1b2>
<david.rysk> @azonenberg @johnsel without very much caching a GH hosted CI run takes about 20min
<d1b2>
<david.rysk> Will have best-casae numbers with caching soon
<d1b2>
<david.rysk> best-case*
<azonenberg>
cyborg_ar: innnteresting
<azonenberg>
file a ticket, thats not something we can cleanly express in our current api
<cyborg_ar>
for now im just ignoring it, i dont normally use it. for you this scope is DC anyway, 150MHz :P
<azonenberg>
we have worked with some instruments where a particular setting was either per channel or global based on the model, but have never seen that for bandwidth limit
<azonenberg>
yeah but still good to know this is a thing that exists
<cyborg_ar>
ugh i wish parsing strings in C++ wasnt such a pain. im so spoiled with python...
<cyborg_ar>
kind of bothers me the driver is doing its won parsing with sscanf, i should be able to pass the transport a format spec and get back a parsed response back, with built in error handling. here most calls with sscanf are unguarded so a bad response can mess things up or crash
<azonenberg>
Yeah improving robustness would be nice to do. but I'm less worried about input parsing bugs in this particular context
<azonenberg>
you're talking to hopefully trusted hardware that should be on an isolated network
<azonenberg>
like, anyone who can tamper with the probably-unencrypted-and-unauthenticated can change your power supply voltage and fry your DUT
<azonenberg>
being able to segfault ngscopeclient with malformed traffic is the least of your worries in that situation
<azonenberg>
making it more robust to user error would certainly be nice, i'm absolutely open to improvements in that regard
<cyborg_ar>
for pure SCPI instruments some sort of auto-probing would be nice too, since each driver should be able to know if they can drive an instrument for a given *IDN? response. non-scpi instruments of course dont get that
<azonenberg>
Yes. That is on the distant wishlist
<azonenberg>
some way to connect to an unknown transport and figure out what driver to invoke on it
<azonenberg>
Also improving robustness if you accidentally select the wrong driver. generally more exceptions and clean error handling will be nice to have eventually
<cyborg_ar>
ah yeah whats the policy on exceptions here?
<azonenberg>
Not currently used, except by the Vulkan wrapper library and I think the YAML parser
<cyborg_ar>
C++ exceptions are kinda ugly so some projects dont even use them
<cyborg_ar>
ah ok
<azonenberg>
but we are probably going to start using them as it seems better than the way we do things now
<azonenberg>
in particular for instrument creation failures
<azonenberg>
theres no good way to get feedback that a connection failed or a driver couldn't initialize in the curent model
<azonenberg>
Backstory: this code is the descendant of something i wrote during my thesis to "just get my work done" and only went public in a form that was buildable by other people (no hard coded paths etc) circa 2020
<azonenberg>
and it took a while for momentum to build and more people to get interested in working with it
<azonenberg>
So there's a fair bit of legacy cruft that needs cleaning out
<azonenberg>
the frontend is generally nicer code because it was completely rewritten recently
<cyborg_ar>
yeah i noticed the program would just crash or your would get a partially initialized instrument
<_whitenotifier-3>
[scopehal-apps] azonenberg cc3acb1 - Merge pull request #677 from d235j/headless-tests Prevent glfw init for tests as glfw requires an X/Wayland server
sgstair has quit [Read error: Connection reset by peer]
sgstair has joined #scopehal
bvernoux has joined #scopehal
<_whitenotifier-e>
[scopehal] azonenberg bfdbe24 - I2CDecoder: removed ascii output since we now have hexdump and ascii output in the protocol analyzer directly from the binary data
<_whitenotifier-3>
[scopehal-apps] ... and 3 more commits.
<azonenberg>
Finally finished
<azonenberg>
This was a massive, like literal order of magnitude difference in framerate, improvement on my test dataset
<azonenberg>
went from "barely possible to use but super annoying and jerky" to butter smooth 60 FPS
<azonenberg>
on a 1-minute-long bus capture with ~75K packets in the analyzer view
<azonenberg>
just in time too, monday starts in 15 minutes and it's a work day
<azonenberg>
and i really didnt want to have to put up with this lag for another work day :p
<d1b2>
<246tnt> For some reason I still can't build master : CMake Error at lib/scopehal/CMakeLists.txt:263 (target_link_libraries): Target "scopehal" links to: Vulkan::glslang but the target was not found. Possible reasons include: * There is a typo in the target name. * A find_package call is missing for an IMPORTED target. * An ALIAS target is missing.
<d1b2>
<azonenberg> @david.rysk ^
<d1b2>
<246tnt> (This is without david's rework of build. With his cmake-cleanup branch it works fine)
<d1b2>
<johnsel> I wouldn't worry about it then, that'll get integrated soon
<azonenberg>
ah ok
<azonenberg>
also hmm it seems my culling rework broke the "select closest packet when you move the cursor" workflow
<azonenberg>
unless the cursor happens to be over a packet in the visible (non culled) part of the list
<d1b2>
<johnsel> azonenberg can you ping 10.2.14.10 ?
<azonenberg>
no
<d1b2>
<johnsel> I'm pretty sure I used to have RDP access to that stupid box
<d1b2>
<johnsel> it thinks it has an ip but is also not connecte
<d1b2>
<johnsel> and console has 0.05fps
<d1b2>
<johnsel> it might be the e1000 adapter but I can't template the RTL one
<d1b2>
<johnsel> grrrr
<d1b2>
<johnsel> sometimes I wish we went with VSphere instead
<d1b2>
<johnsel> would've been done by now
<d1b2>
<johnsel> great it crashed
<d1b2>
<johnsel> azonenberg can you check the logs?
<d1b2>
<johnsel> this new vm won't start
<d1b2>
<johnsel> it says I should check the logs
<d1b2>
<johnsel> oh now it did start
<d1b2>
<johnsel> so strange this, it's also extremely slow to stop the vm or start it
<d1b2>
<johnsel> almost as if things are going wrong on the xen level
<d1b2>
<johnsel> ok good
<d1b2>
<johnsel> @azonenberg can you pull a new template?
<d1b2>
<246tnt> Oh wow, just got a fail notif for the workflow run on github from my PR ... it took 15h to fail ...
<d1b2>
<johnsel> Hopefully the issue is resolved now. For some reason when I create a vm from that template it'll be super slow and BSOD. When I create it through the GUI everything is fine. So annoying. I remember running into this before, so I may need to re-build that template as well perhaps
<d1b2>
<johnsel> anyway config/setup wise I think we're mostly good
<d1b2>
<johnsel> just got to figure out the x server situation on the linux ci box
<d1b2>
<johnsel> but please make sure there is a GPU assigned to it as well. I didn't get one in the last session so it might have lost the association
<azonenberg>
Also reminder everyone, dev call is in just over two hours. I'll drop a zoom link in here shortly
<d1b2>
<johnsel> The GPU objects can be listed with the standard object listing commands: xe pgpu-list, xe gpu-group-list, and xe vgpu-list. The parameters can be manipulated with the standard parameter commands. For more information, see Low-level parameter commands.
<_whitenotifier-3>
[scopehal] azonenberg e849e30 - Fixed two filters that included scopeprotocols.h forcing them to be recompiled needlessly when any other filter header was changed
<d1b2>
<david.rysk> Or have it in if-blocks in the workflow
<d1b2>
<david.rysk> But if you do it on the VM ahead of time, that speeds up build
<d1b2>
<johnsel> yes but try to make it possible to copy from the script
<d1b2>
<johnsel> I always run builds by copying from the github actions if I can
<d1b2>
<johnsel> this way you know everyone gets the same build environment as well
<d1b2>
<johnsel> it's fine splitting out stuff to separate scripts as well
<d1b2>
<johnsel> I wouldn't even put 2 versions of the same OS in one file
<d1b2>
<johnsel> ideally, if you want to keep github runners, we want to just add self-hosted to the existing scripts for those we have an OS image for
<d1b2>
<johnsel> there shouldn't be much management overhead
<d1b2>
<david.rysk> I can add them in once the VMs are working
<d1b2>
<david.rysk> you'll end up with mostly duplicated scripts
<d1b2>
<johnsel> that doesn't matter if it simplifies administrating
<d1b2>
<johnsel> and I can get you a working vm if you want to run scripts against it
<d1b2>
<johnsel> and if andrew blesses it also ssh access
<d1b2>
<david.rysk> I'd like Debian, Fedora, Alpine, if possible
<d1b2>
<johnsel> and access to scopehal-ci with the cloud-config per os
<d1b2>
<johnsel> if you want to change what is pre-installed
<d1b2>
<johnsel> though I'm happy to do that too
<d1b2>
<johnsel> @azonenberg ^
<d1b2>
<johnsel> it's templates time again
<azonenberg>
yeah i can set up ssh access for you if needed. as far as templates go i'll do that in a min
<azonenberg>
Typing one handed with a sandwich in the other
<d1b2>
<david.rysk> don't preinstall anything, I'll put it in the scripts for now
<d1b2>
<david.rysk> then we can preinstall it and it can be a no-op in the scripts
<d1b2>
<johnsel> sure, let me make those changes and remove the ephemeral flag
<azonenberg>
ok template coming right up
<d1b2>
<azonenberg> I dont have the time to learn the ins and outs of how the CI works... just play well together kids 😛
<d1b2>
<david.rysk> can you also make it so that I can use the self-hosted runners from my fork?
<d1b2>
<johnsel> I can allow a PR
<d1b2>
<azonenberg> I'm not sure how it would work with a fork on your own repo. if it was a branch on the main repo, yes
<d1b2>
<johnsel> then all the changes pushed are ran
<d1b2>
<azonenberg> or yes a PR
<d1b2>
<david.rysk> I can PR the changes and put a comment to not merge yet 😛
<d1b2>
<johnsel> PR is easiest
<d1b2>
<david.rysk> but that will spam the crap out of this channel
<d1b2>
<azonenberg> yeah just mark as draft
<d1b2>
<johnsel> that's fine
<d1b2>
<johnsel> we like spam
<d1b2>
<azonenberg> I might want to change the notifier settings for that kind of stuff eventually
<d1b2>
<azonenberg> we are only recently getting enough dev activity that its getting annoying :p
<d1b2>
<johnsel> Yep ideally we get a summary
<d1b2>
<johnsel> but that is probably too much too ask
<d1b2>
<azonenberg> @johnsel which vm did you want templated
<d1b2>
<david.rysk> Any other OSes needed? For versions — currently supported? Do we include bleeding-edge Alpine and Fedora and Debian testing?
<d1b2>
<azonenberg> i dont see anything stopped
<d1b2>
<johnsel> No, david wants to add Alpine and Fedora
<d1b2>
<johnsel> I'm sure you -just- deleted them didn't you?
<d1b2>
<azonenberg> oh
<d1b2>
<azonenberg> lol
<d1b2>
<azonenberg> i thought i only removed old versions of stuff
<d1b2>
<azonenberg> but yeah i am not seeing either
<d1b2>
<johnsel> bhaha
<d1b2>
<johnsel> let me find that script
<d1b2>
<azonenberg> i think something went wrong during the removal
<d1b2>
<azonenberg> because debian jessie is still on there
<d1b2>
<azonenberg> and i dont see alpine
<d1b2>
<azonenberg> lol
<d1b2>
<johnsel> "create-guest-templates"
<d1b2>
<azonenberg> great
<d1b2>
<azonenberg> now we have two of everything
<d1b2>
<johnsel> yay
<azonenberg>
ok this might take some effort to clean up lol
<d1b2>
<johnsel> I'm doing a clean upgrade for debian to 12 while we're at it
<d1b2>
<johnsel> @david.rysk mind if I leave a few packages preinstalled on it?
<d1b2>
<johnsel> I can more easily revert to that template w/ gpu
<d1b2>
<johnsel> the others don't have the GPU attached
<d1b2>
<david.rysk> @johnsel sure go ahead, the only reason not having too much preinstalled would be to ensure we're testing the required package list in the docs
<d1b2>
<johnsel> and as we've established that is a pita
<d1b2>
<johnsel> I appreciate that you're willing to work with me to focus on the self-hosted stuff more
<d1b2>
<david.rysk> well at the moment GH-hosted is working
<d1b2>
<johnsel> I just don't want to end up with a situation where we end up with 2 heavily admin loading ci systems
<d1b2>
<david.rysk> I need to start working on include-what-you-use
<d1b2>
<david.rysk> and windows
<d1b2>
<david.rysk> I haven't touched windows yet
<d1b2>
<david.rysk> other than doing an early test of the CMake changes a while ago
<d1b2>
<johnsel> Yep that will be fun
<d1b2>
<johnsel> pm me your ssh key
<d1b2>
<johnsel> I'll set up ssh via ngrok so you can access it
<d1b2>
<azonenberg> (I'm getting him on the VPN soonish)
<d1b2>
<johnsel> yep
<d1b2>
<johnsel> if you want that is
<d1b2>
<david.rysk> I can wait for the VPN setup
<azonenberg>
(restarting xoa for a sec to fix something)
<azonenberg>
So i dont think we ever had alpine or fedora templates
<azonenberg>
we had *alma* linux
<azonenberg>
whatever that is
<d1b2>
<david.rysk> AlmaLinux was one of the two CentOS replacements
<d1b2>
<johnsel> oh then you need to fetch them somewhere
<d1b2>
<david.rysk> the other being Rocky Linux
<d1b2>
<johnsel> there is another something in xoa where you can download the templates
<azonenberg>
We also now have 86 templates installed including a ton of duplicates
<d1b2>
<johnsel> sorry that was probably the right thing to do from the start
<azonenberg>
and i cant seem to delete them
<azonenberg>
lol
<d1b2>
<johnsel> great
<d1b2>
<johnsel> I love xoa more and more every day
<azonenberg>
the hub shows alpine 3.10 and rocky 8.5
<azonenberg>
do you want one or both?
<d1b2>
<johnsel> alpina and fedora and ubuntu I think
<d1b2>
<david.rysk> Sooo rocky: how do we want to treat RHEL?
<azonenberg>
There is no fedora prebuilt template any where i can find
<d1b2>
<david.rysk> Rocky 8.5 == RHEL 8
<azonenberg>
we may have to install ourselves from an iso and template that
<azonenberg>
I dont have a specific list of targets. I know really ancient RHEL is probably not worth the effort to support
<d1b2>
<david.rysk> would it be less complex to just have one VM OS and use docker containers?
<azonenberg>
generally debian stable has been as old as i've targeted
<d1b2>
<david.rysk> I haven't looked at how GH selfhosted works under the hood
<d1b2>
<johnsel> if you want to help write the dockerfiles, that's definitely an option
<d1b2>
<david.rysk> the Dockerfiles would only have to bring it to the state needed for the GH runner, right?
<d1b2>
<david.rysk> right now I'm chasing bugs in glslang
<d1b2>
<johnsel> correct
<d1b2>
<johnsel> actually
<d1b2>
<johnsel> there is an existing software for docker + self-hosted gh
<d1b2>
<david.rysk> That sounds like a relatively simple Dockerfile tbh 🙂
<d1b2>
<johnsel> (which are just vms)
<d1b2>
<johnsel> yes there's some difficulty with the gpu usage
<d1b2>
<johnsel> same as with the normal vm
<d1b2>
<johnsel> it's no problem getting the pcie device in
<d1b2>
<david.rysk> so about that
<d1b2>
<david.rysk> I fixed the tests to not require an X server
<d1b2>
<johnsel> but getting a window session set up and attached
<d1b2>
<johnsel> (and eventually driven)
<d1b2>
<david.rysk> I think the PR for that got merged
<d1b2>
<johnsel> the unknown pci device isn't a graphics card
<d1b2>
<johnsel> none of the VMs are grabbing GPUs
<d1b2>
<azonenberg> wait what
<d1b2>
<johnsel> that's so strange
<d1b2>
<johnsel> I hate xoa
<d1b2>
<johnsel> this is such a headache
<d1b2>
<johnsel> we had this working in december
<d1b2>
<johnsel> both vm types had a GPU attached
<d1b2>
<david.rysk> what's the OS here?
<d1b2>
<david.rysk> windows?
<d1b2>
<johnsel> this is win11
<d1b2>
<johnsel> but it seems not to matter
<d1b2>
<david.rysk> what ven/dev are you seeing in device manager and what driver package are you installing?
<d1b2>
<johnsel> none
<d1b2>
<david.rysk> ahh right
<d1b2>
<david.rysk> I see above
<d1b2>
<johnsel> you should know that the ACL doesn't let you give access to the GPU
<d1b2>
<johnsel> so by way of the templates having a GPU the derivates got one as well
<d1b2>
<azonenberg> ok so let me try something
<d1b2>
<azonenberg> i'm going to try command line hotplugging a gpu to that vm and see what happens
<d1b2>
<johnsel> the whole "self managed resources set" and GPUs concepts are basically incompatible
<d1b2>
<johnsel> it's not implemented in XOA
<d1b2>
<johnsel> and then second there is only a passthrough GPU
<d1b2>
<johnsel> although it should be possible to create a GPU group with a pci ven/dev (which also sucks because those are equal for the 2) and assign that to the vm manually
<_whitenotifier-e>
[scopehal-apps] azonenberg f1c607c - Fixed logic checking for all density functions vs eye patterns being swapped, leading to spectrograms and other non-eye density plots not being zoomable in the Y axis
<_whitenotifier-e>
[scopehal-apps] azonenberg 9ad7ddf - Merge branch 'master' of github.com:ngscopeclient/scopehal-apps
<_whitenotifier-3>
[scopehal-apps] azonenberg 9c777d1 - Fix scrolling for culled packets
<d1b2>
<johnsel> though might mess up more state in the xen backend
<d1b2>
<azonenberg> I can try a host reboot after work
<d1b2>
<johnsel> xe vgpu-list is the closest I've come so far
<d1b2>
<johnsel> pci-assignable-list will list which devices are available to be assigned to guests. This will list all devices currently assigned to pciback, whether this was done by pci-assignable-add, or by the two methods mentioned in the previous section (linux command-line or manual sysfs commands).
<d1b2>
<johnsel> pci-assignable-list will list which devices are available to be assigned to guests. This will list all devices currently assigned to pciback, whether this was done by pci-assignable-add, or by the two methods mentioned in the previous section (linux command-line or manual sysfs commands).
<d1b2>
<david.rysk> I just squashed a lot of stuff
<d1b2>
<david.rysk> @johnsel once the xoa-side stuff is figured out I definitely can work on fixing up workflows for the selfhosted 🙂
<d1b2>
<david.rysk> right now I'll continue working on what works
<d1b2>
<johnsel> yep we'll see if the GPUs come back after a reboot
<d1b2>
<david.rysk> @246tnt does llvmpipe/lavapipe work when you add that patch?
<d1b2>
<johnsel> otherwise I just need to set up the runners
<d1b2>
<johnsel> but I am too tired now
<d1b2>
<johnsel> I'll do it soon, maybe tomorrow or the day after
<d1b2>
<david.rysk> that's fine
<d1b2>
<246tnt> @david.rysk What patch ?
<d1b2>
<david.rysk> The one that adds barriers
<d1b2>
<246tnt> No, it's merged already and it doesn't fix the issue for llvmpipe.
<d1b2>
<azonenberg> 😦
<d1b2>
<246tnt> But I forced the break out of the loop (manually forcing done to true) and that made it render. It's not a "correct" render (since it only goes through one iteration), but that points to me that the issue is related to done again.
<d1b2>
<david.rysk> can you tell where it gets stuck?
<d1b2>
<246tnt> No I'm not sure why it's not stopping. I don't think it's a shared mem issue because even doing the done signal distribution in the most conservative way possible, it's not triggering, so something else might be wrong.
<d1b2>
<david.rysk> are you allowed to have a barrier() inside that if-statement?
<d1b2>
<david.rysk> or wait, it's not inside, just alongside