All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Seiderer <ps.report@gmx.net>
To: buildroot@busybox.net
Subject: [Buildroot] Analysis of build results
Date: Sun, 1 Mar 2020 00:17:04 +0100	[thread overview]
Message-ID: <20200301001704.68d47833@gmx.net> (raw)
In-Reply-To: <25eb9f2e-26f8-98f4-68ce-8268b0c3ea7b@gmail.com>

Hello Romain,

On Sat, 29 Feb 2020 22:15:10 +0100, Romain Naour <romain.naour@gmail.com> wrote:

> Hi Peter,
> 
> Le 28/02/2020 ? 16:02, Peter Seiderer a ?crit?:
> > Hello Romain,
> > 
> > On Fri, 28 Feb 2020 08:32:18 +0100, Romain Naour <romain.naour@gmail.com> wrote:
> >   
> >>>  
> >>>>     arm      |         mesa3d-19.3.4          | NOK |  
> >>> http://autobuild.buildroot.net/results/6387b0a99e1a0922811919623d9a10b0943988df
> >>> |
> >>>
> >>> {standard input}: Assembler messages:
> >>> {standard input}:334: Error: selected processor does not support `vldm
> >>> r4,{q0,q1,q2,q3}' in ARM mode
> >>> {standard input}:335: Error: selected processor does not support `vst1.8
> >>> d0,[r3],r2' in ARM mode
> >>> {standard input}:336: Error: selected processor does not support `vst1.8
> >>> d1,[r3],r2' in ARM mode
> >>> {standard input}:337: Error: selected processor does not support `vst1.8
> >>> d2,[r3],r2' in ARM mode
> >>>
> >>> Bad stuff happens when building the vc4 driver. It probably needs some
> >>> minimal ARM architecture variant.
> >>>  
> >>
> >> I believe we should re-add the dependency on neon for vc4 driver. There is
> >> -mfpu=neon added by the build system.  
> > 
> > The BR2_ARM_CPU_HAS_NEON dependency was dropped with commit [1] because mesa3d
> > commit [2] added a compile time detected neon support, in the meantime this
> > was changed to a runtime detection [3] and finally enabled for the meson
> > cross compile build with commit [4] (assuming toolchain support for the
> > neon assembler instructions)...  
> 
> Thank you for the detailed explanation.
> 
> I saw the commit [4] and conclude that upstream mesa3d now require neon support
> when vc4 driver is enabled.
> 
> > 
> > Maybe the compile error could be fixed by re-adding partly the compile time
> > check for the neon support (tested):
> > 
> > --- mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h_orig	2020-02-28 14:47:44.232634657 +0100
> > +++ mesa3d-19.3.4/src/broadcom/common/v3d_cpu_tiling.h	2020-02-28 14:49:21.518425222 +0100
> > @@ -31,7 +31,7 @@
> >  v3d_load_utile(void *cpu, uint32_t cpu_stride,
> >                 void *gpu, uint32_t gpu_stride)
> >  {
> > -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM)
> > +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7
> >          if (gpu_stride == 8) {
> >                  __asm__ volatile (
> >                          /* Load from the GPU in one shot, no interleave, to
> > @@ -141,7 +141,7 @@
> >  v3d_store_utile(void *gpu, uint32_t gpu_stride,
> >                  void *cpu, uint32_t cpu_stride)
> >  {
> > -#if defined(V3D_BUILD_NEON) && defined(PIPE_ARCH_ARM)
> > +#if defined(V3D_BUILD_NEON) && defined(__ARM_ARCH) && __ARM_ARCH >= 7
> >          if (gpu_stride == 8) {
> >                  __asm__ volatile (
> >                          /* Load each 8-byte line from cpu-side source,
> >   
> 
> But -mfpu=neon is still present on the command line.

But without problems, as all the neon stuff in handcrafted via
inline assambler ;-)

> 
> Do you think if the neon support can be handled/forced by a new meson option?

The following patch fixes the problem for the vc4 driver (but not for the
v3d one which needs neon unconditionally - or fixed by the previous patch):

diff --git a/meson.build b/meson.build
index 7e2295b..a3134b1 100644
--- a/meson.build
+++ b/meson.build
@@ -1112,8 +1112,10 @@ elif host_machine.cpu_family() == 'x86_64'
   endif
 elif host_machine.cpu_family() == 'arm'
   if system_has_kms_drm
-    with_asm_arch = 'arm'
-    pre_args += ['-DUSE_ARM_ASM']
+    if not (host_machine.cpu().contains('4') or host_machine.cpu().contains('5') or host_machine.cpu().contains('6'))
+      with_asm_arch = 'arm'
+      pre_args += ['-DUSE_ARM_ASM']
+    endif
   endif
 elif host_machine.cpu_family() == 'aarch64'
   if system_has_kms_drm
diff --git a/src/gallium/drivers/vc4/meson.build b/src/gallium/drivers/vc4/meson.build
index 5ce5af5..2bb5d06 100644
--- a/src/gallium/drivers/vc4/meson.build
+++ b/src/gallium/drivers/vc4/meson.build
@@ -84,7 +84,7 @@ files_libvc4 = files(
 vc4_c_args = []
 
 libvc4_neon = []
-if host_machine.cpu_family() == 'arm'
+if host_machine.cpu_family() == 'arm' and not (host_machine.cpu().contains('4') or host_machine.cpu().contains('5') or host_machine.cpu().contains('6'))
   libvc4_neon = static_library(
     'vc4_neon',
     'vc4_tiling_lt_neon.c',

An alternative to the check on ARMvX >=7 a new meson option should be possible...

Regards,
Peter

> 
> Best regards,
> Romain
> 
> > Regards,
> > Peter
> > 
> > [1] https://git.buildroot.net/buildroot/commit/package/mesa3d?id=350cb0d32ece533b9723a5f3ca6fbf7e6f071c90
> > [2] https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1&id=4d30024238efa829cabc72c1601beeee18c3dbf2
> > [3] https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/19.3&id=ece06defe77a77d2db40abeddee5a2e0e45654ce
> > [4] https://cgit.freedesktop.org/mesa/mesa/commit/?id=932ed9c00b99e6ec92146ec9e820f546cf3e6551
> >   
> >>
> >> Romain  
> >   
> 

  reply	other threads:[~2020-02-29 23:17 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27  9:31 [Buildroot] [autobuild.buildroot.net] Daily results for 2020-02-26 Thomas Petazzoni
2020-02-27 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
2020-02-27 23:06   ` Max Filippov
2020-02-27 23:18   ` Giulio Benetti
2020-02-28  8:03     ` Thomas Petazzoni
2020-02-28 18:06     ` Giulio Benetti
2020-02-28  6:21   ` Heiko Thiery
2020-02-28  7:56     ` Sergio Prado
2020-02-28  8:01     ` Thomas Petazzoni
2020-02-28  7:32   ` Romain Naour
2020-02-28 15:02     ` Peter Seiderer
2020-02-29 21:15       ` Romain Naour
2020-02-29 23:17         ` Peter Seiderer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-02-19  7:48 [Buildroot] [autobuild.buildroot.net] Daily results for 2020-02-18 Thomas Petazzoni
     [not found] ` <20200220034343.2370e4e4@windsurf>
2020-02-20 13:36   ` [Buildroot] Analysis of build results Giulio Benetti
2020-02-21  8:23   ` Romain Naour
     [not found]   ` <94c8edad-773d-2b36-5daf-b6ee60dd747f@micronovasrl.com>
     [not found]     ` <3e7b016b-eca6-b768-3fca-8fd7e44d0299@micronovasrl.com>
     [not found]       ` <20200220190807.505b4fb2@windsurf>
     [not found]         ` <00751b5d-ca05-fe42-0e9b-6a1005a09e6d@micronovasrl.com>
     [not found]           ` <20200220192344.03785f04@windsurf>
     [not found]             ` <bcc10a0e-c54e-5b75-9b77-8922b85a925a@micronovasrl.com>
     [not found]               ` <fe7d07df-71a0-e317-6b91-ade479545ec4@smile.fr>
     [not found]                 ` <28258465-4f79-3f47-189d-bb066b0aa9f7@micronovasrl.com>
2020-02-22 19:10                   ` Romain Naour
2020-02-22 19:44                     ` Giulio Benetti
2020-02-22 21:11                       ` Fabrice Fontaine
2020-02-22 21:48                         ` Giulio Benetti
2020-02-22 22:00                           ` Fabrice Fontaine
2020-02-22 23:48   ` Romain Naour
2014-11-11  7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-11-10 Thomas Petazzoni
2014-11-11 22:49 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-11-11 23:41   ` Gustavo Zacarias
2014-11-12  2:30   ` Nathaniel Roach
2014-11-12 14:09   ` Jörg Krause
2014-11-16 10:07   ` Yann E. MORIN
2014-11-22 11:10   ` Bernd Kuhls
2014-08-30  6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-29 Thomas Petazzoni
2014-08-30  9:07 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-08-25  6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-08-24 Thomas Petazzoni
2014-08-25 16:16 ` [Buildroot] Analysis of build results Thomas Petazzoni
2014-08-25 16:26   ` Phil Eichinger
2014-08-25 17:47     ` Thomas Petazzoni
2014-08-25 21:07   ` Peter Korsgaard
2014-08-25 21:13   ` Jörg Krause
2014-08-26  6:17   ` Alexander Lukichev
2014-08-28 12:52   ` Ezequiel Garcia
2014-08-31 16:58     ` Frank Bergmann
2014-08-31 21:13       ` Ezequiel Garcia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200301001704.68d47833@gmx.net \
    --to=ps.report@gmx.net \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.