Re: [Mesa-dev] [PATCH v4 (part2) 21/59] glsl: propagate interface packing information to arrays of scalars, vectors.

2015-08-29 Thread Jordan Justen
On 2015-08-05 01:30:18, Iago Toral Quiroga wrote:
 From: Samuel Iglesias Gonsalvez sigles...@igalia.com
 
 Now std140 is not the only interface packing qualifier that can be used.
 
 Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
 ---
  src/glsl/ast.h  | 10 +
  src/glsl/ast_to_hir.cpp | 54 
 +
  src/glsl/glsl_types.cpp | 14 ++---
  src/glsl/glsl_types.h   |  8 ++--
  4 files changed, 68 insertions(+), 18 deletions(-)
 
 diff --git a/src/glsl/ast.h b/src/glsl/ast.h
 index ac3f80f..ad6e300 100644
 --- a/src/glsl/ast.h
 +++ b/src/glsl/ast.h
 @@ -730,6 +730,11 @@ public:
  struct _mesa_glsl_parse_state *state)
const;
  
 +   const struct glsl_type *glsl_type(const char **name,
 + struct _mesa_glsl_parse_state *state,
 + enum glsl_interface_packing packing)
 +  const;
 +
 virtual void print(void) const;
  
 ir_rvalue *hir(exec_list *, struct _mesa_glsl_parse_state *);
 @@ -757,6 +762,11 @@ public:
  struct _mesa_glsl_parse_state *state)
const;
  
 +   const struct glsl_type *glsl_type(const char **name,
 + struct _mesa_glsl_parse_state *state,
 + enum glsl_interface_packing packing)
 +  const;
 +
 ast_type_qualifier qualifier;
 ast_type_specifier *specifier;
  };
 diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
 index 2dadb03..193098a 100644
 --- a/src/glsl/ast_to_hir.cpp
 +++ b/src/glsl/ast_to_hir.cpp
 @@ -1951,10 +1951,15 @@ process_array_size(exec_node *node,
  static const glsl_type *
  process_array_type(YYLTYPE *loc, const glsl_type *base,
 ast_array_specifier *array_specifier,
 -   struct _mesa_glsl_parse_state *state)
 +   struct _mesa_glsl_parse_state *state,
 +   enum glsl_interface_packing packing)
  {
 const glsl_type *array_type = base;
  
 +   /* Mesa uses std140 interface packing by default. */
 +   if (packing != GLSL_INTERFACE_PACKING_STD430)
 +  packing = GLSL_INTERFACE_PACKING_STD140;

I wonder if we should let drivers decide if they want to use std430
packing for 'shared' and 'packed'?

Maybe the comment should mention packed/shared?

 +
 if (array_specifier != NULL) {
if (base-is_array()) {
  
 @@ -1983,11 +1988,12 @@ process_array_type(YYLTYPE *loc, const glsl_type 
 *base,
for (exec_node *node = array_specifier-array_dimensions.tail_pred;
 !node-is_head_sentinel(); node = node-prev) {
   unsigned array_size = process_array_size(node, state);
 - array_type = glsl_type::get_array_instance(array_type, array_size);
 + array_type = glsl_type::get_array_instance(array_type, array_size,
 +packing);
}
  
if (array_specifier-is_unsized_array)
 - array_type = glsl_type::get_array_instance(array_type, 0);
 + array_type = glsl_type::get_array_instance(array_type, 0, packing);
 }
  
 return array_type;
 @@ -1998,13 +2004,22 @@ const glsl_type *
  ast_type_specifier::glsl_type(const char **name,
struct _mesa_glsl_parse_state *state) const
  {
 +   return glsl_type(name, state, GLSL_INTERFACE_PACKING_STD140);
 +}
 +
 +const glsl_type *
 +ast_type_specifier::glsl_type(const char **name,
 +  struct _mesa_glsl_parse_state *state,
 +  enum glsl_interface_packing packing) const
 +{
 const struct glsl_type *type;
  
 type = state-symbols-get_type(this-type_name);
 *name = this-type_name;
  
 YYLTYPE loc = this-get_location();
 -   type = process_array_type(loc, type, this-array_specifier, state);
 +   type = process_array_type(loc, type, this-array_specifier, state,
 + packing);
  
 return type;
  }
 @@ -2013,7 +2028,14 @@ const glsl_type *
  ast_fully_specified_type::glsl_type(const char **name,
  struct _mesa_glsl_parse_state *state) 
 const
  {
 -   const struct glsl_type *type = this-specifier-glsl_type(name, state);
 +   return glsl_type(name, state, GLSL_INTERFACE_PACKING_STD140);
 +}
 +const glsl_type *
 +ast_fully_specified_type::glsl_type(const char **name,
 +struct _mesa_glsl_parse_state *state,
 +enum glsl_interface_packing packing) 
 const
 +{
 +   const struct glsl_type *type = this-specifier-glsl_type(name, state, 
 packing);
  
 if (type == NULL)
return NULL;
 @@ -3638,7 +3660,7 @@ ast_declarator_list::hir(exec_list *instructions,
  
}
var_type = process_array_type(loc, decl_type, decl-array_specifier,
 -state);
 +   

[Mesa-dev] [PATCH 03/12] i965: Delete the brw_vue_program_key::userclip_active flag.

2015-08-29 Thread Kenneth Graunke
There are two uses of this flag.

The primary use is checking whether we need to emit code to convert
legacy gl_ClipVertex/gl_Position clipping to clip distances.  In this
case, we also have to upload the clip planes as uniforms, which means
setting nr_userclip_plane_consts to a positive value.  Checking if it's
 0 works for detecting this case.

Gen4-5 also wants to know whether we're doing clipping at all, so it can
emit user clip flags.  Checking if output_reg[VARYING_SLOT_CLIP_DIST0]
is set to a real register suffices for this.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |  2 +-
 src/mesa/drivers/dri/i965/brw_program.h|  9 +++--
 src/mesa/drivers/dri/i965/brw_vec4.cpp |  2 +-
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  7 ---
 src/mesa/drivers/dri/i965/brw_vs.c | 17 ++---
 5 files changed, 15 insertions(+), 22 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 504673f..7100646 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -810,7 +810,7 @@ void fs_visitor::compute_clip_distance(gl_clip_plane 
*clip_planes)
   (const struct brw_vue_prog_key *) this-key;
 
/* Bail unless some sort of legacy clipping is enabled */
-   if (!key-userclip_active || prog-UsesClipDistanceOut)
+   if (key-nr_userclip_plane_consts == 0)
   return;
 
/* From the GLSL 1.30 spec, section 7.1 (Vertex Shader Special Variables):
diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index bfcd1c9..5ebf922 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -82,14 +82,11 @@ struct brw_vue_prog_key {
unsigned program_string_id;
 
/**
-* True if at least one clip flag is enabled, regardless of whether the
-* shader uses clip planes or gl_ClipDistance.
-*/
-   bool userclip_active:1;
-
-   /**
 * How many user clipping planes are being uploaded to the vertex shader as
 * push constants.
+*
+* These are used for lowering legacy gl_ClipVertex/gl_Position clipping to
+* clip distances.
 */
unsigned nr_userclip_plane_consts:4;
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index b97b6c1..4f5e85b 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1748,7 +1748,7 @@ vec4_visitor::run(gl_clip_plane *clip_planes)
}
base_ir = NULL;
 
-   if (key-userclip_active  !prog-UsesClipDistanceOut)
+   if (key-nr_userclip_plane_consts  0)
   setup_uniform_clipplane_values(clip_planes);
 
emit_thread_end();
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index ca86e8b..4d3d281 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -3121,7 +3121,8 @@ vec4_visitor::emit_psiz_and_flags(dst_reg reg)
 {
if (devinfo-gen  6 
((prog_data-vue_map.slots_valid  VARYING_BIT_PSIZ) ||
-key-userclip_active || devinfo-has_negative_rhw_bug)) {
+output_reg[VARYING_SLOT_CLIP_DIST0].file != BAD_FILE ||
+devinfo-has_negative_rhw_bug)) {
   dst_reg header1 = dst_reg(this, glsl_type::uvec4_type);
   dst_reg header1_w = header1;
   header1_w.writemask = WRITEMASK_W;
@@ -3136,7 +3137,7 @@ vec4_visitor::emit_psiz_and_flags(dst_reg reg)
 emit(AND(header1_w, src_reg(header1_w), 0x7ff  8));
   }
 
-  if (key-userclip_active) {
+  if (output_reg[VARYING_SLOT_CLIP_DIST0].file != BAD_FILE) {
  current_annotation = Clipping flags;
  dst_reg flags0 = dst_reg(this, glsl_type::uint_type);
  dst_reg flags1 = dst_reg(this, glsl_type::uint_type);
@@ -3354,7 +3355,7 @@ vec4_visitor::emit_vertex()
}
 
/* Lower legacy ff and ClipVertex clipping to clip distances */
-   if (key-userclip_active  !prog-UsesClipDistanceOut) {
+   if (key-nr_userclip_plane_consts  0) {
   current_annotation = user clip distances;
 
   output_reg[VARYING_SLOT_CLIP_DIST0] = dst_reg(this, 
glsl_type::vec4_type);
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
b/src/mesa/drivers/dri/i965/brw_vs.c
index 211929a..3653968 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -172,7 +172,7 @@ brw_codegen_vs_prog(struct brw_context *brw,
 * distance varying slots whenever clipping is enabled, even if the vertex
 * shader doesn't write to gl_ClipDistance.
 */
-   if (key-base.userclip_active) {
+   if (key-base.nr_userclip_plane_consts  0) {
   outputs_written |= BITFIELD64_BIT(VARYING_SLOT_CLIP_DIST0);
   outputs_written |= BITFIELD64_BIT(VARYING_SLOT_CLIP_DIST1);
}
@@ -257,10 +257,7 @@ brw_vs_debug_recompile(struct 

[Mesa-dev] [PATCH 12/12] i965: Simplify handling of VUE map changes.

2015-08-29 Thread Kenneth Graunke
The old code was disasterously complex - spread across multiple atoms
which may not even run, inspecting the dirty bits to try and decide
whether it was necessary to do checks...storing VS information in
brw_context...extra flagging...

This code tripped me and Carl up very badly when working on the
shader cache code.  It's very fragile and hard to maintain.

Now that geometry shaders only depend on their inputs and don't have
to worry about the VS VUE map, we can dramatically simplify this:
just compute the VUE map coming out of the geometry shader stage
in brw_upload_programs.  If it changes, flag it.  Done.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_context.h  | 12 +---
 src/mesa/drivers/dri/i965/brw_gs.c   | 14 +-
 src/mesa/drivers/dri/i965/brw_state_upload.c | 14 +-
 src/mesa/drivers/dri/i965/brw_vs.c   | 13 -
 4 files changed, 15 insertions(+), 38 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index c9c47dd..91258be 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -194,7 +194,6 @@ enum brw_state_id {
BRW_STATE_GS_CONSTBUF,
BRW_STATE_PROGRAM_CACHE,
BRW_STATE_STATE_BASE_ADDRESS,
-   BRW_STATE_VUE_MAP_VS,
BRW_STATE_VUE_MAP_GEOM_OUT,
BRW_STATE_TRANSFORM_FEEDBACK,
BRW_STATE_RASTERIZER_DISCARD,
@@ -276,7 +275,6 @@ enum brw_state_id {
 #define BRW_NEW_GS_CONSTBUF (1ull  BRW_STATE_GS_CONSTBUF)
 #define BRW_NEW_PROGRAM_CACHE   (1ull  BRW_STATE_PROGRAM_CACHE)
 #define BRW_NEW_STATE_BASE_ADDRESS  (1ull  BRW_STATE_STATE_BASE_ADDRESS)
-#define BRW_NEW_VUE_MAP_VS  (1ull  BRW_STATE_VUE_MAP_VS)
 #define BRW_NEW_VUE_MAP_GEOM_OUT(1ull  BRW_STATE_VUE_MAP_GEOM_OUT)
 #define BRW_NEW_TRANSFORM_FEEDBACK  (1ull  BRW_STATE_TRANSFORM_FEEDBACK)
 #define BRW_NEW_RASTERIZER_DISCARD  (1ull  BRW_STATE_RASTERIZER_DISCARD)
@@ -1362,16 +1360,8 @@ struct brw_context
} curbe;
 
/**
-* Layout of vertex data exiting the vertex shader.
-*
-* BRW_NEW_VUE_MAP_VS is flagged when this VUE map changes.
-*/
-   struct brw_vue_map vue_map_vs;
-
-   /**
 * Layout of vertex data exiting the geometry portion of the pipleine.
-* This comes from the geometry shader if one exists, otherwise from the
-* vertex shader.
+* This comes from the last enabled shader stage (GS, DS, or VS).
 *
 * BRW_NEW_VUE_MAP_GEOM_OUT is flagged when the VUE map changes.
 */
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c 
b/src/mesa/drivers/dri/i965/brw_gs.c
index da8af88..6b25150 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -292,8 +292,7 @@ brw_gs_state_dirty(struct brw_context *brw)
return brw_state_dirty(brw,
   _NEW_TEXTURE,
   BRW_NEW_GEOMETRY_PROGRAM |
-  BRW_NEW_TRANSFORM_FEEDBACK |
-  BRW_NEW_VUE_MAP_VS);
+  BRW_NEW_TRANSFORM_FEEDBACK);
 }
 
 static void
@@ -331,11 +330,6 @@ brw_upload_gs_prog(struct brw_context *brw)
 
if (gp == NULL) {
   /* No geometry shader.  Vertex data just passes straight through. */
-  if (brw-ctx.NewDriverState  BRW_NEW_VUE_MAP_VS) {
- brw-vue_map_geom_out = brw-vue_map_vs;
- brw-ctx.NewDriverState |= BRW_NEW_VUE_MAP_GEOM_OUT;
-  }
-
   if (brw-gen == 6 
   (brw-ctx.NewDriverState  BRW_NEW_TRANSFORM_FEEDBACK)) {
  gen6_brw_upload_ff_gs_prog(brw);
@@ -362,12 +356,6 @@ brw_upload_gs_prog(struct brw_context *brw)
   (void)success;
}
brw-gs.base.prog_data = brw-gs.prog_data-base.base;
-
-   if (brw-gs.prog_data-base.vue_map.slots_valid !=
-   brw-vue_map_geom_out.slots_valid) {
-  brw-vue_map_geom_out = brw-gs.prog_data-base.vue_map;
-  brw-ctx.NewDriverState |= BRW_NEW_VUE_MAP_GEOM_OUT;
-   }
 }
 
 bool
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 9de42ce..22161fc 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -589,7 +589,6 @@ static struct dirty_bit_map brw_bits[] = {
DEFINE_BIT(BRW_NEW_GS_CONSTBUF),
DEFINE_BIT(BRW_NEW_PROGRAM_CACHE),
DEFINE_BIT(BRW_NEW_STATE_BASE_ADDRESS),
-   DEFINE_BIT(BRW_NEW_VUE_MAP_VS),
DEFINE_BIT(BRW_NEW_VUE_MAP_GEOM_OUT),
DEFINE_BIT(BRW_NEW_TRANSFORM_FEEDBACK),
DEFINE_BIT(BRW_NEW_RASTERIZER_DISCARD),
@@ -644,6 +643,19 @@ brw_upload_programs(struct brw_context *brw,
   else
  brw_upload_gs_prog(brw);
 
+  /* Update the VUE map for data exiting the GS stage of the pipeline.
+   * This comes from the last enabled shader stage.
+   */
+  GLbitfield64 old_slots = brw-vue_map_geom_out.slots_valid;
+  if (brw-geometry_program)
+ 

[Mesa-dev] [PATCH 01/12] i965: Move brw_setup_tex_for_precompile to brw_program.[ch].

2015-08-29 Thread Kenneth Graunke
This living in brw_fs.{h,cpp} is a historical artifact of us supporting
texturing for fragment shaders before any other stages.  It's kind of
awkward given that we use it for all stages.

This avoids having to include brw_fs.h in geometry shader code in order
to access this function.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_fs.cpp| 19 ---
 src/mesa/drivers/dri/i965/brw_fs.h  |  3 ---
 src/mesa/drivers/dri/i965/brw_program.c | 19 +++
 src/mesa/drivers/dri/i965/brw_program.h |  4 
 4 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 269914d..17d8e75 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -5285,22 +5285,3 @@ brw_fs_precompile(struct gl_context *ctx,
 
return success;
 }
-
-void
-brw_setup_tex_for_precompile(struct brw_context *brw,
- struct brw_sampler_prog_key_data *tex,
- struct gl_program *prog)
-{
-   const bool has_shader_channel_select = brw-is_haswell || brw-gen = 8;
-   unsigned sampler_count = _mesa_fls(prog-SamplersUsed);
-   for (unsigned i = 0; i  sampler_count; i++) {
-  if (!has_shader_channel_select  (prog-ShadowSamplers  (1  i))) {
- /* Assume DEPTH_TEXTURE_MODE is the default: X, X, X, 1 */
- tex-swizzles[i] =
-MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_X, SWIZZLE_X, SWIZZLE_ONE);
-  } else {
- /* Color sampler: assume no swizzling. */
- tex-swizzles[i] = SWIZZLE_XYZW;
-  }
-   }
-}
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
b/src/mesa/drivers/dri/i965/brw_fs.h
index 0a89d2e..dd0526a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -514,6 +514,3 @@ private:
 
 bool brw_do_channel_expressions(struct exec_list *instructions);
 bool brw_do_vector_splitting(struct exec_list *instructions);
-void brw_setup_tex_for_precompile(struct brw_context *brw,
-  struct brw_sampler_prog_key_data *tex,
-  struct gl_program *prog);
diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index 4f38018..1ac0ed2 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -588,3 +588,22 @@ brw_dump_ir(const char *stage, struct gl_shader_program 
*shader_prog,
   _mesa_print_program(prog);
}
 }
+
+void
+brw_setup_tex_for_precompile(struct brw_context *brw,
+ struct brw_sampler_prog_key_data *tex,
+ struct gl_program *prog)
+{
+   const bool has_shader_channel_select = brw-is_haswell || brw-gen = 8;
+   unsigned sampler_count = _mesa_fls(prog-SamplersUsed);
+   for (unsigned i = 0; i  sampler_count; i++) {
+  if (!has_shader_channel_select  (prog-ShadowSamplers  (1  i))) {
+ /* Assume DEPTH_TEXTURE_MODE is the default: X, X, X, 1 */
+ tex-swizzles[i] =
+MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_X, SWIZZLE_X, SWIZZLE_ONE);
+  } else {
+ /* Color sampler: assume no swizzling. */
+ tex-swizzles[i] = SWIZZLE_XYZW;
+  }
+   }
+}
diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index eaa7e4e..bfcd1c9 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -159,6 +159,10 @@ struct brw_wm_prog_key {
 extern C {
 #endif
 
+void brw_setup_tex_for_precompile(struct brw_context *brw,
+  struct brw_sampler_prog_key_data *tex,
+  struct gl_program *prog);
+
 void brw_populate_sampler_prog_key_data(struct gl_context *ctx,
const struct gl_program *prog,
 unsigned sampler_count,
-- 
2.5.0

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


[Mesa-dev] i965: Clipping, GS, and VUE map simplifications

2015-08-29 Thread Kenneth Graunke
Hello,

I've been thinking a lot about VS/GS/HS/DS inputs and outputs lately.
Ideally, I'd like to know the input layout at NIR creation time, so I
can make nir_lower_io() produce nice offsets into the VUE or pushed
registers.  One thing that complicates that is when the inputs/outputs
change based on non-orthagonal state.

One example of this is legacy user-clipping: we extend the VS outputs
to contain clip distances when clip planes are enabled, so we can
potentially clip to gl_Position.  This could then alter the GS input
layout, which awkwardly depends on the VS output layout.

Since we only support geometry shaders in core profile (and on Gen6+),
it turns out a bunch of this is unnecessary - legacy userclipping
simply doesn't exist.  We can drop all GS support for it, and make
the VS only bother in compatibility contexts.  (Presumably Paul added
this code in the hopes of doing ARB_geometry_shader4, back in the day.)

After dropping that, I noticed that we never actually extend VS outputs
(in core profile), so we can just use vp-OutputsWritten, rather than
program keys.  Since the linker makes inputs/outputs match(*), I think
we can actually use gp-InputsRead, which means that the geometry shader
doesn't have any NOS at all - we don't need to recompile based on earlier
stages.  HS and DS similarly have no issues.

(*) I think this is true, even with separate shader objects...but please
correct me if not...I'm not sure if we have tests for SSO VS/GS and
unused varyings...my patches absolutely rely on them being removed.

With that in place, our VUE map handling gets dramatically simpler.

I really like where these patches are going - it's much cleaner and
simpler - but I'm not 100% confident in them.  Review would be most
appreciated.  These also completely kill any hope of geometry shaders
pre-Gen6, but that seems pretty far-fetched to begin with.

This passes Piglit on all platforms, and I verified that a simple GS
cloth rendering demo still works.

Thanks,
--Ken

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


[Mesa-dev] [PATCH 08/12] i965: Don't do legacy userclipping in non-compatibility contexts.

2015-08-29 Thread Kenneth Graunke
According to the GLSL 1.50 specification, page 76:
The shader must also set all values in gl_ClipDistance that have been
 enabled via the OpenGL API, or results are undefined.

With this patch, we only enable clip distance writes when the shader
actually writes them.  We no longer force a value to be written when
clip planes are enabled in the API.  This could mean the first varying
slot would be used as clip distances - I believe it should be the safe
kind of undefined behavior.

Empirically, it doesn't seem to cause a problem.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_vs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
b/src/mesa/drivers/dri/i965/brw_vs.c
index df7e531..05457d4 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -308,6 +308,7 @@ brw_vs_populate_key(struct brw_context *brw,
key-program_string_id = vp-id;
 
if (ctx-Transform.ClipPlanesEnabled != 0 
+   ctx-API == API_OPENGL_COMPAT 
!vp-program.Base.UsesClipDistanceOut) {
   key-nr_userclip_plane_consts =
  _mesa_logbase2(ctx-Transform.ClipPlanesEnabled) + 1;
-- 
2.5.0

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


[Mesa-dev] [PATCH 07/12] i965: Remove the brw_vue_prog_key base class.

2015-08-29 Thread Kenneth Graunke
The legacy userclip fields are only used for the vertex shader, and at
that point there's only program_string_id and the tex struct, which are
common to all keys.  So there's no need for a VUE key base class.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp  | 12 +
 src/mesa/drivers/dri/i965/brw_gs.c|  7 ++---
 src/mesa/drivers/dri/i965/brw_program.h   | 32 +++
 src/mesa/drivers/dri/i965/brw_vec4.cpp| 12 -
 src/mesa/drivers/dri/i965/brw_vec4.h  |  8 +-
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp |  2 +-
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp|  5 ++--
 src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp |  8 +++---
 src/mesa/drivers/dri/i965/brw_vs.c| 22 
 9 files changed, 45 insertions(+), 63 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 7100646..5cb794b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -783,8 +783,8 @@ fs_visitor::emit_fb_writes()
 void
 fs_visitor::setup_uniform_clipplane_values(gl_clip_plane *clip_planes)
 {
-   const struct brw_vue_prog_key *key =
-  (const struct brw_vue_prog_key *) this-key;
+   const struct brw_vs_prog_key *key =
+  (const struct brw_vs_prog_key *) this-key;
 
for (int i = 0; i  key-nr_userclip_plane_consts; i++) {
   this-userplane[i] = fs_reg(UNIFORM, uniforms);
@@ -806,8 +806,8 @@ void fs_visitor::compute_clip_distance(gl_clip_plane 
*clip_planes)
 {
struct brw_vue_prog_data *vue_prog_data =
   (struct brw_vue_prog_data *) prog_data;
-   const struct brw_vue_prog_key *key =
-  (const struct brw_vue_prog_key *) this-key;
+   const struct brw_vs_prog_key *key =
+  (const struct brw_vs_prog_key *) this-key;
 
/* Bail unless some sort of legacy clipping is enabled */
if (key-nr_userclip_plane_consts == 0)
@@ -1076,8 +1076,10 @@ fs_visitor::fs_visitor(const struct brw_compiler 
*compiler, void *log_data,
   key_tex = ((const brw_wm_prog_key *) key)-tex;
   break;
case MESA_SHADER_VERTEX:
+  key_tex = ((const brw_vs_prog_key *) key)-tex;
+  break;
case MESA_SHADER_GEOMETRY:
-  key_tex = ((const brw_vue_prog_key *) key)-tex;
+  key_tex = ((const brw_gs_prog_key *) key)-tex;
   break;
case MESA_SHADER_COMPUTE:
   key_tex = ((const brw_cs_prog_key*) key)-tex;
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c 
b/src/mesa/drivers/dri/i965/brw_gs.c
index f1da635..1c1a095 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -300,11 +300,11 @@ brw_gs_populate_key(struct brw_context *brw,
 
memset(key, 0, sizeof(*key));
 
-   key-base.program_string_id = gp-id;
+   key-program_string_id = gp-id;
 
/* _NEW_TEXTURE */
brw_populate_sampler_prog_key_data(ctx, prog, stage_state-sampler_count,
-  key-base.tex);
+  key-tex);
 
/* BRW_NEW_VUE_MAP_VS */
key-input_varyings = brw-vue_map_vs.slots_valid;
@@ -381,7 +381,8 @@ brw_gs_precompile(struct gl_context *ctx,
 
memset(key, 0, sizeof(key));
 
-   brw_vue_setup_prog_key_for_precompile(ctx, key.base, bgp-id, gp-Base);
+   brw_setup_tex_for_precompile(brw, key.tex, prog);
+   key.program_string_id = bgp-id;
 
/* Assume that the set of varyings coming in from the vertex shader exactly
 * matches what the geometry shader requires.
diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index 5ebf922..00e8f3f 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -78,24 +78,9 @@ struct brw_sampler_prog_key_data {
 };
 
 
-struct brw_vue_prog_key {
-   unsigned program_string_id;
-
-   /**
-* How many user clipping planes are being uploaded to the vertex shader as
-* push constants.
-*
-* These are used for lowering legacy gl_ClipVertex/gl_Position clipping to
-* clip distances.
-*/
-   unsigned nr_userclip_plane_consts:4;
-
-   struct brw_sampler_prog_key_data tex;
-};
-
 /** The program key for Vertex Shaders. */
 struct brw_vs_prog_key {
-   struct brw_vue_prog_key base;
+   unsigned program_string_id;
 
/*
 * Per-attribute workaround flags
@@ -107,6 +92,15 @@ struct brw_vs_prog_key {
bool clamp_vertex_color:1;
 
/**
+* How many user clipping planes are being uploaded to the vertex shader as
+* push constants.
+*
+* These are used for lowering legacy gl_ClipVertex/gl_Position clipping to
+* clip distances.
+*/
+   unsigned nr_userclip_plane_consts:4;
+
+   /**
 * For pre-Gen6 hardware, a bitfield indicating which texture coordinates
 * are going to be replaced with point coordinates (as a consequence of a
 * call to 

[Mesa-dev] [PATCH 05/12] i965: Store a key_tex pointer in vec4_visitor.

2015-08-29 Thread Kenneth Graunke
I'm about to remove the base class for VS/GS/HS/DS program keys, at
which point we won't be able to use key-tex anymore.  Instead, we'll
need to store a direct pointer (like we do in the FS backend).

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_vec4.h   |  1 +
 src/mesa/drivers/dri/i965/brw_vec4_nir.cpp |  4 ++--
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 13 +++--
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 7c31932..10439f2 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -101,6 +101,7 @@ public:
}
 
const struct brw_vue_prog_key * const key;
+   const struct brw_sampler_prog_key_data * const key_tex;
struct brw_vue_prog_data * const prog_data;
unsigned int sanity_param_count;
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index 59e440a..f3dc112 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
@@ -1409,7 +1409,7 @@ vec4_visitor::nir_emit_texture(nir_tex_instr *instr)
 * emitting anything other than setting up the constant result.
 */
if (instr-op == nir_texop_tg4) {
-  int swiz = GET_SWZ(key-tex.swizzles[sampler], instr-component);
+  int swiz = GET_SWZ(key_tex-swizzles[sampler], instr-component);
   if (swiz == SWIZZLE_ZERO || swiz == SWIZZLE_ONE) {
  emit(MOV(dest, src_reg(swiz == SWIZZLE_ONE ? 1.0f : 0.0f)));
  return;
@@ -1471,7 +1471,7 @@ vec4_visitor::nir_emit_texture(nir_tex_instr *instr)
  sample_index = get_nir_src(instr-src[i].src, BRW_REGISTER_TYPE_D, 1);
  assert(coord_type != NULL);
  if (devinfo-gen = 7 
- key-tex.compressed_multisample_layout_mask  (1sampler)) {
+ key_tex-compressed_multisample_layout_mask  (1  sampler)) {
 mcs = emit_mcs_fetch(coord_type, coordinate, sampler_reg);
  } else {
 mcs = src_reg(0u);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 978d28c..5a6e8a8 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2693,7 +2693,7 @@ vec4_visitor::emit_texture(ir_texture_opcode op,
}
 
if (devinfo-gen == 6  op == ir_tg4) {
-  emit_gen6_gather_wa(key-tex.gen6_gather_wa[sampler], inst-dst);
+  emit_gen6_gather_wa(key_tex-gen6_gather_wa[sampler], inst-dst);
}
 
swizzle_result(op, dest,
@@ -2745,7 +2745,7 @@ vec4_visitor::visit(ir_texture *ir)
 */
if (ir-op == ir_tg4) {
   ir_constant *chan = ir-lod_info.component-as_constant();
-  int swiz = GET_SWZ(key-tex.swizzles[sampler], chan-value.i[0]);
+  int swiz = GET_SWZ(key_tex-swizzles[sampler], chan-value.i[0]);
   if (swiz == SWIZZLE_ZERO || swiz == SWIZZLE_ONE) {
  dst_reg result(this, ir-type);
  this-result = src_reg(result);
@@ -2803,7 +2803,7 @@ vec4_visitor::visit(ir_texture *ir)
   ir-lod_info.sample_index-accept(this);
   sample_index = this-result;
 
-  if (devinfo-gen = 7  key-tex.compressed_multisample_layout_mask  
(1sampler))
+  if (devinfo-gen = 7  key_tex-compressed_multisample_layout_mask  
(1  sampler))
  mcs = emit_mcs_fetch(ir-coordinate-type, coordinate, sampler_reg);
   else
  mcs = src_reg(0u);
@@ -2881,14 +2881,14 @@ vec4_visitor::emit_gen6_gather_wa(uint8_t wa, dst_reg 
dst)
 uint32_t
 vec4_visitor::gather_channel(unsigned gather_component, uint32_t sampler)
 {
-   int swiz = GET_SWZ(key-tex.swizzles[sampler], gather_component);
+   int swiz = GET_SWZ(key_tex-swizzles[sampler], gather_component);
switch (swiz) {
   case SWIZZLE_X: return 0;
   case SWIZZLE_Y:
  /* gather4 sampler is broken for green channel on RG32F --
   * we must ask for blue instead.
   */
- if (key-tex.gather_channel_quirk_mask  (1sampler))
+ if (key_tex-gather_channel_quirk_mask  (1sampler))
 return 2;
  return 1;
   case SWIZZLE_Z: return 2;
@@ -2903,7 +2903,7 @@ vec4_visitor::swizzle_result(ir_texture_opcode op, 
dst_reg dest,
  src_reg orig_val, uint32_t sampler,
  const glsl_type *dest_type)
 {
-   int s = key-tex.swizzles[sampler];
+   int s = key_tex-swizzles[sampler];
 
dst_reg swizzled_result = dest;
 
@@ -3717,6 +3717,7 @@ vec4_visitor::vec4_visitor(const struct brw_compiler 
*compiler,
: backend_shader(compiler, log_data, mem_ctx,
 shader_prog, prog, prog_data-base, stage),
  key(key),
+ key_tex(key-tex),
  prog_data(prog_data),
  sanity_param_count(0),
  fail_msg(NULL),
-- 
2.5.0

___
mesa-dev mailing list

[Mesa-dev] [PATCH 09/12] i965/gs: Don't reserve space for clip plane uniforms.

2015-08-29 Thread Kenneth Graunke
These were only for legacy userclipping, which we no longer support
in geometry shaders.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_gs.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_gs.c 
b/src/mesa/drivers/dri/i965/brw_gs.c
index 1c1a095..04d9f3f 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -62,8 +62,6 @@ brw_codegen_gs_prog(struct brw_context *brw,
struct gl_shader *gs = prog-_LinkedShaders[MESA_SHADER_GEOMETRY];
int param_count = gs-num_uniform_components * 4;
 
-   /* We also upload clip plane data as uniforms */
-   param_count += MAX_CLIP_PLANES * 4;
param_count += gs-NumImages * BRW_IMAGE_PARAM_SIZE;
 
c.prog_data.base.base.param =
-- 
2.5.0

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


[Mesa-dev] [PATCH 06/12] i965: Virtualize vec4_visitor::emit_urb_slot().

2015-08-29 Thread Kenneth Graunke
This avoids a downcast of key, which won't exist in the base class soon.

I'm not a huge fan of this patch, but given that we're currently using
inheritance, this seems like the right way to do it.  The alternative
is to make key a void pointer in the parent class and continue
downcasting.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_vec4.h  |  2 +-
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp| 15 -
 src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp | 26 +++
 src/mesa/drivers/dri/i965/brw_vs.h|  1 +
 4 files changed, 28 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 10439f2..7df87b5 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -360,7 +360,7 @@ public:
void emit_ndc_computation();
void emit_psiz_and_flags(dst_reg reg);
vec4_instruction *emit_generic_urb_slot(dst_reg reg, int varying);
-   void emit_urb_slot(dst_reg reg, int varying);
+   virtual void emit_urb_slot(dst_reg reg, int varying);
 
void emit_shader_time_begin();
void emit_shader_time_end();
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 5a6e8a8..0990c7a 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -3233,21 +3233,6 @@ vec4_visitor::emit_urb_slot(dst_reg reg, int varying)
case BRW_VARYING_SLOT_PAD:
   /* No need to write to this slot */
   break;
-   case VARYING_SLOT_COL0:
-   case VARYING_SLOT_COL1:
-   case VARYING_SLOT_BFC0:
-   case VARYING_SLOT_BFC1: {
-  /* These built-in varyings are only supported in compatibility mode,
-   * and we only support GS in core profile.  So, this must be a vertex
-   * shader.
-   */
-  assert(stage == MESA_SHADER_VERTEX);
-  vec4_instruction *inst = emit_generic_urb_slot(reg, varying);
-  if (((struct brw_vs_prog_key *) key)-clamp_vertex_color)
- inst-saturate = true;
-  break;
-   }
-
default:
   emit_generic_urb_slot(reg, varying);
   break;
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 f81ee4e..442cefd 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
@@ -202,6 +202,32 @@ vec4_vs_visitor::emit_urb_write_opcode(bool complete)
 
 
 void
+vec4_vs_visitor::emit_urb_slot(dst_reg reg, int varying)
+{
+   reg.type = BRW_REGISTER_TYPE_F;
+   output_reg[varying].type = reg.type;
+
+   switch (varying) {
+   case VARYING_SLOT_COL0:
+   case VARYING_SLOT_COL1:
+   case VARYING_SLOT_BFC0:
+   case VARYING_SLOT_BFC1: {
+  /* These built-in varyings are only supported in compatibility mode,
+   * and we only support GS in core profile.  So, this must be a vertex
+   * shader.
+   */
+  vec4_instruction *inst = emit_generic_urb_slot(reg, varying);
+  if (key-clamp_vertex_color)
+ inst-saturate = true;
+  break;
+   }
+   default:
+  return vec4_visitor::emit_urb_slot(reg, varying);
+   }
+}
+
+
+void
 vec4_vs_visitor::emit_clip_distances(dst_reg reg, int offset)
 {
/* From the GLSL 1.30 spec, section 7.1 (Vertex Shader Special Variables):
diff --git a/src/mesa/drivers/dri/i965/brw_vs.h 
b/src/mesa/drivers/dri/i965/brw_vs.h
index e98679a..3a847fcd 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.h
+++ b/src/mesa/drivers/dri/i965/brw_vs.h
@@ -103,6 +103,7 @@ protected:
virtual void emit_program_code();
virtual void emit_thread_end();
virtual void emit_urb_write_header(int mrf);
+   virtual void emit_urb_slot(dst_reg reg, int varying);
virtual vec4_instruction *emit_urb_write_opcode(bool complete);
 
 private:
-- 
2.5.0

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


[Mesa-dev] [PATCH 04/12] i965: Move legacy clip plane handling to vec4_vs_visitor.

2015-08-29 Thread Kenneth Graunke
This is now only used for the vertex shader, so it makes sense to get it
out of any paths run by the geometry shader.

By wrapping the run() method, we can eliminate the bogus NULL
parameter in the GS case, and do VS things only for the VS.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_vec4.cpp| 10 ++--
 src/mesa/drivers/dri/i965/brw_vec4.h  |  4 +-
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp |  4 +-
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp| 56 
 src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp | 62 +++
 src/mesa/drivers/dri/i965/brw_vs.h|  5 ++
 6 files changed, 74 insertions(+), 67 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 4f5e85b..c6f64fb 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1719,7 +1719,7 @@ vec4_visitor::emit_shader_time_write(int 
shader_time_subindex, src_reg value)
 }
 
 bool
-vec4_visitor::run(gl_clip_plane *clip_planes)
+vec4_visitor::run()
 {
bool use_vec4_nir =
   compiler-glsl_compiler_options[stage].NirOptions != NULL;
@@ -1748,9 +1748,6 @@ vec4_visitor::run(gl_clip_plane *clip_planes)
}
base_ir = NULL;
 
-   if (key-nr_userclip_plane_consts  0)
-  setup_uniform_clipplane_values(clip_planes);
-
emit_thread_end();
 
calculate_cfg();
@@ -1977,9 +1974,10 @@ brw_vs_emit(struct brw_context *brw,
   prog_data-base.dispatch_mode = DISPATCH_MODE_4X2_DUAL_OBJECT;
 
   vec4_vs_visitor v(brw-intelScreen-compiler, brw, key, prog_data,
-vp, prog, mem_ctx, st_index,
+vp, prog, brw_select_clip_planes(brw-ctx),
+mem_ctx, st_index,
 !_mesa_is_gles3(brw-ctx));
-  if (!v.run(brw_select_clip_planes(brw-ctx))) {
+  if (!v.run()) {
  if (prog) {
 prog-LinkStatus = false;
 ralloc_strcat(prog-InfoLog, v.fail_msg);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 673a29e..7c31932 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -173,10 +173,9 @@ public:
 
struct hash_table *variable_ht;
 
-   bool run(gl_clip_plane *clip_planes);
+   bool run();
void fail(const char *msg, ...);
 
-   void setup_uniform_clipplane_values(gl_clip_plane *clip_planes);
virtual void setup_vec4_uniform_value(unsigned param_offset,
  const gl_constant_value *values,
  unsigned n);
@@ -359,7 +358,6 @@ public:
 
void emit_ndc_computation();
void emit_psiz_and_flags(dst_reg reg);
-   void emit_clip_distances(dst_reg reg, int offset);
vec4_instruction *emit_generic_urb_slot(dst_reg reg, int varying);
void emit_urb_slot(dst_reg reg, int varying);
 
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 019efec..4fd626f 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -679,7 +679,7 @@ brw_gs_emit(struct brw_context *brw,
 
  vec4_gs_visitor v(brw-intelScreen-compiler, brw,
c, prog, mem_ctx, true /* no_spills */, st_index);
- if (v.run(NULL /* clip planes */)) {
+ if (v.run()) {
 return generate_assembly(brw, prog, c-gp-program.Base,
  c-prog_data.base, mem_ctx, v.cfg,
  final_assembly_size);
@@ -727,7 +727,7 @@ brw_gs_emit(struct brw_context *brw,
c, prog, mem_ctx, false /* no_spills */,
st_index);
 
-   if (!gs-run(NULL /* clip planes */)) {
+   if (!gs-run()) {
   prog-LinkStatus = false;
   ralloc_strcat(prog-InfoLog, gs-fail_msg);
} else {
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 4d3d281..978d28c 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -755,22 +755,6 @@ vec4_visitor::setup_uniform_values(ir_variable *ir)
}
 }
 
-void
-vec4_visitor::setup_uniform_clipplane_values(gl_clip_plane *clip_planes)
-{
-   for (int i = 0; i  key-nr_userclip_plane_consts; ++i) {
-  assert(this-uniforms  uniform_array_size);
-  this-uniform_vector_size[this-uniforms] = 4;
-  this-userplane[i] = dst_reg(UNIFORM, this-uniforms);
-  this-userplane[i].type = BRW_REGISTER_TYPE_F;
-  for (int j = 0; j  4; ++j) {
- stage_prog_data-param[this-uniforms * 4 + j] =
-(gl_constant_value *) clip_planes[i][j];
-  }
-  ++this-uniforms;
-   }
-}
-
 /* Our support for builtin uniforms is even scarier than 

[Mesa-dev] [PATCH 11/12] i965: Optimize VUE map comparisons.

2015-08-29 Thread Kenneth Graunke
The entire VUE map is computed based on the slots_valid bitfield;
calling brw_compute_vue_map on the same bitfield will return the
same result.  So we can simply compare those.

struct brw_vue_map is 136 bytes; doing a single 8-byte comparison is
much cheaper and should work just as well.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_gs.c | 4 ++--
 src/mesa/drivers/dri/i965/brw_vs.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_gs.c 
b/src/mesa/drivers/dri/i965/brw_gs.c
index 6cb4263..da8af88 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -363,8 +363,8 @@ brw_upload_gs_prog(struct brw_context *brw)
}
brw-gs.base.prog_data = brw-gs.prog_data-base.base;
 
-   if (memcmp(brw-gs.prog_data-base.vue_map, brw-vue_map_geom_out,
-  sizeof(brw-vue_map_geom_out)) != 0) {
+   if (brw-gs.prog_data-base.vue_map.slots_valid !=
+   brw-vue_map_geom_out.slots_valid) {
   brw-vue_map_geom_out = brw-gs.prog_data-base.vue_map;
   brw-ctx.NewDriverState |= BRW_NEW_VUE_MAP_GEOM_OUT;
}
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
b/src/mesa/drivers/dri/i965/brw_vs.c
index 05457d4..4e0d34f 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -368,8 +368,8 @@ brw_upload_vs_prog(struct brw_context *brw)
}
brw-vs.base.prog_data = brw-vs.prog_data-base.base;
 
-   if (memcmp(brw-vs.prog_data-base.vue_map, brw-vue_map_geom_out,
-  sizeof(brw-vue_map_geom_out)) != 0) {
+   if (brw-vs.prog_data-base.vue_map.slots_valid !=
+   brw-vue_map_geom_out.slots_valid) {
   brw-vue_map_vs = brw-vs.prog_data-base.vue_map;
   brw-ctx.NewDriverState |= BRW_NEW_VUE_MAP_VS;
   if (brw-gen  6) {
-- 
2.5.0

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


[Mesa-dev] [PATCH 10/12] i965/gs: Remove the dependency on the VS VUE map.

2015-08-29 Thread Kenneth Graunke
Because we only support geometry shaders in core profile, we can safely
ignore any driver-extending of VS outputs.

Those are:
- Legacy userclipping (doesn't exist in core profile)
- Edgeflag copying (Gen4-5 only, no GS support)
- Point coord replacement (Gen4-5 only, no GS support)
- front/back color hacks (Gen4-5 only, no GS support)

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_gs.c  | 20 +++-
 src/mesa/drivers/dri/i965/brw_program.h |  2 --
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_gs.c 
b/src/mesa/drivers/dri/i965/brw_gs.c
index 04d9f3f..6cb4263 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -242,8 +242,18 @@ brw_codegen_gs_prog(struct brw_context *brw,
c.prog_data.output_topology =
   get_hw_prim_for_gl_prim(gp-program.OutputType);
 
+   /* The GLSL linker will have already matched up GS inputs and the outputs
+* of prior stages.  The driver does extend VS outputs in some cases, but
+* only for legacy OpenGL or Gen4-5 hardware, neither of which offer
+* geometry shader support.  So we can safely ignore that.
+*
+* However, we need to ignore VARYING_SLOT_PRIMITIVE_ID, as it's not
+* written by previous stages and shows up via payload magic.
+*/
+   GLbitfield64 inputs_read =
+  gp-program.Base.InputsRead  ~VARYING_BIT_PRIMITIVE_ID;
brw_compute_vue_map(brw-intelScreen-devinfo,
-   c.input_vue_map, c.key.input_varyings);
+   c.input_vue_map, inputs_read);
 
/* GS inputs are read from the VUE 256 bits (2 vec4's) at a time, so we
 * need to program a URB read length of ceiling(num_slots / 2).
@@ -303,9 +313,6 @@ brw_gs_populate_key(struct brw_context *brw,
/* _NEW_TEXTURE */
brw_populate_sampler_prog_key_data(ctx, prog, stage_state-sampler_count,
   key-tex);
-
-   /* BRW_NEW_VUE_MAP_VS */
-   key-input_varyings = brw-vue_map_vs.slots_valid;
 }
 
 void
@@ -382,11 +389,6 @@ brw_gs_precompile(struct gl_context *ctx,
brw_setup_tex_for_precompile(brw, key.tex, prog);
key.program_string_id = bgp-id;
 
-   /* Assume that the set of varyings coming in from the vertex shader exactly
-* matches what the geometry shader requires.
-*/
-   key.input_varyings = gp-Base.InputsRead;
-
success = brw_codegen_gs_prog(brw, shader_prog, bgp, key);
 
brw-gs.base.prog_offset = old_prog_offset;
diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
b/src/mesa/drivers/dri/i965/brw_program.h
index 00e8f3f..72d68d8 100644
--- a/src/mesa/drivers/dri/i965/brw_program.h
+++ b/src/mesa/drivers/dri/i965/brw_program.h
@@ -118,8 +118,6 @@ struct brw_gs_prog_key
 {
unsigned program_string_id;
 
-   uint64_t input_varyings;
-
struct brw_sampler_prog_key_data tex;
 };
 
-- 
2.5.0

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


[Mesa-dev] [PATCH 02/12] i965: Remove legacy clip plane handling from geometry shaders.

2015-08-29 Thread Kenneth Graunke
We only support geometry shaders in core profiles, where gl_ClipVertex
doesn't exist.  Presumably the even older behavior of clipping to
gl_Position isn't supported either.  In fact, GLSL 1.50 page 76 claims:

The shader must also set all values in gl_ClipDistance that have been
 enabled via the OpenGL API, or results are undefined.

So we don't need to handle legacy clipping in geometry shaders.  I think
Paul added this back when we were considering supporting the old
GL_ARB_geometry_shader4 extension.

This removes a non-orthagonal state dependency on GS compilation.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_context.h |  5 -
 src/mesa/drivers/dri/i965/brw_gs.c  | 11 ---
 src/mesa/drivers/dri/i965/brw_vs.c  | 25 -
 3 files changed, 8 insertions(+), 33 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index b52bca7..c9c47dd 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -2058,11 +2058,6 @@ void gen8_hiz_exec(struct brw_context *brw, struct 
intel_mipmap_tree *mt,
 uint32_t get_hw_prim_for_gl_prim(int mode);
 
 void
-brw_setup_vue_key_clip_info(struct brw_context *brw,
-struct brw_vue_prog_key *key,
-bool program_uses_clip_distance);
-
-void
 gen6_upload_push_constants(struct brw_context *brw,
const struct gl_program *prog,
const struct brw_stage_prog_data *prog_data,
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c 
b/src/mesa/drivers/dri/i965/brw_gs.c
index 5c0d923..f1da635 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -121,15 +121,6 @@ brw_codegen_gs_prog(struct brw_context *brw,
 
GLbitfield64 outputs_written = gp-program.Base.OutputsWritten;
 
-   /* In order for legacy clipping to work, we need to populate the clip
-* distance varying slots whenever clipping is enabled, even if the vertex
-* shader doesn't write to gl_ClipDistance.
-*/
-   if (c.key.base.userclip_active) {
-  outputs_written |= BITFIELD64_BIT(VARYING_SLOT_CLIP_DIST0);
-  outputs_written |= BITFIELD64_BIT(VARYING_SLOT_CLIP_DIST1);
-   }
-
brw_compute_vue_map(brw-intelScreen-devinfo,
c.prog_data.base.vue_map, outputs_written);
 
@@ -310,8 +301,6 @@ brw_gs_populate_key(struct brw_context *brw,
memset(key, 0, sizeof(*key));
 
key-base.program_string_id = gp-id;
-   brw_setup_vue_key_clip_info(brw, key-base,
-   gp-program.Base.UsesClipDistanceOut);
 
/* _NEW_TEXTURE */
brw_populate_sampler_prog_key_data(ctx, prog, stage_state-sampler_count,
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
b/src/mesa/drivers/dri/i965/brw_vs.c
index c53cb49..211929a 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -279,21 +279,6 @@ brw_vs_debug_recompile(struct brw_context *brw,
}
 }
 
-
-void
-brw_setup_vue_key_clip_info(struct brw_context *brw,
-struct brw_vue_prog_key *key,
-bool program_uses_clip_distance)
-{
-   struct gl_context *ctx = brw-ctx;
-
-   key-userclip_active = (ctx-Transform.ClipPlanesEnabled != 0);
-   if (key-userclip_active  !program_uses_clip_distance) {
-  key-nr_userclip_plane_consts
- = _mesa_logbase2(ctx-Transform.ClipPlanesEnabled) + 1;
-   }
-}
-
 static bool
 brw_vs_state_dirty(struct brw_context *brw)
 {
@@ -325,8 +310,14 @@ brw_vs_populate_key(struct brw_context *brw,
 * the inputs it asks for, whether they are varying or not.
 */
key-base.program_string_id = vp-id;
-   brw_setup_vue_key_clip_info(brw, key-base,
-   vp-program.Base.UsesClipDistanceOut);
+
+   if (ctx-Transform.ClipPlanesEnabled != 0) {
+  key-base.userclip_active = true;
+  if (!vp-program.Base.UsesClipDistanceOut) {
+ key-base.nr_userclip_plane_consts =
+_mesa_logbase2(ctx-Transform.ClipPlanesEnabled) + 1;
+  }
+   }
 
/* _NEW_POLYGON */
if (brw-gen  6) {
-- 
2.5.0

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


[Mesa-dev] [PATCH 4/4] r600g: Use TGSI parse results instead of manually exfiltrating

2015-08-29 Thread Edward O'Callaghan
From: Edward O'Callaghan eocallag...@alterapraxis.com

This makes better use of the work that the TGSI API has done for
us.

Signed-off-by: Edward O'Callaghan eocallag...@alterapraxis.com
---
 src/gallium/drivers/r600/r600_shader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index a265fb8..b7d7828 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1839,7 +1839,7 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
shader-indirect_files = ctx.info.indirect_files;
indirect_gprs = ctx.info.indirect_files  ~(1  TGSI_FILE_CONSTANT);
tgsi_parse_init(ctx.parse, tokens);
-   ctx.type = ctx.parse.FullHeader.Processor.Processor;
+   ctx.type = ctx.info.processor;
shader-processor_type = ctx.type;
ctx.bc-type = shader-processor_type;
 
-- 
2.4.3

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


[Mesa-dev] [PATCH 2/4] r600g: Move geometry properties state from shader to selector

2015-08-29 Thread Edward O'Callaghan
From: Edward O'Callaghan eocallag...@alterapraxis.com

Signed-off-by: Edward O'Callaghan eocallag...@alterapraxis.com
---
 src/gallium/drivers/r600/evergreen_state.c   | 16 
 src/gallium/drivers/r600/r600_pipe.h |  5 +
 src/gallium/drivers/r600/r600_shader.c   |  6 +++---
 src/gallium/drivers/r600/r600_shader.h   |  4 
 src/gallium/drivers/r600/r600_state.c| 12 ++--
 src/gallium/drivers/r600/r600_state_common.c |  2 +-
 6 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index 6a91d47..7c82390 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2143,11 +2143,11 @@ static void evergreen_emit_shader_stages(struct 
r600_context *rctx, struct r600_
if (state-geom_enable) {
uint32_t cut_val;
 
-   if (rctx-gs_shader-current-shader.gs_max_out_vertices = 128)
+   if (rctx-gs_shader-gs_max_out_vertices = 128)
cut_val = V_028A40_GS_CUT_128;
-   else if (rctx-gs_shader-current-shader.gs_max_out_vertices 
= 256)
+   else if (rctx-gs_shader-gs_max_out_vertices = 256)
cut_val = V_028A40_GS_CUT_256;
-   else if (rctx-gs_shader-current-shader.gs_max_out_vertices 
= 512)
+   else if (rctx-gs_shader-gs_max_out_vertices = 512)
cut_val = V_028A40_GS_CUT_512;
else
cut_val = V_028A40_GS_CUT_1024;
@@ -3013,7 +3013,7 @@ void evergreen_update_gs_state(struct pipe_context *ctx, 
struct r600_pipe_shader
struct r600_shader *rshader = shader-shader;
struct r600_shader *cp_shader = shader-gs_copy_shader-shader;
unsigned gsvs_itemsize =
-   (cp_shader-ring_item_size * 
rshader-gs_max_out_vertices)  2;
+   (cp_shader-ring_item_size * 
shader-selector-gs_max_out_vertices)  2;
 
r600_init_command_buffer(cb, 64);
 
@@ -3022,14 +3022,14 @@ void evergreen_update_gs_state(struct pipe_context 
*ctx, struct r600_pipe_shader
r600_store_context_reg(cb, R_028AB8_VGT_VTX_CNT_EN, 1);
 
r600_store_context_reg(cb, R_028B38_VGT_GS_MAX_VERT_OUT,
-  
S_028B38_MAX_VERT_OUT(rshader-gs_max_out_vertices));
+  
S_028B38_MAX_VERT_OUT(shader-selector-gs_max_out_vertices));
r600_store_context_reg(cb, R_028A6C_VGT_GS_OUT_PRIM_TYPE,
-  
r600_conv_prim_to_gs_out(rshader-gs_output_prim));
+  
r600_conv_prim_to_gs_out(shader-selector-gs_output_prim));
 
if (rctx-screen-b.info.drm_minor = 35) {
r600_store_context_reg(cb, R_028B90_VGT_GS_INSTANCE_CNT,
-   S_028B90_CNT(MIN2(rshader-gs_num_invocations, 
127)) |
-   S_028B90_ENABLE(rshader-gs_num_invocations  
0));
+   
S_028B90_CNT(MIN2(shader-selector-gs_num_invocations, 127)) |
+   
S_028B90_ENABLE(shader-selector-gs_num_invocations  0));
}
r600_store_context_reg_seq(cb, R_02891C_SQ_GS_VERT_ITEMSIZE, 4);
r600_store_value(cb, cp_shader-ring_item_size  2);
diff --git a/src/gallium/drivers/r600/r600_pipe.h 
b/src/gallium/drivers/r600/r600_pipe.h
index 3247aba..eb70360 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -311,6 +311,11 @@ struct r600_pipe_shader_selector {
/* PIPE_SHADER_[VERTEX|FRAGMENT|...] */
unsignedtype;
 
+   /* geometry shader properties */
+   unsignedgs_output_prim;
+   unsignedgs_max_out_vertices;
+   unsignedgs_num_invocations;
+
unsignednr_ps_max_color_exports;
 };
 
diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 44e41fb..f0b794c 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -2010,13 +2010,13 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
/* we don't need this one */
break;
case TGSI_PROPERTY_GS_OUTPUT_PRIM:
-   shader-gs_output_prim = property-u[0].Data;
+   pipeshader-selector-gs_output_prim = 
property-u[0].Data;
break;
case TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES:
-   shader-gs_max_out_vertices = 
property-u[0].Data;
+   pipeshader-selector-gs_max_out_vertices = 
property-u[0].Data;
break;
case TGSI_PROPERTY_GS_INVOCATIONS:
-   

[Mesa-dev] [PATCH 3/4] r600g: Set geometry properties in r600_create_shader_state()

2015-08-29 Thread Edward O'Callaghan
From: Edward O'Callaghan eocallag...@alterapraxis.com

The selector is shared by all shader variants, so the
individual shaders shouldn't change it. Use tgsi_shader_scan()
results to set geometry properties within a
r600_create_shader_state() call and treat said propertices in
the selector as read-only within r600_shader_from_tgsi().

Signed-off-by: Edward O'Callaghan eocallag...@alterapraxis.com
---
 src/gallium/drivers/r600/r600_pipe.h |  3 +++
 src/gallium/drivers/r600/r600_shader.c   | 31 ++--
 src/gallium/drivers/r600/r600_state_common.c | 14 +
 3 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_pipe.h 
b/src/gallium/drivers/r600/r600_pipe.h
index eb70360..4bd3d7c 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -36,6 +36,8 @@
 #include util/list.h
 #include util/u_transfer.h
 
+#include tgsi/tgsi_scan.h
+
 #define R600_NUM_ATOMS 75
 
 #define R600_MAX_VIEWPORTS 16
@@ -305,6 +307,7 @@ struct r600_pipe_shader_selector {
 
struct tgsi_token   *tokens;
struct pipe_stream_output_info  so;
+   struct tgsi_shader_info info;
 
unsignednum_shaders;
 
diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index f0b794c..a265fb8 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1809,7 +1809,6 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
struct tgsi_token *tokens = pipeshader-selector-tokens;
struct pipe_stream_output_info so = pipeshader-selector-so;
struct tgsi_full_immediate *immediate;
-   struct tgsi_full_property *property;
struct r600_shader_ctx ctx;
struct r600_bytecode_output output[32];
unsigned output_done, noutput;
@@ -1968,6 +1967,12 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
ctx.nliterals = 0;
ctx.literals = NULL;
shader-fs_write_all = FALSE;
+   if (ctx.info.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])
+   shader-fs_write_all = TRUE;
+
+   shader-vs_position_window_space = FALSE;
+   if (ctx.info.properties[TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION])
+   shader-vs_position_window_space = TRUE;
 
if (shader-vs_as_gs_a)
vs_add_primid_output(ctx, key.vs.prim_id_out);
@@ -1994,31 +1999,7 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
goto out_err;
break;
case TGSI_TOKEN_TYPE_INSTRUCTION:
-   break;
case TGSI_TOKEN_TYPE_PROPERTY:
-   property = ctx.parse.FullToken.FullProperty;
-   switch (property-Property.PropertyName) {
-   case TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS:
-   if (property-u[0].Data == 1)
-   shader-fs_write_all = TRUE;
-   break;
-   case TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION:
-   if (property-u[0].Data == 1)
-   shader-vs_position_window_space = TRUE;
-   break;
-   case TGSI_PROPERTY_VS_PROHIBIT_UCPS:
-   /* we don't need this one */
-   break;
-   case TGSI_PROPERTY_GS_OUTPUT_PRIM:
-   pipeshader-selector-gs_output_prim = 
property-u[0].Data;
-   break;
-   case TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES:
-   pipeshader-selector-gs_max_out_vertices = 
property-u[0].Data;
-   break;
-   case TGSI_PROPERTY_GS_INVOCATIONS:
-   pipeshader-selector-gs_num_invocations = 
property-u[0].Data;
-   break;
-   }
break;
default:
R600_ERR(unsupported token type %d\n, 
ctx.parse.FullToken.Token.Type);
diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index 63746b5..d9cf736 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -34,6 +34,7 @@
 #include util/u_upload_mgr.h
 #include util/u_math.h
 #include tgsi/tgsi_parse.h
+#include tgsi/tgsi_scan.h
 
 void r600_init_command_buffer(struct r600_command_buffer *cb, unsigned num_dw)
 {
@@ -818,6 +819,19 @@ static void *r600_create_shader_state(struct pipe_context 
*ctx,
sel-type = pipe_shader_type;
sel-tokens = tgsi_dup_tokens(state-tokens);
sel-so = state-stream_output;
+   

[Mesa-dev] [PATCH 0/4] r600g: Make better use of the TGSI API (V.2)

2015-08-29 Thread Edward O'Callaghan
From: Edward O'Callaghan eocallag...@alterapraxis.com

Minor cleanups that intend to make better use of the TGSI parser
API tgsi_scan_shader().

V.2 adjustment; Set geometery property state within
r600_create_shader_state().

Edward O'Callaghan (4):
  r600g: Remove dead assigment to 'gs_input_prim' in shader state
  r600g: Move geometry properties state from shader to selector
  r600g: Set geometry properties in r600_create_shader_state()
  r600g: Use TGSI parse results instead of manually exfiltrating

 src/gallium/drivers/r600/evergreen_state.c   | 16 ++---
 src/gallium/drivers/r600/r600_pipe.h |  8 +++
 src/gallium/drivers/r600/r600_shader.c   | 36 ++--
 src/gallium/drivers/r600/r600_shader.h   |  5 
 src/gallium/drivers/r600/r600_state.c| 12 +-
 src/gallium/drivers/r600/r600_state_common.c | 16 -
 6 files changed, 44 insertions(+), 49 deletions(-)

-- 
2.4.3

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


[Mesa-dev] [PATCH 1/4] r600g: Remove dead assigment to 'gs_input_prim' in shader state

2015-08-29 Thread Edward O'Callaghan
From: Edward O'Callaghan eocallag...@alterapraxis.com

Note that 'geometry shader properties' should be carried in the
selector state over the shader state in any case.

Signed-off-by: Edward O'Callaghan eocallag...@alterapraxis.com
---
 src/gallium/drivers/r600/r600_shader.c | 3 ---
 src/gallium/drivers/r600/r600_shader.h | 1 -
 2 files changed, 4 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 4c4b600..44e41fb 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -2009,9 +2009,6 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
case TGSI_PROPERTY_VS_PROHIBIT_UCPS:
/* we don't need this one */
break;
-   case TGSI_PROPERTY_GS_INPUT_PRIM:
-   shader-gs_input_prim = property-u[0].Data;
-   break;
case TGSI_PROPERTY_GS_OUTPUT_PRIM:
shader-gs_output_prim = property-u[0].Data;
break;
diff --git a/src/gallium/drivers/r600/r600_shader.h 
b/src/gallium/drivers/r600/r600_shader.h
index 927bac5..2b99b22 100644
--- a/src/gallium/drivers/r600/r600_shader.h
+++ b/src/gallium/drivers/r600/r600_shader.h
@@ -79,7 +79,6 @@ struct r600_shader {
boolean uses_index_registers;
 
/* geometry shader properties */
-   unsignedgs_input_prim;
unsignedgs_output_prim;
unsignedgs_max_out_vertices;
unsignedgs_num_invocations;
-- 
2.4.3

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


[Mesa-dev] [Bug 91778] white screen in unigine tropics and sanctuary with 11RC1

2015-08-29 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91778

Hleb Valoshka 375...@gmail.com changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

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


[Mesa-dev] [Bug 91778] white screen in unigine tropics and sanctuary with 11RC1

2015-08-29 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91778

Hleb Valoshka 375...@gmail.com changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

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


[Mesa-dev] [Bug 91778] white screen in unigine tropics and sanctuary with 11RC1

2015-08-29 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91778

Benjamin Bellec b.bel...@gmail.com changed:

   What|Removed |Added

 CC||b.bel...@gmail.com

--- Comment #1 from Benjamin Bellec b.bel...@gmail.com ---
Not reproducible with r600g.

Tested with :
OpenGL renderer: Gallium 0.4 on AMD CYPRESS (DRM 2.42.0)
OpenGL core version: 3.3 (Core Profile) Mesa 11.1.0-devel (git-c8a61ea)

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


[Mesa-dev] [Bug 91643] mesa-demos-8.2.0 (latest released version) fails to build against mesa-10.6.4-2.mga6.tainted.src.rpm

2015-08-29 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91643

Alexander Tsoy alexan...@tsoy.me changed:

   What|Removed |Added

 CC||alexan...@tsoy.me

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


[Mesa-dev] [Bug 91797] [r600g] Company of Heroes 2 crash when zooming on the map

2015-08-29 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91797

Benjamin Bellec b.bel...@gmail.com changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
Summary|[r600g] Company of Heroes 2 |[r600g] Company of Heroes 2
   |crash after loading a map   |crash when zooming on the
   ||map

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


[Mesa-dev] [Bug 91778] white screen in unigine tropics and sanctuary with 11RC1

2015-08-29 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91778

--- Comment #2 from Ilia Mirkin imir...@alum.mit.edu ---
It's due to ARB_gpu_shader5 getting enabled, which introduces the 'sample'
keyword. However the tropics shader has a variable called 'sample', which was
legal back then.

ARB_gpu_shader5, in turn, gets enabled because of

option name=force_glsl_extensions_warn value=true /

So ideally there'd be an extra override to disable ARB_gpu_shader5.

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


Re: [Mesa-dev] [PATCH 3/4] r600g: Set geometry properties in r600_create_shader_state()

2015-08-29 Thread Marek Olšák
On Sat, Aug 29, 2015 at 10:31 AM, Edward O'Callaghan
edward.ocallag...@koparo.com wrote:
 From: Edward O'Callaghan eocallag...@alterapraxis.com

 The selector is shared by all shader variants, so the
 individual shaders shouldn't change it. Use tgsi_shader_scan()
 results to set geometry properties within a
 r600_create_shader_state() call and treat said propertices in
 the selector as read-only within r600_shader_from_tgsi().

 Signed-off-by: Edward O'Callaghan eocallag...@alterapraxis.com
 ---
  src/gallium/drivers/r600/r600_pipe.h |  3 +++
  src/gallium/drivers/r600/r600_shader.c   | 31 
 ++--
  src/gallium/drivers/r600/r600_state_common.c | 14 +
  3 files changed, 23 insertions(+), 25 deletions(-)

 diff --git a/src/gallium/drivers/r600/r600_pipe.h 
 b/src/gallium/drivers/r600/r600_pipe.h
 index eb70360..4bd3d7c 100644
 --- a/src/gallium/drivers/r600/r600_pipe.h
 +++ b/src/gallium/drivers/r600/r600_pipe.h
 @@ -36,6 +36,8 @@
  #include util/list.h
  #include util/u_transfer.h

 +#include tgsi/tgsi_scan.h
 +
  #define R600_NUM_ATOMS 75

  #define R600_MAX_VIEWPORTS 16
 @@ -305,6 +307,7 @@ struct r600_pipe_shader_selector {

 struct tgsi_token   *tokens;
 struct pipe_stream_output_info  so;
 +   struct tgsi_shader_info info;

 unsignednum_shaders;

 diff --git a/src/gallium/drivers/r600/r600_shader.c 
 b/src/gallium/drivers/r600/r600_shader.c
 index f0b794c..a265fb8 100644
 --- a/src/gallium/drivers/r600/r600_shader.c
 +++ b/src/gallium/drivers/r600/r600_shader.c
 @@ -1809,7 +1809,6 @@ static int r600_shader_from_tgsi(struct r600_context 
 *rctx,
 struct tgsi_token *tokens = pipeshader-selector-tokens;
 struct pipe_stream_output_info so = pipeshader-selector-so;
 struct tgsi_full_immediate *immediate;
 -   struct tgsi_full_property *property;
 struct r600_shader_ctx ctx;
 struct r600_bytecode_output output[32];
 unsigned output_done, noutput;
 @@ -1968,6 +1967,12 @@ static int r600_shader_from_tgsi(struct r600_context 
 *rctx,
 ctx.nliterals = 0;
 ctx.literals = NULL;
 shader-fs_write_all = FALSE;
 +   if (ctx.info.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])
 +   shader-fs_write_all = TRUE;
 +
 +   shader-vs_position_window_space = FALSE;
 +   if (ctx.info.properties[TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION])
 +   shader-vs_position_window_space = TRUE;

For the two above, you can just do:
shader-... = ctx.info.properties[...];

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


Re: [Mesa-dev] [PATCH 4/4] r600g: Use TGSI parse results instead of manually exfiltrating

2015-08-29 Thread Marek Olšák
This is a patch that doesn't change anything. :)

For the series:
Reviewed-by: Marek Olšák marek.ol...@amd.com

Marek

On Sat, Aug 29, 2015 at 10:31 AM, Edward O'Callaghan
edward.ocallag...@koparo.com wrote:
 From: Edward O'Callaghan eocallag...@alterapraxis.com

 This makes better use of the work that the TGSI API has done for
 us.

 Signed-off-by: Edward O'Callaghan eocallag...@alterapraxis.com
 ---
  src/gallium/drivers/r600/r600_shader.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/gallium/drivers/r600/r600_shader.c 
 b/src/gallium/drivers/r600/r600_shader.c
 index a265fb8..b7d7828 100644
 --- a/src/gallium/drivers/r600/r600_shader.c
 +++ b/src/gallium/drivers/r600/r600_shader.c
 @@ -1839,7 +1839,7 @@ static int r600_shader_from_tgsi(struct r600_context 
 *rctx,
 shader-indirect_files = ctx.info.indirect_files;
 indirect_gprs = ctx.info.indirect_files  ~(1  TGSI_FILE_CONSTANT);
 tgsi_parse_init(ctx.parse, tokens);
 -   ctx.type = ctx.parse.FullHeader.Processor.Processor;
 +   ctx.type = ctx.info.processor;
 shader-processor_type = ctx.type;
 ctx.bc-type = shader-processor_type;

 --
 2.4.3

 ___
 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] configure.ac: Add support to enable read-only text segment on x86.

2015-08-29 Thread Matt Turner
From: Jeremy Huddleston jerem...@freedesktop.org

Cc: 10.6 11.0 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.gentoo.org/240956
---
This is the last patch Gentoo carries :)

 configure.ac | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/configure.ac b/configure.ac
index 90ba4fe..583d45b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -500,6 +500,16 @@ AC_LINK_IFELSE(
 LDFLAGS=$save_LDFLAGS
 AM_CONDITIONAL(HAVE_LD_VERSION_SCRIPT, test $have_ld_version_script = yes)
 
+dnl Read-only text segment on x86 hardened platforms
+AC_ARG_ENABLE([glx-rts],
+[AS_HELP_STRING([--enable-glx-rts],
+[Use a read-only text segment on x86 for libGL 
@:@default=disabled@:@])],
+[enable_glx_rts=$enableval],
+[enable_glx_rts=no])
+if test x$enable_glx_rts = xyes; then
+DEFINES=$DEFINES -DGLX_X86_READONLY_TEXT
+fi
+
 dnl
 dnl Check if linker supports dynamic list files
 dnl
-- 
2.4.6

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


[Mesa-dev] [Bug 91778] white screen in unigine tropics and sanctuary with 11RC1

2015-08-29 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91778

Kenneth Graunke kenn...@whitecape.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Kenneth Graunke kenn...@whitecape.org ---


*** This bug has been marked as a duplicate of bug 82897 ***

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


Re: [Mesa-dev] [PATCH 05/12] i965: Store a key_tex pointer in vec4_visitor.

2015-08-29 Thread Matt Turner
On Sat, Aug 29, 2015 at 2:23 AM, Kenneth Graunke kenn...@whitecape.org wrote:
 I'm about to remove the base class for VS/GS/HS/DS program keys, at
 which point we won't be able to use key-tex anymore.  Instead, we'll
 need to store a direct pointer (like we do in the FS backend).

 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
  src/mesa/drivers/dri/i965/brw_vec4.h   |  1 +
  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp |  4 ++--
  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 13 +++--
  3 files changed, 10 insertions(+), 8 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
 b/src/mesa/drivers/dri/i965/brw_vec4.h
 index 7c31932..10439f2 100644
 --- a/src/mesa/drivers/dri/i965/brw_vec4.h
 +++ b/src/mesa/drivers/dri/i965/brw_vec4.h
 @@ -101,6 +101,7 @@ public:
 }

 const struct brw_vue_prog_key * const key;
 +   const struct brw_sampler_prog_key_data * const key_tex;
 struct brw_vue_prog_data * const prog_data;
 unsigned int sanity_param_count;

 diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
 b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
 index 59e440a..f3dc112 100644
 --- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
 +++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
 @@ -1409,7 +1409,7 @@ vec4_visitor::nir_emit_texture(nir_tex_instr *instr)
  * emitting anything other than setting up the constant result.
  */
 if (instr-op == nir_texop_tg4) {
 -  int swiz = GET_SWZ(key-tex.swizzles[sampler], instr-component);
 +  int swiz = GET_SWZ(key_tex-swizzles[sampler], instr-component);
if (swiz == SWIZZLE_ZERO || swiz == SWIZZLE_ONE) {
   emit(MOV(dest, src_reg(swiz == SWIZZLE_ONE ? 1.0f : 0.0f)));
   return;
 @@ -1471,7 +1471,7 @@ vec4_visitor::nir_emit_texture(nir_tex_instr *instr)
   sample_index = get_nir_src(instr-src[i].src, BRW_REGISTER_TYPE_D, 
 1);
   assert(coord_type != NULL);
   if (devinfo-gen = 7 
 - key-tex.compressed_multisample_layout_mask  (1sampler)) {
 + key_tex-compressed_multisample_layout_mask  (1  sampler)) {
  mcs = emit_mcs_fetch(coord_type, coordinate, sampler_reg);
   } else {
  mcs = src_reg(0u);
 diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
 b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
 index 978d28c..5a6e8a8 100644
 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
 +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
 @@ -2693,7 +2693,7 @@ vec4_visitor::emit_texture(ir_texture_opcode op,
 }

 if (devinfo-gen == 6  op == ir_tg4) {
 -  emit_gen6_gather_wa(key-tex.gen6_gather_wa[sampler], inst-dst);
 +  emit_gen6_gather_wa(key_tex-gen6_gather_wa[sampler], inst-dst);
 }

 swizzle_result(op, dest,
 @@ -2745,7 +2745,7 @@ vec4_visitor::visit(ir_texture *ir)
  */
 if (ir-op == ir_tg4) {
ir_constant *chan = ir-lod_info.component-as_constant();
 -  int swiz = GET_SWZ(key-tex.swizzles[sampler], chan-value.i[0]);
 +  int swiz = GET_SWZ(key_tex-swizzles[sampler], chan-value.i[0]);
if (swiz == SWIZZLE_ZERO || swiz == SWIZZLE_ONE) {
   dst_reg result(this, ir-type);
   this-result = src_reg(result);
 @@ -2803,7 +2803,7 @@ vec4_visitor::visit(ir_texture *ir)
ir-lod_info.sample_index-accept(this);
sample_index = this-result;

 -  if (devinfo-gen = 7  key-tex.compressed_multisample_layout_mask  
 (1sampler))
 +  if (devinfo-gen = 7  key_tex-compressed_multisample_layout_mask  
 (1  sampler))
   mcs = emit_mcs_fetch(ir-coordinate-type, coordinate, sampler_reg);
else
   mcs = src_reg(0u);
 @@ -2881,14 +2881,14 @@ vec4_visitor::emit_gen6_gather_wa(uint8_t wa, dst_reg 
 dst)
  uint32_t
  vec4_visitor::gather_channel(unsigned gather_component, uint32_t sampler)
  {
 -   int swiz = GET_SWZ(key-tex.swizzles[sampler], gather_component);
 +   int swiz = GET_SWZ(key_tex-swizzles[sampler], gather_component);
 switch (swiz) {
case SWIZZLE_X: return 0;
case SWIZZLE_Y:
   /* gather4 sampler is broken for green channel on RG32F --
* we must ask for blue instead.
*/
 - if (key-tex.gather_channel_quirk_mask  (1sampler))
 + if (key_tex-gather_channel_quirk_mask  (1sampler))

Thanks for adding spaces around  -- you should do it here too. :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 00/10] i965: add ARB_shader_texture_image_samples support

2015-08-29 Thread Kenneth Graunke
On Friday, August 28, 2015 12:54:35 PM Ilia Mirkin wrote:
 On Fri, Aug 28, 2015 at 6:58 AM, Francisco Jerez curroje...@riseup.net 
 wrote:
  Ilia Mirkin imir...@alum.mit.edu writes:
 
  This should include everything. I sent a test for textureSamples to
  piglit a while ago, not sure how to test imageSamples -- apparently ms
  images aren't entirely supported on i965? But I'm not sure via what
  feat that happens.
 
  i965 doesn't support MS images because on Gen7-8 it would involve either
  converting all MS textures to UMS on the fly or implementing the
  compressed MS layout in software, which would be even more madness.  On
  Gen9 and up though it's supported natively by the hardware and it
  shouldn't be too difficult to implement, I just haven't had the chance
  to do the work yet.
 
 Yeah, I've heard that before, but... what exactly prevents one from
 using a 2DMS image? I didn't see anything that checked if the images
 were MS.
 
   -ilia

We set ctx-Const.MaxImageSamples = 0 (brw_context.c:518), which is
exposed to the application as glGetInteger(GL_MAX_IMAGE_SAMPLES).

I see some validation code in core Mesa that uses that field, but I
haven't looked too closely.


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


Re: [Mesa-dev] [PATCH] configure.ac: Add support to enable read-only text segment on x86.

2015-08-29 Thread Matt Turner
On Sat, Aug 29, 2015 at 6:57 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
 On Sat, Aug 29, 2015 at 9:46 PM, Matt Turner matts...@gmail.com wrote:
 On Sat, Aug 29, 2015 at 4:27 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
 Why isn't this the default? IOW should this be incompatible with some
 other option and/or set based on some other option?

 Please don't top quote.

 I usually don't, but there wasn't a nice logical place for me to ask
 my question, top seemed as good as any.


 If I understand correctly, this option partially disables an
 optimization in the dispatch table, but the options are still
 distinct.

 My understanding is that with the x86 assembly dispatch
 implementation, either (or both...?) of

 glapi_entrypoint.c:init_glapi_relocs()
 entry_x86_tls.h:entry_patch_public()

 patch .text to contain the TLS pointer, so that the expensive movl
 %gs:0x0, %eax doesn't happen on each GL function call. But that of
 course requires a writable .text section, which is frowned upon.

 So --enable-glx-rts (I'd be happy to change the name to something less
 cryptic) inhibits that, and instead does the expensive TLS look-up
 (see src/mapi/glapi/gen/gl_x86_asm.py) on each GL call, but still uses
 the assembly implementation.

 The assembly implementation is able to jump directly to the _mesa_*
 function implementation (that is, not a call instruction that pushes
 more stuff on the stack), so I think even with --enable-glx-rts, the
 assembly implementation is still better than the C implementation.

 We'll see if idr reads his mail and can confirm my understanding.

 I see. Perhaps a small bit of this commentary can end up in the
 configure option help? i.e. that it allows .text to be read-only at
 some performance cost? Basically when I run ./configure --help, it's
 nice to know what the various options do without being deeply involved
 in the package's functionality. I think things like read only text
 segment make sense, but then the question becomes why it's not just
 always on -- mentioning that there's a small performance penalty would
 be nice.

Indeed, that's a good plan. Hopefully someone can confirm what I said
so I'm not just spreading rumours via ./configure --help :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] r600: port si_conv_prim_to_gs_out from radeonsi

2015-08-29 Thread Ilia Mirkin
On Sun, Aug 30, 2015 at 1:27 AM, Jonathan Gray j...@jsg.id.au wrote:
 On Fri, Aug 28, 2015 at 10:47:44AM +1000, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com

 This code we broken by the tess merge, and I totally missed it
 until now. I'm not sure this fixes anything but it stops the assert.

 Cc: 11.0 mesa-sta...@lists.freedesktop.org
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  src/gallium/drivers/r600/r600_pipe.h | 31 ---
  1 file changed, 16 insertions(+), 15 deletions(-)

 diff --git a/src/gallium/drivers/r600/r600_pipe.h 
 b/src/gallium/drivers/r600/r600_pipe.h
 index 384ba80..3247aba 100644
 --- a/src/gallium/drivers/r600/r600_pipe.h
 +++ b/src/gallium/drivers/r600/r600_pipe.h
 @@ -939,21 +939,22 @@ static inline bool r600_can_read_depth(struct 
 r600_texture *rtex)
  static inline unsigned r600_conv_prim_to_gs_out(unsigned mode)
  {
   static const int prim_conv[] = {
 - V_028A6C_OUTPRIM_TYPE_POINTLIST,
 - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP
 + [PIPE_PRIM_POINTS]  = 
 V_028A6C_OUTPRIM_TYPE_POINTLIST,
 + [PIPE_PRIM_LINES]   = 
 V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 + [PIPE_PRIM_LINE_LOOP]   = 
 V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 + [PIPE_PRIM_LINE_STRIP]  = 
 V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 + [PIPE_PRIM_TRIANGLES]   = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_TRIANGLE_STRIP]  = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_TRIANGLE_FAN]= 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_QUADS]   = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_QUAD_STRIP]  = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_POLYGON] = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_LINES_ADJACENCY] = 
 V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 + [PIPE_PRIM_LINE_STRIP_ADJACENCY]= 
 V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 + [PIPE_PRIM_TRIANGLES_ADJACENCY] = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY]= 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_PATCHES] = 
 V_028A6C_OUTPRIM_TYPE_POINTLIST,
 + [R600_PRIM_RECTANGLE_LIST]  = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP
   };
   assert(mode  Elements(prim_conv));

 This seems to have broken the build on OpenBSD with gcc 4.2.1:

 In file included from sb/sb_bc_parser.cpp:35:
 ./r600_pipe.h: In function 'unsigned int r600_conv_prim_to_gs_out(unsigned 
 int)':
 ./r600_pipe.h:942: error: expected primary-expression before '[' token
 ./r600_pipe.h:943: error: expected primary-expression before '[' token
 ./r600_pipe.h:944: error: expected primary-expression before '[' token
 ./r600_pipe.h:945: error: expected primary-expression before '[' token
 ./r600_pipe.h:946: error: expected primary-expression before '[' token
 ./r600_pipe.h:947: error: expected primary-expression before '[' token
 ./r600_pipe.h:948: error: expected primary-expression before '[' token
 ./r600_pipe.h:949: error: expected primary-expression before '[' token
 ./r600_pipe.h:950: error: expected primary-expression before '[' token
 ./r600_pipe.h:951: error: expected primary-expression before '[' token
 ./r600_pipe.h:952: error: expected primary-expression before '[' token
 ./r600_pipe.h:953: error: expected primary-expression before '[' token
 ./r600_pipe.h:954: error: expected primary-expression before '[' token
 ./r600_pipe.h:955: error: expected primary-expression before '[' token
 ./r600_pipe.h:956: error: expected primary-expression before '[' token
 ./r600_pipe.h:957: error: expected primary-expression before '[' token
 Makefile:801: recipe for target 'sb/sb_bc_parser.lo' failed

We definitely do this sort of thing elsewhere... does it work if you do

static const int prim_conv[PIPE_PRIM_MAX+1] = { ... }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] configure.ac: Add support to enable read-only text segment on x86.

2015-08-29 Thread Ilia Mirkin
On Sat, Aug 29, 2015 at 9:46 PM, Matt Turner matts...@gmail.com wrote:
 On Sat, Aug 29, 2015 at 4:27 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
 Why isn't this the default? IOW should this be incompatible with some
 other option and/or set based on some other option?

 Please don't top quote.

I usually don't, but there wasn't a nice logical place for me to ask
my question, top seemed as good as any.


 If I understand correctly, this option partially disables an
 optimization in the dispatch table, but the options are still
 distinct.

 My understanding is that with the x86 assembly dispatch
 implementation, either (or both...?) of

 glapi_entrypoint.c:init_glapi_relocs()
 entry_x86_tls.h:entry_patch_public()

 patch .text to contain the TLS pointer, so that the expensive movl
 %gs:0x0, %eax doesn't happen on each GL function call. But that of
 course requires a writable .text section, which is frowned upon.

 So --enable-glx-rts (I'd be happy to change the name to something less
 cryptic) inhibits that, and instead does the expensive TLS look-up
 (see src/mapi/glapi/gen/gl_x86_asm.py) on each GL call, but still uses
 the assembly implementation.

 The assembly implementation is able to jump directly to the _mesa_*
 function implementation (that is, not a call instruction that pushes
 more stuff on the stack), so I think even with --enable-glx-rts, the
 assembly implementation is still better than the C implementation.

 We'll see if idr reads his mail and can confirm my understanding.

I see. Perhaps a small bit of this commentary can end up in the
configure option help? i.e. that it allows .text to be read-only at
some performance cost? Basically when I run ./configure --help, it's
nice to know what the various options do without being deeply involved
in the package's functionality. I think things like read only text
segment make sense, but then the question becomes why it's not just
always on -- mentioning that there's a small performance penalty would
be nice.

I had actually assumed that this was more about rtasm stuff, but I
guess that's all separate.

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


Re: [Mesa-dev] [PATCH] configure.ac: Add support to enable read-only text segment on x86.

2015-08-29 Thread Matt Turner
On Sat, Aug 29, 2015 at 4:27 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
 Why isn't this the default? IOW should this be incompatible with some
 other option and/or set based on some other option?

Please don't top quote.

If I understand correctly, this option partially disables an
optimization in the dispatch table, but the options are still
distinct.

My understanding is that with the x86 assembly dispatch
implementation, either (or both...?) of

glapi_entrypoint.c:init_glapi_relocs()
entry_x86_tls.h:entry_patch_public()

patch .text to contain the TLS pointer, so that the expensive movl
%gs:0x0, %eax doesn't happen on each GL function call. But that of
course requires a writable .text section, which is frowned upon.

So --enable-glx-rts (I'd be happy to change the name to something less
cryptic) inhibits that, and instead does the expensive TLS look-up
(see src/mapi/glapi/gen/gl_x86_asm.py) on each GL call, but still uses
the assembly implementation.

The assembly implementation is able to jump directly to the _mesa_*
function implementation (that is, not a call instruction that pushes
more stuff on the stack), so I think even with --enable-glx-rts, the
assembly implementation is still better than the C implementation.

We'll see if idr reads his mail and can confirm my understanding.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] r600: port si_conv_prim_to_gs_out from radeonsi

2015-08-29 Thread Jonathan Gray
On Fri, Aug 28, 2015 at 10:47:44AM +1000, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 This code we broken by the tess merge, and I totally missed it
 until now. I'm not sure this fixes anything but it stops the assert.
 
 Cc: 11.0 mesa-sta...@lists.freedesktop.org
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  src/gallium/drivers/r600/r600_pipe.h | 31 ---
  1 file changed, 16 insertions(+), 15 deletions(-)
 
 diff --git a/src/gallium/drivers/r600/r600_pipe.h 
 b/src/gallium/drivers/r600/r600_pipe.h
 index 384ba80..3247aba 100644
 --- a/src/gallium/drivers/r600/r600_pipe.h
 +++ b/src/gallium/drivers/r600/r600_pipe.h
 @@ -939,21 +939,22 @@ static inline bool r600_can_read_depth(struct 
 r600_texture *rtex)
  static inline unsigned r600_conv_prim_to_gs_out(unsigned mode)
  {
   static const int prim_conv[] = {
 - V_028A6C_OUTPRIM_TYPE_POINTLIST,
 - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 - V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 - V_028A6C_OUTPRIM_TYPE_TRISTRIP
 + [PIPE_PRIM_POINTS]  = 
 V_028A6C_OUTPRIM_TYPE_POINTLIST,
 + [PIPE_PRIM_LINES]   = 
 V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 + [PIPE_PRIM_LINE_LOOP]   = 
 V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 + [PIPE_PRIM_LINE_STRIP]  = 
 V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 + [PIPE_PRIM_TRIANGLES]   = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_TRIANGLE_STRIP]  = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_TRIANGLE_FAN]= 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_QUADS]   = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_QUAD_STRIP]  = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_POLYGON] = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_LINES_ADJACENCY] = 
 V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 + [PIPE_PRIM_LINE_STRIP_ADJACENCY]= 
 V_028A6C_OUTPRIM_TYPE_LINESTRIP,
 + [PIPE_PRIM_TRIANGLES_ADJACENCY] = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY]= 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP,
 + [PIPE_PRIM_PATCHES] = 
 V_028A6C_OUTPRIM_TYPE_POINTLIST,
 + [R600_PRIM_RECTANGLE_LIST]  = 
 V_028A6C_OUTPRIM_TYPE_TRISTRIP
   };
   assert(mode  Elements(prim_conv));

This seems to have broken the build on OpenBSD with gcc 4.2.1:

In file included from sb/sb_bc_parser.cpp:35:
./r600_pipe.h: In function 'unsigned int r600_conv_prim_to_gs_out(unsigned 
int)':
./r600_pipe.h:942: error: expected primary-expression before '[' token
./r600_pipe.h:943: error: expected primary-expression before '[' token
./r600_pipe.h:944: error: expected primary-expression before '[' token
./r600_pipe.h:945: error: expected primary-expression before '[' token
./r600_pipe.h:946: error: expected primary-expression before '[' token
./r600_pipe.h:947: error: expected primary-expression before '[' token
./r600_pipe.h:948: error: expected primary-expression before '[' token
./r600_pipe.h:949: error: expected primary-expression before '[' token
./r600_pipe.h:950: error: expected primary-expression before '[' token
./r600_pipe.h:951: error: expected primary-expression before '[' token
./r600_pipe.h:952: error: expected primary-expression before '[' token
./r600_pipe.h:953: error: expected primary-expression before '[' token
./r600_pipe.h:954: error: expected primary-expression before '[' token
./r600_pipe.h:955: error: expected primary-expression before '[' token
./r600_pipe.h:956: error: expected primary-expression before '[' token
./r600_pipe.h:957: error: expected primary-expression before '[' token
Makefile:801: recipe for target 'sb/sb_bc_parser.lo' failed
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] No VAAPI driver hardlinks?

2015-08-29 Thread Matt Turner
Hi Emil,

src/gallium/targets/vdpau has a block that installs per-driver
hardlinks, but src/gallium/targets/va does not (presumably because it
was added later), which leads to:

https://bugs.gentoo.org/549564

Presumably it's mostly a matter of copy-n-paste?

Also, it appears that there's a minor problem with that block as well:

https://bugs.gentoo.org/545230

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


Re: [Mesa-dev] [PATCH] configure.ac: Add support to enable read-only text segment on x86.

2015-08-29 Thread Ilia Mirkin
Why isn't this the default? IOW should this be incompatible with some
other option and/or set based on some other option?

On Sat, Aug 29, 2015 at 5:54 PM, Matt Turner matts...@gmail.com wrote:
 From: Jeremy Huddleston jerem...@freedesktop.org

 Cc: 10.6 11.0 mesa-sta...@lists.freedesktop.org
 Bugzilla: https://bugs.gentoo.org/240956
 ---
 This is the last patch Gentoo carries :)

  configure.ac | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/configure.ac b/configure.ac
 index 90ba4fe..583d45b 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -500,6 +500,16 @@ AC_LINK_IFELSE(
  LDFLAGS=$save_LDFLAGS
  AM_CONDITIONAL(HAVE_LD_VERSION_SCRIPT, test $have_ld_version_script = 
 yes)

 +dnl Read-only text segment on x86 hardened platforms
 +AC_ARG_ENABLE([glx-rts],
 +[AS_HELP_STRING([--enable-glx-rts],
 +[Use a read-only text segment on x86 for libGL 
 @:@default=disabled@:@])],
 +[enable_glx_rts=$enableval],
 +[enable_glx_rts=no])
 +if test x$enable_glx_rts = xyes; then
 +DEFINES=$DEFINES -DGLX_X86_READONLY_TEXT
 +fi
 +
  dnl
  dnl Check if linker supports dynamic list files
  dnl
 --
 2.4.6

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


[Mesa-dev] [Bug 91020] Mesa's demo / tools won't compile since EGL changes

2015-08-29 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91020

Dennis Schridde devuran...@gmx.net changed:

   What|Removed |Added

 CC||devuran...@gmx.net

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