Compute vs. Hardware

38 points by craigjb 4 years ago | 3 comments

Floating point rasterization brings me back to 1993 style rasterizers (when I was 5…) and all of the problems they entail. Dropouts, double renders, endless edge problems, seams… rasterization is a lot of fun. It’s one of the only areas I can think of where fixed point isn’t merely a feature, it’s a necessity.

Not that rasterization was the point. :)

Ironically, I searched for a reference explaining all of these problems, and wound up finding my own HN comment. https://news.ycombinator.com/item?id=21736821 (Who said HN results rarely show up on Google?)

That five part Chris Hecker rasterization series really is the jams though. It covers so much ground, and it even has code that can (with effort) still run. I’ve wanted to reimplement it in JS and make a web version.

boulos 4 years ago | |

Getting edge equations done right / consistently is certainly important. That's not actually a floating point vs fixed point argument though.

There's always going to be rounding and clamping. With fixed point code or fixed-function hardware it's obvious and explicit. You can do all the same range reduction work in fp32.

Modern rasterizers have been outputting "24-bit Z" aka the equivalent of [-0.5, 0.5] in fp32 forever. Said another way: fp32 hardware perfectly implements a signed 23-bit fixed point :).

stemc43 4 years ago | |

>Floating point rasterization brings me back to 1993 style rasterizers (when I was 5…)

something something "I was spitting out formulas while you were still spitting up formula." https://www.youtube.com/watch?v=TtmFQ194Ze4