Consolidated the test cases necessary to build a regression test suite for Blender’s XR API. Figured out how to implement almost every test case. Built a test harness to use with Blender and ox, so that it’s ergonomic and easy to write test cases that span across multiple frames.
Upgraded stable-diffusion.cpp in Easy Diffusion (and sdkit) to the latest version. This adds support for two new models: Lens and PiD, along with a bunch of bug fixes (for e.g. Chroma rendering has been fixed). It also brings back --diffusion-fa by default, which speeds up rendering. And Chroma seems to be rendering faster than before.
Just completed another round of fixing support issues in Easy Diffusion. Today’s evidence continues to convince me to move Easy Diffusion away from the Python ecosystem for AI inference on end-user PCs. And definitely to stay away from conda, it’s so leaky. Both are excellent in their own right (especially for training and research), but I don’t think they make sense for end-user inference. Easy Diffusion’s v4 full rollout (which drops Python, torch and conda) can’t come soon enough.
Got Freebird working on a Mac (with Blender 5.2 alpha). Used the new ox runtime (v0.6 pre-release) to simulate OpenXR on a Mac, and worked through the bugs to get Freebird running. So if someone ever creates an OpenXR-compatible headset for the Mac, Freebird will run on it!
Got Easy Diffusion v4 working on Apple and Intel Macs. The performance difference ratio (vs ED v3) is similar to the ratio on Windows (with CUDA) and other deployment targets. So that indicates optimization opportunities in sd.cpp. It’s currently about 1.5x slower than diffusers-based Stable Diffusion. In other news, easyinstaller is also out with its first release, which means that Easy Diffusion can now start shipping AppImage, Flatpak, rpm, deb, pkg, dmg etc for the different platforms. Instead of requiring Linux and Mac users to use the terminal to install and start Easy Diffusion. Will work on this soon.
Wrote a little program for myself called “the accountant”, which produces financial reports for my projects. It’s purely for myself, and has the personality of a middle-aged Polish accountant (inspired by Woz’s dial-a-joke service). It’s whimsical, and the humor helps me keep up the habit for I don’t particularly enjoy doing. The jokes were written by Claude, and are surprisingly funny in an understated manner. No, the program is not an LLM agent. It is old-fashioned code that loops through spreadsheet rows and tallies things up. The jokes are just fixed strings, but they seem to have good repeat value. It’s a wizard-style program, since I need to perform some steps manually in between.
Started the long-pending rewrite of Easy Diffusion’s server code. v4 intends to replace the Python (and PyTorch) based server with a simple C++ version. The reason for rewriting the server in C++ is to achieve sub-second startup time for the UI, and to reduce the download size (won’t need to distribute Python along with Easy Diffusion) or mess with conda/venv etc. And it’s also something that I want to do for personal taste, i.e. de-bloating what doesn’t need to be bloated.
Submitted a code fix in Blender to fix the order of calling modal operators for XR Actions - https://projects.blender.org/blender/blender/pulls/152575
For Z-Image, the performance of the stock version of chromaForge is poorer than sd.cpp’s. Mainly because chromaForge isn’t able to run the smaller gguf quantized models that sd.cpp is able to run (chromaForge fails with the errors that I was fixing yesterday). If I really want to push through with this, it would be good to fix the remaining issues with gguf models in chromaForge. Only then can the performance be truly compared (in order to decide whether to release this into ED 3.5). I want to compare the performance of the smaller gguf models, because that’s what ED’s users will run typically.
Worked on fixing Z-Image support in ED’s fork of chromaForge (a fork of Forge WebUI). Fixed a number of integration issues. It’s now crashing on a matrix multiplication error, which looks like an incorrectly transposed matrix (mostly due to reading the weights in the wrong order). I’ll try to install a stock version of chromaForge to see its raw performance with Z-Image (and whether it’s worth pursuing the integration), and also use it to help investigate the matrix multiplication error (and any future errors).