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

[Emil Velikov]

On 11 July 2017 at 03:09, Tim Rowley <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
>
> Total          26360 Kb -> 17632 Kb
> ---
>  src/gallium/drivers/swr/Makefile.am     | 31 ++++++++++++++-----------------
>  src/gallium/drivers/swr/SConscript      | 26 +++++++++++++-------------
>  src/gallium/drivers/swr/swr_context.cpp |  2 +-
>  src/gallium/drivers/swr/swr_loader.cpp  | 14 ++++++--------
>  src/gallium/drivers/swr/swr_screen.h    |  2 ++
>  5 files changed, 36 insertions(+), 39 deletions(-)
>
> diff --git a/src/gallium/drivers/swr/Makefile.am b/src/gallium/drivers/swr/Makefile.am
> index 4b4bd37..7461228 100644
> --- a/src/gallium/drivers/swr/Makefile.am
> +++ b/src/gallium/drivers/swr/Makefile.am
> @@ -26,7 +26,14 @@ AM_CXXFLAGS = $(GALLIUM_DRIVER_CFLAGS) $(SWR_CXX11_CXXFLAGS)
>
>  noinst_LTLIBRARIES = libmesaswr.la
>
> -libmesaswr_la_SOURCES = $(LOADER_SOURCES)
> +# gen_knobs.* included here to provide driver access to swr configuration
> +libmesaswr_la_SOURCES = \
> +       $(CXX_SOURCES) \
> +       $(COMMON_CXX_SOURCES) \
> +       $(JITTER_CXX_SOURCES) \
> +       rasterizer/codegen/gen_knobs.cpp \
> +       rasterizer/codegen/gen_knobs.h \
> +       $(LOADER_SOURCES)
>
>  COMMON_CXXFLAGS = \
>         -fno-strict-aliasing \
> @@ -43,12 +50,15 @@ COMMON_CXXFLAGS = \
>         -I$(srcdir)/rasterizer/jitter \
>         -I$(srcdir)/rasterizer/archrast
>
> +# SWR_AVX_CXXFLAGS needed for intrinsic usage in swr api headers

Still seems strange to have the loader build for AVX, which will then
dive into a AVX or AVX2 only backend.
I'm pretty sure you guys will unwrap that out, once more the important
parts are sorted.

>From build POV, things look great.
Reviewed-by: Emil Velikov <emil.velikov at collabora.com>

Thanks
Emil