Re: [PATCH] Implement x86_64 atomics for compilers w/o intrinsics.

On Thursday 30 September 2010 12:22:37 tom fogal wrote:
> José Fonseca <jfonseca <at> vmware.com> writes:
> > I didn't test but looks fine to me. Please commit.
> 
> Thanks.
> 
> The merge of 7.8 into master was complex at best, so I pushed 7.8 and
> then cherry-picked the commits to master.  Hope that's okay..
> 
> -tom

These days the process is to commit first to master, then cherry-pick to the 
stable branches where appropriate (after the patch has had a little while to 
stabilize).  We changed to this model back in April/May.

Should this be in 7.9?  It seems really weird to have a patch in 7.8 and 
master but not 7.9.

Re: [PATCH] Implement x86_64 atomics for compilers w/o intrinsics.

Kenneth Graunke <kenneth <at> whitecape.org> writes:
> On Thursday 30 September 2010 12:22:37 tom fogal wrote:
> > Jos=C3=A9 Fonseca <jfonseca <at> vmware.com> writes:
> > > I didn't test but looks fine to me. Please commit.
> >
> > Thanks.
> >
> > The merge of 7.8 into master was complex at best, so I pushed 7.8
> > and then cherry-picked the commits to master.  Hope that's okay..
>
> These days the process is to commit first to master, then cherry-pick
> to the stable branches where appropriate (after the patch has had
> a little while t= o stabilize).  We changed to this model back in
> April/May.

Okay, thanks for the clarification!

> Should this be in 7.9?  It seems really weird to have a patch in 7.8
> and master but not 7.9.

Yes, probably... I haven't been following the 7.9 status all that
closely.

I'll pick tomorrow if no other bugs come up.

-tom

[PATCH] scons: add TARGET_ARCH option

Hi,

When building with SCons+MSVC, it defaults to host architecture. So on
64 bit windows 64 bit Mesa is built. Attached patch adds SCons'
TARGET_ARCH option; passing TARGET_ARCH=x86 allows building 32 bit
Mesa on 64 bit host.

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

_______________________________________________
mesa-dev mailing list
mesa-dev <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Improve scons error reporting

Hi I have tried to build mesa using scons with drivers=llvmpipe  and
llvm=yes options in a box without llvm and the only thing I got was a
python backtrace.

I think it would be helpful to catch that exception an prompt a user
friendly "llvm can't be found".

I guess the whole build system have the same problem spread everywhere.

PS: I'm not providing a patch because I'm just starting to read the code.

--

-- 
Masca

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[PATCH] i965g: use Elements macro instead of manual sizeofs

Signed-off-by: Nicolas Kaiser <nikai <at> nikai.net>
---
 src/gallium/drivers/i965/intel_decode.c |   20 +++++++-------------
 1 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/src/gallium/drivers/i965/intel_decode.c b/src/gallium/drivers/i965/intel_decode.c
index bd8b917..36c04a3 100644
--- a/src/gallium/drivers/i965/intel_decode.c
+++ b/src/gallium/drivers/i965/intel_decode.c
 <at>  <at>  -40,6 +40,7  <at>  <at> 
 #include <stdint.h>
 #include <string.h>

+#include "util/u_memory.h"
 #include "util/u_string.h"
 #include "intel_decode.h"

 <at>  <at>  -116,8 +117,7  <at>  <at>  decode_mi(const uint32_t *data, int count, uint32_t hw_offset, int *failures)
     };

 
-    for (opcode = 0; opcode < sizeof(opcodes_mi) / sizeof(opcodes_mi[0]);
-	 opcode++) {
+    for (opcode = 0; opcode < Elements(opcodes_mi); opcode++) {
 	if ((data[0] & 0x1f800000) >> 23 == opcodes_mi[opcode].opcode) {
 	    unsigned int len = 1, i;

 <at>  <at>  -275,8 +275,7  <at>  <at>  decode_2d(const uint32_t *data, int count, uint32_t hw_offset, int *failures)
 	return len;
     }

Re: [PATCH] i965g: use Elements macro instead of manual sizeofs

On 10/01/2010 02:39 PM, Nicolas Kaiser wrote:
> Signed-off-by: Nicolas Kaiser<nikai <at> nikai.net>
> ---
>   src/gallium/drivers/i965/intel_decode.c |   20 +++++++-------------
>   1 files changed, 7 insertions(+), 13 deletions(-)

Committed.  Thanks!

-Brian

initial mesa/st RG support

Started playing around with adding RG support to st/mesa
http://cgit.freedesktop.org/~airlied/mesa/?h=gallium-rg

I'm guessing there is a bit more to  do, I'm not sure r300/r500 can
render to RG, which is what I'm playing about with.

Dave.

Re: initial mesa/st RG support

On Sat, Oct 2, 2010 at 11:40 AM, Dave Airlie <airlied <at> gmail.com> wrote:
> Started playing around with adding RG support to st/mesa
> http://cgit.freedesktop.org/~airlied/mesa/?h=gallium-rg

Okay I pushed this with a few more bits fixed, softpipe passes all the
RG tests in piglit with this, so that seems like a good start.

Dave.

[Bug 30557] New: Mesa/GL crash after creating 1x1 dummy Drawable (with Clutter)

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

           Summary: Mesa/GL crash after creating 1x1 dummy Drawable (with
                    Clutter)
           Product: Mesa
           Version: 7.6
          Platform: All
        OS/Version: OpenBSD
            Status: NEW
          Severity: critical
          Priority: medium
         Component: GLX
        AssignedTo: mesa-dev <at> lists.freedesktop.org
        ReportedBy: jasper <at> humppa.nl

As explained in this bugreport at Clutter
(http://bugzilla.clutter-project.org/show_bug.cgi?id=2345), every application
linking against clutter-glx-1.0 seg. faults upon execution.

Here is the full backtrace of one of the Clutter example programs, which
indicates an issue with Mesa/GLX/DRI:
cerebrum:interactive {110}
/usr/obj/ports/clutter-1.4.0/clutter-1.4.0/tests/interactive/test-interactive
ctest-ct-clip

Segmentation fault (core dumped)
cerebrum:interactive {113} gdb
/usr/obj/ports/clutter-1.4.0/clutter-1.4.0/tests/
-c
test-interactive.coreinter[7 <at> active/.li[3 <at> bs/[17 <at> test-interactive 

[PATCH] gallium/nv50: always true conditional

Untested: Am I guessing right it was rather meant this way?
---
 src/gallium/drivers/nv50/nv50_pc_optimize.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/gallium/drivers/nv50/nv50_pc_optimize.c b/src/gallium/drivers/nv50/nv50_pc_optimize.c
index 921ed15..27eb381 100644
--- a/src/gallium/drivers/nv50/nv50_pc_optimize.c
+++ b/src/gallium/drivers/nv50/nv50_pc_optimize.c
 <at>  <at>  -452,7 +452,7  <at>  <at>  nv_pass_lower_mods(struct nv_pass *ctx, struct nv_basic_block *b)
       if (nvi->opcode == NV_OP_SAT) {
          mi = nvi->src[0]->value->insn;

-         if (mi->opcode != NV_OP_ADD || mi->opcode != NV_OP_MAD)
+         if (mi->opcode != NV_OP_ADD && mi->opcode != NV_OP_MAD)
             continue;
          if (mi->flags_def || mi->def[0]->refc > 1)
             continue;
--

-- 
1.7.2.2