Re: [Mesa-dev] Current tinderbox regression (mesa, radeon)
Does the attached patch fix the issue? (and is the fix correct?) Marek On Sat, Sep 25, 2010 at 7:30 PM, Chris Ball c...@laptop.org wrote: Hi, On Sat, Sep 25, 2010 at 2:37 PM, Chris Ball c...@laptop.org wrote: http://tinderbox.x.org/builds/2010-09-24-0001/logs/libGL/#build looks like libdrm isn't installed properly, I don't see LIBDRM_RADEON being picked up. though previously we didn't build this code by default, maybe it should be conditional on libdrm Sorry, forgot to mention that this is on sparc64. libdrm configure says: configure: WARNING: Disabling libdrm_intel. It depends on atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package. configure: WARNING: Disabling libdrm_radeon. It depends on atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package. So, perhaps this code should not only be conditional on a libdrm install, but on the existence of libdrm_radeon inside that install? - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev 0001-configure.ac-look-for-libdrm_radeon-before-building-.patch Description: application/pgp-keys ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] r600g: fix occlusion querying in the new design
On Sat, Sep 25, 2010 at 4:08 PM, Jerome Glisse j.gli...@gmail.com wrote: On Sat, Sep 25, 2010 at 10:11 AM, Bas Nieuwenhuizen b...@basnieuwenhuizen.nl wrote: These patches fix piglit test occlusion-query-discard in the new design of r600g. The evergreen code is only compile tested as I don't have one. Bas Nieuwenhuizen (3): r600g: set ENABLE_KILL in the shader state in the new design r600g: introduce query state in new design r600g: set ENABLE_KILL on evergreen too Thanks for your patchset, however idea for query is to implement this specific bits into the winsys part. If i can't find time to do that today i will push your patches. Cheers, Jerome I pushed slightly modified version of your patch series, thanks a lot for your work Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Old toys [DRI1 drivers] .....
randrianas...@gmail.com wrote: Can freedesktop/X.org organise something like Google summer (winter?) of Code, with some tasks, need for moving those drivers forward? Good documentation about _today_ mesa's internals and interfaces hopefully will speed up process? X.Org has a Endless Vacation of Code program which allows students to submit proposals at any time of year for work on the X stack (which we generally include Mesa DRI in) - so if there's a student who wants to work on this, they just need to write up a proposal and submit it as described at: http://www.x.org/wiki/XorgEVoC This is *not* a general code bounties program for any developer who wants to earn extra cash, but like Google's program, specifically for students to learn about real-world code while contributing to open source instead of having to look elsewhere for a job between semesters or even during the school year. We're a lot more flexible than Google simply because we generally deal with one or two students at a time, not 5,000. As for documentation, that was part of Matt Turner's Google Summer of Code project this year for adding KMS support to glint, so hopefully we'll have that soon. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System Member of the X.Org Foundation Board of Directors ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Fixed two texture surface leaks in r600_blit_uncompress_depth().
Signed-off-by: Tilman Sauerbeck til...@code-monkey.de --- src/gallium/drivers/r600/r600_blit.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/r600/r600_blit.c b/src/gallium/drivers/r600/r600_blit.c index c30a7c1..7f411ae 100644 --- a/src/gallium/drivers/r600/r600_blit.c +++ b/src/gallium/drivers/r600/r600_blit.c @@ -203,6 +203,9 @@ int r600_blit_uncompress_depth(struct pipe_context *ctx, struct r600_resource_te util_blitter_custom_depth_stencil(rctx-blitter, zsurf, cbsurf, rctx-custom_dsa_flush, depth); + pipe_surface_reference(zsurf, NULL); + pipe_surface_reference(cbsurf, NULL); + /* resume queries */ r600_queries_resume(ctx); return 0; -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cflags mess with llvm builds
On Sat, Sep 25, 2010 at 12:24 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Fri, Sep 24, 2010 at 11:36 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Fri, Sep 24, 2010 at 3:15 PM, Luca Barbieri l...@luca-barbieri.com wrote: Yes, that used to happen for me too. Just edit llvm-config to remove the offending text and ideally file a bug on the LLVM bug tracker. looks like nobled did this for me : http://llvm.org/bugs/show_bug.cgi?id=8220 thanks :) The first answer is very negative and reports the bug as invalid. http://llvm.org/bugs/show_bug.cgi?id=8220#c1 The only suggestion is that custom flags could be appended. Another problem is indeed that mesa puts these llvm flags at the end, and the custom user CFLAGS first. Normally you do that because if the user has custom include paths, you want them to be at the beginning of the command line. It'd be nice if the llvm people could just use pkg-config instead of rolling their own config tool. I thought people had stopped doing that by now. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Implement x86_64 atomics for compilers w/o intrinsics.
Uhh.. also, were we not using the intrinsics on x86 before? Attached checks intrinsics before x86 and the new x86_64 block, so that the latter are fallbacks if intrinsics aren't available. -tom tom fogal tfo...@sci.utah.edu writes: A friend of mine had trouble building 7.8.2 on an old gcc3.3 system (no gcc intrinsics). From 337dace22dc2b0eab2372375f1574d94b894ef84 Mon Sep 17 00:00:00 2001 From: Tom Fogal tfo...@alumni.unh.edu Date: Sun, 26 Sep 2010 22:32:15 -0600 Subject: [PATCH] Prefer intrinsics to handrolled atomic ops. --- src/gallium/auxiliary/util/u_atomic.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/util/u_atomic.h b/src/gallium/auxiliary/util/u_atomic.h index 8434491..4ae6def 100644 --- a/src/gallium/auxiliary/util/u_atomic.h +++ b/src/gallium/auxiliary/util/u_atomic.h @@ -27,12 +27,12 @@ #define PIPE_ATOMIC_MSVC_INTRINSIC #elif (defined(PIPE_CC_MSVC) defined(PIPE_ARCH_X86)) #define PIPE_ATOMIC_ASM_MSVC_X86 +#elif defined(PIPE_CC_GCC) (PIPE_CC_GCC_VERSION = 401) +#define PIPE_ATOMIC_GCC_INTRINSIC #elif (defined(PIPE_CC_GCC) defined(PIPE_ARCH_X86)) #define PIPE_ATOMIC_ASM_GCC_X86 #elif (defined(PIPE_CC_GCC) defined(PIPE_ARCH_X86_64)) #define PIPE_ATOMIC_ASM_GCC_X86_64 -#elif defined(PIPE_CC_GCC) (PIPE_CC_GCC_VERSION = 401) -#define PIPE_ATOMIC_GCC_INTRINSIC #else #error Unsupported platform #endif -- 1.7.0.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
