[Mesa-dev] [PATCH 0/3] Only require libdrm if direct rendering is actually enabled
On 29/10/2010 06:58, Chia-I Wu wrote: > While the patch works great for better > config options and at reducing the compile time, it does not avoid > unnecessary PKG_CHECK_MODULES. But I think that belongs to follow-on > works. Tangentially related to that, here's a few patches (combining patches from bugs #27840 and #29460 and updating for git master) which avoid requiring LIBDRM and DRI2PROTO when configured --with-driver=dri --disable-driglx-direct (which makes it possible to build like that on platforms with no LIBDRM) Jon TURNEY (1): Disable direct rendering on Cygwin Samuel Thibault (1): Only require libdrm if direct rendering is actually enabled. nobled (1): Disable direct rendering on GNU/Hurd configure.ac | 52 +--- 1 files changed, 41 insertions(+), 11 deletions(-) -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] Only require libdrm if direct rendering is actually enabled.
From: Samuel Thibault
Fix build when configured --with-driver=dri --disable-driglx-direct on GNU/Hurd
and Cygwin
Based on the Debian patch file '05_hurd-ftbfs.diff' by Samuel Thibault.
Signed-off-by: Jon TURNEY
---
configure.ac | 29 ++---
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/configure.ac b/configure.ac
index 860ea21..3c3da14 100644
--- a/configure.ac
+++ b/configure.ac
@@ -687,6 +687,14 @@ else
enable_xcb=no
fi
+dnl Direct rendering or just indirect rendering
+AC_ARG_ENABLE([driglx-direct],
+[AS_HELP_STRING([--disable-driglx-direct],
+[enable direct rendering in GLX and EGL for DRI \
+@<:@default=enabled@:>@])],
+[driglx_direct="$enableval"],
+[driglx_direct="yes"])
+
dnl
dnl libGL configuration per driver
dnl
@@ -720,12 +728,17 @@ dri|no) # these checks are still desired when there is no
mesa_driver
AC_MSG_ERROR([Can't use static libraries for DRI drivers])
fi
-# Check for libdrm
-PKG_CHECK_MODULES([LIBDRM], [libdrm >= $LIBDRM_REQUIRED])
-PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
PKG_CHECK_MODULES([GLPROTO], [glproto >= $GLPROTO_REQUIRED])
-GL_PC_REQ_PRIV="libdrm >= $LIBDRM_REQUIRED dri2proto >=
$DRI2PROTO_REQUIRED glproto >= $GLPROTO_REQUIRED"
-DRI_PC_REQ_PRIV="libdrm >= $LIBDRM_REQUIRED"
+GL_PC_REQ_PRIV="glproto >= $GLPROTO_REQUIRED"
+DRI_PC_REQ_PRIV=""
+
+if test x"$driglx_direct" = xyes; then
+# Check for libdrm
+PKG_CHECK_MODULES([LIBDRM], [libdrm >= $LIBDRM_REQUIRED])
+PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
+GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED dri2proto
>= $DRI2PROTO_REQUIRED"
+DRI_PC_REQ_PRIV="libdrm >= $LIBDRM_REQUIRED"
+fi
# find the DRI deps for libGL
if test "$x11_pkgconfig" = yes; then
@@ -822,12 +835,6 @@ AC_ARG_WITH([dri-searchpath],
[DRI_DRIVER_SEARCH_DIR="$withval"],
[DRI_DRIVER_SEARCH_DIR='${DRI_DRIVER_INSTALL_DIR}'])
AC_SUBST([DRI_DRIVER_SEARCH_DIR])
-dnl Direct rendering or just indirect rendering
-AC_ARG_ENABLE([driglx-direct],
-[AS_HELP_STRING([--disable-driglx-direct],
-[enable direct rendering in GLX and EGL for DRI
@<:@default=enabled@:>@])],
-[driglx_direct="$enableval"],
-[driglx_direct="yes"])
dnl Which drivers to build - default is chosen by platform
AC_ARG_WITH([dri-drivers],
[AS_HELP_STRING([--with-dri-drivers@<:@=DIRS...@:>@],
--
1.7.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] Disable direct rendering on GNU/Hurd
From: nobled The Hurd kernel doesn't have DRM yet. Signed-off-by: Jon TURNEY --- configure.ac | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 3c3da14..af70a7b 100644 --- a/configure.ac +++ b/configure.ac @@ -688,12 +688,21 @@ else fi dnl Direct rendering or just indirect rendering +case "$host_os" in +gnu*) +dnl Disable by default on GNU/Hurd +driglx_direct_default="no" +;; +*) +driglx_direct_default="yes" +;; +esac AC_ARG_ENABLE([driglx-direct], [AS_HELP_STRING([--disable-driglx-direct], [enable direct rendering in GLX and EGL for DRI \ -@<:@default=enabled@:>@])], +@<:@default=auto@:>@])], [driglx_direct="$enableval"], -[driglx_direct="yes"]) +[driglx_direct="$driglx_direct_default"]) dnl dnl libGL configuration per driver -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] Disable direct rendering on Cygwin
Add Cygwin platform-specific settings and drivers to build for dri driver: - by default, disable direct rendering. - if direct rendering is enabled, the swrast dridriver is the only one it's sensible to try to build (this doesn't work at the moment as additional patches are required to build a libGL which can load just swrast without the DRM headers, even though there's no actual functional dependency) Signed-off-by: Jon TURNEY --- configure.ac | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index af70a7b..30b3bf5 100644 --- a/configure.ac +++ b/configure.ac @@ -693,6 +693,10 @@ gnu*) dnl Disable by default on GNU/Hurd driglx_direct_default="no" ;; +cygwin*) +dnl Disable by default on cygwin +driglx_direct_default="no" +;; *) driglx_direct_default="yes" ;; @@ -942,6 +946,16 @@ if test "$mesa_driver" = dri -o "$mesa_driver" = no; then DEFINES="$DEFINES -DGLX_DIRECT_RENDERING" fi ;; +cygwin*) +DEFINES="$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER" +DEFINES="$DEFINES -DGLX_INDIRECT_RENDERING" +if test "x$driglx_direct" = xyes; then +DEFINES="$DEFINES -DGLX_DIRECT_RENDERING" +fi +if test "x$DRI_DIRS" = "xyes"; then +DRI_DIRS="swrast" +fi +;; esac # default drivers -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31225] New: State tracker vega fails to compile
https://bugs.freedesktop.org/show_bug.cgi?id=31225 Summary: State tracker vega fails to compile Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: martinsto...@gmail.com When I try to compile mesa with the vega state tracker enabled I get the following error: In file included from api.c:31:0: api.h:39:29: fatal error: vgapi/vgapi_tmp.h: No such file or directory compilation terminated. make[4]: *** [api.o] Error 1 make[4]: Leaving directory `/home/martin/abs/2_xorg/4_-_mesa-full/src/mesa-build/src/gallium/state_trackers/vega' make[3]: *** [subdirs] Error 1 make[3]: Leaving directory `/home/martin/abs/2_xorg/4_-_mesa-full/src/mesa-build/src/gallium/state_trackers' make[2]: *** [default] Error 1 make[2]: Leaving directory `/home/martin/abs/2_xorg/4_-_mesa-full/src/mesa-build/src/gallium' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/martin/abs/2_xorg/4_-_mesa-full/src/mesa-build/src' make: *** [default] Error 1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gl.h, gl2.h, gallium: use stdbool.h for GLboolean and boolean
On Wed, Oct 13, 2010 at 9:05 PM, Brian Paul wrote: > On 10/13/2010 12:26 PM, Nicolas Kaiser wrote: >> >> This patch adds support for the compiler built-in Boolean type >> to GLboolean and the "boolean" type in gallium >> by bringing them in line with the "bool" type in stdbool.h. >> >> Signed-off-by: Nicolas Kaiser > > Every GL/gl.h file I've seen over the years defines GLboolean as-is. > It seems a bit risky (and unnecessary) to me to change it. Erm... using C99 |bool| from can lead to significant performance improvements and code size reduction if there are lots of bools/branches in your code because the compiler no longer has to guess whether the variable may be used as boolean or not, it simply can treat it as one even in low optimisation levels (and it helps in cases when code spans more than one object file because not all compilers do things like Sun's interprocedural optimiser (e.g. which optimises and inlines across all source files in one step)). This was the primary reason why Solaris got a (e.g. that kernel code can use C99 |bool| ; see OpenSolaris PSARC/2009/429, http://mail.opensolaris.org/pipermail/opensolaris-arc/2009-August/017277.html &co. for the discussion) and why we are working on doing this on other larger pieces of code like AT&T AST codebase (which contains stuff like libast and ksh93). Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gl.h, gl2.h, gallium: use stdbool.h for GLboolean and boolean
On Sat, Oct 30, 2010 at 8:13 AM, Roland Mainz wrote: > On Wed, Oct 13, 2010 at 9:05 PM, Brian Paul wrote: >> On 10/13/2010 12:26 PM, Nicolas Kaiser wrote: >>> >>> This patch adds support for the compiler built-in Boolean type >>> to GLboolean and the "boolean" type in gallium >>> by bringing them in line with the "bool" type in stdbool.h. >>> >>> Signed-off-by: Nicolas Kaiser >> >> Every GL/gl.h file I've seen over the years defines GLboolean as-is. >> It seems a bit risky (and unnecessary) to me to change it. > > Erm... using C99 |bool| from can lead to significant > performance improvements and code size reduction if there are lots of > bools/branches in your code because the compiler no longer has to > guess whether the variable may be used as boolean or not, it simply > can treat it as one even in low optimisation levels (and it helps in > cases when code spans more than one object file because not all > compilers do things like Sun's interprocedural optimiser (e.g. which > optimises and inlines across all source files in one step)). The main problem we redefining something like GLboolean is it maybe an ABI change, the C99 bool AFAIK isn't == unsigned char, and it may affect the function signatures to starting using it in these places. Internally in mesa I'm less concerened. Dave. > This was the primary reason why Solaris got a (e.g. > that kernel code can use C99 |bool| ; see OpenSolaris PSARC/2009/429, > http://mail.opensolaris.org/pipermail/opensolaris-arc/2009-August/017277.html > &co. for the discussion) and why we are working on doing this on other > larger pieces of code like AT&T AST codebase (which contains stuff > like libast and ksh93). > > > > Bye, > Roland > > -- > __ . . __ > (o.\ \/ /.o) roland.ma...@nrubsig.org > \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer > /O /==\ O\ TEL +49 641 3992797 > (;O/ \/ \O;) > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31225] State tracker vega fails to compile
https://bugs.freedesktop.org/show_bug.cgi?id=31225 --- Comment #1 from Chia-I Wu 2010-10-29 23:57:17 PDT --- 156e955c25ad should fix the issue. Please try again. But please consider adding --enable-openvg to your configure script. There have been some changes to configure.ac. Eventually, --with-state-trackers=vega without --enable-openvg should be considered an error. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
