Maybe instead you could do something in the middle -- add a precision field to glsl_type instead of adding to glsl_base_type. Then make different precision types compare equal in most places (since it is a hint to the compiler, rather than a full-fledged extra type) and have a pass that propagates mediump from variables to their uses/definitions in GLSL IR, so that non-NIR users also get the benefit. How does that sound?
On Sun, May 15, 2016 at 3:05 PM, Rob Clark <robdcl...@gmail.com> wrote: > 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 > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
