[Buildroot] How to force mesa3d to use llvmpipe?

[Buildroot] How to force mesa3d to use llvmpipe?

[nimaim]

Using Buildroot 2017.11 and following defconfig:

BR2_x86_i686=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://toolchains.free-electrons.com/downloads/releases/toolchains/x86-i686/tarballs/x86-i686--glibc--bleeding-edge-2017.05-toolchains-1-2.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="i686-buildroot-linux-gnu"
BR2_TOOLCHAIN_EXTERNAL_GCC_6=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_9=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_SYSTEM_BIN_SH_BASH=y
BR2_ROOTFS_OVERLAY="fs-overlay"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.9.71"
BR2_LINUX_KERNEL_DEFCONFIG="i386"
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
BR2_PACKAGE_MESA3D_DEMOS=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y
BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
BR2_PACKAGE_MESA3D_OPENGL_TEXTURE_FLOAT=y
BR2_PACKAGE_QT5=y
BR2_PACKAGE_QT5BASE_EXAMPLES=y
BR2_PACKAGE_QT5BASE_WIDGETS=y
BR2_PACKAGE_QT5BASE_OPENGL_ES2=y
BR2_PACKAGE_QT5BASE_XCB=y
BR2_PACKAGE_QT5BASE_DEFAULT_QPA="xcb"
BR2_PACKAGE_QT5BASE_FONTCONFIG=y
BR2_PACKAGE_QT5QUICKCONTROLS2=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XSERVER_XORG_SERVER=y
BR2_PACKAGE_XAPP_XINIT=y
BR2_PACKAGE_XAPP_XINPUT=y
BR2_PACKAGE_XAPP_XINPUT_CALIBRATOR=y
BR2_PACKAGE_XDRIVER_XF86_INPUT_EVDEV=y
BR2_PACKAGE_XDRIVER_XF86_INPUT_TSLIB=y
BR2_PACKAGE_XDRIVER_XF86_VIDEO_FBDEV=y
BR2_PACKAGE_XDRIVER_XF86_VIDEO_VESA=y
BR2_PACKAGE_XTERM=y
BR2_PACKAGE_FLUXBOX=y
BR2_TARGET_ROOTFS_INITRAMFS=y
BR2_TARGET_ROOTFS_ISO9660=y
# BR2_TARGET_ROOTFS_TAR is not set
BR2_TARGET_SYSLINUX=y

Long story short, I am trying to run a Qt 5.9.x Open GL application (based
on Quick Controls 2) on a an x86 platform that has no Linux support for
hardware accelerated graphics. Trying to get a valid framebuffer working on
that platform is no go either (usually crashes the system when you try to
load an intel video driver) so I'm stuck with trying to get it to work with
a software rasterizer and xcb. Upon testing the results, the application
runs very poorly. My only guess is it's because BR's mesa3d package is not
building the llvmpipe driver. When I run glxgears / glxinfo, I can show it
running swrast or softpipe instead. How do I force Mesa to build AND use
this specific driver?

I know it's not completely the hardware's fault because when I run Tiny Core
on it with X and OpenGL SW rast, it seems to run much smoother and the only
difference I see is that they seem to explicitly configure it to build llvm:
http://tinycorelinux.net/8.x/x86/tcz/src/Xorg-7.7-3d/compile_mesa.

Thoughts? Maybe I am misunderstanding how Mesa and OpenGL with swrast,
softpipe, and llvmpipe all work.



--
Sent from: http://buildroot-busybox.2317881.n4.nabble.com/

[Buildroot] How to force mesa3d to use llvmpipe?

[nimaim]

Looks like BR may still not have llvmpipe support. Curious if this patch got
anywhere?
 http://lists.busybox.net/pipermail/buildroot/2017-July/195823.html



--
Sent from: http://buildroot-busybox.2317881.n4.nabble.com/

[Buildroot] How to force mesa3d to use llvmpipe?

[Romain Naour]

Hi Nimai,

Le 22/12/2017 ? 22:22, nimaim a ?crit?:
> Looks like BR may still not have llvmpipe support. Curious if this patch got
> anywhere?
>  http://lists.busybox.net/pipermail/buildroot/2017-July/195823.html

This patch series is still present in the patchwork [1] but this work need to be
updated with the latest llvm/clang release (5.0.1).

However, you can still test this series and you should be able to use llvmpipe.

I have not announced it yet on the mailing list that there will be a student at
Smile working on this subject. He will present his internship topic during the
next Buildroot meeting [2].

Enabling llvmpipe support in mesa is not really difficult but packaging
llvm/clang is a more difficult and time consuming task.

You're welcome to work on this series and give some feedback.

Best regards,
Romain

[1] http://patchwork.ozlabs.org/bundle/kubu/llvm-clang
[2] https://elinux.org/Buildroot:DeveloperDaysFOSDEM2018#Meeting_agenda

> 
> 
> 
> --
> Sent from: http://buildroot-busybox.2317881.n4.nabble.com/
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] How to force mesa3d to use llvmpipe?

[Nimai Mahajan]

On Fri, Dec 22, 2017 at 4:52 PM, Romain Naour <romain.naour@gmail.com>
wrote:

> Hi Nimai,
>
> Le 22/12/2017 ? 22:22, nimaim a ?crit :
> > Looks like BR may still not have llvmpipe support. Curious if this patch
> got
> > anywhere?
> >  http://lists.busybox.net/pipermail/buildroot/2017-July/195823.html
>
> This patch series is still present in the patchwork [1] but this work need
> to be
> updated with the latest llvm/clang release (5.0.1).
>
> However, you can still test this series and you should be able to use
> llvmpipe.
>

Thanks! Sounds good, I will try to merge Adrian's llvm package and mesa3d
patches locally and rebuild mesa and see if I can get Qt to work with the
llvm OpenGL driver. By any chance, do you know if llvm v4.0.0 will work
with mesa 17.2.x or 17.3.x or will it have to be bumped to v5? Also, not
sure how familiar with Qt you are, but do you know if Qt will require
special hooks to be able to use this with xcb?

>
> I have not announced it yet on the mailing list that there will be a
> student at
> Smile working on this subject. He will present his internship topic during
> the
> next Buildroot meeting [2].


> Enabling llvmpipe support in mesa is not really difficult but packaging
> llvm/clang is a more difficult and time consuming task.
>

Great! Agreed, something that definitely needs some work. Glad to see
someone will be working it.

>
> You're welcome to work on this series and give some feedback.
>

I'm merely a small time dev and still learning (as is probably evident by
all my questions :)), especially with embedded graphics, but will be happy
to test and contribute any way I can. Hopefully I can get this in a decent
enough state. Quite surprised that this hasn't made it to BR yet.

>
> Best regards,
> Romain
>
> [1] http://patchwork.ozlabs.org/bundle/kubu/llvm-clang


Link doesn't seem to be working but I guess you are talking about the
patches here?

https://patchwork.ozlabs.org/patch/777949/
https://patchwork.ozlabs.org/patch/777947/


>
> [2] https://elinux.org/Buildroot:DeveloperDaysFOSDEM2018#Meeting_agenda
>
> >
> >
> >
> > --
> > Sent from: http://buildroot-busybox.2317881.n4.nabble.com/
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171222/80031742/attachment.html>

[Buildroot] How to force mesa3d to use llvmpipe?

[Adrian Perez de Castro]

Hello Nimai,

On Fri, 22 Dec 2017 17:10:49 -0500, Nimai Mahajan <nimaim@gmail.com> wrote:
> On Fri, Dec 22, 2017 at 4:52 PM, Romain Naour <romain.naour@gmail.com> wrote:
> 
> > Hi Nimai,
> >
> > Le 22/12/2017 ? 22:22, nimaim a ?crit :
> > > Looks like BR may still not have llvmpipe support. Curious if this patch got
> > > anywhere?
> > >  http://lists.busybox.net/pipermail/buildroot/2017-July/195823.html

I have made those patches as part of a proof-of-concept for a project. The
people involved have decided to switch over to a GPU-accelerated solution, and
that means that I have not been devoting time to polish the patch set for
inclusion upstream. While I think it would be nice to have LLVM packages
merged, so far I have been working on Buildroot using my laptop and it has
been prohibitive to me to spend CPU time on side quests which don't help my
daily work ? sorry about that!

> > This patch series is still present in the patchwork [1] but this work need
> > to be updated with the latest llvm/clang release (5.0.1).

After Christmas I expect to have a powerful build machine and plenty of disk
space, and then it will be more feasible for me to try do some additional
contributions to Buildroot. Let's see then whether I can get it updated.

> > However, you can still test this series and you should be able to use
> > llvmpipe.
> 
> Thanks! Sounds good, I will try to merge Adrian's llvm package and mesa3d
> patches locally and rebuild mesa and see if I can get Qt to work with the
> llvm OpenGL driver. By any chance, do you know if llvm v4.0.0 will work
> with mesa 17.2.x or 17.3.x or will it have to be bumped to v5? Also, not
> sure how familiar with Qt you are, but do you know if Qt will require
> special hooks to be able to use this with xcb?

Any Mesa 17.x should work fine with LLVM 4.x; it should not be needed to
update the build recipes to LLVM 5. Quoting from the Mesa website:

  ?Unless otherwise stated, LLVM version 3.4 is recommended; 3.3 or
   later is required.?

There is also this note regarding PowerPC support:

  ?For ppc64le processors, use of the Altivec feature (the Vector Facility) is
  recommended if supported; use of the VSX feature (the Vector-Scalar
  Facility) is recommended if supported AND Mesa is built with LLVM version
  4.0 or later.?

(See https://www.mesa3d.org/llvmpipe.html for more details.)
 
> > I have not announced it yet on the mailing list that there will be a
> > student at Smile working on this subject. He will present his internship
> > topic during the next Buildroot meeting [2].
> 

Nice! I am considering going to FOSDEM, if I do so it could be nice to meet
and maybe talk a bit about the topic  :-)

> > Enabling llvmpipe support in mesa is not really difficult but packaging
> > llvm/clang is a more difficult and time consuming task.
> 
> Great! Agreed, something that definitely needs some work. Glad to see
> someone will be working it.

Indeed. It would be great to see full support for LLVM in Buildroot, as it
would be a building block for many other things:

 - Enabling ?llvmpipe? the and ?swr? rasterizers in Mesa3D. Also, the ?amdgpu?
   can use (needs?) LLVM for some of the GPUs.

 - As said, it's a requisite of Clang. And having Clang could open the
   door to use Clang-based cross-compiler toolchains.

 - Rust uses LLVM for code generation. There has been patches recently flying
   by the mailing list which use prebuilt binaries (and that's already a great
   first step), but it would be nice that Buildroot compiles its own Rust
   toolchain, like it does for C/C++.

 - Probably others.

> > You're welcome to work on this series and give some feedback.
> >
> 
> I'm merely a small time dev and still learning (as is probably evident by
> all my questions :)), especially with embedded graphics, but will be happy
> to test and contribute any way I can. Hopefully I can get this in a decent
> enough state. Quite surprised that this hasn't made it to BR yet.

We all had to learn at some point, that's all right! Well, I would even say
that there's always one more thing to learn ;-)

Best regards,


--
 Adri?n ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171223/7ee84224/attachment.asc>

[Buildroot] How to force mesa3d to use llvmpipe?

[Adrian Perez de Castro]

On Sat, 23 Dec 2017 01:08:43 +0200, Adrian Perez de Castro <aperez@igalia.com> wrote:
> Hello Nimai,
> 
> On Fri, 22 Dec 2017 17:10:49 -0500, Nimai Mahajan <nimaim@gmail.com> wrote:
> > On Fri, Dec 22, 2017 at 4:52 PM, Romain Naour <romain.naour@gmail.com> wrote:
> > 
> > > Hi Nimai,
> > >
> > > Le 22/12/2017 ? 22:22, nimaim a ?crit :
> > > > Looks like BR may still not have llvmpipe support. Curious if this patch got
> > > > anywhere?
> > > >  http://lists.busybox.net/pipermail/buildroot/2017-July/195823.html
> 
> I have made those patches as part of a proof-of-concept for a project. The
> people involved have decided to switch over to a GPU-accelerated solution, and
> that means that I have not been devoting time to polish the patch set for
> inclusion upstream. While I think it would be nice to have LLVM packages
> merged, so far I have been working on Buildroot using my laptop and it has
> been prohibitive to me to spend CPU time on side quests which don't help my
> daily work ? sorry about that!
> 
> > > This patch series is still present in the patchwork [1] but this work need
> > > to be updated with the latest llvm/clang release (5.0.1).
> 
> After Christmas I expect to have a powerful build machine and plenty of disk
> space, and then it will be more feasible for me to try do some additional
> contributions to Buildroot. Let's see then whether I can get it updated.
> 
> > > However, you can still test this series and you should be able to use
> > > llvmpipe.
> > 
> > Thanks! Sounds good, I will try to merge Adrian's llvm package and mesa3d
> > patches locally and rebuild mesa and see if I can get Qt to work with the
> > llvm OpenGL driver. By any chance, do you know if llvm v4.0.0 will work
> > with mesa 17.2.x or 17.3.x or will it have to be bumped to v5? Also, not
> > sure how familiar with Qt you are, but do you know if Qt will require
> > special hooks to be able to use this with xcb?
> 
> Any Mesa 17.x should work fine with LLVM 4.x; it should not be needed to
> update the build recipes to LLVM 5. Quoting from the Mesa website:
> 
>   ?Unless otherwise stated, LLVM version 3.4 is recommended; 3.3 or
>    later is required.?
> 
> There is also this note regarding PowerPC support:
> 
>   ?For ppc64le processors, use of the Altivec feature (the Vector Facility) is
>   recommended if supported; use of the VSX feature (the Vector-Scalar
>   Facility) is recommended if supported AND Mesa is built with LLVM version
>   4.0 or later.?
> 
> (See https://www.mesa3d.org/llvmpipe.html for more details.)

One more detail: If Mesa does not realize by itself that it should use a
software-based rendering driver (which can happen when there are multiple
drivers built into Mesa), you can force it at runtime by setting the
?LIBGL_ALWAYS_SOFTWARE=1? environment variable. There is more about the
environment variables supported by Mesa here:

  https://www.mesa3d.org/envvars.html

> > > I have not announced it yet on the mailing list that there will be a
> > > student at Smile working on this subject. He will present his internship
> > > topic during the next Buildroot meeting [2].
> > 
> 
> Nice! I am considering going to FOSDEM, if I do so it could be nice to meet
> and maybe talk a bit about the topic  :-)
> 
> > > Enabling llvmpipe support in mesa is not really difficult but packaging
> > > llvm/clang is a more difficult and time consuming task.
> > 
> > Great! Agreed, something that definitely needs some work. Glad to see
> > someone will be working it.
> 
> Indeed. It would be great to see full support for LLVM in Buildroot, as it
> would be a building block for many other things:
> 
>  - Enabling ?llvmpipe? the and ?swr? rasterizers in Mesa3D. Also, the ?amdgpu?
>    can use (needs?) LLVM for some of the GPUs.
> 
>  - As said, it's a requisite of Clang. And having Clang could open the
>    door to use Clang-based cross-compiler toolchains.
> 
>  - Rust uses LLVM for code generation. There has been patches recently flying
>    by the mailing list which use prebuilt binaries (and that's already a great
>    first step), but it would be nice that Buildroot compiles its own Rust
>    toolchain, like it does for C/C++.
> 
>  - Probably others.
> 
> > > You're welcome to work on this series and give some feedback.
> > >
> > 
> > I'm merely a small time dev and still learning (as is probably evident by
> > all my questions :)), especially with embedded graphics, but will be happy
> > to test and contribute any way I can. Hopefully I can get this in a decent
> > enough state. Quite surprised that this hasn't made it to BR yet.
> 
> We all had to learn at some point, that's all right! Well, I would even say
> that there's always one more thing to learn ;-)
> 
> Best regards,
> 
--
 Adri?n ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171223/1ee318ec/attachment.asc>

[Buildroot] How to force mesa3d to use llvmpipe?

[Nimai Mahajan]

On Fri, Dec 22, 2017, 6:12 PM Adrian Perez de Castro <aperez@igalia.com>
wrote:

> On Sat, 23 Dec 2017 01:08:43 +0200, Adrian Perez de Castro <
> aperez at igalia.com> wrote:
> > Hello Nimai,
> >
> > On Fri, 22 Dec 2017 17:10:49 -0500, Nimai Mahajan <nimaim@gmail.com>
> wrote:
> > > On Fri, Dec 22, 2017 at 4:52 PM, Romain Naour <romain.naour@gmail.com>
> wrote:
> > >
> > > > Hi Nimai,
> > > >
> > > > Le 22/12/2017 ? 22:22, nimaim a ?crit :
> > > > > Looks like BR may still not have llvmpipe support. Curious if this
> patch got
> > > > > anywhere?
> > > > >
> http://lists.busybox.net/pipermail/buildroot/2017-July/195823.html
> >
> > I have made those patches as part of a proof-of-concept for a project.
> The
> > people involved have decided to switch over to a GPU-accelerated
> solution, and
> > that means that I have not been devoting time to polish the patch set for
> > inclusion upstream. While I think it would be nice to have LLVM packages
> > merged, so far I have been working on Buildroot using my laptop and it
> has
> > been prohibitive to me to spend CPU time on side quests which don't help
> my
> > daily work ? sorry about that!
> >
> > > > This patch series is still present in the patchwork [1] but this
> work need
> > > > to be updated with the latest llvm/clang release (5.0.1).
> >
> > After Christmas I expect to have a powerful build machine and plenty of
> disk
> > space, and then it will be more feasible for me to try do some additional
> > contributions to Buildroot. Let's see then whether I can get it updated.
> >
> > > > However, you can still test this series and you should be able to use
> > > > llvmpipe.
> > >
> > > Thanks! Sounds good, I will try to merge Adrian's llvm package and
> mesa3d
> > > patches locally and rebuild mesa and see if I can get Qt to work with
> the
> > > llvm OpenGL driver. By any chance, do you know if llvm v4.0.0 will work
> > > with mesa 17.2.x or 17.3.x or will it have to be bumped to v5? Also,
> not
> > > sure how familiar with Qt you are, but do you know if Qt will require
> > > special hooks to be able to use this with xcb?
> >
> > Any Mesa 17.x should work fine with LLVM 4.x; it should not be needed to
> > update the build recipes to LLVM 5. Quoting from the Mesa website:
> >
> >   ?Unless otherwise stated, LLVM version 3.4 is recommended; 3.3 or
> >    later is required.?
> >
> > There is also this note regarding PowerPC support:
> >
> >   ?For ppc64le processors, use of the Altivec feature (the Vector
> Facility) is
> >   recommended if supported; use of the VSX feature (the Vector-Scalar
> >   Facility) is recommended if supported AND Mesa is built with LLVM
> version
> >   4.0 or later.?
> >
> > (See https://www.mesa3d.org/llvmpipe.html for more details.)
>
> One more detail: If Mesa does not realize by itself that it should use a
> software-based rendering driver (which can happen when there are multiple
> drivers built into Mesa), you can force it at runtime by setting the
> ?LIBGL_ALWAYS_SOFTWARE=1? environment variable. There is more about the
> environment variables supported by Mesa here:
>
>   https://www.mesa3d.org/envvars.html
>
> Interesting, thanks I'll check that out. Not sure how to force it to use
> llvmpipe if you have gallium and dri swrast both enabled as well but I
> guess in that case you'd have to explicitly disable those, which hopefully
> doesn't break something else. Will be interesting integrating Qt into the
> mix here but as long as libGL.so is provided by mesa's llvmpipe, it should
> work.
>
> > > > I have not announced it yet on the mailing list that there will be a
> > > > student at Smile working on this subject. He will present his
> internship
> > > > topic during the next Buildroot meeting [2].
> > >
> >
> > Nice! I am considering going to FOSDEM, if I do so it could be nice to
> meet
> > and maybe talk a bit about the topic  :-)
> >
> > > > Enabling llvmpipe support in mesa is not really difficult but
> packaging
> > > > llvm/clang is a more difficult and time consuming task.
> > >
> > > Great! Agreed, something that definitely needs some work. Glad to see
> > > someone will be working it.
> >
> > Indeed. It would be great to see full support for LLVM in Buildroot, as
> it
> > would be a building block for many other things:
> >
> >  - Enabling ?llvmpipe? the and ?swr? rasterizers in Mesa3D. Also, the
> ?amdgpu?
> >    can use (needs?) LLVM for some of the GPUs.
> >
> >  - As said, it's a requisite of Clang. And having Clang could open the
> >    door to use Clang-based cross-compiler toolchains.
> >
> >  - Rust uses LLVM for code generation. There has been patches recently
> flying
> >    by the mailing list which use prebuilt binaries (and that's already a
> great
> >    first step), but it would be nice that Buildroot compiles its own Rust
> >    toolchain, like it does for C/C++.
> >
> >  - Probably others.
> >
> > > > You're welcome to work on this series and give some feedback.
> > > >
> > >
> > > I'm merely a small time dev and still learning (as is probably evident
> by
> > > all my questions :)), especially with embedded graphics, but will be
> happy
> > > to test and contribute any way I can. Hopefully I can get this in a
> decent
> > > enough state. Quite surprised that this hasn't made it to BR yet.
> >
> > We all had to learn at some point, that's all right! Well, I would even
> say
> > that there's always one more thing to learn ;-)
> >
> > Best regards,
> >
> --
>  Adri?n ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171223/bca405e8/attachment.html>

[Buildroot] How to force mesa3d to use llvmpipe?

[Nimai Mahajan]

On Fri, Dec 22, 2017 at 7:05 PM, Nimai Mahajan <nimaim@gmail.com> wrote:

> On Fri, Dec 22, 2017, 6:12 PM Adrian Perez de Castro <aperez@igalia.com>
> wrote:
>
>> On Sat, 23 Dec 2017 01:08:43 +0200, Adrian Perez de Castro <
>> aperez at igalia.com> wrote:
>> > Hello Nimai,
>> >
>> > On Fri, 22 Dec 2017 17:10:49 -0500, Nimai Mahajan <nimaim@gmail.com>
>> wrote:
>> > > On Fri, Dec 22, 2017 at 4:52 PM, Romain Naour <romain.naour@gmail.com>
>> wrote:
>> > >
>> > > > Hi Nimai,
>> > > >
>> > > > Le 22/12/2017 ? 22:22, nimaim a ?crit :
>> > > > > Looks like BR may still not have llvmpipe support. Curious if
>> this patch got
>> > > > > anywhere?
>> > > > >  http://lists.busybox.net/pipermail/buildroot/2017-July/
>> 195823.html
>> >
>> > I have made those patches as part of a proof-of-concept for a project.
>> The
>> > people involved have decided to switch over to a GPU-accelerated
>> solution, and
>> > that means that I have not been devoting time to polish the patch set
>> for
>> > inclusion upstream. While I think it would be nice to have LLVM packages
>> > merged, so far I have been working on Buildroot using my laptop and it
>> has
>> > been prohibitive to me to spend CPU time on side quests which don't
>> help my
>> > daily work ? sorry about that!
>> >
>> > > > This patch series is still present in the patchwork [1] but this
>> work need
>> > > > to be updated with the latest llvm/clang release (5.0.1).
>> >
>> > After Christmas I expect to have a powerful build machine and plenty of
>> disk
>> > space, and then it will be more feasible for me to try do some
>> additional
>> > contributions to Buildroot. Let's see then whether I can get it updated.
>> >
>> > > > However, you can still test this series and you should be able to
>> use
>> > > > llvmpipe.
>> > >
>> > > Thanks! Sounds good, I will try to merge Adrian's llvm package and
>> mesa3d
>> > > patches locally and rebuild mesa and see if I can get Qt to work with
>> the
>> > > llvm OpenGL driver. By any chance, do you know if llvm v4.0.0 will
>> work
>> > > with mesa 17.2.x or 17.3.x or will it have to be bumped to v5? Also,
>> not
>> > > sure how familiar with Qt you are, but do you know if Qt will require
>> > > special hooks to be able to use this with xcb?
>> >
>> > Any Mesa 17.x should work fine with LLVM 4.x; it should not be needed to
>> > update the build recipes to LLVM 5. Quoting from the Mesa website:
>> >
>> >   ?Unless otherwise stated, LLVM version 3.4 is recommended; 3.3 or
>> >    later is required.?
>> >
>> > There is also this note regarding PowerPC support:
>> >
>> >   ?For ppc64le processors, use of the Altivec feature (the Vector
>> Facility) is
>> >   recommended if supported; use of the VSX feature (the Vector-Scalar
>> >   Facility) is recommended if supported AND Mesa is built with LLVM
>> version
>> >   4.0 or later.?
>> >
>> > (See https://www.mesa3d.org/llvmpipe.html for more details.)
>>
>> One more detail: If Mesa does not realize by itself that it should use a
>> software-based rendering driver (which can happen when there are multiple
>> drivers built into Mesa), you can force it at runtime by setting the
>> ?LIBGL_ALWAYS_SOFTWARE=1? environment variable. There is more about the
>> environment variables supported by Mesa here:
>>
>>   https://www.mesa3d.org/envvars.html
>>
>> Interesting, thanks I'll check that out. Not sure how to force it to use
>> llvmpipe if you have gallium and dri swrast both enabled as well but I
>> guess in that case you'd have to explicitly disable those, which hopefully
>> doesn't break something else. Will be interesting integrating Qt into the
>> mix here but as long as libGL.so is provided by mesa's llvmpipe, it should
>> work.
>>
>>

So I patched buildroot master with those two patches (successfully) but
build fails. It seems to build llvm just fine, but mesa3d can't find any of
the llvm stuff and crashes on that. I pasted a stripped buildroot build log
of the llvm and mesa3d builds here:
https://gist.github.com/anonymous/6a5638bb91e4310029aaf90f43ef0d1c (the
blank lines are merely suppressed cmake: /usr/local/lib/libcurl.so.4:
no version
information available (required by cmake) messages to make the output
easier to read). I will have to look at this error more thoroughly at work
this week. I believe the ./configure for mesa3d looks good now though (and
should build llvmpipe swrast):

        prefix:          /usr
        exec_prefix:     /usr
        libdir:          ${exec_prefix}/lib
        includedir:      ${prefix}/include

        OpenGL:          yes (ES1: yes ES2: yes)

        OSMesa:          no

        DRI platform:    drm
        DRI drivers:     swrast
        DRI driver dir:  ${libdir}/dri
        GLX:             DRI-based

        EGL:             yes
        EGL drivers:     builtin:egl_dri2
        GBM:             yes
        EGL/Vulkan/VL platforms:   drm x11

        Vulkan drivers:  no

        llvm:            yes
        llvm-config:     /home/nimai/Desktop/buildroot/output/host/i686-
buildroot-linux-gnu/sysroot/usr/bin/llvm-config
        llvm-version:    4.0.0

        Gallium drivers: swrast
        Gallium st:      mesa

        HUD extra stats: yes
        HUD lmsensors:   no


        Shared libs:     yes
        Static libs:     no
        Shared-glapi:    yes

        CFLAGS:          -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os -Wall -Werror=implicit-function-declaration
-Werror=missing-prototypes -Wmissing-prototypes -fno-math-errno
-fno-trapping-math -std=c99
        CXXFLAGS:        -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os -Wall -fno-math-errno -fno-trapping-math
        LDFLAGS:
        Macros:          -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS
-DNDEBUG -DTEXTURE_FLOAT_ENABLED -DHAVE_XLOCALE_H -DHAVE_SYS_SYSCTL_H
-DHAVE_ENDIAN_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_STRTOD_L
-DHAVE_DL_ITERATE_PHDR -DHAVE_POSIX_MEMALIGN -DHAVE_GALLIUM_EXTRA_HUD=1
-DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
-DGLX_USE_TLS -DHAVE_DRM_PLATFORM -DHAVE_X11_PLATFORM -DENABLE_SHADER_CACHE
-DHAVE_MINCORE -DHAVE_LLVM=0x0400 -DMESA_LLVM_VERSION_PATCH=0

        LLVM_CFLAGS:     -I/home/nimai/Desktop/buildroot/output/host/i686-
buildroot-linux-gnu/sysroot/usr/include -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
        LLVM_CXXFLAGS:   -I/home/nimai/Desktop/buildroot/output/host/i686-
buildroot-linux-gnu/sysroot/usr/include  -std=c++11
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
        LLVM_CPPFLAGS:   -I/home/nimai/Desktop/buildroot/output/host/i686-
buildroot-linux-gnu/sysroot/usr/include -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
        LLVM_LDFLAGS:    -L/home/nimai/Desktop/buildroot/output/host/i686-
buildroot-linux-gnu/sysroot/usr/lib

        PYTHON2:         python2.7

        Run 'make' to build Mesa

Any ideas that will make this compile properly? Thanks. Sorry if this gets
posted twice, I originally pasted the log file which exceeded the mailing
list limit.




>
>> > > > I have not announced it yet on the mailing list that there will be a
>> > > > student at Smile working on this subject. He will present his
>> internship
>> > > > topic during the next Buildroot meeting [2].
>> > >
>> >
>> > Nice! I am considering going to FOSDEM, if I do so it could be nice to
>> meet
>> > and maybe talk a bit about the topic  :-)
>> >
>> > > > Enabling llvmpipe support in mesa is not really difficult but
>> packaging
>> > > > llvm/clang is a more difficult and time consuming task.
>> > >
>> > > Great! Agreed, something that definitely needs some work. Glad to see
>> > > someone will be working it.
>> >
>> > Indeed. It would be great to see full support for LLVM in Buildroot, as
>> it
>> > would be a building block for many other things:
>> >
>> >  - Enabling ?llvmpipe? the and ?swr? rasterizers in Mesa3D. Also, the
>> ?amdgpu?
>> >    can use (needs?) LLVM for some of the GPUs.
>> >
>> >  - As said, it's a requisite of Clang. And having Clang could open the
>> >    door to use Clang-based cross-compiler toolchains.
>> >
>> >  - Rust uses LLVM for code generation. There has been patches recently
>> flying
>> >    by the mailing list which use prebuilt binaries (and that's already
>> a great
>> >    first step), but it would be nice that Buildroot compiles its own
>> Rust
>> >    toolchain, like it does for C/C++.
>> >
>> >  - Probably others.
>> >
>> > > > You're welcome to work on this series and give some feedback.
>> > > >
>> > >
>> > > I'm merely a small time dev and still learning (as is probably
>> evident by
>> > > all my questions :)), especially with embedded graphics, but will be
>> happy
>> > > to test and contribute any way I can. Hopefully I can get this in a
>> decent
>> > > enough state. Quite surprised that this hasn't made it to BR yet.
>> >
>> > We all had to learn at some point, that's all right! Well, I would even
>> say
>> > that there's always one more thing to learn ;-)
>> >
>> > Best regards,
>> >
>> --
>>  Adri?n ?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171224/b197794e/attachment.html>

[Buildroot] How to force mesa3d to use llvmpipe?

[Romain Naour]

Hi Nimai, All,

Le 24/12/2017 ? 17:46, Nimai Mahajan a ?crit?:
> 
> 
> On Fri, Dec 22, 2017 at 7:05 PM, Nimai Mahajan <nimaim@gmail.com
> <mailto:nimaim@gmail.com>> wrote:
> 
>     On Fri, Dec 22, 2017, 6:12 PM Adrian Perez de Castro <aperez@igalia.com
>     <mailto:aperez@igalia.com>> wrote:
> 
>         On Sat, 23 Dec 2017 01:08:43 +0200, Adrian Perez de Castro
>         <aperez at igalia.com <mailto:aperez@igalia.com>> wrote:
>         > Hello Nimai,
>         >
>         > On Fri, 22 Dec 2017 17:10:49 -0500, Nimai Mahajan <nimaim@gmail.com
>         <mailto:nimaim@gmail.com>> wrote:
>         > > On Fri, Dec 22, 2017 at 4:52 PM, Romain Naour
>         <romain.naour at gmail.com <mailto:romain.naour@gmail.com>> wrote:
>         > >
>         > > > Hi Nimai,
>         > > >
>         > > > Le 22/12/2017 ? 22:22, nimaim a ?crit :
>         > > > > Looks like BR may still not have llvmpipe support. Curious if
>         this patch got
>         > > > > anywhere?
>         > > > >?
>         http://lists.busybox.net/pipermail/buildroot/2017-July/195823.html
>         <http://lists.busybox.net/pipermail/buildroot/2017-July/195823.html>
>         >
>         > I have made those patches as part of a proof-of-concept for a project. The
>         > people involved have decided to switch over to a GPU-accelerated
>         solution, and
>         > that means that I have not been devoting time to polish the patch set for
>         > inclusion upstream. While I think it would be nice to have LLVM packages
>         > merged, so far I have been working on Buildroot using my laptop and it has
>         > been prohibitive to me to spend CPU time on side quests which don't
>         help my
>         > daily work ? sorry about that!
>         >
>         > > > This patch series is still present in the patchwork [1] but this
>         work need
>         > > > to be updated with the latest llvm/clang release (5.0.1).
>         >
>         > After Christmas I expect to have a powerful build machine and plenty
>         of disk
>         > space, and then it will be more feasible for me to try do some additional
>         > contributions to Buildroot. Let's see then whether I can get it updated.
>         >
>         > > > However, you can still test this series and you should be able to use
>         > > > llvmpipe.
>         > >
>         > > Thanks! Sounds good, I will try to merge Adrian's llvm package and
>         mesa3d
>         > > patches locally and rebuild mesa and see if I can get Qt to work
>         with the
>         > > llvm OpenGL driver. By any chance, do you know if llvm v4.0.0 will work
>         > > with mesa 17.2.x or 17.3.x or will it have to be bumped to v5? Also, not
>         > > sure how familiar with Qt you are, but do you know if Qt will require
>         > > special hooks to be able to use this with xcb?
>         >
>         > Any Mesa 17.x should work fine with LLVM 4.x; it should not be needed to
>         > update the build recipes to LLVM 5. Quoting from the Mesa website:
>         >
>         >? ??Unless otherwise stated, LLVM version 3.4 is recommended; 3.3 or
>         >? ? later is required.?
>         >
>         > There is also this note regarding PowerPC support:
>         >
>         >? ??For ppc64le processors, use of the Altivec feature (the Vector
>         Facility) is
>         >? ?recommended if supported; use of the VSX feature (the Vector-Scalar
>         >? ?Facility) is recommended if supported AND Mesa is built with LLVM
>         version
>         >? ?4.0 or later.?
>         >
>         > (See https://www.mesa3d.org/llvmpipe.html
>         <https://www.mesa3d.org/llvmpipe.html> for more details.)
> 
>         One more detail: If Mesa does not realize by itself that it should use a
>         software-based rendering driver (which can happen when there are multiple
>         drivers built into Mesa), you can force it at runtime by setting the
>         ?LIBGL_ALWAYS_SOFTWARE=1? environment variable. There is more about the
>         environment variables supported by Mesa here:
> 
>         ? https://www.mesa3d.org/envvars.html <https://www.mesa3d.org/envvars.html>
> 
>         Interesting, thanks I'll check that out. Not sure how to force it to use
>         llvmpipe if you have gallium and dri swrast both enabled as well but I
>         guess in that case you'd have to explicitly disable those, which
>         hopefully doesn't break something else. Will be interesting integrating
>         Qt into the mix here but as long as libGL.so is provided by mesa's
>         llvmpipe, it should work.
> 
> 
> 
> So I patched buildroot master with those two patches (successfully) but build
> fails. It seems to build llvm just fine, but mesa3d can't find any of the llvm
> stuff and crashes on that. I pasted a stripped buildroot build log of the llvm
> and mesa3d builds
> here:?https://gist.github.com/anonymous/6a5638bb91e4310029aaf90f43ef0d1c (the
> blank lines are merely suppressed?cmake:?/usr/local/lib/libcurl.so.4:?no?version
> information available?(required?by?cmake)?messages to make the output easier to
> read). I will have to look at this error more thoroughly at work this week. I
> believe the ./configure for mesa3d looks good now though (and should build
> llvmpipe swrast):
> 
> ? ? ? ? prefix:? ? ? ? ? /usr
> ? ? ? ? exec_prefix:? ? ?/usr
> ? ? ? ? libdir:? ? ? ? ? ${exec_prefix}/lib
> ? ? ? ? includedir:? ? ? ${prefix}/include
> 
> ? ? ? ? OpenGL:? ? ? ? ? yes (ES1: yes ES2: yes)
> 
> ? ? ? ? OSMesa:? ? ? ? ? no
> 
> ? ? ? ? DRI platform:? ? drm
> ? ? ? ? DRI drivers:? ? ?swrast?
> ? ? ? ? DRI driver dir:? ${libdir}/dri
> ? ? ? ? GLX:? ? ? ? ? ? ?DRI-based
> 
> ? ? ? ? EGL:? ? ? ? ? ? ?yes
> ? ? ? ? EGL drivers:? ? ?builtin:egl_dri2
> ? ? ? ? GBM:? ? ? ? ? ? ?yes
> ? ? ? ? EGL/Vulkan/VL platforms:? ?drm x11
> 
> ? ? ? ? Vulkan drivers:? no
> 
> ? ? ? ? llvm:? ? ? ? ? ? yes
> ? ? ? ? llvm-config:? ?
> ?/home/nimai/Desktop/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/bin/llvm-config
> ? ? ? ? llvm-version:? ? 4.0.0
> 
> ? ? ? ? Gallium drivers: swrast
> ? ? ? ? Gallium st:? ? ? mesa
> 
> ? ? ? ? HUD extra stats: yes
> ? ? ? ? HUD lmsensors:? ?no
> 
> 
> ? ? ? ? Shared libs:? ? ?yes
> ? ? ? ? Static libs:? ? ?no
> ? ? ? ? Shared-glapi:? ? yes
> 
> ? ? ? ? CFLAGS:? ? ? ? ? -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -Os -Wall -Werror=implicit-function-declaration
> -Werror=missing-prototypes -Wmissing-prototypes -fno-math-errno
> -fno-trapping-math -std=c99
> ? ? ? ? CXXFLAGS:? ? ? ? -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -Os -Wall -fno-math-errno -fno-trapping-math
> ? ? ? ? LDFLAGS:? ? ? ? ?
> ? ? ? ? Macros:? ? ? ? ? -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> -D__STDC_LIMIT_MACROS -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS
> -DNDEBUG -DTEXTURE_FLOAT_ENABLED -DHAVE_XLOCALE_H -DHAVE_SYS_SYSCTL_H
> -DHAVE_ENDIAN_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_STRTOD_L
> -DHAVE_DL_ITERATE_PHDR -DHAVE_POSIX_MEMALIGN -DHAVE_GALLIUM_EXTRA_HUD=1
> -DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
> -DGLX_USE_TLS -DHAVE_DRM_PLATFORM -DHAVE_X11_PLATFORM -DENABLE_SHADER_CACHE
> -DHAVE_MINCORE -DHAVE_LLVM=0x0400 -DMESA_LLVM_VERSION_PATCH=0
> 
> ? ? ? ? LLVM_CFLAGS:? ?
> ?-I/home/nimai/Desktop/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> ? ? ? ? LLVM_CXXFLAGS:?
> ?-I/home/nimai/Desktop/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include?
> -std=c++11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> ? ? ? ? LLVM_CPPFLAGS:?
> ?-I/home/nimai/Desktop/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> ? ? ? ? LLVM_LDFLAGS:? ?
> -L/home/nimai/Desktop/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/lib?
> 
> ? ? ? ? PYTHON2:? ? ? ? ?python2.7
> 
> ? ? ? ? Run 'make' to build Mesa
> 
> Any ideas that will make this compile properly? Thanks. Sorry if this gets
> posted twice, I originally pasted the log file which exceeded the mailing list
> limit.

Last time I tried this, an older version of mesa was used (17.0 or 17.1).
I don't have much time these days to work on llvm+mesa.
IIRC, mesa needs to be statically linked with llvm libraries. llvm libraries in
staging directory should be shared libraries (*.so). Try to force llvm for the
target to be build statically.

Best regards,
Romain

[Buildroot] How to force mesa3d to use llvmpipe?

[Nimai Mahajan]

On Mon, Dec 25, 2017 at 7:08 AM, Romain Naour <romain.naour@gmail.com>
wrote:

> Hi Nimai, All,
>
> Le 24/12/2017 ? 17:46, Nimai Mahajan a ?crit :
> >
> >
> > On Fri, Dec 22, 2017 at 7:05 PM, Nimai Mahajan <nimaim@gmail.com
> > <mailto:nimaim@gmail.com>> wrote:
> >
> >     On Fri, Dec 22, 2017, 6:12 PM Adrian Perez de Castro <
> aperez at igalia.com
> >     <mailto:aperez@igalia.com>> wrote:
> >
> >         On Sat, 23 Dec 2017 01:08:43 +0200, Adrian Perez de Castro
> >         <aperez at igalia.com <mailto:aperez@igalia.com>> wrote:
> >         > Hello Nimai,
> >         >
> >         > On Fri, 22 Dec 2017 17:10:49 -0500, Nimai Mahajan <
> nimaim at gmail.com
> >         <mailto:nimaim@gmail.com>> wrote:
> >         > > On Fri, Dec 22, 2017 at 4:52 PM, Romain Naour
> >         <romain.naour at gmail.com <mailto:romain.naour@gmail.com>> wrote:
> >         > >
> >         > > > Hi Nimai,
> >         > > >
> >         > > > Le 22/12/2017 ? 22:22, nimaim a ?crit :
> >         > > > > Looks like BR may still not have llvmpipe support.
> Curious if
> >         this patch got
> >         > > > > anywhere?
> >         > > > >
> >         http://lists.busybox.net/pipermail/buildroot/2017-July/
> 195823.html
> >         <http://lists.busybox.net/pipermail/buildroot/2017-July/
> 195823.html>
> >         >
> >         > I have made those patches as part of a proof-of-concept for a
> project. The
> >         > people involved have decided to switch over to a
> GPU-accelerated
> >         solution, and
> >         > that means that I have not been devoting time to polish the
> patch set for
> >         > inclusion upstream. While I think it would be nice to have
> LLVM packages
> >         > merged, so far I have been working on Buildroot using my
> laptop and it has
> >         > been prohibitive to me to spend CPU time on side quests which
> don't
> >         help my
> >         > daily work ? sorry about that!
> >         >
> >         > > > This patch series is still present in the patchwork [1]
> but this
> >         work need
> >         > > > to be updated with the latest llvm/clang release (5.0.1).
> >         >
> >         > After Christmas I expect to have a powerful build machine and
> plenty
> >         of disk
> >         > space, and then it will be more feasible for me to try do some
> additional
> >         > contributions to Buildroot. Let's see then whether I can get
> it updated.
> >         >
> >         > > > However, you can still test this series and you should be
> able to use
> >         > > > llvmpipe.
> >         > >
> >         > > Thanks! Sounds good, I will try to merge Adrian's llvm
> package and
> >         mesa3d
> >         > > patches locally and rebuild mesa and see if I can get Qt to
> work
> >         with the
> >         > > llvm OpenGL driver. By any chance, do you know if llvm
> v4.0.0 will work
> >         > > with mesa 17.2.x or 17.3.x or will it have to be bumped to
> v5? Also, not
> >         > > sure how familiar with Qt you are, but do you know if Qt
> will require
> >         > > special hooks to be able to use this with xcb?
> >         >
> >         > Any Mesa 17.x should work fine with LLVM 4.x; it should not be
> needed to
> >         > update the build recipes to LLVM 5. Quoting from the Mesa
> website:
> >         >
> >         >   ?Unless otherwise stated, LLVM version 3.4 is recommended;
> 3.3 or
> >         >    later is required.?
> >         >
> >         > There is also this note regarding PowerPC support:
> >         >
> >         >   ?For ppc64le processors, use of the Altivec feature (the
> Vector
> >         Facility) is
> >         >   recommended if supported; use of the VSX feature (the
> Vector-Scalar
> >         >   Facility) is recommended if supported AND Mesa is built with
> LLVM
> >         version
> >         >   4.0 or later.?
> >         >
> >         > (See https://www.mesa3d.org/llvmpipe.html
> >         <https://www.mesa3d.org/llvmpipe.html> for more details.)
> >
> >         One more detail: If Mesa does not realize by itself that it
> should use a
> >         software-based rendering driver (which can happen when there are
> multiple
> >         drivers built into Mesa), you can force it at runtime by setting
> the
> >         ?LIBGL_ALWAYS_SOFTWARE=1? environment variable. There is more
> about the
> >         environment variables supported by Mesa here:
> >
> >           https://www.mesa3d.org/envvars.html <https://www.mesa3d.org/
> envvars.html>
> >
> >         Interesting, thanks I'll check that out. Not sure how to force
> it to use
> >         llvmpipe if you have gallium and dri swrast both enabled as well
> but I
> >         guess in that case you'd have to explicitly disable those, which
> >         hopefully doesn't break something else. Will be interesting
> integrating
> >         Qt into the mix here but as long as libGL.so is provided by
> mesa's
> >         llvmpipe, it should work.
> >
> >
> >
> > So I patched buildroot master with those two patches (successfully) but
> build
> > fails. It seems to build llvm just fine, but mesa3d can't find any of
> the llvm
> > stuff and crashes on that. I pasted a stripped buildroot build log of
> the llvm
> > and mesa3d builds
> > here: https://gist.github.com/anonymous/6a5638bb91e4310029aaf90f43ef0d1c
> (the
> > blank lines are merely suppressed cmake: /usr/local/
> lib/libcurl.so.4: no version
> > information available (required by cmake) messages to make the output
> easier to
> > read). I will have to look at this error more thoroughly at work this
> week. I
> > believe the ./configure for mesa3d looks good now though (and should
> build
> > llvmpipe swrast):
> >
> >         prefix:          /usr
> >         exec_prefix:     /usr
> >         libdir:          ${exec_prefix}/lib
> >         includedir:      ${prefix}/include
> >
> >         OpenGL:          yes (ES1: yes ES2: yes)
> >
> >         OSMesa:          no
> >
> >         DRI platform:    drm
> >         DRI drivers:     swrast
> >         DRI driver dir:  ${libdir}/dri
> >         GLX:             DRI-based
> >
> >         EGL:             yes
> >         EGL drivers:     builtin:egl_dri2
> >         GBM:             yes
> >         EGL/Vulkan/VL platforms:   drm x11
> >
> >         Vulkan drivers:  no
> >
> >         llvm:            yes
> >         llvm-config:
> >  /home/nimai/Desktop/buildroot/output/host/i686-
> buildroot-linux-gnu/sysroot/usr/bin/llvm-config
> >         llvm-version:    4.0.0
> >
> >         Gallium drivers: swrast
> >         Gallium st:      mesa
> >
> >         HUD extra stats: yes
> >         HUD lmsensors:   no
> >
> >
> >         Shared libs:     yes
> >         Static libs:     no
> >         Shared-glapi:    yes
> >
> >         CFLAGS:          -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > -D_FILE_OFFSET_BITS=64 -Os -Wall -Werror=implicit-function-declaration
> > -Werror=missing-prototypes -Wmissing-prototypes -fno-math-errno
> > -fno-trapping-math -std=c99
> >         CXXFLAGS:        -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > -D_FILE_OFFSET_BITS=64 -Os -Wall -fno-math-errno -fno-trapping-math
> >         LDFLAGS:
> >         Macros:          -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> > -D__STDC_LIMIT_MACROS -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS
> > -DNDEBUG -DTEXTURE_FLOAT_ENABLED -DHAVE_XLOCALE_H -DHAVE_SYS_SYSCTL_H
> > -DHAVE_ENDIAN_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_STRTOD_L
> > -DHAVE_DL_ITERATE_PHDR -DHAVE_POSIX_MEMALIGN -DHAVE_GALLIUM_EXTRA_HUD=1
> > -DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_INDIRECT_RENDERING
> -DGLX_DIRECT_RENDERING
> > -DGLX_USE_TLS -DHAVE_DRM_PLATFORM -DHAVE_X11_PLATFORM
> -DENABLE_SHADER_CACHE
> > -DHAVE_MINCORE -DHAVE_LLVM=0x0400 -DMESA_LLVM_VERSION_PATCH=0
> >
> >         LLVM_CFLAGS:
> >  -I/home/nimai/Desktop/buildroot/output/host/i686-
> buildroot-linux-gnu/sysroot/usr/include
> > -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> >         LLVM_CXXFLAGS:
> >  -I/home/nimai/Desktop/buildroot/output/host/i686-
> buildroot-linux-gnu/sysroot/usr/include
> > -std=c++11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> -D__STDC_LIMIT_MACROS
> >         LLVM_CPPFLAGS:
> >  -I/home/nimai/Desktop/buildroot/output/host/i686-
> buildroot-linux-gnu/sysroot/usr/include
> > -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> >         LLVM_LDFLAGS:
> > -L/home/nimai/Desktop/buildroot/output/host/i686-
> buildroot-linux-gnu/sysroot/usr/lib
> >
> >         PYTHON2:         python2.7
> >
> >         Run 'make' to build Mesa
> >
> > Any ideas that will make this compile properly? Thanks. Sorry if this
> gets
> > posted twice, I originally pasted the log file which exceeded the
> mailing list
> > limit.
>
> Last time I tried this, an older version of mesa was used (17.0 or 17.1).
> I don't have much time these days to work on llvm+mesa.
> IIRC, mesa needs to be statically linked with llvm libraries. llvm
> libraries in
> staging directory should be shared libraries (*.so). Try to force llvm for
> the
> target to be build statically.
>
> Best regards,
> Romain
>

Thanks Romain, I tried to incorporate some of your RFC patches with what
Adrian had done and build llvm statically (which it seemed to do), and
still couldn't get it working. Same error linking mesa3d gallium libs
against llvm. Unfortunately, I won't have much time to work on this either
as I'm on a tight schedule at work and I have to finish up many other
things for a working build. I will have to resort to using the slow
softpipe driver for now unless someone else wants to take a stab at it. I
don't think yocto has llvmpipe incorporated yet either so everyone is
working towards this (supposedly will be in their next build though:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3488).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171226/b83c6c16/attachment.html>

[Buildroot] How to force mesa3d to use llvmpipe?

[Nimai Mahajan]

On Fri, Dec 22, 2017 at 6:08 PM, Adrian Perez de Castro <aperez@igalia.com>
wrote:

> Hello Nimai,
>
> On Fri, 22 Dec 2017 17:10:49 -0500, Nimai Mahajan <nimaim@gmail.com>
> wrote:
> > On Fri, Dec 22, 2017 at 4:52 PM, Romain Naour <romain.naour@gmail.com>
> wrote:
> >
> > > Hi Nimai,
> > >
> > > Le 22/12/2017 ? 22:22, nimaim a ?crit :
> > > > Looks like BR may still not have llvmpipe support. Curious if this
> patch got
> > > > anywhere?
> > > >  http://lists.busybox.net/pipermail/buildroot/2017-July/195823.html
>
> I have made those patches as part of a proof-of-concept for a project. The
> people involved have decided to switch over to a GPU-accelerated solution,
> and
> that means that I have not been devoting time to polish the patch set for
> inclusion upstream. While I think it would be nice to have LLVM packages
> merged, so far I have been working on Buildroot using my laptop and it has
> been prohibitive to me to spend CPU time on side quests which don't help my
> daily work ? sorry about that!
>

No problem! That's understandable. I appreciate your efforts very much as I
wouldn't even know where to start with integrating LLVM into BR. I do think
getting a software rasterizer like llvmpipe working is pretty important as
many are using older deprecated or embedded systems where GPU accelerated
graphics are simply not an option. swrast / softpipe drivers work very
poorly.

>
> > > This patch series is still present in the patchwork [1] but this work
> need
> > > to be updated with the latest llvm/clang release (5.0.1).
>
> After Christmas I expect to have a powerful build machine and plenty of
> disk
> space, and then it will be more feasible for me to try do some additional
> contributions to Buildroot. Let's see then whether I can get it updated.
>

That would be great! Anything I propose would probably be a hack at best
and I can only test on x86 and I think BR's official solution for LLVM as
is being presented during their next meeting will take a while to
incorporate. So whatever you can propose would be greatly appreciated (as
your schedule allows of course!).

>
> > > However, you can still test this series and you should be able to use
> > > llvmpipe.
> >
> > Thanks! Sounds good, I will try to merge Adrian's llvm package and mesa3d
> > patches locally and rebuild mesa and see if I can get Qt to work with the
> > llvm OpenGL driver. By any chance, do you know if llvm v4.0.0 will work
> > with mesa 17.2.x or 17.3.x or will it have to be bumped to v5? Also, not
> > sure how familiar with Qt you are, but do you know if Qt will require
> > special hooks to be able to use this with xcb?
>
> Any Mesa 17.x should work fine with LLVM 4.x; it should not be needed to
> update the build recipes to LLVM 5. Quoting from the Mesa website:
>
>   ?Unless otherwise stated, LLVM version 3.4 is recommended; 3.3 or
>    later is required.?
>
> There is also this note regarding PowerPC support:
>
>   ?For ppc64le processors, use of the Altivec feature (the Vector
> Facility) is
>   recommended if supported; use of the VSX feature (the Vector-Scalar
>   Facility) is recommended if supported AND Mesa is built with LLVM version
>   4.0 or later.?
>
> (See https://www.mesa3d.org/llvmpipe.html for more details.)
>

Thanks! That's good news. I will give it a go with what you submitted so
far the and work from there.

>
> > > I have not announced it yet on the mailing list that there will be a
> > > student at Smile working on this subject. He will present his
> internship
> > > topic during the next Buildroot meeting [2].
> >
>
> Nice! I am considering going to FOSDEM, if I do so it could be nice to meet
> and maybe talk a bit about the topic  :-)
>
> > > Enabling llvmpipe support in mesa is not really difficult but packaging
> > > llvm/clang is a more difficult and time consuming task.
> >
> > Great! Agreed, something that definitely needs some work. Glad to see
> > someone will be working it.
>
> Indeed. It would be great to see full support for LLVM in Buildroot, as it
> would be a building block for many other things:
>
>  - Enabling ?llvmpipe? the and ?swr? rasterizers in Mesa3D. Also, the
> ?amdgpu?
>    can use (needs?) LLVM for some of the GPUs.
>
>  - As said, it's a requisite of Clang. And having Clang could open the
>    door to use Clang-based cross-compiler toolchains.
>
>  - Rust uses LLVM for code generation. There has been patches recently
> flying
>    by the mailing list which use prebuilt binaries (and that's already a
> great
>    first step), but it would be nice that Buildroot compiles its own Rust
>    toolchain, like it does for C/C++.
>
>  - Probably others.
>

Yes, proper llvm support could definitely open many doors for BR. Looking
forward to this! I'm sure the devs would love it if you could join them at
FOSDEM and help with this.

>
> > > You're welcome to work on this series and give some feedback.
> > >
> >
> > I'm merely a small time dev and still learning (as is probably evident by
> > all my questions :)), especially with embedded graphics, but will be
> happy
> > to test and contribute any way I can. Hopefully I can get this in a
> decent
> > enough state. Quite surprised that this hasn't made it to BR yet.
>
> We all had to learn at some point, that's all right! Well, I would even say
> that there's always one more thing to learn ;-)
>

That's for sure, haha. I've worked with BR for many years but still never
fully understood the infrastructure. At some point in the very near future,
I'll stop procrastinating and properly learn :)

>
> Best regards,
>
>
> --
>  Adri?n ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171222/9a2e2284/attachment.html>