On Sun, Jan 31, 2016 at 3:16 PM, Rob Clark <robdcl...@gmail.com> wrote: > + // XXX get from pipe_screen? Or just let pipe driver provide? > + nir_options.lower_fpow = true; > + nir_options.lower_fsat = true; > + nir_options.lower_scmp = true; > + nir_options.lower_flrp = true; > + nir_options.lower_ffract = true; > + nir_options.native_integers = true; > +
btw, one of the few remaining things to tackle is how to handle nir_shader_compiler_options struct. To follow the existing approach of shader caps, I'd have to add a big pile of caps now, and then keep adding them as nir_shader_compiler_options struct grows. Which seems sub-optimal. How do people feel about adding a screen->get_shader_paramp() which, along the lines of get_paramf, returns a 'const void *'? Then we could add a single cap to return the whole compiler-options struct. (And maybe if at some point there was direct support for LLVM as an IR, it might need something similar??) Other possibility is just a pipe->get_nir_compiler_options() type hook. A bit more of a point solution, but might make sense if we can't think of any other plausible uses for ->get_shader_paramp().. and less churn since it would only need to be implemented by drivers consuming NIR.. Thoughts/opinions? BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
