Andrew Zonenberg

3.3K Followers
473 Following
28K Posts

Security and open source at the hardware/software interface. Embedded sec @ IOActive. Lead dev of ngscopeclient/libscopehal. GHz probe designer. Open source networking hardware. "So others may live"

Toots searchable on tootfinder.

ngscopeclienthttps://www.ngscopeclient.org/
Bloghttps://serd.es
LocationSeattle area
GitHubhttps://github.com/azonenberg

One of these if anyone is curious, the 20mm scale with UKAS traceable certificate

https://www.tedpella.com/histo_html/Pro-Stage-Micrometers.aspx

Pro Series Stage Micrometers for Light Microscopy

stage micrometers for transmitted and reflected light, calibration certificates available

(i asked our lab tech how big a feature was in a microscope photo he sent me and apparently nobody had ever done a pixel size cal on that scope... We have a cheap amscope cal slide of questionable accuracy floating around somewhere but I have a proper traceable reference for my own lab so I told him I'd bring it in next time I was in the city and we'd take care of things)
Chat is it normal to bring traceable personal standards into work to calibrate their equipment against?

Had some stuff to do in the city and am on a semi nocturnal sleep schedule this week so I decided to go to work stupidly early (leaving home at 4:30 in the morning to catch the first bus of the day) so I could get home before bedtime (i.e. lunchtime for most people in the local time zone).

Biking to the bus stop hours before sunrise is reminding me of how much I miss night rides. Quiet, peaceful, empty roads with almost no vehicle traffic unless you're on a major highway. I didn't see a single car until after I had got to the bus stop.

Now that the monsoon season is mostly over and the weather isn't freezing cold as much, I should go for more night rides. I don't mean just after sunset, I mean like 2AM.

Note that we've had apple silicon *builds* running via GitHub actions for a while but since azure did not provide Metal in the runner VM, we did not run *tests* in the CI.

Which is how it went unnoticed this long

This issue proves the value of what I'm doing, though: testing on llvmpipe and nvidia platforms only would not catch this issue. The only way to find it is to a) have tests for as many filters as possible and b) run the tests on as diverse a range of GPUs as possible.

Writing more tests is a whole other can of worms... but literally the first time I ran the existing test suite on apple silicon for the first time, I caught a bug.

The frequency measurement filter has a non-GPU fallback implementation since it also depends on int64 support, so it was trivial to condition for int64 and float64 instead.

But the other two do not have fallback implementations (I probably have non-GPU versions in git history from before they were accelerated, just need to dredge those out)

Well, that was a fun problem.

Turns out we have three shaders that use float64 temporaries, but did not actually check if your GPU *had* float64 support before trying to use them.

And Apple's M4 GPU does not have float64 support whatsoever, at least under MoltenVK (unsure if it's there under Metal).

One of the three (frequency measurement) was in a unit test. But the nature of the failure is such that by the time the failure took place I had already created a pipeline cache object, which was saved to disk, but failed to load the next time libscopehal initialized.

This means that once the test failed, ngscopeclient and all other unit tests wouuld fail to start until you cleared your cache directory.

Progress! Sorted out a bunch of permissions issues and I'm now able to (over SSH) clone a template VM on the mac mini and launch it.

Now to set up a script to actually run the test suite.

I've written more bash than any other language the last week or so and I don't like it lol. But it had to be done...

Anybody familiar enough with Supermicro main board architecture to know what they're using the little Lattice CPLD for? Just IO expansion for the BMC or what?