[Mesa-dev] [PATCH] i965/Gen4: Zero extra coordinates for ir_tex

2013-07-14 Thread Chris Forbes
We always emit U,V,R coordinates for this message, but the sampler gets
very angry if pass garbage in the R coordinate for at least some
texture formats.

Fill the remaining coordinates with zero instead.

Fixes broken rendering on GM45 in Source games.

NOTE: This is a candidate for stable branches.

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index fc7ae58..15d1c6a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -891,6 +891,10 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst, 
fs_reg coordinate,
 emit(MOV(fs_reg(MRF, base_mrf + mlen + i), coordinate));
 coordinate.reg_offset++;
   }
+  /* zero the others. */
+  for (int i = ir-coordinate-type-vector_elements; i3; i++) {
+ emit(MOV(fs_reg(MRF, base_mrf + mlen + i), fs_reg(0.0f)));
+  }
   /* gen4's SIMD8 sampler always has the slots for u,v,r present. */
   mlen += 3;
} else if (ir-op == ir_txd) {
-- 
1.8.3.2

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


Re: [Mesa-dev] [PATCH] i965/Gen4: Zero extra coordinates for ir_tex

2013-07-14 Thread Kenneth Graunke

On 07/13/2013 11:37 PM, Chris Forbes wrote:

We always emit U,V,R coordinates for this message, but the sampler gets
very angry if pass garbage in the R coordinate for at least some
texture formats.

Fill the remaining coordinates with zero instead.

Fixes broken rendering on GM45 in Source games.

NOTE: This is a candidate for stable branches.

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 
  1 file changed, 4 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index fc7ae58..15d1c6a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -891,6 +891,10 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst, 
fs_reg coordinate,
 emit(MOV(fs_reg(MRF, base_mrf + mlen + i), coordinate));
 coordinate.reg_offset++;
}
+  /* zero the others. */
+  for (int i = ir-coordinate-type-vector_elements; i3; i++) {
+ emit(MOV(fs_reg(MRF, base_mrf + mlen + i), fs_reg(0.0f)));
+  }
/* gen4's SIMD8 sampler always has the slots for u,v,r present. */
mlen += 3;
 } else if (ir-op == ir_txd) {



You tracked this down in record time!

On Gen5+, we sometimes reduce the message length, causing the remaining 
fields to be treated as zero.  But on Gen4, the message length is used 
to determine what kind of message it is, so we can't do that.


On all generations, there are a bunch of cases where the sampler 
/should/ ignore components, but doesn't, so zeroing them out is just a 
really good idea.


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] glsl: Initialize ast_jump_statement::opt_return_value.

2013-07-14 Thread Vinson Lee
opt_return_value was not initialized if mode != ast_return.

Fixes Uninitialized pointer field defect reported by Coverity.

Signed-off-by: Vinson Lee v...@freedesktop.org
---
 src/glsl/glsl_parser_extras.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 055dfa9..84c4777 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -1225,6 +1225,7 @@ ast_jump_statement::print(void) const
 
 
 ast_jump_statement::ast_jump_statement(int mode, ast_expression *return_value)
+   : opt_return_value(NULL)
 {
this-mode = ast_jump_modes(mode);
 
-- 
1.8.2.1

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


[Mesa-dev] [Bug 66833] Text rendering problems on Dota 2, all mesa drivers

2013-07-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=66833

Vladimir Ysikov granti...@gmail.com changed:

   What|Removed |Added

 CC||granti...@gmail.com

-- 
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 44618] Cross-compilation broken by glsl builtin_compiler

2013-07-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=44618

--- Comment #27 from Jonathan Liu net...@gmail.com ---
The patch has been submitted to the mesa-dev mailing list already (2013-06-04),
just waiting for approval. I have been using the patch for quite some time now
and it is working fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH V3 0/5] Interpolation fixes for Gen4/5

2013-07-14 Thread Chris Forbes
This series adds support for GLSL 1.30 / EXT_gpu_shader4's 'flat' and
'noperspective' varying interpolation qualifiers on Gen4/5.

Based on Olivier Galibert's series from July 2012, with some simplifications
(that series contained a number of fixes for other bugs which have been
addressed in master already -- two-sided lighting, vue map inconsistencies)

The interpolation qualifiers are still passed through brw-, which Eric
doesn't like in the original version -- which I have some alternatives for:

1) Leave it as-is, but if anything other than the program key builders
go looking in brw-interpolation_mode, it's *wrong*.

2) Tack it onto the VUE map, and have the VS code produce it at the same time
as the VUE map itself. (When we have a GS, the GS will have to do this too).

3) Make the clip program key the primary source, and have the SF program key
builder go snooping in it.

4) Have the clip and SF program key builders redundantly compute it.

The other review point from V2 no longer exists -- fixes to the two-sided
lighting behavior are already done.

I've dropped all the Reviewed-by: lines from V2, since this has changed a fair
bit and could do with a fresh look.

With this series, all of the GLSL 1.30 interpolation tests pass on Gen5 except
those which use gl_ClipDistance, since it's not supported yet.

-- Chris


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


[Mesa-dev] [PATCH V3 1/5] i965 Gen4/5: Compute interpolation status for every varying in one place.

2013-07-14 Thread Chris Forbes
The program keys are updated accordingly, but the values are not used
yet.

[V1-2]: Signed-off-by: Olivier Galibert galibert at pobox.com

V3: Updated for vue_map changes, intel - brw merge, etc. (Chris Forbes)
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/drivers/dri/i965/brw_clip.c| 59 -
 src/mesa/drivers/dri/i965/brw_clip.h|  1 +
 src/mesa/drivers/dri/i965/brw_context.h |  5 +++
 src/mesa/drivers/dri/i965/brw_sf.c  |  7 +++-
 src/mesa/drivers/dri/i965/brw_sf.h  |  1 +
 5 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clip.c 
b/src/mesa/drivers/dri/i965/brw_clip.c
index 2ebf3f6..488e0a0 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -48,6 +48,56 @@
 #define BACK_UNFILLED_BIT   0x2
 
 
+/* Set up interpolation modes for every element in the VUE */
+static void
+brw_setup_vue_interpolation(struct brw_context *brw)
+{
+   const struct gl_fragment_program *fprog = brw-fragment_program;
+   struct brw_vue_map *vue_map = brw-vue_map_geom_out;
+
+   /* XXX: stuffing this in the context is not really good enough */
+   memset(brw-interpolation_mode, INTERP_QUALIFIER_NONE, 
BRW_VARYING_SLOT_COUNT);
+
+   if (!fprog)
+  return;
+
+   for (int i=0; i  vue_map-num_slots; i++) {
+  int varying = vue_map-slot_to_varying[i];
+  if (varying == -1)
+ continue;
+
+  /* HPOS always wants noperspective. setting it up here allows
+   * us to not need special handling in the SF program. */
+  if (varying == VARYING_SLOT_POS) {
+ brw-interpolation_mode[i] = INTERP_QUALIFIER_NOPERSPECTIVE;
+ continue;
+  }
+
+  int frag_attrib = varying;
+  if (varying == VARYING_SLOT_BFC0 || varying == VARYING_SLOT_BFC1)
+ frag_attrib = varying - VARYING_SLOT_BFC0 + VARYING_SLOT_COL0;
+
+  if (!(fprog-Base.InputsRead  BITFIELD64_BIT(frag_attrib)))
+ continue;
+
+  enum glsl_interp_qualifier mode = fprog-InterpQualifier[frag_attrib];
+
+  /* If the mode is not specified, the default varies: Color values
+   * follow GL_SHADE_MODEL; everything else is smooth.
+   */
+  if (mode == INTERP_QUALIFIER_NONE) {
+ if (frag_attrib == VARYING_SLOT_COL0 || frag_attrib == 
VARYING_SLOT_COL1)
+mode = brw-ctx.Light.ShadeModel == GL_FLAT
+   ? INTERP_QUALIFIER_FLAT : INTERP_QUALIFIER_SMOOTH;
+ else
+mode = INTERP_QUALIFIER_SMOOTH;
+  }
+
+  brw-interpolation_mode[i] = mode;
+   }
+}
+
+
 static void compile_clip_prog( struct brw_context *brw,
 struct brw_clip_prog_key *key )
 {
@@ -141,6 +191,11 @@ brw_upload_clip_prog(struct brw_context *brw)
 
/* Populate the key:
 */
+
+   /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
+   brw_setup_vue_interpolation(brw);
+   memcpy(key.interpolation_mode, brw-interpolation_mode, 
BRW_VARYING_SLOT_COUNT);
+
/* BRW_NEW_REDUCED_PRIMITIVE */
key.primitive = brw-reduced_primitive;
/* BRW_NEW_VUE_MAP_GEOM_OUT */
@@ -256,7 +311,9 @@ const struct brw_tracked_state brw_clip_prog = {
_NEW_TRANSFORM |
_NEW_POLYGON | 
_NEW_BUFFERS),
-  .brw   = (BRW_NEW_REDUCED_PRIMITIVE | BRW_NEW_VUE_MAP_GEOM_OUT)
+  .brw   = (BRW_NEW_FRAGMENT_PROGRAM |
+BRW_NEW_REDUCED_PRIMITIVE |
+BRW_NEW_VUE_MAP_GEOM_OUT)
},
.emit = brw_upload_clip_prog
 };
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h 
b/src/mesa/drivers/dri/i965/brw_clip.h
index 02259d4..fcbe2a0 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -43,6 +43,7 @@
  */
 struct brw_clip_prog_key {
GLbitfield64 attrs;
+   unsigned char interpolation_mode[BRW_VARYING_SLOT_COUNT];
GLuint primitive:4;
GLuint nr_userclip:4;
GLuint do_flat_shading:1;
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 86f9f71..a614b96 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1203,6 +1203,11 @@ struct brw_context
uint32_t render_target_format[MESA_FORMAT_COUNT];
bool format_supported_as_render_target[MESA_FORMAT_COUNT];
 
+   /* Interpolation modes, one byte per vue slot.
+* Used Gen4/5 by the clip|sf|wm stages. Ignored on Gen6+.
+*/
+   unsigned char interpolation_mode[BRW_VARYING_SLOT_COUNT];
+
/* PrimitiveRestart */
struct {
   bool in_progress;
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c 
b/src/mesa/drivers/dri/i965/brw_sf.c
index d73973c..7cd383c 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -194,6 +194,9 @@ brw_upload_sf_prog(struct brw_context *brw)
key.do_twoside_color = ((ctx-Light.Enabled  ctx-Light.Model.TwoSide) ||
ctx-VertexProgram._TwoSideEnabled);
 
+   /* 

[Mesa-dev] [PATCH V3 2/5] i965 Gen4/5: Generalize SF interpolation setup for GLSL1.3

2013-07-14 Thread Chris Forbes
Previously the SF only handled the builtin color varying specially.
This patch generalizes that support to cover user-defined varyings,
driven by the interpolation mode array set up alongside the VUE map.

Based on the following patches from Olivier Galibert:
- http://lists.freedesktop.org/archives/mesa-dev/2012-July/024335.html
- http://lists.freedesktop.org/archives/mesa-dev/2012-July/024339.html

With this patch, all the GLSL 1.3 interpolation tests that do not clip
(spec/glsl-1.30/execution/interpolation/*-none.shader_test) pass.

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/drivers/dri/i965/brw_fs.cpp|   2 +-
 src/mesa/drivers/dri/i965/brw_sf.c  |   9 +-
 src/mesa/drivers/dri/i965/brw_sf.h  |   2 +-
 src/mesa/drivers/dri/i965/brw_sf_emit.c | 187 
 4 files changed, 106 insertions(+), 94 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index afd29de..a81e97f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1048,7 +1048,7 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
   inst-predicate = BRW_PREDICATE_NORMAL;
   inst-predicate_inverse = true;
}
-   if (brw-gen  6) {
+   if (brw-gen  6  interpolation_mode == 
INTERP_QUALIFIER_SMOOTH) {
   emit(BRW_OPCODE_MUL, attr, attr, this-pixel_w);
}
   attr.reg_offset++;
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c 
b/src/mesa/drivers/dri/i965/brw_sf.c
index 7cd383c..f7725ed 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -138,6 +138,7 @@ brw_upload_sf_prog(struct brw_context *brw)
struct brw_sf_prog_key key;
/* _NEW_BUFFERS */
bool render_to_fbo = _mesa_is_user_fbo(ctx-DrawBuffer);
+   int i;
 
memset(key, 0, sizeof(key));
 
@@ -190,7 +191,13 @@ brw_upload_sf_prog(struct brw_context *brw)
   key.sprite_origin_lower_left = true;
 
/* _NEW_LIGHT | _NEW_PROGRAM */
-   key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
+   key.has_flat_shading = 0;
+   for (i = 0; i  BRW_VARYING_SLOT_COUNT; i++) {
+  if (brw-interpolation_mode[i] == INTERP_QUALIFIER_FLAT) {
+ key.has_flat_shading = 1;
+ break;
+  }
+   }
key.do_twoside_color = ((ctx-Light.Enabled  ctx-Light.Model.TwoSide) ||
ctx-VertexProgram._TwoSideEnabled);
 
diff --git a/src/mesa/drivers/dri/i965/brw_sf.h 
b/src/mesa/drivers/dri/i965/brw_sf.h
index 55a860d..9bfa994 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.h
+++ b/src/mesa/drivers/dri/i965/brw_sf.h
@@ -50,7 +50,7 @@ struct brw_sf_prog_key {
uint8_t point_sprite_coord_replace;
GLuint primitive:2;
GLuint do_twoside_color:1;
-   GLuint do_flat_shading:1;
+   GLuint has_flat_shading:1;
GLuint frontface_ccw:1;
GLuint do_point_sprite:1;
GLuint do_point_coord:1;
diff --git a/src/mesa/drivers/dri/i965/brw_sf_emit.c 
b/src/mesa/drivers/dri/i965/brw_sf_emit.c
index bd68f68..63e077d 100644
--- a/src/mesa/drivers/dri/i965/brw_sf_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_sf_emit.c
@@ -44,6 +44,15 @@
 
 
 /**
+ * Determine the vue slot corresponding to the given half of the given 
register.
+ */
+static inline int vert_reg_to_vue_slot(struct brw_sf_compile *c, GLuint reg,
+   int half)
+{
+   return (reg + c-urb_entry_read_offset) * 2 + half;
+}
+
+/**
  * Determine the varying corresponding to the given half of the given
  * register.  half=0 means the first half of a register, half=1 means the
  * second half.
@@ -51,11 +60,24 @@
 static inline int vert_reg_to_varying(struct brw_sf_compile *c, GLuint reg,
   int half)
 {
-   int vue_slot = (reg + c-urb_entry_read_offset) * 2 + half;
+   int vue_slot = vert_reg_to_vue_slot(c, reg, half);
return c-vue_map.slot_to_varying[vue_slot];
 }
 
 /**
+ * Determine the register corresponding to the given vue slot
+ */
+static struct brw_reg get_vue_slot(struct brw_sf_compile *c,
+   struct brw_reg vert,
+   int vue_slot)
+{
+   GLuint off = vue_slot / 2 - c-urb_entry_read_offset;
+   GLuint sub = vue_slot % 2;
+
+   return brw_vec4_grf(vert.nr + off, sub * 4);
+}
+
+/**
  * Determine the register corresponding to the given varying.
  */
 static struct brw_reg get_varying(struct brw_sf_compile *c,
@@ -64,10 +86,7 @@ static struct brw_reg get_varying(struct brw_sf_compile *c,
 {
int vue_slot = c-vue_map.varying_to_slot[varying];
assert (vue_slot = c-urb_entry_read_offset);
-   GLuint off = vue_slot / 2 - c-urb_entry_read_offset;
-   GLuint sub = vue_slot % 2;
-
-   return brw_vec4_grf(vert.nr + off, sub * 4);
+   return get_vue_slot(c, vert, vue_slot);
 }
 
 static bool
@@ -79,24 +98,9 @@ have_attr(struct brw_sf_compile *c, GLuint attr)
 

[Mesa-dev] [PATCH V3 3/5] i965 Gen4/5: clip: correctly handle flat varyings

2013-07-14 Thread Chris Forbes
Previously we only gave special treatment to the builtin color varyings.
This patch adds support for arbitrary flat-shaded varyings, which is
required for GLSL 1.30.

Based on Olivier Galibert's patch from last year:
http://lists.freedesktop.org/archives/mesa-dev/2012-July/024340.html

[V1-2]: Signed-off-by: Olivier Galibert galibert at pobox.com
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/drivers/dri/i965/brw_clip.c  | 13 +--
 src/mesa/drivers/dri/i965/brw_clip.h  |  6 ++--
 src/mesa/drivers/dri/i965/brw_clip_line.c |  6 ++--
 src/mesa/drivers/dri/i965/brw_clip_tri.c  | 18 +-
 src/mesa/drivers/dri/i965/brw_clip_unfilled.c |  2 +-
 src/mesa/drivers/dri/i965/brw_clip_util.c | 51 +++
 6 files changed, 40 insertions(+), 56 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clip.c 
b/src/mesa/drivers/dri/i965/brw_clip.c
index 488e0a0..7df4b18 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -186,6 +186,7 @@ brw_upload_clip_prog(struct brw_context *brw)
 {
struct gl_context *ctx = brw-ctx;
struct brw_clip_prog_key key;
+   int i;
 
memset(key, 0, sizeof(key));
 
@@ -200,8 +201,16 @@ brw_upload_clip_prog(struct brw_context *brw)
key.primitive = brw-reduced_primitive;
/* BRW_NEW_VUE_MAP_GEOM_OUT */
key.attrs = brw-vue_map_geom_out.slots_valid;
-   /* _NEW_LIGHT */
-   key.do_flat_shading = (ctx-Light.ShadeModel == GL_FLAT);
+
+   /* BRW_NEW_FRAGMENT_PROGRAM, _NEW_LIGHT */
+   key.has_flat_shading = 0;
+   for (i = 0; i  brw-vue_map_geom_out.num_slots; i++) {
+  if (key.interpolation_mode[i] == INTERP_QUALIFIER_FLAT) {
+ key.has_flat_shading = 1;
+ break;
+  }
+   }
+
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
/* _NEW_TRANSFORM (also part of VUE map)*/
key.nr_userclip = _mesa_bitcount_64(ctx-Transform.ClipPlanesEnabled);
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h 
b/src/mesa/drivers/dri/i965/brw_clip.h
index fcbe2a0..656254b 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -46,7 +46,7 @@ struct brw_clip_prog_key {
unsigned char interpolation_mode[BRW_VARYING_SLOT_COUNT];
GLuint primitive:4;
GLuint nr_userclip:4;
-   GLuint do_flat_shading:1;
+   GLuint has_flat_shading:1;
GLuint pv_first:1;
GLuint do_unfilled:1;
GLuint fill_cw:2;   /* includes cull information */
@@ -173,8 +173,8 @@ void brw_clip_kill_thread(struct brw_clip_compile *c);
 struct brw_reg brw_clip_plane_stride( struct brw_clip_compile *c );
 struct brw_reg brw_clip_plane0_address( struct brw_clip_compile *c );
 
-void brw_clip_copy_colors( struct brw_clip_compile *c,
-  GLuint to, GLuint from );
+void brw_clip_copy_flatshaded_attributes( struct brw_clip_compile *c,
+  GLuint to, GLuint from );
 
 void brw_clip_init_clipmask( struct brw_clip_compile *c );
 
diff --git a/src/mesa/drivers/dri/i965/brw_clip_line.c 
b/src/mesa/drivers/dri/i965/brw_clip_line.c
index 9ce80b8..8df7d0c 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_line.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_line.c
@@ -272,11 +272,11 @@ void brw_emit_line_clip( struct brw_clip_compile *c )
brw_clip_line_alloc_regs(c);
brw_clip_init_ff_sync(c);
 
-   if (c-key.do_flat_shading) {
+   if (c-key.has_flat_shading) {
   if (c-key.pv_first)
- brw_clip_copy_colors(c, 1, 0);
+ brw_clip_copy_flatshaded_attributes(c, 1, 0);
   else
- brw_clip_copy_colors(c, 0, 1);
+ brw_clip_copy_flatshaded_attributes(c, 0, 1);
}
 
clip_and_emit_line(c);
diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c 
b/src/mesa/drivers/dri/i965/brw_clip_tri.c
index bea0853..ac24929 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_tri.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_tri.c
@@ -190,8 +190,8 @@ void brw_clip_tri_flat_shade( struct brw_clip_compile *c )
 
brw_IF(p, BRW_EXECUTE_1);
{
-  brw_clip_copy_colors(c, 1, 0);
-  brw_clip_copy_colors(c, 2, 0);
+  brw_clip_copy_flatshaded_attributes(c, 1, 0);
+  brw_clip_copy_flatshaded_attributes(c, 2, 0);
}
brw_ELSE(p);
{
@@ -203,19 +203,19 @@ void brw_clip_tri_flat_shade( struct brw_clip_compile *c )
 brw_imm_ud(_3DPRIM_TRIFAN));
 brw_IF(p, BRW_EXECUTE_1);
 {
-   brw_clip_copy_colors(c, 0, 1);
-   brw_clip_copy_colors(c, 2, 1);
+   brw_clip_copy_flatshaded_attributes(c, 0, 1);
+   brw_clip_copy_flatshaded_attributes(c, 2, 1);
 }
 brw_ELSE(p);
 {
-   brw_clip_copy_colors(c, 1, 0);
-   brw_clip_copy_colors(c, 2, 0);
+   brw_clip_copy_flatshaded_attributes(c, 1, 0);
+   brw_clip_copy_flatshaded_attributes(c, 2, 0);
 }
 brw_ENDIF(p);
   }
   else {
- 

[Mesa-dev] [PATCH V3 4/5] i965 Gen4/5: clip: Add support for noperspective varyings

2013-07-14 Thread Chris Forbes
Adds support for interpolating noperspective varyings linearly in screen
space when clipping.

Based on Olivier Galibert's patch from last year:
http://lists.freedesktop.org/archives/mesa-dev/2012-July/024341.html

At this point all -fixed and -vertex interpolation tests work.

[V1-2]: Signed-off-by: Olivier Galibert galibert at pobox.com
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/drivers/dri/i965/brw_clip.c  |   8 ++
 src/mesa/drivers/dri/i965/brw_clip.h  |   1 +
 src/mesa/drivers/dri/i965/brw_clip_util.c | 120 +++---
 3 files changed, 119 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clip.c 
b/src/mesa/drivers/dri/i965/brw_clip.c
index 7df4b18..6dd3759 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -211,6 +211,14 @@ brw_upload_clip_prog(struct brw_context *brw)
   }
}
 
+   key.has_noperspective_shading = 0;
+   for (i = 0; i  brw-vue_map_geom_out.num_slots; i++) {
+  if (key.interpolation_mode[i] == INTERP_QUALIFIER_NOPERSPECTIVE) {
+ key.has_noperspective_shading = 1;
+ break;
+  }
+   }
+
key.pv_first = (ctx-Light.ProvokingVertex == GL_FIRST_VERTEX_CONVENTION);
/* _NEW_TRANSFORM (also part of VUE map)*/
key.nr_userclip = _mesa_bitcount_64(ctx-Transform.ClipPlanesEnabled);
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h 
b/src/mesa/drivers/dri/i965/brw_clip.h
index 656254b..90e3e33 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -47,6 +47,7 @@ struct brw_clip_prog_key {
GLuint primitive:4;
GLuint nr_userclip:4;
GLuint has_flat_shading:1;
+   GLuint has_noperspective_shading:1;
GLuint pv_first:1;
GLuint do_unfilled:1;
GLuint fill_cw:2;   /* includes cull information */
diff --git a/src/mesa/drivers/dri/i965/brw_clip_util.c 
b/src/mesa/drivers/dri/i965/brw_clip_util.c
index 8a21c1f..56c9ccd 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_util.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_util.c
@@ -128,6 +128,8 @@ static void brw_clip_project_vertex( struct 
brw_clip_compile *c,
 
 /* Interpolate between two vertices and put the result into a0.0.  
  * Increment a0.0 accordingly.
+ *
+ * Beware that dest_ptr can be equal to v0_ptr!
  */
 void brw_clip_interp_vertex( struct brw_clip_compile *c,
 struct brw_indirect dest_ptr,
@@ -137,7 +139,7 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
 bool force_edgeflag)
 {
struct brw_compile *p = c-func;
-   struct brw_reg tmp = get_tmp(c);
+   struct brw_reg t_nopersp, v0_ndc_copy;
GLuint slot;
 
/* Just copy the vertex header:
@@ -148,12 +150,107 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
 */
brw_copy_indirect_to_indirect(p, dest_ptr, v0_ptr, 1);
   
-   /* Iterate over each attribute (could be done in pairs?)
+
+   /* First handle the 3D and NDC interpolation, in case we
+* need noperspective interpolation. Doing it early has no
+* performance impact in any case.
+*/
+
+   /* Take a copy of the v0 NDC coordinates, in case dest == v0. */
+   if (c-key.has_noperspective_shading) {
+  GLuint offset = brw_varying_to_offset(c-vue_map,
+ BRW_VARYING_SLOT_NDC);
+  v0_ndc_copy = get_tmp(c);
+  brw_MOV(p, v0_ndc_copy, deref_4f(v0_ptr, offset));
+   }
+
+   /* Compute the new 3D position
+*
+* dest_hpos = v0_hpos * (1 - t0) + v1_hpos * t0
+*/
+   {
+  GLuint delta = brw_varying_to_offset(c-vue_map, VARYING_SLOT_POS);
+  struct brw_reg tmp = get_tmp(c);
+  brw_MUL(p, vec4(brw_null_reg()), deref_4f(v1_ptr, delta), t0);
+  brw_MAC(p, tmp, negate(deref_4f(v0_ptr, delta)), t0);
+  brw_ADD(p, deref_4f(dest_ptr, delta), deref_4f(v0_ptr, delta), tmp);
+  release_tmp(c, tmp);
+   }
+
+   /* Recreate the projected (NDC) coordinate in the new vertex header */
+   brw_clip_project_vertex(c, dest_ptr);
+
+   /* If we have noperspective attributes,
+* we need to compute the screen-space t
+*/
+   if (c-key.has_noperspective_shading) {
+  GLuint delta = brw_varying_to_offset(c-vue_map,
+BRW_VARYING_SLOT_NDC);
+  struct brw_reg tmp = get_tmp(c);
+  t_nopersp = get_tmp(c);
+
+  /* t_nopersp = vec4(v1.xy, dest.xy) */
+  brw_MOV(p, t_nopersp, deref_4f(v1_ptr, delta));
+  brw_MOV(p, tmp, deref_4f(dest_ptr, delta));
+  brw_set_access_mode(p, BRW_ALIGN_16);
+  brw_MOV(p,
+  brw_writemask(t_nopersp, WRITEMASK_ZW),
+  brw_swizzle(tmp, 0, 1, 0, 1));
+
+  /* t_nopersp = vec4(v1.xy, dest.xy) - v0.xyxy */
+  brw_ADD(p, t_nopersp, t_nopersp,
+  negate(brw_swizzle(v0_ndc_copy, 0, 1, 0, 1)));
+
+  /* Add the absolute values of the X and Y deltas so that if
+   * the points aren't in the same place on the 

[Mesa-dev] [PATCH V3 5/5] i965 Gen4/5: clip: Don't mangle flat varyings

2013-07-14 Thread Chris Forbes
This patch ensures that integers will pass through unscathed.  Doing
(useless) computations on them is risky, especially when their bit
patterns correspond to values like inf or nan.

[V1-2]: Signed-off-by: Olivier Galibert galibert at pobox.com
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/drivers/dri/i965/brw_clip_util.c | 57 ++-
 1 file changed, 34 insertions(+), 23 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clip_util.c 
b/src/mesa/drivers/dri/i965/brw_clip_util.c
index 56c9ccd..a168b32 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_util.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_util.c
@@ -246,8 +246,8 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
   int varying = c-vue_map.slot_to_varying[slot];
   GLuint delta = brw_vue_slot_to_offset(slot);
 
-  /* HPOS is already handled above */
-  if (varying == VARYING_SLOT_POS)
+  /* HPOS, NDC already handled above */
+  if (varying == VARYING_SLOT_POS || varying == BRW_VARYING_SLOT_NDC)
  continue;
 
 
@@ -269,28 +269,39 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
  * header), so interpolate:
  *
  *New = attr0 + t*attr1 - t*attr0
+  *
+  * Unless the attribute is flat shaded -- in which case just copy
+  * from one of the sources (doesn't matter which; already copied from 
pv)
  */
- struct brw_reg tmp = get_tmp(c);
- struct brw_reg t =
-c-key.interpolation_mode[slot] == INTERP_QUALIFIER_NOPERSPECTIVE ?
-t_nopersp : t0;
-
-brw_MUL(p, 
-vec4(brw_null_reg()),
-deref_4f(v1_ptr, delta),
-t);
-
-brw_MAC(p, 
-tmp, 
-negate(deref_4f(v0_ptr, delta)),
-t); 
- 
-brw_ADD(p,
-deref_4f(dest_ptr, delta), 
-deref_4f(v0_ptr, delta),
-tmp);
-
- release_tmp(c, tmp);
+ GLuint interp = c-key.interpolation_mode[slot];
+
+ if (interp != INTERP_QUALIFIER_FLAT) {
+struct brw_reg tmp = get_tmp(c);
+struct brw_reg t =
+   interp == INTERP_QUALIFIER_NOPERSPECTIVE ? t_nopersp : t0;
+
+brw_MUL(p,
+  vec4(brw_null_reg()),
+  deref_4f(v1_ptr, delta),
+  t);
+
+brw_MAC(p,
+  tmp,
+  negate(deref_4f(v0_ptr, delta)),
+  t);
+
+brw_ADD(p,
+  deref_4f(dest_ptr, delta),
+  deref_4f(v0_ptr, delta),
+  tmp);
+
+release_tmp(c, tmp);
+ }
+ else {
+brw_MOV(p,
+  deref_4f(dest_ptr, delta),
+  deref_4f(v0_ptr, delta));
+ }
   }
}
 
-- 
1.8.3.2

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


[Mesa-dev] [PATCH] i965: allow 8 user clip planes on CTG+

2013-07-14 Thread Chris Forbes
There's no reason to restrict to 6 planes on CTG and ILK -- no bugs to
work around which require the top clip flag.

This is another tiny step toward GLSL 1.30 support.

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/drivers/dri/i965/brw_clip_tri.c | 4 ++--
 src/mesa/drivers/dri/i965/brw_context.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c 
b/src/mesa/drivers/dri/i965/brw_clip_tri.c
index bea0853..61d613e 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_tri.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_tri.c
@@ -273,9 +273,9 @@ void brw_clip_tri( struct brw_clip_compile *c )
brw_MOV(p, get_addr_reg(freelist_ptr), brw_address(c-reg.vertex[3]) );
 
/* Set the initial vertex source mask: The first 6 planes are the bounds
-* of the view volume; the next 6 planes are the user clipping planes.
+* of the view volume; the next 8 planes are the user clipping planes.
 */
-   brw_MOV(p, c-reg.vertex_src_mask, brw_imm_ud(0xfc0));
+   brw_MOV(p, c-reg.vertex_src_mask, brw_imm_ud(0x3fc0));
 
brw_DO(p, BRW_EXECUTE_1);
{
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index a72e226..accbe2d 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -190,7 +190,7 @@ brw_initialize_context_constants(struct brw_context *brw)
ctx-Const.MaxPointSizeAA = 255.0;
ctx-Const.PointSizeGranularity = 1.0;
 
-   if (brw-gen = 6)
+   if (brw-gen = 5 || brw-is_g4x)
   ctx-Const.MaxClipPlanes = 8;
 
ctx-Const.VertexProgram.MaxNativeInstructions = 16 * 1024;
-- 
1.8.3.2

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


[Mesa-dev] [Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

2013-07-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=66558

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 CC||mar...@gmail.com

--- Comment #6 from Alex Deucher ag...@yahoo.com ---
Marek, any idea why r300_render_draw_elements() calls
r300_prepare_for_rendering() with 256 dwords?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] glsl: Fix lower_named_interface_blocks to account for dereferences of consts.

2013-07-14 Thread Paul Berry
In certain rare cases (such as those involving dereference of a
literal constant array of structs),
flatten_named_interface_blocks_declarations's rvalue visitor may be
invoked on an ir_dereference_record whose variable_referenced() method
returns NULL.

Check for this case to avoid a segfault.

Prevents crashes in piglit tests
{vs,fs}-deref-literal-array-of-structs.
---
 src/glsl/lower_named_interface_blocks.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/glsl/lower_named_interface_blocks.cpp 
b/src/glsl/lower_named_interface_blocks.cpp
index 922cc02..d0d491d 100644
--- a/src/glsl/lower_named_interface_blocks.cpp
+++ b/src/glsl/lower_named_interface_blocks.cpp
@@ -194,6 +194,8 @@ 
flatten_named_interface_blocks_declarations::handle_rvalue(ir_rvalue **rvalue)
   return;
 
ir_variable *var = ir-variable_referenced();
+   if (var == NULL)
+  return;
 
if (!var-is_interface_instance())
   return;
-- 
1.8.3.2

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


Re: [Mesa-dev] [PATCH] i965/Gen4: Zero extra coordinates for ir_tex

2013-07-14 Thread Kenneth Graunke

On 07/13/2013 11:37 PM, Chris Forbes wrote:

We always emit U,V,R coordinates for this message, but the sampler gets
very angry if pass garbage in the R coordinate for at least some
texture formats.

Fill the remaining coordinates with zero instead.

Fixes broken rendering on GM45 in Source games.

NOTE: This is a candidate for stable branches.

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 4 
  1 file changed, 4 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index fc7ae58..15d1c6a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -891,6 +891,10 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst, 
fs_reg coordinate,
 emit(MOV(fs_reg(MRF, base_mrf + mlen + i), coordinate));
 coordinate.reg_offset++;
}
+  /* zero the others. */
+  for (int i = ir-coordinate-type-vector_elements; i3; i++) {
+ emit(MOV(fs_reg(MRF, base_mrf + mlen + i), fs_reg(0.0f)));
+  }
/* gen4's SIMD8 sampler always has the slots for u,v,r present. */
mlen += 3;
 } else if (ir-op == ir_txd) {



It just occurred to me that this probably also fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=65236

Still haven't pulled out my GM45 to test, though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965: allow 8 user clip planes on CTG+

2013-07-14 Thread Kenneth Graunke

On 07/14/2013 02:43 AM, Chris Forbes wrote:

There's no reason to restrict to 6 planes on CTG and ILK -- no bugs to
work around which require the top clip flag.


Right, there's no negative RHW bug to work around using a slot...so I 
agree this should be doable.  And also necessary for 1.30.


I'm a little paranoid that there might be some hardcoded limits in the 
clipping code (arrays not big enough, loops that don't go all the way, 
etc...).


I've been looking through the code for the magic number 6, and it 
appears an awful lot of places...though often as 6 + nr_userclip + 1, 
which sounds like the 6 bounds of the view volume, so I think we're okay 
there.


In brw_clip.h, there's a #define MAX_VERTS (3+6+6) (with no comments 
what those are for - eesh)...does one of those need to be an 8?


I agree with this patch in principle, though, and am not up to speed on 
the details, so if you take a look and still think everything is fine:

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


This is another tiny step toward GLSL 1.30 support.

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
  src/mesa/drivers/dri/i965/brw_clip_tri.c | 4 ++--
  src/mesa/drivers/dri/i965/brw_context.c  | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c 
b/src/mesa/drivers/dri/i965/brw_clip_tri.c
index bea0853..61d613e 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_tri.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_tri.c
@@ -273,9 +273,9 @@ void brw_clip_tri( struct brw_clip_compile *c )
 brw_MOV(p, get_addr_reg(freelist_ptr), brw_address(c-reg.vertex[3]) );

 /* Set the initial vertex source mask: The first 6 planes are the bounds
-* of the view volume; the next 6 planes are the user clipping planes.
+* of the view volume; the next 8 planes are the user clipping planes.
  */
-   brw_MOV(p, c-reg.vertex_src_mask, brw_imm_ud(0xfc0));
+   brw_MOV(p, c-reg.vertex_src_mask, brw_imm_ud(0x3fc0));

 brw_DO(p, BRW_EXECUTE_1);
 {
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index a72e226..accbe2d 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -190,7 +190,7 @@ brw_initialize_context_constants(struct brw_context *brw)
 ctx-Const.MaxPointSizeAA = 255.0;
 ctx-Const.PointSizeGranularity = 1.0;

-   if (brw-gen = 6)
+   if (brw-gen = 5 || brw-is_g4x)
ctx-Const.MaxClipPlanes = 8;

 ctx-Const.VertexProgram.MaxNativeInstructions = 16 * 1024;



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


Re: [Mesa-dev] [PATCH] glsl: Fix lower_named_interface_blocks to account for dereferences of consts.

2013-07-14 Thread Kenneth Graunke

On 07/14/2013 09:27 AM, Paul Berry wrote:

In certain rare cases (such as those involving dereference of a
literal constant array of structs),
flatten_named_interface_blocks_declarations's rvalue visitor may be
invoked on an ir_dereference_record whose variable_referenced() method
returns NULL.

Check for this case to avoid a segfault.

Prevents crashes in piglit tests
{vs,fs}-deref-literal-array-of-structs.


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] i965: allow 8 user clip planes on CTG+

2013-07-14 Thread Chris Forbes
Hmmn, that #define does need to change -- the worst-case does get
slightly worse.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glsl: Fix lower_named_interface_blocks to account for dereferences of consts.

2013-07-14 Thread Jordan Justen
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com

On Sun, Jul 14, 2013 at 9:27 AM, Paul Berry stereotype...@gmail.com wrote:
 In certain rare cases (such as those involving dereference of a
 literal constant array of structs),
 flatten_named_interface_blocks_declarations's rvalue visitor may be
 invoked on an ir_dereference_record whose variable_referenced() method
 returns NULL.

 Check for this case to avoid a segfault.

 Prevents crashes in piglit tests
 {vs,fs}-deref-literal-array-of-structs.
 ---
  src/glsl/lower_named_interface_blocks.cpp | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/src/glsl/lower_named_interface_blocks.cpp 
 b/src/glsl/lower_named_interface_blocks.cpp
 index 922cc02..d0d491d 100644
 --- a/src/glsl/lower_named_interface_blocks.cpp
 +++ b/src/glsl/lower_named_interface_blocks.cpp
 @@ -194,6 +194,8 @@ 
 flatten_named_interface_blocks_declarations::handle_rvalue(ir_rvalue **rvalue)
return;

 ir_variable *var = ir-variable_referenced();
 +   if (var == NULL)
 +  return;

 if (!var-is_interface_instance())
return;
 --
 1.8.3.2

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


[Mesa-dev] [Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

2013-07-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=66558

--- Comment #7 from Marek Olšák mar...@gmail.com ---
The function splits the drawing into several packets if there are too many
indices. 256 dwords is a reasonable minimum for the first packet. I think the
problem arises when the splitting takes place in the middle of a primitive,
breaking all the primitives that follow. I'll send a patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] OSMesa Help

2013-07-14 Thread Andy Li
Hi,
I have some questions on the OSMesa code.As you suggested, I have continue 
looking into the swrast code.However, I have trouble figuring out how the code 
works exactly.Now I am now only focusing on the functions which draw lines.As I 
look into s_lines.c, I saw the _swrast_choose_line().And depends on different 
cases, it will call
_swrast_choose_aa_line_function(ctx)or  
USE(general_line)orUSE(rgba_line)orUSE(simple_no_z_rgba_line)etc.
The first thing I did is looking into the _swrast_choose_aa_line_function() and 
it direct me to s_aaline.cIn that file, I saw the struct of LineInfo and other 
computation functions for plane.Then I looked at the 
_swrast_choose_aa_line_function()
and when I saw the code:swrast-Line = aa_general_rgba_line;andswrast-Line = 
aa_rgba_line;
I am not sure what do they mean. And I won't be able to continue finding useful 
info.
I think the main problem I am having is I am not sure what are the steps OSMesa 
have to take in order to draw a line into the frame buffer. Would you be able 
to explain a bit on that? ( what are the steps OSMesa have to take in order to 
draw a line into the frame buffer?)Does drawing a line involve computing the 
plane?What do s_aaline.c and s_aalinetemp.h actually mean? What is 
USE(general_line) ? Where is USE() define?What is swrast-Line = 
aa_general_rgba_line;?Would you suggest any debugging tool for me so that I can 
trace which functions are called while the program is running?For example I 
have the code below:glBegin(GL_LINES);glVertex3f(0.0, 0.0, 0.0);  
glVertex3f(15, 0, 0);glEnd();Is there any debugging tool which can trace 
glVertex3f back in the library and see how OSMesa works?I have tried using gdb, 
however, it would only by-pass the call the go to the next command.
Thank you so much for your time.
Andy.

 Date: Wed, 10 Jul 2013 12:53:19 -0600
 From: bri...@vmware.com
 To: lilap...@hotmail.com; mesa-dev@lists.freedesktop.org
 Subject: Re: [Mesa-dev] OSMesa Help
 
 Please keep your replies on the list so that others can potentially
 help/reply.
 
 On 07/10/2013 12:05 PM, Andy Li wrote:
  Hi Brain,
  
  Thank you for your reply.
  You were right, my plan is to use OSMesa and draw into malloc'd frame 
  buffer in my device, so I can display the image on the screen.
  
  For base functions, what i meant are the drawline() or drawpix() functions.
  In other words, I am wondering which are the functions OSMesa used to 
  draw a line/pixel into the memory (changing the color/rgba value in 
  frame buffer)?
 
 
 In the swrast code, look at s_lines.c, s_triangle.c, etc. to see how
 lines and triangles are drawn.  In some (simple) cases we can write
 directly into the framebuffer but other times we call functions like
 _swrast_write_rgba_span() to do fragment processing/writing.
 
 To access the framebuffer's memory we use the
 ctx-Driver.Map/UnmapRenderbuffer() functions.
 
 
  Why am I trying to find these functions? The other part of my project is 
  to rewrite these functions with an accelerator, so that I can speed up 
  the rendering process with the embedded system I am using.
  
  Would you be able to give me some info/ suggestions on what I am doing?
 
 See above.  Otherwise, just study the code for a while.  It's not all
 that complicated.
 
 -Brian
 
  
  Thanks,
  
  Andy
  
Date: Wed, 10 Jul 2013 07:49:09 -0600
From: bri...@vmware.com
To: lilap...@hotmail.com
CC: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] OSMesa Help
   
On 07/09/2013 11:20 PM, Andy Li wrote:
 Hello everyone,


 I have some questions regarding to OSMesa.

 I am currently working on a project which I have to use Mesa on an
 embedded system.

 My current goal is to port the base functions over to the embedded
 system, so that I can draw a line on a provided VGA screen.

 Since the embedded system I am using does not contain a GPU, 
  therefore I
 have decided to use OSMesa for rendering process.

 I am wondering if there are any documentations/ specifications for 
  OSMesa?
   
End users of OSMesa generally get by on the comments in osmesa.h and the
example programs. But you're working on the driver implementation side.
   
   
 Anyone know which are the base functions that OSMesa used for the
 rendering process?
   
I don't know what you mean by base functions. In Mesa/master git, the
OSMesa can either be used with the legacy swrast driver or with the
gallium softpipe/llvmpipe drivers.
   
   
 I have looked into src/mesa/swrast/s_lines.c and s_drawpix.c and trying
 to figure out how the code works, am I in the right direction?
   
That code is used by the legacy OSMesa driver, but it's also used by the
old Xlib driver too.
   
   
 Moreover, for example, if I found a drawpix() function, how do I 
  know if
 OSMesa actually used this function during rendering process? Is there
 any tool/debugger I 

[Mesa-dev] [RFC] [PATCH 0/3] Introduce a new EGL/DRI extension for resource sharing with Open CL.

2013-07-14 Thread Zhigang Gong
Hi Kristian,

The OpenCL spec has one extension to support interoperation between OpenGL and 
OpenCL.
The key requirement for this extension is to export an OpenGL resource
(texture/buffer object/render buffer)'s internal attributes to the OpenCL's 
driver side.

IMHO, to support that cl extension we may need to add a new extension to the 
EGL/DRI layer
which let the OpenCL driver could use this interface to query the low level 
attributes of
the resource from the mesa dri driver side. Thus I propose this extension as 
below:

EGLAPI EGLBoolean EGLAPIENTRY eglAcquireResourceMESA(EGLDisplay dpy, EGLContext 
ctx, const EGLenum target, const EGLint *attrib_list, void * user_data);
EGLAPI EGLBoolean EGLAPIENTRY eglReleaseResourceMESA(EGLDisplay dpy, EGLContext 
ctx, const EGLenum target, const EGLint *attrib_list);

The first API is to acquire the specified resource and get the low level 
attribute back
in the driver specified user_data structure. The OpenCL side could use this 
structure to
create a correct buffer object in OpenCL domain. The eglAcquireResourceMESA 
will also
implicitly increase the resoruce's reference counter.

The second API is to be called when the resource is no longer be shared with 
Open CL
domain. It will decrease the resource's reference counter.

The following patchset is to implement this extension, and I also implemented 
the OpenCL side
on Beignet's runtime library. The texture sharing part works fine.

Any comments are welcome and if this new extension is not the right way to 
solve the
original problem, please feel free to point it out and kindly guide which is 
the right
way to implement the cl-gl interoperations. Thanks.

Zhigang Gong (3):
  EGL: introduce a new extension to share resource with external
library.
  DRI: implement helper functions for dri resource sharing extension.
  i965: implement driResourceSharing extension.

 include/EGL/eglext.h   |   19 ++
 include/GL/internal/dri_interface.h|   19 ++
 src/egl/drivers/dri2/egl_dri2.c|  167 +
 src/egl/drivers/dri2/egl_dri2.h|2 +
 src/egl/main/Makefile.am   |4 +-
 src/egl/main/eglapi.c  |   33 
 src/egl/main/eglapi.h  |9 +
 src/egl/main/eglresshare.c |  139 ++
 src/egl/main/eglresshare.h |   47 +
 src/mesa/drivers/dri/common/dri_util.c |   48 +
 src/mesa/drivers/dri/common/dri_util.h |   10 +
 src/mesa/drivers/dri/i965/Makefile.am  |2 +
 src/mesa/drivers/dri/i965/Makefile.sources |1 +
 .../drivers/dri/i965/intel_dri_resource_share.c|  192 
 .../drivers/dri/i965/intel_dri_resource_share.h|   36 
 src/mesa/drivers/dri/i965/intel_screen.c   |9 +-
 src/mesa/drivers/dri/i965/intel_screen.h   |   10 +
 17 files changed, 745 insertions(+), 2 deletions(-)
 create mode 100644 src/egl/main/eglresshare.c
 create mode 100644 src/egl/main/eglresshare.h
 create mode 100644 src/mesa/drivers/dri/i965/intel_dri_resource_share.c
 create mode 100644 src/mesa/drivers/dri/i965/intel_dri_resource_share.h

-- 
1.7.9.5

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


[Mesa-dev] [RFC] [PATCH 1/3] EGL: introduce a new extension to share resource with external library.

2013-07-14 Thread Zhigang Gong
OpenCL has some extension can create CL memory object from GL
textures/buffer objects/render buffers. The existing extension
can't satisfied this requirement. As we need to pass the resource
handler directly to the dri driver layer and get some low level
information back which may include the low level buffer object
handler/name, the internal color format and the layout and tiling
information. Then the external library, say Open CL's driver module,
could use this information to create an shared CL memory object.

As Open CL defines a strict usage model of GL-CL interoperations,
it simplfy the requirement of this extension. We just need to provide
two functions,
1. The acquireResource method to get those information and increase
the underlying reference counter of the buffer object at dri driver layer.
2. The releaseResource method to decrease the underlying reference counter
at dri driver layer.

Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
 include/EGL/eglext.h|   19 
 include/GL/internal/dri_interface.h |   19 
 src/egl/drivers/dri2/egl_dri2.c |  167 +++
 src/egl/drivers/dri2/egl_dri2.h |2 +
 src/egl/main/Makefile.am|4 +-
 src/egl/main/eglapi.c   |   33 +++
 src/egl/main/eglapi.h   |9 ++
 src/egl/main/eglresshare.c  |  139 +
 src/egl/main/eglresshare.h  |   47 ++
 9 files changed, 438 insertions(+), 1 deletion(-)
 create mode 100644 src/egl/main/eglresshare.c
 create mode 100644 src/egl/main/eglresshare.h

diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index 1d68178..1e2be31 100644
--- a/include/EGL/eglext.h
+++ b/include/EGL/eglext.h
@@ -283,6 +283,25 @@ typedef EGLImageKHR (EGLAPIENTRYP 
PFNEGLCREATEDRMIMAGEMESAPROC) (EGLDisplay dpy,
 typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESAPROC) (EGLDisplay 
dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride);
 #endif
 
+#ifndef EGL_MESA_cl_khr_gl_sharing
+#define EGL_MESA_cl_khr_gl_sharing 1
+#define EGL_CLGL_TEXTURE_MESA0x3300  /* eglAcuireResource target */
+#define EGL_CLGL_BUFFER_OBJECT_MESA   0x3301  /* eglAcuireResource target 
*/
+#define EGL_CLGL_RENDER_BUFFER_MESA   0x3302  /* eglAcuireResource target 
*/
+#define EGL_CLGL_TEXTURE_ID_MESA 0x3303  /* eglAcuireResource 
attribute */
+#define EGL_CLGL_TEXTURE_LEVEL_MESA  0x3304  /* eglAcuireResource 
attribute */
+#define EGL_CLGL_TEXTURE_TARGET_MESA 0x3305  /* eglAcuireResource 
attribute */
+#define EGL_CLGL_BUFFER_OBJECT_ID_MESA0x3306  /* eglAcuireResource 
attribute */
+#define EGL_CLGL_RENDER_BUFFER_ID_MESA0x3307  /* eglAcuireResource 
attribute */
+
+#ifdef EGL_EGLEXT_PROTOTYPES
+EGLAPI EGLBoolean EGLAPIENTRY eglAcquireResourceMESA(EGLDisplay dpy, 
EGLContext ctx, const EGLenum target, const EGLint *attrib_list, void * 
user_data);
+EGLAPI EGLBoolean EGLAPIENTRY eglReleaseResourceMESA(EGLDisplay dpy, 
EGLContext ctx, const EGLenum target, const EGLint *attrib_list);
+#endif
+typedef EGLBoolean (EGLAPIENTRYP PFNEGLACQUIRERESOURCEMESAPROC) (EGLDisplay 
dpy, EGLContext ctx, const EGLenum target, const EGLint *attrib_list, void * 
user_data);
+typedef EGLBoolean (EGLAPIENTRYP PFNEGLRELEASERESOURCEMESAPROC) (EGLDisplay 
dpy, EGLContext ctx, const EGLenum target, const EGLint *attrib_list);
+#endif
+
 #ifndef EGL_NV_post_sub_buffer
 #define EGL_NV_post_sub_buffer 1
 #define EGL_POST_SUB_BUFFER_SUPPORTED_NV   0x30BE
diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 30ce175..0d799e6 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1169,6 +1169,25 @@ struct __DRI2configQueryExtensionRec {
 };
 
 /**
+ * This extension allows to share GL resources with OpenCL.
+ */
+#define __DRI_RESOURCE_SHARE DRI_RESOURCE_SHARE
+#define __DRI_RESOURCE_SHARE_VERSION 1
+typedef struct __DRIResourceShareExtensionRec __DRIResourceShareExtension;
+struct __DRIResourceShareExtensionRec {
+   __DRIextension base;
+
+   GLboolean (*acquireTexture)(__DRIcontext *context, GLenum target,
+  GLint level, GLuint texture, void 
*user_data);
+   GLboolean (*releaseTexture)(__DRIcontext *context, GLenum target,
+  GLint level, GLuint texture);
+   GLboolean (*acquireBufferObj)(__DRIcontext *context, GLuint bufobj, void 
*user_data);
+   GLboolean (*releaseBufferObj)(__DRIcontext *context, GLuint bufobj);
+   GLboolean (*acquireRenderBuffer)(__DRIcontext *context, GLuint rb, void 
*user_data);
+   GLboolean (*releaseRenderBuffer)(__DRIcontext *context, GLuint rb);
+};
+
+/**
  * Robust context driver extension.
  *
  * Existence of this extension means the driver can accept the
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 1bce314..c8a2a8b 100644
--- a/src/egl/drivers/dri2/egl_dri2.c

[Mesa-dev] [RFC] [PATCH 2/3] DRI: implement helper functions for dri resource sharing extension.

2013-07-14 Thread Zhigang Gong
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
 src/mesa/drivers/dri/common/dri_util.c |   48 
 src/mesa/drivers/dri/common/dri_util.h |   10 +++
 2 files changed, 58 insertions(+)

diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index 9ed9df4..4f798dc 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -520,6 +520,43 @@ dri2ReleaseBuffer(__DRIscreen *screen, __DRIbuffer *buffer)
 driDriverAPI.ReleaseBuffer(screen, buffer);
 }
 
+static GLboolean
+driAcquireTexture(__DRIcontext *context, GLenum target,
+  GLint level, GLuint texture, void *user_data)
+{
+return driDriverAPI.AcquireTexture(context, target, level, texture, 
user_data);
+}
+
+static GLboolean
+driReleaseTexture(__DRIcontext *context, GLenum target,
+  GLint level, GLuint texture)
+{
+return driDriverAPI.ReleaseTexture(context, target, level, texture);
+}
+
+static GLboolean
+driAcquireBufferObj(__DRIcontext *context, GLuint bufobj, void *user_data)
+{
+return driDriverAPI.AcquireBufferObj(context, bufobj, user_data);
+}
+
+static GLboolean
+driReleaseBufferObj(__DRIcontext *context, GLuint bufobj)
+{
+return driDriverAPI.ReleaseBufferObj(context, bufobj);
+}
+
+static GLboolean
+driAcquireRenderBuffer(__DRIcontext *context, GLuint rb, void *user_data)
+{
+return driDriverAPI.AcquireBufferObj(context, rb, user_data);
+}
+
+static GLboolean
+driReleaseRenderBuffer(__DRIcontext *context, GLuint rb)
+{
+return driDriverAPI.ReleaseBufferObj(context, rb);
+}
 
 static int
 dri2ConfigQueryb(__DRIscreen *screen, const char *var, GLboolean *val)
@@ -603,6 +640,17 @@ const __DRI2configQueryExtension dri2ConfigQueryExtension 
= {
.configQueryf= dri2ConfigQueryf,
 };
 
+const __DRIResourceShareExtension driResourceShareExtension = {
+   .base = { __DRI_RESOURCE_SHARE, __DRI_RESOURCE_SHARE_VERSION },
+
+   .acquireTexture= driAcquireTexture,
+   .releaseTexture= driReleaseTexture,
+   .acquireBufferObj  = driAcquireBufferObj,
+   .releaseBufferObj  = driReleaseBufferObj,
+   .acquireRenderBuffer   = driAcquireRenderBuffer,
+   .releaseRenderBuffer   = driReleaseRenderBuffer
+};
+
 void
 dri2InvalidateDrawable(__DRIdrawable *drawable)
 {
diff --git a/src/mesa/drivers/dri/common/dri_util.h 
b/src/mesa/drivers/dri/common/dri_util.h
index 900f048..393d00a 100644
--- a/src/mesa/drivers/dri/common/dri_util.h
+++ b/src/mesa/drivers/dri/common/dri_util.h
@@ -65,6 +65,7 @@ extern const __DRIcoreExtension driCoreExtension;
 extern const __DRIswrastExtension driSWRastExtension;
 extern const __DRIdri2Extension driDRI2Extension;
 extern const __DRI2configQueryExtension dri2ConfigQueryExtension;
+extern const __DRIResourceShareExtension driResourceShareExtension;
 
 /**
  * Driver callback functions.
@@ -113,6 +114,15 @@ struct __DriverAPIRec {
 int width, int height);
 
 void (*ReleaseBuffer) (__DRIscreen *screenPrivate, __DRIbuffer *buffer);
+
+GLboolean (*AcquireTexture) (__DRIcontext *driContextPriv, GLenum target, 
GLint level, GLuint tex, void *user_data);
+GLboolean (*ReleaseTexture) (__DRIcontext *driContextPriv, GLenum target, 
GLint level, GLuint tex);
+
+GLboolean (*AcquireBufferObj) (__DRIcontext *driContextPriv, GLuint 
bufobj, void *user_data);
+GLboolean (*ReleaseBufferObj) (__DRIcontext *driContextPriv, GLuint 
bufobj);
+
+GLboolean (*AcquireRenderBuffer) (__DRIcontext *driContextPriv, GLuint rb, 
void *user_data);
+GLboolean (*ReleaseRenderBuffer) (__DRIcontext *driContextPriv, GLuint rb);
 };
 
 extern const struct __DriverAPIRec driDriverAPI;
-- 
1.7.9.5

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


[Mesa-dev] [RFC] [PATCH 3/3] i965: implement driResourceSharing extension.

2013-07-14 Thread Zhigang Gong
This patch implements the texture sharing.

Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
 src/mesa/drivers/dri/i965/Makefile.am  |2 +
 src/mesa/drivers/dri/i965/Makefile.sources |1 +
 .../drivers/dri/i965/intel_dri_resource_share.c|  192 
 .../drivers/dri/i965/intel_dri_resource_share.h|   36 
 src/mesa/drivers/dri/i965/intel_screen.c   |9 +-
 src/mesa/drivers/dri/i965/intel_screen.h   |   10 +
 6 files changed, 249 insertions(+), 1 deletion(-)
 create mode 100644 src/mesa/drivers/dri/i965/intel_dri_resource_share.c
 create mode 100644 src/mesa/drivers/dri/i965/intel_dri_resource_share.h

diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index 27c67d1..d456910 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -48,6 +48,8 @@ AM_CFLAGS += \
-DFEATURE_ES2=1
 endif
 
+include_HEADERS = intel_dri_resource_share.h
+
 AM_CXXFLAGS = $(AM_CFLAGS)
 
 dridir = $(DRI_DRIVER_INSTALL_DIR)
diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index 1f401fe..695d9b3 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -14,6 +14,7 @@ i965_FILES = \
intel_regions.c \
intel_resolve_map.c \
intel_screen.c \
+intel_dri_resource_share.c \
intel_pixel.c \
intel_pixel_bitmap.c \
intel_pixel_copy.c \
diff --git a/src/mesa/drivers/dri/i965/intel_dri_resource_share.c 
b/src/mesa/drivers/dri/i965/intel_dri_resource_share.c
new file mode 100644
index 000..ffcc5ce
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/intel_dri_resource_share.c
@@ -0,0 +1,192 @@
+/**
+ *
+ * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include errno.h
+#include time.h
+#include main/glheader.h
+#include main/context.h
+#include main/framebuffer.h
+#include main/renderbuffer.h
+#include main/texobj.h
+#include main/hash.h
+#include main/fbobject.h
+#include main/version.h
+
+#include utils.h
+#include xmlpool.h
+
+#include intel_batchbuffer.h
+#include intel_buffers.h
+#include intel_bufmgr.h
+#include intel_chipset.h
+#include intel_fbo.h
+#include intel_mipmap_tree.h
+#include intel_screen.h
+#include intel_tex.h
+#include intel_regions.h
+#include intel_context.h
+
+#include i915_drm.h
+#include intel_dri_resource_share.h
+
+
+/**
+ * Sets up a DRIImage structure to point to our shared image in a region
+ */
+static GLboolean
+intel_setup_cl_region_from_mipmap_tree(struct intel_context *intel,
+   struct intel_mipmap_tree *mt,
+   GLuint level, GLuint zoffset,
+   struct _intel_dri_share_image_region 
*region)
+{
+   unsigned int draw_x, draw_y;
+   uint32_t mask_x, mask_y;
+   struct intel_region *null_region = (struct intel_region *)NULL;
+
+   intel_miptree_check_level_layer(mt, level, zoffset);
+
+   intel_region_get_tile_masks(mt-region, mask_x, mask_y, false);
+   intel_miptree_get_image_offset(mt, level, zoffset, draw_x, draw_y);
+
+   region-w = mt-level[level].width;
+   region-h = mt-level[level].height;
+   region-tile_x = draw_x  mask_x;
+   region-tile_y = draw_y  mask_y;
+   region-tiling = mt-region-tiling;
+   /* XXX hard code to 1 right now. */
+   region-depth = 1;
+   region-row_pitch = mt-region-pitch;
+
+   region-offset = intel_region_get_aligned_offset(mt-region,
+draw_x  ~mask_x,
+