On Sat, Feb 6, 2016 at 2:45 PM, Rob Clark <robdcl...@gmail.com> wrote: > 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?
pipe->get_nir_compiler_options() sounds good. Maybe wait for VMWare guys' opinion as well. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
