Re: [Mesa3d-dev] Mystery of u_format.csv
Marek Olšák wrote on 2009-12-22 08:40: > Hi, > > I noticed that gallium/auxiliary/util/u_format.csv contains some weird > swizzling, for example see this: > > $ grep zyxw u_format.csv > PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , > un8 , zyxw, rgb > PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , > un1 , zyxw, rgb > PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , > un4 , zyxw, rgb > PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , > sn8 , zyxw, rgb > PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 > , zyxw, srgb > > It's hard to believe that ARGB, ABGR, and BGRA have the same > swizzling. Let's continue our journey: > > $ grep A8R8G8B8 u_format.csv > PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , > un8 , zyxw, rgb > PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , > u8 , wxyz, srgb > > Same formats, different swizzling? Also: > > $ grep B8G8R8A8 u_format.csv > PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , > un8 , yzwx, rgb > PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , > u8 , zyxw, srgb > > Same formats, different swizzling? I don't really get it. And there's > much more cases like these. Could someone tell me what the intended > order of channels should be? (or possibly propose a fix) The meaning > of the whole table is self-contradictory and it's definitely the > source of some r300g bugs. > Marek, Yes, that seems like a defect. The format swizzle field tells us how to "swizzle" the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Thanks. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mystery of u_format.csv
The data in u_format.csv was migrated from p_format which was full of inconsistencies. I've fixed some of these but there are others which I haven't. Read the "pipe_format lookup table" thread of mesa3d-dev if you want to know the background. I'll add more documentation to u_format.h. The gist is source channels come in a vector ordered from least significant bit -> highest significant bit. Jose On Mon, 2009-12-21 at 23:40 -0800, Marek Olšák wrote: > Hi, > > I noticed that gallium/auxiliary/util/u_format.csv contains some weird > swizzling, for example see this: > > $ grep zyxw u_format.csv > PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , > un8 , zyxw, rgb > PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , > un1 , zyxw, rgb > PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , > un4 , zyxw, rgb > PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , > sn8 , zyxw, rgb > PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , > u8 , zyxw, srgb > > It's hard to believe that ARGB, ABGR, and BGRA have the same > swizzling. Let's continue our journey: > > $ grep A8R8G8B8 u_format.csv > PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , > un8 , zyxw, rgb > PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , > u8 , wxyz, srgb > > Same formats, different swizzling? Also: > > $ grep B8G8R8A8 u_format.csv > PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , > un8 , yzwx, rgb > PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , > u8 , zyxw, srgb > > Same formats, different swizzling? I don't really get it. And there's > much more cases like these. Could someone tell me what the intended > order of channels should be? (or possibly propose a fix) The meaning > of the whole table is self-contradictory and it's definitely the > source of some r300g bugs. > > Marek -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
On Mon, Dec 21, 2009 at 12:05:50PM -0700, tom fogal wrote: | Allen Akin writes: | > The only reliable way to solve the problem is to benchmark the | > operations you want to use, in precisely the conditions you intend | > to use them, and then make a judgement as to whether the performance | > is good enough. | | That's not nearly good enough either. Well, as far as I know it's the only existing technique that's guaranteed to work, so I wouldn't dismiss it too casually. I sympathize, though. I've been down this path and I know it isn't an easy one. | Rendering a 128^3 dataset in a 400x400 window (which is *tiny* for us) | on some Apple platforms (I think some Intels, older 10.5 with some ATI | cards) can take upwards of ten minutes, during which the application | is hung. ... So for your app, you can't afford to benchmark every time -- you have to do it once (during testing, at installation, or the first run after installation, for example) and save the results for later reuse. One good way to do this is to provide a separate "tuning" app or script that runs benchmarks and saves configuration information. Users can run it whenever they install/upgrade your app or their hardware. | ... On Linux systems with really old nvidia drivers, it crashes | the system. On Linux systems with old nvidia drivers, it crashes the | X server. On Linux systems with new nvidia drivers, a watchdog timer | kicks in after 4 seconds and the screen visibly blinks, corruption is | observed in other apps such as firefox, etc. Those are genuine problems, and I don't mean to minimize them, but they're outside the scope of the performance-characterization question. If the systems are that unstable, your app is going to have problems even when you're not benchmarking. | Further, drivers can do whatever they want on just about any GL call. | We recently added such a `benchmark' feature to our application, | choosing the LoD dynamically based on the time to render the previous | few frames. Many drivers will take, e.g. ~50ms for the majority of | frames, and then spike with e.g. a 300ms frame before dropping back | down to 50. Yes, that's one of the many problems that make performance "guarantees" less useful than you'd like. I don't know what's happening in the particular case you've described (maybe some time-consuming memory-management operation that's only triggered occasionally), but it's hard for me to see how you could boil down this sort of complex behavior into a caps bit that simply says "accelerated" or "not accelerated". | This `solution' is like asking app developers to benchmark JITted code; | there's far too much variability for it to actually work. ... Experience suggests that's not true in general. Nearly everyone tests their code on some number of systems and tunes it accordingly. What I'm suggesting is just formalizing that process a bit. Your case may be different, of course, but I don't know enough about it to speak to it directly. |... I would much | rather deal with a state explosion. Let's assume for the moment that you can come up with a good scheme for encoding the operations you want and the state that applies at the time the operations are executed (and this is by no means easy). Don't forget that you have to handle sequences of operations, and that execution order matters. You'll have to deal with typically tens of GL state variables that can materially affect the performance of each operation, and you'll also have to deal with behavior that's data-dependent (size limits, powers-of-two, etc.), and you'll also have to deal with state that's outside the GL (e.g. characteristics of the drawing surfaces that are determined by the window system). If you try to handle this as a straightforward database problem, I think you're talking billions of records. On the other hand, there may be only tens to hundreds of cases that are relevant to your app, and your benchmarks for checking them can be concise. This is a genuinely hard problem. The industry uses a mix of caps bits (or equivalent, like extension advertisements), minimum requirements for hardware, and pipeline "validation" schemes. As long as the underlying functionality keeps changing, no single one of these approaches will be ideal for long. At least performance-testing is robust. | > I haven't tracked this subject since I left the ARB, but maybe the | > Khronos folks have done some more work on it. | | What is the appropriate forum for this? I'm sorry, I don't know; I've been away from it for too long. One of the other folks here might be able to make a suggestion. If not, I'd check at opengl.org. | As I argue initially and above, since it is the only possibility at | this point, I'm going to argue strongly that extension advertisement | implies some sort of standard on performance. ... It was once (maybe still is) common policy that the presence of an exten
[Mesa3d-dev] [Bug 25654] glsl ifelse BranchTargets seem off
http://bugs.freedesktop.org/show_bug.cgi?id=25654 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Brian Paul 2009-12-22 13:25:51 PST --- OK, I've fixed this issue in Mesa/master, commit 428d81c8b78f5919b42debd9215c40d05a42cba0 Example: 27: IF TEMP[0].; # (if false, goto 29); 28:MOV OUTPUT[1], CONST[4]; 29: ELSE; # (goto 31) 30:MOV OUTPUT[1], CONST[5]; 31: ENDIF; -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Stop make entering/leaving directory messages ending up in mesa_version when autoconf is called from a makefile.
From 5f74bd9753a126808a149145548e09beea93bc49 Mon Sep 17 00:00:00 2001
Stops the following autoconf situation when it is called from within a
makefile, such as when packaging for distribution.
PACKAGE_VERSION='make2: Entering directory `/home/mentor/src/mesa'7.8.0make2:
Leaving directory `/home/mentor/src/mesa''
PACKAGE_STRING='Mesa make2: Entering directory
`/home/mentor/src/mesa'7.8.0make2: Leaving directory `/home/mentor/src/mesa''
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 743196a..5064b63 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4,7 +4,7 @@ AC_PREREQ([2.59])
dnl Versioning - scrape the version from configs/default
m4_define([mesa_version],
-[m4_esyscmd([${MAKE-make} -s -f bin/version.mk version | tr -d '\n'])])
+[m4_esyscmd([${MAKE-make} -s --no-print-directory -f bin/version.mk
version | tr -d '\n'])])
m4_ifval(mesa_version,,
[m4_fatal([Failed to get the Mesa version from `make -f bin/version.mk
version`])])
--
1.6.5
signature.asc
Description: This is a digitally signed message part
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Stop make entering/leaving directory messages ending up in mesa_version when autoconf is called from a makefile.
On Tue, Dec 22, 2009 at 2:30 PM, Matthew W. S. Bell
wrote:
> From 5f74bd9753a126808a149145548e09beea93bc49 Mon Sep 17 00:00:00 2001
>
> Stops the following autoconf situation when it is called from within a
> makefile, such as when packaging for distribution.
>
> PACKAGE_VERSION='make2: Entering directory `/home/mentor/src/mesa'7.8.0make2:
> Leaving directory `/home/mentor/src/mesa''
> PACKAGE_STRING='Mesa make2: Entering directory
> `/home/mentor/src/mesa'7.8.0make2: Leaving directory `/home/mentor/src/mesa''
>
> ---
> configure.ac | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 743196a..5064b63 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -4,7 +4,7 @@ AC_PREREQ([2.59])
>
> dnl Versioning - scrape the version from configs/default
> m4_define([mesa_version],
> - [m4_esyscmd([${MAKE-make} -s -f bin/version.mk version | tr -d '\n'])])
> + [m4_esyscmd([${MAKE-make} -s --no-print-directory -f bin/version.mk
> version | tr -d '\n'])])
> m4_ifval(mesa_version,,
> [m4_fatal([Failed to get the Mesa version from `make -f bin/version.mk
> version`])])
Weird.
Signed-off-by: Dan Nicholson
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
I am not very fond of the idea having another layer of function-call indirections and state management between a driver and a state tracker. I kinda succeed in making the failover driver work with some hacks and limitations (e.g. no textures). Even if I use it as a simple pass-through driver, it results in 40% performance drop in glxgears and 10% performance drop in progs/perf/draw_overhead. The driver overhead is a real issue here and it might be much higher with a full-blown fallback driver, and nobody wants the performance to suck so much. Also I'd like the applications which don't hit any fallback path to not be affected by this additional overhead, so putting a fallback driver on top of a real driver should be deferred if possible which makes this whole thing non-trivial. In the meantime I think we could lie that NPOTs are supported and implement only the functionality state trackers really want (2D textures with the repeat wrap mode and bilinear filtering done in the shader [0]). That would make all state trackers happy except the Mesa one, but doing software fallback instead would not make it happy either. We're talking about turning unavailable features to unusable ones, is it worth it? [0] I think I could do it if someone tells me how to easily replace TEX instructions with my own code in TGSI. Marek On Mon, Dec 21, 2009 at 6:57 PM, Jakob Bornecrantz wrote: > To be honest I'm way more in favor off doing 4 and/or with a env > variable to switch between incorrect rendering and software fallbacks, > but maybe we can do 3 but with another solution. > > At some point the Gallium interface was a expression of what hardware > could do not a interface to program against. Another guiding rule was > that it should be easy to write a pipe driver, putting all the hard > stuff in the state tracker. > > Now we are starting to see a lot of state trackers and its becoming > harder and harder to implement all the work around for the different > caps. Even tho the fallback/workaround code is in a module that can be > shared its still a pain to integrate and a lot of boiler plate code > needs to be written and maintained. > > Maybe we should revive the fallback module or make a another module > like it that takes care of all these shortcomings of the hardware. But > it is optional to the state tracker. That it is optional to the state > tracker is the big thing. > > So an usecase: > The mesa state tracker takes a look at the pipe caps of the r300 > driver and notices something bad no CAP_NPOT but CAP_TEXRECT. It then > wraps the pipe driver with the fallback pipe driver and uses that. And > all the NPOT badness is hidden from the state tracker. > > The code to switch between software and and hardwware rendering only > needs to be written once this includes the code to detect IF we should > switch to software and code to select between different modes of > handling of different type of errors, like FALLBACK_CONFORM, > FALLBACK_BAD_RENDERING. > > The good part with this is that the fallback module is optional and > for state trackers that can handle some of the possible shortcomings > or doesn't need all of the functionality don't need to wrap the pipe > driver. > > We get clean drivers, clean state tracker but a heap of code in the > fallback module... > > I could also see the blitter module getting sucked into the fallback > module. > > Comments please? > > Cheers Jakob. > > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Disable EGL if building static libraries.
On Mon, Dec 21, 2009 at 6:09 AM, Matthew W. S. Bell
wrote:
> On Sat, 2009-12-19 at 12:09 -0800, Dan Nicholson wrote:
>> This seems fine (except for the gratuitous newline introduced), but I
>> think someone submitted a patch the other day that makes the egl build
>> work static. Can you show where the build fails without this patch?
> It fails when it tries to build libEGL.so for target library in
> src/egl/main/Makefile with static (non-PIC) code. Can you find the patch
> so I can see if it fixes the problem?
I don't recall such patch. Does the attached one help?
It cleans up the build rule a little and should fix the issue.
From d1764079ee22f9a374aff329b38d4ed94af366cf Mon Sep 17 00:00:00 2001
From: Chia-I Wu
Date: Mon, 21 Dec 2009 11:13:18 +0800
Subject: [PATCH] egl: Clean up the Makefile rules.
This allows libEGL to be built as a static library and removes libX11
from the dependencies.
Signed-off-by: Chia-I Wu
---
configs/autoconf.in |3 +++
configs/default |5 -
configure.ac | 18 ++
src/egl/main/Makefile | 25 ++---
4 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/configs/autoconf.in b/configs/autoconf.in
index a7f3c9d..66dede4 100644
--- a/configs/autoconf.in
+++ b/configs/autoconf.in
@@ -52,6 +52,7 @@ GLU_LIB_NAME = @GLU_LIB_NAME@
GLUT_LIB_NAME = @GLUT_LIB_NAME@
GLW_LIB_NAME = @GLW_LIB_NAME@
OSMESA_LIB_NAME = @OSMESA_LIB_NAME@
+EGL_LIB_NAME = @EGL_LIB_NAME@
# Globs used to install the lib and all symlinks
GL_LIB_GLOB = @GL_LIB_GLOB@
@@ -59,12 +60,14 @@ GLU_LIB_GLOB = @GLU_LIB_GLOB@
GLUT_LIB_GLOB = @GLUT_LIB_GLOB@
GLW_LIB_GLOB = @GLW_LIB_GLOB@
OSMESA_LIB_GLOB = @OSMESA_LIB_GLOB@
+EGL_LIB_GLOB = @EGL_LIB_GLOB@
# Directories to build
LIB_DIR = @LIB_DIR@
SRC_DIRS = @SRC_DIRS@
GLU_DIRS = @GLU_DIRS@
DRIVER_DIRS = @DRIVER_DIRS@
+EGL_DRIVERS_DIRS = @EGL_DRIVERS_DIRS@
GALLIUM_DIRS = @GALLIUM_DIRS@
GALLIUM_AUXILIARY_DIRS = @GALLIUM_AUXILIARY_DIRS@
GALLIUM_DRIVERS_DIRS = @GALLIUM_DRIVERS_DIRS@
diff --git a/configs/default b/configs/default
index eb6123d..b7e511e 100644
--- a/configs/default
+++ b/configs/default
@@ -55,6 +55,7 @@ GLUT_LIB = glut
GLEW_LIB = GLEW
GLW_LIB = GLw
OSMESA_LIB = OSMesa
+EGL_LIB = EGL
# Library names (actual file names)
@@ -64,6 +65,7 @@ GLUT_LIB_NAME = lib$(GLUT_LIB).so
GLEW_LIB_NAME = lib$(GLEW_LIB).a
GLW_LIB_NAME = lib$(GLW_LIB).so
OSMESA_LIB_NAME = lib$(OSMESA_LIB).so
+EGL_LIB_NAME = lib$(EGL_LIB).so
# globs used to install the lib and all symlinks
GL_LIB_GLOB = $(GL_LIB_NAME)*
@@ -71,6 +73,7 @@ GLU_LIB_GLOB = $(GLU_LIB_NAME)*
GLUT_LIB_GLOB = $(GLUT_LIB_NAME)*
GLW_LIB_GLOB = $(GLW_LIB_NAME)*
OSMESA_LIB_GLOB = $(OSMESA_LIB_NAME)*
+EGL_LIB_GLOB = $(EGL_LIB_NAME)*
# Optional assembly language optimization files for libGL
MESA_ASM_SOURCES =
@@ -89,7 +92,7 @@ DRIVER_DIRS = x11 osmesa
# Which subdirs under $(TOP)/progs/ to enter:
PROGRAM_DIRS = demos redbook samples glsl objviewer xdemos
-# EGL directories
+# EGL drivers to build
EGL_DRIVERS_DIRS = demo
# Gallium directories and
diff --git a/configure.ac b/configure.ac
index 6fa0a60..9ad1d60 100644
--- a/configure.ac
+++ b/configure.ac
@@ -242,24 +242,28 @@ GLU_LIB_NAME='lib$(GLU_LIB).'${LIB_EXTENSION}
GLUT_LIB_NAME='lib$(GLUT_LIB).'${LIB_EXTENSION}
GLW_LIB_NAME='lib$(GLW_LIB).'${LIB_EXTENSION}
OSMESA_LIB_NAME='lib$(OSMESA_LIB).'${LIB_EXTENSION}
+EGL_LIB_NAME='lib$(EGL_LIB).'${LIB_EXTENSION}
GL_LIB_GLOB='lib$(GL_LIB).*'${LIB_EXTENSION}'*'
GLU_LIB_GLOB='lib$(GLU_LIB).*'${LIB_EXTENSION}'*'
GLUT_LIB_GLOB='lib$(GLUT_LIB).*'${LIB_EXTENSION}'*'
GLW_LIB_GLOB='lib$(GLW_LIB).*'${LIB_EXTENSION}'*'
OSMESA_LIB_GLOB='lib$(OSMESA_LIB).*'${LIB_EXTENSION}'*'
+EGL_LIB_GLOB='lib$(EGL_LIB).*'${LIB_EXTENSION}'*'
AC_SUBST([GL_LIB_NAME])
AC_SUBST([GLU_LIB_NAME])
AC_SUBST([GLUT_LIB_NAME])
AC_SUBST([GLW_LIB_NAME])
AC_SUBST([OSMESA_LIB_NAME])
+AC_SUBST([EGL_LIB_NAME])
AC_SUBST([GL_LIB_GLOB])
AC_SUBST([GLU_LIB_GLOB])
AC_SUBST([GLUT_LIB_GLOB])
AC_SUBST([GLW_LIB_GLOB])
AC_SUBST([OSMESA_LIB_GLOB])
+AC_SUBST([EGL_LIB_GLOB])
dnl
dnl Arch/platform-specific settings
@@ -887,17 +891,15 @@ AC_ARG_ENABLE([egl],
[enable_egl=yes])
if test "x$enable_egl" = xyes; then
SRC_DIRS="$SRC_DIRS egl"
-
-if test "$x11_pkgconfig" = yes; then
-PKG_CHECK_MODULES([EGL], [x11])
-EGL_LIB_DEPS="$EGL_LIBS"
-else
-# should check these...
-EGL_LIB_DEPS="$X_LIBS -lX11"
+EGL_LIB_DEPS="$DLOPEN_LIBS -lpthread"
+EGL_DRIVERS_DIRS=""
+if test "$enable_static" != yes && test "$mesa_driver" != osmesa; then
+# build egl_glx when libGL is built
+EGL_DRIVERS_DIRS="glx"
fi
-EGL_LIB_DEPS="$EGL_LIB_DEPS $DLOPEN_LIBS"
fi
AC_SUBST([EGL_LIB_DEPS])
+AC_SUBST([EGL_DRIVERS_DIRS])
dnl
dnl GLU configuration
diff --git a/src/egl/main/Makefile b/src/egl/main/Makefile
index c951b07..ec326a8 100644
--- a/src/egl/main/Makefile
+++ b/src/egl/main/Makefile
@@ -4
Re: [Mesa3d-dev] [PATCH] Disable EGL if building static libraries.
On Tue, Dec 22, 2009 at 6:56 PM, Chia-I Wu wrote: > On Mon, Dec 21, 2009 at 6:09 AM, Matthew W. S. Bell > wrote: >> On Sat, 2009-12-19 at 12:09 -0800, Dan Nicholson wrote: >>> This seems fine (except for the gratuitous newline introduced), but I >>> think someone submitted a patch the other day that makes the egl build >>> work static. Can you show where the build fails without this patch? >> It fails when it tries to build libEGL.so for target library in >> src/egl/main/Makefile with static (non-PIC) code. Can you find the patch >> so I can see if it fixes the problem? > I don't recall such patch. Does the attached one help? > > It cleans up the build rule a little and should fix the issue. I didn't test, but that looks good. I trust you know more about the library dependencies than anyone at this point. :) Reviewed-by: Dan Nicholson -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
