[Mesa-dev] [PATCH] i965/gs: Fix incorrect numbering of DWORDs in 3DSTATE_GS

[Paul Berry]

In commit 247f90c77e8f3894e963d796628246ba0bde27b5 (i965/gs: Set
control data header size/format appropriately for EndPrimitive()), I
incorrectly numbered the DWORDs in the 3DSTATE_GS command starting
from 1 instead of starting from 0.  This caused the control data
format to be programmed into the wrong DWORD, resulting in corruption
in some geometry shaders that used an output type of points.

This patch numbers the DWORDs starting from 0, as we do for all other
commands, which causes the control data format to be programmed into
the correct DWORD.
---
 src/mesa/drivers/dri/i965/gen7_gs_state.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c 
b/src/mesa/drivers/dri/i965/gen7_gs_state.c
index 4f18485..3dd5896 100644
--- a/src/mesa/drivers/dri/i965/gen7_gs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_gs_state.c
@@ -95,7 +95,7 @@ upload_gs_state(struct brw_context *brw)
  OUT_BATCH(0);
   }
 
-  uint32_t dw5 =
+  uint32_t dw4 =
  ((brw->gs.prog_data->output_vertex_size_hwords * 2 - 1) <<
   GEN7_GS_OUTPUT_VERTEX_SIZE_SHIFT) |
  (brw->gs.prog_data->output_topology <<
@@ -105,7 +105,7 @@ upload_gs_state(struct brw_context *brw)
  (0 << GEN6_GS_URB_ENTRY_READ_OFFSET_SHIFT) |
  (prog_data->dispatch_grf_start_reg <<
   GEN6_GS_DISPATCH_START_GRF_SHIFT);
-  uint32_t dw6 =
+  uint32_t dw5 =
  ((brw->max_gs_threads - 1) << max_threads_shift) |
  (brw->gs.prog_data->control_data_header_size_hwords <<
   GEN7_GS_CONTROL_DATA_HEADER_SIZE_SHIFT) |
@@ -114,6 +114,7 @@ upload_gs_state(struct brw_context *brw)
  (brw->gs.prog_data->include_primitive_id ?
   GEN7_GS_INCLUDE_PRIMITIVE_ID : 0) |
  GEN7_GS_ENABLE;
+  uint32_t dw6 = 0;
 
   if (brw->is_haswell) {
  dw6 |= brw->gs.prog_data->control_data_format <<
@@ -123,9 +124,9 @@ upload_gs_state(struct brw_context *brw)
 IVB_GS_CONTROL_DATA_FORMAT_SHIFT;
   }
 
+  OUT_BATCH(dw4);
   OUT_BATCH(dw5);
   OUT_BATCH(dw6);
-  OUT_BATCH(0);
   ADVANCE_BATCH();
} else {
   BEGIN_BATCH(7);
-- 
1.8.4

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

Re: [Mesa-dev] [PATCH 3/4] glsl/gs: handle gl_ClipDistance geometry input in lower_clip_distance.

[Paul Berry]

On 27 September 2013 14:32, Ian Romanick  wrote:

> There are some bits of this patch I'm trying to understand.  I think
> they can be cleared up by one question below...
>
> On 09/14/2013 01:00 PM, Paul Berry wrote:
> > From: Bryan Cain 
> >
> > This corresponds to the lowering of gl_ClipDistance to
> > gl_ClipDistanceMESA for vertex and geometry shader outputs.  Since
> > this lowering pass occurs after lower_named_interface blocks, it deals
> > with 2D arrays (gl_ClipDistance[vertex][clip_plane]) rather than 1D
> > arrays in an interface block
> > (gl_in[vertex].gl_ClipDistance[clip_plane]).
> >
> > v2 (Paul Berry ): Fix indexing order for
> > gl_ClipDistance input lowering.  Properly lower bulk assignment of
> > gl_ClipDistance inputs.  Rework for GLSL 1.50 style geometry shaders.
> > ---
> >  src/glsl/lower_clip_distance.cpp | 223
> +--
> >  1 file changed, 165 insertions(+), 58 deletions(-)
> >
> > diff --git a/src/glsl/lower_clip_distance.cpp
> b/src/glsl/lower_clip_distance.cpp
> > index d6cf944..16eaef6 100644
> > --- a/src/glsl/lower_clip_distance.cpp
> > +++ b/src/glsl/lower_clip_distance.cpp
> > @@ -53,13 +53,16 @@
> >  class lower_clip_distance_visitor : public ir_rvalue_visitor {
> >  public:
> > lower_clip_distance_visitor()
> > -  : progress(false), old_clip_distance_var(NULL),
> > -new_clip_distance_var(NULL)
> > +  : progress(false), old_clip_distance_1d_var(NULL),
> > +old_clip_distance_2d_var(NULL), new_clip_distance_1d_var(NULL),
> > +new_clip_distance_2d_var(NULL)
> > {
> > }
> >
> > virtual ir_visitor_status visit(ir_variable *);
> > void create_indices(ir_rvalue*, ir_rvalue *&, ir_rvalue *&);
> > +   bool is_clip_distance_vec8(ir_rvalue *ir);
> > +   ir_rvalue *lower_clip_distance_vec8(ir_rvalue *ir);
> > virtual ir_visitor_status visit_leave(ir_assignment *);
> > void visit_new_assignment(ir_assignment *ir);
> > virtual ir_visitor_status visit_leave(ir_call *);
> > @@ -73,12 +76,14 @@ public:
> > /**
> >  * Pointer to the declaration of gl_ClipDistance, if found.
> >  */
> > -   ir_variable *old_clip_distance_var;
> > +   ir_variable *old_clip_distance_1d_var;
> > +   ir_variable *old_clip_distance_2d_var;
> >
> > /**
> >  * Pointer to the newly-created gl_ClipDistanceMESA variable.
> >  */
> > -   ir_variable *new_clip_distance_var;
> > +   ir_variable *new_clip_distance_1d_var;
> > +   ir_variable *new_clip_distance_2d_var;
> >  };
> >
> >
> > @@ -89,30 +94,60 @@ public:
> >  ir_visitor_status
> >  lower_clip_distance_visitor::visit(ir_variable *ir)
> >  {
> > -   /* No point in looking for the declaration of gl_ClipDistance if
> > -* we've already found it.
> > -*/
> > -   if (this->old_clip_distance_var)
> > +   if (!ir->name || strcmp(ir->name, "gl_ClipDistance") != 0)
> >return visit_continue;
> > +   assert (ir->type->is_array());
> > +
> > +   if (!ir->type->element_type()->is_array()) {
> > +  /* 1D gl_ClipDistance (used for vertex and geometry output, and
> fragment
> > +   * input).
> > +   */
> > +  if (this->old_clip_distance_1d_var)
> > + return visit_continue;
> >
> > -   if (ir->name && strcmp(ir->name, "gl_ClipDistance") == 0) {
> >this->progress = true;
> > -  this->old_clip_distance_var = ir;
> > -  assert (ir->type->is_array());
> > +  this->old_clip_distance_1d_var = ir;
> >assert (ir->type->element_type() == glsl_type::float_type);
> >unsigned new_size = (ir->type->array_size() + 3) / 4;
> >
> >/* Clone the old var so that we inherit all of its properties */
> > -  this->new_clip_distance_var = ir->clone(ralloc_parent(ir), NULL);
> > +  this->new_clip_distance_1d_var = ir->clone(ralloc_parent(ir),
> NULL);
> >
> >/* And change the properties that we need to change */
> > -  this->new_clip_distance_var->name
> > - = ralloc_strdup(this->new_clip_distance_var,
> "gl_ClipDistanceMESA");
> > -  this->new_clip_distance_var->type
> > +  this->new_clip_distance_1d_var->name
> > + = ralloc_strdup(this->new_clip_distance_1d_var,
> > + "gl_ClipDistance

[Mesa-dev] [PATCH] i965/fs: Improve accuracy of dFdy() to match dFdx().

[Paul Berry]

Previously, we computed dFdy() using the following instruction:

  add(8) dst<1>F src<4,4,0)F -src.2<4,4,0>F { align1 1Q }

That had the disadvantage that it computed the same value for all 4
pixels of a 2x2 subspan, which meant that it was less accurate than
dFdx().  This patch changes it to the following instruction when
c->key.high_quality_derivatives is set:

  add(8) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1Q }

This gives it comparable accuracy to dFdx().

Unfortunately, for some reason the SIMD16 version of this instruction:

  add(16) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1H }

Doesn't seem to work reliably (presumably the hardware designers never
validated the combination of align16 mode with compressed
instructions), so we unroll it to:

  add(8) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1Q }
  add(8) (dst+1)<1>F (src+1)<4,4,1>.xyxyF -(src+1)<4,4,1>.zwzwF { align16 2Q }

Fixes piglit test spec/glsl-1.10/execution/fs-dfdy-accuracy.
---

Note: this patch needs to be applied atop Chia-I Wu's "i965: compute
DDX in a subspan based only on top row"
(http://lists.freedesktop.org/archives/mesa-dev/2013-September/045544.html).

 src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 77 +++---
 src/mesa/drivers/dri/i965/brw_reg.h|  1 +
 2 files changed, 58 insertions(+), 20 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 9eb5e17..4efedc57 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -560,10 +560,8 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg 
dst, struct brw_reg src
  * sample_d.  On at least Haswell, sample_d instruction does some
  * optimizations if the same LOD is used for all pixels in the subspan.
  *
- * For DDY, it's harder, as we want to produce the pairs swizzled between each
- * other.  We could probably do it like ddx and swizzle the right order later,
- * but bail for now and just produce
- * ((ss0.tl - ss0.bl)x4 (ss1.tl - ss1.bl)x4)
+ * For DDY, we need to use ALIGN16 mode since it's capable of doing the
+ * appropriate swizzling.
  */
 void
 fs_generator::generate_ddx(fs_inst *inst, struct brw_reg dst, struct brw_reg 
src)
@@ -604,22 +602,61 @@ void
 fs_generator::generate_ddy(fs_inst *inst, struct brw_reg dst, struct brw_reg 
src,
  bool negate_value)
 {
-   struct brw_reg src0 = brw_reg(src.file, src.nr, 0,
-BRW_REGISTER_TYPE_F,
-BRW_VERTICAL_STRIDE_4,
-BRW_WIDTH_4,
-BRW_HORIZONTAL_STRIDE_0,
-BRW_SWIZZLE_XYZW, WRITEMASK_XYZW);
-   struct brw_reg src1 = brw_reg(src.file, src.nr, 2,
-BRW_REGISTER_TYPE_F,
-BRW_VERTICAL_STRIDE_4,
-BRW_WIDTH_4,
-BRW_HORIZONTAL_STRIDE_0,
-BRW_SWIZZLE_XYZW, WRITEMASK_XYZW);
-   if (negate_value)
-  brw_ADD(p, dst, src1, negate(src0));
-   else
-  brw_ADD(p, dst, src0, negate(src1));
+   if (c->key.high_quality_derivatives) {
+  /* produce accurate derivatives */
+  struct brw_reg src0 = brw_reg(src.file, src.nr, 0,
+BRW_REGISTER_TYPE_F,
+BRW_VERTICAL_STRIDE_4,
+BRW_WIDTH_4,
+BRW_HORIZONTAL_STRIDE_1,
+BRW_SWIZZLE_XYXY, WRITEMASK_XYZW);
+  struct brw_reg src1 = brw_reg(src.file, src.nr, 0,
+BRW_REGISTER_TYPE_F,
+BRW_VERTICAL_STRIDE_4,
+BRW_WIDTH_4,
+BRW_HORIZONTAL_STRIDE_1,
+BRW_SWIZZLE_ZWZW, WRITEMASK_XYZW);
+  brw_push_insn_state(p);
+  brw_set_access_mode(p, BRW_ALIGN_16);
+  brw_set_compression_control(p, BRW_COMPRESSION_NONE);
+  if (negate_value)
+ brw_ADD(p, dst, src1, negate(src0));
+  else
+ brw_ADD(p, dst, src0, negate(src1));
+  if (dispatch_width == 16) {
+ /* For some reason, instruction compression doesn't seem to work
+  * properly with ALIGN16 mode, so when doing a 16-wide dispatch, just
+  * manually unroll to two instructions.
+  */
+ brw_set_compression_control(p, BRW_COMPRESSION_2NDHALF);
+ src0 = sechalf(src0);
+ src1 = sechalf(src1);
+ dst = sechalf(dst);
+ if (negate_value)
+brw_ADD(p, dst, src1, negate(src0));
+ else
+brw_ADD(p, dst, src0, negate(src1));
+  }
+  brw_pop_insn_state(p);
+   } else {
+  /* replicate the derivative at the top-left pixel 

Re: [Mesa-dev] [PATCH V4 01/13] mesa: add texture gather changes

[Paul Berry]

On 30 September 2013 03:08, Chris Forbes  wrote:

> From: Maxence Le Dore 
>
> Reviewed-by: Kenneth Graunke 
>

This patch broke "make check" for me.  src/mesa/main/tests/test-suite.log
shows:

==
   Mesa 9.3.0-devel: src/mesa/main/tests/test-suite.log
==

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: main-test
===

Running main() from gtest_main.cc
[==] Running 6 tests from 2 test cases.
[--] Global test environment set-up.
[--] 2 tests from EnumStrings
[ RUN  ] EnumStrings.LookUpByNumber
enum_strings.cpp:42: Failure
Value of: _mesa_lookup_enum_by_nr(everything[i].value)
  Actual: "GL_MIN_PROGRAM_TEXTURE_GATHER_OFFSET_ARB"
Expected: everything[i].name
Which is: "GL_MIN_PROGRAM_TEXTURE_GATHER_OFFSET"
enum_strings.cpp:42: Failure
Value of: _mesa_lookup_enum_by_nr(everything[i].value)
  Actual: "GL_MAX_PROGRAM_TEXTURE_GATHER_OFFSET_ARB"
Expected: everything[i].name
Which is: "GL_MAX_PROGRAM_TEXTURE_GATHER_OFFSET"
enum_strings.cpp:42: Failure
Value of: _mesa_lookup_enum_by_nr(everything[i].value)
  Actual: "GL_MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS_ARB"
Expected: everything[i].name
Which is: "GL_MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS"
[  FAILED  ] EnumStrings.LookUpByNumber (0 ms)
[ RUN  ] EnumStrings.LookUpUnknownNumber
[   OK ] EnumStrings.LookUpUnknownNumber (0 ms)
[--] 2 tests from EnumStrings (0 ms total)

[--] 4 tests from DispatchSanity_test
[ RUN  ] DispatchSanity_test.GL31_CORE
[   OK ] DispatchSanity_test.GL31_CORE (2 ms)
[ RUN  ] DispatchSanity_test.GLES11
[   OK ] DispatchSanity_test.GLES11 (0 ms)
[ RUN  ] DispatchSanity_test.GLES2
[   OK ] DispatchSanity_test.GLES2 (1 ms)
[ RUN  ] DispatchSanity_test.GLES3
[   OK ] DispatchSanity_test.GLES3 (0 ms)
[--] 4 tests from DispatchSanity_test (3 ms total)

[--] Global test environment tear-down
[==] 6 tests from 2 test cases ran. (3 ms total)
[  PASSED  ] 5 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] EnumStrings.LookUpByNumber

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

[Mesa-dev] [PATCH 00/19] glsl: Support redeclaration of gl_PerVertex interface blck.

[Paul Berry]

This patch series adds the necessary machinery to the GLSL compiler to
allow shaders to redeclare the gl_PerVertex interface block.  Although
the precise rules for how to redeclare gl_PerVertex were not published
until GLSL 4.10, it seems clear from context that this was intended as
a clarification rather than a change in behaviour, so it makes sense
to implement the rules now.  Also, redeclaration of gl_PerVertex is
required in order to get some corner cases of gl_ClipDistance working
with geometry shaders.

This patch series represents the last of the "scary" geometry shader
tasks.  Everything that's left after this is bug fixing and a lot more
testing.  Once this series lands, I plan to turn on geometry shader
support for i965 so people can start trying it out.

Patches 1-2 make some minor corrections to previous work I've done.
Patches 3-4 create the built-in gl_PerVertex output block (previously
we only created gl_PerVertex for geometry shader inputs).  Patch 5
fixes the interface block comparison code to properly account for the
location field (without this, there would be subtle bugs in later
patches).

Patches 6-11 implement the rules for what's allowed to be declared in
an interface block and what's not, including fixing a bunch of
loopholes where we allowed identifiers starting with "gl_" where we
shouldn't.

Patches 12-15 set up the groundwork for allowing gl_PerVertex to be
redeclared.  Patch 16 adds the ability to redeclare the gl_PerVertex
output interface block.  Patch 17 closes a loophole in detecting
compile-time errors.  Patch 18 adds the ability to redeclare the
gl_PerVertex input interface block.

Finally, patch 19 implements the rule that gl_PerVertex is not allowed
to be redeclared after a shader has used it.

Note: I recently published a piglit series containing the tests that I
used to validate this series.  A few minor corner cases still don't
pass yet:

- gs-redeclares-pervertex-out-after-global-redeclaration.geom
- gs-redeclares-pervertex-out-after-other-global-redeclaration.geom
- gs-redeclares-pervertex-out-before-global-redeclaration.geom
- vs-redeclares-pervertex-out-after-global-redeclaration.vert
- vs-redeclares-pervertex-out-after-other-global-redeclaration.vert
- vs-redeclares-pervertex-out-before-global-redeclaration.vert
- interstage-pervertex-redeclaration-unneeded
- intrastage-pervertex-in-redeclaration-unneeded
- intrastage-pervertex-out-redeclaration-unneeded

I plan to address these corner cases in forthcoming patches once this
series lands.

This series depends on two other patch series that have not yet landed:

- the series starting with "glsl: Keep track of location for interface
  block fields." (partially reviewed by Ian)

- the series called "glsl: Support unsized arrays in interface
  blocks." (not yet reviewed)

To see the series in its proper context, check out branch "gs-phase-5"
of https://github.com/stereotype441/mesa.git.

[PATCH 01/19] glsl: Construct gl_in with a location of -1.
[PATCH 02/19] glsl: Fix block name of built-in gl_PerVertex interface block.
[PATCH 03/19] glsl: Refactor code for creating gl_PerVertex interface block.
[PATCH 04/19] glsl: Construct gl_PerVertex interfaces for GS and VS outputs.
[PATCH 05/19] glsl: Account for location field when comparing interface blocks.
[PATCH 06/19] glsl: Refactor code to check that identifier names are valid.
[PATCH 07/19] glsl: Don't allow unnamed interface blocks to redeclare variables.
[PATCH 08/19] glsl: Don't allow invalid identifiers as interface block names.
[PATCH 09/19] glsl: Don't allow invalid identifier names in struct/interface 
fields.
[PATCH 10/19] glsl: Don't allow invalid identifiers as interface block instance 
names.
[PATCH 11/19] glsl: Don't allow invalid identifiers as struct names.
[PATCH 12/19] glsl: Generalize processing of variable redeclarations.
[PATCH 13/19] glsl: Add an ir_variable::reinit_interface_type() function.
[PATCH 14/19] glsl: Make it possible to remove a variable from the symbol table.
[PATCH 15/19] glsl: Error check redeclarations of gl_PerVertex.
[PATCH 16/19] glsl: Support redeclaration of VS and GS gl_PerVertex output.
[PATCH 17/19] glsl: Catch redeclaration of interface block instance names at 
compile time.
[PATCH 18/19] glsl: Support redeclaration of GS gl_PerVertex input.
[PATCH 19/19] glsl: Don't allow gl_PerVertex to be redeclared after it's been 
used.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 01/19] glsl: Construct gl_in with a location of -1.

[Paul Berry]

We use a location of -1 for variables which don't have their own
assigned locations--this includes ir_variables which represent named
interface blocks.  Technically the location assigned to gl_in doesn't
matter, since gl_in is only accessed via its members (which have their
own locations).  But it's nice to be consistent.
---
 src/glsl/builtin_variables.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 7ab120a..3667dc8 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -829,7 +829,7 @@ builtin_variable_generator::generate_varyings()
GLSL_INTERFACE_PACKING_STD140,
"gl_in");
   ir_variable *var = add_variable("gl_in", array(per_vertex_type, 0),
-  ir_var_shader_in, 0);
+  ir_var_shader_in, -1);
   var->init_interface_type(per_vertex_type);
}
 }
-- 
1.8.4

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

[Mesa-dev] [PATCH 02/19] glsl: Fix block name of built-in gl_PerVertex interface block.

[Paul Berry]

Previously, we erroneously used the name "gl_in" for both the block
name and the instance name.
---
 src/glsl/builtin_variables.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 3667dc8..91518ba 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -827,7 +827,7 @@ builtin_variable_generator::generate_varyings()
  glsl_type::get_interface_instance(this->per_vertex_fields,
this->num_per_vertex_fields,
GLSL_INTERFACE_PACKING_STD140,
-   "gl_in");
+   "gl_PerVertex");
   ir_variable *var = add_variable("gl_in", array(per_vertex_type, 0),
   ir_var_shader_in, -1);
   var->init_interface_type(per_vertex_type);
-- 
1.8.4

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

[Mesa-dev] [PATCH 04/19] glsl: Construct gl_PerVertex interfaces for GS and VS outputs.

[Paul Berry]

Although these interfaces can't be accessed directly by GLSL (since
they don't have an instance name), they will be necessary in order to
allow redeclarations of gl_PerVertex.
---
 src/glsl/builtin_variables.cpp | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 0ab7dda..f97fb8e 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -404,7 +404,8 @@ private:
const glsl_type * const mat3_t;
const glsl_type * const mat4_t;
 
-   per_vertex_accumulator per_vertex;
+   per_vertex_accumulator per_vertex_in;
+   per_vertex_accumulator per_vertex_out;
 };
 
 
@@ -803,10 +804,10 @@ builtin_variable_generator::add_varying(int slot, const 
glsl_type *type,
 {
switch (state->target) {
case geometry_shader:
-  this->per_vertex.add_field(slot, type, name);
+  this->per_vertex_in.add_field(slot, type, name);
   /* FALLTHROUGH */
case vertex_shader:
-  add_output(slot, type, name);
+  this->per_vertex_out.add_field(slot, type, name);
   break;
case fragment_shader:
   add_input(slot, type, name);
@@ -852,11 +853,22 @@ builtin_variable_generator::generate_varyings()
}
 
if (state->target == geometry_shader) {
-  const glsl_type *per_vertex_type =
- this->per_vertex.construct_interface_instance();
-  ir_variable *var = add_variable("gl_in", array(per_vertex_type, 0),
+  const glsl_type *per_vertex_in_type =
+ this->per_vertex_in.construct_interface_instance();
+  ir_variable *var = add_variable("gl_in", array(per_vertex_in_type, 0),
   ir_var_shader_in, -1);
-  var->init_interface_type(per_vertex_type);
+  var->init_interface_type(per_vertex_in_type);
+   }
+   if (state->target == vertex_shader || state->target == geometry_shader) {
+  const glsl_type *per_vertex_out_type =
+ this->per_vertex_out.construct_interface_instance();
+  const glsl_struct_field *fields = per_vertex_out_type->fields.structure;
+  for (unsigned i = 0; i < per_vertex_out_type->length; i++) {
+ ir_variable *var =
+add_variable(fields[i].name, fields[i].type, ir_var_shader_out,
+ fields[i].location);
+ var->init_interface_type(per_vertex_out_type);
+  }
}
 }
 
-- 
1.8.4

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

[Mesa-dev] [PATCH 05/19] glsl: Account for location field when comparing interface blocks.

[Paul Berry]

In commit e2660770731b018411fbe1620cacddaf8dff5287 (glsl: Keep track
of location for interface block fields), I neglected to update
glsl_type::record_key_compare to account for the fact that interface
types now contain location information.  As a result, interface types
that differ only by their location information would not be properly
distinguished.

At the moment this is not a problem, because the only interface block
in which location information != -1 is gl_PerVertex, and gl_PerVertex
is always created in the same way.  However, in the patches that
follow, we'll be adding new ways to create gl_PerVertex (by
redeclaring it), so we'll need location information to be handled
properly.
---
 src/glsl/glsl_types.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 4782d15..84414fd 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -452,6 +452,9 @@ glsl_type::record_key_compare(const void *a, const void *b)
   if (key1->fields.structure[i].row_major
  != key2->fields.structure[i].row_major)
 return 1;
+  if (key1->fields.structure[i].location
+  != key2->fields.structure[i].location)
+ return 1;
}
 
return 0;
-- 
1.8.4

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

[Mesa-dev] [PATCH 06/19] glsl: Refactor code to check that identifier names are valid.

[Paul Berry]

GLSL reserves identifiers beginning with "gl_" or containing "__", but
we haven't been consistent about enforcing this rule.  This patch
makes a new function to check whether identifier names are valid.  In
the process it closes a loophole where we would previously allow
function argument names to contain "__".
---
 src/glsl/ast_to_hir.cpp | 65 -
 1 file changed, 32 insertions(+), 33 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index c1e3c08..f4f81e0 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2649,6 +2649,36 @@ handle_geometry_shader_input_decl(struct 
_mesa_glsl_parse_state *state,
}
 }
 
+
+void
+check_valid_identifier(const char *identifier, YYLTYPE loc,
+   struct _mesa_glsl_parse_state *state)
+{
+   /* From page 15 (page 21 of the PDF) of the GLSL 1.10 spec,
+*
+*   "Identifiers starting with "gl_" are reserved for use by
+*   OpenGL, and may not be declared in a shader as either a
+*   variable or a function."
+*/
+   if (strncmp(identifier, "gl_", 3) == 0)
+  _mesa_glsl_error(&loc, state,
+   "identifier `%s' uses reserved `gl_' prefix",
+   identifier);
+   else if (strstr(identifier, "__")) {
+  /* From page 14 (page 20 of the PDF) of the GLSL 1.10
+   * spec:
+   *
+   * "In addition, all identifiers containing two
+   *  consecutive underscores (__) are reserved as
+   *  possible future keywords."
+   */
+  _mesa_glsl_error(&loc, state,
+   "identifier `%s' uses reserved `__' string",
+   identifier);
+   }
+}
+
+
 ir_rvalue *
 ast_declarator_list::hir(exec_list *instructions,
 struct _mesa_glsl_parse_state *state)
@@ -3243,28 +3273,7 @@ ast_declarator_list::hir(exec_list *instructions,
* created for the declaration should be added to the IR stream.
*/
   if (earlier == NULL) {
-/* From page 15 (page 21 of the PDF) of the GLSL 1.10 spec,
- *
- *   "Identifiers starting with "gl_" are reserved for use by
- *   OpenGL, and may not be declared in a shader as either a
- *   variable or a function."
- */
-if (strncmp(decl->identifier, "gl_", 3) == 0)
-   _mesa_glsl_error(& loc, state,
-"identifier `%s' uses reserved `gl_' prefix",
-decl->identifier);
-else if (strstr(decl->identifier, "__")) {
-   /* From page 14 (page 20 of the PDF) of the GLSL 1.10
-* spec:
-*
-* "In addition, all identifiers containing two
-*  consecutive underscores (__) are reserved as
-*  possible future keywords."
-*/
-   _mesa_glsl_error(& loc, state,
-"identifier `%s' uses reserved `__' string",
-decl->identifier);
-}
+ check_valid_identifier(decl->identifier, loc, state);
 
 /* Add the variable to the symbol table.  Note that the initializer's
  * IR was already processed earlier (though it hasn't been emitted
@@ -3505,17 +3514,7 @@ ast_function::hir(exec_list *instructions,
   "function body", name);
}
 
-   /* From page 15 (page 21 of the PDF) of the GLSL 1.10 spec,
-*
-*   "Identifiers starting with "gl_" are reserved for use by
-*   OpenGL, and may not be declared in a shader as either a
-*   variable or a function."
-*/
-   if (strncmp(name, "gl_", 3) == 0) {
-  YYLTYPE loc = this->get_location();
-  _mesa_glsl_error(&loc, state,
-  "identifier `%s' uses reserved `gl_' prefix", name);
-   }
+   check_valid_identifier(name, this->get_location(), state);
 
/* Convert the list of function parameters to HIR now so that they can be
 * used below to compare this function's signature with previously seen
-- 
1.8.4

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

[Mesa-dev] [PATCH 07/19] glsl: Don't allow unnamed interface blocks to redeclare variables.

[Paul Berry]

Note: some limited amount of redeclaration is actually allowed,
provided the shader is redeclaring the built-in gl_PerVertex interface
block.  Support for this will be added in future patches.

Fixes piglit tests
spec/glsl-1.50/compiler/unnamed-interface-block-elem-conflicts-with-prev-{block-elem,global}.vert.
---
 src/glsl/ast_to_hir.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index f4f81e0..3615587 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4742,6 +4742,9 @@ ast_interface_block::hir(exec_list *instructions,
var_mode);
  var->init_interface_type(block_type);
 
+ if (state->symbols->get_variable(var->name) != NULL)
+_mesa_glsl_error(&loc, state, "`%s' redeclared", var->name);
+
  /* Propagate the "binding" keyword into this UBO's fields;
   * the UBO declaration itself doesn't get an ir_variable unless it
   * has an instance name.  This is ugly.
-- 
1.8.4

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

[Mesa-dev] [PATCH 08/19] glsl: Don't allow invalid identifiers as interface block names.

[Paul Berry]

Note: we need to make an exception for the gl_PerVertex interface
block, since this is allowed to be redeclared.  Future patches will
make redeclaration of gl_PerVertex work properly.

Fixes piglit test
spec/glsl-1.50/compiler/interface-block-name-uses-gl-prefix.vert.
---
 src/glsl/ast_to_hir.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 3615587..e2ec23c 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4614,6 +4614,7 @@ ast_interface_block::hir(exec_list *instructions,
   packing = GLSL_INTERFACE_PACKING_STD140;
}
 
+   bool redeclaring_per_vertex = strcmp(this->block_name, "gl_PerVertex") == 0;
bool block_row_major = this->layout.flags.q.row_major;
exec_list declared_variables;
glsl_struct_field *fields;
@@ -4643,6 +4644,9 @@ ast_interface_block::hir(exec_list *instructions,
   assert(!"interface block layout qualifier not found!");
}
 
+   if (!redeclaring_per_vertex)
+  check_valid_identifier(this->block_name, loc, state);
+
const glsl_type *block_type =
   glsl_type::get_interface_instance(fields,
 num_variables,
-- 
1.8.4

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

[Mesa-dev] [PATCH 09/19] glsl: Don't allow invalid identifier names in struct/interface fields.

[Paul Berry]

Note: we need to make an exception for the gl_PerVertex interface
block, since built-in variables are allowed to be redeclared inside
it.  Future patches will make redeclaration of gl_PerVertex work
properly.

Fixes piglit tests:
- spec/glsl-1.50/compiler/interface-block-array-elem-uses-gl-prefix.vert
- spec/glsl-1.50/compiler/named-interface-block-elem-uses-gl-prefix.vert
- spec/glsl-1.50/compiler/unnamed-interface-block-elem-uses-gl-prefix.vert
---
 src/glsl/ast_to_hir.cpp | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index e2ec23c..aabf201 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4410,7 +4410,8 @@ ast_process_structure_or_interface_block(exec_list 
*instructions,
 YYLTYPE &loc,
 glsl_struct_field **fields_ret,
  bool is_interface,
- bool block_row_major)
+ bool block_row_major,
+ bool allow_reserved_names)
 {
unsigned decl_count = 0;
 
@@ -4452,6 +4453,9 @@ ast_process_structure_or_interface_block(exec_list 
*instructions,
 
   foreach_list_typed (ast_declaration, decl, link,
  &decl_list->declarations) {
+ if (!allow_reserved_names)
+check_valid_identifier(decl->identifier, loc, state);
+
  /* From the GL_ARB_uniform_buffer_object spec:
   *
   * "Sampler types are not allowed inside of uniform
@@ -4568,7 +4572,8 @@ ast_struct_specifier::hir(exec_list *instructions,
   loc,
   &fields,
false,
-   false);
+   false,
+   false /* allow_reserved_names 
*/);
 
const glsl_type *t =
   glsl_type::get_record_instance(fields, decl_count, this->name);
@@ -4625,7 +4630,8 @@ ast_interface_block::hir(exec_list *instructions,
loc,
&fields,
true,
-   block_row_major);
+   block_row_major,
+   redeclaring_per_vertex);
 
ir_variable_mode var_mode;
const char *iface_type_name;
-- 
1.8.4

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

[Mesa-dev] [PATCH 10/19] glsl: Don't allow invalid identifiers as interface block instance names.

[Paul Berry]

Note: we need to make an exception for the gl_PerVertex interface
block, since in geometry shaders it is allowed to be redeclared with
the instance name gl_in.  Future patches will make redeclaration of
gl_PerVertex work properly.

Fixes piglit test
spec/glsl-1.50/compiler/interface-block-instance-name-uses-gl-prefix.vert.
---
 src/glsl/ast_to_hir.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index aabf201..bb14fc9 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4692,6 +4692,9 @@ ast_interface_block::hir(exec_list *instructions,
 * field selector ( . ) operator (analogously to structures)."
 */
if (this->instance_name) {
+  if (!redeclaring_per_vertex)
+ check_valid_identifier(this->instance_name, loc, state);
+
   ir_variable *var;
 
   if (this->is_array) {
-- 
1.8.4

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

[Mesa-dev] [PATCH 11/19] glsl: Don't allow invalid identifiers as struct names.

[Paul Berry]

Fixes piglit test
spec/glsl-1.10/compiler/struct/struct-name-uses-gl-prefix.vert.
---
 src/glsl/ast_to_hir.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index bb14fc9..8fb7f2f 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4575,6 +4575,8 @@ ast_struct_specifier::hir(exec_list *instructions,
false,
false /* allow_reserved_names 
*/);
 
+   check_valid_identifier(this->name, loc, state);
+
const glsl_type *t =
   glsl_type::get_record_instance(fields, decl_count, this->name);
 
-- 
1.8.4

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

[Mesa-dev] [PATCH 12/19] glsl: Generalize processing of variable redeclarations.

[Paul Berry]

This patch modifies the get_variable_being_redeclared() function so
that it no longer relies on the ast_declaration for the variable being
redeclared.  In future patches, this will allow
get_variable_being_redeclared() to be used for processing
redeclarations of the built-in gl_PerVertex interface block.
---
 src/glsl/ast_to_hir.cpp | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 8fb7f2f..de65c71 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2327,7 +2327,7 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
  * is a redeclaration, \c NULL otherwise.
  */
 ir_variable *
-get_variable_being_redeclared(ir_variable *var, ast_declaration *decl,
+get_variable_being_redeclared(ir_variable *var, YYLTYPE loc,
  struct _mesa_glsl_parse_state *state)
 {
/* Check if this declaration is actually a re-declaration, either to
@@ -2336,16 +2336,14 @@ get_variable_being_redeclared(ir_variable *var, 
ast_declaration *decl,
 * This is allowed for variables in the current scope, or when at
 * global scope (for built-ins in the implicit outer scope).
 */
-   ir_variable *earlier = state->symbols->get_variable(decl->identifier);
+   ir_variable *earlier = state->symbols->get_variable(var->name);
if (earlier == NULL ||
(state->current_function != NULL &&
-   !state->symbols->name_declared_this_scope(decl->identifier))) {
+   !state->symbols->name_declared_this_scope(var->name))) {
   return NULL;
}
 
 
-   YYLTYPE loc = decl->get_location();
-
/* From page 24 (page 30 of the PDF) of the GLSL 1.50 spec,
 *
 * "It is legal to declare an array without a size and then
@@ -2434,7 +2432,7 @@ get_variable_being_redeclared(ir_variable *var, 
ast_declaration *decl,
   earlier->depth_layout = var->depth_layout;
 
} else {
-  _mesa_glsl_error(&loc, state, "`%s' redeclared", decl->identifier);
+  _mesa_glsl_error(&loc, state, "`%s' redeclared", var->name);
}
 
return earlier;
@@ -3221,7 +3219,8 @@ ast_declarator_list::hir(exec_list *instructions,
* instruction stream.
*/
   exec_list initializer_instructions;
-  ir_variable *earlier = get_variable_being_redeclared(var, decl, state);
+  ir_variable *earlier =
+ get_variable_being_redeclared(var, decl->get_location(), state);
 
   if (decl->initializer != NULL) {
 result = process_initializer((earlier == NULL) ? var : earlier,
-- 
1.8.4

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

[Mesa-dev] [PATCH 13/19] glsl: Add an ir_variable::reinit_interface_type() function.

[Paul Berry]

This will be used by future patches to change an ir_variable's
interface type when the gl_PerVertex built-in interface block is
redeclared.
---
 src/glsl/ir.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 25c7e82..595c935 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -436,6 +436,31 @@ public:
   this->interface_type = type;
}
 
+   /**
+* Change this->interface_type on a variable that previously had a
+* different, and incompatible, interface_type. This is used during
+* compilation to handle redeclaration of the built-in gl_PerVertex
+* interface block.
+*/
+   void reinit_interface_type(const struct glsl_type *type)
+   {
+  if (this->max_ifc_array_access != NULL) {
+#ifndef _NDEBUG
+ /* Redeclaring gl_PerVertex is only allowed if none of the built-ins
+  * it defines have been accessed yet; so it's safe to throw away the
+  * old max_ifc_array_access pointer, since all of its values are
+  * zero.
+  */
+ for (unsigned i = 0; i < this->interface_type->length; i++)
+assert(this->max_ifc_array_access[i] == 0);
+#endif
+ ralloc_free(this->max_ifc_array_access);
+ this->max_ifc_array_access = NULL;
+  }
+  this->interface_type = NULL;
+  init_interface_type(type);
+   }
+
const glsl_type *get_interface_type() const
{
   return this->interface_type;
-- 
1.8.4

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

[Mesa-dev] [PATCH 14/19] glsl: Make it possible to remove a variable from the symbol table.

[Paul Berry]

In later patches, we'll use this in order to implement the required
behaviour that after the gl_PerVertex interface block has been
redeclared, only members of the redeclared interface block may be
used.
---
 src/glsl/glsl_symbol_table.cpp | 9 +
 src/glsl/glsl_symbol_table.h   | 7 +++
 2 files changed, 16 insertions(+)

diff --git a/src/glsl/glsl_symbol_table.cpp b/src/glsl/glsl_symbol_table.cpp
index 6e916b4..694713a 100644
--- a/src/glsl/glsl_symbol_table.cpp
+++ b/src/glsl/glsl_symbol_table.cpp
@@ -256,3 +256,12 @@ symbol_table_entry *glsl_symbol_table::get_entry(const 
char *name)
return (symbol_table_entry *)
   _mesa_symbol_table_find_symbol(table, -1, name);
 }
+
+void
+glsl_symbol_table::remove_variable(const char *name)
+{
+   symbol_table_entry *entry = get_entry(name);
+   if (entry != NULL) {
+  entry->v = NULL;
+   }
+}
diff --git a/src/glsl/glsl_symbol_table.h b/src/glsl/glsl_symbol_table.h
index 62d26b8..b73db3b 100644
--- a/src/glsl/glsl_symbol_table.h
+++ b/src/glsl/glsl_symbol_table.h
@@ -121,6 +121,13 @@ public:
   enum ir_variable_mode mode);
/*@}*/
 
+   /**
+* Remove a variable from the symbol table.  This is necessary when
+* gl_PerVertex is redeclared, to ensure that previously-available built-in
+* variables are no longer available.
+*/
+   void remove_variable(const char *name);
+
 private:
symbol_table_entry *get_entry(const char *name);
 
-- 
1.8.4

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

[Mesa-dev] [PATCH 15/19] glsl: Error check redeclarations of gl_PerVertex.

[Paul Berry]

This patch verifies that:

- The gl_PerVertex input interface block may only be redeclared in a
  geometry shader, and that it may only be redeclared as gl_in[].

- The gl_PerVertex output interface block may only be redeclared in a
  vertex or geometry shader, and that it may only be redeclared as a
  non-array without an interface name.

- gl_PerVertex may not be redeclared as any other type of interface
  block (i.e. as a uniform interface block).

As a side-effect, the code now keeps track of what the previous
declaration of gl_PerVertex was--this will be needed in future
patches.

Fixes piglit tests:
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-in-with-incorrect-name.geom
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-as-array.geom
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-with-instance-name.geom
---
 src/glsl/ast_to_hir.cpp | 60 +
 1 file changed, 60 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index de65c71..0badac7 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4654,6 +4654,66 @@ ast_interface_block::hir(exec_list *instructions,
if (!redeclaring_per_vertex)
   check_valid_identifier(this->block_name, loc, state);
 
+   const glsl_type *earlier_per_vertex = NULL;
+   if (redeclaring_per_vertex) {
+  /* Find the previous declaration of gl_PerVertex.  If we're redeclaring
+   * the named interface block gl_in, we can find it by looking at the
+   * previous declaration of gl_in.  Otherwise we can find it by looking
+   * at the previous decalartion of any of the built-in outputs,
+   * e.g. gl_Position.
+   *
+   * Also check that the instance name and array-ness of the redeclaration
+   * are correct.
+   */
+  switch (var_mode) {
+  case ir_var_shader_in:
+ if (ir_variable *earlier_gl_in =
+ state->symbols->get_variable("gl_in")) {
+earlier_per_vertex = earlier_gl_in->get_interface_type();
+ } else {
+_mesa_glsl_error(&loc, state,
+ "redeclaration of gl_PerVertex input not allowed "
+ "in the %s shader",
+ _mesa_glsl_shader_target_name(state->target));
+ }
+ if (this->instance_name == NULL ||
+ strcmp(this->instance_name, "gl_in") != 0 || !this->is_array) {
+_mesa_glsl_error(&loc, state,
+ "gl_PerVertex input must be redeclared as "
+ "gl_in[]");
+ }
+ break;
+  case ir_var_shader_out:
+ if (ir_variable *earlier_gl_Position =
+ state->symbols->get_variable("gl_Position")) {
+earlier_per_vertex = earlier_gl_Position->get_interface_type();
+ } else {
+_mesa_glsl_error(&loc, state,
+ "redeclaration of gl_PerVertex output not "
+ "allowed in the %s shader",
+ _mesa_glsl_shader_target_name(state->target));
+ }
+ if (this->instance_name != NULL) {
+_mesa_glsl_error(&loc, state,
+ "gl_PerVertex input may not be redeclared with "
+ "an instance name");
+ }
+ break;
+  default:
+ _mesa_glsl_error(&loc, state,
+  "gl_PerVertex must be declared as an input or an "
+  "output");
+ break;
+  }
+
+  if (earlier_per_vertex == NULL) {
+ /* An error has already been reported.  Bail out to avoid null
+  * dereferences later in this function.
+  */
+ return NULL;
+  }
+   }
+
const glsl_type *block_type =
   glsl_type::get_interface_instance(fields,
 num_variables,
-- 
1.8.4

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

[Mesa-dev] [PATCH 16/19] glsl: Support redeclaration of VS and GS gl_PerVertex output.

[Paul Berry]

Fixes piglit tests:
- spec/glsl-1.50/execution/redeclare-pervertex-out-subset-gs
- spec/glsl-1.50/execution/redeclare-pervertex-subset-vs
---
 src/glsl/ast_to_hir.cpp | 62 +++--
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 0badac7..c8a38e7 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2328,7 +2328,8 @@ apply_type_qualifier_to_variable(const struct 
ast_type_qualifier *qual,
  */
 ir_variable *
 get_variable_being_redeclared(ir_variable *var, YYLTYPE loc,
- struct _mesa_glsl_parse_state *state)
+ struct _mesa_glsl_parse_state *state,
+  bool allow_all_redeclarations)
 {
/* Check if this declaration is actually a re-declaration, either to
 * resize an array or add qualifiers to an existing variable.
@@ -2431,6 +2432,16 @@ get_variable_being_redeclared(ir_variable *var, YYLTYPE 
loc,
 
   earlier->depth_layout = var->depth_layout;
 
+   } else if (allow_all_redeclarations) {
+  if (earlier->mode != var->mode) {
+ _mesa_glsl_error(&loc, state,
+  "redeclaration of `%s' with incorrect qualifiers",
+  var->name);
+  } else if (earlier->type != var->type) {
+ _mesa_glsl_error(&loc, state,
+  "redeclaration of `%s' has incorrect type",
+  var->name);
+  }
} else {
   _mesa_glsl_error(&loc, state, "`%s' redeclared", var->name);
}
@@ -3220,7 +3231,8 @@ ast_declarator_list::hir(exec_list *instructions,
*/
   exec_list initializer_instructions;
   ir_variable *earlier =
- get_variable_being_redeclared(var, decl->get_location(), state);
+ get_variable_being_redeclared(var, decl->get_location(), state,
+   false /* allow_all_redeclarations */);
 
   if (decl->initializer != NULL) {
 result = process_initializer((earlier == NULL) ? var : earlier,
@@ -4816,6 +4828,20 @@ ast_interface_block::hir(exec_list *instructions,
var_mode);
  var->init_interface_type(block_type);
 
+ if (redeclaring_per_vertex) {
+ir_variable *earlier =
+   get_variable_being_redeclared(var, loc, state,
+ true /* allow_all_redeclarations 
*/);
+if (strncmp(var->name, "gl_", 3) != 0 || earlier == NULL) {
+   _mesa_glsl_error(&loc, state,
+"redeclaration of gl_PerVertex can only "
+"include built-in variables");
+} else {
+   earlier->reinit_interface_type(block_type);
+}
+continue;
+ }
+
  if (state->symbols->get_variable(var->name) != NULL)
 _mesa_glsl_error(&loc, state, "`%s' redeclared", var->name);
 
@@ -4829,6 +4855,38 @@ ast_interface_block::hir(exec_list *instructions,
  state->symbols->add_variable(var);
  instructions->push_tail(var);
   }
+
+  if (redeclaring_per_vertex && block_type != earlier_per_vertex) {
+ /* From section 7.1 ("Built-in Language Variables") of the GLSL 4.10 
spec:
+  *
+  * It is also a compilation error ... to redeclare a built-in
+  * block and then use a member from that built-in block that was
+  * not included in the redeclaration.
+  *
+  * This appears to be a clarification to the behaviour established
+  * for gl_PerVertex by GLSL 1.50, therefore we implement this
+  * behaviour regardless of GLSL version.
+  *
+  * To prevent the shader from using a member that was not included in
+  * the redeclaration, we simply remove any ir_variables that are
+  * still associated with the old declaration of gl_PerVertex (since
+  * we've already updated all of the variables contained in the new
+  * gl_PerVertex to point to it).
+  *
+  * As a side effect this will prevent
+  * validate_intrastage_interface_blocks() from getting confused and
+  * thinking there are conflicting definitions of gl_PerVertex in the
+  * shader.
+  */
+ foreach_list_safe(node, instructions) {
+ir_variable *const var = ((ir_instruction *) node)->as_variable();
+if (var != NULL &&
+var->get_interface_type() == earlier_per_vertex) {
+   state->symbols->remove_variable(var->name);
+   var->remove();
+}
+ }
+  }
}
 
return NULL;
-- 
1.8.4

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

[Mesa-dev] [PATCH 17/19] glsl: Catch redeclaration of interface block instance names at compile time.

[Paul Berry]

>From section 4.1.9 (Arrays) of the GLSL 4.40 spec (as of revision 7):

However, unless noted otherwise, blocks cannot be redeclared;
an unsized array in a user-declared block cannot be sized
through redeclaration.

The only place where the spec notes that interface blocks can be
redeclared is to allow for redeclaration of built-in interface blocks
such as gl_PerVertex.  Therefore, user-defined interface blocks can
never be redeclared.  This is a clarification of previous intent (see
Khronos bug 10659:
https://cvs.khronos.org/bugzilla/show_bug.cgi?id=10659).

We were already preventing interface block redeclaration using the
same block name at compile time, but we weren't preventing interface
block redeclaration using the same instance name (and different block
names) at compile time.  And we weren't preventing an instance name
from conflicting with a previously-declared ordinary variable.

In practice the problem would be caught at link time, but only because
of a coincidence: since ast_interface_block::hir() wasn't doing any
checking to see if the instance name already existed in the shader, it
was creating a second ir_variable in the shader having the same name
but a different type.  Coincidentally, when the linker checked for
intrastage consistency of global variable declarations, it treated the
two declarations from the same shader as a conflict, so it reported a
link error.

But it seems dangerous to rely on that linker behaviour to catch
illegal redeclarations that really ought to be detected at compile
time.
---
 src/glsl/ast_to_hir.cpp | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index c8a38e7..f44e97d 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4813,8 +4813,14 @@ ast_interface_block::hir(exec_list *instructions,
   var->init_interface_type(block_type);
   if (state->target == geometry_shader && var_mode == ir_var_shader_in)
  handle_geometry_shader_input_decl(state, loc, var);
-  state->symbols->add_variable(var);
-  instructions->push_tail(var);
+
+  if (state->symbols->get_variable(this->instance_name)) {
+ _mesa_glsl_error(&loc, state, "`%s' redeclared", this->instance_name);
+ delete var;
+  } else {
+ state->symbols->add_variable(var);
+ instructions->push_tail(var);
+  }
} else {
   /* In order to have an array size, the block must also be declared with
* an instane name.
-- 
1.8.4

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

[Mesa-dev] [PATCH 18/19] glsl: Support redeclaration of GS gl_PerVertex input.

[Paul Berry]

Fixes piglit test
spec/glsl-1.50/execution/redeclare-pervertex-subset-vs-to-gs.
---
 src/glsl/ast_to_hir.cpp | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index f44e97d..a4af562 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4724,6 +4724,19 @@ ast_interface_block::hir(exec_list *instructions,
   */
  return NULL;
   }
+
+  /* Copy locations from the old gl_PerVertex interface block. */
+  for (unsigned i = 0; i < num_variables; i++) {
+ int j = earlier_per_vertex->field_index(fields[i].name);
+ if (j == -1) {
+_mesa_glsl_error(&loc, state,
+ "redeclaration of gl_PerVertex must be a subset "
+ "of the built-in members of gl_PerVertex");
+ } else {
+fields[i].location =
+   earlier_per_vertex->fields.structure[j].location;
+ }
+  }
}
 
const glsl_type *block_type =
@@ -4814,8 +4827,14 @@ ast_interface_block::hir(exec_list *instructions,
   if (state->target == geometry_shader && var_mode == ir_var_shader_in)
  handle_geometry_shader_input_decl(state, loc, var);
 
-  if (state->symbols->get_variable(this->instance_name)) {
- _mesa_glsl_error(&loc, state, "`%s' redeclared", this->instance_name);
+  if (ir_variable *earlier =
+  state->symbols->get_variable(this->instance_name)) {
+ if (!redeclaring_per_vertex) {
+_mesa_glsl_error(&loc, state, "`%s' redeclared",
+ this->instance_name);
+ }
+ earlier->type = var->type;
+ earlier->reinit_interface_type(block_type);
  delete var;
   } else {
  state->symbols->add_variable(var);
-- 
1.8.4

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

[Mesa-dev] [PATCH 19/19] glsl: Don't allow gl_PerVertex to be redeclared after it's been used.

[Paul Berry]

Fixes piglit tests:
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-in-after-other-usage.geom
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-after-other-usage.geom
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-after-usage.geom
- spec/glsl-1.50/compiler/vs-redeclares-pervertex-out-after-other-usage.vert
- spec/glsl-1.50/compiler/vs-redeclares-pervertex-out-after-usage.vert
---
 src/glsl/ast_to_hir.cpp | 53 +
 1 file changed, 53 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index a4af562..0294036 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4611,6 +4611,39 @@ ast_struct_specifier::hir(exec_list *instructions,
return NULL;
 }
 
+
+/**
+ * Visitor class which detects whether a given interface block has been used.
+ */
+class interface_block_usage_visitor : public ir_hierarchical_visitor
+{
+public:
+   interface_block_usage_visitor(ir_variable_mode mode, const glsl_type *block)
+  : mode(mode), block(block), found(false)
+   {
+   }
+
+   virtual ir_visitor_status visit(ir_dereference_variable *ir)
+   {
+  if (ir->var->mode == mode && ir->var->get_interface_type() == block) {
+ found = true;
+ return visit_stop;
+  }
+  return visit_continue;
+   }
+
+   bool usage_found() const
+   {
+  return this->found;
+   }
+
+private:
+   ir_variable_mode mode;
+   const glsl_type *block;
+   bool found;
+};
+
+
 ir_rvalue *
 ast_interface_block::hir(exec_list *instructions,
  struct _mesa_glsl_parse_state *state)
@@ -4737,6 +4770,26 @@ ast_interface_block::hir(exec_list *instructions,
earlier_per_vertex->fields.structure[j].location;
  }
   }
+
+  /* From section 7.1 ("Built-in Language Variables") of the GLSL 4.10
+   * spec:
+   *
+   * If a built-in interface block is redeclared, it must appear in
+   * the shader before any use of any member included in the built-in
+   * declaration, or a compilation error will result.
+   *
+   * This appears to be a clarification to the behaviour established for
+   * gl_PerVertex by GLSL 1.50, therefore we implement this behaviour
+   * regardless of GLSL version.
+   */
+  interface_block_usage_visitor v(var_mode, earlier_per_vertex);
+  v.run(instructions);
+  if (v.usage_found()) {
+ _mesa_glsl_error(&loc, state,
+  "redeclaration of a built-in interface block must "
+  "appear before any use of any member of the "
+  "interface block");
+  }
}
 
const glsl_type *block_type =
-- 
1.8.4

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

[Mesa-dev] [PATCH 03/19] glsl: Refactor code for creating gl_PerVertex interface block.

[Paul Berry]

Currently, we create just a single gl_PerVertex interface block for
geometry shader inputs.  In later patches, we'll also need to create
an interface block for geometry and vertex shader outputs.  Moving the
code into its own class will make reuse easier.
---
 src/glsl/builtin_variables.cpp | 72 --
 1 file changed, 49 insertions(+), 23 deletions(-)

diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 91518ba..0ab7dda 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -293,6 +293,51 @@ static const struct gl_builtin_uniform_desc 
_mesa_builtin_uniform_desc[] = {
 
 namespace {
 
+/**
+ * Data structure that accumulates fields for the gl_PerVertex interface
+ * block.
+ */
+class per_vertex_accumulator
+{
+public:
+   per_vertex_accumulator();
+   void add_field(int slot, const glsl_type *type, const char *name);
+   const glsl_type *construct_interface_instance() const;
+
+private:
+   glsl_struct_field fields[10];
+   unsigned num_fields;
+};
+
+
+per_vertex_accumulator::per_vertex_accumulator()
+   : num_fields(0)
+{
+}
+
+
+void
+per_vertex_accumulator::add_field(int slot, const glsl_type *type,
+  const char *name)
+{
+   assert(this->num_fields < ARRAY_SIZE(this->fields));
+   this->fields[this->num_fields].type = type;
+   this->fields[this->num_fields].name = name;
+   this->fields[this->num_fields].row_major = false;
+   this->fields[this->num_fields].location = slot;
+   this->num_fields++;
+}
+
+
+const glsl_type *
+per_vertex_accumulator::construct_interface_instance() const
+{
+   return glsl_type::get_interface_instance(this->fields, this->num_fields,
+GLSL_INTERFACE_PACKING_STD140,
+"gl_PerVertex");
+}
+
+
 class builtin_variable_generator
 {
 public:
@@ -359,16 +404,7 @@ private:
const glsl_type * const mat3_t;
const glsl_type * const mat4_t;
 
-   /**
-* Array where the contents of the gl_PerVertex interface instance are
-* accumulated.
-*/
-   glsl_struct_field per_vertex_fields[10];
-
-   /**
-* Number of elements of per_vertex_fields which have been populated.
-*/
-   unsigned num_per_vertex_fields;
+   per_vertex_accumulator per_vertex;
 };
 
 
@@ -379,8 +415,7 @@ builtin_variable_generator::builtin_variable_generator(
  bool_t(glsl_type::bool_type), int_t(glsl_type::int_type),
  float_t(glsl_type::float_type), vec2_t(glsl_type::vec2_type),
  vec3_t(glsl_type::vec3_type), vec4_t(glsl_type::vec4_type),
- mat3_t(glsl_type::mat3_type), mat4_t(glsl_type::mat4_type),
- num_per_vertex_fields(0)
+ mat3_t(glsl_type::mat3_type), mat4_t(glsl_type::mat4_type)
 {
 }
 
@@ -768,13 +803,7 @@ builtin_variable_generator::add_varying(int slot, const 
glsl_type *type,
 {
switch (state->target) {
case geometry_shader:
-  assert(this->num_per_vertex_fields <
- ARRAY_SIZE(this->per_vertex_fields));
-  this->per_vertex_fields[this->num_per_vertex_fields].type = type;
-  this->per_vertex_fields[this->num_per_vertex_fields].name = name;
-  this->per_vertex_fields[this->num_per_vertex_fields].row_major = false;
-  this->per_vertex_fields[this->num_per_vertex_fields].location = slot;
-  this->num_per_vertex_fields++;
+  this->per_vertex.add_field(slot, type, name);
   /* FALLTHROUGH */
case vertex_shader:
   add_output(slot, type, name);
@@ -824,10 +853,7 @@ builtin_variable_generator::generate_varyings()
 
if (state->target == geometry_shader) {
   const glsl_type *per_vertex_type =
- glsl_type::get_interface_instance(this->per_vertex_fields,
-   this->num_per_vertex_fields,
-   GLSL_INTERFACE_PACKING_STD140,
-   "gl_PerVertex");
+ this->per_vertex.construct_interface_instance();
   ir_variable *var = add_variable("gl_in", array(per_vertex_type, 0),
   ir_var_shader_in, -1);
   var->init_interface_type(per_vertex_type);
-- 
1.8.4

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

Re: [Mesa-dev] [PATCH 06/10] i965: Don't dead-code eliminate instructions that write to the accumulator.

[Paul Berry]

On 27 September 2013 18:17, Matt Turner  wrote:

> v2: Set destination register using brw_null_reg().
>

Reviewed-by: Paul Berry 


> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp   | 15 ++-
>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 15 ++-
>  2 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index c1ab561..6c8294c 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -1845,7 +1845,20 @@ fs_visitor::dead_code_eliminate()
>if (inst->dst.file == GRF) {
>   assert(this->virtual_grf_end[inst->dst.reg] >= pc);
>   if (this->virtual_grf_end[inst->dst.reg] == pc) {
> -inst->remove();
> +/* Don't dead code eliminate instructions that write to the
> + * accumulator as a side-effect. Instead just set the
> destination
> + * to the null register to free it.
> + */
> +switch (inst->opcode) {
> +case BRW_OPCODE_ADDC:
> +case BRW_OPCODE_SUBB:
> +case BRW_OPCODE_MACH:
> +   inst->dst = fs_reg(retype(brw_null_reg(), inst->dst.type));
> +   break;
> +default:
> +   inst->remove();
> +   break;
> +}
>  progress = true;
>   }
>}
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index 2c1f541..812a005 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -313,7 +313,20 @@ vec4_visitor::dead_code_eliminate()
>if (inst->dst.file == GRF) {
>   assert(this->virtual_grf_end[inst->dst.reg] >= pc);
>   if (this->virtual_grf_end[inst->dst.reg] == pc) {
> -inst->remove();
> +/* Don't dead code eliminate instructions that write to the
> + * accumulator as a side-effect. Instead just set the
> destination
> + * to the null register to free it.
> + */
> +switch (inst->opcode) {
> +case BRW_OPCODE_ADDC:
> +case BRW_OPCODE_SUBB:
> +case BRW_OPCODE_MACH:
> +   inst->dst = dst_reg(retype(brw_null_reg(),
> inst->dst.type));
> +   break;
> +default:
> +   inst->remove();
> +   break;
> +}
>  progress = true;
>   }
>}
> --
> 1.8.3.2
>
> ___
> 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 09/10] i965/fs: Add a peephole pass to combine ADD with ADDC/SUBB.

[Paul Berry]

On 3 October 2013 10:59, Matt Turner  wrote:

> v2: Check fixed_hw_reg.{file,nr} instead of dst.reg.
> v3: Store the bool emitted_addc_or_subb in the class, not static.
> ---
>  src/mesa/drivers/dri/i965/brw_fs.h   |   3 +
>  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 104
> +++
>  2 files changed, 107 insertions(+)
>

Reviewed-by: Paul Berry 


>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index 6a53e59..c703c2b 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
> @@ -345,6 +345,7 @@ public:
>  fs_reg src0, fs_reg src1);
> bool try_emit_saturate(ir_expression *ir);
> bool try_emit_mad(ir_expression *ir, int mul_arg);
> +   void try_combine_add_with_addc_subb();
> void try_replace_with_sel();
> void emit_bool_to_cond_code(ir_rvalue *condition);
> void emit_if_gen6(ir_if *ir);
> @@ -458,6 +459,8 @@ public:
>
> int force_uncompressed_stack;
> int force_sechalf_stack;
> +
> +   bool emitted_addc_or_subb;
>  };
>
>  /**
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> index b8c30e6..8accbd6 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> @@ -313,6 +313,102 @@ fs_visitor::try_emit_mad(ir_expression *ir, int
> mul_arg)
> return true;
>  }
>
> +/**
> + * The addition and carry in the uaddCarry() built-in function are
> implemented
> + * separately as ir_binop_add and ir_binop_carry respectively. i965
> generates
> + * ADDC and a MOV from the accumulator for the carry.
> + *
> + * The generated code for uaddCarry(uint x, uint y, out uint carry) would
> look
> + * like this:
> + *
> + *addc null, x, y
> + *mov  carry, acc0
> + *add  sum, x, y
> + *
> + * This peephole pass optimizes this into
> + *
> + *addc sum, x, y
> + *mov carry, acc0
> + *
> + * usubBorrow() works in the same fashion.
> + */
> +void
> +fs_visitor::try_combine_add_with_addc_subb()
> +{
> +   /* ADDC/SUBB was introduced in gen7. */
> +   if (brw->gen < 7)
> +  return;
> +
> +   fs_inst *add_inst = (fs_inst *) instructions.get_tail();
> +   assert(add_inst->opcode == BRW_OPCODE_ADD);
> +
> +   /* ADDC/SUBB only operates on UD. */
> +   if (add_inst->dst.type != BRW_REGISTER_TYPE_UD ||
> +   add_inst->src[0].type != BRW_REGISTER_TYPE_UD ||
> +   add_inst->src[1].type != BRW_REGISTER_TYPE_UD)
> +  return;
> +
> +   bool found = false;
> +   fs_inst *match = (fs_inst *) add_inst->prev;
> +   /* The ADDC should appear within 8 instructions of ADD for a vec4. SUBB
> +* should appear farther away because of the extra MOV negates.
> +*/
> +   for (int i = 0; i < 16; i++, match = (fs_inst *) match->prev) {
> +  if (match->is_head_sentinel())
> + return;
> +
> +  /* Look for an ADDC/SUBB instruction whose destination is the null
> +   * register (ir_binop_carry emits ADDC with null destination; same
> for
> +   * ir_binop_borrow with SUBB) and whose sources are identical to
> those
> +   * of the ADD.
> +   */
> +  if (match->opcode != BRW_OPCODE_ADDC && match->opcode !=
> BRW_OPCODE_SUBB)
> + continue;
> +
> +  /* Only look for newly emitted ADDC/SUBB with null destination. */
> +  if (match->dst.file != HW_REG ||
> +  match->dst.fixed_hw_reg.file != BRW_ARCHITECTURE_REGISTER_FILE
> ||
> +  match->dst.fixed_hw_reg.nr != BRW_ARF_NULL)
> + continue;
> +
> +  fs_reg *src0 = &add_inst->src[0];
> +  fs_reg *src1 = &add_inst->src[1];
> +
> +  /* For SUBB, the ADD's second source will contain a negate modifier
> +   * which at this point will be in the form of a
> +   *
> +   *MOV dst, -src
> +   *
> +   * instruction, so src[1].file will be GRF, even if it's a uniform
> push
> +   * constant.
> +   */
> +  if (match->src[1].reg != add_inst->src[1].reg) {
> + /* The negating MOV should be immediately before the ADD. */
> + fs_inst *mov_inst = (fs_inst *) add_inst->prev;
> + if (mov_inst->opcode != BRW_OPCODE_MOV)
> +continue;
> +
> + src1 = &mov_inst->src[0];
> +  }
> +
> +  /* If everything matches, we're done. */
> +  if (match->src[0].file == src0->file &&
> +  match->src[1].file == src1->file &&
> +  match-&

Re: [Mesa-dev] [PATCH 09/10] i965/fs: Add a peephole pass to combine ADD with ADDC/SUBB.

[Paul Berry]

On 4 October 2013 13:51, Paul Berry  wrote:

> On 3 October 2013 10:59, Matt Turner  wrote:
>
>> v2: Check fixed_hw_reg.{file,nr} instead of dst.reg.
>> v3: Store the bool emitted_addc_or_subb in the class, not static.
>> ---
>>  src/mesa/drivers/dri/i965/brw_fs.h   |   3 +
>>  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 104
>> +++
>>  2 files changed, 107 insertions(+)
>>
>
> Reviewed-by: Paul Berry 
>

Whoops, wait a minute.  I spoke too soon.

I'm concerned because it looks like this peephole pass is too generous.
The following instruction stream, for example, shoud not be peephole
optimized:

addc null, x, y
mov carry, acc0
mov x, z
add sum x, y

But I don't see anything in fs_visitor::try_combine_add_with_addc_subb() to
prevent this.

Further comments below on what I believe would have to change.

>
>
>
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
>> b/src/mesa/drivers/dri/i965/brw_fs.h
>> index 6a53e59..c703c2b 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.h
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
>> @@ -345,6 +345,7 @@ public:
>>  fs_reg src0, fs_reg src1);
>> bool try_emit_saturate(ir_expression *ir);
>> bool try_emit_mad(ir_expression *ir, int mul_arg);
>> +   void try_combine_add_with_addc_subb();
>> void try_replace_with_sel();
>> void emit_bool_to_cond_code(ir_rvalue *condition);
>> void emit_if_gen6(ir_if *ir);
>> @@ -458,6 +459,8 @@ public:
>>
>> int force_uncompressed_stack;
>> int force_sechalf_stack;
>> +
>> +   bool emitted_addc_or_subb;
>>  };
>>
>>  /**
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> index b8c30e6..8accbd6 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
>> @@ -313,6 +313,102 @@ fs_visitor::try_emit_mad(ir_expression *ir, int
>> mul_arg)
>> return true;
>>  }
>>
>> +/**
>> + * The addition and carry in the uaddCarry() built-in function are
>> implemented
>> + * separately as ir_binop_add and ir_binop_carry respectively. i965
>> generates
>> + * ADDC and a MOV from the accumulator for the carry.
>> + *
>> + * The generated code for uaddCarry(uint x, uint y, out uint carry)
>> would look
>> + * like this:
>> + *
>> + *addc null, x, y
>> + *mov  carry, acc0
>> + *add  sum, x, y
>> + *
>> + * This peephole pass optimizes this into
>> + *
>> + *addc sum, x, y
>> + *mov carry, acc0
>> + *
>> + * usubBorrow() works in the same fashion.
>> + */
>> +void
>> +fs_visitor::try_combine_add_with_addc_subb()
>> +{
>> +   /* ADDC/SUBB was introduced in gen7. */
>> +   if (brw->gen < 7)
>> +  return;
>> +
>> +   fs_inst *add_inst = (fs_inst *) instructions.get_tail();
>> +   assert(add_inst->opcode == BRW_OPCODE_ADD);
>> +
>> +   /* ADDC/SUBB only operates on UD. */
>> +   if (add_inst->dst.type != BRW_REGISTER_TYPE_UD ||
>> +   add_inst->src[0].type != BRW_REGISTER_TYPE_UD ||
>> +   add_inst->src[1].type != BRW_REGISTER_TYPE_UD)
>> +  return;
>> +
>> +   bool found = false;
>> +   fs_inst *match = (fs_inst *) add_inst->prev;
>> +   /* The ADDC should appear within 8 instructions of ADD for a vec4.
>> SUBB
>> +* should appear farther away because of the extra MOV negates.
>> +*/
>> +   for (int i = 0; i < 16; i++, match = (fs_inst *) match->prev) {
>> +  if (match->is_head_sentinel())
>> + return;
>> +
>> +  /* Look for an ADDC/SUBB instruction whose destination is the null
>> +   * register (ir_binop_carry emits ADDC with null destination; same
>> for
>> +   * ir_binop_borrow with SUBB) and whose sources are identical to
>> those
>> +   * of the ADD.
>> +   */
>> +  if (match->opcode != BRW_OPCODE_ADDC && match->opcode !=
>> BRW_OPCODE_SUBB)
>> + continue;
>>
>
Instead of just "continue" here, I think we need a block that does
something like this:

if (match->opcode != BRW_OPCODE_ADDC && match->opcode != BRW_OPCODE_SUBB)
{
   /* Don't try to peephole across flow control or writes to the source
registers of the sum */
   if (this is a flow control instruction)
  return;
   if (match->dst.file == add_inst->src[0].file && match->dst.reg ==
add_inst-&g

Re: [Mesa-dev] [PATCH 10/10] i965/vs: Add a peephole pass to combine ADD with ADDC/SUBB.

[Paul Berry]

On 3 October 2013 11:00, Matt Turner  wrote:

> v2: Check fixed_hw_reg.{file,nr} instead of dst.reg.
> v3: Store the bool emitted_addc_or_subb in the class, not static.
> ---
>  src/mesa/drivers/dri/i965/brw_vec4.h   |   3 +
>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 104
> -
>  2 files changed, 106 insertions(+), 1 deletion(-)
>

My concerns about patch 9/10 apply to this patch as well.


>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
> b/src/mesa/drivers/dri/i965/brw_vec4.h
> index 25427d7..9e2204d 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.h
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.h
> @@ -507,6 +507,7 @@ public:
>
> bool try_emit_sat(ir_expression *ir);
> bool try_emit_mad(ir_expression *ir, int mul_arg);
> +   void try_combine_add_with_addc_subb();
> void resolve_ud_negate(src_reg *reg);
>
> src_reg get_timestamp();
> @@ -530,6 +531,8 @@ protected:
> virtual int compute_array_stride(ir_dereference_array *ir);
>
> const bool debug_flag;
> +
> +   bool emitted_addc_or_subb;
>  };
>
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> index ffb2cfc..74bdd4d 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> @@ -1122,6 +1122,102 @@ vec4_visitor::try_emit_mad(ir_expression *ir, int
> mul_arg)
> return true;
>  }
>
> +/**
> + * The addition and carry in the uaddCarry() built-in function are
> implemented
> + * separately as ir_binop_add and ir_binop_carry respectively. i965
> generates
> + * ADDC and a MOV from the accumulator for the carry.
> + *
> + * The generated code for uaddCarry(uint x, uint y, out uint carry) would
> look
> + * like this:
> + *
> + *addc null, x, y
> + *mov  carry, acc0
> + *add  sum, x, y
> + *
> + * This peephole pass optimizes this into
> + *
> + *addc sum, x, y
> + *mov carry, acc0
> + *
> + * usubBorrow() works in the same fashion.
> + */
> +void
> +vec4_visitor::try_combine_add_with_addc_subb()
> +{
> +   /* ADDC/SUBB was introduced in gen7. */
> +   if (brw->gen < 7)
> +  return;
> +
> +   vec4_instruction *add_inst = (vec4_instruction *)
> instructions.get_tail();
> +   assert(add_inst->opcode == BRW_OPCODE_ADD);
> +
> +   /* ADDC/SUBB only operates on UD. */
> +   if (add_inst->dst.type != BRW_REGISTER_TYPE_UD ||
> +   add_inst->src[0].type != BRW_REGISTER_TYPE_UD ||
> +   add_inst->src[1].type != BRW_REGISTER_TYPE_UD)
> +  return;
> +
> +   bool found = false;
> +   vec4_instruction *match = (vec4_instruction *) add_inst->prev;
> +   /* The ADDC should appear within 2 instructions of ADD. SUBB should
> appear
> +* farther away because of the extra MOV negate.
> +*/
> +   for (int i = 0; i < 4; i++, match = (vec4_instruction *) match->prev) {
> +  if (match->is_head_sentinel())
> + return;
> +
> +  /* Look for an ADDC/SUBB instruction whose destination is the null
> +   * register (ir_binop_carry emits ADDC with null destination; same
> for
> +   * ir_binop_borrow with SUBB) and whose sources are identical to
> those
> +   * of the ADD.
> +   */
> +  if (match->opcode != BRW_OPCODE_ADDC && match->opcode !=
> BRW_OPCODE_SUBB)
> + continue;
> +
> +  /* Only look for newly emitted ADDC/SUBB with null destination. */
> +  if (match->dst.file != HW_REG ||
> +  match->dst.fixed_hw_reg.file != BRW_ARCHITECTURE_REGISTER_FILE
> ||
> +  match->dst.fixed_hw_reg.nr != BRW_ARF_NULL)
> + continue;
> +
> +  src_reg *src0 = &add_inst->src[0];
> +  src_reg *src1 = &add_inst->src[1];
> +
> +  /* For SUBB, the ADD's second source will contain a negate modifier
> +   * which at this point will be in the form of a
> +   *
> +   *MOV dst, -src
> +   *
> +   * instruction, so src[1].file will be GRF, even if it's a uniform
> push
> +   * constant.
> +   */
> +  if (match->src[1].reg != add_inst->src[1].reg) {
> + /* The negating MOV should be immediately before the ADD. */
> + vec4_instruction *mov_inst = (vec4_instruction *) add_inst->prev;
> + if (mov_inst->opcode != BRW_OPCODE_MOV)
> +continue;
> +
> + src1 = &mov_inst->src[0];
> +  }
> +
> +  /* If everything matches, we're done. */
> +  if (match->src[0].file == src0->file &&
> +  match->src[1].file == src1->file &&
> +  match->src[0].reg == src0->reg &&
> +  match->src[1].reg == src1->reg &&
> +  match->src[0].reg_offset == src0->reg_offset &&
> +  match->src[1].reg_offset == src1->reg_offset) {
> + found = true;
> + break;
> +  }
> +   }
> +
> +   if (found) {
> +  match->dst = add_inst->dst;
> +  add_inst->remove();
> +   }
> +}
> +
>  void
>  vec4_visitor::emit_bool_comparison(unsigned int op,
>  dst_reg dst

Re: [Mesa-dev] [PATCH 09/10] i965/fs: Add a peephole pass to combine ADD with ADDC/SUBB.

[Paul Berry]

On 4 October 2013 14:24, Matt Turner  wrote:

> On Fri, Oct 4, 2013 at 2:19 PM, Paul Berry 
> wrote:
> > On 4 October 2013 13:51, Paul Berry  wrote:
> >>
> >> On 3 October 2013 10:59, Matt Turner  wrote:
> >>>
> >>> v2: Check fixed_hw_reg.{file,nr} instead of dst.reg.
> >>> v3: Store the bool emitted_addc_or_subb in the class, not static.
> >>> ---
> >>>  src/mesa/drivers/dri/i965/brw_fs.h   |   3 +
> >>>  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 104
> >>> +++
> >>>  2 files changed, 107 insertions(+)
> >>
> >>
> >> Reviewed-by: Paul Berry 
> >
> >
> > Whoops, wait a minute.  I spoke too soon.
> >
> > I'm concerned because it looks like this peephole pass is too generous.
>  The
> > following instruction stream, for example, shoud not be peephole
> optimized:
> >
> > addc null, x, y
> > mov carry, acc0
> > mov x, z
> > add sum x, y
> >
> > But I don't see anything in fs_visitor::try_combine_add_with_addc_subb()
> to
> > prevent this.
>
> We're operating on virtual grfs at this point, so I don't think that
> case is possible. I.e., if there were an intervening write to x, it
> just would have been a different vgrf. I think Ken had this same
> concern at one point, although I don't think he ever said it via
> email.
>

Sadly I don't think we can rely on that.  Since we haven't (yet)
implemented SSA, there's no guarantee that different writes will use
different virtual GRFs.  They will only be different virtual GRFs if they
are different variables in the GLSL IR.  And the GLSL IR optimization
passes (e.g. opt_copy_propagation and opt_tree_grafting) are pretty
aggressive in trying to get rid of extra GLSL IR variables where possible,
so even if they start off as different variables in the GLSL IR there's no
guarantee that they'll still be different variables by the time we hit the
back end.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] glsl/gs: handle gl_ClipDistance geometry input in lower_clip_distance.

[Paul Berry]

On 28 September 2013 14:59, Paul Berry  wrote:

> On 27 September 2013 14:32, Ian Romanick  wrote:
>
>> There are some bits of this patch I'm trying to understand.  I think
>> they can be cleared up by one question below...
>>
>> On 09/14/2013 01:00 PM, Paul Berry wrote:
>> > From: Bryan Cain 
>> >
>> > This corresponds to the lowering of gl_ClipDistance to
>> > gl_ClipDistanceMESA for vertex and geometry shader outputs.  Since
>> > this lowering pass occurs after lower_named_interface blocks, it deals
>> > with 2D arrays (gl_ClipDistance[vertex][clip_plane]) rather than 1D
>> > arrays in an interface block
>> > (gl_in[vertex].gl_ClipDistance[clip_plane]).
>> >
>> > v2 (Paul Berry ): Fix indexing order for
>> > gl_ClipDistance input lowering.  Properly lower bulk assignment of
>> > gl_ClipDistance inputs.  Rework for GLSL 1.50 style geometry shaders.
>> > ---
>> >  src/glsl/lower_clip_distance.cpp | 223
>> +--
>> >  1 file changed, 165 insertions(+), 58 deletions(-)
>> >
>> > diff --git a/src/glsl/lower_clip_distance.cpp
>> b/src/glsl/lower_clip_distance.cpp
>> > index d6cf944..16eaef6 100644
>> > --- a/src/glsl/lower_clip_distance.cpp
>> > +++ b/src/glsl/lower_clip_distance.cpp
>> > @@ -53,13 +53,16 @@
>> >  class lower_clip_distance_visitor : public ir_rvalue_visitor {
>> >  public:
>> > lower_clip_distance_visitor()
>> > -  : progress(false), old_clip_distance_var(NULL),
>> > -new_clip_distance_var(NULL)
>> > +  : progress(false), old_clip_distance_1d_var(NULL),
>> > +old_clip_distance_2d_var(NULL), new_clip_distance_1d_var(NULL),
>> > +new_clip_distance_2d_var(NULL)
>> > {
>> > }
>> >
>> > virtual ir_visitor_status visit(ir_variable *);
>> > void create_indices(ir_rvalue*, ir_rvalue *&, ir_rvalue *&);
>> > +   bool is_clip_distance_vec8(ir_rvalue *ir);
>> > +   ir_rvalue *lower_clip_distance_vec8(ir_rvalue *ir);
>> > virtual ir_visitor_status visit_leave(ir_assignment *);
>> > void visit_new_assignment(ir_assignment *ir);
>> > virtual ir_visitor_status visit_leave(ir_call *);
>> > @@ -73,12 +76,14 @@ public:
>> > /**
>> >  * Pointer to the declaration of gl_ClipDistance, if found.
>> >  */
>> > -   ir_variable *old_clip_distance_var;
>> > +   ir_variable *old_clip_distance_1d_var;
>> > +   ir_variable *old_clip_distance_2d_var;
>> >
>> > /**
>> >  * Pointer to the newly-created gl_ClipDistanceMESA variable.
>> >  */
>> > -   ir_variable *new_clip_distance_var;
>> > +   ir_variable *new_clip_distance_1d_var;
>> > +   ir_variable *new_clip_distance_2d_var;
>> >  };
>> >
>> >
>> > @@ -89,30 +94,60 @@ public:
>> >  ir_visitor_status
>> >  lower_clip_distance_visitor::visit(ir_variable *ir)
>> >  {
>> > -   /* No point in looking for the declaration of gl_ClipDistance if
>> > -* we've already found it.
>> > -*/
>> > -   if (this->old_clip_distance_var)
>> > +   if (!ir->name || strcmp(ir->name, "gl_ClipDistance") != 0)
>> >return visit_continue;
>> > +   assert (ir->type->is_array());
>> > +
>> > +   if (!ir->type->element_type()->is_array()) {
>> > +  /* 1D gl_ClipDistance (used for vertex and geometry output, and
>> fragment
>> > +   * input).
>> > +   */
>> > +  if (this->old_clip_distance_1d_var)
>> > + return visit_continue;
>> >
>> > -   if (ir->name && strcmp(ir->name, "gl_ClipDistance") == 0) {
>> >this->progress = true;
>> > -  this->old_clip_distance_var = ir;
>> > -  assert (ir->type->is_array());
>> > +  this->old_clip_distance_1d_var = ir;
>> >assert (ir->type->element_type() == glsl_type::float_type);
>> >unsigned new_size = (ir->type->array_size() + 3) / 4;
>> >
>> >/* Clone the old var so that we inherit all of its properties */
>> > -  this->new_clip_distance_var = ir->clone(ralloc_parent(ir), NULL);
>> > +  this->new_clip_distance_1d_var = ir->clone(ralloc_parent(ir),
>> NULL);
>> >
>> >/* And change the properties tha

Re: [Mesa-dev] [PATCH] i965/blorp: Fix the register types on blorp's push constants.

[Paul Berry]

On 21 September 2013 16:59, Eric Anholt  wrote:

> The UD values were getting set up as floats.  This happened to work out
> because they were used as the second argument where the first was a dword,
> and gen6+ doesn't do source conversions.  But it did trigger fulsim
> warnings, and it meant if you used the push constant as the first operand
> you would have been disappointed.
> ---
>  src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 32
> ++--
>  1 file changed, 16 insertions(+), 16 deletions(-)
>

Reviewed-by: Paul Berry 


>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> index f07d39f..c1880e3 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> @@ -899,22 +899,22 @@ void
>  brw_blorp_blit_program::alloc_push_const_regs(int base_reg)
>  {
>  #define CONST_LOC(name) offsetof(brw_blorp_wm_push_constants, name)
> -#define ALLOC_REG(name) \
> -   this->name = \
> -  brw_vec1_reg(BRW_GENERAL_REGISTER_FILE, \
> -   base_reg + CONST_LOC(name) / 32, \
> -   (CONST_LOC(name) % 32) / 4)
> -
> -   ALLOC_REG(dst_x0);
> -   ALLOC_REG(dst_x1);
> -   ALLOC_REG(dst_y0);
> -   ALLOC_REG(dst_y1);
> -   ALLOC_REG(rect_grid_x1);
> -   ALLOC_REG(rect_grid_y1);
> -   ALLOC_REG(x_transform.multiplier);
> -   ALLOC_REG(x_transform.offset);
> -   ALLOC_REG(y_transform.multiplier);
> -   ALLOC_REG(y_transform.offset);
> +#define ALLOC_REG(name, type)   \
> +   this->name = \
> +  retype(brw_vec1_reg(BRW_GENERAL_REGISTER_FILE,\
> +  base_reg + CONST_LOC(name) / 32,  \
> +  (CONST_LOC(name) % 32) / 4), type)
> +
> +   ALLOC_REG(dst_x0, BRW_REGISTER_TYPE_UD);
> +   ALLOC_REG(dst_x1, BRW_REGISTER_TYPE_UD);
> +   ALLOC_REG(dst_y0, BRW_REGISTER_TYPE_UD);
> +   ALLOC_REG(dst_y1, BRW_REGISTER_TYPE_UD);
> +   ALLOC_REG(rect_grid_x1, BRW_REGISTER_TYPE_F);
> +   ALLOC_REG(rect_grid_y1, BRW_REGISTER_TYPE_F);
> +   ALLOC_REG(x_transform.multiplier, BRW_REGISTER_TYPE_F);
> +   ALLOC_REG(x_transform.offset, BRW_REGISTER_TYPE_F);
> +   ALLOC_REG(y_transform.multiplier, BRW_REGISTER_TYPE_F);
> +   ALLOC_REG(y_transform.offset, BRW_REGISTER_TYPE_F);
>  #undef CONST_LOC
>  #undef ALLOC_REG
>  }
> --
> 1.8.4.rc3
>
> ___
> 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 v2] i965: Initialize brw_blorp_const_color_program::prog_data.

[Paul Berry]

On 27 September 2013 22:24, Vinson Lee  wrote:

> Fixes "Uninitialized scalar field" defect reported by Coverity.
>
> Signed-off-by: Vinson Lee 
> ---
>  src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Paul Berry 


>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> index f26f39d..a40b58a 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
> @@ -127,6 +127,8 @@
> brw_blorp_const_color_program::brw_blorp_const_color_program(
>   clear_rgba(),
>   base_mrf(0)
>  {
> +   prog_data.first_curbe_grf = 0;
> +   prog_data.persample_msaa_dispatch = false;
> brw_init_compile(brw, &func, mem_ctx);
>  }
>
> --
> 1.8.3.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 02/19] glsl: Fix block name of built-in gl_PerVertex interface block.

[Paul Berry]

On 5 October 2013 12:10, Kenneth Graunke  wrote:

> On 10/02/2013 05:45 PM, Paul Berry wrote:
> > Previously, we erroneously used the name "gl_in" for both the block
> > name and the instance name.
> > ---
> >  src/glsl/builtin_variables.cpp | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/glsl/builtin_variables.cpp
> b/src/glsl/builtin_variables.cpp
> > index 3667dc8..91518ba 100644
> > --- a/src/glsl/builtin_variables.cpp
> > +++ b/src/glsl/builtin_variables.cpp
> > @@ -827,7 +827,7 @@ builtin_variable_generator::generate_varyings()
> >   glsl_type::get_interface_instance(this->per_vertex_fields,
> > this->num_per_vertex_fields,
> >
> GLSL_INTERFACE_PACKING_STD140,
> > -   "gl_in");
> > +   "gl_PerVertex");
> >ir_variable *var = add_variable("gl_in", array(per_vertex_type,
> 0),
> >ir_var_shader_in, -1);
> >var->init_interface_type(per_vertex_type);
>
> It would be fantastic if you could update the prototype in glsl_types.h to
> say "block_name" instead of "name" for the parameter:
>
>/**
> * Get the instance of an interface block type
> */
>static const glsl_type *get_interface_instance(const glsl_struct_field
> *fields,
>   unsigned num_fields,
>   enum
> glsl_interface_packing packing,
>   const char *name);
>
> With just "name", it's not obvious which is supposed to be passed here.
>

Sure.  That's easily separable from this series so I'll do it in an
independent patch.


>
> Either way, patches 1-2 are:
> Reviewed-by: Kenneth Graunke 
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: Rename the fourth argument to get_interface_instance.

[Paul Berry]

Interface declarations have two names associated with them: the block
name and the instance name.  It's the block name that needs to be
passed to get_interface_instance().  This patch renames the argument
so that there's no confusion.
---
 src/glsl/glsl_types.cpp | 8 
 src/glsl/glsl_types.h   | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 4782d15..c4c04fe 100644
--- a/src/glsl/glsl_types.cpp
+++ b/src/glsl/glsl_types.cpp
@@ -509,9 +509,9 @@ const glsl_type *
 glsl_type::get_interface_instance(const glsl_struct_field *fields,
  unsigned num_fields,
  enum glsl_interface_packing packing,
- const char *name)
+ const char *block_name)
 {
-   const glsl_type key(fields, num_fields, packing, name);
+   const glsl_type key(fields, num_fields, packing, block_name);
 
if (interface_types == NULL) {
   interface_types = hash_table_ctor(64, record_key_hash, 
record_key_compare);
@@ -519,14 +519,14 @@ glsl_type::get_interface_instance(const glsl_struct_field 
*fields,
 
const glsl_type *t = (glsl_type *) hash_table_find(interface_types, & key);
if (t == NULL) {
-  t = new glsl_type(fields, num_fields, packing, name);
+  t = new glsl_type(fields, num_fields, packing, block_name);
 
   hash_table_insert(interface_types, (void *) t, t);
}
 
assert(t->base_type == GLSL_TYPE_INTERFACE);
assert(t->length == num_fields);
-   assert(strcmp(t->name, name) == 0);
+   assert(strcmp(t->name, block_name) == 0);
 
return t;
 }
diff --git a/src/glsl/glsl_types.h b/src/glsl/glsl_types.h
index 61c8635..e60c191 100644
--- a/src/glsl/glsl_types.h
+++ b/src/glsl/glsl_types.h
@@ -234,7 +234,7 @@ struct glsl_type {
static const glsl_type *get_interface_instance(const glsl_struct_field 
*fields,
  unsigned num_fields,
  enum glsl_interface_packing 
packing,
- const char *name);
+ const char *block_name);
 
/**
 * Query the total number of scalars that make up a scalar, vector or matrix
-- 
1.8.4

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

Re: [Mesa-dev] [PATCH 06/19] glsl: Refactor code to check that identifier names are valid.

[Paul Berry]

On 5 October 2013 12:12, Kenneth Graunke  wrote:

> On 10/02/2013 05:45 PM, Paul Berry wrote:
> > GLSL reserves identifiers beginning with "gl_" or containing "__", but
> > we haven't been consistent about enforcing this rule.  This patch
> > makes a new function to check whether identifier names are valid.  In
> > the process it closes a loophole where we would previously allow
> > function argument names to contain "__".
> > ---
> >  src/glsl/ast_to_hir.cpp | 65
> -
> >  1 file changed, 32 insertions(+), 33 deletions(-)
> >
> > diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> > index c1e3c08..f4f81e0 100644
> > --- a/src/glsl/ast_to_hir.cpp
> > +++ b/src/glsl/ast_to_hir.cpp
> > @@ -2649,6 +2649,36 @@ handle_geometry_shader_input_decl(struct
> _mesa_glsl_parse_state *state,
> > }
> >  }
> >
> > +
> > +void
> > +check_valid_identifier(const char *identifier, YYLTYPE loc,
> > +   struct _mesa_glsl_parse_state *state)
>
> "check_valid_identifier" sounds strange if you read it aloud.
>
> Perhaps one of the following?
> - validate_identifier()
> - check_for_valid_identifier()
> - check_identifier_validity()
>

Ok, I went with validate_identifier().


>
> > +{
> > +   /* From page 15 (page 21 of the PDF) of the GLSL 1.10 spec,
> > +*
> > +*   "Identifiers starting with "gl_" are reserved for use by
> > +*   OpenGL, and may not be declared in a shader as either a
> > +*   variable or a function."
> > +*/
> > +   if (strncmp(identifier, "gl_", 3) == 0)
>
> I would really like to see curly braces here, for two reasons:
> 1. Even though it's a single statement, it spans multiple lines.
> 2. The else case uses curly braces.
>

Ok, fixed.


>
> Even if you don't take my suggestions, this is:
> Reviewed-by: Kenneth Graunke 
>
> > +  _mesa_glsl_error(&loc, state,
> > +   "identifier `%s' uses reserved `gl_' prefix",
> > +   identifier);
> > +   else if (strstr(identifier, "__")) {
> > +  /* From page 14 (page 20 of the PDF) of the GLSL 1.10
> > +   * spec:
> > +   *
> > +   * "In addition, all identifiers containing two
> > +   *  consecutive underscores (__) are reserved as
> > +   *  possible future keywords."
> > +   */
> > +  _mesa_glsl_error(&loc, state,
> > +   "identifier `%s' uses reserved `__' string",
> > +   identifier);
> > +   }
> > +}
> > +
> > +
> >  ir_rvalue *
> >  ast_declarator_list::hir(exec_list *instructions,
> >struct _mesa_glsl_parse_state *state)
> > @@ -3243,28 +3273,7 @@ ast_declarator_list::hir(exec_list *instructions,
> > * created for the declaration should be added to the IR stream.
> > */
> >if (earlier == NULL) {
> > -  /* From page 15 (page 21 of the PDF) of the GLSL 1.10 spec,
> > -   *
> > -   *   "Identifiers starting with "gl_" are reserved for use by
> > -   *   OpenGL, and may not be declared in a shader as either a
> > -   *   variable or a function."
> > -   */
> > -  if (strncmp(decl->identifier, "gl_", 3) == 0)
> > - _mesa_glsl_error(& loc, state,
> > -  "identifier `%s' uses reserved `gl_' prefix",
> > -  decl->identifier);
> > -  else if (strstr(decl->identifier, "__")) {
> > - /* From page 14 (page 20 of the PDF) of the GLSL 1.10
> > -  * spec:
> > -  *
> > -  * "In addition, all identifiers containing two
> > -  *  consecutive underscores (__) are reserved as
> > -  *  possible future keywords."
> > -  */
> > - _mesa_glsl_error(& loc, state,
> > -  "identifier `%s' uses reserved `__' string",
> > -  decl->identifier);
> > -  }
> > + check_valid_identifier(decl->identifier, loc, state);
> >
> >/* Add the variable to the symbol table.  Note that the
> initializer's
> > * IR was already processed earlier (though it hasn't been emitted
> > @@ -350

Re: [Mesa-dev] [PATCH 12/19] glsl: Generalize processing of variable redeclarations.

[Paul Berry]

On 5 October 2013 12:25, Kenneth Graunke  wrote:

> On 10/02/2013 05:45 PM, Paul Berry wrote:
> > This patch modifies the get_variable_being_redeclared() function so
> > that it no longer relies on the ast_declaration for the variable being
> > redeclared.  In future patches, this will allow
> > get_variable_being_redeclared() to be used for processing
> > redeclarations of the built-in gl_PerVertex interface block.
> > ---
> >  src/glsl/ast_to_hir.cpp | 13 ++---
> >  1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> > index 8fb7f2f..de65c71 100644
> > --- a/src/glsl/ast_to_hir.cpp
> > +++ b/src/glsl/ast_to_hir.cpp
> > @@ -2327,7 +2327,7 @@ apply_type_qualifier_to_variable(const struct
> ast_type_qualifier *qual,
> >   * is a redeclaration, \c NULL otherwise.
> >   */
> >  ir_variable *
> > -get_variable_being_redeclared(ir_variable *var, ast_declaration *decl,
> > +get_variable_being_redeclared(ir_variable *var, YYLTYPE loc,
> > struct _mesa_glsl_parse_state *state)
>
> While you're at it, would you mind making this function static?
>

Done.


>
> Either way, patches 5-12 are:
> Reviewed-by: Kenneth Graunke 
>
> >  {
> > /* Check if this declaration is actually a re-declaration, either to
> > @@ -2336,16 +2336,14 @@ get_variable_being_redeclared(ir_variable *var,
> ast_declaration *decl,
> >  * This is allowed for variables in the current scope, or when at
> >  * global scope (for built-ins in the implicit outer scope).
> >  */
> > -   ir_variable *earlier =
> state->symbols->get_variable(decl->identifier);
> > +   ir_variable *earlier = state->symbols->get_variable(var->name);
> > if (earlier == NULL ||
> > (state->current_function != NULL &&
> > - !state->symbols->name_declared_this_scope(decl->identifier))) {
> > + !state->symbols->name_declared_this_scope(var->name))) {
> >return NULL;
> > }
> >
> >
> > -   YYLTYPE loc = decl->get_location();
> > -
> > /* From page 24 (page 30 of the PDF) of the GLSL 1.50 spec,
> >  *
> >  * "It is legal to declare an array without a size and then
> > @@ -2434,7 +2432,7 @@ get_variable_being_redeclared(ir_variable *var,
> ast_declaration *decl,
> >earlier->depth_layout = var->depth_layout;
> >
> > } else {
> > -  _mesa_glsl_error(&loc, state, "`%s' redeclared",
> decl->identifier);
> > +  _mesa_glsl_error(&loc, state, "`%s' redeclared", var->name);
> > }
> >
> > return earlier;
> > @@ -3221,7 +3219,8 @@ ast_declarator_list::hir(exec_list *instructions,
> > * instruction stream.
> > */
> >exec_list initializer_instructions;
> > -  ir_variable *earlier = get_variable_being_redeclared(var, decl,
> state);
> > +  ir_variable *earlier =
> > + get_variable_being_redeclared(var, decl->get_location(),
> state);
> >
> >if (decl->initializer != NULL) {
> >result = process_initializer((earlier == NULL) ? var : earlier,
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/10] glsl/linker: Modify array_sizing_visitor to handle named interface blocks.

[Paul Berry]

On 8 October 2013 21:17, Jordan Justen  wrote:

> On Fri, Sep 27, 2013 at 12:05 PM, Paul Berry 
> wrote:
> > Unsized arrays appearing inside named interface blocks now get a
> > proper size assigned by the array_sizing_visitor.
> >
> > Fixes piglit tests:
> > - spec/glsl-1.50/execution/unsized-in-named-interface-block
> > - spec/glsl-1.50/execution/unsized-in-named-interface-block-gs
> > - spec/glsl-1.50/linker/unsized-in-named-interface-block
> > - spec/glsl-1.50/linker/unsized-in-named-interface-block-gs
> > - spec/glsl-1.50/linker/unsized-in-unnamed-interface-block-gs (*)
> >
> > (*) is fixed by dumb luck--support for unsized arrays in unnamed
> > interface blocks will come in a later patch.
> > ---
> >  src/glsl/ir.h   | 16 +++
> >  src/glsl/linker.cpp | 77
> -
> >  2 files changed, 87 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/glsl/ir.h b/src/glsl/ir.h
> > index 4f63562..16bb76c 100644
> > --- a/src/glsl/ir.h
> > +++ b/src/glsl/ir.h
> > @@ -420,6 +420,22 @@ public:
> >}
> > }
> >
> > +   /**
> > +* Change this->interface_type on a variable that previously had a
> > +* different interface_type.  This is used during linking to set the
> size
> > +* of arrays in interface blocks.
> > +*/
> > +   void change_interface_type(const struct glsl_type *type)
> > +   {
> > +  if (this->max_ifc_array_access != NULL) {
> > + /* max_ifc_array_access has already been allocated, so make
> sure the
> > +  * new interface has the same number of fields as the old one.
> > +  */
> > + assert(this->interface_type->length == type->length);
> > +  }
> > +  this->interface_type = type;
> > +   }
> > +
> > const glsl_type *get_interface_type() const
> > {
> >return this->interface_type;
> > diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> > index c54b704..fe4ccee 100644
> > --- a/src/glsl/linker.cpp
> > +++ b/src/glsl/linker.cpp
> > @@ -1035,15 +1035,80 @@ class array_sizing_visitor : public
> ir_hierarchical_visitor {
> >  public:
> > virtual ir_visitor_status visit(ir_variable *var)
> > {
> > -  if (var->type->is_array() && (var->type->length == 0)) {
> > - const glsl_type *type =
> > -glsl_type::get_array_instance(var->type->fields.array,
> > -  var->max_array_access + 1);
> > - assert(type != NULL);
> > - var->type = type;
> > +  fixup_type(&var->type, var->max_array_access);
> > +  if (var->type->is_interface()) {
> > + if (interface_contains_unsized_arrays(var->type)) {
> > +const glsl_type *new_type =
> > +   resize_interface_members(var->type,
> var->max_ifc_array_access);
> > +var->type = new_type;
> > +var->change_interface_type(new_type);
> > + }
> > +  } else if (var->type->is_array() &&
> > + var->type->fields.array->is_interface()) {
> > + if
> (interface_contains_unsized_arrays(var->type->fields.array)) {
> > +const glsl_type *new_type =
> > +   resize_interface_members(var->type->fields.array,
> > +var->max_ifc_array_access);
> > +var->change_interface_type(new_type);
> > +var->type =
> > +   glsl_type::get_array_instance(new_type,
> var->type->length);
> > + }
> >}
> >return visit_continue;
> > }
> > +
> > +private:
> > +   /**
> > +* If the type pointed to by \c type represents an unsized array,
> replace
> > +* it with a sized array whose size is determined by
> max_array_access.
> > +*/
> > +   static void fixup_type(const glsl_type **type, unsigned
> max_array_access)
> > +   {
> > +  if ((*type)->is_array() && (*type)->length == 0) {
> > + *type = glsl_type::get_array_instance((*type)->fields.array,
> > +   max_array_access + 1);
> > + assert(*type != NULL);
> > +  }
> > +   }
> > +
> > +   /**
> > +* Determine whether the given interface type contains unsized

Re: [Mesa-dev] [PATCH 00/10] glsl: Support unsized arrays in interface blocks.

[Paul Berry]

On 8 October 2013 23:25, Jordan Justen  wrote:

> Patches 1, 2 & 4 - 10:
> Reviewed-by: Jordan Justen 
>
> For 8, I replied with a non-essential question, and the same question
> is relevant in patch 10.
>
> For patch 3 I had that question (mentioned on irc) about ir having
> ast/parser knowledge. I guess I'd like to think about this one a
> little more.
>

I've been thinking about this more too, and I'm of two minds about it.

On the one hand, I think we're going to wind up polluting the IR with
ast/parser knowledge one of these days anyhow, since it would be nice for
(a) linker errors to be able to refer to source line numbers, and (b) the
output of INTEL_DEBUG={vs,gs,fs} to refer to source code lines rather than
IR, and in order for either of those to happen, the IR needs to be able to
store source locations, which are currently knowledge belonging to the
ast/parser.

One the other hand, I didn't really get as much benefit out of using
virtual method dispatch in patch 3 as I was expecting, and I got a fair bit
of headache (which is why patch 2 was necessary).  It would probably be
just as easy to make update_max_array_access() an ordinary function in
ast_array_index.cpp, and implement its dynamic behaviour using functions
like as_dereference_record() and as_dereference_variable().  I'll try doing
that this morning and let you know how it goes.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 07/10] glsl: Update ir_variable::max_ifc_array_access properly.

[Paul Berry]

On 27 September 2013 12:05, Paul Berry  wrote:

> This patch adds an implementation of
> ir_dereference_record::update_max_array_access(), which ensures that
> ir_variable::max_ifc_array_access is properly updated to reflect the
> shader's use of arrays appearing within interface blocks.
> ---
>  src/glsl/ir.cpp | 36 
>  src/glsl/ir.h   |  2 ++
>  2 files changed, 38 insertions(+)
>
> diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
> index 96d4c05..134b100 100644
> --- a/src/glsl/ir.cpp
> +++ b/src/glsl/ir.cpp
> @@ -1367,6 +1367,42 @@
> ir_dereference_record::ir_dereference_record(ir_variable *var,
> this->type = this->record->type->field_type(field);
>  }
>
> +
> +void
> +ir_dereference_record::update_max_array_access(unsigned idx, YYLTYPE *loc,
> +   struct
> _mesa_glsl_parse_state *state)
> +{
> +   /* There are two possibilities we need to consider:
> +*
> +* - Accessing an element of an array that is a member of a named
> interface
> +*   block (e.g. ifc.foo[i])
> +*
> +* - Accessing an element of an array that is a member of a named
> interface
> +*   block array (e.g. ifc[j].foo[i]).
> +*/
> +   ir_dereference_variable *deref_var =
> this->record->as_dereference_variable();
> +   if (deref_var == NULL) {
> +  if (ir_dereference_array *deref_array =
> +  this->record->as_dereference_array()) {
> + deref_var = deref_array->array->as_dereference_variable();
> +  }
> +   }
> +
> +   if (deref_var != NULL) {
>

Oops, I just noticed that this will crash if it encounters GLSL of the form
foo.bar[i] or foo[i].bar[j] where foo is an ordinary struct (or array of
structs) rather than an interface block.  This is easy to fix--just bail
out if deref_var->var->get_interface_type() returns NULL.

I'll fix this as soon as Jordan and I have resolved our discussion on
"[PATCH 00/10] glsl: Support unsized arrays in interface blocks."


> +  unsigned field_index = this->record->type->field_index(this->field);
> +  assert(field_index < deref_var->var->get_interface_type()->length);

+  if (idx > deref_var->var->max_ifc_array_access[field_index]) {
> + deref_var->var->max_ifc_array_access[field_index] = idx;
> +
> + /* Check whether this access will, as a side effect, implicitly
> cause
> +  * the size of a built-in array to be too large.
> +  */
> + check_builtin_array_max_size(this->field, idx+1, *loc, state);
> +  }
> +   }
> +}
> +
> +
>  bool
>  ir_dereference::is_lvalue() const
>  {
> diff --git a/src/glsl/ir.h b/src/glsl/ir.h
> index 63b7f5d..4f63562 100644
> --- a/src/glsl/ir.h
> +++ b/src/glsl/ir.h
> @@ -1952,6 +1952,8 @@ public:
> }
>
> virtual ir_visitor_status accept(ir_hierarchical_visitor *);
> +   virtual void update_max_array_access(unsigned idx, YYLTYPE *loc,
> +struct _mesa_glsl_parse_state
> *state);
>
> ir_rvalue *record;
> const char *field;
> --
> 1.8.4
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/3] Enable GL 3.2 support for i965, bump Mesa version.

[Paul Berry]

It's been a long and rocky road, but geometry shader support in Mesa's
i965/gen7 driver has finally reached a point I'm willing to call
"feature complete".  Since geometry shaders were the last remaining
feature needed for GL 3.2, it's time to turn on GL 3.2 support.  Here
is a short patch series to turn it on.

Patch 1 enables GLSL 1.50 and GL 3.2 for i965/gen7 parts (Ivy Bridge
and Haswell).  Patch 2 removes the old warning message "Geometry
shader support is currently experimental".  Patch 3 bumps the Mesa
major version from 9 to 10 to reflect the fact that we now support a
new version of OpenGL.

Note: although geometry shaders are feature complete, there are still
a few bugs that I still need to iron out before the next release.
Here is a list of all the current GLSL 1.50 and GL 3.2 piglit failures
on Ivy Bridge and Haswell.  With a few minor exceptions that are
unfixable due to hardware limitations, or which are too obscure to be
worth fixing, I believe I can take care of all of these by the Nov 27
release date.

OpenGL 3.2 piglit failures:
--

- layered-rendering/clear-{color,depth}: It appears that our glClear
  implementation doesn't clear all layers of a layered attachment.

- 
layered-rendering/{framebuffer-layered-attachments,framebuffertexture-defaults}:
  I have not investigated, but I believe Jordan Justen may be working
  on this.

- minmax: GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS has the wrong value.

GLSL 1.50 piglit failures:
-

- built-in constants/* (9 failures) and compiler/constants.geom: a few
  new GLSL 1.50 built-in constants aren't being set up properly.

- 
compiler/{vs,gs}-redeclares-pervertex-out-{after,after-other,before}-global-redeclaration.geom:
  We're not flagging an error if both gl_PerVertex and one of its
  members are redeclared.

- compiler/incorrect-{in,out}-layout-qualifiers-with-variable-declarations.geom:
  We're not flagging an error if GS layout qualifiers are improperly
  applied to variables.

- compiler/interface-blocks-name-reused-globally.vert: We're not
  flagging an error if an interface block name conflicts with a global
  variable name.

- compiler/interface-blocks-structs-defined-within-block-instanced.vert:
  We're not flagging an error if a struct is defined inside an
  interface block.

- compiler/layout-fs-no-output.frag: We're not flagging an error if GS
  layout qualifiers are used in a non-geometry shader.

- compiler/layout-not-case-sensitive-{in,max-vert,out}.geom and
  compiler/layout-not-case-sensitive.frag: Layout qualifiers should be
  case-insensitive--they are not.

- compiler/layout-vs-no-{input,output}.vert: We're not flagging an
  error if GS layout qualifiers are used in a non-geometry shader.

- execution/geometry/clip-distance-bulk-copy: Test is broken.  I have
  a patch on the Piglit list to fix this.

- execution/geometry/triangle-strip-orientation (Ivy Bridge only):
  Vertices in triangle strips are improperly ordered.  I am working on
  a fix for this.

- glsl-1.50-geometry-primitive-id-restart GL_POINTS other (Ivy Bridge
  only): A hardware workaround is required.  I am working on a fix for
  this.

- glsl-1.50-geometry-primitive-types * (10 failures): Failing due to
  bugs in transform feedback (I accidentally dropped a patch from
  Bryan Cain's original geometry shader series).  I am working on a
  fix for this.

- glsl-1.50-geometry-tri-strip-ordering-with-prim-restart * (4
  failures): Vertices in triangle strips are improperly ordered.  I am
  working on a fix for this.

- 
linker/interstage-{pervertex,pervertex-in,pervertex-out}-redeclaration-unneeded:
  We're not accounting for the fact that a compilation unit is not
  required to redeclare gl_PerVertex if it does not use it.

- query-gs-prim-types: New geometry shader informational queries are
  not implemented yet.

[PATCH 1/3] i965: Turn on GLSL 1.50 and GL 3.2 support for i965 gen7.
[PATCH 2/3] mesa: Remove warning that geometry shader support is experimental.
[PATCH 3/3] mesa: Bump version to 10.0.0.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] i965: Turn on GLSL 1.50 and GL 3.2 support for i965 gen7.

[Paul Berry]

Geometry shaders were the last thing we needed to finish before
turning on GLSL 1.50 and GL 3.2 support.  They are now working well,
with just a few piglit failures left to fix.
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 4 +++-
 src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 6f024b4..334be05 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -125,7 +125,9 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.OES_standard_derivatives = true;
ctx->Extensions.OES_EGL_image_external = true;
 
-   if (brw->gen >= 6)
+   if (brw->gen >= 7)
+  ctx->Const.GLSLVersion = 150;
+   else if (brw->gen >= 6)
   ctx->Const.GLSLVersion = 140;
else
   ctx->Const.GLSLVersion = 120;
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cddc8e8..3761170 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1224,7 +1224,7 @@ set_max_gl_versions(struct intel_screen *screen)
 
switch (screen->gen) {
case 7:
-  screen->max_gl_core_version = 31;
+  screen->max_gl_core_version = 32;
   screen->max_gl_compat_version = 30;
   screen->max_gl_es1_version = 11;
   screen->max_gl_es2_version = 30;
-- 
1.8.4

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

[Mesa-dev] [PATCH 2/3] mesa: Remove warning that geometry shader support is experimental.

[Paul Berry]

Geometry shader support is now working well, and adequately piglit
tested.  There are just a few piglit failures left to fix.  So there's
no need for an "experimental" warning anymore.
---
 src/mesa/main/shaderapi.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 4c0484a..d3677c8 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -743,12 +743,6 @@ compile_shader(struct gl_context *ctx, GLuint shaderObj)
if (!sh)
   return;
 
-   /* Geometry shaders are not yet fully supported, so issue a warning message
-* if we're compiling one.
-*/
-   if (sh->Type == GL_GEOMETRY_SHADER)
-  printf("WARNING: Geometry shader support is currently experimental.\n");
-
options = &ctx->ShaderCompilerOptions[_mesa_shader_type_to_index(sh->Type)];
 
/* set default pragma state for shader */
-- 
1.8.4

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

[Mesa-dev] [PATCH 3/3] mesa: Bump version to 10.0.0.

[Paul Berry]

Mesa now supports OpenGL 3.2 and GLSL 1.50, so bump the Mesa major
version from 9 to 10 to reflect this.
---
 VERSION |  2 +-
 docs/relnotes.html  |  2 +-
 docs/relnotes/10.0.html | 65 +
 docs/relnotes/9.3.html  | 65 -
 4 files changed, 67 insertions(+), 67 deletions(-)
 create mode 100644 docs/relnotes/10.0.html
 delete mode 100644 docs/relnotes/9.3.html

diff --git a/VERSION b/VERSION
index b260649..8e92e83 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-9.3.0-devel
+10.0.0-devel
diff --git a/docs/relnotes.html b/docs/relnotes.html
index 5929359..82072dd 100644
--- a/docs/relnotes.html
+++ b/docs/relnotes.html
@@ -21,7 +21,7 @@ The release notes summarize what's new or changed in each 
Mesa release.
 
 
 
-9.3 release notes
+10.0 release notes
 9.2.1 release notes
 9.2 release notes
 9.1.7 release notes
diff --git a/docs/relnotes/10.0.html b/docs/relnotes/10.0.html
new file mode 100644
index 000..8f97921
--- /dev/null
+++ b/docs/relnotes/10.0.html
@@ -0,0 +1,65 @@
+http://www.w3.org/TR/html4/loose.dtd";>
+
+
+  
+  Mesa Release Notes
+  
+
+
+
+
+  The Mesa 3D Graphics Library
+
+
+
+
+
+Mesa 10.0 Release Notes / TBD
+
+
+Mesa 10.0 is a new development release.
+People who are concerned with stability and reliability should stick
+with a previous release or wait for Mesa 10.0.1.
+
+
+Mesa 10.0 implements the OpenGL 3.2 API, but the version reported by
+glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) /
+glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used.
+Some drivers don't support all the features required in OpenGL 3.2.  OpenGL
+3.2 is only available if requested at context creation
+because compatibility contexts are not supported.
+
+
+
+MD5 checksums
+
+TBD.
+
+
+
+New features
+
+
+Note: some of the new features are only available with certain drivers.
+
+
+
+GL_AMD_seamless_cubemap_per_texture on i965.
+GL_ARB_conservative_depth on i965.
+GL_ARB_texture_gather on i965.
+GL_ARB_texture_query_levels on i965.
+GL_KHR_debug
+
+
+
+Bug fixes
+
+TBD.
+
+Changes
+
+TBD.
+
+
+
+
diff --git a/docs/relnotes/9.3.html b/docs/relnotes/9.3.html
deleted file mode 100644
index 58a88b0..000
--- a/docs/relnotes/9.3.html
+++ /dev/null
@@ -1,65 +0,0 @@
-http://www.w3.org/TR/html4/loose.dtd";>
-
-
-  
-  Mesa Release Notes
-  
-
-
-
-
-  The Mesa 3D Graphics Library
-
-
-
-
-
-Mesa 9.3 Release Notes / TBD
-
-
-Mesa 9.3 is a new development release.
-People who are concerned with stability and reliability should stick
-with a previous release or wait for Mesa 9.3.1.
-
-
-Mesa 9.3 implements the OpenGL 3.1 API, but the version reported by
-glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) /
-glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used.
-Some drivers don't support all the features required in OpenGL 3.1.  OpenGL
-3.1 is only available if requested at context creation
-because GL_ARB_compatibility is not supported.
-
-
-
-MD5 checksums
-
-TBD.
-
-
-
-New features
-
-
-Note: some of the new features are only available with certain drivers.
-
-
-
-GL_AMD_seamless_cubemap_per_texture on i965.
-GL_ARB_conservative_depth on i965.
-GL_ARB_texture_gather on i965.
-GL_ARB_texture_query_levels on i965.
-GL_KHR_debug
-
-
-
-Bug fixes
-
-TBD.
-
-Changes
-
-TBD.
-
-
-
-
-- 
1.8.4

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

Re: [Mesa-dev] [PATCH 0/3] Enable GL 3.2 support for i965, bump Mesa version.

[Paul Berry]

On 11 October 2013 05:43, Mike Lothian  wrote:

> Well done on getting this enabled
>
> Out of interest how far is SandyBridge from 3.2?
>

I believe geometry shaders are all we would have to implement for Sandy
Bridge.  Unfortunately, geometry shaders work pretty differently on Sandy
Bridge, so getting them to work won't be a slam dunk.  Here's roughly what
would have to be done:

1. Start using Ivy Bridge/Haswell's "single dispatch" mode for geometry
shaders--this mode is more similar to how geometry shaders work on Sandy
Bridge than the "dual object dispatch" mode we're currently using.  In
addition to paving the way for Sandy Bridge geometry shader sepport, there
are additional reasons why this is worth doing on Ivy Bridge and Haswell:
(a) it reduces register pressure, so it should yield better performance for
geometry shaders that would otherwise run out of registers, and (b) it
overlaps a lot with implementing instanced geometry shaders, a feature
required by ARB_gpu_shader5.

2. Ivy Bridge has fixed function hardware to buffer the geometry shader
outputs, decompose strips, and deliver the resulting primitives down the
pipeline one at a time.  Sandy Bridge doesn't, so we'll need to adapt the
shader compilerback end to generate code that does this manually.

3. Ivy Bridge has fixed function hardware to do transform feedback.  Sandy
Bridge doesn't; instead the driver generates an ad hoc geometry shader
program to do transform feedback when it's needed.  When there's a
user-supplied geometry shader, this ad-hoc program will need to get merged
together with the user-supplied shader.

4. Once all that is done, it should be fairly straightforward to emit the
correct 3DSTATE_GS packet to turn on the geometry shader.

I'm hoping I can get to #1 fairly soon (perhaps in December).  I'm not sure
when (or if) I'll have time to work on the others.  It will depend on how
Intel management decides to set my priorities. If anyone out in the
community is interested in contributing to the Sandy Bridge geometry shader
effort, I'd be delighted to collaborate.

Cheers
>
> Mike
> On 11 Oct 2013 05:28, "Paul Berry"  wrote:
>
>> It's been a long and rocky road, but geometry shader support in Mesa's
>> i965/gen7 driver has finally reached a point I'm willing to call
>> "feature complete".  Since geometry shaders were the last remaining
>> feature needed for GL 3.2, it's time to turn on GL 3.2 support.  Here
>> is a short patch series to turn it on.
>>
>> Patch 1 enables GLSL 1.50 and GL 3.2 for i965/gen7 parts (Ivy Bridge
>> and Haswell).  Patch 2 removes the old warning message "Geometry
>> shader support is currently experimental".  Patch 3 bumps the Mesa
>> major version from 9 to 10 to reflect the fact that we now support a
>> new version of OpenGL.
>>
>> Note: although geometry shaders are feature complete, there are still
>> a few bugs that I still need to iron out before the next release.
>> Here is a list of all the current GLSL 1.50 and GL 3.2 piglit failures
>> on Ivy Bridge and Haswell.  With a few minor exceptions that are
>> unfixable due to hardware limitations, or which are too obscure to be
>> worth fixing, I believe I can take care of all of these by the Nov 27
>> release date.
>>
>> OpenGL 3.2 piglit failures:
>> --
>>
>> - layered-rendering/clear-{color,depth}: It appears that our glClear
>>   implementation doesn't clear all layers of a layered attachment.
>>
>> -
>> layered-rendering/{framebuffer-layered-attachments,framebuffertexture-defaults}:
>>   I have not investigated, but I believe Jordan Justen may be working
>>   on this.
>>
>> - minmax: GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS has the wrong value.
>>
>> GLSL 1.50 piglit failures:
>> -
>>
>> - built-in constants/* (9 failures) and compiler/constants.geom: a few
>>   new GLSL 1.50 built-in constants aren't being set up properly.
>>
>> -
>> compiler/{vs,gs}-redeclares-pervertex-out-{after,after-other,before}-global-redeclaration.geom:
>>   We're not flagging an error if both gl_PerVertex and one of its
>>   members are redeclared.
>>
>> -
>> compiler/incorrect-{in,out}-layout-qualifiers-with-variable-declarations.geom:
>>   We're not flagging an error if GS layout qualifiers are improperly
>>   applied to variables.
>>
>> - compiler/interface-blocks-name-reused-globally.vert: We're not
>>   flagging an error if an interface block name conflicts with a global
>>   variable name.
>>
>> - compiler/interfa

[Mesa-dev] [PATCH] mesa: fix transform feedback when a geometry shader is active.

[Paul Berry]

From: Bryan Cain 

When a geometry shader is active, the transform feedback primitive
type ("mode") needs to be validated against the geometry shader output
primitive type, not the primitive type passed to the glDraw*()
function.

Fixes the following piglit tests:
- glsl-1.50-geometry-primitive-types GL_LINES
- glsl-1.50-geometry-primitive-types GL_LINES_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_LINE_STRIP
- glsl-1.50-geometry-primitive-types GL_LINE_STRIP_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_TRIANGLES
- glsl-1.50-geometry-primitive-types GL_TRIANGLES_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_TRIANGLE_FAN

Exposes previously hidden failures in the following piglit tests:
- glsl-1.50-geometry-primitive-id-restart GL_LINES other
- glsl-1.50-geometry-primitive-id-restart GL_LINES_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_LOOP ffs
- glsl-1.50-geometry-primitive-id-restart GL_LINE_LOOP other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_STRIP other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_STRIP_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLES other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLES_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_FAN ffs
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_FAN other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP_ADJACENCY other

(These failures were previously hidden due to a flaw in the test: it
doesn't check for GL errors.  I'll fix the test shortly).
---
 src/mesa/main/api_validate.c | 53 +---
 1 file changed, 35 insertions(+), 18 deletions(-)

diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 0029921..f285c97 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -330,26 +330,43 @@ _mesa_valid_prim_mode(struct gl_context *ctx, GLenum 
mode, const char *name)
if (_mesa_is_xfb_active_and_unpaused(ctx)) {
   GLboolean pass = GL_TRUE;
 
-  switch (mode) {
-  case GL_POINTS:
- pass = ctx->TransformFeedback.Mode == GL_POINTS;
-break;
-  case GL_LINES:
-  case GL_LINE_STRIP:
-  case GL_LINE_LOOP:
- pass = ctx->TransformFeedback.Mode == GL_LINES;
-break;
-  default:
- pass = ctx->TransformFeedback.Mode == GL_TRIANGLES;
-break;
+  if(ctx->Shader.CurrentGeometryProgram) {
+ switch (ctx->Shader.CurrentGeometryProgram->Geom.OutputType) {
+ case GL_POINTS:
+pass = ctx->TransformFeedback.Mode == GL_POINTS;
+break;
+ case GL_LINE_STRIP:
+pass = ctx->TransformFeedback.Mode == GL_LINES;
+break;
+ case GL_TRIANGLE_STRIP:
+pass = ctx->TransformFeedback.Mode == GL_TRIANGLES;
+break;
+ default:
+pass = GL_FALSE;
+ }
+  }
+  else {
+ switch (mode) {
+ case GL_POINTS:
+pass = ctx->TransformFeedback.Mode == GL_POINTS;
+break;
+ case GL_LINES:
+ case GL_LINE_STRIP:
+ case GL_LINE_LOOP:
+pass = ctx->TransformFeedback.Mode == GL_LINES;
+break;
+ default:
+pass = ctx->TransformFeedback.Mode == GL_TRIANGLES;
+break;
+ }
   }
   if (!pass) {
-_mesa_error(ctx, GL_INVALID_OPERATION,
-"%s(mode=%s vs transform feedback %s)",
-name,
-_mesa_lookup_prim_by_nr(mode),
-_mesa_lookup_prim_by_nr(ctx->TransformFeedback.Mode));
-return GL_FALSE;
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+"%s(mode=%s vs transform feedback %s)",
+name,
+_mesa_lookup_prim_by_nr(mode),
+_mesa_lookup_prim_by_nr(ctx->TransformFeedback.Mode));
+ return GL_FALSE;
   }
}
 
-- 
1.8.4

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

[Mesa-dev] [PATCH] i965/gs: Set the REORDER bit in 3DSTATE_GS.

[Paul Berry]

Ivy Bridge's "reorder enable" bit gives us a binary choice for the
order in which vertices from triangle strips are delivered to the
geometry shader.  Neither choice follows the OpenGL spec, but setting
the bit is better, because it gets triangle orientation correct.

Haswell replaces the "reorder enable" bit with a new "reorder mode"
bit (which occupies the same location in the command packet).  This
bit gives us a different binary choice, which affects both triangle
strips and triangle strips with adjacency.  Setting the bit gives the
proper order according to the OpenGL spec.

So in either case we want to set the bit.

On Ivy Bridge, fixes piglit test "triangle-strip-orientation".

On Haswell, fixes piglit tests "glsl-1.50-geometry-primitive-types
{GL_TRIANGLE_STRIP,GL_TRIANGLE_STRIP_ADJACENCY}" and
"glsl-1.50-geometry-tri-strip-ordering-with-prim-restart *".
---
 src/mesa/drivers/dri/i965/brw_defines.h   |  1 +
 src/mesa/drivers/dri/i965/gen7_gs_state.c | 28 
 2 files changed, 29 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index c1e7f31..902b7e8 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1381,6 +1381,7 @@ enum brw_message_target {
 # define GEN6_GS_SO_STATISTICS_ENABLE  (1 << 9)
 # define GEN6_GS_RENDERING_ENABLE  (1 << 8)
 # define GEN7_GS_INCLUDE_PRIMITIVE_ID  (1 << 4)
+# define GEN7_GS_REORDER_MODE  (1 << 2)
 # define GEN7_GS_ENABLE(1 << 0)
 /* DW6 */
 # define HSW_GS_CONTROL_DATA_FORMAT_SHIFT  31
diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c 
b/src/mesa/drivers/dri/i965/gen7_gs_state.c
index 3dd5896..bd5b666 100644
--- a/src/mesa/drivers/dri/i965/gen7_gs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_gs_state.c
@@ -105,6 +105,33 @@ upload_gs_state(struct brw_context *brw)
  (0 << GEN6_GS_URB_ENTRY_READ_OFFSET_SHIFT) |
  (prog_data->dispatch_grf_start_reg <<
   GEN6_GS_DISPATCH_START_GRF_SHIFT);
+
+  /* Note: the meaning of the GEN7_GS_REORDER_MODE bit changes between Ivy
+   * Bridge and Haswell.
+   *
+   * On Ivy bridge, setting this bit causes the vertices of a triangle
+   * strip to be delivered to the geometry shader in an order that does
+   * not strictly follow the OpenGL spec, but preserves triangle
+   * orientation.  For example, if the vertices are (1, 2, 3, 4, 5), then
+   * the geometry shader sees triangles:
+   *
+   * (1, 2, 3), (2, 4, 3), (3, 4, 5)
+   *
+   * (Clearing the bit is even worse, because it fails to preserve
+   * orientation).
+   *
+   * Triangle strips with adjacency always ordered in a way that preserves
+   * triangle orientation but does not strictly follow the OpenGL spec,
+   * regardless of the setting of this bit.
+   *
+   * On Haswell, both triangle strips and triangle strips with adjacency
+   * are always ordered in a way that preserves triangle orientation.
+   * Setting this bit causes the ordering to strictly follow the OpenGL
+   * spec.
+   *
+   * So in either case we want to set the bit.  Unfortunately on Ivy
+   * Bridge this will get the order close to correct but not perfect.
+   */
   uint32_t dw5 =
  ((brw->max_gs_threads - 1) << max_threads_shift) |
  (brw->gs.prog_data->control_data_header_size_hwords <<
@@ -113,6 +140,7 @@ upload_gs_state(struct brw_context *brw)
  GEN6_GS_STATISTICS_ENABLE |
  (brw->gs.prog_data->include_primitive_id ?
   GEN7_GS_INCLUDE_PRIMITIVE_ID : 0) |
+ GEN7_GS_REORDER_MODE |
  GEN7_GS_ENABLE;
   uint32_t dw6 = 0;
 
-- 
1.8.4

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

[Mesa-dev] [PATCH 1/2] vbo: Make vbo_sw_primitive_restart optionally count primitives.

[Paul Berry]

This will be necessary in order to get the i965 back-end to produce
the correct value of gl_PrimitiveIDIn when using software primitive
restart.
---
 src/mesa/drivers/dri/i965/brw_primitive_restart.c |  2 +-
 src/mesa/vbo/vbo.h|  3 ++-
 src/mesa/vbo/vbo_exec_array.c |  2 +-
 src/mesa/vbo/vbo_primitive_restart.c  | 16 +++-
 4 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_primitive_restart.c 
b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
index 2ee6055..2572c12 100644
--- a/src/mesa/drivers/dri/i965/brw_primitive_restart.c
+++ b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
@@ -175,7 +175,7 @@ brw_handle_primitive_restart(struct gl_context *ctx,
   /* Not all the primitive draw modes are supported by the cut index,
* so take the software path
*/
-  vbo_sw_primitive_restart(ctx, prims, nr_prims, ib);
+  vbo_sw_primitive_restart(ctx, prims, nr_prims, ib, NULL);
}
 
brw->prim_restart.in_progress = false;
diff --git a/src/mesa/vbo/vbo.h b/src/mesa/vbo/vbo.h
index c4472e9..ec3b6f5 100644
--- a/src/mesa/vbo/vbo.h
+++ b/src/mesa/vbo/vbo.h
@@ -182,7 +182,8 @@ void
 vbo_sw_primitive_restart(struct gl_context *ctx,
  const struct _mesa_prim *prim,
  GLuint nr_prims,
- const struct _mesa_index_buffer *ib);
+ const struct _mesa_index_buffer *ib,
+ GLuint *prim_count);
 
 void GLAPIENTRY
 _es_Color4f(GLfloat r, GLfloat g, GLfloat b, GLfloat a);
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 1670409..afe2a15 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -579,7 +579,7 @@ vbo_handle_primitive_restart(struct gl_context *ctx,
ctx->Const.PrimitiveRestartInSoftware &&
ctx->Array._PrimitiveRestart) {
   /* Handle primitive restart in software */
-  vbo_sw_primitive_restart(ctx, prim, nr_prims, ib);
+  vbo_sw_primitive_restart(ctx, prim, nr_prims, ib, NULL);
} else {
   /* Call driver directly for draw_prims */
   vbo->draw_prims(ctx, prim, nr_prims, ib,
diff --git a/src/mesa/vbo/vbo_primitive_restart.c 
b/src/mesa/vbo/vbo_primitive_restart.c
index 418f882..13a8c43 100644
--- a/src/mesa/vbo/vbo_primitive_restart.c
+++ b/src/mesa/vbo/vbo_primitive_restart.c
@@ -158,12 +158,17 @@ find_sub_primitives(const void *elements, unsigned 
element_size,
  *
  * This function breaks up calls into the driver so primitive restart
  * support is not required in the driver.
+ *
+ * If a non-NULL value is passed in prim_count, then prior to each draw call,
+ * that value is updated to contain the number of primitives previously
+ * processed.
  */
 void
 vbo_sw_primitive_restart(struct gl_context *ctx,
  const struct _mesa_prim *prims,
  GLuint nr_prims,
- const struct _mesa_index_buffer *ib)
+ const struct _mesa_index_buffer *ib,
+ GLuint *prim_count)
 {
GLuint prim_num;
struct sub_primitive *sub_prims;
@@ -197,6 +202,9 @@ vbo_sw_primitive_restart(struct gl_context *ctx,
   ctx->Driver.UnmapBuffer(ctx, ib->obj);
}
 
+   if (prim_count != NULL)
+  *prim_count = 0;
+
/* Loop over the primitives, and use the located sub-primitives to draw
 * each primitive with a break to implement each primitive restart.
 */
@@ -220,6 +228,12 @@ vbo_sw_primitive_restart(struct gl_context *ctx,
GL_FALSE, -1, -1,
NULL);
 }
+if (prim_count != NULL) {
+   *prim_count +=
+  vbo_count_tessellated_primitives(temp_prim.mode,
+   temp_prim.count,
+   temp_prim.num_instances);
+}
  }
  if (sub_end_index >= end_index) {
 break;
-- 
1.8.4

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

[Mesa-dev] [PATCH 2/2] i965/gs: Fix gl_PrimitiveIDIn when using SW primitive restart.

[Paul Berry]

Ivy Bridge hardware doesn't support primitve restart under all
circumstances--when it doesn't, we emulate it in software by splitting
up each logical draw operation into multiple 3DPRIMITIVE commands.
This causes the hardware's primitive ID counter to be reset to 0,
producing incorrect values for gl_PrimitiveIDIn.

To work around that problem, we create a hidden uniform which is added
to the hardware's primitive ID counter at the top of the geometry
shader; the software primitive restart mechanism ensures that this
uniform always contains the number of primitives that were sent down
the pipeline by previous 3DPRIMITIVE commands within the same logical
draw operation.

To reduce the performance impact of the workaround, we only compile it
into the shader when the hardware is Ivy Bridge and the shader
accesses gl_PrimitiveIDIn.  To reduce unnecessary state updates, we
only flag _NEW_PROGRAM_CONSTANTS when when the workaround is compiled
in *and* software primitive restart is active.

On Ivy Bridge, fixes all variants of
"glsl-1.50-geometry-primitive-id-restart" except the GL_LINE_LOOP
variants, which are broken due to an unrelated hardware limitation.
---
 src/mesa/drivers/dri/i965/brw_context.c   |  1 +
 src/mesa/drivers/dri/i965/brw_context.h   |  2 ++
 src/mesa/drivers/dri/i965/brw_draw.c  | 20 +++
 src/mesa/drivers/dri/i965/brw_primitive_restart.c |  4 ++-
 src/mesa/drivers/dri/i965/brw_vec4_gs.c   | 11 +
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 30 +++
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h   |  1 +
 7 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 776d221..0717398 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -453,6 +453,7 @@ brwCreateContext(int api,
 
brw->prim_restart.in_progress = false;
brw->prim_restart.enable_cut_index = false;
+   brw->prim_restart.sw_prim_counter = 0;
 
brw_init_state( brw );
 
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index c6e6655..8625145 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -591,6 +591,7 @@ struct brw_gs_prog_data
unsigned control_data_format;
 
bool include_primitive_id;
+   bool need_primitive_id_workaround;
 };
 
 /** Number of texture sampler units */
@@ -1365,6 +1366,7 @@ struct brw_context
struct {
   bool in_progress;
   bool enable_cut_index;
+  GLuint sw_prim_counter;
} prim_restart;
 
/** Computed depth/stencil/hiz state from the current attached
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 549f9d0a..cf283d3 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -445,6 +445,26 @@ retry:
   }
}
 
+   /* When using software primitive restart, Ivy Bridge resets the primitive
+* ID on each restart.  We work around this by creating a hidden uniform
+* whose value will be added to the incoming primitive ID.
+*
+* To ensure that the uniform value gets updated, we need to flag
+* _NEW_PROGRAM_CONSTANTS.
+*
+* We do this after the draw call because that's when the uniform value
+* changes (vbo_sw_primitive_restart() increments it after each draw, and
+* brw_handle_primitive_restart() resets it to 0 after the final draw).  A
+* side benefit of doing this after the draw is that we can safely examine
+* brw->geometry_program and brw->gs.prog_data to see if the workaround is
+* necessary.
+*/
+   if (brw->gen < 8 && !brw->is_haswell && brw->prim_restart.in_progress &&
+   !brw->prim_restart.enable_cut_index && brw->geometry_program != NULL &&
+   brw->gs.prog_data->need_primitive_id_workaround) {
+  ctx->NewState |= _NEW_PROGRAM_CONSTANTS;
+   }
+
if (brw->always_flush_batch)
   intel_batchbuffer_flush(brw);
 
diff --git a/src/mesa/drivers/dri/i965/brw_primitive_restart.c 
b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
index 2572c12..cbd8d21 100644
--- a/src/mesa/drivers/dri/i965/brw_primitive_restart.c
+++ b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
@@ -175,7 +175,9 @@ brw_handle_primitive_restart(struct gl_context *ctx,
   /* Not all the primitive draw modes are supported by the cut index,
* so take the software path
*/
-  vbo_sw_primitive_restart(ctx, prims, nr_prims, ib, NULL);
+  vbo_sw_primitive_restart(ctx, prims, nr_prims, ib,
+   &brw->prim_restart.sw_prim_counter);
+  brw->prim_restart.sw_prim_counter = 0;
}
 
brw->prim_restart.in_progress = false;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs.c 
b/src/mesa/drivers/dri/i965/brw_vec4_gs.c
index 064e541..bfc9bc8 100644
--- a/src/mesa/drivers/dri/i965/brw

[Mesa-dev] [PATCH] i965/fs: Remove bogus field prog_data->dispatch_width.

[Paul Berry]

Despite the name, this field wasn't being set to the dispatch width at
all; it was always 8.  The only place it was used was that the
constant buffer read length was aligned to it, and as far as I can
tell from the docs, there is no need to align this value to the
dispatch width; aligning it to a multiple of 8 is sufficient.  So I've
just replaced it with a hardcoded 8.
---
 src/mesa/drivers/dri/i965/brw_context.h   | 1 -
 src/mesa/drivers/dri/i965/brw_fs.cpp  | 2 --
 src/mesa/drivers/dri/i965/gen6_wm_state.c | 6 ++
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index c6e6655..490216c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -328,7 +328,6 @@ struct brw_wm_prog_data {
GLuint nr_params;   /**< number of float params/constants */
GLuint nr_pull_params;
bool dual_src_blend;
-   int dispatch_width;
uint32_t prog_offset_16;
 
/**
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 0238336..4d12f7a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3147,8 +3147,6 @@ brw_wm_fs_emit(struct brw_context *brw, struct 
brw_wm_compile *c,
   }
}
 
-   c->prog_data.dispatch_width = 8;
-
fs_generator g(brw, c, prog, fp, v.dual_src_output.file != BAD_FILE);
const unsigned *generated = g.generate_assembly(&v.instructions,
simd16_instructions,
diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c 
b/src/mesa/drivers/dri/i965/gen6_wm_state.c
index c96a107..cccb107 100644
--- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
@@ -78,8 +78,7 @@ gen6_upload_wm_push_constants(struct brw_context *brw)
 printf("\n");
   }
 
-  brw->wm.base.push_const_size =
- ALIGN(prog_data->nr_params, prog_data->dispatch_width) / 8;
+  brw->wm.base.push_const_size = ALIGN(prog_data->nr_params, 8) / 8;
}
 }
 
@@ -123,8 +122,7 @@ upload_wm_state(struct brw_context *brw)
* state flags from gen6_upload_wm_push_constants.
*/
   OUT_BATCH(brw->wm.base.push_const_offset +
-   ALIGN(brw->wm.prog_data->nr_params,
- brw->wm.prog_data->dispatch_width) / 8 - 1);
+   ALIGN(brw->wm.prog_data->nr_params, 8) / 8 - 1);
   OUT_BATCH(0);
   OUT_BATCH(0);
   OUT_BATCH(0);
-- 
1.8.4

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

Re: [Mesa-dev] [PATCH] i965/gs: Set the REORDER bit in 3DSTATE_GS.

[Paul Berry]

On 11 October 2013 14:13, Matt Turner  wrote:

> On Fri, Oct 11, 2013 at 1:27 PM, Paul Berry 
> wrote:
> > Ivy Bridge's "reorder enable" bit gives us a binary choice for the
> > order in which vertices from triangle strips are delivered to the
> > geometry shader.  Neither choice follows the OpenGL spec, but setting
> > the bit is better, because it gets triangle orientation correct.
> >
> > Haswell replaces the "reorder enable" bit with a new "reorder mode"
> > bit (which occupies the same location in the command packet).  This
> > bit gives us a different binary choice, which affects both triangle
> > strips and triangle strips with adjacency.  Setting the bit gives the
> > proper order according to the OpenGL spec.
> >
> > So in either case we want to set the bit.
> >
> > On Ivy Bridge, fixes piglit test "triangle-strip-orientation".
> >
> > On Haswell, fixes piglit tests "glsl-1.50-geometry-primitive-types
> > {GL_TRIANGLE_STRIP,GL_TRIANGLE_STRIP_ADJACENCY}" and
> > "glsl-1.50-geometry-tri-strip-ordering-with-prim-restart *".
> > ---
> >  src/mesa/drivers/dri/i965/brw_defines.h   |  1 +
> >  src/mesa/drivers/dri/i965/gen7_gs_state.c | 28
> 
> >  2 files changed, 29 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
> b/src/mesa/drivers/dri/i965/brw_defines.h
> > index c1e7f31..902b7e8 100644
> > --- a/src/mesa/drivers/dri/i965/brw_defines.h
> > +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> > @@ -1381,6 +1381,7 @@ enum brw_message_target {
> >  # define GEN6_GS_SO_STATISTICS_ENABLE  (1 << 9)
> >  # define GEN6_GS_RENDERING_ENABLE  (1 << 8)
> >  # define GEN7_GS_INCLUDE_PRIMITIVE_ID  (1 << 4)
> > +# define GEN7_GS_REORDER_MODE  (1 << 2)
> >  # define GEN7_GS_ENABLE(1 << 0)
> >  /* DW6 */
> >  # define HSW_GS_CONTROL_DATA_FORMAT_SHIFT  31
> > diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c
> b/src/mesa/drivers/dri/i965/gen7_gs_state.c
> > index 3dd5896..bd5b666 100644
> > --- a/src/mesa/drivers/dri/i965/gen7_gs_state.c
> > +++ b/src/mesa/drivers/dri/i965/gen7_gs_state.c
> > @@ -105,6 +105,33 @@ upload_gs_state(struct brw_context *brw)
> >   (0 << GEN6_GS_URB_ENTRY_READ_OFFSET_SHIFT) |
> >   (prog_data->dispatch_grf_start_reg <<
> >GEN6_GS_DISPATCH_START_GRF_SHIFT);
> > +
> > +  /* Note: the meaning of the GEN7_GS_REORDER_MODE bit changes
> between Ivy
> > +   * Bridge and Haswell.
> > +   *
> > +   * On Ivy bridge, setting this bit causes the vertices of a
> triangle
>
> You've capitalized Bridge everywhere else, so I suppose you meant to
> here as well.
>

Fixed, thanks.


>
> > +   * strip to be delivered to the geometry shader in an order that
> does
> > +   * not strictly follow the OpenGL spec, but preserves triangle
> > +   * orientation.  For example, if the vertices are (1, 2, 3, 4,
> 5), then
> > +   * the geometry shader sees triangles:
> > +   *
> > +   * (1, 2, 3), (2, 4, 3), (3, 4, 5)
> > +   *
> > +   * (Clearing the bit is even worse, because it fails to preserve
> > +   * orientation).
> > +   *
> > +   * Triangle strips with adjacency always ordered in a way that
> preserves
> > +   * triangle orientation but does not strictly follow the OpenGL
> spec,
> > +   * regardless of the setting of this bit.
> > +   *
> > +   * On Haswell, both triangle strips and triangle strips with
> adjacency
> > +   * are always ordered in a way that preserves triangle
> orientation.
> > +   * Setting this bit causes the ordering to strictly follow the
> OpenGL
> > +   * spec.
> > +   *
> > +   * So in either case we want to set the bit.  Unfortunately on Ivy
> > +   * Bridge this will get the order close to correct but not
> perfect.
> > +   */
> >uint32_t dw5 =
> >   ((brw->max_gs_threads - 1) << max_threads_shift) |
> >   (brw->gs.prog_data->control_data_header_size_hwords <<
> > @@ -113,6 +140,7 @@ upload_gs_state(struct brw_context *brw)
> >   GEN6_GS_STATISTICS_ENABLE |
> >   (brw->gs.prog_data->include_primitive_id ?
> >GEN7_GS_INCLUDE_PRIMITIVE_ID : 0) |
> > + GEN7_GS_REORDER_MODE |
>
> The actual 1-bit is called REORDER_TRAILING on Haswell. Should we call
> it that instead?
>

Yeah, that's a good point.  I've renamed it.


>
> In any case:
>
> Reviewed-by: Matt Turner 
>

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

[Mesa-dev] [PATCH] glsl: Add new GLSL 1.50 constants.

[Paul Berry]

This patch populates the following built-in GLSL 1.50 variables based
on constants stored in ctx->Const:

- gl_MaxVertexOutputComponents
- gl_MaxGeometryInputComponents
- gl_MaxGeometryOutputComponents
- gl_MaxFragmentInputComponents
- gl_MaxGeometryTextureImageUnits
- gl_MaxGeometryOutputVertices
- gl_MaxGeometryTotalOutputComponents
- gl_MaxGeometryUniformComponents
- gl_MaxGeometryVaryingComponents

On i965/gen7, fixes all Piglit tests in "spec/glsl-1.50/built-in
constants/*" except for gl_MaxCombinedTextureImageUnits and
gl_MaxGeometryUniformComponents.
---
 src/glsl/builtin_variables.cpp  | 31 +++
 src/glsl/glsl_parser_extras.cpp | 10 ++
 src/glsl/glsl_parser_extras.h   | 10 ++
 3 files changed, 51 insertions(+)

diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index ae0a03f..f06d2ab 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -583,6 +583,37 @@ builtin_variable_generator::generate_constants()
   add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying * 4);
}
 
+   if (state->is_version(150, 0)) {
+  add_const("gl_MaxVertexOutputComponents",
+state->Const.MaxVertexOutputComponents);
+  add_const("gl_MaxGeometryInputComponents",
+state->Const.MaxGeometryInputComponents);
+  add_const("gl_MaxGeometryOutputComponents",
+state->Const.MaxGeometryOutputComponents);
+  add_const("gl_MaxFragmentInputComponents",
+state->Const.MaxFragmentInputComponents);
+  add_const("gl_MaxGeometryTextureImageUnits",
+state->Const.MaxGeometryTextureImageUnits);
+  add_const("gl_MaxGeometryOutputVertices",
+state->Const.MaxGeometryOutputVertices);
+  add_const("gl_MaxGeometryTotalOutputComponents",
+state->Const.MaxGeometryTotalOutputComponents);
+  add_const("gl_MaxGeometryUniformComponents",
+state->Const.MaxGeometryUniformComponents);
+
+  /* Note: the GLSL 1.50-4.40 specs require
+   * gl_MaxGeometryVaryingComponents to be present, and to be at least 64.
+   * But they do not define what it means (and there does not appear to be
+   * any corresponding constant in the GL specs).  However,
+   * ARB_geometry_shader4 defines MAX_GEOMETRY_VARYING_COMPONENTS_ARB to
+   * be the maximum number of components available for use as geometry
+   * outputs.  So we assume this is a synonym for
+   * gl_MaxGeometryOutputComponents.
+   */
+  add_const("gl_MaxGeometryVaryingComponents",
+state->Const.MaxGeometryOutputComponents);
+   }
+
if (compatibility) {
   /* Note: gl_MaxLights stopped being listed as an explicit constant in
* GLSL 1.30, however it continues to be referred to (as a minimum size
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index f1cabf4..be17109 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -108,6 +108,16 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct 
gl_context *_ctx,
 
this->Const.MaxDrawBuffers = ctx->Const.MaxDrawBuffers;
 
+   /* 1.50 constants */
+   this->Const.MaxVertexOutputComponents = 
ctx->Const.VertexProgram.MaxOutputComponents;
+   this->Const.MaxGeometryInputComponents = 
ctx->Const.GeometryProgram.MaxInputComponents;
+   this->Const.MaxGeometryOutputComponents = 
ctx->Const.GeometryProgram.MaxOutputComponents;
+   this->Const.MaxFragmentInputComponents = 
ctx->Const.FragmentProgram.MaxInputComponents;
+   this->Const.MaxGeometryTextureImageUnits = 
ctx->Const.GeometryProgram.MaxTextureImageUnits;
+   this->Const.MaxGeometryOutputVertices = 
ctx->Const.MaxGeometryOutputVertices;
+   this->Const.MaxGeometryTotalOutputComponents = 
ctx->Const.MaxGeometryTotalOutputComponents;
+   this->Const.MaxGeometryUniformComponents = 
ctx->Const.GeometryProgram.MaxUniformComponents;
+
this->current_function = NULL;
this->toplevel_ir = NULL;
this->found_return = false;
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 26841f5..a674384 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -219,6 +219,16 @@ struct _mesa_glsl_parse_state {
   /* 3.00 ES */
   int MinProgramTexelOffset;
   int MaxProgramTexelOffset;
+
+  /* 1.50 */
+  unsigned MaxVertexOutputComponents;
+  unsigned MaxGeometryInputComponents;
+  unsigned MaxGeometryOutputComponents;
+  unsigned MaxFragmentInputComponents;
+  unsigned MaxGeometryTextureImageUnits;
+  unsigned MaxGeometryOutputVertices;
+  unsigned MaxGeometryTotalOutputComponents;
+  unsigned MaxGeometryUniformComponents;
} Const;
 
/**
-- 
1.8.4

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

Re: [Mesa-dev] [PATCH] glsl: Add new GLSL 1.50 constants.

[Paul Berry]

On 11 October 2013 17:53, Matt Turner  wrote:

> On Fri, Oct 11, 2013 at 5:29 PM, Paul Berry 
> wrote:
> > This patch populates the following built-in GLSL 1.50 variables based
> > on constants stored in ctx->Const:
> >
> > - gl_MaxVertexOutputComponents
> > - gl_MaxGeometryInputComponents
> > - gl_MaxGeometryOutputComponents
> > - gl_MaxFragmentInputComponents
> > - gl_MaxGeometryTextureImageUnits
>
> Presumably this is the GS140 task (named
> gl_MaxGeometryTexture*Image*Units)?
>

Oops, yes, you're right.  I had a typo in my task list.  Fixed!


>
> > - gl_MaxGeometryOutputVertices
> > - gl_MaxGeometryTotalOutputComponents
> > - gl_MaxGeometryUniformComponents
> > - gl_MaxGeometryVaryingComponents
> >
> > On i965/gen7, fixes all Piglit tests in "spec/glsl-1.50/built-in
> > constants/*" except for gl_MaxCombinedTextureImageUnits and
> > gl_MaxGeometryUniformComponents.
> > ---
>
> Reviewed-by: Matt Turner 
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] Enable GL 3.2 support for i965, bump Mesa version.

[Paul Berry]

On 10 October 2013 21:27, Paul Berry  wrote:

> It's been a long and rocky road, but geometry shader support in Mesa's
> i965/gen7 driver has finally reached a point I'm willing to call
> "feature complete".  Since geometry shaders were the last remaining
> feature needed for GL 3.2, it's time to turn on GL 3.2 support.  Here
> is a short patch series to turn it on.
>
> Patch 1 enables GLSL 1.50 and GL 3.2 for i965/gen7 parts (Ivy Bridge
> and Haswell).  Patch 2 removes the old warning message "Geometry
> shader support is currently experimental".  Patch 3 bumps the Mesa
> major version from 9 to 10 to reflect the fact that we now support a
> new version of OpenGL.
>

Ok, I've pushed this series.  Note: on i965/gen7, there is an apparent
regression: "glsl-1.40/built-in constants *" tests now fail.  This is due
to a flaw in the test (it is trying to create geometry shaders using a
"#version 140" directive).  I will send out a piglit patch soon that fixes
the test.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] i965: Move the common binding table offset code to brw_shader.cpp.

[Paul Berry]

On 4 October 2013 15:44, Eric Anholt  wrote:

> Now that both vec4 and fs are dynamically assigning offsets, a lot of the
> code is the same.
> ---
>

Since next_binding_table_offset is only used to into
assign_common_binding_table_offsets(), I'd prefer to see it made into a
function argument rather than a class member.  That way it wouldn't be
necessary to grep through the code to verify that no one else uses it.

With that changed, this patch is:

Reviewed-by: Paul Berry 

I already sent out a comment on patch 4/7.  The remainder of the series is:

Reviewed-by: Paul Berry 


>  src/mesa/drivers/dri/i965/brw_fs.cpp   | 33 ++
>  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |  3 ++
>  src/mesa/drivers/dri/i965/brw_shader.cpp   | 47
> ++
>  src/mesa/drivers/dri/i965/brw_shader.h |  5 +++
>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 33 +-
>  src/mesa/drivers/dri/i965/brw_vec4.h   |  1 -
>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  2 ++
>  7 files changed, 61 insertions(+), 63 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 86ff378..13c6ddc 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -2943,37 +2943,10 @@ fs_visitor::setup_payload_gen6()
>  void
>  fs_visitor::assign_binding_table_offsets()
>  {
> -   int num_textures = _mesa_fls(fp->Base.SamplersUsed);
> -   int next = 0;
> +   c->prog_data.binding_table.render_target_start =
> next_binding_table_offset;
> +   next_binding_table_offset += c->key.nr_color_regions;
>
> -   c->prog_data.binding_table.render_target_start = next;
> -   next += c->key.nr_color_regions;
> -
> -   c->prog_data.base.binding_table.texture_start = next;
> -   next += num_textures;
> -
> -   if (shader) {
> -  c->prog_data.base.binding_table.ubo_start = next;
> -  next += shader->base.NumUniformBlocks;
> -   }
> -
> -   if (INTEL_DEBUG & DEBUG_SHADER_TIME) {
> -  c->prog_data.base.binding_table.shader_time_start = next;
> -  next++;
> -   }
> -
> -   if (fp->Base.UsesGather) {
> -  c->prog_data.base.binding_table.gather_texture_start = next;
> -  next += num_textures;
> -   }
> -
> -   /* This may or may not be used depending on how the compile goes. */
> -   c->prog_data.base.binding_table.pull_constants_start = next;
> -   next++;
> -
> -   assert(next < BRW_MAX_SURFACES);
> -
> -   /* c->prog_data.base.binding_table.size will be set by
> mark_surface_used. */
> +   assign_common_binding_table_offsets();
>  }
>
>  bool
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> index 8fa7f9d..aa76231 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> @@ -2617,8 +2617,10 @@ fs_visitor::fs_visitor(struct brw_context *brw,
> this->c = c;
> this->brw = brw;
> this->fp = fp;
> +   this->prog = &fp->Base;
> this->shader_prog = shader_prog;
> this->prog = &fp->Base;
> +   this->stage_prog_data = &c->prog_data.base;
> this->ctx = &brw->ctx;
> this->mem_ctx = ralloc_context(NULL);
> if (shader_prog)
> @@ -2651,6 +2653,7 @@ fs_visitor::fs_visitor(struct brw_context *brw,
>
> this->force_uncompressed_stack = 0;
> this->force_sechalf_stack = 0;
> +   this->next_binding_table_offset = 0;
>
> memset(&this->param_size, 0, sizeof(this->param_size));
>  }
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
> b/src/mesa/drivers/dri/i965/brw_shader.cpp
> index 61c4bf5..b97bb5e 100644
> --- a/src/mesa/drivers/dri/i965/brw_shader.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
> @@ -578,3 +578,50 @@ backend_visitor::dump_instructions()
>dump_instruction(inst);
> }
>  }
> +
> +
> +/**
> + * Sets up the starting offsets for the groups of binding table entries
> + * commong to all pipeline stages.
> + *
> + * Unused groups are initialized to 0xd0d0d0d0 to make it obvious that
> they're
> + * unused but also make sure that addition of small offsets to them will
> + * trigger some of our asserts that surface indices are <
> BRW_MAX_SURFACES.
> + */
> +void
> +backend_visitor::assign_common_binding_table_offsets()
> +{
> +   int num_textures = _mesa_fls(prog->SamplersUsed);
> +
> +   stage_prog_data->binding_table.texture_start =
> next_binding_table_offset;
> +   next_binding_table_offset += n

[Mesa-dev] [PATCH] glsl: In update_max_array_access, fix interface instance check.

[Paul Berry]

In commit f878d20 (glsl: Update ir_variable::max_ifc_array_access
properly), I accidentally used the wrong kind of check to determine
whether the variable being accessed was an interface instance (I used
var->get_interface_type() != NULL when I should have used
var->is_interface_instance()).  As a result, if an unnamed interface
block contained a struct which contained an array,
update_max_array_access() would mistakenly interpret the struct as a
named interface block and try to dereference a null
var->max_ifc_array_access.

This patch corrects the check, fixing the null dereference.

Fixes piglit test interface-block-struct-nesting.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70368
---
 src/glsl/ast_array_index.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/glsl/ast_array_index.cpp b/src/glsl/ast_array_index.cpp
index da96cc1..b457ec8 100644
--- a/src/glsl/ast_array_index.cpp
+++ b/src/glsl/ast_array_index.cpp
@@ -69,9 +69,9 @@ update_max_array_access(ir_rvalue *ir, unsigned idx, YYLTYPE 
*loc,
   }
 
   if (deref_var != NULL) {
- const glsl_type *interface_type =
-deref_var->var->get_interface_type();
- if (interface_type != NULL) {
+ if (deref_var->var->is_interface_instance()) {
+const glsl_type *interface_type =
+   deref_var->var->get_interface_type();
 unsigned field_index =
deref_record->record->type->field_index(deref_record->field);
 assert(field_index < interface_type->length);
-- 
1.8.4

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

Re: [Mesa-dev] [PATCH] i965/fs: Remove bogus field prog_data->dispatch_width.

[Paul Berry]

On 11 October 2013 16:18, Eric Anholt  wrote:

> Paul Berry  writes:
>
> > Despite the name, this field wasn't being set to the dispatch width at
> > all; it was always 8.  The only place it was used was that the
> > constant buffer read length was aligned to it, and as far as I can
> > tell from the docs, there is no need to align this value to the
> > dispatch width; aligning it to a multiple of 8 is sufficient.  So I've
> > just replaced it with a hardcoded 8.
>
> Reviewed-by: Eric Anholt 
>
> but I'd also r-b a patch that reused brw->wm.base.push_const_size in the
> last hunk.
>

Good idea--I like that even better.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: When disabling gl_PerVertex variables, check that mode matches.

[Paul Berry]

In commit 1b4a737 (glsl: Support redeclaration of VS and GS
gl_PerVertex output), I added code to ensure that when an unnamed
gl_PerVertex interface block is redeclared, any ir_variables that
weren't included in the redeclaration are removed from the IR (and the
symbol table).  This ensures that only those variables that were
explicitly redeclared may be used.

However, when I wrote this code, I neglected to match the variable
mode when finding variables to remove.  This meant that redeclaring a
built-in output block might cause the built-in input gl_in to be
accidentally removed.

Fixes piglit test gs-redeclares-pervertex-out-only.
---
 src/glsl/ast_to_hir.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index dfa32d9..3803c3f 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4959,7 +4959,8 @@ ast_interface_block::hir(exec_list *instructions,
  foreach_list_safe(node, instructions) {
 ir_variable *const var = ((ir_instruction *) node)->as_variable();
 if (var != NULL &&
-var->get_interface_type() == earlier_per_vertex) {
+var->get_interface_type() == earlier_per_vertex &&
+var->mode == var_mode) {
state->symbols->disable_variable(var->name);
var->remove();
 }
-- 
1.8.4

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

[Mesa-dev] [PATCH 1/2] glsl: Call check_builtin_array_max_size when redeclaring gl_in.

[Paul Berry]

Normally when a built-in array (such as gl_ClipDistance) is
redeclared, we call get_variable_being_redeclared() to do the
redeclaration, and it in turn calls check_builtin_array_max_size() to
make sure that the redeclared array size isn't too large.

However when a built-in array is redeclared as part of redeclaring
gl_in, we don't call get_variable_being_redeclared() (since the
individual built-ins aren't each represented by their own ir_variable
anymore).  So we need to add an explicit call to
check_builtin_array_max_size() to make sure the new array size isn't
too large.

Note: at the moment this is redundant with a test that's done at link
time, so there's no change to piglit results.  But the patch that
follows will prevent link errors from being reported if gl_PerVertex
isn't used, so in order to prevent that patch from causing
regressions, we need to add the compile check now.  Besides, it's
nicer to report this error at compile time anyhow.
---
 src/glsl/ast_to_hir.cpp | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index dfa32d9..c732187 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4831,8 +4831,24 @@ ast_interface_block::hir(exec_list *instructions,
 * field selector ( . ) operator (analogously to structures)."
 */
if (this->instance_name) {
-  if (!redeclaring_per_vertex)
+  if (redeclaring_per_vertex) {
+ /* When a built-in in an unnamed interface block is redeclared,
+  * get_variable_being_redeclared() calls
+  * check_builtin_array_max_size() to make sure that built-in array
+  * variables aren't redeclared to illegal sizes.  But we're looking
+  * at a redeclaration of a named built-in interface block.  So we
+  * have to manually call check_builtin_array_max_size() for all parts
+  * of the interface that are arrays.
+  */
+ for (unsigned i = 0; i < num_variables; i++) {
+if (fields[i].type->is_array()) {
+   const unsigned size = fields[i].type->array_size();
+   check_builtin_array_max_size(fields[i].name, size, loc, state);
+}
+ }
+  } else {
  validate_identifier(this->instance_name, loc, state);
+  }
 
   ir_variable *var;
 
-- 
1.8.4

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

[Mesa-dev] [PATCH 2/2] glsl: Remove unused gl_PerVertex interface blocks.

[Paul Berry]

The GLSL 4.10 rules for redeclaration of built-in interface blocks
(which we've chosen to regard as clarifications of GLSL 1.50) only
require gl_PerVertex blocks to match in shaders that actually use
those blocks.  The easiest way to implement this is to detect
situations where a compiled shader doesn't refer to any elements of
gl_PerVertex, and remove all the associated ir_variables from the
shader at the end of ast-to-ir conversion.

Fixes piglit tests
linker/interstage-{pervertex,pervertex-in,pervertex-out}-redeclaration-unneeded.
---
 src/glsl/ast_to_hir.cpp | 90 +
 1 file changed, 90 insertions(+)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index c732187..73760d5 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -60,6 +60,10 @@
 static void
 detect_conflicting_assignments(struct _mesa_glsl_parse_state *state,
   exec_list *instructions);
+static void
+remove_per_vertex_blocks(exec_list *instructions,
+ _mesa_glsl_parse_state *state, ir_variable_mode mode);
+
 
 void
 _mesa_ast_to_hir(exec_list *instructions, struct _mesa_glsl_parse_state *state)
@@ -114,6 +118,40 @@ _mesa_ast_to_hir(exec_list *instructions, struct 
_mesa_glsl_parse_state *state)
   var->remove();
   instructions->push_head(var);
}
+
+   /* From section 7.1 (Built-In Language Variables) of the GLSL 4.10 spec:
+*
+* If multiple shaders using members of a built-in block belonging to
+* the same interface are linked together in the same program, they
+* must all redeclare the built-in block in the same way, as described
+* in section 4.3.7 "Interface Blocks" for interface block matching, or
+* a link error will result.
+*
+* The phrase "using members of a built-in block" implies that if two
+* shaders are linked together and one of them *does not use* any members
+* of the built-in block, then that shader does not need to have a matching
+* redeclaration of the built-in block.
+*
+* This appears to be a clarification to the behaviour established for
+* gl_PerVertex by GLSL 1.50, therefore implement it regardless of GLSL
+* version.
+*
+* The definition of "interface" in section 4.3.7 that applies here is as
+* follows:
+*
+* The boundary between adjacent programmable pipeline stages: This
+* spans all the outputs in all compilation units of the first stage
+* and all the inputs in all compilation units of the second stage.
+*
+* Therefore this rule applies to both inter- and intra-stage linking.
+*
+* The easiest way to implement this is to check whether the shader uses
+* gl_PerVertex right after ast-to-ir conversion, and if it doesn't, simply
+* remove all the relevant variable declaration from the IR, so that the
+* linker won't see them and complain about mismatches.
+*/
+   remove_per_vertex_blocks(instructions, state, ir_var_shader_in);
+   remove_per_vertex_blocks(instructions, state, ir_var_shader_out);
 }
 
 
@@ -5112,3 +5150,55 @@ detect_conflicting_assignments(struct 
_mesa_glsl_parse_state *state,
   user_defined_fs_output->name);
}
 }
+
+
+static void
+remove_per_vertex_blocks(exec_list *instructions,
+ _mesa_glsl_parse_state *state, ir_variable_mode mode)
+{
+   /* Find the gl_PerVertex interface block of the appropriate (in/out) mode,
+* if it exists in this shader type.
+*/
+   const glsl_type *per_vertex = NULL;
+   switch (mode) {
+   case ir_var_shader_in:
+  if (ir_variable *gl_in = state->symbols->get_variable("gl_in"))
+ per_vertex = gl_in->get_interface_type();
+  break;
+   case ir_var_shader_out:
+  if (ir_variable *gl_Position =
+  state->symbols->get_variable("gl_Position")) {
+ per_vertex = gl_Position->get_interface_type();
+  }
+  break;
+   default:
+  assert(!"Unexpected mode");
+  break;
+   }
+
+   /* If we didn't find a built-in gl_PerVertex interface block, then we don't
+* need to do anything.
+*/
+   if (per_vertex == NULL)
+  return;
+
+   /* If the interface block is used by the shader, then we don't need to do
+* anything.
+*/
+   interface_block_usage_visitor v(mode, per_vertex);
+   v.run(instructions);
+   if (v.usage_found())
+  return;
+
+   /* Remove any ir_variable declarations that refer to the interface block
+* we're removing.
+*/
+   foreach_list_safe(node, instructions) {
+  ir_variable *const var = ((ir_instruction *) node)->as_variable();
+  if (var != NULL && var->get_interface_type() == per_vertex &&
+  var->mode == mode) {
+ state->symbols->disable_variable(var->name);
+ var->remove();
+  }
+   }
+}
-- 
1.8.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
h

[Mesa-dev] [PATCH] glsl: Treat layout-qualifier-id's as case-insensitive in desktop GLSL.

[Paul Berry]

In desktop GLSL, location qualifiers are case-insensitive.  In GLSL
ES, they are case-sensitive.  This patch handles the difference by
using a new function to match layout qualifiers,
match_layout_qualifier(), which calls either strcmp() or strcasecmp()
as appropriate.

Fixes piglit tests:
- layout-not-case-sensitive-in.geom
- layout-not-case-sensitive-max-vert.geom
- layout-not-case-sensitive-out.geom
- layout-not-case-sensitive.frag
---
 src/glsl/glsl_parser.yy | 74 +++--
 1 file changed, 59 insertions(+), 15 deletions(-)

diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index a1d593f..ba2dc63 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -43,6 +43,32 @@ _mesa_glsl_lex(YYSTYPE *val, YYLTYPE *loc, 
_mesa_glsl_parse_state *state)
 {
return _mesa_glsl_lexer_lex(val, loc, state->scanner);
 }
+
+static bool match_layout_qualifier(const char *s1, const char *s2,
+   _mesa_glsl_parse_state *state)
+{
+   /* From the GLSL 1.50 spec, section 4.3.8 (Layout Qualifiers):
+*
+* "The tokens in any layout-qualifier-id-list ... are not case
+* sensitive, unless explicitly noted otherwise."
+*
+* The text "unless explicitly noted otherwise" appears to be
+* vacuous--no desktop GLSL spec (up through GLSL 4.40) notes
+* otherwise.
+*
+* However, the GLSL ES 3.00 spec says, in section 4.3.8 (Layout
+* Qualifiers):
+*
+* "As for other identifiers, they are case sensitive."
+*
+* So we need to do a case-sensitive or a case-insensitive match,
+* depending on whether we are compiling for GLSL ES.
+*/
+   if (state->es_shader)
+  return strcmp(s1, s2);
+   else
+  return strcasecmp(s1, s2);
+}
 %}
 
 %expect 0
@@ -1160,9 +1186,10 @@ layout_qualifier_id:
   /* Layout qualifiers for ARB_fragment_coord_conventions. */
   if (!$$.flags.i && (state->ARB_fragment_coord_conventions_enable ||
   state->is_version(150, 0))) {
- if (strcmp($1, "origin_upper_left") == 0) {
+ if (match_layout_qualifier($1, "origin_upper_left", state) == 0) {
 $$.flags.q.origin_upper_left = 1;
- } else if (strcmp($1, "pixel_center_integer") == 0) {
+ } else if (match_layout_qualifier($1, "pixel_center_integer",
+   state) == 0) {
 $$.flags.q.pixel_center_integer = 1;
  }
 
@@ -1177,13 +1204,14 @@ layout_qualifier_id:
   if (!$$.flags.i &&
   (state->AMD_conservative_depth_enable ||
state->ARB_conservative_depth_enable)) {
- if (strcmp($1, "depth_any") == 0) {
+ if (match_layout_qualifier($1, "depth_any", state) == 0) {
 $$.flags.q.depth_any = 1;
- } else if (strcmp($1, "depth_greater") == 0) {
+ } else if (match_layout_qualifier($1, "depth_greater", state) == 0) {
 $$.flags.q.depth_greater = 1;
- } else if (strcmp($1, "depth_less") == 0) {
+ } else if (match_layout_qualifier($1, "depth_less", state) == 0) {
 $$.flags.q.depth_less = 1;
- } else if (strcmp($1, "depth_unchanged") == 0) {
+ } else if (match_layout_qualifier($1, "depth_unchanged",
+   state) == 0) {
 $$.flags.q.depth_unchanged = 1;
  }
 
@@ -1201,20 +1229,32 @@ layout_qualifier_id:
 
   /* See also interface_block_layout_qualifier. */
   if (!$$.flags.i && state->has_uniform_buffer_objects()) {
- if (strcmp($1, "std140") == 0) {
+ if (match_layout_qualifier($1, "std140", state) == 0) {
 $$.flags.q.std140 = 1;
- } else if (strcmp($1, "shared") == 0) {
+ } else if (match_layout_qualifier($1, "shared", state) == 0) {
 $$.flags.q.shared = 1;
- } else if (strcmp($1, "column_major") == 0) {
+ } else if (match_layout_qualifier($1, "column_major", state) == 0) {
 $$.flags.q.column_major = 1;
  /* "row_major" is a reserved word in GLSL 1.30+. Its token is parsed
   * below in the interface_block_layout_qualifier rule.
   *
   * It is not a reserved word in GLSL ES 3.00, so it's handled here as
   * an identifier.
+  *
+  * Also, this takes care of alternate capitalizations of
+  * "row_major" (which is necessary because layout qualifiers
+  * are case-insensitive in desktop GLSL).
   */
- } else if (strcmp($1, "row_major") == 0) {
+ } else if (match_layout_qualifier($1, "row_major", state) == 0) {
 $$.flags.q.row_major = 1;
+ /* "packed" is a reserved word in GLSL, and its token is
+  * parsed below in the interface_block_layout_qualifier rule.
+  * However, we must take care of alternate capitalizations of
+  * "packed", because layout qualifiers are case-insensiti

[Mesa-dev] [RFC PATCH] glsl: Allow mixing of GLSL 1.40 and later shader versions.

[Paul Berry]

---

I'm not 100% sure this is the right way to go, and here's why:

Taken together, all the GLSL specs except GLSL 4.30 and GLSL 4.40 tell
a consistent story: desktop shader versions 1.10 and 1.20 may be
linked together, and desktop shader versions 1.40 and above may be
linked together.  No other cross-version linking is allowed.

However, cross-version linking restrictions were explicitly removed in
GLSL 4.30 (the change is listed under "Summary of Changes from Version
4.20 as "Remove cross-version linking restrictions.").  GLSL 4.30 and
4.40 state that *any* version of desktop GLSL may be linked with any
other version of desktop GLSL.  (Note that cross-version linking is
still prohibited for ES shaders).

This leads to a conundrum.  Normally when the GLSL spec changes from
one version to the next, we implement different rules depending on the
user-supplied "#version" directive.  But we can't do that for
cross-version linking rules since it's not clear which version of GLSL
should apply.  Should we:

(a) always follow pre-GLSL 4.30 linking rules, since we don't support
GLSL 4.30 yet?  (that's what this patch implements).

(b) always follow post-GLSL 4.30 linking rules, since they're probably
the clearest reflection of the Khronos board's intent?

(c) make some kind of dynamic determination of which set of rules to
follow?

FWIW, the NVIDIA proprietary driver for Linux (version 313.18) appears
to implement (b).

 src/glsl/linker.cpp | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 9095a40..1dac85c 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2057,17 +2057,29 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
   }
}
 
-   /* Previous to GLSL version 1.30, different compilation units could mix and
-* match shading language versions.  With GLSL 1.30 and later, the versions
-* of all shaders must match.
+   /* For desktop GLSL, versions 1.10 and 1.20 may be linked together, and
+* versions 1.40 and later may be linked together.  But version 1.30 may
+* not be linked with any other version, and versions prior to 1.30 may not
+* be linked to versions after 1.30.
 *
 * GLSL ES has never allowed mixing of shading language versions.
 */
-   if ((is_es_prog || max_version >= 130)
-   && min_version != max_version) {
-  linker_error(prog, "all shaders must use same shading "
-  "language version\n");
-  goto done;
+   if (is_es_prog) {
+  if (min_version != max_version) {
+ linker_error(prog, "all shaders must use same shading "
+  "language version\n");
+ goto done;
+  }
+   } else {
+  if (min_version < 130 && max_version >= 130) {
+ linker_error(prog, "GLSL versions prior to 1.30 may not be linked "
+  "with GLSL versions 1.30 and above\n");
+ goto done;
+  } else if (min_version == 130 && max_version > 130) {
+ linker_error(prog, "GLSL version 1.30 may not be linked with GLSL "
+  "versions above 1.30\n");
+ goto done;
+  }
}
 
prog->Version = max_version;
-- 
1.8.4.1

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

[Mesa-dev] [PATCH] mesa: Fix geometry shader program queries.

[Paul Berry]

The queries GEOMETRY_VERTICES_OUT, GEOMETRY_INPUT_TYPE, and
GEOMETRY_OUTPUT_TYPE (defined by GL 3.2) differ from the corresponding
queries in ARB_geometry_shader4 in the following ways:

- They use different enum values

- They can only be queried; they cannot be set.

- Attempting to query them yields INVALID_OPERATION if the program is
  not linked, or lacks a geometry shader.

This patch switches us over from the ARB_geometry_shader4 behaviour to
the GL 3.2 behaviour.

Fixes piglit test query-gs-prim-types.
---
 src/mesa/main/shaderapi.c | 100 +++---
 1 file changed, 40 insertions(+), 60 deletions(-)

diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index d3677c8..8be1f78 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -460,6 +460,31 @@ get_handle(struct gl_context *ctx, GLenum pname)
 
 
 /**
+ * Check if a geometry shader query is valid at this time.  If not, report an
+ * error and return false.
+ *
+ * From GL 3.2 section 6.1.16 (Shader and Program Queries):
+ *
+ * "If GEOMETRY_VERTICES_OUT, GEOMETRY_INPUT_TYPE, or GEOMETRY_OUTPUT_TYPE
+ * are queried for a program which has not been linked successfully, or
+ * which does not contain objects to form a geometry shader, then an
+ * INVALID_OPERATION error is generated."
+ */
+static bool
+check_gs_query(struct gl_context *ctx, const struct gl_shader_program *shProg)
+{
+   if (shProg->LinkStatus &&
+   shProg->_LinkedShaders[MESA_SHADER_GEOMETRY] != NULL) {
+  return true;
+   }
+
+   _mesa_error(ctx, GL_INVALID_OPERATION,
+   "glGetProgramv(linked geometry shader required)");
+   return false;
+}
+
+
+/**
  * glGetProgramiv() - get shader program state.
  * Note that this is for GLSL shader programs, not ARB vertex/fragment
  * programs (see glGetProgramivARB).
@@ -477,9 +502,10 @@ get_programiv(struct gl_context *ctx, GLuint program, 
GLenum pname, GLint *param
   || ctx->API == API_OPENGL_CORE
   || _mesa_is_gles3(ctx);
 
-   /* Are geometry shaders available in this context?
+   /* Are geometry shaders (of the form that was adopted into GLSL 1.50 and GL
+* 3.2) available in this context?
 */
-   const bool has_gs = _mesa_has_geometry_shaders(ctx);
+   const bool has_core_gs = _mesa_is_desktop_gl(ctx) && ctx->Version >= 32;
 
/* Are uniform buffer objects available in this context?
 */
@@ -564,20 +590,23 @@ get_programiv(struct gl_context *ctx, GLuint program, 
GLenum pname, GLint *param
  break;
   *params = shProg->TransformFeedback.BufferMode;
   return;
-   case GL_GEOMETRY_VERTICES_OUT_ARB:
-  if (!has_gs)
+   case GL_GEOMETRY_VERTICES_OUT:
+  if (!has_core_gs)
  break;
-  *params = shProg->Geom.VerticesOut;
+  if (check_gs_query(ctx, shProg))
+ *params = shProg->Geom.VerticesOut;
   return;
-   case GL_GEOMETRY_INPUT_TYPE_ARB:
-  if (!has_gs)
+   case GL_GEOMETRY_INPUT_TYPE:
+  if (!has_core_gs)
  break;
-  *params = shProg->Geom.InputType;
+  if (check_gs_query(ctx, shProg))
+ *params = shProg->Geom.InputType;
   return;
-   case GL_GEOMETRY_OUTPUT_TYPE_ARB:
-  if (!has_gs)
+   case GL_GEOMETRY_OUTPUT_TYPE:
+  if (!has_core_gs)
  break;
-  *params = shProg->Geom.OutputType;
+  if (check_gs_query(ctx, shProg))
+ *params = shProg->Geom.OutputType;
   return;
case GL_ACTIVE_UNIFORM_BLOCK_MAX_NAME_LENGTH: {
   unsigned i;
@@ -1631,55 +1660,6 @@ _mesa_ProgramParameteri(GLuint program, GLenum pname, 
GLint value)
   return;
 
switch (pname) {
-   case GL_GEOMETRY_VERTICES_OUT_ARB:
-  if (!_mesa_is_desktop_gl(ctx) || !ctx->Extensions.ARB_geometry_shader4)
- break;
-
-  if (value < 0 ||
-  (unsigned) value > ctx->Const.MaxGeometryOutputVertices) {
- _mesa_error(ctx, GL_INVALID_VALUE,
- "glProgramParameteri(GL_GEOMETRY_VERTICES_OUT_ARB=%d)",
- value);
- return;
-  }
-  shProg->Geom.VerticesOut = value;
-  return;
-   case GL_GEOMETRY_INPUT_TYPE_ARB:
-  if (!_mesa_is_desktop_gl(ctx) || !ctx->Extensions.ARB_geometry_shader4)
- break;
-
-  switch (value) {
-  case GL_POINTS:
-  case GL_LINES:
-  case GL_LINES_ADJACENCY_ARB:
-  case GL_TRIANGLES:
-  case GL_TRIANGLES_ADJACENCY_ARB:
- shProg->Geom.InputType = value;
- break;
-  default:
- _mesa_error(ctx, GL_INVALID_VALUE,
- "glProgramParameteri(geometry input type = %s)",
- _mesa_lookup_enum_by_nr(value));
- return;
-  }
-  return;
-   case GL_GEOMETRY_OUTPUT_TYPE_ARB:
-  if (!_mesa_is_desktop_gl(ctx) || !ctx->Extensions.ARB_geometry_shader4)
- break;
-
-  switch (value) {
-  case GL_POINTS:
-  case GL_LINE_STRIP:
-  case GL_TRIANGLE_STRIP:
- shProg->Geom.OutputType = value;
- 

Re: [Mesa-dev] [RFC PATCH] glsl: Allow mixing of GLSL 1.40 and later shader versions.

[Paul Berry]

On 16 October 2013 16:56, Ian Romanick  wrote:

> On 10/16/2013 10:29 AM, Paul Berry wrote:
> > ---
> >
> > I'm not 100% sure this is the right way to go, and here's why:
> >
> > Taken together, all the GLSL specs except GLSL 4.30 and GLSL 4.40 tell
> > a consistent story: desktop shader versions 1.10 and 1.20 may be
> > linked together, and desktop shader versions 1.40 and above may be
> > linked together.  No other cross-version linking is allowed.
> >
> > However, cross-version linking restrictions were explicitly removed in
> > GLSL 4.30 (the change is listed under "Summary of Changes from Version
> > 4.20 as "Remove cross-version linking restrictions.").  GLSL 4.30 and
> > 4.40 state that *any* version of desktop GLSL may be linked with any
> > other version of desktop GLSL.  (Note that cross-version linking is
> > still prohibited for ES shaders).
>
> This came from a Khronos bug that I submitted.  The problem is that no
> other driver enforces the spec mandated restriction.  On top of that,
> you can't fully enforce the restriction (without draw-time errors) with
> separate shader objects.  I *thought* the change in 4.3 was to allow
> mixed versions between stages, but mixing versions within a stage is
> still forbidden.
>

Looking at the specs, it appears that they removed the restriction for both
intra- and inter-stage linking.


>
> > This leads to a conundrum.  Normally when the GLSL spec changes from
> > one version to the next, we implement different rules depending on the
> > user-supplied "#version" directive.  But we can't do that for
> > cross-version linking rules since it's not clear which version of GLSL
> > should apply.  Should we:
> >
> > (a) always follow pre-GLSL 4.30 linking rules, since we don't support
> > GLSL 4.30 yet?  (that's what this patch implements).
> >
> > (b) always follow post-GLSL 4.30 linking rules, since they're probably
> > the clearest reflection of the Khronos board's intent?
> >
> > (c) make some kind of dynamic determination of which set of rules to
> > follow?
> >
> > FWIW, the NVIDIA proprietary driver for Linux (version 313.18) appears
> > to implement (b).
>
> There are different cases: intrastage and interstage.  I assume they
> allow mixing interstage.  What about intrastage?
>

That's a good point--when I tested this the other day, I only tested
interstage.

I've just checked intrastage linking and I see the same behaviour: any
version can be linked with any other version.


>
> >  src/glsl/linker.cpp | 28 
> >  1 file changed, 20 insertions(+), 8 deletions(-)
> >
> > diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> > index 9095a40..1dac85c 100644
> > --- a/src/glsl/linker.cpp
> > +++ b/src/glsl/linker.cpp
> > @@ -2057,17 +2057,29 @@ link_shaders(struct gl_context *ctx, struct
> gl_shader_program *prog)
> >}
> > }
> >
> > -   /* Previous to GLSL version 1.30, different compilation units could
> mix and
> > -* match shading language versions.  With GLSL 1.30 and later, the
> versions
> > -* of all shaders must match.
> > +   /* For desktop GLSL, versions 1.10 and 1.20 may be linked together,
> and
> > +* versions 1.40 and later may be linked together.  But version 1.30
> may
> > +* not be linked with any other version, and versions prior to 1.30
> may not
> > +* be linked to versions after 1.30.
> >  *
> >  * GLSL ES has never allowed mixing of shading language versions.
> >  */
> > -   if ((is_es_prog || max_version >= 130)
> > -   && min_version != max_version) {
> > -  linker_error(prog, "all shaders must use same shading "
> > -"language version\n");
> > -  goto done;
> > +   if (is_es_prog) {
> > +  if (min_version != max_version) {
> > + linker_error(prog, "all shaders must use same shading "
> > +  "language version\n");
> > + goto done;
> > +  }
> > +   } else {
> > +  if (min_version < 130 && max_version >= 130) {
> > + linker_error(prog, "GLSL versions prior to 1.30 may not be
> linked "
> > +  "with GLSL versions 1.30 and above\n");
> > + goto done;
> > +  } else if (min_version == 130 && max_version > 130) {
> > + linker_error(prog, "GLSL version 1.30 may not be linked with
> GLSL "
> > +  "versions above 1.30\n");
> > + goto done;
> > +  }
> > }
> >
> > prog->Version = max_version;
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Fix geometry shader program queries.

[Paul Berry]

On 16 October 2013 23:29, Pohjolainen, Topi wrote:

> On Wed, Oct 16, 2013 at 11:13:33AM -0700, Paul Berry wrote:
> > The queries GEOMETRY_VERTICES_OUT, GEOMETRY_INPUT_TYPE, and
> > GEOMETRY_OUTPUT_TYPE (defined by GL 3.2) differ from the corresponding
> > queries in ARB_geometry_shader4 in the following ways:
> >
> > - They use different enum values
> >
> > - They can only be queried; they cannot be set.
> >
> > - Attempting to query them yields INVALID_OPERATION if the program is
> >   not linked, or lacks a geometry shader.
> >
> > This patch switches us over from the ARB_geometry_shader4 behaviour to
> > the GL 3.2 behaviour.
> >
> > Fixes piglit test query-gs-prim-types.
> > ---
> >  src/mesa/main/shaderapi.c | 100
> +++---
> >  1 file changed, 40 insertions(+), 60 deletions(-)
> >
> > diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> > index d3677c8..8be1f78 100644
> > --- a/src/mesa/main/shaderapi.c
> > +++ b/src/mesa/main/shaderapi.c
> > @@ -460,6 +460,31 @@ get_handle(struct gl_context *ctx, GLenum pname)
> >
> >
> >  /**
> > + * Check if a geometry shader query is valid at this time.  If not,
> report an
> > + * error and return false.
> > + *
> > + * From GL 3.2 section 6.1.16 (Shader and Program Queries):
> > + *
> > + * "If GEOMETRY_VERTICES_OUT, GEOMETRY_INPUT_TYPE, or
> GEOMETRY_OUTPUT_TYPE
> > + * are queried for a program which has not been linked
> successfully, or
> > + * which does not contain objects to form a geometry shader, then an
> > + * INVALID_OPERATION error is generated."
> > + */
> > +static bool
> > +check_gs_query(struct gl_context *ctx, const struct gl_shader_program
> *shProg)
> > +{
> > +   if (shProg->LinkStatus &&
> > +   shProg->_LinkedShaders[MESA_SHADER_GEOMETRY] != NULL) {
> > +  return true;
> > +   }
> > +
> > +   _mesa_error(ctx, GL_INVALID_OPERATION,
> > +   "glGetProgramv(linked geometry shader required)");
> > +   return false;
> > +}
> > +
> > +
> > +/**
> >   * glGetProgramiv() - get shader program state.
> >   * Note that this is for GLSL shader programs, not ARB vertex/fragment
> >   * programs (see glGetProgramivARB).
> > @@ -477,9 +502,10 @@ get_programiv(struct gl_context *ctx, GLuint
> program, GLenum pname, GLint *param
> >|| ctx->API == API_OPENGL_CORE
> >|| _mesa_is_gles3(ctx);
> >
> > -   /* Are geometry shaders available in this context?
> > +   /* Are geometry shaders (of the form that was adopted into GLSL 1.50
> and GL
> > +* 3.2) available in this context?
>
> I had to check just for my own understanding. The question here is not
> implying
> that there is still doubt by the author that something else should be
> checked
> along with version 3.2. Instead it is meant to be understood the same as
> "Check
> if geometry shaders (...) are available...", similarly as in case of
> 'check_gs_query()' above, right?
>

Yeah.  I agree that phrasing the comment in the form of a question is a
little misleading here.  How about if I said this instead?

/* True if geometry shaders (of the form that was adopted into GLSL 1.50
and GL 3.2) are available in this context */


> >  */
> > -   const bool has_gs = _mesa_has_geometry_shaders(ctx);
> > +   const bool has_core_gs = _mesa_is_desktop_gl(ctx) && ctx->Version >=
> 32;
> >
> > /* Are uniform buffer objects available in this context?
> >  */
> > @@ -564,20 +590,23 @@ get_programiv(struct gl_context *ctx, GLuint
> program, GLenum pname, GLint *param
> >   break;
> >*params = shProg->TransformFeedback.BufferMode;
> >return;
> > -   case GL_GEOMETRY_VERTICES_OUT_ARB:
> > -  if (!has_gs)
> > +   case GL_GEOMETRY_VERTICES_OUT:
> > +  if (!has_core_gs)
> >   break;
> > -  *params = shProg->Geom.VerticesOut;
> > +  if (check_gs_query(ctx, shProg))
> > + *params = shProg->Geom.VerticesOut;
> >return;
> > -   case GL_GEOMETRY_INPUT_TYPE_ARB:
> > -  if (!has_gs)
> > +   case GL_GEOMETRY_INPUT_TYPE:
> > +  if (!has_core_gs)
> >   break;
> > -  *params = shProg->Geom.InputType;
> > +  if (check_gs_query(ctx, shProg))
> > + *params = shProg->Geom.InputType;
> >return;
> > -   case GL_GEOMET

[Mesa-dev] [PATCH 1/8] i965/vec4: Add the ability for attributes to be interleaved.

[Paul Berry]

When geometry shaders are operated in "single" or "dual instanced"
mode, a single set of geometry shader inputs is interleaved into the
thread payload (with each payload register containing a pair of
inputs) in order to save register space.

This patch modifies vec4_visitor::lower_attributes_to_hw_regs so that
it can handle the interleaved format.
---
 src/mesa/drivers/dri/i965/brw_vec4.cpp| 28 +++
 src/mesa/drivers/dri/i965/brw_vec4.h  |  3 ++-
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp |  2 +-
 3 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index d3ee9a1..d774e6f 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1184,12 +1184,32 @@ vec4_visitor::dump_instruction(backend_instruction 
*be_inst)
printf("\n");
 }
 
+
+static inline struct brw_reg
+attribute_to_hw_reg(int attr, bool interleaved)
+{
+   if (interleaved)
+  return stride(brw_vec4_grf(attr / 2, (attr % 2) * 4), 0, 4, 1);
+   else
+  return brw_vec8_grf(attr, 0);
+}
+
+
 /**
  * Replace each register of type ATTR in this->instructions with a reference
  * to a fixed HW register.
+ *
+ * If interleaved is true, then each attribute takes up half a register, with
+ * register N containing attribute 2*N in its first half and attribute 2*N+1
+ * in its second half (this corresponds to the payload setup used by geometry
+ * shaders in "single" or "dual instanced" dispatch mode).  If interleaved is
+ * false, then each attribute takes up a whole register, with register N
+ * containing attribute N (this corresponds to the payload setup used by
+ * vertex shaders, and by geometry shaders in "dual object" dispatch mode).
  */
 void
-vec4_visitor::lower_attributes_to_hw_regs(const int *attribute_map)
+vec4_visitor::lower_attributes_to_hw_regs(const int *attribute_map,
+  bool interleaved)
 {
foreach_list(node, &this->instructions) {
   vec4_instruction *inst = (vec4_instruction *)node;
@@ -1203,7 +1223,7 @@ vec4_visitor::lower_attributes_to_hw_regs(const int 
*attribute_map)
   */
  assert(grf != 0);
 
-struct brw_reg reg = brw_vec8_grf(grf, 0);
+struct brw_reg reg = attribute_to_hw_reg(grf, interleaved);
 reg.type = inst->dst.type;
 reg.dw1.bits.writemask = inst->dst.writemask;
 
@@ -1222,7 +1242,7 @@ vec4_visitor::lower_attributes_to_hw_regs(const int 
*attribute_map)
   */
  assert(grf != 0);
 
-struct brw_reg reg = brw_vec8_grf(grf, 0);
+struct brw_reg reg = attribute_to_hw_reg(grf, interleaved);
 reg.dw1.bits.swizzle = inst->src[i].swizzle;
  reg.type = inst->src[i].type;
 if (inst->src[i].abs)
@@ -1260,7 +1280,7 @@ vec4_vs_visitor::setup_attributes(int payload_reg)
   nr_attributes++;
}
 
-   lower_attributes_to_hw_regs(attribute_map);
+   lower_attributes_to_hw_regs(attribute_map, false /* interleaved */);
 
/* The BSpec says we always have to read at least one thing from
 * the VF, and it appears that the hardware wedges otherwise.
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 41d91e5..f99fdfa 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -517,7 +517,8 @@ public:
 
 protected:
void emit_vertex();
-   void lower_attributes_to_hw_regs(const int *attribute_map);
+   void lower_attributes_to_hw_regs(const int *attribute_map,
+bool interleaved);
void setup_payload_interference(struct ra_graph *g, int first_payload_node,
int reg_node_count);
virtual dst_reg *make_reg_for_system_value(ir_variable *ir) = 0;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 50feb89..bd13082 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -110,7 +110,7 @@ vec4_gs_visitor::setup_payload()
 
reg = setup_varying_inputs(reg, attribute_map);
 
-   lower_attributes_to_hw_regs(attribute_map);
+   lower_attributes_to_hw_regs(attribute_map, false /* interleaved */);
 
this->first_non_payload_grf = reg;
 }
-- 
1.8.4.1

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

[Mesa-dev] [PATCH 0/8] i965/gs: Use DUAL_INSTANCED mode to ease register pressure.

[Paul Berry]

Previously, i965 geometry shaders always operated in DUAL_OBJECT mode,
which is similar to vertex shader operation in that two independent
sets of inputs get dispatched to a single SIMD4x2 geometry shader
thread, which executes them both in parallel.

When register usage is tight, we need to switch to a mechanism that
uses fewer registers.  In an ideal world we'd fall back to SINGLE
mode, in which a single set of inputs is dispatched to a SIMD4x1
geometry shader thread.  Effectively this makes twice as many
registers available, since it allows independent data to be
interleaved into the lower and upper halves of each register.

Unfortunately, we don't yet have the infrastructure in the vec4
back-end to support interleaving all the registers.  So we do the next
best thing, which is to use DUAL_INSTANCED dispatch mode.  In this
mode, a single set of geometry shader inputs is delivered to the
shader in interleaved fashion (as would happen in SINGLE mode), but
the shader operates as a SIMD4x2 shader (so all other registers are
non-interleaved).  If the geometry shader is instanced, then up to two
instances may be dispatched to the geometry shader at once; otherwise,
each geometry shader invocation runs in its own thread, with the
execution mask set appropriately.  Since we don't support instanced
geometry shaders yet, DUAL_INSTANCED and SINGLE modes are for all
intents and purposes equivalent, except that we don't have to do as
much back-end register interleaving work.

The compilation strategy for choosing between DUAL_INSTANCED and
DUAL_OBJECT modes is similar to what we do for 8-wide vs. 16-wide
fragment shaders.  First we try compiling the shader in DUAL_OBJECT
mode with register spilling disabled.  If that fails, we fall back to
DUAL_INSTANCED mode and compile with register spilling enabled.

Unfortunately, even when using DUAL_INSTANCED mode we still can't
support 128 geometry shader input components, due to other limitations
in our vec4 back-end code.  So the final patch of the series reduces
gl_MaxGeometryInputComponents to 64, the minimum required by the spec.

This series needs to be applied atop "vbo: Make
vbo_sw_primitive_restart optionally count primitives." and "i965/gs:
Fix gl_PrimitiveIDIn when using SW primitive restart.", which are on
the mailing list but haven't been reviewed yet.  To see the series in
context, please check out branch "gs-phase-6" from
https://github.com/stereotype441/mesa.git.

[PATCH 1/8] i965/vec4: Add the ability for attributes to be interleaved.
[PATCH 2/8] i965/vec4: if register allocation fails, don't try to schedule.
[PATCH 3/8] i965/vec4: Add the ability to suppress register spilling.
[PATCH 4/8] i965/gs: Add the ability to compile a DUAL_INSTANCED geometry 
shader.
[PATCH 5/8] i965/gs: Fix up gl_PointSize input swizzling for DUAL_INSTANCED gs.
[PATCH 6/8] i965/gs: fix up primitive ID workaround for DUAL_INSTANCE dispatch.
[PATCH 7/8] i965/gs: If a DUAL_OBJECT gs would spill, fall back to 
DUAL_INSTANCED.
[PATCH 8/8] i965: Reduce gl_MaxGeometryInputComponents to 64.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/8] i965/vec4: Add the ability to suppress register spilling.

[Paul Berry]

In future patches, this will allow us to first try compiling a
geometry shader in DUAL_OBJECT mode (which is more efficient but uses
more registers) and then if spilling is required, fall back on
DUAL_INSTANCED mode.
---
 src/mesa/drivers/dri/i965/brw_vec4.h  | 9 -
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 7 ---
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h   | 3 ++-
 src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp   | 5 -
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp| 5 +++--
 src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp | 2 +-
 src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp | 2 +-
 7 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index f99fdfa..fc8804f 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -232,7 +232,8 @@ public:
struct gl_shader_program *shader_prog,
struct brw_shader *shader,
void *mem_ctx,
-bool debug_flag);
+bool debug_flag,
+bool no_spills);
~vec4_visitor();
 
dst_reg dst_null_f()
@@ -531,6 +532,12 @@ protected:
virtual int compute_array_stride(ir_dereference_array *ir);
 
const bool debug_flag;
+
+private:
+   /**
+* If true, then register allocation should fail instead of spilling.
+*/
+   const bool no_spills;
 };
 
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index bd13082..8d8f20e 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -37,10 +37,11 @@ vec4_gs_visitor::vec4_gs_visitor(struct brw_context *brw,
  struct brw_gs_compile *c,
  struct gl_shader_program *prog,
  struct brw_shader *shader,
- void *mem_ctx)
+ void *mem_ctx,
+ bool no_spills)
: vec4_visitor(brw, &c->base, &c->gp->program.Base, &c->key.base,
   &c->prog_data.base, prog, shader, mem_ctx,
-  INTEL_DEBUG & DEBUG_GS),
+  INTEL_DEBUG & DEBUG_GS, no_spills),
  c(c)
 {
 }
@@ -562,7 +563,7 @@ brw_gs_emit(struct brw_context *brw,
   printf("\n\n");
}
 
-   vec4_gs_visitor v(brw, c, prog, shader, mem_ctx);
+   vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, false /* no_spills */);
if (!v.run()) {
   prog->LinkStatus = false;
   ralloc_strcat(&prog->InfoLog, v.fail_msg);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h
index bdcb415..f7ca5f0 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h
@@ -81,7 +81,8 @@ public:
struct brw_gs_compile *c,
struct gl_shader_program *prog,
struct brw_shader *shader,
-   void *mem_ctx);
+   void *mem_ctx,
+   bool no_spills);
 
 protected:
virtual dst_reg *make_reg_for_system_value(ir_variable *ir);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
index 3777027..807c2f3 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
@@ -214,7 +214,10 @@ vec4_visitor::reg_allocate()
* loop back into here to try again.
*/
   int reg = choose_spill_reg(g);
-  if (reg == -1) {
+  if (this->no_spills) {
+ fail("Failure to register allocate.  Reduce number of live "
+  "values to avoid this.");
+  } else if (reg == -1) {
  fail("no register to spill\n");
   } else {
  spill_reg(reg);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 231815f..ecc6fe6 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -3143,8 +3143,9 @@ vec4_visitor::vec4_visitor(struct brw_context *brw,
   struct gl_shader_program *shader_prog,
   struct brw_shader *shader,
   void *mem_ctx,
-   bool debug_flag)
-   : debug_flag(debug_flag)
+   bool debug_flag,
+   bool no_spills)
+   : debug_flag(debug_flag), no_spills(no_spills)
 {
this->brw = brw;
this->ctx = &brw->ctx;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
index 1f5cc25..31c42c4 100644
--- a/src/mesa/drivers/dri/i965/brw_v

[Mesa-dev] [PATCH 2/8] i965/vec4: if register allocation fails, don't try to schedule.

[Paul Berry]

Otherwise the scheduler would be invoked with prog_data->total_grf ==
0, causing havoc.

In a future patch, this will allow us to try compiling a geometry
shader in DUAL_OBJECT mode with spilling disabled, and then fall back
to DUAL_INSTANCED mode if that failed.
---
 src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index d774e6f..89f1978 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1520,7 +1520,7 @@ vec4_visitor::run()
 
while (!reg_allocate()) {
   if (failed)
- break;
+ return false;
}
 
opt_schedule_instructions();
-- 
1.8.4.1

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

[Mesa-dev] [PATCH 4/8] i965/gs: Add the ability to compile a DUAL_INSTANCED geometry shader.

[Paul Berry]

Not yet enabled.
---
 src/mesa/drivers/dri/i965/brw_context.h   |  6 ++
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 25 +--
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h   |  3 ++-
 src/mesa/drivers/dri/i965/gen7_gs_state.c |  4 +++-
 4 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index cafcf5c..6a14c7f 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -642,6 +642,12 @@ struct brw_gs_prog_data
 
bool include_primitive_id;
bool need_primitive_id_workaround;
+
+   /**
+* True if the thread should be dispatched in DUAL_INSTANCE mode, false if
+* it should be dispatched in DUAL_OBJECT mode.
+*/
+   bool dual_instanced_dispatch;
 };
 
 /** Number of texture sampler units */
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 8d8f20e..2be2666 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -57,7 +57,8 @@ vec4_gs_visitor::make_reg_for_system_value(ir_variable *ir)
 
 
 int
-vec4_gs_visitor::setup_varying_inputs(int payload_reg, int *attribute_map)
+vec4_gs_visitor::setup_varying_inputs(int payload_reg, int *attribute_map,
+  int attributes_per_reg)
 {
/* For geometry shaders there are N copies of the input attributes, where N
 * is the number of input vertices.  attribute_map[BRW_VARYING_SLOT_COUNT *
@@ -75,11 +76,14 @@ vec4_gs_visitor::setup_varying_inputs(int payload_reg, int 
*attribute_map)
   int varying = c->input_vue_map.slot_to_varying[slot];
   for (unsigned vertex = 0; vertex < num_input_vertices; vertex++) {
  attribute_map[BRW_VARYING_SLOT_COUNT * vertex + varying] =
-payload_reg + input_array_stride * vertex + slot;
+attributes_per_reg * payload_reg + input_array_stride * vertex +
+slot;
   }
}
 
-   return payload_reg + input_array_stride * num_input_vertices;
+   int regs_used = ALIGN(input_array_stride * num_input_vertices,
+ attributes_per_reg) / attributes_per_reg;
+   return payload_reg + regs_used;
 }
 
 
@@ -88,6 +92,11 @@ vec4_gs_visitor::setup_payload()
 {
int attribute_map[BRW_VARYING_SLOT_COUNT * MAX_GS_INPUT_VERTICES];
 
+   /* If we are in dual instanced mode, then attributes are going to be
+* interleaved, so one register contains two attribute slots.
+*/
+   int attributes_per_reg = c->prog_data.dual_instanced_dispatch ? 2 : 1;
+
/* If a geometry shader tries to read from an input that wasn't written by
 * the vertex shader, that produces undefined results, but it shouldn't
 * crash anything.  So initialize attribute_map to zeros--that ensures that
@@ -105,13 +114,14 @@ vec4_gs_visitor::setup_payload()
 
/* If the shader uses gl_PrimitiveIDIn, that goes in r1. */
if (c->prog_data.include_primitive_id)
-  attribute_map[VARYING_SLOT_PRIMITIVE_ID] = reg++;
+  attribute_map[VARYING_SLOT_PRIMITIVE_ID] = attributes_per_reg * reg++;
 
reg = setup_uniforms(reg);
 
-   reg = setup_varying_inputs(reg, attribute_map);
+   reg = setup_varying_inputs(reg, attribute_map, attributes_per_reg);
 
-   lower_attributes_to_hw_regs(attribute_map, false /* interleaved */);
+   lower_attributes_to_hw_regs(attribute_map,
+   c->prog_data.dual_instanced_dispatch);
 
this->first_non_payload_grf = reg;
 }
@@ -563,6 +573,9 @@ brw_gs_emit(struct brw_context *brw,
   printf("\n\n");
}
 
+   /* Assume the geometry shader will use DUAL_OBJECT dispatch for now. */
+   c->prog_data.dual_instanced_dispatch = false;
+
vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, false /* no_spills */);
if (!v.run()) {
   prog->LinkStatus = false;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h
index f7ca5f0..da4adcd 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.h
@@ -97,7 +97,8 @@ protected:
virtual void visit(ir_end_primitive *);
 
 private:
-   int setup_varying_inputs(int payload_reg, int *attribute_map);
+   int setup_varying_inputs(int payload_reg, int *attribute_map,
+int attributes_per_reg);
void emit_control_data_bits();
void primitive_id_workaround();
 
diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c 
b/src/mesa/drivers/dri/i965/gen7_gs_state.c
index c272b7d..2602200 100644
--- a/src/mesa/drivers/dri/i965/gen7_gs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_gs_state.c
@@ -136,7 +136,9 @@ upload_gs_state(struct brw_context *brw)
  ((brw->max_gs_threads - 1) << max_threads_shift) |
  (brw->gs.prog_data->control_data_header_size_hwords <<
   GEN7_GS

[Mesa-dev] [PATCH 5/8] i965/gs: Fix up gl_PointSize input swizzling for DUAL_INSTANCED gs.

[Paul Berry]

Geometry shaders that run in "DUAL_INSTANCED" mode store their inputs
in vec4's.  This means that when compiling gl_PointSize input
swizzling (a MOV instruction which uses a geometry shader input as
both source and destination), we need to do two things:

- Set force_writemask_all to ensure that the MOV happens regardless of
  which channels are enabled.

- Set the source register region to <4;4,1> (instead of <0;4,1> to
  satisfy register region restrictions.
---
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp  | 17 -
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp |  8 +++-
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index 1b597b5..700da54 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -858,7 +858,22 @@ vec4_generator::generate_vec4_instruction(vec4_instruction 
*instruction,
 
switch (inst->opcode) {
case BRW_OPCODE_MOV:
-  brw_MOV(p, dst, src[0]);
+  if (dst.width == BRW_WIDTH_4) {
+ /* This happens in attribute fixups for "dual instanced" geometry
+  * shaders, since they use attributes that are vec4's.  Since the
+  * exec width is only 4, it's essential that the caller set
+  * force_writemask_all in order to make sure the MOV happens
+  * regardless of which channels are enabled.
+  */
+ assert(inst->force_writemask_all);
+
+ /* To satisfy register region restrictions, the source needs a stride
+  * of <4;4,1>.
+  */
+ brw_MOV(p, dst, stride(src[0], 4, 4, 1));
+  } else {
+ brw_MOV(p, dst, src[0]);
+  }
   break;
case BRW_OPCODE_ADD:
   brw_ADD(p, dst, src[0], src[1]);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 2be2666..5b823c4 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -210,7 +210,13 @@ vec4_gs_visitor::emit_prolog()
  src_reg src(dst);
  dst.writemask = WRITEMASK_X;
  src.swizzle = BRW_SWIZZLE_;
- emit(MOV(dst, src));
+ inst = emit(MOV(dst, src));
+
+ /* In dual instanced dispatch mode, dst has a width of 4, so we need
+  * to make sure the MOV happens regardless of which channels are
+  * enabled.
+  */
+ inst->force_writemask_all = true;
   }
}
 
-- 
1.8.4.1

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

[Mesa-dev] [PATCH 7/8] i965/gs: If a DUAL_OBJECT gs would spill, fall back to DUAL_INSTANCED.

[Paul Berry]

This is similar to what we do for 16-wide vs 8-wide fragment shaders.
First we try compiling the geometry shader in DUAL_OBJECT mode.  If we
can't do that without spilling, we fall back on DUAL_INSTANCED mode,
which should require less spilling (since it uses an interleaved
layout of payload registers).

In an ideal world we'd fall back to SINGLE mode, which would allow us
to interleave general-purpose registers too (resulting in even less
likelihood of spilling).  But at the moment, the vec4 generator and
visitor classes don't have the infrastructure to interleave general
purpose registers, so DUAL_INSTANCED is the best we can do.

As a side benefit this paves the way for implementing instanced
geometry shaders (which are incompatible with DUAL_OBJECT mode).

Since most geometry shaders used in piglit testing are small,
DUAL_INSTANCED mode won't get exercised very much in a normal piglit
run.  To force DUAL_INSTANCED mode to be used for all geometry
shaders, set INTEL_DEBUG=nogualobj.
---
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 30 +--
 src/mesa/drivers/dri/i965/intel_debug.c   |  1 +
 src/mesa/drivers/dri/i965/intel_debug.h   |  1 +
 3 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 76209b0..68f11ed 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -587,8 +587,34 @@ brw_gs_emit(struct brw_context *brw,
   printf("\n\n");
}
 
-   /* Assume the geometry shader will use DUAL_OBJECT dispatch for now. */
-   c->prog_data.dual_instanced_dispatch = false;
+   /* Compile the geometry shader in DUAL_OBJECT dispatch mode, if we can do
+* so without spilling.
+*/
+   if (likely(!(INTEL_DEBUG & DEBUG_NO_DUAL_OBJECT_GS))) {
+  c->prog_data.dual_instanced_dispatch = false;
+
+  vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, true /* no_spills */);
+  if (v.run()) {
+ vec4_generator g(brw, prog, &c->gp->program.Base, &c->prog_data.base,
+  mem_ctx, INTEL_DEBUG & DEBUG_GS);
+ const unsigned *generated =
+g.generate_assembly(&v.instructions, final_assembly_size);
+
+ return generated;
+  }
+   }
+
+   /* Either we failed to compile in DUAL_OBJECT mode (probably because it
+* would have required spilling) or DUAL_OBJECT mode is disabled.  So fall
+* back to DUAL_INSTANCED mode, which consumes fewer registers.
+*
+* FIXME: In an ideal world we'd fall back to SINGLE mode, which would
+* allow us to interleave general purpose registers (resulting in even less
+* likelihood of spilling).  But at the moment, the vec4 generator and
+* visitor classes don't have the infrastructure to interleave general
+* purpose registers, so DUAL_INSTANCED is the best we can do.
+*/
+   c->prog_data.dual_instanced_dispatch = true;
 
vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, false /* no_spills */);
if (!v.run()) {
diff --git a/src/mesa/drivers/dri/i965/intel_debug.c 
b/src/mesa/drivers/dri/i965/intel_debug.c
index 03abdfa..b3e2935 100644
--- a/src/mesa/drivers/dri/i965/intel_debug.c
+++ b/src/mesa/drivers/dri/i965/intel_debug.c
@@ -64,6 +64,7 @@ static const struct dri_debug_control debug_control[] = {
{ "shader_time", DEBUG_SHADER_TIME },
{ "no16",  DEBUG_NO16 },
{ "blorp", DEBUG_BLORP },
+   { "nodualobj", DEBUG_NO_DUAL_OBJECT_GS },
{ NULL,0 }
 };
 
diff --git a/src/mesa/drivers/dri/i965/intel_debug.h 
b/src/mesa/drivers/dri/i965/intel_debug.h
index 486a8d6..718d95b 100644
--- a/src/mesa/drivers/dri/i965/intel_debug.h
+++ b/src/mesa/drivers/dri/i965/intel_debug.h
@@ -60,6 +60,7 @@ extern int INTEL_DEBUG;
 #define DEBUG_BLORP   0x1000
 #define DEBUG_NO160x2000
 #define DEBUG_VUE 0x4000
+#define DEBUG_NO_DUAL_OBJECT_GS 0x8000
 
 #ifdef HAVE_ANDROID_PLATFORM
 #define LOG_TAG "INTEL-MESA"
-- 
1.8.4.1

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

[Mesa-dev] [PATCH 6/8] i965/gs: fix up primitive ID workaround for DUAL_INSTANCE dispatch.

[Paul Berry]

Parallel change to "i965/gs: Fix up gl_PointSize input swizzling for
DUAL_INSTANCED gs.", except applied to the gl_PrimitiveID fixup
instead of the gl_PointSize fixup.
---
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp  | 18 +-
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 10 +-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index 700da54..07e9697 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -876,7 +876,23 @@ vec4_generator::generate_vec4_instruction(vec4_instruction 
*instruction,
   }
   break;
case BRW_OPCODE_ADD:
-  brw_ADD(p, dst, src[0], src[1]);
+  if (dst.width == BRW_WIDTH_4) {
+ /* This happens in the geometry shader primitive ID workaround for
+  * "dual instanced" geometry shaders, since they use attributes
+  * (including gl_PrimitiveID) that are vec4's.  Since the exec width
+  * is only 4, it's essential that the caller set force_writemask_all
+  * in order to make sure the MOV happens regardless of which channels
+  * are enabled.
+  */
+ assert(inst->force_writemask_all);
+
+ /* To satisfy register region restrictions, the source registers need
+  * a stride of <4;4,1>.
+  */
+ brw_ADD(p, dst, stride(src[0], 4, 4, 1), stride(src[1], 4, 4, 1));
+  } else {
+ brw_ADD(p, dst, src[0], src[1]);
+  }
   break;
case BRW_OPCODE_MUL:
   brw_MUL(p, dst, src[0], src[1]);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index 5b823c4..76209b0 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -149,7 +149,15 @@ vec4_gs_visitor::primitive_id_workaround()
this->current_annotation = "primitive ID workaround";
dst_reg dst(ATTR, VARYING_SLOT_PRIMITIVE_ID);
dst.type = BRW_REGISTER_TYPE_UD;
-   emit(ADD(dst, src_reg(dst), src_reg(primitive_id_offset)));
+   vec4_instruction *inst =
+  emit(ADD(dst, src_reg(dst), src_reg(primitive_id_offset)));
+
+   /* In dual instanced dispatch mode, the primitive ID has a width of 4, so
+* we need to make sure the ADD happens regardless of which channels are
+* enabled.
+*/
+   inst->force_writemask_all = true;
+
this->current_annotation = NULL;
 }
 
-- 
1.8.4.1

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

[Mesa-dev] [PATCH 8/8] i965: Reduce gl_MaxGeometryInputComponents to 64.

[Paul Berry]

Although in principle there is no hardware limitation that prevents
gl_MaxGeometryInputComponents from being set to 128 on Gen7, we have
the following limitations in the vec4 compiler back end:

- Registers assigned to geometry shader inputs can't be spilled or
  later re-used for any other purpose.

- The last 16 registers are set aside for the "MRF hack", meaning they
  can only be used to send messages, and not for general purpose
  computation.

- Up to 32 registers may be reserved for push constants, even if there
  is sufficient register pressure to make this impractical.

A shader using 128 geometry input components, and having an input type
of triangles_adjacency, would use up:

- 1 register for r0 (which holds URB handles and various pieces of
  control information).

- 1 register for gl_PrimitiveID.

- 102 registers for geometry shader inputs (17 registers per input
  vertex, assuming DUAL_INSTANCED dispatch mode and allowing for one
  register of overhead for gl_Position and gl_PointSize, which are
  present in the URB map even if they are not used).

- Up to 32 registers for push constants.

- 16 registers for the "MRF hack".

That's a total of 152 registers, which is well over the 128 registers
the hardware supports.

Fortunately, the GLSL 1.50 spec allows us to reduce
gl_MaxGeometryInputComponents to 64.  Doing that frees up 48
registers, brining the total down to 104 registers, leaving 24
registers available to do computation.

Fixes piglit test
spec/glsl-1.50/execution/geometry/max-input-components.
---
 src/mesa/drivers/dri/i965/brw_context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 307292d..2bd494f 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -400,7 +400,7 @@ brw_initialize_context_constants(struct brw_context *brw)
if (brw->gen >= 6) {
   ctx->Const.MaxVarying = 32;
   ctx->Const.VertexProgram.MaxOutputComponents = 128;
-  ctx->Const.GeometryProgram.MaxInputComponents = 128;
+  ctx->Const.GeometryProgram.MaxInputComponents = 64;
   ctx->Const.GeometryProgram.MaxOutputComponents = 128;
   ctx->Const.FragmentProgram.MaxInputComponents = 128;
}
-- 
1.8.4.1

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

Re: [Mesa-dev] [RFC PATCH] glsl: Allow mixing of GLSL 1.40 and later shader versions.

[Paul Berry]

On 16 October 2013 22:30, Kenneth Graunke  wrote:

> On 10/16/2013 04:56 PM, Ian Romanick wrote:
> > On 10/16/2013 10:29 AM, Paul Berry wrote:
> >> ---
> >>
> >> I'm not 100% sure this is the right way to go, and here's why:
> >>
> >> Taken together, all the GLSL specs except GLSL 4.30 and GLSL 4.40 tell
> >> a consistent story: desktop shader versions 1.10 and 1.20 may be
> >> linked together, and desktop shader versions 1.40 and above may be
> >> linked together.  No other cross-version linking is allowed.
> >>
> >> However, cross-version linking restrictions were explicitly removed in
> >> GLSL 4.30 (the change is listed under "Summary of Changes from Version
> >> 4.20 as "Remove cross-version linking restrictions.").  GLSL 4.30 and
> >> 4.40 state that *any* version of desktop GLSL may be linked with any
> >> other version of desktop GLSL.  (Note that cross-version linking is
> >> still prohibited for ES shaders).
> >
> > This came from a Khronos bug that I submitted.  The problem is that no
> > other driver enforces the spec mandated restriction.  On top of that,
> > you can't fully enforce the restriction (without draw-time errors) with
> > separate shader objects.  I *thought* the change in 4.3 was to allow
> > mixed versions between stages, but mixing versions within a stage is
> > still forbidden.
> >
> >> This leads to a conundrum.  Normally when the GLSL spec changes from
> >> one version to the next, we implement different rules depending on the
> >> user-supplied "#version" directive.  But we can't do that for
> >> cross-version linking rules since it's not clear which version of GLSL
> >> should apply.  Should we:
> >>
> >> (a) always follow pre-GLSL 4.30 linking rules, since we don't support
> >> GLSL 4.30 yet?  (that's what this patch implements).
> >>
> >> (b) always follow post-GLSL 4.30 linking rules, since they're probably
> >> the clearest reflection of the Khronos board's intent?
> >>
> >> (c) make some kind of dynamic determination of which set of rules to
> >> follow?
> >>
> >> FWIW, the NVIDIA proprietary driver for Linux (version 313.18) appears
> >> to implement (b).
> >
> > There are different cases: intrastage and interstage.  I assume they
> > allow mixing interstage.  What about intrastage?
>
> I ran a quick test on my AMD Radeon 6870, using Catalyst 13.10 (which
> supports 4.30).  It allowed both kinds of linking.  Here's my test:
>
> [require]
> GL >= 2.1
> GLSL >= 1.10
>
> [vertex shader]
> #version 400 compatibility
>
> void main()
> {
> gl_Position = gl_Vertex;
> }
>
> [fragment shader]
> #version 330 core
> uniform vec4 color;
>
> vec4 get_color()
> {
> return color;
> }
>
> [fragment shader]
> #version 110
> vec4 get_color();
>
> void main()
> {
> gl_FragColor = get_color();
> }
>
> [test]
> uniform vec4 color 0 1 0 1
> draw rect -1 -1 2 2
> relative probe rgba (0.5, 0.5) (0.0, 1.0, 0.0, 1.0)
>

Ok, thanks Ken.  Based on the NVIDIA results, and further discussion with
Ian this morning, I'm going to NAK this patch and follow up with a patch
that allows all desktop GLSL versions to be inter-linked.

(BTW, for any Khronos members, the Khronos bug that led to this change is
bug 8463)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] strcasecmp() not found w/ MSVC

[Paul Berry]

On 17 October 2013 12:35, Brian Paul  wrote:

> Hi Paul,
>
> It looks like MSVC doesn't have the strcasecmp() function you recently
> employed in src/glsl/glsl_parser.yy.
>
> Looks like the work-around is _stricmp, per
> http://stackoverflow.com/**questions/3694723/error-c3861-**
> strcasecmp-identifier-not-**found-in-visual-studio-2008/**3694738#3694738
>
> I'll look into fixing it here, but you might want to take a look too (and
> I might not get to it for a few hours).
>
> -Brian
>

It should be an easy enough fix.  I'll send out a patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: Fix MSVC build (missing strcasecmp())

[Paul Berry]

MSVC doesn't have a strcasecmp() function; it uses _stricmp() instead.
---
 src/glsl/glsl_parser.yy | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index ba2dc63..00589e2 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -66,8 +66,14 @@ static bool match_layout_qualifier(const char *s1, const 
char *s2,
 */
if (state->es_shader)
   return strcmp(s1, s2);
-   else
+   else {
+#if defined(_MSC_VER)
+  /* MSVC doesn't have a strcasecmp() function; instead it has _stricmp. */
+  return _stricmp(s1, s2);
+#else
   return strcasecmp(s1, s2);
+#endif
+   }
 }
 %}
 
-- 
1.8.4.1

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

[Mesa-dev] [PATCH] glsl/linker: Allow mixing of desktop GLSL versions.

[Paul Berry]

Previously, Mesa followed the linkage rules outlined in the GLSL
1.20-1.40 specs, which (collectively) said that GLSL versions 1.10 and
1.20 could be linked together, but no other versions could be linked.

In GLSL 4.30, the linkage rules were relaxed so that any two desktop
GLSL versions can be linked together.  This change was made because it
reflected the behaviour of nearly all existing implementations (see
Khronos bug 8463).  Mesa was one of the few (perhaps the only)
exceptions to prohibit cross-linking of some GLSL versions.

Since the GLSL linkage rules were deliberately relaxed in order to
match the behaviour of existing implementations, it seems appropriate
to relax the rules in Mesa too (even though Mesa doesn't support GLSL
4.30 yet).

Note that linking ES and desktop shaders is still prohibited, as is
linking ES shaders having different GLSL versions.

Fixes piglit tests "shaders/version-mixing {interstage,intrastage}".
---
 src/glsl/linker.cpp | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 9095a40..0a949b4 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2057,14 +2057,10 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
   }
}
 
-   /* Previous to GLSL version 1.30, different compilation units could mix and
-* match shading language versions.  With GLSL 1.30 and later, the versions
-* of all shaders must match.
-*
-* GLSL ES has never allowed mixing of shading language versions.
+   /* In desktop GLSL, different shader versions may be linked together.  In
+* GLSL ES, all shader versions must be the same.
 */
-   if ((is_es_prog || max_version >= 130)
-   && min_version != max_version) {
+   if (is_es_prog && min_version != max_version) {
   linker_error(prog, "all shaders must use same shading "
   "language version\n");
   goto done;
-- 
1.8.4.1

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

Re: [Mesa-dev] i965 driver questions

[Paul Berry]

On 9 October 2013 03:33, Rogovin, Kevin  wrote:

> Hi all,
>
>  I've been digging through the i965 driver implementation attempting to
> get my head around it. I have a few questions which I hope can be answered:
>
>   *   What is LIR? The comments say that Mesa GLSL IR is converted into
> LIR which in turn is converted into GPU code. What is LIR and how is the
> LIR represented? I am guessing LIR is some intermediate thing used by i965
> before going to code for different GPUs supported on the i965 or "Lower IR"
> from Mesa upstairs.
>

We haven't really used the terminology "LIR" very consistently.  Theres is
a lower-level intermediate representation we use in the i965 back-end which
is pretty close to assembly instructions (see the vec4_instruction and
fs_inst classes), but the only terminology I've heard us consistently apply
to these representations is "backend instructions".


>   *   In brw_misc_state.c, why does
> brw_workaround_depthstencil_alignment() even exist? I understand the work
> around issue, but why are not those buffers allocated so that they are
> aligned? Moreover, I did not really understand the remark for Gen7
> hardware:  "Gen7+ doesn't require the workarounds, since we always program
> the surface state at the start of the whole surface." not needing the
> workaround, is that comment talking about a specific brw_state_tracker in
> gen7_atoms (of brw_state_upload) or about how the memory is allocated or
> something else?
>

The issue is that due to a quirk of how we've implemented rendering on
pre-gen7, there are different layout requirements for texturing and
rendering.  When texturing, the different miplevels and array slices are
required to be laid out in a precise arrangement on the texture size.  The
hardware also supports rendering to this arrangement, however for
historical reasons, we don't take care of that capability until gen7.  For
pre-gen7 hardware, we instead lie to the hardware and tell it that it's
always rendering to level 0 and layer 0, and we adjust the buffer's base
address and X/Y offsets to cause rendering to go to the right location.
However, that lie sometimes doesn't work because of alignment
restrictions.  When that happens, we render to temporary buffers that are
properly aligned, and later copy the rendered data into the correct
arrangement.  The job of brw_workaround_depthstencil_alignment is to figure
out if the lie is going to work.  If so, it computes the necessary buffer
address offset and X/Y offsets to accomplish the lie.  If not, it creates
the temporary buffers.

Earlier this year, we added the code to gen7 to avoid lying to the hardware
about rendering level and layer--this allowed us to drop
brw_workaround_depthstencil_alignment() for that platform (it was a
necessary prerequisite for implementing geometry shaders).  In an ideal
world, we'd backport that code to pre-gen7 and drop
brw_workaround_depthstencil_alignment entirely.  But we haven't had the
time to do that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] glsl: When constructing a variable with an interface type, set interface_type

[Paul Berry]

On 11 October 2013 11:18, Ian Romanick  wrote:

> From: Ian Romanick 
>
> Ever since the addition of interface blocks with instance names, we have
> had an implicit invariant:
>
> var->type->is_interface() == (var->type == var->interface_type)
>
> A similar invariant exists if var->type->fields.array->is_interface().
>

Can we please spell this out in more detail?  As written, it seems to be
implying that the following two invariants both hold simultaneously:

var->type->is_interface() == (var->type == var->interface_type)
AND
var->type->fields.array->is_interface() == ...

Which is impossible because you can't access "fields.array" of an interface
type.

I think the invariant you mean is something like this:

If var->type->is_interface(), then var->interface_type == var->type.
If var->type->is_array() and var->type->fields.array->is_interface(), then
var->interface_type == var->type->fields.array.

With that fixed, this patch is:

Reviewed-by: Paul Berry 


>
>
> However, the ir_variable constructor doesn't maintain either invariant.
> That seems kind of silly... and I tripped over it while writing some
> other code.  This patch makes the constructor do the right thing, and it
> introduces some tests to verify that behavior.
>
> Signed-off-by: Ian Romanick 
> ---
>  src/glsl/Makefile.am   | 16 +++
>  src/glsl/ast_to_hir.cpp|  1 -
>  src/glsl/builtin_variables.cpp |  1 -
>  src/glsl/ir.cpp| 11 -
>  src/glsl/tests/general_ir_test.cpp | 89
> ++
>  5 files changed, 114 insertions(+), 4 deletions(-)
>  create mode 100644 src/glsl/tests/general_ir_test.cpp
>
> diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
> index cbf253c..f43f49d 100644
> --- a/src/glsl/Makefile.am
> +++ b/src/glsl/Makefile.am
> @@ -32,6 +32,7 @@ AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS)
>  include Makefile.sources
>
>  TESTS = glcpp/tests/glcpp-test \
> +   tests/general-ir-test   \
> tests/optimization-test \
> tests/ralloc-test   \
> tests/sampler-types-test\
> @@ -45,12 +46,27 @@ noinst_LTLIBRARIES = libglsl.la libglcpp.la
>  check_PROGRAMS =   \
> glcpp/glcpp \
> glsl_test   \
> +   tests/general-ir-test   \
> tests/ralloc-test   \
> tests/sampler-types-test\
> tests/uniform-initializer-test
>
>  noinst_PROGRAMS = glsl_compiler
>
> +tests_general_ir_test_SOURCES =\
> +   $(top_srcdir)/src/mesa/main/hash_table.c\
> +   $(top_srcdir)/src/mesa/main/imports.c   \
> +   $(top_srcdir)/src/mesa/program/prog_hash_table.c\
> +   $(top_srcdir)/src/mesa/program/symbol_table.c   \
> +   $(GLSL_SRCDIR)/standalone_scaffolding.cpp \
> +   tests/general_ir_test.cpp
> +tests_general_ir_test_CFLAGS = \
> +   $(PTHREAD_CFLAGS)
> +tests_general_ir_test_LDADD =  \
> +   $(top_builddir)/src/gtest/libgtest.la   \
> +   $(top_builddir)/src/glsl/libglsl.la \
> +   $(PTHREAD_LIBS)
> +
>  tests_uniform_initializer_test_SOURCES =   \
> $(top_srcdir)/src/mesa/main/hash_table.c\
> $(top_srcdir)/src/mesa/main/imports.c   \
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index dfa32d9..b644b22 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -4876,7 +4876,6 @@ ast_interface_block::hir(exec_list *instructions,
>var_mode);
>}
>
> -  var->init_interface_type(block_type);
>if (state->target == geometry_shader && var_mode ==
> ir_var_shader_in)
>   handle_geometry_shader_input_decl(state, loc, var);
>
> diff --git a/src/glsl/builtin_variables.cpp
> b/src/glsl/builtin_variables.cpp
> index ae0a03f..9d78b2e 100644
> --- a/src/glsl/builtin_variables.cpp
> +++ b/src/glsl/builtin_variables.cpp
> @@ -858,7 +858,6 @@ builtin_variable_generator::generate_varyings()
>   this->per_vertex_in.construct_interface_instance();
>ir_variable *var = add_variable("gl_in", array(per_vertex_in_type,
> 0),
>ir_var_shader_in, -1);
> -  var->init_interface_type(per_vertex_

Re: [Mesa-dev] [PATCH 2/6] glsl/tests: Verify vertex shader built-ins generated by _mesa_glsl_initialize_variables

[Paul Berry]

> +common_builtin::TearDown()
> +{
> +   ralloc_free(this->mem_ctx);
> +   this->mem_ctx = NULL;
> +}
> +
> +void
> +common_builtin::string_starts_with_prefix(const char *str, const char
> *prefix)
> +{
> +   const size_t len = strlen(prefix);
> +   char *const name_prefix = new char[len];
>

This needs to be new char[len + 1], since you assign to its len'th element
below.


> +
> +   strncpy(name_prefix, str, len);
> +   name_prefix[len] = '\0';
> +   EXPECT_STREQ(prefix, name_prefix) << "Bad name " << str;
> +}
> +
> +void
> +common_builtin::names_start_with_gl()
> +{
> +   foreach_list(node, &this->ir) {
> +  ir_variable *const var = ((ir_instruction *) node)->as_variable();
> +
> +  string_starts_with_prefix(var->name, "gl_");
> +   }
> +}
> +
> +void
> +common_builtin::uniforms_and_system_values_dont_have_explicit_location()
> +{
> +   foreach_list(node, &this->ir) {
> +  ir_variable *const var = ((ir_instruction *) node)->as_variable();
> +
> +  if (var->mode != ir_var_uniform && var->mode != ir_var_system_value)
> + continue;
> +
> +  EXPECT_FALSE(var->explicit_location);
> +  EXPECT_EQ(-1, var->location);
> +   }
> +}
> +
> +void
> +common_builtin::constants_are_constant()
> +{
> +   foreach_list(node, &this->ir) {
> +  ir_variable *const var = ((ir_instruction *) node)->as_variable();
> +
> +  if (var->mode != ir_var_auto)
> + continue;
> +
> +  EXPECT_FALSE(var->explicit_location);
> +  EXPECT_EQ(-1, var->location);
> +  EXPECT_TRUE(var->read_only);
> +   }
> +}
> +
> +void
> +common_builtin::no_invalid_variable_modes()
> +{
> +   foreach_list(node, &this->ir) {
> +  ir_variable *const var = ((ir_instruction *) node)->as_variable();
> +
> +  switch (var->mode) {
> +  case ir_var_auto:
> +  case ir_var_uniform:
> +  case ir_var_shader_in:
> +  case ir_var_shader_out:
> +  case ir_var_system_value:
> + break;
> +
> +  /* Invalid modes that we know. */
> +  case ir_var_function_in:
> +  case ir_var_function_out:
> +  case ir_var_function_inout:
> +  case ir_var_const_in:
> +  case ir_var_temporary:
> + EXPECT_NE(ir_var_function_in, var->mode);
> + EXPECT_NE(ir_var_function_out, var->mode);
> + EXPECT_NE(ir_var_function_inout, var->mode);
> + EXPECT_NE(ir_var_const_in, var->mode);
> + EXPECT_NE(ir_var_temporary, var->mode);
> + break;
>

This block seems really strange to me.  All of these invalid modes are
adequately covered by the default case, which is easier to read.

With those two things fixed, this patch is:

Reviewed-by: Paul Berry 


> +
> +  /* Invalid modes that we don't know. */
> +  default:
> + EXPECT_TRUE(false) << "invalid mode " << int(var->mode);
> + break;
> +  }
> +   }
> +}
> +
> +//
> +
> +class vertex_builtin : public common_builtin {
> +public:
> +   vertex_builtin()
> +  : common_builtin(GL_VERTEX_SHADER)
> +   {
> +  /* empty */
> +   }
> +};
> +
> +TEST_F(vertex_builtin, names_start_with_gl)
> +{
> +   common_builtin::names_start_with_gl();
> +}
> +
> +TEST_F(vertex_builtin, inputs_have_explicit_location)
> +{
> +   foreach_list(node, &this->ir) {
> +  ir_variable *const var = ((ir_instruction *) node)->as_variable();
> +
> +  if (var->mode != ir_var_shader_in)
> + continue;
> +
> +  EXPECT_TRUE(var->explicit_location);
> +  EXPECT_NE(-1, var->location);
> +  EXPECT_GT(VERT_ATTRIB_GENERIC0, var->location);
> +  EXPECT_EQ(0u, var->location_frac);
> +   }
> +}
> +
> +TEST_F(vertex_builtin, outputs_have_explicit_location)
> +{
> +   foreach_list(node, &this->ir) {
> +  ir_variable *const var = ((ir_instruction *) node)->as_variable();
> +
> +  if (var->mode != ir_var_shader_out)
> + continue;
> +
> +  EXPECT_TRUE(var->explicit_location);
> +  EXPECT_NE(-1, var->location);
> +  EXPECT_GT(VARYING_SLOT_VAR0, var->location);
> +  EXPECT_EQ(0u, var->location_frac);
> +
> +  /* Several varyings only exist in the fragment shader.  Be sure
> that no
> +   * outputs with these locations exist.
> +   */
> +  EXPECT_NE(VARYING_SLOT_PNTC, var->location);
> +  EXPECT_NE(VARYING_SLOT_FACE, var->location);
> +  EXPECT_NE(VARYING_SLOT_PRIMITIVE_ID, var->location);
> +   }
> +}
> +
> +TEST_F(vertex_builtin,
> uniforms_and_system_values_dont_have_explicit_location)
> +{
> +
> common_builtin::uniforms_and_system_values_dont_have_explicit_location();
> +}
> +
> +TEST_F(vertex_builtin, constants_are_constant)
> +{
> +   common_builtin::constants_are_constant();
> +}
> +
> +TEST_F(vertex_builtin, no_invalid_variable_modes)
> +{
> +   common_builtin::no_invalid_variable_modes();
> +}
> --
> 1.8.1.4
>
> ___
> 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 3/6] glsl/tests: Verify fragment shader built-ins generated by _mesa_glsl_initialize_variables

[Paul Berry]

On 11 October 2013 11:18, Ian Romanick  wrote:

> From: Ian Romanick 
>
> Checks that the variables generated meet certain criteria.
>
>  - Fragment shader inputs have an explicit location.
>
>  - Fragment shader outputs have an explicit location.
>
>  - Vertex / geometry shader-only varying locations are not used.
>
>  - Fragment shader uniforms and system values don't have an explicit
>location.
>
>  - Fragment shader constants don't have an explicit location and are
>read-only.
>
>  - No other kinds of fragment variables exist.
>
> It does not verify that an specific variables exist.
>
> Signed-off-by: Ian Romanick 
> ---
>  src/glsl/tests/builtin_variable_test.cpp | 76
> 
>  1 file changed, 76 insertions(+)
>
> diff --git a/src/glsl/tests/builtin_variable_test.cpp
> b/src/glsl/tests/builtin_variable_test.cpp
> index c4711ab..37c8f25 100644
> --- a/src/glsl/tests/builtin_variable_test.cpp
> +++ b/src/glsl/tests/builtin_variable_test.cpp
> @@ -233,3 +233,79 @@ TEST_F(vertex_builtin, no_invalid_variable_modes)
>  {
> common_builtin::no_invalid_variable_modes();
>  }
> +
> +//
> +
> +class fragment_builtin : public common_builtin {
> +public:
> +   fragment_builtin()
> +  : common_builtin(GL_FRAGMENT_SHADER)
> +   {
> +  /* empty */
> +   }
> +};
> +
> +TEST_F(fragment_builtin, names_start_with_gl)
> +{
> +   common_builtin::names_start_with_gl();
> +}
> +
> +TEST_F(fragment_builtin, inputs_have_explicit_location)
> +{
> +   foreach_list(node, &this->ir) {
> +  ir_variable *const var = ((ir_instruction *) node)->as_variable();
> +
> +  if (var->mode != ir_var_shader_in)
> +continue;
> +
> +  EXPECT_TRUE(var->explicit_location);
> +  EXPECT_NE(-1, var->location);
> +  EXPECT_GT(VARYING_SLOT_VAR0, var->location);
> +  EXPECT_EQ(0u, var->location_frac);
> +
> +  /* Several varyings only exist in the vertex / geometry shader.  Be
> sure
> +   * that no inputs with these locations exist.
> +   */
> +  EXPECT_NE(VARYING_SLOT_PSIZ, var->location);
> +  EXPECT_NE(VARYING_SLOT_BFC0, var->location);
> +  EXPECT_NE(VARYING_SLOT_BFC1, var->location);
> +  EXPECT_NE(VARYING_SLOT_EDGE, var->location);
> +  EXPECT_NE(VARYING_SLOT_CLIP_VERTEX, var->location);
> +  EXPECT_NE(VARYING_SLOT_LAYER, var->location);
>

You can use

EXPECT_TRUE(_mesa_varying_slot_in_fs((gl_varying_slot) var->location);

instead.

With that fixed,

Reviewed-by: Paul Berry 


> +   }
> +}
> +
> +TEST_F(fragment_builtin, outputs_have_explicit_location)
> +{
> +   foreach_list(node, &this->ir) {
> +  ir_variable *const var = ((ir_instruction *) node)->as_variable();
> +
> +  if (var->mode != ir_var_shader_out)
> +continue;
> +
> +  EXPECT_TRUE(var->explicit_location);
> +  EXPECT_NE(-1, var->location);
> +
> +  /* gl_FragData[] has location FRAG_RESULT_DATA0.  Locations beyond
> that
> +   * are invalid.
> +   */
> +  EXPECT_GE(FRAG_RESULT_DATA0, var->location);
> +
> +  EXPECT_EQ(0u, var->location_frac);
> +   }
> +}
> +
> +TEST_F(fragment_builtin,
> uniforms_and_system_values_dont_have_explicit_location)
> +{
> +
> common_builtin::uniforms_and_system_values_dont_have_explicit_location();
> +}
> +
> +TEST_F(fragment_builtin, constants_are_constant)
> +{
> +   common_builtin::constants_are_constant();
> +}
> +
> +TEST_F(fragment_builtin, no_invalid_variable_modes)
> +{
> +   common_builtin::no_invalid_variable_modes();
> +}
> --
> 1.8.1.4
>
> ___
> 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 5/6] glsl/tests: Unit test vertex shader in / out with link_invalidate_variable_locations

[Paul Berry]

;
> +   EXPECT_TRUE(var->explicit_location);
> +   EXPECT_FALSE(var->is_unmatched_generic_inout);
> +}
> +
> +TEST_F(invalidate_locations, vertex_in_builtin)
> +{
> +   ir_variable *const var =
> +  new(mem_ctx) ir_variable(glsl_type::vec(4),
> +   "gl_Vertex",
> +   ir_var_shader_in);
> +
> +   EXPECT_FALSE(var->explicit_location);
> +   EXPECT_EQ(-1, var->location);
> +
> +   var->location = VERT_ATTRIB_POS;
> +   var->explicit_location = true;
> +
> +   ir.push_tail(var);
> +
> +   link_invalidate_variable_locations(&ir,
> +  VERT_ATTRIB_GENERIC0,
> +  VARYING_SLOT_VAR0);
> +
> +   EXPECT_EQ(VERT_ATTRIB_POS, var->location);
> +   EXPECT_EQ(0u, var->location_frac);
> +   EXPECT_TRUE(var->explicit_location);
> +   EXPECT_FALSE(var->is_unmatched_generic_inout);
> +}
> +
> +TEST_F(invalidate_locations, vertex_in_builtin_without_explicit)
> +{
> +   /* This test is almost identical to vertex_in_builtin.  However,
> +* ir_variable::explicit_location is not.
>

Did you mean to say "...is not set"?


> +* link_invalidate_variable_locations has the behavior that non-generic
> +* inputs (or outputs) are not modified.
> +*/
>

It seems a little weird to be testing this case, since as I understand it,
non-generic (i.e. built-in) inputs and outputs always have
explicit_location set to true.  Are you really meaning to test a corner
case that we know never happens?  My temptation would be to delete this
test.

If you really think we should keep it, I think at the very least the
comment above should be updated to say something like "Although non-generic
inputs/outputs always have explicit_location set to true, the contract of
link_invalidate_variable_locations() is that it should not modify
non-generic inputs or outputs regardless of the setting of
explicit_location."


> +   ir_variable *const var =
> +  new(mem_ctx) ir_variable(glsl_type::vec(4),
> +   "gl_Vertex",
> +   ir_var_shader_in);
> +
> +   EXPECT_FALSE(var->explicit_location);
> +   EXPECT_EQ(-1, var->location);
> +
> +   var->location = VERT_ATTRIB_POS;
> +
> +   ir.push_tail(var);
> +
> +   link_invalidate_variable_locations(&ir,
> +  VERT_ATTRIB_GENERIC0,
> +  VARYING_SLOT_VAR0);
> +
> +   EXPECT_EQ(VERT_ATTRIB_POS, var->location);
> +   EXPECT_EQ(0u, var->location_frac);
> +   EXPECT_FALSE(var->explicit_location);
> +   EXPECT_FALSE(var->is_unmatched_generic_inout);
> +}
> +
> +TEST_F(invalidate_locations, simple_vertex_out_generic)
> +{
> +   ir_variable *const var =
> +  new(mem_ctx) ir_variable(glsl_type::vec(4),
> +   "a",
> +   ir_var_shader_out);
> +
> +   EXPECT_FALSE(var->explicit_location);
> +   EXPECT_EQ(-1, var->location);
> +
> +   var->location = VARYING_SLOT_VAR0;
> +
> +   ir.push_tail(var);
> +
> +   link_invalidate_variable_locations(&ir,
> +  VERT_ATTRIB_GENERIC0,
> +  VARYING_SLOT_VAR0);
> +
> +   EXPECT_EQ(-1, var->location);
> +   EXPECT_EQ(0u, var->location_frac);
> +   EXPECT_FALSE(var->explicit_location);
> +   EXPECT_TRUE(var->is_unmatched_generic_inout);
> +}
> +
> +TEST_F(invalidate_locations, vertex_out_builtin)
> +{
> +   ir_variable *const var =
> +  new(mem_ctx) ir_variable(glsl_type::vec(4),
> +   "gl_FrontColor",
> +   ir_var_shader_out);
> +
> +   EXPECT_FALSE(var->explicit_location);
> +   EXPECT_EQ(-1, var->location);
> +
> +   var->location = VARYING_SLOT_COL0;
> +   var->explicit_location = true;
> +
> +   ir.push_tail(var);
> +
> +   link_invalidate_variable_locations(&ir,
> +  VERT_ATTRIB_GENERIC0,
> +  VARYING_SLOT_VAR0);
> +
> +   EXPECT_EQ(VARYING_SLOT_COL0, var->location);
> +   EXPECT_EQ(0u, var->location_frac);
> +   EXPECT_TRUE(var->explicit_location);
> +   EXPECT_FALSE(var->is_unmatched_generic_inout);
> +}
> +
> +TEST_F(invalidate_locations, vertex_out_builtin_without_explicit)
> +{
> +   /* This test is almost identical to vertex_out_builtin.  However,
> +* ir_variable::explicit_location is not.
> +* link_invalidate_variable_locations has the behavior that non-generic
> +* inputs (or outputs) are not modified.
> +*/
>

I have similar feelings about this test.


> +   ir_variable *const var =
> +  new(mem_ctx) ir_variable(glsl_type::vec(4),
> +   "gl_FrontColor",
> +   ir_var_shader_out);
> +
> +   EXPECT_FALSE(var->explicit_location);
> +   EXPECT_EQ(-1, var->location);
> +
> +   var->location = VARYING_SLOT_COL0;
> +
> +   ir.push_tail(var);
> +
> +   link_invalidate_variable_locations(&ir,
> +  VERT_ATTRIB_GENERIC0,
> +  VARYING_SLOT_VAR0);
> +
> +   EXPECT_EQ(VARYING_SLOT_COL0, var->location);
> +   EXPECT_EQ(0u, var->location_frac);
> +   EXPECT_FALSE(var->explicit_location);
> +   EXPECT_FALSE(var->is_unmatched_generic_inout);
> +}
> --
> 1.8.1.4
>

With the *_builtin_without_explicit issues resolved, this patch is:

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

Re: [Mesa-dev] [PATCH 6/6] glsl: Simplify the interface to link_invalidate_variable_locations

[Paul Berry]

On 11 October 2013 11:18, Ian Romanick  wrote:

> From: Ian Romanick 
>
> The unit tests added in the previous commits prove some things about the
> state of some internal data structures.  The most important of these is
> that all built-in input and output variables have explicit_location
> set.  This means that link_invalidate_variable_locations doesn't need to
> know the range of non-generic shader inputs or outputs.  It can simply
> reset location state depending on whether explicit_location is set.
>
> There are two additional assumptions that were already implicit in the
> code that comments now document.
>
>   - ir_variable::is_unmatched_generic_inout is only used by the linker
> when connecting outputs from one shader stage to inputs of another
> shader stage.
>
>   - Any varying that has explicit_location set must be a built-in.  This
> will be true until GL_ARB_separate_shader_objects is supported.
>
> As a result, the input_base and output_base parameters to
> link_invalidate_variable_locations are no longer necessary, and the code
> for resetting locations and setting is_unmatched_generic_inout can be
> simplified.
>
> Signed-off-by: Ian Romanick 
> Cc: Paul Berry 
> ---
>  src/glsl/linker.cpp  | 48 ++---
>  src/glsl/linker.h|  3 +-
>  src/glsl/tests/invalidate_locations_test.cpp | 62
> ++--
>  3 files changed, 55 insertions(+), 58 deletions(-)
>
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index 02eb4e1..acc3039 100644
> --- a/src/glsl/linker.cpp
> +++ b/src/glsl/linker.cpp
> @@ -366,8 +366,7 @@ parse_program_resource_name(const GLchar *name,
>
>
>  void
> -link_invalidate_variable_locations(exec_list *ir, int input_base,
> -   int output_base)
> +link_invalidate_variable_locations(exec_list *ir)
>  {
> foreach_list(node, ir) {
>ir_variable *const var = ((ir_instruction *) node)->as_variable();
> @@ -375,26 +374,30 @@ link_invalidate_variable_locations(exec_list *ir,
> int input_base,
>if (var == NULL)
>   continue;
>
> -  int base;
> -  switch (var->mode) {
> -  case ir_var_shader_in:
> - base = input_base;
> - break;
> -  case ir_var_shader_out:
> - base = output_base;
> - break;
> -  default:
> - continue;
> -  }
> -
> -  /* Only assign locations for generic attributes / varyings / etc.
> +  /* Only assign locations for variables that lack an explicit
> location.
> +   * Explicit locations are set for all built-in variables, generic
> vertex
> +   * shader inputs (via layout(location=...)), and generic fragment
> shader
> +   * outputs (also via layout(location=...)).
> */
> -  if ((var->location >= base) && !var->explicit_location)
> +  if (!var->explicit_location) {
>   var->location = -1;
> + var->location_frac = 0;
> +  }
>
> -  if ((var->location == -1) && !var->explicit_location) {
> +  /* ir_variable::is_unmatched_generic_inout is used by the linker
> while
> +   * connecting outputs from one stage to inputs of the next stage.
> +   *
> +   * There are two implicit assumptions here.  First, we assume that
> any
> +   * built-in variable (i.e., non-generic in or out) will have
> +   * explicit_location set.  Second, we assume that any generic in or
> out
> +   * will not have explicit_location set.
> +   *
> +   * This second assumption will only be valid until
> +   * GL_ARB_separate_shader_objects is supported.  When that
> extension is
> +   * implemented, this function will need some modifications.
> +   */
> +  if (!var->explicit_location) {
>   var->is_unmatched_generic_inout = 1;
> - var->location_frac = 0;
>} else {
>   var->is_unmatched_generic_inout = 0;
>}
> @@ -2221,18 +2224,15 @@ link_shaders(struct gl_context *ctx, struct
> gl_shader_program *prog)
> /* Mark all generic shader inputs and outputs as unpaired. */
> if (prog->_LinkedShaders[MESA_SHADER_VERTEX] != NULL) {
>link_invalidate_variable_locations(
> -prog->_LinkedShaders[MESA_SHADER_VERTEX]->ir,
> -VERT_ATTRIB_GENERIC0, VARYING_SLOT_VAR0);
> +prog->_LinkedShaders[MESA_SHADER_VERTEX]->ir);
> }
> if (prog->_LinkedShaders[MESA_SHADER_GEOMETRY] != NULL) {
>link_invalidate_variable_locations(
> -prog->_LinkedShaders[MESA_SHADER_GE

Re: [Mesa-dev] Documentation plan: request for comments

[Paul Berry]

On 11 October 2013 14:40, Chad Versace  wrote:

> On 10/10/2013 01:38 AM, Rogovin, Kevin wrote:
>
>> Hello all,
>>
>>My current goal is to add documentation to Mesa so that the ramp up
>> time of Mesa goes down a great deal.
>>
>
> I support that goal. When I see other projects that publish good Doxygen
> documentation,
> like 
> http://llvm.org/doxygen/**modules.html,
> I become jealous and wish Mesa did the same.
>
>
>  In addition I wish to create an index of files and data structures keyed
>> by subjects. The use case of such an index is of the form "How does Mesa
>> does functionality foo? Where are those functions and states?" and then one
>> can quickly find the files and data structures to answer that question. The
>> goal I have is that one can use doxygen output to quickly browse source
>> code to find the implementation details as well.
>>
>> There are several approaches that I can think of on how to accomplish
>> this, so far I have come up with 2 options:
>>
>>
>>   Option A: A separate file that lists an organization of files of Mesa
>> by functionality. Each file is placed into a section and/or subsection and
>> a brief description of each file. This I have already done.
>>
>>Advantages: easier to organize text, easier to create linking
>> narration between groups. Greater control over text presentation to create
>> a flow, especially between units.
>>
>>Disadvantages: Document needs to be maintained as a separate file: as
>> files are added and changed they need to update their entries in the file.
>>
>>
>>
>> OR
>>
>>
>>
>>Option B: A set of doxygen groups and subgroups. The groups and
>> subgroups will have names given by functionality. Each header AND _source_
>> file would be placed into a group. In addition each source file would have
>> a file tag describing what it does. This requires adding the necessary
>> doxygen tag header "\addtogroup FOO @{" and footer "@}". For those files
>> that provide support to another file, those files should be in a list
>> stating that they support another file.
>>
>>
>>
>>Advantages: Documentation is better localized to a file. Changes to a
>> file will then get their documentation updated too with the file.
>>
>>
>>Disadvantages: Very difficult to make a good table of contents without
>> resorting to a script to run on the files hunting for tags (AFAIK doxygen
>> does not generate nice TOC's for groups). Massive number of patches for the
>> first commit since it would essentially touch every file. Trickier to
>> create linking narration for different groups.
>>
>>
>>
>> Option A is already done for src/mesa/main and src/mesa/vbo.
>>
>>
>>
>> Thoughts, suggestions, etc are greatly appreciated.
>>
>
> I prefer option B, keep the documentation as close to the source as
> possible. Mesa developers, according to my
> observations, do not fastidiously maintain documentation. So I believe you
> will need to eliminate as much
> maintenance overhead as possible, and put the docs close to the source, if
> you intend to succeed at your
> endeavor.
>
> To aid everyone in examining the current state of our Doxygen, I've
> automated it publication every 4 hours
> to here:
>
> http://people.freedesktop.org/**~chadversary/mesa/doxygen
>
> I'm currently building the Doxygen only for master. If you'd like me to
> automate publication of one your
> branches too, just let me know.


Any chance we could move this to a non-Chad-specific section of the web
site, and put a link to it on the main Mesa page?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] glsl: When constructing a variable with an interface type, set interface_type

[Paul Berry]

On 18 October 2013 12:17, Paul Berry  wrote:

> On 11 October 2013 11:18, Ian Romanick  wrote:
>
>> From: Ian Romanick 
>>
>> Ever since the addition of interface blocks with instance names, we have
>> had an implicit invariant:
>>
>> var->type->is_interface() == (var->type == var->interface_type)
>>
>> A similar invariant exists if var->type->fields.array->is_interface().
>>
>
> Can we please spell this out in more detail?  As written, it seems to be
> implying that the following two invariants both hold simultaneously:
>
> var->type->is_interface() == (var->type == var->interface_type)
> AND
> var->type->fields.array->is_interface() == ...
>
> Which is impossible because you can't access "fields.array" of an
> interface type.
>
> I think the invariant you mean is something like this:
>
> If var->type->is_interface(), then var->interface_type == var->type.
> If var->type->is_array() and var->type->fields.array->is_interface(), then
> var->interface_type == var->type->fields.array.
>
> With that fixed, this patch is:
>
> Reviewed-by: Paul Berry 
>

One other thing: would you mind adding "general-ir-test" to
src/glsl/tests/.gitignore?  Thanks.


>
>
>>
>>
>> However, the ir_variable constructor doesn't maintain either invariant.
>> That seems kind of silly... and I tripped over it while writing some
>> other code.  This patch makes the constructor do the right thing, and it
>> introduces some tests to verify that behavior.
>>
>> Signed-off-by: Ian Romanick 
>> ---
>>  src/glsl/Makefile.am   | 16 +++
>>  src/glsl/ast_to_hir.cpp|  1 -
>>  src/glsl/builtin_variables.cpp |  1 -
>>  src/glsl/ir.cpp| 11 -
>>  src/glsl/tests/general_ir_test.cpp | 89
>> ++
>>  5 files changed, 114 insertions(+), 4 deletions(-)
>>  create mode 100644 src/glsl/tests/general_ir_test.cpp
>>
>> diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
>> index cbf253c..f43f49d 100644
>> --- a/src/glsl/Makefile.am
>> +++ b/src/glsl/Makefile.am
>> @@ -32,6 +32,7 @@ AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS)
>>  include Makefile.sources
>>
>>  TESTS = glcpp/tests/glcpp-test \
>> +   tests/general-ir-test   \
>> tests/optimization-test \
>> tests/ralloc-test   \
>> tests/sampler-types-test\
>> @@ -45,12 +46,27 @@ noinst_LTLIBRARIES = libglsl.la libglcpp.la
>>  check_PROGRAMS =   \
>> glcpp/glcpp \
>> glsl_test   \
>> +   tests/general-ir-test   \
>> tests/ralloc-test   \
>> tests/sampler-types-test\
>> tests/uniform-initializer-test
>>
>>  noinst_PROGRAMS = glsl_compiler
>>
>> +tests_general_ir_test_SOURCES =\
>> +   $(top_srcdir)/src/mesa/main/hash_table.c\
>> +   $(top_srcdir)/src/mesa/main/imports.c   \
>> +   $(top_srcdir)/src/mesa/program/prog_hash_table.c\
>> +   $(top_srcdir)/src/mesa/program/symbol_table.c   \
>> +   $(GLSL_SRCDIR)/standalone_scaffolding.cpp \
>> +   tests/general_ir_test.cpp
>> +tests_general_ir_test_CFLAGS = \
>> +   $(PTHREAD_CFLAGS)
>> +tests_general_ir_test_LDADD =  \
>> +   $(top_builddir)/src/gtest/libgtest.la   \
>> +   $(top_builddir)/src/glsl/libglsl.la \
>> +   $(PTHREAD_LIBS)
>> +
>>  tests_uniform_initializer_test_SOURCES =   \
>> $(top_srcdir)/src/mesa/main/hash_table.c\
>> $(top_srcdir)/src/mesa/main/imports.c   \
>> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
>> index dfa32d9..b644b22 100644
>> --- a/src/glsl/ast_to_hir.cpp
>> +++ b/src/glsl/ast_to_hir.cpp
>> @@ -4876,7 +4876,6 @@ ast_interface_block::hir(exec_list *instructions,
>>var_mode);
>>}
>>
>> -  var->init_interface_type(block_type);
>>if (state->target == geometry_shader && var_mode ==
>> ir_var_shader_in)
>>   handle_geometry_shader_input_decl(state

Re: [Mesa-dev] [PATCH] glsl: Initialize per_vertex_accumluator::fields.

[Paul Berry]

On 11 October 2013 23:23, Vinson Lee  wrote:

> Fixes "Uninitialized pointer field" defect reported by Coverity.
>
> Signed-off-by: Vinson Lee 
>

Reviewed-by: Paul Berry 


> ---
>  src/glsl/builtin_variables.cpp | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/glsl/builtin_variables.cpp
> b/src/glsl/builtin_variables.cpp
> index ae0a03f..3f87502 100644
> --- a/src/glsl/builtin_variables.cpp
> +++ b/src/glsl/builtin_variables.cpp
> @@ -311,7 +311,8 @@ private:
>
>
>  per_vertex_accumulator::per_vertex_accumulator()
> -   : num_fields(0)
> +   : fields(),
> + num_fields(0)
>  {
>  }
>
> --
> 1.8.3.2
>
> ___
> 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 3/8] mesa: Pass number of samples as a program state variable

[Paul Berry]

On 14 October 2013 10:12, Anuj Phogat  wrote:

> Number of samples will be required in fragment shader program by new
> GLSL builtin uniform "gl_NumSamples".
>
> Signed-off-by: Anuj Phogat 
> ---
>  src/mesa/program/prog_statevars.c | 11 +++
>  src/mesa/program/prog_statevars.h |  2 ++
>  2 files changed, 13 insertions(+)
>
> diff --git a/src/mesa/program/prog_statevars.c
> b/src/mesa/program/prog_statevars.c
> index 145c07c..8f798da 100644
> --- a/src/mesa/program/prog_statevars.c
> +++ b/src/mesa/program/prog_statevars.c
> @@ -349,6 +349,9 @@ _mesa_fetch_state(struct gl_context *ctx, const
> gl_state_index state[],
>   }
>}
>return;
> +   case STATE_NUM_SAMPLES:
> +  ((int *)value)[0] = ctx->DrawBuffer->Visual.samples;
> +  return;
> case STATE_DEPTH_RANGE:
>value[0] = ctx->Viewport.Near; /* near   */
>value[1] = ctx->Viewport.Far;  /* far*/
> @@ -665,6 +668,9 @@ _mesa_program_state_flags(const gl_state_index
> state[STATE_LENGTH])
> case STATE_PROGRAM_MATRIX:
>return _NEW_TRACK_MATRIX;
>
> +   case STATE_NUM_SAMPLES:
> +  return _NEW_MULTISAMPLE;
>

I think this should be _NEW_BUFFERS.  _NEW_MULTISAMPLE is only flagged when
something in gl_multisample_attrib changes, and nothing in that category
affects ctx->DrawBuffer->Visual.samples.

With that fixed, this patch is:

Reviewed-by: Paul Berry 


> +
> case STATE_DEPTH_RANGE:
>return _NEW_VIEWPORT;
>
> @@ -852,6 +858,9 @@ append_token(char *dst, gl_state_index k)
> case STATE_TEXENV_COLOR:
>append(dst, "texenv");
>break;
> +   case STATE_NUM_SAMPLES:
> +  append(dst, "num.samples");
> +  break;
> case STATE_DEPTH_RANGE:
>append(dst, "depth.range");
>break;
> @@ -1027,6 +1036,8 @@ _mesa_program_state_string(const gl_state_index
> state[STATE_LENGTH])
>break;
> case STATE_FOG_COLOR:
>break;
> +   case STATE_NUM_SAMPLES:
> +  break;
> case STATE_DEPTH_RANGE:
>break;
> case STATE_FRAGMENT_PROGRAM:
> diff --git a/src/mesa/program/prog_statevars.h
> b/src/mesa/program/prog_statevars.h
> index ec22b73..c3081c4 100644
> --- a/src/mesa/program/prog_statevars.h
> +++ b/src/mesa/program/prog_statevars.h
> @@ -103,6 +103,8 @@ typedef enum gl_state_index_ {
>
> STATE_TEXENV_COLOR,
>
> +   STATE_NUM_SAMPLES,
> +
> STATE_DEPTH_RANGE,
>
> STATE_VERTEX_PROGRAM,
> --
> 1.8.1.4
>
> ___
> 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 4/8] glsl: Add new builtins required by GL_ARB_sample_shading

[Paul Berry]

On 14 October 2013 10:12, Anuj Phogat  wrote:

> New builtins added by GL_ARB_sample_shading:
> in vec2 gl_SamplePosition
> in int gl_SampleID
> in int gl_NumSamples
> out int gl_SampleMask[]
>
> Signed-off-by: Anuj Phogat 
> ---
>  src/glsl/builtin_variables.cpp | 11 +++
>  src/glsl/link_varyings.cpp |  2 ++
>  src/mesa/main/mtypes.h |  7 ++-
>  src/mesa/program/prog_print.c  |  5 +
>  4 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/src/glsl/builtin_variables.cpp
> b/src/glsl/builtin_variables.cpp
> index ae0a03f..c886840 100644
> --- a/src/glsl/builtin_variables.cpp
> +++ b/src/glsl/builtin_variables.cpp
> @@ -30,6 +30,9 @@
>  #include "program/prog_statevars.h"
>  #include "program/prog_instruction.h"
>
> +static struct gl_builtin_uniform_element gl_NumSamples_elements[] = {
> +   {NULL, {STATE_NUM_SAMPLES, 0, 0}, SWIZZLE_XYZW}
> +};
>
>  static struct gl_builtin_uniform_element gl_DepthRange_elements[] = {
> {"near", {STATE_DEPTH_RANGE, 0, 0}, SWIZZLE_},
> @@ -236,6 +239,7 @@ static struct gl_builtin_uniform_element
> gl_NormalMatrix_elements[] = {
>  #define STATEVAR(name) {#name, name ## _elements, Elements(name ##
> _elements)}
>
>  static const struct gl_builtin_uniform_desc _mesa_builtin_uniform_desc[]
> = {
> +   STATEVAR(gl_NumSamples),
> STATEVAR(gl_DepthRange),
> STATEVAR(gl_ClipPlane),
> STATEVAR(gl_Point),
> @@ -613,6 +617,7 @@ builtin_variable_generator::generate_constants()
>  void
>  builtin_variable_generator::generate_uniforms()
>  {
> +   add_uniform(int_t, "gl_NumSamples");
> add_uniform(type("gl_DepthRangeParameters"), "gl_DepthRange");
> add_uniform(array(vec4_t, VERT_ATTRIB_MAX),
> "gl_CurrentAttribVertMESA");
> add_uniform(array(vec4_t, VARYING_SLOT_MAX),
> "gl_CurrentAttribFragMESA");
> @@ -789,6 +794,12 @@ builtin_variable_generator::generate_fs_special_vars()
>if (state->AMD_shader_stencil_export_warn)
>   var->warn_extension = "GL_AMD_shader_stencil_export";
> }
> +
> +   if (state->ARB_sample_shading_enable) {
> +  add_input(VARYING_SLOT_SAMPLE_ID, int_t, "gl_SampleID");
> +  add_input(VARYING_SLOT_SAMPLE_POS, vec2_t, "gl_SamplePosition");
>

Can we make gl_SampleID and gl_SamplePosition system values (like
SYSTEM_VALUE_VERTEX_ID and SYSTEM_VALUE_INSTANCE_ID) instead of varyings?
They aren't really varyings at all (since they don't appear in any shader
stage except the fragment shader), and that way they won't take up space in
all the data structures that we use to represent varyings (such as the i965
VUE map).

With that fixed, and assuming that the other issues brought up by Ken and
Ian are addressed, this patch is:

Reviewed-by: Paul Berry 


> +  add_output(FRAG_RESULT_SAMPLE_MASK, array(int_t, 1),
> "gl_SampleMask");
> +   }
>  }
>
>
> diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
> index 4ba6d8a..3595a58 100644
> --- a/src/glsl/link_varyings.cpp
> +++ b/src/glsl/link_varyings.cpp
> @@ -938,6 +938,8 @@ is_varying_var(GLenum shaderType, const ir_variable
> *var)
>case VARYING_SLOT_POS:
>case VARYING_SLOT_FACE:
>case VARYING_SLOT_PNTC:
> +  case VARYING_SLOT_SAMPLE_ID:
> +  case VARYING_SLOT_SAMPLE_POS:
>   return false;
>default:
>   return true;
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 5520e86..65ec829 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -236,6 +236,8 @@ typedef enum
> VARYING_SLOT_LAYER, /* Appears as VS or GS output */
> VARYING_SLOT_FACE, /* FS only */
> VARYING_SLOT_PNTC, /* FS only */
> +   VARYING_SLOT_SAMPLE_ID, /* FS only */
> +   VARYING_SLOT_SAMPLE_POS, /* FS only */
> VARYING_SLOT_VAR0, /* First generic varying slot */
> VARYING_SLOT_MAX = VARYING_SLOT_VAR0 + MAX_VARYING
>  } gl_varying_slot;
> @@ -272,6 +274,8 @@ typedef enum
>  #define VARYING_BIT_FACE BITFIELD64_BIT(VARYING_SLOT_FACE)
>  #define VARYING_BIT_PNTC BITFIELD64_BIT(VARYING_SLOT_PNTC)
>  #define VARYING_BIT_VAR(V) BITFIELD64_BIT(VARYING_SLOT_VAR0 + (V))
> +#define VARYING_BIT_SAMPLE_ID BITFIELD64_BIT(VARYING_SLOT_SAMPLE_ID)
> +#define VARYING_BIT_SAMPLE_POS BITFIELD64_BIT(VARYING_SLOT_SAMPLE_POS)
>  /*@}*/
>
>
> @@ -306,12 +310,13 @@ typedef enum
>  * register is written.  No FRAG_RESULT_DATAn will be written.
>  */
> FRAG_RESULT_COLOR = 2,
> +   FRAG_RESULT_SAMPLE_MASK = 3,
>
> /* FRAG_RESULT_DATAn are the per-render-target (GLSL gl_FragD

Re: [Mesa-dev] [PATCH 5/8] i965/gs: Fix up gl_PointSize input swizzling for DUAL_INSTANCED gs.

[Paul Berry]

On 18 October 2013 17:04, Eric Anholt  wrote:

> Paul Berry  writes:
>
> > Geometry shaders that run in "DUAL_INSTANCED" mode store their inputs
> > in vec4's.  This means that when compiling gl_PointSize input
> > swizzling (a MOV instruction which uses a geometry shader input as
> > both source and destination), we need to do two things:
> >
> > - Set force_writemask_all to ensure that the MOV happens regardless of
> >   which channels are enabled.
> >
> > - Set the source register region to <4;4,1> (instead of <0;4,1> to
> >   satisfy register region restrictions.
>
> This sure sounds like something you empirically found, but I'm confused.
> I would have assumed that DUAL_INSTANCED with an instance count of 1
> meant that the channel enables the hardware gave you had the first 4
> enabled and the second 4 disabled.  And since the dst.width (and thus
> execsize) is 4, whether or not the second 4 are disabled wouldn't
> matter.  In that case, why do you need the writemask forced, since just
> the 4 channels you care about will be affected, anyway?
>

Setting force_writemask_all was not empirical--I did it out of general
caution. I couldn't find any documentation in the bspec to guarantee that
an instance count of 1 would get dispatched to the first 4 channels rather
than the second 4, and I didn't want to rely on undocumented behaviour.


>
> And, if dst.width == 4, then execsize == 4, and I'm confused what
> register region restriction is being honored by promoting the hstride to
> 4.
>

This part was empirical.  I discovered that if I don't set the hstride to
4, then I get an assertion failure here (in validate_reg() in
brw_eu_emit.c):

   /* 4. */
   if (execsize == width && hstride != 0) {
  assert(vstride == -1 || vstride == width * hstride);
   }

I don't know why the hardware cares about this, but I double-checked the
bspec and this restriction is really there.

Side note: I forgot to mention it in the comments, but in addition to
fixing up <0;4,1> -> <4;4,1>, this code fixes up <8;8,1> -> <4;4,1>.
That's necessary for a stupid reason: in the vec4 back-end we represent
GRFs as <8;8,1> so that guess_execution_size() will correctly guess an
execution size of 8.  However, in align16 mode, the hardware assumes a
width of 4, so it really needs to be <4;4,1>.  Normally, we fix that up in
brw_set_src0() and brw_set_src1(), but we do it *after* the call to
validate_reg().  So to avoid validate_reg() asserting on these width-4
instructions, we need to change the source register from <8;8,1> to <4;4,1>
before emitting the instruction.  One of these days, I swear I'm going to
get rid of guess_execution_size() so we can end this sort of madness.


>
> Putting these fixups for a couple of weird cases in just MOV and ADD
> feels wrong to me, but maybe when I understand better what's going on
> it'll seem more natural.
>

Another possibility I'd be equally happy with would be to put the fixup at
the top of vec4_generator::generate_vec4_instruction(), before the switch
statement.  It would look something like this:

   if (dst.width == BRW_WIDTH_4) {
  /* This happens in attribute fixups for "dual instanced" geometry
   * shaders, since they use attributes that are vec4's.  Since the exec
   * width is only 4, it's essential that the caller set
   * force_writemask_all in order to make sure the instruction is
executed
   * regardless of which channels are enabled.
   */
  assert(inst->force_writemask_all);

  /* Fix up any <8;8,1> or <0;4,1> source registers to <4;4,1> to
satisfy
   * the following register region restrictions (from Graphics BSpec:
   * 3D-Media-GPGPU Engine > EU Overview > Registers and Register
Regions
   * > Register Region Restrictions)
   *
   * 1. ExecSize must be greater than or equal to Width.
   *
   * 2. If ExecSize = Width and HorzStride != 0, VertStride must be
set
   *to Width * HorzStride."
   */
  for (int i = 0; i < 3; i++) {
 if (src[i].file == BRW_GENERAL_REGISTER_FILE)
src[i] = stride(src[i], 4, 4, 1);
  }
   }

Does that seem better to you?  I actually think I like it slightly better
because by making the assertion more general, I caught another case where I
think I should be setting force_writemask_all to be on the safe side (the
"clear r0.2" instruction in the gs prolog).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/8] i965/gs: If a DUAL_OBJECT gs would spill, fall back to DUAL_INSTANCED.

[Paul Berry]

On 18 October 2013 16:46, Eric Anholt  wrote:

> Paul Berry  writes:
> > Since most geometry shaders used in piglit testing are small,
> > DUAL_INSTANCED mode won't get exercised very much in a normal piglit
> > run.  To force DUAL_INSTANCED mode to be used for all geometry
> > shaders, set INTEL_DEBUG=nogualobj.
>
>^ nodualobj
>

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

Re: [Mesa-dev] [PATCH] glsl/linker: Allow mixing of desktop GLSL versions.

[Paul Berry]

On 18 October 2013 11:07, Ian Romanick  wrote:

> On 10/17/2013 08:07 PM, Paul Berry wrote:
> > Previously, Mesa followed the linkage rules outlined in the GLSL
> > 1.20-1.40 specs, which (collectively) said that GLSL versions 1.10 and
> > 1.20 could be linked together, but no other versions could be linked.
> >
> > In GLSL 4.30, the linkage rules were relaxed so that any two desktop
> > GLSL versions can be linked together.  This change was made because it
> > reflected the behaviour of nearly all existing implementations (see
> > Khronos bug 8463).  Mesa was one of the few (perhaps the only)
> > exceptions to prohibit cross-linking of some GLSL versions.
> >
> > Since the GLSL linkage rules were deliberately relaxed in order to
> > match the behaviour of existing implementations, it seems appropriate
> > to relax the rules in Mesa too (even though Mesa doesn't support GLSL
> > 4.30 yet).
> >
> > Note that linking ES and desktop shaders is still prohibited, as is
> > linking ES shaders having different GLSL versions.
> >
> > Fixes piglit tests "shaders/version-mixing {interstage,intrastage}".
>
> Are there any piglit tests that now fail?  It seems like we may have had
> one or two tests that verify the (old) spec behavior...
>

I would have thought so, but I just did a full piglit run and didn't get
any regressions, so I guess not.


>
> You should ping the reporter of this bug:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=70261
>
> This should fix his problem as well.
>

Good call.  I'll do that once I've landed the patch.


>
> > ---
> >  src/glsl/linker.cpp | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> > index 9095a40..0a949b4 100644
> > --- a/src/glsl/linker.cpp
> > +++ b/src/glsl/linker.cpp
> > @@ -2057,14 +2057,10 @@ link_shaders(struct gl_context *ctx, struct
> gl_shader_program *prog)
> >}
> > }
> >
> > -   /* Previous to GLSL version 1.30, different compilation units could
> mix and
> > -* match shading language versions.  With GLSL 1.30 and later, the
> versions
> > -* of all shaders must match.
> > -*
> > -* GLSL ES has never allowed mixing of shading language versions.
> > +   /* In desktop GLSL, different shader versions may be linked
> together.  In
> > +* GLSL ES, all shader versions must be the same.
> >  */
> > -   if ((is_es_prog || max_version >= 130)
> > -   && min_version != max_version) {
> > +   if (is_es_prog && min_version != max_version) {
> >linker_error(prog, "all shaders must use same shading "
> >  "language version\n");
> >goto done;
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/8] i965: Implement FS backend for ARB_sample_shading

[Paul Berry]

On 18 October 2013 10:30, Anuj Phogat  wrote:

> I know we can specify stride if we have a brw_reg :-
> fs_reg (stride(brw_vec1_grf(0, 0), 2, 4, 0));
>
> But I could not  find a reliable way to use stride if we have a fs_reg.
> That's why I used OR to get the desired result.
>

The right way to do this, IMHO, is to create a special back-end instruction
opcode to do the work.  That way you can put the call to stride() in
fs_generator, and it will happen after registers have been assigned and
everything has been turned into brw_reg's.  See for example what happens in
FS_OPCODE_SET_SIMD4X2_OFFSET, which does a similar thing except that
instead of changing the stride of the register it changes its width.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/8] i965: Implement FS backend for ARB_sample_shading

[Paul Berry]

On 14 October 2013 10:12, Anuj Phogat  wrote:

> Implement the FS backend for new builtins added by the extension:
> in vec2 gl_SamplePosition
> in int gl_SampleID
> in int gl_NumSamples
> out int gl_SampleMask[]
>

There is a lot going on in this one patch, and it's getting hard to follow
all the patch review that's going on.  If you wind up re-spinning this
patch series, can you please break it into four separate patches, one to
add support for each builtin?


>
> Signed-off-by: Anuj Phogat 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 109
> +++
>  src/mesa/drivers/dri/i965/brw_fs.h   |   4 +
>  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |  23 ++
>  src/mesa/drivers/dri/i965/brw_wm.h   |   1 +
>  4 files changed, 137 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index e5d6e4b..e4f7745 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -1115,6 +1115,109 @@
> fs_visitor::emit_frontfacing_interpolation(ir_variable *ir)
> return reg;
>  }
>
> +void
> +fs_visitor::compute_sample_position(fs_reg dst, fs_reg int_sample_pos)
> +{
> +   int num_samples = ctx->DrawBuffer->Visual.samples;
>

This isn't safe.  When compilation depends on a piece of GL state, you need
to include the state in brw_wm_prog_key.  Otherwise the program won't get
recompiled when the value changes.

To avoid unnecessary recompiles, I'd recommend adding a boolean to
brw_wm_prog_key which is:
- true if ctx->Multisample.Enabled && num_samples != 0 && (shader accesses
gl_SamplePosition)
- false otherwise


> +   assert(num_samples >= 0 && num_samples <= 8);
> +
> +   /* From arb_sample_shading specification:
> +* "When rendering to a non-multisample buffer, or if multisample
> +*  rasterization is disabled, gl_SamplePosition will always be
> +*  (0.5, 0.5).
> +*/
> +   if (!ctx->Multisample.Enabled || num_samples == 0) {
> +  emit(BRW_OPCODE_MOV, dst, fs_reg(0.5f));
>

It looks like you're using the old, more verbose style of emitting
instructions.  Can we convert this (and the other instructions in this
patch) to the more compact style:

emit(MOV(dst, fs_reg(0.5f)));



> +   }
> +   else {
> +  /* For num_samples = {4, 8} */
> +  emit(BRW_OPCODE_MOV, dst, int_sample_pos);
> +  emit(BRW_OPCODE_MUL, dst, dst, fs_reg(1 / 16.0f));
>

Like Ken, I was confused as to why we needed a separate MOV before the
MUL.  The assertion Ken recommended would have been a useful clue, but I'd
prefer to just have explicit comments explaining why we need the MOV.  How
about this:

/* Convert int_sample_pos to floating point */
emit(BRW_OPCODE_MOV, dst, int_sample_pos);
/* Scale to the range [0, 1] */
emit(BRW_OPCODE_MUL, dst, dst, fs_reg(1 / 16.0f));


> +   }
> +}
> +
> +fs_reg *
> +fs_visitor::emit_samplepos_interpolation(ir_variable *ir)
> +{
> +   assert(brw->gen >= 6);
> +
> +   this->current_annotation = "compute sample position";
> +   fs_reg *reg = new(this->mem_ctx) fs_reg(this, ir->type);
>

Since this code assigns to two consecutive registers, it relies on the fact
that ir->type is vec2.  Just to make that explicit, can we add:

assert(ir->type == glsl_type::vec2_type);


> +   fs_reg pos = *reg;
> +   fs_reg int_sample_x = fs_reg(this, glsl_type::int_type);
> +   fs_reg int_sample_y = fs_reg(this, glsl_type::int_type);
> +
> +   /* WM will be run in MSDISPMODE_PERSAMPLE. So, only SIMD8 mode will be
> +* enabled. The X, Y sample positions come in as bytes in  thread
> payload.
> +* Sample IDs and sample positions remain same for all four slots in a
> +* subspan. So, read the positions using vstride=2, width=4, hstride=0.
>

I have similar concerns to Ken about why MSDISPMODE_PERSAMPLE implies that
only SIMD8 mode will be enabled.  I'm assuming the two of you have
adequately resolved that.


> +*/
> +   emit(BRW_OPCODE_AND, int_sample_x,
> +fs_reg(stride(retype(brw_vec1_grf(c->sample_pos_reg, 0),
> + BRW_REGISTER_TYPE_D), 2, 4, 0)),
> +fs_reg(brw_imm_d(0xff)));
>

If I understand correctly, this is creating the instruction

AND(8) int_sample_x<1>:d sample_pos_reg<2;4,0>:d 0x00ff:d

I think this works, but it would be more straightforward to do this, which
just selects the X coordinate bytes from the sample_pos_reg register:

MOV(8) int_sample_x<1>:d sample_pos_reg<16;8,2>:b

That would have the advantage that it doesn't rely on the fact that sample
IDs and sample positions are the same for all four slots in a subspan.

(Note: there are some weird restrictions on byte operations, and I can't
remember all the details.  So you might need to try this in the simulator
and tweak it to get it to work.)


> +
> +   /* Compute gl_SamplePosition.x */
> +   compute_sample_position(pos, int_sample_x);
> +   pos.reg_offset++;
>

I think if we change this to:

pos.reg_offset += dispatch_width / 8;

t

Re: [Mesa-dev] [PATCH 6/8] i965/gen6: Enable the features required for GL_ARB_sample_shading

[Paul Berry]

On 14 October 2013 10:12, Anuj Phogat  wrote:

> - Enable GEN6_WM_MSDISPMODE_PERSAMPLE, GEN6_WM_POSOFFSET_SAMPLE,
>   GEN6_WM_OMASK_TO_RENDER_TARGET as per extension's specification.
> - Don't enable GEN6_WM_16_DISPATCH_ENABLE when GEN6_WM_MSDISPMODE_PERSAMPLE
>   is enabled. Refer SNB PRM Vol. 2, Part 1, Page 279 for details.
>
> Signed-off-by: Anuj Phogat 
> ---
>  src/mesa/drivers/dri/i965/gen6_wm_state.c | 67
> +--
>  1 file changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c
> b/src/mesa/drivers/dri/i965/gen6_wm_state.c
> index c96a107..4bc25d6 100644
> --- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
> @@ -103,6 +103,7 @@ upload_wm_state(struct brw_context *brw)
>
> /* _NEW_BUFFERS */
> bool multisampled_fbo = ctx->DrawBuffer->Visual.samples > 1;
> +   bool msdispmode_persample = false;
>
>  /* CACHE_NEW_WM_PROG */
> if (brw->wm.prog_data->nr_params == 0) {
> @@ -156,7 +157,17 @@ upload_wm_state(struct brw_context *brw)
>
> /* CACHE_NEW_WM_PROG */
> dw5 |= GEN6_WM_8_DISPATCH_ENABLE;
> -   if (brw->wm.prog_data->prog_offset_16)
> +   msdispmode_persample =
> +  ctx->Multisample.Enabled &&
> +  (ctx->Multisample.SampleShading ||
> +   brw->fragment_program->Base.InputsRead & VARYING_BIT_SAMPLE_ID ||
> +   brw->fragment_program->Base.InputsRead & VARYING_BIT_SAMPLE_POS);
>

The dependency on ctx->Multisample.SampleShading isn't quite right.  You
also need to account for the value of
ctx->Multisample.MinSampleShadingValue.  I believe the correct expression
is something like:

(ctx->Multisample.SampleShading &&
ceil(ctx->Multisample.MinSampleShadingValue *
ctx->DrawBuffer->Visual.samples) > 1)

This is necessary to ensure that if, for example, the buffer is 4xMSAA and
the client sets MinSampleShadingARB to 0.25 or less, we still get
per-fragment shading.


> +
> +   /* In case of non 1x (i.e 4x, 8x) multisampling with
> MDISPMODE_PERSAMPLE,
> +* only one of SIMD8 and SIMD16 should be enabled.
> +*/
> +   if (brw->wm.prog_data->prog_offset_16 &&
> +   !(multisampled_fbo && msdispmode_persample))
>dw5 |= GEN6_WM_16_DISPATCH_ENABLE;
>
> /* CACHE_NEW_WM_PROG | _NEW_COLOR */
> @@ -185,7 +196,10 @@ upload_wm_state(struct brw_context *brw)
>
> /* _NEW_COLOR, _NEW_MULTISAMPLE */
> if (fp->program.UsesKill || ctx->Color.AlphaEnabled ||
> -   ctx->Multisample.SampleAlphaToCoverage)
> +   ctx->Multisample.SampleAlphaToCoverage ||
> +   (ctx->Multisample.SampleShading &&
> +(fp->program.Base.OutputsWritten &
> + BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK
>dw5 |= GEN6_WM_KILL_ENABLE;
>

There's a problem here.  The bspec says "This bit is required to be ENABLED
in the following situations: ... The pixel shader kernel generates and
outputs oMask.".  That means you need to use the same boolean expression
here to determine whether to turn on GEN6_WM_KILL_ENABLE as you do in patch
5 (in fs_visitor::emit_fb_writes()) to decide whether to output oMask.

But here you're using (ctx->Multisample.SampleShading &&
(fp->program.Base.OutputsWritten & BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK)))

Whereas in patch 5 you just use (fp->program.Base.OutputsWritten &
BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK))

I believe the expression in patch 5 is the correct one, because
gl_SampleMask should still be able to kill samples even if we're not using
per-sample shading.

To avoid bugs like this, I recommend adding a boolean to brw_wm_prog_data
to indicate whether the fragment shader outputs an oMask (let's say we call
it "uses_omask").  fs_visitor::emit_fb_writes() should set it to true if
it's outputting oMask.  Then, here in gen6_wm_state.c, rather than having
to duplicate the boolean expression (and risking bugs if you don't get it
right), you can just refer brw->wm.prog_data->uses_omask.  We already use a
similar mechanism for keeping track of whether dual source blending is
enabled (see the dual_src_blend boolean in brw_wm_prog_data).


>
> if (brw_color_buffer_write_enabled(brw) ||
> @@ -193,6 +207,19 @@ upload_wm_state(struct brw_context *brw)
>dw5 |= GEN6_WM_DISPATCH_ENABLE;
> }
>
> +   /* From the SNB PRM, volume 2 part 1, page 278:
> +* "This bit is inserted in the PS payload header and made available to
> +* the DataPort (either via the message header or via header bypass) to
> +* indicate that oMask data (one or two phases) is included in Render
> +* Target Write messages. If present, the oMask data is used to mask
> off
> +* samples."
> +* TODO: [DevSNB:A0] This bit must be disabled in A Step.
> +*/
> +   if (ctx->Extensions.ARB_sample_shading &&
> +   (brw->fragment_program->Base.OutputsWritten &
> +BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK)))
> +  dw5 |= GEN6_WM_OMASK_TO_RENDER_TARGET;
> +
>

The dependency on ctx->Extensions.ARB_sample_shading 

Re: [Mesa-dev] [PATCH 7/8] i965/gen7: Enable the features required for GL_ARB_sample_shading

[Paul Berry]

On 14 October 2013 10:12, Anuj Phogat  wrote:

> - Enable GEN7_WM_MSDISPMODE_PERSAMPLE, GEN7_WM_POSOFFSET_SAMPLE,
>   GEN7_WM_OMASK_TO_RENDER_TARGET as per extension's specification.
> - Don't enable GEN7_WM_16_DISPATCH_ENABLE when GEN7_WM_MSDISPMODE_PERSAMPLE
>   is enabled. Refer IVB PRM Vol. 2, Part 1, Page 288 for details.
>
> Signed-off-by: Anuj Phogat 
>

My comments on patch 6 apply here as well.


> ---
>  src/mesa/drivers/dri/i965/gen7_wm_state.c | 70
> +--
>  1 file changed, 67 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
> b/src/mesa/drivers/dri/i965/gen7_wm_state.c
> index a2046c3..0267e0e 100644
> --- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
> @@ -82,9 +82,15 @@ upload_wm_state(struct brw_context *brw)
>GEN7_WM_BARYCENTRIC_INTERPOLATION_MODE_SHIFT;
>
> /* _NEW_COLOR, _NEW_MULTISAMPLE */
> +   /* Enable if the pixel shader kernel generates and outputs oMask.
> +*/
> if (fp->program.UsesKill || ctx->Color.AlphaEnabled ||
> -   ctx->Multisample.SampleAlphaToCoverage)
> +   ctx->Multisample.SampleAlphaToCoverage ||
> +   (ctx->Multisample.SampleShading &&
> +(fp->program.Base.OutputsWritten &
> + BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK {
>dw1 |= GEN7_WM_KILL_ENABLE;
> +   }
>
> /* _NEW_BUFFERS */
> if (brw_color_buffer_write_enabled(brw) || writes_depth ||
> @@ -97,7 +103,25 @@ upload_wm_state(struct brw_context *brw)
>   dw1 |= GEN7_WM_MSRAST_ON_PATTERN;
>else
>   dw1 |= GEN7_WM_MSRAST_OFF_PIXEL;
> -  dw2 |= GEN7_WM_MSDISPMODE_PERPIXEL;
> +  /* From arb_sample_shading specification:
> +   * "If MULTISAMPLE or SAMPLE_SHADING_ARB is disabled, sample shading
> +   *  has no effect."
> +   *
> +   * "Using gl_SampleID in a fragment shader causes the entire shader
> +   *  to be evaluated per-sample."
> +   * "Using gl_SamplePosition in a fragment shader causes the entire
> +   *  shader to be evaluated per-sample."
> +   *
> +   *  I interprate the above four lines as enable the sample shading
> +   *  if fragment shader uses gl_SampleID or gl_SamplePosition.
> +   */
> +  if (ctx->Multisample.Enabled &&
> +  (ctx->Multisample.SampleShading ||
> +   brw->fragment_program->Base.InputsRead & VARYING_BIT_SAMPLE_ID
> ||
> +   brw->fragment_program->Base.InputsRead &
> VARYING_BIT_SAMPLE_POS))
> + dw2 |= GEN7_WM_MSDISPMODE_PERSAMPLE;
> +  else
> + dw2 |= GEN7_WM_MSDISPMODE_PERPIXEL;
> } else {
>dw1 |= GEN7_WM_MSRAST_OFF_PIXEL;
>dw2 |= GEN7_WM_MSDISPMODE_PERSAMPLE;
> @@ -129,6 +153,8 @@ upload_ps_state(struct brw_context *brw)
> uint32_t dw2, dw4, dw5;
> const int max_threads_shift = brw->is_haswell ?
>HSW_PS_MAX_THREADS_SHIFT : IVB_PS_MAX_THREADS_SHIFT;
> +   bool msdispmode_persample = false;
> +   bool multisampled_fbo = ctx->DrawBuffer->Visual.samples > 1;
>
> /* BRW_NEW_PS_BINDING_TABLE */
> BEGIN_BATCH(2);
> @@ -169,6 +195,34 @@ upload_ps_state(struct brw_context *brw)
> if (brw->wm.prog_data->nr_params > 0)
>dw4 |= GEN7_PS_PUSH_CONSTANT_ENABLE;
>
> +   /* From the IVB PRM, volume 2 part 1, page 287:
> +* "This bit is inserted in the PS payload header and made available to
> +* the DataPort (either via the message header or via header bypass) to
> +* indicate that oMask data (one or two phases) is included in Render
> +* Target Write messages. If present, the oMask data is used to mask
> off
> +* samples."
> +*/
> +   if (ctx->Extensions.ARB_sample_shading &&
> +   (brw->fragment_program->Base.OutputsWritten &
> +BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK)))
> +  dw4 |= GEN7_PS_OMASK_TO_RENDER_TARGET;
> +
> +   /* From the IVB PRM, volume 2 part 1, page 287:
> +* "If the PS kernel does not need the Position XY Offsets to
> +* compute a Position Value, then this field should be programmed
> +* to POSOFFSET_NONE."
> +* "SW Recommendation: If the PS kernel needs the Position Offsets
> +* to compute a Position XY value, this field should match Position
> +* ZW Interpolation Mode to ensure a consistent position.xyzw
> +* computation."
> +* We only require XY sample offsets. So, this recommendation doesn't
> +* look useful at the moment. We might need this in future.
> +*/
> +   if (brw->fragment_program->Base.InputsRead & VARYING_BIT_SAMPLE_POS)
> +  dw4 |= GEN7_PS_POSOFFSET_SAMPLE;
> +   else
> +  dw4 |= GEN7_PS_POSOFFSET_NONE;
> +
> /* CACHE_NEW_WM_PROG | _NEW_COLOR
>  *
>  * The hardware wedges if you have this bit set but don't turn on any
> dual
> @@ -185,7 +239,17 @@ upload_ps_state(struct brw_context *brw)
>dw4 |= GEN7_PS_ATTRIBUTE_ENABLE;
>
> dw4 |= GEN7_PS_8_DISPATCH_ENABLE;
> -   if (brw->wm.prog_data->prog_offset_16)
> +   

Re: [Mesa-dev] [PATCH 7/8] i965/gen7: Enable the features required for GL_ARB_sample_shading

[Paul Berry]

On 16 October 2013 15:20, Ian Romanick  wrote:

> On 10/16/2013 02:57 PM, Anuj Phogat wrote:
> > On Tue, Oct 15, 2013 at 3:48 PM, Kenneth Graunke 
> wrote:
> >> On 10/14/2013 10:12 AM, Anuj Phogat wrote:
> >>> - Enable GEN7_WM_MSDISPMODE_PERSAMPLE, GEN7_WM_POSOFFSET_SAMPLE,
> >>>   GEN7_WM_OMASK_TO_RENDER_TARGET as per extension's specification.
> >>> - Don't enable GEN7_WM_16_DISPATCH_ENABLE when
> GEN7_WM_MSDISPMODE_PERSAMPLE
> >>>   is enabled. Refer IVB PRM Vol. 2, Part 1, Page 288 for details.
> >>>
> >>> Signed-off-by: Anuj Phogat 
> >>> ---
> >>>  src/mesa/drivers/dri/i965/gen7_wm_state.c | 70
> +--
> >>>  1 file changed, 67 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
> b/src/mesa/drivers/dri/i965/gen7_wm_state.c
> >>> index a2046c3..0267e0e 100644
> >>> --- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
> >>> +++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
> >>> @@ -82,9 +82,15 @@ upload_wm_state(struct brw_context *brw)
> >>>GEN7_WM_BARYCENTRIC_INTERPOLATION_MODE_SHIFT;
> >>>
> >>> /* _NEW_COLOR, _NEW_MULTISAMPLE */
> >>> +   /* Enable if the pixel shader kernel generates and outputs oMask.
> >>> +*/
> >>> if (fp->program.UsesKill || ctx->Color.AlphaEnabled ||
> >>> -   ctx->Multisample.SampleAlphaToCoverage)
> >>> +   ctx->Multisample.SampleAlphaToCoverage ||
> >>> +   (ctx->Multisample.SampleShading &&
> >>> +(fp->program.Base.OutputsWritten &
> >>> + BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK {
> >>>dw1 |= GEN7_WM_KILL_ENABLE;
> >>> +   }
> >>>
> >>> /* _NEW_BUFFERS */
> >>> if (brw_color_buffer_write_enabled(brw) || writes_depth ||
> >>> @@ -97,7 +103,25 @@ upload_wm_state(struct brw_context *brw)
> >>>   dw1 |= GEN7_WM_MSRAST_ON_PATTERN;
> >>>else
> >>>   dw1 |= GEN7_WM_MSRAST_OFF_PIXEL;
> >>> -  dw2 |= GEN7_WM_MSDISPMODE_PERPIXEL;
> >>> +  /* From arb_sample_shading specification:
> >>> +   * "If MULTISAMPLE or SAMPLE_SHADING_ARB is disabled, sample
> shading
> >>> +   *  has no effect."
> >>> +   *
> >>> +   * "Using gl_SampleID in a fragment shader causes the entire
> shader
> >>> +   *  to be evaluated per-sample."
> >>> +   * "Using gl_SamplePosition in a fragment shader causes the
> entire
> >>> +   *  shader to be evaluated per-sample."
> >>> +   *
> >>> +   *  I interprate the above four lines as enable the sample
> shading
> >>> +   *  if fragment shader uses gl_SampleID or gl_SamplePosition.
> >>> +   */
> >>> +  if (ctx->Multisample.Enabled &&
> >>> +  (ctx->Multisample.SampleShading ||
> >>> +   brw->fragment_program->Base.InputsRead &
> VARYING_BIT_SAMPLE_ID ||
> >>> +   brw->fragment_program->Base.InputsRead &
> VARYING_BIT_SAMPLE_POS))
> >>> + dw2 |= GEN7_WM_MSDISPMODE_PERSAMPLE;
> >>> +  else
> >>> + dw2 |= GEN7_WM_MSDISPMODE_PERPIXEL;
> >>> } else {
> >>>dw1 |= GEN7_WM_MSRAST_OFF_PIXEL;
> >>>dw2 |= GEN7_WM_MSDISPMODE_PERSAMPLE;
> >>> @@ -129,6 +153,8 @@ upload_ps_state(struct brw_context *brw)
> >>> uint32_t dw2, dw4, dw5;
> >>> const int max_threads_shift = brw->is_haswell ?
> >>>HSW_PS_MAX_THREADS_SHIFT : IVB_PS_MAX_THREADS_SHIFT;
> >>> +   bool msdispmode_persample = false;
> >>> +   bool multisampled_fbo = ctx->DrawBuffer->Visual.samples > 1;
> >>>
> >>> /* BRW_NEW_PS_BINDING_TABLE */
> >>> BEGIN_BATCH(2);
> >>> @@ -169,6 +195,34 @@ upload_ps_state(struct brw_context *brw)
> >>> if (brw->wm.prog_data->nr_params > 0)
> >>>dw4 |= GEN7_PS_PUSH_CONSTANT_ENABLE;
> >>>
> >>> +   /* From the IVB PRM, volume 2 part 1, page 287:
> >>> +* "This bit is inserted in the PS payload header and made
> available to
> >>> +* the DataPort (either via the message header or via header
> bypass) to
> >>> +* indicate that oMask data (one or two phases) is included in
> Render
> >>> +* Target Write messages. If present, the oMask data is used to
> mask off
> >>> +* samples."
> >>> +*/
> >>> +   if (ctx->Extensions.ARB_sample_shading &&
> >>> +   (brw->fragment_program->Base.OutputsWritten &
> >>> +BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK)))
> >>> +  dw4 |= GEN7_PS_OMASK_TO_RENDER_TARGET;
> >>> +
> >>> +   /* From the IVB PRM, volume 2 part 1, page 287:
> >>> +* "If the PS kernel does not need the Position XY Offsets to
> >>> +* compute a Position Value, then this field should be programmed
> >>> +* to POSOFFSET_NONE."
> >>> +* "SW Recommendation: If the PS kernel needs the Position Offsets
> >>> +* to compute a Position XY value, this field should match Position
> >>> +* ZW Interpolation Mode to ensure a consistent position.xyzw
> >>> +* computation."
> >>> +* We only require XY sample offsets. So, this recommendation
> doesn't
> >>> +* look useful at the moment. We might need this in future.
> >>> +*/

Re: [Mesa-dev] [PATCH 6/8] i965/gen6: Enable the features required for GL_ARB_sample_shading

[Paul Berry]

On 20 October 2013 07:25, Paul Berry  wrote:

> On 14 October 2013 10:12, Anuj Phogat  wrote:
>
>> - Enable GEN6_WM_MSDISPMODE_PERSAMPLE, GEN6_WM_POSOFFSET_SAMPLE,
>>   GEN6_WM_OMASK_TO_RENDER_TARGET as per extension's specification.
>> - Don't enable GEN6_WM_16_DISPATCH_ENABLE when
>> GEN6_WM_MSDISPMODE_PERSAMPLE
>>   is enabled. Refer SNB PRM Vol. 2, Part 1, Page 279 for details.
>>
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/mesa/drivers/dri/i965/gen6_wm_state.c | 67
>> +--
>>  1 file changed, 64 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c
>> b/src/mesa/drivers/dri/i965/gen6_wm_state.c
>> index c96a107..4bc25d6 100644
>> --- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
>> +++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
>> @@ -103,6 +103,7 @@ upload_wm_state(struct brw_context *brw)
>>
>> /* _NEW_BUFFERS */
>> bool multisampled_fbo = ctx->DrawBuffer->Visual.samples > 1;
>> +   bool msdispmode_persample = false;
>>
>>  /* CACHE_NEW_WM_PROG */
>> if (brw->wm.prog_data->nr_params == 0) {
>> @@ -156,7 +157,17 @@ upload_wm_state(struct brw_context *brw)
>>
>> /* CACHE_NEW_WM_PROG */
>> dw5 |= GEN6_WM_8_DISPATCH_ENABLE;
>> -   if (brw->wm.prog_data->prog_offset_16)
>> +   msdispmode_persample =
>> +  ctx->Multisample.Enabled &&
>> +  (ctx->Multisample.SampleShading ||
>> +   brw->fragment_program->Base.InputsRead & VARYING_BIT_SAMPLE_ID ||
>> +   brw->fragment_program->Base.InputsRead & VARYING_BIT_SAMPLE_POS);
>>
>
> The dependency on ctx->Multisample.SampleShading isn't quite right.  You
> also need to account for the value of
> ctx->Multisample.MinSampleShadingValue.  I believe the correct expression
> is something like:
>
> (ctx->Multisample.SampleShading &&
> ceil(ctx->Multisample.MinSampleShadingValue *
> ctx->DrawBuffer->Visual.samples) > 1)
>
> This is necessary to ensure that if, for example, the buffer is 4xMSAA and
> the client sets MinSampleShadingARB to 0.25 or less, we still get
> per-fragment shading.
>

My suggestion on patch 7 about _mesa_get_min_invocations_per_fragment(...)
should also be sufficient to take care of this.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/8] Implement GL_ARB_sample_shading on Intel hardware

[Paul Berry]

On 14 October 2013 10:12, Anuj Phogat  wrote:

> Patches listed below implement the GL_ARB_sample_shading extension
> on Intel hardware >= gen6. I verified the implementation with a
> number of piglit tests, currently under review on piglit mailing
> list. Observed no piglit, gles3 CTS regressions with these patches
> on SNB & IVB.
> These patches can also be found at my github branch:
> https://github.com/aphogat/mesa.git branch: sample-shading-5
>
> Anuj Phogat (8):
>   mesa: Add infrastructure for GL_ARB_sample_shading
>   mesa: Add new functions and enums required by GL_ARB_sample_shading
>   mesa: Pass number of samples as a program state variable
>   glsl: Add new builtins required by GL_ARB_sample_shading
>   i965: Implement FS backend for ARB_sample_shading
>   i965/gen6: Enable the features required for GL_ARB_sample_shading
>   i965/gen7: Enable the features required for GL_ARB_sample_shading
>   i965: Enable ARB_sample_shading on intel hardware >= gen6
>

I sent out comments on patches 3-7.  Patch 8 is:

Reviewed-by: Paul Berry 

I'll defer to the others' expertise on patches 1-2.

Thanks for your hard work on this, Anuj!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glsl: Use saved values instead of recomputing them.

[Paul Berry]

On 16 October 2013 16:56, Matt Turner  wrote:

> ---
>  src/glsl/opt_algebraic.cpp | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
>

Series is:

Reviewed-by: Paul Berry 


>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index 3e5802e..b915f3c 100644
> --- a/src/glsl/opt_algebraic.cpp
> +++ b/src/glsl/opt_algebraic.cpp
> @@ -257,11 +257,9 @@ ir_algebraic_visitor::handle_expression(ir_expression
> *ir)
> * folding.
> */
>if (op_const[0] && !op_const[1])
> -reassociate_constant(ir, 0, op_const[0],
> - ir->operands[1]->as_expression());
> +reassociate_constant(ir, 0, op_const[0], op_expr[1]);
>if (op_const[1] && !op_const[0])
> -reassociate_constant(ir, 1, op_const[1],
> - ir->operands[0]->as_expression());
> +reassociate_constant(ir, 1, op_const[1], op_expr[0]);
>break;
>
> case ir_binop_sub:
> @@ -315,11 +313,9 @@ ir_algebraic_visitor::handle_expression(ir_expression
> *ir)
> * constant folding.
> */
>if (op_const[0] && !op_const[1])
> -reassociate_constant(ir, 0, op_const[0],
> - ir->operands[1]->as_expression());
> +reassociate_constant(ir, 0, op_const[0], op_expr[1]);
>if (op_const[1] && !op_const[0])
> -reassociate_constant(ir, 1, op_const[1],
> - ir->operands[0]->as_expression());
> +reassociate_constant(ir, 1, op_const[1], op_expr[0]);
>
>break;
>
> --
> 1.8.3.2
>
> ___
> 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] glsl: mark variables produced by lower_named_interface_blocks.

[Paul Berry]

These variables will need to be treated specially by
program_resource_visitor, so that they can be addressed through the
API using their interface block name (and array index, for interface
block arrays).
---
 src/glsl/ir.h | 12 
 src/glsl/lower_named_interface_blocks.cpp |  2 ++
 2 files changed, 14 insertions(+)

diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index aac8cbb..91eb4c6 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -579,6 +579,18 @@ public:
unsigned location_frac:2;
 
/**
+* Non-zero if this variable was created by lowering a named interface
+* block which was not an array.
+*/
+   unsigned from_named_ifc_block_nonarray:1;
+
+   /**
+* Non-zero if this variable was created by lowering a named interface
+* block which was an array.
+*/
+   unsigned from_named_ifc_block_array:1;
+
+   /**
 * \brief Layout qualifier for gl_FragDepth.
 *
 * This is not equal to \c ir_depth_layout_none if and only if this
diff --git a/src/glsl/lower_named_interface_blocks.cpp 
b/src/glsl/lower_named_interface_blocks.cpp
index f415252..6329d5a 100644
--- a/src/glsl/lower_named_interface_blocks.cpp
+++ b/src/glsl/lower_named_interface_blocks.cpp
@@ -140,6 +140,7 @@ flatten_named_interface_blocks_declarations::run(exec_list 
*instructions)
   new(mem_ctx) ir_variable(iface_t->fields.structure[i].type,
var_name,
(ir_variable_mode) var->mode);
+   new_var->from_named_ifc_block_nonarray = 1;
 } else {
const glsl_type *new_array_type =
   glsl_type::get_array_instance(
@@ -149,6 +150,7 @@ flatten_named_interface_blocks_declarations::run(exec_list 
*instructions)
   new(mem_ctx) ir_variable(new_array_type,
var_name,
(ir_variable_mode) var->mode);
+   new_var->from_named_ifc_block_array = 1;
 }
 new_var->location = iface_t->fields.structure[i].location;
 
-- 
1.8.4.1

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