Conversation

Notices

1. Embed this notice
   Robin Green (fatlimey@mastodon.gamedev.place)'s status on Tuesday, 08-Apr-2025 16:33:04 JST Robin Green

   Interesting talk on designing low-bit floating point number systems. Imagine you have 6-bits, using IEEE754 would you want to waste 6 of your codes for different NaNs? Do you really need two zeros? How about adding ±∞ or does saturating to ±FLT_MAX work for you use case? You can upconvert to Binary32 or Binary64 to do math operations, but which one gives you the better conversion when re-packing back down to 6-bits?

   IEEE working group P3109 has the goods.

   https://www.ac.uma.es/arith2024/slides/keynote1.pdf

   • Embed this notice
     Tom Forsyth (tomf@mastodon.gamedev.place)'s status on Tuesday, 08-Apr-2025 16:32:58 JST Tom Forsyth

     in reply to

     @fatlimey The paper then goes on to talk about different fp8 formats, but now we truly are just in LUT territory. Convert to the most appropriate fp16, then just look up whatever mapping you want. Whatever makes sense for your app.

   • Embed this notice
     Tom Forsyth (tomf@mastodon.gamedev.place)'s status on Tuesday, 08-Apr-2025 16:32:59 JST Tom Forsyth

     in reply to

     @fatlimey We already have two different float16 formats. Feels like you could add a whole bunch more pretty easily and fine-tune for your use cases. It's not quite per-app-specific compression (because you need a fast & cheap encode from f24ish to whatever 16 bit format you choose), but seems like hardware could easily support 8 different ones.

     Rich Felker repeated this.