Bloom, On Time

Bloom is the glow around the bright things, the soft halo that says a light is genuinely hot rather than merely light gray. You point it at a scene, it blooms, everyone is happy. Except on real graphics cards it was showing up a frame behind, and on the standalone texture.Bloom node it was not showing up at all.

The two panels below are the same bright scene on its very first frame. Left is what you got before, crisp boxes and no glow. Right is what you get now.

The cause lives one level below anything an artist should ever have to think about. To go fast, the renderer can hand some work to the graphics card’s compute lane and the rest to its graphics lane, and let the driver run them together. Bloom is a two-step recipe: a “promote” step preps the image, then the glow chain reads that prepped image and spreads the light. The prep was running in the graphics lane, the glow chain in the compute lane, and the way the two lanes get handed to the card, the compute lane goes first. So the glow chain read the image before the prep had written it. On a still scene the standalone node read an empty frame every single time and never bloomed; the scene’s own bloom read yesterday’s frame, so it trailed one step behind on anything that moved.

The fix is almost anticlimactic: run bloom’s glow chain in the same lane as its prep, so prep finishes before glow starts. The honest question is whether that costs speed, and the answer is no. The parallel lane only wins when there is other work to run beside it, and bloom is a strict assembly line, prep then glow then grade, each step waiting on the one before. There was never anything to run alongside it. The fast lane was buying nothing here and quietly breaking the picture. Every part of the renderer that genuinely profits from that lane, the shadows and culling and lighting, keeps it untouched.

A tripwire, so it stays fixed

The interesting failures are the ones that pass every test while staying broken, and this was one of them. On the software renderer our test suite runs on, the two lanes collapse into one and the bug politely disappears, so a plain before-and-after screenshot looked fine and told you nothing. The regression test had to be built to reproduce the real hardware’s ordering, which it now does: it renders the first frame and demands the glow already be there, anchored not to a saved image of our own output but to the same scene with bloom deliberately switched off. A blank first frame cannot outshine a scene with the lights off, so the test cannot be quietly satisfied by the bug creeping back.

There is also a structural guard now, one step lower. Any future effect that tries to read across the two lanes in the wrong order trips a loud failure the moment it is wired up, rather than shipping a glow that is a frame behind and waiting for someone to notice. The whole general machinery for making the lanes wait on each other properly is a real piece of work, and it has a home on the roadmap for the day a workload actually needs it. Bloom did not, so bloom did not wait for it.