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

[Marek Olšák]

On Sat, Feb 6, 2016 at 2:45 PM, Rob Clark <robdclark at gmail.com> wrote:
> 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?

pipe->get_nir_compiler_options() sounds good.

Maybe wait for VMWare guys' opinion as well.

Marek