date:20100822

[Mesa-dev] [PATCHES] clang compatibility

2010-08-22 Thread nobled

The first three attached patches make it possible to compile Mesa with
LLVM/Clang:
1. Add -lstdc++ when linking glsl_compiler and glcpp
2. Move -lstdc++ from the Gallium-specific Makefile.dri to
DRI_LIB_DEPS in configure (fixes linking classic Mesa drivers)
3. Since autoconf gives GCC=yes even when using clang (since it just
tests for the __GNUC__ macro), don't check for a minimum version of
3.3 if $(CC) points to a clang executable. (unfortunately I'm not sure
how to properly detect clang, short of test-compiling a file that
contains #ifdef __clang__. I.e. if $(CC) = 'cc', and 'cc' is an
alternatives symlink to llvm-clang, this doesn't detect that case.)

The rest are just fixes to compiler warnings:
4. dri: Fix implicit declaration
5. program: Fix struct/class confusion
6. dr/radeon: Fix printf format
7. llvmpipe: Fix memory leak

With the first three patches, I can compile Mesa with clang 2.7 in
Ubuntu Lucid if I export three variables before configure:
export CC=llvm-clang
export CXX=llvm-clang
export CPPFLAGS=/usr/lib/clang/1.1/include
./configure
(Yeah, the third one is really prone to breakage with new versions and
I'm still trying to figure out how to not need it; it should also get
passed as part of MKDEP_OPTIONS in configure.ac, TBH.)
From 5bd1fd451f459ceede759877d06a846fcc27f29f Mon Sep 17 00:00:00 2001
From: nobled 
Date: Sun, 22 Aug 2010 04:37:28 +
Subject: [PATCH] glsl: Add -lstdc++ linkage

Fixes "undefined reference to `__gxx_personality_v0'" error
when linking with a non-g++ compiler (e.g. llvm-clang).
---
 src/glsl/Makefile|3 ++-
 src/glsl/Makefile.am |2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/glsl/Makefile b/src/glsl/Makefile
index 1d200b4..64016d2 100644
--- a/src/glsl/Makefile
+++ b/src/glsl/Makefile
@@ -75,7 +75,8 @@ CXX_SOURCES = \
 
 LIBS = \
 	$(TOP)/src/glsl/libglsl.a \
-	$(shell pkg-config --libs talloc)
+	$(shell pkg-config --libs talloc) \
+	-lstdc++
 
 APPS = glsl_compiler glcpp/glcpp
 
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 5728a8b..a683598 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -28,7 +28,7 @@ SUBDIRS = glcpp
 bin_PROGRAMS = glsl
 
 glsl_LDADD = ./glcpp/libglcpp.la
-glsl_LDFLAGS = @LDFLAGS@ $(talloc_LIBS)
+glsl_LDFLAGS = @LDFLAGS@ $(talloc_LIBS) -lstdc++
 glsl_SOURCES = \
 	main.cpp \
 	builtin_types.h \
-- 
1.5.4.3

From ebeb533110e8d0a9afd716c058a9e99024d124cc Mon Sep 17 00:00:00 2001
From: nobled 
Date: Sun, 22 Aug 2010 04:37:53 +
Subject: [PATCH] Move -lstdc++ to DRI_LIB_DEPS

Fixes "undefined reference to `operator new[](unsigned int)'"
error when linking classic drivers with a non-g++ compiler
(e.g. llvm-clang).
---
 configure.ac |3 ++-
 src/gallium/targets/Makefile.dri |2 --
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 3d86dec..c319c1e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -855,7 +855,8 @@ if test "$mesa_driver" = dri; then
 [AC_MSG_ERROR([Expat required for DRI.])])
 
 # put all the necessary libs together
-DRI_LIB_DEPS="$SELINUX_LIBS $LIBDRM_LIBS $EXPAT_LIB -lm -lpthread $DLOPEN_LIBS $TALLOC_LIBS"
+DRI_LIB_DEPS="$SELINUX_LIBS $LIBDRM_LIBS $EXPAT_LIB -lm -lpthread \
+$DLOPEN_LIBS $TALLOC_LIBS -lstdc++"
 fi
 AC_SUBST([DRI_DIRS])
 AC_SUBST([EXPAT_INCLUDES])
diff --git a/src/gallium/targets/Makefile.dri b/src/gallium/targets/Makefile.dri
index 59961e9..d487481 100644
--- a/src/gallium/targets/Makefile.dri
+++ b/src/gallium/targets/Makefile.dri
@@ -5,8 +5,6 @@ ifeq ($(MESA_LLVM),1)
 PIPE_DRIVERS += $(TOP)/src/gallium/drivers/llvmpipe/libllvmpipe.a
 LDFLAGS += $(LLVM_LDFLAGS)
 DRIVER_EXTRAS = $(LLVM_LIBS)
-else
-LDFLAGS += -lstdc++
 endif
 
 MESA_MODULES = \
-- 
1.5.4.3

From dd4a3298e7594edb835731afef57de13838d9a98 Mon Sep 17 00:00:00 2001
From: nobled 
Date: Sun, 22 Aug 2010 06:42:32 +
Subject: [PATCH] Make configure work with clang

It was mistaking clang for gcc and deciding its version
was too low.
---
 configure.ac |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index c319c1e..e6ba34b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -48,9 +48,20 @@ solaris*)
 ;;
 esac
 
+dnl This is to hack around the GCC=yes false positive with clang,
+dnl since it's mostly GCC-compatible, but its version is much lower.
+case "$CC" in
+*clang*)
+CLANG=yes
+;;
+*)
+CLANG=no
+;;
+esac
+
 dnl If we're using GCC, make sure that it is at least version 3.3.0.  Older
 dnl versions are explictly not supported.
-if test "x$GCC" = xyes; then
+if test "x$GCC" = xyes -a "x$CLANG" = xno; then
 AC_MSG_CHECKING([whether gcc version is sufficient])
 major=0
 minor=0
-- 
1.5.4.3

From 375788bcdd310abd0a5f2c03858750028ddb02b4 Mon Sep 17 00:00:00 2001
From: nobled 
Date: Sun, 22 Aug 2010 05:15:30 +
Subject: [PATCH] dri: Fix 'implicit declaration'

Fixes "warning: implicit declaration

[Mesa-dev] [Bug 29684] [glsl] wine shaders break with mesa GLSL

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29684

--- Comment #10 from Marc  2010-08-22 08:26:47 PDT ---
mmh - still broken here, but works when "UseGLSL = disabled" in wine.

-- 
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

[Mesa-dev] [Bug 29684] [glsl] wine shaders break with mesa GLSL

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29684

--- Comment #11 from Marc  2010-08-22 08:28:46 PDT ---
Created an attachment (id=38060)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38060)
output with MESA_GLSL=dump

-- 
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

[Mesa-dev] [Bug 29684] [glsl] wine shaders break with mesa GLSL

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29684

Marc  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
 CC||marvi...@gmx.de

-- 
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

[Mesa-dev] [PATCH 1/3] targets/egl: rename pipe_radeon to pipe_r300

2010-08-22 Thread Benjamin Franzke

st/egl/x11/x11_screen.c requests a driver named r300 not radeon

KNOWN ISSUE: breaks st/egl/kms/
st/egl/kms requests a pipe named "radeon"
that will not be found now

so why not leaving pipe_radeon there?
that was possible as long we have only r300g.
now there is also r600g for which st/egl/kms also
requests a pipe named "radeon"
(possible solution in later commit)
---
 src/gallium/targets/egl/Makefile  |   14 +++---
 src/gallium/targets/egl/pipe_r300.c   |   27 +++
 src/gallium/targets/egl/pipe_radeon.c |   27 ---
 3 files changed, 34 insertions(+), 34 deletions(-)
 create mode 100644 src/gallium/targets/egl/pipe_r300.c
 delete mode 100644 src/gallium/targets/egl/pipe_radeon.c

diff --git a/src/gallium/targets/egl/Makefile b/src/gallium/targets/egl/Makefile
index 1585e2d..636fceb 100644
--- a/src/gallium/targets/egl/Makefile
+++ b/src/gallium/targets/egl/Makefile
@@ -90,10 +90,10 @@ nouveau_LIBS := \
$(TOP)/src/gallium/drivers/nv50/libnv50.a \
$(TOP)/src/gallium/drivers/nouveau/libnouveau.a
 
-# radeon pipe driver
-radeon_CPPFLAGS :=
-radeon_SYS := -ldrm -ldrm_radeon
-radeon_LIBS := \
+# r300 pipe driver
+r300_CPPFLAGS :=
+r300_SYS := -ldrm -ldrm_radeon
+r300_LIBS := \
$(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
$(TOP)/src/gallium/drivers/r300/libr300.a
 
@@ -151,7 +151,7 @@ ifneq ($(findstring nouveau/drm,$(GALLIUM_WINSYS_DIRS)),)
 OUTPUTS += nouveau
 endif
 ifneq ($(findstring radeon/drm,$(GALLIUM_WINSYS_DIRS)),)
-OUTPUTS += radeon
+OUTPUTS += r300
 endif
 ifneq ($(findstring svga/drm,$(GALLIUM_WINSYS_DIRS)),)
 OUTPUTS += vmwgfx
@@ -188,8 +188,8 @@ $(OUTPUT_PATH)/$(PIPE_PREFIX)i965.so: pipe_i965.o 
$(i965_LIBS)
 $(OUTPUT_PATH)/$(PIPE_PREFIX)nouveau.so: pipe_nouveau.o $(nouveau_LIBS)
$(call mklib,nouveau)
 
-$(OUTPUT_PATH)/$(PIPE_PREFIX)radeon.so: pipe_radeon.o $(radeon_LIBS)
-   $(call mklib,radeon)
+$(OUTPUT_PATH)/$(PIPE_PREFIX)r300.so: pipe_r300.o $(r300_LIBS)
+   $(call mklib,r300)
 
 $(OUTPUT_PATH)/$(PIPE_PREFIX)vmwgfx.so: pipe_vmwgfx.o $(vmwgfx_LIBS)
$(call mklib,vmwgfx)
diff --git a/src/gallium/targets/egl/pipe_r300.c 
b/src/gallium/targets/egl/pipe_r300.c
new file mode 100644
index 000..2fa495e
--- /dev/null
+++ b/src/gallium/targets/egl/pipe_r300.c
@@ -0,0 +1,27 @@
+
+#include "target-helpers/inline_debug_helper.h"
+#include "state_tracker/drm_driver.h"
+#include "radeon/drm/radeon_drm_public.h"
+#include "r300/r300_public.h"
+
+static struct pipe_screen *
+create_screen(int fd)
+{
+   struct r300_winsys_screen *sws;
+   struct pipe_screen *screen;
+
+   sws = r300_drm_winsys_screen_create(fd);
+   if (!sws)
+  return NULL;
+
+   screen = r300_screen_create(sws);
+   if (!screen)
+  return NULL;
+
+   screen = debug_screen_wrap(screen);
+
+   return screen;
+}
+
+PUBLIC
+DRM_DRIVER_DESCRIPTOR("r300", "r300", create_screen)
diff --git a/src/gallium/targets/egl/pipe_radeon.c 
b/src/gallium/targets/egl/pipe_radeon.c
deleted file mode 100644
index 35550bc..000
--- a/src/gallium/targets/egl/pipe_radeon.c
+++ /dev/null
@@ -1,27 +0,0 @@
-
-#include "target-helpers/inline_debug_helper.h"
-#include "state_tracker/drm_driver.h"
-#include "radeon/drm/radeon_drm_public.h"
-#include "r300/r300_public.h"
-
-static struct pipe_screen *
-create_screen(int fd)
-{
-   struct r300_winsys_screen *sws;
-   struct pipe_screen *screen;
-
-   sws = r300_drm_winsys_screen_create(fd);
-   if (!sws)
-  return NULL;
-
-   screen = r300_screen_create(sws);
-   if (!screen)
-  return NULL;
-
-   screen = debug_screen_wrap(screen);
-
-   return screen;
-}
-
-PUBLIC
-DRM_DRIVER_DESCRIPTOR("radeon", "radeon", create_screen)
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] targets/egl: add passthrough pipe pipe_radeon

2010-08-22 Thread Benjamin Franzke

load pipe_r300 or pipe_r600 depending on the chip_id

needed for st/egl/kms which requests a "radeon" pipe
for both: r300 and r600 cards
---
 src/gallium/targets/egl/Makefile  |   15 ++-
 src/gallium/targets/egl/pipe_radeon.c |   24 
 2 files changed, 38 insertions(+), 1 deletions(-)
 create mode 100644 src/gallium/targets/egl/pipe_radeon.c

diff --git a/src/gallium/targets/egl/Makefile b/src/gallium/targets/egl/Makefile
index 636fceb..625c1be 100644
--- a/src/gallium/targets/egl/Makefile
+++ b/src/gallium/targets/egl/Makefile
@@ -97,6 +97,16 @@ r300_LIBS := \
$(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
$(TOP)/src/gallium/drivers/r300/libr300.a
 
+# radeon pipe driver (r300 + r600)
+radeon_CPPFLAGS := \
+   -I$(TOP)/src/gallium/state_trackers/egl \
+   -I$(TOP)/src/egl/main \
+   $(LIBDRM_CFLAGS)
+radeon_SYS := $(LIBDRM_LIB)
+radeon_LIBS := \
+   egl.o \
+   $(TOP)/src/gallium/state_trackers/egl/libegl.a
+
 # vmwgfx pipe driver
 vmwgfx_CPPFLAGS :=
 vmwgfx_SYS :=
@@ -151,7 +161,7 @@ ifneq ($(findstring nouveau/drm,$(GALLIUM_WINSYS_DIRS)),)
 OUTPUTS += nouveau
 endif
 ifneq ($(findstring radeon/drm,$(GALLIUM_WINSYS_DIRS)),)
-OUTPUTS += r300
+OUTPUTS += r300 radeon
 endif
 ifneq ($(findstring svga/drm,$(GALLIUM_WINSYS_DIRS)),)
 OUTPUTS += vmwgfx
@@ -191,6 +201,9 @@ $(OUTPUT_PATH)/$(PIPE_PREFIX)nouveau.so: pipe_nouveau.o 
$(nouveau_LIBS)
 $(OUTPUT_PATH)/$(PIPE_PREFIX)r300.so: pipe_r300.o $(r300_LIBS)
$(call mklib,r300)
 
+$(OUTPUT_PATH)/$(PIPE_PREFIX)radeon.so: pipe_radeon.o $(radeon_LIBS)
+   $(call mklib,radeon)
+
 $(OUTPUT_PATH)/$(PIPE_PREFIX)vmwgfx.so: pipe_vmwgfx.o $(vmwgfx_LIBS)
$(call mklib,vmwgfx)
 
diff --git a/src/gallium/targets/egl/pipe_radeon.c 
b/src/gallium/targets/egl/pipe_radeon.c
new file mode 100644
index 000..6b802de
--- /dev/null
+++ b/src/gallium/targets/egl/pipe_radeon.c
@@ -0,0 +1,24 @@
+#include 
+#include 
+
+#include "egldriver.h"
+#include "common/egl_g3d.h"
+
+#include "radeon/drm/radeon_drm.h"
+
+static struct pipe_screen *
+create_screen(int fd)
+{
+   int chip_id;
+
+   struct drm_radeon_info info = { .value = (unsigned long) &chip_id };
+
+   if (drmCommandWriteRead(fd, DRM_RADEON_INFO, &info, sizeof(info)) != 0)
+  return NULL;
+
+   return egl_g3d_driver(_eglMain(NULL))->loader->create_drm_screen(
+is_r3xx(chip_id) ? "r300" : "r600", fd);
+}
+
+PUBLIC
+DRM_DRIVER_DESCRIPTOR("radeon", "radeon", create_screen)
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] targets/egl: add pipe_r600

2010-08-22 Thread Benjamin Franzke

KNOWN ISSUE: eglShowScreenSurfaceMESA in st/egl/kms fails
but st/egl/x11 works
---
 src/gallium/targets/egl/Makefile|   13 +
 src/gallium/targets/egl/pipe_r600.c |   27 +++
 2 files changed, 40 insertions(+), 0 deletions(-)
 create mode 100644 src/gallium/targets/egl/pipe_r600.c

diff --git a/src/gallium/targets/egl/Makefile b/src/gallium/targets/egl/Makefile
index 625c1be..1452c59 100644
--- a/src/gallium/targets/egl/Makefile
+++ b/src/gallium/targets/egl/Makefile
@@ -97,6 +97,13 @@ r300_LIBS := \
$(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
$(TOP)/src/gallium/drivers/r300/libr300.a
 
+# r600 pipe driver
+r600_CPPFLAGS :=
+r600_SYS := -ldrm -ldrm_radeon
+r600_LIBS := \
+   $(TOP)/src/gallium/winsys/r600/drm/libr600winsys.a \
+   $(TOP)/src/gallium/drivers/r600/libr600.a
+
 # radeon pipe driver (r300 + r600)
 radeon_CPPFLAGS := \
-I$(TOP)/src/gallium/state_trackers/egl \
@@ -163,6 +170,9 @@ endif
 ifneq ($(findstring radeon/drm,$(GALLIUM_WINSYS_DIRS)),)
 OUTPUTS += r300 radeon
 endif
+ifneq ($(findstring r600/drm,$(GALLIUM_WINSYS_DIRS)),)
+OUTPUTS += r600 radeon
+endif
 ifneq ($(findstring svga/drm,$(GALLIUM_WINSYS_DIRS)),)
 OUTPUTS += vmwgfx
 endif
@@ -201,6 +211,9 @@ $(OUTPUT_PATH)/$(PIPE_PREFIX)nouveau.so: pipe_nouveau.o 
$(nouveau_LIBS)
 $(OUTPUT_PATH)/$(PIPE_PREFIX)r300.so: pipe_r300.o $(r300_LIBS)
$(call mklib,r300)
 
+$(OUTPUT_PATH)/$(PIPE_PREFIX)r600.so: pipe_r600.o $(r600_LIBS)
+   $(call mklib,r600)
+
 $(OUTPUT_PATH)/$(PIPE_PREFIX)radeon.so: pipe_radeon.o $(radeon_LIBS)
$(call mklib,radeon)
 
diff --git a/src/gallium/targets/egl/pipe_r600.c 
b/src/gallium/targets/egl/pipe_r600.c
new file mode 100644
index 000..c35a0b0
--- /dev/null
+++ b/src/gallium/targets/egl/pipe_r600.c
@@ -0,0 +1,27 @@
+
+#include "state_tracker/drm_driver.h"
+#include "target-helpers/inline_debug_helper.h"
+#include "r600/drm/r600_drm_public.h"
+#include "r600/r600_public.h"
+
+static struct pipe_screen *
+create_screen(int fd)
+{
+   struct radeon *rw;
+   struct pipe_screen *screen;
+
+   rw = r600_drm_winsys_create(fd);
+   if (!rw)
+  return NULL;
+
+   screen = r600_screen_create(rw);
+   if (!screen)
+  return NULL;
+
+   screen = debug_screen_wrap(screen);
+
+   return screen;
+}
+
+PUBLIC
+DRM_DRIVER_DESCRIPTOR("r600", "r600", create_screen)
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29684] [glsl] wine shaders break with mesa GLSL

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29684

--- Comment #12 from Rubén Fernández  2010-08-22 09:41:32 
PDT ---
(In reply to comment #10)
> mmh - still broken here, but works when "UseGLSL = disabled" in wine.

Your output log indicates no compilation errors - which means that this
particular bug is fixed. I know there are still GLSL bugs in wine, but I think
they should be reported as separate bugs, as I'll do soon.

-- 
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 1/3] targets/egl: rename pipe_radeon to pipe_r300

2010-08-22 Thread Corbin Simpson

On Sun, Aug 22, 2010 at 9:24 AM, Benjamin Franzke
 wrote:
> st/egl/x11/x11_screen.c requests a driver named r300 not radeon
>
> KNOWN ISSUE: breaks st/egl/kms/
>        st/egl/kms requests a pipe named "radeon"
>        that will not be found now
>
>        so why not leaving pipe_radeon there?
>        that was possible as long we have only r300g.
>        now there is also r600g for which st/egl/kms also
>        requests a pipe named "radeon"
>        (possible solution in later commit)
> ---
>  src/gallium/targets/egl/Makefile      |   14 +++---
>  src/gallium/targets/egl/pipe_r300.c   |   27 +++
>  src/gallium/targets/egl/pipe_radeon.c |   27 ---
>  3 files changed, 34 insertions(+), 34 deletions(-)
>  create mode 100644 src/gallium/targets/egl/pipe_r300.c
>  delete mode 100644 src/gallium/targets/egl/pipe_radeon.c
>
> diff --git a/src/gallium/targets/egl/Makefile 
> b/src/gallium/targets/egl/Makefile
> index 1585e2d..636fceb 100644
> --- a/src/gallium/targets/egl/Makefile
> +++ b/src/gallium/targets/egl/Makefile
> @@ -90,10 +90,10 @@ nouveau_LIBS := \
>        $(TOP)/src/gallium/drivers/nv50/libnv50.a \
>        $(TOP)/src/gallium/drivers/nouveau/libnouveau.a
>
> -# radeon pipe driver
> -radeon_CPPFLAGS :=
> -radeon_SYS := -ldrm -ldrm_radeon
> -radeon_LIBS := \
> +# r300 pipe driver
> +r300_CPPFLAGS :=
> +r300_SYS := -ldrm -ldrm_radeon
> +r300_LIBS := \
>        $(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
>        $(TOP)/src/gallium/drivers/r300/libr300.a
>
> @@ -151,7 +151,7 @@ ifneq ($(findstring nouveau/drm,$(GALLIUM_WINSYS_DIRS)),)
>  OUTPUTS += nouveau
>  endif
>  ifneq ($(findstring radeon/drm,$(GALLIUM_WINSYS_DIRS)),)
> -OUTPUTS += radeon
> +OUTPUTS += r300
>  endif
>  ifneq ($(findstring svga/drm,$(GALLIUM_WINSYS_DIRS)),)
>  OUTPUTS += vmwgfx
> @@ -188,8 +188,8 @@ $(OUTPUT_PATH)/$(PIPE_PREFIX)i965.so: pipe_i965.o 
> $(i965_LIBS)
>  $(OUTPUT_PATH)/$(PIPE_PREFIX)nouveau.so: pipe_nouveau.o $(nouveau_LIBS)
>        $(call mklib,nouveau)
>
> -$(OUTPUT_PATH)/$(PIPE_PREFIX)radeon.so: pipe_radeon.o $(radeon_LIBS)
> -       $(call mklib,radeon)
> +$(OUTPUT_PATH)/$(PIPE_PREFIX)r300.so: pipe_r300.o $(r300_LIBS)
> +       $(call mklib,r300)
>
>  $(OUTPUT_PATH)/$(PIPE_PREFIX)vmwgfx.so: pipe_vmwgfx.o $(vmwgfx_LIBS)
>        $(call mklib,vmwgfx)
> diff --git a/src/gallium/targets/egl/pipe_r300.c 
> b/src/gallium/targets/egl/pipe_r300.c
> new file mode 100644
> index 000..2fa495e
> --- /dev/null
> +++ b/src/gallium/targets/egl/pipe_r300.c
> @@ -0,0 +1,27 @@
> +
> +#include "target-helpers/inline_debug_helper.h"
> +#include "state_tracker/drm_driver.h"
> +#include "radeon/drm/radeon_drm_public.h"
> +#include "r300/r300_public.h"
> +
> +static struct pipe_screen *
> +create_screen(int fd)
> +{
> +   struct r300_winsys_screen *sws;
> +   struct pipe_screen *screen;
> +
> +   sws = r300_drm_winsys_screen_create(fd);
> +   if (!sws)
> +      return NULL;
> +
> +   screen = r300_screen_create(sws);
> +   if (!screen)
> +      return NULL;
> +
> +   screen = debug_screen_wrap(screen);
> +
> +   return screen;
> +}
> +
> +PUBLIC
> +DRM_DRIVER_DESCRIPTOR("r300", "r300", create_screen)
> diff --git a/src/gallium/targets/egl/pipe_radeon.c 
> b/src/gallium/targets/egl/pipe_radeon.c
> deleted file mode 100644
> index 35550bc..000
> --- a/src/gallium/targets/egl/pipe_radeon.c
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -
> -#include "target-helpers/inline_debug_helper.h"
> -#include "state_tracker/drm_driver.h"
> -#include "radeon/drm/radeon_drm_public.h"
> -#include "r300/r300_public.h"
> -
> -static struct pipe_screen *
> -create_screen(int fd)
> -{
> -   struct r300_winsys_screen *sws;
> -   struct pipe_screen *screen;
> -
> -   sws = r300_drm_winsys_screen_create(fd);
> -   if (!sws)
> -      return NULL;
> -
> -   screen = r300_screen_create(sws);
> -   if (!screen)
> -      return NULL;
> -
> -   screen = debug_screen_wrap(screen);
> -
> -   return screen;
> -}
> -
> -PUBLIC
> -DRM_DRIVER_DESCRIPTOR("radeon", "radeon", create_screen)
> --
> 1.7.1

I'm not so sure about this series, because (a) it should be possible
to come up with something that works for both EGL backends (b) we
haven't decided yet how much code r300g and r600g get to share.

Can some of the other people touching radeon code comment? Dave, Jerome, Marek?

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] targets/egl: rename pipe_radeon to pipe_r300

2010-08-22 Thread Marek Olšák

On Sun, Aug 22, 2010 at 6:58 PM, Corbin Simpson
wrote:

> On Sun, Aug 22, 2010 at 9:24 AM, Benjamin Franzke
>  wrote:
> > st/egl/x11/x11_screen.c requests a driver named r300 not radeon
> >
> > KNOWN ISSUE: breaks st/egl/kms/
> >st/egl/kms requests a pipe named "radeon"
> >that will not be found now
> >
> >so why not leaving pipe_radeon there?
> >that was possible as long we have only r300g.
> >now there is also r600g for which st/egl/kms also
> >requests a pipe named "radeon"
> >(possible solution in later commit)
> > ---
> >  src/gallium/targets/egl/Makefile  |   14 +++---
> >  src/gallium/targets/egl/pipe_r300.c   |   27 +++
> >  src/gallium/targets/egl/pipe_radeon.c |   27 ---
> >  3 files changed, 34 insertions(+), 34 deletions(-)
> >  create mode 100644 src/gallium/targets/egl/pipe_r300.c
> >  delete mode 100644 src/gallium/targets/egl/pipe_radeon.c
> >
> > diff --git a/src/gallium/targets/egl/Makefile
> b/src/gallium/targets/egl/Makefile
> > index 1585e2d..636fceb 100644
> > --- a/src/gallium/targets/egl/Makefile
> > +++ b/src/gallium/targets/egl/Makefile
> > @@ -90,10 +90,10 @@ nouveau_LIBS := \
> >$(TOP)/src/gallium/drivers/nv50/libnv50.a \
> >$(TOP)/src/gallium/drivers/nouveau/libnouveau.a
> >
> > -# radeon pipe driver
> > -radeon_CPPFLAGS :=
> > -radeon_SYS := -ldrm -ldrm_radeon
> > -radeon_LIBS := \
> > +# r300 pipe driver
> > +r300_CPPFLAGS :=
> > +r300_SYS := -ldrm -ldrm_radeon
> > +r300_LIBS := \
> >$(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
> >$(TOP)/src/gallium/drivers/r300/libr300.a
> >
> > @@ -151,7 +151,7 @@ ifneq ($(findstring
> nouveau/drm,$(GALLIUM_WINSYS_DIRS)),)
> >  OUTPUTS += nouveau
> >  endif
> >  ifneq ($(findstring radeon/drm,$(GALLIUM_WINSYS_DIRS)),)
> > -OUTPUTS += radeon
> > +OUTPUTS += r300
> >  endif
> >  ifneq ($(findstring svga/drm,$(GALLIUM_WINSYS_DIRS)),)
> >  OUTPUTS += vmwgfx
> > @@ -188,8 +188,8 @@ $(OUTPUT_PATH)/$(PIPE_PREFIX)i965.so: pipe_i965.o
> $(i965_LIBS)
> >  $(OUTPUT_PATH)/$(PIPE_PREFIX)nouveau.so: pipe_nouveau.o $(nouveau_LIBS)
> >$(call mklib,nouveau)
> >
> > -$(OUTPUT_PATH)/$(PIPE_PREFIX)radeon.so: pipe_radeon.o $(radeon_LIBS)
> > -   $(call mklib,radeon)
> > +$(OUTPUT_PATH)/$(PIPE_PREFIX)r300.so: pipe_r300.o $(r300_LIBS)
> > +   $(call mklib,r300)
> >
> >  $(OUTPUT_PATH)/$(PIPE_PREFIX)vmwgfx.so: pipe_vmwgfx.o $(vmwgfx_LIBS)
> >$(call mklib,vmwgfx)
> > diff --git a/src/gallium/targets/egl/pipe_r300.c
> b/src/gallium/targets/egl/pipe_r300.c
> > new file mode 100644
> > index 000..2fa495e
> > --- /dev/null
> > +++ b/src/gallium/targets/egl/pipe_r300.c
> > @@ -0,0 +1,27 @@
> > +
> > +#include "target-helpers/inline_debug_helper.h"
> > +#include "state_tracker/drm_driver.h"
> > +#include "radeon/drm/radeon_drm_public.h"
> > +#include "r300/r300_public.h"
> > +
> > +static struct pipe_screen *
> > +create_screen(int fd)
> > +{
> > +   struct r300_winsys_screen *sws;
> > +   struct pipe_screen *screen;
> > +
> > +   sws = r300_drm_winsys_screen_create(fd);
> > +   if (!sws)
> > +  return NULL;
> > +
> > +   screen = r300_screen_create(sws);
> > +   if (!screen)
> > +  return NULL;
> > +
> > +   screen = debug_screen_wrap(screen);
> > +
> > +   return screen;
> > +}
> > +
> > +PUBLIC
> > +DRM_DRIVER_DESCRIPTOR("r300", "r300", create_screen)
> > diff --git a/src/gallium/targets/egl/pipe_radeon.c
> b/src/gallium/targets/egl/pipe_radeon.c
> > deleted file mode 100644
> > index 35550bc..000
> > --- a/src/gallium/targets/egl/pipe_radeon.c
> > +++ /dev/null
> > @@ -1,27 +0,0 @@
> > -
> > -#include "target-helpers/inline_debug_helper.h"
> > -#include "state_tracker/drm_driver.h"
> > -#include "radeon/drm/radeon_drm_public.h"
> > -#include "r300/r300_public.h"
> > -
> > -static struct pipe_screen *
> > -create_screen(int fd)
> > -{
> > -   struct r300_winsys_screen *sws;
> > -   struct pipe_screen *screen;
> > -
> > -   sws = r300_drm_winsys_screen_create(fd);
> > -   if (!sws)
> > -  return NULL;
> > -
> > -   screen = r300_screen_create(sws);
> > -   if (!screen)
> > -  return NULL;
> > -
> > -   screen = debug_screen_wrap(screen);
> > -
> > -   return screen;
> > -}
> > -
> > -PUBLIC
> > -DRM_DRIVER_DESCRIPTOR("radeon", "radeon", create_screen)
> > --
> > 1.7.1
>
> I'm not so sure about this series, because (a) it should be possible
> to come up with something that works for both EGL backends (b) we
> haven't decided yet how much code r300g and r600g get to share.
>

(a) I agree.

(b) So far it seems to me that the strategy is to copy-paste useful pieces
of code from r300g to r600g and reinventing the wheel elsewhere, instead of
code sharing. My idea is that r300_xxx and r600_xxx structures should
inherit yet-non-existent structures radeon_xxx which should be used by
common code, and these in turn should inherit pipe_xxx. This way we don't
have to redirect a

[Mesa-dev] [Bug 29684] [glsl] wine shaders break with mesa GLSL

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29684

Marc  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Marc  2010-08-22 11:26:51 PDT ---
ok - I didn't read the whole bug report (just the symptoms). sorry, closing
again.

-- 
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] [PATCHES] clang compatibility

2010-08-22 Thread Eric Anholt

On Sun, 22 Aug 2010 05:35:19 -0400, nobled  wrote:
> The first three attached patches make it possible to compile Mesa with
> LLVM/Clang:
> 1. Add -lstdc++ when linking glsl_compiler and glcpp
> 2. Move -lstdc++ from the Gallium-specific Makefile.dri to
> DRI_LIB_DEPS in configure (fixes linking classic Mesa drivers)
> 3. Since autoconf gives GCC=yes even when using clang (since it just
> tests for the __GNUC__ macro), don't check for a minimum version of
> 3.3 if $(CC) points to a clang executable. (unfortunately I'm not sure
> how to properly detect clang, short of test-compiling a file that
> contains #ifdef __clang__. I.e. if $(CC) = 'cc', and 'cc' is an
> alternatives symlink to llvm-clang, this doesn't detect that case.)

From #llvm:

 is it intended that when linking a c++ app with clang that -lstdc++ 
has to be explicitly specified?
 anholt: link via clang++
 :)
 yes, same as with gcc. try linking with clang++ instead.
 ah, my 2.7 clang packages don't come with a clang++ binary
 anholt: don't use 2.7 for C++. For c++, you'll need to use
clang from Subversion
 anholt: adding -lstdc++ is the wrong solution. clang++ is just
a symlink to clang, by the way. you can add it yourself

pgpsDmHVMsln5.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29737] New: Coldest: assertion failure when compiling shader

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29737

   Summary: Coldest: assertion failure when compiling shader
   Product: Mesa
   Version: git
  Platform: Other
   URL: http://www.coldestgame.com/site/
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: s...@whiz.se


Created an attachment (id=38073)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38073)
Shader from Coldest

One of the shaders in the game "Coldest" is causing an assertion failure when
compiled:

ir_constant_variable.cpp:143: virtual ir_visitor_status
ir_constant_variable_visitor::visit_enter(ir_call*): Assertion `var' failed.

I _think_ the one attached is the shader in question, at least it's the last
one dumped when MESA_GLSL=dump is used.

http://www.coldestgame.com/site/

-- 
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

[Mesa-dev] [Bug 29689] Heroes of Newerth models are rendered as 2D

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29689

Roman Schmaker Šmakal  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Mesa core
 AssignedTo|dri-de...@lists.freedesktop |mesa-...@lists.freedesktop.
   |.org|org

--- Comment #4 from Roman Schmaker Šmakal  2010-08-22 
14:02:58 PDT ---
Bog looks kinda different to me. Ill post some screenshots.

-- 
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

[Mesa-dev] [Bug 29689] [regression] GLSL2 merge broke Heroes of Newerth

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29689

Roman Schmaker Šmakal  changed:

   What|Removed |Added

Summary|Heroes of Newerth models|[regression] GLSL2 merge
   |are rendered as 2D  |broke Heroes of Newerth

-- 
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

[Mesa-dev] [Bug 29689] Heroes of Newerth models are rendered as 2D

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29689

--- Comment #5 from Sven Arvidsson  2010-08-22 14:12:06 PDT ---
(In reply to comment #4)
> Bog looks kinda different to me. Ill post some screenshots.

Yeah, I get different output on softpipe too, difference between drivers I
guess.

-- 
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 1/3] targets/egl: rename pipe_radeon to pipe_r300

2010-08-22 Thread Jerome Glisse

On Sun, Aug 22, 2010 at 08:13:45PM +0200, Marek Olšák wrote:
> On Sun, Aug 22, 2010 at 6:58 PM, Corbin Simpson
> wrote:
> >
> > I'm not so sure about this series, because (a) it should be possible
> > to come up with something that works for both EGL backends (b) we
> > haven't decided yet how much code r300g and r600g get to share.
> >
> 
> (a) I agree.
> 
> (b) So far it seems to me that the strategy is to copy-paste useful pieces
> of code from r300g to r600g and reinventing the wheel elsewhere, instead of
> code sharing. My idea is that r300_xxx and r600_xxx structures should
> inherit yet-non-existent structures radeon_xxx which should be used by
> common code, and these in turn should inherit pipe_xxx. This way we don't
> have to redirect all entrypoints to a driver like in galahad, only the ones
> we want to override. At least all buffer management and texture transfer
> code could be shared. Then, the drivers would not need to implement
> entrypoints like user_buffer_create and transfers and some other resource
> entrypoints, and an alternate low-level bufmgr interface would be provided
> the drivers must implement instead.
> 
> The idea of sharing winsys is pretty much dead, as you probably already
> know. I think Jerome wants to move some of the r600g winsys code into
> kernel.
> 
> Marek

My feeling is that only some of the buffer management for avoiding
to allocate too frequently bo would be usefull. I think this buffer
management can be moved to util at some point as i believe other
driver can benefit from similar things. It would be target for
allocation of small buffer and the logic would be come one (couple
of callback to allow driver to plug its low level allocation would
be enough like bo_open,bo_decref,bo_incref,bo_is_idle,bo_wait_idle)

The rest of the winsys is too different, i am going to simplify the
r600 winsys state/context over the next few days but it will still
be different from atom+prediction all over the place.

Cheers,
Jerome
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29675] Variable indexing of variable arrays in the FS unsupported

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29675

Sven Arvidsson  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/DRI/i965
 AssignedTo|mesa-...@lists.freedesktop. |e...@anholt.net
   |org |

-- 
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

[Mesa-dev] [Bug 29689] Heroes of Newerth models are rendered as 2D

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29689

--- Comment #6 from Roman Schmaker Šmakal  2010-08-22 
14:12:37 PDT ---
Created an attachment (id=38074)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38074)
[R600]Models bug (in menu)

-- 
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

[Mesa-dev] [Bug 29689] Heroes of Newerth models are rendered as 2D

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29689

--- Comment #7 from Roman Schmaker Šmakal  2010-08-22 
14:13:45 PDT ---
Created an attachment (id=38075)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38075)
[R600]Models bug (ingame)

-- 
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

[Mesa-dev] [Bug 29585] glsl2: --enable-32-bit doesn't check for talloc properly

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29585

--- Comment #2 from Mathias Brodala  2010-08-22 16:20:51 PDT 
---
I am experiencing a similar issue with the recent git master, most likely due
to the GLSL branch merge:

> mklib: Making Linux shared library:  r600_dri.so.tmp
> g++ -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math 
> -fvisibility=hidden -fno-strict-aliasing -m32  -fPIC -m32 -DUSE_X86_ASM 
> -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS 
> -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 
> -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS 
> -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -DHAVE_LIBDRM_RADEON=1 
> -I/usr/include/libdrm   -DFEATURE_GL=1 -o r600_dri.so.test 
> ../../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp   -ldrm 
>   -lexpat -lm -lpthread -ldl -ldrm_radeon -ldrm  
> r600_dri.so.tmp: undefined reference to `talloc_strdup_append'
> r600_dri.so.tmp: undefined reference to `talloc_asprintf'
> r600_dri.so.tmp: undefined reference to `talloc_unlink'
> r600_dri.so.tmp: undefined reference to `talloc_strndup'
> r600_dri.so.tmp: undefined reference to `_talloc_free'
> r600_dri.so.tmp: undefined reference to `_talloc_array'
> r600_dri.so.tmp: undefined reference to `_talloc_reference_loc'
> r600_dri.so.tmp: undefined reference to `talloc_parent'
> r600_dri.so.tmp: undefined reference to `talloc_init'
> r600_dri.so.tmp: undefined reference to `talloc_strdup'
> r600_dri.so.tmp: undefined reference to `_talloc_zero'
> r600_dri.so.tmp: undefined reference to `_talloc_steal_loc'
> r600_dri.so.tmp: undefined reference to `_talloc_zero_array'
> r600_dri.so.tmp: undefined reference to `talloc_asprintf_append'
> r600_dri.so.tmp: undefined reference to `talloc_vasprintf_append'
> r600_dri.so.tmp: undefined reference to `talloc_named_const'
> r600_dri.so.tmp: undefined reference to `talloc_strndup_append'
> r600_dri.so.tmp: undefined reference to `_talloc_set_destructor'
> collect2: ld returned 1 exit status

My configure flags include --enable-32-bit and --disable-64-bit.

-- 
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

[Mesa-dev] [Bug 29741] New: [glsl] wine with GLSL renders incompletely or not at all

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29741

   Summary: [glsl] wine with GLSL renders incompletely or not at
all
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: rubenf3...@gmail.com


Altough not giving any compilation errors now, most GLSL shaders generated by
wine fail to render correctly.

In some applications/games, some objects are shown, others aren't. In some
games, nothing is rendered at all.

Testing a revision of git previous to the glsl2 merge, I found that this bug
happened exactly the same with the old GLSL compiler; this suggests that the
problem might not be the compiler per se, but the r300g driver executing the
resulting assembly incorrectly. The fact that the games render correctly with
the LLVMpipe software renderer seems to confirm this.

Graphics Card: ATI Technologies Inc RV505 [Radeon X1550 64-bit]
CPU: Intel Core Duo 1.8 Ghz, 2.5 GB RAM
Linux kernel 2.6.34, libdrm 2.4.21

-- 
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

[Mesa-dev] [Bug 29741] [glsl] wine with GLSL renders incompletely or not at all

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29741

--- Comment #1 from Rubén Fernández  2010-08-22 16:28:55 
PDT ---
Created an attachment (id=38078)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38078)
Screenshot with GLSL disabled, rendering correctly

when wine is set to disable GLSL, it generates the shaders using the ARB
assembly shader language; then, it renders most apps/games correctly

-- 
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

[Mesa-dev] [Bug 29741] [glsl] wine with GLSL renders incompletely or not at all

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29741

--- Comment #2 from Rubén Fernández  2010-08-22 16:30:35 
PDT ---
Created an attachment (id=38079)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38079)
Screenshot with GLSL enabled, rendering incorrectly

However, when GLSL is enabled in wine, only some objects are rendered; in this
screenshot, the creatures and the torch flames are shown, but not the door or
the walls.

-- 
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

[Mesa-dev] [Bug 29741] [glsl] wine with GLSL renders incompletely or not at all

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29741

--- Comment #3 from Rubén Fernández  2010-08-22 16:31:28 
PDT ---
Created an attachment (id=38080)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38080)
Log generated with MESA_GLSL=dump and RADEON_DEBUG=fp, with GLSL enabled

-- 
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

[Mesa-dev] [Bug 29741] [glsl] wine with GLSL renders incompletely or not at all

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29741

--- Comment #4 from Rubén Fernández  2010-08-22 16:32:40 
PDT ---
Created an attachment (id=38081)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38081)
Log generated with RADEON_DEBUG=fp, with GLSL disabled

A log without GLSL (when it is rendered correctly) for reference

-- 
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

[Mesa-dev] [Bug 29684] [glsl] wine shaders break with mesa GLSL

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29684

--- Comment #14 from Rubén Fernández  2010-08-22 16:34:32 
PDT ---
(In reply to comment #13)
> ok - I didn't read the whole bug report (just the symptoms). sorry, closing
> again.

You can now follow / contribute to improving GLSL with this new bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=29741

-- 
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

[Mesa-dev] [Bug 29741] [glsl] wine with GLSL renders incompletely or not at all

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29741

Marek Olšák  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #5 from Marek Olšák  2010-08-22 16:45:45 PDT ---
According to your logs, it seems to be the same issue as bug 29137. See the
discussion here:

https://bugs.freedesktop.org/show_bug.cgi?id=29137#c12

*** This bug has been marked as a duplicate of bug 29137 ***

-- 
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

[Mesa-dev] [Bug 29585] glsl2: --enable-32-bit doesn't check for talloc properly

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29585

Eric Anholt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Eric Anholt  2010-08-22 17:42:25 PDT ---
Thanks for tracking down the issue.  Hopefully this fixes it:

commit 639cdd3782c40c422c33c907949376c735d9340c
Author: Eric Anholt 
Date:   Sun Aug 22 17:34:18 2010 -0700

mesa: AC_SUBST the talloc libs/cflags so the ./configure results are saved.

I had used pkg-config from the Makefile because I didn't want to screw
around with the non-autoconf build, but that doesn't work because the
PKG_CONFIG_PATH or TALLOC_LIBS/TALLOC_CFLAGS that people set at
configure time needs to be respected and may not be present at build
time.

Bug #29585

-- 
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

[Mesa-dev] [Bug 29044] GLSL compiler tracker

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29044

Bug 29044 depends on bug 27004, which changed state.

Bug 27004 Summary: [GLSL] allowing macro redefinition
https://bugs.freedesktop.org/show_bug.cgi?id=27004

   What|Old Value   |New Value

 Resolution||FIXED
 Status|NEW |RESOLVED

-- 
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 5/5] st/mesa: fix ReadPixels crashes when reading depth/stencil from a FBO

2010-08-22 Thread Brian Paul

On Sat, Aug 14, 2010 at 9:47 AM, Marek Olšák  wrote:
> NOTE: This is a candidate for the 7.8 branch.
> ---
>  src/mesa/state_tracker/st_cb_readpixels.c |   13 +++--
>  1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_readpixels.c 
> b/src/mesa/state_tracker/st_cb_readpixels.c
> index b8493da..3cfb262 100644
> --- a/src/mesa/state_tracker/st_cb_readpixels.c
> +++ b/src/mesa/state_tracker/st_cb_readpixels.c
> @@ -63,11 +63,16 @@ st_read_stencil_pixels(GLcontext *ctx, GLint x, GLint y,
>  {
>    struct gl_framebuffer *fb = ctx->ReadBuffer;
>    struct pipe_context *pipe = st_context(ctx)->pipe;
> -   struct st_renderbuffer *strb = st_renderbuffer(fb->_StencilBuffer);
> +   struct st_renderbuffer *strb;
>    struct pipe_transfer *pt;
>    ubyte *stmap;
>    GLint j;
>
> +   if (fb->_StencilBuffer->Wrapped)
> +      strb = st_renderbuffer(fb->_StencilBuffer->Wrapped);
> +   else
> +      strb = st_renderbuffer(fb->_StencilBuffer);
> +
>    if (st_fb_orientation(ctx->DrawBuffer) == Y_0_TOP) {
>       y = ctx->DrawBuffer->Height - y - height;
>    }
> @@ -358,7 +363,11 @@ st_readpixels(GLcontext *ctx, GLint x, GLint y, GLsizei 
> width, GLsizei height,
>       return;
>    }
>    else if (format == GL_DEPTH_COMPONENT) {
> -      strb = st_renderbuffer(ctx->ReadBuffer->_DepthBuffer);
> +      struct gl_renderbuffer *depthRb = ctx->ReadBuffer->_DepthBuffer;
> +      if (depthRb->Wrapped)
> +         strb = st_renderbuffer(depthRb->Wrapped);
> +      else
> +         strb = st_renderbuffer(depthRb);
>    }
>    else {
>       /* Read color buffer */
> --
> 1.7.0.4

Thanks.  I've committed a slightly modified version of this patch.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29737] Coldest: assertion failure when compiling shader

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29737

Eric Anholt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Eric Anholt  2010-08-22 18:36:03 PDT ---
Thanks.  I cut the shader down to the minimum code to reproduce, and it was
pretty simple:

commit dad8f7a19c8819a6b9f02ef9059384ca09c4ac42
Author: Eric Anholt 
Date:   Sun Aug 22 18:28:47 2010 -0700

glsl-constant-folding-call-1: New test for bug #29737.

commit 137b8397fa5cc5d70e86a4b14d6be9326340f584
Author: Eric Anholt 
Date:   Sun Aug 22 18:25:55 2010 -0700

glsl: Don't tree-graft in an expression in place of a function outval.

Fixes: glsl-constant-folding-call-1 (bug #29737)

-- 
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 1/5] st/mesa: use pipe_context::clear for D24S8 textures when appropriate

2010-08-22 Thread Brian Paul

On Fri, Aug 20, 2010 at 10:40 AM, Marek Olšák  wrote:
> On Mon, Aug 16, 2010 at 3:55 PM, Roland Scheidegger 
> wrote:
>>
>> On 14.08.2010 17:47, Marek Olšák wrote:
>> > If PIPE_CAP_DEPTHSTENCIL_CLEAR_SEPARATE is not advertised and there is
>> > a D24S8 texture bound and the mask is
>> > BUFFER_BIT_DEPTH|BUFFER_BIT_STENCIL,
>> > the state tracker always cleared the texture with a quad instead of
>> > using
>> > pipe_context::clear.
>>
>> > @@ -543,7 +549,7 @@ st_Clear(GLcontext *ctx, GLbitfield mask)
>> >         */
>> >        if ((clear_buffers & PIPE_CLEAR_DEPTHSTENCIL) &&
>> >            ((clear_buffers & PIPE_CLEAR_DEPTHSTENCIL) !=
>> > PIPE_CLEAR_DEPTHSTENCIL) &&
>> > -          (depthRb == stencilRb) &&
>> > +          depth_stencil_combined &&
>> >            (ctx->DrawBuffer->Visual.depthBits == 0 ||
>> >             ctx->DrawBuffer->Visual.stencilBits == 0))
>> >           clear_buffers |= PIPE_CLEAR_DEPTHSTENCIL;
>>
>> I think there's an issue with this code when used for texture
>> attachments, we use the Visual information but I don't think that's
>> meaningful in that case (Visual information is also used elsewhere in
>> the clear code), potentially leading to bogus results. If the code
>> didn't handle texture attachments correctly before that bug might have
>> been hidden.
>
> OK, I've attached a new patch which also resolves the issue with the Visual
> bits. There is an explanation in the commit message.
>
> May I push?

I need a bit more time to review this but I committed the part that
added the st_is_depth_stencil_combined() function, plus the other
patches which help to fix the piglit fbo-blit-d24s8 test.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29627] [glsl2] Matrix comparison not implemented for non-constants

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29627

Eric Anholt  changed:

   What|Removed |Added

 CC||v...@vmware.com

--- Comment #1 from Eric Anholt  2010-08-22 18:49:52 PDT ---
*** Bug 29694 has been marked as a duplicate of this bug. ***

-- 
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

[Mesa-dev] [Bug 29744] New: Loader failure for egl_gallium

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29744

   Summary: Loader failure for egl_gallium
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: lu_z...@gentoo.org


Testcase es2_info from mesa-progs.

Backtrace

#0  0x7f57f76c773c in create_drm_screen (name=, fd=7)
at egl.c:322
#1  0x7f57f76cfad4 in x11_create_dri2_display (dpy=0x1d2f010, 
event_handler=0x7f57f7902390, user_data=0x1d3b040) at x11/native_dri2.c:714
#2  0x7f57f76c91c6 in native_create_display (dpy=0x1d2f010, 
event_handler=0x7f57f7902390, user_data=0x1d3b040) at x11/native_x11.c:42
#3  0x7f57f76c81e0 in egl_g3d_initialize (drv=, 
dpy=0x1d3b040, major=, minor=)
at common/egl_g3d.c:498
#4  0x7f57f8e777f1 in _eglMatchDriver (dpy=, 
use_probe=) at egldriver.c:580
#5  0x7f57f8e7186a in eglInitialize (dpy=0x1d3b040, major=0x7fff1f24036c, 
minor=0x7fff1f240368) at eglapi.c:294
#6  0x004013d2 in main (argc=1, argv=0x7fff1f240488) at es2_info.c:259

317
318 static struct pipe_screen *
319 create_drm_screen(const char *name, int fd)
320 {
321struct pipe_module *pmod = get_pipe_module(name);
322return (pmod && pmod->drmdd->create_screen) ?
323   pmod->drmdd->create_screen(fd) : NULL;
324 }
325
326 static struct pipe_screen *

initial name is r300, the name should be radeon.

it's a bit unknown why it returns

(gdb) print *pmod
$2 = {initialized = 1 '\001', name = 0x0, lib = 0x0, drmdd = 0x0, 
  swrast_create_screen = 0}

something this wrong.

-- 
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

[Mesa-dev] [Bug 29744] Loader failure for egl_gallium

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29744

--- Comment #1 from Luca Barbato  2010-08-22 19:30:21 PDT 
---
load_pipe_module seems the culprit:

(gdb) print pmod->drmdd->driver_name
$5 = 0x7fca7adaf6e0 "radeon"
(gdb) print pmod->name
$6 = 0x25b4140 "r300"

158_eglSearchPathForEach(dlopen_pipe_module_cb, (void *) pmod);
159if (pmod->lib) {
160   pmod->drmdd = (const struct drm_driver_descriptor *)
161  util_dl_get_proc_address(pmod->lib, "driver_descriptor");
162   if (pmod->drmdd) {
163  if (pmod->drmdd->driver_name) {
164 /* driver name mismatch */
165 if (strcmp(pmod->drmdd->driver_name, pmod->name) != 0)
166pmod->drmdd = NULL;
167  }

-- 
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

[Mesa-dev] [Bug 29745] New: glsl2 crash

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29745

   Summary: glsl2 crash
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: lu_z...@gentoo.org


trying es2gears 

Backtrace

#1  0x7fd22ec7b4ae in link_intrastage_shaders (ctx=, 
prog=0xc6b9f0, shader_list=0xdba250, num_shaders=1) at linker.cpp:751
#2  0x7fd22ec7bae1 in link_shaders (ctx=0x6ef610, prog=0xc6b9f0)
at linker.cpp:1283
#3  0x7fd22ec42db3 in _mesa_glsl_link_shader (ctx=0x6ef610, prog=0xc6b9f0)
at program/ir_to_mesa.cpp:2747
#4  0x00403a7a in gears_init () at es2gears.c:678
#5  0x00403bf5 in main (argc=1, argv=0x7fffc290e978) at es2gears.c:717

-- 
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 1/3] targets/egl: rename pipe_radeon to pipe_r300

2010-08-22 Thread Chia-I Wu

On Mon, Aug 23, 2010 at 12:24 AM, Benjamin Franzke
 wrote:
> st/egl/x11/x11_screen.c requests a driver named r300 not radeon
>
> KNOWN ISSUE: breaks st/egl/kms/
>        st/egl/kms requests a pipe named "radeon"
>        that will not be found now
>
>        so why not leaving pipe_radeon there?
>        that was possible as long we have only r300g.
>        now there is also r600g for which st/egl/kms also
>        requests a pipe named "radeon"
>        (possible solution in later commit)
I had a look at xorg-video-ati and r300 should be the right name.  st/egl/kms
should duplicate the logic in the DDX driver and request r300 or r600 when the
kernel module is radeon.

But I am now wondering why targets/dri-radeong builds radeon_dri instead of
r300_dri?


> ---
>  src/gallium/targets/egl/Makefile      |   14 +++---
>  src/gallium/targets/egl/pipe_r300.c   |   27 +++
>  src/gallium/targets/egl/pipe_radeon.c |   27 ---
>  3 files changed, 34 insertions(+), 34 deletions(-)
>  create mode 100644 src/gallium/targets/egl/pipe_r300.c
>  delete mode 100644 src/gallium/targets/egl/pipe_radeon.c
>
> diff --git a/src/gallium/targets/egl/Makefile 
> b/src/gallium/targets/egl/Makefile
> index 1585e2d..636fceb 100644
> --- a/src/gallium/targets/egl/Makefile
> +++ b/src/gallium/targets/egl/Makefile
> @@ -90,10 +90,10 @@ nouveau_LIBS := \
>        $(TOP)/src/gallium/drivers/nv50/libnv50.a \
>        $(TOP)/src/gallium/drivers/nouveau/libnouveau.a
>
> -# radeon pipe driver
> -radeon_CPPFLAGS :=
> -radeon_SYS := -ldrm -ldrm_radeon
> -radeon_LIBS := \
> +# r300 pipe driver
> +r300_CPPFLAGS :=
> +r300_SYS := -ldrm -ldrm_radeon
> +r300_LIBS := \
>        $(TOP)/src/gallium/winsys/radeon/drm/libradeonwinsys.a \
>        $(TOP)/src/gallium/drivers/r300/libr300.a
>
> @@ -151,7 +151,7 @@ ifneq ($(findstring nouveau/drm,$(GALLIUM_WINSYS_DIRS)),)
>  OUTPUTS += nouveau
>  endif
>  ifneq ($(findstring radeon/drm,$(GALLIUM_WINSYS_DIRS)),)
> -OUTPUTS += radeon
> +OUTPUTS += r300
>  endif
>  ifneq ($(findstring svga/drm,$(GALLIUM_WINSYS_DIRS)),)
>  OUTPUTS += vmwgfx
> @@ -188,8 +188,8 @@ $(OUTPUT_PATH)/$(PIPE_PREFIX)i965.so: pipe_i965.o 
> $(i965_LIBS)
>  $(OUTPUT_PATH)/$(PIPE_PREFIX)nouveau.so: pipe_nouveau.o $(nouveau_LIBS)
>        $(call mklib,nouveau)
>
> -$(OUTPUT_PATH)/$(PIPE_PREFIX)radeon.so: pipe_radeon.o $(radeon_LIBS)
> -       $(call mklib,radeon)
> +$(OUTPUT_PATH)/$(PIPE_PREFIX)r300.so: pipe_r300.o $(r300_LIBS)
> +       $(call mklib,r300)
>
>  $(OUTPUT_PATH)/$(PIPE_PREFIX)vmwgfx.so: pipe_vmwgfx.o $(vmwgfx_LIBS)
>        $(call mklib,vmwgfx)
> diff --git a/src/gallium/targets/egl/pipe_r300.c 
> b/src/gallium/targets/egl/pipe_r300.c
> new file mode 100644
> index 000..2fa495e
> --- /dev/null
> +++ b/src/gallium/targets/egl/pipe_r300.c
> @@ -0,0 +1,27 @@
> +
> +#include "target-helpers/inline_debug_helper.h"
> +#include "state_tracker/drm_driver.h"
> +#include "radeon/drm/radeon_drm_public.h"
> +#include "r300/r300_public.h"
> +
> +static struct pipe_screen *
> +create_screen(int fd)
> +{
> +   struct r300_winsys_screen *sws;
> +   struct pipe_screen *screen;
> +
> +   sws = r300_drm_winsys_screen_create(fd);
> +   if (!sws)
> +      return NULL;
> +
> +   screen = r300_screen_create(sws);
> +   if (!screen)
> +      return NULL;
> +
> +   screen = debug_screen_wrap(screen);
> +
> +   return screen;
> +}
> +
> +PUBLIC
> +DRM_DRIVER_DESCRIPTOR("r300", "r300", create_screen)
> diff --git a/src/gallium/targets/egl/pipe_radeon.c 
> b/src/gallium/targets/egl/pipe_radeon.c
> deleted file mode 100644
> index 35550bc..000
> --- a/src/gallium/targets/egl/pipe_radeon.c
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -
> -#include "target-helpers/inline_debug_helper.h"
> -#include "state_tracker/drm_driver.h"
> -#include "radeon/drm/radeon_drm_public.h"
> -#include "r300/r300_public.h"
> -
> -static struct pipe_screen *
> -create_screen(int fd)
> -{
> -   struct r300_winsys_screen *sws;
> -   struct pipe_screen *screen;
> -
> -   sws = r300_drm_winsys_screen_create(fd);
> -   if (!sws)
> -      return NULL;
> -
> -   screen = r300_screen_create(sws);
> -   if (!screen)
> -      return NULL;
> -
> -   screen = debug_screen_wrap(screen);
> -
> -   return screen;
> -}
> -
> -PUBLIC
> -DRM_DRIVER_DESCRIPTOR("radeon", "radeon", create_screen)
> --
> 1.7.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 29744] Loader failure for egl_gallium

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29744

--- Comment #2 from Chia-I Wu  2010-08-22 20:29:45 PDT ---
Hmm.  Could you enlighten me which DRI driver would libGL load on your system? 
r300_dri or radeon_dri?  It seems should be r300_dri from a quick look at
xorg-video-ati.  But I am then curious why src/gallium/targets/dri-radeong
builds radeon_dri instead r300_dri.  I must miss something...

-- 
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

[Mesa-dev] [Bug 29744] Loader failure for egl_gallium

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29744

--- Comment #3 from Alex Deucher  2010-08-22 21:49:00 PDT ---
(In reply to comment #2)
> Hmm.  Could you enlighten me which DRI driver would libGL load on your 
> system? 
> r300_dri or radeon_dri?  It seems should be r300_dri from a quick look at
> xorg-video-ati.  But I am then curious why src/gallium/targets/dri-radeong
> builds radeon_dri instead r300_dri.  I must miss something...

There are two 3D drivers for r300-r500 radeon hardware, the classic mesa r300
driver and the gallium r300 driver.  At the moment the classic driver is the
default, but that's likely to change soon.

-- 
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

[Mesa-dev] [Bug 29044] GLSL compiler tracker

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29044

Gordon Jin  changed:

   What|Removed |Added

 Depends on||29747

-- 
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

[Mesa-dev] [Bug 29744] Loader failure for egl_gallium

2010-08-22 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=29744

--- Comment #4 from Benjamin Franzke  
2010-08-22 23:00:32 PDT ---
hm what has this directly to do with DRI drivers?

That code is executed after loading a pipe module, so lib/egl/pipe_radeon.so
and not the dri stuff..
This error looks to me as if a symlink created from lib/egl/pipe_r300.so ->
lib/egl/pipe_radeon.so.
(I did the same think as i experienced propblems loading r300g pipe with
egl/x11)
my patches i send yesterday should have solved that:
http://lists.freedesktop.org/archives/mesa-dev/2010-August/002385.html

-- 
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

[Mesa-dev] [PATCH] glsl / imports.h: fix MSVC build

2010-08-22 Thread Aras Pranckevicius

Hi,

Attached patch fixes MSVC (2008) build. MSVC was still missing truncf,
exp2f, log2f (all used in GLSL2).

MSVC does not have trunc(), so defining truncf() to trunc() does not quite
work. The _XOPEN_SOURCE usage looked pretty weird as well; it made whole
that block not be included if the define is not there at all.

-- 
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info


glsl-fix-msvc-build.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl / imports.h: fix MSVC build

2010-08-22 Thread Chia-I Wu

On Mon, Aug 23, 2010 at 2:25 PM, Aras Pranckevicius  wrote:
> Hi,
> Attached patch fixes MSVC (2008) build. MSVC was still missing truncf,
> exp2f, log2f (all used in GLSL2).
> MSVC does not have trunc(), so defining truncf() to trunc() does not quite
> work. The _XOPEN_SOURCE usage looked pretty weird as well; it made whole
> that block not be included if the define is not there at all.
Not that familiar with MSVC, but when I built Mesa on Windows the other day,
other than the defines introduced by this patch, these functions were also
missing: snprintf, strtoll, and isblank.  Is it me or the patch that misses
something?


-- 
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl / imports.h: fix MSVC build

2010-08-22 Thread Aras Pranckevicius

>
> Not that familiar with MSVC, but when I built Mesa on Windows the other
> day,
> other than the defines introduced by this patch, these functions were also
> missing: snprintf, strtoll, and isblank.  Is it me or the patch that misses
> something?
>

Could be; I'm not actually building full Mesa (just the GLSL compiler). At
least for snprintf, in MSVC it's _snprintf; no idea about others right now.


-- 
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

45 matches

Mail list logo