[Mesa-dev] [Bug 29684] [glsl] wine shaders break with mesa GLSL
https://bugs.freedesktop.org/show_bug.cgi?id=29684 --- Comment #10 from Marc marvi...@gmx.de 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
https://bugs.freedesktop.org/show_bug.cgi?id=29684 --- Comment #11 from Marc marvi...@gmx.de 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
https://bugs.freedesktop.org/show_bug.cgi?id=29684 Marc marvi...@gmx.de 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
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 3/3] targets/egl: add pipe_r600
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
https://bugs.freedesktop.org/show_bug.cgi?id=29684 --- Comment #12 from Rubén Fernández rubenf3...@gmail.com 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
On Sun, Aug 22, 2010 at 9:24 AM, Benjamin Franzke
benjaminfran...@googlemail.com 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
mostawesomed...@gmail.com
___
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
On Sun, Aug 22, 2010 at 6:58 PM, Corbin Simpson
mostawesomed...@gmail.comwrote:
On Sun, Aug 22, 2010 at 9:24 AM, Benjamin Franzke
benjaminfran...@googlemail.com 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 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
[Mesa-dev] [Bug 29684] [glsl] wine shaders break with mesa GLSL
https://bugs.freedesktop.org/show_bug.cgi?id=29684 Marc marvi...@gmx.de changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #13 from Marc marvi...@gmx.de 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
On Sun, 22 Aug 2010 05:35:19 -0400, nobled nob...@dreamwidth.org 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: anholt is it intended that when linking a c++ app with clang that -lstdc++ has to be explicitly specified? aKor anholt: link via clang++ aKor :) nicholas yes, same as with gcc. try linking with clang++ instead. anholt ah, my 2.7 clang packages don't come with a clang++ binary dgregor anholt: don't use 2.7 for C++. For c++, you'll need to use clang from Subversion dgregor 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 29689] Heroes of Newerth models are rendered as 2D
https://bugs.freedesktop.org/show_bug.cgi?id=29689 Roman Schmaker Šmakal schma...@ifrit.eu 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 schma...@ifrit.eu 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
https://bugs.freedesktop.org/show_bug.cgi?id=29689 Roman Schmaker Šmakal schma...@ifrit.eu 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
https://bugs.freedesktop.org/show_bug.cgi?id=29689 --- Comment #5 from Sven Arvidsson s...@whiz.se 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
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 mostawesomed...@gmail.comwrote: 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
https://bugs.freedesktop.org/show_bug.cgi?id=29675 Sven Arvidsson s...@whiz.se 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
https://bugs.freedesktop.org/show_bug.cgi?id=29689 --- Comment #6 from Roman Schmaker Šmakal schma...@ifrit.eu 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
https://bugs.freedesktop.org/show_bug.cgi?id=29689 --- Comment #7 from Roman Schmaker Šmakal schma...@ifrit.eu 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
https://bugs.freedesktop.org/show_bug.cgi?id=29585 --- Comment #2 from Mathias Brodala i...@noctus.net 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=29741 --- Comment #1 from Rubén Fernández rubenf3...@gmail.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=29741 --- Comment #2 from Rubén Fernández rubenf3...@gmail.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=29741 --- Comment #3 from Rubén Fernández rubenf3...@gmail.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=29741 --- Comment #4 from Rubén Fernández rubenf3...@gmail.com 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 29741] [glsl] wine with GLSL renders incompletely or not at all
https://bugs.freedesktop.org/show_bug.cgi?id=29741 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #5 from Marek Olšák mar...@gmail.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=29585 Eric Anholt e...@anholt.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Eric Anholt e...@anholt.net 2010-08-22 17:42:25 PDT --- Thanks for tracking down the issue. Hopefully this fixes it: commit 639cdd3782c40c422c33c907949376c735d9340c Author: Eric Anholt e...@anholt.net 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
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
On Sat, Aug 14, 2010 at 9:47 AM, Marek Olšák mar...@gmail.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=29737 Eric Anholt e...@anholt.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Eric Anholt e...@anholt.net 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 e...@anholt.net Date: Sun Aug 22 18:28:47 2010 -0700 glsl-constant-folding-call-1: New test for bug #29737. commit 137b8397fa5cc5d70e86a4b14d6be9326340f584 Author: Eric Anholt e...@anholt.net 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
On Fri, Aug 20, 2010 at 10:40 AM, Marek Olšák mar...@gmail.com wrote: On Mon, Aug 16, 2010 at 3:55 PM, Roland Scheidegger srol...@vmware.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=29627 Eric Anholt e...@anholt.net changed: What|Removed |Added CC||v...@vmware.com --- Comment #1 from Eric Anholt e...@anholt.net 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
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=value optimized out, 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=value optimized out,
dpy=0x1d3b040, major=value optimized out, minor=value optimized out)
at common/egl_g3d.c:498
#4 0x7f57f8e777f1 in _eglMatchDriver (dpy=value optimized out,
use_probe=value optimized out) 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
https://bugs.freedesktop.org/show_bug.cgi?id=29744
--- Comment #1 from Luca Barbato lu_z...@gentoo.org 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
Re: [Mesa-dev] [PATCH 1/3] targets/egl: rename pipe_radeon to pipe_r300
On Mon, Aug 23, 2010 at 12:24 AM, Benjamin Franzke
benjaminfran...@googlemail.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=29744 --- Comment #2 from Chia-I Wu olva...@gmail.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=29744 --- Comment #3 from Alex Deucher ag...@yahoo.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Gordon Jin gordon@intel.com 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
