[Mesa-dev] [Bug 48788] Mesa after 7.11.2 won't use hardware for OpenGL acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=48788 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #8 from Michel Dänzer mic...@daenzer.net 2012-04-17 00:10:17 PDT --- According to glxinfo and the related discussion on IRC, you're using the standalone software rendering libGL.so.1, which can't use hardware acceleration and doesn't know about LIBGL_DEBUG. You'll need to sort this out with folks knowledgeable about Gentoo. (In reply to comment #6) Because xf86-video-ati won't works nice for me, I have obscure mouse cursor issue [...] Now, that might warrant a bug report. -- 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 48788] Mesa after 7.11.2 won't use hardware for OpenGL acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=48788 --- Comment #9 from russian...@gmail.com russian...@gmail.com 2012-04-17 00:15:43 PDT --- Dear Michel, looks like you didnt followed IRC discussion closely, especially today one. I've did even clean building of mesa with installation to /opt (according to wiki article in /topic of IRC channel) and the problem is still there. So please reopen 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 48788] Mesa after 7.11.2 won't use hardware for OpenGL acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=48788 --- Comment #10 from Michel Dänzer mic...@daenzer.net 2012-04-17 00:33:50 PDT --- As long as glxinfo says OpenGL renderer string: Mesa X11 my analysis stands. -- 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 48788] Mesa after 7.11.2 won't use hardware for OpenGL acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=48788 --- Comment #11 from russian...@gmail.com russian...@gmail.com 2012-04-17 00:35:37 PDT --- That's why I opened that issue. Reverting mesa to 7.11 solves that. -- 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 48788] Mesa after 7.11.2 won't use hardware for OpenGL acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=48788 --- Comment #12 from Dave Airlie airl...@freedesktop.org 2012-04-17 00:35:54 PDT --- what Michael said stands, you are using a libGL built for X11 sw rendering, nothing else you can do except fix the libGL build will affect 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 48788] Mesa after 7.11.2 won't use hardware for OpenGL acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=48788 --- Comment #13 from Dave Airlie airl...@freedesktop.org 2012-04-17 00:36:29 PDT --- you'd need to attach a full build log with configure stage to see why. -- 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] Mesa-8.0.2 libGL.so: undefined reference to `XGetXCBConnection'
On Mon, 2012-04-16 at 22:15 +1000, jupiter@gmail.com wrote: I've just built Mesa-8.0.2 in a Linux box. Then there were errors of libGL.so: undefined reference to `XGetXCBConnection' % nm -aD --defined /usr/lib/libX11-xcb.so.1 | grep XCB 473ef560 T XGetXCBConnection and libGL.so: undefined reference to `xcb_glx_client_info' while I was compiling glew-1.7.0. What was I missing in building Mesa-8.0.2? % nm -aD --defined /usr/lib/libxcb-glx.so.0 | grep client_info$ 47756d10 T xcb_glx_client_info $ ldd libGL.so linux-gate.so.1 = (0x003d9000) libX11.so.6 = /usr/lib/libX11.so.6 (0x00588000) libXext.so.6 = /usr/lib/libXext.so.6 (0x0016c000) libXxf86vm.so.1 = /usr/lib/libXxf86vm.so.1 (0x0097c000) libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x009ed000) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x003a8000) libpthread.so.0 = /lib/libpthread.so.0 (0x006ea000) libdl.so.2 = /lib/libdl.so.2 (0x00dad000) libdrm.so.2 = /usr/local/mesa/lib/libdrm.so.2 (0x0023e000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x00248000) libm.so.6 = /lib/libm.so.6 (0x00aa4000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x008f5000) libc.so.6 = /lib/libc.so.6 (0x003da000) libxcb.so.1 = /usr/lib/libxcb.so.1 (0x0011) /lib/ld-linux.so.2 (0x0085f000) librt.so.1 = /lib/librt.so.1 (0x0012e000) libXau.so.6 = /usr/lib/libXau.so.6 (0x00137000) Note that neither one of the above libraries is mentioned in your ldd output, which means libGL was linked incorrectly. What method did you use to build Mesa? - ajax signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] glx: Use AM_CPPFLAGS to pass -I and -D to both C and C++ compiles.
On Mon, 2012-04-16 at 16:59 -0700, Eric Anholt wrote: --- tests/glx/Makefile.am |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/tests/glx/Makefile.am b/tests/glx/Makefile.am index f5581d6..7f93fd7 100644 --- a/tests/glx/Makefile.am +++ b/tests/glx/Makefile.am @@ -1,10 +1,8 @@ -INC = \ +AM_CPPFLAGS = \ -I$(top_builddir)/src/gtest/include \ -I$(top_builddir)/src/mapi \ - -I$(top_builddir)/src/glx - -AM_CFLAGS = $(INC) $(X11_CFLAGS) -AM_CXXFLAGS = $(INC) $(X11_CFLAGS) + -I$(top_builddir)/src/glx \ + $(X11_CFLAGS) if HAVE_XCB_GLX_CREATE_CONTEXT TESTS = glx_unittest Reviewed-by: Adam Jackson a...@redhat.com - ajax signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL 1.40 and fixed function
On 04/16/2012 12:00 PM, nobled wrote: On Mon, Apr 16, 2012 at 1:01 PM, Paul Berrystereotype...@gmail.com wrote: On 16 April 2012 09:44, Ian Romanicki...@freedesktop.org wrote: Here's my new proposal: * Don't generate a linker error or warning for incomplete programs. * For draw calls that use incomplete programs, drop the rendering on the floor and emit a message to the debug log. That makes sense as a conservative approach. If it's truly undefined behaviour, then emitting INVALID_OPERATION would also be legal. I'm surprised that isn't required, since there's already something *almost* like that anyway in the standard for *other* conditions that make a program non useable-- validation is done when the first rendering command is issued, to determine if the currently active program object can be executed. If it cannot be executed then no fragments will be rendered, and the error INVALID_OPERATION will be generated. We generally avoid Begin-time error checks. People rarely check for them (though GL_ARB_debug changes this a bit), and they add cost in cases where the programmer hasn't made an error. The error that you've quoted, IIRC, refers to checking sampler settings. The driver has to do that check (or make the GPU crash), so generating the error causes no additional overhead. A point of clarification: if the program is incomplete because it lacks a fragment shader, is transform feedback expected to work? My read of the spec is that the phrase the results of fragment shader execution are undefined means that transform feedback is still expected to work in this situation. So we need to make sure that we only drop fragments on the floor, not vertices. Yep-- page 71/84 section 2.11.7 Shader Execution: Undefined behavior results if the program object in use has no fragment shader unless transform feedback is enabled, in which case only a vertex shader is re- quired. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC][PATCH 00/11] gallium: Basic compute infrastructure.
Jose Fonseca jfons...@vmware.com writes: Francisco, Sorry for the delay reviewing this, but I haven't been able to dedicate some time until now. Overall, it's a great piece of work! Just a few relatively minor comments/requests. Hi Jose, thanks for the comments. [...] gallium/tgsi: Add support for raw resources. What's the difference between raw resources and buffers? Shouldn't all buffers be raw, and non-buffers resources non-row? The difference is that raw resources have no associated data type, so there's no type conversion between what the shader sees and what ends up stored in memory. This is somewhat orthogonal to the number of addressing dimensions of the resource, so you can get raw 2D textures, 3D textures, etc. You're right that CL only uses raw buffers right now, but D3D11 makes a similar distinction and both raw and non-raw buffers are likely to be useful if someone tries to implement ByteAddressBuffers and Buffers, respectively. [...] gallium/compute: Drop TGSI dependency. This fine in principle, but I don't understand what PIPE_COMPUTE_CAP_IR_TARGET's triplets are supposed to be (a string?), Yes, it's supposed to be a null-terminated string containing a target triple specification in the standard form many compilers understand, as documented in screen.rst. and how would this scheme work, e.g., if a driver wanted to consume GLSL IR in the future. Hm, I'm not convinced that letting a driver consume GLSL IR would be a good idea in itself. It opens the door to a situation where each driver has to provide a compiler front-end for each individual API it aims to support, and it would break with the principle of having API-agnostic drivers running under a hardware-agnostic state tracker. IMHO, in an ideal world we'd have one common transport IR all drivers would be comfortable with, otherwise you get a matrix of code paths that is likely to get more and more painful to debug and maintain as the number of drivers and state trackers grows. As AMD didn't seem to be willing to use TGSI directly in their compute stack, the purpose of this change was to simplify the driver code in cases where the front-end compiler already happens to support the native binary format required by the pipe driver, so, right now PIPE_COMPUTE_CAP_IR_TARGET can be either tgsi or the hardware's native binary format. I think that an enum would be preferrable. I'm OK with changing it to an enum if you think it would be preferable. What made me decide for a string was that if it were to be an enum, we would need to have hardware-specific enum values (e.g. PIPE_COMPUTE_CAP_IR_TARGET_AMD_R700), and the state trackers would need driver-specific code to make a proper interpretation of it. If it's a string in some standard form the state tracker can just pass it on to the compiler without looking inside. Jose pgpkDyz4Q48Av.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: add a couple fast-paths to fast_read_rgba_pixels_memcpy()
Accelerates a few glReadPixels cases for WebGL.
See https://bugs.freedesktop.org/show_bug.cgi?id=48545
Note: This is a candidate for the 8.0 branch.
---
src/mesa/main/readpix.c | 61 +-
1 files changed, 54 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 4918549..ace1c8e 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -208,6 +208,11 @@ read_stencil_pixels( struct gl_context *ctx,
ctx-Driver.UnmapRenderbuffer(ctx, rb);
}
+
+/**
+ * Try to do glReadPixels of RGBA data using a simple memcpy or swizzle.
+ * \return GL_TRUE if successful, GL_FALSE otherwise (use the slow path)
+ */
static GLboolean
fast_read_rgba_pixels_memcpy( struct gl_context *ctx,
GLint x, GLint y,
@@ -220,9 +225,23 @@ fast_read_rgba_pixels_memcpy( struct gl_context *ctx,
struct gl_renderbuffer *rb = ctx-ReadBuffer-_ColorReadBuffer;
GLubyte *dst, *map;
int dstStride, stride, j, texelBytes;
-
- if (!_mesa_format_matches_format_and_type(rb-Format, format, type,
- ctx-Pack.SwapBytes))
+ GLboolean swizzle_rb = GL_FALSE, copy_xrgb = GL_FALSE;
+
+ /* XXX we could check for other swizzle/special cases here as needed */
+ if (rb-Format == MESA_FORMAT_RGBA_REV
+ format == GL_BGRA
+ type == GL_UNSIGNED_INT_8_8_8_8_REV
+ !ctx-Pack.SwapBytes) {
+ swizzle_rb = GL_TRUE;
+ }
+ else if (rb-Format == MESA_FORMAT_XRGB
+ format == GL_BGRA
+ type == GL_UNSIGNED_INT_8_8_8_8_REV
+ !ctx-Pack.SwapBytes) {
+ copy_xrgb = GL_TRUE;
+ }
+ else if (!_mesa_format_matches_format_and_type(rb-Format, format, type,
+ ctx-Pack.SwapBytes))
return GL_FALSE;
/* If the format is unsigned normalized then we can ignore clamping
@@ -247,10 +266,38 @@ fast_read_rgba_pixels_memcpy( struct gl_context *ctx,
}
texelBytes = _mesa_get_format_bytes(rb-Format);
- for (j = 0; j height; j++) {
- memcpy(dst, map, width * texelBytes);
- dst += dstStride;
- map += stride;
+
+ if (swizzle_rb) {
+ /* swap R/B */
+ for (j = 0; j height; j++) {
+ int i;
+ for (i = 0; i width; i++) {
+dst[i*4+0] = map[i*4+2];
+dst[i*4+1] = map[i*4+1];
+dst[i*4+2] = map[i*4+0];
+dst[i*4+3] = map[i*4+3];
+ }
+ dst += dstStride;
+ map += stride;
+ }
+ } else if (copy_xrgb) {
+ /* convert xrgb - argb */
+ for (j = 0; j height; j++) {
+ GLuint *dst4 = (GLuint *) dst, *map4 = (GLuint *) map;
+ int i;
+ for (i = 0; i width; i++) {
+dst4[i] = map4[i] | 0xff00; /* set A=0xff */
+ }
+ dst += dstStride;
+ map += stride;
+ }
+ } else {
+ /* just memcpy */
+ for (j = 0; j height; j++) {
+ memcpy(dst, map, width * texelBytes);
+ dst += dstStride;
+ map += stride;
+ }
}
ctx-Driver.UnmapRenderbuffer(ctx, rb);
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] r600g: Add hooks for the LLVM backend
Hi, This patch series adds the necessary hooks, so that r600g can use the LLVM backend for graphics shaders. To use the LLVM backend just add --enable-r600-llvm-compiler to your configure flags. The LLVM backend for graphics is still experimental, and it currently has to fallback to the default compiler in order to handle indirect addressing. With that fallback it passes 5464/5641 piglit tests vs 5511/5641 with the default compiler. Besides indirect addressing, the biggest thing missing from the backend is support for most of the texturing instructions. At the moment, I do not have any plans to improve support for graphics in the LLVM backend, but I wanted to get these patches merged into master to give people who are interested a chance to hack on it. -Tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] configure.ac: Move HAVE_LLVM definition into configure.ac
Otherwise HAVE_LLVM won't be included in the $(DEFINES) variable for
Automake generated Makefiles.
---
configs/autoconf.in |4
configure.ac|2 +-
2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/configs/autoconf.in b/configs/autoconf.in
index ec3f319..eb6713d 100644
--- a/configs/autoconf.in
+++ b/configs/autoconf.in
@@ -217,9 +217,5 @@ WAYLAND_LIBS = @WAYLAND_LIBS@
MESA_LLVM = @MESA_LLVM@
LLVM_VERSION = @LLVM_VERSION@
-ifneq ($(LLVM_VERSION),)
- HAVE_LLVM := 0x0$(subst .,0,$(LLVM_VERSION:svn=))
- DEFINES += -DHAVE_LLVM=$(HAVE_LLVM)
-endif
HAVE_XF86VIDMODE = @HAVE_XF86VIDMODE@
diff --git a/configure.ac b/configure.ac
index 4f84b77..c5514b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1805,7 +1805,7 @@ if test x$enable_gallium_llvm = xyes; then
LLVM_BINDIR=`$LLVM_CONFIG --bindir`
LLVM_CXXFLAGS=`$LLVM_CONFIG --cxxflags`
LLVM_INCLUDEDIR=`$LLVM_CONFIG --includedir`
- DEFINES=$DEFINES -D__STDC_CONSTANT_MACROS
+ DEFINES=${DEFINES} -DHAVE_LLVM=`echo $LLVM_VERSION | sed -e
's/\([[0-9]]\)\.\([[0-9]]\)/0x0\10\2/g'`
MESA_LLVM=1
else
MESA_LLVM=0
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] r600g: fix gpr number calculation
From: Vadim Girlin vadimgir...@gmail.com
Signed-off-by: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/r600/r600_asm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index 3298386..0ecca36 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@ -290,6 +290,9 @@ int r600_bytecode_add_output(struct r600_bytecode *bc,
const struct r600_bytecod
{
int r;
+ if (output-gpr = bc-ngpr)
+ bc-ngpr = output-gpr + 1;
+
if (bc-cf_last (bc-cf_last-inst == output-inst ||
(bc-cf_last-inst == BC_INST(bc,
V_SQ_CF_ALLOC_EXPORT_WORD1_SQ_CF_INST_EXPORT)
output-inst == BC_INST(bc,
V_SQ_CF_ALLOC_EXPORT_WORD1_SQ_CF_INST_EXPORT_DONE)))
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] radeon: Move radeon_llvm_emit.cpp declarations into their own header
---
src/gallium/drivers/radeon/loader.cpp |2 +-
src/gallium/drivers/radeon/radeon_llvm.h| 20 +---
src/gallium/drivers/radeon/radeon_llvm_emit.cpp |2 +-
src/gallium/drivers/radeon/radeon_llvm_emit.h | 52 +++
4 files changed, 57 insertions(+), 19 deletions(-)
create mode 100644 src/gallium/drivers/radeon/radeon_llvm_emit.h
diff --git a/src/gallium/drivers/radeon/loader.cpp
b/src/gallium/drivers/radeon/loader.cpp
index 5b46cad..1eae173 100644
--- a/src/gallium/drivers/radeon/loader.cpp
+++ b/src/gallium/drivers/radeon/loader.cpp
@@ -1,5 +1,5 @@
-#include radeon_llvm.h
+#include radeon_llvm_emit.h
#include llvm/Support/CommandLine.h
#include llvm/Support/IRReader.h
diff --git a/src/gallium/drivers/radeon/radeon_llvm.h
b/src/gallium/drivers/radeon/radeon_llvm.h
index 14c9ecb..9be7f90 100644
--- a/src/gallium/drivers/radeon/radeon_llvm.h
+++ b/src/gallium/drivers/radeon/radeon_llvm.h
@@ -24,8 +24,8 @@
*
*/
-#ifndef LLVM_GPU_H
-#define LLVM_GPU_H
+#ifndef RADEON_LLVM_H
+#define RADEON_LLVM_H
#include llvm-c/Core.h
#include gallivm/lp_bld_init.h
@@ -36,10 +36,6 @@
#define RADEON_LLVM_MAX_BRANCH_DEPTH 16
#define RADEON_LLVM_MAX_LOOP_DEPTH 16
-#ifdef __cplusplus
-extern C {
-#endif
-
struct radeon_llvm_branch {
LLVMBasicBlockRef endif_block;
LLVMBasicBlockRef if_block;
@@ -109,13 +105,6 @@ struct radeon_llvm_context {
struct gallivm_state gallivm;
};
-unsigned radeon_llvm_compile(
- LLVMModuleRef M,
- unsigned char ** bytes,
- unsigned * byte_count,
- const char * gpu_family,
- unsigned dump);
-
void radeon_llvm_context_init(struct radeon_llvm_context * ctx);
void radeon_llvm_dispose(struct radeon_llvm_context * ctx);
@@ -130,7 +119,4 @@ unsigned radeon_llvm_reg_index_soa(unsigned index, unsigned
chan);
void radeon_llvm_finalize_module(struct radeon_llvm_context * ctx);
-#ifdef __cplusplus
-}
-#endif
-#endif /* LLVM_GPU_H */
+#endif /* RADEON_LLVM_H */
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.cpp
b/src/gallium/drivers/radeon/radeon_llvm_emit.cpp
index 04fd6dd..b482569 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_emit.cpp
+++ b/src/gallium/drivers/radeon/radeon_llvm_emit.cpp
@@ -23,7 +23,7 @@
* Authors: Tom Stellard thomas.stell...@amd.com
*
*/
-#include radeon_llvm.h
+#include radeon_llvm_emit.h
#include llvm/LLVMContext.h
#include llvm/Module.h
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.h
b/src/gallium/drivers/radeon/radeon_llvm_emit.h
new file mode 100644
index 000..bdb242b
--- /dev/null
+++ b/src/gallium/drivers/radeon/radeon_llvm_emit.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2012 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ * Authors: Tom Stellard thomas.stell...@amd.com
+ *
+ */
+
+#ifndef RADEON_LLVM_EMIT_H
+#define RADEON_LLVM_EMIT_H
+
+#include llvm-c/Core.h
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+unsigned radeon_llvm_bitcode_compile(
+ unsigned char * bitcode, unsigned bitcode_len,
+ unsigned char ** bytes, unsigned * byte_count,
+ const char * gpu_family, unsigned dump);
+
+unsigned radeon_llvm_compile(
+ LLVMModuleRef M,
+ unsigned char ** bytes,
+ unsigned * byte_count,
+ const char * gpu_family,
+ unsigned dump);
+
+#ifdef __cplusplus
+} /* Extern C */
+#endif
+
+#endif /* RADEON_LLVM_EMIT_H */
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] r600g: Add TGSI-LLVM implementation
---
src/gallium/drivers/r600/r600_llvm.c | 300 ++
src/gallium/drivers/r600/r600_llvm.h | 29
2 files changed, 329 insertions(+), 0 deletions(-)
create mode 100644 src/gallium/drivers/r600/r600_llvm.c
create mode 100644 src/gallium/drivers/r600/r600_llvm.h
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
new file mode 100644
index 000..267fb19
--- /dev/null
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -0,0 +1,300 @@
+#include r600_llvm.h
+
+#include gallivm/lp_bld_const.h
+#include gallivm/lp_bld_intr.h
+#include gallivm/lp_bld_gather.h
+#include tgsi/tgsi_parse.h
+#include util/u_double_list.h
+
+#include r600.h
+#include r600_asm.h
+#include r600_opcodes.h
+#include r600_shader.h
+#include radeon_llvm.h
+#include radeon_llvm_emit.h
+
+#include stdio.h
+
+static LLVMValueRef llvm_fetch_const(
+ struct lp_build_tgsi_context * bld_base,
+ const struct tgsi_full_src_register *reg,
+ enum tgsi_opcode_type type,
+ unsigned swizzle)
+{
+ return lp_build_intrinsic_unary(bld_base-base.gallivm-builder,
+ llvm.AMDGPU.load.const, bld_base-base.elem_type,
+ lp_build_const_int32(bld_base-base.gallivm,
+ radeon_llvm_reg_index_soa(reg-Register.Index, swizzle)));
+}
+
+static void llvm_load_input(
+ struct radeon_llvm_context * ctx,
+ unsigned input_index,
+ const struct tgsi_full_declaration *decl)
+{
+ unsigned chan;
+
+ for (chan = 0; chan 4; chan++) {
+ unsigned soa_index = radeon_llvm_reg_index_soa(input_index,
+ chan);
+
+ /* The * 4 is assuming that we are in soa mode. */
+ LLVMValueRef reg = lp_build_const_int32(
+ ctx-soa.bld_base.base.gallivm,
+ soa_index + (ctx-reserved_reg_count * 4));
+ ctx-inputs[soa_index] = lp_build_intrinsic_unary(
+ ctx-soa.bld_base.base.gallivm-builder,
+ llvm.R600.load.input,
+ ctx-soa.bld_base.base.elem_type, reg);
+ }
+}
+
+static void llvm_emit_prologue(struct lp_build_tgsi_context * bld_base)
+{
+ struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
+ struct lp_build_context * base = bld_base-base;
+ unsigned i;
+
+ /* Reserve special input registers */
+ for (i = 0; i ctx-reserved_reg_count; i++) {
+ unsigned chan;
+ for (chan = 0; chan TGSI_NUM_CHANNELS; chan++) {
+ LLVMValueRef reg;
+ LLVMValueRef reg_index = lp_build_const_int32(
+ base-gallivm,
+ radeon_llvm_reg_index_soa(i, chan));
+ reg = lp_build_intrinsic_unary(base-gallivm-builder,
+ llvm.AMDGPU.reserve.reg,
+ base-elem_type, reg_index);
+ lp_build_intrinsic_unary(base-gallivm-builder,
+ llvm.AMDGPU.export.reg,
+ LLVMVoidTypeInContext(base-gallivm-context),
+ reg);
+ }
+ }
+}
+
+static void llvm_emit_epilogue(struct lp_build_tgsi_context * bld_base)
+{
+ struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
+ struct lp_build_context * base = bld_base-base;
+ unsigned i;
+
+ /* Add the necessary export instructions */
+ for (i = 0; i ctx-output_reg_count; i++) {
+ unsigned chan;
+ for (chan = 0; chan TGSI_NUM_CHANNELS; chan++) {
+ LLVMValueRef output;
+ LLVMValueRef store_output;
+ unsigned adjusted_reg_idx = i +
+ ctx-reserved_reg_count;
+ LLVMValueRef reg_index = lp_build_const_int32(
+ base-gallivm,
+ radeon_llvm_reg_index_soa(adjusted_reg_idx,
chan));
+
+ output = LLVMBuildLoad(base-gallivm-builder,
+ ctx-soa.outputs[i][chan], );
+
+ store_output = lp_build_intrinsic_binary(
+ base-gallivm-builder,
+ llvm.AMDGPU.store.output,
+ base-elem_type,
+ output, reg_index);
+
+ lp_build_intrinsic_unary(base-gallivm-builder,
+ llvm.AMDGPU.export.reg,
+ LLVMVoidTypeInContext(base-gallivm-context),
+ store_output);
+ }
+ }
+}
+
+static void llvm_emit_tex(
+
[Mesa-dev] [PATCH 6/6] r600g: Add hooks for the LLVM shader compiler
The LLVM backend can now be enabled for r600g by using the
--enable-r600-llvm-compiler configure flag. If you configure with this
flag, you can still use the default compiler by setting the envrionment
variable R600_USE_LLVM=0
---
configure.ac | 14 ++
src/gallium/drivers/r600/Makefile.am | 24 +++
src/gallium/drivers/r600/Makefile.sources |2 +
src/gallium/drivers/r600/r600_shader.c| 280 -
4 files changed, 318 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index c5514b9..a70d1b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -637,6 +637,12 @@ AC_ARG_ENABLE([gallium_gbm],
[enable_gallium_gbm=$enableval],
[enable_gallium_gbm=auto])
+AC_ARG_ENABLE([r600-llvm-compiler],
+[AS_HELP_STRING([--enable-r600-llvm-compilerl],
+[Enable experimental LLVM backend for graphics shaders
@:default=disable@:@])],
+[enable_r600_llvm=$enableval],
+[enable_r600_llvm=no])
+
# Option for Gallium drivers
GALLIUM_DRIVERS_DEFAULT=r300,r600,svga,swrast
@@ -1906,6 +1912,13 @@ if test x$with_gallium_drivers != x; then
xr600)
PKG_CHECK_MODULES([RADEON], [libdrm_radeon =
$LIBDRM_RADEON_REQUIRED])
GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS r600
+if test x$enable_r600_llvm = xyes; then
+if test x$LLVM_VERSION != x3.1; then
+AC_MSG_ERROR([LLVM 3.1 is required for the r600 llvm
compiler.])
+fi
+NEED_RADEON_GALLIUM=yes;
+USE_R600_LLVM_COMPILER=yes;
+fi
gallium_check_st radeon/drm dri-r600 xorg-r600
xvmc-r600 vdpau-r600 va-r600
;;
xradeonsi)
@@ -1976,6 +1989,7 @@ AM_CONDITIONAL(HAVE_GALAHAD_GALLIUM, test
x$HAVE_GALAHAD_GALLIUM = xyes)
AM_CONDITIONAL(HAVE_IDENTITY_GALLIUM, test x$HAVE_IDENTITY_GALLIUM = xyes)
AM_CONDITIONAL(HAVE_NOOP_GALLIUM, test x$HAVE_NOOP_GALLIUM = xyes)
AM_CONDITIONAL(NEED_RADEON_GALLIUM, test x$NEED_RADEON_GALLIUM = xyes)
+AM_CONDITIONAL(USE_R600_LLVM_COMPILER, test x$USE_R600_LLVM_COMPILER = xyes)
AC_SUBST([GALLIUM_MAKE_DIRS])
dnl prepend CORE_DIRS to SRC_DIRS
diff --git a/src/gallium/drivers/r600/Makefile.am
b/src/gallium/drivers/r600/Makefile.am
index 8acd36a..a567f07 100644
--- a/src/gallium/drivers/r600/Makefile.am
+++ b/src/gallium/drivers/r600/Makefile.am
@@ -15,3 +15,27 @@ AM_CFLAGS = \
libr600_a_SOURCES = \
$(C_SOURCES)
+
+if USE_R600_LLVM_COMPILER
+
+# This is a hack until we can move the backend into the LLVM project.
+# We need to use mklib, because it splits up libradeon.a into object files
+# so that we can link it with the r600 objects.
+libr600_a_AR = $(top_srcdir)/bin/mklib -o r600 -static
+
+libr600_a_SOURCES += \
+ $(LLVM_C_SOURCES)
+
+libr600_a_LIBADD = \
+ $(top_srcdir)/src/gallium/drivers/radeon/libradeon.a
+
+AM_CFLAGS += \
+ $(LLVM_CFLAGS) \
+ -I$(top_srcdir)/src/gallium/drivers/radeon/ \
+ -DR600_USE_LLVM
+
+AM_CXXFLAGS= \
+ $(LLVM_CXXFLAGS)
+else
+libr600_a_AR = $(AR) $(ARFLAGS)
+endif
diff --git a/src/gallium/drivers/r600/Makefile.sources
b/src/gallium/drivers/r600/Makefile.sources
index e7813ef..a920b93 100644
--- a/src/gallium/drivers/r600/Makefile.sources
+++ b/src/gallium/drivers/r600/Makefile.sources
@@ -15,3 +15,5 @@ C_SOURCES := \
eg_asm.c \
r600_translate.c \
r600_state_common.c
+
+LLVM_C_SOURCES := r600_llvm.c
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 4932dcc..562f27b 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -21,14 +21,18 @@
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#include r600_sq.h
+#include r600_llvm.h
#include r600_formats.h
#include r600_opcodes.h
#include r600d.h
+#include pipe/p_shader_tokens.h
#include tgsi/tgsi_info.h
#include tgsi/tgsi_parse.h
#include tgsi/tgsi_scan.h
#include tgsi/tgsi_dump.h
+#include util/u_memory.h
+#include stdio.h
#include errno.h
#include byteswap.h
@@ -205,6 +209,224 @@ struct r600_shader_tgsi_instruction {
static struct r600_shader_tgsi_instruction r600_shader_tgsi_instruction[],
eg_shader_tgsi_instruction[], cm_shader_tgsi_instruction[];
static int tgsi_helper_tempx_replicate(struct r600_shader_ctx *ctx);
+static inline void callstack_check_depth(struct r600_shader_ctx *ctx, unsigned
reason, unsigned check_max_only);
+static void fc_pushlevel(struct r600_shader_ctx *ctx, int type);
+static int tgsi_else(struct r600_shader_ctx *ctx);
+static int tgsi_endif(struct r600_shader_ctx *ctx);
+static int tgsi_bgnloop(struct r600_shader_ctx *ctx);
+static int tgsi_endloop(struct r600_shader_ctx *ctx);
+static int tgsi_loop_brk_cont(struct r600_shader_ctx *ctx);
+
+/*
+ * bytestream - r600 shader
+ *
+ * These functions are used to transform the output of the LLVM backend into
+ * struct r600_bytecode.
+ */
+
+static
[Mesa-dev] [Bug 48833] New: dri library path issue
https://bugs.freedesktop.org/show_bug.cgi?id=48833 Bug #: 48833 Summary: dri library path issue Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: freedesk...@behdad.org I'm not sure why I didn't have this problem before. Anyway, I'm installing mesa to ~/.local, which means dri drivers are installed in ~/.local/dri. Mesa correctly finds the drivers (eg. ~/.local/lib/dri/i965_dri.so), but dlopen fails loading the driver since it fails to find libdricore.so and other libraries in that directory because ~/.local/lib/dri is not in my LD_LIBRARY_PATH, only ~/.local/lib is. I think the libdricore.so and libglsl.so should be installed to $libdir, and only the modules to $libdir/dri. -- 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] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Tue, 17 Apr 2012 05:51:23 -0700 (PDT), Benoit Jacob bja...@mozilla.com
wrote:
In the WebGL WG, we need to have WebGL 1.0.1 conformance tests fully
passing on multiple, real drivers, before we can claim that WebGL has
conformant implementations.
So we are trying to get people to run these conformance tests on
development versions of their favorite browsers, using recent drivers:
http://www.khronos.org/webgl/wiki/CrowdsourcingDriverTesting
It would be great to see some more results with Mesa 8.0.2 or 8.1-git.
Note: if you are using Firefox for testing, please use today
(20120417)'s Nightly build, as some important fixes/workarounds just
landed.
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html: 1
tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false, alpha: false,
antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was false.
Is this assuming that MSAA is available? If it's looking for MSAA
visuals, we don't expose those and it would be webgl's problem. If it's
looking for msaa renderbuffers, we're lying about those and it's our
problem. But either way, we're working on exposing MSAA as a high
priority task currently.
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-use formerly good program, with new bad
shader attached
FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing with a
valid program shouldn't generate a GL error
This sounded like it was going to be a Mesa bug, but this testcase
passes:
{
...
glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
good_fs = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
good_fs_source);
prog = piglit_link_simple_program(vs, good_fs);
if (!vs || !good_fs || !prog)
piglit_report_result(PIGLIT_FAIL);
glUseProgram(prog);
piglit_draw_rect(-1, -1, 1, 2);
bad_fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(bad_fs, 1, (const GLchar **) bad_fs_source, NULL);
glCompileShader(bad_fs);
glGetShaderiv(bad_fs, GL_COMPILE_STATUS, ok);
if (ok)
piglit_report_result(PIGLIT_FAIL);
glAttachShader(prog, bad_fs);
piglit_draw_rect(0, -1, 1, 2);
pass = piglit_probe_rect_rgba(0, 0,
piglit_width, piglit_height,
green);
...
}
Is it possible to run just a subtest? It would be nice to apitrace
what's going on in this testcase, but if I run the whole test I won't be
able to find where the failure was in the trace.
conformance/renderbuffers/framebuffer-object-attachment.html: 3 tests failed
Create and attach depthStencil renderbuffer
PASS depthStencilBuffer = gl.createRenderbuffer() is non-null.
PASS getError was expected value: NO_ERROR :
PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_WIDTH) is
width
PASS gl.getRenderbufferParameter(gl.RENDERBUFFER, gl.RENDERBUFFER_HEIGHT) is
height
FAIL gl.getRenderbufferParameter(gl.RENDERBUFFER,
gl.RENDERBUFFER_INTERNAL_FORMAT) should be 34041. Was 0.
[ and 2 others of this sort ]
I bet this will be our failure. We don't have test coverage for
GL_RENDERBUFFER_INTERNAL_FORMAT in piglit, which I'll try to fix.
conformance/textures/tex-image-and-sub-image-2d-with-image.html: 8
tests failed
I'm not sure what code path this is.
---
text results summary:
WebGL Conformance Test Results
Version 1.0.1
---
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120417
Firefox/14.0a1
WebGL VENDOR: Mozilla
WebGL VERSION: WebGL 1.0
WebGL RENDERER: Mozilla
Unmasked VENDOR: undefined
Unmasked RENDERER: undefined
WebGL R/G/B/A/Depth/Stencil bits (default config): 8/8/8/8/24/0
---
Test Summary (8879 total tests):
Tests PASSED: 8866
Tests FAILED: 13
Tests TIMED OUT: 0
---
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html: 1
tests failed
conformance/programs/program-test.html: 1 tests failed
conformance/renderbuffers/framebuffer-object-attachment.html: 3 tests failed
conformance/textures/tex-image-and-sub-image-2d-with-image.html: 8 tests failed
---
Complete Test Results (total / pass / fail / timeout):
conformance/attribs/gl-enable-vertex-attrib.html: 3 / 3 / 0 / 0
conformance/attribs/gl-vertex-attrib-zero-issues.html: 14 / 14 / 0 / 0
conformance/attribs/gl-vertex-attrib.html: 515 / 515 / 0 / 0
conformance/attribs/gl-vertexattribpointer-offsets.html: 451 / 451 / 0 / 0
conformance/attribs/gl-vertexattribpointer.html: 782 / 782 / 0 / 0
conformance
[Mesa-dev] [Bug 48788] Mesa after 7.11.2 won't use hardware for OpenGL acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=48788 --- Comment #14 from russian...@gmail.com russian...@gmail.com 2012-04-17 11:22:47 PDT --- Created attachment 60205 -- https://bugs.freedesktop.org/attachment.cgi?id=60205 Build and use log of latest mesa-git for Michel -- 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 48788] Mesa after 7.11.2 won't use hardware for OpenGL acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=48788 --- Comment #15 from russian...@gmail.com russian...@gmail.com 2012-04-17 11:23:35 PDT --- I've published information, requested by Michel. Here is configure, build and some tests log in one file. I hope this time he won't be so fast on closing bugs :) -- 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/2] glsl: Support GL_ARB_shading_language_include internally.
Hi, I definitely like the idea of refactoring and cleaning up the built-in profiles...they're definitely huge and out of control. That said, I don't think ARB_shading_language_include is really the mechanism to do that. As Ian pointed out, #include in GLSL isn't supposed to offer any kind of filesystem access...and I'd prefer not to implement -more- standalone compiler complexity just to support built-ins. (They're complex enough as it is...) I've come up with an alternate approach that achieves basically the same effect with ~4 lines of change to generate_builtins.py. So I suppose the question is: do we want to support ARB_shading_language_include in GLSL? If so, we ought to be able to use your patch as a starting point. My initial feeling is that I'd rather see AMD, nVidia, or Apple implement it first (and I don't think they have), since the extension is rather odd...especially the whole path-handling feature. Unless they support it, it's unlikely to see much use... --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glsl: Support GL_ARB_shading_language_include internally.
On 04/17/2012 12:38 PM, Kenneth Graunke wrote: Hi, I definitely like the idea of refactoring and cleaning up the built-in profiles...they're definitely huge and out of control. That said, I don't think ARB_shading_language_include is really the mechanism to do that. As Ian pointed out, #include in GLSL isn't supposed to offer any kind of filesystem access...and I'd prefer not to implement -more- standalone compiler complexity just to support built-ins. (They're complex enough as it is...) I've come up with an alternate approach that achieves basically the same effect with ~4 lines of change to generate_builtins.py. So I suppose the question is: do we want to support ARB_shading_language_include in GLSL? If so, we ought to be able to use your patch as a starting point. My initial feeling is that I'd rather see AMD, nVidia, or Apple implement it first (and I don't think they have), NVIDIA has it in their 295.33 driver, at least. since the extension is rather odd...especially the whole path-handling feature. Unless they support it, it's unlikely to see much use... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] glsl: Make the standalone compiler accept '.glsl' files.
These ought to be treated as 'any stage', but for now, they're just treated as vertex shaders. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/glsl/main.cpp |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Needed for the next patch. Otherwise, I'd have to copy .glsl files to a temporary .vert or .frag file, which is doable but just ugly. This seems less ugly and we can turn it into proper 'generic' shader support someday. diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp index d43bf1a..3231b1b 100644 --- a/src/glsl/main.cpp +++ b/src/glsl/main.cpp @@ -238,7 +238,7 @@ main(int argc, char **argv) usage_fail(argv[0]); const char *const ext = argv[optind][len - 5]; - if (strncmp(.vert, ext, 5) == 0) + if (strncmp(.vert, ext, 5) == 0 || strncmp(.glsl, ext, 5) == 0) shader-Type = GL_VERTEX_SHADER; else if (strncmp(.geom, ext, 5) == 0) shader-Type = GL_GEOMETRY_SHADER; -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Cut 2903 lines from the built-in profile madness.
This series is inspired by Olivier's shading language include series, which nuked a zillion lines from the built-in profiles. However, this one does it in 4 lines of Python and should reduce startup time a little as well. I was actually surprised it turned out this simple. I'd originally devised something far more complicated and couldn't get it to work. Then I realized that all the infrastructure was already all in place, deleted all the complexity, and everything worked... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Cut 2903 lines from the built-in profile madness.
On 04/17/2012 12:45 PM, Kenneth Graunke wrote: This series is inspired by Olivier's shading language include series, which nuked a zillion lines from the built-in profiles. However, this one does it in 4 lines of Python and should reduce startup time a little as well. I was actually surprised it turned out this simple. I'd originally devised something far more complicated and couldn't get it to work. Then I realized that all the infrastructure was already all in place, deleted all the complexity, and everything worked... Looks great. Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message -
On Tue, 17 Apr 2012 05:51:23 -0700 (PDT), Benoit Jacob
bja...@mozilla.com wrote:
In the WebGL WG, we need to have WebGL 1.0.1 conformance tests
fully
passing on multiple, real drivers, before we can claim that WebGL
has
conformant implementations.
So we are trying to get people to run these conformance tests on
development versions of their favorite browsers, using recent
drivers:
http://www.khronos.org/webgl/wiki/CrowdsourcingDriverTesting
It would be great to see some more results with Mesa 8.0.2 or
8.1-git.
Note: if you are using Firefox for testing, please use today
(20120417)'s Nightly build, as some important fixes/workarounds
just
landed.
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
1 tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false, alpha:
false, antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was false.
Is this assuming that MSAA is available?
Ouch. Yes, this test is effectively requiring MSAA. It's a bug in the test: in
WebGL, anti-aliasing is a hint, not a requirement. We'll fix this very soon in
the WebGL conformance tests, but it's too late for the 1.0.1 version
unfortunately. Very unfortunate that we didn't catch this earlier.
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-use formerly good program, with
new bad shader attached
FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing
with a
valid program shouldn't generate a GL error
This sounded like it was going to be a Mesa bug, but this testcase
passes:
{
...
glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
good_fs = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
good_fs_source);
prog = piglit_link_simple_program(vs, good_fs);
if (!vs || !good_fs || !prog)
piglit_report_result(PIGLIT_FAIL);
glUseProgram(prog);
piglit_draw_rect(-1, -1, 1, 2);
bad_fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(bad_fs, 1, (const GLchar **) bad_fs_source, NULL);
glCompileShader(bad_fs);
glGetShaderiv(bad_fs, GL_COMPILE_STATUS, ok);
if (ok)
piglit_report_result(PIGLIT_FAIL);
glAttachShader(prog, bad_fs);
piglit_draw_rect(0, -1, 1, 2);
pass = piglit_probe_rect_rgba(0, 0,
piglit_width, piglit_height,
green);
...
}
Is it possible to run just a subtest?
You can run each page individually using its URL, e.g.
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/programs/program-test.html
But we don't have a simple way of running less than that without editing the
pages. That's fairly easy though. Just svn checkout the test suite:
svn checkout https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl
The 1.0.1 tests are under conformance-suites/1.0.1
If you run this locally as a file:// URL, you'll need to tell your browser to
be lax with the same-origin policy. In Firefox, go to about:config and set
security.fileuri.strict_origin_policy=false. Alternatively, a better solution
is to run your own HTTP server, which is very simple: in the directory you want
to serve, run:
$ python -m SimpleHTTPServer
This will serve the current directory on http://127.0.0.1:8000
It would be nice to apitrace
what's going on in this testcase, but if I run the whole test I won't
be
able to find where the failure was in the trace.
So you could edit the testcase by running it locally as explained above; in
addition to triming it, you could insert dummy unusual GL calls as markers,
e.g. using webgl.polygonOffset().
conformance/renderbuffers/framebuffer-object-attachment.html: 3
tests failed
Create and attach depthStencil renderbuffer
PASS depthStencilBuffer = gl.createRenderbuffer() is non-null.
PASS getError was expected value: NO_ERROR :
PASS gl.getRenderbufferParameter(gl.RENDERBUFFER,
gl.RENDERBUFFER_WIDTH) is width
PASS gl.getRenderbufferParameter(gl.RENDERBUFFER,
gl.RENDERBUFFER_HEIGHT) is height
FAIL gl.getRenderbufferParameter(gl.RENDERBUFFER,
gl.RENDERBUFFER_INTERNAL_FORMAT) should be 34041. Was 0.
[ and 2 others of this sort ]
I bet this will be our failure. We don't have test coverage for
GL_RENDERBUFFER_INTERNAL_FORMAT in piglit, which I'll try to fix.
Notice that Firefox implements WebGL DEPTH_STENCIL renderbuffer using OpenGL
DEPTH24_STENCIL8 renderbuffers. This isn't 100% universally supported, as in
theory
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message -
- Original Message -
On Tue, 17 Apr 2012 05:51:23 -0700 (PDT), Benoit Jacob
bja...@mozilla.com wrote:
In the WebGL WG, we need to have WebGL 1.0.1 conformance tests
fully
passing on multiple, real drivers, before we can claim that WebGL
has
conformant implementations.
So we are trying to get people to run these conformance tests on
development versions of their favorite browsers, using recent
drivers:
http://www.khronos.org/webgl/wiki/CrowdsourcingDriverTesting
It would be great to see some more results with Mesa 8.0.2 or
8.1-git.
Note: if you are using Firefox for testing, please use today
(20120417)'s Nightly build, as some important fixes/workarounds
just
landed.
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
1 tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false,
alpha:
false, antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was false.
Is this assuming that MSAA is available?
Ouch. Yes, this test is effectively requiring MSAA. It's a bug in the
test: in WebGL, anti-aliasing is a hint, not a requirement. We'll
fix this very soon in the WebGL conformance tests, but it's too late
for the 1.0.1 version unfortunately. Very unfortunate that we didn't
catch this earlier.
Ah no, sorry, this is not a bug in the conformance test, this is purely a
Firefox bug. What happens is that this test is checking that the actual context
attributes match reality. They should. Firefox's bug is that it's returning the
context creation attributes (which have antialias=true) instead of the actual
context attributes. Will fix. Nothing to be done or worry about on your end.
Benoit
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-use formerly good program, with
new bad shader attached
FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing
with a
valid program shouldn't generate a GL error
This sounded like it was going to be a Mesa bug, but this testcase
passes:
{
...
glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
good_fs = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
good_fs_source);
prog = piglit_link_simple_program(vs, good_fs);
if (!vs || !good_fs || !prog)
piglit_report_result(PIGLIT_FAIL);
glUseProgram(prog);
piglit_draw_rect(-1, -1, 1, 2);
bad_fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(bad_fs, 1, (const GLchar **) bad_fs_source, NULL);
glCompileShader(bad_fs);
glGetShaderiv(bad_fs, GL_COMPILE_STATUS, ok);
if (ok)
piglit_report_result(PIGLIT_FAIL);
glAttachShader(prog, bad_fs);
piglit_draw_rect(0, -1, 1, 2);
pass = piglit_probe_rect_rgba(0, 0,
piglit_width, piglit_height,
green);
...
}
Is it possible to run just a subtest?
You can run each page individually using its URL, e.g.
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/programs/program-test.html
But we don't have a simple way of running less than that without
editing the pages. That's fairly easy though. Just svn checkout the
test suite:
svn checkout
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl
The 1.0.1 tests are under conformance-suites/1.0.1
If you run this locally as a file:// URL, you'll need to tell your
browser to be lax with the same-origin policy. In Firefox, go to
about:config and set security.fileuri.strict_origin_policy=false.
Alternatively, a better solution is to run your own HTTP server,
which is very simple: in the directory you want to serve, run:
$ python -m SimpleHTTPServer
This will serve the current directory on http://127.0.0.1:8000
It would be nice to apitrace
what's going on in this testcase, but if I run the whole test I
won't
be
able to find where the failure was in the trace.
So you could edit the testcase by running it locally as explained
above; in addition to triming it, you could insert dummy unusual GL
calls as markers, e.g. using webgl.polygonOffset().
conformance/renderbuffers/framebuffer-object-attachment.html: 3
tests failed
Create and attach depthStencil renderbuffer
PASS depthStencilBuffer = gl.createRenderbuffer() is non-null.
PASS getError was expected value: NO_ERROR :
PASS gl.getRenderbufferParameter(gl.RENDERBUFFER,
gl.RENDERBUFFER_WIDTH) is width
PASS
[Mesa-dev] [PATCH 1/2] i965/fs: Fix texelFetchOffset()
It appears that when using 'ld' with the offset bits, address bounds
checking happens before the offset is applied, so parts of the drawing
in piglit texelFetchOffset() with a negative texcoord go black.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 27 --
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 51c1fd2..1ef3fb3 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -990,8 +990,9 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
int base_mrf = 2;
int reg_width = c-dispatch_width / 8;
bool header_present = false;
+ int offsets[3];
- if (ir-offset) {
+ if (ir-offset ir-op != ir_txf) {
/* The offsets set up by the ir_texture visitor are in the
* m1 header, so we can't go headerless.
*/
@@ -1054,9 +1055,23 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg
dst, fs_reg coordinate,
mlen += reg_width;
break;
case ir_txf:
+ /* It appears that the ld instruction used for txf does its
+ * address bounds check before adding in the offset. To work
+ * around this, just add the integer offset to the integer texel
+ * coordinate, and don't put the offset in the header.
+ */
+ if (ir-offset) {
+ir_constant *offset = ir-offset-as_constant();
+offsets[0] = offset-value.i[0];
+offsets[1] = offset-value.i[1];
+offsets[2] = offset-value.i[2];
+ } else {
+memset(offsets, 0, sizeof(offsets));
+ }
+
/* Unfortunately, the parameters for LD are intermixed: u, lod, v, r. */
- emit(BRW_OPCODE_MOV,
- fs_reg(MRF, base_mrf + mlen, BRW_REGISTER_TYPE_D), coordinate);
+ emit(BRW_OPCODE_ADD,
+ fs_reg(MRF, base_mrf + mlen, BRW_REGISTER_TYPE_D), coordinate,
offsets[0]);
coordinate.reg_offset++;
mlen += reg_width;
@@ -1065,8 +1080,8 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg dst,
fs_reg coordinate,
mlen += reg_width;
for (int i = 1; i ir-coordinate-type-vector_elements; i++) {
-emit(BRW_OPCODE_MOV,
- fs_reg(MRF, base_mrf + mlen, BRW_REGISTER_TYPE_D), coordinate);
+emit(BRW_OPCODE_ADD,
+ fs_reg(MRF, base_mrf + mlen, BRW_REGISTER_TYPE_D), coordinate,
offsets[i]);
coordinate.reg_offset++;
mlen += reg_width;
}
@@ -1128,7 +1143,7 @@ fs_visitor::visit(ir_texture *ir)
ir-coordinate-accept(this);
fs_reg coordinate = this-result;
- if (ir-offset != NULL) {
+ if (ir-offset != NULL !(intel-gen == 7 ir-op == ir_txf)) {
uint32_t offset_bits = brw_texture_offset(ir-offset-as_constant());
/* Explicitly set up the message header by copying g0 to msg reg m1. */
--
1.7.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message - Is it possible to run just a subtest? It would be nice to apitrace what's going on in this testcase, but if I run the whole test I won't be able to find where the failure was in the trace. apitrace/scripts/retracediff.py allows to run against a software renderer, and quickly spot what call the rendering diverges, but given that all available software renderers are based from Mesa, odds are many bugs will appear on both, so not that useful. One of these day's I'll add SSH support to retracediff.py, so that one can eaily compare the rendering against a remote machine (running, e.g., NVIDIA OpenGL), or even a different OS. Of course, this only works if both implementations support the functionality recorded in the trace. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] glsl/builtins: Support stage-agnostic built-in profiles.
On Tue, 17 Apr 2012 11:45:20 -0700, Kenneth Graunke kenn...@whitecape.org wrote: The built-in subsystem uses profiles, or GLSL shaders containing prototypes for all built-ins supported within a particular language version (or extension) and shader stage. Since profiles were stage-specific, we had to cut and paste almost all the prototypes between (e.g.) 110.vert and 110.frag. Naturally, this led to sundry cut and paste bugs, where someone fixed an issue in .frag but neglected to update .vert, or vice-versa. Geometry shaders would have only made this worse. This patch introduces support for a new '.glsl' profile suffix which contains prototypes common to all shader stages. The existing '.frag' and '.vert' profiles need only contain the few stage-specific built-ins. Not only does this remove duplication, it makes built-in setup slightly faster: we don't need to re-read the common prototypes and function bodies for both the vertex and fragment shader stage. Internally, this was trivial. We already create a list of gl_shader objects to search through for built-ins: one for the core language version/stage, and additional shaders for any extensions in use. This patch simply adds another shader to the list: core/common, core/stage, and extensions. The next patch will update the profiles to remove the duplication. It's separated out purely to make review easier. Signed-off-by: Kenneth Graunke kenn...@whitecape.org I like this a lot. It seems like a small change with a big win. I haven't done a line-by-line review of the profiles changes, but I looked for some likely copy-and-paste bugs and didn't find them. So, the series is: Reviewed-by: Eric Anholt e...@anholt.net pgp9CWBUQDbu2.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message -
- Original Message -
- Original Message -
On Tue, 17 Apr 2012 05:51:23 -0700 (PDT), Benoit Jacob
bja...@mozilla.com wrote:
In the WebGL WG, we need to have WebGL 1.0.1 conformance tests
fully
passing on multiple, real drivers, before we can claim that
WebGL
has
conformant implementations.
So we are trying to get people to run these conformance tests
on
development versions of their favorite browsers, using recent
drivers:
http://www.khronos.org/webgl/wiki/CrowdsourcingDriverTesting
It would be great to see some more results with Mesa 8.0.2 or
8.1-git.
Note: if you are using Firefox for testing, please use today
(20120417)'s Nightly build, as some important fixes/workarounds
just
landed.
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
1 tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false,
alpha:
false, antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was
false.
Is this assuming that MSAA is available?
Ouch. Yes, this test is effectively requiring MSAA. It's a bug in
the
test: in WebGL, anti-aliasing is a hint, not a requirement. We'll
fix this very soon in the WebGL conformance tests, but it's too
late
for the 1.0.1 version unfortunately. Very unfortunate that we
didn't
catch this earlier.
Ah no, sorry, this is not a bug in the conformance test, this is
purely a Firefox bug. What happens is that this test is checking
that the actual context attributes match reality. They should.
Firefox's bug is that it's returning the context creation attributes
(which have antialias=true) instead of the actual context
attributes. Will fix. Nothing to be done or worry about on your end.
Sorry for ping-ponging on this but looking closer into this, I'm not so sure
anymore that it's a Firefox bug:
- Firefox does check the actual context format and returns that
- I can't reproduce this test failure here on Mesa 7.11, r600g driver.
So I'm wondering if this could actually be an issue with the Intel driver, or
with Mesa 8 ?
The question is: does Mesa/Intel correctly return 0 for
glGetIntegerv(LOCAL_GL_MAX_SAMPLES, result)?
An APItrace of this test would give the answer.
Benoit
Benoit
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-use formerly good program,
with
new bad shader attached
FAIL getError expected: NO_ERROR. Was INVALID_OPERATION :
drawing
with a
valid program shouldn't generate a GL error
This sounded like it was going to be a Mesa bug, but this
testcase
passes:
{
...
glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
good_fs = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
good_fs_source);
prog = piglit_link_simple_program(vs, good_fs);
if (!vs || !good_fs || !prog)
piglit_report_result(PIGLIT_FAIL);
glUseProgram(prog);
piglit_draw_rect(-1, -1, 1, 2);
bad_fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(bad_fs, 1, (const GLchar **) bad_fs_source,
NULL);
glCompileShader(bad_fs);
glGetShaderiv(bad_fs, GL_COMPILE_STATUS, ok);
if (ok)
piglit_report_result(PIGLIT_FAIL);
glAttachShader(prog, bad_fs);
piglit_draw_rect(0, -1, 1, 2);
pass = piglit_probe_rect_rgba(0, 0,
piglit_width, piglit_height,
green);
...
}
Is it possible to run just a subtest?
You can run each page individually using its URL, e.g.
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/programs/program-test.html
But we don't have a simple way of running less than that without
editing the pages. That's fairly easy though. Just svn checkout the
test suite:
svn checkout
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl
The 1.0.1 tests are under conformance-suites/1.0.1
If you run this locally as a file:// URL, you'll need to tell your
browser to be lax with the same-origin policy. In Firefox, go to
about:config and set security.fileuri.strict_origin_policy=false.
Alternatively, a better solution is to run your own HTTP server,
which is very simple: in the directory you want to serve, run:
$ python -m SimpleHTTPServer
This will serve the current directory on http://127.0.0.1:8000
It would be nice to apitrace
what's going
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
- Original Message -
- Original Message -
- Original Message -
- Original Message -
On Tue, 17 Apr 2012 05:51:23 -0700 (PDT), Benoit Jacob
bja...@mozilla.com wrote:
In the WebGL WG, we need to have WebGL 1.0.1 conformance
tests
fully
passing on multiple, real drivers, before we can claim that
WebGL
has
conformant implementations.
So we are trying to get people to run these conformance tests
on
development versions of their favorite browsers, using recent
drivers:
http://www.khronos.org/webgl/wiki/CrowdsourcingDriverTesting
It would be great to see some more results with Mesa 8.0.2 or
8.1-git.
Note: if you are using Firefox for testing, please use today
(20120417)'s Nightly build, as some important
fixes/workarounds
just
landed.
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
1 tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false,
alpha:
false, antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is
non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was
false.
Is this assuming that MSAA is available?
Ouch. Yes, this test is effectively requiring MSAA. It's a bug in
the
test: in WebGL, anti-aliasing is a hint, not a requirement. We'll
fix this very soon in the WebGL conformance tests, but it's too
late
for the 1.0.1 version unfortunately. Very unfortunate that we
didn't
catch this earlier.
Ah no, sorry, this is not a bug in the conformance test, this is
purely a Firefox bug. What happens is that this test is checking
that the actual context attributes match reality. They should.
Firefox's bug is that it's returning the context creation
attributes
(which have antialias=true) instead of the actual context
attributes. Will fix. Nothing to be done or worry about on your
end.
Sorry for ping-ponging on this but looking closer into this, I'm not
so sure anymore that it's a Firefox bug:
- Firefox does check the actual context format and returns that
- I can't reproduce this test failure here on Mesa 7.11, r600g
driver.
So I'm wondering if this could actually be an issue with the Intel
driver, or with Mesa 8 ?
The question is: does Mesa/Intel correctly return 0 for
glGetIntegerv(LOCAL_GL_MAX_SAMPLES, result)?
It just occurred to me that a 1 here really means no antialiasing, and we're
currently mis-interpreting it.
Filed Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=746296
Benoit
An APItrace of this test would give the answer.
Benoit
Benoit
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-use formerly good program,
with
new bad shader attached
FAIL getError expected: NO_ERROR. Was INVALID_OPERATION :
drawing
with a
valid program shouldn't generate a GL error
This sounded like it was going to be a Mesa bug, but this
testcase
passes:
{
...
glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
good_fs = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
good_fs_source);
prog = piglit_link_simple_program(vs, good_fs);
if (!vs || !good_fs || !prog)
piglit_report_result(PIGLIT_FAIL);
glUseProgram(prog);
piglit_draw_rect(-1, -1, 1, 2);
bad_fs = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(bad_fs, 1, (const GLchar **) bad_fs_source,
NULL);
glCompileShader(bad_fs);
glGetShaderiv(bad_fs, GL_COMPILE_STATUS, ok);
if (ok)
piglit_report_result(PIGLIT_FAIL);
glAttachShader(prog, bad_fs);
piglit_draw_rect(0, -1, 1, 2);
pass = piglit_probe_rect_rgba(0, 0,
piglit_width, piglit_height,
green);
...
}
Is it possible to run just a subtest?
You can run each page individually using its URL, e.g.
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/conformance-suites/1.0.1/conformance/programs/program-test.html
But we don't have a simple way of running less than that without
editing the pages. That's fairly easy though. Just svn checkout
the
test suite:
svn checkout
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl
The 1.0.1 tests are under
[Mesa-dev] [Bug 48788] Mesa after 7.11.2 won't use hardware for OpenGL acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=48788 --- Comment #17 from russian...@gmail.com russian...@gmail.com 2012-04-17 14:36:32 PDT --- After configure.ac patch (which is now in mesa-git) I can confirm that 3D acceleration working again, also, for some reason LIBGL_DEBUG env var is respected and works as intended. So, probably it works only with DRI built libGL. -- 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/6] r600g: Add TGSI-LLVM implementation
On Tue, Apr 17, 2012 at 12:11 PM, Tom Stellard tstel...@gmail.com wrote:
---
src/gallium/drivers/r600/r600_llvm.c | 300
++
src/gallium/drivers/r600/r600_llvm.h | 29
2 files changed, 329 insertions(+), 0 deletions(-)
create mode 100644 src/gallium/drivers/r600/r600_llvm.c
create mode 100644 src/gallium/drivers/r600/r600_llvm.h
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
new file mode 100644
index 000..267fb19
--- /dev/null
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -0,0 +1,300 @@
+#include r600_llvm.h
+
+#include gallivm/lp_bld_const.h
+#include gallivm/lp_bld_intr.h
+#include gallivm/lp_bld_gather.h
+#include tgsi/tgsi_parse.h
+#include util/u_double_list.h
+
+#include r600.h
+#include r600_asm.h
+#include r600_opcodes.h
+#include r600_shader.h
+#include radeon_llvm.h
+#include radeon_llvm_emit.h
+
+#include stdio.h
+
+static LLVMValueRef llvm_fetch_const(
+ struct lp_build_tgsi_context * bld_base,
+ const struct tgsi_full_src_register *reg,
+ enum tgsi_opcode_type type,
+ unsigned swizzle)
+{
+ return lp_build_intrinsic_unary(bld_base-base.gallivm-builder,
+ llvm.AMDGPU.load.const, bld_base-base.elem_type,
+ lp_build_const_int32(bld_base-base.gallivm,
+ radeon_llvm_reg_index_soa(reg-Register.Index, swizzle)));
+}
+
+static void llvm_load_input(
+ struct radeon_llvm_context * ctx,
+ unsigned input_index,
+ const struct tgsi_full_declaration *decl)
+{
+ unsigned chan;
+
+ for (chan = 0; chan 4; chan++) {
+ unsigned soa_index = radeon_llvm_reg_index_soa(input_index,
+ chan);
+
+ /* The * 4 is assuming that we are in soa mode. */
+ LLVMValueRef reg = lp_build_const_int32(
+ ctx-soa.bld_base.base.gallivm,
+ soa_index + (ctx-reserved_reg_count * 4));
+ ctx-inputs[soa_index] = lp_build_intrinsic_unary(
+ ctx-soa.bld_base.base.gallivm-builder,
+ llvm.R600.load.input,
+ ctx-soa.bld_base.base.elem_type, reg);
+ }
+}
+
+static void llvm_emit_prologue(struct lp_build_tgsi_context * bld_base)
+{
+ struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
+ struct lp_build_context * base = bld_base-base;
+ unsigned i;
+
+ /* Reserve special input registers */
+ for (i = 0; i ctx-reserved_reg_count; i++) {
+ unsigned chan;
+ for (chan = 0; chan TGSI_NUM_CHANNELS; chan++) {
+ LLVMValueRef reg;
+ LLVMValueRef reg_index = lp_build_const_int32(
+ base-gallivm,
+ radeon_llvm_reg_index_soa(i, chan));
+ reg = lp_build_intrinsic_unary(base-gallivm-builder,
+ llvm.AMDGPU.reserve.reg,
+ base-elem_type, reg_index);
+ lp_build_intrinsic_unary(base-gallivm-builder,
+ llvm.AMDGPU.export.reg,
+ LLVMVoidTypeInContext(base-gallivm-context),
+ reg);
+ }
+ }
+}
+
+static void llvm_emit_epilogue(struct lp_build_tgsi_context * bld_base)
+{
+ struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
+ struct lp_build_context * base = bld_base-base;
+ unsigned i;
+
+ /* Add the necessary export instructions */
+ for (i = 0; i ctx-output_reg_count; i++) {
+ unsigned chan;
+ for (chan = 0; chan TGSI_NUM_CHANNELS; chan++) {
+ LLVMValueRef output;
+ LLVMValueRef store_output;
+ unsigned adjusted_reg_idx = i +
+ ctx-reserved_reg_count;
+ LLVMValueRef reg_index = lp_build_const_int32(
+ base-gallivm,
+ radeon_llvm_reg_index_soa(adjusted_reg_idx,
chan));
+
+ output = LLVMBuildLoad(base-gallivm-builder,
+ ctx-soa.outputs[i][chan], );
+
+ store_output = lp_build_intrinsic_binary(
+ base-gallivm-builder,
+ llvm.AMDGPU.store.output,
+ base-elem_type,
+ output, reg_index);
+
+ lp_build_intrinsic_unary(base-gallivm-builder,
+ llvm.AMDGPU.export.reg,
+
Re: [Mesa-dev] r600g: Add hooks for the LLVM backend
On Tue, Apr 17, 2012 at 12:11 PM, Tom Stellard tstel...@gmail.com wrote: Hi, This patch series adds the necessary hooks, so that r600g can use the LLVM backend for graphics shaders. To use the LLVM backend just add --enable-r600-llvm-compiler to your configure flags. The LLVM backend for graphics is still experimental, and it currently has to fallback to the default compiler in order to handle indirect addressing. With that fallback it passes 5464/5641 piglit tests vs 5511/5641 with the default compiler. Besides indirect addressing, the biggest thing missing from the backend is support for most of the texturing instructions. At the moment, I do not have any plans to improve support for graphics in the LLVM backend, but I wanted to get these patches merged into master to give people who are interested a chance to hack on it. For the series: Reviewed-by: Alex Deucher alexander.deuc...@amd.com Please note the missing case for ARUBA on patch 5/6. Alex -Tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa-8.0.2 libGL.so: undefined reference to `XGetXCBConnection'
Thanks Adam, please see following information. On 2012-04-17 09:34-0400, Adam Jackson wrote: On Mon, 2012-04-16 at 22:15 +1000, jupiter@gmail.com wrote: I've just built Mesa-8.0.2 in a Linux box. Then there were errors of libGL.so: undefined reference to `XGetXCBConnection' % nm -aD --defined /usr/lib/libX11-xcb.so.1 | grep XCB 473ef560 T XGetXCBConnection $ nm -aD --defined /usr/lib/libX11-xcb.so.1 | grep XCB 0470 T XGetXCBConnection and libGL.so: undefined reference to `xcb_glx_client_info' while I was compiling glew-1.7.0. What was I missing in building Mesa-8.0.2? % nm -aD --defined /usr/lib/libxcb-glx.so.0 | grep client_info$ 47756d10 T xcb_glx_client_info $ nm -aD --defined /usr/lib/libxcb-glx.so.0 | grep client_info$ ddf0 T xcb_glx_client_info $ ldd libGL.so linux-gate.so.1 = (0x003d9000) libX11.so.6 = /usr/lib/libX11.so.6 (0x00588000) libXext.so.6 = /usr/lib/libXext.so.6 (0x0016c000) libXxf86vm.so.1 = /usr/lib/libXxf86vm.so.1 (0x0097c000) libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x009ed000) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x003a8000) libpthread.so.0 = /lib/libpthread.so.0 (0x006ea000) libdl.so.2 = /lib/libdl.so.2 (0x00dad000) libdrm.so.2 = /usr/local/mesa/lib/libdrm.so.2 (0x0023e000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x00248000) libm.so.6 = /lib/libm.so.6 (0x00aa4000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x008f5000) libc.so.6 = /lib/libc.so.6 (0x003da000) libxcb.so.1 = /usr/lib/libxcb.so.1 (0x0011) /lib/ld-linux.so.2 (0x0085f000) librt.so.1 = /lib/librt.so.1 (0x0012e000) libXau.so.6 = /usr/lib/libXau.so.6 (0x00137000) Note that neither one of the above libraries is mentioned in your ldd output, which means libGL was linked incorrectly. What method did you use to build Mesa? The default of the configuration was used. How should I change the default configure to link libX11-xcb and libxcb-glx properly? Thank you. --juper ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Tue, 17 Apr 2012 12:41:21 -0700 (PDT), Jose Fonseca jfons...@vmware.com wrote: - Original Message - Is it possible to run just a subtest? It would be nice to apitrace what's going on in this testcase, but if I run the whole test I won't be able to find where the failure was in the trace. apitrace/scripts/retracediff.py allows to run against a software renderer, and quickly spot what call the rendering diverges, but given that all available software renderers are based from Mesa, odds are many bugs will appear on both, so not that useful. One of these day's I'll add SSH support to retracediff.py, so that one can eaily compare the rendering against a remote machine (running, e.g., NVIDIA OpenGL), or even a different OS. Of course, this only works if both implementations support the functionality recorded in the trace. The issue in question was that a GL_INVALID_OPERATION was thrown at a point that it shouldn't have been, so it wouldn't show up as rendering. Whacking the HTML sounds like a better way to isolate the failure. pgppq3Sqetkmz.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
On Tue, 17 Apr 2012 12:53:12 -0700 (PDT), Benoit Jacob bja...@mozilla.com
wrote:
i965 driver:
Results: (8866 of 8879 passed)
Failures:
conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
1 tests failed
PASS webGL = getWebGL(2, 2, { depth: false, stencil: false,
alpha:
false, antialias: true }, [ 0, 0, 0, 1 ], 1, 0) is non-null.
PASS contextAttribs = webGL.getContextAttributes() is non-null.
FAIL pixel[0] != 255 pixel[0] != 0 should be true. Was
false.
Is this assuming that MSAA is available?
Ouch. Yes, this test is effectively requiring MSAA. It's a bug in
the
test: in WebGL, anti-aliasing is a hint, not a requirement. We'll
fix this very soon in the WebGL conformance tests, but it's too
late
for the 1.0.1 version unfortunately. Very unfortunate that we
didn't
catch this earlier.
Ah no, sorry, this is not a bug in the conformance test, this is
purely a Firefox bug. What happens is that this test is checking
that the actual context attributes match reality. They should.
Firefox's bug is that it's returning the context creation attributes
(which have antialias=true) instead of the actual context
attributes. Will fix. Nothing to be done or worry about on your end.
Sorry for ping-ponging on this but looking closer into this, I'm not so sure
anymore that it's a Firefox bug:
- Firefox does check the actual context format and returns that
- I can't reproduce this test failure here on Mesa 7.11, r600g driver.
So I'm wondering if this could actually be an issue with the Intel driver, or
with Mesa 8 ?
The question is: does Mesa/Intel correctly return 0 for
glGetIntegerv(LOCAL_GL_MAX_SAMPLES, result)?
An APItrace of this test would give the answer.
GL_MAX_SAMPLES tells you how many samples you can ask for from a
multisample renderbuffer (GL 3.0 spec page 285), while to ask about the
number of samples in a particular GLX visuals you have to check the
GLX_SAMPLE_BUFFERS_ARB of the visual (GL_ARB_multisample spec). We
currently expose GL_MAX_SAMPLES of 4 (GL 3.0 spec page 391), but that's
a lie and if you ask for a 4-sample renderbuffer we don't actually
multisample it. We don't expose any GLX visuals with nonzero
GLX_SAMPLE_BUFFERS_ARB, which is conformant but disappointing.
pgpvJRVIpms1M.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers
GL_MAX_SAMPLES tells you how many samples you can ask for from a multisample renderbuffer (GL 3.0 spec page 285), while to ask about the number of samples in a particular GLX visuals you have to check the GLX_SAMPLE_BUFFERS_ARB of the visual (GL_ARB_multisample spec). We currently expose GL_MAX_SAMPLES of 4 (GL 3.0 spec page 391), but that's a lie and if you ask for a 4-sample renderbuffer we don't actually multisample it. We don't expose any GLX visuals with nonzero GLX_SAMPLE_BUFFERS_ARB, which is conformant but disappointing. Thanks for that information. WebGL antialiasing relies in multisample renderbuffers (ARB_framebuffer_multisample), not on multisample GLX visuals. So GL_MAX_SAMPLES is really what we care about. If the value returned by Mesa for getIntegerv(GL_MAX_SAMPLES) can't be used to tell whether multisample renderbuffers are actually supported, then how can we determine that? Benoit ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
