hmm, that is still a lot of sites of type comparison to fixup, unless maybe some operator overloading hackery.. but that sounds ugly.. I guess the pass to propagate precision works out equivalently, as far as applying precision propagation, to my precision_visitor. Not *really* sure that makes it any easier to use for st_glsl_to_tgsi, and still has all the same issues as my 2nd approach with having to fixup intermediate var's that get created..
BR, -R On Sun, May 15, 2016 at 3:47 PM, Connor Abbott <cwabbo...@gmail.com> wrote: > 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
