Re: [Mesa-dev] [PATCH 0/5] Add ARB_derivative_control support

[Matt Turner]

On Wed, Aug 13, 2014 at 9:52 PM, Ilia Mirkin  wrote:
> I left all the variants as separate operations in the glsl ir. However for
> gallium I only added the fine version, as it seems like DDX can do pretty much
> whatever it wants. I was on the fence about adding coarse versions as well and
> then using the FragmentShaderDerivative hint to select one or the other in the
> glsl -> tgsi conversion.
>
> In the case of nv50/nvc0, doing the fine version is pretty much the only
> (easy) way of doing derivatives. I haven't traced the blob to see how it
> handles things yet. In any case, on nv50/nvc0 all this is completely moot, at
> least for now. Curious about what the situation with other hardware is.

i965 already implements coarse and fine derivatives, selectable by the
derivatives hint, coarse default.

The calculation of the derivative itself isn't faster for coarse
derivatives, but it was discovered that if all of the samples of a
sample_d are from the same LOD, it's a bunch faster on Haswell at
least. See commit 848c0e72. And with coarse derivatives they are.

Maybe other hardware has similar optimizations?

> Also, the extension spec claims to require GLSL 4.00, which seems a little
> extreme. Instead I restrict it to core contexts. Let me know if I should
> change this.

Making it core-only doesn't help, nor does it satisfy the GLSL >= 4.0
requirement in the spec. I'm not sure if we have a way to arbitrarily
limit an extension to being exposed under certain GLSL versions... ?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/5] glsl: add ARB_derivative control support

[Matt Turner]

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

Re: [Mesa-dev] [PATCH 1/5] mesa: add ARB_derivative_control extension bit

[Matt Turner]

On Wed, Aug 13, 2014 at 9:52 PM, Ilia Mirkin  wrote:
> Signed-off-by: Ilia Mirkin 
> ---
>  src/mesa/main/extensions.c | 1 +
>  src/mesa/main/mtypes.h | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> index 8658ca8..3dcb199 100644
> --- a/src/mesa/main/extensions.c
> +++ b/src/mesa/main/extensions.c
> @@ -101,6 +101,7 @@ static const struct extension extension_table[] = {
> { "GL_ARB_depth_buffer_float",  
> o(ARB_depth_buffer_float),  GL, 2008 },
> { "GL_ARB_depth_clamp", o(ARB_depth_clamp),   
>   GL, 2003 },
> { "GL_ARB_depth_texture",   o(ARB_depth_texture), 
>   GLL,2001 },
> +   { "GL_ARB_derivative_control",  
> o(ARB_derivative_control),  GLC,2014 },

No reason to be core-only that I can see.

With s/GLC/GL/ this is

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

[Mesa-dev] [PATCH v2 2/5] glsl: add ARB_derivative control support

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---

Oops :) The piglit tests caught these...

v1 -> v2:
 - add constant expression handling
 - add name strings for new opcodes
 - add new opcodes into ir_expression constructor

 src/glsl/builtin_functions.cpp  | 48 +
 src/glsl/glcpp/glcpp-parse.y|  3 +++
 src/glsl/glsl_parser_extras.cpp |  1 +
 src/glsl/glsl_parser_extras.h   |  2 ++
 src/glsl/ir.cpp |  8 +++
 src/glsl/ir.h   |  4 
 src/glsl/ir_constant_expression.cpp |  4 
 src/glsl/ir_validate.cpp|  4 
 8 files changed, 74 insertions(+)

diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 185fe98..c882ec8 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -318,6 +318,14 @@ fs_oes_derivatives(const _mesa_glsl_parse_state *state)
 }
 
 static bool
+fs_derivative_control(const _mesa_glsl_parse_state *state)
+{
+   return state->stage == MESA_SHADER_FRAGMENT &&
+  (state->is_version(450, 0) ||
+   state->ARB_derivative_control_enable);
+}
+
+static bool
 tex1d_lod(const _mesa_glsl_parse_state *state)
 {
return !state->es_shader && lod_exists_in_stage(state);
@@ -618,6 +626,12 @@ private:
B1(dFdx);
B1(dFdy);
B1(fwidth);
+   B1(dFdxCoarse);
+   B1(dFdyCoarse);
+   B1(fwidthCoarse);
+   B1(dFdxFine);
+   B1(dFdyFine);
+   B1(fwidthFine);
B1(noise1);
B1(noise2);
B1(noise3);
@@ -2148,6 +2162,12 @@ builtin_builder::create_builtins()
F(dFdx)
F(dFdy)
F(fwidth)
+   F(dFdxCoarse)
+   F(dFdyCoarse)
+   F(fwidthCoarse)
+   F(dFdxFine)
+   F(dFdyFine)
+   F(fwidthFine)
F(noise1)
F(noise2)
F(noise3)
@@ -4010,7 +4030,11 @@ builtin_builder::_textureQueryLevels(const glsl_type 
*sampler_type)
 }
 
 UNOP(dFdx, ir_unop_dFdx, fs_oes_derivatives)
+UNOP(dFdxCoarse, ir_unop_dFdx_coarse, fs_derivative_control)
+UNOP(dFdxFine, ir_unop_dFdx_fine, fs_derivative_control)
 UNOP(dFdy, ir_unop_dFdy, fs_oes_derivatives)
+UNOP(dFdyCoarse, ir_unop_dFdy_coarse, fs_derivative_control)
+UNOP(dFdyFine, ir_unop_dFdy_fine, fs_derivative_control)
 
 ir_function_signature *
 builtin_builder::_fwidth(const glsl_type *type)
@@ -4024,6 +4048,30 @@ builtin_builder::_fwidth(const glsl_type *type)
 }
 
 ir_function_signature *
+builtin_builder::_fwidthCoarse(const glsl_type *type)
+{
+   ir_variable *p = in_var(type, "p");
+   MAKE_SIG(type, fs_derivative_control, 1, p);
+
+   body.emit(ret(add(abs(expr(ir_unop_dFdx_coarse, p)),
+ abs(expr(ir_unop_dFdy_coarse, p);
+
+   return sig;
+}
+
+ir_function_signature *
+builtin_builder::_fwidthFine(const glsl_type *type)
+{
+   ir_variable *p = in_var(type, "p");
+   MAKE_SIG(type, fs_derivative_control, 1, p);
+
+   body.emit(ret(add(abs(expr(ir_unop_dFdx_fine, p)),
+ abs(expr(ir_unop_dFdy_fine, p);
+
+   return sig;
+}
+
+ir_function_signature *
 builtin_builder::_noise1(const glsl_type *type)
 {
return unop(v110, ir_unop_noise, glsl_type::float_type, type);
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index a616973..f1119eb 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -2469,6 +2469,9 @@ _glcpp_parser_handle_version_declaration(glcpp_parser_t 
*parser, intmax_t versio
 
  if (extensions->ARB_shader_image_load_store)
 add_builtin_define(parser, "GL_ARB_shader_image_load_store", 
1);
+
+  if (extensions->ARB_derivative_control)
+ add_builtin_define(parser, "GL_ARB_derivative_control", 1);
   }
}
 
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index ad91c46..490c3c8 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -514,6 +514,7 @@ static const _mesa_glsl_extension 
_mesa_glsl_supported_extensions[] = {
EXT(ARB_arrays_of_arrays,   true,  false, ARB_arrays_of_arrays),
EXT(ARB_compute_shader, true,  false, ARB_compute_shader),
EXT(ARB_conservative_depth, true,  false, 
ARB_conservative_depth),
+   EXT(ARB_derivative_control, true,  false, 
ARB_derivative_control),
EXT(ARB_draw_buffers,   true,  false, dummy_true),
EXT(ARB_draw_instanced, true,  false, ARB_draw_instanced),
EXT(ARB_explicit_attrib_location,   true,  false, 
ARB_explicit_attrib_location),
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index ce66e2f..c8b9478 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -393,6 +393,8 @@ struct _mesa_glsl_parse_state {
bool ARB_compute_shader_warn;
bool ARB_conservative_depth_enable;
bool ARB_conservative_depth_warn;
+   bool ARB_derivative_control_enable;
+   bool ARB_derivative_control_warn;
bool ARB_draw_buffers_enable;
bool ARB_draw_buffers_w

[Mesa-dev] [PATCH 0/5] Add ARB_derivative_control support

[Ilia Mirkin]

I left all the variants as separate operations in the glsl ir. However for
gallium I only added the fine version, as it seems like DDX can do pretty much
whatever it wants. I was on the fence about adding coarse versions as well and
then using the FragmentShaderDerivative hint to select one or the other in the
glsl -> tgsi conversion.

In the case of nv50/nvc0, doing the fine version is pretty much the only
(easy) way of doing derivatives. I haven't traced the blob to see how it
handles things yet. In any case, on nv50/nvc0 all this is completely moot, at
least for now. Curious about what the situation with other hardware is.

Also, the extension spec claims to require GLSL 4.00, which seems a little
extreme. Instead I restrict it to core contexts. Let me know if I should
change this.

I will try to send some piglits out for this soon, but it's all fairly
straightforward...

Ilia Mirkin (5):
  mesa: add ARB_derivative_control extension bit
  glsl: add ARB_derivative control support
  gallium: add opcodes/cap for fine derivative support
  mesa/st: add support for emitting fine derivative opcodes
  nv50,nvc0: add support for fine derivatives

 docs/GL3.txt   |  2 +-
 src/gallium/auxiliary/tgsi/tgsi_info.c |  3 ++
 src/gallium/auxiliary/tgsi/tgsi_util.c |  2 +
 src/gallium/docs/source/screen.rst |  2 +
 src/gallium/docs/source/tgsi.rst   | 12 +-
 src/gallium/drivers/freedreno/freedreno_screen.c   |  1 +
 src/gallium/drivers/i915/i915_screen.c |  1 +
 src/gallium/drivers/ilo/ilo_screen.c   |  1 +
 src/gallium/drivers/llvmpipe/lp_screen.c   |  1 +
 .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  |  4 ++
 src/gallium/drivers/nouveau/nv30/nv30_screen.c |  1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c |  1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c |  1 +
 src/gallium/drivers/r300/r300_screen.c |  1 +
 src/gallium/drivers/r600/r600_pipe.c   |  1 +
 src/gallium/drivers/radeonsi/si_pipe.c |  1 +
 src/gallium/drivers/softpipe/sp_screen.c   |  1 +
 src/gallium/drivers/svga/svga_screen.c |  1 +
 src/gallium/drivers/vc4/vc4_screen.c   |  1 +
 src/gallium/include/pipe/p_defines.h   |  1 +
 src/gallium/include/pipe/p_shader_tokens.h |  5 ++-
 src/glsl/builtin_functions.cpp | 48 ++
 src/glsl/glcpp/glcpp-parse.y   |  3 ++
 src/glsl/glsl_parser_extras.cpp|  1 +
 src/glsl/glsl_parser_extras.h  |  2 +
 src/glsl/ir.h  |  4 ++
 src/glsl/ir_validate.cpp   |  4 ++
 src/mesa/main/extensions.c |  1 +
 src/mesa/main/mtypes.h |  1 +
 src/mesa/state_tracker/st_extensions.c |  3 +-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  9 +++-
 31 files changed, 114 insertions(+), 6 deletions(-)

-- 
1.8.5.5

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

[Mesa-dev] [PATCH 5/5] nv50, nvc0: add support for fine derivatives

[Ilia Mirkin]

The quadop-based method we currently use on all chipsets already
provides the fine version of the derivatives.

Signed-off-by: Ilia Mirkin 
---
 docs/GL3.txt  | 2 +-
 src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 4 
 src/gallium/drivers/nouveau/nv50/nv50_screen.c| 2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 2 +-
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 89529fe..0a40e23 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -189,7 +189,7 @@ GL 4.5, GLSL 4.50:
   GL_ARB_clip_control  not started
   GL_ARB_conditional_render_inverted   not started
   GL_ARB_cull_distance not started
-  GL_ARB_derivative_controlnot started
+  GL_ARB_derivative_controlDONE (nv50, nvc0)
   GL_ARB_direct_state_access   not started
   GL_ARB_get_texture_sub_image started (Brian Paul)
   GL_ARB_shader_texture_image_samples  not started
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 14b6d68..456efcb 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -531,7 +531,9 @@ static nv50_ir::operation translateOpcode(uint opcode)
 
NV50_IR_OPCODE_CASE(COS, COS);
NV50_IR_OPCODE_CASE(DDX, DFDX);
+   NV50_IR_OPCODE_CASE(DDX_FINE, DFDX);
NV50_IR_OPCODE_CASE(DDY, DFDY);
+   NV50_IR_OPCODE_CASE(DDY_FINE, DFDY);
NV50_IR_OPCODE_CASE(KILL, DISCARD);
 
NV50_IR_OPCODE_CASE(SEQ, SET);
@@ -2327,6 +2329,8 @@ Converter::handleInstruction(const struct 
tgsi_full_instruction *insn)
case TGSI_OPCODE_NOT:
case TGSI_OPCODE_DDX:
case TGSI_OPCODE_DDY:
+   case TGSI_OPCODE_DDX_FINE:
+   case TGSI_OPCODE_DDY_FINE:
   FOR_EACH_DST_ENABLED_CHANNEL(0, c, tgsi)
  mkOp1(op, dstTy, dst0[c], fetchSrc(0, c));
   break;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 34cca3d..8a9a40e 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -169,6 +169,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_USER_VERTEX_BUFFERS:
case PIPE_CAP_TEXTURE_MULTISAMPLE:
case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
+   case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
   return 1;
case PIPE_CAP_SEAMLESS_CUBE_MAP:
   return 1; /* class_3d >= NVA0_3D_CLASS; */
@@ -200,7 +201,6 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
case PIPE_CAP_COMPUTE:
case PIPE_CAP_DRAW_INDIRECT:
-   case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
   return 0;
}
 
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 17aee63..c6d9b91 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -167,6 +167,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_SAMPLE_SHADING:
case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
case PIPE_CAP_TEXTURE_GATHER_SM5:
+   case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
   return 1;
case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
   return (class_3d >= NVE4_3D_CLASS) ? 1 : 0;
@@ -184,7 +185,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
case PIPE_CAP_FAKE_SW_MSAA:
case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
-   case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
   return 0;
}
 
-- 
1.8.5.5

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

[Mesa-dev] [PATCH 4/5] mesa/st: add support for emitting fine derivative opcodes

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 src/mesa/state_tracker/st_extensions.c | 3 ++-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 9 -
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index eace321..24e886c 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -458,7 +458,8 @@ void st_init_extensions(struct pipe_screen *screen,
   { o(ARB_texture_multisample),  PIPE_CAP_TEXTURE_MULTISAMPLE  
},
   { o(ARB_texture_query_lod),PIPE_CAP_TEXTURE_QUERY_LOD
},
   { o(ARB_sample_shading),   PIPE_CAP_SAMPLE_SHADING   
},
-  { o(ARB_draw_indirect),PIPE_CAP_DRAW_INDIRECT
}
+  { o(ARB_draw_indirect),PIPE_CAP_DRAW_INDIRECT
},
+  { o(ARB_derivative_control),   PIPE_CAP_TGSI_FS_FINE_DERIVATIVE  
},
};
 
/* Required: render target and sampler support */
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 4898166..84bdc4f 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -1462,9 +1462,15 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
   break;
 
case ir_unop_dFdx:
+   case ir_unop_dFdx_coarse:
   emit(ir, TGSI_OPCODE_DDX, result_dst, op[0]);
   break;
+   case ir_unop_dFdx_fine:
+  emit(ir, TGSI_OPCODE_DDX_FINE, result_dst, op[0]);
+  break;
case ir_unop_dFdy:
+   case ir_unop_dFdy_coarse:
+   case ir_unop_dFdy_fine:
{
   /* The X component contains 1 or -1 depending on whether the framebuffer
* is a FBO or the window system buffer, respectively.
@@ -1485,7 +1491,8 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
   st_src_reg temp = get_temp(glsl_type::vec4_type);
 
   emit(ir, TGSI_OPCODE_MUL, st_dst_reg(temp), transform_y, op[0]);
-  emit(ir, TGSI_OPCODE_DDY, result_dst, temp);
+  emit(ir, ir->operation == ir_unop_dFdy_fine ?
+   TGSI_OPCODE_DDY_FINE : TGSI_OPCODE_DDY, result_dst, temp);
   break;
}
 
-- 
1.8.5.5

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

[Mesa-dev] [PATCH 3/5] gallium: add opcodes/cap for fine derivative support

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 src/gallium/auxiliary/tgsi/tgsi_info.c   |  3 +++
 src/gallium/auxiliary/tgsi/tgsi_util.c   |  2 ++
 src/gallium/docs/source/screen.rst   |  2 ++
 src/gallium/docs/source/tgsi.rst | 12 ++--
 src/gallium/drivers/freedreno/freedreno_screen.c |  1 +
 src/gallium/drivers/i915/i915_screen.c   |  1 +
 src/gallium/drivers/ilo/ilo_screen.c |  1 +
 src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  1 +
 src/gallium/drivers/r300/r300_screen.c   |  1 +
 src/gallium/drivers/r600/r600_pipe.c |  1 +
 src/gallium/drivers/radeonsi/si_pipe.c   |  1 +
 src/gallium/drivers/softpipe/sp_screen.c |  1 +
 src/gallium/drivers/svga/svga_screen.c   |  1 +
 src/gallium/drivers/vc4/vc4_screen.c |  1 +
 src/gallium/include/pipe/p_defines.h |  1 +
 src/gallium/include/pipe/p_shader_tokens.h   |  5 -
 19 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c 
b/src/gallium/auxiliary/tgsi/tgsi_info.c
index e24348f..35f9747 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_info.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
@@ -235,6 +235,9 @@ static const struct tgsi_opcode_info 
opcode_info[TGSI_OPCODE_LAST] =
{ 1, 1, 0, 0, 0, 0, OTHR, "INTERP_CENTROID", TGSI_OPCODE_INTERP_CENTROID },
{ 1, 2, 0, 0, 0, 0, OTHR, "INTERP_SAMPLE", TGSI_OPCODE_INTERP_SAMPLE },
{ 1, 2, 0, 0, 0, 0, OTHR, "INTERP_OFFSET", TGSI_OPCODE_INTERP_OFFSET },
+
+   { 1, 1, 0, 0, 0, 0, COMP, "DDX_FINE", TGSI_OPCODE_DDX_FINE },
+   { 1, 1, 0, 0, 0, 0, COMP, "DDY_FINE", TGSI_OPCODE_DDY_FINE },
 };
 
 const struct tgsi_opcode_info *
diff --git a/src/gallium/auxiliary/tgsi/tgsi_util.c 
b/src/gallium/auxiliary/tgsi/tgsi_util.c
index e48159c..e1cba95 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_util.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_util.c
@@ -245,6 +245,8 @@ tgsi_util_get_inst_usage_mask(const struct 
tgsi_full_instruction *inst,
case TGSI_OPCODE_USNE:
case TGSI_OPCODE_IMUL_HI:
case TGSI_OPCODE_UMUL_HI:
+   case TGSI_OPCODE_DDX_FINE:
+   case TGSI_OPCODE_DDY_FINE:
   /* Channel-wise operations */
   read_mask = write_mask;
   break;
diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index 814e3ae..6fecc15 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -213,6 +213,8 @@ The integer capabilities:
 * ``PIPE_CAP_DRAW_INDIRECT``: Whether the driver supports taking draw arguments
   { count, instance_count, start, index_bias } from a PIPE_BUFFER resource.
   See pipe_draw_info.
+* ``PIPE_CAP_TGSI_FS_FINE_DERIVATIVE``: Whether the fragment shader supports
+  the FINE versions of DDX/DDY.
 
 
 .. _pipe_capf:
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index ac0ea54..7d5918f 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -433,7 +433,11 @@ This instruction replicates its result.
   dst = \cos{src.x}
 
 
-.. opcode:: DDX - Derivative Relative To X
+.. opcode:: DDX, DDX_FINE - Derivative Relative To X
+
+The fine variant is only used when ``PIPE_CAP_TGSI_FS_FINE_DERIVATIVE`` is
+advertised. When it is, the fine version guarantees one derivative per row
+while DDX is allowed to be the same for the entire 2x2 quad.
 
 .. math::
 
@@ -446,7 +450,11 @@ This instruction replicates its result.
   dst.w = partialx(src.w)
 
 
-.. opcode:: DDY - Derivative Relative To Y
+.. opcode:: DDY, DDY_FINE - Derivative Relative To Y
+
+The fine variant is only used when ``PIPE_CAP_TGSI_FS_FINE_DERIVATIVE`` is
+advertised. When it is, the fine version guarantees one derivative per column
+while DDY is allowed to be the same for the entire 2x2 quad.
 
 .. math::
 
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index de69b14..b156d8b 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -216,6 +216,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
case PIPE_CAP_DRAW_INDIRECT:
+   case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
return 0;
 
/* Stream output. */
diff --git a/src/gallium/drivers/i915/i915_screen.c 
b/src/gallium/drivers/i915/i915_screen.c
index ca3dd4a..53d5e75 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -231,6 +231,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
cap)
case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
cas

[Mesa-dev] [PATCH 2/5] glsl: add ARB_derivative control support

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 src/glsl/builtin_functions.cpp  | 48 +
 src/glsl/glcpp/glcpp-parse.y|  3 +++
 src/glsl/glsl_parser_extras.cpp |  1 +
 src/glsl/glsl_parser_extras.h   |  2 ++
 src/glsl/ir.h   |  4 
 src/glsl/ir_validate.cpp|  4 
 6 files changed, 62 insertions(+)

diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 185fe98..c882ec8 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -318,6 +318,14 @@ fs_oes_derivatives(const _mesa_glsl_parse_state *state)
 }
 
 static bool
+fs_derivative_control(const _mesa_glsl_parse_state *state)
+{
+   return state->stage == MESA_SHADER_FRAGMENT &&
+  (state->is_version(450, 0) ||
+   state->ARB_derivative_control_enable);
+}
+
+static bool
 tex1d_lod(const _mesa_glsl_parse_state *state)
 {
return !state->es_shader && lod_exists_in_stage(state);
@@ -618,6 +626,12 @@ private:
B1(dFdx);
B1(dFdy);
B1(fwidth);
+   B1(dFdxCoarse);
+   B1(dFdyCoarse);
+   B1(fwidthCoarse);
+   B1(dFdxFine);
+   B1(dFdyFine);
+   B1(fwidthFine);
B1(noise1);
B1(noise2);
B1(noise3);
@@ -2148,6 +2162,12 @@ builtin_builder::create_builtins()
F(dFdx)
F(dFdy)
F(fwidth)
+   F(dFdxCoarse)
+   F(dFdyCoarse)
+   F(fwidthCoarse)
+   F(dFdxFine)
+   F(dFdyFine)
+   F(fwidthFine)
F(noise1)
F(noise2)
F(noise3)
@@ -4010,7 +4030,11 @@ builtin_builder::_textureQueryLevels(const glsl_type 
*sampler_type)
 }
 
 UNOP(dFdx, ir_unop_dFdx, fs_oes_derivatives)
+UNOP(dFdxCoarse, ir_unop_dFdx_coarse, fs_derivative_control)
+UNOP(dFdxFine, ir_unop_dFdx_fine, fs_derivative_control)
 UNOP(dFdy, ir_unop_dFdy, fs_oes_derivatives)
+UNOP(dFdyCoarse, ir_unop_dFdy_coarse, fs_derivative_control)
+UNOP(dFdyFine, ir_unop_dFdy_fine, fs_derivative_control)
 
 ir_function_signature *
 builtin_builder::_fwidth(const glsl_type *type)
@@ -4024,6 +4048,30 @@ builtin_builder::_fwidth(const glsl_type *type)
 }
 
 ir_function_signature *
+builtin_builder::_fwidthCoarse(const glsl_type *type)
+{
+   ir_variable *p = in_var(type, "p");
+   MAKE_SIG(type, fs_derivative_control, 1, p);
+
+   body.emit(ret(add(abs(expr(ir_unop_dFdx_coarse, p)),
+ abs(expr(ir_unop_dFdy_coarse, p);
+
+   return sig;
+}
+
+ir_function_signature *
+builtin_builder::_fwidthFine(const glsl_type *type)
+{
+   ir_variable *p = in_var(type, "p");
+   MAKE_SIG(type, fs_derivative_control, 1, p);
+
+   body.emit(ret(add(abs(expr(ir_unop_dFdx_fine, p)),
+ abs(expr(ir_unop_dFdy_fine, p);
+
+   return sig;
+}
+
+ir_function_signature *
 builtin_builder::_noise1(const glsl_type *type)
 {
return unop(v110, ir_unop_noise, glsl_type::float_type, type);
diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index a616973..f1119eb 100644
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -2469,6 +2469,9 @@ _glcpp_parser_handle_version_declaration(glcpp_parser_t 
*parser, intmax_t versio
 
  if (extensions->ARB_shader_image_load_store)
 add_builtin_define(parser, "GL_ARB_shader_image_load_store", 
1);
+
+  if (extensions->ARB_derivative_control)
+ add_builtin_define(parser, "GL_ARB_derivative_control", 1);
   }
}
 
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index ad91c46..490c3c8 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -514,6 +514,7 @@ static const _mesa_glsl_extension 
_mesa_glsl_supported_extensions[] = {
EXT(ARB_arrays_of_arrays,   true,  false, ARB_arrays_of_arrays),
EXT(ARB_compute_shader, true,  false, ARB_compute_shader),
EXT(ARB_conservative_depth, true,  false, 
ARB_conservative_depth),
+   EXT(ARB_derivative_control, true,  false, 
ARB_derivative_control),
EXT(ARB_draw_buffers,   true,  false, dummy_true),
EXT(ARB_draw_instanced, true,  false, ARB_draw_instanced),
EXT(ARB_explicit_attrib_location,   true,  false, 
ARB_explicit_attrib_location),
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index ce66e2f..c8b9478 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -393,6 +393,8 @@ struct _mesa_glsl_parse_state {
bool ARB_compute_shader_warn;
bool ARB_conservative_depth_enable;
bool ARB_conservative_depth_warn;
+   bool ARB_derivative_control_enable;
+   bool ARB_derivative_control_warn;
bool ARB_draw_buffers_enable;
bool ARB_draw_buffers_warn;
bool ARB_draw_instanced_enable;
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 31c3545..18623b9 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -1205,7 +1205,11 @@ enum ir_expression_operation {
 */
/*@{*/
ir_unop_dFdx,
+   ir_unop_dFdx_coarse,
+   ir_unop_dFdx_fine,

[Mesa-dev] [PATCH 1/5] mesa: add ARB_derivative_control extension bit

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 src/mesa/main/extensions.c | 1 +
 src/mesa/main/mtypes.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 8658ca8..3dcb199 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -101,6 +101,7 @@ static const struct extension extension_table[] = {
{ "GL_ARB_depth_buffer_float",  o(ARB_depth_buffer_float),  
GL, 2008 },
{ "GL_ARB_depth_clamp", o(ARB_depth_clamp), 
GL, 2003 },
{ "GL_ARB_depth_texture",   o(ARB_depth_texture),   
GLL,2001 },
+   { "GL_ARB_derivative_control",  o(ARB_derivative_control),  
GLC,2014 },
{ "GL_ARB_draw_buffers",o(dummy_true),  
GL, 2002 },
{ "GL_ARB_draw_buffers_blend",  o(ARB_draw_buffers_blend),  
GL, 2009 },
{ "GL_ARB_draw_elements_base_vertex",   
o(ARB_draw_elements_base_vertex),   GL, 2009 },
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 742ce3e..97b1ad2 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3558,6 +3558,7 @@ struct gl_extensions
GLboolean ARB_depth_buffer_float;
GLboolean ARB_depth_clamp;
GLboolean ARB_depth_texture;
+   GLboolean ARB_derivative_control;
GLboolean ARB_draw_buffers_blend;
GLboolean ARB_draw_elements_base_vertex;
GLboolean ARB_draw_indirect;
-- 
1.8.5.5

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

[Mesa-dev] [PATCH 2/2] meta: Use instanced rendering for layered clears.

[Kenneth Graunke]

Layered rendering is part of OpenGL 3.2; GL_ARB_draw_instanced is part
of OpenGL 3.1.  As such, all drivers supporting layered rendering
already support gl_InstanceID.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/common/meta.c | 21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 439c7e2..e0d39c6 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -1527,12 +1527,12 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
 {
const char *vs_source =
   "#extension GL_AMD_vertex_shader_layer : enable\n"
+  "#extension GL_ARB_draw_instanced : enable\n"
   "attribute vec4 position;\n"
-  "uniform int layer;\n"
   "void main()\n"
   "{\n"
   "#ifdef GL_AMD_vertex_shader_layer\n"
-  "   gl_Layer = layer;\n"
+  "   gl_Layer = gl_InstanceID;\n"
   "#endif\n"
   "   gl_Position = position;\n"
   "}\n";
@@ -1568,7 +1568,6 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
_mesa_LinkProgram(clear->ShaderProg);
 
clear->ColorLocation = _mesa_GetUniformLocation(clear->ShaderProg, "color");
-   clear->LayerLocation = _mesa_GetUniformLocation(clear->ShaderProg, "layer");
 
has_integer_textures = _mesa_is_gles3(ctx) ||
   (_mesa_is_desktop_gl(ctx) && ctx->Const.GLSLVersion >= 130);
@@ -1579,12 +1578,12 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
  ralloc_asprintf(shader_source_mem_ctx,
  "#version 130\n"
  "#extension GL_AMD_vertex_shader_layer : enable\n"
+ "#extension GL_ARB_draw_instanced : enable\n"
  "in vec4 position;\n"
- "uniform int layer;\n"
  "void main()\n"
  "{\n"
  "#ifdef GL_AMD_vertex_shader_layer\n"
- "   gl_Layer = layer;\n"
+ "   gl_Layer = gl_InstanceID;\n"
  "#endif\n"
  "   gl_Position = position;\n"
  "}\n");
@@ -1623,8 +1622,6 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
 
   clear->IntegerColorLocation =
 _mesa_GetUniformLocation(clear->IntegerShaderProg, "color");
-  clear->IntegerLayerLocation =
- _mesa_GetUniformLocation(clear->IntegerShaderProg, "layer");
}
 }
 
@@ -1832,15 +1829,7 @@ meta_clear(struct gl_context *ctx, GLbitfield buffers, 
bool glsl)
 
/* draw quad(s) */
if (fb->MaxNumLayers > 0) {
-  unsigned layer;
-  assert(glsl && clear->LayerLocation != -1);
-  for (layer = 0; layer < fb->MaxNumLayers; layer++) {
- if (fb->_IntegerColor)
-_mesa_Uniform1i(clear->IntegerLayerLocation, layer);
- else
-_mesa_Uniform1i(clear->LayerLocation, layer);
- _mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
-  }
+  _mesa_DrawArraysInstanced(GL_TRIANGLE_FAN, 0, 4, fb->MaxNumLayers);
} else {
   _mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
}
-- 
2.0.2

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

[Mesa-dev] [PATCH 1/2] mesa: Expose vbo_exec_DrawArraysInstanced as _mesa_DrawArraysInstanced.

[Kenneth Graunke]

So we can use it in meta.c.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/main/varray.h| 4 
 src/mesa/vbo/vbo_exec_array.c | 6 ++
 2 files changed, 10 insertions(+)

diff --git a/src/mesa/main/varray.h b/src/mesa/main/varray.h
index f94ebac..d5d8b36 100644
--- a/src/mesa/main/varray.h
+++ b/src/mesa/main/varray.h
@@ -272,6 +272,10 @@ extern void GLAPIENTRY
 _mesa_DrawArrays(GLenum mode, GLint first, GLsizei count);
 
 extern void GLAPIENTRY
+_mesa_DrawArraysInstanced(GLenum mode, GLint first, GLsizei count,
+  GLsizei primcount);
+
+extern void GLAPIENTRY
 _mesa_DrawElements(GLenum mode, GLsizei count, GLenum type,
const GLvoid *indices);
 
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 9c161cc..3f7058d 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -1890,6 +1890,12 @@ _mesa_DrawArrays(GLenum mode, GLint first, GLsizei count)
vbo_exec_DrawArrays(mode, first, count);
 }
 
+void GLAPIENTRY
+_mesa_DrawArraysInstanced(GLenum mode, GLint first, GLsizei count,
+  GLsizei primcount)
+{
+   vbo_exec_DrawArraysInstanced(mode, first, count, primcount);
+}
 
 void GLAPIENTRY
 _mesa_DrawElements(GLenum mode, GLsizei count, GLenum type,
-- 
2.0.2

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

Re: [Mesa-dev] [PATCH v2] nouveau: force luminance clear colors to have the same g/b values as r

[Francisco Jerez]

Ilia Mirkin  writes:

> Fixes the LUMINANCE_ALPHA formats of fbo-clear-formats piglit test.
>
> Signed-off-by: Ilia Mirkin 
> ---
>  src/mesa/drivers/dri/nouveau/nouveau_driver.c | 10 +-
>  src/mesa/drivers/dri/nouveau/nouveau_util.h   |  9 +
>  2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_driver.c 
> b/src/mesa/drivers/dri/nouveau/nouveau_driver.c
> index b0afb69..e61bf4e 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_driver.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_driver.c
> @@ -114,8 +114,16 @@ nouveau_clear(struct gl_context *ctx, GLbitfield buffers)
>   fb->Attachment[i].Renderbuffer)->surface;
>  
>   if (buf & BUFFER_BITS_COLOR) {
> + float *color = ctx->Color.ClearColor.f;

This should probably be declared const.  With that fixed:

Reviewed-by: Francisco Jerez 

> +
> + if (fb->Attachment[i].Renderbuffer->_BaseFormat ==
> + GL_LUMINANCE_ALPHA)
> + value = pack_la_clamp_f(
> + s->format, color[0], color[3]);
> + else
> + value = pack_rgba_clamp_f(s->format, color);
> +
>   mask = pack_rgba_i(s->format, ctx->Color.ColorMask[0]);
> - value = pack_rgba_clamp_f(s->format, 
> ctx->Color.ClearColor.f);
>  
>   if (mask)
>   context_drv(ctx)->surface_fill(
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_util.h 
> b/src/mesa/drivers/dri/nouveau/nouveau_util.h
> index 56b819b..d11bae2 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_util.h
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_util.h
> @@ -92,6 +92,15 @@ pack_zs_f(mesa_format f, float z, uint8_t s)
>   return pack_zs_i(f, FLOAT_TO_UINT(z), s);
>  }
>  
> +static inline unsigned
> +pack_la_clamp_f(mesa_format f, float l, float a)
> +{
> + GLubyte lb, ab;
> + UNCLAMPED_FLOAT_TO_UBYTE(lb, l);
> + UNCLAMPED_FLOAT_TO_UBYTE(ab, a);
> + return pack_rgba_i(f, (uint8_t []) { lb, lb, lb, ab });
> +}
> +
>  /* Integer base-2 logarithm, rounded towards zero. */
>  static inline unsigned
>  log2i(unsigned i)
> -- 
> 1.8.5.5


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

Re: [Mesa-dev] New stable-branch 10.2 candidate pushed

[Carl Worth]

Carl Worth  writes:
> Normally, I would have completed my own testing of the branch prior to
> pushing the candidate. This time, I'm a little late, but I plan to
> follow up tomorrow with my own testing results, (which hopefully will
> not lead to any changes in the branch).

I've completed that testing now. With piglit, I compared Mesa 10.2.5 to
the current 10.2 branch in three configurations:

i965_dri.so with Haswell
Gallium swrast_dri.so
Non-Gallium swrast_dri.so

And there were no regressions in any of the configurations.

Unless I hear any negative testing reports from users of any other
hardware, I will plan to release 10.2.6 late this upcoming Friday (in my
timezone at least).

-Carl


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

[Mesa-dev] [PATCH] squash! glsl: Optimize min/max expression trees

[Matt Turner]

---
I'd squash this in at minimum. The changes are

 - Whitespace
 - Removal of unnecessary destructor
 - Renaming "one" and "two" to "a" and "b" (one->value.u[c0] < 
two->value.u[c0]...)
 - continue -> break
 - assert(!...) -> unreachable
 - Not doing assignments in if conditionals
 - Marking swizzle_if_required as static

I also think less_all_components should just return an enum like
{ MIXED, EQUAL, LESS, GREATER }, rather than setting a variable in
the class. It, as well as smaller/larger_constant, can then be
static functions outside of the visitor.

I think the algorithm itself looks correct.

 src/glsl/opt_minmax.cpp | 145 +---
 1 file changed, 63 insertions(+), 82 deletions(-)

diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
index 5656059..b987386 100644
--- a/src/glsl/opt_minmax.cpp
+++ b/src/glsl/opt_minmax.cpp
@@ -37,12 +37,10 @@
 #include "glsl_types.h"
 #include "main/macros.h"
 
-namespace
-{
-class minmax_range
-{
-public:
+namespace {
 
+class minmax_range {
+public:
minmax_range(ir_constant *low = NULL, ir_constant *high = NULL)
{
   range[0] = low;
@@ -60,60 +58,45 @@ public:
 class ir_minmax_visitor : public ir_rvalue_enter_visitor {
 public:
ir_minmax_visitor()
-  : progress(false)
-  , valid(true)
-   {
-   }
-
-   virtual ~ir_minmax_visitor()
+  : progress(false), valid(true)
{
}
 
-   bool
-   less_all_components(ir_constant *one, ir_constant *two);
-
-   ir_constant *
-   smaller_constant(ir_constant *one, ir_constant *two);
-
-   ir_constant *
-   larger_constant(ir_constant *one, ir_constant *two);
+   bool less_all_components(ir_constant *a, ir_constant *b);
+   ir_constant *smaller_constant(ir_constant *a, ir_constant *b);
+   ir_constant *larger_constant(ir_constant *a, ir_constant *b);
 
-   minmax_range
-   combine_range(minmax_range r0, minmax_range r1, bool ismin);
+   minmax_range combine_range(minmax_range r0, minmax_range r1, bool ismin);
 
-   minmax_range
-   range_intersection(minmax_range r0, minmax_range r1);
+   minmax_range range_intersection(minmax_range r0, minmax_range r1);
 
-   minmax_range
-   get_range(ir_rvalue *rval);
+   minmax_range get_range(ir_rvalue *rval);
 
-   ir_rvalue *
-   prune_expression(ir_expression *expr, minmax_range baserange);
+   ir_rvalue *prune_expression(ir_expression *expr, minmax_range baserange);
 
-   void
-   handle_rvalue(ir_rvalue **rvalue);
+   void handle_rvalue(ir_rvalue **rvalue);
 
bool progress;
bool valid;
 };
 
 /*
- * Returns true if all vector components of `one' are less than of `two'.
+ * Returns true if all vector components of `a' are less than of `b'.
  *
  * If there are vector components that are less while others are greater, the
  * visitor is marked invalid and no further changes will be made to the IR.
  */
 bool
-ir_minmax_visitor::less_all_components(ir_constant *one, ir_constant *two)
+ir_minmax_visitor::less_all_components(ir_constant *a, ir_constant *b)
 {
-   assert(one != NULL);
-   assert(two != NULL);
+   assert(a != NULL);
+   assert(b != NULL);
 
-   assert(one->type->base_type == two->type->base_type);
+   assert(a->type->base_type == b->type->base_type);
 
-   unsigned oneinc = one->type->is_scalar() ? 0 : 1;
-   unsigned twoinc = two->type->is_scalar() ? 0 : 1;
-   unsigned components = MAX2(one->type->components(), 
two->type->components());
+   unsigned a_inc = a->type->is_scalar() ? 0 : 1;
+   unsigned b_inc = b->type->is_scalar() ? 0 : 1;
+   unsigned components = MAX2(a->type->components(), b->type->components());
 
/* No early escape. We need to go through all components and mark the
 * visitor as invalid if comparison yields less for some components and
@@ -127,34 +110,34 @@ ir_minmax_visitor::less_all_components(ir_constant *one, 
ir_constant *two)
 
for (unsigned i = 0, c0 = 0, c1 = 0;
 i < components;
-c0 += oneinc, c1 += twoinc, ++i) {
-  switch (one->type->base_type) {
+c0 += a_inc, c1 += b_inc, ++i) {
+  switch (a->type->base_type) {
   case GLSL_TYPE_UINT:
- if (one->value.u[c0] < two->value.u[c1])
+ if (a->value.u[c0] < b->value.u[c1])
 foundless = true;
- else if (one->value.u[c0] > two->value.u[c1])
+ else if (a->value.u[c0] > b->value.u[c1])
 foundgreater = true;
  else
 foundequal = true;
- continue;
+ break;
   case GLSL_TYPE_INT:
- if (one->value.i[c0] < two->value.i[c1])
+ if (a->value.i[c0] < b->value.i[c1])
 foundless = true;
- else if (one->value.i[c0] > two->value.i[c1])
+ else if (a->value.i[c0] > b->value.i[c1])
 foundgreater = true;
  else
 foundequal = true;
- continue;
+ break;
   case GLSL_TYPE_FLOAT:
- if (one->value.f[c0] < two->value.f[c1])
+ if (a->value.f[c0] < b->value.f[c1])
 foundless = 

Re: [Mesa-dev] [PATCH] i965/fs: Add pass to rename registers to break live ranges.

[Connor Abbott]

On Wed, Aug 13, 2014 at 1:22 PM, Matt Turner  wrote:
> From: Kenneth Graunke 
>
> The pass breaks live ranges of virtual registers by allocating new
> registers when it sees an assignment to a virtual GRF it's already seen
> written.
>
> total instructions in shared programs: 4337879 -> 4335014 (-0.07%)
> instructions in affected programs: 343865 -> 341000 (-0.83%)
> GAINED:46
> LOST:  1
>
> Reviewed-by: Eric Anholt 
> Reviewed-by: Matt Turner 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 67 
> 
>  src/mesa/drivers/dri/i965/brw_fs.h   |  1 +
>  2 files changed, 68 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index cc5ec16..6ec1c8f 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -2068,6 +2068,72 @@ fs_visitor::opt_algebraic()
>  }
>
>  bool
> +fs_visitor::opt_register_renaming()
> +{
> +   bool progress = false;
> +   int depth = 0;
> +
> +   int remap[virtual_grf_count];
> +   memset(remap, -1, sizeof(int) * virtual_grf_count);
> +
> +   foreach_in_list(fs_inst, inst, &this->instructions) {
> +  if (inst->opcode == BRW_OPCODE_IF || inst->opcode == BRW_OPCODE_DO) {
> + depth++;
> +  } else if (inst->opcode == BRW_OPCODE_ENDIF ||
> + inst->opcode == BRW_OPCODE_WHILE) {
> + depth--;
> +  }
> +
> +  /* Rewrite instruction sources. */
> +  for (int i = 0; i < inst->sources; i++) {
> + if (inst->src[i].file == GRF &&
> + remap[inst->src[i].reg] != -1 &&
> + remap[inst->src[i].reg] != inst->src[i].reg) {
> +inst->src[i].reg = remap[inst->src[i].reg];
> +progress = true;
> + }
> +  }
> +
> +  int dst = inst->dst.reg;
> +
> +  if (depth == 0 &&
> +  inst->dst.file == GRF &&
> +  virtual_grf_sizes[inst->dst.reg] == 1 &&

We can just use dst here instead of inst->dst.reg

> +  !inst->is_partial_write()) {
> + if (remap[dst] == -1) {
> +remap[dst] = dst;
> + } else {
> +remap[dst] = virtual_grf_alloc(virtual_grf_sizes[dst]);

Since this code only gets run when virtual_grf_sizes[dst] == 1, we can
just do virtual_grf_alloc(1).

Also, I think you're forgetting to set the type of the new destination
(i.e. remap[dst]).

Finally, I don't think this should matter in practice, but if the
instruction's destination is a hardware register we should probably
bail out.

> +inst->dst.reg = remap[dst];
> +progress = true;
> + }
> +  } else if (inst->dst.file == GRF &&
> + remap[dst] != -1 &&
> + remap[dst] != dst) {
> + inst->dst.reg = remap[dst];

I think you're forgetting to set the type here too.

> + progress = true;
> +  }
> +   }
> +
> +   if (progress) {
> +  invalidate_live_intervals();
> +
> +  for (unsigned i = 0; i < ARRAY_SIZE(delta_x); i++) {
> + if (delta_x[i].file == GRF && remap[delta_x[i].reg] != -1) {
> +delta_x[i].reg = remap[delta_x[i].reg];
> + }
> +  }
> +  for (unsigned i = 0; i < ARRAY_SIZE(delta_y); i++) {
> + if (delta_y[i].file == GRF && remap[delta_y[i].reg] != -1) {
> +delta_y[i].reg = remap[delta_y[i].reg];
> + }
> +  }
> +   }
> +
> +   return progress;
> +}
> +
> +bool
>  fs_visitor::compute_to_mrf()
>  {
> bool progress = false;
> @@ -3092,6 +3158,7 @@ fs_visitor::run()
>   OPT(dead_code_eliminate);
>   OPT(opt_peephole_sel);
>   OPT(dead_control_flow_eliminate, this);
> + OPT(opt_register_renaming);
>   OPT(opt_saturate_propagation);
>   OPT(register_coalesce);
>   OPT(compute_to_mrf);
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index e7a82c4..d30b0b8 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
> @@ -339,6 +339,7 @@ public:
> bool opt_copy_propagate_local(void *mem_ctx, bblock_t *block,
>   exec_list *acp);
> void opt_drop_redundant_mov_to_flags();
> +   bool opt_register_renaming();
> bool register_coalesce();
> bool compute_to_mrf();
> bool dead_code_eliminate();
> --
> 1.8.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Other than my comments above,

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

[Mesa-dev] [PATCH] egl: don't exit process on initialization failure

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 src/egl/drivers/dri2/egl_dri2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 5602ec3..dda13a3 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -358,7 +358,7 @@ dri2_bind_extensions(struct dri2_egl_display *dri2_dpy,
for (j = 0; matches[j].name; j++) {
   field = ((char *) dri2_dpy + matches[j].offset);
   if (*(const __DRIextension **) field == NULL) {
-_eglLog(_EGL_FATAL, "DRI2: did not find extension %s version %d",
+_eglLog(_EGL_WARNING, "DRI2: did not find extension %s version %d",
 matches[j].name, matches[j].version);
 ret = EGL_FALSE;
   }
-- 
1.8.5.5

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

[Mesa-dev] [Bug 82327] FAIL: glcpp/tests/glcpp-test-cr-lf

[bugzilla-daemon]

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

--- Comment #3 from Ian Romanick  ---
Those tests make heavy use of sed and tr.  Is there some difference between the
versions on those platforms?  What sed and tr (or other commands used in those
tests) exist on OS X and FreeBSD?

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

Re: [Mesa-dev] [PATCH 1/9] glsl: Optimize min/max expression trees

[Ian Romanick]

On 07/29/2014 02:36 AM, Petri Latvala wrote:
> Add an optimization pass that drops min/max expression operands that
> can be proven to not contribute to the final result. The algorithm is
> similar to alpha-beta pruning on a minmax search, from the field of
> AI.
> 
> This optimization pass can optimize min/max expressions where operands
> are min/max expressions. Such code can appear in shaders by itself, or
> as the result of clamp() or AMD_shader_trinary_minmax functions.
> 
> This optimization pass improves the generated code for piglit's
> AMD_shader_trinary_minmax tests as follows:
> 
> total instructions in shared programs: 75 -> 67 (-10.67%)
> instructions in affected programs: 60 -> 52 (-13.33%)
> GAINED:0
> LOST:  0
> 
> All tests (max3, min3, mid3) improved.

And I assume no piglit regressions?

Also... have you tried this in combination with Abdiel's related work on
saturates?

> A full shader-db run:
> 
> total instructions in shared programs: 4293603 -> 4293575 (-0.00%)
> instructions in affected programs: 1188 -> 1160 (-2.36%)
> GAINED:0
> LOST:  0
> 
> Improvements happen in Guacamelee and Serious Sam 3. One shader from
> Dungeon Defenders is hurt by shader-db metrics (26 -> 28), because of
> dropping of a (constant float (0.0)) operand, which was
> compiled to a saturate modifier.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76861
> Signed-off-by: Petri Latvala 
> ---
>  src/glsl/Makefile.sources   |   1 +
>  src/glsl/glsl_parser_extras.cpp |   1 +
>  src/glsl/ir_optimization.h  |   1 +
>  src/glsl/opt_minmax.cpp | 395 
> 
>  4 files changed, 398 insertions(+)
>  create mode 100644 src/glsl/opt_minmax.cpp
> 
> diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
> index b54eae7..1ee80a3 100644
> --- a/src/glsl/Makefile.sources
> +++ b/src/glsl/Makefile.sources
> @@ -95,6 +95,7 @@ LIBGLSL_FILES = \
>   $(GLSL_SRCDIR)/opt_flip_matrices.cpp \
>   $(GLSL_SRCDIR)/opt_function_inlining.cpp \
>   $(GLSL_SRCDIR)/opt_if_simplification.cpp \
> + $(GLSL_SRCDIR)/opt_minmax.cpp \
>   $(GLSL_SRCDIR)/opt_noop_swizzle.cpp \
>   $(GLSL_SRCDIR)/opt_rebalance_tree.cpp \
>   $(GLSL_SRCDIR)/opt_redundant_jumps.cpp \
> diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
> index 890123a..9f57ef3 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -1561,6 +1561,7 @@ do_common_optimization(exec_list *ir, bool linked,
> else
>progress = do_constant_variable_unlinked(ir) || progress;
> progress = do_constant_folding(ir) || progress;
> +   progress = do_minmax_prune(ir) || progress;
> progress = do_cse(ir) || progress;
> progress = do_rebalance_tree(ir) || progress;
> progress = do_algebraic(ir, native_integers, options) || progress;
> diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
> index b83c225..9d22585 100644
> --- a/src/glsl/ir_optimization.h
> +++ b/src/glsl/ir_optimization.h
> @@ -98,6 +98,7 @@ bool opt_flatten_nested_if_blocks(exec_list *instructions);
>  bool do_discard_simplification(exec_list *instructions);
>  bool lower_if_to_cond_assign(exec_list *instructions, unsigned max_depth = 
> 0);
>  bool do_mat_op_to_vec(exec_list *instructions);
> +bool do_minmax_prune(exec_list *instructions);
>  bool do_noop_swizzle(exec_list *instructions);
>  bool do_structure_splitting(exec_list *instructions);
>  bool do_swizzle_swizzle(exec_list *instructions);
> diff --git a/src/glsl/opt_minmax.cpp b/src/glsl/opt_minmax.cpp
> new file mode 100644
> index 000..5656059
> --- /dev/null
> +++ b/src/glsl/opt_minmax.cpp
> @@ -0,0 +1,395 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECT

[Mesa-dev] [Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

[bugzilla-daemon]

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

--- Comment #27 from Michel Dänzer  ---
(In reply to comment #17)
> Program received signal SIGSEGV, Segmentation fault.
> PatchJump (label=..., jump=...) at

When it says 'PatchJump (label=..., jump=...) at [...]', it's not a crash but
normal JavaScript JIT operation. Run 'continue' in that case.


> Program received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()

Only when it says '0x in ?? ()' is it the crash you're looking
for. Run 'bt full' in that case and attach the output here.

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

Re: [Mesa-dev] [PATCH 01/12] i965: Assign PS kernel start pointers when we decide which kernels to use

[Ian Romanick]

On 08/11/2014 05:29 PM, Kristian Høgsberg wrote:
> Right now we decide which kernels to use and the GRF start offsets in
> one place and emit the kernel pointers later.  The logic of how to map
> 8, 16 and 32 kernels to kernel start pointers follows the same logic as which
> GRF start offsets to use, so lets figure out these two things in one place.
> 
> Signed-off-by: Kristian Høgsberg 
> ---
>  src/mesa/drivers/dri/i965/gen6_wm_state.c | 16 
>  src/mesa/drivers/dri/i965/gen7_wm_state.c | 18 ++
>  src/mesa/drivers/dri/i965/gen8_ps_state.c | 14 --
>  3 files changed, 26 insertions(+), 22 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c 
> b/src/mesa/drivers/dri/i965/gen6_wm_state.c
> index 047e036..ebd8443 100644
> --- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
> @@ -71,7 +71,7 @@ upload_wm_state(struct brw_context *brw)
> struct gl_context *ctx = &brw->ctx;
> const struct brw_fragment_program *fp =
>brw_fragment_program_const(brw->fragment_program);
> -   uint32_t dw2, dw4, dw5, dw6;
> +   uint32_t dw2, dw4, dw5, dw6, ksp0, ksp2;
>  
> /* _NEW_BUFFERS */
> bool multisampled_fbo = ctx->DrawBuffer->Visual.samples > 1;
> @@ -109,7 +109,7 @@ upload_wm_state(struct brw_context *brw)
>ADVANCE_BATCH();
> }
>  
> -   dw2 = dw4 = dw5 = dw6 = 0;
> +   dw2 = dw4 = dw5 = dw6 = ksp2 = 0;
> dw4 |= GEN6_WM_STATISTICS_ENABLE;
> dw5 |= GEN6_WM_LINE_AA_WIDTH_1_0;
> dw5 |= GEN6_WM_LINE_END_CAP_AA_WIDTH_0_5;
> @@ -151,14 +151,18 @@ upload_wm_state(struct brw_context *brw)
>   GEN6_WM_DISPATCH_START_GRF_SHIFT_0);
>   dw4 |= (brw->wm.prog_data->dispatch_grf_start_reg_16 <<
>   GEN6_WM_DISPATCH_START_GRF_SHIFT_2);
> + ksp0 = brw->wm.base.prog_offset;
> + ksp2 = brw->wm.base.prog_offset + brw->wm.prog_data->prog_offset_16;
>} else
>   dw4 |= (brw->wm.prog_data->dispatch_grf_start_reg_16 <<
>  GEN6_WM_DISPATCH_START_GRF_SHIFT_0);
> + ksp0 = brw->wm.base.prog_offset + brw->wm.prog_data->prog_offset_16;

This looks pretty broken.  More { and } are needed.

> }
> else {
>dw5 |= GEN6_WM_8_DISPATCH_ENABLE;
>dw4 |= (brw->wm.prog_data->base.dispatch_grf_start_reg <<
>GEN6_WM_DISPATCH_START_GRF_SHIFT_0);
> +  ksp0 = brw->wm.base.prog_offset;
> }
>  
> /* CACHE_NEW_WM_PROG | _NEW_COLOR */
> @@ -277,10 +281,7 @@ upload_wm_state(struct brw_context *brw)
>  
> BEGIN_BATCH(9);
> OUT_BATCH(_3DSTATE_WM << 16 | (9 - 2));
> -   if (brw->wm.prog_data->prog_offset_16 && min_inv_per_frag > 1)
> -  OUT_BATCH(brw->wm.base.prog_offset + 
> brw->wm.prog_data->prog_offset_16);
> -   else
> -  OUT_BATCH(brw->wm.base.prog_offset);
> +   OUT_BATCH(ksp0);
> OUT_BATCH(dw2);
> if (brw->wm.prog_data->total_scratch) {
>OUT_RELOC(brw->wm.base.scratch_bo,
> @@ -293,8 +294,7 @@ upload_wm_state(struct brw_context *brw)
> OUT_BATCH(dw5);
> OUT_BATCH(dw6);
> OUT_BATCH(0); /* kernel 1 pointer */
> -   /* kernel 2 pointer */
> -   OUT_BATCH(brw->wm.base.prog_offset + brw->wm.prog_data->prog_offset_16);
> +   OUT_BATCH(ksp2);
> ADVANCE_BATCH();
>  }
>  
> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c 
> b/src/mesa/drivers/dri/i965/gen7_wm_state.c
> index 27a3f44..c03d19d 100644
> --- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
> @@ -139,11 +139,11 @@ static void
>  upload_ps_state(struct brw_context *brw)
>  {
> struct gl_context *ctx = &brw->ctx;
> -   uint32_t dw2, dw4, dw5;
> +   uint32_t dw2, dw4, dw5, ksp0, ksp2;
> const int max_threads_shift = brw->is_haswell ?
>HSW_PS_MAX_THREADS_SHIFT : IVB_PS_MAX_THREADS_SHIFT;
>  
> -   dw2 = dw4 = dw5 = 0;
> +   dw2 = dw4 = dw5 = ksp2 = 0;
>  
> dw2 |=
>(ALIGN(brw->wm.base.sampler_count, 4) / 4) << 
> GEN7_PS_SAMPLER_COUNT_SHIFT;
> @@ -231,22 +231,24 @@ upload_ps_state(struct brw_context *brw)
>   GEN7_PS_DISPATCH_START_GRF_SHIFT_0);
>   dw5 |= (brw->wm.prog_data->dispatch_grf_start_reg_16 <<
>   GEN7_PS_DISPATCH_START_GRF_SHIFT_2);
> -  } else
> + ksp0 = brw->wm.base.prog_offset;
> + ksp2 = brw->wm.base.prog_offset + brw->wm.prog_data->prog_offset_16;
> +  } else {
>   dw5 |= (brw->wm.prog_data->dispatch_grf_start_reg_16 <<
>   GEN7_PS_DISPATCH_START_GRF_SHIFT_0);
> + ksp0 = brw->wm.base.prog_offset + brw->wm.prog_data->prog_offset_16;
> +  }
> }
> else {
>dw4 |= GEN7_PS_8_DISPATCH_ENABLE;
>dw5 |= (brw->wm.prog_data->base.dispatch_grf_start_reg <<
>GEN7_PS_DISPATCH_START_GRF_SHIFT_0);
> +  ksp0 = brw->wm.base.prog_offset;
> }
>  
> BEGIN_BATCH(8);
> OUT_BATCH(_3DSTATE_PS << 16 | (8 - 2));
> -   if (brw->wm.prog_data->prog_offset_16

Re: [Mesa-dev] [PATCH 01/12] i965: Assign PS kernel start pointers when we decide which kernels to use

[Ian Romanick]

On 08/13/2014 06:16 PM, Ian Romanick wrote:
> On 08/11/2014 05:29 PM, Kristian Høgsberg wrote:
>> Right now we decide which kernels to use and the GRF start offsets in
>> one place and emit the kernel pointers later.  The logic of how to map
>> 8, 16 and 32 kernels to kernel start pointers follows the same logic as which
>> GRF start offsets to use, so lets figure out these two things in one place.
>>
>> Signed-off-by: Kristian Høgsberg 
>> ---
>>  src/mesa/drivers/dri/i965/gen6_wm_state.c | 16 
>>  src/mesa/drivers/dri/i965/gen7_wm_state.c | 18 ++
>>  src/mesa/drivers/dri/i965/gen8_ps_state.c | 14 --
>>  3 files changed, 26 insertions(+), 22 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c 
>> b/src/mesa/drivers/dri/i965/gen6_wm_state.c
>> index 047e036..ebd8443 100644
>> --- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
>> +++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
>> @@ -71,7 +71,7 @@ upload_wm_state(struct brw_context *brw)
>> struct gl_context *ctx = &brw->ctx;
>> const struct brw_fragment_program *fp =
>>brw_fragment_program_const(brw->fragment_program);
>> -   uint32_t dw2, dw4, dw5, dw6;
>> +   uint32_t dw2, dw4, dw5, dw6, ksp0, ksp2;
>>  
>> /* _NEW_BUFFERS */
>> bool multisampled_fbo = ctx->DrawBuffer->Visual.samples > 1;
>> @@ -109,7 +109,7 @@ upload_wm_state(struct brw_context *brw)
>>ADVANCE_BATCH();
>> }
>>  
>> -   dw2 = dw4 = dw5 = dw6 = 0;
>> +   dw2 = dw4 = dw5 = dw6 = ksp2 = 0;
>> dw4 |= GEN6_WM_STATISTICS_ENABLE;
>> dw5 |= GEN6_WM_LINE_AA_WIDTH_1_0;
>> dw5 |= GEN6_WM_LINE_END_CAP_AA_WIDTH_0_5;
>> @@ -151,14 +151,18 @@ upload_wm_state(struct brw_context *brw)
>>   GEN6_WM_DISPATCH_START_GRF_SHIFT_0);
>>   dw4 |= (brw->wm.prog_data->dispatch_grf_start_reg_16 <<
>>   GEN6_WM_DISPATCH_START_GRF_SHIFT_2);
>> + ksp0 = brw->wm.base.prog_offset;
>> + ksp2 = brw->wm.base.prog_offset + 
>> brw->wm.prog_data->prog_offset_16;
>>} else
>>   dw4 |= (brw->wm.prog_data->dispatch_grf_start_reg_16 <<
>>  GEN6_WM_DISPATCH_START_GRF_SHIFT_0);
>> + ksp0 = brw->wm.base.prog_offset + 
>> brw->wm.prog_data->prog_offset_16;
> 
> This looks pretty broken.  More { and } are needed.

Which Ken also noticed.  Never mind.

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

Re: [Mesa-dev] [PATCH 5/5] clover: Enable cl_khr_fp64 for devices that support doubles v2

[Matt Arsenault]

On Jun 26, 2014, at 7:15 AM, Francisco Jerez  wrote:

> Tom Stellard  writes:
> 
>> v2:
>>  - Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE and
>>CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
>>  - Only define cl_khr_fp64 if the extension is supported.
>>  - Remove trailing space from extension string.
>>  - Rename device query function from cl_khr_fp86() to has_doubles().
>> ---
>> src/gallium/state_trackers/clover/api/device.cpp  | 6 +++---
>> src/gallium/state_trackers/clover/core/device.cpp | 6 ++
>> src/gallium/state_trackers/clover/core/device.hpp | 1 +
>> src/gallium/state_trackers/clover/core/program.cpp| 5 -
>> src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
>> 5 files changed, 14 insertions(+), 5 deletions(-)
>> 
>> diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
>> b/src/gallium/state_trackers/clover/api/device.cpp
>> index 7006702..1176668 100644
>> --- a/src/gallium/state_trackers/clover/api/device.cpp
>> +++ b/src/gallium/state_trackers/clover/api/device.cpp
>> @@ -145,7 +145,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>>   break;
>> 
>>case CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE:
>> -  buf.as_scalar() = 2;
>> +  buf.as_scalar() = dev.has_doubles() ? 2 : 0;
>>   break;
>> 
>>case CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF:
>> @@ -290,7 +290,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>>   break;
>> 
>>case CL_DEVICE_EXTENSIONS:
>> -  buf.as_string() = "";
>> +  buf.as_string() = dev.has_doubles() ? "cl_khr_fp64" : "";
>>   break;
>> 
>>case CL_DEVICE_PLATFORM:
>> @@ -322,7 +322,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>>   break;
>> 
>>case CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE:
>> -  buf.as_scalar() = 2;
>> +  buf.as_scalar() = dev.has_doubles() ? 2 : 0;
>>   break;
>> 
>>case CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF:
>> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
>> b/src/gallium/state_trackers/clover/core/device.cpp
>> index bc6b761..6bf33e0 100644
>> --- a/src/gallium/state_trackers/clover/core/device.cpp
>> +++ b/src/gallium/state_trackers/clover/core/device.cpp
>> @@ -193,6 +193,12 @@ device::half_fp_config() const {
>>return CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
>> }
>> 
>> +bool
>> +device::has_doubles() const {
>> +   return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
>> + PIPE_SHADER_CAP_DOUBLES);
>> +}
>> +
>> std::vector
>> device::max_block_size() const {
>>auto v = get_compute_param(pipe, 
>> PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE);
>> diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
>> b/src/gallium/state_trackers/clover/core/device.hpp
>> index 16831ab..025c648 100644
>> --- a/src/gallium/state_trackers/clover/core/device.hpp
>> +++ b/src/gallium/state_trackers/clover/core/device.hpp
>> @@ -66,6 +66,7 @@ namespace clover {
>>   cl_device_fp_config single_fp_config() const;
>>   cl_device_fp_config double_fp_config() const;
>>   cl_device_fp_config half_fp_config() const;
>> +  bool has_doubles() const;
>> 
>>   std::vector max_block_size() const;
>>   std::string device_name() const;
>> diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
>> b/src/gallium/state_trackers/clover/core/program.cpp
>> index e09c3aa..f65f321 100644
>> --- a/src/gallium/state_trackers/clover/core/program.cpp
>> +++ b/src/gallium/state_trackers/clover/core/program.cpp
>> @@ -95,7 +95,10 @@ program::build_status(const device &dev) const {
>> 
>> std::string
>> program::build_opts(const device &dev) const {
>> -   return _opts.count(&dev) ? _opts.find(&dev)->second : "";
>> +   std::string opts = _opts.count(&dev) ? _opts.find(&dev)->second : "";
>> +   if (dev.has_doubles())
>> +  opts.append(" -Dcl_khr_fp64");
>> +   return opts;
> 
> This define belongs in the target-specific part of libclc.  With this
> hunk removed this patch is:
> 
> Reviewed-by: Francisco Jerez 
> 
>> }
>> 
>> std::string
>> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp 
>> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> index 5d2efc4..f2b4fd9 100644
>> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
>> @@ -183,7 +183,6 @@ namespace {
>> 
>>   // clc.h requires that this macro be defined:
>>   
>> c.getPreprocessorOpts().addMacroDef("cl_clang_storage_class_specifiers");
>> -  c.getPreprocessorOpts().addMacroDef("cl_khr_fp64");
>> 
>>   c.getLangOpts().NoBuiltin = true;
>>   c.getTargetOpts().Triple = triple;
>> -- 
>> 1.8.1.5
>> 
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesk

[Mesa-dev] [PATCH v2] nouveau: force luminance clear colors to have the same g/b values as r

[Ilia Mirkin]

Fixes the LUMINANCE_ALPHA formats of fbo-clear-formats piglit test.

Signed-off-by: Ilia Mirkin 
---
 src/mesa/drivers/dri/nouveau/nouveau_driver.c | 10 +-
 src/mesa/drivers/dri/nouveau/nouveau_util.h   |  9 +
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/nouveau/nouveau_driver.c 
b/src/mesa/drivers/dri/nouveau/nouveau_driver.c
index b0afb69..e61bf4e 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_driver.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_driver.c
@@ -114,8 +114,16 @@ nouveau_clear(struct gl_context *ctx, GLbitfield buffers)
fb->Attachment[i].Renderbuffer)->surface;
 
if (buf & BUFFER_BITS_COLOR) {
+   float *color = ctx->Color.ClearColor.f;
+
+   if (fb->Attachment[i].Renderbuffer->_BaseFormat ==
+   GL_LUMINANCE_ALPHA)
+   value = pack_la_clamp_f(
+   s->format, color[0], color[3]);
+   else
+   value = pack_rgba_clamp_f(s->format, color);
+
mask = pack_rgba_i(s->format, ctx->Color.ColorMask[0]);
-   value = pack_rgba_clamp_f(s->format, 
ctx->Color.ClearColor.f);
 
if (mask)
context_drv(ctx)->surface_fill(
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_util.h 
b/src/mesa/drivers/dri/nouveau/nouveau_util.h
index 56b819b..d11bae2 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_util.h
+++ b/src/mesa/drivers/dri/nouveau/nouveau_util.h
@@ -92,6 +92,15 @@ pack_zs_f(mesa_format f, float z, uint8_t s)
return pack_zs_i(f, FLOAT_TO_UINT(z), s);
 }
 
+static inline unsigned
+pack_la_clamp_f(mesa_format f, float l, float a)
+{
+   GLubyte lb, ab;
+   UNCLAMPED_FLOAT_TO_UBYTE(lb, l);
+   UNCLAMPED_FLOAT_TO_UBYTE(ab, a);
+   return pack_rgba_i(f, (uint8_t []) { lb, lb, lb, ab });
+}
+
 /* Integer base-2 logarithm, rounded towards zero. */
 static inline unsigned
 log2i(unsigned i)
-- 
1.8.5.5

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

Re: [Mesa-dev] [PATCHv2 01/13] mesa: protect the debug state with a mutex

[Ian Romanick]

Patches 7, 8, and 9 are

Reviewed-by: Ian Romanick 

I made a few minor comments on 7, but they should be trivial to resolve.

Patches 10 through 13 are

Acked-by: Ian Romanick 

I'd like to see some feed back on those last four from Ken and / or
Matt.  I'd also like, if possible, for this to land this week.

On 07/09/2014 12:47 AM, Chia-I Wu wrote:
> We are about to change mesa to spawn threads for deferred glCompileShader and
> glLinkProgram, and we need to make sure those threads can send compiler
> warnings/errors to the debug output safely.
> 
> Signed-off-by: Chia-I Wu 
> ---
>  src/mesa/main/errors.c | 172 
> +++--
>  src/mesa/main/mtypes.h |   1 +
>  2 files changed, 126 insertions(+), 47 deletions(-)
> 
> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
> index aa0ff50..156eb0d 100644
> --- a/src/mesa/main/errors.c
> +++ b/src/mesa/main/errors.c
> @@ -676,22 +676,41 @@ debug_pop_group(struct gl_debug_state *debug)
>  
>  
>  /**
> - * Return debug state for the context.  The debug state will be allocated
> - * and initialized upon the first call.
> + * Lock and return debug state for the context.  The debug state will be
> + * allocated and initialized upon the first call.  When NULL is returned, the
> + * debug state is not locked.
>   */
>  static struct gl_debug_state *
> -_mesa_get_debug_state(struct gl_context *ctx)
> +_mesa_lock_debug_state(struct gl_context *ctx)
>  {
> +   mtx_lock(&ctx->DebugMutex);
> +
> if (!ctx->Debug) {
>ctx->Debug = debug_create();
>if (!ctx->Debug) {
> - _mesa_error(ctx, GL_OUT_OF_MEMORY, "allocating debug state");
> + GET_CURRENT_CONTEXT(cur);
> + mtx_unlock(&ctx->DebugMutex);
> +
> + /*
> +  * This function may be called from other threads.  When that is the
> +  * case, we cannot record this OOM error.
> +  */
> + if (ctx == cur)
> +_mesa_error(ctx, GL_OUT_OF_MEMORY, "allocating debug state");
> +
> + return NULL;
>}
> }
>  
> return ctx->Debug;
>  }
>  
> +static void
> +_mesa_unlock_debug_state(struct gl_context *ctx)
> +{
> +   mtx_unlock(&ctx->DebugMutex);
> +}
> +
>  /**
>   * Set the integer debug state specified by \p pname.  This can be called 
> from
>   * _mesa_set_enable for example.
> @@ -699,7 +718,7 @@ _mesa_get_debug_state(struct gl_context *ctx)
>  bool
>  _mesa_set_debug_state_int(struct gl_context *ctx, GLenum pname, GLint val)
>  {
> -   struct gl_debug_state *debug = _mesa_get_debug_state(ctx);
> +   struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
>  
> if (!debug)
>return false;
> @@ -716,6 +735,8 @@ _mesa_set_debug_state_int(struct gl_context *ctx, GLenum 
> pname, GLint val)
>break;
> }
>  
> +   _mesa_unlock_debug_state(ctx);
> +
> return true;
>  }
>  
> @@ -729,9 +750,12 @@ _mesa_get_debug_state_int(struct gl_context *ctx, GLenum 
> pname)
> struct gl_debug_state *debug;
> GLint val;
>  
> +   mtx_lock(&ctx->DebugMutex);
> debug = ctx->Debug;
> -   if (!debug)
> +   if (!debug) {
> +  mtx_unlock(&ctx->DebugMutex);
>return 0;
> +   }
>  
> switch (pname) {
> case GL_DEBUG_OUTPUT:
> @@ -756,6 +780,8 @@ _mesa_get_debug_state_int(struct gl_context *ctx, GLenum 
> pname)
>break;
> }
>  
> +   mtx_unlock(&ctx->DebugMutex);
> +
> return val;
>  }
>  
> @@ -769,9 +795,12 @@ _mesa_get_debug_state_ptr(struct gl_context *ctx, GLenum 
> pname)
> struct gl_debug_state *debug;
> void *val;
>  
> +   mtx_lock(&ctx->DebugMutex);
> debug = ctx->Debug;
> -   if (!debug)
> +   if (!debug) {
> +  mtx_unlock(&ctx->DebugMutex);
>return NULL;
> +   }
>  
> switch (pname) {
> case GL_DEBUG_CALLBACK_FUNCTION_ARB:
> @@ -786,9 +815,49 @@ _mesa_get_debug_state_ptr(struct gl_context *ctx, GLenum 
> pname)
>break;
> }
>  
> +   mtx_unlock(&ctx->DebugMutex);
> +
> return val;
>  }
>  
> +/**
> + * Insert a debug message.  The mutex is assumed to be locked, and will be
> + * unlocked by this call.
> + */
> +static void
> +log_msg_locked_and_unlock(struct gl_context *ctx,
> +  enum mesa_debug_source source,
> +  enum mesa_debug_type type, GLuint id,
> +  enum mesa_debug_severity severity,
> +  GLint len, const char *buf)
> +{
> +   struct gl_debug_state *debug = ctx->Debug;
> +
> +   if (!debug_is_message_enabled(debug, source, type, id, severity)) {
> +  _mesa_unlock_debug_state(ctx);
> +  return;
> +   }
> +
> +   if (ctx->Debug->Callback) {
> +  GLenum gl_source = debug_source_enums[source];
> +  GLenum gl_type = debug_type_enums[type];
> +  GLenum gl_severity = debug_severity_enums[severity];
> +  GLDEBUGPROC callback = ctx->Debug->Callback;
> +  const void *data = ctx->Debug->CallbackData;
> +
> +  /*
> +   * When ctx->Debug->Syn

Re: [Mesa-dev] [PATCHv2 06/13] glsl: add a generic thread pool data structure

[Ian Romanick]

On 07/09/2014 12:47 AM, Chia-I Wu wrote:
> It can be used to implement, for example, threaded glCompileShader and
> glLinkProgram.
> 
> v2: allow tasks to "complete" other tasks
> 
> Signed-off-by: Chia-I Wu 
> ---
>  src/glsl/Makefile.am   |  12 +-
>  src/glsl/Makefile.sources  |   3 +-
>  src/glsl/tests/threadpool_test.cpp | 137 +++

Some description of what the tests are doing would be good.

>  src/glsl/threadpool.c  | 476 
> +
>  src/glsl/threadpool.h  |  67 ++
>  5 files changed, 693 insertions(+), 2 deletions(-)
>  create mode 100644 src/glsl/tests/threadpool_test.cpp
>  create mode 100644 src/glsl/threadpool.c
>  create mode 100644 src/glsl/threadpool.h
> 
> diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
> index 00261fd..3d07af3 100644
> --- a/src/glsl/Makefile.am
> +++ b/src/glsl/Makefile.am
> @@ -35,6 +35,7 @@ TESTS = glcpp/tests/glcpp-test  
> \
>   tests/general-ir-test   \
>   tests/optimization-test \
>   tests/ralloc-test   \
> + tests/threadpool-test   \
>   tests/sampler-types-test\
>   tests/uniform-initializer-test
>  
> @@ -48,6 +49,7 @@ check_PROGRAMS =\
>   glsl_test   \
>   tests/general-ir-test   \
>   tests/ralloc-test   \
> + tests/threadpool-test   \
>   tests/sampler-types-test\
>   tests/uniform-initializer-test
>  
> @@ -95,6 +97,14 @@ tests_ralloc_test_LDADD =  \
>   $(top_builddir)/src/gtest/libgtest.la   \
>   $(PTHREAD_LIBS)
>  
> +tests_threadpool_test_SOURCES =  \
> + tests/threadpool_test.cpp   \
> + $(top_builddir)/src/glsl/threadpool.c
> +tests_threadpool_test_CFLAGS = $(PTHREAD_CFLAGS)
> +tests_threadpool_test_LDADD =\
> + $(top_builddir)/src/gtest/libgtest.la   \
> + $(PTHREAD_LIBS)
> +
>  tests_sampler_types_test_SOURCES =   \
>   $(top_srcdir)/src/mesa/program/prog_hash_table.c\
>   $(top_srcdir)/src/mesa/program/symbol_table.c   \
> @@ -120,7 +130,7 @@ glcpp_glcpp_LDADD =   
> \
>   libglcpp.la \
>   -lm
>  
> -libglsl_la_LIBADD = libglcpp.la
> +libglsl_la_LIBADD = libglcpp.la $(PTHREAD_LIBS)
>  libglsl_la_SOURCES = \
>   glsl_lexer.cpp  \
>   glsl_parser.cpp \
> diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
> index 6fc94d6..bab2358 100644
> --- a/src/glsl/Makefile.sources
> +++ b/src/glsl/Makefile.sources
> @@ -103,7 +103,8 @@ LIBGLSL_FILES = \
>   $(GLSL_SRCDIR)/opt_tree_grafting.cpp \
>   $(GLSL_SRCDIR)/opt_vectorize.cpp \
>   $(GLSL_SRCDIR)/s_expression.cpp \
> - $(GLSL_SRCDIR)/strtod.cpp
> + $(GLSL_SRCDIR)/strtod.cpp \
> + $(GLSL_SRCDIR)/threadpool.c
>  
>  # glsl_compiler
>  
> diff --git a/src/glsl/tests/threadpool_test.cpp 
> b/src/glsl/tests/threadpool_test.cpp
> new file mode 100644
> index 000..63f55c5
> --- /dev/null
> +++ b/src/glsl/tests/threadpool_test.cpp
> @@ -0,0 +1,137 @@
> +/*
> + * Copyright © 2014 LunarG, Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "c11/threads.h"
> +
> +#include "threadpool.h"
> +
> +#define NUM_THREADS 10
> +#define OPS_PER_THREAD 100
> +#define MAX_TASKS 10
> +
>

Re: [Mesa-dev] [PATCH] mesa/texstore: Don't use the _mesa_swizzle_and_convert if we need transfer ops

[Jason Ekstrand]

On Wed, Aug 13, 2014 at 5:18 PM, Roland Scheidegger 
wrote:

> Reviewed-by: Roland Scheidegger 
>
> Not sure though why you moved the function, it's declared elsewhere anyway.
>

Heh, I guess you're right.  I'll un-move the function to reduce churn.


> (And I bet there's cases where transfer ops wouldn't actually be
> required which aren't caught by this check, like for instance RGB
> formats with only alpha pixel scale, but that was already there, plus I
> guess we don't care all that much about performance for apps which
> fiddle with that stuff...)
>

Yeah, We could spend a lot of time optimizing that but I don't see a need.
--Jason


>
>
> Am 13.08.2014 20:05, schrieb Jason Ekstrand:
> > The _mesa_swizzle_and_convert path can't do transfer ops, so we should
> bail
> > if they're needed.
> >
> > Signed-off-by: Jason Ekstrand 
> > ---
> >  src/mesa/main/texstore.c | 63
> +---
> >  1 file changed, 33 insertions(+), 30 deletions(-)
> >
> > diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
> > index 42cebbd..50c7dde 100644
> > --- a/src/mesa/main/texstore.c
> > +++ b/src/mesa/main/texstore.c
> > @@ -1462,6 +1462,36 @@ invert_swizzle(uint8_t dst[4], const uint8_t
> src[4])
> >  dst[i] = j;
> >  }
> >
> > +GLboolean
> > +_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
> > +  GLenum baseInternalFormat,
> > +  mesa_format dstFormat)
> > +{
> > +   GLenum dstType;
> > +
> > +   /* There are different rules depending on the base format. */
> > +   switch (baseInternalFormat) {
> > +   case GL_DEPTH_COMPONENT:
> > +   case GL_DEPTH_STENCIL:
> > +  return ctx->Pixel.DepthScale != 1.0f ||
> > + ctx->Pixel.DepthBias != 0.0f;
> > +
> > +   case GL_STENCIL_INDEX:
> > +  return GL_FALSE;
> > +
> > +   default:
> > +  /* Color formats.
> > +   * Pixel transfer ops (scale, bias, table lookup) do not apply
> > +   * to integer formats.
> > +   */
> > +  dstType = _mesa_get_format_datatype(dstFormat);
> > +
> > +  return dstType != GL_INT && dstType != GL_UNSIGNED_INT &&
> > + ctx->_ImageTransferState;
> > +   }
> > +}
> > +
> > +
> >  /** Store a texture by per-channel conversions and swizzling.
> >   *
> >   * This function attempts to perform a texstore operation by doing
> simple
> > @@ -1495,6 +1525,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
> > if (!is_array)
> >return GL_FALSE;
> >
> > +   if (_mesa_texstore_needs_transfer_ops(ctx, baseInternalFormat,
> dstFormat))
> > +  return GL_FALSE;
> > +
> > switch (srcType) {
> > case GL_FLOAT:
> > case GL_UNSIGNED_BYTE:
> > @@ -1762,36 +1795,6 @@ texstore_rgba(TEXSTORE_PARAMS)
> >  }
> >
> >  GLboolean
> > -_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
> > -  GLenum baseInternalFormat,
> > -  mesa_format dstFormat)
> > -{
> > -   GLenum dstType;
> > -
> > -   /* There are different rules depending on the base format. */
> > -   switch (baseInternalFormat) {
> > -   case GL_DEPTH_COMPONENT:
> > -   case GL_DEPTH_STENCIL:
> > -  return ctx->Pixel.DepthScale != 1.0f ||
> > - ctx->Pixel.DepthBias != 0.0f;
> > -
> > -   case GL_STENCIL_INDEX:
> > -  return GL_FALSE;
> > -
> > -   default:
> > -  /* Color formats.
> > -   * Pixel transfer ops (scale, bias, table lookup) do not apply
> > -   * to integer formats.
> > -   */
> > -  dstType = _mesa_get_format_datatype(dstFormat);
> > -
> > -  return dstType != GL_INT && dstType != GL_UNSIGNED_INT &&
> > - ctx->_ImageTransferState;
> > -   }
> > -}
> > -
> > -
> > -GLboolean
> >  _mesa_texstore_can_use_memcpy(struct gl_context *ctx,
> >GLenum baseInternalFormat, mesa_format
> dstFormat,
> >GLenum srcFormat, GLenum srcType,
> >
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/texstore: Don't use the _mesa_swizzle_and_convert if we need transfer ops

[Roland Scheidegger]

Reviewed-by: Roland Scheidegger 

Not sure though why you moved the function, it's declared elsewhere anyway.
(And I bet there's cases where transfer ops wouldn't actually be
required which aren't caught by this check, like for instance RGB
formats with only alpha pixel scale, but that was already there, plus I
guess we don't care all that much about performance for apps which
fiddle with that stuff...)


Am 13.08.2014 20:05, schrieb Jason Ekstrand:
> The _mesa_swizzle_and_convert path can't do transfer ops, so we should bail
> if they're needed.
> 
> Signed-off-by: Jason Ekstrand 
> ---
>  src/mesa/main/texstore.c | 63 
> +---
>  1 file changed, 33 insertions(+), 30 deletions(-)
> 
> diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
> index 42cebbd..50c7dde 100644
> --- a/src/mesa/main/texstore.c
> +++ b/src/mesa/main/texstore.c
> @@ -1462,6 +1462,36 @@ invert_swizzle(uint8_t dst[4], const uint8_t src[4])
>  dst[i] = j;
>  }
>  
> +GLboolean
> +_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
> +  GLenum baseInternalFormat,
> +  mesa_format dstFormat)
> +{
> +   GLenum dstType;
> +
> +   /* There are different rules depending on the base format. */
> +   switch (baseInternalFormat) {
> +   case GL_DEPTH_COMPONENT:
> +   case GL_DEPTH_STENCIL:
> +  return ctx->Pixel.DepthScale != 1.0f ||
> + ctx->Pixel.DepthBias != 0.0f;
> +
> +   case GL_STENCIL_INDEX:
> +  return GL_FALSE;
> +
> +   default:
> +  /* Color formats.
> +   * Pixel transfer ops (scale, bias, table lookup) do not apply
> +   * to integer formats.
> +   */
> +  dstType = _mesa_get_format_datatype(dstFormat);
> +
> +  return dstType != GL_INT && dstType != GL_UNSIGNED_INT &&
> + ctx->_ImageTransferState;
> +   }
> +}
> +
> +
>  /** Store a texture by per-channel conversions and swizzling.
>   *
>   * This function attempts to perform a texstore operation by doing simple
> @@ -1495,6 +1525,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
> if (!is_array)
>return GL_FALSE;
>  
> +   if (_mesa_texstore_needs_transfer_ops(ctx, baseInternalFormat, dstFormat))
> +  return GL_FALSE;
> +
> switch (srcType) {
> case GL_FLOAT:
> case GL_UNSIGNED_BYTE:
> @@ -1762,36 +1795,6 @@ texstore_rgba(TEXSTORE_PARAMS)
>  }
>  
>  GLboolean
> -_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
> -  GLenum baseInternalFormat,
> -  mesa_format dstFormat)
> -{
> -   GLenum dstType;
> -
> -   /* There are different rules depending on the base format. */
> -   switch (baseInternalFormat) {
> -   case GL_DEPTH_COMPONENT:
> -   case GL_DEPTH_STENCIL:
> -  return ctx->Pixel.DepthScale != 1.0f ||
> - ctx->Pixel.DepthBias != 0.0f;
> -
> -   case GL_STENCIL_INDEX:
> -  return GL_FALSE;
> -
> -   default:
> -  /* Color formats.
> -   * Pixel transfer ops (scale, bias, table lookup) do not apply
> -   * to integer formats.
> -   */
> -  dstType = _mesa_get_format_datatype(dstFormat);
> -
> -  return dstType != GL_INT && dstType != GL_UNSIGNED_INT &&
> - ctx->_ImageTransferState;
> -   }
> -}
> -
> -
> -GLboolean
>  _mesa_texstore_can_use_memcpy(struct gl_context *ctx,
>GLenum baseInternalFormat, mesa_format 
> dstFormat,
>GLenum srcFormat, GLenum srcType,
> 

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

Re: [Mesa-dev] [PATCH 3/9] glsl: Refactor the python test case generator

[Dylan Baker]

On Tuesday, July 29, 2014 12:36:33 PM Petri Latvala wrote:
> Move the IR sexp builder helpers and test script creation parts of
> tests/lower_jumps/create_test_cases.py into tests/test_case_generator.py
> 
> No functional changes.
> 
> Signed-off-by: Petri Latvala 
> ---
>  src/glsl/tests/lower_jumps/create_test_cases.py | 336 
> +++-
>  src/glsl/tests/test_case_generator.py   | 293 +
>  2 files changed, 334 insertions(+), 295 deletions(-)
>  create mode 100644 src/glsl/tests/test_case_generator.py
> 
> diff --git a/src/glsl/tests/lower_jumps/create_test_cases.py 
> b/src/glsl/tests/lower_jumps/create_test_cases.py
> index 3be1079..9783627 100644
> --- a/src/glsl/tests/lower_jumps/create_test_cases.py
> +++ b/src/glsl/tests/lower_jumps/create_test_cases.py
> @@ -27,278 +27,9 @@ import re
>  import subprocess
>  import sys
>  
> -sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..')) # For 
> access to sexps.py, which is in parent dir
> +sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..')) # For 
> access to sexps.py and test_case_generator.py, which are in parent dir
>  from sexps import *
> -
> -def make_test_case(f_name, ret_type, body):
> -"""Create a simple optimization test case consisting of a single
> -function with the given name, return type, and body.
> -
> -Global declarations are automatically created for any undeclared
> -variables that are referenced by the function.  All undeclared
> -variables are assumed to be floats.
> -"""
> -check_sexp(body)
> -declarations = {}
> -def make_declarations(sexp, already_declared = ()):
> -if isinstance(sexp, list):
> -if len(sexp) == 2 and sexp[0] == 'var_ref':
> -if sexp[1] not in already_declared:
> -declarations[sexp[1]] = [
> -'declare', ['in'], 'float', sexp[1]]
> -elif len(sexp) == 4 and sexp[0] == 'assign':
> -assert sexp[2][0] == 'var_ref'
> -if sexp[2][1] not in already_declared:
> -declarations[sexp[2][1]] = [
> -'declare', ['out'], 'float', sexp[2][1]]
> -make_declarations(sexp[3], already_declared)
> -else:
> -already_declared = set(already_declared)
> -for s in sexp:
> -if isinstance(s, list) and len(s) >= 4 and \
> -s[0] == 'declare':
> -already_declared.add(s[3])
> -else:
> -make_declarations(s, already_declared)
> -make_declarations(body)
> -return declarations.values() + \
> -[['function', f_name, ['signature', ret_type, ['parameters'], body]]]
> -
> -
> -# The following functions can be used to build expressions.
> -
> -def const_float(value):
> -"""Create an expression representing the given floating point value."""
> -return ['constant', 'float', ['{0:.6f}'.format(value)]]
> -
> -def const_bool(value):
> -"""Create an expression representing the given boolean value.
> -
> -If value is not a boolean, it is converted to a boolean.  So, for
> -instance, const_bool(1) is equivalent to const_bool(True).
> -"""
> -return ['constant', 'bool', ['{0}'.format(1 if value else 0)]]
> -
> -def gt_zero(var_name):
> -"""Create Construct the expression var_name > 0"""
> -return ['expression', 'bool', '>', ['var_ref', var_name], const_float(0)]
> -
> -
> -# The following functions can be used to build complex control flow
> -# statements.  All of these functions return statement lists (even
> -# those which only create a single statement), so that statements can
> -# be sequenced together using the '+' operator.
> -
> -def return_(value = None):
> -"""Create a return statement."""
> -if value is not None:
> -return [['return', value]]
> -else:
> -return [['return']]
> -
> -def break_():
> -"""Create a break statement."""
> -return ['break']
> -
> -def continue_():
> -"""Create a continue statement."""
> -return ['continue']
> -
> -def simple_if(var_name, then_statements, else_statements = None):
> -"""Create a statement of the form
> -
> -if (var_name > 0.0) {
> -   
> -} else {
> -   
> -}
> -
> -else_statements may be omitted.
> -"""
> -if else_statements is None:
> -else_statements = []
> -check_sexp(then_statements)
> -check_sexp(else_statements)
> -return [['if', gt_zero(var_name), then_statements, else_statements]]
> -
> -def loop(statements):
> -"""Create a loop containing the given statements as its loop
> -body.
> -"""
> -check_sexp(statements)
> -return [['loop', statements]]
> -
> -def declare_temp(var_type, var_name):
> -"""Create a declaration of the form
> -
> -(declare (temporary)   -"""
> -return [['declare', 

Re: [Mesa-dev] [PATCH 9/9] glsl: Add tests for minmax prune

[Dylan Baker]

On Tuesday, July 29, 2014 12:36:39 PM Petri Latvala wrote:
> tests/minmax/create_test_cases.py generates the following tests:
> 
> multiple_min*.opt_test:
>  Construct a tree of min expressions for all permutations of a var_ref
>  and three constants. They should all optimize to a single min with
>  the variable and the smallest constant.
> multiple_max*.opt_test:
>  Same as above, for max.
> mid3opt*.opt_test:
>  Test that code generated from a mid3() for two constants and a
>  var_ref optimizes to a single max and a single min.
> mixed_vectors*.opt_test:
>  Test that the optimization pass doesn't modify expression trees with
>  constant vectors where some components compare as less, some as
>  greater.
> 
> Signed-off-by: Petri Latvala 
> ---
>  src/glsl/tests/minmax/.gitignore   |   3 +
>  src/glsl/tests/minmax/create_test_cases.py | 151 
> +
>  2 files changed, 154 insertions(+)
>  create mode 100644 src/glsl/tests/minmax/.gitignore
>  create mode 100644 src/glsl/tests/minmax/create_test_cases.py
> 
> diff --git a/src/glsl/tests/minmax/.gitignore 
> b/src/glsl/tests/minmax/.gitignore
> new file mode 100644
> index 000..e98df62
> --- /dev/null
> +++ b/src/glsl/tests/minmax/.gitignore
> @@ -0,0 +1,3 @@
> +*.opt_test
> +*.expected
> +*.out
> diff --git a/src/glsl/tests/minmax/create_test_cases.py 
> b/src/glsl/tests/minmax/create_test_cases.py
> new file mode 100644
> index 000..4f78980
> --- /dev/null
> +++ b/src/glsl/tests/minmax/create_test_cases.py
> @@ -0,0 +1,151 @@
> +# coding=utf-8
> +#
> +# Copyright © 2014 Intel Corporation
> +#
> +# Permission is hereby granted, free of charge, to any person obtaining a
> +# copy of this software and associated documentation files (the "Software"),
> +# to deal in the Software without restriction, including without limitation
> +# the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +# and/or sell copies of the Software, and to permit persons to whom the
> +# Software is furnished to do so, subject to the following conditions:
> +#
> +# The above copyright notice and this permission notice (including the next
> +# paragraph) shall be included in all copies or substantial portions of the
> +# Software.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +# DEALINGS IN THE SOFTWARE.
> +
> +import os
> +import os.path
> +import re
> +import subprocess
> +import sys
> +import itertools

This comment applies to all the patches.
You're importing a bunch of modules you're not using, you should remove
any that are not used.

In this file os.path, re, and subprocess are not used.

> +
> +sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..'))
> +from sexps import *
> +from test_case_generator import *
> +
> +def test_multiple_max():
> +doc_string = """Test that multiple constants in multiple max expressions 
> are reduced to a single max."""

What is this? If it's a docstring it's not assigned, it's just a triple
quoted string at the start of the function or class. Fix this for the
other functions as well

> +
> +operands = [const_float(1),
> +const_float(2),
> +const_float(3),
> +['var_ref', 'a']]
> +
> +c = 1
> +for ops in itertools.permutations(operands):
> +maxtree1 = reduce(lambda a, b: max_(a, b, 'float'), ops)
> +maxtree2 = reduce(lambda a, b: max_(b, a, 'float'), ops)
> +
> +expected = max_(const_float(3), ['var_ref', 'a'], 'float')
> +
> +input_sexp = make_test_case('main', 'void', (
> +assign_x('b', maxtree1) +
> +assign_x('c', maxtree2)
> +))
> +expected_sexp = make_test_case('main', 'void', (
> +assign_x('b', expected) +
> +assign_x('c', expected)
> +))
> +
> +create_test_case(doc_string, input_sexp, expected_sexp, 
> 'multiple_max{0}'.format(c), 'do_minmax_prune')
> +c += 1
> +
> +def test_multiple_min():
> +doc_string = """Test that multiple constants in multiple min expressions 
> are reduced to a single min."""
> +
> +operands = [const_float(1),
> +const_float(2),
> +const_float(3),
> +['var_ref', 'a']]
> +
> +c = 1
> +for ops in itertools.permutations(operands):
> +mintree1 = reduce(lambda a, b: min_(a, b, 'float'), ops)
> +mintree2 = reduce(lambda a, b: min_(b, a, 'float'), ops)
> +
> +expected = min_(const_float(1), ['var_ref', 'a'], 'float')
> +
> +input_se

Re: [Mesa-dev] [PATCH 4/9] glsl: Make compare_ir sort expression operands for commutative operations

[Dylan Baker]

On Tuesday, July 29, 2014 12:36:34 PM Petri Latvala wrote:
> Sort expression operands when possible so that building expected IR
> sexps doesn't need to know which ordering will be produced by an
> optimization pass.
> 
> Signed-off-by: Petri Latvala 
> ---
>  src/glsl/tests/compare_ir |  4 ++--
>  src/glsl/tests/sexps.py   | 37 +
>  2 files changed, 39 insertions(+), 2 deletions(-)
> 
> diff --git a/src/glsl/tests/compare_ir b/src/glsl/tests/compare_ir
> index a40fc81..0b63fab 100755
> --- a/src/glsl/tests/compare_ir
> +++ b/src/glsl/tests/compare_ir
> @@ -38,9 +38,9 @@ if len(sys.argv) != 3:
>  exit(1)
>  
>  with open(sys.argv[1]) as f:
> -ir1 = sort_decls(parse_sexp(f.read()))
> +ir1 = sort_decls(sort_commutatives(parse_sexp(f.read(
>  with open(sys.argv[2]) as f:
> -ir2 = sort_decls(parse_sexp(f.read()))
> +ir2 = sort_decls(sort_commutatives(parse_sexp(f.read(
>  
>  if ir1 == ir2:
>  exit(0)
> diff --git a/src/glsl/tests/sexps.py b/src/glsl/tests/sexps.py
> index a714af8..60c54bd 100644
> --- a/src/glsl/tests/sexps.py
> +++ b/src/glsl/tests/sexps.py
> @@ -101,3 +101,40 @@ def sort_decls(sexp):
>  other_code.append(s)
>  return sorted(decls) + other_code
>  
> +commutatives = [
> +'+',
> +'*',
> +'imul_high',
> +'carry',
> +'==',
> +'!=',
> +'all_equal',
> +'any_nequal',
> +'&',
> +'^',
> +'|',
> +'&&',
> +'^^',
> +'||',
> +'dot',
> +'min',
> +'max'
> +]

In python style constants go at the top of the file, and should be
all caps.

> +
> +def sort_commutatives(sexp):
> +"""Sort operands of expressions that are commutative in sexp.
> +
> +This is used to work around the fact that optimization passes might
> +reorder operands.
> +"""
> +if not isinstance(sexp, list): return sexp
> +
> +code = []
> +for s in sexp:
> +sd = sort_commutatives(s)
> +# An expression is [expression, type, operation, operand1, ...]
> +if isinstance(sd, list) and len(sd) >= 3 and sd[0] == 'expression' 
> and sd[2] in commutatives:
> +code.append(['expression', sd[1:2]] + sorted(sd[3:]))
> +else:
> +code.append(sd)
> +return code
> -- 
> 2.0.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [Bug 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #7 from Emil Velikov  ---
OK apart from hacking a ton of printfs into configure.ac there is one more
thing which you can try:
Please revert 2af28040d639dddbb7c258981a00eaf3dfcbcf03 on top of master,
cleanup everything (make clean && git clean -fxd) and give a bash ?

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

Re: [Mesa-dev] [PATCH 1/2] Revert "configure: Fix --enable-XX-bit flags by moving LT_INIT where it should"

[Brian Paul]

On 08/13/2014 11:18 AM, Emil Velikov wrote:

This reverts commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03.

The commit was resolving an issue where libtool will not setup the
environment correctly when one explicitly provides --enable-{32,64}-bit
at configure time. It was caused due to the "-m32,64" C{,XX}FLAGS being
set too late relative to LT_INIT.

At the same time this cases the enable_static to be incorrectly set,
amongst others leading to build issues. Rather than being smart and
trying to handle 32/64 bit build ourselves it may be better to delegate
it to the builder/maintainer. The latter should now know better which is
the correct(most appropriate) method.

Bugzilla: 
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D82536&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=2rJADKBBw7CAwlUx1lK5uOXm%2FpoMgAhVfQ0TXYag1c0%3D%0A&s=be1649d30d36b4e67d923d38dd39518152737ca8cb96a2344c2c33aed1c054a5
Bugzilla: 
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D82546&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=2rJADKBBw7CAwlUx1lK5uOXm%2FpoMgAhVfQ0TXYag1c0%3D%0A&s=03a9001a12b03ee473597e26f113b615695a122cfceeb3f91e7065f9bed51325
---
  configure.ac | 11 +++
  1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4ff87eb..f678fa3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -57,6 +57,9 @@ AC_CHECK_PROGS([PYTHON2], [python2 python])
  AC_PROG_SED
  AC_PROG_MKDIR_P

+LT_PREREQ([2.2])
+LT_INIT([disable-static])
+
  AX_PROG_BISON([],
AS_IF([test ! -f "$srcdir/src/glsl/glcpp/glcpp-parse.c"],
  [AC_MSG_ERROR([bison not found - unable to compile 
glcpp-parse.y])]))
@@ -2190,14 +2193,6 @@ dnl Add user CFLAGS and CXXFLAGS
  CFLAGS="$CFLAGS $USER_CFLAGS"
  CXXFLAGS="$CXXFLAGS $USER_CXXFLAGS"

-dnl
-dnl LT_INIT adds tests to determine host based on some variables like 
(AM_)C(XX)FLAGS and (AM_)LDFLAGS.
-dnl They need to be set before calling LT_INIT so the macro can configure 
things correctly when cross_compiling.
-dnl This will allow --enable-xx-bit to work as expected.
-dnl
-LT_PREREQ([2.2])
-LT_INIT([disable-static])
-
  dnl Substitute the config
  AC_CONFIG_FILES([Makefile
src/Makefile



This patch also broke the mechanism that copies the libGL.so libs, etc 
into the top-level lib/ and lib/gallium/ directories.  Reverting the 
patch fixes that.


Reviewed-by: Brian Paul 
Tested-by: Brian Paul 

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

[Mesa-dev] [Bug 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #6 from Vinson Lee  ---
Created attachment 104593
  --> https://bugs.freedesktop.org/attachment.cgi?id=104593&action=edit
Makefile

-- 
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 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #5 from Vinson Lee  ---
$ make V=1 -C src/gallium/winsys/svga/drm
make: Entering directory `mesa/src/gallium/winsys/svga/drm'
/bin/bash ../../../../../libtool  --tag=CC   --mode=compile gcc
-DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\"
-DPACKAGE_VERSION=\"10.3.0-devel\" -DPACKAGE_STRING=\"Mesa\ 10.3.0-devel\"
-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi\?product=Mesa\";
-DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"10.3.0-devel\"
-DYYTEXT_POINTER=1 -DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1
-DHAVE_DLADDR=1 -DHAVE_PTHREAD=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I.   
-I../../../../../src/gallium/drivers/svga
-I../../../../../src/gallium/drivers/svga/include
-I../../../../../src/gallium/drivers -I../../../../../include
-I../../../../../src/gallium/include -I../../../../../src/gallium/auxiliary
-DUSE_EXTERNAL_DXTN_LIB=1 -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_SSE41 -DDEBUG
-DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN
-DMESA_EGL_NO_X11_HEADERS -fvisibility=hidden  -g -O2 -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-strict-aliasing -fno-builtin-memcmp  -std=gnu99 -D_FILE_OFFSET_BITS=64 -MT
vmw_screen_dri.lo -MD -MP -MF .deps/vmw_screen_dri.Tpo -c -o vmw_screen_dri.lo
vmw_screen_dri.c
libtool: compile:  gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\"
-DPACKAGE_VERSION=\"10.3.0-devel\" "-DPACKAGE_STRING=\"Mesa 10.3.0-devel\""
"-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\"";
-DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"10.3.0-devel\"
-DYYTEXT_POINTER=1 -DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1
-DHAVE_DLADDR=1 -DHAVE_PTHREAD=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I.
-I../../../../../src/gallium/drivers/svga
-I../../../../../src/gallium/drivers/svga/include
-I../../../../../src/gallium/drivers -I../../../../../include
-I../../../../../src/gallium/include -I../../../../../src/gallium/auxiliary
-DUSE_EXTERNAL_DXTN_LIB=1 -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_SSE41 -DDEBUG
-DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN
-DMESA_EGL_NO_X11_HEADERS -fvisibility=hidden -g -O2 -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-strict-aliasing -fno-builtin-memcmp -std=gnu99 -D_FILE_OFFSET_BITS=64 -MT
vmw_screen_dri.lo -MD -MP -MF .deps/vmw_screen_dri.Tpo -c vmw_screen_dri.c 
-fPIC -DPIC -o .libs/vmw_screen_dri.o
In file included from vmw_screen_dri.c:41:
vmwgfx_drm.h:32:17: error: drm.h: No such file or directory
In file included from vmw_screen_dri.c:41:
vmwgfx_drm.h:701: error: field ‘base’ has incomplete type
In file included from vmw_screen_dri.c:42:
/usr/include/xf86drm.h:268: error: expected specifier-qualifier-list before
‘drm_context_t’
/usr/include/xf86drm.h:281: error: expected specifier-qualifier-list before
‘drm_handle_t’
/usr/include/xf86drm.h:546: error: expected declaration specifiers or ‘...’
before ‘drm_magic_t’
/usr/include/xf86drm.h:550: error: expected declaration specifiers or ‘...’
before ‘drm_handle_t’
/usr/include/xf86drm.h:552: error: expected declaration specifiers or ‘...’
before ‘drm_handle_t’
/usr/include/xf86drm.h:570: error: expected declaration specifiers or ‘...’
before ‘drm_magic_t’
/usr/include/xf86drm.h:572: error: expected declaration specifiers or ‘...’
before ‘drm_handle_t’
/usr/include/xf86drm.h:576: error: expected declaration specifiers or ‘...’
before ‘drm_handle_t’
/usr/include/xf86drm.h:577: error: expected declaration specifiers or ‘...’
before ‘drm_handle_t’
/usr/include/xf86drm.h:578: error: expected declaration specifiers or ‘...’
before ‘drm_context_t’
/usr/include/xf86drm.h:579: error: expected declaration specifiers or ‘...’
before ‘drm_handle_t’
/usr/include/xf86drm.h:585: error: expected declaration specifiers or ‘...’
before ‘drm_context_t’
/usr/include/xf86drm.h:586: error: expected declaration specifiers or ‘...’
before ‘drm_context_t’
/usr/include/xf86drm.h:588: error: expected declaration specifiers or ‘...’
before ‘drm_context_t’
/usr/include/xf86drm.h:590: error: expected declaration specifiers or ‘...’
before ‘drm_context_t’
/usr/include/xf86drm.h:591: error: expected declaration specifiers or ‘...’
before ‘drm_context_t’
/usr/include/xf86drm.h:592: error: expected declaration specifiers or ‘...’
before ‘drm_context_t’
/usr/include/xf86drm.h:593: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘*’ token
/usr/include/xf86drm.h:594: error: expected ‘)’ before ‘*’ token
/usr/include/xf86drm.h:595: error: expected declaration specifiers or ‘...’
before ‘drm_context_t’
/usr/include/xf86drm.h:596: error: expected declaration specifiers or ‘...’
before ‘drm_context_t’
/usr/include/xf86drm.h:597: error: expected declaration specifiers or ‘...’
before ‘drm_drawable_t’
/usr/include/xf86drm.h:598: error: expected declaration specifiers or ‘...’
before ‘drm_drawable_t’
/u

Re: [Mesa-dev] [PATCH] docs/autoconf: mention CC/CXX when doing multilib builds

[Ilia Mirkin]

On Wed, Aug 13, 2014 at 6:15 PM, Emil Velikov  wrote:
> On 13/08/14 23:01, Ilia Mirkin wrote:
>> On Wed, Aug 13, 2014 at 5:56 PM, Emil Velikov  
>> wrote:
>>> On 13/08/14 22:22, Ilia Mirkin wrote:
 On Wed, Aug 13, 2014 at 5:16 PM, Emil Velikov  
 wrote:
> Signed-off-by: Emil Velikov 
> ---
>
> Unless someone object I would like to squash this patch with the
> previous one.
>
> -Emil
>
>  docs/autoconf.html | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/docs/autoconf.html b/docs/autoconf.html
> index f27838f..c225659 100644
> --- a/docs/autoconf.html
> +++ b/docs/autoconf.html
> @@ -141,14 +141,26 @@ assembly will not be used.
>  --host=
>  By default, the build will compile code for the architecture that
>  it's running on. In order to build Mesa on a x64-86 machine that is to 
> run

 While you're fixing stuff, x86-64

>>> Ack, will do.
>>>
> -on a i686, one would need to set the options to:
> +on a i686, one would need to set the options to:
>
>  --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
>
>  Note that these can vary from distribution to distribution. For more
>  information check with the
>   href="https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html";>
> -autoconf manual.
> +autoconf manual.
> +
> +
> +In some cases a single compiler is capable of handling both 
> architectures
> +in that case one would need to set the CC,CXX variables
> +appending the correct machine options. Seek your compiler documentation 
> for
> +further information -
> +https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html";> gcc
> +machine dependent options
> +
> +The following is the complete setup needed to compile on my Archlinux 
> setup

 There's nothing about the below that's specific to Arch, or any
 distro, really -- I'd avoid the explicit distro reference.
>>> Haven't touched any other distro but Arch in years. Yet it makes sense to 
>>> drop
>>> the distro reference but keep the example.
>>
>> Right, I was suggesting s/Archlinux// :)
>>
>>>
 Do you
 actually need the --build and --host things? I thought that was if you
 were going to use a cross-compiler. I only have
 x86_64-pc-linux-gnu-gcc, no i686-...-gnu-gcc.

>>> --build/host (at lest) used to be required by mesa, as some bits were built
>>> differently when doing cross-compilation. Not sure what the case is now - I
>>> care not look in src/{glsl,mesa} which is where all of that chaos was.
>>
>> But that's my point -- it's not a cross-compilation. It's using the
>> same system compiler. The way cross-compilation works (afaik) is that
>> you just look for $host-gcc, $host-ld, $host-as etc (and use
>> $build-gcc, etc for the binaries that need to be run as part of the
>> build). But i686-...-gcc is not a binary available on my system. So
>> the cross-compilation will fail...
>>
> IIRC the --build/host flags were required to get mesa past the "make" into the
> "make check" stage when doing "multilib" builds. Things may have changed, yet
> there should be no side-effects (unless we have a bug somewhere). Will give it
> a try shortly, perhaps you can give it a bash on your Gentoo system as well ?
>
> Afaik if $arch-$plat-gcc is missing, then we fall back to $arch-gcc and
> finally to gcc, and similarly for every other tool used.

Ah I see. I was not aware of that. Sneaky. I'll check it out tonight,
although I doubt that I'll have different results from you. These
things tend to vary from compiler to compiler, but not if we're using
the same-ish environment (which we are).

>
>> Perhaps I'm just misunderstanding how things work though.
> I don't claim to be an expert on the topic so it may be that I'm missing
> something :)
>
> -Emil
>>
>>>
>>>
 In the past I've just done CFLAGS=-m32 CXXFLAGS=-m32 and it has worked
 like a charm. But perhaps there's a downside to doing that...

>>> I cannot think of any side effects to be honest (barring any bugs in mesa).
>>> Yet I would love if people avoid touching any *FLAGS :)
>>>
>>> Thanks
>>> -Emil
>>>
> +
> +./configure CC="gcc -m32" CXX="g++ -m32" 
> --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu ...
>  
>  
>
> --
> 2.0.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

[bugzilla-daemon]

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

--- Comment #26 from Marek Olšák  ---
(In reply to comment #25)
> Recently tried:
> 
> exec=env R600_DEBUG=nosb firefox
> 
> After exiting firefox crashed too.
> 
> P.S. Let me guess, you need output (do you ?)

Not really. Your previous backtrace showed that it doesn't crash in Mesa. I
just don't understand why.

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

Re: [Mesa-dev] [PATCH] docs/autoconf: mention CC/CXX when doing multilib builds

[Emil Velikov]

On 13/08/14 23:01, Ilia Mirkin wrote:
> On Wed, Aug 13, 2014 at 5:56 PM, Emil Velikov  
> wrote:
>> On 13/08/14 22:22, Ilia Mirkin wrote:
>>> On Wed, Aug 13, 2014 at 5:16 PM, Emil Velikov  
>>> wrote:
 Signed-off-by: Emil Velikov 
 ---

 Unless someone object I would like to squash this patch with the
 previous one.

 -Emil

  docs/autoconf.html | 16 ++--
  1 file changed, 14 insertions(+), 2 deletions(-)

 diff --git a/docs/autoconf.html b/docs/autoconf.html
 index f27838f..c225659 100644
 --- a/docs/autoconf.html
 +++ b/docs/autoconf.html
 @@ -141,14 +141,26 @@ assembly will not be used.
  --host=
  By default, the build will compile code for the architecture that
  it's running on. In order to build Mesa on a x64-86 machine that is to run
>>>
>>> While you're fixing stuff, x86-64
>>>
>> Ack, will do.
>>
 -on a i686, one would need to set the options to:
 +on a i686, one would need to set the options to:

  --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu

  Note that these can vary from distribution to distribution. For more
  information check with the
  >>> href="https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html";>
 -autoconf manual.
 +autoconf manual.
 +
 +
 +In some cases a single compiler is capable of handling both 
 architectures
 +in that case one would need to set the CC,CXX variables
 +appending the correct machine options. Seek your compiler documentation 
 for
 +further information -
 +https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html";> gcc
 +machine dependent options
 +
 +The following is the complete setup needed to compile on my Archlinux 
 setup
>>>
>>> There's nothing about the below that's specific to Arch, or any
>>> distro, really -- I'd avoid the explicit distro reference.
>> Haven't touched any other distro but Arch in years. Yet it makes sense to 
>> drop
>> the distro reference but keep the example.
> 
> Right, I was suggesting s/Archlinux// :)
> 
>>
>>> Do you
>>> actually need the --build and --host things? I thought that was if you
>>> were going to use a cross-compiler. I only have
>>> x86_64-pc-linux-gnu-gcc, no i686-...-gnu-gcc.
>>>
>> --build/host (at lest) used to be required by mesa, as some bits were built
>> differently when doing cross-compilation. Not sure what the case is now - I
>> care not look in src/{glsl,mesa} which is where all of that chaos was.
> 
> But that's my point -- it's not a cross-compilation. It's using the
> same system compiler. The way cross-compilation works (afaik) is that
> you just look for $host-gcc, $host-ld, $host-as etc (and use
> $build-gcc, etc for the binaries that need to be run as part of the
> build). But i686-...-gcc is not a binary available on my system. So
> the cross-compilation will fail...
> 
IIRC the --build/host flags were required to get mesa past the "make" into the
"make check" stage when doing "multilib" builds. Things may have changed, yet
there should be no side-effects (unless we have a bug somewhere). Will give it
a try shortly, perhaps you can give it a bash on your Gentoo system as well ?

Afaik if $arch-$plat-gcc is missing, then we fall back to $arch-gcc and
finally to gcc, and similarly for every other tool used.

> Perhaps I'm just misunderstanding how things work though.
I don't claim to be an expert on the topic so it may be that I'm missing
something :)

-Emil
> 
>>
>>
>>> In the past I've just done CFLAGS=-m32 CXXFLAGS=-m32 and it has worked
>>> like a charm. But perhaps there's a downside to doing that...
>>>
>> I cannot think of any side effects to be honest (barring any bugs in mesa).
>> Yet I would love if people avoid touching any *FLAGS :)
>>
>> Thanks
>> -Emil
>>
 +
 +./configure CC="gcc -m32" CXX="g++ -m32" 
 --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu ...
  
  

 --
 2.0.2

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

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

Re: [Mesa-dev] [PATCH] docs/autoconf: mention CC/CXX when doing multilib builds

[Ilia Mirkin]

On Wed, Aug 13, 2014 at 5:56 PM, Emil Velikov  wrote:
> On 13/08/14 22:22, Ilia Mirkin wrote:
>> On Wed, Aug 13, 2014 at 5:16 PM, Emil Velikov  
>> wrote:
>>> Signed-off-by: Emil Velikov 
>>> ---
>>>
>>> Unless someone object I would like to squash this patch with the
>>> previous one.
>>>
>>> -Emil
>>>
>>>  docs/autoconf.html | 16 ++--
>>>  1 file changed, 14 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/docs/autoconf.html b/docs/autoconf.html
>>> index f27838f..c225659 100644
>>> --- a/docs/autoconf.html
>>> +++ b/docs/autoconf.html
>>> @@ -141,14 +141,26 @@ assembly will not be used.
>>>  --host=
>>>  By default, the build will compile code for the architecture that
>>>  it's running on. In order to build Mesa on a x64-86 machine that is to run
>>
>> While you're fixing stuff, x86-64
>>
> Ack, will do.
>
>>> -on a i686, one would need to set the options to:
>>> +on a i686, one would need to set the options to:
>>>
>>>  --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
>>>
>>>  Note that these can vary from distribution to distribution. For more
>>>  information check with the
>>>  >> href="https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html";>
>>> -autoconf manual.
>>> +autoconf manual.
>>> +
>>> +
>>> +In some cases a single compiler is capable of handling both 
>>> architectures
>>> +in that case one would need to set the CC,CXX variables
>>> +appending the correct machine options. Seek your compiler documentation for
>>> +further information -
>>> +https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html";> gcc
>>> +machine dependent options
>>> +
>>> +The following is the complete setup needed to compile on my Archlinux 
>>> setup
>>
>> There's nothing about the below that's specific to Arch, or any
>> distro, really -- I'd avoid the explicit distro reference.
> Haven't touched any other distro but Arch in years. Yet it makes sense to drop
> the distro reference but keep the example.

Right, I was suggesting s/Archlinux// :)

>
>> Do you
>> actually need the --build and --host things? I thought that was if you
>> were going to use a cross-compiler. I only have
>> x86_64-pc-linux-gnu-gcc, no i686-...-gnu-gcc.
>>
> --build/host (at lest) used to be required by mesa, as some bits were built
> differently when doing cross-compilation. Not sure what the case is now - I
> care not look in src/{glsl,mesa} which is where all of that chaos was.

But that's my point -- it's not a cross-compilation. It's using the
same system compiler. The way cross-compilation works (afaik) is that
you just look for $host-gcc, $host-ld, $host-as etc (and use
$build-gcc, etc for the binaries that need to be run as part of the
build). But i686-...-gcc is not a binary available on my system. So
the cross-compilation will fail...

Perhaps I'm just misunderstanding how things work though.

>
>
>> In the past I've just done CFLAGS=-m32 CXXFLAGS=-m32 and it has worked
>> like a charm. But perhaps there's a downside to doing that...
>>
> I cannot think of any side effects to be honest (barring any bugs in mesa).
> Yet I would love if people avoid touching any *FLAGS :)
>
> Thanks
> -Emil
>
>>> +
>>> +./configure CC="gcc -m32" CXX="g++ -m32" 
>>> --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu ...
>>>  
>>>  
>>>
>>> --
>>> 2.0.2
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs/autoconf: mention CC/CXX when doing multilib builds

[Emil Velikov]

On 13/08/14 22:22, Ilia Mirkin wrote:
> On Wed, Aug 13, 2014 at 5:16 PM, Emil Velikov  
> wrote:
>> Signed-off-by: Emil Velikov 
>> ---
>>
>> Unless someone object I would like to squash this patch with the
>> previous one.
>>
>> -Emil
>>
>>  docs/autoconf.html | 16 ++--
>>  1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/docs/autoconf.html b/docs/autoconf.html
>> index f27838f..c225659 100644
>> --- a/docs/autoconf.html
>> +++ b/docs/autoconf.html
>> @@ -141,14 +141,26 @@ assembly will not be used.
>>  --host=
>>  By default, the build will compile code for the architecture that
>>  it's running on. In order to build Mesa on a x64-86 machine that is to run
> 
> While you're fixing stuff, x86-64
> 
Ack, will do.

>> -on a i686, one would need to set the options to:
>> +on a i686, one would need to set the options to:
>>
>>  --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
>>
>>  Note that these can vary from distribution to distribution. For more
>>  information check with the
>>  > href="https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html";>
>> -autoconf manual.
>> +autoconf manual.
>> +
>> +
>> +In some cases a single compiler is capable of handling both architectures
>> +in that case one would need to set the CC,CXX variables
>> +appending the correct machine options. Seek your compiler documentation for
>> +further information -
>> +https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html";> gcc
>> +machine dependent options
>> +
>> +The following is the complete setup needed to compile on my Archlinux 
>> setup
> 
> There's nothing about the below that's specific to Arch, or any
> distro, really -- I'd avoid the explicit distro reference.
Haven't touched any other distro but Arch in years. Yet it makes sense to drop
the distro reference but keep the example.

> Do you
> actually need the --build and --host things? I thought that was if you
> were going to use a cross-compiler. I only have
> x86_64-pc-linux-gnu-gcc, no i686-...-gnu-gcc.
> 
--build/host (at lest) used to be required by mesa, as some bits were built
differently when doing cross-compilation. Not sure what the case is now - I
care not look in src/{glsl,mesa} which is where all of that chaos was.


> In the past I've just done CFLAGS=-m32 CXXFLAGS=-m32 and it has worked
> like a charm. But perhaps there's a downside to doing that...
> 
I cannot think of any side effects to be honest (barring any bugs in mesa).
Yet I would love if people avoid touching any *FLAGS :)

Thanks
-Emil

>> +
>> +./configure CC="gcc -m32" CXX="g++ -m32" 
>> --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu ...
>>  
>>  
>>
>> --
>> 2.0.2
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

Re: [Mesa-dev] [PATCH 02/12] i965: Add an option to not generate the SIMD8 fragment shader

[Matt Turner]

On Mon, Aug 11, 2014 at 10:35 PM, Kristian Høgsberg  wrote:
> On Mon, Aug 11, 2014 at 08:08:33PM -0700, Ben Widawsky wrote:
>> On Mon, Aug 11, 2014 at 05:29:32PM -0700, Kristian Høgsberg wrote:
>> > const unsigned *assembly = NULL;
>> > if (brw->gen >= 8) {
>> >gen8_fs_generator g(brw, mem_ctx, key, prog_data, prog, fp, 
>> > v.do_dual_src);
>> > -  assembly = g.generate_assembly(&v.instructions, simd16_instructions,
>> > +  assembly = g.generate_assembly(simd8_instructions, 
>> > simd16_instructions,
>> >   final_assembly_size);
>> > } else {
>> >fs_generator g(brw, mem_ctx, key, prog_data, prog, fp, 
>> > v.do_dual_src,
>> >   v.runtime_check_aads_emit, INTEL_DEBUG & DEBUG_WM);
>> > -  assembly = g.generate_assembly(&v.instructions, simd16_instructions,
>> > +  assembly = g.generate_assembly(simd8_instructions, 
>> > simd16_instructions,
>> >   final_assembly_size);
>> > }
>>
>> Suppose you could combine the two.
>
> I don't think so? g is a different type in the two branches.

Moot point now. There's only one generator now.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs/autoconf: update to better reflect reality

[Matt Turner]

Looks good. Thanks Emil!

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

[Mesa-dev] [Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

[bugzilla-daemon]

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

--- Comment #25 from Eugene  ---
Recently tried:

exec=env R600_DEBUG=nosb firefox

After exiting firefox crashed too.

P.S. Let me guess, you need output (do you ?)

-- 
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 81680] [r600g] Firefox crashes with hardware acceleration turned on

[bugzilla-daemon]

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

--- Comment #24 from Marek Olšák  ---
No, just try to reproduce the bug while the environment variable is set.

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

Re: [Mesa-dev] [PATCH] docs/autoconf: mention CC/CXX when doing multilib builds

[Ilia Mirkin]

On Wed, Aug 13, 2014 at 5:16 PM, Emil Velikov  wrote:
> Signed-off-by: Emil Velikov 
> ---
>
> Unless someone object I would like to squash this patch with the
> previous one.
>
> -Emil
>
>  docs/autoconf.html | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/docs/autoconf.html b/docs/autoconf.html
> index f27838f..c225659 100644
> --- a/docs/autoconf.html
> +++ b/docs/autoconf.html
> @@ -141,14 +141,26 @@ assembly will not be used.
>  --host=
>  By default, the build will compile code for the architecture that
>  it's running on. In order to build Mesa on a x64-86 machine that is to run

While you're fixing stuff, x86-64

> -on a i686, one would need to set the options to:
> +on a i686, one would need to set the options to:
>
>  --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
>
>  Note that these can vary from distribution to distribution. For more
>  information check with the
>   href="https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html";>
> -autoconf manual.
> +autoconf manual.
> +
> +
> +In some cases a single compiler is capable of handling both architectures
> +in that case one would need to set the CC,CXX variables
> +appending the correct machine options. Seek your compiler documentation for
> +further information -
> +https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html";> gcc
> +machine dependent options
> +
> +The following is the complete setup needed to compile on my Archlinux 
> setup

There's nothing about the below that's specific to Arch, or any
distro, really -- I'd avoid the explicit distro reference. Do you
actually need the --build and --host things? I thought that was if you
were going to use a cross-compiler. I only have
x86_64-pc-linux-gnu-gcc, no i686-...-gnu-gcc.

In the past I've just done CFLAGS=-m32 CXXFLAGS=-m32 and it has worked
like a charm. But perhaps there's a downside to doing that...

> +
> +./configure CC="gcc -m32" CXX="g++ -m32" 
> --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu ...
>  
>  
>
> --
> 2.0.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] docs/autoconf: mention CC/CXX when doing multilib builds

[Emil Velikov]

Signed-off-by: Emil Velikov 
---

Unless someone object I would like to squash this patch with the
previous one.

-Emil 

 docs/autoconf.html | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/docs/autoconf.html b/docs/autoconf.html
index f27838f..c225659 100644
--- a/docs/autoconf.html
+++ b/docs/autoconf.html
@@ -141,14 +141,26 @@ assembly will not be used.
 --host=
 By default, the build will compile code for the architecture that
 it's running on. In order to build Mesa on a x64-86 machine that is to run
-on a i686, one would need to set the options to:
+on a i686, one would need to set the options to:
 
 --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
 
 Note that these can vary from distribution to distribution. For more
 information check with the
 https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html";>
-autoconf manual.
+autoconf manual.
+
+
+In some cases a single compiler is capable of handling both architectures
+in that case one would need to set the CC,CXX variables
+appending the correct machine options. Seek your compiler documentation for
+further information -
+https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html";> gcc
+machine dependent options
+
+The following is the complete setup needed to compile on my Archlinux 
setup
+
+./configure CC="gcc -m32" CXX="g++ -m32" --build=i686-unknown-linux-gnu 
--host=i686-unknown-linux-gnu ...
 
 
 
-- 
2.0.2

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

[Mesa-dev] [PATCH 1/1] glapi: Fix compiler warning and script name

[Jan Vesely]

Signed-off-by: Jan Vesely 
---
 src/mapi/glapi/gen/gl_gentable.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mapi/glapi/gen/gl_gentable.py 
b/src/mapi/glapi/gen/gl_gentable.py
index 7577b66..c49f9a5 100644
--- a/src/mapi/glapi/gen/gl_gentable.py
+++ b/src/mapi/glapi/gen/gl_gentable.py
@@ -100,7 +100,7 @@ static void
 __glapi_gentable_set_remaining_noop(struct _glapi_table *disp) {
 GLuint entries = _glapi_get_dispatch_table_size();
 void **dispatch = (void **) disp;
-int i;
+unsigned i;
 
 /* ISO C is annoying sometimes */
 union {_glapi_proc p; void *v;} p;
@@ -147,7 +147,7 @@ class PrintCode(gl_XML.gl_print_base):
 def __init__(self):
 gl_XML.gl_print_base.__init__(self)
 
-self.name = "gl_gen_table.py (from Mesa)"
+self.name = "gl_gentable.py (from Mesa)"
 self.license = license.bsd_license_template % ( \
 """Copyright (C) 1999-2001  Brian Paul   All Rights Reserved.
 (C) Copyright IBM Corporation 2004, 2005
-- 
1.9.3

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

[Mesa-dev] [PATCH 1/1] configure.ac: Fix build with git-svn llvm version string

[Jan Vesely]

Signed-off-by: Jan Vesely 
---

My llvm-config --version is
3.6.0git-svn-r215564-cd35a3b3

This patch assumes that the interesting part consists of only digits and dots.


 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 4ff87eb..dc5117e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1697,7 +1697,7 @@ if test "x$enable_gallium_llvm" = xyes; then
 fi
 
 if test "x$LLVM_CONFIG" != xno; then
-LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'`
+LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/[[^0-9.]].*//g'`
 LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
 LLVM_BINDIR=`$LLVM_CONFIG --bindir`
 LLVM_CPPFLAGS=`strip_unwanted_llvm_flags "$LLVM_CONFIG --cppflags"`
-- 
1.9.3

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

[Mesa-dev] [Bug 82546] [regression] libOSMesa build failure

[bugzilla-daemon]

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

--- Comment #6 from Emil Velikov  ---
My plan is to revert the offending commit and remove the enable-32,64-bit hacks
that the commit was fixing.
I'm also adding a note how to properly do cross-compile/multilib builds :)

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

Re: [Mesa-dev] [PATCHv2 13/13] i965: enable threaded precompile

[Ian Romanick]

On 07/09/2014 12:47 AM, Chia-I Wu wrote:
> Inherit gl_shader_program and add save/restore functions to save precompile
> results in the shader programs.  When DeferLinkProgram is set, we will save
> the precompile results instead of uploading them immediately because we may be
> on a different thread.
> 
> A few other modifications are also needed.  brw_shader_program_precompile_key
> is introduced and initialized in NofityLinkShader for we cannot inspect the
> context during precompiling.
> 
> Signed-off-by: Chia-I Wu 
> ---
>  src/mesa/drivers/dri/i965/brw_context.c  |   4 +-
>  src/mesa/drivers/dri/i965/brw_fs.cpp |  33 --
>  src/mesa/drivers/dri/i965/brw_program.c  |   1 +
>  src/mesa/drivers/dri/i965/brw_shader.cpp | 177 
> ++-
>  src/mesa/drivers/dri/i965/brw_shader.h   |  44 
>  src/mesa/drivers/dri/i965/brw_vec4_gs.c  |  37 +--
>  src/mesa/drivers/dri/i965/brw_vs.c   |  36 +--
>  src/mesa/drivers/dri/i965/brw_wm.c   |  23 ++--
>  src/mesa/drivers/dri/i965/brw_wm.h   |   5 +-
>  9 files changed, 310 insertions(+), 50 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index bd13ebf..4a28766 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -784,8 +784,8 @@ brwCreateContext(gl_api api,
> if (INTEL_DEBUG & DEBUG_SHADER_TIME)
>brw_init_shader_time(brw);
>  
> -   /* brw_shader_precompile is not thread-safe */
> -   if (brw->precompile)
> +   /* brw_shader_precompile is not thread-safe when debug flags are set */
> +   if (brw->precompile && (INTEL_DEBUG || brw->perf_debug))
>ctx->Const.DeferLinkProgram = GL_FALSE;

But it is safe now without debug flags?

>  
> _mesa_compute_version(ctx);
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index a3ad375..61a0dff 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -3288,6 +3288,8 @@ bool
>  brw_fs_precompile(struct gl_context *ctx, struct gl_shader_program *prog)
>  {
> struct brw_context *brw = brw_context(ctx);
> +   const struct brw_shader_program_precompile_key *pre_key =
> +  brw_shader_program_get_precompile_key(prog);
> struct brw_wm_prog_key key;
>  
> if (!prog->_LinkedShaders[MESA_SHADER_FRAGMENT])
> @@ -3329,7 +3331,7 @@ brw_fs_precompile(struct gl_context *ctx, struct 
> gl_shader_program *prog)
> }
>  
> if (fp->Base.InputsRead & VARYING_BIT_POS) {
> -  key.drawable_height = ctx->DrawBuffer->Height;
> +  key.drawable_height = pre_key->fbo_height;
> }
>  
> key.nr_color_regions = _mesa_bitcount_64(fp->Base.OutputsWritten &
> @@ -3337,7 +3339,7 @@ brw_fs_precompile(struct gl_context *ctx, struct 
> gl_shader_program *prog)
>   BITFIELD64_BIT(FRAG_RESULT_SAMPLE_MASK)));
>  
> if ((fp->Base.InputsRead & VARYING_BIT_POS) || program_uses_dfdy) {
> -  key.render_to_fbo = _mesa_is_user_fbo(ctx->DrawBuffer) ||
> +  key.render_to_fbo = pre_key->is_user_fbo ||
>key.nr_color_regions > 1;
> }
>  
> @@ -3349,13 +3351,28 @@ brw_fs_precompile(struct gl_context *ctx, struct 
> gl_shader_program *prog)
>  
> key.program_string_id = bfp->id;
>  
> -   uint32_t old_prog_offset = brw->wm.base.prog_offset;
> -   struct brw_wm_prog_data *old_prog_data = brw->wm.prog_data;
> +   struct brw_wm_compile c;
>  
> -   bool success = do_wm_prog(brw, prog, bfp, &key);
> +   brw_wm_init_compile(brw, prog, bfp, &key, &c);
> +   if (!brw_wm_do_compile(brw, &c)) {
> +  brw_wm_clear_compile(brw, &c);
> +  return false;
> +   }
> +
> +   if (brw->ctx.Const.DeferLinkProgram) {
> +  brw_shader_program_save_wm_compile(prog, &c);
> +   }
> +   else {
> +  uint32_t old_prog_offset = brw->wm.base.prog_offset;
> +  struct brw_wm_prog_data *old_prog_data = brw->wm.prog_data;
>  
> -   brw->wm.base.prog_offset = old_prog_offset;
> -   brw->wm.prog_data = old_prog_data;
> +  brw_wm_upload_compile(brw, &c);
>  
> -   return success;
> +  brw->wm.base.prog_offset = old_prog_offset;
> +  brw->wm.prog_data = old_prog_data;
> +   }
> +
> +   brw_wm_clear_compile(brw, &c);
> +
> +   return true;
>  }
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
> b/src/mesa/drivers/dri/i965/brw_program.c
> index cff1188..2194640 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -259,6 +259,7 @@ void brwInitFragProgFuncs( struct dd_function_table 
> *functions )
> functions->NewShader = brw_new_shader;
> functions->NewShaderProgram = brw_new_shader_program;
> functions->LinkShader = brw_link_shader;
> +   functions->NotifyLinkShader = brw_notify_link_shader;
>  }
>  
>  void
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp 
> b/src/mesa/drivers/dri/i965/brw_shader.cpp
> index 318802b..3cf1f15 10064

[Mesa-dev] [Bug 82546] [regression] libOSMesa build failure

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 CC||aaronbotte...@gmail.com

--- Comment #5 from Emil Velikov  ---
*** Bug 82581 has been marked as a duplicate of this bug. ***

-- 
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 82581] Build fails on OSMesa stage, missing dlfcn.h.

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

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

--- Comment #1 from Emil Velikov  ---
How would a missing header inclusion would cause a link issue ?
Either way thanks for reporting Aaron, but someone beat you to it :P Fix
(revert) should be out shortly.

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

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

Re: [Mesa-dev] [PATCHv2 08/13] mesa: add infrastructure for threaded shader compilation

[Ian Romanick]

On 07/09/2014 12:47 AM, Chia-I Wu wrote:
> @@ -3489,6 +3508,18 @@ struct gl_constants
> GLfloat MaxFragmentInterpolationOffset;
>  
> GLboolean FakeSWMSAA;
> +
> +   /*
> +* Defer certain operations to a thread pool.
> +*
> +* When DeferLinkProgram is set, these functions must be thread-safe
> +*
> +*   ctx->Driver.NewShader
> +*   ctx->Driver.DeleteShader
> +*   ctx->Driver.LinkShader
> +*/
> +   GLboolean DeferCompileShader;
> +   GLboolean DeferLinkProgram;

We're trying to make non-API facing things use bool instead.

>  };
>  
>  

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

Re: [Mesa-dev] [PATCHv2 01/13] mesa: protect the debug state with a mutex

[Ian Romanick]

This series fell off my radar.  Sorry about the delays. :(

Patches 1 through 5 are

Reviewed-by: Ian Romanick 

I'm still working my way through the rest.  I'd like to see these land
as soon as reasonably possible.

On 07/09/2014 12:47 AM, Chia-I Wu wrote:
> We are about to change mesa to spawn threads for deferred glCompileShader and
> glLinkProgram, and we need to make sure those threads can send compiler
> warnings/errors to the debug output safely.
> 
> Signed-off-by: Chia-I Wu 
> ---
>  src/mesa/main/errors.c | 172 
> +++--
>  src/mesa/main/mtypes.h |   1 +
>  2 files changed, 126 insertions(+), 47 deletions(-)
> 
> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
> index aa0ff50..156eb0d 100644
> --- a/src/mesa/main/errors.c
> +++ b/src/mesa/main/errors.c
> @@ -676,22 +676,41 @@ debug_pop_group(struct gl_debug_state *debug)
>  
>  
>  /**
> - * Return debug state for the context.  The debug state will be allocated
> - * and initialized upon the first call.
> + * Lock and return debug state for the context.  The debug state will be
> + * allocated and initialized upon the first call.  When NULL is returned, the
> + * debug state is not locked.
>   */
>  static struct gl_debug_state *
> -_mesa_get_debug_state(struct gl_context *ctx)
> +_mesa_lock_debug_state(struct gl_context *ctx)
>  {
> +   mtx_lock(&ctx->DebugMutex);
> +
> if (!ctx->Debug) {
>ctx->Debug = debug_create();
>if (!ctx->Debug) {
> - _mesa_error(ctx, GL_OUT_OF_MEMORY, "allocating debug state");
> + GET_CURRENT_CONTEXT(cur);
> + mtx_unlock(&ctx->DebugMutex);
> +
> + /*
> +  * This function may be called from other threads.  When that is the
> +  * case, we cannot record this OOM error.
> +  */
> + if (ctx == cur)
> +_mesa_error(ctx, GL_OUT_OF_MEMORY, "allocating debug state");
> +
> + return NULL;
>}
> }
>  
> return ctx->Debug;
>  }
>  
> +static void
> +_mesa_unlock_debug_state(struct gl_context *ctx)
> +{
> +   mtx_unlock(&ctx->DebugMutex);
> +}
> +
>  /**
>   * Set the integer debug state specified by \p pname.  This can be called 
> from
>   * _mesa_set_enable for example.
> @@ -699,7 +718,7 @@ _mesa_get_debug_state(struct gl_context *ctx)
>  bool
>  _mesa_set_debug_state_int(struct gl_context *ctx, GLenum pname, GLint val)
>  {
> -   struct gl_debug_state *debug = _mesa_get_debug_state(ctx);
> +   struct gl_debug_state *debug = _mesa_lock_debug_state(ctx);
>  
> if (!debug)
>return false;
> @@ -716,6 +735,8 @@ _mesa_set_debug_state_int(struct gl_context *ctx, GLenum 
> pname, GLint val)
>break;
> }
>  
> +   _mesa_unlock_debug_state(ctx);
> +
> return true;
>  }
>  
> @@ -729,9 +750,12 @@ _mesa_get_debug_state_int(struct gl_context *ctx, GLenum 
> pname)
> struct gl_debug_state *debug;
> GLint val;
>  
> +   mtx_lock(&ctx->DebugMutex);
> debug = ctx->Debug;
> -   if (!debug)
> +   if (!debug) {
> +  mtx_unlock(&ctx->DebugMutex);
>return 0;
> +   }
>  
> switch (pname) {
> case GL_DEBUG_OUTPUT:
> @@ -756,6 +780,8 @@ _mesa_get_debug_state_int(struct gl_context *ctx, GLenum 
> pname)
>break;
> }
>  
> +   mtx_unlock(&ctx->DebugMutex);
> +
> return val;
>  }
>  
> @@ -769,9 +795,12 @@ _mesa_get_debug_state_ptr(struct gl_context *ctx, GLenum 
> pname)
> struct gl_debug_state *debug;
> void *val;
>  
> +   mtx_lock(&ctx->DebugMutex);
> debug = ctx->Debug;
> -   if (!debug)
> +   if (!debug) {
> +  mtx_unlock(&ctx->DebugMutex);
>return NULL;
> +   }
>  
> switch (pname) {
> case GL_DEBUG_CALLBACK_FUNCTION_ARB:
> @@ -786,9 +815,49 @@ _mesa_get_debug_state_ptr(struct gl_context *ctx, GLenum 
> pname)
>break;
> }
>  
> +   mtx_unlock(&ctx->DebugMutex);
> +
> return val;
>  }
>  
> +/**
> + * Insert a debug message.  The mutex is assumed to be locked, and will be
> + * unlocked by this call.
> + */
> +static void
> +log_msg_locked_and_unlock(struct gl_context *ctx,
> +  enum mesa_debug_source source,
> +  enum mesa_debug_type type, GLuint id,
> +  enum mesa_debug_severity severity,
> +  GLint len, const char *buf)
> +{
> +   struct gl_debug_state *debug = ctx->Debug;
> +
> +   if (!debug_is_message_enabled(debug, source, type, id, severity)) {
> +  _mesa_unlock_debug_state(ctx);
> +  return;
> +   }
> +
> +   if (ctx->Debug->Callback) {
> +  GLenum gl_source = debug_source_enums[source];
> +  GLenum gl_type = debug_type_enums[type];
> +  GLenum gl_severity = debug_severity_enums[severity];
> +  GLDEBUGPROC callback = ctx->Debug->Callback;
> +  const void *data = ctx->Debug->CallbackData;
> +
> +  /*
> +   * When ctx->Debug->SyncOutput is GL_FALSE, the client is prepared for
> +   * unsynchronous calls.  When it is G

[Mesa-dev] [PATCH] docs/autoconf: update to better reflect reality

[Emil Velikov]

 * --enable-{32,64}-bit is done. Use --build and --host instead.
 * Configure does not add "-g -O2" to C{,XX}FLAGS.
 * Pkg-config has been mandatory for a while now.
 * Avoid using LDFLAGS, refer to pkg-config.
 * --with-expat is deprecated. Use pkg-config.

Signed-off-by: Emil Velikov 
---

Matt how does this look ?


 docs/autoconf.html | 40 
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/docs/autoconf.html b/docs/autoconf.html
index d4e8a35..f27838f 100644
--- a/docs/autoconf.html
+++ b/docs/autoconf.html
@@ -97,20 +97,22 @@ shared libraries in a single pass.
 CC, CFLAGS, CXX, CXXFLAGS
 These environment variables
 control the C and C++ compilers used during the build. By default,
-gcc and g++ are used with the options
-"-g -O2".
+gcc and g++ are used and the debug/optimisation
+level is left unchanged.
 
 
 LDFLAGS
 An environment variable specifying flags to
-pass when linking programs. These are normally empty, but can be used
-to direct the linker to use libraries in nonstandard directories. For
-example, LDFLAGS="-L/usr/X11R6/lib".
+pass when linking programs. These should be empty and
+PKG_CONFIG_PATH is recommended to be used instead. If needed
+it can be used to direct the linker to use libraries in nonstandard
+directories. For example, LDFLAGS="-L/usr/X11R6/lib".
 
 
 PKG_CONFIG_PATH
-When available, the
-pkg-config utility is used to search for external libraries
+The
+pkg-config utility is a hard requirement for cofiguring and
+building mesa. It is used to search for external libraries
 on the system. This environment variable is used to control the search
 path for pkg-config. For instance, setting
 PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig will search for
@@ -135,14 +137,18 @@ one of these architectures is detected. This option 
ensures that
 assembly will not be used.
 
 
---enable-32-bit
---enable-64-bit
-By default, the build will compile code as directed by the environment
-variables
-CC, CFLAGS, etc. If the compiler is
-gcc, these options offer a helper to add the compiler flags
-to force 32- or 64-bit code generation as used on the x86 and x86_64
-architectures. Note that these options are mutually exclusive.
+--build=
+--host=
+By default, the build will compile code for the architecture that
+it's running on. In order to build Mesa on a x64-86 machine that is to run
+on a i686, one would need to set the options to:
+
+--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
+
+Note that these can vary from distribution to distribution. For more
+information check with the
+https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html";>
+autoconf manual.
 
 
 
@@ -194,7 +200,9 @@ kernel DRM modules are not available.
 --enable-glx-tls 
 Enable Thread Local Storage (TLS) in
 GLX.
---with-expat=DIR  The DRI-enabled libGL uses expat to
+--with-expat=DIR
+DEPRECATED, use PKG_CONFIG_PATH 
instead.
+The DRI-enabled libGL uses expat to
 parse the DRI configuration files in /etc/drirc and
 ~/.drirc. This option allows a specific expat installation
 to be used. For example, --with-expat=/usr/local will
-- 
2.0.2

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

[Mesa-dev] [Bug 82581] Build fails on OSMesa stage, missing dlfcn.h.

[bugzilla-daemon]

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

Aaron B  changed:

   What|Removed |Added

Summary|Build fails.|Build fails on OSMesa
   ||stage, missing dlfcn.h.

-- 
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 82581] New: Build fails.

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 82581
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: Build fails.
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: aaronbotte...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

Tee didn't print all output apparently, but it looks like someone forgot to
"#include " and when attempting to link OSMesa, it fails to link. The
files it complains about not having it are the s3tc compression and
glapi_gentable.

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

Re: [Mesa-dev] [PATCHv2 08/13] mesa: add infrastructure for threaded shader compilation

[Ian Romanick]

On 07/09/2014 12:47 AM, Chia-I Wu wrote:
> Add _mesa_enable_glsl_threadpool to enable the thread pool for a context, and
> add ctx->Const.DeferCompileShader and ctx->Const.DeferLinkProgram to
> fine-control what gets threaded.
> 
> Setting DeferCompileShader to true will make _mesa_glsl_compile_shader be
> executed in a worker thread.  The function is thread-safe so there is no
> restriction on DeferCompileShader.
> 
> Setting DeferLinkProgram to true will make _mesa_glsl_link_shader be executed
> in a worker thread.  The function is thread-safe only when certain driver
> functions (as documented in struct gl_constants) are thread-safe.  It is
> drivers' responsibility to fix those driver functions before setting
> DeferLinkProgram.
> 
> When DeferLinkProgram is set, drivers are not supposed to inspect the context
> in their LinkShader callbacks.  Instead, NotifyLinkShader is added.  Drivers
> should inspect the context in NotifyLinkShader and save what they need for
> LinkShader in gl_shader_program.
> 
> As a final note, most applications will not benefit from threaded shader
> compilation because they check GL_COMPILE_STATUS/GL_LINK_STATUS immediately,
> giving the worker threads no time to do their jobs.  A possible improvement is
> to split LinkShader into two parts: the first part links and error checks
> while the second part optimizes and generates the machine code.  With the
> split, we can always defer the second part to the thread pool.
> 
> Signed-off-by: Chia-I Wu 
> ---
>  src/mesa/main/context.c |  29 +++
>  src/mesa/main/context.h |   3 ++
>  src/mesa/main/dd.h  |   8 +++
>  src/mesa/main/mtypes.h  |  34 
>  src/mesa/main/pipelineobj.c |  18 +++
>  src/mesa/main/shaderapi.c   | 122 
> +++-
>  src/mesa/main/shaderobj.c   |  74 +--
>  src/mesa/main/shaderobj.h   |  55 ++--
>  8 files changed, 322 insertions(+), 21 deletions(-)
> 
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index b082159..e27450c 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -112,6 +112,7 @@
>  #include "points.h"
>  #include "polygon.h"
>  #include "queryobj.h"
> +#include "shaderapi.h"
>  #include "syncobj.h"
>  #include "rastpos.h"
>  #include "remap.h"
> @@ -139,6 +140,7 @@
>  #endif
>  
>  #include "glsl_parser_extras.h"
> +#include "threadpool.h"
>  #include 
>  
>  
> @@ -1187,6 +1189,27 @@ _mesa_create_context(gl_api api,
> }
>  }
>  
> +void
> +_mesa_enable_glsl_threadpool(struct gl_context *ctx, int max_threads)
> +{
> +   if (!ctx->ThreadPool)
> +  ctx->ThreadPool = _mesa_glsl_get_threadpool(max_threads);
> +}
> +
> +static void
> +wait_shader_object_cb(GLuint id, void *data, void *userData)
> +{
> +   struct gl_context *ctx = (struct gl_context *) userData;
> +   struct gl_shader *sh = (struct gl_shader *) data;
> +
> +   if (_mesa_validate_shader_target(ctx, sh->Type)) {
> +  _mesa_wait_shaders(ctx, &sh, 1);
> +   }
> +   else {
> +  struct gl_shader_program *shProg = (struct gl_shader_program *) data;
> +  _mesa_wait_shader_program(ctx, shProg);
> +   }
> +}
>  
>  /**
>   * Free the data associated with the given context.
> @@ -1205,6 +1228,12 @@ _mesa_free_context_data( struct gl_context *ctx )
>_mesa_make_current(ctx, NULL, NULL);
> }
>  
> +   if (ctx->ThreadPool) {
> +  _mesa_HashWalk(ctx->Shared->ShaderObjects, wait_shader_object_cb, ctx);
> +  _mesa_threadpool_unref(ctx->ThreadPool);
> +  ctx->ThreadPool = NULL;
> +   }
> +
> /* unreference WinSysDraw/Read buffers */
> _mesa_reference_framebuffer(&ctx->WinSysDrawBuffer, NULL);
> _mesa_reference_framebuffer(&ctx->WinSysReadBuffer, NULL);
> diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
> index 792ab4c..b23f9fa 100644
> --- a/src/mesa/main/context.h
> +++ b/src/mesa/main/context.h
> @@ -118,6 +118,9 @@ _mesa_create_context(gl_api api,
>   const struct dd_function_table *driverFunctions);
>  
>  extern void
> +_mesa_enable_glsl_threadpool(struct gl_context *ctx, int max_threads);
> +
> +extern void
>  _mesa_free_context_data( struct gl_context *ctx );
>  
>  extern void
> diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
> index 633ea2c..38f8c68 100644
> --- a/src/mesa/main/dd.h
> +++ b/src/mesa/main/dd.h
> @@ -447,6 +447,14 @@ struct dd_function_table {
>  */
> /*@{*/
> /**
> +* Called when a shader program is to be linked.
> +*
> +* This is optional and gives drivers an opportunity to inspect the 
> context
> +* and prepare for LinkShader, which may be deferred to another thread.
> +*/
> +   void (*NotifyLinkShader)(struct gl_context *ctx,
> +struct gl_shader_program *shader);
> +   /**
>  * Called when a shader program is linked.
>  *
>  * This gives drivers an opportunity to clone the IR and make their
> diff --git a/

Re: [Mesa-dev] [PATCH 10/12] mesa: Use _mesa_lock_context_textures in _mesa_GetTexParameterfv()

[Kenneth Graunke]

On Monday, August 11, 2014 05:29:40 PM Kristian Høgsberg wrote:
> GetTexParamterfv() doesnt change texture state, so instead of
> _mesa_lock_texture() we can use _mesa_lock_context_textures(),
> which doesn't increase the texture stamp.  With this change,
> _mesa_update_state_locked() is now only called from under
> _mesa_lock_context_textures(), which is right thing to do.  Right now
> it's the same mutex, but if we made texture locking more fine grained
> locking one day, just locking one texture here would be wrong.
> 
> This all ignores the fact that texture locking seem a bit
> flaky and broken, but we're trying to not blatantly make it worse.
> 
> This change allows us to reliably unlock the context textures in the
> dd::UpdateState callback as is necessary for meta color resolves.
> 
> Signed-off-by: Kristian Høgsberg 
> ---
>  src/mesa/main/texparam.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
> index 30dd0b9..e40fb24 100644
> --- a/src/mesa/main/texparam.c
> +++ b/src/mesa/main/texparam.c
> @@ -1384,7 +1384,7 @@ _mesa_GetTexParameterfv( GLenum target, GLenum pname, 
> GLfloat *params )
> if (!obj)
>return;
>  
> -   _mesa_lock_texture(ctx, obj);
> +   _mesa_lock_context_textures(ctx);
> switch (pname) {
>case GL_TEXTURE_MAG_FILTER:
>*params = ENUM_TO_FLOAT(obj->Sampler.MagFilter);
> @@ -1591,11 +1591,11 @@ _mesa_GetTexParameterfv( GLenum target, GLenum pname, 
> GLfloat *params )
> }
>  
> /* no error if we get here */
> -   _mesa_unlock_texture(ctx, obj);
> +   _mesa_unlock_context_textures(ctx);
> return;
>  
>  invalid_pname:
> -   _mesa_unlock_texture(ctx, obj);
> +   _mesa_unlock_context_textures(ctx);
> _mesa_error(ctx, GL_INVALID_ENUM, "glGetTexParameterfv(pname=0x%x)", 
> pname);
>  }
>  
> 

Yeah...the old code incremented the texture timestamp, and I don't see any 
point in that.  It doesn't alter the state at all.  This patch retains taking 
the mutex.

But, it really seems like you need to do the analogous change in 
_mesa_GetTexParameteriv().  I think you'll hit the same issue, and are just 
getting lucky...

With that fixed,
Reviewed-by: Kenneth Graunke 

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

[Mesa-dev] [PATCH] i965/fs: Add pass to rename registers to break live ranges.

[Matt Turner]

From: Kenneth Graunke 

The pass breaks live ranges of virtual registers by allocating new
registers when it sees an assignment to a virtual GRF it's already seen
written.

total instructions in shared programs: 4337879 -> 4335014 (-0.07%)
instructions in affected programs: 343865 -> 341000 (-0.83%)
GAINED:46
LOST:  1

Reviewed-by: Eric Anholt 
Reviewed-by: Matt Turner 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 67 
 src/mesa/drivers/dri/i965/brw_fs.h   |  1 +
 2 files changed, 68 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index cc5ec16..6ec1c8f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2068,6 +2068,72 @@ fs_visitor::opt_algebraic()
 }
 
 bool
+fs_visitor::opt_register_renaming()
+{
+   bool progress = false;
+   int depth = 0;
+
+   int remap[virtual_grf_count];
+   memset(remap, -1, sizeof(int) * virtual_grf_count);
+
+   foreach_in_list(fs_inst, inst, &this->instructions) {
+  if (inst->opcode == BRW_OPCODE_IF || inst->opcode == BRW_OPCODE_DO) {
+ depth++;
+  } else if (inst->opcode == BRW_OPCODE_ENDIF ||
+ inst->opcode == BRW_OPCODE_WHILE) {
+ depth--;
+  }
+
+  /* Rewrite instruction sources. */
+  for (int i = 0; i < inst->sources; i++) {
+ if (inst->src[i].file == GRF &&
+ remap[inst->src[i].reg] != -1 &&
+ remap[inst->src[i].reg] != inst->src[i].reg) {
+inst->src[i].reg = remap[inst->src[i].reg];
+progress = true;
+ }
+  }
+
+  int dst = inst->dst.reg;
+
+  if (depth == 0 &&
+  inst->dst.file == GRF &&
+  virtual_grf_sizes[inst->dst.reg] == 1 &&
+  !inst->is_partial_write()) {
+ if (remap[dst] == -1) {
+remap[dst] = dst;
+ } else {
+remap[dst] = virtual_grf_alloc(virtual_grf_sizes[dst]);
+inst->dst.reg = remap[dst];
+progress = true;
+ }
+  } else if (inst->dst.file == GRF &&
+ remap[dst] != -1 &&
+ remap[dst] != dst) {
+ inst->dst.reg = remap[dst];
+ progress = true;
+  }
+   }
+
+   if (progress) {
+  invalidate_live_intervals();
+
+  for (unsigned i = 0; i < ARRAY_SIZE(delta_x); i++) {
+ if (delta_x[i].file == GRF && remap[delta_x[i].reg] != -1) {
+delta_x[i].reg = remap[delta_x[i].reg];
+ }
+  }
+  for (unsigned i = 0; i < ARRAY_SIZE(delta_y); i++) {
+ if (delta_y[i].file == GRF && remap[delta_y[i].reg] != -1) {
+delta_y[i].reg = remap[delta_y[i].reg];
+ }
+  }
+   }
+
+   return progress;
+}
+
+bool
 fs_visitor::compute_to_mrf()
 {
bool progress = false;
@@ -3092,6 +3158,7 @@ fs_visitor::run()
  OPT(dead_code_eliminate);
  OPT(opt_peephole_sel);
  OPT(dead_control_flow_eliminate, this);
+ OPT(opt_register_renaming);
  OPT(opt_saturate_propagation);
  OPT(register_coalesce);
  OPT(compute_to_mrf);
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
b/src/mesa/drivers/dri/i965/brw_fs.h
index e7a82c4..d30b0b8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -339,6 +339,7 @@ public:
bool opt_copy_propagate_local(void *mem_ctx, bblock_t *block,
  exec_list *acp);
void opt_drop_redundant_mov_to_flags();
+   bool opt_register_renaming();
bool register_coalesce();
bool compute_to_mrf();
bool dead_code_eliminate();
-- 
1.8.5.5

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

[Mesa-dev] [Bug 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #4 from Emil Velikov  ---
Hmm I still don't see how this can even remotely happen. To make things even
"better" it builds like a charm on my system :\

Can you attach src/gallium/winsys/svga/drm/Makefile and pastebin the output of
 $ make V=1
in while in src/gallium/winsys/svga/drm/ directory ?

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

Re: [Mesa-dev] [PATCHv2 04/13] glsl: protect anonymous struct id with a mutex

[Kenneth Graunke]

On Wednesday, August 13, 2014 12:03:10 PM Ian Romanick wrote:
> On 07/09/2014 12:47 AM, Chia-I Wu wrote:
> > There may be two contexts compiling shaders at the same time, and we want 
> > the
> > anonymous struct id to be globally unique.
> > 
> > Signed-off-by: Chia-I Wu 
> > ---
> >  src/glsl/glsl_parser_extras.cpp | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/glsl/glsl_parser_extras.cpp 
> > b/src/glsl/glsl_parser_extras.cpp
> > index b327c2b..ad31469 100644
> > --- a/src/glsl/glsl_parser_extras.cpp
> > +++ b/src/glsl/glsl_parser_extras.cpp
> > @@ -1347,9 +1347,15 @@ ast_struct_specifier::ast_struct_specifier(const 
> > char *identifier,
> >ast_declarator_list *declarator_list)
> >  {
> > if (identifier == NULL) {
> > +  static mtx_t mutex = _MTX_INITIALIZER_NP;
> >static unsigned anon_count = 1;
> > -  identifier = ralloc_asprintf(this, "#anon_struct_%04x", anon_count);
> > -  anon_count++;
> > +  unsigned count;
> > +
> > +  mtx_lock(&mutex);
> > +  count = anon_count++;
> > +  mtx_unlock(&mutex);
> 
> My previous feedback on this was to try and use some sort of atomic
> counter when available.  I'm not excited about the performance hit of
> taking a lock here.  Although, this probably isn't hit too much.  After
> this lands, can you submit an enhancement bug for this issue?

Yeah, I don't think this is hit often at all...

--Ken

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] st/vdpau: add device reference counting

[Ilia Mirkin]

On Wed, Aug 13, 2014 at 11:51 AM, Christian König
 wrote:
> Am 13.08.2014 um 17:13 schrieb Ilia Mirkin:
>
>> On Wed, Aug 13, 2014 at 11:07 AM, Christian König
>>  wrote:
>>>
>>> From: Christian König 
>>>
>>> This fixes an issue with flash where it tries to destroy a decoder
>>> after already destroying the device associated with the decoder.
>>>
>>> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82517
>>>
>>> Signed-off-by: Christian König 
>>
>> Have you considered the opposite approach -- tearing everything down
>> when the device is torn down, instead of keeping the device alive
>> longer?
>
> Yeah, considered that as well but refcounting of the device was just easier
> to implement.
>
> I mostly think that this is just a workaround for a buggy application and I
> don't want anything like this in the driver if it isn't lightweight and/or
> necessary.
>
>
>> Any idea what NVIDIA does? (Do the VDPAU docs say anything
>> about this? I don't see it anywhere.)
>
> I briefly remember reading about that, but couldn't find it of hand any
> more.
>
>
>> The reason I bring it up is that now an application that doesn't
>> destroy everything about a device will end up leaking it, which may be
>> a heavier object to leak than just surfaces or something.
>
> As long as it doesn't crash with this approach and the VDPAU spec doesn't
> mandates something else I would like to stay with just refcounting the
> device.
>
> Trying to work around all buggy applications in the driver is usually a
> hopeless effort and only encourages application developers to not fix bugs
> any more.

Makes sense. This change looks fine, but I didn't actually do an
in-depth check that you made sure that you hit *every* place that
needed it. So this gets my

Acked-by: Ilia Mirkin 

>
> Thanks for the comment,
> Christian.
>
>
>>
>>> ---
>>>   src/gallium/state_trackers/vdpau/bitmap.c|  4 +++-
>>>   src/gallium/state_trackers/vdpau/decode.c|  4 +++-
>>>   src/gallium/state_trackers/vdpau/device.c| 21
>>> -
>>>   src/gallium/state_trackers/vdpau/mixer.c |  4 +++-
>>>   src/gallium/state_trackers/vdpau/output.c|  4 +++-
>>>   src/gallium/state_trackers/vdpau/presentation.c  |  4 +++-
>>>   src/gallium/state_trackers/vdpau/surface.c   |  4 +++-
>>>   src/gallium/state_trackers/vdpau/vdpau_private.h | 12 
>>>   8 files changed, 46 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/src/gallium/state_trackers/vdpau/bitmap.c
>>> b/src/gallium/state_trackers/vdpau/bitmap.c
>>> index a068921..97a4287 100644
>>> --- a/src/gallium/state_trackers/vdpau/bitmap.c
>>> +++ b/src/gallium/state_trackers/vdpau/bitmap.c
>>> @@ -67,7 +67,7 @@ vlVdpBitmapSurfaceCreate(VdpDevice device,
>>>  if (!vlsurface)
>>> return VDP_STATUS_RESOURCES;
>>>
>>> -   vlsurface->device = dev;
>>> +   DeviceReference(&vlsurface->device, dev);
>>>
>>>  memset(&res_tmpl, 0, sizeof(res_tmpl));
>>>  res_tmpl.target = PIPE_TEXTURE_2D;
>>> @@ -117,6 +117,7 @@ err_sampler:
>>>  pipe_sampler_view_reference(&vlsurface->sampler_view, NULL);
>>>   err_unlock:
>>>  pipe_mutex_unlock(dev->mutex);
>>> +   DeviceReference(&vlsurface->device, NULL);
>>>  FREE(vlsurface);
>>>  return ret;
>>>   }
>>> @@ -138,6 +139,7 @@ vlVdpBitmapSurfaceDestroy(VdpBitmapSurface surface)
>>>  pipe_mutex_unlock(vlsurface->device->mutex);
>>>
>>>  vlRemoveDataHTAB(surface);
>>> +   DeviceReference(&vlsurface->device, NULL);
>>>  FREE(vlsurface);
>>>
>>>  return VDP_STATUS_OK;
>>> diff --git a/src/gallium/state_trackers/vdpau/decode.c
>>> b/src/gallium/state_trackers/vdpau/decode.c
>>> index 1e5f81e..767d311 100644
>>> --- a/src/gallium/state_trackers/vdpau/decode.c
>>> +++ b/src/gallium/state_trackers/vdpau/decode.c
>>> @@ -110,7 +110,7 @@ vlVdpDecoderCreate(VdpDevice device,
>>> return VDP_STATUS_RESOURCES;
>>>  }
>>>
>>> -   vldecoder->device = dev;
>>> +   DeviceReference(&vldecoder->device, dev);
>>>
>>>  templat.entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
>>>  templat.chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
>>> @@ -141,6 +141,7 @@ error_handle:
>>>
>>>   error_decoder:
>>>  pipe_mutex_unlock(dev->mutex);
>>> +   DeviceReference(&vldecoder->device, NULL);
>>>  FREE(vldecoder);
>>>  return ret;
>>>   }
>>> @@ -163,6 +164,7 @@ vlVdpDecoderDestroy(VdpDecoder decoder)
>>>  pipe_mutex_destroy(vldecoder->mutex);
>>>
>>>  vlRemoveDataHTAB(decoder);
>>> +   DeviceReference(&vldecoder->device, NULL);
>>>  FREE(vldecoder);
>>>
>>>  return VDP_STATUS_OK;
>>> diff --git a/src/gallium/state_trackers/vdpau/device.c
>>> b/src/gallium/state_trackers/vdpau/device.c
>>> index 0cdda73..9c5ec60 100644
>>> --- a/src/gallium/state_trackers/vdpau/device.c
>>> +++ b/src/gallium/state_trackers/vdpau/device.c
>>> @@ -59,6 +59,8 @@ vdp_imp_device_create_x11(Display *display, int screen,
>>> VdpDevice *device,
>>> goto no_dev;
>>>  }
>>>
>>> +  

Re: [Mesa-dev] [PATCH] winsys/radeon: fix hawaii accel_working2 comment

[Alex Deucher]

On Wed, Aug 13, 2014 at 3:30 PM, Andreas Boll
 wrote:
> accel_working2 returns 3 if the new firmware is used.
>
> The comment wasn't updated in v3 of commit:
> 36771dc winsys/radeon: fix nop packet padding for hawaii
>
> Signed-off-by: Andreas Boll 

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
> b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> index dd109af..ecf8957 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> @@ -447,7 +447,7 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs 
> *rcs,
>  /* pad DMA ring to 8 DWs to meet CP fetch alignment requirements
>   * r6xx, requires at least 4 dw alignment to avoid a hw bug.
>   * hawaii with old firmware needs type2 nop packet.
> - * accel_working2 with value 2 indicates the new firmware.
> + * accel_working2 with value 3 indicates the new firmware.
>   */
>  if (cs->ws->info.chip_class <= SI ||
>  (cs->ws->info.family == CHIP_HAWAII &&
> --
> 2.0.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCHv2 06/13] glsl: add a generic thread pool data structure

[Ian Romanick]

On 07/09/2014 07:42 AM, Brian Paul wrote:
> On 07/09/2014 01:47 AM, Chia-I Wu wrote:
>> It can be used to implement, for example, threaded glCompileShader and
>> glLinkProgram.
>>
>> v2: allow tasks to "complete" other tasks
>>
>> Signed-off-by: Chia-I Wu 
>> ---
>>   src/glsl/Makefile.am   |  12 +-
>>   src/glsl/Makefile.sources  |   3 +-
>>   src/glsl/tests/threadpool_test.cpp | 137 +++
>>   src/glsl/threadpool.c  | 476
>> +
>>   src/glsl/threadpool.h  |  67 ++
> 
> Does the threadpool code have anything GLSL-specific in it?  If not,
> maybe these files should go in src/mesa/main/

Or src/util these days. :)

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

Re: [Mesa-dev] [PATCH 2/2] r600g/compute: Decrement map_count when unmapping items

[Tom Stellard]

On Thu, Aug 07, 2014 at 12:14:24PM +0200, Bruno Jiménez wrote:
> This patch adds a new struct: r600_transfer_global. It will
> act as a wrapper around an r600_resource_global and an r600_transfer.
> 
> It will be used for calling r600_compute_global_transfer_unmap when
> transfer_unmap is called. And at the same time, keep all the transfer
> information, so we can call r600_buffer_transfer_unmap with the
> 'real' transfer.
> ---
>  src/gallium/drivers/r600/evergreen_compute.c | 46 
> +---
>  src/gallium/drivers/r600/evergreen_compute.h |  5 +++
>  2 files changed, 40 insertions(+), 11 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/evergreen_compute.c 
> b/src/gallium/drivers/r600/evergreen_compute.c
> index f50f94a..ac72256 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.c
> +++ b/src/gallium/drivers/r600/evergreen_compute.c
> @@ -970,10 +970,16 @@ void *r600_compute_global_transfer_map(
>   struct r600_resource_global* buffer =
>   (struct r600_resource_global*)resource;
>  
> + struct r600_transfer_global *trans = NULL;
> + uint8_t *data;
> +
>   struct compute_memory_item *item = buffer->chunk;
>   struct pipe_resource *dst = NULL;
>   unsigned offset = box->x;
>  
> + trans = CALLOC(1, sizeof(struct r600_transfer_global));
> + trans->resource = resource;
> +
>   if (is_item_in_pool(item)) {
>   compute_memory_demote_item(pool, item, ctx_);
>   }
> @@ -1004,8 +1010,11 @@ void *r600_compute_global_transfer_map(
>   assert(box->z == 0);
>  
>   ///TODO: do it better, mapping is not possible if the pool is too big
> - return pipe_buffer_map_range(ctx_, dst,
> - offset, box->width, usage, ptransfer);
> + data = pipe_buffer_map_range(ctx_, dst,
> + offset, box->width, usage, &trans->ptransfer);
> +
> + *ptransfer = (struct pipe_transfer *)trans;
> + return data;
>  }
>  
>  void r600_compute_global_transfer_unmap(
> @@ -1013,16 +1022,31 @@ void r600_compute_global_transfer_unmap(
>   struct pipe_transfer* transfer)
>  {
>   /* struct r600_resource_global are not real resources, they just map
> -  * to an offset within the compute memory pool.  The function
> -  * r600_compute_global_transfer_map() maps the memory pool
> -  * resource rather than the struct r600_resource_global passed to
> -  * it as an argument and then initalizes ptransfer->resource with
> -  * the memory pool resource (via pipe_buffer_map_range).
> -  * When transfer_unmap is called it uses the memory pool's
> -  * vtable which calls r600_buffer_transfer_map() rather than
> -  * this function.
> +  * to an offset within the compute memory pool. The function
> +  * r600_compute_global_transfer_map() creates a struct
> +  * r600_transfer_global, which has as resource an r600_global_resource
> +  * and an r600_transfer which will act as the 'real' pipe_transfer
> +  * that will be passed to pipe_buffer_map_range.
> +  *
> +  * This allows us to use an r600_resource_global vtable when 
> transfer_unmap
> +  * is called, and still have the full information about the transfer,
> +  * which will be used to actually unmap the resource.
>*/
> - assert (!"This function should not be called");
> +
> + struct r600_context *rctx = (struct r600_context *)ctx_;
> + struct r600_transfer_global *trans =
> + (struct r600_transfer_global *)transfer;
> + struct r600_resource_global *buffer =
> + (struct r600_resource_global *)trans->resource;
> + struct compute_memory_item *item = buffer->chunk;
> +
> + COMPUTE_DBG(rctx->screen, "* r600_compute_global_transfer_unmap()\n"
> + "Unmaping Buffer: %u\n", item->id);
> +
> + ctx_->transfer_unmap(ctx_, trans->ptransfer);
> + item->map_count--;
> +
> + FREE(trans);
>  }
>  
>  void r600_compute_global_transfer_flush_region(
> diff --git a/src/gallium/drivers/r600/evergreen_compute.h 
> b/src/gallium/drivers/r600/evergreen_compute.h
> index 4fb53a1..842e5e4 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.h
> +++ b/src/gallium/drivers/r600/evergreen_compute.h
> @@ -38,6 +38,11 @@ struct r600_resource_global {
>   struct compute_memory_item *chunk;
>  };
>  
> +struct r600_transfer_global {
> + struct pipe_resource *resource;
> + struct pipe_transfer *ptransfer;

This still looks wrong. ptransfer should be the first member, and it
should not be a pointer.

-Tom

> +};
> +
>  void *evergreen_create_compute_state(struct pipe_context *ctx, const struct 
> pipe_compute_state *cso);
>  void evergreen_delete_compute_state(struct pipe_context *ctx, void *state);
>  void evergreen_compute_upload_input(struct pipe_context *context, const uint 
> *block_layout, const uint *grid_layout, const void *input);
> -- 
> 2.0.4
> 
___
mesa-dev ma

Re: [Mesa-dev] [PATCH] r300g: Fix bug in build_loop_info()

[Tom Stellard]

On Tue, Aug 05, 2014 at 07:06:51PM +0200, David Heidelberger wrote:
> fixes piglit glean "do-loop with continue and break" on RS690
> 
> It's based on Tom Stellard patch and improved to handle CMP instruction.
> 
> [v2] handle CMP instruction
> 
> Signed-off-by: David Heidelberger 

I've pushed this, thanks!

-Tom

> ---
>  .../drivers/r300/compiler/radeon_emulate_loops.c   | 34
> +++---
>  1 file changed, 23 insertions(+), 11 deletions(-)
> 
> diff --git
> a/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
> b/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
> index 91ed9d2..25512b3 100644
> --- a/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
> +++ b/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
> @@ -368,6 +368,8 @@ static int build_loop_info(struct
> radeon_compiler * c, struct loop_info * loop,
>   break;
>   }
>   case RC_OPCODE_BRK:
> + {
> + struct rc_src_register *src;
>   if(ptr->Next->U.I.Opcode != RC_OPCODE_ENDIF
>   || ptr->Prev->U.I.Opcode != RC_OPCODE_IF
>   || loop->Brk){
> @@ -376,20 +378,30 @@ static int build_loop_info(struct
> radeon_compiler * c, struct loop_info * loop,
>   loop->Brk = ptr;
>   loop->If = ptr->Prev;
>   loop->EndIf = ptr->Next;
> - switch(loop->If->Prev->U.I.Opcode){
> - case RC_OPCODE_SLT:
> - case RC_OPCODE_SGE:
> - case RC_OPCODE_SGT:
> - case RC_OPCODE_SLE:
> - case RC_OPCODE_SEQ:
> - case RC_OPCODE_SNE:
> - break;
> - default:
> + src = &loop->If->U.I.SrcReg[0];
> +
> + for (loop->Cond = loop->If->Prev;
> + loop->Cond->U.I.Opcode != RC_OPCODE_BGNLOOP;
> + loop->Cond = loop->Cond->Prev) {
> +
> + const struct rc_dst_register *dst = 
> &loop->Cond->U.I.DstReg;
> + if (dst->File == src->File &&
> + dst->Index == src->Index &&
> + dst->WriteMask & 
> (rc_swizzle_to_writemask(src->Swizzle))) {
> + if (loop->Cond->U.I.Opcode == 
> RC_OPCODE_CMP) {
> + src = 
> &loop->Cond->U.I.SrcReg[0];
> + continue;
> + }
> + break;
> + }
> + }
> +
> + if (loop->Cond->U.I.Opcode == RC_OPCODE_BGNLOOP) {
> + rc_error(c, "%s: Cannot find condition for 
> if\n", __FUNCTION__);
>   return 0;
>   }
> - loop->Cond = loop->If->Prev;
>   break;
> -
> + }
>   case RC_OPCODE_ENDLOOP:
>   loop->EndLoop = ptr;
>   break;
> -- 
> 2.0.0

> fixes piglit glean "do-loop with continue and break" on RS690
> 
> It's based on Tom Stellard patch and improved to handle CMP instruction.
> 
> [v2] handle CMP instruction
> 
> Signed-off-by: David Heidelberger 
> ---
>  .../drivers/r300/compiler/radeon_emulate_loops.c   | 34 
> +++---
>  1 file changed, 23 insertions(+), 11 deletions(-)
> 
> diff --git a/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c 
> b/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
> index 91ed9d2..25512b3 100644
> --- a/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
> +++ b/src/gallium/drivers/r300/compiler/radeon_emulate_loops.c
> @@ -368,6 +368,8 @@ static int build_loop_info(struct radeon_compiler * c, 
> struct loop_info * loop,
>   break;
>   }
>   case RC_OPCODE_BRK:
> + {
> + struct rc_src_register *src;
>   if(ptr->Next->U.I.Opcode != RC_OPCODE_ENDIF
>   || ptr->Prev->U.I.Opcode != RC_OPCODE_IF
>   || loop->Brk){
> @@ -376,20 +378,30 @@ static int build_loop_info(struct radeon_compiler * c, 
> struct loop_info * loop,
>   loop->Brk = ptr;
>   loop->If = ptr->Prev;
>   loop->EndIf = ptr->Next;
> - switch(loop->If->Prev->U.I.Opcode){
> - case RC_OPCODE_SLT:
> - case RC_OPCODE_SGE:
> - case RC_OPCODE_SGT:
> - case RC_OPCODE_SLE:
> - case RC_OPCODE_SEQ:
> - 

Re: [Mesa-dev] [PATCH 2/2] configure.ac: remove enable 32/64 bit hacks

[Brian Paul]

On 08/13/2014 12:20 PM, Matt Turner wrote:

On Wed, Aug 13, 2014 at 11:03 AM, Emil Velikov  wrote:

On 13/08/14 18:38, Matt Turner wrote:

On Wed, Aug 13, 2014 at 10:18 AM, Emil Velikov  wrote:

These two were added ages ago, with an explicit comment "Hacks ..."
They have been insufficient for years and maintainers needed to
explicitly handle the build themselves.

Rather than lying and pretending that it works, just kill this hack and
let maintainers build things the way it should be done for their
distribution.

Document the removal in the release notes.


I've wanted to do this for a while. Gentoo has supported multilib
builds for a while and has never used these flags.

Let's put something in the documentation that describes how to do
32-bit builds on 64-bit platforms.


What kind of documentation do you have in mind ? IMHO "see how your
distribution builds 32bit 'stuff'" is the best one :)


I think just some info telling people to use

--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu

instead of --enable-32-bit would be sufficient.


Definitely.  I hate having to hunt down obscure stuff like that.

-Brian


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

[Mesa-dev] [Bug 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02

[bugzilla-daemon]

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

--- Comment #8 from Vinson Lee  ---
(In reply to comment #7)
> Created attachment 104581 [details] [review]
> Jose's patch
> 
> Can you give this a bash ? I'm guessing that some of the formatting has been
> causing problems.

attachment 104581 fixes the build error for me too.

Tested-by: Vinson Lee 

-- 
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 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02

[bugzilla-daemon]

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

--- Comment #7 from Emil Velikov  ---
Created attachment 104581
  --> https://bugs.freedesktop.org/attachment.cgi?id=104581&action=edit
Jose's patch

Can you give this a bash ? I'm guessing that some of the formatting has been
causing problems.

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

[Mesa-dev] [PATCH] winsys/radeon: fix hawaii accel_working2 comment

[Andreas Boll]

accel_working2 returns 3 if the new firmware is used.

The comment wasn't updated in v3 of commit:
36771dc winsys/radeon: fix nop packet padding for hawaii

Signed-off-by: Andreas Boll 
---
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index dd109af..ecf8957 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -447,7 +447,7 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs 
*rcs,
 /* pad DMA ring to 8 DWs to meet CP fetch alignment requirements
  * r6xx, requires at least 4 dw alignment to avoid a hw bug.
  * hawaii with old firmware needs type2 nop packet.
- * accel_working2 with value 2 indicates the new firmware.
+ * accel_working2 with value 3 indicates the new firmware.
  */
 if (cs->ws->info.chip_class <= SI ||
 (cs->ws->info.family == CHIP_HAWAII &&
-- 
2.0.1

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

[Mesa-dev] [Bug 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02

[bugzilla-daemon]

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

--- Comment #6 from Vinson Lee  ---
(In reply to comment #4)
> You can also try Jose's patch
> http://patchwork.freedesktop.org/patch/31651/

This patch does not apply.

-- 
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 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02

[bugzilla-daemon]

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

--- Comment #5 from Vinson Lee  ---
(In reply to comment #3)
> Can you give http://patchwork.freedesktop.org/patch/31650/ a try ?
> 
> It brings us back to the original behaviour by dropping the headers as scons
> parses through the list. It will also allow us to put all headers in
> makefile.sources and (one day) have a fully working automake 'make dist' :)

This patch fixes the build error for me.

Tested-by: Vinson Lee 

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

Re: [Mesa-dev] [PATCH 2/4] r600g: fix constant buffer fetches

[Andreas Boll]

Thanks for fixing!

Tested-by: Andreas Boll 

2014-08-11 22:46 GMT+02:00 Marek Olšák :
> From: Marek Olšák 
>
> Somebody forgot to do this. It was uncovered by recent st/mesa changes.
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82139
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/gallium/drivers/r600/r600_shader.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/r600/r600_shader.c 
> b/src/gallium/drivers/r600/r600_shader.c
> index 8019a1c..4f90586 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -1015,6 +1015,7 @@ static int tgsi_split_constant(struct r600_shader_ctx 
> *ctx)
> alu.src[0].sel = ctx->src[i].sel;
> alu.src[0].chan = k;
> alu.src[0].rel = ctx->src[i].rel;
> +   alu.src[0].kc_bank = ctx->src[i].kc_bank;
> alu.dst.sel = treg;
> alu.dst.chan = k;
> alu.dst.write = 1;
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #3 from Vinson Lee  ---
drm.h is at /usr/include/drm/drm.h

$ pkg-config --cflags libdrm
-I/usr/include/drm

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

Re: [Mesa-dev] [PATCHv2 04/13] glsl: protect anonymous struct id with a mutex

[Ian Romanick]

On 07/09/2014 12:47 AM, Chia-I Wu wrote:
> There may be two contexts compiling shaders at the same time, and we want the
> anonymous struct id to be globally unique.
> 
> Signed-off-by: Chia-I Wu 
> ---
>  src/glsl/glsl_parser_extras.cpp | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
> index b327c2b..ad31469 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -1347,9 +1347,15 @@ ast_struct_specifier::ast_struct_specifier(const char 
> *identifier,
>  ast_declarator_list *declarator_list)
>  {
> if (identifier == NULL) {
> +  static mtx_t mutex = _MTX_INITIALIZER_NP;
>static unsigned anon_count = 1;
> -  identifier = ralloc_asprintf(this, "#anon_struct_%04x", anon_count);
> -  anon_count++;
> +  unsigned count;
> +
> +  mtx_lock(&mutex);
> +  count = anon_count++;
> +  mtx_unlock(&mutex);

My previous feedback on this was to try and use some sort of atomic
counter when available.  I'm not excited about the performance hit of
taking a lock here.  Although, this probably isn't hit too much.  After
this lands, can you submit an enhancement bug for this issue?

> +
> +  identifier = ralloc_asprintf(this, "#anon_struct_%04x", count);
> }
> name = identifier;
> this->declarations.push_degenerate_list_at_head(&declarator_list->link);
> 

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

Re: [Mesa-dev] [PATCHv2 03/13] glsl: initialize locale_t with a static object

[Ian Romanick]

On 07/09/2014 12:47 AM, Chia-I Wu wrote:
> The compiler may be used by multiple contexts simultaneously and needs to be
> thread-safe.
> 
> Signed-off-by: Chia-I Wu 
> ---
>  src/glsl/strtod.cpp | 29 +++--
>  1 file changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/src/glsl/strtod.cpp b/src/glsl/strtod.cpp
> index 5d4346b..1ac29ec 100644
> --- a/src/glsl/strtod.cpp
> +++ b/src/glsl/strtod.cpp
> @@ -35,6 +35,17 @@
>  
>  #include "strtod.h"
>  
> +#if defined(_GNU_SOURCE) && !defined(__CYGWIN__) && !defined(__FreeBSD__) && 
> \
> +   !defined(__HAIKU__) && !defined(__UCLIBC__)
> +#define GLSL_HAVE_LOCALE_T
> +#endif

Could we just do this in configure.ac (or whatever the scons analog is)
instead?

> +
> +#ifdef GLSL_HAVE_LOCALE_T
> +static struct locale_initializer {
> +   locale_initializer() { loc = newlocale(LC_CTYPE_MASK, "C", NULL); }
> +   locale_t loc;
> +} loc_init;
> +#endif
>  
>  
>  /**
> @@ -44,13 +55,8 @@
>  double
>  glsl_strtod(const char *s, char **end)
>  {
> -#if defined(_GNU_SOURCE) && !defined(__CYGWIN__) && !defined(__FreeBSD__) && 
> \
> -   !defined(__HAIKU__) && !defined(__UCLIBC__)
> -   static locale_t loc = NULL;
> -   if (!loc) {
> -  loc = newlocale(LC_CTYPE_MASK, "C", NULL);
> -   }
> -   return strtod_l(s, end, loc);
> +#ifdef GLSL_HAVE_LOCALE_T
> +   return strtod_l(s, end, loc_init.loc);
>  #else
> return strtod(s, end);
>  #endif
> @@ -64,13 +70,8 @@ glsl_strtod(const char *s, char **end)
>  float
>  glsl_strtof(const char *s, char **end)
>  {
> -#if defined(_GNU_SOURCE) && !defined(__CYGWIN__) && !defined(__FreeBSD__) && 
> \
> -   !defined(__HAIKU__) && !defined(__UCLIBC__)
> -   static locale_t loc = NULL;
> -   if (!loc) {
> -  loc = newlocale(LC_CTYPE_MASK, "C", NULL);
> -   }
> -   return strtof_l(s, end, loc);
> +#ifdef GLSL_HAVE_LOCALE_T
> +   return strtof_l(s, end, loc_init.loc);
>  #elif _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE
> return strtof(s, end);
>  #else
> 

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

[Mesa-dev] [Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

[bugzilla-daemon]

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

--- Comment #23 from Eugene  ---
(In reply to comment #22)
> What happens if you set this environment variable and test firefox?
> 
> R600_DEBUG=nosb

Whan do you mean 'test firefox' ? Try to debug it again ?

-- 
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 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

   Keywords||bisected

--- Comment #2 from Vinson Lee  ---
fd7da27a43182169e6306d9df39e7e9498e38d28 is the first bad commit
commit fd7da27a43182169e6306d9df39e7e9498e38d28
Author: Emil Velikov 
Date:   Wed Aug 13 00:00:50 2014 +0100

automake: compact gallium/drivers and gallium/winsys makefiles

Rather than having two separate almost empty and identical makefiles,
compact them thus improving the configure and build time.
Additionally this makes the automake build symmetrical to the scons
and android one.

v2: Rebase on top of vc4, compact drivers + winsys on a single line.

Signed-off-by: Emil Velikov 
Reviewed-by: Matt Turner 

:100644 100644 2fc38ef709df6ecfef1b00ae35f2bad037d1fdf8
b4e32a70c7462866b689b4254c4ecd81e07b25cc Mconfigure.ac
:04 04 536ed7e80b32bab70fd3f4655d28c082a9c5c98e
cda7dc4291e0b5a2bebd639eb85908af2c0d88da Msrc
bisect run success

-- 
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 81680] [r600g] Firefox crashes with hardware acceleration turned on

[bugzilla-daemon]

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

--- Comment #22 from Marek Olšák  ---
What happens if you set this environment variable and test firefox?

R600_DEBUG=nosb

-- 
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 80561] Incorrect implementation of some VDPAU APIs.

[bugzilla-daemon]

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

--- Comment #1 from Christian König  ---
Created attachment 104577
  --> https://bugs.freedesktop.org/attachment.cgi?id=104577&action=edit
Possible fix

The attached patch should fix the issue, please test.

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

Re: [Mesa-dev] [PATCH 2/2] configure.ac: remove enable 32/64 bit hacks

[Matt Turner]

On Wed, Aug 13, 2014 at 11:03 AM, Emil Velikov  wrote:
> On 13/08/14 18:38, Matt Turner wrote:
>> On Wed, Aug 13, 2014 at 10:18 AM, Emil Velikov  
>> wrote:
>>> These two were added ages ago, with an explicit comment "Hacks ..."
>>> They have been insufficient for years and maintainers needed to
>>> explicitly handle the build themselves.
>>>
>>> Rather than lying and pretending that it works, just kill this hack and
>>> let maintainers build things the way it should be done for their
>>> distribution.
>>>
>>> Document the removal in the release notes.
>>
>> I've wanted to do this for a while. Gentoo has supported multilib
>> builds for a while and has never used these flags.
>>
>> Let's put something in the documentation that describes how to do
>> 32-bit builds on 64-bit platforms.
>>
> What kind of documentation do you have in mind ? IMHO "see how your
> distribution builds 32bit 'stuff'" is the best one :)

I think just some info telling people to use

   --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu

instead of --enable-32-bit would be sufficient.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa/texstore: Don't use the _mesa_swizzle_and_convert if we need transfer ops

[Jason Ekstrand]

The _mesa_swizzle_and_convert path can't do transfer ops, so we should bail
if they're needed.

Signed-off-by: Jason Ekstrand 
---
 src/mesa/main/texstore.c | 63 +---
 1 file changed, 33 insertions(+), 30 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 42cebbd..50c7dde 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1462,6 +1462,36 @@ invert_swizzle(uint8_t dst[4], const uint8_t src[4])
 dst[i] = j;
 }
 
+GLboolean
+_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
+  GLenum baseInternalFormat,
+  mesa_format dstFormat)
+{
+   GLenum dstType;
+
+   /* There are different rules depending on the base format. */
+   switch (baseInternalFormat) {
+   case GL_DEPTH_COMPONENT:
+   case GL_DEPTH_STENCIL:
+  return ctx->Pixel.DepthScale != 1.0f ||
+ ctx->Pixel.DepthBias != 0.0f;
+
+   case GL_STENCIL_INDEX:
+  return GL_FALSE;
+
+   default:
+  /* Color formats.
+   * Pixel transfer ops (scale, bias, table lookup) do not apply
+   * to integer formats.
+   */
+  dstType = _mesa_get_format_datatype(dstFormat);
+
+  return dstType != GL_INT && dstType != GL_UNSIGNED_INT &&
+ ctx->_ImageTransferState;
+   }
+}
+
+
 /** Store a texture by per-channel conversions and swizzling.
  *
  * This function attempts to perform a texstore operation by doing simple
@@ -1495,6 +1525,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
if (!is_array)
   return GL_FALSE;
 
+   if (_mesa_texstore_needs_transfer_ops(ctx, baseInternalFormat, dstFormat))
+  return GL_FALSE;
+
switch (srcType) {
case GL_FLOAT:
case GL_UNSIGNED_BYTE:
@@ -1762,36 +1795,6 @@ texstore_rgba(TEXSTORE_PARAMS)
 }
 
 GLboolean
-_mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
-  GLenum baseInternalFormat,
-  mesa_format dstFormat)
-{
-   GLenum dstType;
-
-   /* There are different rules depending on the base format. */
-   switch (baseInternalFormat) {
-   case GL_DEPTH_COMPONENT:
-   case GL_DEPTH_STENCIL:
-  return ctx->Pixel.DepthScale != 1.0f ||
- ctx->Pixel.DepthBias != 0.0f;
-
-   case GL_STENCIL_INDEX:
-  return GL_FALSE;
-
-   default:
-  /* Color formats.
-   * Pixel transfer ops (scale, bias, table lookup) do not apply
-   * to integer formats.
-   */
-  dstType = _mesa_get_format_datatype(dstFormat);
-
-  return dstType != GL_INT && dstType != GL_UNSIGNED_INT &&
- ctx->_ImageTransferState;
-   }
-}
-
-
-GLboolean
 _mesa_texstore_can_use_memcpy(struct gl_context *ctx,
   GLenum baseInternalFormat, mesa_format dstFormat,
   GLenum srcFormat, GLenum srcType,
-- 
2.0.4

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

Re: [Mesa-dev] [PATCH 2/2] configure.ac: remove enable 32/64 bit hacks

[Emil Velikov]

On 13/08/14 18:38, Matt Turner wrote:
> On Wed, Aug 13, 2014 at 10:18 AM, Emil Velikov  
> wrote:
>> These two were added ages ago, with an explicit comment "Hacks ..."
>> They have been insufficient for years and maintainers needed to
>> explicitly handle the build themselves.
>>
>> Rather than lying and pretending that it works, just kill this hack and
>> let maintainers build things the way it should be done for their
>> distribution.
>>
>> Document the removal in the release notes.
> 
> I've wanted to do this for a while. Gentoo has supported multilib
> builds for a while and has never used these flags.
> 
> Let's put something in the documentation that describes how to do
> 32-bit builds on 64-bit platforms.
> 
What kind of documentation do you have in mind ? IMHO "see how your
distribution builds 32bit 'stuff'" is the best one :)

-Emil
> Once we have that, both of these are
> 
> Reviewed-by: Matt Turner 
> 

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

Re: [Mesa-dev] [PATCH] mesa: fix texstore with GL_COLOR_INDEX data

[Jason Ekstrand]

Yeah, I think you're right about that.  I'll send out a quick fix-up
patch.  I guess we don't have piglit tests for that either.
--Jason


On Wed, Aug 13, 2014 at 10:56 AM, Roland Scheidegger 
wrote:

> Oh and forgot to mention, on a quick looked it seemed to me like the
> texstore_swizzle path could potentially forget about transfer ops, or
> can't this happen? Of course at least the state tracker would not be
> affected by this (as it implements the transfer ops on its own).
>
> Roland
>
> Am 13.08.2014 19:46, schrieb Roland Scheidegger:
> > Ha one minute faster :-).
> > FWIW interestingly this one also fixes the other conform failures I was
> > seeing (with GL_BYTE/GL_RGB data) when unconditionally disabling
> > texstore_swizzle so I guess the results of the swizzle path aren't quite
> > identical to the fallback one, which is a bit worrying.
> >
> > Roland
> >
> >
> > Am 13.08.2014 19:35, schrieb Jason Ekstrand:
> >> Roland,
> >> I just sent the exact same patch.
> >>
> >> Reviewed-by: Jason Ekstrand  >> >
> >>
> >>
> >> On Wed, Aug 13, 2014 at 10:33 AM,  >> > wrote:
> >>
> >> From: Roland Scheidegger  >> >
> >>
> >> This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
> >> GL_COLOR_INDEX data is still supported (in legacy contexts), but
> the new
> >> texstore_swizzle path cannot handle it (and didn't detect this).
> >> Unfortunately there's no piglit test trying to specify textures
> with a
> >> GL_COLOR_INDEX source format, and I don't really understand how all
> >> the color
> >> map stuff which is used by this works, but this caused conform
> failures
> >> (with a reported mesa implementation error when trying to figure out
> >> the color
> >> mapping).
> >> ---
> >>  src/mesa/main/texstore.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
> >> index 50306d8..4ea5bd8 100644
> >> --- a/src/mesa/main/texstore.c
> >> +++ b/src/mesa/main/texstore.c
> >> @@ -1495,6 +1495,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
> >> if (!is_array)
> >>return GL_FALSE;
> >>
> >> +   if (srcFormat == GL_COLOR_INDEX)
> >> +  return GL_FALSE;
> >> +
> >> switch (srcType) {
> >> case GL_FLOAT:
> >> case GL_UNSIGNED_BYTE:
> >> --
> >> 1.9.1
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org  mesa-dev@lists.freedesktop.org>
> >>
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=xqryYn1SYeTuaMHcKhK9kr5ky%2B5J1xT0UbAWnqrV6NI%3D%0A&s=ebe6df4c3e57be9157eb91233e4e044c21707ee4994d7c87a4c027db8d4f83e2
> >> <
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=kpN1ocKMKopthTMpVD729xdP3L%2F%2BKfivsbBUJlBpVdY%3D%0A&s=079b1ceec81b05c2373f584c1766e6c24fe8895f13610993060e66d56dc2a1de
> >
> >>
> >>
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> >
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=xqryYn1SYeTuaMHcKhK9kr5ky%2B5J1xT0UbAWnqrV6NI%3D%0A&s=ebe6df4c3e57be9157eb91233e4e044c21707ee4994d7c87a4c027db8d4f83e2
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

[bugzilla-daemon]

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

--- Comment #21 from Eugene  ---
Recently tried another way. Please, look at attachment. May be this way result
will be something helpfull (?)

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

Re: [Mesa-dev] [PATCH] mesa: fix texstore with GL_COLOR_INDEX data

[Roland Scheidegger]

Oh and forgot to mention, on a quick looked it seemed to me like the
texstore_swizzle path could potentially forget about transfer ops, or
can't this happen? Of course at least the state tracker would not be
affected by this (as it implements the transfer ops on its own).

Roland

Am 13.08.2014 19:46, schrieb Roland Scheidegger:
> Ha one minute faster :-).
> FWIW interestingly this one also fixes the other conform failures I was
> seeing (with GL_BYTE/GL_RGB data) when unconditionally disabling
> texstore_swizzle so I guess the results of the swizzle path aren't quite
> identical to the fallback one, which is a bit worrying.
> 
> Roland
> 
> 
> Am 13.08.2014 19:35, schrieb Jason Ekstrand:
>> Roland,
>> I just sent the exact same patch.
>>
>> Reviewed-by: Jason Ekstrand > >
>>
>>
>> On Wed, Aug 13, 2014 at 10:33 AM, > > wrote:
>>
>> From: Roland Scheidegger > >
>>
>> This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
>> GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
>> texstore_swizzle path cannot handle it (and didn't detect this).
>> Unfortunately there's no piglit test trying to specify textures with a
>> GL_COLOR_INDEX source format, and I don't really understand how all
>> the color
>> map stuff which is used by this works, but this caused conform failures
>> (with a reported mesa implementation error when trying to figure out
>> the color
>> mapping).
>> ---
>>  src/mesa/main/texstore.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
>> index 50306d8..4ea5bd8 100644
>> --- a/src/mesa/main/texstore.c
>> +++ b/src/mesa/main/texstore.c
>> @@ -1495,6 +1495,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
>> if (!is_array)
>>return GL_FALSE;
>>
>> +   if (srcFormat == GL_COLOR_INDEX)
>> +  return GL_FALSE;
>> +
>> switch (srcType) {
>> case GL_FLOAT:
>> case GL_UNSIGNED_BYTE:
>> --
>> 1.9.1
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org 
>> 
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=xqryYn1SYeTuaMHcKhK9kr5ky%2B5J1xT0UbAWnqrV6NI%3D%0A&s=ebe6df4c3e57be9157eb91233e4e044c21707ee4994d7c87a4c027db8d4f83e2
>> 
>> 
>>
>>
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=xqryYn1SYeTuaMHcKhK9kr5ky%2B5J1xT0UbAWnqrV6NI%3D%0A&s=ebe6df4c3e57be9157eb91233e4e044c21707ee4994d7c87a4c027db8d4f83e2
> 

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

[Mesa-dev] [Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

[bugzilla-daemon]

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

--- Comment #20 from Eugene  ---
Created attachment 104576
  --> https://bugs.freedesktop.org/attachment.cgi?id=104576&action=edit
Debugging output

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

Re: [Mesa-dev] [PATCH] mesa: fix texstore with GL_COLOR_INDEX data

[Roland Scheidegger]

Ha one minute faster :-).
FWIW interestingly this one also fixes the other conform failures I was
seeing (with GL_BYTE/GL_RGB data) when unconditionally disabling
texstore_swizzle so I guess the results of the swizzle path aren't quite
identical to the fallback one, which is a bit worrying.

Roland


Am 13.08.2014 19:35, schrieb Jason Ekstrand:
> Roland,
> I just sent the exact same patch.
> 
> Reviewed-by: Jason Ekstrand  >
> 
> 
> On Wed, Aug 13, 2014 at 10:33 AM,  > wrote:
> 
> From: Roland Scheidegger  >
> 
> This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
> GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
> texstore_swizzle path cannot handle it (and didn't detect this).
> Unfortunately there's no piglit test trying to specify textures with a
> GL_COLOR_INDEX source format, and I don't really understand how all
> the color
> map stuff which is used by this works, but this caused conform failures
> (with a reported mesa implementation error when trying to figure out
> the color
> mapping).
> ---
>  src/mesa/main/texstore.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
> index 50306d8..4ea5bd8 100644
> --- a/src/mesa/main/texstore.c
> +++ b/src/mesa/main/texstore.c
> @@ -1495,6 +1495,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
> if (!is_array)
>return GL_FALSE;
> 
> +   if (srcFormat == GL_COLOR_INDEX)
> +  return GL_FALSE;
> +
> switch (srcType) {
> case GL_FLOAT:
> case GL_UNSIGNED_BYTE:
> --
> 1.9.1
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 
> 
> 

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

[Mesa-dev] [PATCH] mesa/texstore: Don't try swizzle_and_convert on color-index formats

[Jason Ekstrand]

The _mesa_swizzle_and_convert function can't handle them.  Now we fall back
to the more generic path which can handle it instead of failing an assert.

Signed-off-by: Jason Ekstrand 
---
 src/mesa/main/texstore.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 50306d8..42cebbd 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1526,6 +1526,10 @@ texstore_swizzle(TEXSTORE_PARAMS)
}
swap = need_swap ? map_3210 : map_identity;
 
+   /* _mesa_swizzle_and_convert can't handle color-index formats */
+   if (srcFormat == GL_COLOR_INDEX)
+  return GL_FALSE;
+
compute_component_mapping(srcFormat, baseInternalFormat, base2src);
compute_component_mapping(baseInternalFormat, GL_RGBA, rgba2base);
invert_swizzle(dst2rgba, rgba2dst);
-- 
2.0.4

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

Re: [Mesa-dev] [PATCH 2/2] configure.ac: remove enable 32/64 bit hacks

[Matt Turner]

On Wed, Aug 13, 2014 at 10:18 AM, Emil Velikov  wrote:
> These two were added ages ago, with an explicit comment "Hacks ..."
> They have been insufficient for years and maintainers needed to
> explicitly handle the build themselves.
>
> Rather than lying and pretending that it works, just kill this hack and
> let maintainers build things the way it should be done for their
> distribution.
>
> Document the removal in the release notes.

I've wanted to do this for a while. Gentoo has supported multilib
builds for a while and has never used these flags.

Let's put something in the documentation that describes how to do
32-bit builds on 64-bit platforms.

Once we have that, both of these are

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

Re: [Mesa-dev] [PATCH] mesa: fix texstore with GL_COLOR_INDEX data

[Jason Ekstrand]

Roland,
I just sent the exact same patch.

Reviewed-by: Jason Ekstrand 


On Wed, Aug 13, 2014 at 10:33 AM,  wrote:

> From: Roland Scheidegger 
>
> This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
> GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
> texstore_swizzle path cannot handle it (and didn't detect this).
> Unfortunately there's no piglit test trying to specify textures with a
> GL_COLOR_INDEX source format, and I don't really understand how all the
> color
> map stuff which is used by this works, but this caused conform failures
> (with a reported mesa implementation error when trying to figure out the
> color
> mapping).
> ---
>  src/mesa/main/texstore.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
> index 50306d8..4ea5bd8 100644
> --- a/src/mesa/main/texstore.c
> +++ b/src/mesa/main/texstore.c
> @@ -1495,6 +1495,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
> if (!is_array)
>return GL_FALSE;
>
> +   if (srcFormat == GL_COLOR_INDEX)
> +  return GL_FALSE;
> +
> switch (srcType) {
> case GL_FLOAT:
> case GL_UNSIGNED_BYTE:
> --
> 1.9.1
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: fix texstore with GL_COLOR_INDEX data

[sroland]

From: Roland Scheidegger 

This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify textures with a
GL_COLOR_INDEX source format, and I don't really understand how all the color
map stuff which is used by this works, but this caused conform failures
(with a reported mesa implementation error when trying to figure out the color
mapping).
---
 src/mesa/main/texstore.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 50306d8..4ea5bd8 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -1495,6 +1495,9 @@ texstore_swizzle(TEXSTORE_PARAMS)
if (!is_array)
   return GL_FALSE;
 
+   if (srcFormat == GL_COLOR_INDEX)
+  return GL_FALSE;
+
switch (srcType) {
case GL_FLOAT:
case GL_UNSIGNED_BYTE:
-- 
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): mesa/formats: Add layout and swizzle information

[Jason Ekstrand]

On Tue, Aug 12, 2014 at 8:52 PM, Roland Scheidegger 
wrote:

> Am 06.08.2014 11:28, schrieb Michel Dänzer:
> > On 06.08.2014 03:08, Jason Ekstrand wrote:
> >> Module: Mesa
> >> Branch: master
> >> Commit: 850fb0d1dca616179d3239a7b7bd94fe1979604c
> >> URL:
> https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D850fb0d1dca616179d3239a7b7bd94fe1979604c&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=M3mfjwgruJzPHL55%2BrGtDjCQ6DTQMURIoUjKbv00MIU%3D%0A&s=af10bfc26af3611fea43b64de32c55e38bc2721b145a63dcde3f0085fcd850d7
> >>
> >> Author: Jason Ekstrand 
> >> Date:   Thu Jul 10 23:59:42 2014 -0700
> >>
> >> mesa/formats: Add layout and swizzle information
> >>
> >> v2: Move the MESA_FORMAT_SWIZZLE enum to the top of the file
> >>
> >> Signed-off-by: Jason Ekstrand 
> >> Reviewed-by: Brian Paul 
> >
> > As of this commit, ~20 depth/stencil related piglit tests have regressed
> with the radeonsi driver compared to before your changes. See below for an
> example failure of the draw-pixels test.
> >
>
> There's actually more breakage due to this at least in gallium based
> drivers though unfortunately there's no piglit test catching it (conform
> drawpix does). I'm not sure if this is along similar lines to the issues
> with stencil index, but drawpixel with GL_COLOR_INDEX data is busted -
> it'll actually report a mesa implementation error because the
> COLOR_INDEX_DATA is passed through to the texstore functions, and the
> new texstore_swizzle() function can't handle this.
> Backtrace from the error looks like this:
>
> #0  get_map_idx (value=6400) at src/mesa/main/texstore.c:245
> #1  0x73ee0f56 in compute_component_mapping (inFormat=6400,
> outFormat=6408, map=0x7fffb310 "@\263\377\377\377\177")
> at src/mesa/main/texstore.c:264
> #2  0x73ee4312 in texstore_swizzle (ctx=0x77fd3010, dims=2,
> baseInternalFormat=6408, dstFormat=MESA_FORMAT_R8G8B8A8_UNORM,
> dstRowStride=192, dstSlices=0x7fffb4a0, srcWidth=40, srcHeight=40,
> srcDepth=1, srcFormat=6400, srcType=5121, srcAddr=0x8aa980,
> srcPacking=0x7fffb590) at src/mesa/main/texstore.c:1529
> #3  0x73ee4cc6 in texstore_rgba (ctx=0x77fd3010, dims=2,
> baseInternalFormat=6408, dstFormat=MESA_FORMAT_R8G8B8A8_UNORM,
> dstRowStride=192, dstSlices=0x7fffb4a0, srcWidth=40, srcHeight=40,
> srcDepth=1, srcFormat=6400, srcType=5121, srcAddr=0x8aa980,
> srcPacking=0x7fffb590) at src/mesa/main/texstore.c:1730
> #4  0x73ee5190 in _mesa_texstore (ctx=0x77fd3010, dims=2,
> baseInternalFormat=6408, dstFormat=MESA_FORMAT_R8G8B8A8_UNORM,
> dstRowStride=192, dstSlices=0x7fffb4a0, srcWidth=40, srcHeight=40,
> srcDepth=1, srcFormat=6400, srcType=5121, srcAddr=0x8aa980,
> srcPacking=0x7fffb590) at src/mesa/main/texstore.c:1871
> #5  0x740876c2 in make_texture (st=0x8367d0, width=40, height=40,
> format=6400, type=5121, unpack=0x7fffb590, pixels=0x8aa980)
> at src/mesa/state_tracker/st_cb_drawpixels.c:540
> #6  0x740895ee in st_DrawPixels (ctx=0x77fd3010, x=0, y=0,
> width=40, height=40, format=6400, type=5121, unpack=0x7fffb590,
> pixels=0x8aa980) at src/mesa/state_tracker/st_cb_drawpixels.c:1170
> #7  0x73f7cfb2 in _mesa_DrawPixels (width=40, height=40,
> format=6400,
> type=5121, pixels=0x8aa980) at src/mesa/main/drawpix.c:162
>
> I can't quite see if that is even supposed to work or if the state
> tracker needs to handle it (it used to work at least somehow), though
> quickly disabling texstore_swizzle() does fix it (doesn't help all that
> much though since the test will then later complain about other cases
> though maybe these are due to the different snorm formulas, as it
> happens with GL_BYTE/GL_RGB type/format).
>
> Any ideas?
>

Yeah, I forgot about the color-index formats since mesa doesn't handle them
as internal formats anymore.  I'll send out a patch that I *think* will fix
it.  If you could give it a try, that would be great.
-- Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] configure.ac: remove enable 32/64 bit hacks

[Emil Velikov]

These two were added ages ago, with an explicit comment "Hacks ..."
They have been insufficient for years and maintainers needed to
explicitly handle the build themselves.

Rather than lying and pretending that it works, just kill this hack and
let maintainers build things the way it should be done for their
distribution.

Document the removal in the release notes.

Signed-off-by: Emil Velikov 
---
 configure.ac| 40 ++--
 docs/relnotes/10.3.html |  2 ++
 2 files changed, 4 insertions(+), 38 deletions(-)

diff --git a/configure.ac b/configure.ac
index f678fa3..dc81c80 100644
--- a/configure.ac
+++ b/configure.ac
@@ -243,39 +243,6 @@ if test "x$SSE41_SUPPORTED" = x1; then
 fi
 AM_CONDITIONAL([SSE41_SUPPORTED], [test x$SSE41_SUPPORTED = x1])
 
-dnl
-dnl Hacks to enable 32 or 64 bit build
-dnl
-AC_ARG_ENABLE([32-bit],
-[AS_HELP_STRING([--enable-32-bit],
-[build 32-bit libraries @<:@default=auto@:>@])],
-[enable_32bit="$enableval"],
-[enable_32bit=auto]
-)
-if test "x$enable_32bit" = xyes; then
-if test "x$GCC" = xyes; then
-CFLAGS="$CFLAGS -m32"
-CCASFLAGS="$CCASFLAGS -m32"
-fi
-if test "x$GXX" = xyes; then
-CXXFLAGS="$CXXFLAGS -m32"
-fi
-fi
-AC_ARG_ENABLE([64-bit],
-[AS_HELP_STRING([--enable-64-bit],
-[build 64-bit libraries @<:@default=auto@:>@])],
-[enable_64bit="$enableval"],
-[enable_64bit=auto]
-)
-if test "x$enable_64bit" = xyes; then
-if test "x$GCC" = xyes; then
-CFLAGS="$CFLAGS -m64"
-fi
-if test "x$GXX" = xyes; then
-CXXFLAGS="$CXXFLAGS -m64"
-fi
-fi
-
 dnl Can't have static and shared libraries, default to static if user
 dnl explicitly requested. If both disabled, set to static since shared
 dnl was explicitly requested.
@@ -487,10 +454,7 @@ if test "x$enable_asm" = xyes; then
 case "$host_cpu" in
 i?86)
 case "$host_os" in
-linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*)
-test "x$enable_64bit" = xyes && asm_arch=x86_64 || asm_arch=x86
-;;
-gnu*)
+linux* | *freebsd* | dragonfly* | *netbsd* | openbsd* | gnu*)
 asm_arch=x86
 ;;
 esac
@@ -498,7 +462,7 @@ if test "x$enable_asm" = xyes; then
 x86_64|amd64)
 case "$host_os" in
 linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*)
-test "x$enable_32bit" = xyes && asm_arch=x86 || asm_arch=x86_64
+asm_arch=x86_64
 ;;
 esac
 ;;
diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html
index a297106..86cbabc 100644
--- a/docs/relnotes/10.3.html
+++ b/docs/relnotes/10.3.html
@@ -77,6 +77,8 @@ TBD.
 
 
 Removed support for the GL_ATI_envmap_bumpmap extension
+The hacky --enable-32/64-bit is no longer available in configure. To build
+32/64 bit mesa refer to the default method recommended by your 
distribution
 
 
 
-- 
2.0.2

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

[Mesa-dev] [PATCH 1/2] Revert "configure: Fix --enable-XX-bit flags by moving LT_INIT where it should"

[Emil Velikov]

This reverts commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03.

The commit was resolving an issue where libtool will not setup the
environment correctly when one explicitly provides --enable-{32,64}-bit
at configure time. It was caused due to the "-m32,64" C{,XX}FLAGS being
set too late relative to LT_INIT.

At the same time this cases the enable_static to be incorrectly set,
amongst others leading to build issues. Rather than being smart and
trying to handle 32/64 bit build ourselves it may be better to delegate
it to the builder/maintainer. The latter should now know better which is
the correct(most appropriate) method.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82536
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82546
---
 configure.ac | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4ff87eb..f678fa3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -57,6 +57,9 @@ AC_CHECK_PROGS([PYTHON2], [python2 python])
 AC_PROG_SED
 AC_PROG_MKDIR_P
 
+LT_PREREQ([2.2])
+LT_INIT([disable-static])
+
 AX_PROG_BISON([],
   AS_IF([test ! -f "$srcdir/src/glsl/glcpp/glcpp-parse.c"],
 [AC_MSG_ERROR([bison not found - unable to compile 
glcpp-parse.y])]))
@@ -2190,14 +2193,6 @@ dnl Add user CFLAGS and CXXFLAGS
 CFLAGS="$CFLAGS $USER_CFLAGS"
 CXXFLAGS="$CXXFLAGS $USER_CXXFLAGS"
 
-dnl
-dnl LT_INIT adds tests to determine host based on some variables like 
(AM_)C(XX)FLAGS and (AM_)LDFLAGS.
-dnl They need to be set before calling LT_INIT so the macro can configure 
things correctly when cross_compiling.
-dnl This will allow --enable-xx-bit to work as expected.
-dnl
-LT_PREREQ([2.2])
-LT_INIT([disable-static])
-
 dnl Substitute the config
 AC_CONFIG_FILES([Makefile
src/Makefile
-- 
2.0.2

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

[Mesa-dev] [PATCH] i915: Fix texcoord vs. varying collision in fragment programs

[ville . syrjala]

From: Ville Syrjälä 

i915 fragment programs utilize the texture coordinate registers
for both texture coordinates and varyings. Unfortunately the
code doesn't check if the same index might be in use for both.
It just naively uses the index to pick a texture unit, which
could lead to collisions.

Add an extra mapping step to allocate non conflicting texture
units for both uses.

The issue can be reproduced with a pair of simple shaders like
these:
 attribute vec4 in_mod;
 varying vec4 mod;
 void main() {
   mod = in_mod;
   gl_TexCoord[0] = gl_MultiTexCoord0;
   gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
 }

 varying vec4 mod;
 uniform sampler2D tex;
 void main() {
   gl_FragColor = texture2D(tex, vec2(gl_TexCoord[0])) * mod;
 }

This was tested on a PNV.

Signed-off-by: Ville Syrjälä 
---
 src/mesa/drivers/dri/i915/i915_context.h  | 14 ++---
 src/mesa/drivers/dri/i915/i915_fragprog.c | 86 +--
 2 files changed, 74 insertions(+), 26 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_context.h 
b/src/mesa/drivers/dri/i915/i915_context.h
index 34af202..2615bd6 100644
--- a/src/mesa/drivers/dri/i915/i915_context.h
+++ b/src/mesa/drivers/dri/i915/i915_context.h
@@ -115,6 +115,8 @@ enum {
I915_RASTER_RULES_SETUP_SIZE,
 };
 
+#define I915_TEX_UNITS 8
+
 #define I915_MAX_CONSTANT  32
 #define I915_CONSTANT_SIZE (2+(4*I915_MAX_CONSTANT))
 
@@ -194,7 +196,8 @@ struct i915_fragment_program
 
/* Helpers for i915_fragprog.c:
 */
-   GLuint wpos_tex;
+   uint8_t texcoord_mapping[I915_TEX_UNITS];
+   uint8_t wpos_tex;
bool depth_written;
 
struct
@@ -205,15 +208,6 @@ struct i915_fragment_program
GLuint nr_params;
 };
 
-
-
-
-
-
-
-#define I915_TEX_UNITS 8
-
-
 struct i915_hw_state
 {
GLuint Ctx[I915_CTX_SETUP_SIZE];
diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c 
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index 96fdd3c..05e1de6 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -72,6 +72,24 @@ static const GLfloat cos_constants[4] = { 1.0,
-1.0 / (6 * 5 * 4 * 3 * 2 * 1)
 };
 
+/* texcoord_mapping[unit] = index | TEXCOORD_{TEX,VAR} */
+#define TEXCOORD_TEX (0<<7)
+#define TEXCOORD_VAR (1<<7)
+
+static GLint get_texcoord_mapping(struct i915_fragment_program *p,
+  uint8_t texcoord)
+{
+   GLint i;
+
+   for (i = 0; i < p->ctx->Const.MaxTextureCoordUnits; i++) {
+  if (p->texcoord_mapping[i] == texcoord)
+ return i;
+   }
+
+   /* blah */
+   return p->ctx->Const.MaxTextureCoordUnits - 1;
+}
+
 /**
  * Retrieve a ureg for the given source register.  Will emit
  * constants, apply swizzling and negation as needed.
@@ -82,6 +100,7 @@ src_vector(struct i915_fragment_program *p,
const struct gl_fragment_program *program)
 {
GLuint src;
+   GLint unit;
 
switch (source->File) {
 
@@ -119,8 +138,10 @@ src_vector(struct i915_fragment_program *p,
   case VARYING_SLOT_TEX5:
   case VARYING_SLOT_TEX6:
   case VARYING_SLOT_TEX7:
+ unit = get_texcoord_mapping(p, (source->Index -
+ VARYING_SLOT_TEX0) | TEXCOORD_TEX);
  src = i915_emit_decl(p, REG_TYPE_T,
-  T_TEX0 + (source->Index - VARYING_SLOT_TEX0),
+  T_TEX0 + unit,
   D0_CHANNEL_ALL);
 break;
 
@@ -132,8 +153,10 @@ src_vector(struct i915_fragment_program *p,
   case VARYING_SLOT_VAR0 + 5:
   case VARYING_SLOT_VAR0 + 6:
   case VARYING_SLOT_VAR0 + 7:
+ unit = get_texcoord_mapping(p, (source->Index -
+ VARYING_SLOT_VAR0) | TEXCOORD_VAR);
  src = i915_emit_decl(p, REG_TYPE_T,
-  T_TEX0 + (source->Index - VARYING_SLOT_VAR0),
+  T_TEX0 + unit,
   D0_CHANNEL_ALL);
  break;
 
@@ -1190,27 +1213,55 @@ fixup_depth_write(struct i915_fragment_program *p)
}
 }
 
+static void
+check_texcoord_mapping(struct i915_fragment_program *p)
+{
+   GLbitfield64 inputs = p->FragProg.Base.InputsRead;
+   GLint i;
+   GLint unit = 0;
+
+   for (i = 0; i < p->ctx->Const.MaxTextureCoordUnits; i++) {
+  if (inputs & VARYING_BIT_TEX(i)) {
+ if (unit >= p->ctx->Const.MaxTextureCoordUnits) {
+unit++;
+break;
+ }
+ p->texcoord_mapping[unit++] = i | TEXCOORD_TEX;
+  }
+  if (inputs & VARYING_BIT_VAR(i)) {
+ if (unit >= p->ctx->Const.MaxTextureCoordUnits) {
+unit++;
+break;
+ }
+ p->texcoord_mapping[unit++] = i | TEXCOORD_VAR;
+  }
+   }
+
+   if (unit > p->ctx->Const.MaxTextureCoordUnits)
+  i915_program_error(p, "Too many texcoord units");
+}
 
 static void
 check_wpos(struct i915_fragment_program *p)
 {
GLbitfield64 inputs = p->FragProg.Base.InputsRead;
GLint i;

[Mesa-dev] [Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

[bugzilla-daemon]

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

--- Comment #19 from Eugene  ---
Yes, it seems several crash happens during debugging. But Firefox not closed.
And at last I reached the crash that happens after closing Firefox. But if
several crashes happens before the crash closing Firefox, how it could be
possible to backtrace it ?
If I try to run bt/bt full immediately after first segmentation fault, it
writes the following:

#0  PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
No locals.
#1  js::jit::JitRuntime::patchIonBackedges (this=, rt=, target=target@entry=js::jit::JitRuntime::BackedgeLoopHeader) at
/build/buildd/firefox-31.0+build1/js/src/jit/Ion.cpp:412
iter = {iter = 0x7fffb95d1de0}
#2  0x732cab85 in js::jit::InterruptCheck (cx=0x7fffdeb54480) at
/build/buildd/firefox-31.0+build1/js/src/jit/VMFunctions.cpp:523
No locals.
#3  0x77e5527a in ?? ()
No symbol table info available.
#4  0x7fff78b8 in ?? ()
No symbol table info available.
#5  0x7fff7840 in ?? ()
No symbol table info available.
#6  0x754f0840 in DeepCloneObjectLiteralInfo () from
/usr/lib/firefox/libxul.so
No symbol table info available.
#7  0x7fffe0d34880 in ?? ()
No symbol table info available.
#8  0x7fffe0adde71 in ?? ()
No symbol table info available.
#9  0x0601 in ?? ()
No symbol table info available.
#10 0x7fff78b8 in ?? ()
No symbol table info available.
#11 0xfffbbdc542b0 in ?? ()
No symbol table info available.
#12 0xfffbdb521b00 in ?? ()
No symbol table info available.
#13 0x4cfbc8b851ea6000 in ?? ()
No symbol table info available.
#14 0x7fff7990 in ?? ()
No symbol table info available.
#15 0xfff88058 in ?? ()
No symbol table info available.
#16 0x7fffdb530a80 in ?? ()
No symbol table info available.
#17 0x in ?? ()
No symbol table info available.
#0  PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
#1  js::jit::JitRuntime::patchIonBackedges (this=, rt=, target=target@entry=js::jit::JitRuntime::BackedgeLoopHeader) at
/build/buildd/firefox-31.0+build1/js/src/jit/Ion.cpp:412
#2  0x732cab85 in js::jit::InterruptCheck (cx=0x7fffdeb54480) at
/build/buildd/firefox-31.0+build1/js/src/jit/VMFunctions.cpp:523
#3  0x77e5527a in ?? ()
#4  0x7fff78b8 in ?? ()
#5  0x7fff7840 in ?? ()
#6  0x754f0840 in DeepCloneObjectLiteralInfo () from
/usr/lib/firefox/libxul.so
#7  0x7fffe0d34880 in ?? ()
#8  0x7fffe0adde71 in ?? ()
#9  0x0601 in ?? ()
#10 0x7fff78b8 in ?? ()
#11 0xfffbbdc542b0 in ?? ()
#12 0xfffbdb521b00 in ?? ()
#13 0x4cfbc8b851ea6000 in ?? ()
#14 0x7fff7990 in ?? ()
#15 0xfff88058 in ?? ()
#16 0x7fffdb530a80 in ?? ()
#17 0x in ?? ()

Where are those damn symbols ? o_O

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

Re: [Mesa-dev] [PATCH] egl_dri2: fix EXT_image_dma_buf_import fds

[Pohjolainen, Topi]

On Fri, Aug 08, 2014 at 05:28:59PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen 
> 
> The EGL_EXT_image_dma_buf_import specification was revised (according to
> its revision history) on Dec 5th, 2013, for EGL to not take ownership of
> the file descriptors.
> 
> Do not close the file descriptors passed in to eglCreateImageKHR with
> EGL_LINUX_DMA_BUF_EXT target.
> 
> It is assumed, that the drivers, which ultimately process the file
> descriptors, do not close or modify them in any way either. This avoids
> the need to dup(), as it seems we would only need to just close the
> dup'd file descriptors right after.
> 
> Signed-off-by: Pekka Paalanen 

I wrote the current logic based on the older version, and at least to me this
is the right thing to do. Thanks for fixing it as well as taking care of the
piglit test.

Reviewed-by: Topi Pohjolainen 

I would be happier though if someone else gave his/her approval as well.

> ---
> 
> Hi,
> 
> the corresponding Piglit fix has already been sent to the piglit mailing
> list. Both this and that need to be applied to not regress Mesa' piglit run
> by one test (ext_image_dma_buf_import-ownership_transfer).
> 
> This patch fixes my test case on heavily modified Weston.
> 
> Thanks,
> pq
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 37 ++---
>  1 file changed, 6 insertions(+), 31 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 5602ec3..cd85fd3 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1678,36 +1678,13 @@ dri2_check_dma_buf_format(const _EGLImageAttribs 
> *attrs)
>  /**
>   * The spec says:
>   *
> - * "If eglCreateImageKHR is successful for a EGL_LINUX_DMA_BUF_EXT target,
> - *  the EGL takes ownership of the file descriptor and is responsible for
> - *  closing it, which it may do at any time while the EGLDisplay is
> - *  initialized."
> + * "If eglCreateImageKHR is successful for a EGL_LINUX_DMA_BUF_EXT target, 
> the
> + *  EGL will take a reference to the dma_buf(s) which it will release at any
> + *  time while the EGLDisplay is initialized. It is the responsibility of the
> + *  application to close the dma_buf file descriptors."
> + *
> + * Therefore we must never close or otherwise modify the file descriptors.
>   */
> -static void
> -dri2_take_dma_buf_ownership(const int *fds, unsigned num_fds)
> -{
> -   int already_closed[num_fds];
> -   unsigned num_closed = 0;
> -   unsigned i, j;
> -
> -   for (i = 0; i < num_fds; ++i) {
> -  /**
> -   * The same file descriptor can be referenced multiple times in case 
> more
> -   * than one plane is found in the same buffer, just with a different
> -   * offset.
> -   */
> -  for (j = 0; j < num_closed; ++j) {
> - if (already_closed[j] == fds[i])
> -break;
> -  }
> -
> -  if (j == num_closed) {
> - close(fds[i]);
> - already_closed[num_closed++] = fds[i];
> -  }
> -   }
> -}
> -
>  static _EGLImage *
>  dri2_create_image_dma_buf(_EGLDisplay *disp, _EGLContext *ctx,
> EGLClientBuffer buffer, const EGLint *attr_list)
> @@ -1770,8 +1747,6 @@ dri2_create_image_dma_buf(_EGLDisplay *disp, 
> _EGLContext *ctx,
>return EGL_NO_IMAGE_KHR;
>  
> res = dri2_create_image_from_dri(disp, dri_image);
> -   if (res)
> -  dri2_take_dma_buf_ownership(fds, num_fds);
>  
> return res;
>  }
> -- 
> 1.8.5.5
> 
> ___
> 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 82546] [regression] libOSMesa build failure

[bugzilla-daemon]

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

--- Comment #4 from Tobias Klausmann  ---
git bisect shows

2af28040d639dddbb7c258981a00eaf3dfcbcf03 is the first bad commit
commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03
Author: Alexandre Demers 
Date:   Fri Nov 22 20:06:20 2013 -0500

configure: Fix --enable-XX-bit flags by moving LT_INIT where it should

Moving LT_INIT after setting completely (AM_)C(XX)FLAGS and LDFLAGS.
LT_INIT needs them as they are expected to be used all along
the compilation when the macro runs its tests to determine among other
things the host type.

For info, see
http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50754
Signed-off-by: Alexandre Demers 
Tested-by: Tapani Palli 
Reviewed-by: Emil Velikov 

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