~ / cmdr2

projects: freebird, easy diffusion

hacks: carbon editor, torchruntime, findstarlink

  # filter by: [ posts | worklogs ]
  • #findstarlink

Migrated findstarlink.com (and its mobile apps) from the TLE to OMM data format for satellite tracking. TLEs use a 5 digit identifier for satellites, and we’ve basically run out of them. This was a very intrusive change in what’s effectively a legacy codebase for me (most of the code has been untouched for 6 years). Celestrak (the source of satellite info) has long-recommended moving to the OMM format, which supports a larger number of satellites. They stopped publishing new TLE data for satellites last week (i.e. early May, 2026), because we’ve run out of possible TLE identifiers.

  • #finance

Ported a financial market analysis tool (that I wrote for myself many years ago, and ran locally) to Cloudflare Workers and R2. I used a custom data storage format for the time-series data with sharding, to work well as static files on R2 (object store). A relational database wasn’t necessary (and wouldn’t fit in the free tier anyway). A GitHub Actions workflow runs every weekday, and fetches the latest market data and updates the static data on R2. The webpage hosted on Cloudflare Workers works with this data via a worker.

  • #ai
  • #agents

The models powering coding agents currently feel more like fuzzy function calls, or Q&A bots. For more complex tasks, it would be better if they (ironically) behave more like chat, where they refine their understanding (and mine too) with follow-up questions and discussion, rather than being biased towards “answering”/“solving” in the very next reply. For e.g. when talking to a freelancer, we’d expect them to ask follow-up questions and clarify the requirements until we’re both sure that we’ve really understood the task. Or maybe even clarify stuff while implementing. “Plan mode” is an okay approximation (especially if you explicitly ask it to list questions for me). But that’s a workaround - the model is not explicitly post-trained/architected for dialogue. And doesn’t come into play during implementation.

  • #sdkit
  • #easydiffusion

Released Easy Diffusion v4.3 (which updates to sdkit v3.2). This adds support for Ernie Image (and Ernie Turbo), as well as improved support for Anima models. It also includes a bunch of bug fixes in the rendering engine (i.e. stable-diffusion.cpp), and a few community-contributed bug fixes to the UI.

  • #easydiffusion

Development update for Easy Diffusion: the beta branch has been merged into main, so this releases v3.5 (webui) and v4 to everyone. This shouldn’t affect existing users who’re on the main branch, i.e. people using the v3 engine will continue doing so. The two engines (v3.5 and v4) are marked as optional, so new users will continue to get and use v3 by default. The main purpose of this update is to merge the two forked codebases that we’ve had for over 1.5 years. Now the main and beta branches are back in sync. This brings back the streamlined release process that we had previously, where new changes would first land in beta, and then get merged into main after testing.

  • #freebird

Freebird v2.6.0 released. Changes since the last blog post (v2.2.2): Adds the ability to add and edit Text while inside VR. This is useful for labeling and making notes inside VR, without having to sketch notes by hand. Adds support for Vulkan and Blender 5. Shows the scene scale in the controller’s panel (below the main menu). This will let you know the zoom level of the scene, for e.g. 1:1 or 1:10 or 15:1, so that you can plan accordingly when working with real-world units.

  • #sdkit
  • #easydiffusion

The new engine that’ll power Easy Diffusion’s upcoming v4 release (i.e. sdkit3) has now been integrated into Easy Diffusion. It’s available to test by selecting v4 engine in the Settings tab (after enabling Beta). Please press Save and restart Easy Diffusion after selecting this. It uses stable-diffusion.cpp and ggml under-the-hood, and produces optimized, lightweight builds for the target hardware. The main benefits of Easy Diffusion’s new engine are:

  • #sdkit
  • #v3

Managed to get stable-diffusion.cpp integrated into sdkit v3 and Easy Diffusion. sdkit v3 wraps stable-diffusion.cpp with an API server. For now, the API server exposes an API compatible with Forge WebUI. This saves me time, and allows Easy Diffusion to work out-of-the-box with the new C++ based sdkit. It compiles and runs quite well. Ran it with Easy Diffusion’s UI. Tested with Vulkan and CUDA, on Windows.

  • #sdkit
  • #ggml
  • #compiler

Following up to the previous post on sdkit v3’s design: The initial experiments with generating ggml from onnx models were promising, and it looks like a fairly solid path forward. It produces numerically-identical results, and there’s a clear path to reach performance-parity with stable-diffusion.cpp with a few basic optimizations (since both will eventually generate the same underlying ggml graph). But I think it’s better to use the simpler option first, i.e. use stable-diffusion.cpp directly. It mostly meets the design goals for sdkit v3 (after a bit of performance tuning). Everything else is premature optimization and scope bloat.

  • #ml
  • #compiler
  • #sdkit
  • #onnx
  • #ggml

Successfully compiled the VAE of Stable Diffusion 1.5 using graph-compiler. The compiled model is terribly slow because I haven’t written any performance optimizations, and it (conservatively) converts a lot of intermediate tensors to contiguous copies. But we don’t need any clever optimizations to get to decent performance, just basic ones. It’s pretty exciting because I was able to bypass the need to port the model to C++ manually. Instead, I was able to just compile the exported ONNX model and get the same output values as the original PyTorch implementation (given the same input and weights). I could compile to any platform supported by ggml by just changing one flag (e.g. CPU, CUDA, ROCm, Vulkan, Metal etc).