Skip to contentSkip to conversation

RFC: Patch "Gallium VC4 driver depends on NEON"?

Buildroot Thomas Ruschival 2 participants 2 messages Mar 17, 2022

lore
Share & tools
lore
#0 lore raw

Hi Arnout,

the Patch "package/mesa3d: Gallium VC4 driver depends on NEON" commit a5cdb54ed78b136c83dd44aebfa27f715cda5ea3 prevents using VC4 and hence OpenGL on Raspberry Pi Zero.

From the referenced autobuild logs I gathered that the build that failed used the bootlin-armv5-uclibc toolchain.

Since I wanted to use OpenGL for Qt on a Raspberry Pi Zero I reverted the commit. The package compiled without errors and the system works as expected. Since my build is using a buildroot toolchain arm-buildroot-linux-gnueabihf (gcc 10, glibc) I guess the assembler errors are due to the toolchain.

I am not sure how to proceed in this case.

Should I investigate further on a more elaborate dependency logic to allow for usage of VC4 on Raspberry Pi Zero that doesn't break autobuild with bootlin-armv5-uclibc?

Best regards
Thomas
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

#1 lore raw
Quoted 15 lines · Thomas Ruschival

Hi Arnout,

the Patch "package/mesa3d: Gallium VC4 driver depends on NEON" commit a5cdb54ed78b136c83dd44aebfa27f715cda5ea3 prevents using VC4 and hence OpenGL on Raspberry Pi Zero.

From the referenced autobuild logs I gathered that the build that failed
used the bootlin-armv5-uclibc toolchain.

Since I wanted to use OpenGL for Qt on a Raspberry Pi Zero I reverted the commit. The package compiled without errors and the system works as expected. Since my build is using a buildroot toolchain arm-buildroot-linux-gnueabihf (gcc 10, glibc) I guess the assembler errors are due to the toolchain.

Quoted 5 lines

I am not sure how to proceed in this case.

Should I investigate further on a more elaborate dependency logic to allow for usage of VC4 on Raspberry Pi Zero that doesn't break autobuild with bootlin-armv5-uclibc?

The easiest is to test if it still fails with the bootlin toolchain (you can
select it from the external toolchains list). If it doesn't, then it's probably something that got fixed by a mesa3d bump. Ideally you should investigate what changed exactly to fix this - I had a quick look, nothing changed in the files using NEON instructions themselves, so it must be that the V3D_BUILD_NEON or PIPE_ARCH_ARM macros are defined differently (they determine whether or not the NEON instructions are used).

If it builds now for the bootlin toolchain, please send a revert patch with an
explanation why it works - ideally referring to the upstream commit that fixed it. And a reference to the version in which it was fixed, so we know if the revert can be backported to the stable branches.

If the build still fails with the bootlin toolchain, then yes ideally find out
why it behaves differently with the two toolchains. Again, the NEON instructions are still there in the code, so the difference must be with the V3D_BUILD_NEON or PIPE_ARCH_ARM macros.

The only other explanation (I can think of) is a difference in binutils, where
your binutils accepts the NEON instructions even on an architecture that doesn't support NEON. Seems pretty unlikely.

Regards,
Arnout
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot