swr: allow a single swr architecture to be builtin
authorChuck Atkins <chuck.atkins@kitware.com>
Thu, 18 Jan 2018 19:57:58 +0000 (14:57 -0500)
committerGeorge Kyriazis <george.kyriazis@intel.com>
Fri, 19 Jan 2018 19:16:00 +0000 (13:16 -0600)
commita4be2bcee2f344b864ed133ddde3dac7a266cab8
tree8306d375dabc4b1e55511734b20da19eba6fb823
parent2ed8b6f82704081a8992b3c30995ac8873b0c711
swr: allow a single swr architecture to be builtin

Part 2 of 2 (part 1 is autoconf changes, part 2 is C++ changes)

When only a single SWR architecture is being used, this allows that
architecture to be builtin rather than as a separate libswrARCH.so that
gets loaded via dlopen.  Since there are now several different code
paths for each detected CPU architecture, the log output is also
adjusted to convey where the backend is getting loaded from.

This allows SWR to be used for static mesa builds which are still
important for large HPC environments where shared libraries can impose
unacceptable application startup times as hundreds of thousands of copies
of the libs are loaded from a shared parallel filesystem.

Based on an initial implementation by Tim Rowley.

v2: Refactor repetitive preprocessor checks to reduce code duplication
v3: Formatting changes per Bruce C. Also delay screen creation until end
    to avoid leaks when failure conditions are hit.

Signed-off-by: Chuck Atkins <chuck.atkins@kitware.com>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
CC: Tim Rowley <timothy.o.rowley@intel.com>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
src/gallium/drivers/swr/swr_loader.cpp