[Mesa-dev] mediump / half-precision support

Rob Clark robdclark at gmail.com
Sun May 15 19:05:16 UTC 2016


So I've been hacking around on a couple approaches to getting
half-precision support going for gles (and btw, someday it might be
interesting to have an extension to respect precision qualifiers in gl
too)

I initially started by propagating ir_variable_data::precision to
nir_variable_data and fixing up glsl_get_bit_size() to take a
precision argument.  Ilia recommended to extend glsl_types to have
half-precision types instead.. so I gave that a try.  IMHO it turns
out to be a lot of churn (type explosion, with ripple-on effects to
builtin-functions, new glsl ir opcodes, etc).  What I have can at
least compile correctly *some* gles shaders.  And still having some
problems with things getting promoted to full precision when they
should not (or missing implicit conversion on function return types,
etc).  And builtin-functions is still missing a handling for a lot of
the various permutations of full and half-precision types, probably
falls over harder when there are samplers in the mix, etc... so still
lots of typing to do..  But here is what I've go:

https://github.com/freedreno/mesa/commits/wip-mediump

I may resurrect the other branch and see how far I get with that,
since I didn't get as far as to be able to compile a shader before I
switched. I did introduce a hierarchical-visitor to derive precision
from an ir_rvalue (which I think might be a more sane way to implement
the rules about precision promotion).  After that I think the main
thing was to fixup precision on generated intermediate variables (such
as for handling inlining of fxns, etc), but I think a lot of that
could just use the precision_visitor to figure out what to do.  For
most part, in nir the bitsize comes from the originating ir_variable
or glsl_struct_field for struct deref's..).  We'd have to somehow make
glsl_to_nir clever enough to insert f2h/h2f/u2h/.. conversion
instructions, since at the glsl ir level precision is separate from
type.  But I kinda think this might be the easier approach.

Thoughts?

BR,
-R


More information about the mesa-dev mailing list