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

[Mark Janes]

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?

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.

> Rob
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev