[Mesa-dev] [RFCv3 11/11] mesa/st: add support for NIR as possible driver IR

[Rob Clark]

On Sun, Jan 31, 2016 at 3:16 PM, Rob Clark <robdclark at 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