sketch Half in skvm
Key design points...
A) Take care to not commit too much to Half's range or precision.
In particular, don't offer operations whose result might not
be representable in Half. E.g., shy away from Half divide,
not just because we might not be able to do a native divide,
but even more so because division produces results that might
not fit in Half, ±inf or NaN.
B) No native Half loads, stores, uniforms or splats,
instead converting from I32 or F32. This keeps the entire
front-end (user code, Builder, etc.) specified in terms of precise
format and oblivious to the various backends' representations of
Half. Native Half splats would be less trouble than uniforms I
think, and uniforms less trouble than loads and stores, but still
enough a pain that we're better of deferring any of that for now.
(Explicit fp16 uniforms do make sense to me though.)
C) Keep the current F32-based Color and all the effect virtuals
that use it around, introducing parallel Half-based HalfColors
and entry points for those. The key cool idea here is to have
the default entry points for F32/Color and Half/HalfColor call
each other, so that any given effect can implement one, the other,
or both and always be compatble with however it's called.
This is mostly about incremental rollout, but I suspect we'll
have areas that stick to F32 forever. (Think the IEEE 754 32-bit
float specific bit hacks we used for approx_log/approx_exp.)
D) (not done yet) allow implicit Half->F32 conversion, but not
the other way around of course. This makes it easier to lean
on the body of F32 routines we already have, and again mostly
helps enable incremental rollout.
Change-Id: I8bb38efbe476ff89dd2591411e115c2ab3757854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/341800
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
5 files changed