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

Roland Scheidegger sroland at vmware.com
Mon Feb 8 11:58:38 UTC 2016


Am 06.02.2016 um 22:30 schrieb 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.

Looks usable to me, albeit I'm not sure you really need NIR-specific
options as such? That is those options above don't really look nir
specific - maybe they aren't used with just glsl->tgsi, but it looks to
me like they would in theory be applicable to other IR as well. Though I
suppose if you just had compiler_otions it would be a bit confusing if
you had entries which then may not be used...

Roland




More information about the mesa-dev mailing list