[Mesa-dev] [Bug 45420] undefined reference to `LLVMInitializeARMDisassembler'

[bugzilla-daemon]

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

ojab  changed:

   What|Removed |Added

  Attachment #56357|0   |1
is obsolete||

--- Comment #4 from ojab  2012-01-31 22:32:10 PST ---
Created attachment 56422
  --> https://bugs.freedesktop.org/attachment.cgi?id=56422
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?

-- 
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] Help required in configuring mesa 3d in non X environment.

[Matt Turner]

On Tue, Jan 31, 2012 at 4:26 AM, Sanjoy Saha - ERS, HCL Tech
 wrote:
> Matt,
>   I tried with --disable-glx option in autogen.sh line and I am still getting 
> the same error. Below is the log output. The option --disable-glx is not 
> recognized "configure: WARNING: unrecognized options: --disable-glx".
> The mesa version I am using is mesa-7.11.

Looks like the --disable-glx option was added after 7.11. Maybe you
should try 8.0-rc2? ftp://ftp.freedesktop.org/pub/mesa/8.0/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

Matt Turner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Matt Turner  2012-01-31 20:30:59 PST ---
Patches reverts. So, fixed, I guess.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] undefined C++ GLSL symbol error

[Kenneth Graunke]

On 01/31/2012 06:26 PM, Matt Turner wrote:

On Tue, Jan 31, 2012 at 8:32 PM, Brian Paul  wrote:

On 01/31/2012 02:44 PM, Zack Rusin wrote:


On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:


$ make>log
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'll revert the glsl stuff tonight.

I think automaking src/mesa/drivers/dri/* is okay, more or less?

Matt


I think trying to revert everything will just make things worse.  I'm 
okay with reverting the very latest bits for now.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium/dri: Handle xserver that doesn't send needless DRI2 invalidate events

[Ville Syrjälä]

From: Ville Syrjala 

Ever since xserver commit 531869448d07e00ae241120b59f35709d59c,
the server no longer sends invalidate events to clients, unless they
have performed a GetBuffers request since the drawable was last
invalidated.

If the drawable gets invalidated immediately after the GetBuffers
request was processed by the X server, it's possible that Xlib
will process the invalidate event while waiting for the GetBuffers
reply. So the server, thinking the client knows that the buffers
are invalid, is waiting for another GetBuffers request before
sending any more invalidate events. The client, on the other hand,
believes the buffers to be valid, and thus is expecting to receive
another invalidate event before it has to send another GetBuffers
request. The end result is that the client never again sends
a GetBuffers request.

To avoid this problem, take a snapshot of the lastStamp before
doing GetBuffers, and retry if the snapshot and the current
lastStamp no longer match after the GetBuffers reply has been
processed.

Signed-off-by: Ville Syrjälä 
---
Sigh. So no one actually took the bait based on the original
patch submission (apart from a small nibble from Dave).
Let's try again...

Distros are shipping the broken xserver-1.11 + Mesa 7.11 combo,
so either people don't care about the breakage, or no one
resizes their windows anymore. Either way I'd like at least my
system to work correctly w/o manual patching.

 .../state_trackers/dri/common/dri_drawable.c   |   30 +++
 1 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c 
b/src/gallium/state_trackers/dri/common/dri_drawable.c
index 65b3d04..5a261dd 100644
--- a/src/gallium/state_trackers/dri/common/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/common/dri_drawable.c
@@ -53,6 +53,7 @@ dri_st_framebuffer_validate(struct st_framebuffer_iface 
*stfbi,
unsigned statt_mask, new_mask;
boolean new_stamp;
int i;
+   unsigned int lastStamp;
 
statt_mask = 0x0;
for (i = 0; i < count; i++)
@@ -66,23 +67,26 @@ dri_st_framebuffer_validate(struct st_framebuffer_iface 
*stfbi,
 * client stamp.  It has the value of the server stamp when last
 * checked.
 */
-   new_stamp = (drawable->texture_stamp != drawable->dPriv->lastStamp);
+   do {
+  lastStamp = drawable->dPriv->lastStamp;
+  new_stamp = (drawable->texture_stamp != lastStamp);
 
-   if (new_stamp || new_mask || screen->broken_invalidate) {
-  if (new_stamp && drawable->update_drawable_info)
- drawable->update_drawable_info(drawable);
+  if (new_stamp || new_mask || screen->broken_invalidate) {
+ if (new_stamp && drawable->update_drawable_info)
+drawable->update_drawable_info(drawable);
 
-  drawable->allocate_textures(drawable, statts, count);
+ drawable->allocate_textures(drawable, statts, count);
 
-  /* add existing textures */
-  for (i = 0; i < ST_ATTACHMENT_COUNT; i++) {
- if (drawable->textures[i])
-statt_mask |= (1 << i);
-  }
+ /* add existing textures */
+ for (i = 0; i < ST_ATTACHMENT_COUNT; i++) {
+if (drawable->textures[i])
+   statt_mask |= (1 << i);
+ }
 
-  drawable->texture_stamp = drawable->dPriv->lastStamp;
-  drawable->texture_mask = statt_mask;
-   }
+ drawable->texture_stamp = lastStamp;
+ drawable->texture_mask = statt_mask;
+  }
+   } while (lastStamp != drawable->dPriv->lastStamp);
 
if (!out)
   return TRUE;
-- 
1.7.3.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Do not use sched_yield() on Linux

[Adam Jackson]

On 1/31/12 12:30 PM, Alan Swanson wrote:

As discussed back in 2003, sched_yield() on Linux is no longer
equivalent to other POSIX variations. From a LWN article; "This call
used to simply move the process to the end of the run queue; now it
moves the process to the "expired" queue, effectively cancelling the
rest of the process's time slice. So a process calling sched_yield() now
must wait until all other runnable processes in the system have used up
their time slices before it will get the processor again."

However its use on Linux has sneaked back in causing suboptimal
performance such as reported by Simon Farnsworth on r600g. Use sleep on
Linux instead.


Any reason why that can't be pthread_cond_wait() instead?  Explicit 
sleeps are a sin.


- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] undefined C++ GLSL symbol error

[Matt Turner]

On Tue, Jan 31, 2012 at 8:32 PM, Brian Paul  wrote:
> On 01/31/2012 02:44 PM, Zack Rusin wrote:
>>
>> On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:

 $ make>log
 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'll revert the glsl stuff tonight.

I think automaking src/mesa/drivers/dri/* is okay, more or less?

Matt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Convert colors if span ChanType and renderbuffer data type don't match

[Brian Paul]

On Tue, Jan 31, 2012 at 7:05 PM, Brian Paul  wrote:
> On Tue, Jan 31, 2012 at 4:47 PM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> This is a partial revert of f9874fe.  It turns out that the types
>> don't always match.  Specifically, this can happen when doing
>> glCopyPixels from a float FBO to a RGBA8 FBO.
>>
>> Signed-off-by: Ian Romanick 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45429
>> ---
>>  src/mesa/swrast/s_span.c |   19 +++
>>  1 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/mesa/swrast/s_span.c b/src/mesa/swrast/s_span.c
>> index 28f2f3d..422d86c 100644
>> --- a/src/mesa/swrast/s_span.c
>> +++ b/src/mesa/swrast/s_span.c
>> @@ -1321,12 +1321,23 @@ _swrast_write_rgba_span( struct gl_context *ctx, 
>> SWspan *span)
>>          if (rb) {
>>             GLchan rgbaSave[MAX_WIDTH][4];
>>
>> -            if (span->array->ChanType == GL_UNSIGNED_BYTE) {
>> -               span->array->rgba = span->array->rgba8;
>> +           GLenum datatype;
>> +           GLuint comps;
>> +
>> +           _mesa_format_to_type_and_comps(rb->Format, &datatype, &comps);
>> +
>> +            /* set span->array->rgba to colors for render buffer's datatype 
>> */
>> +            if (datatype != span->array->ChanType) {
>> +               convert_color_type(span, datatype, 0);
>>             }
>>             else {
>> -               span->array->rgba = (void *)
>> -                  span->array->attribs[FRAG_ATTRIB_COL0];
>> +               if (span->array->ChanType == GL_UNSIGNED_BYTE) {
>> +                  span->array->rgba = span->array->rgba8;
>> +               }
>> +               else {
>> +                  span->array->rgba = (void *)
>> +                     span->array->attribs[FRAG_ATTRIB_COL0];
>> +               }
>>             }
>>
>>             if (!multiFragOutputs && numBuffers > 1) {
>
> LGTM.  Reviewed-by: Brian Paul 

Candidate for 8.0, right?

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Convert colors if span ChanType and renderbuffer data type don't match

[Brian Paul]

On Tue, Jan 31, 2012 at 4:47 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> This is a partial revert of f9874fe.  It turns out that the types
> don't always match.  Specifically, this can happen when doing
> glCopyPixels from a float FBO to a RGBA8 FBO.
>
> Signed-off-by: Ian Romanick 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45429
> ---
>  src/mesa/swrast/s_span.c |   19 +++
>  1 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/swrast/s_span.c b/src/mesa/swrast/s_span.c
> index 28f2f3d..422d86c 100644
> --- a/src/mesa/swrast/s_span.c
> +++ b/src/mesa/swrast/s_span.c
> @@ -1321,12 +1321,23 @@ _swrast_write_rgba_span( struct gl_context *ctx, 
> SWspan *span)
>          if (rb) {
>             GLchan rgbaSave[MAX_WIDTH][4];
>
> -            if (span->array->ChanType == GL_UNSIGNED_BYTE) {
> -               span->array->rgba = span->array->rgba8;
> +           GLenum datatype;
> +           GLuint comps;
> +
> +           _mesa_format_to_type_and_comps(rb->Format, &datatype, &comps);
> +
> +            /* set span->array->rgba to colors for render buffer's datatype 
> */
> +            if (datatype != span->array->ChanType) {
> +               convert_color_type(span, datatype, 0);
>             }
>             else {
> -               span->array->rgba = (void *)
> -                  span->array->attribs[FRAG_ATTRIB_COL0];
> +               if (span->array->ChanType == GL_UNSIGNED_BYTE) {
> +                  span->array->rgba = span->array->rgba8;
> +               }
> +               else {
> +                  span->array->rgba = (void *)
> +                     span->array->attribs[FRAG_ATTRIB_COL0];
> +               }
>             }
>
>             if (!multiFragOutputs && numBuffers > 1) {

LGTM.  Reviewed-by: Brian Paul 
___
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'

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #3 from Vinson Lee  2012-01-31 17:45:38 PST 
---
mesa: b0337b679ad4c2feae59215104cfa60b58a619d5 (master)

$ llvm-config --version
2.7

$ scons
[...]
  Linking build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend ...
build/linux-x86_64-debug/gallium/auxiliary/libgallium.a(lp_bld_debug.os): In
function `llvm::InitializeAllAsmPrinters()':
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeMBlazeAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeBlackfinAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeSystemZAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeMSP430AsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeXCoreAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializePIC16AsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeCellSPUAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeMipsAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeARMAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeAlphaAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializePowerPCAsmPrinter'
/usr/include/llvm/Config/AsmPrinters.def:27: undefined reference to
`LLVMInitializeSparcAsmPrinter'
collect2: ld returned 1 exit status

-- 
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 2/2] mesa: reference shared state in glPushAttrib(GL_TEXTURE_BIT)

[Brian Paul]

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] [PATCH 1/2] mesa: use new _mesa_reference_shared_state() function

[Brian Paul]

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
+++ b/src/mesa/main/shared.h
@@ -27,13 +27,14 @@
 
 struct gl_context;
 
-struct gl_shared_state *
-_mesa_alloc_shared_state(struct gl_context *ctx);
+void
+

Re: [Mesa-dev] undefined C++ GLSL symbol error

[Brian Paul]

On 01/31/2012 02:44 PM, Zack Rusin wrote:

On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:

$ make>log
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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: Implement ralloc with talloc

[Carl Worth]

Since talloc has more debugging features than ralloc, such as the
very useful:

 talloc_report_full(ctx, stdout);

we here conditionally implement ralloc by simply calling directly into
talloc.

NOTE: This commit is simply example code that I used recently, and I
thought I should share in case someone else might find useful. I'm not
proposing pushing it upstream in its current state. If there is any
interest in pushing this upstream, at least the following would need
to be done:

* The hard-coded #define of RALLOC_USE_TALLOC should be removed from
  ralloc.h and some configuration mechanism should instead be provided
  so that the user can choose to build with talloc.

* Said configuration mechanism should also arrange for linking with
  -ltalloc. In the meantime, a user can do:

LDFLAGS=-ltalloc ./autogen.sh

Some other things could be done that aren't strictly necessary, but
might be nice for cleaner code:

* The three blocks of "#if ! RALLOC_USE_TALLOC" in ralloc.c could be
  reduced to one by simply moving some code around. I didn't do this
  simply to avoid making the patch look more involved than it actually
  is.

* The conditional support for a destructor to be void (for ralloc) and
  to return int (for talloc) is really ugly. I would recommend just
  changing ralloc's destructor type to return int.

* This current patch changes one line of code even when
  RALLOC_USE_TALLOC is not defined to a true value. Namely, inside of
  ralloc_asprintf_rewrite_tail, a call to the internal resize function
  is replaced to a call to reralloc_size. I think this is correct, but
  Ken should confirm that.
---
 src/glsl/glsl_symbol_table.h |   20 -
 src/glsl/ralloc.c|   12 +-
 src/glsl/ralloc.h|   48 ++
 3 files changed, 78 insertions(+), 2 deletions(-)

diff --git a/src/glsl/glsl_symbol_table.h b/src/glsl/glsl_symbol_table.h
index 637bc03..a051e29 100644
--- a/src/glsl/glsl_symbol_table.h
+++ b/src/glsl/glsl_symbol_table.h
@@ -44,10 +44,22 @@ class symbol_table_entry;
  */
 struct glsl_symbol_table {
 private:
+
+/* Ralloc wants a void destructor while talloc wants a return value of
+ * int. Support both based on the RALLOC_USE_TALLOC conditional. */
+#if RALLOC_USE_TALLOC
+   static int
+#else
static void
+#endif
_glsl_symbol_table_destructor (glsl_symbol_table *table)
{
   table->~glsl_symbol_table();
+
+#if RALLOC_USE_TALLOC
+  return 0;
+#endif
+
}
 
 public:
@@ -60,7 +72,13 @@ public:
   table = ralloc_size(ctx, size);
   assert(table != NULL);
 
-  ralloc_set_destructor(table, (void (*)(void*)) 
_glsl_symbol_table_destructor);
+  ralloc_set_destructor(table,
+#if RALLOC_USE_TALLOC  
+   (int (*)(void*))
+#else
+   (void (*)(void*))
+#endif
+   _glsl_symbol_table_destructor);
 
   return table;
}
diff --git a/src/glsl/ralloc.c b/src/glsl/ralloc.c
index 91e4bab..cbd3407 100644
--- a/src/glsl/ralloc.c
+++ b/src/glsl/ralloc.c
@@ -49,6 +49,8 @@ _CRTIMP int _vscprintf(const char *format, va_list argptr);
 #define unlikely(x) !!(x)
 #endif
 
+#if ! RALLOC_USE_TALLOC
+
 #ifndef va_copy
 #ifdef __va_copy
 #define va_copy(dest, src) __va_copy((dest), (src))
@@ -184,6 +186,7 @@ ralloc_array_size(const void *ctx, size_t size, unsigned 
count)
 
return ralloc_size(ctx, size * count);
 }
+#endif /* ! RALLOC_USE_TALLOC */
 
 void *
 rzalloc_array_size(const void *ctx, size_t size, unsigned count)
@@ -203,6 +206,7 @@ reralloc_array_size(const void *ctx, void *ptr, size_t 
size, unsigned count)
return reralloc_size(ctx, ptr, size * count);
 }
 
+#if ! RALLOC_USE_TALLOC
 void
 ralloc_free(void *ptr)
 {
@@ -390,6 +394,8 @@ ralloc_asprintf(const void *ctx, const char *fmt, ...)
return ptr;
 }
 
+#endif /* ! RALLOC_USE_TALLOC */
+
 /* Return the length of the string that would be generated by a printf-style
  * format and argument list, not including the \0 byte.
  */
@@ -419,6 +425,8 @@ printf_length(const char *fmt, va_list untouched_args)
return size;
 }
 
+#if ! RALLOC_USE_TALLOC
+
 char *
 ralloc_vasprintf(const void *ctx, const char *fmt, va_list args)
 {
@@ -451,6 +459,8 @@ ralloc_vasprintf_append(char **str, const char *fmt, 
va_list args)
return ralloc_vasprintf_rewrite_tail(str, existing_length, fmt, args);
 }
 
+#endif /* ! RALLOC_USE_TALLOC */
+
 bool
 ralloc_asprintf_rewrite_tail(char **str, size_t start, const char *fmt, ...)
 {
@@ -479,7 +489,7 @@ ralloc_vasprintf_rewrite_tail(char **str, size_t start, 
const char *fmt,
 
new_length = printf_length(fmt, args);
 
-   ptr = resize(*str, start + new_length + 1);
+   ptr = reralloc_size(ralloc_parent(*str), *str, start + new_length + 1);
if (unlikely(ptr == NULL))
   return false;
 
diff --git a/src/glsl/ralloc.h b/src/glsl/ralloc.h
index 1324f34..67e9100 100644
--- a/src/glsl/ralloc.h
+++ b/s

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

--- Comment #8 from Kevin DeKorte  2012-01-31 16:12:40 PST 
---
I had this working yesterday and with the patch in bug #45466 I can get to
compile again.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: Convert colors if span ChanType and renderbuffer data type don't match

[Ian Romanick]

From: Ian Romanick 

This is a partial revert of f9874fe.  It turns out that the types
don't always match.  Specifically, this can happen when doing
glCopyPixels from a float FBO to a RGBA8 FBO.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45429
---
 src/mesa/swrast/s_span.c |   19 +++
 1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/mesa/swrast/s_span.c b/src/mesa/swrast/s_span.c
index 28f2f3d..422d86c 100644
--- a/src/mesa/swrast/s_span.c
+++ b/src/mesa/swrast/s_span.c
@@ -1321,12 +1321,23 @@ _swrast_write_rgba_span( struct gl_context *ctx, SWspan 
*span)
  if (rb) {
 GLchan rgbaSave[MAX_WIDTH][4];
 
-if (span->array->ChanType == GL_UNSIGNED_BYTE) {
-   span->array->rgba = span->array->rgba8;
+   GLenum datatype;
+   GLuint comps;
+
+   _mesa_format_to_type_and_comps(rb->Format, &datatype, &comps);
+
+/* set span->array->rgba to colors for render buffer's datatype */
+if (datatype != span->array->ChanType) {
+   convert_color_type(span, datatype, 0);
 }
 else {
-   span->array->rgba = (void *)
-  span->array->attribs[FRAG_ATTRIB_COL0];
+   if (span->array->ChanType == GL_UNSIGNED_BYTE) {
+  span->array->rgba = span->array->rgba8;
+   }
+   else {
+  span->array->rgba = (void *)
+ span->array->attribs[FRAG_ATTRIB_COL0];
+   }
 }
 
 if (!multiFragOutputs && numBuffers > 1) {
-- 
1.7.6.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

--- Comment #7 from Ian Romanick  2012-01-31 15:47:23 PST 
---
32-bit-on-64-bit builds have been broken for some time.  I report this back in
October of 2011: bug #41700.

-- 
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] gen_matypes: fix cross-compiling with gcc

[Mike Frysinger]

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 
---
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 ) \
+   DEFINE_UL( s, d )
+
+#define printf( x )\
+   __asm__ __

[Mesa-dev] [Bug 45466] New: Updated configure.ac check for llvm-config to use 32 version when appropriate

[bugzilla-daemon]

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

 Bug #: 45466
   Summary: Updated configure.ac check for llvm-config to use 32
version when appropriate
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: kdeko...@yahoo.com


diff --git a/configure.ac b/configure.ac
index 0e03af7..6400638 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1762,14 +1762,25 @@ if test "x$enable_gallium_llvm" = xauto; then
 esac
 fi
 if test "x$enable_gallium_llvm" = xyes; then
-AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no])
+if test "x$enable_32bit" = xyes; then
+AC_PATH_PROG([LLVM_CONFIG], [llvm-config-32], [no])
+   LLVM_LDFLAGS_ADD="-m32"
+fi
+if test "x$enable_64" = xyes; then
+AC_PATH_PROG([LLVM_CONFIG], [llvm-config-64], [no])
+   LLVM_LDFLAGS_ADD="-m64"
+fi
+if test "x$LLVM_CONFIG" = x; then
+AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no])
+fi 

 if test "x$LLVM_CONFIG" != xno; then
LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'`
-   LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed -e 's/-DNDEBUG\>//g' -e
's/-ped
+   LLVM_CFLAGS=`$LLVM_CONFIG --cxxflags|sed -e 's/-DNDEBUG\>//g' -e
's/-ped
LLVM_LIBS="`$LLVM_CONFIG --libs engine bitwriter`"

LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
+   LLVM_LDFLAGS="$LLVM_LDFLAGS $LLVM_LDFLAGS_ADD"
DEFINES="$DEFINES -D__STDC_CONSTANT_MACROS"
MESA_LLVM=1
 else

-- 
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] undefined C++ GLSL symbol error

[Zack Rusin]

On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:
> > $ make>log
> > 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?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Build fail since Make sure libGL.so links with libglsl

[Andy Furniss]

Brian Paul wrote:


make[3]: *** [r600_dri.so] Error 1


I've been running into weird build problems all day too (I'm seeing the
same problem with softpipe ATM using very simple configure options).

It seems that make -j8 is flakey too. I've had better luck omitting -j.
That definitely needs to be fixed too.


Thanks, I tried without -j, but it makes no difference to this one.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Build fail since Make sure libGL.so links with libglsl

[Andy Furniss]

Matt Turner wrote:

On Tue, Jan 31, 2012 at 3:12 PM, Andy Furniss  wrote:

Maybe it's just me having a strange/old LFS system  - but I am getting build
errors since


Are you subscribed? It seems so is everyone else. :P


Make sure libGL.so links with libglsl
f53e7e981ef35ab64a084c8da6c67bd2d230fe33


*Since* this commit? It was working before this?



The build fails on this commit and apparently works on the commit before.

But I've just noticed -

lrwxrwxrwx 1 andy andy 10 2012-01-31 20:02 
/home/andy/Src/Xorg-git/modular/lib/libGL.so -> libGL.so.1

bash-3.2$ ls -lh /home/andy/Src/Xorg-git/modular/lib/libGL.so.1
lrwxrwxrwx 1 andy andy 12 2012-01-31 20:02 
/home/andy/Src/Xorg-git/modular/lib/libGL.so.1 -> libGL.so.1.2

bash-3.2$ ls -lh /home/andy/Src/Xorg-git/modular/lib/libGL.so.1.2
-rwxrwxr-x 1 andy andy 2.3M 2012-01-31 11:00 
/home/andy/Src/Xorg-git/modular/lib/libGL.so.1.2


So it looks like I am not really building/installing libGL.so.1.2 since 
11.00 this morning - which would be when I had the tree reset to some 
time ago trying to find a different build problem.



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: fix scaffolding build

[Matt Turner]

On Tue, Jan 31, 2012 at 2:31 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> /usr/bin/ld: .libs/glsl_compiler: hidden symbol `_mesa_reference_shader' in 
> standalone_scaffolding.o is referenced by DSO
>
> export the symbol.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/glsl/standalone_scaffolding.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/glsl/standalone_scaffolding.h 
> b/src/glsl/standalone_scaffolding.h
> index 8773320..e79c40c 100644
> --- a/src/glsl/standalone_scaffolding.h
> +++ b/src/glsl/standalone_scaffolding.h
> @@ -33,7 +33,7 @@
>
>  #include "main/mtypes.h"
>
> -extern "C" void
> +extern "C" GLAPI void
>  _mesa_reference_shader(struct gl_context *ctx, struct gl_shader **ptr,
>                        struct gl_shader *sh);
>
> --
> 1.7.7.6

I'm seeing that osdemo fails to build with undefined references (like
Brian reported):

  CC osdemo.o
  CCLD   osdemo
/usr/lib64/libglsl.so: undefined reference to `_mesa_symbol_table_add_symbol'
/usr/lib64/libglsl.so: undefined reference to `_mesa_symbol_table_symbol_scope'
/usr/lib64/libglsl.so: undefined reference to `_mesa_symbol_table_pop_scope'
/usr/lib64/libglsl.so: undefined reference to `_mesa_symbol_table_find_symbol'
/usr/lib64/libglsl.so: undefined reference to `_mesa_new_shader'
/usr/lib64/libglsl.so: undefined reference to `_mesa_reference_shader'
/usr/lib64/libglsl.so: undefined reference to
`_mesa_symbol_table_add_global_symbol'
/usr/lib64/libglsl.so: undefined reference to `_mesa_symbol_table_push_scope'
/usr/lib64/libglsl.so: undefined reference to `_mesa_symbol_table_ctor'
/usr/lib64/libglsl.so: undefined reference to `_mesa_symbol_table_dtor'
collect2: ld returned 1 exit status

Applying this patch doesn't seem to affect it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

--- Comment #6 from Matt Turner  2012-01-31 12:33:05 PST ---
(In reply to comment #4)
> Adding those flags before autogen does seem to fix it, but shouldn't that be
> what --enable-32-bit does?

Yes. Please send a patch. :)

(In reply to comment #5)
> I think we want the --enable-32-bit so that we can build 32bit binaries on a
> 64bit machine so that we can run 32bit applications.

No, with proper automake you specify --build, --target, --host to do this, not
hacky --enable-32-bit flags.

-- 
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] Build fail since Make sure libGL.so links with libglsl

[Matt Turner]

On Tue, Jan 31, 2012 at 3:12 PM, Andy Furniss  wrote:
> Maybe it's just me having a strange/old LFS system  - but I am getting build
> errors since

Are you subscribed? It seems so is everyone else. :P

> Make sure libGL.so links with libglsl
> f53e7e981ef35ab64a084c8da6c67bd2d230fe33

*Since* this commit? It was working before this?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

--- Comment #5 from Kevin DeKorte  2012-01-31 12:22:28 PST 
---
I think we want the --enable-32-bit so that we can build 32bit binaries on a
64bit machine so that we can run 32bit applications.

-- 
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 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

--- Comment #4 from Kevin DeKorte  2012-01-31 12:21:22 PST 
---
Adding those flags before autogen does seem to fix it, but shouldn't that be
what --enable-32-bit does?

-- 
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 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

--- Comment #3 from Matt Turner  2012-01-31 12:19:37 PST ---
If that fixes it, then yeah.

The real solution is to automake everything and then kill the
--enable-{32,64}-bit flags.

-- 
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] Build fail since Make sure libGL.so links with libglsl

[Brian Paul]

On 01/31/2012 01:12 PM, Andy Furniss wrote:

Maybe it's just me having a strange/old LFS system  - but I am getting
build errors since

Make sure libGL.so links with libglsl
f53e7e981ef35ab64a084c8da6c67bd2d230fe33

Perhaps my build options are to blame -

CPPFLAGS="-I/home/andy/Src/Xorg-git/modular/include"
LDFLAGS="-L/home/andy/Src/Xorg-git/modular/lib" ./autogen.sh
--prefix=/home/andy/Src/Xorg-git/modular --enable-debug --disable-egl
--enable-texture-float --enable-gallium-g3dvl --disable-gallium-llvm
--with-gallium-drivers=r600,swrast --with-dri-drivers=swrast



/bin/sh ../../../../bin/mklib -o r600_dri.so.tmp -noprefix -linker
'g++' -ldflags '-L/home/andy/Src/Xorg-git/modular/lib' \
target.o ../../../../src/mesa/drivers/dri/common/utils.o
../../../../src/mesa/drivers/dri/common/dri_util.o
../../../../src/mesa/drivers/dri/common/xmlconfig.o
../../../../src/gallium/drivers/r600/libr600.a
../../../../src/gallium/state_trackers/dri/drm/libdridrm.a
../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a
../../../../src/gallium/drivers/trace/libtrace.a
../../../../src/gallium/drivers/rbug/librbug.a
../../../../src/gallium/drivers/noop/libnoop.a \
-Wl,--start-group ../../../../src/mesa/libmesagallium.a
../../../../src/gallium/auxiliary/libgallium.a -Wl,--end-group \
-L../../../../lib -Wl,-R/home/andy/Src/Xorg-git/modular/lib/dri
-ldricore -lglsl -L/home/andy/Src/Xorg-git/modular/lib -ldrm -lexpat
-lm -lpthread -ldl
mklib: Making Linux shared library: r600_dri.so.tmp
g++ -I/home/andy/Src/Xorg-git/modular/include -g -O2 -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-strict-aliasing -fno-builtin-memcmp -g -g -O2 -fPIC -DUSE_X86_ASM
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
-DDEBUG -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS
-fvisibility=hidden -o r600_dri.so.test
../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp
-L../../../../lib -Wl,-R/home/andy/Src/Xorg-git/modular/lib/dri
-ldricore -lglsl -L/home/andy/Src/Xorg-git/modular/lib -ldrm -lexpat
-lm -lpthread -ldl -L/home/andy/Src/Xorg-git/modular/lib;
r600_dri.so.tmp: undefined reference to `st_gl_api_create'
collect2: ld returned 1 exit status
make[3]: *** [r600_dri.so] Error 1


I've been running into weird build problems all day too (I'm seeing 
the same problem with softpipe ATM using very simple configure options).


It seems that make -j8 is flakey too.  I've had better luck omitting 
-j.  That definitely needs to be fixed too.


-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

--- Comment #2 from Kenneth Graunke  2012-01-31 12:13:40 
PST ---
Yeah, I'm pretty sure this broke a while back.  It -should- work if you do:

CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --enable-32-bit --more-options-here

Which also has the added benefit of allowing you to select whether you want -O2
or not.  That said, it'd probably be nice to add -m32 to CFLAGS and CXXFLAGS
when --enable-32-bit is passed.  Matt, do you agree?

-- 
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] Build fail since Make sure libGL.so links with libglsl

[Andy Furniss]

Maybe it's just me having a strange/old LFS system  - but I am getting 
build errors since


Make sure libGL.so links with libglsl 
f53e7e981ef35ab64a084c8da6c67bd2d230fe33


Perhaps my build options are to blame -

CPPFLAGS="-I/home/andy/Src/Xorg-git/modular/include" 
LDFLAGS="-L/home/andy/Src/Xorg-git/modular/lib" ./autogen.sh 
--prefix=/home/andy/Src/Xorg-git/modular --enable-debug --disable-egl 
--enable-texture-float --enable-gallium-g3dvl --disable-gallium-llvm 
--with-gallium-drivers=r600,swrast --with-dri-drivers=swrast




/bin/sh ../../../../bin/mklib -o r600_dri.so.tmp -noprefix -linker 'g++' 
-ldflags '-L/home/andy/Src/Xorg-git/modular/lib' \
target.o 
../../../../src/mesa/drivers/dri/common/utils.o 
../../../../src/mesa/drivers/dri/common/dri_util.o 
../../../../src/mesa/drivers/dri/common/xmlconfig.o 
../../../../src/gallium/drivers/r600/libr600.a 
../../../../src/gallium/state_trackers/dri/drm/libdridrm.a 
../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a 
../../../../src/gallium/drivers/trace/libtrace.a 
../../../../src/gallium/drivers/rbug/librbug.a 
../../../../src/gallium/drivers/noop/libnoop.a \
-Wl,--start-group ../../../../src/mesa/libmesagallium.a 
../../../../src/gallium/auxiliary/libgallium.a -Wl,--end-group \
  -L../../../../lib 
-Wl,-R/home/andy/Src/Xorg-git/modular/lib/dri -ldricore -lglsl 
-L/home/andy/Src/Xorg-git/modular/lib -ldrm   -lexpat -lm -lpthread -ldl

mklib: Making Linux shared library:  r600_dri.so.tmp
g++ -I/home/andy/Src/Xorg-git/modular/include -g -O2 -Wall -std=c99 
-Werror=implicit-function-declaration -Werror=missing-prototypes 
-fno-strict-aliasing -fno-builtin-memcmp -g -g -O2  -fPIC  -DUSE_X86_ASM 
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS 
-DDEBUG -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB 
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING 
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS 
-fvisibility=hidden -o r600_dri.so.test 
../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp 
-L../../../../lib -Wl,-R/home/andy/Src/Xorg-git/modular/lib/dri 
-ldricore -lglsl  -L/home/andy/Src/Xorg-git/modular/lib -ldrm   -lexpat 
-lm -lpthread -ldl  -L/home/andy/Src/Xorg-git/modular/lib;

r600_dri.so.tmp: undefined reference to `st_gl_api_create'
collect2: ld returned 1 exit status
make[3]: *** [r600_dri.so] Error 1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

--- Comment #1 from Kevin DeKorte  2012-01-31 11:58:45 PST 
---
After additional research it appears the build triplet is wrong. I don't think
that the --enable-32-bit flag is being honored by libglsl

-- 
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] Segmentation fault with VTK OffScreenRendering

[Joshua Daniel Franklin (UW Seattle)]

On 1/30/12 12:14 PM, Kevin H. Hobbs wrote:

The VTK tests have the same pattern of failures with the Fedora 15
OSMesa package as with the custom built OSMesa library, that is :


Thanks, so it does. Works fine on Fedora 15 and Red Hat EL6 too. FYI, 
since I'm very interested in repeatable deployment, I adapted your 
script to build using only mesa-libOSMesa-devel and put it here:


http://staff.washington.edu/joshuadf/vtk/

I also adapted the OffScreenRendering.cxx to java which is here and 
tested it:

http://staff.washington.edu/joshuadf/vtk/OffScreenRendering.java

For the Java wrappers I had to use Java 7, for added hilarity "Java 
versions 1.5/1.6 throw UnsatisfiedLinkError when run headless"

http://bugs.sun.com/view_bug.do?bug_id=6539705

This did effect OpenJDK 1.6.0_22 on Fedora 15.

Thanks again!
Joshua
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: fix scaffolding build

[Dave Airlie]

From: Dave Airlie 

/usr/bin/ld: .libs/glsl_compiler: hidden symbol `_mesa_reference_shader' in 
standalone_scaffolding.o is referenced by DSO

export the symbol.

Signed-off-by: Dave Airlie 
---
 src/glsl/standalone_scaffolding.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/glsl/standalone_scaffolding.h 
b/src/glsl/standalone_scaffolding.h
index 8773320..e79c40c 100644
--- a/src/glsl/standalone_scaffolding.h
+++ b/src/glsl/standalone_scaffolding.h
@@ -33,7 +33,7 @@
 
 #include "main/mtypes.h"
 
-extern "C" void
+extern "C" GLAPI void
 _mesa_reference_shader(struct gl_context *ctx, struct gl_shader **ptr,
struct gl_shader *sh);
 
-- 
1.7.7.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

Kevin DeKorte  changed:

   What|Removed |Added

 CC||bri...@vmware.com,
   ||matts...@gmail.com,
   ||stereotype...@gmail.com

-- 
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 45458] New: mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

[bugzilla-daemon]

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

 Bug #: 45458
   Summary: mesa will not compile in 32bit mode on a 64bit machine
that is setup to do that
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: kdeko...@yahoo.com


git ffe376d5a74dee837dc1a421de29ae551087630f

./autogen.sh --prefix=/usr --libdir=/usr/lib --with-dri-drivers=""
--with-galliu
m-drivers=r600,swrast --enable-gallium-egl --enable-openvg --enable-gles1
--enab
le-gles2 --enable-texture-float --enable-vdpau --enable-xvmc --enable-osmesa
--e
nable-32-bit --enable-gallium-llvm --enable-texture-float

This command worked properly on 1/30/2012. I'm guessing that the LDFLAGS is not
properly set in the Makefile. In my Makefile in src/glsl LDFLAGS is not set. It
should contain something like -m32 or $(ARCH_FLAGS)



gmake[4]: Entering directory `/home/kdekorte/git/mesa-32/src/glsl'
  CXXLD  libglsl.la
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-redhat-linux/4.6.2/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/libm.so when searching
for -lm
/usr/bin/ld: skipping incompatible /usr/lib/../lib64/libm.so when searching for
-lm
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/libc.so when searching
for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib64/libc.so when searching for
-lc
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-redhat-linux/4.6.2/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: i386:x86-64 architecture of input file
`/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/crti.o' is
incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file
`/usr/lib/gcc/x86_64-redhat-linux/4.6.2/crtbeginS.o' is incompatible with i386
output
/usr/bin/ld: i386:x86-64 architecture of input file
`/usr/lib/gcc/x86_64-redhat-linux/4.6.2/crtendS.o' is incompatible with i386
output
/usr/bin/ld: i386:x86-64 architecture of input file
`/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/crtn.o' is
incompatible with i386 output
collect2: ld returned 1 exit status
gmake[4]: *** [libglsl.la] Error 1
gmake[4]: Leaving directory `/home/kdekorte/git/mesa-32/src/glsl'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory `/home/kdekorte/git/mesa-32/src/glsl'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/kdekorte/git/mesa-32/src/glsl'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/kdekorte/git/mesa-32/src'
make: *** [default] Error 1

-- 
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] OSMesa glapi linlking

[Kevin H. Hobbs]

On 01/31/2012 09:53 AM, Brian Paul wrote:
> 
> I just pushed a couple osmesa fixes to master and the 8.0 branch.  Can 
> you give it a try?
> 
> Thinks seem to fix things on the 8.0 branch but I'm unable to verify 
> on master due to some other regressions ATM.
> 
> -Brian
> 

master leaves a bunch of symbols undefined.

/home/kevin/mesa_osmesa/lib/libglsl.so: undefined reference to
`_mesa_symbol_table_ctor'
/home/kevin/mesa_osmesa/lib/libOSMesa.so.8: undefined reference to
`_swrast_unmap_soft_renderbuffer'
/home/kevin/mesa_osmesa/lib/libOSMesa.so.8: undefined reference to
`_tnl_InvalidateState'
/home/kevin/mesa_osmesa/lib/libOSMesa.so.8: undefined reference to
`_swrast_map_soft_renderbuffer'

8.0 mostly works

98% tests passed, 9 tests failed out of 596

Total Test time (real) = 259.19 sec

The following tests FAILED:
259 - TestMultiTexturing (SEGFAULT)
260 - TestMultiTexturingTransform (SEGFAULT)
262 - TestScalarBar (Failed)
330 - TestBarChartActor (Failed)
334 - TestPieChartActor (Failed)
338 - TestLegendBoxActor (Failed)
380 - TestBrokenLineWidget (Failed)
510 - Infovis-TestTulipReaderClusters (Failed)
536 - Views-TestRenderView (Failed)



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION

[Christoph Bumiller]

On 31.01.2012 09:49, Jose Fonseca wrote:
> I don't oppose adding the cap.
>
> But I think that the story for draw module should be figured out, as at least 
> nv50/nvc0 drivers will advertise 
> PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION = 1 and are using the draw 
> module:
>
> $ git grep '\' src/gallium/drivers/
> src/gallium/drivers/i915/i915_context.c:   i915->draw = 
> draw_create(&i915->base);
> src/gallium/drivers/nv50/nv50_context.c:   nv50->draw = draw_create(pipe);
> src/gallium/drivers/nvc0/nvc0_context.c:   nvc0->draw = draw_create(pipe);

Those have been there since forever and it's not actually used or
needed, I'll happily remove it for nv50 and nvc0.

So in practice the draw module should never encounter a driver that
reports 'yes' for the cap; I'll add the assertion.

> src/gallium/drivers/nvfx/nvfx_context.c:nvfx->draw = 
> draw_create(&nvfx->pipe);
> src/gallium/drivers/r300/r300_context.c:r300->draw = 
> draw_create(&r300->context);
> src/gallium/drivers/softpipe/sp_context.c:  softpipe->draw = 
> draw_create(&softpipe->pipe);
> src/gallium/drivers/svga/svga_swtnl_draw.c:   svga->swtnl.draw = 
> draw_create(&svga->pipe);
>
> Either:
> - nv50/nvc0 continue to advertise 
> PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION = 0
> - nv50/nvc0 stop using draw module (at least for things that use software 
> vertex processing or depend on flatshading)
> - update draw module to respect 
> PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION (as it does for triangles, 
> but still a bit of work)
> - wait for draw module to start using geometry shaders (where available) for 
> its workarounds, where stuff like provoking vertex can be easily accommodated 
>  I think
>
> Jose
>
> - Original Message -
>> BTW I am in favor of adding the CAP. r300 doesn't support the
>> first-vertex convention for quads, but r600 does support it and it
>> cannot be disabled for quads only. Because of that, the provoking
>> vertex switch is currently part of the draw state instead of the
>> rasterizer state in r600g. Adding the CAP will help move it back to
>> the rasterizer state.
>>
>> Of course, if we didn't have r600 and nv50 drivers, the CAP would be
>> useless.
>>
>> Marek
>>
>> On Mon, Jan 30, 2012 at 5:59 PM, Jose Fonseca 
>> wrote:
>>> Note that unless the draw module is updated to take
>>> PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION == 1 in
>>> consideration this change will cause regressions for drivers that
>>> fallback to draw module for doing things like clipping, unfilled
>>> mode, etc w/ flat shadding.  Can this happen in practice?  If yes,
>>> then I'm not sure if this is worth the trouble. If no, then please
>>> add an assert(PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION ==
>>> 0) somewhere in draw module to catch such mismatch in the future.
>>>
>>> For the record, there was a discussion on this when
>>> GL_EXT_provoking_vertex support was added to gallium:
>>> http://old.nabble.com/GL_EXT_provoking_vertex-and-GL_ARB_map_buffer_range-td23955481.html
>>>
>>> Jose
>>>
>>>
 Keith Whitwell wrote:
> Brian Paul wrote:
>> I've been working on these two extensions in my spare time.
>>
>> Each is on a temporary/feature branch in git:
>> ext-provoking-vertex
>> and arb_map_buffer_range
>>
>> Both are implemented for swrast and gallium.
>>
>> If you're interested in either or both take a look at the
>> branches and
>> let me know if there's any concerns.
>>
>> I'll merge to master in a few days otherwise.
> I should mention a few open issues with GL_EXT_provoking_vertex:
>
> 1. provoking vertex for lines isn't totally working yet for
> gallium/softpipe
>
> 2. Should there be a gallium PIPE_CAP query to determine if the
> gallium driver supports first-provoking-vertex, or should all
> drivers
> be expected to support it? I'm assuming the later at this point.
 Correct. Hardware that doesn't support first-vertex wouldn't
 support
 D3D -- there isn't much of that about... Typically we have to jump
 on
 hardware to make it support GL's provoking vertex.
> 3. The state tracker assumes that all gallium drivers support
> first-provoking-vertex for quads and quad strips too. This is
> actually an optional feature in the GL_EXT_provoking_vertex
> spec.
> Another PIPE_CAP query may be needed for that.
 There's probably no use-case for it -- the purpose of the
 extension
 is
 to match DX9's flatshading behaviour, but DX doesn't have QUAD
 primitives, so there is nothing to match...
 >From my point of view we could pick any one of:
 - all drivers are required to implement first-pv quads
 - all drivers are required not to
 - drivers can ignore first-pv for quad primitives, behaviour
 undefined
 I don't think it's worth adding a query/cap-bit for something like
 this
 (which no-one will use) - let's j

Re: [Mesa-dev] [PATCH] glsl: Fix optimization tests after converting src/glsl to automake.

[Paul Berry]

On 30 January 2012 20:08, Matt Turner  wrote:

> On Mon, Jan 30, 2012 at 10:28 PM, Paul Berry 
> wrote:
> > Commit 99476561 (automake: src/glsl and src/glsl/glcpp) changed the
> > build system so that src/glsl/glsl_test is not built by default.  This
> > inadvertently broke "make check", since the tests in
> > src/glsl/tests/lower_jumps (which are run by "make check") rely on
> > glsl_test.
> >
> > This patch ensures that "make check" builds glsl_test before running
> > any tests.
> > ---
> >  Makefile |1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 1fa369a..e593e7f 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -22,6 +22,7 @@ doxygen:
> >cd doxygen && $(MAKE)
> >
> >  check:
> > +   cd src/glsl && $(MAKE) check
>
> This will run the glcpp test suite as well. If you don't want to do
> that, you can just do
>
> cd src/glsl && $(MAKE) glsl_test
>
> Either way,
> Reviewed-by: Matt Turner 
>

Thanks, Matt.  Pushed.

BTW, I left the patch as "cd src/glsl && $(MAKE) check", since I'd prefer
to have "make check" run as many tests as possible.


>
> I'll fix this up in the next day or so so that src/glsl/Makefile.am
> will run these tests directly.
>
> Thanks for finding this Paul. I knew about glsl_test, but I hadn't
> seen how it was used.
>
> Matt
>
___
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

[Michel Dänzer]

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.
> 
> Signed-off-by: Simon Farnsworth 
[...] 
> diff --git a/src/gallium/drivers/r600/r600_pipe.c 
> b/src/gallium/drivers/r600/r600_pipe.c
> index c38fbc5..12c5bf5 100644
> --- a/src/gallium/drivers/r600/r600_pipe.c
> +++ b/src/gallium/drivers/r600/r600_pipe.c
> @@ -605,13 +604,10 @@ 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;

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.


> 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.


The rest looks good to me.


-- 
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] Do not use sched_yield() on Linux

[Alan Swanson]

As discussed back in 2003, sched_yield() on Linux is no longer
equivalent to other POSIX variations. From a LWN article; "This call
used to simply move the process to the end of the run queue; now it
moves the process to the "expired" queue, effectively cancelling the
rest of the process's time slice. So a process calling sched_yield() now
must wait until all other runnable processes in the system have used up
their time slices before it will get the processor again."

However its use on Linux has sneaked back in causing suboptimal
performance such as reported by Simon Farnsworth on r600g. Use sleep on
Linux instead.

Signed-off-by: Alan Swanson 
diff -ur mesa/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c mesa-killschedyield/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
--- mesa/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c	2011-09-19 11:53:16.0 +0100
+++ mesa-killschedyield/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c	2012-01-31 17:24:46.0 +
@@ -45,6 +45,7 @@
 #include "pipe/p_defines.h"
 #include "util/u_debug.h"
 #include "os/os_thread.h"
+#include "os/os_time.h"
 #include "util/u_memory.h"
 #include "util/u_double_list.h"
 
@@ -1009,8 +1010,10 @@
/* Wait on outstanding fences */
while (fenced_mgr->num_fenced) {
   pipe_mutex_unlock(fenced_mgr->mutex);
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS)
+#if defined(PIPE_OS_UNIX) && !defined(PIPE_OS_LINUX)
   sched_yield();
+#else
+  os_time_sleep(10);
 #endif
   pipe_mutex_lock(fenced_mgr->mutex);
   while(fenced_manager_check_signalled_locked(fenced_mgr, TRUE))
diff -ur mesa/src/gallium/drivers/nouveau/nouveau_fence.c mesa-killschedyield/src/gallium/drivers/nouveau/nouveau_fence.c
--- mesa/src/gallium/drivers/nouveau/nouveau_fence.c	2011-10-15 13:43:24.0 +0100
+++ mesa-killschedyield/src/gallium/drivers/nouveau/nouveau_fence.c	2012-01-31 17:28:09.0 +
@@ -21,6 +21,7 @@
  */
 
 #include "util/u_double_list.h"
+#include "os_os_time.h"
 
 #include "nouveau_screen.h"
 #include "nouveau_fence.h"
@@ -207,7 +208,11 @@
   spins++;
 #ifdef PIPE_OS_UNIX
   if (!(spins % 8)) /* donate a few cycles */
+#ifndef PIPE_OS_LINUX
  sched_yield();
+#else
+ os_time_sleep(10);
+#endif
 #endif
} while (spins < NOUVEAU_FENCE_MAX_SPINS);
 
diff -ur mesa/src/gallium/drivers/r600/r600_pipe.c mesa-killschedyield/src/gallium/drivers/r600/r600_pipe.c
--- mesa/src/gallium/drivers/r600/r600_pipe.c	2012-01-23 18:43:17.0 +
+++ mesa-killschedyield/src/gallium/drivers/r600/r600_pipe.c	2012-01-31 16:32:24.0 +
@@ -605,7 +605,7 @@
 	while (rscreen->fences.data[rfence->index] == 0) {
 		if (++spins % 256)
 			continue;
-#ifdef PIPE_OS_UNIX
+#if defined(PIPE_OS_UNIX) && !defined(PIPE_OS_LINUX)
 		sched_yield();
 #else
 		os_time_sleep(10);
diff -ur mesa/src/gallium/winsys/radeon/drm/radeon_drm_bo.c mesa-killschedyield/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
--- mesa/src/gallium/winsys/radeon/drm/radeon_drm_bo.c	2012-01-23 18:43:17.0 +
+++ mesa-killschedyield/src/gallium/winsys/radeon/drm/radeon_drm_bo.c	2012-01-31 17:26:23.0 +
@@ -33,6 +33,7 @@
 #include "util/u_double_list.h"
 #include "os/os_thread.h"
 #include "os/os_mman.h"
+#include "os/os_time.h"
 
 #include "state_tracker/drm_driver.h"
 
@@ -152,7 +153,11 @@
 struct radeon_bo *bo = get_radeon_bo(_buf);
 
 while (p_atomic_read(&bo->num_active_ioctls)) {
+#if defined(PIPE_OS_UNIX) && !defined(PIPE_OS_LINUX)
 sched_yield();
+#else
+os_time_sleep(10); 
+#endif
 }
 
 /* XXX use this when it's ready */
@@ -664,7 +669,11 @@
 }
 
 while (p_atomic_read(&bo->num_active_ioctls)) {
+#if defined(PIPE_OS_UNIX) && !defined(PIPE_OS_LINUX)
 sched_yield();
+#else
+os_time_sleep(10);
+#endif
 }
 
 if (microtiled == RADEON_LAYOUT_TILED)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Do not use sched_yield() on Linux

[Simon Farnsworth]

On Tuesday 31 January 2012, Alan Swanson  wrote:
> As discussed back in 2003, sched_yield() on Linux is no longer
> equivalent to other POSIX variations. From a LWN article; "This call
> used to simply move the process to the end of the run queue; now it
> moves the process to the "expired" queue, effectively cancelling the
> rest of the process's time slice. So a process calling sched_yield() now
> must wait until all other runnable processes in the system have used up
> their time slices before it will get the processor again."
> 
> However its use on Linux has sneaked back in causing suboptimal
> performance such as reported by Simon Farnsworth on r600g. Use sleep on
> Linux instead.
> 
> Signed-off-by: Alan Swanson 
>
I should note that I'm running my 3D app real-time (SCHED_RR) - the
performance pain I was facing is that I got to hog one CPU core waiting for
the GPU, while having several (three or four, typically) other processes
(SCHED_OTHER priority) waiting for free CPU time. As the E-350 is not
overblessed with CPU time in the first place, this hurt.

I've fixed my problem by a different route (in other patches sent to the
list); I no longer spin at all when waiting for fences to complete, instead
waiting for an interrupt from the GPU.

Having said that, I'll rebase your patch on top of my changes, and confirm
that it doesn't break things for me.
-- 
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] OSMesa glapi linlking

[Eric Anholt]

On Tue, 31 Jan 2012 10:50:51 -0500, "Kevin H. Hobbs"  wrote:
> On 01/31/2012 09:53 AM, Brian Paul wrote:
> > 
> > Kevin,
> > 
> > I just pushed a couple osmesa fixes to master and the 8.0 branch.  Can 
> > you give it a try?
> > 
> > Thinks seem to fix things on the 8.0 branch but I'm unable to verify 
> > on master due to some other regressions ATM.
> > 
> > -Brian
> > 
> 
> [kevin@bubbles mesa]$ git branch
> * 8.0
>   master
> [kevin@bubbles mesa]$ make
> make[1]: Entering directory `/home/kevin/mesa/src'
> Making sources for autoconf
> gmake[2]: Entering directory `/home/kevin/mesa/src/mapi/glapi'
> gmake[2]: Nothing to be done for `default'.
> gmake[2]: Leaving directory `/home/kevin/mesa/src/mapi/glapi'
> gmake[2]: Entering directory `/home/kevin/mesa/src/glsl'
> g++ -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp  -fPIC
> -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DHAVE_MINCORE
> -DHAVE_LIBUDEV -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0208
> -DFEATURE_GL=1 -fvisibility=hidden   -c -o glsl_lexer.o glsl_lexer.cc
> In file included from glsl_parser_extras.h:35:0,
>  from ast.h:30,
>  from glsl_lexer.ll:27:
> glsl_symbol_table.h:32:34: fatal error: program/symbol_table.h: No such
> file or directory
> compilation terminated.
> gmake[2]: *** [glsl_lexer.o] Error 1
> gmake[2]: Leaving directory `/home/kevin/mesa/src/glsl'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/home/kevin/mesa/src'
> make: *** [default] Error 1

I found this was due to the old build system picking up the new build
system's generated glsl_lexer.cc that was left in my tree, even though
the old build system doesn't mention that file.


pgpBXTD8N3d9o.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] undefined C++ GLSL symbol error

[Matt Turner]

On Tue, Jan 31, 2012 at 11:36 AM, Brian Paul  wrote:
> On 01/31/2012 08:32 AM, Matt Turner wrote:
>>
>> On Tue, Jan 31, 2012 at 9:32 AM, Matt Turner  wrote:
>>>
>>> On Tue, Jan 31, 2012 at 2:12 PM, Brian Paul  wrote:

 I just ran into this problem this morning.

 make realclean
 ./autogen.sh
 ./configure --disable-dri --enable-xlib-glx --enable-osmesa
 --enable-debug
 make

 The build appears to go fine, but when I try to run any GL app I get:

 glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1: undefined
 symbol: _ZN23ir_hierarchical_visitor5visitEP11ir_variable

 I haven't bisected yet to see if one of the recent GLSL changes is
 responsible...

 -Brian
>>>
>>>
>>> I can reproduce. I'll take a look.
>>>
>>> Thanks,
>>> Matt
>>
>>
>> Does this patch fix it for you?
>>
>> Matt
>
>
> $ make>log
> 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
>
> The build completes, but when I try to run anything:
>
> glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1: undefined
> symbol: _tnl_run_pipeline

I don't understand this -- I didn't touch src/mesa/drivers/x11, but
before automaking src/glsl it works and after it doesn't, so.

libGL.so before didn't have an undefined reference (ie, nm -C -D -g
gives 'U _tnl_run_pipeline') but after it does. In fact, before,
nothing seems to have a reference to _tnl_run_pipeline. If you build
libdricore.so, you can LD_PRELOAD it to work around this.

I'll keep looking.
Matt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r600g: Use new kernel interface to wait for fences

[Simon Farnsworth]

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 
---
This builds on top of the kernel interface I add in Message-Id:
<1328029169-12729-1-git-send-email-simon.farnswo...@onelan.co.uk> and
depends on libdrm's copy of radeon_drm.h being synced with the changes made
in that patch.

As with the kernel patch, I'm working atop Jerome's 2D tiling work, so this
may not apply to any current tree. I'm happy to rebase against another tree
on request, though.

 src/gallium/drivers/r600/r600_hw_context.c|2 +-
 src/gallium/drivers/r600/r600_pipe.c  |   12 +++-
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c |   35 +
 src/gallium/winsys/radeon/drm/radeon_winsys.h |   16 +++
 4 files changed, 56 insertions(+), 9 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..12c5bf5 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,13 +604,10 @@ 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;
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
@@ -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,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.

Re: [Mesa-dev] OSMesa glapi linlking

[Kevin H. Hobbs]

On 01/31/2012 11:14 AM, Matt Turner wrote:
> 
> You cannot change branches or bisect without running autogen.sh (and
> maybe git clean to be safe). I see glsl_lexer.cc in your log, which
> exists only in the master branch.
> 

Sorry, I left a lot out, but I can't be certain I did enough cleaning so :

$ ./mesa_thurough_cross_branch_build_check.sh > \
mesa_thurough_cross_branch_build_check.out 2>&1 &

http://crab-lab.zool.ohiou.edu/kevin/mesa_thurough_cross_branch_build_check.tar.bz2

Ackk gotta go...



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] dri: Add Unigine Tropics as an app that requires the GLSL warn workaround.

[Eugeni Dodonov]

On Mon, Jan 30, 2012 at 21:23, Eric Anholt  wrote:

> I wasn't seeing it be needed because of the previous bug.
> ---
>  src/mesa/drivers/dri/common/drirc |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>

For both patches:

Reviewed-by: Eugeni Dodonov 

-- 
Eugeni Dodonov

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] OSMesa glapi linlking

[Kevin DeKorte]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/31/2012 09:14 AM, Matt Turner wrote:
> On Tue, Jan 31, 2012 at 10:50 AM, Kevin H. Hobbs 
> wrote:
>> On 01/31/2012 09:53 AM, Brian Paul wrote:
>>> 
>>> Kevin,
>>> 
>>> I just pushed a couple osmesa fixes to master and the 8.0
>>> branch.  Can you give it a try?
>>> 
>>> Thinks seem to fix things on the 8.0 branch but I'm unable to
>>> verify on master due to some other regressions ATM.
>>> 
>>> -Brian
>>> 
>> 
>> [kevin@bubbles mesa]$ git branch * 8.0 master [kevin@bubbles
>> mesa]$ make make[1]: Entering directory `/home/kevin/mesa/src' 
>> Making sources for autoconf gmake[2]: Entering directory
>> `/home/kevin/mesa/src/mapi/glapi' gmake[2]: Nothing to be done
>> for `default'. gmake[2]: Leaving directory
>> `/home/kevin/mesa/src/mapi/glapi' gmake[2]: Entering directory
>> `/home/kevin/mesa/src/glsl' g++ -g -O2 -Wall -fno-strict-aliasing
>> -fno-builtin-memcmp  -fPIC -D_GNU_SOURCE -DPTHREADS
>> -DHAVE_POSIX_MEMALIGN -DHAVE_MINCORE -DHAVE_LIBUDEV
>> -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0208 -DFEATURE_GL=1
>> -fvisibility=hidden   -c -o glsl_lexer.o glsl_lexer.cc In file
>> included from glsl_parser_extras.h:35:0, from ast.h:30, from
>> glsl_lexer.ll:27: glsl_symbol_table.h:32:34: fatal error:
>> program/symbol_table.h: No such file or directory compilation
>> terminated. gmake[2]: *** [glsl_lexer.o] Error 1 gmake[2]:
>> Leaving directory `/home/kevin/mesa/src/glsl' make[1]: ***
>> [subdirs] Error 1 make[1]: Leaving directory
>> `/home/kevin/mesa/src' make: *** [default] Error 1
>> 
>> 
>> 
>> [kevin@bubbles mesa]$ git branch 8.0 * master [kevin@bubbles
>> mesa]$ make make[1]: Entering directory `/home/kevin/mesa/src' 
>> Making sources for autoconf gmake[2]: Entering directory
>> `/home/kevin/mesa/src/mapi/glapi' gmake[2]: Nothing to be done
>> for `default'. gmake[2]: Leaving directory
>> `/home/kevin/mesa/src/mapi/glapi' gmake[2]: Entering directory
>> `/home/kevin/mesa/src/glsl' gmake  all-recursive gmake[3]:
>> Entering directory `/home/kevin/mesa/src/glsl' Making all in
>> glcpp gmake[4]: Entering directory
>> `/home/kevin/mesa/src/glsl/glcpp' gmake  all-am gmake[5]:
>> Entering directory `/home/kevin/mesa/src/glsl/glcpp' CCLD
>> libglcpp.la ar: .libs/glcpp-lex.o: No such file or directory 
>> gmake[5]: *** [libglcpp.la] Error 1 gmake[5]: Leaving directory
>> `/home/kevin/mesa/src/glsl/glcpp' gmake[4]: *** [all] Error 2 
>> gmake[4]: Leaving directory `/home/kevin/mesa/src/glsl/glcpp' 
>> gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory
>> `/home/kevin/mesa/src/glsl' gmake[2]: *** [all] Error 2 gmake[2]:
>> Leaving directory `/home/kevin/mesa/src/glsl' make[1]: ***
>> [subdirs] Error 1 make[1]: Leaving directory
>> `/home/kevin/mesa/src' make: *** [default] Error 1
> 
> You cannot change branches or bisect without running autogen.sh
> (and maybe git clean to be safe). I see glsl_lexer.cc in your log,
> which exists only in the master branch. 
> ___ mesa-dev mailing
> list mesa-dev@lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

I think libglsl might not be being passed the linker flags..

I build with this setup that worked yesterday..

./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-32-bit
- --enable-gallium-llvm --enable-texture-float

I'm guessing it is not being passed the correct libpath. Because the
libaries should be coming from i686 rather than x86_64


CXXLD  libglsl.la
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-redhat-linux/4.6.2/libstdc++.so when searching for
- -lstdc++
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/libm.so when
searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/../lib64/libm.so when
searching for -lm
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/libc.so when
searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib64/libc.so when
searching for -lc
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-redhat-linux/4.6.2/libgcc_s.so when searching for
- -lgcc_s
/usr/bin/ld: i386:x86-64 architecture of input file
`/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/crti.o' is
incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file
`/usr/lib/gcc/x86_64-redhat-linux/4.6.2/crtbeginS.o' is incompatible
with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file
`/usr/lib/gcc/x86_64-redhat-linux/4.6.2/crtendS.o' is incompatible
with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file
`/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../lib64/crtn.o' is
incompatible with i386 output
collect2: ld returned 1 exit status
gmake[4]: *** [libglsl.la] Error 1
gmake[4

Re: [Mesa-dev] undefined C++ GLSL symbol error

[Brian Paul]

On 01/31/2012 08:32 AM, Matt Turner wrote:

On Tue, Jan 31, 2012 at 9:32 AM, Matt Turner  wrote:

On Tue, Jan 31, 2012 at 2:12 PM, Brian Paul  wrote:

I just ran into this problem this morning.

make realclean
./autogen.sh
./configure --disable-dri --enable-xlib-glx --enable-osmesa --enable-debug
make

The build appears to go fine, but when I try to run any GL app I get:

glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1: undefined
symbol: _ZN23ir_hierarchical_visitor5visitEP11ir_variable

I haven't bisected yet to see if one of the recent GLSL changes is
responsible...

-Brian


I can reproduce. I'll take a look.

Thanks,
Matt


Does this patch fix it for you?

Matt


$ make>log
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

The build completes, but when I try to run anything:

glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1: 
undefined symbol: _tnl_run_pipeline


And with lib/gallium/libGL:

glxinfo: symbol lookup error: /home/brian/mesa/lib/gallium/libGL.so.1: 
undefined symbol: st_gl_api_create


I started with make realclean, ./autogen.sh, etc.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VDPAU build fail since autoconf: Enable missing-prototypes errors when available.

[Christian König]

On 31.01.2012 17:22, Andy Furniss wrote:

I am getting a build fail with vdpau since

commit b9aab8b3b3769b9c5121686efe3446dae770b951
Author: Eric Anholt 
Date:   Thu Jan 26 18:48:20 2012 -0800

autoconf: Enable missing-prototypes errors when available.

After the removal of the dri driver link test, this should help avoid
the original problem that it was designed to catch: The warning about
a missing prototype due to typoing a function name scrolling by in 
the

Mesa build spew, and you not noticing until you try to run an
application and it falls back to swrast.


make[4]: Entering directory 
`/home/andy/Src/Mesa-git/mesa/src/gallium/state_trackers/vdpau'
gcc -c -I. -I../../../../src/gallium/include 
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers 
-I/home/andy/Src/Xorg-git/modular/include 
-I../../../../src/gallium/winsys/g3dvl 
-I/home/andy/Src/Xorg-git/modular/include -g -O2 -Wall -std=c99 
-Werror=implicit-function-declaration -Werror=missing-prototypes 
-fno-strict-aliasing -fno-builtin-memcmp -g -g -O2  -fPIC  
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM 
-D_GNU_SOURCE -DPTHREADS -DDEBUG -DTEXTURE_FLOAT_ENABLED 
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING 
-DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER 
-DHAVE_ALIAS -fvisibility=hidden -DVER_MAJOR=1 -DVER_MINOR=0  
preemption.c -o preemption.o
preemption.c:35: error: no previous prototype for 
'vlVdpPreemptionCallback'
preemption.c:45: error: no previous prototype for 
'vlVdpPreemptionCallbackRegister'

make[4]: *** [preemption.o] Error 1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Hi Andy,

fixed that in master a couple of minutes ago.

Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VDPAU build fail since autoconf: Enable missing-prototypes errors when available.

[Andy Furniss]

Andy Furniss wrote:

I am getting a build fail with vdpau since


I see it's fixed now.



commit b9aab8b3b3769b9c5121686efe3446dae770b951
Author: Eric Anholt 
Date: Thu Jan 26 18:48:20 2012 -0800

autoconf: Enable missing-prototypes errors when available.

After the removal of the dri driver link test, this should help avoid
the original problem that it was designed to catch: The warning about
a missing prototype due to typoing a function name scrolling by in the
Mesa build spew, and you not noticing until you try to run an
application and it falls back to swrast.


make[4]: Entering directory
`/home/andy/Src/Mesa-git/mesa/src/gallium/state_trackers/vdpau'
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I/home/andy/Src/Xorg-git/modular/include
-I../../../../src/gallium/winsys/g3dvl
-I/home/andy/Src/Xorg-git/modular/include -g -O2 -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-strict-aliasing -fno-builtin-memcmp -g -g -O2 -fPIC -DUSE_X86_ASM
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
-DDEBUG -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS
-fvisibility=hidden -DVER_MAJOR=1 -DVER_MINOR=0 preemption.c -o
preemption.o
preemption.c:35: error: no previous prototype for 'vlVdpPreemptionCallback'
preemption.c:45: error: no previous prototype for
'vlVdpPreemptionCallbackRegister'
make[4]: *** [preemption.o] Error 1

___
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

[Mesa-dev] VDPAU build fail since autoconf: Enable missing-prototypes errors when available.

[Andy Furniss]

I am getting a build fail with vdpau since

commit b9aab8b3b3769b9c5121686efe3446dae770b951
Author: Eric Anholt 
Date:   Thu Jan 26 18:48:20 2012 -0800

autoconf: Enable missing-prototypes errors when available.

After the removal of the dri driver link test, this should help avoid
the original problem that it was designed to catch: The warning about
a missing prototype due to typoing a function name scrolling by in the
Mesa build spew, and you not noticing until you try to run an
application and it falls back to swrast.


make[4]: Entering directory 
`/home/andy/Src/Mesa-git/mesa/src/gallium/state_trackers/vdpau'
gcc -c -I. -I../../../../src/gallium/include 
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers 
-I/home/andy/Src/Xorg-git/modular/include 
-I../../../../src/gallium/winsys/g3dvl 
-I/home/andy/Src/Xorg-git/modular/include -g -O2 -Wall -std=c99 
-Werror=implicit-function-declaration -Werror=missing-prototypes 
-fno-strict-aliasing -fno-builtin-memcmp -g -g -O2  -fPIC  -DUSE_X86_ASM 
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS 
-DDEBUG -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB 
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING 
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS 
-fvisibility=hidden -DVER_MAJOR=1 -DVER_MINOR=0  preemption.c -o 
preemption.o

preemption.c:35: error: no previous prototype for 'vlVdpPreemptionCallback'
preemption.c:45: error: no previous prototype for 
'vlVdpPreemptionCallbackRegister'

make[4]: *** [preemption.o] Error 1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] build errors and make distclean

[Andy Furniss]

Matt Turner wrote:

On Tue, Jan 31, 2012 at 6:18 AM, Andy Furniss  wrote:

I am getting a build error today - will have time later to investigate more.

I did notice, though that make distclean on head is not cleaning well enough
for me to git reset --hard back to somewhere that previously worked without
build errors.

I have to look at git status and manually clean up untracked eg.

rm -r bin/ylwrap src/glsl/.deps/ src/glsl/Makefile.in src/glsl/glcpp/.deps/
src/glsl/glcpp/Makefile src/glsl/glcpp/Makefile.in src/glsl/glsl_lexer.cc
src/glsl/glsl_parser.cc src/mesa/drivers/osmesa/.deps/
src/mesa/drivers/osmesa/Makefile.in

I assume this will break bisectability.


Mesa's top level Makefile simply runs `make clean` on subdirectories
and cleans up a .o and .a files for distclean.

Use `git clean -[dfx]` in the mean time?


Thanks, that's a lot quicker.

I expected that git bisect would clean by default, but anyway I found my 
problem.





___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] OSMesa glapi linlking

[Matt Turner]

On Tue, Jan 31, 2012 at 10:50 AM, Kevin H. Hobbs  wrote:
> On 01/31/2012 09:53 AM, Brian Paul wrote:
>>
>> Kevin,
>>
>> I just pushed a couple osmesa fixes to master and the 8.0 branch.  Can
>> you give it a try?
>>
>> Thinks seem to fix things on the 8.0 branch but I'm unable to verify
>> on master due to some other regressions ATM.
>>
>> -Brian
>>
>
> [kevin@bubbles mesa]$ git branch
> * 8.0
>  master
> [kevin@bubbles mesa]$ make
> make[1]: Entering directory `/home/kevin/mesa/src'
> Making sources for autoconf
> gmake[2]: Entering directory `/home/kevin/mesa/src/mapi/glapi'
> gmake[2]: Nothing to be done for `default'.
> gmake[2]: Leaving directory `/home/kevin/mesa/src/mapi/glapi'
> gmake[2]: Entering directory `/home/kevin/mesa/src/glsl'
> g++ -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp  -fPIC
> -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DHAVE_MINCORE
> -DHAVE_LIBUDEV -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0208
> -DFEATURE_GL=1 -fvisibility=hidden   -c -o glsl_lexer.o glsl_lexer.cc
> In file included from glsl_parser_extras.h:35:0,
>                 from ast.h:30,
>                 from glsl_lexer.ll:27:
> glsl_symbol_table.h:32:34: fatal error: program/symbol_table.h: No such
> file or directory
> compilation terminated.
> gmake[2]: *** [glsl_lexer.o] Error 1
> gmake[2]: Leaving directory `/home/kevin/mesa/src/glsl'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/home/kevin/mesa/src'
> make: *** [default] Error 1
>
>
>
> [kevin@bubbles mesa]$ git branch
>  8.0
> * master
> [kevin@bubbles mesa]$ make
> make[1]: Entering directory `/home/kevin/mesa/src'
> Making sources for autoconf
> gmake[2]: Entering directory `/home/kevin/mesa/src/mapi/glapi'
> gmake[2]: Nothing to be done for `default'.
> gmake[2]: Leaving directory `/home/kevin/mesa/src/mapi/glapi'
> gmake[2]: Entering directory `/home/kevin/mesa/src/glsl'
> gmake  all-recursive
> gmake[3]: Entering directory `/home/kevin/mesa/src/glsl'
> Making all in glcpp
> gmake[4]: Entering directory `/home/kevin/mesa/src/glsl/glcpp'
> gmake  all-am
> gmake[5]: Entering directory `/home/kevin/mesa/src/glsl/glcpp'
>  CCLD   libglcpp.la
> ar: .libs/glcpp-lex.o: No such file or directory
> gmake[5]: *** [libglcpp.la] Error 1
> gmake[5]: Leaving directory `/home/kevin/mesa/src/glsl/glcpp'
> gmake[4]: *** [all] Error 2
> gmake[4]: Leaving directory `/home/kevin/mesa/src/glsl/glcpp'
> gmake[3]: *** [all-recursive] Error 1
> gmake[3]: Leaving directory `/home/kevin/mesa/src/glsl'
> gmake[2]: *** [all] Error 2
> gmake[2]: Leaving directory `/home/kevin/mesa/src/glsl'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/home/kevin/mesa/src'
> make: *** [default] Error 1

You cannot change branches or bisect without running autogen.sh (and
maybe git clean to be safe). I see glsl_lexer.cc in your log, which
exists only in the master branch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45444] Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

[bugzilla-daemon]

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

--- Comment #3 from Christian König  2012-01-31 
08:13:54 PST ---
That was a one liner. Fix pushed to master.

Christian.

-- 
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 45444] Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

[bugzilla-daemon]

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

--- Comment #2 from Emeric Grange  2012-01-31 08:11:57 
PST ---
Seems like #include "vdpau_private.h" is missing inside
src/gallium/state_trackers/vdpau/preemption.c ?

-- 
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: Set the gl_array_object::ARBsemantics flag at the right time

[Ian Romanick]

From: Ian Romanick 

With 0963990 the flag was only set when Bind created the object.  In
all cases where ::ARBsemantics could be true, this path never
happened.  Instead, add a _Used flag to track whether a VAO has ever
been bound.  On the first Bind, set the _Used flag, and set the
ARBsemantics flag to the correct value.

NOTE: This is a candidate for release branches.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45423
---
 src/mesa/main/arrayobj.c |6 +-
 src/mesa/main/mtypes.h   |5 +
 2 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index d9ae187..c7584d9 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -373,6 +373,10 @@ bind_vertex_array(struct gl_context *ctx, GLuint id, 
GLboolean genRequired)
 return;
  }
 
+ save_array_object(ctx, newObj);
+  }
+
+  if (!newObj->_Used) {
  /* The "Interactions with APPLE_vertex_array_object" section of the
   * GL_ARB_vertex_array_object spec says:
   *
@@ -380,7 +384,7 @@ bind_vertex_array(struct gl_context *ctx, GLuint id, 
GLboolean genRequired)
   * BindVertexArrayAPPLE, determines the semantic of the object."
   */
  newObj->ARBsemantics = genRequired;
- save_array_object(ctx, newObj);
+ newObj->_Used = GL_TRUE;
   }
}
 
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index e8a9d42..5d9c7e8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1631,6 +1631,11 @@ struct gl_array_object
 */
GLboolean ARBsemantics;
 
+   /**
+* Has this array object been bound?
+*/
+   GLboolean _Used;
+
/** Vertex attribute arrays */
struct gl_client_array VertexAttrib[VERT_ATTRIB_MAX];
 
-- 
1.7.6.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45444] Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Christian König  2012-01-31 
08:04:00 PST ---
Already investigating, looks like somebody added "-Werror=missing-prototypes"
to the default mesa build options.

But currently even the gallium dri drivers won't compile for me.

-- 
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 45444] Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

[bugzilla-daemon]

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

Kevin DeKorte  changed:

   What|Removed |Added

 CC||deathsim...@vodafone.de

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45444] Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

[bugzilla-daemon]

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

Kevin DeKorte  changed:

   What|Removed |Added

 CC||emeric.gra...@gmail.com

-- 
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] OSMesa glapi linlking

[Kevin H. Hobbs]

On 01/31/2012 09:53 AM, Brian Paul wrote:
> 
> Kevin,
> 
> I just pushed a couple osmesa fixes to master and the 8.0 branch.  Can 
> you give it a try?
> 
> Thinks seem to fix things on the 8.0 branch but I'm unable to verify 
> on master due to some other regressions ATM.
> 
> -Brian
> 

[kevin@bubbles mesa]$ git branch
* 8.0
  master
[kevin@bubbles mesa]$ make
make[1]: Entering directory `/home/kevin/mesa/src'
Making sources for autoconf
gmake[2]: Entering directory `/home/kevin/mesa/src/mapi/glapi'
gmake[2]: Nothing to be done for `default'.
gmake[2]: Leaving directory `/home/kevin/mesa/src/mapi/glapi'
gmake[2]: Entering directory `/home/kevin/mesa/src/glsl'
g++ -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp  -fPIC
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DHAVE_MINCORE
-DHAVE_LIBUDEV -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0208
-DFEATURE_GL=1 -fvisibility=hidden   -c -o glsl_lexer.o glsl_lexer.cc
In file included from glsl_parser_extras.h:35:0,
 from ast.h:30,
 from glsl_lexer.ll:27:
glsl_symbol_table.h:32:34: fatal error: program/symbol_table.h: No such
file or directory
compilation terminated.
gmake[2]: *** [glsl_lexer.o] Error 1
gmake[2]: Leaving directory `/home/kevin/mesa/src/glsl'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/kevin/mesa/src'
make: *** [default] Error 1



[kevin@bubbles mesa]$ git branch
  8.0
* master
[kevin@bubbles mesa]$ make
make[1]: Entering directory `/home/kevin/mesa/src'
Making sources for autoconf
gmake[2]: Entering directory `/home/kevin/mesa/src/mapi/glapi'
gmake[2]: Nothing to be done for `default'.
gmake[2]: Leaving directory `/home/kevin/mesa/src/mapi/glapi'
gmake[2]: Entering directory `/home/kevin/mesa/src/glsl'
gmake  all-recursive
gmake[3]: Entering directory `/home/kevin/mesa/src/glsl'
Making all in glcpp
gmake[4]: Entering directory `/home/kevin/mesa/src/glsl/glcpp'
gmake  all-am
gmake[5]: Entering directory `/home/kevin/mesa/src/glsl/glcpp'
  CCLD   libglcpp.la
ar: .libs/glcpp-lex.o: No such file or directory
gmake[5]: *** [libglcpp.la] Error 1
gmake[5]: Leaving directory `/home/kevin/mesa/src/glsl/glcpp'
gmake[4]: *** [all] Error 2
gmake[4]: Leaving directory `/home/kevin/mesa/src/glsl/glcpp'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory `/home/kevin/mesa/src/glsl'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/kevin/mesa/src/glsl'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/kevin/mesa/src'
make: *** [default] Error 1



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering

[Kevin H. Hobbs]

On 01/31/2012 09:55 AM, Brian Paul wrote:
> On 01/30/2012 01:14 PM, Kevin H. Hobbs wrote:
>> 
>> The VTK tests have the same pattern of failures with the Fedora 15
>> OSMesa package as with the custom built OSMesa library, that is :
>>
>> The following tests FAILED:
>>  146 - TestTecplotReader (Failed)
>>  203 - TestMultiTexturing (SEGFAULT)
>>  204 - TestMultiTexturingTransform (SEGFAULT)
> 
> Have you filed bugs for these failures?
> 

I don't think so, maybe on VTK's end.

I haven't tested anything but master in a long time.

I've been too busy whining about master.


> I don't have time to download/test VTK so if you could at least 
> provide stack traces from gdb, that'd help.

As soon as master works I'll look at these again.



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] undefined C++ GLSL symbol error

[Matt Turner]

On Tue, Jan 31, 2012 at 9:32 AM, Matt Turner  wrote:
> On Tue, Jan 31, 2012 at 2:12 PM, Brian Paul  wrote:
>> I just ran into this problem this morning.
>>
>> make realclean
>> ./autogen.sh
>> ./configure --disable-dri --enable-xlib-glx --enable-osmesa --enable-debug
>> make
>>
>> The build appears to go fine, but when I try to run any GL app I get:
>>
>> glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1: undefined
>> symbol: _ZN23ir_hierarchical_visitor5visitEP11ir_variable
>>
>> I haven't bisected yet to see if one of the recent GLSL changes is
>> responsible...
>>
>> -Brian
>
> I can reproduce. I'll take a look.
>
> Thanks,
> Matt

Does this patch fix it for you?

Matt
diff --git a/configure.ac b/configure.ac
index 8af2456..0e03af7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -401,6 +401,7 @@ GLESv1_CM_LIB_NAME='lib$(GLESv1_CM_LIB).'${LIB_EXTENSION}
 GLESv2_LIB_NAME='lib$(GLESv2_LIB).'${LIB_EXTENSION}
 VG_LIB_NAME='lib$(VG_LIB).'${LIB_EXTENSION}
 GLAPI_LIB_NAME='lib$(GLAPI_LIB).'${LIB_EXTENSION}
+GLSL_LIB_NAME='libglsl.'${LIB_EXTENSION}
 
 GL_LIB_GLOB=${LIB_PREFIX_GLOB}'$(GL_LIB)'${LIB_VERSION_SEPARATOR}'*'${LIB_EXTENSION}'*'
 GLU_LIB_GLOB=${LIB_PREFIX_GLOB}'$(GLU_LIB)'${LIB_VERSION_SEPARATOR}'*'${LIB_EXTENSION}'*'
@@ -420,6 +421,7 @@ AC_SUBST([GLESv1_CM_LIB_NAME])
 AC_SUBST([GLESv2_LIB_NAME])
 AC_SUBST([VG_LIB_NAME])
 AC_SUBST([GLAPI_LIB_NAME])
+AC_SUBST([GLSL_LIB_NAME])
 
 AC_SUBST([GL_LIB_GLOB])
 AC_SUBST([GLU_LIB_GLOB])
diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index 0768890..aadbf41 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -368,7 +368,7 @@ COMMON_DRIVER_OBJECTS = $(COMMON_DRIVER_SOURCES:.c=.o)
 ### Other archives/libraries
 
 GLSL_LIBS = \
-	$(TOP)/src/glsl/libglsl.la
+	$(TOP)/src/glsl/.libs/$(GLSL_LIB_NAME)
 
 
 ### Include directories
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering

[Brian Paul]

On 01/30/2012 01:14 PM, Kevin H. Hobbs wrote:

On 01/30/2012 02:53 PM, Kevin H. Hobbs wrote:


I'm trying that now but you can give it a shot before then.



The VTK tests have the same pattern of failures with the Fedora 15
OSMesa package as with the custom built OSMesa library, that is :

The following tests FAILED:
 146 - TestTecplotReader (Failed)
 203 - TestMultiTexturing (SEGFAULT)
 204 - TestMultiTexturingTransform (SEGFAULT)


Have you filed bugs for these failures?

I don't have time to download/test VTK so if you could at least 
provide stack traces from gdb, that'd help.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] OSMesa glapi linlking

[Brian Paul]

On 01/30/2012 11:27 AM, Kevin H. Hobbs wrote:

On 01/30/2012 12:15 PM, Brian Paul wrote:

On 01/30/2012 08:56 AM, Kevin H. Hobbs wrote:


I tried with just the lines added manually and almost every VTK test
gives me:

osmesa.c:892: OSMesaMakeCurrent: Assertion `osmesa->srb->Base.RefCount
== 2' failed.


What happens if you remove that assertion?


The tests go really slowly, fail, and I get a bunch of these:

Start 155: TestGenericContourFilter
*** glibc detected ***
/home/kevin/kitware/VTK_OSMesa_Build/bin/GenericFilteringCxxTests:
double free or corruption (fasttop): 0x011da870 ***
=== Backtrace: =
/lib64/libc.so.6[0x3654076d63]
/home/kevin/mesa_osmesa/lib/libOSMesa.so.8(+0xa3cc0)[0x7f0dfd395cc0]
/home/kevin/mesa_osmesa/lib/libOSMesa.so.8(OSMesaMakeCurrent+0x112)[0x7f0dfd33be22]
/home/kevin/kitware/VTK_OSMesa_Build/bin/libvtkRendering.so.5.9(_ZN23vtkOSOpenGLRenderWindow11MakeCurrentEv+0x3b)[0x7f0e003392eb]

...



Kevin,

I just pushed a couple osmesa fixes to master and the 8.0 branch.  Can 
you give it a try?


Thinks seem to fix things on the 8.0 branch but I'm unable to verify 
on master due to some other regressions ATM.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] osmesa: Fix osmesa_context.DataType type.

[Brian Paul]

On 01/27/2012 11:36 PM, Vinson Lee wrote:

Fixes these GCC warnings.
osmesa.c: In function ‘osmesa_renderbuffer_storage’:
osmesa.c:417: warning: comparison is always false due to limited range of data 
type
osmesa.c:423: warning: comparison is always false due to limited range of data 
type
osmesa.c:431: warning: comparison is always false due to limited range of data 
type
osmesa.c:437: warning: comparison is always false due to limited range of data 
type
osmesa.c:447: warning: comparison is always false due to limited range of data 
type
osmesa.c:453: warning: comparison is always false due to limited range of data 
type
osmesa.c:463: warning: comparison is always false due to limited range of data 
type
osmesa.c:466: warning: comparison is always false due to limited range of data 
type
osmesa.c:476: warning: comparison is always false due to limited range of data 
type
osmesa.c:479: warning: comparison is always false due to limited range of data 
type

Signed-off-by: Vinson Lee
---
  src/mesa/drivers/osmesa/osmesa.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/osmesa/osmesa.c b/src/mesa/drivers/osmesa/osmesa.c
index 0a42741..0ec2d37 100644
--- a/src/mesa/drivers/osmesa/osmesa.c
+++ b/src/mesa/drivers/osmesa/osmesa.c
@@ -75,7 +75,7 @@ struct osmesa_context
 GLvoid *rowaddr[MAX_HEIGHT];   /*<  address of first pixel in each 
image row */
 GLboolean yup; /*<  TRUE  ->  Y increases upward */
/*<  FALSE ->  Y increases downward */
-   GLboolean DataType;
+   GLenum DataType;
  };



Vinson, I'm going to commit this.  It's definitely needed.

-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] undefined C++ GLSL symbol error

[Matt Turner]

On Tue, Jan 31, 2012 at 2:12 PM, Brian Paul  wrote:
> I just ran into this problem this morning.
>
> make realclean
> ./autogen.sh
> ./configure --disable-dri --enable-xlib-glx --enable-osmesa --enable-debug
> make
>
> The build appears to go fine, but when I try to run any GL app I get:
>
> glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1: undefined
> symbol: _ZN23ir_hierarchical_visitor5visitEP11ir_variable
>
> I haven't bisected yet to see if one of the recent GLSL changes is
> responsible...
>
> -Brian

I can reproduce. I'll take a look.

Thanks,
Matt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] undefined C++ GLSL symbol error

[Brian Paul]

On 01/31/2012 07:12 AM, Brian Paul wrote:

I just ran into this problem this morning.

make realclean
./autogen.sh
./configure --disable-dri --enable-xlib-glx --enable-osmesa
--enable-debug
make

The build appears to go fine, but when I try to run any GL app I get:

glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1:
undefined symbol: _ZN23ir_hierarchical_visitor5visitEP11ir_variable

I haven't bisected yet to see if one of the recent GLSL changes is
responsible...


Bisecting isn't working too well.  Compilation fails at intermediate 
steps with:


gmake[2]: Entering directory `/home/brian/mesa/src/glsl'
g++ -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp  -fPIC 
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_XSHM 
-DHAVE_MINCORE -DHAVE_LIBUDEV -D__STDC_CONSTANT_MACROS 
-DHAVE_LLVM=0x0300  -DFEATURE_GL=1 -fvisibility=hidden   -c -o 
glsl_lexer.o glsl_lexer.cc

In file included from glsl_parser_extras.h:35:0,
 from ast.h:30,
 from glsl_lexer.ll:27:
glsl_symbol_table.h:32:34: fatal error: program/symbol_table.h: No 
such file or directory

compilation terminated.
gmake[2]: *** [glsl_lexer.o] Error 1


Grrr.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45444] New: Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

[bugzilla-daemon]

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

 Bug #: 45444
   Summary: Compilation error with git
6386f80dbd6f1230abf16fa5ac65dc0dca70033a
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: kdeko...@yahoo.com


./autogen.sh --prefix=/usr --libdir=/usr/lib64 --with-dri-drivers=""
--with-gall
ium-drivers=r600,swrast --enable-gallium-egl --enable-openvg --enable-gles1
--en
able-gles2 --enable-texture-float --enable-vdpau --enable-xvmc --enable-osmesa
-
-enable-xorg --enable-texture-float

I get this error when compiling mesa today, it worked fine yesterday.


gmake[4]: Entering directory
`/home/kdekorte/git/mesa/src/gallium/state_trackers/vdpau'
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  
-I../../../../src/gallium/winsys/g3dvl -g -O2 -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-strict-aliasing -fno-builtin-memcmp -g -O2  -fPIC  -DUSE_X86_64_ASM
-D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN
-DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE
-DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN
-DHAVE_XEXTPROTO_71 -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209
-fvisibility=hidden -DVER_MAJOR=1 -DVER_MINOR=0  -I/usr/include   -D_GNU_SOURCE
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS preemption.c -o preemption.o
preemption.c:34:6: error: no previous prototype for ‘vlVdpPreemptionCallback’
[-Werror=missing-prototypes]
preemption.c:42:11: error: no previous prototype for
‘vlVdpPreemptionCallbackRegister’ [-Werror=missing-prototypes]
cc1: some warnings being treated as errors

-- 
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] undefined C++ GLSL symbol error

[Brian Paul]

I just ran into this problem this morning.

make realclean
./autogen.sh
./configure --disable-dri --enable-xlib-glx --enable-osmesa --enable-debug
make

The build appears to go fine, but when I try to run any GL app I get:

glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1: 
undefined symbol: _ZN23ir_hierarchical_visitor5visitEP11ir_variable


I haven't bisected yet to see if one of the recent GLSL changes is 
responsible...


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Help required in configuring mesa 3d in non X environment.

[Sanjoy Saha - ERS, HCL Tech]

Matt,
   I tried with --disable-glx option in autogen.sh line and I am still getting 
the same error. Below is the log output. The option --disable-glx is not 
recognized "configure: WARNING: unrecognized options: --disable-glx".
The mesa version I am using is mesa-7.11.


root@MPC8641HPCN:~/working/mesa-7.11# ./autogen.sh --enable-gallium-egl 
--with-egl-platforms=drm --enable-shared-glapi --with-gallium-drivers=r600 
--enable-gles1 --disable-glx
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
configure.ac:15: warning: AC_INIT: not a literal: 
https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
autoreconf: configure.ac: tracing
configure.ac:15: warning: AC_INIT: not a literal: 
https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
configure.ac:15: warning: AC_INIT: not a literal: 
https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
autoreconf: configure.ac: not using Autoheader
autoreconf: configure.ac: not using Automake
autoreconf: Leaving directory `.'
configure: WARNING: unrecognized options: --disable-glx
checking build system type... powerpc-unknown-linux-gnu
checking host system type... powerpc-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gmake... no
checking for make... make
checking for python2... no
checking for python... python
checking for makedepend... /usr/bin/makedepend
checking for sed... /bin/sed
checking for flex... /usr/bin/flex
checking for bison... /usr/bin/bison
checking for a BSD-compatible install... /usr/bin/install -c
checking if compiling with clang... no
checking whether gcc version is sufficient... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether gcc supports -fvisibility=hidden... yes
checking whether g++ supports -fvisibility=hidden... yes
checking whether to enable assembly... yes, ppc
checking for gcc option to produce PIC... -fPIC
checking for dlopen... no
checking for dlopen in -ldl... yes
checking for posix_memalign... yes
checking pkg-config files for X11 are available... no
checking for X... no
configure: error: X11 development libraries needed for dri driver



-Original Message-
From: Matt Turner [mailto:matts...@gmail.com]
Sent: Monday, January 30, 2012 9:08 PM
To: Sanjoy Saha - ERS, HCL Tech
Cc: Michel Dänzer; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] Help required in configuring mesa 3d in non X 
environment.

On Mon, Jan 30, 2012 at 1:46 AM, Sanjoy Saha - ERS, HCL Tech
 wrote:
> checking pkg-config files for X11 are available... no
> checking for X... no
> configure: error: X11 development libraries needed for GLX

I would try --disable-glx on the configure/autogen.sh line.

::DISCLAIMER::
---

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. 
Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the 
opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is 
strictly prohibited. If you have
received this email in error please delete it and notify the sender 
immediately. Before opening any mail and
attachments please check them for viruses and defect.

---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nv50: use larger arrays to silence warnings

[Brian Paul]

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

Re: [Mesa-dev] [PATCH] autoconf: Enable missing-prototypes errors when available.

[Jon TURNEY]

On 27/01/2012 19:58, Eric Anholt wrote:
> After the removal of the dri driver link test, this should help avoid
> the original problem that it was designed to catch: The warning about
> a missing prototype due to typoing a function name scrolling by in the
> Mesa build spew, and you not noticing until you try to run an
> application and it falls back to swrast.
> ---
>  configure.ac |   15 ++-
>  1 files changed, 14 insertions(+), 1 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 06d400f..0cd8421 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -176,7 +176,20 @@ esac
>  
>  dnl Add flags for gcc and g++
>  if test "x$GCC" = xyes; then
> -CFLAGS="$CFLAGS -Wall -Wmissing-prototypes -std=c99"
> +CFLAGS="$CFLAGS -Wall -std=c99"
> +
> +# Enable -Werror=implicit-function-declaration and
> +# -Werror=missing-prototypes, if available, or otherwise, just
> +# -Wmissing-prototypes.  This is particularly useful to avoid
> +# generating a loadable driver module that has undefined symbols.
> +save_CFLAGS="$CFLAGS"
> +AC_MSG_CHECKING([whether $CC supports -Werror=missing-prototypes])
> +CFLAGS="$CFLAGS -Werror=implicit-function-declaration"
> +CFLAGS="$CFLAGS -Werror=missing-prototypes"
> +AC_LINK_IFELSE([AC_LANG_PROGRAM()],
> +AC_MSG_RESULT([yes]),
> +[CFLAGS="$save_CFLAGS -Wmissing-prototypes";
> + AC_MSG_RESULT([no])]);
>  
>  # Enable -fvisibility=hidden if using a gcc that supports it
>  save_CFLAGS="$CFLAGS"

Looks like this change breaks compilation of the C dispatch code, see [1], [2].

In file included from glapi_dispatch.c:91:
../../../src/mapi/glapi/glapitemp.h:4641: error: no previous prototype for
'glDrawBuffersNV'


[1] http://tinderbox.freedesktop.org/builds/2012-01-31-0012/logs/libGL/#build
[2]
http://tinderbox.freedesktop.org/builds/2012-01-31-0012/logs/libGL-indirect-only/#build
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] build errors and make distclean

[Matt Turner]

On Tue, Jan 31, 2012 at 6:18 AM, Andy Furniss  wrote:
> I am getting a build error today - will have time later to investigate more.
>
> I did notice, though that make distclean on head is not cleaning well enough
> for me to git reset --hard back to somewhere that previously worked without
> build errors.
>
> I have to look at git status and manually clean up untracked eg.
>
> rm -r bin/ylwrap src/glsl/.deps/ src/glsl/Makefile.in src/glsl/glcpp/.deps/
> src/glsl/glcpp/Makefile src/glsl/glcpp/Makefile.in src/glsl/glsl_lexer.cc
> src/glsl/glsl_parser.cc src/mesa/drivers/osmesa/.deps/
> src/mesa/drivers/osmesa/Makefile.in
>
> I assume this will break bisectability.

Mesa's top level Makefile simply runs `make clean` on subdirectories
and cleans up a .o and .a files for distclean.

Use `git clean -[dfx]` in the mean time?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] build errors and make distclean

[Andy Furniss]

I am getting a build error today - will have time later to investigate more.

I did notice, though that make distclean on head is not cleaning well 
enough for me to git reset --hard back to somewhere that previously 
worked without build errors.


I have to look at git status and manually clean up untracked eg.

rm -r bin/ylwrap src/glsl/.deps/ src/glsl/Makefile.in 
src/glsl/glcpp/.deps/ src/glsl/glcpp/Makefile src/glsl/glcpp/Makefile.in 
src/glsl/glsl_lexer.cc src/glsl/glsl_parser.cc 
src/mesa/drivers/osmesa/.deps/ src/mesa/drivers/osmesa/Makefile.in


I assume this will break bisectability.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Rename R300_NO_TCL envvar to RADEON_NO_TCL

[Michel Dänzer]

On Mon, 2012-01-30 at 14:04 -0500, Matt Turner wrote: 
> The envvar works for R100 and R200 too, and the classic R300 driver
> doesn't even exist anymore.

RADEON_NO_TCL is kind of redundant for the radeon and r200 drivers,
which both support the driconf tcl_mode setting. (r200 also listens to
R200_NO_TCL...)


-- 
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

Re: [Mesa-dev] [PATCH 5/5] src/glsl/glcpp: wire up glcpp-test to make check

[Gaetan Nadon]

On 12-01-30 12:33 PM, Matt Turner wrote:
> On Mon, Jan 30, 2012 at 12:03 PM, Gaetan Nadon  wrote:
>> Sorry, I meant $(top_builddir)/src/glsl/glcpp or whatever the correct
>> location is.
> I don't understand -- I'm not seeing top_builddir or builddir defined
> in the execution of tests/glcpp-test.
>
ooops, I thought this code was in Makefile.am. It just happened that the
builddir variable name in glcpp-test is the same as the one in Makefile.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION

[Jose Fonseca]

I don't oppose adding the cap.

But I think that the story for draw module should be figured out, as at least 
nv50/nvc0 drivers will advertise 
PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION = 1 and are using the draw 
module:

$ git grep '\' src/gallium/drivers/
src/gallium/drivers/i915/i915_context.c:   i915->draw = 
draw_create(&i915->base);
src/gallium/drivers/nv50/nv50_context.c:   nv50->draw = draw_create(pipe);
src/gallium/drivers/nvc0/nvc0_context.c:   nvc0->draw = draw_create(pipe);
src/gallium/drivers/nvfx/nvfx_context.c:nvfx->draw = 
draw_create(&nvfx->pipe);
src/gallium/drivers/r300/r300_context.c:r300->draw = 
draw_create(&r300->context);
src/gallium/drivers/softpipe/sp_context.c:  softpipe->draw = 
draw_create(&softpipe->pipe);
src/gallium/drivers/svga/svga_swtnl_draw.c:   svga->swtnl.draw = 
draw_create(&svga->pipe);

Either:
- nv50/nvc0 continue to advertise 
PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION = 0
- nv50/nvc0 stop using draw module (at least for things that use software 
vertex processing or depend on flatshading)
- update draw module to respect 
PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION (as it does for triangles, 
but still a bit of work)
- wait for draw module to start using geometry shaders (where available) for 
its workarounds, where stuff like provoking vertex can be easily accommodated  
I think

Jose

- Original Message -
> BTW I am in favor of adding the CAP. r300 doesn't support the
> first-vertex convention for quads, but r600 does support it and it
> cannot be disabled for quads only. Because of that, the provoking
> vertex switch is currently part of the draw state instead of the
> rasterizer state in r600g. Adding the CAP will help move it back to
> the rasterizer state.
> 
> Of course, if we didn't have r600 and nv50 drivers, the CAP would be
> useless.
> 
> Marek
> 
> On Mon, Jan 30, 2012 at 5:59 PM, Jose Fonseca 
> wrote:
> > Note that unless the draw module is updated to take
> > PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION == 1 in
> > consideration this change will cause regressions for drivers that
> > fallback to draw module for doing things like clipping, unfilled
> > mode, etc w/ flat shadding.  Can this happen in practice?  If yes,
> > then I'm not sure if this is worth the trouble. If no, then please
> > add an assert(PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION ==
> > 0) somewhere in draw module to catch such mismatch in the future.
> >
> > For the record, there was a discussion on this when
> > GL_EXT_provoking_vertex support was added to gallium:
> > http://old.nabble.com/GL_EXT_provoking_vertex-and-GL_ARB_map_buffer_range-td23955481.html
> >
> > Jose
> >
> >
> >> Keith Whitwell wrote:
> >> > Brian Paul wrote:
> >> > > I've been working on these two extensions in my spare time.
> >> > >
> >> > > Each is on a temporary/feature branch in git:
> >> > > ext-provoking-vertex
> >> > > and arb_map_buffer_range
> >> > >
> >> > > Both are implemented for swrast and gallium.
> >> > >
> >> > > If you're interested in either or both take a look at the
> >> > > branches and
> >> > > let me know if there's any concerns.
> >> > >
> >> > > I'll merge to master in a few days otherwise.
> >> >
> >> > I should mention a few open issues with GL_EXT_provoking_vertex:
> >> >
> >> > 1. provoking vertex for lines isn't totally working yet for
> >> > gallium/softpipe
> >> >
> >> > 2. Should there be a gallium PIPE_CAP query to determine if the
> >> > gallium driver supports first-provoking-vertex, or should all
> >> > drivers
> >> > be expected to support it? I'm assuming the later at this point.
> >
> >> Correct. Hardware that doesn't support first-vertex wouldn't
> >> support
> >> D3D -- there isn't much of that about... Typically we have to jump
> >> on
> >> hardware to make it support GL's provoking vertex.
> >
> >> > 3. The state tracker assumes that all gallium drivers support
> >> > first-provoking-vertex for quads and quad strips too. This is
> >> > actually an optional feature in the GL_EXT_provoking_vertex
> >> > spec.
> >> > Another PIPE_CAP query may be needed for that.
> >
> >> There's probably no use-case for it -- the purpose of the
> >> extension
> >> is
> >> to match DX9's flatshading behaviour, but DX doesn't have QUAD
> >> primitives, so there is nothing to match...
> >
> >> >From my point of view we could pick any one of:
> >> - all drivers are required to implement first-pv quads
> >> - all drivers are required not to
> >> - drivers can ignore first-pv for quad primitives, behaviour
> >> undefined
> >
> >> I don't think it's worth adding a query/cap-bit for something like
> >> this
> >> (which no-one will use) - let's just pick a behaviour and make it
> >> universal.
> >
> >> Keith
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
___
me

[Mesa-dev] [Bug 45420] undefined reference to `LLVMInitializeARMDisassembler'

[bugzilla-daemon]

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

José Fonseca  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from José Fonseca  2012-01-31 00:37:32 PST 
---
Pushed. Thanks.

-- 
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