Fabian Giesen

It clearly didn’t come out of game dev. Many people doing high performance work on either embedded or “big silicon” (amd64) in that era were fully aware of the importance of locality, branch prediction, etc

But game dev, in particular Mike Acton, did an amazing job of making it more broadly known. His CppCon talk from 2014 [0] is IMO one of the most digestible ways to start thinking about performance in high throughput systems.

In terms of heroes, I’d place Mike Acton, Fabian Giesen [1], and Bruce Dawson [2] at the top of the list. All solid performance-oriented people who’ve taken real time to explain how they think and how you can think that way as well.

I miss being able to listen in on gamedev Twitter circa 2013 before all hell broke loose.

[0] https://youtu.be/rX0ItVEVjHc?si=v8QJfAl9dPjeL6BI

[1] https://fgiesen.wordpress.com/

[2] https://randomascii.wordpress.com/

So, you're saying they built a novel storage architecture that competed with state-of-the-art consumer hardware, at a lower price point. Five years later, laptops are just catching up, and that at the same price point, it's faster than what you'd expect from a PC.

The compression codec they licensed was built by some of the best programmers alive [0], and was later acquired by Epic [1]

I dunno how you put those together and come up with "isn't really fast" or "not particularly innovative".

Fast doesn't mean 'faster than anything else in existence'. Fast is relative to other existing solutions with similar resource constraints.

[0] https://fgiesen.wordpress.com/about/ [1] https://www.epicgames.com/site/en-US/news/epic-acquires-rad-game-tools

Of course there is comparison with LZ4: http://www.radgametools.com/oodlemermaidselkie.htm

LZ4HC is LZ4 compressed with the slow compressor to achieve better compression. It is decompressed using regular LZ4 decompressor.

They also compare with zstd and lzma, which are the open source competition.

I don't know what "specs" you think are missing. They do say which architectures are supported, what the memory use is, whether multi-threading is supported, etc.

No public price, true.

You can read the blogs of the people who work on this code to get a feel for the caliber:

https://cbloomrants.blogspot.com/

https://fgiesen.wordpress.com/

These are known people with known reputation. The product itself is well known in the industry.

You'd definitively be interested by the ryg[1] series on the graphic pipeline. It goes in details about how bits get to the GPU and how the GPU handle them. The author writes that using a 3D graphics API is a prerequisite. To the contrary, the series itself is great to get a grasp on things and not feel completely alienated by 3D graphics APIs if you ever decide to use one in the future. It's fairly old (2011) but I still see it recommended as a relevant resource today.

[1] https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/

The details are outdated now, I guess, but I don't know if there's any more inspiring reading for an aspiring graphics programmer than Fabian Giesen's "A trip through the graphics pipeline" https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/

As for a place to actually start, I think Computer Graphics From Scratch is a good place https://www.gabrielgambetta.com/computer-graphics-from-scratch/. A great thing about the book is it gives you many ideas for where to go next once you work your way through to the end.

Golomb-Rice with base M is prefix code optimal for approximately geometric probability distribution
Pr(x) ~ sqrt(2)^(-Mx).
Arithmetic coding or FSE/tANS would allow to use the actual probability distribution. The question is how large the gain could be - how far from Shannon is Golomb-Rice for this specific type of data?
If this probability distribution varies, maybe it's worth thinking about adaptive rANS, like in Oodle LZNA and BitKnit: https://fgiesen.wordpress.com/2015/12/21/rans-in-practice/
ps. Is M fixed or adapting?