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

[Marek Olšák]

On Sat, Feb 6, 2016 at 10:30 PM, Marek Olšák <maraeo at gmail.com> wrote:
> 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.

Well, it should be screen->...

Marek