[Mesa-dev] [PATCH v3 1/2] configure.ac: Enable GLX_USE_TLS if possible.
Zhigang Gong
zhigang.gong at linux.intel.com
Wed Feb 15 16:57:22 PST 2012
> -----Original Message-----
> From: tf (mobile) [mailto:tfogal at sci.utah.edu]
> Sent: Wednesday, February 15, 2012 8:53 PM
> To: zhigang.gong at linux.intel.com
> Cc: dbn.lists at gmail.com; nobled at dreamwidth.org;
> mesa-dev at lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v3 1/2] configure.ac: Enable GLX_USE_TLS
> if possible.
>
> Even if the system supports tls, the x server may not have been built with
it.
> As i recall, there is an issue with mismatching tls between x and
drivers...
> Can a non-tls server load a tls driver?
AFAIK, a mesa built without TLS can work with a xserver built with TLS
enabled,
Actually, this is current situation. Xserver will enable TLS if the system
support
It, but mesa will not enable TLS by default no matter the system support it.
IMO, the only relevant part may be the indirect GLX in xserver which will
load
DRI driver and thus mesa. But xserver has its own glapi.c and will not share
the mesa's glapi.c, then the mismatch will not be a big issue. If I missed
anything,
please correct me.
Anyway, I still think it's better to keep the xserver and mesa have the same
configuration
when they are built/running on the same system. Right?
Besides that issue, I think mesa should check whether the system support
TLS and tls model before enable it. So I still want this patchset get
accepted.
Any comment?
>
> Anyway, if there's an issue there, this check must be more complicated --
it
> can't be just, "does the system support this", it would instead need to
be
> "can the system support this and is it enabled in the x server."
>
> IIRC Eric and ajax and Dan know more, but there should also be a
> discussion of this in the xorg-devel and/or mesa archives.
>
> -tom
>
> On 15.02.2012, at 12:41, zhigang.gong at linux.intel.com wrote:
>
> > From: Zhigang Gong <zhigang.gong at linux.intel.com>
> >
> > If the system support tls, we prefer to enable it by default just as
> > xserver does. Actually, the checking code is copied from
> > xserver/configure.ac.
> > According to nobled's suggestion, move the checking before
> enable_asm.
> > As if tls_model is not supported, then asm may can't work correctly.
> > Then we check the tls model first, and if doesn't support it, we need
> > to disable the asm code.
> > Here is the reference:
> > https://bugs.freedesktop.org/show_bug.cgi?id=35268
> >
> > Signed-off-by: Zhigang Gong <zhigang.gong at linux.intel.com>
> > Reviewed-by: Dan Nicholson <dbn.lists at gmail.com>
> > ---
> > acinclude.m4 | 41
> +++++++++++++++++++++++++++++++++++++++++
> > configure.ac | 25 ++++++++++++++++++++++---
> > 2 files changed, 63 insertions(+), 3 deletions(-)
> >
> > diff --git a/acinclude.m4 b/acinclude.m4 index a5b389d..23805f3
> 100644
> > --- a/acinclude.m4
> > +++ b/acinclude.m4
> > @@ -117,3 +117,44 @@ if test "$enable_pic" != no; then fi
> > AC_SUBST([PIC_FLAGS])
> > ])# MESA_PIC_FLAGS
> > +
> > +dnl TLS detection
> > +AC_DEFUN([MESA_TLS],
> > +[AC_MSG_CHECKING(for thread local storage (TLS) support)
> > +AC_CACHE_VAL(ac_cv_tls, [
> > + ac_cv_tls=none
> > + keywords="__thread __declspec(thread)"
> > + for kw in $keywords ; do
> > + AC_TRY_COMPILE([int $kw test;], [], ac_cv_tls=$kw)
> > + done
> > +])
> > +AC_MSG_RESULT($ac_cv_tls)
> > +
> > +if test "$ac_cv_tls" != "none"; then
> > + STRICT_CFLAGS="-pedantic -Werror"
> > + # Add -Werror=attributes if supported (gcc 4.2 & later)
> > + AC_MSG_CHECKING([if $CC supports -Werror=attributes])
> > + save_CFLAGS="$CFLAGS"
> > + CFLAGS="$CFLAGS $STRICT_CFLAGS -Werror=attributes"
> > + AC_TRY_COMPILE([int test;], [],
> > + [STRICT_CFLAGS="$STRICT_CFLAGS
> -Werror=attributes"
> > + AC_MSG_RESULT([yes])],
> > + [AC_MSG_RESULT([no])])
> > + CFLAGS="$save_CFLAGS $STRICT_CFLAGS"
> > +
> > + AC_MSG_CHECKING(for tls_model attribute support)
> > + AC_CACHE_VAL(ac_cv_tls_model, [
> > + AC_TRY_COMPILE([int $ac_cv_tls
> __attribute__((tls_model("initial-exec"))) test;], [],
> > + ac_cv_tls_model=yes, ac_cv_tls_model=no)
> > + ])
> > + AC_MSG_RESULT($ac_cv_tls_model)
> > +
> > + if test "x$ac_cv_tls_model" = "xyes" ; then
> > + TLS=$ac_cv_tls' __attribute__((tls_model(\"initial-exec\")))'
> > + else
> > + TLS=$ac_cv_tls
> > + fi
> > + DEFINES="$DEFINES -DTLS=\"$TLS\""
> > + CFLAGS="$save_CFLAGS"
> > +fi
> > +])
> > diff --git a/configure.ac b/configure.ac index b2b1ab8..3226a09 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -433,6 +433,11 @@ AC_SUBST([VG_LIB_GLOB])
> > AC_SUBST([GLAPI_LIB_GLOB])
> >
> > dnl
> > +dnl Check tls model support
> > +dnl
> > +MESA_TLS
> > +
> > +dnl
> > dnl Arch/platform-specific settings
> > dnl
> > AC_ARG_ENABLE([asm],
> > @@ -446,6 +451,14 @@ ASM_FLAGS=""
> > MESA_ASM_SOURCES=""
> > GLAPI_ASM_SOURCES=""
> > AC_MSG_CHECKING([whether to enable assembly])
> > +
> > +if test "x$ac_cv_tls_model" = "xno" ; then dnl dnl If tls model is
> > +not supported, disable asm.
> > +dnl
> > + enable_asm=no
> > +fi
> > +
> > test "x$enable_asm" = xno && AC_MSG_RESULT([no]) # disable if cross
> > compiling on x86/x86_64 since we must run gen_matypes if test
> > "x$enable_asm" = xyes && test "x$cross_compiling" = xyes; then @@
> > -1102,9 +1115,15 @@ dnl
> >
> > AC_ARG_ENABLE([glx-tls],
> > [AS_HELP_STRING([--enable-glx-tls],
> > - [enable TLS support in GLX @<:@default=disabled@:>@])],
> > - [GLX_USE_TLS="$enableval"],
> > - [GLX_USE_TLS=no])
> > + [enable TLS support in GLX @<:@default=auto@:>@])],
> > + [GLX_USE_TLS=$enableval
> > + if test "x$GLX_USE_TLS" = "xyes" && test "${ac_cv_tls}" = "none" ;
> then
> > + AC_MSG_ERROR([GLX with TLS support requested, but the
> compiler does not support it.])
> > + fi],
> > + [GLX_USE_TLS=no
> > + if test "${ac_cv_tls}" != "none" ; then
> > + GLX_USE_TLS=yes
> > + fi])
> > AC_SUBST(GLX_TLS, ${GLX_USE_TLS})
> >
> > AS_IF([test "x$GLX_USE_TLS" = xyes],
> > --
> > 1.7.4.4
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list