[Mesa-dev] [PATCH 2/2] swr: build driver proper separate from rasterizer

Rowley, Timothy O timothy.o.rowley at intel.com
Mon Jul 10 16:53:42 UTC 2017


On Jul 10, 2017, at 8:24 AM, Emil Velikov <emil.l.velikov at gmail.com<mailto:emil.l.velikov at gmail.com>> wrote:

Hi Tim,

On 7 July 2017 at 22:25, Tim Rowley <timothy.o.rowley at intel.com<mailto:timothy.o.rowley at intel.com>> wrote:
swr used to build and link the rasterizer to the driver, and to support
multiple architectures we needed to have multiple versions of the
driver/rasterizer combination, which needed to link in much of mesa.

Changing to having one instance of the driver and just building
architecture specific versions of the rasterizer gives a large reduction
in disk space.

libGL.so        6464 Kb ->  7000 Kb
libswrAVX.so   10068 Kb ->  5432 Kb
libswrAVX2.so   9828 Kb ->  5200 Kb

If one considers the other binaries which include libmesaswr.la<http://libmesaswr.la/>
(swr_dri.so, osmesa, etc) savings might be a bit smaller ;-)
Regardless, thank you for working on this.

I do have an ulterior motive in mind for reducing our footprint - there’s a couple follow-up patches to come, one of which will make the swr architectures we build configurable, and another which will add a KNL architecture (disabled by default).


Total          26360 Kb -> 17632 Kb
---
src/gallium/drivers/swr/Makefile.am     | 24 +++++++++++++-----------
src/gallium/drivers/swr/swr_context.cpp |  2 +-
src/gallium/drivers/swr/swr_loader.cpp  | 14 ++++++--------
src/gallium/drivers/swr/swr_screen.h    |  2 ++
4 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/swr/Makefile.am b/src/gallium/drivers/swr/Makefile.am
index 4b4bd37..e764e0d 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -26,7 +26,13 @@ AM_CXXFLAGS = $(GALLIUM_DRIVER_CFLAGS) $(SWR_CXX11_CXXFLAGS)

noinst_LTLIBRARIES = libmesaswr.la<http://libmesaswr.la>

-libmesaswr_la_SOURCES = $(LOADER_SOURCES)
+libmesaswr_la_SOURCES = \

+       $(COMMON_CXX_SOURCES) \
+       rasterizer/codegen/gen_knobs.cpp \
+       rasterizer/codegen/gen_knobs.h \
These three now seems to be duplicated across the frontend and
AVX/AVX2 backends. Is that intentional?
Worth adding a note?

Yes, that was intentional - our driver looks at a handful of knobs (primarily the hardcoded ones in knobs.h, but also one out of gen_knobs.h).  Adding a knob query to the api table didn’t really fit the rest of the api, so I decided to take the small hit of duplication.  That does mean the driver can no longer override knobs for the core, which is why a previous patch moved the tuning of the frontend draw split from the driver to the core.

+libmesaswr_la_CXXFLAGS = \
+       $(SWR_AVX_CXXFLAGS) \
+       -DKNOB_ARCH=KNOB_ARCH_AVX \
With his KNOB, the frontend will be build for AVX. What about AVX2?

This is an artifact of api.h including state.h, which contains both api-exposed state structures and internal ones which depend on the simd size.  The former are simd-size safe, but as our intrinsics layer is included we need to specify some architecture to allow a compile.  I chose the lowest common denominator architecture in case some simd-using helper function got called.  I’ll look into splitting state.h into internal/external in a future commit.

-COMMON_LIBADD = \
-       $(top_builddir)/src/gallium/auxiliary/libgallium.la<http://libgallium.la/> \
-       $(top_builddir)/src/mesa/libmesagallium.la<http://libmesagallium.la/> \
-       $(LLVM_LIBS)
-
With this gone libswrAVX{,2}_la_LIBADD become empty, so we can drop them.

Will remove.


Can you check that configure --with-gallium-drivers=swr
--enable-gallium-osmesa --disable-dri --enable-glx=gallium-xlib build
fine (needs a second run dropping the latter two options). I cannot
spot anything obvious - just a gut feeling. You might want to sort the
SCons build as well?


gallium-xlib is the configuration we normally build and test with.  A dri version builds, but I don’t have a machine that I can actually run it on.

SCons - the build system I keep forgetting.  Working on getting this updated and tested for v2 of the patch.

-Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170710/761a7079/attachment-0001.html>


More information about the mesa-dev mailing list