<azonenberg>
lain: fixed a bunch of thread safety issues and resource leaks in ngscopeclient so pull when you get a chance
<azonenberg>
how far are you from being ready to merge the queue allocator?
nelgau has quit []
nelgau has joined #scopehal
<lain>
azonenberg: I think it's ready to merge for glscopeclient, but it breaks ngscopeclient currently. planning to fix that tonight; sleep schedule is way off normal currently lol
<lain>
also need to resolve some issues with tests failing, though comparing with current master, I'm not sure the broken tests are a result of my changes
<lain>
oh, neat. I just noticed resizing is very broken in glscopeclient on macOS :D
<azonenberg>
lain: does it totally throw off the aspect ratio or something?
<azonenberg>
in the gtk chrome?
<azonenberg>
thats a known issue and was one of the motivating factors for going to imgui
<azonenberg>
> sleep schedule is way off normal currently
<azonenberg>
in other news, water is wet
<azonenberg>
ok so, for ngscopeclient there is going to be a dedicated history manager separate from the dialog
<azonenberg>
the dialog will just be a visualization for it
<azonenberg>
and it will be part of the session
<lain>
oo nice
<lain>
and yeah it throws off the aspect ratio, so window contents extend beyond the actual window and get clipped, or the window isn't filled anymore and you get fun glitches
<lain>
ok right, there's two files blocking ngscopeclient on using queue manager. TextureManager.cpp and WaveformArea.cpp, because they use some global variables for queue families that are no longer relevant
<lain>
oh, of note is the fact that imgui holds onto a vk::Queue&. it's only used in two functions, so I think it'll be pretty easy to lock on those accesses in the future and support GPUs with a single queue, but for now I've patched around it by just having ngscopeclient hold a perpetual lock on its render queue, separate from the other queues, so you need at least 2 queues
<lain>
I plan to get that fixed up after I get queue manager all sorted
<azonenberg>
So imgui functions are all called in a couple of functions at the high level
<azonenberg>
basically VulkanWindow::Render
<azonenberg>
you can lock on that then unlock to allow background threads to run
<azonenberg>
which will allow us to run on single-queue platforms like my intel integrated gpu on my laptop
<lain>
yeah
<azonenberg>
for TextureManager, i think the best option is to the image be eConcurrent
<azonenberg>
and have the list of queue families encompass all possible queue families for now
<azonenberg>
it might be faster if we could narrow that down but for now it will get things working
<lain>
alright, I'll make a note to see about optimizing that in the future
<azonenberg>
That code path is only really used for toolbar icons right now
<azonenberg>
so if they're a little slow to render its not like it's a critical path
<lain>
ahh ok
nelgau has quit []
nelgau has joined #scopehal
<lain>
hmm.. actually, which queue families will access the Textures? it looks like just MainWindow, in which case it will only have a single family, and so we could just set exclusive access
<azonenberg>
So we use one queue to push the staging buffer to the image, and another for rendering
<azonenberg>
so i guess if we were to use the render queue for the transfer
<azonenberg>
then yeah you could use the render queue and make it exclusive
<azonenberg>
as long as the render queue is transfer capable
<lain>
hm
<azonenberg>
which it is on every device i am aware of
<azonenberg>
I havent checked a lot of AMD or embedded GPUs yet
<azonenberg>
on metal, all queues can do everything
<azonenberg>
on the intel cards i've looked at there's one queue that can do everything
<azonenberg>
on most nvidia, there's 16 queues that can do everything, 2 that can only do transfers, and 8 that can do compute and transfers
<azonenberg>
let me look at ap i4
<azonenberg>
a pi4*
<lain>
azonenberg: off the top of your head, where is the transfer done? or is that handled by an AcceleratorBuffer?
<azonenberg>
It's stagingBuf allocated on line 396
<azonenberg>
we pass it to the Texture constructor
<azonenberg>
the overload on line 48
<azonenberg>
the actual transfer is on line 89 - 117
<azonenberg>
maybe change it to take a commandbuffer and queue / queue family
<azonenberg>
that the transfer is to use
<azonenberg>
and then have those be the rendering queue
<lain>
ohh derp, I see
<lain>
I hope apple announces M2 Pro / M2 Max macbook pros next month like the rumors say. eventually I might be able to afford one, it'd make these builds go so much faster lol
<lain>
not that the M1 is slow by any stretch, but more cores + more ram == more faster :3
<azonenberg>
meanwhile i'm sitting here staring wistfully at my shiny new xeon attached to a heatsink sitting on a table in the lab
<azonenberg>
with no motherboard to mate it to
<lain>
Darius: oh nice hehe
<lain>
azonenberg: sadness.
<d1b2>
<Darius> good ole Intel and their socket segmentation 😦
<azonenberg>
darius: to be fair
<azonenberg>
they switched from 6 to 8 channel memory going from 2nd to 3rd gen
<azonenberg>
1st and 2nd were i think socket compatible, both were 6 channel
<d1b2>
<Darius> yeah but... they do plenty of socket shenanegans even so 😦
<azonenberg>
true
<d1b2>
<Darius> bit better in the server/workstation space though
<azonenberg>
yeah i havent touched intel consumer cpus since like 2015
<azonenberg>
pretty much everything i've built since then has had >= 128GB of ECC RAM lol
<azonenberg>
well ok except the storage cluster nodes which are less ram
<azonenberg>
but still xeons
<d1b2>
<Darius> they're pretty eyewatering
<d1b2>
<Darius> (cost wise)
<azonenberg>
Yes but i tend to keep hardware for a long time
<d1b2>
<Darius> the literal cost of using C++ 😅
<azonenberg>
:P
<azonenberg>
yeah sure, cause i'd need less if i was using python lol
<d1b2>
<Darius> you wouldn't be spending it on compile cycles anwyay
<d1b2>
<Darius> (modulo cython etc)
<azonenberg>
anyway, my core router is probably the oldest box i have in active service. i3-4160 with 16GB of RAM (not that it needs that much)
<azonenberg>
VM server is a xeon 4116 with 192GB currently, with upgrade to 5370 and 256GB in progress as soon as the not-dead mobo shows up
<d1b2>
<Darius> nice
<azonenberg>
First storage cluster node is a xeon 3106, although it will be inheriting the 4116 from the vm server post upgrade
<azonenberg>
the newer storage nodes are 4208s
<azonenberg>
all are 24GB of RAM which is pretty heavily used because ceph uses a lot for caching and metadata. so next time i add a drive to one of those boxes i will probably add significantly more memory
<azonenberg>
then my office workstation is dual socket xeon 6144 with 192GB
Degi has quit [Ping timeout: 250 seconds]
<azonenberg>
soldering/test equipment bench workstation is the newest build, a 4310 with 128GB
<d1b2>
<Darius> I guess you don't have to worry about winter heating much
<azonenberg>
and the microscope box is also fairly old, an i5-4590
<azonenberg>
32GB of DDR3 on that one
<azonenberg>
actually the T&M gear eats more power than the computers do
<d1b2>
<Darius> ah yes I can imagine
<azonenberg>
i leave the scopes on all the time, especially the 16 GHz one because it has a flaky power suplpy that blows GFCIs during powerup
<azonenberg>
but is fine once it's on
<azonenberg>
there is enough ground bounce it blows *adjacent* gfcis, that is
Degi has joined #scopehal
<azonenberg>
(it wont even turn on if *its* circuit has a gfci)
<azonenberg>
to avoid the risk of losing power to half the lab blowing multiple breakers (most of the lab is on gfcis for safety) i never shut it off lol
<azonenberg>
and i leave the other stuff on mostly for stability since they've got OCXOs etc
<azonenberg>
wrt winter heating, funny you say that
<d1b2>
<Darius> sounds like you need a house frequency reference 😄
<azonenberg>
i actually have to worry about winter *cooling* in the lab
<d1b2>
<Darius> lol
<azonenberg>
(that's on the todo, a stanford instruments gpsdo is on the wishlist)
<azonenberg>
stanford research*
<d1b2>
<Darius> work is like that if we are testing transmitters
<azonenberg>
the minisplit runs year round in cool mode
<azonenberg>
I've wanted to figure out a way to dump that waste heat into the house during winter and overboard in the summer
<d1b2>
<Darius> nice, we ship radar systems with PRS-10s
<azonenberg>
but havent found a way to pull that off yet
<azonenberg>
I was looking at the FS752
<azonenberg>
nice low profile 1U
<d1b2>
<Darius> try Jackson Labs MicroJLTs now, availability for the PRS-10 had been pretty touch and go and their recent ones also had poor reliabilty
<azonenberg>
and its a GPS disciplined OCXO not a rubidium
<azonenberg>
anyway, wrt power my base load for the entire house is somewhere in the 5.2 - 5.5 kW average range
<d1b2>
<Darius> nice
<d1b2>
<Darius> boggles
<azonenberg>
the lab is around 3 - 3.5 kW on the UPS
<azonenberg>
all servers + T&M gear and most other smaller stuff
<azonenberg>
that does not count soldering equipment, lighting, or cooling
<azonenberg>
so that ~2 kW is all of that plus the rest of the house, HVAC for the living spaces, etc
<azonenberg>
I would definitely save in the winter if i could dump my waste lab heat into the house but like i said, so far don't have a viable path forward
<d1b2>
<Darius> heat pump hydronic hot water? 🙂
<azonenberg>
I did put a fair bit of effort into efficiency. 3ish kW is not much for the amount of gear i'm running
<azonenberg>
like, i have a lot of server but many of them are mid tens of watts typical consumption
<azonenberg>
(last time i came up from a cold start i logged total power on the UPS as each piece of gear came up)
<d1b2>
<Darius> yeah
<azonenberg>
the cisco switches are fairly heavy
<azonenberg>
one of many reasons i want to replace them with my own fpga-based switching which would probably use half as much
<lain>
meanwhile we're still migrating a lot of our hardware to more modern, lower-power gear, because some quick math revealed that the expense of buying shiny new stuff is *rapidly* covered by the reduction in power bill lol
<azonenberg>
yes. i phased out all of my core2quad era stuff for that reason a couple years ago
<azonenberg>
but my 16 GHz scope is still a c2q
<azonenberg>
although i doubt the cpu is the big power hog there
<azonenberg>
not when it's all full of big chonker SiGe ADCs
<lain>
hehe
<azonenberg>
speaking of which when i'm visiting lecroy i want to ask them if it's the same chipset they use in the labmaster
<azonenberg>
i strongly suspect the 80 Gsps labmasters are two interleaved versions of the 40 Gsps converter on the wavemaster/sda
<azonenberg>
and the only reason they get 36 GHz BW instead of what the wavemasters do is a better frontend
<azonenberg>
the newer wavemaster/sda models can even interleave to get 80 Gsps but only on 2 channels
<lain>
currently our oldest hardware is some servers and blades with xeon e5-2609v2's
<azonenberg>
re shiny new stuff being lower power, i'm reminded of my intro to GPGPU work
<lain>
which aren't the worst, but they do idle a fair bit higher than a more modern cpu. haven't actually priced out replacing those yet, it's pretty hard to compete on 2-generation-old ebay server prices :P
<azonenberg>
the box was called GLaDOS, it had a phenom ii x4 940, 16GB of DDR2 which was a lot in those times
<azonenberg>
And four tesla c1060s
<azonenberg>
it had two ~1500W power supplies intended to be plugged into separate circuits
<azonenberg>
because it would blow a 15 amp breaker if you put them both on one
<azonenberg>
one ran the mobo and two GPUs, the other ran the other two GPUs
<d1b2>
<Darius> sounds like a bit more than 3kW then
<azonenberg>
i have no idea what it cost in power to run but it probably burned as much juice as my entire lab does lol
<d1b2>
<Darius> oh wait you are probably on 110VAC
<azonenberg>
yeah
<azonenberg>
Workstations typically do not have 240V plugs here as 240V receptacles are rare
<azonenberg>
they exist, since our 120V system is effectively two 180 degree offset 120V phases giving 240V between them
<d1b2>
<Darius> how quaint
<d1b2>
<Darius> ducks
<azonenberg>
And it's 3ph higher up the chain but most residential and smaller commercial buildings only see one phase
<azonenberg>
My UPS is 240V but it has a 240 -> 2x 120 transformer on the output and all of the downstream receptacles are 120V 20A
<azonenberg>
Right now I'm pulling 13.7A @ 239V from the output with 246V mains input
<azonenberg>
(the UPS is double conversion so it rectifies and inverts)
<lain>
man. the vulkan debug stuff is so useful
<azonenberg>
works better with dirty generator power and also helps ensure nice clean low-noise power for T&M gear
<azonenberg>
lain: yeah i have no idea how i got anything done in opengl/opencl without this
<azonenberg>
i'm never going back
<lain>
aye
<lain>
azonenberg: name suggestion for ngscopeclient: "scope-pal", goes with "scope hal"
<lain>
:3
<azonenberg>
lol
<azonenberg>
we'll throw it in the hat but it sounds too similar
<azonenberg>
enough that it would confuse people imo
bvernoux has joined #scopehal
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 264 seconds]
<d1b2>
<ehntoo> just read through scrollback, and I think I'm going to take a look at compile times. It seems like there's more than enough folks working on the project nowadays to make some time invested in reducing compile times worthwhile. A little preliminary profiling with clang's -ftime-trace, ninjatracing, and some hastily-assembled queries in the perfetto UI queries suggests that >~51% of total time for compiling a clean build of ngscopeclient on my
<d1b2>
mac is taken up by including scopehal.h. I'll do some refactoring experiments and report back.
<d1b2>
<j4cbo> yeah power in the US is weird
<d1b2>
<j4cbo> residences are generally 240 center-tapped, but large apartment and office buildings are often fully 3-phase 208Y/120
<d1b2>
<j4cbo> so an outlet for a stove, dryer, air conditioner, EV charger, etc could be either 208 or 240 depending on what kind of building it’s in
<d1b2>
<zyp> Norway is a bit weird too, while the rest of Europe mainly got 230V wye (i.e. 400V phase to phase), Norway got a ton of 230V delta
<d1b2>
<zyp> everything new is getting 400V, but most older areas got 230V
<d1b2>
<zyp> so I've got 400V at home, but 230V at the hobby workshop I'm renting with friends
<d1b2>
<zyp> doesn't matter for single phase loads since they're all 230V anyway, but it's a hassle for three phase loads
<jacekowski>
as long as you actually get 3 phases you can fix the voltage with a transformer
<d1b2>
<zyp> yeah, I'm on the lookout for a 15kVA or so transformer for the hobby workshop
<d1b2>
<zyp> I've got a nice 7.5kW air compressor at home that'd see way more use at the hobby workshop, but it's 400V and VFD based, so it's not just a matter of rewiring it to delta
<d1b2>
<xabean> so very far off topic, but the coolest part of three phase devices is: no ground/neutral line since it all cancels out.
<d1b2>
<xabean> or if you've got something very misbalanced it doesn't cancel out and ... not great :)
<d1b2>
<Mughees> @azonenberg I have done the summation algorithm. Now I am looking at the zero being outputted in the stats window. In the bool MaximumStatistic::Calculate(StreamDescriptor stream, double& value) function, m_pastMaximums[stream] = value; is populated with correct value (Value 0.0000003183088210789720) but stat window shows zero. I believe something is lost intranslation here from m_pastMaximums[stream] to GUI?
<d1b2>
<Mughees> Plus, shuould I go ahead and add a volt-sec unit OR you would want to add proper support for SI units?
<azonenberg>
ehntoo: we have an open ticket for optimizing #include's to not pull in more than needed
<azonenberg>
if you want to work on it, by all means
<azonenberg>
mughees: i'll look into the printing logic in a bit. i'll actually be adding stats support to ngscopeclient so i will be re-examining that
<azonenberg>
wrt volt-sec, go ahead and add one so you can get this filter upstreamed near term
<azonenberg>
but it is not a permanent solution
<azonenberg>
we do need to work on proper composable units in order to support e.g. integrating a curve with units of amps
<azonenberg>
or ohms
<azonenberg>
or anything else
<azonenberg>
ideally output unit for your integration filter would be the product of x and y units
<azonenberg>
whatever that is
<azonenberg>
and it would be algebraically computed for arbitrary waveform type
<azonenberg>
hard coding volt-sec as a special case will do for a starting point but is not the correct long term solution