Re: [Mesa-dev] [PATCH] vbo: introduce vbo_get_minmax_indices function

2012-01-11 Thread Yuanhan Liu
On Tue, Jan 10, 2012 at 08:43:18PM -0700, Brian Paul wrote:
 On Tue, Jan 3, 2012 at 8:59 PM, Yuanhan Liu yuanhan@linux.intel.com 
 wrote:
  On Wed, Jan 04, 2012 at 11:20:07AM +0800, Yuanhan Liu wrote:
  On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:
   Ah index scanning...
   I don't like that this will map/unmap the ib once for each prim,
  Me either :)
 
   though
[snip]..
  +vbo_get_minmax_indices(struct gl_context *ctx,
  +                       const struct _mesa_prim *prims,
  +                       const struct _mesa_index_buffer *ib,
  +                       GLuint *min_index,
  +                       GLuint *max_index,
  +                       GLuint nr_prims)
  +{
  +   struct _mesa_prim start_prim;
 
 I think you could use a pointer for start_prim:
 
 const struct _mesa_prim *start_prim;
 
 to avoid copying 20 bytes per loop iteration below.  The declaration
 could also be moved inside the loop.

Aha, yes. I should do this. Thanks, here is the updated patch:

From 66f309648a20736c932eb1d393ca7cad6679532a Mon Sep 17 00:00:00 2001
From: Yuanhan Liu yuanhan@linux.intel.com
Date: Sat, 31 Dec 2011 14:22:46 +0800
Subject: [PATCH] vbo: introduce vbo_get_minmax_indices function

Introduce vbo_get_minmax_indices() function to handle the min/max index
computation for nr_prims(= 1). The old code just compute the first
prim's min/max index; this would results an error rendering if user
called functions like glMultiDrawElements(). This patch servers as
fixing this issue.

As when nr_prims = 1, we can pass 1 to paramter nr_prims, thus I made
vbo_get_minmax_index() static.

v2: per Roland's suggestion, put the indices address compuation into
vbo_get_minmax_index() instead.

Also do comination if possible to reduce map/unmap count

v3: per Brian's suggestion, use a pointer for start_prim to avoid
structure copy per loop.

Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
Reviewed-by: Roland Scheidegger srol...@vmware.com
Reviewed-by: Brian Paul bri...@vmware.com
---
 src/mesa/drivers/dri/i965/brw_draw.c |2 +-
 src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c |3 +-
 src/mesa/main/api_validate.c |2 +-
 src/mesa/state_tracker/st_draw.c |3 +-
 src/mesa/state_tracker/st_draw_feedback.c|2 +-
 src/mesa/tnl/t_draw.c|2 +-
 src/mesa/vbo/vbo.h   |6 ++--
 src/mesa/vbo/vbo_exec_array.c|   50 +
 8 files changed, 53 insertions(+), 17 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 621195d..f50fffd 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -586,7 +586,7 @@ void brw_draw_prims( struct gl_context *ctx,
 
if (!vbo_all_varyings_in_vbos(arrays)) {
   if (!index_bounds_valid)
-vbo_get_minmax_index(ctx, prim, ib, min_index, max_index);
+vbo_get_minmax_indices(ctx, prim, ib, min_index, max_index, 
nr_prims);
 
   /* Decide if we want to rebase.  If so we end up recursing once
* only into this function.
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c 
b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
index de04d18..59f1542 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
@@ -437,7 +437,8 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
struct nouveau_render_state *render = to_render_state(ctx);
 
if (!index_bounds_valid)
-   vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+   vbo_get_minmax_indices(ctx, prims, ib, min_index, max_index,
+  nr_prims);
 
vbo_choose_render_mode(ctx, arrays);
vbo_choose_attrs(ctx, arrays);
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 945f127..b6871d0 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -184,7 +184,7 @@ check_index_bounds(struct gl_context *ctx, GLsizei count, 
GLenum type,
ib.ptr = indices;
ib.obj = ctx-Array.ArrayObj-ElementArrayBufferObj;
 
-   vbo_get_minmax_index(ctx, prim, ib, min, max);
+   vbo_get_minmax_indices(ctx, prim, ib, min, max, 1);
 
if ((int)(min + basevertex)  0 ||
max + basevertex  ctx-Array.ArrayObj-_MaxElement) {
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 6d6fc85..c0554cf 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -990,7 +990,8 @@ st_draw_vbo(struct gl_context *ctx,
   /* Gallium probably doesn't want this in some cases. */
   if (!index_bounds_valid)
  if (!all_varyings_in_vbos(arrays))
-vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+vbo_get_minmax_indices(ctx, prims, ib, min_index, max_index,
+   

[Mesa-dev] [PATCH 1/3] i965: Move loop over texture units into brw_populate_sampler_prog_key.

2012-01-11 Thread Kenneth Graunke
The whole reason I avoided this was because it might operate on a
brw_vertex_program or a brw_fragment_program.  However, that isn't a
problem: all we need is the gl_program base type.

This avoids awkwardly passing the loop counter 'i' as a parameter,
simplifies both callers, and most importantly, plumbs prog in place for
use in the next commit.

Cc: Eric Anholt e...@anholt.net
Cc: Ian Romanick i...@freedesktop.org
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_program.h |3 +-
 src/mesa/drivers/dri/i965/brw_vs.c  |5 +-
 src/mesa/drivers/dri/i965/brw_wm.c  |  160 ---
 3 files changed, 84 insertions(+), 84 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index a2698cf..5fe5202 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -55,6 +55,7 @@ struct brw_sampler_prog_key_data {
 };
 
 void brw_populate_sampler_prog_key_data(struct gl_context *ctx,
-   struct brw_sampler_prog_key_data *key, 
int i);
+   struct gl_program *prog,
+   struct brw_sampler_prog_key_data *key);
 
 #endif
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
b/src/mesa/drivers/dri/i965/brw_vs.c
index 7fc7dcc..c9fcea8 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -322,10 +322,7 @@ static void brw_upload_vs_prog(struct brw_context *brw)
}
 
/* _NEW_TEXTURE */
-   for (i = 0; i  BRW_MAX_TEX_UNIT; i++) {
-  if (prog-TexturesUsed[i])
-brw_populate_sampler_prog_key_data(ctx, key.tex, i);
-   }
+   brw_populate_sampler_prog_key_data(ctx, prog, key.tex);
 
/* BRW_NEW_VERTICES */
for (i = 0; i  VERT_ATTRIB_MAX; i++) {
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c 
b/src/mesa/drivers/dri/i965/brw_wm.c
index cad0af8..cbf9e23 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -322,86 +322,91 @@ bool do_wm_prog(struct brw_context *brw,
 
 void
 brw_populate_sampler_prog_key_data(struct gl_context *ctx,
-  struct brw_sampler_prog_key_data *key,
-  int i)
+  struct gl_program *prog,
+  struct brw_sampler_prog_key_data *key)
 {
-   const struct gl_texture_unit *unit = ctx-Texture.Unit[i];
-
-   if (unit-_ReallyEnabled) {
-  const struct gl_texture_object *t = unit-_Current;
-  const struct gl_texture_image *img = t-Image[0][t-BaseLevel];
-  struct gl_sampler_object *sampler = _mesa_get_samplerobj(ctx, i);
-  int swizzles[SWIZZLE_NIL + 1] = {
-SWIZZLE_X,
-SWIZZLE_Y,
-SWIZZLE_Z,
-SWIZZLE_W,
-SWIZZLE_ZERO,
-SWIZZLE_ONE,
-SWIZZLE_NIL
-  };
-
-  if (img-_BaseFormat == GL_DEPTH_COMPONENT ||
- img-_BaseFormat == GL_DEPTH_STENCIL) {
-if (sampler-CompareMode == GL_COMPARE_R_TO_TEXTURE_ARB)
-   key-compare_funcs[i] = sampler-CompareFunc;
-
-/* We handle GL_DEPTH_TEXTURE_MODE here instead of as surface format
- * overrides because shadow comparison always returns the result of
- * the comparison in all channels anyway.
- */
-switch (sampler-DepthMode) {
-case GL_ALPHA:
-   swizzles[0] = SWIZZLE_ZERO;
-   swizzles[1] = SWIZZLE_ZERO;
-   swizzles[2] = SWIZZLE_ZERO;
-   swizzles[3] = SWIZZLE_X;
-   break;
-case GL_LUMINANCE:
-   swizzles[0] = SWIZZLE_X;
-   swizzles[1] = SWIZZLE_X;
-   swizzles[2] = SWIZZLE_X;
-   swizzles[3] = SWIZZLE_ONE;
-   break;
-case GL_INTENSITY:
-   swizzles[0] = SWIZZLE_X;
-   swizzles[1] = SWIZZLE_X;
-   swizzles[2] = SWIZZLE_X;
-   swizzles[3] = SWIZZLE_X;
-   break;
-case GL_RED:
-   swizzles[0] = SWIZZLE_X;
-   swizzles[1] = SWIZZLE_ZERO;
-   swizzles[2] = SWIZZLE_ZERO;
-   swizzles[3] = SWIZZLE_ONE;
-   break;
+   for (int i = 0; i  BRW_MAX_TEX_UNIT; i++) {
+  if (!prog-TexturesUsed[i])
+continue;
+
+  const struct gl_texture_unit *unit = ctx-Texture.Unit[i];
+
+  if (unit-_ReallyEnabled) {
+const struct gl_texture_object *t = unit-_Current;
+const struct gl_texture_image *img = t-Image[0][t-BaseLevel];
+struct gl_sampler_object *sampler = _mesa_get_samplerobj(ctx, i);
+int swizzles[SWIZZLE_NIL + 1] = {
+   SWIZZLE_X,
+   SWIZZLE_Y,
+   SWIZZLE_Z,
+   SWIZZLE_W,
+   SWIZZLE_ZERO,
+   SWIZZLE_ONE,
+   SWIZZLE_NIL
+};
+
+if (img-_BaseFormat == GL_DEPTH_COMPONENT ||
+img-_BaseFormat == GL_DEPTH_STENCIL) {
+   if 

[Mesa-dev] [PATCH 2/3] i965: Store the SamplerUnits array in the program cache key.

2012-01-11 Thread Kenneth Graunke
Since sampler unit information is encoded inside the sampler SEND
instruction, we need to create specialized shaders for different values
of the SamplerUnits array.  In particular, we need to recompile whenever
SamplerUnits changes.

This is exactly what the program keys are for: when we need to get a
shader, we populate the program key with the current state, and use it
to look up in the program cache.  If we haven't seen it before, we'll
compile a new variant.  Otherwise, we'll return the cached copy.

To make this work, add the _NEW_PROGRAM dirty bit to the brw_vs_prog and
brw_wm_prog tracked state atoms, since it's required for us to be
notified when SamplerUnits changes.

This patch should not have any functional change, as we were already
recompiling when this changed via a much uglier mechanism which will be
removed in the next commit.

Cc: Eric Anholt e...@anholt.net
Cc: Ian Romanick i...@freedesktop.org
Cc: Marek Olšák mar...@gmail.com
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |2 +-
 src/mesa/drivers/dri/i965/brw_program.h|6 ++
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |2 +-
 src/mesa/drivers/dri/i965/brw_vs.c |1 +
 src/mesa/drivers/dri/i965/brw_wm.c |4 
 src/mesa/drivers/dri/i965/brw_wm_fp.c  |4 ++--
 6 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 44c9ee8..b4f7977 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1063,7 +1063,7 @@ fs_visitor::visit(ir_texture *ir)
fs_inst *inst = NULL;
 
int sampler = _mesa_get_sampler_uniform_value(ir-sampler, prog, fp-Base);
-   sampler = fp-Base.SamplerUnits[sampler];
+   sampler = c-key.tex.SamplerUnits[sampler];
 
/* Our hardware doesn't have a sample_d_c message, so shadow compares
 * for textureGrad/TXD need to be emulated with instructions.
diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index 5fe5202..f2ee431 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -29,6 +29,12 @@
  */
 struct brw_sampler_prog_key_data {
/**
+* A map from sampler unit to texture unit (set by glUniform1i()).
+* This is a copy of gl_program::SamplerUnits.
+*/
+   unsigned char SamplerUnits[MAX_SAMPLERS];
+
+   /**
 * Per-sampler comparison functions:
 *
 * If comparison mode is GL_COMPARE_R_TO_TEXTURE, then this is set to one
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 20da487..ba1e446 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1757,7 +1757,7 @@ void
 vec4_visitor::visit(ir_texture *ir)
 {
int sampler = _mesa_get_sampler_uniform_value(ir-sampler, prog, vp-Base);
-   sampler = vp-Base.SamplerUnits[sampler];
+   sampler = c-key.tex.SamplerUnits[sampler];
 
/* Should be lowered by do_lower_texture_projection */
assert(!ir-projector);
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
b/src/mesa/drivers/dri/i965/brw_vs.c
index c9fcea8..a258075 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -349,6 +349,7 @@ static void brw_upload_vs_prog(struct brw_context *brw)
 const struct brw_tracked_state brw_vs_prog = {
.dirty = {
   .mesa  = (_NEW_TRANSFORM | _NEW_POLYGON | _NEW_POINT | _NEW_LIGHT |
+   _NEW_PROGRAM |
_NEW_TEXTURE |
_NEW_BUFFERS),
   .brw   = (BRW_NEW_VERTEX_PROGRAM |
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c 
b/src/mesa/drivers/dri/i965/brw_wm.c
index cbf9e23..f6f87ae 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -325,6 +325,9 @@ brw_populate_sampler_prog_key_data(struct gl_context *ctx,
   struct gl_program *prog,
   struct brw_sampler_prog_key_data *key)
 {
+   /* _NEW_PROGRAM | _NEW_TEXTURE */
+   memcpy(key-SamplerUnits, prog-SamplerUnits, sizeof(key-SamplerUnits));
+
for (int i = 0; i  BRW_MAX_TEX_UNIT; i++) {
   if (!prog-TexturesUsed[i])
 continue;
@@ -563,6 +566,7 @@ const struct brw_tracked_state brw_wm_prog = {
_NEW_LIGHT |
_NEW_FRAG_CLAMP |
_NEW_BUFFERS |
+   _NEW_PROGRAM |
_NEW_TEXTURE),
   .brw   = (BRW_NEW_FRAGMENT_PROGRAM |
BRW_NEW_WM_INPUT_DIMENSIONS |
diff --git a/src/mesa/drivers/dri/i965/brw_wm_fp.c 
b/src/mesa/drivers/dri/i965/brw_wm_fp.c
index 1358e74..3975699 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_fp.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_fp.c
@@ -664,7 +664,7 @@ static void precalc_tex( struct brw_wm_compile *c,
  

[Mesa-dev] [PATCH 3/3] mesa: Stop calling ProgramStringNotify when SamplerUnits changes.

2012-01-11 Thread Kenneth Graunke
This rather rudely told the driver the moral equivalent of Your shader
code changed in an unimaginable way---don't assume anything; recompile!

The i965 driver used to rely on this in order to recompile the program
when SamplerUnits changed.  It now properly listens to _NEW_PROGRAM and
_NEW_TEXTURE, which this code flags, and does the right thing.

According to Marek, st/mesa doesn't need nor want a ProgramStringNotify
here.  The classic radeon, r200, and nouveau drivers don't use the
SamplerUnits array, so they should be unaffected.

(Unfortunately I think i915 may still rely on this :( Ian/Eric, can you
 confirm or deny that?  It doesn't seem to have any of the program
 caching, which seems rather horrible...)

Cc: Eric Anholt e...@anholt.net
Cc: Ian Romanick i...@freedesktop.org
Cc: Marek Olšák mar...@gmail.com
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/main/uniform_query.cpp |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

This has survived a piglit run on Sandybridge, as well as basic openarena
and Cogs functionality.  It hasn't received testing on other platforms.

diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index f3d6a16..8c96117 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -729,7 +729,6 @@ _mesa_uniform(struct gl_context *ctx, struct 
gl_shader_program *shProg,
   sizeof(shProg-SamplerUnits));
 
_mesa_update_shader_textures_used(prog);
-   (void) ctx-Driver.ProgramStringNotify(ctx, prog-Target, prog);
 }
   }
}
-- 
1.7.7.5

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


[Mesa-dev] Gen7 HiZ regression

2012-01-11 Thread Kenneth Graunke

Hi Chad,

I tracked down the Gen7 HiZ regression a little bit.  It turns out it 
isn't HiZ, since


$ INTEL_HIZ=0 ./bin/fbo-clear-formats GL_ARB_depth_texture

still fails.  However, reverting commit bebc91f0f3a1f2d19d36a7
(i965: Replace references to stencil region size with buffer size) fixes 
the test.  (You also have to revert 254b24f195110 so it compiles.)


I'll leave it to you to figure out why...

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


[Mesa-dev] [Bug 44666] New: softpipe_screen struct member typos

2012-01-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44666

 Bug #: 44666
   Summary: softpipe_screen struct member typos
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: All
OS/Version: All
Status: NEW
  Severity: minor
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: elbeardmo...@msn.com


two instances of 'use_llvm' exist in sp_screen.c which should be 'using_llvm'
(as per the struct def). these interrupted my build

-- 
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 44666] softpipe_screen struct member typos

2012-01-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44666

--- Comment #2 from Dave Airlie airl...@freedesktop.org 2012-01-11 02:54:51 
UTC ---
already fixed in master.

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


Re: [Mesa-dev] [PATCH 3/3] mesa: Stop calling ProgramStringNotify when SamplerUnits changes.

2012-01-11 Thread Marek Olšák
I actually made this change locally when I found the issue with shader
recompilations, so this is:

Tested-by: Marek Olšák mar...@gmail.com

On Wed, Jan 11, 2012 at 10:55 AM, Kenneth Graunke kenn...@whitecape.org wrote:
 This rather rudely told the driver the moral equivalent of Your shader
 code changed in an unimaginable way---don't assume anything; recompile!

 The i965 driver used to rely on this in order to recompile the program
 when SamplerUnits changed.  It now properly listens to _NEW_PROGRAM and
 _NEW_TEXTURE, which this code flags, and does the right thing.

 According to Marek, st/mesa doesn't need nor want a ProgramStringNotify
 here.  The classic radeon, r200, and nouveau drivers don't use the
 SamplerUnits array, so they should be unaffected.

 (Unfortunately I think i915 may still rely on this :( Ian/Eric, can you
  confirm or deny that?  It doesn't seem to have any of the program
  caching, which seems rather horrible...)

 Cc: Eric Anholt e...@anholt.net
 Cc: Ian Romanick i...@freedesktop.org
 Cc: Marek Olšák mar...@gmail.com
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
  src/mesa/main/uniform_query.cpp |    1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

 This has survived a piglit run on Sandybridge, as well as basic openarena
 and Cogs functionality.  It hasn't received testing on other platforms.

 diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
 index f3d6a16..8c96117 100644
 --- a/src/mesa/main/uniform_query.cpp
 +++ b/src/mesa/main/uniform_query.cpp
 @@ -729,7 +729,6 @@ _mesa_uniform(struct gl_context *ctx, struct 
 gl_shader_program *shProg,
                   sizeof(shProg-SamplerUnits));

            _mesa_update_shader_textures_used(prog);
 -           (void) ctx-Driver.ProgramStringNotify(ctx, prog-Target, prog);
         }
       }
    }
 --
 1.7.7.5

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


[Mesa-dev] [PATCH] i965: Don't reallocate push constant URB space on new VS programs.

2012-01-11 Thread Kenneth Graunke
The gen7_urb atom depends on CACHE_NEW_VS_PROG and CACHE_NEW_GS_PROG,
causing gen7_upload_urb() to be called when switching to a new VS
program.

In addition to partitioning the URB space between the VS and GS,
gen7_upload_urb() also allocated space for VS and PS push constants.
Unfortunately, this meant that whenever CACHE_NEW_VS was flagged, we'd
reallocate the space for the PS push constants.  This appears to trash
the PS push constants until the next 3DSTATE_CONSTANT_PS packet.

Since our URB allocation for push constants is entirely static, it makes
sense to split it out into its own atom that only subscribes to
BRW_NEW_CONTEXT.  This avoids reallocating the space and trashing
constants.

Fixes a rendering artifact in Extreme Tuxracer, where instead of a snow
trail, you'd get a bright red streak (affectionately known as the
bloody penguin bug).

This also explains why adding VS-related dirty bits to gen7_ps_state
made the problem disappear: it made 3DSTATE_CONSTANT_PS be emitted after
every 3DSTATE_PUSH_CONSTANT_ALLOC_PS packet.

NOTE: This is a candidate for the 7.11 and 8.0 branches.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38868
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_state.h|1 +
 src/mesa/drivers/dri/i965/brw_state_upload.c |1 +
 src/mesa/drivers/dri/i965/gen7_urb.c |   34 ++---
 3 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
b/src/mesa/drivers/dri/i965/brw_state.h
index fcfe79f..2dd5665 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -110,6 +110,7 @@ extern const struct brw_tracked_state gen7_clip_state;
 extern const struct brw_tracked_state gen7_depth_stencil_state_pointer;
 extern const struct brw_tracked_state gen7_disable_stages;
 extern const struct brw_tracked_state gen7_ps_state;
+extern const struct brw_tracked_state gen7_push_constant_alloc;
 extern const struct brw_tracked_state gen7_samplers;
 extern const struct brw_tracked_state gen7_sbe_state;
 extern const struct brw_tracked_state gen7_sf_clip_viewport;
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index c7b796c..d071f87 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -188,6 +188,7 @@ const struct brw_tracked_state *gen7_atoms[] =
 
/* Command packets: */
brw_invariant_state,
+   gen7_push_constant_alloc,
 
/* must do before binding table pointers, cc state ptrs */
brw_state_base_address,
diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c 
b/src/mesa/drivers/dri/i965/gen7_urb.c
index e53fcb7..e6cf1eb 100644
--- a/src/mesa/drivers/dri/i965/gen7_urb.c
+++ b/src/mesa/drivers/dri/i965/gen7_urb.c
@@ -51,6 +51,30 @@
  * See Volume 2a: 3D Pipeline, section 1.8.
  */
 static void
+gen7_allocate_push_constants(struct brw_context *brw)
+{
+   struct intel_context *intel = brw-intel;
+   BEGIN_BATCH(2);
+   OUT_BATCH(_3DSTATE_PUSH_CONSTANT_ALLOC_VS  16 | (2 - 2));
+   OUT_BATCH(8);
+   ADVANCE_BATCH();
+
+   BEGIN_BATCH(2);
+   OUT_BATCH(_3DSTATE_PUSH_CONSTANT_ALLOC_PS  16 | (2 - 2));
+   OUT_BATCH(8 | 8  GEN7_PUSH_CONSTANT_BUFFER_OFFSET_SHIFT);
+   ADVANCE_BATCH();
+}
+
+const struct brw_tracked_state gen7_push_constant_alloc = {
+   .dirty = {
+  .mesa = 0,
+  .brw = BRW_NEW_CONTEXT,
+  .cache = 0,
+   },
+   .emit = gen7_allocate_push_constants,
+};
+
+static void
 gen7_upload_urb(struct brw_context *brw)
 {
struct intel_context *intel = brw-intel;
@@ -76,16 +100,6 @@ gen7_upload_urb(struct brw_context *brw)
assert(!brw-gs.prog_active);
 
BEGIN_BATCH(2);
-   OUT_BATCH(_3DSTATE_PUSH_CONSTANT_ALLOC_VS  16 | (2 - 2));
-   OUT_BATCH(8);
-   ADVANCE_BATCH();
-
-   BEGIN_BATCH(2);
-   OUT_BATCH(_3DSTATE_PUSH_CONSTANT_ALLOC_PS  16 | (2 - 2));
-   OUT_BATCH(8 | 8  GEN7_PUSH_CONSTANT_BUFFER_OFFSET_SHIFT);
-   ADVANCE_BATCH();
-
-   BEGIN_BATCH(2);
OUT_BATCH(_3DSTATE_URB_VS  16 | (2 - 2));
OUT_BATCH(brw-urb.nr_vs_entries |
  ((brw-urb.vs_size - 1)  GEN7_URB_ENTRY_SIZE_SHIFT) |
-- 
1.7.7.1

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


Re: [Mesa-dev] [PATCH] st/dri: Remove useless flush front.

2012-01-11 Thread Jose Fonseca
Stephane,

Although flushing the front buffer may be unnecessary, flushing itself is not, 
as glXMakeCurrent mandates that the current must be flushed:

   Pending commands to the previous context, if any, are flushed before it is 
released.

So this flush call can only be removed, if a flush is done elsewhere in DRI 
shared code, otherwise rendering queued in that context may not happen.

Jose

- Original Message -
 In the following scenario:
 - CreateContext C1
 - MakeCurrent C1
 - DestroyContext C1 (does not actually destroy the first context,
 postponed
   until the next MakeCurrent)
 - CreateContext C2
 - MakeCurrent C2
 
 MakeCurrent will call flush on a context which might not even have
 had a front
 buffer, leading to crashes. Since none of the dri drivers use the
 flush in
 their unbind_context implementation either, we remove this useless
 flush front
 call.
 
 This fixes GPU crashes with Chrome and gallium drivers.
 ---
  .../state_trackers/dri/common/dri_context.c|1 -
  1 files changed, 0 insertions(+), 1 deletions(-)
 
 diff --git a/src/gallium/state_trackers/dri/common/dri_context.c
 b/src/gallium/state_trackers/dri/common/dri_context.c
 index b47d8d9..226c630 100644
 --- a/src/gallium/state_trackers/dri/common/dri_context.c
 +++ b/src/gallium/state_trackers/dri/common/dri_context.c
 @@ -188,7 +188,6 @@ dri_unbind_context(__DRIcontext * cPriv)
  
 if (--ctx-bind_count == 0) {
if (ctx-st == ctx-stapi-get_current(ctx-stapi)) {
 - ctx-st-flush(ctx-st, ST_FLUSH_FRONT, NULL);
   stapi-make_current(stapi, NULL, NULL, NULL);
}
 }
 --
 1.7.5.3.367.ga9930
 
 ___
 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] [PATCH 1/2] tgsi: add TGSI_TEXTURE_SHADOWCUBEMAP

2012-01-11 Thread Dave Airlie
From: Dave Airlie airl...@redhat.com

This adds support for shadow cubemap texture sampling instructions.

This is required for GL 3.0.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 src/gallium/auxiliary/tgsi/tgsi_exec.c |2 ++
 src/gallium/auxiliary/tgsi/tgsi_strings.c  |1 +
 src/gallium/auxiliary/tgsi/tgsi_util.c |1 +
 src/gallium/include/pipe/p_shader_tokens.h |3 ++-
 4 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 72b1dca..c0bd2d0 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -1865,6 +1865,7 @@ exec_tex(struct tgsi_exec_machine *mach,
   r[0], r[1], r[2], r[3]);  /* outputs */
   break;
case TGSI_TEXTURE_SHADOW2D_ARRAY:
+   case TGSI_TEXTURE_SHADOWCUBE:
   FETCH(r[0], 0, CHAN_X);
   FETCH(r[1], 0, CHAN_Y);
   FETCH(r[2], 0, CHAN_Z);
@@ -2182,6 +2183,7 @@ exec_sample(struct tgsi_exec_machine *mach,
   break;
 
case TGSI_TEXTURE_SHADOW2D_ARRAY:
+   case TGSI_TEXTURE_SHADOWCUBE:
   FETCH(r[0], 0, CHAN_X);
   FETCH(r[1], 0, CHAN_Y);
   FETCH(r[2], 0, CHAN_Z);
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c 
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index de9152d..520452c 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -90,6 +90,7 @@ const char *tgsi_texture_names[TGSI_TEXTURE_COUNT] =
2DARRAY,
SHADOW1DARRAY,
SHADOW2DARRAY,
+   SHADOWCUBE
 };
 
 const char *tgsi_property_names[TGSI_PROPERTY_COUNT] =
diff --git a/src/gallium/auxiliary/tgsi/tgsi_util.c 
b/src/gallium/auxiliary/tgsi/tgsi_util.c
index 9f6997d..36dc10d 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_util.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_util.c
@@ -284,6 +284,7 @@ tgsi_util_get_inst_usage_mask(const struct 
tgsi_full_instruction *inst,
 read_mask = TGSI_WRITEMASK_XYZ;
 break;
  case TGSI_TEXTURE_SHADOW2D_ARRAY:
+ case TGSI_TEXTURE_SHADOWCUBE:
 read_mask = TGSI_WRITEMASK_XYZW;
 break;
  default:
diff --git a/src/gallium/include/pipe/p_shader_tokens.h 
b/src/gallium/include/pipe/p_shader_tokens.h
index a131630..df2dd5e 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -454,7 +454,8 @@ struct tgsi_instruction_label
 #define TGSI_TEXTURE_2D_ARRAY   10
 #define TGSI_TEXTURE_SHADOW1D_ARRAY 11
 #define TGSI_TEXTURE_SHADOW2D_ARRAY 12
-#define TGSI_TEXTURE_COUNT  13
+#define TGSI_TEXTURE_SHADOWCUBE 13
+#define TGSI_TEXTURE_COUNT  14
 
 struct tgsi_instruction_texture
 {
-- 
1.7.7.4

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


[Mesa-dev] [PATCH 2/2] glsl_to_tgsi: add support for shadow cube map sampling.

2012-01-11 Thread Dave Airlie
From: Dave Airlie airl...@redhat.com

This along with the TGSI support lets the piglit sampler-cube-shadow
test pass on softpipe.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp |5 +++--
 src/mesa/state_tracker/st_mesa_to_tgsi.c   |1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index cb44e2b..a947e18 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2646,8 +2646,9 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
   ir-shadow_comparitor-accept(this);
 
   /* XXX This will need to be updated for cubemap array samplers. */
-  if (sampler_type-sampler_dimensionality == GLSL_SAMPLER_DIM_2D 
-  sampler_type-sampler_array) {
+  if ((sampler_type-sampler_dimensionality == GLSL_SAMPLER_DIM_2D 
+  sampler_type-sampler_array) ||
+ sampler_type-sampler_dimensionality == GLSL_SAMPLER_DIM_CUBE) {
  coord_dst.writemask = WRITEMASK_W;
   } else {
  coord_dst.writemask = WRITEMASK_Z;
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c 
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index ac61534..e467ffd 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -279,6 +279,7 @@ translate_texture_target( GLuint textarget,
   case TEXTURE_RECT_INDEX: return TGSI_TEXTURE_SHADOWRECT;
   case TEXTURE_1D_ARRAY_INDEX: return TGSI_TEXTURE_SHADOW1D_ARRAY;
   case TEXTURE_2D_ARRAY_INDEX: return TGSI_TEXTURE_SHADOW2D_ARRAY;
+  case TEXTURE_CUBE_INDEX: return TGSI_TEXTURE_SHADOWCUBE;
   default: break;
   }
}
-- 
1.7.7.4

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


Re: [Mesa-dev] [PATCH 3/3] xlib: use X error handler to catch XShmQueryVersion() failure

2012-01-11 Thread Adam Jackson
On Tue, 2012-01-10 at 19:46 -0700, Brian Paul wrote:
 From: Brian Paul bri...@vmware.com
 
 This is a follow-on to the previous commits.  It seems that
 XShmQueryVersion() can trigger an X error after the first X
 connection is closed and we start using a new connection.

I assume this is when you switch which Display you're talking to as
well.

 +static int
 +xshm_query_version_err_handler( XMesaDisplay* dpy, XErrorEvent* xerr )
 +{
 +   /* If this function gets called, it's because XShmQuerryVersion()
 +* has failed.
 +*/
 +   XShmErrorFlag = True;
 +   return 0;
 +}

Not safe against a process using multiple Display connections, which is
admittedly quite rare.  There's a few instances of that kind of bug
already though, I wouldn't call it a blocker.

 +  /* Install X error handler before calling XShmQueryVersion() to catch
 +   * a spurious X error.
 +   */
 +  XShmErrorFlag = False;
 +  old_handler = XSetErrorHandler(xshm_query_version_err_handler);
 +  ok = XShmQueryVersion( display, major, minor, pixmaps );
 +  XSetErrorHandler(old_handler);
 +  if (XShmErrorFlag)
 + ok = False;
 +
 +  if (ok) {

Not thread-safe, though it's tough to hit.  You want an XLockDisplay
before the first XSetErrorHandler and the matching XUnlockDisplay after
the second, otherwise your handler can get called for errors on other
threads.

- ajax


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] tgsi: add TGSI_TEXTURE_SHADOWCUBEMAP

2012-01-11 Thread Brian Paul

On 01/11/2012 06:25 AM, Dave Airlie wrote:

From: Dave Airlieairl...@redhat.com

This adds support for shadow cubemap texture sampling instructions.

This is required for GL 3.0.

Signed-off-by: Dave Airlieairl...@redhat.com
---
  src/gallium/auxiliary/tgsi/tgsi_exec.c |2 ++
  src/gallium/auxiliary/tgsi/tgsi_strings.c  |1 +
  src/gallium/auxiliary/tgsi/tgsi_util.c |1 +
  src/gallium/include/pipe/p_shader_tokens.h |3 ++-
  4 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 72b1dca..c0bd2d0 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -1865,6 +1865,7 @@ exec_tex(struct tgsi_exec_machine *mach,
r[0],r[1],r[2],r[3]);  /* outputs */
break;
 case TGSI_TEXTURE_SHADOW2D_ARRAY:
+   case TGSI_TEXTURE_SHADOWCUBE:
FETCH(r[0], 0, CHAN_X);
FETCH(r[1], 0, CHAN_Y);
FETCH(r[2], 0, CHAN_Z);
@@ -2182,6 +2183,7 @@ exec_sample(struct tgsi_exec_machine *mach,
break;

 case TGSI_TEXTURE_SHADOW2D_ARRAY:
+   case TGSI_TEXTURE_SHADOWCUBE:
FETCH(r[0], 0, CHAN_X);
FETCH(r[1], 0, CHAN_Y);
FETCH(r[2], 0, CHAN_Z);
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c 
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index de9152d..520452c 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -90,6 +90,7 @@ const char *tgsi_texture_names[TGSI_TEXTURE_COUNT] =
 2DARRAY,
 SHADOW1DARRAY,
 SHADOW2DARRAY,
+   SHADOWCUBE
  };

  const char *tgsi_property_names[TGSI_PROPERTY_COUNT] =
diff --git a/src/gallium/auxiliary/tgsi/tgsi_util.c 
b/src/gallium/auxiliary/tgsi/tgsi_util.c
index 9f6997d..36dc10d 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_util.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_util.c
@@ -284,6 +284,7 @@ tgsi_util_get_inst_usage_mask(const struct 
tgsi_full_instruction *inst,
  read_mask = TGSI_WRITEMASK_XYZ;
  break;
   case TGSI_TEXTURE_SHADOW2D_ARRAY:
+ case TGSI_TEXTURE_SHADOWCUBE:
  read_mask = TGSI_WRITEMASK_XYZW;
  break;
   default:
diff --git a/src/gallium/include/pipe/p_shader_tokens.h 
b/src/gallium/include/pipe/p_shader_tokens.h
index a131630..df2dd5e 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -454,7 +454,8 @@ struct tgsi_instruction_label
  #define TGSI_TEXTURE_2D_ARRAY   10
  #define TGSI_TEXTURE_SHADOW1D_ARRAY 11
  #define TGSI_TEXTURE_SHADOW2D_ARRAY 12
-#define TGSI_TEXTURE_COUNT  13
+#define TGSI_TEXTURE_SHADOWCUBE 13
+#define TGSI_TEXTURE_COUNT  14

  struct tgsi_instruction_texture
  {



Reviewed-by: Brian Paul bri...@vmware.com

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


Re: [Mesa-dev] [PATCH 3/3] xlib: use X error handler to catch XShmQueryVersion() failure

2012-01-11 Thread Brian Paul

On 01/11/2012 08:13 AM, Adam Jackson wrote:

On Tue, 2012-01-10 at 19:46 -0700, Brian Paul wrote:

From: Brian Paulbri...@vmware.com

This is a follow-on to the previous commits.  It seems that
XShmQueryVersion() can trigger an X error after the first X
connection is closed and we start using a new connection.


I assume this is when you switch which Display you're talking to as
well.


Yes.  It's really weird.  I looked at the sources for the XShm 
extension code and I didn't see anything obviously wrong there.


If I disabled all use of XShm in the Mesa code the test app worked 
fine.  Also, If I hard coded the check_for_xshm() function to just 
always return true, things ran normally as well.


So the X error handler is a band-aid over the problem, but it seems to 
do the job.


I guess another solution would be to simply remove the call to 
XShmQueryVersion() and assume that if XQueryExtension(MIT-SHM) 
passes then the version is acceptable (it's been 1.1 forever, AFAIK). 
 What do you think about that?





+static int
+xshm_query_version_err_handler( XMesaDisplay* dpy, XErrorEvent* xerr )
+{
+   /* If this function gets called, it's because XShmQuerryVersion()
+* has failed.
+*/
+   XShmErrorFlag = True;
+   return 0;
+}


Not safe against a process using multiple Display connections, which is
admittedly quite rare.  There's a few instances of that kind of bug
already though, I wouldn't call it a blocker.


+  /* Install X error handler before calling XShmQueryVersion() to catch
+   * a spurious X error.
+   */
+  XShmErrorFlag = False;
+  old_handler = XSetErrorHandler(xshm_query_version_err_handler);
+  ok = XShmQueryVersion( display,major,minor,pixmaps );
+  XSetErrorHandler(old_handler);
+  if (XShmErrorFlag)
+ ok = False;
+
+  if (ok) {


Not thread-safe, though it's tough to hit.  You want an XLockDisplay
before the first XSetErrorHandler and the matching XUnlockDisplay after
the second, otherwise your handler can get called for errors on other
threads.


I guess I'm not too concerned about that for the time being.  As you 
said, there's other instances of multi-display and thread safety 
issues already.


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


[Mesa-dev] [Bug 44618] Cross-compilation broken by glsl builtin_compiler

2012-01-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44618

José Fonseca jfons...@vmware.com changed:

   What|Removed |Added

 CC||jfons...@vmware.com

--- Comment #1 from José Fonseca jfons...@vmware.com 2012-01-11 07:45:19 PST 
---
Scons supports cross-compilation using approach 1). It builds the
builtin_compiler and its dependencies twice. This works because each
platform/machine gets built in a separate build sub directory (e.g.,
build/linux-x86-debug, build/).

Getting this to work with the Mesa make file subsystem is probably quite a lot
of work.


2) seems an easier approach. But still tricky given that Mesa doesn't allow out
of source build.


Another option would be simply to eliminate builtin_compiler, and do whatever
it does at runtime, when the drivers are loaded.

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


Re: [Mesa-dev] [PATCH 3/3] xlib: use X error handler to catch XShmQueryVersion() failure

2012-01-11 Thread Adam Jackson
On Wed, 2012-01-11 at 08:43 -0700, Brian Paul wrote:
 On 01/11/2012 08:13 AM, Adam Jackson wrote:
  On Tue, 2012-01-10 at 19:46 -0700, Brian Paul wrote:
  From: Brian Paulbri...@vmware.com
 
  This is a follow-on to the previous commits.  It seems that
  XShmQueryVersion() can trigger an X error after the first X
  connection is closed and we start using a new connection.
 
  I assume this is when you switch which Display you're talking to as
  well.
 
 Yes.  It's really weird.  I looked at the sources for the XShm 
 extension code and I didn't see anything obviously wrong there.

Bizarre.  Only thing I can guess is the close_display hook not getting
called, but I don't see how that'd happen.

 I guess another solution would be to simply remove the call to 
 XShmQueryVersion() and assume that if XQueryExtension(MIT-SHM) 
 passes then the version is acceptable (it's been 1.1 forever, AFAIK). 
   What do you think about that?

Looks like 1.1 was X11R5.  From a quick check of the changes between R4
and R5, the only functional difference was that the support for shm
pixmaps was made contingent on all screens supporting the same format,
so there's a semantic shm pixmaps definitely work on multiple screens
if available change but no protocol change.

So yeah, that sounds fine, we're not using shm pixmaps regardless.

 I guess I'm not too concerned about that for the time being.  As you 
 said, there's other instances of multi-display and thread safety 
 issues already.

Yeah, not a showstopper by any means, just something I've wanted to
clean up for a while since I keep getting threading bugs.  But in the
xlib backend I don't really care, it's not something I ship and wouldn't
consider it a conformance path even if I did.

For the series:

Reviewed-by: Adam Jackson a...@redhat.com

- ajax


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965: Don't reallocate push constant URB space on new VS programs.

2012-01-11 Thread Paul Berry
On 11 January 2012 11:44, Kenneth Graunke kenn...@whitecape.org wrote:

 The gen7_urb atom depends on CACHE_NEW_VS_PROG and CACHE_NEW_GS_PROG,
 causing gen7_upload_urb() to be called when switching to a new VS
 program.

 In addition to partitioning the URB space between the VS and GS,
 gen7_upload_urb() also allocated space for VS and PS push constants.
 Unfortunately, this meant that whenever CACHE_NEW_VS was flagged, we'd
 reallocate the space for the PS push constants.  This appears to trash
 the PS push constants until the next 3DSTATE_CONSTANT_PS packet.

 Since our URB allocation for push constants is entirely static, it makes
 sense to split it out into its own atom that only subscribes to
 BRW_NEW_CONTEXT.  This avoids reallocating the space and trashing
 constants.

 Fixes a rendering artifact in Extreme Tuxracer, where instead of a snow
 trail, you'd get a bright red streak (affectionately known as the
 bloody penguin bug).

 This also explains why adding VS-related dirty bits to gen7_ps_state
 made the problem disappear: it made 3DSTATE_CONSTANT_PS be emitted after
 every 3DSTATE_PUSH_CONSTANT_ALLOC_PS packet.

 NOTE: This is a candidate for the 7.11 and 8.0 branches.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38868
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org


Reviewed-by: Paul Berry stereotype...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] configure.ac: add and use AC_PROG_BISON/FLEX macros

2012-01-11 Thread Matt Turner
On Wed, Jan 11, 2012 at 1:49 AM, Kenneth Graunke kenn...@whitecape.org wrote:
 On 01/10/2012 10:16 PM, Matt Turner wrote:

 Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
 easier while still specifically requiring bison and flex.

 Based on bison.m4 and flex.m4 found in LLVM's tree.

 Signed-off-by: Matt Turnermatts...@gmail.com
 ---
  configure.ac |    9 -
  m4/bison.m4  |   16 
  m4/flex.m4   |   16 
  3 files changed, 36 insertions(+), 5 deletions(-)
  create mode 100644 m4/bison.m4
  create mode 100644 m4/flex.m4

 diff --git a/configure.ac b/configure.ac
 index 511d147..c0abeb9 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -45,11 +45,10 @@ if test x$MKDEP = x; then
      AC_MSG_ERROR([makedepend is required to build Mesa])
  fi

 -AC_PATH_PROG([FLEX], [flex])
 -test x$FLEX = x  AC_MSG_ERROR([flex is needed to build Mesa])
 -
 -AC_PATH_PROG([BISON], [bison])
 -test x$BISON = x  AC_MSG_ERROR([bison is needed to build Mesa])
 +m4_include([m4/bison.m4])
 +AC_PROG_BISON
 +m4_include([m4/flex.m4])
 +AC_PROG_FLEX

  dnl Our fallback install-sh is a symlink to minstall. Use the existing
  dnl configuration in that case.
 diff --git a/m4/bison.m4 b/m4/bison.m4
 new file mode 100644
 index 000..641d438
 --- /dev/null
 +++ b/m4/bison.m4
 @@ -0,0 +1,16 @@
 +#
 +# Check for Bison.
 +#
 +# This macro verifies that Bison is installed.  If successful, then
 +# 1) YACC is set to bison -y (to emulate YACC calls)


 I don't think we want to emulate POSIX yacc.  We're not using -y today, and
 I expect it'd only break things...


 +# 2) BISON is set to bison
 +#
 +AC_DEFUN([AC_PROG_BISON],
 +[AC_PROG_YACC()
 +if test $YACC != bison -y; then
 +  AC_SUBST(BISON,[])
 +  AC_MSG_WARN([bison not found])
 +else
 +  AC_SUBST(BISON,[bison])
 +fi
 +])
 diff --git a/m4/flex.m4 b/m4/flex.m4
 new file mode 100644
 index 000..6a2a004
 --- /dev/null
 +++ b/m4/flex.m4
 @@ -0,0 +1,16 @@
 +#
 +# Check for FLEX.
 +#
 +# This macro verifies that flex is installed.  If successful, then
 +# 1) LEX is set to flex (to emulate lex calls)
 +# 2) FLEX is set to flex
 +#
 +AC_DEFUN([AC_PROG_FLEX],
 +[AC_PROG_LEX()
 +if test $LEX != flex; then
 +  AC_SUBST(FLEX,[])
 +  AC_MSG_ERROR([flex not found])
 +else
 +  AC_SUBST(FLEX,[flex])
 +fi
 +])


 I like the idea of AC_PROG_FLEX and AC_PROG_BISON macros, but I don't care
 for this implementation.  I would expect them to perform some kind of
 feature check, or ask the program whether it's flex/bison.  This just
 matches on the name, so if I had flex installed only as lex, or bison
 installed as bison25 or such, this would break.

 Maybe this is okay, but at least in my mind, only allowing one name seems to
 kind of defeat the point of a configure check.  Not entirely, but still.

Agree, this isn't very good.

Using AC_PROG_PATH for bison and flex doesn't make automake happy, but
using AC_PROG_YACC/LEX works fine. Oh, and when experimenting with
this I discovered that bison -y worked while plain bison didn't. Who
knows.

I suggest we just do what my previous automake patch does with
AC_PROG_YACC/LEX and just let builders ensure that they're using flex
and bison. In Gentoo, we've found that this is very common.

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


Re: [Mesa-dev] [PATCH] [rfc] mesa: don't allow GLSL 1.30 without GL3.

2012-01-11 Thread Paul Berry
On 10 January 2012 13:38, Christoph Bumiller
e0425...@student.tuwien.ac.atwrote:

 On 01/10/2012 10:09 PM, Dave Airlie wrote:
  On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt e...@anholt.net wrote:
  On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie airl...@gmail.com
 wrote:
  From: Dave Airlie airl...@redhat.com
 
  Things can get confused if you expose one without the other which can
 happen
  if you are missing one or two of the extensions (like say float
 textures).
 
  Can you clarify what things can get confused means?
 
  Well piglit starts to fail in wierd and wonderful way, I just don't
  think we have any valid use cases for exposing GLSL1.30 without GL3
  and I'd like to enforce that.
 

 Some tests only check for GLSL 1.3 and then use functions like
 glUniform*ui that glew only sets up if GL_VERSION_3_0 and as a result
 they call a NULL pointer.


Personally I would call this a flaw in the piglit tests.  If sloppy
dependency checking in piglit tests is our only reason for making this
change, then I'd rather fix the piglit tests rather than constrain what
GLSL version Mesa can advertise.  It was really useful for us in our GL 3.0
work on Sandy Bridge to be able to enable GLSL 1.30 support when it was
ready, and not have to wait until we had all the components of GL 3.0 in
place before we could start testing the GLSL 1.30 features.

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


Re: [Mesa-dev] [PATCH] st/dri: Remove useless flush front.

2012-01-11 Thread Stéphane Marchesin
Where else would the flush go? I'll look into fixing it differently
but if the flush is anywhere in the makecurrent path, the same issue
will happen. Again, none of the classic dri drivers do it.

Stéphane


2012/1/11 Jose Fonseca jfons...@vmware.com:
 Stephane,

 Although flushing the front buffer may be unnecessary, flushing itself is 
 not, as glXMakeCurrent mandates that the current must be flushed:

   Pending commands to the previous context, if any, are flushed before it is 
 released.

 So this flush call can only be removed, if a flush is done elsewhere in DRI 
 shared code, otherwise rendering queued in that context may not happen.

 Jose

 - Original Message -
 In the following scenario:
 - CreateContext C1
 - MakeCurrent C1
 - DestroyContext C1 (does not actually destroy the first context,
 postponed
   until the next MakeCurrent)
 - CreateContext C2
 - MakeCurrent C2

 MakeCurrent will call flush on a context which might not even have
 had a front
 buffer, leading to crashes. Since none of the dri drivers use the
 flush in
 their unbind_context implementation either, we remove this useless
 flush front
 call.

 This fixes GPU crashes with Chrome and gallium drivers.
 ---
  .../state_trackers/dri/common/dri_context.c        |    1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

 diff --git a/src/gallium/state_trackers/dri/common/dri_context.c
 b/src/gallium/state_trackers/dri/common/dri_context.c
 index b47d8d9..226c630 100644
 --- a/src/gallium/state_trackers/dri/common/dri_context.c
 +++ b/src/gallium/state_trackers/dri/common/dri_context.c
 @@ -188,7 +188,6 @@ dri_unbind_context(__DRIcontext * cPriv)

     if (--ctx-bind_count == 0) {
        if (ctx-st == ctx-stapi-get_current(ctx-stapi)) {
 -         ctx-st-flush(ctx-st, ST_FLUSH_FRONT, NULL);
           stapi-make_current(stapi, NULL, NULL, NULL);
        }
     }
 --
 1.7.5.3.367.ga9930

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


[Mesa-dev] [Bug 44693] New: [r600g, regression] Piglit: Four GL_SELECT tests fail

2012-01-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44693

 Bug #: 44693
   Summary: [r600g,regression] Piglit: Four GL_SELECT tests fail
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: k...@dev.carbon-project.org


A regression for four of the five GL_SELECT tests was introduced between
master/78402613 and master/765ed3a6. The failing tests are:
- GL_SELECT - alpha-test enabled
(http://dev.carbon-project.org/misc/piglit/20120111git765ed3a6/test_general__GL_SELECTalphatestenabled.html)
- GL_SELECT - no test function
(http://dev.carbon-project.org/misc/piglit/20120111git765ed3a6/test_general__GL_SELECTnotestfunction.html)
- GL_SELECT - scissor-test enabled
(http://dev.carbon-project.org/misc/piglit/20120111git765ed3a6/test_general__GL_SELECTscissortestenabled.html)
- GL_SELECT - stencil-test enabled
(http://dev.carbon-project.org/misc/piglit/20120111git765ed3a6/test_general__GL_SELECTstenciltestenabled.html)

I didn't have time to bisect this yet, but maybe you know already which commit
might be the culprit. If nobody beats me to it, I'll try to do the bisection on
the weekend.

Used stack:
libdrm: 2.4.30-1
Mesa: master/765ed3a6 (r600g)
Linux: 3.2
DDX: 6.14.3 + commits from Git up until and including master/ae45d7e6
X.org: 1.11.2.902 (1.11.3 RC 2)
Hardware: 1002:9553

Detailed test results available from:
http://dev.carbon-project.org/misc/piglit/

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


Re: [Mesa-dev] [PATCH] st/dri: Remove useless flush front.

2012-01-11 Thread Jakob Bornecrantz
Are you sure that the flush doesn't happen somewhere higher up in the
call chain, like in the common dri code, or glx code?

Cheers, Jakob.

- Ursprungligt meddelande -
 Where else would the flush go? I'll look into fixing it differently
 but if the flush is anywhere in the makecurrent path, the same issue
 will happen. Again, none of the classic dri drivers do it.
 
 Stéphane
 
 
 2012/1/11 Jose Fonseca jfons...@vmware.com:
  Stephane,
 
  Although flushing the front buffer may be unnecessary, flushing
  itself is not, as glXMakeCurrent mandates that the current must be
  flushed:
 
    Pending commands to the previous context, if any, are flushed
    before it is released.
 
  So this flush call can only be removed, if a flush is done
  elsewhere in DRI shared code, otherwise rendering queued in that
  context may not happen.
 
  Jose
 
  - Original Message -
  In the following scenario:
  - CreateContext C1
  - MakeCurrent C1
  - DestroyContext C1 (does not actually destroy the first context,
  postponed
    until the next MakeCurrent)
  - CreateContext C2
  - MakeCurrent C2
 
  MakeCurrent will call flush on a context which might not even have
  had a front
  buffer, leading to crashes. Since none of the dri drivers use the
  flush in
  their unbind_context implementation either, we remove this useless
  flush front
  call.
 
  This fixes GPU crashes with Chrome and gallium drivers.
  ---
   .../state_trackers/dri/common/dri_context.c        |    1 -
   1 files changed, 0 insertions(+), 1 deletions(-)
 
  diff --git a/src/gallium/state_trackers/dri/common/dri_context.c
  b/src/gallium/state_trackers/dri/common/dri_context.c
  index b47d8d9..226c630 100644
  --- a/src/gallium/state_trackers/dri/common/dri_context.c
  +++ b/src/gallium/state_trackers/dri/common/dri_context.c
  @@ -188,7 +188,6 @@ dri_unbind_context(__DRIcontext * cPriv)
 
      if (--ctx-bind_count == 0) {
         if (ctx-st == ctx-stapi-get_current(ctx-stapi)) {
  -         ctx-st-flush(ctx-st, ST_FLUSH_FRONT, NULL);
            stapi-make_current(stapi, NULL, NULL, NULL);
         }
      }
  --
  1.7.5.3.367.ga9930
 
  ___
  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 mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] st/dri: Remove useless flush front.

2012-01-11 Thread Jose Fonseca
- Original Message -
 Where else would the flush go? 

Maybe one of the callers already invoked glFlush, or something like that.

 I'll look into fixing it differently
 but if the flush is anywhere in the makecurrent path, the same issue
 will happen. Again, none of the classic dri drivers do it.

If you wanna a short term fix, it might be OK with just commenting out the 
flush call, but please leave a note there saying that a flush is needed for 
strict conformance.

Jose

 Stéphane
 
 
 2012/1/11 Jose Fonseca jfons...@vmware.com:
  Stephane,
 
  Although flushing the front buffer may be unnecessary, flushing
  itself is not, as glXMakeCurrent mandates that the current must be
  flushed:
 
    Pending commands to the previous context, if any, are flushed
    before it is released.
 
  So this flush call can only be removed, if a flush is done
  elsewhere in DRI shared code, otherwise rendering queued in that
  context may not happen.
 
  Jose
 
  - Original Message -
  In the following scenario:
  - CreateContext C1
  - MakeCurrent C1
  - DestroyContext C1 (does not actually destroy the first context,
  postponed
    until the next MakeCurrent)
  - CreateContext C2
  - MakeCurrent C2
 
  MakeCurrent will call flush on a context which might not even have
  had a front
  buffer, leading to crashes. Since none of the dri drivers use the
  flush in
  their unbind_context implementation either, we remove this useless
  flush front
  call.
 
  This fixes GPU crashes with Chrome and gallium drivers.
  ---
   .../state_trackers/dri/common/dri_context.c        |    1 -
   1 files changed, 0 insertions(+), 1 deletions(-)
 
  diff --git a/src/gallium/state_trackers/dri/common/dri_context.c
  b/src/gallium/state_trackers/dri/common/dri_context.c
  index b47d8d9..226c630 100644
  --- a/src/gallium/state_trackers/dri/common/dri_context.c
  +++ b/src/gallium/state_trackers/dri/common/dri_context.c
  @@ -188,7 +188,6 @@ dri_unbind_context(__DRIcontext * cPriv)
 
      if (--ctx-bind_count == 0) {
         if (ctx-st == ctx-stapi-get_current(ctx-stapi)) {
  -         ctx-st-flush(ctx-st, ST_FLUSH_FRONT, NULL);
            stapi-make_current(stapi, NULL, NULL, NULL);
         }
      }
  --
  1.7.5.3.367.ga9930
 
  ___
  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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] gallivm: add IABS opcode support

2012-01-11 Thread nobled
---
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c |1 +
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
index a021efd..88702bc 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
@@ -697,6 +697,7 @@ emit_instruction(
   return FALSE;

case TGSI_OPCODE_ABS:
+   case TGSI_OPCODE_IABS:
   src0 = emit_fetch(bld, inst, 0);
   dst0 = lp_build_abs(bld-base, src0);
   break;
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 40744e3..f9dc5b4 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -1812,6 +1812,7 @@ emit_instruction(
   break;

case TGSI_OPCODE_ABS:
+   case TGSI_OPCODE_IABS:
   FOR_EACH_DST0_ENABLED_CHANNEL( inst, chan_index ) {
  tmp0 = emit_fetch( bld, inst, 0, chan_index );
  dst0[chan_index] = lp_build_abs( bld-base, tmp0 );
-- 
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gallivm: add IABS opcode support

2012-01-11 Thread Dave Airlie
how did you get gallivm to get this opcode?

it shouldn't be possible yet, and gallivm needs a lot of work before
it can do integers.

Dave.

On Wed, Jan 11, 2012 at 6:23 PM, nobled nob...@dreamwidth.org wrote:
 ---
  src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c |    1 +
  src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |    1 +
  2 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
 b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
 index a021efd..88702bc 100644
 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
 +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
 @@ -697,6 +697,7 @@ emit_instruction(
       return FALSE;

    case TGSI_OPCODE_ABS:
 +   case TGSI_OPCODE_IABS:
       src0 = emit_fetch(bld, inst, 0);
       dst0 = lp_build_abs(bld-base, src0);
       break;
 diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
 b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
 index 40744e3..f9dc5b4 100644
 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
 +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
 @@ -1812,6 +1812,7 @@ emit_instruction(
       break;

    case TGSI_OPCODE_ABS:
 +   case TGSI_OPCODE_IABS:
       FOR_EACH_DST0_ENABLED_CHANNEL( inst, chan_index ) {
          tmp0 = emit_fetch( bld, inst, 0, chan_index );
          dst0[chan_index] = lp_build_abs( bld-base, tmp0 );
 --
 1.7.4.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


Re: [Mesa-dev] [PATCH] Enable is_front_buffer_rendering variable in case of GL_FRONT_AND_BACK

2012-01-11 Thread Anuj Phogat
On Fri 06 Jan 2012 01:00:36 PM PST, Anuj Phogat wrote:
 glDrawBuffer(GL_FRONT_AND_BACK) results in to segmentation fault if
 intel-is_front_buffer_rendering is not enabled with GL_FRONT_AND_BACK.
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44153

 Reported-by: Yi Sun yi@intel.com
 Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
 ---
  src/mesa/drivers/dri/intel/intel_buffers.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c 
 b/src/mesa/drivers/dri/intel/intel_buffers.c
 index 4632751..9809f79 100644
 --- a/src/mesa/drivers/dri/intel/intel_buffers.c
 +++ b/src/mesa/drivers/dri/intel/intel_buffers.c
 @@ -88,7 +88,7 @@ intelDrawBuffer(struct gl_context * ctx, GLenum mode)
   intel-is_front_buffer_rendering;
  
intel-is_front_buffer_rendering = (mode == GL_FRONT_LEFT)
 - || (mode == GL_FRONT);
 + || (mode == GL_FRONT) || (mode == GL_FRONT_AND_BACK);
  
/* If we weren't front-buffer rendering before but we are now,
 * invalidate our DRI drawable so we'll ask for new buffers

Any comments on the above patch?


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


Re: [Mesa-dev] [PATCH] gallivm: add IABS opcode support

2012-01-11 Thread Jose Fonseca
Test slaves are also reporting similar failures on glean:

  ./glean --run results --overwrite --quick --tests glsl1'
  warning: failed to translate tgsi opcode F2I to LLVM
  warning: failed to translate tgsi opcode IDIV to LLVM
  src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:2232:emit_instruction: 
Assertion `0' failed.

TGSI_OPCODE_I2F

Jose

- Original Message -
 how did you get gallivm to get this opcode?
 
 it shouldn't be possible yet, and gallivm needs a lot of work before
 it can do integers.
 
 Dave.
 
 On Wed, Jan 11, 2012 at 6:23 PM, nobled nob...@dreamwidth.org
 wrote:
  ---
   src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c |    1 +
   src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |    1 +
   2 files changed, 2 insertions(+), 0 deletions(-)
 
  diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
  b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
  index a021efd..88702bc 100644
  --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
  +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c
  @@ -697,6 +697,7 @@ emit_instruction(
        return FALSE;
 
     case TGSI_OPCODE_ABS:
  +   case TGSI_OPCODE_IABS:
        src0 = emit_fetch(bld, inst, 0);
        dst0 = lp_build_abs(bld-base, src0);
        break;
  diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
  b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
  index 40744e3..f9dc5b4 100644
  --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
  +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
  @@ -1812,6 +1812,7 @@ emit_instruction(
        break;
 
     case TGSI_OPCODE_ABS:
  +   case TGSI_OPCODE_IABS:
        FOR_EACH_DST0_ENABLED_CHANNEL( inst, chan_index ) {
           tmp0 = emit_fetch( bld, inst, 0, chan_index );
           dst0[chan_index] = lp_build_abs( bld-base, tmp0 );
  --
  1.7.4.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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] st/dri: Remove useless flush front.

2012-01-11 Thread Stéphane Marchesin
On Wed, Jan 11, 2012 at 10:13, Jose Fonseca jfons...@vmware.com wrote:
 - Original Message -
 Where else would the flush go?

 Maybe one of the callers already invoked glFlush, or something like that.


Not that I could see.

 I'll look into fixing it differently
 but if the flush is anywhere in the makecurrent path, the same issue
 will happen. Again, none of the classic dri drivers do it.

 If you wanna a short term fix, it might be OK with just commenting out the 
 flush call, but please leave a note there saying that a flush is needed for 
 strict conformance.

Maybe I'll do that, what about those lines in g/st/dri/common/dri_drawable.c:
/* XXX remove this and just set the correct one on the framebuffer */
drawable-flush_frontbuffer(drawable, statt);

It's on the same path that leads to that crash and seems to suggest
that the flush might not be required?

Stéphane



 Jose

 Stéphane


 2012/1/11 Jose Fonseca jfons...@vmware.com:
  Stephane,
 
  Although flushing the front buffer may be unnecessary, flushing
  itself is not, as glXMakeCurrent mandates that the current must be
  flushed:
 
    Pending commands to the previous context, if any, are flushed
    before it is released.
 
  So this flush call can only be removed, if a flush is done
  elsewhere in DRI shared code, otherwise rendering queued in that
  context may not happen.
 
  Jose
 
  - Original Message -
  In the following scenario:
  - CreateContext C1
  - MakeCurrent C1
  - DestroyContext C1 (does not actually destroy the first context,
  postponed
    until the next MakeCurrent)
  - CreateContext C2
  - MakeCurrent C2
 
  MakeCurrent will call flush on a context which might not even have
  had a front
  buffer, leading to crashes. Since none of the dri drivers use the
  flush in
  their unbind_context implementation either, we remove this useless
  flush front
  call.
 
  This fixes GPU crashes with Chrome and gallium drivers.
  ---
   .../state_trackers/dri/common/dri_context.c        |    1 -
   1 files changed, 0 insertions(+), 1 deletions(-)
 
  diff --git a/src/gallium/state_trackers/dri/common/dri_context.c
  b/src/gallium/state_trackers/dri/common/dri_context.c
  index b47d8d9..226c630 100644
  --- a/src/gallium/state_trackers/dri/common/dri_context.c
  +++ b/src/gallium/state_trackers/dri/common/dri_context.c
  @@ -188,7 +188,6 @@ dri_unbind_context(__DRIcontext * cPriv)
 
      if (--ctx-bind_count == 0) {
         if (ctx-st == ctx-stapi-get_current(ctx-stapi)) {
  -         ctx-st-flush(ctx-st, ST_FLUSH_FRONT, NULL);
            stapi-make_current(stapi, NULL, NULL, NULL);
         }
      }
  --
  1.7.5.3.367.ga9930
 
  ___
  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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gallivm: add IABS opcode support

2012-01-11 Thread Dave Airlie
On Wed, Jan 11, 2012 at 7:20 PM, Jose Fonseca jfons...@vmware.com wrote:
 Test slaves are also reporting similar failures on glean:

  ./glean --run results --overwrite --quick --tests glsl1'
  warning: failed to translate tgsi opcode F2I to LLVM
  warning: failed to translate tgsi opcode IDIV to LLVM
  src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:2232:emit_instruction: 
 Assertion `0' failed.

 TGSI_OPCODE_I2F

Okay I'll fix that, it definitely should be seeing those opcodes in there.

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


Re: [Mesa-dev] [PATCH] gallivm: add IABS opcode support

2012-01-11 Thread Dave Airlie
On Wed, Jan 11, 2012 at 7:30 PM, Dave Airlie airl...@gmail.com wrote:
 On Wed, Jan 11, 2012 at 7:20 PM, Jose Fonseca jfons...@vmware.com wrote:
 Test slaves are also reporting similar failures on glean:

  ./glean --run results --overwrite --quick --tests glsl1'
  warning: failed to translate tgsi opcode F2I to LLVM
  warning: failed to translate tgsi opcode IDIV to LLVM
  src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:2232:emit_instruction: 
 Assertion `0' failed.

 TGSI_OPCODE_I2F

 Okay I'll fix that, it definitely should be seeing those opcodes in there.

shouldn't.


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


Re: [Mesa-dev] [PATCH] glx/dri: Initialize api even if num_attribs == 0.

2012-01-11 Thread Ian Romanick

On 01/10/2012 11:36 PM, Kenneth Graunke wrote:

Both dri2_create_context_attribs and drisw_create_context_attribs call
dri2_convert_glx_attribs, expecting it to fill in *api on success.

However, when num_attribs == 0, it was returning true without setting
*api, causing the caller to use an uninitialized value.

Cc: Vadim Girlinvadimgir...@gmail.com
Signed-off-by: Kenneth Graunkekenn...@whitecape.org


Reviewed-by: Ian Romanick ian.d.roman...@intel.com


---
  src/glx/dri_common.c |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)

Vadim, hopefully this should also fix Unigine Heaven for you.

diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 8feb587..ed0b134 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -429,8 +429,10 @@ dri2_convert_glx_attribs(unsigned num_attribs, const 
uint32_t *attribs,
 uint32_t profile;
 int render_type = GLX_RGBA_TYPE;

-   if (num_attribs == 0)
+   if (num_attribs == 0) {
+  *api = __DRI_API_OPENGL;
return true;
+   }

 /* This is actually an internal error, but what the heck.
  */


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


Re: [Mesa-dev] [PATCH] mesa: Make ffs/ffsl conditions match popcount ones.

2012-01-11 Thread Eric Anholt
On Tue, 10 Jan 2012 23:08:51 -0600, Alexander von Gluck kallis...@unixzen.com 
wrote:
 
 - Ensure mesa code uses the _mesa_ffs(l) functions
consistantly instead of jumping around between ffs
and _mesa_ffs
 - This makes ffs/ffsl behave more like the popcount code
 - Better detects and handles edge cases of missing ffs/ffsl
 - Use builtin ffs/ffsl more often as it may provide
performance improvements

We intentionally don't use those mesa wrappers in our code.  If you have
a portability issue where they're not present on your platform, please
define them on your platform instead of making people use some other
function.


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


[Mesa-dev] [PATCH 1/2] i965 gen4-6: Fix off-by-one errors brw_create_constant_surface()

2012-01-11 Thread Paul Berry
Commit 9bdc44a52804a64219a0ca1a061b18596863e524 (i965: Replace struct
with bit shifting for WM pull constant surfaces) accidentally
introduced off-by-one errors into the calculation of the surface
width, height, and depth.  This patch restores the correct
computation.

The reason this wasn't noticed by Piglit tests is that the size of our
constant surfaces is always less than 2^20, therefore the off-by-one
error was causing the depth field of the surface to be set to all
1's.  The hardware interpreted this as an extremely large surface, so
overflow checking was effectively disabled.

No Piglit regressions on Sandy Bridge.

NOTE: This is a candidate for the 7.11 and 8.0 branches.
---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index dedf594..b40f5e1 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -698,10 +698,10 @@ brw_create_constant_surface(struct brw_context *brw,
 
surf[1] = bo-offset; /* reloc */
 
-   surf[2] = (((w  0x7f) - 1)  BRW_SURFACE_WIDTH_SHIFT |
- (((w  7)  0x1fff) - 1)  BRW_SURFACE_HEIGHT_SHIFT);
+   surf[2] = ((w  0x7f)  BRW_SURFACE_WIDTH_SHIFT |
+ ((w  7)  0x1fff)  BRW_SURFACE_HEIGHT_SHIFT);
 
-   surf[3] = w  20)  0x7f) - 1)  BRW_SURFACE_DEPTH_SHIFT |
+   surf[3] = (((w  20)  0x7f)  BRW_SURFACE_DEPTH_SHIFT |
  (width * 16 - 1)  BRW_SURFACE_PITCH_SHIFT);
 
surf[4] = 0;
-- 
1.7.6.5

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


[Mesa-dev] [PATCH 2/2] i965: Set pitch of pull constant buffers to 16.

2012-01-11 Thread Paul Berry
We always access pull constant buffers using the message types OWord
Block Read or OWord Dual Block Read.  According to the Sandy Bridge
PRM, Vol 4 Part 1, pages 214 and 218, when using these messages:

the surface pitch is ignored, the surface is treated as a
1-dimensional surface.  An element size (pitch) of 16 bytes is
used to determine the size of the buffer for out-of-bounds
checking if using the surface state model.

Previously we were setting the pitch for pull constant buffers to the
size of the whole constant buffer--this made no sense and would have
led to incorrect behavior if it were not for the fact that the pitch
is ignored.

For clarity, this patch sets the pitch for pull constant buffers to 16
bytes, consistent with the hardware's behavior.

No piglit regressions on Sandy Bridge or Ivy Bridge.
---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c  |2 +-
 src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index b40f5e1..e474626 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -702,7 +702,7 @@ brw_create_constant_surface(struct brw_context *brw,
  ((w  7)  0x1fff)  BRW_SURFACE_HEIGHT_SHIFT);
 
surf[3] = (((w  20)  0x7f)  BRW_SURFACE_DEPTH_SHIFT |
- (width * 16 - 1)  BRW_SURFACE_PITCH_SHIFT);
+ 15  BRW_SURFACE_PITCH_SHIFT); /* ignored */
 
surf[4] = 0;
surf[5] = 0;
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index 1c0183b..b05c8ae 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -157,7 +157,7 @@ gen7_create_constant_surface(struct brw_context *brw,
surf-ss2.width = w  0x7f;/* bits 6:0 of size or width */
surf-ss2.height = (w  7)  0x1fff;  /* bits 19:7 of size or width */
surf-ss3.depth = (w  20)  0x7f;/* bits 26:20 of size or width */
-   surf-ss3.pitch = (width * 16) - 1; /* ignored?? */
+   surf-ss3.pitch = 15; /* ignored */
gen7_set_surface_tiling(surf, I915_TILING_NONE); /* tiling now allowed */
 
/* Emit relocation to surface contents.  Section 5.1.1 of the gen4
-- 
1.7.6.5

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


Re: [Mesa-dev] [PATCH] Enable is_front_buffer_rendering variable in case of GL_FRONT_AND_BACK

2012-01-11 Thread Eric Anholt
On Fri,  6 Jan 2012 13:00:36 -0800, Anuj Phogat anuj.pho...@gmail.com wrote:
 glDrawBuffer(GL_FRONT_AND_BACK) results in to segmentation fault if
 intel-is_front_buffer_rendering is not enabled with GL_FRONT_AND_BACK.
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44153

Reviewed-by: Eric Anholt e...@anholt.net


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


Re: [Mesa-dev] [PATCH] mesa: Make ffs/ffsl conditions match popcount ones.

2012-01-11 Thread Kenneth Graunke

On 01/11/2012 12:02 PM, Eric Anholt wrote:

On Tue, 10 Jan 2012 23:08:51 -0600, Alexander von Gluckkallis...@unixzen.com  
wrote:


- Ensure mesa code uses the _mesa_ffs(l) functions
consistantly instead of jumping around between ffs
and _mesa_ffs
- This makes ffs/ffsl behave more like the popcount code
- Better detects and handles edge cases of missing ffs/ffsl
- Use builtin ffs/ffsl more often as it may provide
performance improvements


We intentionally don't use those mesa wrappers in our code.  If you have
a portability issue where they're not present on your platform, please
define them on your platform instead of making people use some other
function.


In other words, I think the preference is to use the ffs/ffsl names 
everywhere, and never call _mesa_ffs.  On platforms that don't 
natively support ffs, Mesa would provide the implementation of ffs.

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


Re: [Mesa-dev] [PATCH 1/2] i965 gen4-6: Fix off-by-one errors brw_create_constant_surface()

2012-01-11 Thread Eric Anholt
On Wed, 11 Jan 2012 12:06:36 -0800, Paul Berry stereotype...@gmail.com wrote:
 Commit 9bdc44a52804a64219a0ca1a061b18596863e524 (i965: Replace struct
 with bit shifting for WM pull constant surfaces) accidentally
 introduced off-by-one errors into the calculation of the surface
 width, height, and depth.  This patch restores the correct
 computation.
 
 The reason this wasn't noticed by Piglit tests is that the size of our
 constant surfaces is always less than 2^20, therefore the off-by-one
 error was causing the depth field of the surface to be set to all
 1's.  The hardware interpreted this as an extremely large surface, so
 overflow checking was effectively disabled.
 
 No Piglit regressions on Sandy Bridge.

Reviewed-by: Eric Anholt e...@anholt.net


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


Re: [Mesa-dev] [PATCH 2/2] i965: Set pitch of pull constant buffers to 16.

2012-01-11 Thread Eric Anholt
On Wed, 11 Jan 2012 12:06:37 -0800, Paul Berry stereotype...@gmail.com wrote:
 We always access pull constant buffers using the message types OWord
 Block Read or OWord Dual Block Read.  According to the Sandy Bridge
 PRM, Vol 4 Part 1, pages 214 and 218, when using these messages:
 
 the surface pitch is ignored, the surface is treated as a
 1-dimensional surface.  An element size (pitch) of 16 bytes is
 used to determine the size of the buffer for out-of-bounds
 checking if using the surface state model.
 
 Previously we were setting the pitch for pull constant buffers to the
 size of the whole constant buffer--this made no sense and would have
 led to incorrect behavior if it were not for the fact that the pitch
 is ignored.
 
 For clarity, this patch sets the pitch for pull constant buffers to 16
 bytes, consistent with the hardware's behavior.

I'd prefer to see the 15 written as (16 - 1) just to clarify that it's a
value-minus-one field, similarly to how we do the
OUT_BATCH(_3DSTATE_CONSTANT_PS  16 | (7 - 2)); for the length field of
packets.


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


Re: [Mesa-dev] [PATCH 2/2] i965: Set pitch of pull constant buffers to 16.

2012-01-11 Thread Paul Berry
On 11 January 2012 12:23, Eric Anholt e...@anholt.net wrote:

 On Wed, 11 Jan 2012 12:06:37 -0800, Paul Berry stereotype...@gmail.com
 wrote:
  We always access pull constant buffers using the message types OWord
  Block Read or OWord Dual Block Read.  According to the Sandy Bridge
  PRM, Vol 4 Part 1, pages 214 and 218, when using these messages:
 
  the surface pitch is ignored, the surface is treated as a
  1-dimensional surface.  An element size (pitch) of 16 bytes is
  used to determine the size of the buffer for out-of-bounds
  checking if using the surface state model.
 
  Previously we were setting the pitch for pull constant buffers to the
  size of the whole constant buffer--this made no sense and would have
  led to incorrect behavior if it were not for the fact that the pitch
  is ignored.
 
  For clarity, this patch sets the pitch for pull constant buffers to 16
  bytes, consistent with the hardware's behavior.

 I'd prefer to see the 15 written as (16 - 1) just to clarify that it's a
 value-minus-one field, similarly to how we do the
 OUT_BATCH(_3DSTATE_CONSTANT_PS  16 | (7 - 2)); for the length field of
 packets.


Ok, I'll do that.  Is that a reviewed-by with this change?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] Clean up GL3 status

2012-01-11 Thread Matt Turner
Signed-off-by: Matt Turner matts...@gmail.com
---
 docs/GL3.txt |   78 +-
 1 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 0c67dce..069d36d 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -12,47 +12,47 @@ Feature   Status
 
 GL 3.0:
 
-GLSL 1.30 (GL_EXT_gpu_shader4, etc.)  started
+GLSL 1.30 DONE
 glBindFragDataLocation, glGetFragDataLocation DONE
-Conditional rendering (GL_NV_conditional_render)  DONE (swrast, softpipe, 
i965)
-Map buffer subranges (GL_ARB_map_buffer_range)DONE
-Clamping controls (GL_ARB_color_buffer_float) DONE
-Float textures, renderbuffers (GL_ARB_texture_float)  DONE (gallium r300)
-GL_EXT_packed_float   DONE (gallium r600)
-GL_EXT_texture_shared_exponentDONE (gallium, swrast)
-Float depth buffers (GL_ARB_depth_buffer_float)   DONE
-Framebuffer objects (GL_EXT_framebuffer_object)   DONE
+Conditional rendering (GL_NV_conditional_render)  DONE (i965, r600, swrast)
+Map buffer subranges (GL_ARB_map_buffer_range)DONE (i965, r600, swrast)
+Clamping controls (GL_ARB_color_buffer_float) DONE (i965, r600)
+Float textures, renderbuffers (GL_ARB_texture_float)  DONE (i965, r600)
+GL_EXT_packed_float   DONE (i965, r600)
+GL_EXT_texture_shared_exponentDONE (i965, r600, swrast)
+Float depth buffers (GL_ARB_depth_buffer_float)   DONE (i965, r600)
+Framebuffer objects (GL_EXT_framebuffer_object)   DONE (i965, r600, swrast)
 Half-floatDONE
 Multisample blit  DONE
 Non-normalized Integer texture/framebuffer formats~50% done
-1D/2D Texture arrays  DONE (gallium, swrast)
+1D/2D Texture arrays  DONE
 Packed depth/stencil formats  DONE
-Per-buffer blend and masks (GL_EXT_draw_buffers2) DONE
-GL_EXT_texture_compression_rgtc   DONE (swrast, gallium 
r600)
-Red and red/green texture formats DONE (swrast, i965, 
gallium)
-Transform feedback (GL_EXT_transform_feedback)DONE
-Vertex array objects (GL_APPLE_vertex_array_object)   DONE
-sRGB framebuffer format (GL_EXT_framebuffer_sRGB) core GL done (i965, 
gallium), GLX todo
+Per-buffer blend and masks (GL_EXT_draw_buffers2) DONE (i965, r600, swrast)
+GL_EXT_texture_compression_rgtc   DONE (i965, r600, swrast)
+Red and red/green texture formats DONE (i965, swrast, 
gallium)
+Transform feedback (GL_EXT_transform_feedback)DONE (i965)
+Vertex array objects (GL_APPLE_vertex_array_object)   DONE (i965, r600, swrast)
+sRGB framebuffer format (GL_EXT_framebuffer_sRGB) DONE (i965, r600)
 glClearBuffer commandsDONE
 glGetStringi command  DONE
 glTexParameterI, glGetTexParameterI commands  DONE
 glVertexAttribI commands  DONE (but converts int
 values to floats)
-Depth format cube texturesnot started
-GLX_ARB_create_context (GLX 1.4 is required)  not started
+Depth format cube texturesDONE
+GLX_ARB_create_context (GLX 1.4 is required)  DONE
 
 
 GL 3.1:
 
 GLSL 1.40 not started
 Instanced drawing (GL_ARB_draw_instanced) DONE (gallium, swrast)
-Buffer copying (GL_ARB_copy_buffer)   DONE
-Primitive restart (GL_NV_primitive_restart)   DONE (gallium)
+Buffer copying (GL_ARB_copy_buffer)   DONE (i965, r600, swrast)
+Primitive restart (GL_NV_primitive_restart)   DONE (r600)
 16 vertex texture image units DONE
 Texture buffer objs (GL_ARB_texture_buffer_object)not started
-Rectangular textures (GL_ARB_texture_rectangle)   DONE
+Rectangular textures (GL_ARB_texture_rectangle)   DONE (i965, r600, swrast)
 Uniform buffer objs (GL_ARB_uniform_buffer_object)not started
-Signed normalized textures (GL_EXT_texture_snorm) DONE (gallium)
+Signed normalized textures (GL_EXT_texture_snorm) DONE (i965, r600)
 
 
 GL 3.2:
@@ -60,36 +60,36 @@ GL 3.2:
 Core/compatibility profiles   not started
 GLSL 1.50 not started
 Geometry shaders (GL_ARB_geometry_shader4)partially done (Zack)
-BGRA vertex order (GL_ARB_vertex_array_bgra)  DONE
-Base vertex offset(GL_ARB_draw_elements_base_vertex)  DONE
-Frag shader coord (GL_ARB_fragment_coord_conventions) DONE (swrast, gallium)

Re: [Mesa-dev] [PATCH 3/3] mesa: Stop calling ProgramStringNotify when SamplerUnits changes.

2012-01-11 Thread Eric Anholt
On Wed, 11 Jan 2012 01:55:46 -0800, Kenneth Graunke kenn...@whitecape.org 
wrote:
 This rather rudely told the driver the moral equivalent of Your shader
 code changed in an unimaginable way---don't assume anything; recompile!
 
 The i965 driver used to rely on this in order to recompile the program
 when SamplerUnits changed.  It now properly listens to _NEW_PROGRAM and
 _NEW_TEXTURE, which this code flags, and does the right thing.
 
 According to Marek, st/mesa doesn't need nor want a ProgramStringNotify
 here.  The classic radeon, r200, and nouveau drivers don't use the
 SamplerUnits array, so they should be unaffected.
 
 (Unfortunately I think i915 may still rely on this :( Ian/Eric, can you
  confirm or deny that?  It doesn't seem to have any of the program
  caching, which seems rather horrible...)

Yes, it is horrible.  But this patch will break it -- it's relying on
i915ProgramStringNotify to trigger p-translated = 0 to do a recompile.
Minimally, i915_update_program() could set it to 0 until we do the
caching right.


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


Re: [Mesa-dev] [PATCH] configure.ac: add and use AC_PROG_BISON/FLEX macros

2012-01-11 Thread Eric Anholt
On Wed, 11 Jan 2012 01:16:18 -0500, Matt Turner matts...@gmail.com wrote:
 Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
 easier while still specifically requiring bison and flex.
 
 Based on bison.m4 and flex.m4 found in LLVM's tree.

Copying stuff from their tree without noting the license? :(


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


Re: [Mesa-dev] [PATCH] configure.ac: don't set HAVE_GTEST twice

2012-01-11 Thread Ian Romanick

On 01/10/2012 10:16 PM, Matt Turner wrote:

Signed-off-by: Matt Turnermatts...@gmail.com


Reviewed-by: Ian Romanick ian.d.roman...@intel.com


---
  configure.ac |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index 08a0209..d36901b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -69,7 +69,6 @@ AC_PATH_PROG([GTESTCONFIG], [gtest-config])
  if test x$GTESTCONFIG != x; then
  GTEST_CFLAGS=`gtest-config --cppflags --cxxflags`
  GTEST_LIBS=`gtest-config --ldflags --libs`
-HAVE_GTEST=1
  AC_SUBST([GTEST_CFLAGS])
  AC_SUBST([GTEST_LIBS])
  HAVE_GTEST=yes


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


Re: [Mesa-dev] [PATCH] mesa: Make ffs/ffsl conditions match popcount ones.

2012-01-11 Thread Brian Paul

On 01/11/2012 01:13 PM, Kenneth Graunke wrote:

On 01/11/2012 12:02 PM, Eric Anholt wrote:

On Tue, 10 Jan 2012 23:08:51 -0600, Alexander von
Gluckkallis...@unixzen.com wrote:


- Ensure mesa code uses the _mesa_ffs(l) functions
consistantly instead of jumping around between ffs
and _mesa_ffs
- This makes ffs/ffsl behave more like the popcount code
- Better detects and handles edge cases of missing ffs/ffsl
- Use builtin ffs/ffsl more often as it may provide
performance improvements


We intentionally don't use those mesa wrappers in our code. If you have
a portability issue where they're not present on your platform, please
define them on your platform instead of making people use some other
function.


In other words, I think the preference is to use the ffs/ffsl names
everywhere, and never call _mesa_ffs. On platforms that don't
natively support ffs, Mesa would provide the implementation of ffs.



Alexander, I should have told you to do this from the start.

I'll post a patch which cleans up the ffs stuff and removes _mesa_ffs. 
 Please fix it as needed for your platform.  Thanks.


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


Re: [Mesa-dev] [PATCH 2/2] i965: Set pitch of pull constant buffers to 16.

2012-01-11 Thread Eric Anholt
On Wed, 11 Jan 2012 12:26:43 -0800, Paul Berry stereotype...@gmail.com wrote:
 On 11 January 2012 12:23, Eric Anholt e...@anholt.net wrote:
 
  On Wed, 11 Jan 2012 12:06:37 -0800, Paul Berry stereotype...@gmail.com
  wrote:
   We always access pull constant buffers using the message types OWord
   Block Read or OWord Dual Block Read.  According to the Sandy Bridge
   PRM, Vol 4 Part 1, pages 214 and 218, when using these messages:
  
   the surface pitch is ignored, the surface is treated as a
   1-dimensional surface.  An element size (pitch) of 16 bytes is
   used to determine the size of the buffer for out-of-bounds
   checking if using the surface state model.
  
   Previously we were setting the pitch for pull constant buffers to the
   size of the whole constant buffer--this made no sense and would have
   led to incorrect behavior if it were not for the fact that the pitch
   is ignored.
  
   For clarity, this patch sets the pitch for pull constant buffers to 16
   bytes, consistent with the hardware's behavior.
 
  I'd prefer to see the 15 written as (16 - 1) just to clarify that it's a
  value-minus-one field, similarly to how we do the
  OUT_BATCH(_3DSTATE_CONSTANT_PS  16 | (7 - 2)); for the length field of
  packets.
 
 
 Ok, I'll do that.  Is that a reviewed-by with this change?

Yeah.


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


[Mesa-dev] [PATCH] mesa: remove _mesa_ffs(), implement ffs() for non-GNU platforms

2012-01-11 Thread Brian Paul
Call ffs() and ffsll() everywhere.  Define our own ffs(), ffsll()
functions when the platform doesn't have them.
---
 src/mesa/drivers/dri/i965/brw_wm_emit.c  |   12 ++--
 src/mesa/drivers/dri/i965/brw_wm_fp.c|4 ++--
 src/mesa/drivers/dri/intel/intel_blit.c  |2 +-
 src/mesa/drivers/dri/intel/intel_clear.c |2 +-
 src/mesa/main/arrayobj.c |2 +-
 src/mesa/main/bitset.h   |2 +-
 src/mesa/main/buffers.c  |4 ++--
 src/mesa/main/ff_fragment_shader.cpp |2 +-
 src/mesa/main/ffvertex_prog.c|2 +-
 src/mesa/main/imports.c  |   11 ++-
 src/mesa/main/imports.h  |   21 -
 src/mesa/main/shaderapi.c|2 +-
 src/mesa/program/prog_print.c|4 ++--
 src/mesa/swrast/s_texture.c  |4 ++--
 14 files changed, 35 insertions(+), 39 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_emit.c 
b/src/mesa/drivers/dri/i965/brw_wm_emit.c
index 270e321..2647a38 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_emit.c
@@ -766,7 +766,7 @@ void emit_dp2(struct brw_compile *p,
  const struct brw_reg *arg0,
  const struct brw_reg *arg1)
 {
-   int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
 
if (!(mask  WRITEMASK_XYZW))
   return; /* Do not emit dead code */
@@ -787,7 +787,7 @@ void emit_dp3(struct brw_compile *p,
  const struct brw_reg *arg0,
  const struct brw_reg *arg1)
 {
-   int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
 
if (!(mask  WRITEMASK_XYZW))
   return; /* Do not emit dead code */
@@ -809,7 +809,7 @@ void emit_dp4(struct brw_compile *p,
  const struct brw_reg *arg0,
  const struct brw_reg *arg1)
 {
-   int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
 
if (!(mask  WRITEMASK_XYZW))
   return; /* Do not emit dead code */
@@ -832,7 +832,7 @@ void emit_dph(struct brw_compile *p,
  const struct brw_reg *arg0,
  const struct brw_reg *arg1)
 {
-   const int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   const int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
 
if (!(mask  WRITEMASK_XYZW))
   return; /* Do not emit dead code */
@@ -882,7 +882,7 @@ void emit_math1(struct brw_wm_compile *c,
 {
struct brw_compile *p = c-func;
struct intel_context *intel = p-brw-intel;
-   int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
GLuint saturate = ((mask  SATURATE) ?
  BRW_MATH_SATURATE_SATURATE :
  BRW_MATH_SATURATE_NONE);
@@ -945,7 +945,7 @@ void emit_math2(struct brw_wm_compile *c,
 {
struct brw_compile *p = c-func;
struct intel_context *intel = p-brw-intel;
-   int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
 
if (!(mask  WRITEMASK_XYZW))
   return; /* Do not emit dead code */
diff --git a/src/mesa/drivers/dri/i965/brw_wm_fp.c 
b/src/mesa/drivers/dri/i965/brw_wm_fp.c
index 1358e74..b40c501 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_fp.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_fp.c
@@ -159,7 +159,7 @@ static struct prog_dst_register dst_undef( void )
 
 static struct prog_dst_register get_temp( struct brw_wm_compile *c )
 {
-   int bit = _mesa_ffs( ~c-fp_temp );
+   int bit = ffs( ~c-fp_temp );
 
if (!bit) {
   printf(%s: out of temporaries\n, __FILE__);
@@ -260,7 +260,7 @@ static struct prog_instruction *emit_scalar_insn(struct 
brw_wm_compile *c,
if (inst0-DstReg.WriteMask == 0)
   return NULL;
 
-   dst_chan = _mesa_ffs(inst0-DstReg.WriteMask) - 1;
+   dst_chan = ffs(inst0-DstReg.WriteMask) - 1;
inst = get_fp_inst(c);
*inst = *inst0;
inst-DstReg.WriteMask = 1  dst_chan;
diff --git a/src/mesa/drivers/dri/intel/intel_blit.c 
b/src/mesa/drivers/dri/intel/intel_blit.c
index 1369e63..e484fd3 100644
--- a/src/mesa/drivers/dri/intel/intel_blit.c
+++ b/src/mesa/drivers/dri/intel/intel_blit.c
@@ -261,7 +261,7 @@ intelClearWithBlit(struct gl_context *ctx, GLbitfield mask)
/* Loop over all renderbuffers */
mask = (1  BUFFER_COUNT) - 1;
while (mask) {
-  GLuint buf = _mesa_ffs(mask) - 1;
+  GLuint buf = ffs(mask) - 1;
   bool is_depth_stencil = buf == BUFFER_DEPTH || buf == BUFFER_STENCIL;
   struct intel_renderbuffer *irb;
   int x1, y1, x2, y2;
diff --git a/src/mesa/drivers/dri/intel/intel_clear.c 
b/src/mesa/drivers/dri/intel/intel_clear.c
index e60fa66..dee4956 100644
--- a/src/mesa/drivers/dri/intel/intel_clear.c
+++ b/src/mesa/drivers/dri/intel/intel_clear.c
@@ -171,7 +171,7 @@ intelClear(struct gl_context *ctx, GLbitfield mask)
 * buffer with it.
 */
if 

Re: [Mesa-dev] [PATCH 1/2] i965 gen4-6: Fix off-by-one errors brw_create_constant_surface()

2012-01-11 Thread Kenneth Graunke

On 01/11/2012 12:06 PM, Paul Berry wrote:

Commit 9bdc44a52804a64219a0ca1a061b18596863e524 (i965: Replace struct
with bit shifting for WM pull constant surfaces) accidentally
introduced off-by-one errors into the calculation of the surface
width, height, and depth.  This patch restores the correct
computation.

The reason this wasn't noticed by Piglit tests is that the size of our
constant surfaces is always less than 2^20, therefore the off-by-one
error was causing the depth field of the surface to be set to all
1's.  The hardware interpreted this as an extremely large surface, so
overflow checking was effectively disabled.

No Piglit regressions on Sandy Bridge.

NOTE: This is a candidate for the 7.11 and 8.0 branches.
---
  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index dedf594..b40f5e1 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -698,10 +698,10 @@ brw_create_constant_surface(struct brw_context *brw,

 surf[1] = bo-offset; /* reloc */

-   surf[2] = (((w  0x7f) - 1)  BRW_SURFACE_WIDTH_SHIFT |
- (((w  7)  0x1fff) - 1)  BRW_SURFACE_HEIGHT_SHIFT);
+   surf[2] = ((w  0x7f)  BRW_SURFACE_WIDTH_SHIFT |
+ ((w  7)  0x1fff)  BRW_SURFACE_HEIGHT_SHIFT);

-   surf[3] = w  20)  0x7f) - 1)  BRW_SURFACE_DEPTH_SHIFT |
+   surf[3] = (((w  20)  0x7f)  BRW_SURFACE_DEPTH_SHIFT |
  (width * 16 - 1)  BRW_SURFACE_PITCH_SHIFT);

 surf[4] = 0;


Yeah, from reading the simulator, these -1's are clearly wrong.

Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] i965: Set pitch of pull constant buffers to 16.

2012-01-11 Thread Kenneth Graunke

On 01/11/2012 12:06 PM, Paul Berry wrote:

We always access pull constant buffers using the message types OWord
Block Read or OWord Dual Block Read.  According to the Sandy Bridge
PRM, Vol 4 Part 1, pages 214 and 218, when using these messages:

 the surface pitch is ignored, the surface is treated as a
 1-dimensional surface.  An element size (pitch) of 16 bytes is
 used to determine the size of the buffer for out-of-bounds
 checking if using the surface state model.

Previously we were setting the pitch for pull constant buffers to the
size of the whole constant buffer--this made no sense and would have
led to incorrect behavior if it were not for the fact that the pitch
is ignored.

For clarity, this patch sets the pitch for pull constant buffers to 16
bytes, consistent with the hardware's behavior.

No piglit regressions on Sandy Bridge or Ivy Bridge.
---
  src/mesa/drivers/dri/i965/brw_wm_surface_state.c  |2 +-
  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)


I find it hilarious that you've managed to justify why (16 - 1) is the 
obviously correct value for an unused field. :)  Consider me convinced.


Like Eric, I also prefer (16 - 1).

Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: remove _mesa_ffs(), implement ffs() for non-GNU platforms

2012-01-11 Thread Kenneth Graunke

On 01/11/2012 12:50 PM, Brian Paul wrote:

Call ffs() and ffsll() everywhere.  Define our own ffs(), ffsll()
functions when the platform doesn't have them.


Looks great, Brian.  Thanks!

Reviewed-by: Kenneth Graunke kenn...@whitecape.org

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


[Mesa-dev] [PATCH] Revert i965: Replace references to stencil region size with buffer size

2012-01-11 Thread Chad Versace
This reverts commit bebc91f0f3a1f2d19d36a7f1a4f7c992ace064e9.

Fixes the following Piglit regressions on gen7:
spec/ARB_depth_buffer_float/fbo-clear-formats
spec/ARB_depth_texture/fbo-clear-formats
spec/EXT_packed_depth_stencil/fbo-clear-formats

I mistakenly thought that depth_rb-Width and depth_irb-mt-region-width
were identical. But of course they're not when there are multiple images
in the miptree.

To fix the compile, the commit below is also reverted:
commit 254b24f19511014cdf4741b73d69349ac9e931a2.
i965: Fix compiler warnings from hiz changes

CC: Eric Anholt e...@anholt.net
CC: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
 src/mesa/drivers/dri/i965/brw_misc_state.c  |   10 ++
 src/mesa/drivers/dri/i965/gen7_misc_state.c |8 
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index f9652df..1c0c52b 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -330,6 +330,8 @@ static void emit_depthbuffer(struct brw_context *brw)
* Section 7.5.5.1.1 3DSTATE_DEPTH_BUFFER, Bit 1.27 Tiled Surface:
* [DevGT+]: This field must be set to TRUE.
*/
+  struct intel_region *region = stencil_mt-region;
+
   assert(intel-has_separate_stencil);
 
   BEGIN_BATCH(len);
@@ -341,8 +343,8 @@ static void emit_depthbuffer(struct brw_context *brw)
(1  27) | /* tiled surface */
(BRW_SURFACE_2D  29));
   OUT_BATCH(0);
-  OUT_BATCH(((stencil_irb-Base.Width - 1)  6) |
-(stencil_irb-Base.Height - 1)  19);
+  OUT_BATCH(((region-width - 1)  6) |
+(2 * region-height - 1)  19);
   OUT_BATCH(0);
   OUT_BATCH(0);
 
@@ -376,8 +378,8 @@ static void emit_depthbuffer(struct brw_context *brw)
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
offset);
   OUT_BATCH((BRW_SURFACE_MIPMAPLAYOUT_BELOW  1) |
-   ((depth_irb-Base.Width - 1)  6) |
-   ((depth_irb-Base.Height - 1)  19));
+   ((region-width - 1)  6) |
+   ((region-height - 1)  19));
   OUT_BATCH(0);
 
   if (intel-is_g4x || intel-gen = 5)
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c 
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 8a383f5..b1ea66b 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -69,13 +69,14 @@ static void emit_depthbuffer(struct brw_context *brw)
   if (stencil_mt == NULL) {
 dw1 |= (BRW_SURFACE_NULL  29);
   } else {
+struct intel_region *region = stencil_mt-region;
+
 /* _NEW_STENCIL: enable stencil buffer writes */
 dw1 |= ((ctx-Stencil.WriteMask != 0)  27);
 
 /* 3DSTATE_STENCIL_BUFFER inherits surface type and dimensions. */
 dw1 |= (BRW_SURFACE_2D  29);
-dw3 = ((srb-Base.Width - 1)  4) |
-  ((srb-Base.Height - 1)  18);
+dw3 = ((region-width - 1)  4) | ((2 * region-height - 1)  18);
   }
 
   BEGIN_BATCH(7);
@@ -107,8 +108,7 @@ static void emit_depthbuffer(struct brw_context *brw)
   OUT_RELOC(region-bo,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
offset);
-  OUT_BATCH(((drb-Base.Width - 1)  4) |
-((drb-Base.Height - 1)  18));
+  OUT_BATCH(((region-width - 1)  4) | ((region-height - 1)  18));
   OUT_BATCH(0);
   OUT_BATCH(tile_x | (tile_y  16));
   OUT_BATCH(0);
-- 
1.7.7.4

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


Re: [Mesa-dev] [PATCH] mesa: remove _mesa_ffs(), implement ffs() for non-GNU platforms

2012-01-11 Thread Brian Paul

On 01/11/2012 02:14 PM, Kenneth Graunke wrote:

On 01/11/2012 12:50 PM, Brian Paul wrote:

Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.


Looks great, Brian. Thanks!

Reviewed-by: Kenneth Graunke kenn...@whitecape.org


I'm not going to push this until Alexander can verify that it's OK on 
his platform too.


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


[Mesa-dev] [PATCH] mesa: Remove unused opengl version macros

2012-01-11 Thread Jakob Bornecrantz
Found this while preparing for the release, couldn't find
any users of this.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 src/mesa/main/version.h |   13 +
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/src/mesa/main/version.h b/src/mesa/main/version.h
index d288c4d..c1f4e8e 100644
--- a/src/mesa/main/version.h
+++ b/src/mesa/main/version.h
@@ -35,24 +35,13 @@ struct gl_context;
 #define MESA_MAJOR 8
 #define MESA_MINOR 0
 #define MESA_PATCH 0
-#define MESA_VERSION_STRING 8.0-devel
+#define MESA_VERSION_STRING 8.0-rc1
 
 /* To make version comparison easy */
 #define MESA_VERSION(a,b,c) (((a)  16) + ((b)  8) + (c))
 #define MESA_VERSION_CODE MESA_VERSION(MESA_MAJOR, MESA_MINOR, MESA_PATCH)
 
 
-/* OpenGL API version */
-#define OPENGL_MAJOR 2
-#define OPENGL_MINOR 1
-#define OPENGL_PATCH 0
-#define OPENGL_VERSION_STRING 2.1
-
-/* To make version comparison easy */
-#define OPENGL_VERSION(a,b,c) (((a)  16) + ((b)  8) + (c))
-#define OPENGL_VERSION_CODE OPENGL_VERSION(OPENGL_MAJOR, OPENGL_MINOR, 
OPENGL_PATCH)
-
-
 extern void
 _mesa_compute_version(struct gl_context *ctx);
 
-- 
1.7.5.4

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


Re: [Mesa-dev] [PATCH] mesa: Remove unused opengl version macros

2012-01-11 Thread Jakob Bornecrantz
- Original Message -
 Found this while preparing for the release, couldn't find
 any users of this.
 
 Signed-off-by: Jakob Bornecrantz ja...@vmware.com
 ---
  src/mesa/main/version.h |   13 +
  1 files changed, 1 insertions(+), 12 deletions(-)
 
 diff --git a/src/mesa/main/version.h b/src/mesa/main/version.h
 index d288c4d..c1f4e8e 100644
 --- a/src/mesa/main/version.h
 +++ b/src/mesa/main/version.h
 @@ -35,24 +35,13 @@ struct gl_context;
  #define MESA_MAJOR 8
  #define MESA_MINOR 0
  #define MESA_PATCH 0
 -#define MESA_VERSION_STRING 8.0-devel
 +#define MESA_VERSION_STRING 8.0-rc1

Ops, this shouldn't be here, must have pressed 'a' instead of 'y'
git adding.

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


Re: [Mesa-dev] [PATCH] mesa: Remove unused opengl version macros

2012-01-11 Thread Brian Paul

On 01/11/2012 03:02 PM, Jakob Bornecrantz wrote:

- Original Message -

Found this while preparing for the release, couldn't find
any users of this.

Signed-off-by: Jakob Bornecrantzja...@vmware.com
---
  src/mesa/main/version.h |   13 +
  1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/src/mesa/main/version.h b/src/mesa/main/version.h
index d288c4d..c1f4e8e 100644
--- a/src/mesa/main/version.h
+++ b/src/mesa/main/version.h
@@ -35,24 +35,13 @@ struct gl_context;
  #define MESA_MAJOR 8
  #define MESA_MINOR 0
  #define MESA_PATCH 0
-#define MESA_VERSION_STRING 8.0-devel
+#define MESA_VERSION_STRING 8.0-rc1


Ops, this shouldn't be here, must have pressed 'a' instead of 'y'
git adding.


Looks good otherwise.

Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: remove _mesa_ffs(), implement ffs() for non-GNU platforms

2012-01-11 Thread Alexander von Gluck

On 11.01.2012 15:19, Brian Paul wrote:

On 01/11/2012 02:14 PM, Kenneth Graunke wrote:

On 01/11/2012 12:50 PM, Brian Paul wrote:

Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.


Looks great, Brian. Thanks!

Reviewed-by: Kenneth Graunke kenn...@whitecape.org


I'm not going to push this until Alexander can verify that it's OK on his 
platform too.


Will verify ASAP.

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


[Mesa-dev] [PATCH] i965/hiz: Don't bind GL_DRAW_FRAMEBUFFER on GLES

2012-01-11 Thread Chad Versace
From: Neil Roberts n...@linux.intel.com

When using Mesa with a GLES API, calling _mesa_FramebufferRenderbuffer
with GL_DRAW_FRAMEBUFFER will report a 'user error' because
get_framebuffer_target validates that this enum from the framebuffer
blit extension is only used on GL. To work around it this patch makes
it use the GL_FRAMEBUFFER enum instead in that case.

[chad]: Make comments more concise. Change the if-condition to be
compatible with a core context, which may not advertise old extensions.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43418
CC: Neil Roberts n...@linux.intel.com
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
 src/mesa/drivers/dri/i965/gen6_hiz.c |   37 +
 1 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen6_hiz.c 
b/src/mesa/drivers/dri/i965/gen6_hiz.c
index e282511..4428777 100644
--- a/src/mesa/drivers/dri/i965/gen6_hiz.c
+++ b/src/mesa/drivers/dri/i965/gen6_hiz.c
@@ -109,6 +109,27 @@ static const uint32_t gen6_hiz_meta_save =
 
   MESA_META_SELECT_FEEDBACK;
 
+static void
+gen6_hiz_get_framebuffer_enum(struct gl_context *ctx,
+  GLenum *bind_enum,
+  GLenum *get_enum)
+{
+   if (ctx-VersionMajor = 3
+   || ctx-Extensions.EXT_framebuffer_blit) {
+  /* Different buffers may be bound to the read and draw framebuffers. Take
+   * care not to disrupt the readbuffer.
+   */
+  *bind_enum = GL_DRAW_FRAMEBUFFER;
+  *get_enum = GL_DRAW_FRAMEBUFFER_BINDING;
+   } else {
+  /* The enums GL_DRAW_FRAMEBUFFER and GL_READ_FRAMEBUFFER do not exist.
+   * The bound framebuffer is both the read and draw buffer.
+   */
+  *bind_enum = GL_FRAMEBUFFER;
+  *get_enum = GL_FRAMEBUFFER_BINDING;
+   }
+}
+
 /**
  * Initialize static data needed for HiZ operations.
  */
@@ -117,10 +138,13 @@ gen6_hiz_init(struct brw_context *brw)
 {
struct gl_context *ctx = brw-intel.ctx;
struct brw_hiz_state *hiz = brw-hiz;
+   GLenum fb_bind_enum, fb_get_enum;
 
if (hiz-fbo != 0)
   return;
 
+   gen6_hiz_get_framebuffer_enum(ctx, fb_bind_enum, fb_get_enum);
+
/* Create depthbuffer.
 *
 * Until glRenderbufferStorage is called, the renderbuffer hash table
@@ -139,8 +163,8 @@ gen6_hiz_init(struct brw_context *brw)
 
/* Setup FBO. */
_mesa_GenFramebuffersEXT(1, hiz-fbo);
-   _mesa_BindFramebufferEXT(GL_DRAW_FRAMEBUFFER, hiz-fbo);
-   _mesa_FramebufferRenderbufferEXT(GL_DRAW_FRAMEBUFFER,
+   _mesa_BindFramebufferEXT(fb_bind_enum, hiz-fbo);
+   _mesa_FramebufferRenderbufferEXT(fb_bind_enum,
 GL_DEPTH_ATTACHMENT,
 GL_RENDERBUFFER,
 hiz-depth_rb-Name);
@@ -241,6 +265,7 @@ gen6_resolve_slice(struct intel_context *intel,
struct gl_context *ctx = intel-ctx;
struct brw_context *brw = brw_context(ctx);
struct brw_hiz_state *hiz = brw-hiz;
+   GLenum fb_bind_enum, fb_get_enum;
 
/* Do not recurse. */
assert(!brw-hiz.op);
@@ -250,11 +275,13 @@ gen6_resolve_slice(struct intel_context *intel,
assert(level = mt-last_level);
assert(layer  mt-level[level].depth);
 
+   gen6_hiz_get_framebuffer_enum(ctx, fb_bind_enum, fb_get_enum);
+
/* Save state. */
GLint save_drawbuffer;
GLint save_renderbuffer;
_mesa_meta_begin(ctx, gen6_hiz_meta_save);
-   _mesa_GetIntegerv(GL_DRAW_FRAMEBUFFER_BINDING, save_drawbuffer);
+   _mesa_GetIntegerv(fb_get_enum, save_drawbuffer);
_mesa_GetIntegerv(GL_RENDERBUFFER_BINDING, save_renderbuffer);
 
/* Initialize context data for HiZ operations. */
@@ -272,7 +299,7 @@ gen6_resolve_slice(struct intel_context *intel,
 
/* Setup FBO. */
gen6_hiz_setup_depth_buffer(brw, mt, level, layer);
-   _mesa_BindFramebufferEXT(GL_DRAW_FRAMEBUFFER, hiz-fbo);
+   _mesa_BindFramebufferEXT(fb_bind_enum, hiz-fbo);
 
 
/* A rectangle primitive (3DPRIM_RECTLIST) consists of only three vertices.
@@ -316,7 +343,7 @@ gen6_resolve_slice(struct intel_context *intel,
 */
gen6_hiz_teardown_depth_buffer(hiz-depth_rb);
_mesa_BindRenderbufferEXT(GL_RENDERBUFFER, save_renderbuffer);
-   _mesa_BindFramebufferEXT(GL_DRAW_FRAMEBUFFER, save_drawbuffer);
+   _mesa_BindFramebufferEXT(fb_bind_enum, save_drawbuffer);
_mesa_meta_end(ctx);
 }
 
-- 
1.7.7.4

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


[Mesa-dev] [PATCH 1/5] meta: Add GL_RED/GL_RG support to meta CopyTexImage.

2012-01-11 Thread Eric Anholt
Fixes some _mesa_problem()s in oglconform.
---
 src/mesa/drivers/common/meta.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index ad289aa..e4aced4 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3071,6 +3071,8 @@ get_temp_image_type(struct gl_context *ctx, GLenum 
baseFormat)
switch (baseFormat) {
case GL_RGBA:
case GL_RGB:
+   case GL_RG:
+   case GL_RED:
case GL_ALPHA:
case GL_LUMINANCE:
case GL_LUMINANCE_ALPHA:
@@ -3086,7 +3088,8 @@ get_temp_image_type(struct gl_context *ctx, GLenum 
baseFormat)
case GL_DEPTH_STENCIL:
   return GL_UNSIGNED_INT_24_8;
default:
-  _mesa_problem(ctx, Unexpected format in get_temp_image_type());
+  _mesa_problem(ctx, Unexpected format %d in get_temp_image_type(),
+   baseFormat);
   return 0;
}
 }
-- 
1.7.7.3

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


[Mesa-dev] [PATCH 3/5] mesa: Throw the required error for glReadPixels() from a multisampled FBO.

2012-01-11 Thread Eric Anholt
Fixes piglit EXT_framebuffer_multisample-negative-readpixels.
---
 src/mesa/main/readpix.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 0c0e539..c1489d2 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -782,6 +782,11 @@ _mesa_ReadnPixelsARB( GLint x, GLint y, GLsizei width, 
GLsizei height,
   return;
}
 
+   if (ctx-ReadBuffer-Name != 0  ctx-ReadBuffer-Visual.samples  0) {
+  _mesa_error(ctx, GL_INVALID_OPERATION, glReadPixels(multisample FBO));
+  return;
+   }
+
if (!_mesa_source_buffer_exists(ctx, format)) {
   _mesa_error(ctx, GL_INVALID_OPERATION, glReadPixels(no readbuffer));
   return;
-- 
1.7.7.3

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


[Mesa-dev] [PATCH 4/5] mesa: Throw the required error for glCopyTex{Sub, }Image from multisample FBO.

2012-01-11 Thread Eric Anholt
Fixes piglit EXT_framebuffer_multisample/negative-copyteximage.
---
 src/mesa/main/teximage.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 9475e84..d5e462b 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1909,6 +1909,13 @@ copytexture_error_check( struct gl_context *ctx, GLuint 
dimensions,
  glCopyTexImage%dD(invalid readbuffer), dimensions);
  return GL_TRUE;
   }
+
+  if (ctx-ReadBuffer-Visual.samples  0) {
+_mesa_error(ctx, GL_INVALID_FRAMEBUFFER_OPERATION,
+glCopyTexImage%dD(multisample FBO),
+dimensions);
+return GL_TRUE;
+  }
}
 
/* Check border */
@@ -2008,6 +2015,13 @@ copytexsubimage_error_check1( struct gl_context *ctx, 
GLuint dimensions,
  glCopyTexImage%dD(invalid readbuffer), dimensions);
  return GL_TRUE;
   }
+
+  if (ctx-ReadBuffer-Visual.samples  0) {
+_mesa_error(ctx, GL_INVALID_FRAMEBUFFER_OPERATION,
+glCopyTexSubImage%dD(multisample FBO),
+dimensions);
+return GL_TRUE;
+  }
}
 
/* check target (proxies not allowed) */
-- 
1.7.7.3

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


[Mesa-dev] [PATCH 5/5] mesa: Throw the required error for glCopyPixels from multisample FBO.

2012-01-11 Thread Eric Anholt
Fixes piglit EXT_framebuffer_multisample/negative-copypixels.
---
 src/mesa/main/drawpix.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index 9f5b0b3..01983d9 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/drawpix.c
@@ -203,6 +203,12 @@ _mesa_CopyPixels( GLint srcx, GLint srcy, GLsizei width, 
GLsizei height,
   goto end;
}
 
+   if (ctx-ReadBuffer-Name != 0  ctx-ReadBuffer-Visual.samples  0) {
+  _mesa_error(ctx, GL_INVALID_FRAMEBUFFER_OPERATION,
+ glCopyPixels(multisample FBO));
+  goto end;
+   }
+
if (!_mesa_source_buffer_exists(ctx, type) ||
!_mesa_dest_buffer_exists(ctx, type)) {
   _mesa_error(ctx, GL_INVALID_OPERATION,
-- 
1.7.7.3

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


[Mesa-dev] [PATCH] Always build shared glapi

2012-01-11 Thread Matt Turner
---
No one on IRC knows why an unshared glapi is useful.

Does anyone have a use-case for this?

If not, we can drop it to simplify automake work.

 configs/autoconf.in |1 -
 configure.ac|   24 +---
 src/egl/drivers/dri2/Android.mk |1 -
 src/egl/drivers/dri2/Makefile   |4 
 src/egl/drivers/dri2/egl_dri2.c |8 
 src/gallium/targets/egl-static/Makefile |7 ---
 src/gallium/targets/libgl-xlib/Makefile |2 --
 src/glx/Makefile|3 ---
 src/glx/SConscript  |3 ---
 src/glx/glxcmds.c   |2 --
 src/glx/indirect.c  |4 
 src/glx/indirect.h  |3 ---
 src/mapi/glapi/Makefile |   13 -
 src/mapi/glapi/gen/glX_proto_send.py|6 --
 src/mesa/drivers/x11/Makefile   |2 --
 15 files changed, 1 insertions(+), 82 deletions(-)

diff --git a/configs/autoconf.in b/configs/autoconf.in
index 9ea7588..3e5da79 100644
--- a/configs/autoconf.in
+++ b/configs/autoconf.in
@@ -15,7 +15,6 @@ ASM_FLAGS = @ASM_FLAGS@
 PIC_FLAGS = @PIC_FLAGS@
 DEFINES = @DEFINES@
 API_DEFINES = @API_DEFINES@
-SHARED_GLAPI = @SHARED_GLAPI@
 CFLAGS_NOVISIBILITY = @CPPFLAGS@ @CFLAGS@ \
$(OPT_FLAGS) $(PIC_FLAGS) $(ARCH_FLAGS) $(ASM_FLAGS) $(DEFINES)
 CXXFLAGS_NOVISIBILITY = @CPPFLAGS@ @CXXFLAGS@ \
diff --git a/configure.ac b/configure.ac
index e2302de..3f8b6b6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -706,18 +706,6 @@ if test x$enable_gles2 = xyes; then
 fi
 AC_SUBST([API_DEFINES])
 
-AC_ARG_ENABLE([shared-glapi],
-[AS_HELP_STRING([--enable-shared-glapi],
-[EXPERIMENTAL.  Enable shared glapi for OpenGL @:@default=no@:@])],
-[enable_shared_glapi=$enableval],
-[enable_shared_glapi=no])
-
-SHARED_GLAPI=0
-if test x$enable_shared_glapi = xyes; then
-SHARED_GLAPI=1
-fi
-AC_SUBST([SHARED_GLAPI])
-
 dnl
 dnl Driver configuration. Options are xlib, dri and osmesa right now.
 dnl More later: fbdev, ...
@@ -801,7 +789,7 @@ dnl Driver specific build directories
 dnl
 
 dnl this variable will be prepended to SRC_DIRS and is not exported
-CORE_DIRS=
+CORE_DIRS=mapi/shared-glapi
 
 SRC_DIRS=
 GLU_DIRS=sgi
@@ -811,13 +799,6 @@ GALLIUM_WINSYS_DIRS=sw
 GALLIUM_DRIVERS_DIRS=galahad trace rbug noop identity
 GALLIUM_STATE_TRACKERS_DIRS=
 
-# build shared-glapi if enabled for OpenGL or if OpenGL ES is enabled
-case x$enable_shared_glapi$enable_gles1$enable_gles2 in
-x*yes*)
-CORE_DIRS=$CORE_DIRS mapi/shared-glapi
-;;
-esac
-
 # build glapi if OpenGL is enabled
 if test x$enable_opengl = xyes; then
 CORE_DIRS=$CORE_DIRS mapi/glapi
@@ -1363,9 +1344,6 @@ if test x$enable_gbm = xyes; then
 
 if test x$enable_dri = xyes; then
 GBM_BACKEND_DIRS=$GBM_BACKEND_DIRS dri
-if test $SHARED_GLAPI -eq 0; then
-AC_MSG_ERROR([gbm_dri requires --enable-shared-glapi])
-fi
 fi
 fi
 AC_SUBST([GBM_LIB_DEPS])
diff --git a/src/egl/drivers/dri2/Android.mk b/src/egl/drivers/dri2/Android.mk
index 5c506f8..b120c95 100644
--- a/src/egl/drivers/dri2/Android.mk
+++ b/src/egl/drivers/dri2/Android.mk
@@ -34,7 +34,6 @@ LOCAL_SRC_FILES := \
 LOCAL_CFLAGS := \
-D_EGL_MAIN=_eglBuiltInDriverDRI2 \
-DDEFAULT_DRIVER_DIR=\/system/lib/dri\ \
-   -DHAVE_SHARED_GLAPI \
-DHAVE_ANDROID_PLATFORM
 
 LOCAL_C_INCLUDES := \
diff --git a/src/egl/drivers/dri2/Makefile b/src/egl/drivers/dri2/Makefile
index d2b1f4f..5780510 100644
--- a/src/egl/drivers/dri2/Makefile
+++ b/src/egl/drivers/dri2/Makefile
@@ -21,10 +21,6 @@ EGL_LIBS = $(LIBUDEV_LIBS) $(DLOPEN_LIBS) $(LIBDRM_LIB)
 EGL_CFLAGS = -D_EGL_MAIN=_eglBuiltInDriverDRI2
 EGL_BUILTIN = true
 
-ifeq ($(SHARED_GLAPI),1)
-EGL_CFLAGS += -DHAVE_SHARED_GLAPI
-endif
-
 ifneq ($(findstring x11, $(EGL_PLATFORMS)),)
 EGL_SOURCES += platform_x11.c
 EGL_INCLUDES += -DHAVE_X11_PLATFORM $(XCB_DRI2_CFLAGS)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 80b2e38..a320f35 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1362,19 +1362,11 @@ static EGLBoolean
 dri2_load(_EGLDriver *drv)
 {
struct dri2_egl_driver *dri2_drv = dri2_egl_driver(drv);
-#ifdef HAVE_SHARED_GLAPI
 #ifdef HAVE_ANDROID_PLATFORM
const char *libname = libglapi.so;
 #else
const char *libname = libglapi.so.0;
 #endif
-#else
-   /*
-* Both libGL.so and libglapi.so are glapi providers.  There is no way to
-* tell which one to load.
-*/
-   const char *libname = NULL;
-#endif
void *handle;
 
/* RTLD_GLOBAL to make sure glapi symbols are visible to DRI drivers */
diff --git a/src/gallium/targets/egl-static/Makefile 
b/src/gallium/targets/egl-static/Makefile
index 79a098a..9e87774 100644
--- a/src/gallium/targets/egl-static/Makefile
+++ b/src/gallium/targets/egl-static/Makefile
@@ -8,7 +8,6 @@
 #   EGL_PLATFORMS  

[Mesa-dev] [PATCH] mesa: Include glx tests Makefile.in in tarball

2012-01-11 Thread Jakob Bornecrantz
Fix suggested by Kenneth Graunke.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 Makefile |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 4a41948..1fa369a 100644
--- a/Makefile
+++ b/Makefile
@@ -191,6 +191,8 @@ PACKAGE_NAME = MesaLib-$(PACKAGE_VERSION)
 EXTRA_FILES = \
aclocal.m4  \
configure   \
+   tests/Makefile.in   \
+   tests/glx/Makefile.in   \
src/glsl/glsl_parser.cpp\
src/glsl/glsl_parser.h  \
src/glsl/glsl_lexer.cpp \
-- 
1.7.5.4

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


[Mesa-dev] [PATCH] i965/gen7: Fix depth buffer rendering to tile offsets.

2012-01-11 Thread Eric Anholt
Previously, we were saying that everything from the starting tile to
region width+height was part of the limits of our depthbuffer, even if
the tile was near the bottom of the depthbuffer.  This mean that our
range was not clipping to buffer buonds if the start tile was anything
but the start of the buffer.

In bebc91f0f3a1f2d19d36a7f1a4f7c992ace064e9, this was changed to
saying that we're just rendering to a region of the size of the
renderbuffer.  This is great -- we get a range that should actually
match what we want.  However, the hardware's range checking occurs
after the X/Y offset addition, so we were clipping out rendering to
small depth mip levels when an X/Y offset was present.  Just add
tile_x/y to the width in that case -- the WM won't produce negative
x/y values pre-offset, so we just need to get the left/bottom sides of
the region to cover our buffer.

Fixes piglit fbo-clear-formats GL_ARB_depth_buffer_float on gen7.
(Full test run not completed yet because of memory leaks in master)
---
 src/mesa/drivers/dri/i965/brw_misc_state.c  |4 ++--
 src/mesa/drivers/dri/i965/gen7_misc_state.c |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index f9652df..b6bca4b 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -376,8 +376,8 @@ static void emit_depthbuffer(struct brw_context *brw)
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
offset);
   OUT_BATCH((BRW_SURFACE_MIPMAPLAYOUT_BELOW  1) |
-   ((depth_irb-Base.Width - 1)  6) |
-   ((depth_irb-Base.Height - 1)  19));
+   (((depth_irb-Base.Width + tile_x)- 1)  6) |
+   (((depth_irb-Base.Height + tile_y) - 1)  19));
   OUT_BATCH(0);
 
   if (intel-is_g4x || intel-gen = 5)
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c 
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 8a383f5..c2f58d5 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -107,8 +107,8 @@ static void emit_depthbuffer(struct brw_context *brw)
   OUT_RELOC(region-bo,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
offset);
-  OUT_BATCH(((drb-Base.Width - 1)  4) |
-((drb-Base.Height - 1)  18));
+  OUT_BATCHdrb-Base.Width + tile_x) - 1)  4) |
+(((drb-Base.Height + tile_y) - 1)  18));
   OUT_BATCH(0);
   OUT_BATCH(tile_x | (tile_y  16));
   OUT_BATCH(0);
-- 
1.7.7.3

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


Re: [Mesa-dev] [PATCH] mesa: Include glx tests Makefile.in in tarball

2012-01-11 Thread Kenneth Graunke

On 01/11/2012 03:37 PM, Jakob Bornecrantz wrote:

Fix suggested by Kenneth Graunke.

Signed-off-by: Jakob Bornecrantzja...@vmware.com
---
  Makefile |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 4a41948..1fa369a 100644
--- a/Makefile
+++ b/Makefile
@@ -191,6 +191,8 @@ PACKAGE_NAME = MesaLib-$(PACKAGE_VERSION)
  EXTRA_FILES = \
aclocal.m4  \
configure   \
+   tests/Makefile.in   \
+   tests/glx/Makefile.in   \
src/glsl/glsl_parser.cpp\
src/glsl/glsl_parser.h  \
src/glsl/glsl_lexer.cpp \


Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Always build shared glapi

2012-01-11 Thread Jakob Bornecrantz
On Thu, Jan 12, 2012 at 12:37 AM, Matt Turner matts...@gmail.com wrote:
 ---
 No one on IRC knows why an unshared glapi is useful.

 Does anyone have a use-case for this?

 If not, we can drop it to simplify automake work.

I tried searching on gmail as to why this was added, but I turned up
nothing. Maybe Chia-I Wu knows.

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


[Mesa-dev] [PATCH] Remove -ffast-math from default CFLAGS

2012-01-11 Thread Matt Turner
Fixes glsl-const-folding-01. inversesqrt(1.0) != 1.0 was evaluating as
true.

Signed-off-by: Matt Turner matts...@gmail.com
---
I think softpipe also had some problems recently due to -ffast-math?

 configure.ac |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 3f8b6b6..7461f28 100644
--- a/configure.ac
+++ b/configure.ac
@@ -168,9 +168,6 @@ esac
 dnl Add flags for gcc and g++
 if test x$GCC = xyes; then
 CFLAGS=$CFLAGS -Wall -Wmissing-prototypes -std=c99
-if test x$CLANG = xno; then
-   CFLAGS=$CFLAGS -ffast-math
-fi
 
 # Enable -fvisibility=hidden if using a gcc that supports it
 save_CFLAGS=$CFLAGS
-- 
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] Remove -ffast-math from default CFLAGS

2012-01-11 Thread Egon Ashrafinia
2012/1/12 Matt Turner matts...@gmail.com

 Fixes glsl-const-folding-01. inversesqrt(1.0) != 1.0 was evaluating as
 true.

 Signed-off-by: Matt Turner matts...@gmail.com
 ---
 I think softpipe also had some problems recently due to -ffast-math?

  configure.ac |3 ---
  1 files changed, 0 insertions(+), 3 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 3f8b6b6..7461f28 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -168,9 +168,6 @@ esac
  dnl Add flags for gcc and g++
  if test x$GCC = xyes; then
 CFLAGS=$CFLAGS -Wall -Wmissing-prototypes -std=c99
 -if test x$CLANG = xno; then
 -   CFLAGS=$CFLAGS -ffast-math
 -fi

 # Enable -fvisibility=hidden if using a gcc that supports it
 save_CFLAGS=$CFLAGS
 --
 1.7.3.4

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


+1

I we are going to change this, then please also do so in the currend ( new
opened ) 8.0 branch as it will fix bugs.

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


[Mesa-dev] Mesa 8.0 branch made.

2012-01-11 Thread Jakob Bornecrantz
Hi all

So after much building and testing I finally made the branch. I was planning on 
doing a rc1 release now as well but it looks like historically we have opened 
the branch and then made the first rc release a short time after, so I'm 
holding of on it.

If people want a RC release ASAP I can do that as well, I will probably do one 
during the weekend anyways.

When cherry picking to this branch please make sure you include a reference 
back to the master commit. Easiest to do this is with git cherry-pick -x -e 
commit which will also let you edit the commit message. As I was hoping to 
automate the NOTE: candidate for branch tracking and without the commit 
sha1 that would be hard.

Thanks to everybody who made Mesa get to GL3.0, now on to bug fixing.

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


Re: [Mesa-dev] [PATCH] Always build shared glapi

2012-01-11 Thread Chia-I Wu
On Thu, Jan 12, 2012 at 7:47 AM, Jakob Bornecrantz wallbra...@gmail.com wrote:
 On Thu, Jan 12, 2012 at 12:37 AM, Matt Turner matts...@gmail.com wrote:
 ---
 No one on IRC knows why an unshared glapi is useful.

 Does anyone have a use-case for this?

 If not, we can drop it to simplify automake work.

 I tried searching on gmail as to why this was added, but I turned up
 nothing. Maybe Chia-I Wu knows.
Shared glapi adds libglapi.so.  Weird things could happen when
libGL.so and libglapi.so are from different versions of Mesa.

But it is more a problem for distros to deal with.  If we all agree on
that, I am happy to see shared glapi always on.

 Cheers, Jakob.



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


[Mesa-dev] [PATCH] Avoid null pointer dereference when glXSwapBuffers is called with no bound context

2012-01-11 Thread Anuj Phogat
Calling glXSwapBuffers with no bound context causes segmentation fault in
function intelDRI2Flush. All the gl calls should be ignored after setting the
current context to null. So the contents of framebuffer stay unchanged.
But the driver should not seg fault.

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

Reported-by: Yi Sun yi@intel.com
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
 src/mesa/drivers/dri/intel/intel_screen.c |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_screen.c 
b/src/mesa/drivers/dri/intel/intel_screen.c
index ce96ddd..03c2a1e 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -115,13 +115,15 @@ intelDRI2Flush(__DRIdrawable *drawable)
GET_CURRENT_CONTEXT(ctx);
struct intel_context *intel = intel_context(ctx);
 
-   if (intel-gen  4)
-  INTEL_FIREVERTICES(intel);
+   if (intel != NULL) {
+  if (intel-gen  4)
+INTEL_FIREVERTICES(intel);
 
-   intel-need_throttle = true;
+  intel-need_throttle = true;
 
-   if (intel-batch.used)
-  intel_batchbuffer_flush(intel);
+  if (intel-batch.used)
+intel_batchbuffer_flush(intel);
+   }
 }
 
 static const struct __DRI2flushExtensionRec intelFlushExtension = {
-- 
1.7.7.4

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


[Mesa-dev] [PATCH] gallium: improve the pipe_stream_output_info struct (v2)

2012-01-11 Thread Marek Olšák
There are 3 changes:

1) stride is specified for each buffer, not just one, so that drivers don't
   have to derive it from the outputs

2) new per-output property dst_offset, which specifies the offset
   into the buffer in dwords where the output should be stored,
   so that drivers don't have to compute the offsets manually;
   this will also be useful for gl_SkipComponents
   from ARB_transform_feedback3

3) register_mask is removed, instead, there is start_component
   and num_components; register_mask with non-consecutive 1s
   doesn't make much sense (some hardware cannot do packing of components)

Christoph Bumiller: fixed nvc0.

v2: resolve merge conflicts in Draw and clean it up
---
 src/gallium/auxiliary/draw/draw_pt_so_emit.c |   87 +++---
 src/gallium/auxiliary/util/u_blitter.c   |4 +-
 src/gallium/auxiliary/util/u_dump_state.c|6 +-
 src/gallium/drivers/llvmpipe/lp_state_so.c   |2 +-
 src/gallium/drivers/nvc0/nvc0_program.c  |   11 +--
 src/gallium/drivers/r600/r600.h  |4 +-
 src/gallium/drivers/r600/r600_hw_context.c   |8 +-
 src/gallium/drivers/r600/r600_pipe.h |1 -
 src/gallium/drivers/r600/r600_shader.c   |   46 --
 src/gallium/drivers/r600/r600_state_common.c |2 +-
 src/gallium/drivers/trace/tr_dump_state.c|6 +-
 src/gallium/include/pipe/p_state.h   |   13 +++--
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp   |   18 ++---
 13 files changed, 57 insertions(+), 151 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pt_so_emit.c 
b/src/gallium/auxiliary/draw/draw_pt_so_emit.c
index 466f46a..ecf287f 100644
--- a/src/gallium/auxiliary/draw/draw_pt_so_emit.c
+++ b/src/gallium/auxiliary/draw/draw_pt_so_emit.c
@@ -79,72 +79,6 @@ void draw_pt_so_emit_prepare(struct pt_so_emit *emit)
draw_do_flush( draw, DRAW_FLUSH_BACKEND );
 }
 
-static boolean
-is_component_writable(unsigned mask,
-  unsigned compo)
-{
-   switch (mask) {
-   case TGSI_WRITEMASK_NONE:
-  return FALSE;
-   case TGSI_WRITEMASK_X:
-  return compo == 0;
-   case TGSI_WRITEMASK_Y:
-  return compo == 1;
-   case TGSI_WRITEMASK_XY:
-  return compo == 0 || compo == 1;
-   case TGSI_WRITEMASK_Z:
-  return compo == 2;
-   case TGSI_WRITEMASK_XZ:
-  return compo == 0 || compo == 2;
-   case TGSI_WRITEMASK_YZ:
-  return compo == 1 || compo == 2;
-   case TGSI_WRITEMASK_XYZ:
-  return compo == 0 || compo == 1 || compo == 2;
-   case TGSI_WRITEMASK_W:
-  return compo == 3;
-   case TGSI_WRITEMASK_XW:
-  return compo == 0 || compo == 3;
-   case TGSI_WRITEMASK_YW:
-  return compo == 1 || compo == 3;
-   case TGSI_WRITEMASK_XYW:
-  return compo == 0 || compo == 1 || compo == 3;
-   case TGSI_WRITEMASK_ZW:
-  return compo == 2 || compo == 3;
-   case TGSI_WRITEMASK_XZW:
-  return compo == 0 || compo == 1 || compo == 3;
-   case TGSI_WRITEMASK_YZW:
-  return compo == 1 || compo == 2 || compo == 4;
-   case TGSI_WRITEMASK_XYZW:
-  return compo  4;
-   default:
-  debug_assert(!Unknown writemask in stream out);
-  return compo  4;
-   }
-}
-
-static INLINE int mask_num_comps(int register_mask)
-{
-   int comps = 0;
-   switch (register_mask) {
-   case TGSI_WRITEMASK_XYZW:
-  comps = 4;
-  break;
-   case TGSI_WRITEMASK_XYZ:
-  comps = 3;
-  break;
-   case TGSI_WRITEMASK_XY:
-  comps = 2;
-  break;
-   case TGSI_WRITEMASK_X:
-  comps = 1;
-  break;
-   default:
-  assert(0);
-  break;
-   }
-   return comps;
-}
-
 static void so_emit_prim(struct pt_so_emit *so,
  unsigned *indices,
  unsigned num_vertices)
@@ -170,14 +104,14 @@ static void so_emit_prim(struct pt_so_emit *so,
/* check have we space to emit prim first - if not don't do anything */
for (i = 0; i  num_vertices; ++i) {
   for (slot = 0; slot  state-num_outputs; ++slot) {
- unsigned writemask = state-output[slot].register_mask;
+ unsigned num_comps = state-output[slot].num_components;
  int ob = state-output[slot].output_buffer;
 
- if ((buffer_total_bytes[ob] + mask_num_comps(writemask) * 
sizeof(float)) 
+ if ((buffer_total_bytes[ob] + num_comps * sizeof(float)) 
  draw-so.targets[ob]-target.buffer_size) {
 return;
  }
- buffer_total_bytes[ob] += mask_num_comps(writemask) * sizeof(float);
+ buffer_total_bytes[ob] += num_comps * sizeof(float);
   }
}
 
@@ -190,21 +124,16 @@ static void so_emit_prim(struct pt_so_emit *so,
 
   for (slot = 0; slot  state-num_outputs; ++slot) {
  unsigned idx = state-output[slot].register_index;
- unsigned writemask = state-output[slot].register_mask;
- unsigned written_compos = 0;
- unsigned compo;
+ unsigned start_comp = state-output[slot].start_component;
+ unsigned num_comps = 

Re: [Mesa-dev] [PATCH] Avoid null pointer dereference when glXSwapBuffers is called with no bound context

2012-01-11 Thread Brian Paul

On 01/11/2012 06:06 PM, Anuj Phogat wrote:

Calling glXSwapBuffers with no bound context causes segmentation fault in
function intelDRI2Flush. All the gl calls should be ignored after setting the
current context to null. So the contents of framebuffer stay unchanged.
But the driver should not seg fault.

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

Reported-by: Yi Sunyi@intel.com
Signed-off-by: Anuj Phogatanuj.pho...@gmail.com
---
  src/mesa/drivers/dri/intel/intel_screen.c |   12 +++-
  1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_screen.c 
b/src/mesa/drivers/dri/intel/intel_screen.c
index ce96ddd..03c2a1e 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -115,13 +115,15 @@ intelDRI2Flush(__DRIdrawable *drawable)
 GET_CURRENT_CONTEXT(ctx);
 struct intel_context *intel = intel_context(ctx);

-   if (intel-gen  4)
-  INTEL_FIREVERTICES(intel);
+   if (intel != NULL) {
+  if (intel-gen  4)
+INTEL_FIREVERTICES(intel);

-   intel-need_throttle = true;
+  intel-need_throttle = true;

-   if (intel-batch.used)
-  intel_batchbuffer_flush(intel);
+  if (intel-batch.used)
+intel_batchbuffer_flush(intel);
+   }
  }

  static const struct __DRI2flushExtensionRec intelFlushExtension = {


Someone from Intel should probably review this, but in the future 
please prefix your commit message with the component being changed. 
And try to keep lines in your commit message under 76 characters:


For example, something like:

intel: fix glXSwapBuffers crash when there's no context

Thanks.

-Brian

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


Re: [Mesa-dev] [PATCH] vbo: introduce vbo_get_minmax_indices function

2012-01-11 Thread Brian Paul

On 01/11/2012 01:17 AM, Yuanhan Liu wrote:

On Tue, Jan 10, 2012 at 08:43:18PM -0700, Brian Paul wrote:

On Tue, Jan 3, 2012 at 8:59 PM, Yuanhan Liuyuanhan@linux.intel.com  wrote:

On Wed, Jan 04, 2012 at 11:20:07AM +0800, Yuanhan Liu wrote:

On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:

Ah index scanning...
I don't like that this will map/unmap the ib once for each prim,

Me either :)


though

[snip]..

+vbo_get_minmax_indices(struct gl_context *ctx,
+   const struct _mesa_prim *prims,
+   const struct _mesa_index_buffer *ib,
+   GLuint *min_index,
+   GLuint *max_index,
+   GLuint nr_prims)
+{
+   struct _mesa_prim start_prim;


I think you could use a pointer for start_prim:

const struct _mesa_prim *start_prim;

to avoid copying 20 bytes per loop iteration below.  The declaration
could also be moved inside the loop.


Aha, yes. I should do this. Thanks, here is the updated patch:

 From 66f309648a20736c932eb1d393ca7cad6679532a Mon Sep 17 00:00:00 2001
From: Yuanhan Liuyuanhan@linux.intel.com
Date: Sat, 31 Dec 2011 14:22:46 +0800
Subject: [PATCH] vbo: introduce vbo_get_minmax_indices function

Introduce vbo_get_minmax_indices() function to handle the min/max index
computation for nr_prims(= 1). The old code just compute the first
prim's min/max index; this would results an error rendering if user
called functions like glMultiDrawElements(). This patch servers as
fixing this issue.

As when nr_prims = 1, we can pass 1 to paramter nr_prims, thus I made
vbo_get_minmax_index() static.

v2: per Roland's suggestion, put the indices address compuation into
 vbo_get_minmax_index() instead.

 Also do comination if possible to reduce map/unmap count

v3: per Brian's suggestion, use a pointer for start_prim to avoid
 structure copy per loop.

Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com
Reviewed-by: Roland Scheideggersrol...@vmware.com
Reviewed-by: Brian Paulbri...@vmware.com
---
  src/mesa/drivers/dri/i965/brw_draw.c |2 +-
  src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c |3 +-
  src/mesa/main/api_validate.c |2 +-
  src/mesa/state_tracker/st_draw.c |3 +-
  src/mesa/state_tracker/st_draw_feedback.c|2 +-
  src/mesa/tnl/t_draw.c|2 +-
  src/mesa/vbo/vbo.h   |6 ++--
  src/mesa/vbo/vbo_exec_array.c|   50 +
  8 files changed, 53 insertions(+), 17 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 621195d..f50fffd 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -586,7 +586,7 @@ void brw_draw_prims( struct gl_context *ctx,

 if (!vbo_all_varyings_in_vbos(arrays)) {
if (!index_bounds_valid)
-vbo_get_minmax_index(ctx, prim, ib,min_index,max_index);
+vbo_get_minmax_indices(ctx, prim, ib,min_index,max_index, nr_prims);

/* Decide if we want to rebase.  If so we end up recursing once
 * only into this function.
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c 
b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
index de04d18..59f1542 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
@@ -437,7 +437,8 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
struct nouveau_render_state *render = to_render_state(ctx);

if (!index_bounds_valid)
-   vbo_get_minmax_index(ctx, prims, ib,min_index,max_index);
+   vbo_get_minmax_indices(ctx, prims, ib,min_index,max_index,
+  nr_prims);

vbo_choose_render_mode(ctx, arrays);
vbo_choose_attrs(ctx, arrays);
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 945f127..b6871d0 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -184,7 +184,7 @@ check_index_bounds(struct gl_context *ctx, GLsizei count, 
GLenum type,
 ib.ptr = indices;
 ib.obj = ctx-Array.ArrayObj-ElementArrayBufferObj;

-   vbo_get_minmax_index(ctx,prim,ib,min,max);
+   vbo_get_minmax_indices(ctx,prim,ib,min,max, 1);

 if ((int)(min + basevertex)  0 ||
 max + basevertex  ctx-Array.ArrayObj-_MaxElement) {
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 6d6fc85..c0554cf 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -990,7 +990,8 @@ st_draw_vbo(struct gl_context *ctx,
/* Gallium probably doesn't want this in some cases. */
if (!index_bounds_valid)
   if (!all_varyings_in_vbos(arrays))
-vbo_get_minmax_index(ctx, prims, ib,min_index,max_index);
+vbo_get_minmax_indices(ctx, prims, ib,min_index,max_index,
+  

[Mesa-dev] [PATCH] mesa: update compute_version for GL3

2012-01-11 Thread Marek Olšák
only check ARB_fbo, add shader_texture_lod as a requirement
---
 src/mesa/main/version.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 49cdc30..38ae1ce 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -130,16 +130,14 @@ compute_version(struct gl_context *ctx)
   ctx-Extensions.ARB_half_float_pixel 
   ctx-Extensions.ARB_half_float_vertex 
   ctx-Extensions.ARB_map_buffer_range 
+  ctx-Extensions.ARB_shader_texture_lod 
   ctx-Extensions.ARB_texture_float 
   ctx-Extensions.ARB_texture_rg 
   ctx-Extensions.ARB_texture_compression_rgtc 
   ctx-Extensions.APPLE_vertex_array_object 
   ctx-Extensions.EXT_draw_buffers2 
-  ctx-Extensions.EXT_framebuffer_blit 
-  ctx-Extensions.EXT_framebuffer_multisample 
-  ctx-Extensions.EXT_framebuffer_object 
+  ctx-Extensions.ARB_framebuffer_object 
   ctx-Extensions.EXT_framebuffer_sRGB 
-  ctx-Extensions.EXT_packed_depth_stencil 
   ctx-Extensions.EXT_packed_float 
   ctx-Extensions.EXT_texture_array 
   ctx-Extensions.EXT_texture_integer 
-- 
1.7.5.4

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


Re: [Mesa-dev] [PATCH] mesa: remove _mesa_ffs(), implement ffs() for non-GNU platforms

2012-01-11 Thread Alexander von Gluck

On 11.01.2012 14:50, Brian Paul wrote:

Call ffs() and ffsll() everywhere.  Define our own ffs(), ffsll()
functions when the platform doesn't have them.
---
 src/mesa/main/imports.c  |   11 ++-



diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 2469e42..b3d56db 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -458,7 +458,7 @@ _mesa_inv_sqrtf(float n)
  * Find the first bit set in a word.
  */
 int
-_mesa_ffs(int32_t i)
+ffs(int i)
 {
 #if (defined(_WIN32) ) || defined(__IBMC__) || defined(__IBMCPP__)


This seems like a bad idea... infinite recursion.
ffs calls itself if it's non-gnuc and !WIN  !IBM.

This is why I changed everything to call _mesa_ffs.
Otherwise it does seem to work ok under Haiku as we don't fall into
that trap.

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


Re: [Mesa-dev] [PATCH] mesa: remove _mesa_ffs(), implement ffs() for non-GNU platforms

2012-01-11 Thread Brian Paul

On 01/11/2012 08:06 PM, Alexander von Gluck wrote:

On 11.01.2012 14:50, Brian Paul wrote:

Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
---
src/mesa/main/imports.c | 11 ++-



diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 2469e42..b3d56db 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -458,7 +458,7 @@ _mesa_inv_sqrtf(float n)
* Find the first bit set in a word.
*/
int
-_mesa_ffs(int32_t i)
+ffs(int i)
{
#if (defined(_WIN32) ) || defined(__IBMC__) || defined(__IBMCPP__)


This seems like a bad idea... infinite recursion.
ffs calls itself if it's non-gnuc and !WIN  !IBM.


That was an oversight and not intentional.



This is why I changed everything to call _mesa_ffs.
Otherwise it does seem to work ok under Haiku as we don't fall into
that trap.


I'll post a v2 of the patch.  Would you mind testing again?

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


[Mesa-dev] [PATCH] mesa: remove _mesa_ffs(), implement ffs() for non-GNU platforms

2012-01-11 Thread Brian Paul
Call ffs() and ffsll() everywhere.  Define our own ffs(), ffsll()
functions when the platform doesn't have them.

v2: remove #ifdef _WIN32, __IBMC__, __IBMCPP_ tests inside ffs()
implementation.  The #else clause was recursive.
---
 src/mesa/drivers/dri/i965/brw_wm_emit.c  |   12 ++--
 src/mesa/drivers/dri/i965/brw_wm_fp.c|4 ++--
 src/mesa/drivers/dri/intel/intel_blit.c  |2 +-
 src/mesa/drivers/dri/intel/intel_clear.c |2 +-
 src/mesa/main/arrayobj.c |2 +-
 src/mesa/main/bitset.h   |2 +-
 src/mesa/main/buffers.c  |4 ++--
 src/mesa/main/ff_fragment_shader.cpp |2 +-
 src/mesa/main/ffvertex_prog.c|2 +-
 src/mesa/main/imports.c  |   15 ++-
 src/mesa/main/imports.h  |   21 -
 src/mesa/main/shaderapi.c|1 +
 src/mesa/program/prog_print.c|4 ++--
 src/mesa/swrast/s_texture.c  |4 ++--
 14 files changed, 35 insertions(+), 42 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_emit.c 
b/src/mesa/drivers/dri/i965/brw_wm_emit.c
index 270e321..2647a38 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_emit.c
@@ -766,7 +766,7 @@ void emit_dp2(struct brw_compile *p,
  const struct brw_reg *arg0,
  const struct brw_reg *arg1)
 {
-   int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
 
if (!(mask  WRITEMASK_XYZW))
   return; /* Do not emit dead code */
@@ -787,7 +787,7 @@ void emit_dp3(struct brw_compile *p,
  const struct brw_reg *arg0,
  const struct brw_reg *arg1)
 {
-   int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
 
if (!(mask  WRITEMASK_XYZW))
   return; /* Do not emit dead code */
@@ -809,7 +809,7 @@ void emit_dp4(struct brw_compile *p,
  const struct brw_reg *arg0,
  const struct brw_reg *arg1)
 {
-   int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
 
if (!(mask  WRITEMASK_XYZW))
   return; /* Do not emit dead code */
@@ -832,7 +832,7 @@ void emit_dph(struct brw_compile *p,
  const struct brw_reg *arg0,
  const struct brw_reg *arg1)
 {
-   const int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   const int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
 
if (!(mask  WRITEMASK_XYZW))
   return; /* Do not emit dead code */
@@ -882,7 +882,7 @@ void emit_math1(struct brw_wm_compile *c,
 {
struct brw_compile *p = c-func;
struct intel_context *intel = p-brw-intel;
-   int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
GLuint saturate = ((mask  SATURATE) ?
  BRW_MATH_SATURATE_SATURATE :
  BRW_MATH_SATURATE_NONE);
@@ -945,7 +945,7 @@ void emit_math2(struct brw_wm_compile *c,
 {
struct brw_compile *p = c-func;
struct intel_context *intel = p-brw-intel;
-   int dst_chan = _mesa_ffs(mask  WRITEMASK_XYZW) - 1;
+   int dst_chan = ffs(mask  WRITEMASK_XYZW) - 1;
 
if (!(mask  WRITEMASK_XYZW))
   return; /* Do not emit dead code */
diff --git a/src/mesa/drivers/dri/i965/brw_wm_fp.c 
b/src/mesa/drivers/dri/i965/brw_wm_fp.c
index 1358e74..b40c501 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_fp.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_fp.c
@@ -159,7 +159,7 @@ static struct prog_dst_register dst_undef( void )
 
 static struct prog_dst_register get_temp( struct brw_wm_compile *c )
 {
-   int bit = _mesa_ffs( ~c-fp_temp );
+   int bit = ffs( ~c-fp_temp );
 
if (!bit) {
   printf(%s: out of temporaries\n, __FILE__);
@@ -260,7 +260,7 @@ static struct prog_instruction *emit_scalar_insn(struct 
brw_wm_compile *c,
if (inst0-DstReg.WriteMask == 0)
   return NULL;
 
-   dst_chan = _mesa_ffs(inst0-DstReg.WriteMask) - 1;
+   dst_chan = ffs(inst0-DstReg.WriteMask) - 1;
inst = get_fp_inst(c);
*inst = *inst0;
inst-DstReg.WriteMask = 1  dst_chan;
diff --git a/src/mesa/drivers/dri/intel/intel_blit.c 
b/src/mesa/drivers/dri/intel/intel_blit.c
index 1369e63..e484fd3 100644
--- a/src/mesa/drivers/dri/intel/intel_blit.c
+++ b/src/mesa/drivers/dri/intel/intel_blit.c
@@ -261,7 +261,7 @@ intelClearWithBlit(struct gl_context *ctx, GLbitfield mask)
/* Loop over all renderbuffers */
mask = (1  BUFFER_COUNT) - 1;
while (mask) {
-  GLuint buf = _mesa_ffs(mask) - 1;
+  GLuint buf = ffs(mask) - 1;
   bool is_depth_stencil = buf == BUFFER_DEPTH || buf == BUFFER_STENCIL;
   struct intel_renderbuffer *irb;
   int x1, y1, x2, y2;
diff --git a/src/mesa/drivers/dri/intel/intel_clear.c 
b/src/mesa/drivers/dri/intel/intel_clear.c
index e60fa66..dee4956 100644
--- a/src/mesa/drivers/dri/intel/intel_clear.c
+++ 

Re: [Mesa-dev] [PATCH] mesa: remove _mesa_ffs(), implement ffs() for non-GNU platforms

2012-01-11 Thread Alexander von Gluck

On 11.01.2012 21:11, Brian Paul wrote:

On 01/11/2012 08:06 PM, Alexander von Gluck wrote:

On 11.01.2012 14:50, Brian Paul wrote:

Call ffs() and ffsll() everywhere. Define our own ffs(), ffsll()
functions when the platform doesn't have them.
---
src/mesa/main/imports.c | 11 ++-



diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 2469e42..b3d56db 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -458,7 +458,7 @@ _mesa_inv_sqrtf(float n)
* Find the first bit set in a word.
*/
int
-_mesa_ffs(int32_t i)
+ffs(int i)
{
#if (defined(_WIN32) ) || defined(__IBMC__) || defined(__IBMCPP__)


This seems like a bad idea... infinite recursion.
ffs calls itself if it's non-gnuc and !WIN  !IBM.


That was an oversight and not intentional.



This is why I changed everything to call _mesa_ffs.
Otherwise it does seem to work ok under Haiku as we don't fall into
that trap.


I'll post a v2 of the patch.  Would you mind testing again?


Latest code works 100%.  Thanks!

 Think this is a candidate for the 8.0 branch?

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


Re: [Mesa-dev] [PATCH 3/3] mesa: Clean up gl_array_object::_MaxElement computation.

2012-01-11 Thread Mathias Fröhlich

Hi Eric,

Thanks for the review.
I will send shortly an updated patch.

... except:

On Friday, December 30, 2011 12:13:36 Eric Anholt wrote:
 Also, I think that helper would be easier to read as;
 
 +   GLbitfield64 enabled = arrayObj-_Enabled;
 +
 +   if (enabled  VERT_ATTRIB_GENERIC0)
 +  enabled = ~VERT_BIT_POS;
 +
 +   return enabled;

Regarding that, I would agree for readability.
But, I can observe a difference in speed between the two variants. The variant 
with the if is a little slower in average on my particular machine here. It 
appears that fully pipelineable bitfield stuff without the 'if' branch could be 
faster.
This really surprises me that this particular place is visible in speed. But 
since I have seen that I think I will try to keep that.

An other argument for the bitshift variant could be that you do not want to do 
the nv aliasing without that simultanous bitfield trick. So understanding one 
or the other is about the same and one of which is required anyway.

So, if you do require this change I will do, but see the above.

Thanks

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


[Mesa-dev] [PATCH 0/3] Array object Improvement v2

2012-01-11 Thread Mathias Fröhlich
Hi,

Thanks for the first review.

Following a short followup series to the gl_array_object change.
The most important change is the use ot an ffs based loop to compute 
gl_array_object::_MaxElement. This change provides a noticable performance 
improovement for my average workloads.
To implement this, a small set of helper functions is introduced in the patch 
before, to compute the bitmasks of enabled arrays taking into account the 
aliasing rules for the different arrays.
The first patch just makes use of the recently introduced BITFIELD64_RANGE 
macro where it makes sense.

v2: Incorporate review from Brian and Eric.
* Readability improvments.
* State clearly in logs that this changes and actualy fixes something.
* Fix typos.

The complete changeset survives a piglit quick run for r600g/rv770 and swrast 
without regressions.

Regarding the pending ffs platform changes, I will update this change to use 
ffsll directly when the other patch lands upstream.

Please review.
Thanks

Mathias


Mathias Froehlich (1):
  mesa: Use BITFIELD64_RANGE for VERT_BIT_*_ALL.
  mesa: Introduce enabled bitfield helper functions.
  mesa: Fix and speedup gl_array_object::_MaxElement computation.

 src/mesa/main/arrayobj.c |   41 ++-
 src/mesa/main/arrayobj.h |   37 +
 src/mesa/main/mtypes.h   |   14 +++--
 src/mesa/main/state.c|  126 
+-
 4 files changed, 74 insertions(+), 144 deletions(-)

-- 
1.7.7.5

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


[Mesa-dev] [PATCH 1/3] mesa: Use BITFIELD64_RANGE for VERT_BIT_*_ALL.

2012-01-11 Thread Mathias Fröhlich
Signed-off-by: Mathias Fröhlich mathias.froehl...@web.de
---
 src/mesa/main/mtypes.h |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 9fdabf9..b381ad2 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -199,19 +199,19 @@ typedef enum
 #define VERT_BIT_GENERIC0BITFIELD64_BIT(VERT_ATTRIB_GENERIC0)
 
 #define VERT_BIT(i)  BITFIELD64_BIT(i)
-#define VERT_BIT_ALL (BITFIELD64_BIT(VERT_ATTRIB_MAX) - 1)
+#define VERT_BIT_ALL BITFIELD64_RANGE(0, VERT_ATTRIB_MAX)
 
 #define VERT_BIT_FF(i)   VERT_BIT(i)
-#define VERT_BIT_FF_ALL  (BITFIELD64_BIT(VERT_ATTRIB_FF_MAX) - 1)
+#define VERT_BIT_FF_ALL  BITFIELD64_RANGE(0, VERT_ATTRIB_FF_MAX)
 #define VERT_BIT_TEX(i)  VERT_BIT(VERT_ATTRIB_TEX(i))
 #define VERT_BIT_TEX_ALL \
-  ((BITFIELD64_BIT(VERT_ATTRIB_TEX_MAX) - 1)  VERT_ATTRIB_TEX(0))
+   BITFIELD64_RANGE(VERT_ATTRIB_TEX(0), VERT_ATTRIB_TEX_MAX)
 #define VERT_BIT_GENERIC_NV(i)   VERT_BIT(VERT_ATTRIB_GENERIC_NV(i))
 #define VERT_BIT_GENERIC_NV_ALL  \
-  ((BITFIELD64_BIT(VERT_ATTRIB_GENERIC_NV_MAX) - 1)  
(VERT_ATTRIB_GENERIC_NV(0)))
+   BITFIELD64_RANGE(VERT_ATTRIB_GENERIC_NV(0), VERT_ATTRIB_GENERIC_NV_MAX)
 #define VERT_BIT_GENERIC(i)  VERT_BIT(VERT_ATTRIB_GENERIC(i))
 #define VERT_BIT_GENERIC_ALL \
-  ((BITFIELD64_BIT(VERT_ATTRIB_GENERIC_MAX) - 1)  (VERT_ATTRIB_GENERIC(0)))
+   BITFIELD64_RANGE(VERT_ATTRIB_GENERIC(0), VERT_ATTRIB_GENERIC_MAX)
 /*@}*/
 
 
-- 
1.7.7.5

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


[Mesa-dev] [PATCH 2/3] mesa: Introduce enabled bitfield helper functions.

2012-01-11 Thread Mathias Froehlich
Depending on the installed shader type, different arrays are used
from gl_array_object. Provide helper functions that compute
the bitmask of these arrays that are finally enabled for a given
shader type. The will be used in a followup change.

Signed-off-by: Mathias Fröhlich mathias.froehl...@web.de
---
 src/mesa/main/arrayobj.h |   37 +
 src/mesa/main/mtypes.h   |4 
 2 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/arrayobj.h b/src/mesa/main/arrayobj.h
index 0b5a013..717c791 100644
--- a/src/mesa/main/arrayobj.h
+++ b/src/mesa/main/arrayobj.h
@@ -29,6 +29,7 @@
 #define ARRAYOBJ_H
 
 #include glheader.h
+#include mtypes.h
 
 struct gl_context;
 
@@ -64,6 +65,42 @@ extern void
 _mesa_update_array_object_max_element(struct gl_context *ctx,
   struct gl_array_object *arrayObj);
 
+/** Returns the bitmask of all enabled arrays in fixed function mode.
+ *
+ *  In fixed function mode only the traditional fixed function arrays
+ *  are available.
+ */
+static inline GLbitfield64
+_mesa_array_object_get_enabled_ff(const struct gl_array_object *arrayObj)
+{
+   return arrayObj-_Enabled  VERT_BIT_FF_ALL;
+}
+
+/** Returns the bitmask of all enabled arrays in nv shader mode.
+ *
+ *  In nv shader mode, the nv generic arrays take precedence over
+ *  the legacy arrays.
+ */
+static inline GLbitfield64
+_mesa_array_object_get_enabled_nv(const struct gl_array_object *arrayObj)
+{
+   GLbitfield64 enabled = arrayObj-_Enabled;
+   return enabled  ~(VERT_BIT_FF_NVALIAS  (enabled  
VERT_ATTRIB_GENERIC0));
+}
+
+/** Returns the bitmask of all enabled arrays in arb/glsl shader mode.
+ *
+ *  In arb/glsl shader mode all the fixed function and the arb/glsl generic
+ *  arrays are available. Only the first generic array takes
+ *  precedence over the legacy position array.
+ */
+static inline GLbitfield64
+_mesa_array_object_get_enabled_arb(const struct gl_array_object *arrayObj)
+{
+   GLbitfield64 enabled = arrayObj-_Enabled;
+   return enabled  ~(VERT_BIT_POS  (enabled  VERT_ATTRIB_GENERIC0));
+}
+
 
 /*
  * API functions
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index b381ad2..f8ef01d 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -206,9 +206,13 @@ typedef enum
 #define VERT_BIT_TEX(i)  VERT_BIT(VERT_ATTRIB_TEX(i))
 #define VERT_BIT_TEX_ALL \
BITFIELD64_RANGE(VERT_ATTRIB_TEX(0), VERT_ATTRIB_TEX_MAX)
+#define VERT_BIT_FF_NVALIAS  \
+   BITFIELD64_RANGE(VERT_ATTRIB_POS, VERT_ATTRIB_TEX(VERT_ATTRIB_TEX_MAX))
+
 #define VERT_BIT_GENERIC_NV(i)   VERT_BIT(VERT_ATTRIB_GENERIC_NV(i))
 #define VERT_BIT_GENERIC_NV_ALL  \
BITFIELD64_RANGE(VERT_ATTRIB_GENERIC_NV(0), VERT_ATTRIB_GENERIC_NV_MAX)
+
 #define VERT_BIT_GENERIC(i)  VERT_BIT(VERT_ATTRIB_GENERIC(i))
 #define VERT_BIT_GENERIC_ALL \
BITFIELD64_RANGE(VERT_ATTRIB_GENERIC(0), VERT_ATTRIB_GENERIC_MAX)
-- 
1.7.7.5

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


Re: [Mesa-dev] [PATCH] configure.ac: add and use AC_PROG_BISON/FLEX macros

2012-01-11 Thread Gaetan Nadon
On 12-01-11 01:16 AM, Matt Turner wrote:
 Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
 easier while still specifically requiring bison and flex.

 Based on bison.m4 and flex.m4 found in LLVM's tree.

 Signed-off-by: Matt Turner matts...@gmail.com
 ---
  configure.ac |9 -
  m4/bison.m4  |   16 
  m4/flex.m4   |   16 
  3 files changed, 36 insertions(+), 5 deletions(-)
  create mode 100644 m4/bison.m4
  create mode 100644 m4/flex.m4

 diff --git a/configure.ac b/configure.ac
 index 511d147..c0abeb9 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -45,11 +45,10 @@ if test x$MKDEP = x; then
  AC_MSG_ERROR([makedepend is required to build Mesa])
  fi
  
 -AC_PATH_PROG([FLEX], [flex])
 -test x$FLEX = x  AC_MSG_ERROR([flex is needed to build Mesa])
 -
 -AC_PATH_PROG([BISON], [bison])
 -test x$BISON = x  AC_MSG_ERROR([bison is needed to build Mesa])
 +m4_include([m4/bison.m4])
 +AC_PROG_BISON
 +m4_include([m4/flex.m4])
 +AC_PROG_FLEX
  
  dnl Our fallback install-sh is a symlink to minstall. Use the existing
  dnl configuration in that case.
 diff --git a/m4/bison.m4 b/m4/bison.m4
 new file mode 100644
 index 000..641d438
 --- /dev/null
 +++ b/m4/bison.m4
 @@ -0,0 +1,16 @@
 +#
 +# Check for Bison.
 +#
 +# This macro verifies that Bison is installed.  If successful, then
 +# 1) YACC is set to bison -y (to emulate YACC calls)
 +# 2) BISON is set to bison
 +#
 +AC_DEFUN([AC_PROG_BISON],
 +[AC_PROG_YACC()
 +if test $YACC != bison -y; then
This may rule out some tools. In my previous distro I had byacc which I
think was suitable. An alternative is to take what AC_PROG_YACC gives
you and do a feature test to verify that the tool can handle the
special situation for the glx compiler. This concept is used for the
grep command, for example.

 +  AC_SUBST(BISON,[])
 +  AC_MSG_WARN([bison not found])
This will prevent mesa to build from a tarball (./configure) when bison
is not installed. The lex  yacc generated code should be included in
the tarball. Even more important if some platforms don't have the bison
tool you expect.

Check xorg/lib/libxkbcommon. It takes care of all the situations. You
would only need to add the feature test.
 +else
 +  AC_SUBST(BISON,[bison])
 +fi
 +])
 diff --git a/m4/flex.m4 b/m4/flex.m4
 new file mode 100644
 index 000..6a2a004
 --- /dev/null
 +++ b/m4/flex.m4
 @@ -0,0 +1,16 @@
 +#
 +# Check for FLEX.
 +#
 +# This macro verifies that flex is installed.  If successful, then
 +# 1) LEX is set to flex (to emulate lex calls)
 +# 2) FLEX is set to flex
 +#
 +AC_DEFUN([AC_PROG_FLEX],
 +[AC_PROG_LEX()
 +if test $LEX != flex; then
 +  AC_SUBST(FLEX,[])
 +  AC_MSG_ERROR([flex not found])
 +else
 +  AC_SUBST(FLEX,[flex])
 +fi
 +])

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


Re: [Mesa-dev] [PATCH] configure.ac: use AC_PROG_SED

2012-01-11 Thread Gaetan Nadon
On 12-01-11 01:16 AM, Matt Turner wrote:
 AC_PROG_PATH was used in the original configure.ac (dca1b796b) and I
 can't see any reason AC_PROG_SED wasn't used.

 Signed-off-by: Matt Turner matts...@gmail.com
 ---
  configure.ac |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index c0abeb9..08a0209 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -38,8 +38,8 @@ AC_PROG_CC
  AC_PROG_CXX
  AC_CHECK_PROGS([MAKE], [gmake make])
  AC_CHECK_PROGS([PYTHON2], [python2 python])
Consider using AM_PATH_PYTHON([2])
http://www.gnu.org/software/automake/manual/automake.html#Python
 +AC_PROG_SED
Correct
  AC_PATH_PROG([MKDEP], [makedepend])
 -AC_PATH_PROG([SED], [sed])
  
  if test x$MKDEP = x; then
  AC_MSG_ERROR([makedepend is required to build Mesa])

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


Re: [Mesa-dev] [PATCH] configure.ac: add and use AC_PROG_BISON/FLEX macros

2012-01-11 Thread Gaetan Nadon
On 12-01-11 01:29 AM, Matt Turner wrote:
 On Wed, Jan 11, 2012 at 1:16 AM, Matt Turner matts...@gmail.com wrote:
 Defining these macros lets us use AC_PROG_YACC/LEX which makes automake
 easier while still specifically requiring bison and flex.

 Based on bison.m4 and flex.m4 found in LLVM's tree.

 Signed-off-by: Matt Turner matts...@gmail.com
 ---
  configure.ac |9 -
  m4/bison.m4  |   16 
  m4/flex.m4   |   16 
  3 files changed, 36 insertions(+), 5 deletions(-)
  create mode 100644 m4/bison.m4
  create mode 100644 m4/flex.m4

 diff --git a/configure.ac b/configure.ac
 index 511d147..c0abeb9 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -45,11 +45,10 @@ if test x$MKDEP = x; then
 AC_MSG_ERROR([makedepend is required to build Mesa])
  fi

 -AC_PATH_PROG([FLEX], [flex])
 -test x$FLEX = x  AC_MSG_ERROR([flex is needed to build Mesa])
 -
 -AC_PATH_PROG([BISON], [bison])
 -test x$BISON = x  AC_MSG_ERROR([bison is needed to build Mesa])
 +m4_include([m4/bison.m4])
I am not sure if you need to m4_include. Perhaps because the toplevel
makefile is not Automake.

 +AC_PROG_BISON
 +m4_include([m4/flex.m4])
 +AC_PROG_FLEX

  dnl Our fallback install-sh is a symlink to minstall. Use the existing
  dnl configuration in that case.
 diff --git a/m4/bison.m4 b/m4/bison.m4
 new file mode 100644
 index 000..641d438
 --- /dev/null
 +++ b/m4/bison.m4
 @@ -0,0 +1,16 @@
 +#
 +# Check for Bison.
 +#
 +# This macro verifies that Bison is installed.  If successful, then
 +# 1) YACC is set to bison -y (to emulate YACC calls)
 +# 2) BISON is set to bison
 +#
 +AC_DEFUN([AC_PROG_BISON],
 +[AC_PROG_YACC()
 +if test $YACC != bison -y; then
 +  AC_SUBST(BISON,[])
 +  AC_MSG_WARN([bison not found])
 This should be AC_MSG_ERROR.
Not if you want to be able to build from tarball using the generated
code included in the tarball.


 +else
 +  AC_SUBST(BISON,[bison])
 +fi
 +])
 diff --git a/m4/flex.m4 b/m4/flex.m4
 new file mode 100644
 index 000..6a2a004
 --- /dev/null
 +++ b/m4/flex.m4
 @@ -0,0 +1,16 @@
 +#
 +# Check for FLEX.
 +#
 +# This macro verifies that flex is installed.  If successful, then
 +# 1) LEX is set to flex (to emulate lex calls)
 +# 2) FLEX is set to flex
 +#
 +AC_DEFUN([AC_PROG_FLEX],
 +[AC_PROG_LEX()
 +if test $LEX != flex; then
 +  AC_SUBST(FLEX,[])
 +  AC_MSG_ERROR([flex not found])
 +else
 +  AC_SUBST(FLEX,[flex])
 +fi
 +])
 --
 1.7.3.4


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


[Mesa-dev] [Bug 44618] Cross-compilation broken by glsl builtin_compiler

2012-01-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44618

--- Comment #2 from Thierry Reding thierry.red...@avionic-design.de 
2012-01-11 23:35:47 PST ---
(In reply to comment #1)
 Scons supports cross-compilation using approach 1). It builds the
 builtin_compiler and its dependencies twice. This works because each
 platform/machine gets built in a separate build sub directory (e.g.,
 build/linux-x86-debug, build/).

Are you saying that using SCons, Mesa already cross-builds properly?

 Getting this to work with the Mesa make file subsystem is probably quite a lot
 of work.

You're probably right. But I believe it is the technically correct approach.

 2) seems an easier approach. But still tricky given that Mesa doesn't allow 
 out
 of source build.

Out of tree builds would also be nice to have. Has anyone ever done some work
on
that? The problem with this option is that it requires special instructions to
make cross-compilation work (compile for build system, then compile for host
system with special flags). Cross-compilation really should work
out-of-the-box.

 Another option would be simply to eliminate builtin_compiler, and do whatever
 it does at runtime, when the drivers are loaded.

I think that was one of the reasons why builtin_compiler was introduced in the
first place, to avoid having to do this at runtime. I think the benefits 
outweigh the trickiness required at build time.

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