Bug 108135

Created attachment 141840 [details] [review]
Attempt at making the variables local static

The patch does solve the problem for the particular file, but there are more AVX uses in swrast_dri.so. The next issue is the intialisation of the builtin types in src/compiler/glsl_types.cpp, caused by:

#define DECL_TYPE(NAME, ...)                                    \
   const glsl_type glsl_type::_##NAME##_type = glsl_type(__VA_ARGS__, #NAME); \
   const glsl_type *const glsl_type::NAME##_type = &glsl_type::_##NAME##_type;

#define STRUCT_TYPE(NAME)

#include "compiler/builtin_type_macros.h"

(In reply to Thiago Macieira from comment #2)
> The patch does solve the problem for the particular file, but there are more
> AVX uses in swrast_dri.so. The next issue is the intialisation of the
> builtin types in src/compiler/glsl_types.cpp, caused by:

I believe that's a red herring. It's caused by our use of -flto in the build, meaning the use of AVX in one place "spills" to surrounding code that is otherwise innocent.

Without -flto, the next instruction to crash happens inside GlobalKnobs::GlobalKnobs(). I see this function (in fact, the entire gen_knobs.cpp file) present in at least two libraries: libmesaswr and libswrAVX. That is, both./src/gallium/drivers/swr/rasterizer/codegen/.libs/libmesaswr_la-gen_knobs.o and ./src/gallium/drivers/swr/rasterizer/codegen/.libs/libswrAVX_la-gen_knobs.o exist and contain this function. And BOTH files have AVX instructions. I can see the -mavx flag in the build.

Was this intended?

Hi Thiago,

Thanks for taking such a deep look into this. We probably shouldn't need to be specifically targeting a specific architecture in the jitter. We may be able to fix this by tweaking the build system.

Please note that Clear was affected by this GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87522. HJ is on it. It affects LTO.

However, there's still one load-time initialisation left even without LTO. That's a showstopper for all distributions: they simply can't turn SWR on. If we want SWR to be used, that needs to be solved.

I'm working on a different solution for Clear, but it won't apply to other Linux distributions.

This does point out an even more serious issue though:

Megadrivers interacts very badly with drivers that have global C++ initializers.  When dlopen'ing a DRI driver, C++ global constructors will run for ANY driver that is built in, even if that isn't the driver the user is trying to use.

In other words, let's say you're on a Raspberry Pi and are trying to use the vc4 driver.  If your distro happens to have built SWR, then you'll end up running a bunch of SWR C++ constructors...when trying to dlopen vc4_dri.so...because both live in the same .so file.

Such global initialization really ought to happen at driver screen init time, not dlopen time.  IMO we should forbid C++ global objects in Mesa drivers.  (We have a few in the compiler, but everybody uses the compiler.)  I don't know how feasible that is, though.  If it isn't, maybe we need to exclude such drivers from the megadrivers mechanism...

You can scan for .o that have initialisers by searching for .init_array sections

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/198.