[Mesa-dev] [PATCH] mesa: Enable LTO compilation
This patch enables compilation with -flto. The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears. Performance changes in OpenGL games haven't been measured yet, my feeling is that they are negligible. diff --git a/configure.ac b/configure.ac index fc0b1db..e84a1ad 100644 --- a/configure.ac +++ b/configure.ac @@ -362,6 +362,8 @@ if test "x$GXX" = xyes; then CXXFLAGS="$CXXFLAGS -fno-builtin-memcmp" fi +AX_CHECK_COMPILE_FLAG([-flto], AM_CONDITIONAL(COMPILER_UNDERSTANDS_LTO, true), AM_CONDITIONAL(COMPILER_UNDERSTANDS_LTO, false)) + AC_SUBST([MSVC2013_COMPAT_CFLAGS]) AC_SUBST([MSVC2013_COMPAT_CXXFLAGS]) diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am index 68a28a2..4b7d266 100644 --- a/src/mapi/Makefile.am +++ b/src/mapi/Makefile.am @@ -51,6 +51,11 @@ AM_CPPFLAGS = \ include Makefile.sources +if COMPILER_UNDERSTANDS_LTO +CFLAGS += -fno-lto +CXXFLAGS += -fno-lto +endif + MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D) PYTHON_GEN = $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Mon, May 30, 2016 at 10:28 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > This patch enables compilation with -flto. > > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears. > Performance changes in OpenGL games haven't been measured yet, my feeling is > that they are negligible. Without a compelling reason, I don't think the build system should be adding compiler flags like this. -flto makes debugging impossible, at least the last time I tried it with gcc. I don't think that's something we would want enabled whenever it's supported. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Mon, May 30, 2016 at 1:39 PM, Matt Turner wrote: > On Mon, May 30, 2016 at 10:28 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: >> This patch enables compilation with -flto. >> >> The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears. >> Performance changes in OpenGL games haven't been measured yet, my feeling is >> that they are negligible. > > Without a compelling reason, I don't think the build system should be > adding compiler flags like this. > > -flto makes debugging impossible, at least the last time I tried it > with gcc. I don't think that's something we would want enabled > whenever it's supported. It would be interesting to know what gains it brings in scenarios less synthetic than glxgears.. my suspicion is that we have been doing manual lto forever (ie. use of static-inline fxn's where it matters). If it turns out to be a significant gain, I wouldn't be against it. Although perhaps only for non-debug builds.. BR, -R > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On 07:28 PM - May 30 2016, ⚛ wrote: > This patch enables compilation with -flto. > > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears. > Performance changes in OpenGL games haven't been measured yet, my feeling > is that they are negligible. > diff --git a/configure.ac b/configure.ac > index fc0b1db..e84a1ad 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -362,6 +362,8 @@ if test "x$GXX" = xyes; then > CXXFLAGS="$CXXFLAGS -fno-builtin-memcmp" > fi > > +AX_CHECK_COMPILE_FLAG([-flto], AM_CONDITIONAL(COMPILER_UNDERSTANDS_LTO, > true), AM_CONDITIONAL(COMPILER_UNDERSTANDS_LTO, false)) > + > AC_SUBST([MSVC2013_COMPAT_CFLAGS]) > AC_SUBST([MSVC2013_COMPAT_CXXFLAGS]) > > diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am > index 68a28a2..4b7d266 100644 > --- a/src/mapi/Makefile.am > +++ b/src/mapi/Makefile.am > @@ -51,6 +51,11 @@ AM_CPPFLAGS = > \ > > include Makefile.sources > > +if COMPILER_UNDERSTANDS_LTO > +CFLAGS += -fno-lto > +CXXFLAGS += -fno-lto This should be `-flto` if I’m not mistaken. Pierre > +endif > + > MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D) > PYTHON_GEN = $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS) > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Mon, May 30, 2016 at 11:02 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > > On Mon, May 30, 2016 at 7:39 PM, Matt Turner wrote: >> >> On Mon, May 30, 2016 at 10:28 AM, <0xe2.0x9a.0...@gmail.com> wrote: >> > This patch enables compilation with -flto. >> > >> > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears. >> > Performance changes in OpenGL games haven't been measured yet, my feeling >> > is >> > that they are negligible. >> >> Without a compelling reason, I don't think the build system should be >> adding compiler flags like this. > > > What does it mean "like this". The patched build system only checks whether > -flto works because it needs to be disabled in mesa/src/mapi. > >> >> -flto makes debugging impossible, at least the last time I tried it >> with gcc. I don't think that's something we would want enabled >> whenever it's supported. > > > "Enable LTO compilation" means the person compiling Mesa can choose whether > to use -flto. Oh, I see. I misunderstood the patch initially. Because src/mapi cannot be compiled with -flto, this patch *disables* -flto in that directory if it is enabled. Interesting. (Please keep mesa-dev@ in Cc on your replies, and don't sent HTML mail) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Mon, May 30, 2016 at 8:07 PM, Pierre Moreau wrote: > On 07:28 PM - May 30 2016, ⚛ wrote: >> +if COMPILER_UNDERSTANDS_LTO >> +CFLAGS += -fno-lto >> +CXXFLAGS += -fno-lto > > This should be `-flto` if I’m not mistaken. > > Pierre -fno-lto is correct because GCC has issues compiling the assembler statements in C files in that directory. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
Ok, I found the answer to my question regarding the `-fno-lto`. IMHO that should be in the commit message, since the patch only checks for availability and disables LTO in one case, never enabling it explicitely. Please ignore my previous mail. Pierre On 11:06 AM - May 30 2016, Matt Turner wrote: > On Mon, May 30, 2016 at 11:02 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > > > > On Mon, May 30, 2016 at 7:39 PM, Matt Turner wrote: > >> > >> On Mon, May 30, 2016 at 10:28 AM, <0xe2.0x9a.0...@gmail.com> wrote: > >> > This patch enables compilation with -flto. > >> > > >> > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for > >> > glxgears. > >> > Performance changes in OpenGL games haven't been measured yet, my > >> > feeling is > >> > that they are negligible. > >> > >> Without a compelling reason, I don't think the build system should be > >> adding compiler flags like this. > > > > > > What does it mean "like this". The patched build system only checks whether > > -flto works because it needs to be disabled in mesa/src/mapi. > > > >> > >> -flto makes debugging impossible, at least the last time I tried it > >> with gcc. I don't think that's something we would want enabled > >> whenever it's supported. > > > > > > "Enable LTO compilation" means the person compiling Mesa can choose whether > > to use -flto. > > Oh, I see. I misunderstood the patch initially. > > Because src/mapi cannot be compiled with -flto, this patch *disables* > -flto in that directory if it is enabled. Interesting. > > (Please keep mesa-dev@ in Cc on your replies, and don't sent HTML mail) > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
Hi there, On 30 May 2016 at 18:28, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > This patch enables compilation with -flto. > > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears. > Performance changes in OpenGL games haven't been measured yet, my feeling is > that they are negligible. > Please try to send patches via git send-email for the future. While not a hard requirement, it would be nice if you setup your email client/git to show your name/nickname. It's always better to address someone directly, as opposed to "hey you". About the patch itself: - Please add a summary message for the change. Peter's has a nice article on the topic [1]. - We normally try to include performance metrics in the commit message. It makes it easier to justify said change. - Have you tried debugging the resulting binary ? As Matt mentioned there used to be issues with LTO, so if those are still unresolved we want to _avoid_ forcing that for everyone. - Are you use the mapi hunk is needed ? last time I've tried (some months ago, copying the tweaks from the Clearlinux spec file [2]) things built without issues. Thanks Emil [1] http://who-t.blogspot.co.uk/2009/12/on-commit-messages.html [2] https://download.clearlinux.org/releases/8470/clear/source/SRPMS/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Mon, May 30, 2016 at 12:27 PM, Emil Velikov wrote: > Hi there, > On 30 May 2016 at 18:28, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > > This patch enables compilation with -flto. > > > > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for > glxgears. > > Performance changes in OpenGL games haven't been measured yet, my > feeling is > > that they are negligible. > > > Please try to send patches via git send-email for the future. > > While not a hard requirement, it would be nice if you setup your email > client/git to show your name/nickname. > It's always better to address someone directly, as opposed to "hey you". > > About the patch itself: > - Please add a summary message for the change. Peter's has a nice > article on the topic [1]. > - We normally try to include performance metrics in the commit > message. It makes it easier to justify said change. > - Have you tried debugging the resulting binary ? As Matt mentioned > there used to be issues with LTO, so if those are still unresolved we > want to _avoid_ forcing that for everyone. > Regarding the above two comments: The patch he attached does not enable LTO, it just disables it for mapi so that *if* you put -flto in your CFLAGS, it doesn't blow up. If this patch were enabling LTO by default, questions about performance and debugability would be reasonable. However, given that the patch is purely protective, the only real question required to justify the patch is "is LTO actually a problem for mapi?" > - Are you use the mapi hunk is needed ? last time I've tried (some > months ago, copying the tweaks from the Clearlinux spec file [2]) > things built without issues. > You are claiming it isn't. That said, I tried to build with -flto recently and it blew up. I don't remember exactly why. > > Thanks > Emil > > [1] http://who-t.blogspot.co.uk/2009/12/on-commit-messages.html > [2] https://download.clearlinux.org/releases/8470/clear/source/SRPMS/ > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On 30 May 2016 at 21:10, Jason Ekstrand wrote: > On Mon, May 30, 2016 at 12:27 PM, Emil Velikov > wrote: > >> Hi there, >> On 30 May 2016 at 18:28, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: >> > This patch enables compilation with -flto. >> > >> > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for >> glxgears. >> > Performance changes in OpenGL games haven't been measured yet, my >> feeling is >> > that they are negligible. >> > >> Please try to send patches via git send-email for the future. >> >> While not a hard requirement, it would be nice if you setup your email >> client/git to show your name/nickname. >> It's always better to address someone directly, as opposed to "hey you". >> >> About the patch itself: >> - Please add a summary message for the change. Peter's has a nice >> article on the topic [1]. >> - We normally try to include performance metrics in the commit >> message. It makes it easier to justify said change. >> - Have you tried debugging the resulting binary ? As Matt mentioned >> there used to be issues with LTO, so if those are still unresolved we >> want to _avoid_ forcing that for everyone. >> > > Regarding the above two comments: The patch he attached does not enable > LTO, it just disables it for mapi so that *if* you put -flto in your > CFLAGS, it doesn't blow up. If this patch were enabling LTO by default, > questions about performance and debugability would be reasonable. However, > given that the patch is purely protective, the only real question required > to justify the patch is "is LTO actually a problem for mapi?" > > Seems like I'm the next person to fall trap of the commit message... that's embarrassing. Wrt the approach used... perhaps one should be checking for the same flag like they use ? It should still work though - just good practise. > - Are you use the mapi hunk is needed ? last time I've tried (some >> months ago, copying the tweaks from the Clearlinux spec file [2]) >> things built without issues. >> > > You are claiming it isn't. > > That said, I tried to build with -flto recently and it blew up. I don't > remember exactly why. > Do you (others) recall any details about how you enabled it (tweak *FLAGS, CC and/or other), if there was anything special in the configure options and/or which the GCC version ? I'll give it another try in a minute, just in case I butchered something. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On May 30, 2016 1:31 PM, "Emil Velikov" wrote: > > On 30 May 2016 at 21:10, Jason Ekstrand wrote: >> >> On Mon, May 30, 2016 at 12:27 PM, Emil Velikov wrote: >>> >>> Hi there, >>> On 30 May 2016 at 18:28, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: >>> > This patch enables compilation with -flto. >>> > >>> > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears. >>> > Performance changes in OpenGL games haven't been measured yet, my feeling is >>> > that they are negligible. >>> > >>> Please try to send patches via git send-email for the future. >>> >>> While not a hard requirement, it would be nice if you setup your email >>> client/git to show your name/nickname. >>> It's always better to address someone directly, as opposed to "hey you". >>> >>> About the patch itself: >>> - Please add a summary message for the change. Peter's has a nice >>> article on the topic [1]. >>> - We normally try to include performance metrics in the commit >>> message. It makes it easier to justify said change. >>> - Have you tried debugging the resulting binary ? As Matt mentioned >>> there used to be issues with LTO, so if those are still unresolved we >>> want to _avoid_ forcing that for everyone. >> >> >> Regarding the above two comments: The patch he attached does not enable LTO, it just disables it for mapi so that *if* you put -flto in your CFLAGS, it doesn't blow up. If this patch were enabling LTO by default, questions about performance and debugability would be reasonable. However, given that the patch is purely protective, the only real question required to justify the patch is "is LTO actually a problem for mapi?" >> > > Seems like I'm the next person to fall trap of the commit message... that's embarrassing. > > Wrt the approach used... perhaps one should be checking for the same flag like they use ? It should still work though - just good practise. > >>> >>> - Are you use the mapi hunk is needed ? last time I've tried (some >>> months ago, copying the tweaks from the Clearlinux spec file [2]) >>> things built without issues. >> >> >> You are claiming it isn't. >> >> That said, I tried to build with -flto recently and it blew up. I don't remember exactly why. > > Do you (others) recall any details about how you enabled it (tweak *FLAGS, CC and/or other), if there was anything special in the configure options and/or which the GCC version ? I just set it on CFLAGS, CXXFLAGS, and LFLAGS > I'll give it another try in a minute, just in case I butchered something. > > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
Hi, On 30.05.2016 20:57, Rob Clark wrote: On Mon, May 30, 2016 at 1:39 PM, Matt Turner wrote: On Mon, May 30, 2016 at 10:28 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: This patch enables compilation with -flto. The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears. Performance changes in OpenGL games haven't been measured yet, my feeling is that they are negligible. Without a compelling reason, I don't think the build system should be adding compiler flags like this. -flto makes debugging impossible, at least the last time I tried it with gcc. I don't think that's something we would want enabled whenever it's supported. It would be interesting to know what gains it brings in scenarios less synthetic than glxgears.. my suspicion is that we have been doing manual lto forever (ie. use of static-inline fxn's where it matters). If it turns out to be a significant gain, I wouldn't be against it. Although perhaps only for non-debug builds.. Martin did some testing with LTO last year for a real customer 3D benchmark that was partly CPU bound. In that case there were actually several percent performance improvements. How much, depends on: - How CPU bound the 3D benchmark is and do those CPU bottlenecks hit cases where LTO can actually help - What's the CPU/GPU balance on the given given HW (more visible on more CPU bound HW) - What GCC version is used (newer GCC versions provide more benefit with LTO) And it should not hurt performance (at least if one is using "performance" frequency policy, or fixed CPU frequency, instead of "powersave" one. "Powersave" can drop CPU frequency dramatically when use-case drop its CPU usage and large enough CPU freq drop can make things slower). - Eero ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
I've been using lto for the past several weeks not for performance reasons but to reduce the resulting binary size which has grown to be rather substantial. I usually set "-flto -ffat-lto-objects -flto-odr-type-merging" in the CFLAGS and CXXFLAGS env vars prior to configure and have yet to experience any problems with the files in mapi./ - Chuck On Tue, May 31, 2016 at 3:42 AM, Eero Tamminen wrote: > Hi, > > On 30.05.2016 20:57, Rob Clark wrote: > >> On Mon, May 30, 2016 at 1:39 PM, Matt Turner wrote: >> >>> On Mon, May 30, 2016 at 10:28 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: >>> This patch enables compilation with -flto. The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears. Performance changes in OpenGL games haven't been measured yet, my feeling is that they are negligible. >>> >>> Without a compelling reason, I don't think the build system should be >>> adding compiler flags like this. >>> >>> -flto makes debugging impossible, at least the last time I tried it >>> with gcc. I don't think that's something we would want enabled >>> whenever it's supported. >>> >> >> It would be interesting to know what gains it brings in scenarios less >> synthetic than glxgears.. my suspicion is that we have been doing >> manual lto forever (ie. use of static-inline fxn's where it matters). >> If it turns out to be a significant gain, I wouldn't be against it. >> Although perhaps only for non-debug builds.. >> > > Martin did some testing with LTO last year for a real customer 3D > benchmark that was partly CPU bound. In that case there were actually > several percent performance improvements. > > How much, depends on: > - How CPU bound the 3D benchmark is and do those CPU bottlenecks hit cases > where LTO can actually help > - What's the CPU/GPU balance on the given given HW > (more visible on more CPU bound HW) > - What GCC version is used > (newer GCC versions provide more benefit with LTO) > > And it should not hurt performance (at least if one is using "performance" > frequency policy, or fixed CPU frequency, instead of "powersave" one. > "Powersave" can drop CPU frequency dramatically when use-case drop its CPU > usage and large enough CPU freq drop can make things slower). > > > - Eero > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On 31 May 2016 at 15:34, Chuck Atkins wrote: > I've been using lto for the past several weeks not for performance reasons > but to reduce the resulting binary size which has grown to be rather > substantial. I usually set "-flto -ffat-lto-objects > -flto-odr-type-merging" in the CFLAGS and CXXFLAGS env vars prior to > configure and have yet to experience any problems with the files in mapi./ > > Thanks for the confirmation Chuck. It matches what I'm seeing when building using only "-flto". On the binary size topic - please make sure you include only the drivers that you need in --with-dri-drivers and --with-gallium-drivers. Otherwise you'll end up with 'megadrivers' (all the drivers in a single binary) with hardlinks for each driver instance. The latter is for backwards compatibility. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
I only build with swr and llvmpipe. I generally don't have use for the GPU
drivers so my configure line is typically:
--enable-opengl --disable-gles1 --disable-gles2
--disable-va --disable-gbm --disable-xvmc --disable-vdpau
--enable-shared-glapi
--disable-dri --with-dri-drivers=
--enable-gallium-llvm --enable-llvm-shared-libs
--with-gallium-drivers=swrast,swr
--disable-egl --disable-gbm --with-egl-platforms=
--enable-gallium-osmesa
--enable-glx
With gcc 5.3.1 I end up with lib{GL,OSMesa}.so @ 44M and libswrAVX{,2}.so @
70M. With flto turned on it drops WAY down to lib{GL,OSMesa}.so @ 13M and
libswrAVX{,2}.so @ 18M
- Chuck
On Tue, May 31, 2016 at 10:57 AM, Emil Velikov
wrote:
> On 31 May 2016 at 15:34, Chuck Atkins wrote:
>
>> I've been using lto for the past several weeks not for performance
>> reasons but to reduce the resulting binary size which has grown to be
>> rather substantial. I usually set "-flto -ffat-lto-objects
>> -flto-odr-type-merging" in the CFLAGS and CXXFLAGS env vars prior to
>> configure and have yet to experience any problems with the files in mapi./
>>
>> Thanks for the confirmation Chuck. It matches what I'm seeing when
> building using only "-flto".
>
> On the binary size topic - please make sure you include only the drivers
> that you need in --with-dri-drivers and --with-gallium-drivers. Otherwise
> you'll end up with 'megadrivers' (all the drivers in a single binary) with
> hardlinks for each driver instance. The latter is for backwards
> compatibility.
>
> -Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Mon, May 30, 2016 at 9:27 PM, Emil Velikov wrote: > - Are you use the mapi hunk is needed ? last time I've tried (some > months ago, copying the tweaks from the Clearlinux spec file [2]) > things built without issues. I tried Clearlinux today, but I failed to execute rpmbuild on the mesa.src.rpm file and didn't want to spend more time on the task. I am going to install Fedora (unless somebody has a better suggestion) in VirtualBox to see whether mesa.src.rpm can be compiled with -flto. I will try to report about the result tomorrow. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Tue, May 31, 2016 at 1:57 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > On Mon, May 30, 2016 at 9:27 PM, Emil Velikov > wrote: > > - Are you use the mapi hunk is needed ? last time I've tried (some > > months ago, copying the tweaks from the Clearlinux spec file [2]) > > things built without issues. > Agreed. I've been building on both Fedora and EL7 for the past few months with -flto and haven't seen any issues with the files in mapi. You reported that you get build failures with gcc for this though so what is your particular build environment that is failing and how is it failing? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Tue, May 31, 2016 at 8:04 PM, Chuck Atkins wrote: > Agreed. I've been building on both Fedora and EL7 for the past few months > with -flto and haven't seen any issues with the files in mapi. You reported > that you get build failures with gcc for this though so what is your > particular build environment that is failing and how is it failing? Build environment: Gentoo, GCC 4.9.3, binutils 2.25.1 The error message: make[5]: Entering directory 'build32/src/mapi' /bin/sh ../../libtool --tag=CC --mode=link ccache-gcc -pthread -Werror=pointer-arith -Werror=vla -g -Og -Wall -flto=4 -msse4 -ffat-lto-objects -fuse-linker-plugin -m32 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-math-errno -fno-trapping-math -fno-builtin-memcmp -no-undefined -Wl,--gc-sections -Wl,--no-undefined -o shared-glapi/libglapi.la -rpath install32/lib shared_glapi_libglapi_la-entry.lo shared_glapi_libglapi_la-mapi_glapi.lo shared_glapi_libglapi_la-stub.lo shared_glapi_libglapi_la-table.lo shared_glapi_libglapi_la-u_current.lo shared_glapi_libglapi_la-u_execmem.lo -lpthread libtool: link: ccache-gcc -shared -fPIC -DPIC .libs/shared_glapi_libglapi_la-entry.o .libs/shared_glapi_libglapi_la-mapi_glapi.o .libs/shared_glapi_libglapi_la-stub.o .libs/shared_glapi_libglapi_la-table.o .libs/shared_glapi_libglapi_la-u_current.o .libs/shared_glapi_libglapi_la-u_execmem.o -lpthread -pthread -g -Og -flto=4 -msse4 -fuse-linker-plugin -m32 -Wl,--gc-sections -Wl,--no-undefined -pthread -Wl,-soname -Wl,libglapi.so.0 -o shared-glapi/.libs/libglapi.so.0.0.0 /tmp/ccuX0CSJ.ltrans5.ltrans.o: In function `entry_patch_public': src/mapi/entry_x86_tls.h:87: undefined reference to `x86_current_tls' src/mapi/entry_x86_tls.h:89: undefined reference to `x86_entry_start' /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccuX0CSJ.ltrans5.ltrans.o: relocation R_386_GOTOFF against undefined symbol `x86_entry_start' can not be used when making a shared object /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Mon, May 30, 2016 at 3:31 PM, Emil Velikov wrote: > On 30 May 2016 at 21:10, Jason Ekstrand wrote: > >> On Mon, May 30, 2016 at 12:27 PM, Emil Velikov >> wrote: >> >>> Hi there, >>> On 30 May 2016 at 18:28, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: >>> > This patch enables compilation with -flto. >>> > >>> > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for >>> glxgears. >>> > Performance changes in OpenGL games haven't been measured yet, my >>> feeling is >>> > that they are negligible. >>> > >>> Please try to send patches via git send-email for the future. >>> >>> While not a hard requirement, it would be nice if you setup your email >>> client/git to show your name/nickname. >>> It's always better to address someone directly, as opposed to "hey you". >>> >>> About the patch itself: >>> - Please add a summary message for the change. Peter's has a nice >>> article on the topic [1]. >>> - We normally try to include performance metrics in the commit >>> message. It makes it easier to justify said change. >>> - Have you tried debugging the resulting binary ? As Matt mentioned >>> there used to be issues with LTO, so if those are still unresolved we >>> want to _avoid_ forcing that for everyone. >>> >> >> Regarding the above two comments: The patch he attached does not enable >> LTO, it just disables it for mapi so that *if* you put -flto in your >> CFLAGS, it doesn't blow up. If this patch were enabling LTO by default, >> questions about performance and debugability would be reasonable. However, >> given that the patch is purely protective, the only real question required >> to justify the patch is "is LTO actually a problem for mapi?" >> >> > Seems like I'm the next person to fall trap of the commit message... > that's embarrassing. > > Wrt the approach used... perhaps one should be checking for the same flag > like they use ? It should still work though - just good practise. > > >> - Are you use the mapi hunk is needed ? last time I've tried (some >>> months ago, copying the tweaks from the Clearlinux spec file [2]) >>> things built without issues. >>> >> >> You are claiming it isn't. >> >> That said, I tried to build with -flto recently and it blew up. I don't >> remember exactly why. >> > Do you (others) recall any details about how you enabled it (tweak *FLAGS, > CC and/or other), if there was anything special in the configure options > and/or which the GCC version ? > > I'll give it another try in a minute, just in case I butchered something. > My Build (for one machine): CXXFLAGS="-flto=8 -ffat-lto-objects -flto-odr-type-merging" CFLAGS="-flto=8 -ffat-lto-objects -flto-odr-type-merging" LD=ld LDFLAGS=" -flto=8" CC=gcc CXX=g++ /home/awatry/src/mesa/autogen.sh --with-dri-drivers=i965 --with-dri-driverdir=/usr/local/lib/dri/ --enable-debug --enable-glx-tls --enable-gles1 --enable-gles2 --enable-texture-float --with-gallium-drivers= With the mapi/LTO patch, build succeeds. Without it, I get the following: CCLD glapi/libglapi.la ar: `u' modifier ignored since `D' is the default (see `U') CCLD shared-glapi/libglapi.la /tmp/ccLynnFb.ltrans7.ltrans.o: In function `entry_get_public': /home/awatry/src/mesa/src/mapi/entry_x86-64_tls.h:63: undefined reference to `x86_64_entry_start' /usr/bin/ld: /tmp/ccLynnFb.ltrans7.ltrans.o: relocation R_X86_64_PC32 against undefined symbol `x86_64_entry_start' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value Given the header that it's failing in, I removed the --enable-glx-tls flag, and then things built successfully. --Aaron > > -Emil > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Tue, May 31, 2016 at 8:30 PM, Aaron Watry wrote: > > Given the header that it's failing in, I removed the --enable-glx-tls flag, > and then things built successfully. mesa.spec in http://download.clearlinux.org/releases/8490/clear/source/SRPMS/mesa-11.2.99.1-21.src.rpm seems to be using both -flto and --enable-glx-tls ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On 31/05/16 10:42, Eero Tamminen wrote: Hi, On 30.05.2016 20:57, Rob Clark wrote: On Mon, May 30, 2016 at 1:39 PM, Matt Turner wrote: On Mon, May 30, 2016 at 10:28 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: This patch enables compilation with -flto. The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears. Performance changes in OpenGL games haven't been measured yet, my feeling is that they are negligible. Without a compelling reason, I don't think the build system should be adding compiler flags like this. -flto makes debugging impossible, at least the last time I tried it with gcc. I don't think that's something we would want enabled whenever it's supported. It would be interesting to know what gains it brings in scenarios less synthetic than glxgears.. my suspicion is that we have been doing manual lto forever (ie. use of static-inline fxn's where it matters). If it turns out to be a significant gain, I wouldn't be against it. Although perhaps only for non-debug builds.. Martin did some testing with LTO last year for a real customer 3D benchmark that was partly CPU bound. In that case there were actually several percent performance improvements. Definitely was the case on some machines. However, I used GCC 5.X to get it to work reliably and one GCC 5 release was clearly improving the performance. I stopped making LTO builds because it took too long to compile when bisecting performance issues. I should try again now that gcc has "link-time parallelization (enabled using -flto=n)". If it scales with the number of threads, then linking mesa will not take 3 minutes anymore but ~45seconds or a normal quad core machine. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On 31/05/16 21:26, ⚛ wrote: On Tue, May 31, 2016 at 8:04 PM, Chuck Atkins wrote: Agreed. I've been building on both Fedora and EL7 for the past few months with -flto and haven't seen any issues with the files in mapi. You reported that you get build failures with gcc for this though so what is your particular build environment that is failing and how is it failing? Build environment: Gentoo, GCC 4.9.3, binutils 2.25.1 The error message: make[5]: Entering directory 'build32/src/mapi' /bin/sh ../../libtool --tag=CC --mode=link ccache-gcc -pthread -Werror=pointer-arith -Werror=vla -g -Og -Wall -flto=4 -msse4 -ffat-lto-objects -fuse-linker-plugin -m32 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-math-errno -fno-trapping-math -fno-builtin-memcmp -no-undefined -Wl,--gc-sections -Wl,--no-undefined -o shared-glapi/libglapi.la -rpath install32/lib shared_glapi_libglapi_la-entry.lo shared_glapi_libglapi_la-mapi_glapi.lo shared_glapi_libglapi_la-stub.lo shared_glapi_libglapi_la-table.lo shared_glapi_libglapi_la-u_current.lo shared_glapi_libglapi_la-u_execmem.lo -lpthread libtool: link: ccache-gcc -shared -fPIC -DPIC .libs/shared_glapi_libglapi_la-entry.o .libs/shared_glapi_libglapi_la-mapi_glapi.o .libs/shared_glapi_libglapi_la-stub.o .libs/shared_glapi_libglapi_la-table.o .libs/shared_glapi_libglapi_la-u_current.o .libs/shared_glapi_libglapi_la-u_execmem.o -lpthread -pthread -g -Og -flto=4 -msse4 -fuse-linker-plugin -m32 -Wl,--gc-sections -Wl,--no-undefined -pthread -Wl,-soname -Wl,libglapi.so.0 -o shared-glapi/.libs/libglapi.so.0.0.0 /tmp/ccuX0CSJ.ltrans5.ltrans.o: In function `entry_patch_public': src/mapi/entry_x86_tls.h:87: undefined reference to `x86_current_tls' src/mapi/entry_x86_tls.h:89: undefined reference to `x86_entry_start' /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccuX0CSJ.ltrans5.ltrans.o: relocation R_386_GOTOFF against undefined symbol `x86_entry_start' can not be used when making a shared object /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status I had issues until gcc 5.1 to get LTO to work with mesa. LTO is not as good on older versions of GCC anyway. What is stopping you from moving to GCC 6.1? Martin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On Tue, May 31, 2016 at 4:57 PM, Martin Peres wrote: > On 31/05/16 10:42, Eero Tamminen wrote: > >> Hi, >> >> On 30.05.2016 20:57, Rob Clark wrote: >> >>> On Mon, May 30, 2016 at 1:39 PM, Matt Turner wrote: >>> On Mon, May 30, 2016 at 10:28 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > This patch enables compilation with -flto. > > The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for > glxgears. > Performance changes in OpenGL games haven't been measured yet, my > feeling is > that they are negligible. > Without a compelling reason, I don't think the build system should be adding compiler flags like this. -flto makes debugging impossible, at least the last time I tried it with gcc. I don't think that's something we would want enabled whenever it's supported. >>> It would be interesting to know what gains it brings in scenarios less >>> synthetic than glxgears.. my suspicion is that we have been doing >>> manual lto forever (ie. use of static-inline fxn's where it matters). >>> If it turns out to be a significant gain, I wouldn't be against it. >>> Although perhaps only for non-debug builds.. >>> >> Martin did some testing with LTO last year for a real customer 3D >> benchmark that was partly CPU bound. In that case there were actually >> several percent performance improvements. >> > > Definitely was the case on some machines. However, I used GCC 5.X to get > it to work reliably and one GCC 5 release was clearly improving the > performance. > > I stopped making LTO builds because it took too long to compile when > bisecting performance issues. I should try again now that gcc has > "link-time parallelization (enabled using -flto=n)". If it scales with the > number of threads, then linking mesa will not take 3 minutes anymore but > ~45seconds or a normal quad core machine. > > I did some tests on my work laptop earlier today (i7 Haswell Quad Mobile), and my build time from no LTO to -flto=8 went from 3m18s to do autogen.sh with arguments && make -j8 check to about 3m45s. This is with the GCC 5.3.1 that comes stock with ubuntu xenial (16.04). The build overhead wasn't that bad, and the binary size reduction was pretty significant (35+MB to 17MB for i965_dri.so if memory serves). I haven't done benchmarks of the resulting executables yet, but I could if someone is interested in the results. --Aaron > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
On 01.06.2016 00:07, Chuck Atkins wrote:
>
> With gcc 5.3.1 I end up with lib{GL,OSMesa}.so @ 44M and
> libswrAVX{,2}.so @ 70M. With flto turned on it drops WAY down to
> lib{GL,OSMesa}.so @ 13M and libswrAVX{,2}.so @ 18M
I assume those numbers are including debugging symbols? How do stripped
binaries compare?
I'm asking because I heard that LTO negatively affects debugability, so
I wonder if the difference isn't mostly due to the debugging symbols.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
Hi, On 31.05.2016 21:43, ⚛ wrote: On Tue, May 31, 2016 at 8:30 PM, Aaron Watry wrote: Given the header that it's failing in, I removed the --enable-glx-tls flag, and then things built successfully. mesa.spec in http://download.clearlinux.org/releases/8490/clear/source/SRPMS/mesa-11.2.99.1-21.src.rpm seems to be using both -flto and --enable-glx-tls FYI: "--enable-glx-tls" is needed by Steam games: https://bugs.freedesktop.org/show_bug.cgi?id=72902#c26 - Eero ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
Am Mittwoch, 1. Juni 2016, 12:36:15 CEST schrieb Eero Tamminen: > Hi, > > On 31.05.2016 21:43, ⚛ wrote: > > On Tue, May 31, 2016 at 8:30 PM, Aaron Watry wrote: > >> Given the header that it's failing in, I removed the --enable-glx-tls > >> flag, and then things built successfully.> > > mesa.spec in > > http://download.clearlinux.org/releases/8490/clear/source/SRPMS/mesa-11.2 > > .99.1-21.src.rpm seems to be using both -flto and --enable-glx-tls > > FYI: "--enable-glx-tls" is needed by Steam games: > https://bugs.freedesktop.org/show_bug.cgi?id=72902#c26 I just tried LTO on openSUSE tumbleweed and it compiles fine *without* any patch applied using gcc 6.1.1 or gcc 5.3.1. AFAIK, older gcc version have rather poor LTO support. So is this patch needed at all? Marvin signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
>
> > With gcc 5.3.1 I end up with lib{GL,OSMesa}.so @ 44M and
> > libswrAVX{,2}.so @ 70M. With flto turned on it drops WAY down to
> > lib{GL,OSMesa}.so @ 13M and libswrAVX{,2}.so @ 18M
>
> I assume those numbers are including debugging symbols? How do stripped
> binaries compare?
>
Silly me, I didn't even consider that since I wasn't explicitly doing a
debug build. That being said, after explicitly stripping the binaries with
"strip -g", the resulting difference is negligible between the two (LTO vs
non-LTO).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Enable LTO compilation
Hello. The patch has moved to http://lists.freedesktop.org/archives/mesa-dev/2016-June/119257.html ( http://patchwork.freedesktop.org/series/8176/) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
