[Mesa-dev] [PATCH 2/2 v2] nir: mako all the intrinsics

[Rob Herring]

On Wed, Mar 28, 2018 at 10:18 AM, Rob Clark <robdclark at gmail.com> wrote:
> On Wed, Mar 28, 2018 at 10:43 AM, Rob Herring <robh at kernel.org> wrote:
>> On Sun, Mar 25, 2018 at 1:10 PM, Rob Clark <robdclark at gmail.com> wrote:
>>> I threatened to do this a long time ago.. I probably *should* have done
>>> it a long time ago when there where many fewer intrinsics.  But the
>>> system of macro/#include magic for dealing with intrinsics is a bit
>>> annoying, and python has the nice property of optional fxn params,
>>> making it possible to define new intrinsics while ignoring parameters
>>> that are not applicable (and naming optional params).  And not having to
>>> specify various array lengths explicitly is nice too.
>>>
>>> I think the end result makes it easier to add new intrinsics.
>>>
>>> v2: couple small fixes found with a test program to compare the old and
>>>     new tables
>>> v3: misc comments, don't rely on capture=true for meson.build, get rid
>>>     of system_values table to avoid return value of intrinsic() and
>>>     *mostly* remove side-effects, add autotools build support
>>>
>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>>> ---
>>> So, new scheme is, I think, a reasonable compromise between keeping the
>>> python "clean" and keeping the intrinsic declarations easy to follow.
>>> It still has the side-effect that intrinsic() adds to the table, but
>>> drops the separate system_values table so that intrinsic() doesn't
>>> return a value.  The alternative would require the helper for various
>>> specialized intrinsic categories to be declared far from where they are
>>> used, which is, I think, suboptimal.  And it keeps intrinsic() and
>>> various wrappers pretty straightforward, so I don't think this should
>>> ever pose a problem for refactoring (and certainly less of a problem
>>> than the previous solution using cpp macros, so regardless of what your
>>> opinion about the py code, I guess anyone could agree that this is an
>>> improvement over the current state ;-))
>>>
>>> Also added autotools build support.  Sorry scons and android.  (Are we
>>> ready to drop either of these in favor of nir?)
>>
>> You mean meson? For Android, no. I don't see that happening anytime
>> soon. I looked into it some by having a prebuilt target in Android.mk
>> that calls meson. The problem is getting all the Android build
>> environment such as include paths out of Android build system and
>> passed into meson. I don't know how to do that in a way that is not
>> manual and fragile.
>>
>> It looks like you'd just need to do some copy-n-paste of rules for
>> Android. And you know you can push an 'android/*' branch to trigger an
>> Android build of mesa?
>>
>
> no, I didn't realize that.. on the main git tree?

Yep. No one uses it AFAICT.

Rob