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

[Rob Herring]

On Wed, Mar 28, 2018 at 12:24 PM, Mark Janes <mark.a.janes at intel.com> wrote:
> Rob Herring <robh at kernel.org> writes:
>
>> 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.
>
> I was told that this mechanism was not useful because it builds with
> -Werror.  Is that still true?

No. I believe I disabled that in master because mesa certainly can't
build with -Werror.

> Clayton implemented a buildtest for android within the i965 CI, so
> anyone testing there will be notified when they break android.  We are
> waiting on some additional hardware before enabling it for developer
> branches.

I imagine you don't build all drivers or build for arm/arm64, so less
useful for others.

Rob