Re: [Mesa-dev] undefined C++ GLSL symbol error
On Die, 2012-01-31 at 21:26 -0500, Matt Turner wrote: On Tue, Jan 31, 2012 at 8:32 PM, Brian Paul bri...@vmware.com wrote: On 01/31/2012 02:44 PM, Zack Rusin wrote: Could you maybe revert all of this and do it in a branch where we could iron out those issues? Yeah, I was thinking the same thing. When we get things working again let's do all follow-on autoconf work on a branch where we can test first. I'm okay with that if people will actually test. The glsl patch has been on the mailing list since September, through multiple iterations, and I think only got testing from two other people. You don't need anyone else to test --with-gallium-drivers=swrast for you. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 42649] OpenVG's VGfont not work.
https://bugs.freedesktop.org/show_bug.cgi?id=42649 José Fonseca jfons...@vmware.com changed: What|Removed |Added CC||jfons...@vmware.com, ||z...@kde.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 42386] [openvg] VG_DRAW_IMAGE_MULTIPLY does not work for alpha 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=42386 José Fonseca jfons...@vmware.com changed: What|Removed |Added CC||jfons...@vmware.com, ||z...@kde.org Summary|VG_DRAW_IMAGE_MULTIPLY does |[openvg] |not work for alpha 1.0 |VG_DRAW_IMAGE_MULTIPLY does ||not work for alpha 1.0 --- Comment #1 from José Fonseca jfons...@vmware.com 2012-02-01 02:11:04 PST --- Was this with llvmpipe? Does softpipe behave differently? -- 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 34261] Buildsystem disables openvg when disabling gallium egl
https://bugs.freedesktop.org/show_bug.cgi?id=34261 José Fonseca jfons...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from José Fonseca jfons...@vmware.com 2012-02-01 02:16:32 PST --- I think that releases with this fix should be available and this can be closed now. -- 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 42386] [openvg] VG_DRAW_IMAGE_MULTIPLY does not work for alpha 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=42386 Andreas Betz andreas.b...@elektrobit.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andreas Betz andreas.b...@elektrobit.com 2012-02-01 02:30:04 PST --- this was with both pipes ... but i seems that it is fixed by now - sorry for not closing the ticket -- 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] gen_matypes: fix cross-compiling with gcc
I'm not familiar with with autotools to comment on those bits, but I think this
is a pretty neat idea.
This could be also when when cross compiling for windows w/ mingw.
Jose
- Original Message -
The current gen_matypes logic assumes that the host compiler will
produce
information that is useful for the target compiler. Unfortunately,
this
is not the case whenever cross-compiling.
When we detect that we're cross-compiling and using GCC, use the
target
compiler to produce assembly from the gen_matypes.c source, then
process
it with a shell script to create a usable header. This is similar to
how
the linux kernel creates its asm-offsets.c file.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
Note: please keep me on cc as i'm not subscribed
configs/autoconf.in|2 ++
configure.ac |6 ++
src/mesa/x86/Makefile | 18 +++---
src/mesa/x86/gen_matypes.c | 35
+--
4 files changed, 52 insertions(+), 9 deletions(-)
diff --git a/configs/autoconf.in b/configs/autoconf.in
index bb8f2c3..4ad49ea 100644
--- a/configs/autoconf.in
+++ b/configs/autoconf.in
@@ -213,3 +213,5 @@ ifneq ($(LLVM_VERSION),)
endif
HAVE_XF86VIDMODE = @HAVE_XF86VIDMODE@
+
+GEN_ASM_OFFSETS = @GEN_ASM_OFFSETS@
diff --git a/configure.ac b/configure.ac
index 0e03af7..25c30d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -106,6 +106,7 @@ AC_MSG_RESULT([$acv_mesa_CLANG])
dnl If we're using GCC, make sure that it is at least version 3.3.0.
Older
dnl versions are explictly not supported.
+GEN_ASM_OFFSETS=no
if test x$GCC = xyes -a x$acv_mesa_CLANG = xno; then
AC_MSG_CHECKING([whether gcc version is sufficient])
major=0
@@ -123,7 +124,12 @@ if test x$GCC = xyes -a x$acv_mesa_CLANG =
xno; then
else
AC_MSG_RESULT([yes])
fi
+
+if test x$cross_compiling = xyes; then
+GEN_ASM_OFFSETS=yes
+fi
fi
+AC_SUBST([GEN_ASM_OFFSETS])
MKDEP_OPTIONS=-fdepend
diff --git a/src/mesa/x86/Makefile b/src/mesa/x86/Makefile
index 9716dc2..0dba5a2 100644
--- a/src/mesa/x86/Makefile
+++ b/src/mesa/x86/Makefile
@@ -13,8 +13,7 @@ INCLUDE_DIRS = \
-I../math \
-I../tnl
-
-default: gen_matypes matypes.h
+default: matypes.h
clean:
-rm -f matypes.h gen_matypes
@@ -24,9 +23,22 @@ gen_matypes: gen_matypes.c
$(HOST_CC) $(ARCH_FLAGS) $(INCLUDE_DIRS) $(HOST_CFLAGS)
gen_matypes.c -o gen_matypes
# need some special rules here, unfortunately
-matypes.h: ../main/mtypes.h ../tnl/t_context.h gen_matypes
+matypes.h: ../main/mtypes.h ../tnl/t_context.h
+
+ifeq ($(GEN_ASM_OFFSETS),yes)
+
+matypes.h: gen_matypes.c
+ $(CC) $(ARCH_FLAGS) $(INCLUDE_DIRS) $(CFLAGS) gen_matypes.c
-DASM_OFFSETS -S -o - | \
+ sed -n '/^-/{s:^-::;/[$$]/{s:^:#define :;s:[$$]::};p}' $@
+
+else
+
+default: gen_matypes
+matypes.h: gen_matypes
./gen_matypes matypes.h
+endif
+
common_x86_asm.o: matypes.h
3dnow_normal.o: matypes.h
3dnow_xform1.o: matypes.h
diff --git a/src/mesa/x86/gen_matypes.c b/src/mesa/x86/gen_matypes.c
index 97f71f9..b359bb8 100644
--- a/src/mesa/x86/gen_matypes.c
+++ b/src/mesa/x86/gen_matypes.c
@@ -52,7 +52,7 @@ do {
\
printf( \n ); \
printf( /*
=\
\n ); \
- printf( * Offsets for %s\n, x );
\
+ printf( * Offsets for x \n );
\
printf( */\n );
\
printf( \n ); \
} while (0)
@@ -61,20 +61,43 @@ do {
\
do { \
printf( \n ); \
printf( /*\n ); \
- printf( * Flags for %s\n, x ); \
+ printf( * Flags for x \n ); \
printf( */\n );
\
printf( \n ); \
} while (0)
-#define OFFSET( s, t, m )\
- printf( #define %s\t%lu\n, s, (unsigned long) offsetof( t, m )
);
+#ifdef ASM_OFFSETS
-#define SIZEOF( s, t )
\
- printf( #define %s\t%lu\n, s, (unsigned long) sizeof(t) );
+/*
+ * Format the asm output in a special way that we can manipulate
+ * after the fact and turn into the final header for
Re: [Mesa-dev] [PATCH 1/2] mesa: use new _mesa_reference_shared_state() function
Looks solid to me Brian.
Jose
- Original Message -
This cleans up the reference counting of shared context state.
The next patch will use this to fix an actual bug.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/context.c | 28 --
src/mesa/main/shared.c | 48
+-
src/mesa/main/shared.h | 11 +
3 files changed, 49 insertions(+), 38 deletions(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index f39cab5..43e7438 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -939,13 +939,10 @@ _mesa_initialize_context(struct gl_context
*ctx,
return GL_FALSE;
}
- _glthread_LOCK_MUTEX(shared-Mutex);
- ctx-Shared = shared;
- shared-RefCount++;
- _glthread_UNLOCK_MUTEX(shared-Mutex);
+ _mesa_reference_shared_state(ctx, ctx-Shared, shared);
if (!init_attrib_groups( ctx )) {
- _mesa_release_shared_state(ctx, ctx-Shared);
+ _mesa_reference_shared_state(ctx, ctx-Shared, NULL);
return GL_FALSE;
}
@@ -973,7 +970,7 @@ _mesa_initialize_context(struct gl_context *ctx,
}
if (!ctx-Exec) {
- _mesa_release_shared_state(ctx, ctx-Shared);
+ _mesa_reference_shared_state(ctx, ctx-Shared, NULL);
return GL_FALSE;
}
#endif
@@ -1002,7 +999,7 @@ _mesa_initialize_context(struct gl_context *ctx,
#if FEATURE_dlist
ctx-Save = _mesa_create_save_table();
if (!ctx-Save) {
- _mesa_release_shared_state(ctx, ctx-Shared);
+ _mesa_reference_shared_state(ctx, ctx-Shared, NULL);
free(ctx-Exec);
return GL_FALSE;
}
@@ -1140,7 +1137,7 @@ _mesa_free_context_data( struct gl_context *ctx
)
free(ctx-Save);
/* Shared context state (display lists, textures, etc) */
- _mesa_release_shared_state( ctx, ctx-Shared );
+ _mesa_reference_shared_state(ctx, ctx-Shared, NULL);
/* needs to be after freeing shared state */
_mesa_free_display_list_data(ctx);
@@ -1540,17 +1537,18 @@ GLboolean
_mesa_share_state(struct gl_context *ctx, struct gl_context
*ctxToShare)
{
if (ctx ctxToShare ctx-Shared ctxToShare-Shared) {
- struct gl_shared_state *oldSharedState = ctx-Shared;
+ struct gl_shared_state *oldShared = NULL;
- ctx-Shared = ctxToShare-Shared;
-
- _glthread_LOCK_MUTEX(ctx-Shared-Mutex);
- ctx-Shared-RefCount++;
- _glthread_UNLOCK_MUTEX(ctx-Shared-Mutex);
+ /* save ref to old state to prevent it from being deleted
immediately */
+ _mesa_reference_shared_state(ctx, oldShared, ctx-Shared);
+
+ /* update ctx's Shared pointer */
+ _mesa_reference_shared_state(ctx, ctx-Shared,
ctxToShare-Shared);
update_default_objects(ctx);
- _mesa_release_shared_state(ctx, oldSharedState);
+ /* release the old shared state */
+ _mesa_reference_shared_state(ctx, oldShared, NULL);
return GL_TRUE;
}
diff --git a/src/mesa/main/shared.c b/src/mesa/main/shared.c
index c3e93b5..c07ce82 100644
--- a/src/mesa/main/shared.c
+++ b/src/mesa/main/shared.c
@@ -388,28 +388,40 @@ free_shared_state(struct gl_context *ctx,
struct gl_shared_state *shared)
/**
- * Decrement shared state object reference count and potentially
free it
- * and all children structures.
- *
- * \param ctx GL context.
- * \param shared shared state pointer.
- *
- * \sa free_shared_state().
+ * gl_shared_state objects are ref counted.
+ * If ptr's refcount goes to zero, free the shared state.
*/
void
-_mesa_release_shared_state(struct gl_context *ctx,
- struct gl_shared_state *shared)
+_mesa_reference_shared_state(struct gl_context *ctx,
+ struct gl_shared_state **ptr,
+ struct gl_shared_state *state)
{
- GLint RefCount;
-
- _glthread_LOCK_MUTEX(shared-Mutex);
- RefCount = --shared-RefCount;
- _glthread_UNLOCK_MUTEX(shared-Mutex);
+ if (*ptr == state)
+ return;
+
+ if (*ptr) {
+ /* unref old state */
+ struct gl_shared_state *old = *ptr;
+ GLboolean delete;
+
+ _glthread_LOCK_MUTEX(old-Mutex);
+ assert(old-RefCount = 1);
+ old-RefCount--;
+ delete = (old-RefCount == 0);
+ _glthread_UNLOCK_MUTEX(old-Mutex);
+
+ if (delete) {
+ free_shared_state(ctx, old);
+ }
- assert(RefCount = 0);
+ *ptr = NULL;
+ }
- if (RefCount == 0) {
- /* free shared state */
- free_shared_state( ctx, shared );
+ if (state) {
+ /* reference new state */
+ _glthread_LOCK_MUTEX(state-Mutex);
+ state-RefCount++;
+ *ptr = state;
+ _glthread_UNLOCK_MUTEX(state-Mutex);
}
}
diff --git a/src/mesa/main/shared.h b/src/mesa/main/shared.h
index 55516a8..3fe4578 100644
--- a/src/mesa/main/shared.h
+++
Re: [Mesa-dev] [PATCH 2/2] mesa: reference shared state in glPushAttrib(GL_TEXTURE_BIT)
Looks good. Good find!
Jose
- Original Message -
This fixes a dangling texture object pointer bug hit via
wglShareLists().
When we push the GL_TEXTURE_BIT state we may push references to the
default
texture objects which are owned by the gl_shared_state object. We
don't
want to accidentally delete that shared state while the attribute
stack
references shared objects. So keep a reference to it.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/attrib.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 01e7945..1068dd8 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -47,6 +47,7 @@
#include multisample.h
#include points.h
#include polygon.h
+#include shared.h
#include scissor.h
#include stencil.h
#include texenv.h
@@ -165,6 +166,13 @@ struct texture_state
* deleted while saved in the attribute stack).
*/
struct gl_texture_object
*SavedTexRef[MAX_TEXTURE_UNITS][NUM_TEXTURE_TARGETS];
+
+ /* We need to keep a reference to the shared state. That's where
the
+* default texture objects are kept. We don't want that state to
be
+* freed while the attribute stack contains pointers to any
default
+* texture objects.
+*/
+ struct gl_shared_state *SharedRef;
};
@@ -437,6 +445,8 @@ _mesa_PushAttrib(GLbitfield mask)
}
}
+ _mesa_reference_shared_state(ctx, texstate-SharedRef,
ctx-Shared);
+
_mesa_unlock_context_textures(ctx);
save_attrib_data(head, GL_TEXTURE_BIT, texstate);
@@ -806,6 +816,8 @@ pop_texture_group(struct gl_context *ctx, struct
texture_state *texstate)
_mesa_ActiveTextureARB(GL_TEXTURE0_ARB +
texstate-Texture.CurrentUnit);
+ _mesa_reference_shared_state(ctx, texstate-SharedRef, NULL);
+
_mesa_unlock_context_textures(ctx);
}
@@ -1605,6 +1617,7 @@ _mesa_free_attrib_data(struct gl_context *ctx)
_mesa_reference_texobj(texstate-SavedTexRef[u][tgt],
NULL);
}
}
+_mesa_reference_shared_state(ctx, texstate-SharedRef,
NULL);
}
else {
/* any other chunks of state that requires special
handling? */
--
1.7.3.4
___
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] [PATCH] nv50: use larger arrays to silence warnings
Silences warnings and fixes potential bugs due to buffer overflow.
The nv50 maintainers could benefit from sprinkling a few asserts to catch this
early in the future, as it is bound to happen again.
Jose
- Original Message -
The warnings were:
nv50_pc_regalloc.c: In function ‘pass_generate_phi_movs’:
nv50_pc_regalloc.c:423:41: warning: array subscript is above array
bounds
codegen/nv50_ir_peephole.cpp: In member function ‘bool
nv50_ir::MemoryOpt::replaceStFromSt(nv50_ir::Instruction*,
nv50_ir::MemoryOpt::Record*)’:
codegen/nv50_ir_peephole.cpp:1475:18: warning: array subscript is
above array bounds
codegen/nv50_ir_peephole.cpp:1475:18: warning: array subscript is
above array bounds
codegen/nv50_ir_peephole.cpp:1475:18: warning: array subscript is
above array bounds
codegen/nv50_ir_peephole.cpp:1475:18: warning: array subscript is
above array bounds
---
.../drivers/nv50/codegen/nv50_ir_peephole.cpp |2 +-
src/gallium/drivers/nv50/nv50_pc.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nv50/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nv50/codegen/nv50_ir_peephole.cpp
index fc025d8..fb4041f 100644
--- a/src/gallium/drivers/nv50/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nv50/codegen/nv50_ir_peephole.cpp
@@ -1463,7 +1463,7 @@ MemoryOpt::replaceStFromSt(Instruction
*restrict st, Record *rec)
st-takeExtraSources(0, extra);
if (offR offS) {
- Value *vals[4];
+ Value *vals[10];
int s, n;
int k = 0;
// get non-replaced sources of ri
diff --git a/src/gallium/drivers/nv50/nv50_pc.h
b/src/gallium/drivers/nv50/nv50_pc.h
index 45804d3..9abefa2 100644
--- a/src/gallium/drivers/nv50/nv50_pc.h
+++ b/src/gallium/drivers/nv50/nv50_pc.h
@@ -234,7 +234,7 @@ struct nv_instruction {
int serial;
struct nv_value *def[4];
struct nv_value *flags_def;
- struct nv_ref *src[5];
+ struct nv_ref *src[6];
struct nv_ref *flags_src;
struct nv_basic_block *bb;
struct nv_basic_block *target; /* target block of control flow
insn */
--
1.7.3.4
___
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] [PATCH] r600g: Use new kernel interface to wait for fences
On Tuesday 31 January 2012, Michel Dänzer mic...@daenzer.net wrote:
On Die, 2012-01-31 at 17:02 +, Simon Farnsworth wrote:
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
If the new kernel interface is unavailable, fall back to busywaiting.
if (timeout != PIPE_TIMEOUT_INFINITE
os_time_get() - start_time = timeout) {
return FALSE;
Maybe add something like
if (rscreen-fences.data[rfence-index])
return TRUE;
before the timeout check? Otherwise there may be a false negative if the
fence signalled just before the timeout.
I'll fix this - I think I'd prefer to use a ternary operator in the return.
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 143dcf9..487fc58 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -892,4 +922,9 @@ void radeon_bomgr_init_functions(struct
radeon_drm_winsys *ws)
ws-base.buffer_from_handle = radeon_winsys_bo_from_handle;
ws-base.buffer_get_handle = radeon_winsys_bo_get_handle;
ws-base.buffer_get_virtual_address = radeon_winsys_bo_va;
+if (ws-info.drm_major 2 ||
+(ws-info.drm_major == 2 ws-info.drm_minor = 15))
+ws-base.buffer_wait_fence = radeon_winsys_bo_wait_fence;
+else
+ws-base.buffer_wait_fence = radeon_winsys_bo_wait_fence_nokernel;
}
We have no idea what kind of API a hypothetical major version 2 might
have, so I think it's better to only check for (ws-info.drm_minor =
15) here.
I'll make that change as well and respin.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
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
[Mesa-dev] [Bug 45420] undefined reference to `LLVMInitializeARMDisassembler'
https://bugs.freedesktop.org/show_bug.cgi?id=45420
--- Comment #5 from José Fonseca jfons...@vmware.com 2012-02-01 03:45:04 PST
---
(In reply to comment #4)
Created attachment 56422 [details] [review]
Proposed fix for LLVM-2.7
I don't really know how to properly fix this for all targets, because
LLVM_NATIVE_ARCH in LLVM-2.7 is ${LLVM_NATIVE_ARCH}Target (X86Target for X86,
ARMTarget for ARM etc), so it's not possible to write something like
#define LLVM_ASM_PRINTER(TargetName) LLVMInitialize##TargetName##AsmPrinter();
to fix all targets. Attached patch adds defines only for for X86 and ARM, is
it
sufficient, should it be added for other targets or it can be completely
skipped for LLVM 2.8?
Patch also adds needed defines for LLVM Disassembler.
Thanks ojab.
Also llvmpipe docs say that LLVM: version 2.9 recommended; 2.6 or later
required, is it up-to-date and build should also be tested with LLVM-2.6?
The ability to build with LLVM-2.6 is still useful for now, as it is one of the
most stable LLVM releases for us ever.
But the ability to disassemble w/ LLVM 2.7 or eralier is not really important
(as most developers will have recent LLVM anyway), so we could simply cut our
losses and do:
--- a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
@@ -172,7 +172,7 @@ public:
extern C void
lp_disassemble(const void* func)
{
-#if HAVE_LLVM = 0x0207
+#if HAVE_LLVM = 0x0208
using namespace llvm;
const uint8_t *bytes = (const uint8_t *)func;
Vinson, I don't have LLVM 2.7. Could you verify either ojab's or my change
fixes the build issue?
--
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] [PATCHv2] r600g: Use new kernel interface to wait for fences
Instead of busywaiting for the GPU to finish a fence, use the new kernel
interface to wait for fence completion.
If the new kernel interface is unavailable, fall back to busywaiting.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
This is simply addressing Michel's review comments against the v1 patch.
There is ongoing debate on the dri-devel list about the required kernel
interface to make this patch useful; until that discussion is resolved, this
patch should probably not be applied.
src/gallium/drivers/r600/r600_hw_context.c|2 +-
src/gallium/drivers/r600/r600_pipe.c | 14 +++--
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 34 +
src/gallium/winsys/radeon/drm/radeon_winsys.h | 16 +++
4 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 8eb8e6d..35a57a7 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -1618,7 +1618,7 @@ void r600_context_emit_fence(struct r600_context *ctx,
struct r600_resource *fen
ctx-pm4[ctx-pm4_cdwords++] =
EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH_AND_INV_TS_EVENT) | EVENT_INDEX(5);
ctx-pm4[ctx-pm4_cdwords++] = va 0xUL; /* ADDRESS_LO */
/* DATA_SEL | INT_EN | ADDRESS_HI */
- ctx-pm4[ctx-pm4_cdwords++] = (1 29) | (0 24) | ((va 32UL)
0xFF);
+ ctx-pm4[ctx-pm4_cdwords++] = (1 29) | (2 24) | ((va 32UL)
0xFF);
ctx-pm4[ctx-pm4_cdwords++] = value; /* DATA_LO */
ctx-pm4[ctx-pm4_cdwords++] = 0; /* DATA_HI */
ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_NOP, 0, 0);
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index c38fbc5..c03a176 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -595,7 +595,6 @@ static boolean r600_fence_finish(struct pipe_screen
*pscreen,
struct r600_screen *rscreen = (struct r600_screen *)pscreen;
struct r600_fence *rfence = (struct r600_fence*)fence;
int64_t start_time = 0;
- unsigned spins = 0;
if (timeout != PIPE_TIMEOUT_INFINITE) {
start_time = os_time_get();
@@ -605,16 +604,13 @@ static boolean r600_fence_finish(struct pipe_screen
*pscreen,
}
while (rscreen-fences.data[rfence-index] == 0) {
- if (++spins % 256)
- continue;
-#ifdef PIPE_OS_UNIX
- sched_yield();
-#else
- os_time_sleep(10);
-#endif
+ rscreen-ws-buffer_wait_fence(rscreen-fences.bo-buf,
+ rfence-index 2,
+ 0,
+ timeout);
if (timeout != PIPE_TIMEOUT_INFINITE
os_time_get() - start_time = timeout) {
- return FALSE;
+ return rscreen-fences.data[rfence-index] == 0 ? FALSE
: TRUE;
}
}
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 143dcf9..b83791d 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -879,6 +879,36 @@ static uint64_t radeon_winsys_bo_va(struct pb_buffer
*buffer)
return bo-va;
}
+/* No kernel support for doing this faster - just spin */
+static void radeon_winsys_bo_wait_fence_nokernel(struct pb_buffer *buf,
+unsigned offset,
+uint32_t value,
+uint64_t timeout)
+{
+#ifdef PIPE_OS_UNIX
+sched_yield();
+#else
+os_time_sleep(10);
+#endif
+}
+
+static void radeon_winsys_bo_wait_fence(struct pb_buffer *_buf,
+ unsigned offset,
+ uint32_t value,
+ uint64_t timeout)
+{
+struct radeon_bo *bo = get_radeon_bo(_buf);
+struct drm_radeon_gem_wait_user_fence args;
+memset(args, 0, sizeof(args));
+args.handle = bo-handle;
+args.ring = RADEON_CS_RING_GFX;
+args.offset = offset;
+args.value = value;
+args.timeout_usec = timeout;
+while (drmCommandWrite(bo-rws-fd, DRM_RADEON_GEM_WAIT_USER_FENCE,
+ args, sizeof(args)) == -EBUSY);
+}
+
void radeon_bomgr_init_functions(struct radeon_drm_winsys *ws)
{
ws-base.buffer_get_cs_handle = radeon_drm_get_cs_handle;
@@ -892,4 +922,8 @@ void radeon_bomgr_init_functions(struct radeon_drm_winsys
*ws)
ws-base.buffer_from_handle = radeon_winsys_bo_from_handle;
ws-base.buffer_get_handle = radeon_winsys_bo_get_handle;
ws-base.buffer_get_virtual_address =
[Mesa-dev] [PATCHv2] drm/radeon: Add support for userspace fence waits
Userspace currently busywaits for fences to complete; on my workload, this
busywait consumes 10% of the available CPU time.
Provide an ioctl so that userspace can wait for an EOP interrupt that
corresponds to a previous EVENT_WRITE_EOP.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
There's debate ongoing about whether this is a sensible interface; I've
cleaned up in accordance with Dave Airlie's review comments, so that there's
a nicer starting point if the debate ends up agreeing that this is actually
the sort of interface we want.
In the meantime, I'm going to leave this interface alone, and work on
porting r300g's fence mechanism to r600g, using it to sleep instead of
spinning when fences are issued with an infinite timeout, but using the
existing busywait mechanism if a timeout is provided.
drivers/gpu/drm/radeon/radeon.h |3 ++
drivers/gpu/drm/radeon/radeon_drv.c |3 +-
drivers/gpu/drm/radeon/radeon_fence.c |2 +
drivers/gpu/drm/radeon/radeon_gem.c | 63 +
drivers/gpu/drm/radeon/radeon_kms.c |1 +
include/drm/radeon_drm.h | 31
6 files changed, 102 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 2859406..00c187b 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -217,6 +217,7 @@ struct radeon_fence_driver {
unsigned long last_jiffies;
unsigned long last_timeout;
wait_queue_head_t queue;
+ wait_queue_head_t userspace_queue;
struct list_headcreated;
struct list_heademitted;
struct list_headsignaled;
@@ -1348,6 +1349,8 @@ int radeon_gem_set_tiling_ioctl(struct drm_device *dev,
void *data,
struct drm_file *filp);
int radeon_gem_get_tiling_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
+int radeon_gem_wait_user_fence_ioctl(struct drm_device *dev, void *data,
+struct drm_file *filp);
/* VRAM scratch page for HDP bug, default vram page */
struct r600_vram_scratch {
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 4ae2e1d..9f82fa9 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -56,9 +56,10 @@
* 2.12.0 - RADEON_CS_KEEP_TILING_FLAGS
* 2.13.0 - virtual memory support
* 2.14.0 - add evergreen tiling informations
+ * 2.15.0 - gem_wait_user_fence ioctl
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 14
+#define KMS_DRIVER_MINOR 15
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 64ea3dd..d86bc28 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -356,6 +356,7 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
if (wake) {
wake_up_all(rdev-fence_drv[ring].queue);
}
+ wake_up_interruptible_all(rdev-fence_drv[ring].userspace_queue);
}
int radeon_fence_count_emitted(struct radeon_device *rdev, int ring)
@@ -421,6 +422,7 @@ static void radeon_fence_driver_init_ring(struct
radeon_device *rdev, int ring)
INIT_LIST_HEAD(rdev-fence_drv[ring].emitted);
INIT_LIST_HEAD(rdev-fence_drv[ring].signaled);
init_waitqueue_head(rdev-fence_drv[ring].queue);
+ init_waitqueue_head(rdev-fence_drv[ring].userspace_queue);
rdev-fence_drv[ring].initialized = false;
}
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 7337850..765fc6d 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -531,3 +531,66 @@ int radeon_mode_dumb_destroy(struct drm_file *file_priv,
{
return drm_gem_handle_delete(file_priv, handle);
}
+
+int radeon_gem_wait_user_fence_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp)
+{
+ struct drm_radeon_gem_wait_user_fence *args = data;
+ struct radeon_device *rdev = dev-dev_private;
+ struct drm_gem_object *gobj;
+ struct radeon_bo *robj;
+ void *buffer_data;
+ uint32_t *fence_data;
+ int r = 0;
+ long timeout;
+ int ring = RADEON_RING_TYPE_GFX_INDEX;
+
+ /* If you're implementing this for other rings, you'll want to share
+ code with radeon_cs_get_ring in radeon_cs.c */
+ if (args-ring != RADEON_CS_RING_GFX) {
+ return -EINVAL;
+ }
+
+ gobj = drm_gem_object_lookup(dev, filp, args-handle);
+ if
Re: [Mesa-dev] undefined C++ GLSL symbol error
- Original Message - On Tue, Jan 31, 2012 at 8:32 PM, Brian Paul bri...@vmware.com wrote: On 01/31/2012 02:44 PM, Zack Rusin wrote: On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote: $ makelog ar: creating libglapi.a ar: creating libmesa.a ar: libmesa.a: Error reading ../../src/glsl/.libs/: Is a directory ar: creating libmesagallium.a ar: libmesagallium.a: Error reading ../../src/glsl/.libs/: Is a directory ar: creating libegl_glx.a ar: creating libgallium.a Getting similar error, but my build doesn't finish: $ make realclean $ git clean -fxd $ ./autogen.sh --with-gallium-drivers=svga -with-dri-drivers= --enable-xa $ make ar: creating libmesa.a ar: ../../src/glsl/.libs/: File format not recognized ranlib: 'libmesa.a': No such file ar: creating libmesagallium.a ar: ../../src/glsl/.libs/: File format not recognized ranlib: 'libmesagallium.a': No such file ... make[3]: *** No rule to make target '../../../../src/mesa/libmesagallium.a', needed by 'vmwgfx_dri.so'.Stop. make[3]: Leaving directory '/home/zack/src/mesa/gallium/targets/dri-vmwgfx' I'll keep looking. Could you maybe revert all of this and do it in a branch where we could iron out those issues? Yeah, I was thinking the same thing. When we get things working again let's do all follow-on autoconf work on a branch where we can test first. -Brian I'm okay with that if people will actually test. The glsl patch has been on the mailing list since September, through multiple iterations, and I think only got testing from two other people. I wonder if people have use any tools to facility applying patches posted to mesa, as for me locate, save, and applying them takes a lot of time, and more often than not fails due to white space munging. I barely can keep up with the review requests anyway. Matt, if you commit your changes to a branch on fdo, then I can easily test. I can also also setup an automated build job on it and report failures to you. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] patches (Re: undefined C++ GLSL symbol error)
On Wed, 1 Feb 2012 05:03:21 -0800 (PST) Jose Fonseca jfons...@vmware.com wrote: I wonder if people have use any tools to facility applying patches posted to mesa, as for me locate, save, and applying them takes a lot of time, and more often than not fails due to white space munging. I barely can keep up with the review requests anyway. If a patch is malformatted to begin with, I can't help it. But, if your email client happens to support running external commands on mail files, I have a script that applies them to a given local git repo, launching a terminal window for it and optionally running it though the kernel checkpatch.pl. On any errors, it drops you to a shell. Personally I use claws-mail, and could share my setup, if anyone is interested in homebrewn solution for the save apply part. Thanks, pq ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] patches (Re: undefined C++ GLSL symbol error)
- Original Message - On Wed, 1 Feb 2012 05:03:21 -0800 (PST) Jose Fonseca jfons...@vmware.com wrote: I wonder if people have use any tools to facility applying patches posted to mesa, as for me locate, save, and applying them takes a lot of time, and more often than not fails due to white space munging. I barely can keep up with the review requests anyway. If a patch is malformatted to begin with, I can't help it. But, if your email client happens to support running external commands on mail files, I have a script that applies them to a given local git repo, launching a terminal window for it and optionally running it though the kernel checkpatch.pl. On any errors, it drops you to a shell. Personally I use claws-mail, and could share my setup, if anyone is interested in homebrewn solution for the save apply part. I use webmail (mostly due to namely calendar integration, quick search of all email, easy access anywhere, etc), which makes this difficult. So I probably would need to tag and/or move the mail messages w/ the patches to an IMAP folder, and then have the fetchmail + apply + etc on the script which I'd run from a git checkout. I wouldn't mind take a look to your script. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50: use larger arrays to silence warnings
On 02/01/2012 03:40 AM, Jose Fonseca wrote: Silences warnings and fixes potential bugs due to buffer overflow. The nv50 maintainers could benefit from sprinkling a few asserts to catch this early in the future, as it is bound to happen again. Good point. I'll add a couple asserts. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glapi dispatch table isn't built correctly with --shared-glapi
This is with git master, but the same issue exists since at least mesa-7.11.2. ./configure --enable-shared-glapi --disable-driglx-direct --with-driver=dri --with-dri-drivers=swrast --with-gallium-drivers=swrast $ gdb --args ./glean -r foo -o -t vertProg1 --quick ... (gdb) b __indirect_glProgramParameters4fvNV Function __indirect_glProgramParameters4fvNV not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (__indirect_glProgramParameters4fvNV) pending. (gdb) r Starting program: /opt/jhbuild/git/glean/bin/glean -r foo -o -t vertProg1 --quick Breakpoint 1, __indirect_glProgramParameters4fvNV (target=1, index=135353784, num=20, params=0xb11c) at indirect.c:9306 9306struct glx_context *const gc = __glXGetCurrentContext(); (gdb) bt #0 __indirect_glProgramParameters4fvNV (target=1, index=135353784, num=20, params=0xb11c) at indirect.c:9306 #1 0x080b719b in GLEAN::VertexProgramTest::setup (this=0x8115520) at tvertprog1.cpp:831 #2 0x080b82e3 in GLEAN::VertexProgramTest::runOne (this=0x8115520, r=..., w=...) at tvertprog1.cpp:1112 #3 0x08059885 in GLEAN::BaseTestGLEAN::MultiTestResult::run (this=0x8115520, environment=...) at tbase.h:317 #4 0x08053ec0 in main (argc=7, argv=0xb3d4) at main.cpp:140 (gdb) frame 1 #1 0x080b719b in GLEAN::VertexProgramTest::setup (this=0x8115520) at tvertprog1.cpp:831 831 glGenProgramsARB_func(1, progID); Note that glean is calling glGenPrograms, but we are ending up in glProgramParameters4fvNV. It seems the indirect dispatch table isn't being built correctly. The dispatch table layouts in glapi_map_tmpi.h and glapitable.h are inconsistent when buiding shared glapi, as shared-glapi/glapi_mapi_tmp.h is generated from gl_and_es_API.xml, whereas glapitable.h is generated from gl_API.xml ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Use a fake reloc to sleep for fences
r300g is able to sleep until a fence completes rather than busywait because
it creates a special buffer object and relocation that stays busy until the
CS containing the fence is finished.
Copy the idea into r600g, and use it to sleep if the user asked for an
infinite wait, falling back to busywaiting if the user provided a timeout.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
This is a userspace only fix for my problem, as suggested by Mark Olšák. It
doesn't fix the case with a timeout (which doesn't matter to me), but works
on existing kernels.
Given that my previous suggested fix opened a can of worms (mostly because I
don't fully understand modern Radeon hardware), this is probably enough of a
fix to apply for now, leaving a proper fix for someone with more
understanding of the way multiple rings interact.
src/gallium/drivers/r600/r600.h|2 +-
src/gallium/drivers/r600/r600_hw_context.c | 16 +++-
src/gallium/drivers/r600/r600_pipe.c | 10 +-
src/gallium/drivers/r600/r600_pipe.h |1 +
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index baf09c1..bac4890 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -284,7 +284,7 @@ void r600_context_queries_resume(struct r600_context *ctx);
void r600_query_predication(struct r600_context *ctx, struct r600_query
*query, int operation,
int flag_wait);
void r600_context_emit_fence(struct r600_context *ctx, struct r600_resource
*fence,
- unsigned offset, unsigned value);
+ unsigned offset, unsigned value, struct pb_buffer
**sleep_bo);
void r600_context_flush_all(struct r600_context *ctx, unsigned flush_flags);
void r600_context_flush_dest_caches(struct r600_context *ctx);
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 8eb8e6d..cc81c48 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -1603,7 +1603,7 @@ void r600_context_flush(struct r600_context *ctx,
unsigned flags)
}
}
-void r600_context_emit_fence(struct r600_context *ctx, struct r600_resource
*fence_bo, unsigned offset, unsigned value)
+void r600_context_emit_fence(struct r600_context *ctx, struct r600_resource
*fence_bo, unsigned offset, unsigned value, struct pb_buffer **sleep_bo)
{
uint64_t va;
@@ -1623,6 +1623,20 @@ void r600_context_emit_fence(struct r600_context *ctx,
struct r600_resource *fen
ctx-pm4[ctx-pm4_cdwords++] = 0; /* DATA_HI */
ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_NOP, 0, 0);
ctx-pm4[ctx-pm4_cdwords++] = r600_context_bo_reloc(ctx, fence_bo,
RADEON_USAGE_WRITE);
+
+ if (sleep_bo) {
+ unsigned reloc_index;
+ /* Create a dummy BO so that fence_finish without a timeout can
sleep waiting for completion */
+ *sleep_bo = ctx-ws-buffer_create(ctx-ws, 1, 1,
+ PIPE_BIND_CUSTOM,
+ RADEON_DOMAIN_GTT);
+ /* Add the fence as a dummy relocation. */
+ reloc_index = ctx-ws-cs_add_reloc(ctx-cs,
+
ctx-ws-buffer_get_cs_handle(*sleep_bo),
+ RADEON_USAGE_READWRITE,
RADEON_DOMAIN_GTT);
+ if (reloc_index = ctx-creloc)
+ ctx-creloc = reloc_index+1;
+ }
}
static unsigned r600_query_read_result(char *map, unsigned start_index,
unsigned end_index,
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index c38fbc5..71e31b1 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -115,7 +115,7 @@ static struct r600_fence *r600_create_fence(struct
r600_pipe_context *ctx)
pipe_reference_init(fence-reference, 1);
rscreen-fences.data[fence-index] = 0;
- r600_context_emit_fence(ctx-ctx, rscreen-fences.bo, fence-index, 1);
+ r600_context_emit_fence(ctx-ctx, rscreen-fences.bo, fence-index, 1,
fence-sleep_bo);
out:
pipe_mutex_unlock(rscreen-fences.mutex);
return fence;
@@ -605,6 +605,14 @@ static boolean r600_fence_finish(struct pipe_screen
*pscreen,
}
while (rscreen-fences.data[rfence-index] == 0) {
+ /* Special-case infinite timeout */
+ if (timeout == PIPE_TIMEOUT_INFINITE
+ rfence-sleep_bo) {
+ rscreen-ws-buffer_wait(rfence-sleep_bo,
RADEON_USAGE_READWRITE);
+ pb_reference(rfence-sleep_bo, NULL);
+ continue;
+ }
+
if (++spins % 256)
[Mesa-dev] [PATCH] glsl: Modify glsl-max-varyings to test varying packing
---
tests/shaders/CMakeLists.gl.txt |1 +
tests/shaders/glsl-max-varyings-2.c | 413 +++
2 files changed, 414 insertions(+), 0 deletions(-)
create mode 100644 tests/shaders/glsl-max-varyings-2.c
diff --git a/tests/shaders/CMakeLists.gl.txt b/tests/shaders/CMakeLists.gl.txt
index 9d72260..b00219e 100644
--- a/tests/shaders/CMakeLists.gl.txt
+++ b/tests/shaders/CMakeLists.gl.txt
@@ -143,6 +143,7 @@ add_executable (vp-ignore-input vp-ignore-input.c)
add_executable (glsl-empty-vs-no-fs glsl-empty-vs-no-fs.c)
add_executable (glsl-mat-attribute glsl-mat-attribute.c)
add_executable (glsl-max-varyings glsl-max-varyings.c)
+add_executable (glsl-max-varyings-2 glsl-max-varyings-2.c)
add_executable (glsl-useprogram-displaylist glsl-useprogram-displaylist.c)
add_executable (glsl-routing glsl-routing.c)
add_executable (shader_runner shader_runner.c)
diff --git a/tests/shaders/glsl-max-varyings-2.c
b/tests/shaders/glsl-max-varyings-2.c
new file mode 100644
index 000..b020d6c
--- /dev/null
+++ b/tests/shaders/glsl-max-varyings-2.c
@@ -0,0 +1,413 @@
+/*
+ * Copyright © 2010 Intel Corporation
+ *
+ * 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:
+ *Eric Anholt e...@anholt.net
+ *
+ */
+
+/** @file glsl-max-varyings.c
+ *
+ * Tests whether GL_MAX_VARYING_FLOATS varying components can be used when
packed
+ * as vec4, vec3, vec2, or float. Drivers have to pack varyings to pass this
test.
+ */
+
+#include piglit-util.h
+
+#define MAX_VARYING 128
+
+/* 10x10 rectangles with 2 pixels of pad. Deal with up to 32 varyings. */
+int piglit_width = (2 + MAX_VARYING * 12), piglit_height = (2 + MAX_VARYING *
12);
+int piglit_window_mode = GLUT_RGB | GLUT_DOUBLE;
+
+
+enum varyings_type {
+ FLT = 0,
+ V2 = 1,
+ V3 = 2,
+ V4 = 3
+};
+
+const unsigned increments[] = { 4, 2, 2, 1 };
+
+/* Generate a VS that writes to num_varyings vec4s, and put
+ * interesting data in data_varying with 0.0 everywhere else.
+ */
+static GLint get_vs(int num_varyings, int data_varying, enum varyings_type
type)
+{
+
+ const char * varying_decl[] = {
+ varying float v%d;\n,
+ varying vec2 v%d;\n,
+ varying vec3 v%d;\n,
+ varying vec4 v%d;\n,
+ };
+
+ GLuint shader;
+ unsigned i;
+ char *code;
+ char temp[2048];
+
+ code = malloc(2048 * 4);
+ code[0] = 0;
+ for (i = 0; i num_varyings; i++) {
+sprintf(temp, varying_decl[type], i);
+ strcat(code, temp);
+ }
+
+ sprintf(temp,
+ attribute vec4 green;\n
+ attribute float v_zero;\n
+ void main()\n
+ {\n
+ gl_Position = (gl_ModelViewProjectionMatrix * \n
+ gl_Vertex);\n
+ );
+ strcat(code, temp);
+ i = 0;
+ while (i + increments[type] num_varyings) {
+ if (i == data_varying) {
+ switch (type) {
+ case FLT:
+ sprintf(temp,
+ v%d = green.x;\n
+ v%d = green.y;\n
+ v%d = green.z;\n
+ v%d = green.w;\n,
+ i,
+ i + 1,
+ i + 2,
+ i + 3);
+ break;
+ case V2:
+ sprintf(temp,
+ v%d = green.xy;\n
+ v%d = green.zw;\n,
+ i,
+ i + 1);
+ break;
+ case V3:
+ sprintf(temp,
+ v%d = green.xyz;\n
+ v%d.x = green.w;\n,
+ i,
+ i + 1);
+ break;
+
Re: [Mesa-dev] [PATCH] r600g: Use a fake reloc to sleep for fences
On Wednesday 1 February 2012, Simon Farnsworth simon.farnswo...@onelan.co.uk wrote: This is a userspace only fix for my problem, as suggested by Mark Olšák. It My apologies, Marek; my typing appears to have failed me, and renamed you to Mark. I shall try not to make that mistake again. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ 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] nv50: use larger arrays to silence warnings
On 01.02.2012 15:23, Brian Paul wrote: On 02/01/2012 03:40 AM, Jose Fonseca wrote: Silences warnings and fixes potential bugs due to buffer overflow. The nv50 maintainers could benefit from sprinkling a few asserts to catch this early in the future, as it is bound to happen again. Good point. I'll add a couple asserts. Hm, I don't see any assertions in the commit ... I should really have used something like NV50_MAX_INSN_SRCS in the loop in the old code there (nv50_pc_regalloc), but it's scheduled for removal anyway ... As for the optimization pass, I don't see how the compiler can statically determine that the array will overflow, and it wasn't supposed to (maximum store size is 16 bytes, and minimum size of a Value (with TGSI input) is 4 bytes, makes 4 Values. But you're right I should have been more careful with that code, it's ... been written at a point where I just wanted to be done with it (but still include enough optimizations so as to not produce worse code than the old solution). Thanks for fixing, Christoph hm, I need to make my compiler spit out better/more warnings ... -Brian ___ 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] [PATCH] nv50: use larger arrays to silence warnings
On 02/01/2012 08:14 AM, Christoph Bumiller wrote: On 01.02.2012 15:23, Brian Paul wrote: On 02/01/2012 03:40 AM, Jose Fonseca wrote: Silences warnings and fixes potential bugs due to buffer overflow. The nv50 maintainers could benefit from sprinkling a few asserts to catch this early in the future, as it is bound to happen again. Good point. I'll add a couple asserts. Hm, I don't see any assertions in the commit ... Grrr, I forgot to fold them into the commit before pushing. I'll push them soon. I should really have used something like NV50_MAX_INSN_SRCS in the loop in the old code there (nv50_pc_regalloc), but it's scheduled for removal anyway ... As for the optimization pass, I don't see how the compiler can statically determine that the array will overflow, I was a bit surprised to see the compiler figure that out too. and it wasn't supposed to (maximum store size is 16 bytes, and minimum size of a Value (with TGSI input) is 4 bytes, makes 4 Values. But you're right I should have been more careful with that code, it's ... been written at a point where I just wanted to be done with it (but still include enough optimizations so as to not produce worse code than the old solution). Thanks for fixing, Christoph hm, I need to make my compiler spit out better/more warnings ... Do you want to cherry-pick these fixes to 8.0? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50: use larger arrays to silence warnings
On 01.02.2012 16:21, Brian Paul wrote: On 02/01/2012 08:14 AM, Christoph Bumiller wrote: On 01.02.2012 15:23, Brian Paul wrote: On 02/01/2012 03:40 AM, Jose Fonseca wrote: Silences warnings and fixes potential bugs due to buffer overflow. The nv50 maintainers could benefit from sprinkling a few asserts to catch this early in the future, as it is bound to happen again. Good point. I'll add a couple asserts. Hm, I don't see any assertions in the commit ... Grrr, I forgot to fold them into the commit before pushing. I'll push them soon. I should really have used something like NV50_MAX_INSN_SRCS in the loop in the old code there (nv50_pc_regalloc), but it's scheduled for removal anyway ... As for the optimization pass, I don't see how the compiler can statically determine that the array will overflow, I was a bit surprised to see the compiler figure that out too. and it wasn't supposed to (maximum store size is 16 bytes, and minimum size of a Value (with TGSI input) is 4 bytes, makes 4 Values. But you're right I should have been more careful with that code, it's ... been written at a point where I just wanted to be done with it (but still include enough optimizations so as to not produce worse code than the old solution). Thanks for fixing, Christoph hm, I need to make my compiler spit out better/more warnings ... Do you want to cherry-pick these fixes to 8.0? Yes, seems like the kind of fix that should go into stable. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vbo: fix node_attrsz[] usage in vbo_bind_vertex_list()
The node_attrsz[] array is initially copied from the node-attrsz[] array but some values get rewritten. Thereafter, we need to use the node_attrsz[] values. Fixes a bug when replaying a display list that uses generic vertex array[16] (at least). NOTE: This is a candidate for the 8.0 branch. --- src/mesa/vbo/vbo_save_draw.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c index 9f02905..b903757 100644 --- a/src/mesa/vbo/vbo_save_draw.c +++ b/src/mesa/vbo/vbo_save_draw.c @@ -191,7 +191,7 @@ static void vbo_bind_vertex_list(struct gl_context *ctx, save-inputs[attr] = arrays[attr]; arrays[attr].Ptr = (const GLubyte *) NULL + buffer_offset; -arrays[attr].Size = node-attrsz[src]; +arrays[attr].Size = node_attrsz[src]; arrays[attr].StrideB = node-vertex_size * sizeof(GLfloat); arrays[attr].Stride = node-vertex_size * sizeof(GLfloat); arrays[attr].Type = GL_FLOAT; @@ -205,7 +205,7 @@ static void vbo_bind_vertex_list(struct gl_context *ctx, assert(arrays[attr].BufferObj-Name); -buffer_offset += node-attrsz[src] * sizeof(GLfloat); +buffer_offset += node_attrsz[src] * sizeof(GLfloat); varying_inputs |= VERT_BIT(attr); ctx-NewState |= _NEW_ARRAY; } -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glapi dispatch table isn't built correctly with --shared-glapi
On Wed, Feb 1, 2012 at 9:41 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: This is with git master, but the same issue exists since at least mesa-7.11.2. ./configure --enable-shared-glapi --disable-driglx-direct --with-driver=dri --with-dri-drivers=swrast --with-gallium-drivers=swrast $ gdb --args ./glean -r foo -o -t vertProg1 --quick ... (gdb) b __indirect_glProgramParameters4fvNV Function __indirect_glProgramParameters4fvNV not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (__indirect_glProgramParameters4fvNV) pending. (gdb) r Starting program: /opt/jhbuild/git/glean/bin/glean -r foo -o -t vertProg1 --quick Breakpoint 1, __indirect_glProgramParameters4fvNV (target=1, index=135353784, num=20, params=0xb11c) at indirect.c:9306 9306 struct glx_context *const gc = __glXGetCurrentContext(); (gdb) bt #0 __indirect_glProgramParameters4fvNV (target=1, index=135353784, num=20, params=0xb11c) at indirect.c:9306 #1 0x080b719b in GLEAN::VertexProgramTest::setup (this=0x8115520) at tvertprog1.cpp:831 #2 0x080b82e3 in GLEAN::VertexProgramTest::runOne (this=0x8115520, r=..., w=...) at tvertprog1.cpp:1112 #3 0x08059885 in GLEAN::BaseTestGLEAN::MultiTestResult::run (this=0x8115520, environment=...) at tbase.h:317 #4 0x08053ec0 in main (argc=7, argv=0xb3d4) at main.cpp:140 (gdb) frame 1 #1 0x080b719b in GLEAN::VertexProgramTest::setup (this=0x8115520) at tvertprog1.cpp:831 831 glGenProgramsARB_func(1, progID); Note that glean is calling glGenPrograms, but we are ending up in glProgramParameters4fvNV. It seems the indirect dispatch table isn't being built correctly. The dispatch table layouts in glapi_map_tmpi.h and glapitable.h are inconsistent when buiding shared glapi, as shared-glapi/glapi_mapi_tmp.h is generated from gl_and_es_API.xml, whereas glapitable.h is generated from gl_API.xml Do you think this is related to http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg17627.html ? Thanks, Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gen_matypes: fix cross-compiling with gcc
On Tue, Jan 31, 2012 at 6:07 PM, Mike Frysinger vap...@gentoo.org wrote:
The current gen_matypes logic assumes that the host compiler will produce
information that is useful for the target compiler. Unfortunately, this
is not the case whenever cross-compiling.
When we detect that we're cross-compiling and using GCC, use the target
compiler to produce assembly from the gen_matypes.c source, then process
it with a shell script to create a usable header. This is similar to how
the linux kernel creates its asm-offsets.c file.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
Note: please keep me on cc as i'm not subscribed
configs/autoconf.in | 2 ++
configure.ac | 6 ++
src/mesa/x86/Makefile | 18 +++---
src/mesa/x86/gen_matypes.c | 35 +--
4 files changed, 52 insertions(+), 9 deletions(-)
diff --git a/configs/autoconf.in b/configs/autoconf.in
index bb8f2c3..4ad49ea 100644
--- a/configs/autoconf.in
+++ b/configs/autoconf.in
@@ -213,3 +213,5 @@ ifneq ($(LLVM_VERSION),)
endif
HAVE_XF86VIDMODE = @HAVE_XF86VIDMODE@
+
+GEN_ASM_OFFSETS = @GEN_ASM_OFFSETS@
diff --git a/configure.ac b/configure.ac
index 0e03af7..25c30d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -106,6 +106,7 @@ AC_MSG_RESULT([$acv_mesa_CLANG])
dnl If we're using GCC, make sure that it is at least version 3.3.0. Older
dnl versions are explictly not supported.
+GEN_ASM_OFFSETS=no
if test x$GCC = xyes -a x$acv_mesa_CLANG = xno; then
AC_MSG_CHECKING([whether gcc version is sufficient])
major=0
@@ -123,7 +124,12 @@ if test x$GCC = xyes -a x$acv_mesa_CLANG = xno; then
else
AC_MSG_RESULT([yes])
fi
+
+ if test x$cross_compiling = xyes; then
+ GEN_ASM_OFFSETS=yes
+ fi
fi
+AC_SUBST([GEN_ASM_OFFSETS])
MKDEP_OPTIONS=-fdepend
diff --git a/src/mesa/x86/Makefile b/src/mesa/x86/Makefile
index 9716dc2..0dba5a2 100644
--- a/src/mesa/x86/Makefile
+++ b/src/mesa/x86/Makefile
@@ -13,8 +13,7 @@ INCLUDE_DIRS = \
-I../math \
-I../tnl
-
-default: gen_matypes matypes.h
+default: matypes.h
clean:
-rm -f matypes.h gen_matypes
@@ -24,9 +23,22 @@ gen_matypes: gen_matypes.c
$(HOST_CC) $(ARCH_FLAGS) $(INCLUDE_DIRS) $(HOST_CFLAGS) gen_matypes.c
-o gen_matypes
# need some special rules here, unfortunately
-matypes.h: ../main/mtypes.h ../tnl/t_context.h gen_matypes
+matypes.h: ../main/mtypes.h ../tnl/t_context.h
+
+ifeq ($(GEN_ASM_OFFSETS),yes)
+
+matypes.h: gen_matypes.c
+ $(CC) $(ARCH_FLAGS) $(INCLUDE_DIRS) $(CFLAGS) gen_matypes.c
-DASM_OFFSETS -S -o - | \
+ sed -n '/^-/{s:^-::;/[$$]/{s:^:#define :;s:[$$]::};p}' $@
+
+else
+
+default: gen_matypes
+matypes.h: gen_matypes
./gen_matypes matypes.h
+endif
+
common_x86_asm.o: matypes.h
3dnow_normal.o: matypes.h
3dnow_xform1.o: matypes.h
diff --git a/src/mesa/x86/gen_matypes.c b/src/mesa/x86/gen_matypes.c
index 97f71f9..b359bb8 100644
--- a/src/mesa/x86/gen_matypes.c
+++ b/src/mesa/x86/gen_matypes.c
@@ -52,7 +52,7 @@ do {
\
printf( \n ); \
printf( /* = \
\n ); \
- printf( * Offsets for %s\n, x ); \
+ printf( * Offsets for x \n ); \
printf( */\n ); \
printf( \n ); \
} while (0)
@@ -61,20 +61,43 @@ do {
\
do { \
printf( \n ); \
printf( /*\n ); \
- printf( * Flags for %s\n, x ); \
+ printf( * Flags for x \n ); \
printf( */\n ); \
printf( \n ); \
} while (0)
-#define OFFSET( s, t, m ) \
- printf( #define %s\t%lu\n, s, (unsigned long) offsetof( t, m ) );
+#ifdef ASM_OFFSETS
-#define SIZEOF( s, t ) \
- printf( #define %s\t%lu\n, s, (unsigned long) sizeof(t) );
+/*
+ * Format the asm output in a special way that we can manipulate
+ * after the fact and turn into the final header for the target.
+ */
+
+#define DEFINE_UL( s, ul ) \
+ __asm__ __volatile__ ( \n- s %0 : : i (ul) )
+
+#define DEFINE( s, d )
[Mesa-dev] [Bug 38970] [bisected]piglit glx/glx-pixmap-multi failed
https://bugs.freedesktop.org/show_bug.cgi?id=38970 Ian Romanick i...@freedesktop.org changed: What|Removed |Added Blocks|42993 | --- Comment #17 from Ian Romanick i...@freedesktop.org 2012-02-01 08:01:29 PST --- I'm going to remove this from the blocker list. Some further analysis suggests that Adam is correct. The test was generating a pass result, but the underlying functionality was not working. I'd argue, therefore, that this is not a regression. In some sense this situation is better: the user gets an error instead of some garbage that won't work. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Use a fake reloc to sleep for fences
[ Dropping dri-devel list ]
On Mit, 2012-02-01 at 15:01 +, Simon Farnsworth wrote:
r300g is able to sleep until a fence completes rather than busywait because
it creates a special buffer object and relocation that stays busy until the
CS containing the fence is finished.
Copy the idea into r600g, and use it to sleep if the user asked for an
infinite wait, falling back to busywaiting if the user provided a timeout.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
This is a userspace only fix for my problem, as suggested by Mark Olšák. It
doesn't fix the case with a timeout (which doesn't matter to me), but works
on existing kernels.
Given that my previous suggested fix opened a can of worms (mostly because I
don't fully understand modern Radeon hardware), this is probably enough of a
fix to apply for now, leaving a proper fix for someone with more
understanding of the way multiple rings interact.
[...]
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index 8eb8e6d..cc81c48 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -1623,6 +1623,20 @@ void r600_context_emit_fence(struct r600_context *ctx,
struct r600_resource *fen
ctx-pm4[ctx-pm4_cdwords++] = 0; /* DATA_HI */
ctx-pm4[ctx-pm4_cdwords++] = PKT3(PKT3_NOP, 0, 0);
ctx-pm4[ctx-pm4_cdwords++] = r600_context_bo_reloc(ctx, fence_bo,
RADEON_USAGE_WRITE);
+
+ if (sleep_bo) {
+ unsigned reloc_index;
+ /* Create a dummy BO so that fence_finish without a timeout can
sleep waiting for completion */
+ *sleep_bo = ctx-ws-buffer_create(ctx-ws, 1, 1,
+PIPE_BIND_CUSTOM,
+RADEON_DOMAIN_GTT);
+ /* Add the fence as a dummy relocation. */
+ reloc_index = ctx-ws-cs_add_reloc(ctx-cs,
+
ctx-ws-buffer_get_cs_handle(*sleep_bo),
+ RADEON_USAGE_READWRITE,
RADEON_DOMAIN_GTT);
+ if (reloc_index = ctx-creloc)
+ ctx-creloc = reloc_index+1;
+ }
Is there a point in making sleep_bo optional?
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index c38fbc5..71e31b1 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -605,6 +605,14 @@ static boolean r600_fence_finish(struct pipe_screen
*pscreen,
}
while (rscreen-fences.data[rfence-index] == 0) {
+ /* Special-case infinite timeout */
+ if (timeout == PIPE_TIMEOUT_INFINITE
+ rfence-sleep_bo) {
+ rscreen-ws-buffer_wait(rfence-sleep_bo,
RADEON_USAGE_READWRITE);
+ pb_reference(rfence-sleep_bo, NULL);
+ continue;
+ }
I think rfence-sleep_bo should only be unreferenced in
r600_fence_reference() when the fence is recycled, otherwise it'll be
leaked if r600_fence_finish() is never called for some reason.
If r600_fence_finish() only ever called os_time_sleep(), never
sched_yield() (like r300_fence_finish()), would that avoid your problem
even with a finite timeout?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: FBOs with texture border are unsupported
From: Ian Romanick ian.d.roman...@intel.com
FBOs differ from textures in a significant way. With textures, we can
strip the border and get correct rendering except when the application
fetches texels outside [0,1].
With an FBO, the pixel at (0,0) is in the border. The
ARB_framebuffer_object spec says:
If the attached image is a texture image, then the window
coordinates (x[w], y[w]) correspond to the texel (i, j, k), from
figure 3.10 as follows:
i = (x[w] - b)
j = (y[w] - b)
k = (layer - b)
where b is the texture image's border width...
Since the border doesn't exist, we can never render any pixels in the
correct location. Just mark these FBOs FRAMEBUFFER_UNSUPPORTED.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42336
---
src/mesa/drivers/dri/intel/intel_fbo.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 2ba43ac..62ed754 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -746,6 +746,7 @@ intel_validate_framebuffer(struct gl_context *ctx, struct
gl_framebuffer *fb)
for (i = 0; i Elements(fb-Attachment); i++) {
struct gl_renderbuffer *rb;
+ struct gl_texture_object *tex;
struct intel_renderbuffer *irb;
if (fb-Attachment[i].Type == GL_NONE)
@@ -762,6 +763,18 @@ intel_validate_framebuffer(struct gl_context *ctx, struct
gl_framebuffer *fb)
continue;
}
+ tex = fb-Attachment[i].Texture;
+ if (tex != NULL) {
+const unsigned face = fb-Attachment[i].CubeMapFace;
+const unsigned level = fb-Attachment[i].TextureLevel;
+
+if (tex-Image[face][level]-Border) {
+ DBG(texture with border\n);
+ fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
+ continue;
+}
+ }
+
irb = intel_renderbuffer(rb);
if (irb == NULL) {
DBG(software rendering renderbuffer\n);
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Use a fake reloc to sleep for fences
On Wednesday 1 February 2012, Michel Dänzer mic...@daenzer.net wrote:
On Mit, 2012-02-01 at 15:01 +, Simon Farnsworth wrote:
+ if (sleep_bo) {
+ unsigned reloc_index;
+ /* Create a dummy BO so that fence_finish without a timeout can
sleep waiting for completion */
+ *sleep_bo = ctx-ws-buffer_create(ctx-ws, 1, 1,
+ PIPE_BIND_CUSTOM,
+ RADEON_DOMAIN_GTT);
+ /* Add the fence as a dummy relocation. */
+ reloc_index = ctx-ws-cs_add_reloc(ctx-cs,
+
ctx-ws-buffer_get_cs_handle(*sleep_bo),
+ RADEON_USAGE_READWRITE,
RADEON_DOMAIN_GTT);
+ if (reloc_index = ctx-creloc)
+ ctx-creloc = reloc_index+1;
+ }
Is there a point in making sleep_bo optional?
I can't think of a reason to make it optional; I'll remove that in v2.
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index c38fbc5..71e31b1 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -605,6 +605,14 @@ static boolean r600_fence_finish(struct pipe_screen
*pscreen,
}
while (rscreen-fences.data[rfence-index] == 0) {
+ /* Special-case infinite timeout */
+ if (timeout == PIPE_TIMEOUT_INFINITE
+ rfence-sleep_bo) {
+ rscreen-ws-buffer_wait(rfence-sleep_bo,
RADEON_USAGE_READWRITE);
+ pb_reference(rfence-sleep_bo, NULL);
+ continue;
+ }
I think rfence-sleep_bo should only be unreferenced in
r600_fence_reference() when the fence is recycled, otherwise it'll be
leaked if r600_fence_finish() is never called for some reason.
I'll fix this in v2.
If r600_fence_finish() only ever called os_time_sleep(), never
sched_yield() (like r300_fence_finish()), would that avoid your problem
even with a finite timeout?
I experimented with that - depending on the specific workload, I need the
timeout to vary, otherwise I can see the impact of the loop in terms of bad
latency behaviour (resulting in occasional dropped frames). For the
workloads I tried, I needed the sleep to vary between 1 usec (for
low-complexity workloads) and 100 usec (for high complexity
workloads). Recompiling Mesa for each workload is obviously not an option.
I did try an adaptive spin - essentially removing the if (spins++ % 256)
continue, and adding:
if (spins 40)
os_sleep_time(1);
else if (spins 100)
os_sleep_time(10);
else
os_sleep_time(100);
But I felt this was ugly, when the core problem is that I want to sleep
until completion, the hardware has support for sleeping until completion,
and the only reason I can't is deficiencies in the driver stack.
Fundamentally, I suspect that the reason I'm seeing pain from this and other
people aren't is that I'm comparing an AMD E-350 to an Intel Atom D510, and
I've tuned my software stack on the D510 to within an inch of its life.
My expectation is that the better GPU in the E-350 will make my 2D
graphics-intensive workload (OpenGL compositing of 2D movies) perform about
as well as it did on the D510 - sleep-based waiting for fence completion
gets in the way, as the D510 has slightly more CPU power than the E-350, and
I'm not (yet) fully exploiting the E-350's GPU.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
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
[Mesa-dev] [PATCH] intel: Remove num_mapped_regions assertion from _intel_batchbuffer_flush
From: Ian Romanick ian.d.roman...@intel.com
There are cases where a buffer can be mapped while another buffer is
flushed. This can happen in the CopyPixels meta-op path for piglit's
fbo-mipmap-copypix. After some discussion with Eric, it seems this
assertion is no longer necessary, and it has always been too strict.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Eric Anholt e...@anholt.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43328
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index f4bc6b2..c58dee8 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -208,13 +208,6 @@ _intel_batchbuffer_flush(struct intel_context *intel,
{
int ret;
- /* No batch should be emitted that uses a mapped region, because that would
-* cause the map to be incoherent with GPU rendering done by the
-* batchbuffer. To ensure that condition, we assert a condition that is
-* stronger but easier to implement: that *no* region is mapped.
-*/
- assert(intel-num_mapped_regions == 0);
-
if (intel-batch.used == 0)
return 0;
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Remove num_mapped_regions assertion from _intel_batchbuffer_flush
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2012 10:40 AM, Ian Romanick wrote: From: Ian Romanick ian.d.roman...@intel.com There are cases where a buffer can be mapped while another buffer is flushed. This can happen in the CopyPixels meta-op path for piglit's fbo-mipmap-copypix. After some discussion with Eric, it seems this assertion is no longer necessary, and it has always been too strict. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Cc: Eric Anholt e...@anholt.net Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43328 - From inspection of how intel_miptree_map() is used, I believe the assertion can safely be removed. Reviewed-by: Chad Versace chad.vers...@linux.intel.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPKYl1AAoJEAIvNt057x8iNqYP/3VwhK6zNvIFf7i+4LU2Z6LI RD1Pzb+ib8sUqAMgdelQYSyycVMCmaWxMrRQ+mYYU9TjhBd/W3Uo5hhh6J9LVDqZ jqwIEcTAspLwB+/q/er8/pOJ+V7/K4YB0/D4n5u1273PSE0/bE1AVm0VOgilQCNU tTuCJ+By5fc6A5t5DQR3uAiNZuPeGWIouCT0R9IK6drHaAdyM/uZm/bq0Od5aXvk XRMLefbXZXip3ZDL62YuUAK/x4QEek39fVgoRFUxXzzAZFYF6qderlEt6GbHu0Qa 6an8CTbNGYeLt8fiBbjYocNZlpD7QUQjLk35UI1qpYVkV+rt/6ZEHo3FSBfIW76Q oay1R0ZmSze/FYvjdiZtFZRJJKmGrN8R8BA/hy/SQDZqhJRpTSVnBVVO/cfiPh9K m7N5LX/XTeHfWftcrqrHNsVdRIq3s3HVlsQvmlE/24ZZpQcGExsBm3r7j8/tIOpZ 9MJgdIfi4qRZArbW35hfEg6zvoyOnVC7dhMGuZFng0fECjf3D7wM6fXsphaeeMUn m1zh7DsGz5hj4fyAOAzIlq4Kigh3xtX8bsiIO8d9vyQR1swEcmqpxwR8nQCqttQk jbot3bx9W31kQnrMdx11GpZUDNWKoZf1l+o74VC5I3Ei+XbNZ8E5mN5o2o7uH1Cl XdUiq5aBcSSD4luxuTBU =JooQ -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glapi dispatch table isn't built correctly with --shared-glapi
On 01/02/2012 15:59, Matt Turner wrote: On Wed, Feb 1, 2012 at 9:41 AM, Jon TURNEY wrote: Note that glean is calling glGenPrograms, but we are ending up in glProgramParameters4fvNV. It seems the indirect dispatch table isn't being built correctly. The dispatch table layouts in glapi_map_tmpi.h and glapitable.h are inconsistent when buiding shared glapi, as shared-glapi/glapi_mapi_tmp.h is generated from gl_and_es_API.xml, whereas glapitable.h is generated from gl_API.xml Do you think this is related to http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg17627.html ? The part of that thread that says... On 24/01/2012 01:59, Brian Paul wrote: However, any program that uses extension functions acts peculiar and dies: ... I would guess so, yes. Turning --shared-glapi always on just made it more obvious it was broken :S ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: Also check renderability in intel_renderbuffer_update_wrapper
From: Ian Romanick ian.d.roman...@intel.com
A similar check was removed in 05ab8fc. The check is not complete
redundand because some paths, such as
_mesa_meta_check_generate_mipmap_fallback, can get to
intel_renderbuffer_update_wrapper but not get to
intel_validate_framebuffer. This occurs when trying to generate
mipmaps for GL_SLUMINANCE8 textures.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44961
Cc: Eric Anholt e...@anholt.net
---
src/mesa/drivers/dri/intel/intel_fbo.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 62ed754..c235fb4 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -482,6 +482,12 @@ intel_renderbuffer_update_wrapper(struct intel_context
*intel,
rb-Delete = intel_delete_renderbuffer;
rb-AllocStorage = intel_nop_alloc_storage;
+ if (!intel-vtbl.render_target_supported(intel, rb)) {
+ DBG(Render to texture BAD FORMAT %s\n,
+ _mesa_get_format_name(rb-Format));
+ return false;
+ }
+
intel_miptree_check_level_layer(mt, level, layer);
irb-mt_level = level;
irb-mt_layer = layer;
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vbo: fix node_attrsz[] usage in vbo_bind_vertex_list()
On 02/01/2012 08:52 AM, Brian Paul wrote: The node_attrsz[] array is initially copied from the node-attrsz[] array but some values get rewritten. Thereafter, we need to use the node_attrsz[] values. Fixes a bug when replaying a display list that uses generic vertex array[16] (at least). NOTE: This is a candidate for the 8.0 branch. Reviewed-by: Ian Romanick ian.d.roman...@intel.com --- src/mesa/vbo/vbo_save_draw.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c index 9f02905..b903757 100644 --- a/src/mesa/vbo/vbo_save_draw.c +++ b/src/mesa/vbo/vbo_save_draw.c @@ -191,7 +191,7 @@ static void vbo_bind_vertex_list(struct gl_context *ctx, save-inputs[attr] =arrays[attr]; arrays[attr].Ptr = (const GLubyte *) NULL + buffer_offset; -arrays[attr].Size = node-attrsz[src]; +arrays[attr].Size = node_attrsz[src]; arrays[attr].StrideB = node-vertex_size * sizeof(GLfloat); arrays[attr].Stride = node-vertex_size * sizeof(GLfloat); arrays[attr].Type = GL_FLOAT; @@ -205,7 +205,7 @@ static void vbo_bind_vertex_list(struct gl_context *ctx, assert(arrays[attr].BufferObj-Name); -buffer_offset += node-attrsz[src] * sizeof(GLfloat); +buffer_offset += node_attrsz[src] * sizeof(GLfloat); varying_inputs |= VERT_BIT(attr); ctx-NewState |= _NEW_ARRAY; } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix maximum allowed proxy texture size condition
On 01/28/2012 04:04 AM, Jose Fonseca wrote:
- Original Message -
width, height parameter of glTexImage2D() includes: texture image
width + 2 * border (if any). So when doing the texture size check
in _mesa_test_proxy_teximage() width and height should not exceed
maximum supported size for target texture type.
i.e. 1 (ctx-Const.MaxTextureLevels - 1)
This patch fixes Intel oglconform test case: max_values
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970
Note: This is a candidate for mesa 8.0 branch.
Signed-off-by: Anuj Phogatanuj.pho...@gmail.com
---
src/mesa/main/teximage.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index d11425d..018aca0 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1179,7 +1179,7 @@ _mesa_test_proxy_teximage(struct gl_context
*ctx, GLenum target, GLint level,
switch (target) {
case GL_PROXY_TEXTURE_1D:
maxSize = 1 (ctx-Const.MaxTextureLevels - 1);
- if (width 2 * border || width 2 + maxSize)
+ if (width 2 * border || width maxSize)
Anuj,
I may be missing something, but I'm still unsure about this, because this will
create problems for drivers that do support borders.
AFAIK, the only desktop graphics hardware that ever supported borders is
NVIDIA. Their driver follows the convention (width + 2 * border)
maxSize, and their driver advertises a maximum size of 2^n. I tried
creating a proxy texture that was the full 2^n plus a border on their
closed-source Linux driver, and it was rejected. A proxy texture 2^n-2
plus a border was accepted.
Based on that, I believe this patch is correct.
Intel driver sets:
ctx-Const.StripTextureBorder = GL_TRUE
So I'd expect the right expression to be
if (width 2 * border || width 2 * border + maxSize)
and that we do one two things:
- we return FALSE here if border 0 and ctx-Const.StripTextureBorder ==
GL_TRUE
- or we make sure that the border is striped _everywhere_, including whatever
upload path that caused the segfault in bug 44970.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix maximum allowed proxy texture size condition
- Original Message -
On 01/28/2012 04:04 AM, Jose Fonseca wrote:
- Original Message -
width, height parameter of glTexImage2D() includes: texture image
width + 2 * border (if any). So when doing the texture size check
in _mesa_test_proxy_teximage() width and height should not exceed
maximum supported size for target texture type.
i.e. 1 (ctx-Const.MaxTextureLevels - 1)
This patch fixes Intel oglconform test case: max_values
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970
Note: This is a candidate for mesa 8.0 branch.
Signed-off-by: Anuj Phogatanuj.pho...@gmail.com
---
src/mesa/main/teximage.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index d11425d..018aca0 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1179,7 +1179,7 @@ _mesa_test_proxy_teximage(struct gl_context
*ctx, GLenum target, GLint level,
switch (target) {
case GL_PROXY_TEXTURE_1D:
maxSize = 1 (ctx-Const.MaxTextureLevels - 1);
- if (width 2 * border || width 2 + maxSize)
+ if (width 2 * border || width maxSize)
Anuj,
I may be missing something, but I'm still unsure about this,
because this will create problems for drivers that do support
borders.
AFAIK, the only desktop graphics hardware that ever supported borders
is
NVIDIA. Their driver follows the convention (width + 2 * border)
maxSize, and their driver advertises a maximum size of 2^n. I tried
creating a proxy texture that was the full 2^n plus a border on their
closed-source Linux driver, and it was rejected. A proxy texture
2^n-2
plus a border was accepted.
Based on that, I believe this patch is correct.
Fair enough. Sounds good to me then!
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] intel: verify if hardware has LLC support
Rely on libdrm HAS_LLC parameter to verify if hardware supports it. In case the libdrm version does not supports this check, fallback to older way of detecting it which assumed that GPUs newer than GEN6 have it. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- src/mesa/drivers/dri/intel/intel_context.c |1 + src/mesa/drivers/dri/intel/intel_context.h |1 + src/mesa/drivers/dri/intel/intel_screen.c |8 src/mesa/drivers/dri/intel/intel_screen.h |2 ++ 4 files changed, 12 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index 81ba6a1..377bcbc 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -628,6 +628,7 @@ intelInitContext(struct intel_context *intel, intel-has_separate_stencil = intel-intelScreen-hw_has_separate_stencil; intel-must_use_separate_stencil = intel-intelScreen-hw_must_use_separate_stencil; intel-has_hiz = intel-intelScreen-hw_has_hiz; + intel-has_llc = intel-intelScreen-hw_has_llc; memset(ctx-TextureFormatSupported, 0, sizeof(ctx-TextureFormatSupported)); diff --git a/src/mesa/drivers/dri/intel/intel_context.h b/src/mesa/drivers/dri/intel/intel_context.h index 4d4e030..150e55f 100644 --- a/src/mesa/drivers/dri/intel/intel_context.h +++ b/src/mesa/drivers/dri/intel/intel_context.h @@ -213,6 +213,7 @@ struct intel_context bool has_separate_stencil; bool must_use_separate_stencil; bool has_hiz; + bool has_llc; int urb_size; diff --git a/src/mesa/drivers/dri/intel/intel_screen.c b/src/mesa/drivers/dri/intel/intel_screen.c index 063bbe7..60781e5 100644 --- a/src/mesa/drivers/dri/intel/intel_screen.c +++ b/src/mesa/drivers/dri/intel/intel_screen.c @@ -735,6 +735,14 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp) intelScreen-hw_has_hiz = intelScreen-gen = 6; intelScreen-dri2_has_hiz = INTEL_DRI2_HAS_HIZ_UNKNOWN; +#if defined(I915_PARAM_HAS_LLC) + intelScreen-hw_has_llc = + intel_get_boolean(intelScreen-driScrnPriv, + I915_PARAM_HAS_LLC); +#else + intelScreen-hw_has_llc = intelScreen-gen = 6; +#endif + intel_override_hiz(intelScreen); intel_override_separate_stencil(intelScreen); diff --git a/src/mesa/drivers/dri/intel/intel_screen.h b/src/mesa/drivers/dri/intel/intel_screen.h index 6c6b516..a6baf16 100644 --- a/src/mesa/drivers/dri/intel/intel_screen.h +++ b/src/mesa/drivers/dri/intel/intel_screen.h @@ -116,6 +116,8 @@ struct intel_screen bool kernel_has_gen7_sol_reset; + bool hw_has_llc; + bool no_vbo; dri_bufmgr *bufmgr; struct _mesa_HashTable *named_regions; -- 1.7.8.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] intel: check for LLC support when reading maps
This checks for advertised LLC support by the GPU instead of relying on
the GPU generation for detection.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index eae79c1..5290da4 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -1052,7 +1052,7 @@ intel_miptree_map(struct intel_context *intel,
intel_miptree_map_s8(intel, mt, map, level, slice);
} else if (mt-stencil_mt) {
intel_miptree_map_depthstencil(intel, mt, map, level, slice);
- } else if (intel-gen = 6
+ } else if (intel-has_llc
!(mode GL_MAP_WRITE_BIT)
!mt-compressed
mt-region-tiling == I915_TILING_X) {
--
1.7.8.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Fix copy-and-paste bug in do_row_3D
From: Ian Romanick ian.d.roman...@intel.com
Several of the half-float cases used 4 as the texel size when it
should have been some smaller value.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43324
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43325
---
src/mesa/main/mipmap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
index 03ce536..756316a 100644
--- a/src/mesa/main/mipmap.c
+++ b/src/mesa/main/mipmap.c
@@ -991,7 +991,7 @@ do_row_3D(GLenum datatype, GLuint comps, GLint srcWidth,
}
}
else if ((datatype == GL_HALF_FLOAT_ARB) (comps == 3)) {
- DECLARE_ROW_POINTERS(GLhalfARB, 4);
+ DECLARE_ROW_POINTERS(GLhalfARB, 3);
for (i = j = 0, k = k0; i (GLuint) dstWidth;
i++, j += colStride, k += colStride) {
@@ -1001,7 +1001,7 @@ do_row_3D(GLenum datatype, GLuint comps, GLint srcWidth,
}
}
else if ((datatype == GL_HALF_FLOAT_ARB) (comps == 2)) {
- DECLARE_ROW_POINTERS(GLhalfARB, 4);
+ DECLARE_ROW_POINTERS(GLhalfARB, 2);
for (i = j = 0, k = k0; i (GLuint) dstWidth;
i++, j += colStride, k += colStride) {
@@ -1010,7 +1010,7 @@ do_row_3D(GLenum datatype, GLuint comps, GLint srcWidth,
}
}
else if ((datatype == GL_HALF_FLOAT_ARB) (comps == 1)) {
- DECLARE_ROW_POINTERS(GLhalfARB, 4);
+ DECLARE_ROW_POINTERS(GLhalfARB, 1);
for (i = j = 0, k = k0; i (GLuint) dstWidth;
i++, j += colStride, k += colStride) {
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix copy-and-paste bug in do_row_3D
On 02/01/2012 02:21 PM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
Several of the half-float cases used 4 as the texel size when it
should have been some smaller value.
Signed-off-by: Ian Romanickian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43324
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43325
---
src/mesa/main/mipmap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
index 03ce536..756316a 100644
--- a/src/mesa/main/mipmap.c
+++ b/src/mesa/main/mipmap.c
@@ -991,7 +991,7 @@ do_row_3D(GLenum datatype, GLuint comps, GLint srcWidth,
}
}
else if ((datatype == GL_HALF_FLOAT_ARB) (comps == 3)) {
- DECLARE_ROW_POINTERS(GLhalfARB, 4);
+ DECLARE_ROW_POINTERS(GLhalfARB, 3);
for (i = j = 0, k = k0; i (GLuint) dstWidth;
i++, j += colStride, k += colStride) {
@@ -1001,7 +1001,7 @@ do_row_3D(GLenum datatype, GLuint comps, GLint srcWidth,
}
}
else if ((datatype == GL_HALF_FLOAT_ARB) (comps == 2)) {
- DECLARE_ROW_POINTERS(GLhalfARB, 4);
+ DECLARE_ROW_POINTERS(GLhalfARB, 2);
for (i = j = 0, k = k0; i (GLuint) dstWidth;
i++, j += colStride, k += colStride) {
@@ -1010,7 +1010,7 @@ do_row_3D(GLenum datatype, GLuint comps, GLint srcWidth,
}
}
else if ((datatype == GL_HALF_FLOAT_ARB) (comps == 1)) {
- DECLARE_ROW_POINTERS(GLhalfARB, 4);
+ DECLARE_ROW_POINTERS(GLhalfARB, 1);
for (i = j = 0, k = k0; i (GLuint) dstWidth;
i++, j += colStride, k += colStride) {
Looks good. Reviewed-by: Brian Paul bri...@vmware.com
Do we actually have any piglit tests that exercise 3D mipmap
generation? I'm not sure I've ever seen an app use it, but anyway.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix copy-and-paste bug in do_row_3D
On 02/01/2012 02:28 PM, Brian Paul wrote:
On 02/01/2012 02:21 PM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
Several of the half-float cases used 4 as the texel size when it
should have been some smaller value.
Signed-off-by: Ian Romanickian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43324
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43325
---
src/mesa/main/mipmap.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
index 03ce536..756316a 100644
--- a/src/mesa/main/mipmap.c
+++ b/src/mesa/main/mipmap.c
@@ -991,7 +991,7 @@ do_row_3D(GLenum datatype, GLuint comps, GLint
srcWidth,
}
}
else if ((datatype == GL_HALF_FLOAT_ARB) (comps == 3)) {
- DECLARE_ROW_POINTERS(GLhalfARB, 4);
+ DECLARE_ROW_POINTERS(GLhalfARB, 3);
for (i = j = 0, k = k0; i (GLuint) dstWidth;
i++, j += colStride, k += colStride) {
@@ -1001,7 +1001,7 @@ do_row_3D(GLenum datatype, GLuint comps, GLint
srcWidth,
}
}
else if ((datatype == GL_HALF_FLOAT_ARB) (comps == 2)) {
- DECLARE_ROW_POINTERS(GLhalfARB, 4);
+ DECLARE_ROW_POINTERS(GLhalfARB, 2);
for (i = j = 0, k = k0; i (GLuint) dstWidth;
i++, j += colStride, k += colStride) {
@@ -1010,7 +1010,7 @@ do_row_3D(GLenum datatype, GLuint comps, GLint
srcWidth,
}
}
else if ((datatype == GL_HALF_FLOAT_ARB) (comps == 1)) {
- DECLARE_ROW_POINTERS(GLhalfARB, 4);
+ DECLARE_ROW_POINTERS(GLhalfARB, 1);
for (i = j = 0, k = k0; i (GLuint) dstWidth;
i++, j += colStride, k += colStride) {
Looks good. Reviewed-by: Brian Paul bri...@vmware.com
Do we actually have any piglit tests that exercise 3D mipmap generation?
I'm not sure I've ever seen an app use it, but anyway.
I'm sure it's roughly proportional to the number of apps using 3D
textures in general... and that number is small.
We don't have any piglit tests yet. We hit this in Intel's internal,
closed-source test suite. It's on our (very, very long) list of new
tests and test infrastructure that need to be written over the next
couple months.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate
https://bugs.freedesktop.org/show_bug.cgi?id=45466 --- Comment #1 from Kevin DeKorte kdeko...@yahoo.com 2012-02-01 13:38:57 PST --- Created attachment 56473 -- https://bugs.freedesktop.org/attachment.cgi?id=56473 Improved version of the patch that touches mklib as well I found that mesa would not compile after doing a make distclean, due to my previous patch. I determined that it was due to mklib erroring on the -m32 I was adding when compiling xorg-r600. So I modified mklib to output a warning and skip the the next argument in this case rather than exiting. By applying this patch to git head (f09910f399d747e524731953bb11b64c1f4821d0). I can use the following command to build mesa in 32bit on a 64bit (Fedora) system. Which covers a large portion of mesa CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/usr --libdir=/usr/lib --with-dri-drivers= --with-gallium-drivers=r600,swrast --enable-gallium-egl --enable-openvg --enable-gles1 --enable-gles2 --enable-texture-float --enable-vdpau --enable-xvmc --enable-osmesa --enable-xorg --enable-texture-float --enable-32-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] [PATCH] mesa: Add unpack_uint_z_row support for floating-point depth buffers
From: Ian Romanick ian.d.roman...@intel.com
This is a hack, and it will result in incorrect rendering. However,
it does eliminate spurious warnings in several piglit CopyPixels tests
that involve floating-point depth buffers.
The real solution is to add a zf field to SWspan to store float Z
values. When a float depth buffer is involved, swrast should also
populate the zf field. I'll consider this post-8.0 work.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/main/format_unpack.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index cd16a9e..b45dde2 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -2916,6 +2916,32 @@ unpack_uint_z_Z32(const void *src, GLuint *dst, GLuint n)
memcpy(dst, src, n * sizeof(GLuint));
}
+static void
+unpack_uint_z_Z32_FLOAT(const void *src, GLuint *dst, GLuint n)
+{
+ const float *s = ((const float *)src);
+ GLuint i;
+ for (i = 0; i n; i++) {
+ dst[i] = FLOAT_TO_UINT(IROUND(CLAMP((s[i]), 0.0F, 1.0F)));
+ }
+}
+
+static void
+unpack_uint_z_Z32_FLOAT_X24S8(const void *src, GLuint *dst, GLuint n)
+{
+ struct z32f_x24s8 {
+ float z;
+ uint32_t x24s8;
+ };
+
+ const struct z32f_x24s8 *s = (const struct z32f_x24s8 *) src;
+ GLuint i;
+
+ for (i = 0; i n; i++) {
+ dst[i] = FLOAT_TO_UINT(IROUND(CLAMP((s[i].z), 0.0F, 1.0F)));
+ }
+}
+
/**
* Unpack Z values.
@@ -2943,6 +2969,12 @@ _mesa_unpack_uint_z_row(gl_format format, GLuint n,
case MESA_FORMAT_Z32:
unpack = unpack_uint_z_Z32;
break;
+ case MESA_FORMAT_Z32_FLOAT:
+ unpack = unpack_uint_z_Z32_FLOAT;
+ break;
+ case MESA_FORMAT_Z32_FLOAT_X24S8:
+ unpack = unpack_uint_z_Z32_FLOAT_X24S8;
+ break;
default:
_mesa_problem(NULL, bad format %s in _mesa_unpack_uint_z_row,
_mesa_get_format_name(format));
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate
https://bugs.freedesktop.org/show_bug.cgi?id=45466 Kevin DeKorte kdeko...@yahoo.com changed: What|Removed |Added CC||i...@freedesktop.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 41700] Gallium won't build with --enable-32-bit on a 64-bit system
https://bugs.freedesktop.org/show_bug.cgi?id=41700 --- Comment #1 from Kevin DeKorte kdeko...@yahoo.com 2012-02-01 13:41:13 PST --- Patch in Bug #45466 fixes this on Fedora 16 x86_64 -- 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] mesa: Add unpack_uint_z_row support for floating-point depth buffers
On 02/01/2012 02:38 PM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
This is a hack, and it will result in incorrect rendering. However,
it does eliminate spurious warnings in several piglit CopyPixels tests
that involve floating-point depth buffers.
The real solution is to add a zf field to SWspan to store float Z
values. When a float depth buffer is involved, swrast should also
populate the zf field. I'll consider this post-8.0 work.
Signed-off-by: Ian Romanickian.d.roman...@intel.com
---
src/mesa/main/format_unpack.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index cd16a9e..b45dde2 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -2916,6 +2916,32 @@ unpack_uint_z_Z32(const void *src, GLuint *dst, GLuint n)
memcpy(dst, src, n * sizeof(GLuint));
}
+static void
+unpack_uint_z_Z32_FLOAT(const void *src, GLuint *dst, GLuint n)
+{
+ const float *s = ((const float *)src);
More parens than necessary there.
+ GLuint i;
+ for (i = 0; i n; i++) {
+ dst[i] = FLOAT_TO_UINT(IROUND(CLAMP((s[i]), 0.0F, 1.0F)));
+ }
+}
+
+static void
+unpack_uint_z_Z32_FLOAT_X24S8(const void *src, GLuint *dst, GLuint n)
+{
+ struct z32f_x24s8 {
+ float z;
+ uint32_t x24s8;
+ };
+
+ const struct z32f_x24s8 *s = (const struct z32f_x24s8 *) src;
+ GLuint i;
+
+ for (i = 0; i n; i++) {
+ dst[i] = FLOAT_TO_UINT(IROUND(CLAMP((s[i].z), 0.0F, 1.0F)));
+ }
+}
+
/**
* Unpack Z values.
@@ -2943,6 +2969,12 @@ _mesa_unpack_uint_z_row(gl_format format, GLuint n,
case MESA_FORMAT_Z32:
unpack = unpack_uint_z_Z32;
break;
+ case MESA_FORMAT_Z32_FLOAT:
+ unpack = unpack_uint_z_Z32_FLOAT;
+ break;
+ case MESA_FORMAT_Z32_FLOAT_X24S8:
+ unpack = unpack_uint_z_Z32_FLOAT_X24S8;
+ break;
default:
_mesa_problem(NULL, bad format %s in _mesa_unpack_uint_z_row,
_mesa_get_format_name(format));
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/11] Interlaced video library support and some cleanup
The following series of patches completes the my general work on interlaced video playback. It implements everything necessary for video playback using interlaced buffers, including a simple weave deinterlacer. Still missing are the changes necessary for interlaced mpeg2 decoding, this will have to wait until I'm back from FOSDEM. Cheers, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/11] vl/video_buffer: fix height of interlaced video buffers
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 021e81e..249124f 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -321,7 +321,7 @@ vl_video_buffer_create(struct pipe_context *pipe,
const struct pipe_video_buffer *tmpl)
{
const enum pipe_format *resource_formats;
- struct pipe_video_buffer templat;
+ struct pipe_video_buffer templat, *result;
bool pot_buffers;
assert(pipe);
@@ -347,11 +347,17 @@ vl_video_buffer_create(struct pipe_context *pipe,
if (tmpl-interlaced)
templat.height /= 2;
- return vl_video_buffer_create_ex
+ result = vl_video_buffer_create_ex
(
pipe, templat, resource_formats,
tmpl-interlaced ? 2 : 1, PIPE_USAGE_STATIC
);
+
+
+ if (result tmpl-interlaced)
+ result-height *= 2;
+
+ return result;
}
struct pipe_video_buffer *
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/11] vl/video_buffer: fix interlaced surface ordering
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 249124f..f7134a5 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -285,23 +285,29 @@ vl_video_buffer_surfaces(struct pipe_video_buffer *buffer)
struct vl_video_buffer *buf = (struct vl_video_buffer *)buffer;
struct pipe_surface surf_templ;
struct pipe_context *pipe;
- unsigned i, j, surf;
+ unsigned i, j, depth, surf;
assert(buf);
pipe = buf-base.context;
- for (i = 0, surf = 0; i buf-num_planes; ++i ) {
- for (j = 0; j buf-resources[i]-depth0; ++j, ++surf) {
+ depth = buffer-interlaced ? 2 : 1;
+ for (i = 0, surf = 0; i depth; ++i ) {
+ for (j = 0; j VL_MAX_PLANES; ++j, ++surf) {
assert(surf (VL_MAX_PLANES * 2));
+ if (!buf-resources[j]) {
+pipe_surface_reference(buf-surfaces[surf], NULL);
+continue;
+ }
+
if (!buf-surfaces[surf]) {
memset(surf_templ, 0, sizeof(surf_templ));
-surf_templ.format = buf-resources[i]-format;
+surf_templ.format = buf-resources[j]-format;
surf_templ.usage = PIPE_BIND_SAMPLER_VIEW |
PIPE_BIND_RENDER_TARGET;
-surf_templ.u.tex.first_layer = surf_templ.u.tex.last_layer = j;
-buf-surfaces[i] = pipe-create_surface(pipe, buf-resources[i],
surf_templ);
-if (!buf-surfaces[i])
+surf_templ.u.tex.first_layer = surf_templ.u.tex.last_layer = i;
+buf-surfaces[surf] = pipe-create_surface(pipe,
buf-resources[j], surf_templ);
+if (!buf-surfaces[surf])
goto error;
}
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/11] vl: add interlacing capabilities
Let the driver control interlaced or progressive format of video buffers. Signed-off-by: Christian König deathsim...@vodafone.de --- src/gallium/drivers/nouveau/nouveau_video.c |6 ++ src/gallium/drivers/nvfx/nvfx_screen.c |6 ++ src/gallium/drivers/r300/r300_screen.c |6 ++ src/gallium/drivers/r600/r600_pipe.c|6 ++ src/gallium/drivers/softpipe/sp_screen.c|6 ++ src/gallium/include/pipe/p_video_enums.h|5 - 6 files changed, 34 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_video.c b/src/gallium/drivers/nouveau/nouveau_video.c index 47d332a..cfbf857 100644 --- a/src/gallium/drivers/nouveau/nouveau_video.c +++ b/src/gallium/drivers/nouveau/nouveau_video.c @@ -837,6 +837,12 @@ nouveau_screen_get_video_param(struct pipe_screen *pscreen, return vl_video_buffer_max_size(pscreen); case PIPE_VIDEO_CAP_PREFERED_FORMAT: return PIPE_FORMAT_NV12; + case PIPE_VIDEO_CAP_PREFERS_INTERLACED: + return false; + case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED: + return false; + case PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE: + return true; default: debug_printf(unknown video param: %d\n, param); return 0; diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c b/src/gallium/drivers/nvfx/nvfx_screen.c index 623903a..ba1a242 100644 --- a/src/gallium/drivers/nvfx/nvfx_screen.c +++ b/src/gallium/drivers/nvfx/nvfx_screen.c @@ -236,6 +236,12 @@ nvfx_screen_get_video_param(struct pipe_screen *screen, return vl_video_buffer_max_size(screen); case PIPE_VIDEO_CAP_PREFERED_FORMAT: return PIPE_FORMAT_NV12; + case PIPE_VIDEO_CAP_PREFERS_INTERLACED: + return false; + case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED: + return false; + case PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE: + return true; default: return 0; } diff --git a/src/gallium/drivers/r300/r300_screen.c b/src/gallium/drivers/r300/r300_screen.c index 9a9418b..eb233a0 100644 --- a/src/gallium/drivers/r300/r300_screen.c +++ b/src/gallium/drivers/r300/r300_screen.c @@ -314,6 +314,12 @@ static int r300_get_video_param(struct pipe_screen *screen, return vl_video_buffer_max_size(screen); case PIPE_VIDEO_CAP_PREFERED_FORMAT: return PIPE_FORMAT_NV12; + case PIPE_VIDEO_CAP_PREFERS_INTERLACED: + return false; + case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED: + return false; + case PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE: + return true; default: return 0; } diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index 351ecfe..140ae11 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -535,6 +535,12 @@ static int r600_get_video_param(struct pipe_screen *screen, return vl_video_buffer_max_size(screen); case PIPE_VIDEO_CAP_PREFERED_FORMAT: return PIPE_FORMAT_NV12; + case PIPE_VIDEO_CAP_PREFERS_INTERLACED: + return false; + case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED: + return false; + case PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE: + return true; default: return 0; } diff --git a/src/gallium/drivers/softpipe/sp_screen.c b/src/gallium/drivers/softpipe/sp_screen.c index 6cafeaf..6d61d00 100644 --- a/src/gallium/drivers/softpipe/sp_screen.c +++ b/src/gallium/drivers/softpipe/sp_screen.c @@ -209,6 +209,12 @@ softpipe_get_video_param(struct pipe_screen *screen, return vl_video_buffer_max_size(screen); case PIPE_VIDEO_CAP_PREFERED_FORMAT: return PIPE_FORMAT_NV12; + case PIPE_VIDEO_CAP_PREFERS_INTERLACED: + return false; + case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED: + return false; + case PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE: + return true; default: return 0; } diff --git a/src/gallium/include/pipe/p_video_enums.h b/src/gallium/include/pipe/p_video_enums.h index 3b61601..deacf8d 100644 --- a/src/gallium/include/pipe/p_video_enums.h +++ b/src/gallium/include/pipe/p_video_enums.h @@ -51,7 +51,10 @@ enum pipe_video_cap PIPE_VIDEO_CAP_NPOT_TEXTURES = 1, PIPE_VIDEO_CAP_MAX_WIDTH = 2, PIPE_VIDEO_CAP_MAX_HEIGHT = 3, - PIPE_VIDEO_CAP_PREFERED_FORMAT = 4 + PIPE_VIDEO_CAP_PREFERED_FORMAT = 4, + PIPE_VIDEO_CAP_PREFERS_INTERLACED = 5, + PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE = 6, + PIPE_VIDEO_CAP_SUPPORTS_INTERLACED = 7 }; enum pipe_video_codec -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/11] st/vdpau: implement uploads to interlaced video buffers
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/state_trackers/vdpau/surface.c | 48 +++
1 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/surface.c
b/src/gallium/state_trackers/vdpau/surface.c
index 85ce4c3..00c64ee 100644
--- a/src/gallium/state_trackers/vdpau/surface.c
+++ b/src/gallium/state_trackers/vdpau/surface.c
@@ -191,7 +191,7 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
enum pipe_format pformat = FormatYCBCRToPipe(source_ycbcr_format);
struct pipe_context *pipe;
struct pipe_sampler_view **sampler_views;
- unsigned i;
+ unsigned i, j;
if (!vlCreateHTAB())
return VDP_STATUS_RESOURCES;
@@ -204,8 +204,7 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
if (!pipe)
return VDP_STATUS_INVALID_HANDLE;
- if (p_surf-video_buffer == NULL || p_surf-video_buffer-interlaced ||
- pformat != p_surf-video_buffer-buffer_format) {
+ if (p_surf-video_buffer == NULL || pformat !=
p_surf-video_buffer-buffer_format) {
/* destroy the old one */
if (p_surf-video_buffer)
@@ -213,7 +212,6 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
/* adjust the template parameters */
p_surf-templat.buffer_format = pformat;
- p_surf-templat.interlaced = false;
/* and try to create the video buffer with the new format */
p_surf-video_buffer = pipe-create_video_buffer(pipe, p_surf-templat);
@@ -227,27 +225,35 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
if (!sampler_views)
return VDP_STATUS_RESOURCES;
- for (i = 0; i 3; ++i) { //TODO put nr of planes into util format
+ for (i = 0; i 3; ++i) {
struct pipe_sampler_view *sv = sampler_views[i];
- struct pipe_box dst_box = { 0, 0, 0, sv-texture-width0,
sv-texture-height0, 1 };
-
- struct pipe_transfer *transfer;
- void *map;
-
- transfer = pipe-get_transfer(pipe, sv-texture, 0, PIPE_TRANSFER_WRITE,
dst_box);
- if (!transfer)
- return VDP_STATUS_RESOURCES;
-
- map = pipe-transfer_map(pipe, transfer);
- if (map) {
- util_copy_rect(map, sv-texture-format, transfer-stride, 0, 0,
-dst_box.width, dst_box.height,
-source_data[i], source_pitches[i], 0, 0);
+ if (!sv) continue;
+
+ for (j = 0; j sv-texture-depth0; ++j) {
+ struct pipe_box dst_box = {
+0, 0, j,
+sv-texture-width0, sv-texture-height0, 1
+ };
+
+ struct pipe_transfer *transfer;
+ void *map;
+
+ transfer = pipe-get_transfer(pipe, sv-texture, 0,
PIPE_TRANSFER_WRITE, dst_box);
+ if (!transfer)
+return VDP_STATUS_RESOURCES;
+
+ map = pipe-transfer_map(pipe, transfer);
+ if (map) {
+util_copy_rect(map, sv-texture-format, transfer-stride, 0, 0,
+ dst_box.width, dst_box.height,
+ source_data[i] + source_pitches[i] * j,
+ source_pitches[i] * sv-texture-depth0,
+ 0, 0);
+ }
pipe-transfer_unmap(pipe, transfer);
+ pipe-transfer_destroy(pipe, transfer);
}
-
- pipe-transfer_destroy(pipe, transfer);
}
return VDP_STATUS_OK;
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/11] vl: add a simple weave deinterlacer
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/auxiliary/vl/vl_compositor.c | 204 +-
src/gallium/auxiliary/vl/vl_compositor.h |2 +
2 files changed, 173 insertions(+), 33 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c
b/src/gallium/auxiliary/vl/vl_compositor.c
index 0f2210c..d41a7b4 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -43,6 +43,14 @@
#define MIN_DIRTY (0)
#define MAX_DIRTY (1 15)
+enum VS_OUTPUT
+{
+ VS_O_VPOS,
+ VS_O_VTEX,
+ VS_O_VTOP,
+ VS_O_VBOTTOM,
+};
+
typedef float csc_matrix[16];
static void *
@@ -50,7 +58,9 @@ create_vert_shader(struct vl_compositor *c)
{
struct ureg_program *shader;
struct ureg_src vpos, vtex;
+ struct ureg_dst tmp;
struct ureg_dst o_vpos, o_vtex;
+ struct ureg_dst o_vtop, o_vbottom;
shader = ureg_create(TGSI_PROCESSOR_VERTEX);
if (!shader)
@@ -58,8 +68,11 @@ create_vert_shader(struct vl_compositor *c)
vpos = ureg_DECL_vs_input(shader, 0);
vtex = ureg_DECL_vs_input(shader, 1);
- o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, 0);
- o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, 1);
+ tmp = ureg_DECL_temporary(shader);
+ o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
+ o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
+ o_vtop = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTOP);
+ o_vbottom = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VBOTTOM);
/*
* o_vpos = vpos
@@ -68,6 +81,27 @@ create_vert_shader(struct vl_compositor *c)
ureg_MOV(shader, o_vpos, vpos);
ureg_MOV(shader, o_vtex, vtex);
+ ureg_MUL(shader, ureg_writemask(tmp, TGSI_WRITEMASK_X),
+ureg_scalar(vtex, TGSI_SWIZZLE_W), ureg_imm1f(shader, 0.5f));
+ ureg_MUL(shader, ureg_writemask(tmp, TGSI_WRITEMASK_Y),
+ureg_scalar(vtex, TGSI_SWIZZLE_W), ureg_imm1f(shader, 0.25f));
+
+ ureg_MOV(shader, ureg_writemask(o_vtop, TGSI_WRITEMASK_X), vtex);
+ ureg_MAD(shader, ureg_writemask(o_vtop, TGSI_WRITEMASK_Y),
ureg_scalar(vtex, TGSI_SWIZZLE_Y),
+ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_X), ureg_imm1f(shader,
0.25f));
+ ureg_MAD(shader, ureg_writemask(o_vtop, TGSI_WRITEMASK_Z),
ureg_scalar(vtex, TGSI_SWIZZLE_Y),
+ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_Y), ureg_imm1f(shader,
0.25f));
+ ureg_RCP(shader, ureg_writemask(o_vtop, TGSI_WRITEMASK_W),
+ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_X));
+
+ ureg_MOV(shader, ureg_writemask(o_vbottom, TGSI_WRITEMASK_X), vtex);
+ ureg_MAD(shader, ureg_writemask(o_vbottom, TGSI_WRITEMASK_Y),
ureg_scalar(vtex, TGSI_SWIZZLE_Y),
+ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_X), ureg_imm1f(shader,
-0.25f));
+ ureg_MAD(shader, ureg_writemask(o_vbottom, TGSI_WRITEMASK_Z),
ureg_scalar(vtex, TGSI_SWIZZLE_Y),
+ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_Y), ureg_imm1f(shader,
-0.25f));
+ ureg_RCP(shader, ureg_writemask(o_vbottom, TGSI_WRITEMASK_W),
+ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_Y));
+
ureg_END(shader);
return ureg_create_shader_and_destroy(shader, c-pipe);
@@ -101,7 +135,7 @@ create_frag_shader_video_buffer(struct vl_compositor *c)
* fragment = csc * texel
*/
for (i = 0; i 3; ++i)
- ureg_TEX(shader, ureg_writemask(texel, TGSI_WRITEMASK_X i),
TGSI_TEXTURE_2D, tc, sampler[i]);
+ ureg_TEX(shader, ureg_writemask(texel, TGSI_WRITEMASK_X i),
TGSI_TEXTURE_3D, tc, sampler[i]);
ureg_MOV(shader, ureg_writemask(texel, TGSI_WRITEMASK_W),
ureg_imm1f(shader, 1.0f));
@@ -117,6 +151,98 @@ create_frag_shader_video_buffer(struct vl_compositor *c)
}
static void *
+create_frag_shader_weave(struct vl_compositor *c)
+{
+ struct ureg_program *shader;
+ struct ureg_src i_tc[2];
+ struct ureg_src csc[3];
+ struct ureg_src sampler[3];
+ struct ureg_dst t_tc[2];
+ struct ureg_dst t_texel[2];
+ struct ureg_dst o_fragment;
+ unsigned i, j;
+
+ shader = ureg_create(TGSI_PROCESSOR_FRAGMENT);
+ if (!shader)
+ return false;
+
+ i_tc[0] = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTOP,
TGSI_INTERPOLATE_LINEAR);
+ i_tc[1] = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VBOTTOM,
TGSI_INTERPOLATE_LINEAR);
+
+ for (i = 0; i 3; ++i) {
+ csc[i] = ureg_DECL_constant(shader, i);
+ sampler[i] = ureg_DECL_sampler(shader, i);
+ }
+
+ for (i = 0; i 2; ++i) {
+ t_tc[i] = ureg_DECL_temporary(shader);
+ t_texel[i] = ureg_DECL_temporary(shader);
+ }
+ o_fragment = ureg_DECL_output(shader, TGSI_SEMANTIC_COLOR, 0);
+
+ /* calculate the texture offsets
+* t_tc.x = i_tc.x
+* t_tc.y = (round(i_tc.y) + 0.5) / height * 2
+*/
+ for (i = 0; i 2; ++i) {
+ ureg_MOV(shader, ureg_writemask(t_tc[i], TGSI_WRITEMASK_X), i_tc[i]);
+ ureg_ROUND(shader, ureg_writemask(t_tc[i],
[Mesa-dev] [PATCH 06/11] st/vdpau: use interlacing capabilities
Recreate video buffer if need arises.
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/state_trackers/vdpau/decode.c | 10 +-
src/gallium/state_trackers/vdpau/surface.c |6 ++
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/decode.c
b/src/gallium/state_trackers/vdpau/decode.c
index 00232ad..de9835f 100644
--- a/src/gallium/state_trackers/vdpau/decode.c
+++ b/src/gallium/state_trackers/vdpau/decode.c
@@ -393,6 +393,7 @@ vlVdpDecoderRender(VdpDecoder decoder,
VdpStatus ret;
struct pipe_screen *screen;
struct pipe_video_decoder *dec;
+ bool buffer_support[2];
unsigned i;
union {
struct pipe_picture_desc base;
@@ -424,8 +425,12 @@ vlVdpDecoderRender(VdpDecoder decoder,
// TODO: Recreate decoder with correct chroma
return VDP_STATUS_INVALID_CHROMA_TYPE;
+ buffer_support[0] = screen-get_video_param(screen, dec-profile,
PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE);
+ buffer_support[1] = screen-get_video_param(screen, dec-profile,
PIPE_VIDEO_CAP_SUPPORTS_INTERLACED);
+
if (vlsurf-video_buffer == NULL ||
- !screen-is_video_format_supported(screen,
vlsurf-video_buffer-buffer_format, dec-profile)) {
+ !screen-is_video_format_supported(screen,
vlsurf-video_buffer-buffer_format, dec-profile) ||
+ buffer_support[vlsurf-video_buffer-interlaced]) {
/* destroy the old one */
if (vlsurf-video_buffer)
@@ -434,6 +439,9 @@ vlVdpDecoderRender(VdpDecoder decoder,
/* set the buffer format to the prefered one */
vlsurf-templat.buffer_format = screen-get_video_param(screen,
dec-profile, PIPE_VIDEO_CAP_PREFERED_FORMAT);
+ /* also set interlacing to decoders preferences */
+ vlsurf-templat.interlaced = screen-get_video_param(screen,
dec-profile, PIPE_VIDEO_CAP_PREFERS_INTERLACED);
+
/* and recreate the video buffer */
vlsurf-video_buffer = dec-context-create_video_buffer(dec-context,
vlsurf-templat);
diff --git a/src/gallium/state_trackers/vdpau/surface.c
b/src/gallium/state_trackers/vdpau/surface.c
index 00c64ee..5774a83 100644
--- a/src/gallium/state_trackers/vdpau/surface.c
+++ b/src/gallium/state_trackers/vdpau/surface.c
@@ -85,6 +85,12 @@ vlVdpVideoSurfaceCreate(VdpDevice device, VdpChromaType
chroma_type,
p_surf-templat.chroma_format = ChromaToPipe(chroma_type);
p_surf-templat.width = width;
p_surf-templat.height = height;
+ p_surf-templat.interlaced = pipe-screen-get_video_param
+ (
+ pipe-screen,
+ PIPE_VIDEO_PROFILE_UNKNOWN,
+ PIPE_VIDEO_CAP_PREFERS_INTERLACED
+ );
p_surf-video_buffer = pipe-create_video_buffer(pipe, p_surf-templat);
*surface = vlAddDataHTAB(p_surf);
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/11] st/xvmc: respect caps when creating video buffers
Signed-off-by: Christian König deathsim...@vodafone.de --- src/gallium/state_trackers/xorg/xvmc/surface.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/gallium/state_trackers/xorg/xvmc/surface.c b/src/gallium/state_trackers/xorg/xvmc/surface.c index f1c3271..024612e 100644 --- a/src/gallium/state_trackers/xorg/xvmc/surface.c +++ b/src/gallium/state_trackers/xorg/xvmc/surface.c @@ -184,6 +184,12 @@ Status XvMCCreateSurface(Display *dpy, XvMCContext *context, XvMCSurface *surfac tmpl.chroma_format = context_priv-decoder-chroma_format; tmpl.width = context_priv-decoder-width; tmpl.height = context_priv-decoder-height; + tmpl.interlaced = pipe-screen-get_video_param + ( + pipe-screen, + PIPE_VIDEO_PROFILE_MPEG2_MAIN, + PIPE_VIDEO_CAP_PREFERS_INTERLACED + ); surface_priv-video_buffer = pipe-create_video_buffer(pipe, tmpl); surface_priv-context = context; -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/11] vl: remove assert on unknown video profile
It's perfectly valid to ask for an unknown profile and get unknown code as a result. Signed-off-by: Christian König deathsim...@vodafone.de --- src/gallium/auxiliary/util/u_video.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/gallium/auxiliary/util/u_video.h b/src/gallium/auxiliary/util/u_video.h index be3fac2..e575947 100644 --- a/src/gallium/auxiliary/util/u_video.h +++ b/src/gallium/auxiliary/util/u_video.h @@ -64,7 +64,6 @@ u_reduce_video_profile(enum pipe_video_profile profile) return PIPE_VIDEO_CODEC_MPEG4_AVC; default: - assert(0); return PIPE_VIDEO_CODEC_UNKNOWN; } } -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/11] vl: add VL_MAX_SURFACES define
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/auxiliary/vl/vl_defines.h|1 +
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c |3 ++-
src/gallium/auxiliary/vl/vl_video_buffer.h |2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_defines.h
b/src/gallium/auxiliary/vl/vl_defines.h
index ffbc653..6f20706 100644
--- a/src/gallium/auxiliary/vl/vl_defines.h
+++ b/src/gallium/auxiliary/vl/vl_defines.h
@@ -36,6 +36,7 @@
#define VL_BLOCK_HEIGHT 8
#define VL_NUM_COMPONENTS 3
+#define VL_MAX_SURFACES (VL_NUM_COMPONENTS * 2)
#define VL_MAX_REF_FRAMES 2
#endif
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index 78dfd69..31d96fd 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
@@ -683,6 +683,7 @@ vl_mpeg12_end_frame(struct pipe_video_decoder *decoder,
unsigned nr_components;
assert(dec target picture);
+ assert(!target-interlaced);
buf = vl_mpeg12_get_decode_buffer(dec, target);
@@ -734,7 +735,7 @@ vl_mpeg12_end_frame(struct pipe_video_decoder *decoder,
plane_order = vl_video_buffer_plane_order(target-buffer_format);
mc_source_sv = dec-mc_source-get_sampler_view_planes(dec-mc_source);
- for (i = 0, component = 0; i VL_NUM_COMPONENTS; ++i) {
+ for (i = 0, component = 0; component VL_NUM_COMPONENTS; ++i) {
if (!target_surfaces[i]) continue;
nr_components =
util_format_get_nr_components(target_surfaces[i]-texture-format);
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.h
b/src/gallium/auxiliary/vl/vl_video_buffer.h
index 16c2e31..6e2f8b8 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.h
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.h
@@ -45,7 +45,7 @@ struct vl_video_buffer
struct pipe_resource *resources[VL_NUM_COMPONENTS];
struct pipe_sampler_view *sampler_view_planes[VL_NUM_COMPONENTS];
struct pipe_sampler_view *sampler_view_components[VL_NUM_COMPONENTS];
- struct pipe_surface *surfaces[VL_NUM_COMPONENTS * 2];
+ struct pipe_surface *surfaces[VL_MAX_SURFACES];
};
/**
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/11] vl: prefix size defines with VL_
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/auxiliary/vl/vl_decoder.c|4 +-
src/gallium/auxiliary/vl/vl_defines.h|8 ++--
src/gallium/auxiliary/vl/vl_idct.c | 34 +++---
src/gallium/auxiliary/vl/vl_mc.c | 20 ++--
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 18 ++--
src/gallium/auxiliary/vl/vl_video_buffer.c |4 +-
src/gallium/auxiliary/vl/vl_zscan.c | 41 +
7 files changed, 65 insertions(+), 64 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_decoder.c
b/src/gallium/auxiliary/vl/vl_decoder.c
index a88347f..d6909cb 100644
--- a/src/gallium/auxiliary/vl/vl_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_decoder.c
@@ -65,8 +65,8 @@ vl_create_decoder(struct pipe_context *pipe,
PIPE_VIDEO_CAP_NPOT_TEXTURES
);
- buffer_width = pot_buffers ? util_next_power_of_two(width) : align(width,
MACROBLOCK_WIDTH);
- buffer_height = pot_buffers ? util_next_power_of_two(height) :
align(height, MACROBLOCK_HEIGHT);
+ buffer_width = pot_buffers ? util_next_power_of_two(width) : align(width,
VL_MACROBLOCK_WIDTH);
+ buffer_height = pot_buffers ? util_next_power_of_two(height) :
align(height, VL_MACROBLOCK_HEIGHT);
switch (u_reduce_video_profile(profile)) {
case PIPE_VIDEO_CODEC_MPEG12:
diff --git a/src/gallium/auxiliary/vl/vl_defines.h
b/src/gallium/auxiliary/vl/vl_defines.h
index 7568db0..c53d15c 100644
--- a/src/gallium/auxiliary/vl/vl_defines.h
+++ b/src/gallium/auxiliary/vl/vl_defines.h
@@ -29,11 +29,11 @@
#define vl_defines_h
/* constants usually used with all known codecs */
-#define MACROBLOCK_WIDTH 16
-#define MACROBLOCK_HEIGHT 16
+#define VL_MACROBLOCK_WIDTH 16
+#define VL_MACROBLOCK_HEIGHT 16
-#define BLOCK_WIDTH 8
-#define BLOCK_HEIGHT 8
+#define VL_BLOCK_WIDTH 8
+#define VL_BLOCK_HEIGHT 8
#define VL_MAX_PLANES 3
#define VL_MAX_REF_FRAMES 2
diff --git a/src/gallium/auxiliary/vl/vl_idct.c
b/src/gallium/auxiliary/vl/vl_idct.c
index 1166de0..18697d3 100644
--- a/src/gallium/auxiliary/vl/vl_idct.c
+++ b/src/gallium/auxiliary/vl/vl_idct.c
@@ -162,9 +162,9 @@ create_mismatch_vert_shader(struct vl_idct *idct)
o_addr[1] = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_L_ADDR1);
/*
-* scale = (BLOCK_WIDTH, BLOCK_HEIGHT) / (dst.width, dst.height)
+* scale = (VL_BLOCK_WIDTH, VL_BLOCK_HEIGHT) / (dst.width, dst.height)
*
-* t_vpos = vpos + 7 / BLOCK_WIDTH
+* t_vpos = vpos + 7 / VL_BLOCK_WIDTH
* o_vpos.xy = t_vpos * scale
*
* o_addr = calc_addr(...)
@@ -172,8 +172,8 @@ create_mismatch_vert_shader(struct vl_idct *idct)
*/
scale = ureg_imm2f(shader,
- (float)BLOCK_WIDTH / idct-buffer_width,
- (float)BLOCK_HEIGHT / idct-buffer_height);
+ (float)VL_BLOCK_WIDTH / idct-buffer_width,
+ (float)VL_BLOCK_HEIGHT / idct-buffer_height);
ureg_MAD(shader, ureg_writemask(o_vpos, TGSI_WRITEMASK_XY), vpos, scale,
scale);
ureg_MOV(shader, ureg_writemask(o_vpos, TGSI_WRITEMASK_ZW),
ureg_imm1f(shader, 1.0f));
@@ -283,7 +283,7 @@ create_stage1_vert_shader(struct vl_idct *idct)
o_r_addr[1] = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_R_ADDR1);
/*
-* scale = (BLOCK_WIDTH, BLOCK_HEIGHT) / (dst.width, dst.height)
+* scale = (VL_BLOCK_WIDTH, VL_BLOCK_HEIGHT) / (dst.width, dst.height)
*
* t_vpos = vpos + vrect
* o_vpos.xy = t_vpos * scale
@@ -295,8 +295,8 @@ create_stage1_vert_shader(struct vl_idct *idct)
*/
scale = ureg_imm2f(shader,
- (float)BLOCK_WIDTH / idct-buffer_width,
- (float)BLOCK_HEIGHT / idct-buffer_height);
+ (float)VL_BLOCK_WIDTH / idct-buffer_width,
+ (float)VL_BLOCK_HEIGHT / idct-buffer_height);
ureg_ADD(shader, ureg_writemask(t_tex, TGSI_WRITEMASK_XY), vpos, vrect);
ureg_MUL(shader, ureg_writemask(t_tex, TGSI_WRITEMASK_XY), ureg_src(t_tex),
scale);
@@ -307,7 +307,7 @@ create_stage1_vert_shader(struct vl_idct *idct)
ureg_MUL(shader, ureg_writemask(t_start, TGSI_WRITEMASK_XY), vpos, scale);
calc_addr(shader, o_l_addr, ureg_src(t_tex), ureg_src(t_start), false,
false, idct-buffer_width / 4);
- calc_addr(shader, o_r_addr, vrect, ureg_imm1f(shader, 0.0f), true, true,
BLOCK_WIDTH / 4);
+ calc_addr(shader, o_r_addr, vrect, ureg_imm1f(shader, 0.0f), true, true,
VL_BLOCK_WIDTH / 4);
ureg_release_temporary(shader, t_tex);
ureg_release_temporary(shader, t_start);
@@ -366,7 +366,7 @@ create_stage1_frag_shader(struct vl_idct *idct)
for (i = 0; i idct-nr_of_render_targets; ++i) {
struct ureg_src s_addr[2];
- increment_addr(shader, r, r_addr, true, true, i -
(signed)idct-nr_of_render_targets / 2, BLOCK_HEIGHT);
+ increment_addr(shader, r, r_addr, true, true, i -
(signed)idct-nr_of_render_targets / 2, VL_BLOCK_HEIGHT);
s_addr[0] = ureg_src(r[0]);
s_addr[1] = ureg_src(r[1]);
@@ -414,15 +414,15 @@
[Mesa-dev] [PATCH 10/11] vl: rename VL_MAX_PLANES to VL_NUM_COMPONENTS
Signed-off-by: Christian König deathsim...@vodafone.de
---
src/gallium/auxiliary/vl/vl_defines.h|2 +-
src/gallium/auxiliary/vl/vl_mc.h |2 +-
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 20 ++--
src/gallium/auxiliary/vl/vl_mpeg12_decoder.h |8
src/gallium/auxiliary/vl/vl_vertex_buffers.c | 14 +++---
src/gallium/auxiliary/vl/vl_vertex_buffers.h |2 +-
src/gallium/auxiliary/vl/vl_video_buffer.c | 26 +-
src/gallium/auxiliary/vl/vl_video_buffer.h | 12 ++--
src/gallium/drivers/nouveau/nouveau_video.c |2 +-
9 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_defines.h
b/src/gallium/auxiliary/vl/vl_defines.h
index c53d15c..ffbc653 100644
--- a/src/gallium/auxiliary/vl/vl_defines.h
+++ b/src/gallium/auxiliary/vl/vl_defines.h
@@ -35,7 +35,7 @@
#define VL_BLOCK_WIDTH 8
#define VL_BLOCK_HEIGHT 8
-#define VL_MAX_PLANES 3
+#define VL_NUM_COMPONENTS 3
#define VL_MAX_REF_FRAMES 2
#endif
diff --git a/src/gallium/auxiliary/vl/vl_mc.h b/src/gallium/auxiliary/vl/vl_mc.h
index 2c3b237..b506659 100644
--- a/src/gallium/auxiliary/vl/vl_mc.h
+++ b/src/gallium/auxiliary/vl/vl_mc.h
@@ -36,7 +36,7 @@
#include vl_defines.h
#include vl_types.h
-#define VL_MC_NUM_BLENDERS (1 VL_MAX_PLANES)
+#define VL_MC_NUM_BLENDERS (1 VL_NUM_COMPONENTS)
struct pipe_context;
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index 96e1c84..78dfd69 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
@@ -124,7 +124,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct
vl_mpeg12_buffer *buffer
if (!destination)
goto error_surface;
- for (i = 0; i VL_MAX_PLANES; ++i)
+ for (i = 0; i VL_NUM_COMPONENTS; ++i)
if (!vl_zscan_init_buffer(i == 0 ? dec-zscan_y : dec-zscan_c,
buffer-zscan[i], buffer-zscan_source,
destination[i]))
goto error_plane;
@@ -150,7 +150,7 @@ cleanup_zscan_buffer(struct vl_mpeg12_buffer *buffer)
assert(buffer);
- for (i = 0; i VL_MAX_PLANES; ++i)
+ for (i = 0; i VL_NUM_COMPONENTS; ++i)
vl_zscan_cleanup_buffer(buffer-zscan[i]);
pipe_sampler_view_reference(buffer-zscan_source, NULL);
@@ -234,7 +234,7 @@ cleanup_mc_buffer(struct vl_mpeg12_buffer *buf)
assert(buf);
- for (i = 0; i VL_MAX_PLANES; ++i)
+ for (i = 0; i VL_NUM_COMPONENTS; ++i)
vl_mc_cleanup_buffer(buf-mc[i]);
}
@@ -533,7 +533,7 @@ vl_mpeg12_begin_frame(struct pipe_video_decoder *decoder,
memset(non_intra_matrix, 0x10, sizeof(non_intra_matrix));
}
- for (i = 0; i VL_MAX_PLANES; ++i) {
+ for (i = 0; i VL_NUM_COMPONENTS; ++i) {
struct vl_zscan *zscan = i == 0 ? dec-zscan_y : dec-zscan_c;
vl_zscan_upload_quant(zscan, buf-zscan[i], intra_matrix, true);
vl_zscan_upload_quant(zscan, buf-zscan[i], non_intra_matrix, false);
@@ -555,7 +555,7 @@ vl_mpeg12_begin_frame(struct pipe_video_decoder *decoder,
buf-block_num = 0;
buf-texels = dec-base.context-transfer_map(dec-base.context,
buf-tex_transfer);
- for (i = 0; i VL_MAX_PLANES; ++i) {
+ for (i = 0; i VL_NUM_COMPONENTS; ++i) {
buf-ycbcr_stream[i] = vl_vb_get_ycbcr_stream(buf-vertex_stream, i);
buf-num_ycbcr_blocks[i] = 0;
}
@@ -564,7 +564,7 @@ vl_mpeg12_begin_frame(struct pipe_video_decoder *decoder,
buf-mv_stream[i] = vl_vb_get_mv_stream(buf-vertex_stream, i);
if (dec-base.entrypoint = PIPE_VIDEO_ENTRYPOINT_IDCT) {
- for (i = 0; i VL_MAX_PLANES; ++i)
+ for (i = 0; i VL_NUM_COMPONENTS; ++i)
vl_zscan_set_layout(buf-zscan[i], dec-zscan_linear);
}
}
@@ -658,7 +658,7 @@ vl_mpeg12_decode_bitstream(struct pipe_video_decoder
*decoder,
buf = vl_mpeg12_get_decode_buffer(dec, target);
assert(buf);
- for (i = 0; i VL_MAX_PLANES; ++i)
+ for (i = 0; i VL_NUM_COMPONENTS; ++i)
vl_zscan_set_layout(buf-zscan[i], desc-alternate_scan ?
dec-zscan_alternate : dec-zscan_normal);
@@ -704,7 +704,7 @@ vl_mpeg12_end_frame(struct pipe_video_decoder *decoder,
}
dec-base.context-bind_vertex_elements_state(dec-base.context,
dec-ves_mv);
- for (i = 0; i VL_MAX_PLANES; ++i) {
+ for (i = 0; i VL_NUM_COMPONENTS; ++i) {
if (!target_surfaces[i]) continue;
vl_mc_set_surface(buf-mc[i], target_surfaces[i]);
@@ -720,7 +720,7 @@ vl_mpeg12_end_frame(struct pipe_video_decoder *decoder,
}
dec-base.context-bind_vertex_elements_state(dec-base.context,
dec-ves_ycbcr);
- for (i = 0; i VL_MAX_PLANES; ++i) {
+ for (i = 0; i VL_NUM_COMPONENTS; ++i) {
if (!buf-num_ycbcr_blocks[i]) continue;
vb[1] = vl_vb_get_ycbcr(buf-vertex_stream, i);
@@ -734,7 +734,7 @@ vl_mpeg12_end_frame(struct pipe_video_decoder *decoder,
plane_order =
Re: [Mesa-dev] [PATCH 1/2] intel: verify if hardware has LLC support
On 02/01/2012 01:07 PM, Eugeni Dodonov wrote: Rely on libdrm HAS_LLC parameter to verify if hardware supports it. In case the libdrm version does not supports this check, fallback to older way of detecting it which assumed that GPUs newer than GEN6 have it. Signed-off-by: Eugeni Dodonoveugeni.dodo...@intel.com Looks good to me. Thanks! For the series: Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix copy-and-paste bug in do_row_3D
On 02/01/2012 01:21 PM, Ian Romanick wrote: From: Ian Romanickian.d.roman...@intel.com Several of the half-float cases used 4 as the texel size when it should have been some smaller value. Signed-off-by: Ian Romanickian.d.roman...@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43324 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43325 --- src/mesa/main/mipmap.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) Hooray for copy and paste! Nice catch. Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Also check renderability in intel_renderbuffer_update_wrapper
On 02/01/2012 11:29 AM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
A similar check was removed in 05ab8fc. The check is not complete
redundand because some paths, such as
_mesa_meta_check_generate_mipmap_fallback, can get to
intel_renderbuffer_update_wrapper but not get to
intel_validate_framebuffer. This occurs when trying to generate
mipmaps for GL_SLUMINANCE8 textures.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanickian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44961
Cc: Eric Anholte...@anholt.net
---
src/mesa/drivers/dri/intel/intel_fbo.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 62ed754..c235fb4 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -482,6 +482,12 @@ intel_renderbuffer_update_wrapper(struct intel_context
*intel,
rb-Delete = intel_delete_renderbuffer;
rb-AllocStorage = intel_nop_alloc_storage;
+ if (!intel-vtbl.render_target_supported(intel, rb)) {
+ DBG(Render to texture BAD FORMAT %s\n,
+ _mesa_get_format_name(rb-Format));
+ return false;
+ }
+
intel_miptree_check_level_layer(mt, level, layer);
irb-mt_level = level;
irb-mt_layer = layer;
Looks reasonable to me, though I obviously defer to Eric's judgement as
I'm not terribly familiar with this code.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: FBOs with texture border are unsupported
On 02/01/2012 09:31 AM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
FBOs differ from textures in a significant way. With textures, we can
strip the border and get correct rendering except when the application
fetches texels outside [0,1].
With an FBO, the pixel at (0,0) is in the border. The
ARB_framebuffer_object spec says:
If the attached image is a texture image, then the window
coordinates (x[w], y[w]) correspond to the texel (i, j, k), from
figure 3.10 as follows:
i = (x[w] - b)
j = (y[w] - b)
k = (layer - b)
whereb is the texture image's border width...
Since the border doesn't exist, we can never render any pixels in the
correct location. Just mark these FBOs FRAMEBUFFER_UNSUPPORTED.
Signed-off-by: Ian Romanickian.d.roman...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42336
---
src/mesa/drivers/dri/intel/intel_fbo.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 2ba43ac..62ed754 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -746,6 +746,7 @@ intel_validate_framebuffer(struct gl_context *ctx, struct
gl_framebuffer *fb)
for (i = 0; i Elements(fb-Attachment); i++) {
struct gl_renderbuffer *rb;
+ struct gl_texture_object *tex;
struct intel_renderbuffer *irb;
if (fb-Attachment[i].Type == GL_NONE)
@@ -762,6 +763,18 @@ intel_validate_framebuffer(struct gl_context *ctx, struct
gl_framebuffer *fb)
continue;
}
+ tex = fb-Attachment[i].Texture;
+ if (tex != NULL) {
+const unsigned face = fb-Attachment[i].CubeMapFace;
+const unsigned level = fb-Attachment[i].TextureLevel;
+
+if (tex-Image[face][level]-Border) {
+ DBG(texture with border\n);
+ fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
+ continue;
+}
+ }
+
irb = intel_renderbuffer(rb);
if (irb == NULL) {
DBG(software rendering renderbuffer\n);
Yeah, I think flagging these as unsupported is best. They aren't, and
the application already has to check for FBO completeness, so they
should be prepared to handle this. Plus, seriously, who uses this crap?
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] anongit.freedesktop.org not available?
Hi, I've been trying all day to sync sources from anongit.freedesktop.org (dri and mesa) and it always ends up by a time out. Is there a problem with the server or the address? Cheers, -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] anongit.freedesktop.org not available?
On 02/ 1/12 08:52 PM, Alexandre Demers wrote: Hi, I've been trying all day to sync sources from anongit.freedesktop.org (dri and mesa) and it always ends up by a time out. Is there a problem with the server or the address? Yes. Others have reported on IRC that it works if you force the hostnames to resolve to 131.252.210.176 instead of the DNS reported 131.252.210.161. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Fix copy-and-paste error in _mesa_pack_rgba_span_float
From: Ian Romanick ian.d.roman...@intel.com
GL_RG_INTEGER only has two components, not three. I'll be surprised
if anyone ever tries to glReadPixels(..., GL_SHORT, GL_RG_INTEGER,
...). This was found by inspection.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/main/pack.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index d07e2aa..41485a1 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
@@ -1175,9 +1175,8 @@ _mesa_pack_rgba_span_float(struct gl_context *ctx, GLuint
n, GLfloat rgba[][4],
break;
case GL_RG_INTEGER:
for (i=0;in;i++) {
- dst[i*3+0] = (GLshort) rgba[i][RCOMP];
- dst[i*3+1] = (GLshort) rgba[i][GCOMP];
- dst[i*3+2] = (GLshort) rgba[i][BCOMP];
+ dst[i*2+0] = (GLshort) rgba[i][RCOMP];
+ dst[i*2+1] = (GLshort) rgba[i][GCOMP];
}
break;
case GL_RGB_INTEGER_EXT:
--
1.7.6.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39017] [bisected] Segfault in Gallium drivers in Mupen64Plus
https://bugs.freedesktop.org/show_bug.cgi?id=39017 --- Comment #7 from Diego Viola diego.vi...@gmail.com 2012-02-01 22:05:57 PST --- I seem to be getting this issue as well, mupen64plus crashes on my machine as soon as I start a game. Mupen64Plus Console User-Interface Version 1.99.4 UI-console: attached to core library 'Mupen64Plus Core' version 1.99.4 I've tried building from source (hg) and it doesn't crash there but it hangs. It used to work fine with previous versions. I'm using nouveau, Linux 3.2.2, Arch Linux x86-64. -- 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 39017] [bisected] Segfault in Gallium drivers in Mupen64Plus
https://bugs.freedesktop.org/show_bug.cgi?id=39017 --- Comment #8 from Diego Viola diego.vi...@gmail.com 2012-02-01 22:07:21 PST --- BTW I use nouveau, and my card is: GeForce 9500 GT -- 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 45420] undefined reference to `LLVMInitializeARMDisassembler'
https://bugs.freedesktop.org/show_bug.cgi?id=45420
--- Comment #6 from Vinson Lee v...@freedesktop.org 2012-02-01 22:12:50 PST
---
(In reply to comment #5)
The ability to build with LLVM-2.6 is still useful for now, as it is one of
the
most stable LLVM releases for us ever.
But the ability to disassemble w/ LLVM 2.7 or eralier is not really important
(as most developers will have recent LLVM anyway), so we could simply cut our
losses and do:
--- a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
+++ b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp
@@ -172,7 +172,7 @@ public:
extern C void
lp_disassemble(const void* func)
{
-#if HAVE_LLVM = 0x0207
+#if HAVE_LLVM = 0x0208
using namespace llvm;
const uint8_t *bytes = (const uint8_t *)func;
Vinson, I don't have LLVM 2.7. Could you verify either ojab's or my change
fixes the build issue?
The build failure in comment #3 doesn't occur with llvm-2.6. Only the build
with llvm-2.7 is failing.
Jose, your patch fixes the build for llvm-2.7. The llvm-2.6 build is unaffected
and still completes.
Tested-by: Vinson Lee v...@freedesktop.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 45420] undefined reference to `LLVMInitializeARMDisassembler'
https://bugs.freedesktop.org/show_bug.cgi?id=45420
--- Comment #7 from Vinson Lee v...@freedesktop.org 2012-02-01 22:20:26 PST
---
(In reply to comment #4)
Created attachment 56422 [details] [review]
Proposed fix for LLVM-2.7
I don't really know how to properly fix this for all targets, because
LLVM_NATIVE_ARCH in LLVM-2.7 is ${LLVM_NATIVE_ARCH}Target (X86Target for X86,
ARMTarget for ARM etc), so it's not possible to write something like
#define LLVM_ASM_PRINTER(TargetName) LLVMInitialize##TargetName##AsmPrinter();
to fix all targets. Attached patch adds defines only for for X86 and ARM, is
it
sufficient, should it be added for other targets or it can be completely
skipped for LLVM 2.8?
Patch also adds needed defines for LLVM Disassembler.
Also llvmpipe docs say that LLVM: version 2.9 recommended; 2.6 or later
required, is it up-to-date and build should also be tested with LLVM-2.6?
ojab, your patch also fixes the build with llvm-2.7. The llvm-2.6 is unaffected
and still completes.
Tested-by: Vinson Lee v...@freedesktop.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 39017] [bisected] Segfault in Gallium drivers in Mupen64Plus
https://bugs.freedesktop.org/show_bug.cgi?id=39017 --- Comment #9 from Diego Viola diego.vi...@gmail.com 2012-02-01 22:36:56 PST --- Created attachment 56498 -- https://bugs.freedesktop.org/attachment.cgi?id=56498 mupen64plus gdb backtrace I've managed to get a backtrace. See the file attached. -- 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
