Re: [Mesa-dev] [PATCH 2/2] i965: Fix shared atomic intrinsics to pay attention to base.

[Jason Ekstrand]

On Jul 18, 2016 3:49 PM, "Kenneth Graunke"  wrote:
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> index 6265dc6..a39c37e 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> @@ -4177,13 +4177,24 @@ fs_visitor::nir_emit_shared_atomic(const
fs_builder ,
>dest = get_nir_dest(instr->dest);
>
> fs_reg surface = brw_imm_ud(GEN7_BTI_SLM);
> -   fs_reg offset = get_nir_src(instr->src[0]);
> +   fs_reg offset;
> fs_reg data1 = get_nir_src(instr->src[1]);
> fs_reg data2;
> if (op == BRW_AOP_CMPWR)
>data2 = get_nir_src(instr->src[2]);
>
> -   /* Emit the actual atomic operation operation */
> +   /* Get the offset */
> +   nir_const_value *const_offset = nir_src_as_const_value(instr->src[0]);
> +   if (const_offset) {
> +  offset = brw_imm_ud(instr->const_index[0] + const_offset->u32[0]);

Should we be using nir_intrinsic_base here instead of accessing the
const_index directly?

> +   } else {
> +  offset = vgrf(glsl_type::uint_type);
> +  bld.ADD(offset,
> + retype(get_nir_src(instr->src[0]), BRW_REGISTER_TYPE_UD),
> + brw_imm_ud(instr->const_index[0]));

Same here

> +   }
> +
> +   /* Emit the actua atomic operation operation */
>
> fs_reg atomic_result = emit_untyped_atomic(bld, surface, offset,
>data1, data2,
> --
> 2.9.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965: Fix shared atomic intrinsics to pay attention to base.

[Kenneth Graunke]

On Tuesday, July 19, 2016 10:23:03 AM PDT Timothy Arceri wrote:
> On Mon, 2016-07-18 at 15:49 -0700, Kenneth Graunke wrote:
> So this fixes a bug with indirects right? Is there a piglit test for
> this?

Not exactly.  Right now, GLSL lowers shared variable access at the
GLSL IR level, and when we translate the GLSL IR intrinsics to NIR,
we always set base to 0 and put everything in offset.  So Piglit
wouldn't have hit this.

Vulkan lowers shared variables in NIR, and was actually using a
non-zero base.  Vulkan tests could have hit this, but I don't think
any actually did.

I recall Jordan saying he ran into some issues when trying to make
GLSL use the NIR-based lowering, so maybe Piglit actually did hit
this base problem.  Not sure.

> With the typo Ilia pointed out fixed, both are:
> 
> Reviewed-by: Timothy Arceri 

Thanks!


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

Re: [Mesa-dev] [PATCH 00/16] Various Vulkan/SPIR-V fixes (mostly SPIR-V)

[Jason Ekstrand]

Please ignore the N/9 patches.  They've already been merged but somehow got
sent by git-send-email.

On Thu, Jul 21, 2016 at 9:21 PM, Jason Ekstrand 
wrote:

> I pulled the latest version of the Vulkan CTS and gave it a run.  One of
> the major aditions was a pile of tests for different texturing operations.
> This demonstrated that our texturing support was, well, sub-par.  These
> patches get it most of the way fixed up.  As a nice side-benifit, it also
> fixes 5 piglit tests on GL.
>
> Jason Ekstrand (16):
>   spirv/nir: Fix some texture opcode asserts
>   spirv/nir: Add support for shadow samplers that return vec4
>   spirv/nir: Properly handle gather components
>   anv/pipeline: Set binding_table.gather_texture_start
>   nir: Add a helper for determining the type of a texture source
>   nir/lower_tex: Add some helpers for working with tex sources
>   nir/lower_tex: Add support for lowering coordinate offsets
>   i965/nir: Enable NIR lowering of txf and rect offsets
>   i965: Get rid of the do_lower_unnormalized_offsets pass
>   spirv/nir: Don't increment coord_components for array lod queries
>   anv/image: Assert that the image format is actually supported
>   spirv/nir/: Move opcode selection higher up in handle_texture
>   spirv/nir: Refactor type handling in handle_texture
>   nir/spirv: Refactor coordinate handling in handle_texture
>   spirv/nir: Handle texture projectors
>   spirv/nir: Add support for ImageQuerySamples
>
>  src/compiler/nir/nir.h |  54 ++
>  src/compiler/nir/nir_lower_tex.c   |  98 +--
>  src/compiler/spirv/spirv_to_nir.c  | 189
> -
>  src/intel/vulkan/anv_image.c   |   7 +-
>  src/intel/vulkan/anv_pipeline.c|   1 +
>  src/mesa/drivers/dri/i965/Makefile.sources |   1 -
>  src/mesa/drivers/dri/i965/brw_context.h|   1 -
>  src/mesa/drivers/dri/i965/brw_link.cpp |   1 -
>  .../dri/i965/brw_lower_unnormalized_offset.cpp | 106 
>  src/mesa/drivers/dri/i965/brw_nir.c|   2 +
>  10 files changed, 255 insertions(+), 205 deletions(-)
>  delete mode 100644
> src/mesa/drivers/dri/i965/brw_lower_unnormalized_offset.cpp
>
> --
> 2.5.0.400.gff86faf
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 02/16] spirv/nir: Add support for shadow samplers that return vec4

[Jason Ekstrand]

While SPIR-V technically doesn't support "old style" shadow, the
shadow-compare gather instruction does return a vec4 so we need to be able
to set the old_style_shadow bit in NIR.

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/spirv/spirv_to_nir.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 22cd2e7..c32dfaa 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1479,7 +1479,8 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
instr->sampler_dim = glsl_get_sampler_dim(image_type);
instr->is_array = glsl_sampler_type_is_array(image_type);
instr->is_shadow = glsl_sampler_type_is_shadow(image_type);
-   instr->is_new_style_shadow = instr->is_shadow;
+   instr->is_new_style_shadow = instr->is_shadow &&
+glsl_get_components(ret_type->type) == 1;
 
if (has_coord) {
   switch (instr->sampler_dim) {
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 15/16] spirv/nir: Handle texture projectors

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/spirv/spirv_to_nir.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 6ebf951..20ff472 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1442,6 +1442,21 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
   break;
}
 
+   switch (opcode) {
+   case SpvOpImageSampleProjImplicitLod:
+   case SpvOpImageSampleProjExplicitLod:
+   case SpvOpImageSampleProjDrefImplicitLod:
+   case SpvOpImageSampleProjDrefExplicitLod:
+  /* These have the projetor as the last coordinate component */
+  p->src = nir_src_for_ssa(nir_channel(>nb, coord, coord_components));
+  p->src_type = nir_tex_src_projector;
+  p++;
+  break;
+
+   default:
+  break;
+   }
+
unsigned gather_component = 0;
switch (opcode) {
case SpvOpImageSampleDrefImplicitLod:
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 16/16] spirv/nir: Add support for ImageQuerySamples

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/spirv/spirv_to_nir.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 20ff472..4d74e88 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1383,6 +1383,9 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
   break;
 
case SpvOpImageQuerySamples:
+  texop = nir_texop_texture_samples;
+  break;
+
default:
   unreachable("Unhandled opcode");
}
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 3/9] anv/pipeline: Refactor specialization constant handling a bit

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Jordan Justen 
---
 src/intel/vulkan/anv_pipeline.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 789bc1a..372feeb 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -123,13 +123,12 @@ anv_shader_compile_to_nir(struct anv_device *device,
  num_spec_entries = spec_info->mapEntryCount;
  spec_entries = malloc(num_spec_entries * sizeof(*spec_entries));
  for (uint32_t i = 0; i < num_spec_entries; i++) {
-const uint32_t *data =
-   spec_info->pData + spec_info->pMapEntries[i].offset;
-assert((const void *)(data + 1) <=
-   spec_info->pData + spec_info->dataSize);
+VkSpecializationMapEntry entry = spec_info->pMapEntries[i];
+const void *data = spec_info->pData + entry.offset;
+assert(data + entry.size <= spec_info->pData + 
spec_info->dataSize);
 
 spec_entries[i].id = spec_info->pMapEntries[i].constantID;
-spec_entries[i].data = *data;
+spec_entries[i].data = *(const uint32_t *)data;
  }
   }
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 7/9] anv/pipeline: Silently pass tests if depth or stencil is missing

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Ian Romanick 
---
 src/intel/vulkan/gen7_pipeline.c  | 12 ++--
 src/intel/vulkan/gen8_pipeline.c  | 12 ++--
 src/intel/vulkan/genX_pipeline_util.h | 30 +-
 3 files changed, 49 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 243b18b..0d2d086 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -155,6 +155,8 @@ genX(graphics_pipeline_create)(
 VkPipeline* pPipeline)
 {
ANV_FROM_HANDLE(anv_device, device, _device);
+   ANV_FROM_HANDLE(anv_render_pass, pass, pCreateInfo->renderPass);
+   struct anv_subpass *subpass = >subpasses[pCreateInfo->subpass];
struct anv_pipeline *pipeline;
VkResult result;
 
@@ -178,7 +180,7 @@ genX(graphics_pipeline_create)(
assert(pCreateInfo->pRasterizationState);
gen7_emit_rs_state(pipeline, pCreateInfo->pRasterizationState, extra);
 
-   emit_ds_state(pipeline, pCreateInfo->pDepthStencilState);
+   emit_ds_state(pipeline, pCreateInfo->pDepthStencilState, pass, subpass);
 
gen7_emit_cb_state(pipeline, pCreateInfo->pColorBlendState,
 pCreateInfo->pMultisampleState);
@@ -369,10 +371,16 @@ genX(graphics_pipeline_create)(
  wm.PixelShaderUsesSourceW  = wm_prog_data->uses_src_w;
  wm.PixelShaderUsesInputCoverageMask= 
wm_prog_data->uses_sample_mask;
 
+ /* TODO: We could probably do something a bit more intellegent here.
+  * However, CTS tests expect that if earliy fragment tests are not
+  * performed, the shader *will* be executed for every fragment.  In
+  * order to work around this we would have to check whether or not
+  * the shader has side-effects before we can set the mode to NORMAL.
+  */
  if (wm_prog_data->early_fragment_tests) {
 wm.EarlyDepthStencilControl = EDSC_PREPS;
  } else {
-wm.EarlyDepthStencilControl = EDSC_NORMAL;
+wm.EarlyDepthStencilControl = EDSC_PSEXEC;
  }
 
  wm.BarycentricInterpolationMode= 
wm_prog_data->barycentric_interp_modes;
diff --git a/src/intel/vulkan/gen8_pipeline.c b/src/intel/vulkan/gen8_pipeline.c
index 7cc7c51..4b477ee 100644
--- a/src/intel/vulkan/gen8_pipeline.c
+++ b/src/intel/vulkan/gen8_pipeline.c
@@ -268,6 +268,8 @@ genX(graphics_pipeline_create)(
 VkPipeline* pPipeline)
 {
ANV_FROM_HANDLE(anv_device, device, _device);
+   ANV_FROM_HANDLE(anv_render_pass, pass, pCreateInfo->renderPass);
+   struct anv_subpass *subpass = >subpasses[pCreateInfo->subpass];
struct anv_pipeline *pipeline;
VkResult result;
uint32_t offset, length;
@@ -294,7 +296,7 @@ genX(graphics_pipeline_create)(
emit_rs_state(pipeline, pCreateInfo->pRasterizationState,
  pCreateInfo->pMultisampleState, extra);
emit_ms_state(pipeline, pCreateInfo->pMultisampleState);
-   emit_ds_state(pipeline, pCreateInfo->pDepthStencilState);
+   emit_ds_state(pipeline, pCreateInfo->pDepthStencilState, pass, subpass);
emit_cb_state(pipeline, pCreateInfo->pColorBlendState,
pCreateInfo->pMultisampleState);
 
@@ -330,10 +332,16 @@ genX(graphics_pipeline_create)(
   wm.ForceThreadDispatchEnable   = NORMAL;
   wm.PointRasterizationRule  = RASTRULE_UPPER_RIGHT;
 
+  /* TODO: We could probably do something a bit more intellegent here.
+   * However, CTS tests expect that if earliy fragment tests are not
+   * performed, the shader *will* be executed for every fragment.  In
+   * order to work around this we would have to check whether or not
+   * the shader has side-effects before we can set the mode to NORMAL.
+   */
   if (wm_prog_data && wm_prog_data->early_fragment_tests) {
  wm.EarlyDepthStencilControl = PREPS;
   } else {
- wm.EarlyDepthStencilControl = NORMAL;
+ wm.EarlyDepthStencilControl = PSEXEC;
   }
 
   wm.BarycentricInterpolationMode = pipeline->ps_ksp0 == NO_KERNEL ?
diff --git a/src/intel/vulkan/genX_pipeline_util.h 
b/src/intel/vulkan/genX_pipeline_util.h
index fe24048..669b456 100644
--- a/src/intel/vulkan/genX_pipeline_util.h
+++ b/src/intel/vulkan/genX_pipeline_util.h
@@ -21,6 +21,8 @@
  * IN THE SOFTWARE.
  */
 
+#include "vk_format_info.h"
+
 static uint32_t
 vertex_element_comp_control(enum isl_format format, unsigned comp)
 {
@@ -428,7 +430,9 @@ static const uint32_t vk_to_gen_stencil_op[] = {
 
 static void
 emit_ds_state(struct anv_pipeline *pipeline,
-  const VkPipelineDepthStencilStateCreateInfo *info)
+  const VkPipelineDepthStencilStateCreateInfo *info,
+  const 

[Mesa-dev] [PATCH 12/16] spirv/nir/: Move opcode selection higher up in handle_texture

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/spirv/spirv_to_nir.c | 96 +++
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 6654f5f..a0aeadf 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1336,6 +1336,54 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
   image_type = sampled.sampler->var->var->interface_type;
}
 
+   /* Figure out the base texture operation */
+   nir_texop texop;
+   switch (opcode) {
+   case SpvOpImageSampleImplicitLod:
+   case SpvOpImageSampleDrefImplicitLod:
+   case SpvOpImageSampleProjImplicitLod:
+   case SpvOpImageSampleProjDrefImplicitLod:
+  texop = nir_texop_tex;
+  break;
+
+   case SpvOpImageSampleExplicitLod:
+   case SpvOpImageSampleDrefExplicitLod:
+   case SpvOpImageSampleProjExplicitLod:
+   case SpvOpImageSampleProjDrefExplicitLod:
+  texop = nir_texop_txl;
+  break;
+
+   case SpvOpImageFetch:
+  if (glsl_get_sampler_dim(image_type) == GLSL_SAMPLER_DIM_MS) {
+ texop = nir_texop_txf_ms;
+  } else {
+ texop = nir_texop_txf;
+  }
+  break;
+
+   case SpvOpImageGather:
+   case SpvOpImageDrefGather:
+  texop = nir_texop_tg4;
+  break;
+
+   case SpvOpImageQuerySizeLod:
+   case SpvOpImageQuerySize:
+  texop = nir_texop_txs;
+  break;
+
+   case SpvOpImageQueryLod:
+  texop = nir_texop_lod;
+  break;
+
+   case SpvOpImageQueryLevels:
+  texop = nir_texop_query_levels;
+  break;
+
+   case SpvOpImageQuerySamples:
+   default:
+  unreachable("Unhandled opcode");
+   }
+
nir_tex_src srcs[8]; /* 8 should be enough */
nir_tex_src *p = srcs;
 
@@ -1393,54 +1441,6 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
if (opcode == SpvOpImageQuerySizeLod)
   (*p++) = vtn_tex_src(b, w[idx++], nir_tex_src_lod);
 
-   /* Figure out the base texture operation */
-   nir_texop texop;
-   switch (opcode) {
-   case SpvOpImageSampleImplicitLod:
-   case SpvOpImageSampleDrefImplicitLod:
-   case SpvOpImageSampleProjImplicitLod:
-   case SpvOpImageSampleProjDrefImplicitLod:
-  texop = nir_texop_tex;
-  break;
-
-   case SpvOpImageSampleExplicitLod:
-   case SpvOpImageSampleDrefExplicitLod:
-   case SpvOpImageSampleProjExplicitLod:
-   case SpvOpImageSampleProjDrefExplicitLod:
-  texop = nir_texop_txl;
-  break;
-
-   case SpvOpImageFetch:
-  if (glsl_get_sampler_dim(image_type) == GLSL_SAMPLER_DIM_MS) {
- texop = nir_texop_txf_ms;
-  } else {
- texop = nir_texop_txf;
-  }
-  break;
-
-   case SpvOpImageGather:
-   case SpvOpImageDrefGather:
-  texop = nir_texop_tg4;
-  break;
-
-   case SpvOpImageQuerySizeLod:
-   case SpvOpImageQuerySize:
-  texop = nir_texop_txs;
-  break;
-
-   case SpvOpImageQueryLod:
-  texop = nir_texop_lod;
-  break;
-
-   case SpvOpImageQueryLevels:
-  texop = nir_texop_query_levels;
-  break;
-
-   case SpvOpImageQuerySamples:
-   default:
-  unreachable("Unhandled opcode");
-   }
-
/* Now we need to handle some number of optional arguments */
if (idx < count) {
   uint32_t operands = w[idx++];
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 5/9] genxml/gen6,7,75: s/BackFace/Backface

[Jason Ekstrand]

This is more consistent with gen8+

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Jordan Justen 
---
 src/intel/genxml/gen6.xml  | 4 ++--
 src/intel/genxml/gen7.xml  | 4 ++--
 src/intel/genxml/gen75.xml | 4 ++--
 src/intel/vulkan/gen7_cmd_buffer.c | 2 +-
 src/intel/vulkan/gen7_pipeline.c   | 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
index afaea7f..7525fce 100644
--- a/src/intel/genxml/gen6.xml
+++ b/src/intel/genxml/gen6.xml
@@ -176,7 +176,7 @@
 
   
 
-
+
 
 
   
@@ -216,7 +216,7 @@
 
 
 
-
+
   
   
   
diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index 7417f55..6f3e8cc 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -199,7 +199,7 @@
 
   
 
-
+
 
 
   
@@ -239,7 +239,7 @@
 
 
 
-
+
   
   
   
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 709904f..ac1b6e4 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -209,7 +209,7 @@
 
   
 
-
+
 
 
   
@@ -249,7 +249,7 @@
 
 
 
-
+
   
   
   
diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
b/src/intel/vulkan/gen7_cmd_buffer.c
index 331275e..714d14a 100644
--- a/src/intel/vulkan/gen7_cmd_buffer.c
+++ b/src/intel/vulkan/gen7_cmd_buffer.c
@@ -357,7 +357,7 @@ genX(cmd_buffer_flush_dynamic_state)(struct anv_cmd_buffer 
*cmd_buffer)
  .BlendConstantColorBlue = 
cmd_buffer->state.dynamic.blend_constants[2],
  .BlendConstantColorAlpha = 
cmd_buffer->state.dynamic.blend_constants[3],
  .StencilReferenceValue = d->stencil_reference.front & 0xff,
- .BackFaceStencilReferenceValue = d->stencil_reference.back & 0xff,
+ .BackfaceStencilReferenceValue = d->stencil_reference.back & 0xff,
   };
   GENX(COLOR_CALC_STATE_pack)(NULL, cc_state.map, );
   if (!cmd_buffer->device->info.has_llc)
diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 2cfd7bf..14614ac 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -104,7 +104,7 @@ gen7_emit_ds_state(struct anv_pipeline *pipeline,
   .BackfaceStencilFailOp = vk_to_gen_stencil_op[info->back.failOp],
   .BackfaceStencilPassDepthPassOp = 
vk_to_gen_stencil_op[info->back.passOp],
   .BackfaceStencilPassDepthFailOp = 
vk_to_gen_stencil_op[info->back.depthFailOp],
-  .BackFaceStencilTestFunction = 
vk_to_gen_compare_op[info->back.compareOp],
+  .BackfaceStencilTestFunction = 
vk_to_gen_compare_op[info->back.compareOp],
};
 
GENX(DEPTH_STENCIL_STATE_pack)(NULL, >gen7.depth_stencil_state, 
);
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 09/16] i965: Get rid of the do_lower_unnormalized_offsets pass

[Jason Ekstrand]

We can do this in NIR now.  No need to keep a GLSL pass lying around for
it.

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/mesa/drivers/dri/i965/Makefile.sources |   1 -
 src/mesa/drivers/dri/i965/brw_context.h|   1 -
 src/mesa/drivers/dri/i965/brw_link.cpp |   1 -
 .../dri/i965/brw_lower_unnormalized_offset.cpp | 106 -
 4 files changed, 109 deletions(-)
 delete mode 100644 src/mesa/drivers/dri/i965/brw_lower_unnormalized_offset.cpp

diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index ca7591f..df6b5dd 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -133,7 +133,6 @@ i965_FILES = \
brw_gs_surface_state.c \
brw_link.cpp \
brw_lower_texture_gradients.cpp \
-   brw_lower_unnormalized_offset.cpp \
brw_meta_util.c \
brw_meta_util.h \
brw_misc_state.c \
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index bfad868..e0f7000 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1795,7 +1795,6 @@ brw_program_reloc(struct brw_context *brw, uint32_t 
state_offset,
 bool brw_do_cubemap_normalize(struct exec_list *instructions);
 bool brw_lower_texture_gradients(struct brw_context *brw,
  struct exec_list *instructions);
-bool brw_do_lower_unnormalized_offset(struct exec_list *instructions);
 
 extern const char * const conditional_modifier[16];
 extern const char *const pred_ctrl_align16[16];
diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
b/src/mesa/drivers/dri/i965/brw_link.cpp
index a77df50..1ad2369 100644
--- a/src/mesa/drivers/dri/i965/brw_link.cpp
+++ b/src/mesa/drivers/dri/i965/brw_link.cpp
@@ -132,7 +132,6 @@ process_glsl_ir(gl_shader_stage stage,
do_vec_index_to_cond_assign(shader->ir);
lower_vector_insert(shader->ir, true);
lower_offset_arrays(shader->ir);
-   brw_do_lower_unnormalized_offset(shader->ir);
lower_noise(shader->ir);
lower_quadop_vector(shader->ir, false);
 
diff --git a/src/mesa/drivers/dri/i965/brw_lower_unnormalized_offset.cpp 
b/src/mesa/drivers/dri/i965/brw_lower_unnormalized_offset.cpp
deleted file mode 100644
index f5d7bae..000
--- a/src/mesa/drivers/dri/i965/brw_lower_unnormalized_offset.cpp
+++ /dev/null
@@ -1,106 +0,0 @@
-/*
- * Copyright © 2013 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.
- */
-
-/**
- * \file brw_lower_unnormalized_offset.cpp
- *
- * IR lower pass to convert a texture offset into an adjusted coordinate,
- * for use with unnormalized coordinates. At least the gather4* messages
- * on Ivybridge and Haswell make a mess with nonzero offsets.
- *
- * \author Chris Forbes 
- */
-
-#include "compiler/glsl_types.h"
-#include "compiler/glsl/ir.h"
-#include "compiler/glsl/ir_builder.h"
-
-using namespace ir_builder;
-
-class brw_lower_unnormalized_offset_visitor : public ir_hierarchical_visitor {
-public:
-   brw_lower_unnormalized_offset_visitor()
-   {
-  progress = false;
-   }
-
-   ir_visitor_status visit_leave(ir_texture *ir);
-
-   bool progress;
-};
-
-ir_visitor_status
-brw_lower_unnormalized_offset_visitor::visit_leave(ir_texture *ir)
-{
-   if (!ir->offset)
-  return visit_continue;
-
-   if (ir->op == ir_tg4 || ir->op == ir_tex) {
-  if (ir->sampler->type->sampler_dimensionality != GLSL_SAMPLER_DIM_RECT)
- return visit_continue;
-   }
-   else if (ir->op != ir_txf) {
-  return visit_continue;
-   }
-
-   void *mem_ctx = ralloc_parent(ir);
-
-   if (ir->op == ir_txf) {
-  /* It appears that the ld instruction used for txf does its
-   * address bounds check before adding in the offset.  To work
-   

[Mesa-dev] [PATCH 6/9] anv/pipeline: Unify gen7/8 emit_ds_state

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Jordan Justen 
---
 src/intel/vulkan/gen7_pipeline.c  | 37 +-
 src/intel/vulkan/gen8_pipeline.c  | 49 -
 src/intel/vulkan/genX_pipeline_util.h | 59 +++
 3 files changed, 60 insertions(+), 85 deletions(-)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 14614ac..243b18b 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -76,41 +76,6 @@ gen7_emit_rs_state(struct anv_pipeline *pipeline,
 }
 
 static void
-gen7_emit_ds_state(struct anv_pipeline *pipeline,
-   const VkPipelineDepthStencilStateCreateInfo *info)
-{
-   if (info == NULL) {
-  /* We're going to OR this together with the dynamic state.  We need
-   * to make sure it's initialized to something useful.
-   */
-  memset(pipeline->gen7.depth_stencil_state, 0,
- sizeof(pipeline->gen7.depth_stencil_state));
-  return;
-   }
-
-   struct GENX(DEPTH_STENCIL_STATE) state = {
-  .DepthTestEnable = info->depthTestEnable,
-  .DepthBufferWriteEnable = info->depthWriteEnable,
-  .DepthTestFunction = vk_to_gen_compare_op[info->depthCompareOp],
-  .DoubleSidedStencilEnable = true,
-
-  .StencilTestEnable = info->stencilTestEnable,
-  .StencilBufferWriteEnable = info->stencilTestEnable,
-  .StencilFailOp = vk_to_gen_stencil_op[info->front.failOp],
-  .StencilPassDepthPassOp = vk_to_gen_stencil_op[info->front.passOp],
-  .StencilPassDepthFailOp = vk_to_gen_stencil_op[info->front.depthFailOp],
-  .StencilTestFunction = vk_to_gen_compare_op[info->front.compareOp],
-
-  .BackfaceStencilFailOp = vk_to_gen_stencil_op[info->back.failOp],
-  .BackfaceStencilPassDepthPassOp = 
vk_to_gen_stencil_op[info->back.passOp],
-  .BackfaceStencilPassDepthFailOp = 
vk_to_gen_stencil_op[info->back.depthFailOp],
-  .BackfaceStencilTestFunction = 
vk_to_gen_compare_op[info->back.compareOp],
-   };
-
-   GENX(DEPTH_STENCIL_STATE_pack)(NULL, >gen7.depth_stencil_state, 
);
-}
-
-static void
 gen7_emit_cb_state(struct anv_pipeline *pipeline,
const VkPipelineColorBlendStateCreateInfo *info,
const VkPipelineMultisampleStateCreateInfo *ms_info)
@@ -213,7 +178,7 @@ genX(graphics_pipeline_create)(
assert(pCreateInfo->pRasterizationState);
gen7_emit_rs_state(pipeline, pCreateInfo->pRasterizationState, extra);
 
-   gen7_emit_ds_state(pipeline, pCreateInfo->pDepthStencilState);
+   emit_ds_state(pipeline, pCreateInfo->pDepthStencilState);
 
gen7_emit_cb_state(pipeline, pCreateInfo->pColorBlendState,
 pCreateInfo->pMultisampleState);
diff --git a/src/intel/vulkan/gen8_pipeline.c b/src/intel/vulkan/gen8_pipeline.c
index 48774a5..7cc7c51 100644
--- a/src/intel/vulkan/gen8_pipeline.c
+++ b/src/intel/vulkan/gen8_pipeline.c
@@ -216,55 +216,6 @@ emit_cb_state(struct anv_pipeline *pipeline,
 }
 
 static void
-emit_ds_state(struct anv_pipeline *pipeline,
-  const VkPipelineDepthStencilStateCreateInfo *info)
-{
-   uint32_t *dw = GEN_GEN == 8 ?
-  pipeline->gen8.wm_depth_stencil : pipeline->gen9.wm_depth_stencil;
-
-   if (info == NULL) {
-  /* We're going to OR this together with the dynamic state.  We need
-   * to make sure it's initialized to something useful.
-   */
-  memset(pipeline->gen8.wm_depth_stencil, 0,
- sizeof(pipeline->gen8.wm_depth_stencil));
-  memset(pipeline->gen9.wm_depth_stencil, 0,
- sizeof(pipeline->gen9.wm_depth_stencil));
-  return;
-   }
-
-   /* VkBool32 depthBoundsTestEnable; // optional (depth_bounds_test) */
-
-   struct GENX(3DSTATE_WM_DEPTH_STENCIL) wm_depth_stencil = {
-  .DepthTestEnable = info->depthTestEnable,
-  .DepthBufferWriteEnable = info->depthWriteEnable,
-  .DepthTestFunction = vk_to_gen_compare_op[info->depthCompareOp],
-  .DoubleSidedStencilEnable = true,
-
-  .StencilTestEnable = info->stencilTestEnable,
-  .StencilBufferWriteEnable = info->stencilTestEnable,
-  .StencilFailOp = vk_to_gen_stencil_op[info->front.failOp],
-  .StencilPassDepthPassOp = vk_to_gen_stencil_op[info->front.passOp],
-  .StencilPassDepthFailOp = vk_to_gen_stencil_op[info->front.depthFailOp],
-  .StencilTestFunction = vk_to_gen_compare_op[info->front.compareOp],
-  .BackfaceStencilFailOp = vk_to_gen_stencil_op[info->back.failOp],
-  .BackfaceStencilPassDepthPassOp = 
vk_to_gen_stencil_op[info->back.passOp],
-  .BackfaceStencilPassDepthFailOp 
=vk_to_gen_stencil_op[info->back.depthFailOp],
-  .BackfaceStencilTestFunction = 
vk_to_gen_compare_op[info->back.compareOp],
-   };
-
-   /* From the Broadwell PRM:
-*
-*"If Depth_Test_Enable = 1 AND Depth_Test_func = EQUAL, the
-*

[Mesa-dev] [PATCH 4/9] anv/pipeline: Add support for early depth stencil

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Jordan Justen 
---
 src/intel/vulkan/gen7_pipeline.c | 8 +++-
 src/intel/vulkan/gen8_pipeline.c | 7 ++-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 285b191..2cfd7bf 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -398,12 +398,18 @@ genX(graphics_pipeline_create)(
  wm.ThreadDispatchEnable= true;
  wm.LineEndCapAntialiasingRegionWidth   = 0; /* 0.5 pixels */
  wm.LineAntialiasingRegionWidth = 1; /* 1.0 pixels */
- wm.EarlyDepthStencilControl= EDSC_NORMAL;
  wm.PointRasterizationRule  = RASTRULE_UPPER_RIGHT;
  wm.PixelShaderComputedDepthMode= 
wm_prog_data->computed_depth_mode;
  wm.PixelShaderUsesSourceDepth  = wm_prog_data->uses_src_depth;
  wm.PixelShaderUsesSourceW  = wm_prog_data->uses_src_w;
  wm.PixelShaderUsesInputCoverageMask= 
wm_prog_data->uses_sample_mask;
+
+ if (wm_prog_data->early_fragment_tests) {
+wm.EarlyDepthStencilControl = EDSC_PREPS;
+ } else {
+wm.EarlyDepthStencilControl = EDSC_NORMAL;
+ }
+
  wm.BarycentricInterpolationMode= 
wm_prog_data->barycentric_interp_modes;
   }
}
diff --git a/src/intel/vulkan/gen8_pipeline.c b/src/intel/vulkan/gen8_pipeline.c
index d966694..48774a5 100644
--- a/src/intel/vulkan/gen8_pipeline.c
+++ b/src/intel/vulkan/gen8_pipeline.c
@@ -376,10 +376,15 @@ genX(graphics_pipeline_create)(
   wm.StatisticsEnable= true;
   wm.LineEndCapAntialiasingRegionWidth   = _05pixels;
   wm.LineAntialiasingRegionWidth = _10pixels;
-  wm.EarlyDepthStencilControl= NORMAL;
   wm.ForceThreadDispatchEnable   = NORMAL;
   wm.PointRasterizationRule  = RASTRULE_UPPER_RIGHT;
 
+  if (wm_prog_data && wm_prog_data->early_fragment_tests) {
+ wm.EarlyDepthStencilControl = PREPS;
+  } else {
+ wm.EarlyDepthStencilControl = NORMAL;
+  }
+
   wm.BarycentricInterpolationMode = pipeline->ps_ksp0 == NO_KERNEL ?
  0 : wm_prog_data->barycentric_interp_modes;
}
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 08/16] i965/nir: Enable NIR lowering of txf and rect offsets

[Jason Ekstrand]

This fixes the following piglit tests on gen6+:

tex-miplevel-selection textureProjGradOffset 2DRect
tex-miplevel-selection textureGradOffset 2DRect
tex-miplevel-selection textureGradOffset 2DRectShadow
tex-miplevel-selection textureProjGradOffset 2DRect_ProjVec4
tex-miplevel-selection textureProjGradOffset 2DRectShadow

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/mesa/drivers/dri/i965/brw_nir.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
b/src/mesa/drivers/dri/i965/brw_nir.c
index fe76531..bf8fe8c 100644
--- a/src/mesa/drivers/dri/i965/brw_nir.c
+++ b/src/mesa/drivers/dri/i965/brw_nir.c
@@ -429,6 +429,8 @@ brw_preprocess_nir(const struct brw_compiler *compiler, 
nir_shader *nir)
 
static const nir_lower_tex_options tex_options = {
   .lower_txp = ~0,
+  .lower_txf_offset = true,
+  .lower_rect_offset = true,
};
 
OPT(nir_lower_tex, _options);
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 14/16] nir/spirv: Refactor coordinate handling in handle_texture

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/spirv/spirv_to_nir.c | 57 +++
 1 file changed, 28 insertions(+), 29 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 284a2c8..6ebf951 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1392,7 +1392,8 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
 
unsigned idx = 4;
 
-   bool has_coord = false;
+   struct nir_ssa_def *coord;
+   unsigned coord_components;
switch (opcode) {
case SpvOpImageSampleImplicitLod:
case SpvOpImageSampleExplicitLod:
@@ -1407,15 +1408,37 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
case SpvOpImageDrefGather:
case SpvOpImageQueryLod: {
   /* All these types have the coordinate as their first real argument */
-  struct vtn_ssa_value *coord = vtn_ssa_value(b, w[idx++]);
-  has_coord = true;
-  p->src = nir_src_for_ssa(coord->def);
+  switch (sampler_dim) {
+  case GLSL_SAMPLER_DIM_1D:
+  case GLSL_SAMPLER_DIM_BUF:
+ coord_components = 1;
+ break;
+  case GLSL_SAMPLER_DIM_2D:
+  case GLSL_SAMPLER_DIM_RECT:
+  case GLSL_SAMPLER_DIM_MS:
+ coord_components = 2;
+ break;
+  case GLSL_SAMPLER_DIM_3D:
+  case GLSL_SAMPLER_DIM_CUBE:
+ coord_components = 3;
+ break;
+  default:
+ assert("Invalid sampler type");
+  }
+
+  if (is_array && texop != nir_texop_lod)
+ coord_components++;
+
+  coord = vtn_ssa_value(b, w[idx++])->def;
+  p->src = nir_src_for_ssa(coord);
   p->src_type = nir_tex_src_coord;
   p++;
   break;
}
 
default:
+  coord = NULL;
+  coord_components = 0;
   break;
}
 
@@ -1488,6 +1511,7 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
 
memcpy(instr->src, srcs, instr->num_srcs * sizeof(*instr->src));
 
+   instr->coord_components = coord_components;
instr->sampler_dim = sampler_dim;
instr->is_array = is_array;
instr->is_shadow = is_shadow;
@@ -1495,31 +1519,6 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
   is_shadow && glsl_get_components(ret_type->type) == 1;
instr->component = gather_component;
 
-   if (has_coord) {
-  switch (instr->sampler_dim) {
-  case GLSL_SAMPLER_DIM_1D:
-  case GLSL_SAMPLER_DIM_BUF:
- instr->coord_components = 1;
- break;
-  case GLSL_SAMPLER_DIM_2D:
-  case GLSL_SAMPLER_DIM_RECT:
-  case GLSL_SAMPLER_DIM_MS:
- instr->coord_components = 2;
- break;
-  case GLSL_SAMPLER_DIM_3D:
-  case GLSL_SAMPLER_DIM_CUBE:
- instr->coord_components = 3;
- break;
-  default:
- assert("Invalid sampler type");
-  }
-
-  if (instr->is_array && instr->op != nir_texop_lod)
- instr->coord_components++;
-   } else {
-  instr->coord_components = 0;
-   }
-
switch (glsl_get_sampler_result_type(image_type)) {
case GLSL_TYPE_FLOAT:   instr->dest_type = nir_type_float; break;
case GLSL_TYPE_INT: instr->dest_type = nir_type_int;   break;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 04/16] anv/pipeline: Set binding_table.gather_texture_start

[Jason Ekstrand]

This should get texture gather working on gen8+ and mostly working on gen7.

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/intel/vulkan/anv_pipeline.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 3723423..57e1bdd 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -387,6 +387,7 @@ anv_fill_binding_table(struct brw_stage_prog_data 
*prog_data, unsigned bias)
 {
prog_data->binding_table.size_bytes = 0;
prog_data->binding_table.texture_start = bias;
+   prog_data->binding_table.gather_texture_start = bias;
prog_data->binding_table.ubo_start = bias;
prog_data->binding_table.ssbo_start = bias;
prog_data->binding_table.image_start = bias;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 11/16] anv/image: Assert that the image format is actually supported

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/intel/vulkan/anv_image.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index e467e87..dff51bc 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -137,10 +137,13 @@ make_surface(const struct anv_device *dev,
image->extent = anv_sanitize_image_extent(vk_info->imageType,
  vk_info->extent);
 
+   enum isl_format format = anv_get_isl_format(>info, vk_info->format,
+   aspect, vk_info->tiling);
+   assert(format != ISL_FORMAT_UNSUPPORTED);
+
ok = isl_surf_init(>isl_dev, _surf->isl,
   .dim = vk_to_isl_surf_dim[vk_info->imageType],
-  .format = anv_get_isl_format(>info, vk_info->format,
-   aspect, vk_info->tiling),
+  .format = format,
   .width = image->extent.width,
   .height = image->extent.height,
   .depth = image->extent.depth,
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 03/16] spirv/nir: Properly handle gather components

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/spirv/spirv_to_nir.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index c32dfaa..b1bb48b 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1368,14 +1368,23 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
   break;
}
 
-   /* These all have an explicit depth value as their next source */
+   unsigned gather_component = 0;
switch (opcode) {
case SpvOpImageSampleDrefImplicitLod:
case SpvOpImageSampleDrefExplicitLod:
case SpvOpImageSampleProjDrefImplicitLod:
case SpvOpImageSampleProjDrefExplicitLod:
+   case SpvOpImageDrefGather:
+  /* These all have an explicit depth value as their next source */
   (*p++) = vtn_tex_src(b, w[idx++], nir_tex_src_comparitor);
   break;
+
+   case SpvOpImageGather:
+  /* This has a component as its next source */
+  gather_component =
+ vtn_value(b, w[idx++], vtn_value_type_constant)->constant->value.u[0];
+  break;
+
default:
   break;
}
@@ -1481,6 +1490,7 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
instr->is_shadow = glsl_sampler_type_is_shadow(image_type);
instr->is_new_style_shadow = instr->is_shadow &&
 glsl_get_components(ret_type->type) == 1;
+   instr->component = gather_component;
 
if (has_coord) {
   switch (instr->sampler_dim) {
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 2/9] nir/lower_indirect_derefs: Use the direct array deref for recursion

[Jason Ekstrand]

This fixes about 100 of the new Vulkan CTS tests.

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Connor Abbott 
Cc: Ian Romanick 
Cc: Kenneth Graunke 
---
 src/compiler/nir/nir_lower_indirect_derefs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_lower_indirect_derefs.c 
b/src/compiler/nir/nir_lower_indirect_derefs.c
index 694a6e0..1bf4bf6 100644
--- a/src/compiler/nir/nir_lower_indirect_derefs.c
+++ b/src/compiler/nir/nir_lower_indirect_derefs.c
@@ -50,7 +50,7 @@ emit_indirect_load_store(nir_builder *b, nir_intrinsic_instr 
*orig_instr,
   direct.indirect = NIR_SRC_INIT;
 
   arr_parent->child = 
-  emit_load_store(b, orig_instr, deref, >deref, dest, src);
+  emit_load_store(b, orig_instr, deref, , dest, src);
   arr_parent->child = >deref;
} else {
   int mid = start + (end - start) / 2;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 06/16] nir/lower_tex: Add some helpers for working with tex sources

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/nir/nir_lower_tex.c | 46 ++--
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c
index 195cb1d..0cf1071 100644
--- a/src/compiler/nir/nir_lower_tex.c
+++ b/src/compiler/nir/nir_lower_tex.c
@@ -38,16 +38,39 @@
 #include "nir.h"
 #include "nir_builder.h"
 
+static int
+tex_instr_find_src(nir_tex_instr *tex, nir_tex_src_type src)
+{
+   for (unsigned i = 0; i < tex->num_srcs; i++) {
+  if (tex->src[i].src_type == src)
+ return i;
+   }
+
+   return -1;
+}
+
+static void
+tex_instr_remove_src(nir_tex_instr *tex, unsigned src_idx)
+{
+   assert(src_idx < tex->num_srcs);
+
+   /* First rewrite the source to NIR_SRC_INIT */
+   nir_instr_rewrite_src(>instr, >src[src_idx].src, NIR_SRC_INIT);
+
+   /* Now, move all of the other sources down */
+   for (unsigned i = src_idx + 1; i < tex->num_srcs; i++) {
+  tex->src[i-1].src_type = tex->src[i].src_type;
+  nir_instr_move_src(>instr, >src[i-1].src, >src[i].src);
+   }
+   tex->num_srcs--;
+}
+
 static void
 project_src(nir_builder *b, nir_tex_instr *tex)
 {
/* Find the projector in the srcs list, if present. */
-   unsigned proj_index;
-   for (proj_index = 0; proj_index < tex->num_srcs; proj_index++) {
-  if (tex->src[proj_index].src_type == nir_tex_src_projector)
- break;
-   }
-   if (proj_index == tex->num_srcs)
+   int proj_index = tex_instr_find_src(tex, nir_tex_src_projector);
+   if (proj_index < 0)
   return;
 
b->cursor = nir_before_instr(>instr);
@@ -102,16 +125,7 @@ project_src(nir_builder *b, nir_tex_instr *tex)
 nir_src_for_ssa(projected));
}
 
-   /* Now move the later tex sources down the array so that the projector
-* disappears.
-*/
-   nir_instr_rewrite_src(>instr, >src[proj_index].src,
- NIR_SRC_INIT);
-   for (unsigned i = proj_index + 1; i < tex->num_srcs; i++) {
-  tex->src[i-1].src_type = tex->src[i].src_type;
-  nir_instr_move_src(>instr, >src[i-1].src, >src[i].src);
-   }
-   tex->num_srcs--;
+   tex_instr_remove_src(tex, proj_index);
 }
 
 static nir_ssa_def *
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 10/16] spirv/nir: Don't increment coord_components for array lod queries

[Jason Ekstrand]

For lod query instructions, we really don't care whether or not the sampler
is an array type because that doesn't factor into the LOD.

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/spirv/spirv_to_nir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index b1bb48b..6654f5f 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1511,7 +1511,7 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
  assert("Invalid sampler type");
   }
 
-  if (instr->is_array)
+  if (instr->is_array && instr->op != nir_texop_lod)
  instr->coord_components++;
} else {
   instr->coord_components = 0;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 13/16] spirv/nir: Refactor type handling in handle_texture

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/spirv/spirv_to_nir.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index a0aeadf..284a2c8 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1335,6 +1335,9 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
} else {
   image_type = sampled.sampler->var->var->interface_type;
}
+   const enum glsl_sampler_dim sampler_dim = glsl_get_sampler_dim(image_type);
+   const bool is_array = glsl_sampler_type_is_array(image_type);
+   const bool is_shadow = glsl_sampler_type_is_shadow(image_type);
 
/* Figure out the base texture operation */
nir_texop texop;
@@ -1485,11 +1488,11 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
 
memcpy(instr->src, srcs, instr->num_srcs * sizeof(*instr->src));
 
-   instr->sampler_dim = glsl_get_sampler_dim(image_type);
-   instr->is_array = glsl_sampler_type_is_array(image_type);
-   instr->is_shadow = glsl_sampler_type_is_shadow(image_type);
-   instr->is_new_style_shadow = instr->is_shadow &&
-glsl_get_components(ret_type->type) == 1;
+   instr->sampler_dim = sampler_dim;
+   instr->is_array = is_array;
+   instr->is_shadow = is_shadow;
+   instr->is_new_style_shadow =
+  is_shadow && glsl_get_components(ret_type->type) == 1;
instr->component = gather_component;
 
if (has_coord) {
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 9/9] nir/spirv: Handle the WorkgroupSize builtin decoration

[Jason Ekstrand]

This fixes the 7 dEQP-VK.pipeline.spec_constant.compute.local_size.* tests
in the latest dev version of the Vulkan CTS.

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Ian Romanick 
---
 src/compiler/spirv/spirv_to_nir.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index bb7aba4..cece645 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -932,6 +932,25 @@ get_specialization(struct vtn_builder *b, struct vtn_value 
*val,
 }
 
 static void
+handle_workgroup_size_decoration_cb(struct vtn_builder *b,
+struct vtn_value *val,
+int member,
+const struct vtn_decoration *dec,
+void *data)
+{
+   assert(member == -1);
+   if (dec->decoration != SpvDecorationBuiltIn ||
+   dec->literals[0] != SpvBuiltInWorkgroupSize)
+  return;
+
+   assert(val->const_type == glsl_vector_type(GLSL_TYPE_UINT, 3));
+
+   b->shader->info.cs.local_size[0] = val->constant->value.u[0];
+   b->shader->info.cs.local_size[1] = val->constant->value.u[1];
+   b->shader->info.cs.local_size[2] = val->constant->value.u[2];
+}
+
+static void
 vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
 const uint32_t *w, unsigned count)
 {
@@ -1151,6 +1170,9 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
default:
   unreachable("Unhandled opcode");
}
+
+   /* Now that we have the value, update the workgroup size if needed */
+   vtn_foreach_decoration(b, val, handle_workgroup_size_decoration_cb, NULL);
 }
 
 static void
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 07/16] nir/lower_tex: Add support for lowering coordinate offsets

[Jason Ekstrand]

On i965, we can't support coordinate offsets for texelFetch or rectangle
textures.  Previously, we were doing this with a GLSL pass but we need to
do it in NIR if we want those workarounds for SPIR-V.

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/nir/nir.h   | 10 
 src/compiler/nir/nir_lower_tex.c | 54 
 2 files changed, 64 insertions(+)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index d0f52b0..45f758c 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2405,6 +2405,16 @@ typedef struct nir_lower_tex_options {
unsigned lower_txp;
 
/**
+* If true, lower away nir_tex_src_offset for all texelfetch instructions.
+*/
+   bool lower_txf_offset;
+
+   /**
+* If true, lower away nir_tex_src_offset for all rect textures.
+*/
+   bool lower_rect_offset;
+
+   /**
 * If true, lower rect textures to 2D, using txs to fetch the
 * texture dimensions and dividing the texture coords by the
 * texture dims to normalize.
diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c
index 0cf1071..a1280e1 100644
--- a/src/compiler/nir/nir_lower_tex.c
+++ b/src/compiler/nir/nir_lower_tex.c
@@ -128,6 +128,54 @@ project_src(nir_builder *b, nir_tex_instr *tex)
tex_instr_remove_src(tex, proj_index);
 }
 
+static bool
+lower_offset(nir_builder *b, nir_tex_instr *tex)
+{
+   int offset_index = tex_instr_find_src(tex, nir_tex_src_offset);
+   if (offset_index < 0)
+  return false;
+
+   int coord_index = tex_instr_find_src(tex, nir_tex_src_coord);
+   assert(coord_index >= 0);
+
+   assert(tex->src[offset_index].src.is_ssa);
+   assert(tex->src[coord_index].src.is_ssa);
+   nir_ssa_def *offset = tex->src[offset_index].src.ssa;
+   nir_ssa_def *coord = tex->src[coord_index].src.ssa;
+
+   b->cursor = nir_before_instr(>instr);
+
+   nir_ssa_def *offset_coord;
+   if (nir_tex_instr_src_type(tex, coord_index) == nir_type_float) {
+  assert(tex->sampler_dim == GLSL_SAMPLER_DIM_RECT);
+  offset_coord = nir_fadd(b, coord, nir_i2f(b, offset));
+   } else {
+  offset_coord = nir_iadd(b, coord, offset);
+   }
+
+   if (tex->is_array) {
+  /* The offset is not applied to the array index */
+  if (tex->coord_components == 2) {
+ offset_coord = nir_vec2(b, nir_channel(b, offset_coord, 0),
+nir_channel(b, coord, 1));
+  } else if (tex->coord_components == 3) {
+ offset_coord = nir_vec3(b, nir_channel(b, offset_coord, 0),
+nir_channel(b, offset_coord, 1),
+nir_channel(b, coord, 2));
+  } else {
+ unreachable("Invalid number of components");
+  }
+   }
+
+   nir_instr_rewrite_src(>instr, >src[coord_index].src,
+ nir_src_for_ssa(offset_coord));
+
+   tex_instr_remove_src(tex, offset_index);
+
+   return true;
+}
+
+
 static nir_ssa_def *
 get_texture_size(nir_builder *b, nir_tex_instr *tex)
 {
@@ -458,6 +506,12 @@ nir_lower_tex_block(nir_block *block, nir_builder *b,
  progress = true;
   }
 
+  if ((tex->op == nir_texop_txf && options->lower_txf_offset) ||
+  (tex->sampler_dim == GLSL_SAMPLER_DIM_RECT &&
+   options->lower_rect_offset)) {
+ progress = lower_offset(b, tex) || progress;
+  }
+
   if ((tex->sampler_dim == GLSL_SAMPLER_DIM_RECT) && options->lower_rect) {
  lower_rect(b, tex);
  progress = true;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 8/9] nir/spirv: Use breaks instead of returns in constant handling

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Ian Romanick 
---
 src/compiler/spirv/spirv_to_nir.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 4061b8a..bb7aba4 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1028,7 +1028,7 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
val->constant->value.u[i] = u[comp];
 }
  }
- return;
+ break;
   }
 
   case SpvOpCompositeExtract:
@@ -1105,7 +1105,7 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
   (*c)->value.u[elem + i] = insert->constant->value.u[i];
 }
  }
- return;
+ break;
   }
 
   default: {
@@ -1134,9 +1134,10 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
  for (unsigned k = 0; k < num_components; k++)
 val->constant->value.u[k] = res.u32[k];
 
- return;
+ break;
   } /* default */
   }
+  break;
}
 
case SpvOpConstantNull:
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 05/16] nir: Add a helper for determining the type of a texture source

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/nir/nir.h | 44 
 1 file changed, 44 insertions(+)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 2873c15..d0f52b0 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -1246,6 +1246,50 @@ nir_tex_instr_is_query(nir_tex_instr *instr)
}
 }
 
+static inline nir_alu_type
+nir_tex_instr_src_type(nir_tex_instr *instr, unsigned src)
+{
+   switch (instr->src[src].src_type) {
+   case nir_tex_src_coord:
+  switch (instr->op) {
+  case nir_texop_txf:
+  case nir_texop_txf_ms:
+  case nir_texop_txf_ms_mcs:
+  case nir_texop_samples_identical:
+ return nir_type_int;
+
+  default:
+ return nir_type_float;
+  }
+
+   case nir_tex_src_lod:
+  switch (instr->op) {
+  case nir_texop_txs:
+  case nir_texop_txf:
+ return nir_type_int;
+
+  default:
+ return nir_type_float;
+  }
+
+   case nir_tex_src_projector:
+   case nir_tex_src_comparitor:
+   case nir_tex_src_bias:
+   case nir_tex_src_ddx:
+   case nir_tex_src_ddy:
+  return nir_type_float;
+
+   case nir_tex_src_offset:
+   case nir_tex_src_ms_index:
+   case nir_tex_src_texture_offset:
+   case nir_tex_src_sampler_offset:
+  return nir_type_int;
+
+   default:
+  unreachable("Invalid texture source type");
+   }
+}
+
 static inline unsigned
 nir_tex_instr_src_size(nir_tex_instr *instr, unsigned src)
 {
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 01/16] spirv/nir: Fix some texture opcode asserts

[Jason Ekstrand]

We can't get an lod with txf_ms and SPIR-V considers textureGrad to be an
explicit-LOD texturing instruction.

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
---
 src/compiler/spirv/spirv_to_nir.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 1efda9b..22cd2e7 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1444,12 +1444,12 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
 
   if (operands & SpvImageOperandsLodMask) {
  assert(texop == nir_texop_txl || texop == nir_texop_txf ||
-texop == nir_texop_txf_ms || texop == nir_texop_txs);
+texop == nir_texop_txs);
  (*p++) = vtn_tex_src(b, w[idx++], nir_tex_src_lod);
   }
 
   if (operands & SpvImageOperandsGradMask) {
- assert(texop == nir_texop_tex);
+ assert(texop == nir_texop_txl);
  texop = nir_texop_txd;
  (*p++) = vtn_tex_src(b, w[idx++], nir_tex_src_ddx);
  (*p++) = vtn_tex_src(b, w[idx++], nir_tex_src_ddy);
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 1/9] anv/clear: Handle ClearImage on 3-D images

[Jason Ekstrand]

Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Nanley Chery 
---
 src/intel/vulkan/anv_meta_clear.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_meta_clear.c 
b/src/intel/vulkan/anv_meta_clear.c
index 18dfae8..fe750c8 100644
--- a/src/intel/vulkan/anv_meta_clear.c
+++ b/src/intel/vulkan/anv_meta_clear.c
@@ -761,9 +761,11 @@ anv_cmd_clear_image(struct anv_cmd_buffer *cmd_buffer,
 
for (uint32_t r = 0; r < range_count; r++) {
   const VkImageSubresourceRange *range = [r];
-
   for (uint32_t l = 0; l < anv_get_levelCount(image, range); ++l) {
- for (uint32_t s = 0; s < anv_get_layerCount(image, range); ++s) {
+ const uint32_t layer_count = image->type == VK_IMAGE_TYPE_3D ?
+  anv_minify(image->extent.depth, l) :
+  anv_get_layerCount(image, range);
+ for (uint32_t s = 0; s < layer_count; ++s) {
 struct anv_image_view iview;
 anv_image_view_init(, cmd_buffer->device,
&(VkImageViewCreateInfo) {
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 00/16] Various Vulkan/SPIR-V fixes (mostly SPIR-V)

[Jason Ekstrand]

I pulled the latest version of the Vulkan CTS and gave it a run.  One of
the major aditions was a pile of tests for different texturing operations.
This demonstrated that our texturing support was, well, sub-par.  These
patches get it most of the way fixed up.  As a nice side-benifit, it also
fixes 5 piglit tests on GL.

Jason Ekstrand (16):
  spirv/nir: Fix some texture opcode asserts
  spirv/nir: Add support for shadow samplers that return vec4
  spirv/nir: Properly handle gather components
  anv/pipeline: Set binding_table.gather_texture_start
  nir: Add a helper for determining the type of a texture source
  nir/lower_tex: Add some helpers for working with tex sources
  nir/lower_tex: Add support for lowering coordinate offsets
  i965/nir: Enable NIR lowering of txf and rect offsets
  i965: Get rid of the do_lower_unnormalized_offsets pass
  spirv/nir: Don't increment coord_components for array lod queries
  anv/image: Assert that the image format is actually supported
  spirv/nir/: Move opcode selection higher up in handle_texture
  spirv/nir: Refactor type handling in handle_texture
  nir/spirv: Refactor coordinate handling in handle_texture
  spirv/nir: Handle texture projectors
  spirv/nir: Add support for ImageQuerySamples

 src/compiler/nir/nir.h |  54 ++
 src/compiler/nir/nir_lower_tex.c   |  98 +--
 src/compiler/spirv/spirv_to_nir.c  | 189 -
 src/intel/vulkan/anv_image.c   |   7 +-
 src/intel/vulkan/anv_pipeline.c|   1 +
 src/mesa/drivers/dri/i965/Makefile.sources |   1 -
 src/mesa/drivers/dri/i965/brw_context.h|   1 -
 src/mesa/drivers/dri/i965/brw_link.cpp |   1 -
 .../dri/i965/brw_lower_unnormalized_offset.cpp | 106 
 src/mesa/drivers/dri/i965/brw_nir.c|   2 +
 10 files changed, 255 insertions(+), 205 deletions(-)
 delete mode 100644 src/mesa/drivers/dri/i965/brw_lower_unnormalized_offset.cpp

-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH] egl/dri2: Add reference count for dri2_egl_display

[Nicolas Boichat]

On Thu, Jul 21, 2016 at 10:51 PM, Emil Velikov  wrote:
> On 21 July 2016 at 01:44, Nicolas Boichat  wrote:
>> On Wed, Jul 20, 2016 at 11:52 PM, Emil Velikov  
>> wrote:
>>> On 20 July 2016 at 15:42, Emil Velikov  wrote:
 On 20 July 2016 at 09:26, Nicolas Boichat  wrote:
> android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls
> eglTerminate, followed by eglReleaseThread. A similar case is
> observed in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=69622,
> where the test calls eglTerminate, then eglMakeCurrent(dpy, NULL, NULL, 
> NULL).
>
> With the current code, dri2_dpy structure is freed on eglTerminate
> call, so the display is not initialized when eglReleaseThread calls
> MakeCurrent with NULL parameters, to unbind the context, which
> causes a a segfault in drv->API.MakeCurrent (dri2_make_current),
> either in glFlush or in a latter call.
>
> eglTerminate specifies that "If contexts or surfaces associated
> with display is current to any thread, they are not released until
> they are no longer current as a result of eglMakeCurrent."
>
> However, to properly free the current context/surface (i.e., call
> glFlush, unbindContext, driDestroyContext), we still need the
> display vtbl (and possibly an active dri dpy connection). Therefore,
> we add some reference counter to dri2_egl_display, to make sure
> the structure is kept allocated as long as it is required.
>
 Looks very, just a couple of suggestions below.

> Signed-off-by: Nicolas Boichat 
> ---
>
> Replaces https://patchwork.freedesktop.org/patch/98874/.
>
>  src/egl/drivers/dri2/egl_dri2.c | 96 
> -
>  src/egl/drivers/dri2/egl_dri2.h |  4 ++
>  2 files changed, 80 insertions(+), 20 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c 
> b/src/egl/drivers/dri2/egl_dri2.c
> index ac2be86..00269d3 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -761,6 +761,14 @@ dri2_create_screen(_EGLDisplay *disp)
>  static EGLBoolean
>  dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
>  {
> +   EGLBoolean ret = EGL_FALSE;
> +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> +
> +   if (dri2_dpy) {
> +  dri2_dpy->ref_count++;
> +  return EGL_TRUE;
> +   }
> +
 I'm not sure that reusing the dpy is what we want here. IMHO we should
 either call dri2_display_release (to release existing resources) or
 simply error out.

>>> A bit more meat to it:
>>> Upper layer(s) will ensure that upon second call to eglInitialize
>>> (without a eglTerminate in between) we won't get here. Thus only case
>>> we get this is on user misuse/leak  - missing explicit/implicit
>>> eglMakeCurrent(...NULL, NULL) call while having called eglTerminate.
>>
>> Yes, that's how it's intended to work, "Initialized" boolean in
>> _EGLDisplay structure protects against repeated calls (I added a
>> comment to dri2_terminate, I should add the same in dri2_initialize).
>>
>>> If we ref count we exacerbate the leak. At the same time, returning
>>> error in case of a user leak sounds silly, so dri2_display_release
>>> might be like the better option ?
>>
>> That's right, we "leak" the display connection in this case:
>>  - eglMakeCurrent(context1)
>>  - eglTerminate
>>  - never call any EGL function
>>
>> However that's a arguably an application bug, as we _must_ keep a
>> reference to context1. Also, we still hold a reference to the display,
>> so calling eglReleaseThread, eglMakeCurrent(NULL), or eglInitialize
>> would free/reuse the display.
>>
>> To go along your lines, I first tried doing something like:
>> while (dri2_egl_display(disp))
>>dri2_display_release(disp);
>>
>> But then in this test case:
>>  - eglMakeCurrent(context1)
>>  - eglTerminate
>>  - eglInitialize
>>  - eglMakeCurrent(context2)
>>
>> context1 would permanently leak (similar to the issue we had with the
>> previous patch). And eglMakeCurrent(context2) would crash trying to
>> unbind context1 (didn't trace the exact nature of the crash, but I
>> suppose the new display is not aware of context1). I wrote a small
>> test case for this scenario:
>> https://android-review.googlesource.com/#/c/249320/1 .
>>
> That said I fully agree with all the above - we cannot do much in case
> of application bugs/user leaks.
>
>> A more sensible option might be to call dri2_make_current(NULL). But
>> IIUC, we'd need to do that on all threads, and it violates the spec
>> "If contexts or surfaces associated with display is current to any
>> thread, they are not released until they are no longer current as a
>> result of eglMakeCurrent."
>>
>> In 

[Mesa-dev] [PATCH v2] egl/dri2: Add reference count for dri2_egl_display

[Nicolas Boichat]

android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls
eglTerminate, followed by eglReleaseThread. A similar case is
observed in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=69622,
where the test calls eglTerminate, then eglMakeCurrent(dpy, NULL, NULL, NULL).

With the current code, dri2_dpy structure is freed on eglTerminate
call, so the display is not initialized when eglReleaseThread calls
MakeCurrent with NULL parameters, to unbind the context, which
causes a a segfault in drv->API.MakeCurrent (dri2_make_current),
either in glFlush or in a latter call.

eglTerminate specifies that "If contexts or surfaces associated
with display is current to any thread, they are not released until
they are no longer current as a result of eglMakeCurrent."

However, to properly free the current context/surface (i.e., call
glFlush, unbindContext, driDestroyContext), we still need the
display vtbl (and possibly an active dri dpy connection). Therefore,
we add some reference counter to dri2_egl_display, to make sure
the structure is kept allocated as long as it is required.

One drawback of this is that eglInitialize may not completely reinitialize
the display (if eglTerminate was called with a current context), however,
this seems to meet the EGL spec quite well, and does not permanently
leak any context/display even for incorrectly written apps.

Signed-off-by: Nicolas Boichat 
Reviewed-by: Eric Engestrom 

---
 src/egl/drivers/dri2/egl_dri2.c | 111 
 src/egl/drivers/dri2/egl_dri2.h |   4 ++
 2 files changed, 95 insertions(+), 20 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index ac2be86..114cf4e 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -757,10 +757,33 @@ dri2_create_screen(_EGLDisplay *disp)
 
 /**
  * Called via eglInitialize(), GLX_drv->API.Initialize().
+ *
+ * This must be guaranteed to be called exactly once, even if eglInitialize is
+ * called many times (without a eglTerminate in between).
  */
 static EGLBoolean
 dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
 {
+   EGLBoolean ret = EGL_FALSE;
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+
+   /* In the case where the application calls eglMakeCurrent(context1),
+* eglTerminate, then eglInitialize again (without a call to 
eglReleaseThread
+* or eglMakeCurrent(NULL) before that), dri2_dpy structure is still
+* initialized, as we need it to be able to free context1 correctly.
+*
+* It would probably be safest to forcibly release the display with
+* dri2_display_release, to make sure the display is reinitialized 
correctly.
+* However, the EGL spec states that we need to keep a reference to the
+* current context (so we cannot call dri2_make_current(NULL)), and 
therefore
+* we would leak context1 as we would be missing the old display connection
+* to free it up correctly.
+*/
+   if (dri2_dpy) {
+  dri2_dpy->ref_count++;
+  return EGL_TRUE;
+   }
+
/* not until swrast_dri is supported */
if (disp->Options.UseFallback)
   return EGL_FALSE;
@@ -769,52 +792,75 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
 #ifdef HAVE_SURFACELESS_PLATFORM
case _EGL_PLATFORM_SURFACELESS:
   if (disp->Options.TestOnly)
- return EGL_TRUE;
-  return dri2_initialize_surfaceless(drv, disp);
+ ret = EGL_TRUE;
+  else
+ ret = dri2_initialize_surfaceless(drv, disp);
+  break;
 #endif
-
 #ifdef HAVE_X11_PLATFORM
case _EGL_PLATFORM_X11:
   if (disp->Options.TestOnly)
- return EGL_TRUE;
-  return dri2_initialize_x11(drv, disp);
+ ret = EGL_TRUE;
+  else
+ ret = dri2_initialize_x11(drv, disp);
+  break;
 #endif
-
 #ifdef HAVE_DRM_PLATFORM
case _EGL_PLATFORM_DRM:
   if (disp->Options.TestOnly)
- return EGL_TRUE;
-  return dri2_initialize_drm(drv, disp);
+ ret = EGL_TRUE;
+  else
+ ret = dri2_initialize_drm(drv, disp);
+  break;
 #endif
 #ifdef HAVE_WAYLAND_PLATFORM
case _EGL_PLATFORM_WAYLAND:
   if (disp->Options.TestOnly)
- return EGL_TRUE;
-  return dri2_initialize_wayland(drv, disp);
+ ret = EGL_TRUE;
+  else
+ ret = dri2_initialize_wayland(drv, disp);
+  break;
 #endif
 #ifdef HAVE_ANDROID_PLATFORM
case _EGL_PLATFORM_ANDROID:
   if (disp->Options.TestOnly)
- return EGL_TRUE;
-  return dri2_initialize_android(drv, disp);
+ ret = EGL_TRUE;
+  else
+ ret = dri2_initialize_android(drv, disp);
+  break;
 #endif
-
default:
   _eglLog(_EGL_WARNING, "No EGL platform enabled.");
   return EGL_FALSE;
}
+
+   if (ret) {
+  dri2_dpy = dri2_egl_display(disp);
+
+  if (!dri2_dpy) {
+ return EGL_FALSE;
+  }
+
+  dri2_dpy->ref_count++;
+   }
+
+   return ret;

Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: Add GL_BGRA_EXT to the list of GenerateMipmap internal formats.

[Ian Romanick]

On 07/21/2016 05:44 PM, Kenneth Graunke wrote:
> The GL_EXT_texture_format_BGRA extension specification defines a
> GL_BGRA_EXT unsized internal format (which is a little odd - usually
> BGRA is a pixel transfer format).  The extension is written against
> the ES 1.0 specification, so it's a little hard to map, but I believe
> it's effectively adding it to the table used here, so we should allow
> it here as well.

OpenGL ES 1.x and 2.0 only have unsized internal formats, so this is
"correct."  The internal format is inferred from the format and type...
and the driver isn't supposed to (have to) do any conversions.

> Note that GL_EXT_texture_format_BGRA is always enabled (dummy_true),
> so we don't need to check if it's enabled here.
> 
> This fixes mipmap generation in Skia and ChromeOS.
> 
> Signed-off-by: Kenneth Graunke 
> References: https://bugs.chromium.org/p/chromium/issues/detail?id=630371
> Cc: Stéphane Marchesin 
> Cc: mesa-sta...@lists.freedesktop.org

Reviewed-by: Ian Romanick 

> ---
>  src/mesa/main/genmipmap.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/mesa/main/genmipmap.c b/src/mesa/main/genmipmap.c
> index 5e780c9..c952c4f 100644
> --- a/src/mesa/main/genmipmap.c
> +++ b/src/mesa/main/genmipmap.c
> @@ -85,10 +85,15 @@ 
> _mesa_is_valid_generate_texture_mipmap_internalformat(struct gl_context *ctx,
> *  not specified with an unsized internal format from table 8.3 or a
> *  sized internal format that is both color-renderable and
> *  texture-filterable according to table 8.10."
> +   *
> +   * GL_EXT_texture_format_BGRA adds a GL_BGRA_EXT unsized internal
> +   * format, and includes it in a very similar looking table.  So we
> +   * include it here as well.
> */
>return internalformat == GL_RGBA || internalformat == GL_RGB ||
>   internalformat == GL_LUMINANCE_ALPHA ||
>   internalformat == GL_LUMINANCE || internalformat == GL_ALPHA ||
> + internalformat == GL_BGRA_EXT ||
>   (_mesa_is_es3_color_renderable(internalformat) &&
>_mesa_is_es3_texture_filterable(ctx, internalformat));
> }


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

Re: [Mesa-dev] [PATCH] Rename the DEBUG macro to MESA_DEBUG

[Rob Clark]

On Thu, Jul 21, 2016 at 9:35 PM, Rob Clark  wrote:
> On Thu, Jul 21, 2016 at 1:48 PM, Vedran Miletić  wrote:
>> LLVM and Mesa both define the DEBUG macro in incompatible ways. As a
>> general practice, we should avoid using such generic names when it is
>> possible to do so.
>>
>> This patch renames all occurrences of the DEBUG macro to MESA_DEBUG,
>> and removes workarounds previously used to enable building Mesa with
>> LLVM (pop_macro() and push_macro() function calls).
>>
>> Please let me know if I missed any.
>
> I guess at least some in-flight patches (at least my
> pipe_mutex_assert_locked() patch, but I guess DEBUG is common enough
> that it might effect others).. not sure if there is a better way to
> deal with that without things falling through the cracks..  maybe
> introduce MESA_DEBUG which is the same as DEBUG first, and then a
> later patch to remove DEBUG.  Or at least including sed/etc rule to
> re-do the mass-change on a later baseline in the commit msg?
>
> I don't mind rebasing my patch, just more worried about things falling
> through the cracks with other in-progress stuff, since it seems like
> the end result would be a silent fail to enable intended debug code..

btw, possibly tilting at windmills here, but afaik we don't export
DEBUG outside the mesa codebase.. so actually it should be llvm that
s/DEBUG/LLVM_DEBUG/

BR,
-R

> BR,
> -R
>
>> Signed-off-by: Vedran Miletić 
>> ---
>>  configure.ac   |  2 +-
>>  src/compiler/glsl/ir_validate.cpp  |  4 +-
>>  src/compiler/nir/nir.h |  6 +-
>>  src/compiler/nir/nir_metadata.c|  4 +-
>>  src/compiler/nir/nir_validate.c|  5 +-
>>  src/egl/drivers/haiku/egl_haiku.cpp|  6 +-
>>  src/egl/main/eglconfig.c   |  6 +-
>>  src/gallium/auxiliary/draw/draw_cliptest_tmp.h |  4 +-
>>  src/gallium/auxiliary/gallivm/lp_bld_debug.h   | 12 ++--
>>  src/gallium/auxiliary/gallivm/lp_bld_init.c| 16 +++---
>>  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp  | 23 ++--
>>  src/gallium/auxiliary/gallivm/lp_bld_struct.c  | 16 +++---
>>  src/gallium/auxiliary/os/os_memory.h   |  6 +-
>>  src/gallium/auxiliary/os/os_misc.c |  4 +-
>>  src/gallium/auxiliary/os/os_misc.h |  6 +-
>>  .../auxiliary/pipebuffer/pb_buffer_fenced.c| 10 ++--
>>  src/gallium/auxiliary/pipebuffer/pb_bufmgr_debug.c |  6 +-
>>  src/gallium/auxiliary/tgsi/tgsi_exec.c | 16 +++---
>>  src/gallium/auxiliary/tgsi/tgsi_ureg.c |  8 +--
>>  src/gallium/auxiliary/util/u_cache.c   | 16 +++---
>>  src/gallium/auxiliary/util/u_cpu_detect.c  |  8 +--
>>  src/gallium/auxiliary/util/u_debug.c   | 18 +++---
>>  src/gallium/auxiliary/util/u_debug.h   | 66 
>> +++---
>>  src/gallium/auxiliary/util/u_debug_flush.c |  4 +-
>>  src/gallium/auxiliary/util/u_debug_flush.h |  6 +-
>>  src/gallium/auxiliary/util/u_debug_image.c |  4 +-
>>  src/gallium/auxiliary/util/u_debug_image.h |  8 +--
>>  src/gallium/drivers/freedreno/ir3/ir3.c| 16 +++---
>>  src/gallium/drivers/freedreno/ir3/ir3.h| 18 +++---
>>  src/gallium/drivers/freedreno/ir3/ir3_print.c  |  4 +-
>>  src/gallium/drivers/freedreno/ir3/ir3_ra.c |  4 +-
>>  src/gallium/drivers/i915/i915_debug.c  |  6 +-
>>  src/gallium/drivers/i915/i915_debug.h  |  6 +-
>>  src/gallium/drivers/ilo/core/ilo_debug.h   | 17 +++---
>>  src/gallium/drivers/llvmpipe/lp_debug.h|  6 +-
>>  src/gallium/drivers/llvmpipe/lp_perf.h |  6 +-
>>  src/gallium/drivers/llvmpipe/lp_rast.c |  4 +-
>>  src/gallium/drivers/llvmpipe/lp_rast.h |  4 +-
>>  src/gallium/drivers/llvmpipe/lp_rast_priv.h|  6 +-
>>  src/gallium/drivers/llvmpipe/lp_scene.c|  4 +-
>>  src/gallium/drivers/llvmpipe/lp_screen.c   |  8 +--
>>  src/gallium/drivers/llvmpipe/lp_setup_line.c   |  4 +-
>>  src/gallium/drivers/llvmpipe/lp_setup_point.c  |  4 +-
>>  src/gallium/drivers/llvmpipe/lp_state_sampler.c|  4 +-
>>  src/gallium/drivers/llvmpipe/lp_test_main.c|  4 +-
>>  src/gallium/drivers/llvmpipe/lp_texture.c  | 24 
>>  src/gallium/drivers/llvmpipe/lp_texture.h  |  4 +-
>>  .../drivers/nouveau/codegen/nv50_ir_driver.h   |  6 +-
>>  .../drivers/nouveau/codegen/nv50_ir_inlines.h  |  4 +-
>>  src/gallium/drivers/nouveau/nouveau_screen.h   |  4 +-
>>  src/gallium/drivers/nouveau/nouveau_statebuf.h | 10 ++--
>>  src/gallium/drivers/nouveau/nv50/nv50_program.c|  6 +-
>>  src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 14 ++---
>>  src/gallium/drivers/nouveau/nvc0/nve4_compute.c| 12 ++--
>>  

Re: [Mesa-dev] [PATCH] Rename the DEBUG macro to MESA_DEBUG

[Rob Clark]

On Thu, Jul 21, 2016 at 1:48 PM, Vedran Miletić  wrote:
> LLVM and Mesa both define the DEBUG macro in incompatible ways. As a
> general practice, we should avoid using such generic names when it is
> possible to do so.
>
> This patch renames all occurrences of the DEBUG macro to MESA_DEBUG,
> and removes workarounds previously used to enable building Mesa with
> LLVM (pop_macro() and push_macro() function calls).
>
> Please let me know if I missed any.

I guess at least some in-flight patches (at least my
pipe_mutex_assert_locked() patch, but I guess DEBUG is common enough
that it might effect others).. not sure if there is a better way to
deal with that without things falling through the cracks..  maybe
introduce MESA_DEBUG which is the same as DEBUG first, and then a
later patch to remove DEBUG.  Or at least including sed/etc rule to
re-do the mass-change on a later baseline in the commit msg?

I don't mind rebasing my patch, just more worried about things falling
through the cracks with other in-progress stuff, since it seems like
the end result would be a silent fail to enable intended debug code..

BR,
-R

> Signed-off-by: Vedran Miletić 
> ---
>  configure.ac   |  2 +-
>  src/compiler/glsl/ir_validate.cpp  |  4 +-
>  src/compiler/nir/nir.h |  6 +-
>  src/compiler/nir/nir_metadata.c|  4 +-
>  src/compiler/nir/nir_validate.c|  5 +-
>  src/egl/drivers/haiku/egl_haiku.cpp|  6 +-
>  src/egl/main/eglconfig.c   |  6 +-
>  src/gallium/auxiliary/draw/draw_cliptest_tmp.h |  4 +-
>  src/gallium/auxiliary/gallivm/lp_bld_debug.h   | 12 ++--
>  src/gallium/auxiliary/gallivm/lp_bld_init.c| 16 +++---
>  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp  | 23 ++--
>  src/gallium/auxiliary/gallivm/lp_bld_struct.c  | 16 +++---
>  src/gallium/auxiliary/os/os_memory.h   |  6 +-
>  src/gallium/auxiliary/os/os_misc.c |  4 +-
>  src/gallium/auxiliary/os/os_misc.h |  6 +-
>  .../auxiliary/pipebuffer/pb_buffer_fenced.c| 10 ++--
>  src/gallium/auxiliary/pipebuffer/pb_bufmgr_debug.c |  6 +-
>  src/gallium/auxiliary/tgsi/tgsi_exec.c | 16 +++---
>  src/gallium/auxiliary/tgsi/tgsi_ureg.c |  8 +--
>  src/gallium/auxiliary/util/u_cache.c   | 16 +++---
>  src/gallium/auxiliary/util/u_cpu_detect.c  |  8 +--
>  src/gallium/auxiliary/util/u_debug.c   | 18 +++---
>  src/gallium/auxiliary/util/u_debug.h   | 66 
> +++---
>  src/gallium/auxiliary/util/u_debug_flush.c |  4 +-
>  src/gallium/auxiliary/util/u_debug_flush.h |  6 +-
>  src/gallium/auxiliary/util/u_debug_image.c |  4 +-
>  src/gallium/auxiliary/util/u_debug_image.h |  8 +--
>  src/gallium/drivers/freedreno/ir3/ir3.c| 16 +++---
>  src/gallium/drivers/freedreno/ir3/ir3.h| 18 +++---
>  src/gallium/drivers/freedreno/ir3/ir3_print.c  |  4 +-
>  src/gallium/drivers/freedreno/ir3/ir3_ra.c |  4 +-
>  src/gallium/drivers/i915/i915_debug.c  |  6 +-
>  src/gallium/drivers/i915/i915_debug.h  |  6 +-
>  src/gallium/drivers/ilo/core/ilo_debug.h   | 17 +++---
>  src/gallium/drivers/llvmpipe/lp_debug.h|  6 +-
>  src/gallium/drivers/llvmpipe/lp_perf.h |  6 +-
>  src/gallium/drivers/llvmpipe/lp_rast.c |  4 +-
>  src/gallium/drivers/llvmpipe/lp_rast.h |  4 +-
>  src/gallium/drivers/llvmpipe/lp_rast_priv.h|  6 +-
>  src/gallium/drivers/llvmpipe/lp_scene.c|  4 +-
>  src/gallium/drivers/llvmpipe/lp_screen.c   |  8 +--
>  src/gallium/drivers/llvmpipe/lp_setup_line.c   |  4 +-
>  src/gallium/drivers/llvmpipe/lp_setup_point.c  |  4 +-
>  src/gallium/drivers/llvmpipe/lp_state_sampler.c|  4 +-
>  src/gallium/drivers/llvmpipe/lp_test_main.c|  4 +-
>  src/gallium/drivers/llvmpipe/lp_texture.c  | 24 
>  src/gallium/drivers/llvmpipe/lp_texture.h  |  4 +-
>  .../drivers/nouveau/codegen/nv50_ir_driver.h   |  6 +-
>  .../drivers/nouveau/codegen/nv50_ir_inlines.h  |  4 +-
>  src/gallium/drivers/nouveau/nouveau_screen.h   |  4 +-
>  src/gallium/drivers/nouveau/nouveau_statebuf.h | 10 ++--
>  src/gallium/drivers/nouveau/nv50/nv50_program.c|  6 +-
>  src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 14 ++---
>  src/gallium/drivers/nouveau/nvc0/nve4_compute.c| 12 ++--
>  src/gallium/drivers/r300/r300_cb.h |  6 +-
>  src/gallium/drivers/r300/r300_context.c|  6 +-
>  src/gallium/drivers/r300/r300_cs.h |  6 +-
>  src/gallium/drivers/softpipe/sp_tex_sample.c   |  4 +-
>  src/gallium/drivers/svga/svga_debug.h  |  8 +--
>  src/gallium/drivers/svga/svga_draw.c  

Re: [Mesa-dev] [PATCH 07/10] egl/android: Make drm_gralloc headers optional

[Rob Clark]

On Thu, Jul 21, 2016 at 6:07 PM, Stéphane Marchesin
 wrote:
> On Tue, Jul 19, 2016 at 6:36 AM, Rob Clark  wrote:
>> On Tue, Jul 19, 2016 at 6:54 AM, Emil Velikov  
>> wrote:
>>> On 19 July 2016 at 04:21, Tomasz Figa  wrote:
 On Tue, Jul 19, 2016 at 2:35 AM, Emil Velikov  
 wrote:
> On 18 July 2016 at 16:38, Tomasz Figa  wrote:
>> On Mon, Jul 18, 2016 at 11:58 PM, Emil Velikov 
>>  wrote:
>>> On 18 July 2016 at 13:02, Tomasz Figa  wrote:
 On Mon, Jul 18, 2016 at 7:28 PM, Emil Velikov 
  wrote:
> Hi Tomasz,
>
> On 15 July 2016 at 08:53, Tomasz Figa  wrote:
>
>> +#define DRM_RENDER_DEV_NAME  "%s/renderD%d"
>> +
>> +static int
>> +droid_open_device(_EGLDisplay *dpy)
>> +{
>> +   struct dri2_egl_display *dri2_dpy = dpy->DriverData;
>> +   const int limit = 64;
>> +   const int base = 128;
>> +   int fd;
>> +   int i;
>> +
>> +   for (i = 0; i < limit; ++i) {
>> +  char *card_path;
>> +  if (asprintf(_path, DRM_RENDER_DEV_NAME, DRM_DIR_NAME, 
>> base + i) < 0)
> Why do we need any of this ? What gralloc implementation are you guys 
> using ?

 We are using our heavily rewritten fork of some old drm_gralloc
 release. It supports only render nodes and PRIME FDs and doesn't
 export the DRI device FD outside of its internals (which isn't
 actually even fully correct, at least for PRIME and render nodes, see
 my reply to Rob's comments).

>>> That explain it, since https://chromium.googlesource.com/ does not
>>> have gralloc, and
>>> https://android.googlesource.com/platform/external/drm_gralloc/ has
>>> both the DRM_FD define and the gem/flink function(s)?
>>>
>>> Can I suggest porting the fd drm_gralloc/gbm_gralloc patches to your
>>> private copy/repo. This way we'll have some consistency throughout
>>> gralloc implementations
>>
>> I'd prefer if any code using flink names was not added back. On top of
>> that, our drm_gralloc doesn't really have much in common with that
>> from android-x86 anymore (as I said, it was heavily rewritten) and
>> there is not even a chance that with its current design flink names
>> could even work.
>>
>> Also I'm wondering why we want to consider current brokenness of
>> drm_gralloc as something to be consistent with. It's supposed to be a
>> HAL library providing an uniform abstraction, but it exports private
>> APIs on the side instead. Moreover, as I mentioned before, flink names
>> are considered insecure and it would be really much better if we could
>> just forget about them.
>>
>>> and you can use gbm_gralloc directly in the
>>> (hopefully) not too distant future.
>>
>> I agree with this part, though. gbm_gralloc is definitely something
>> that we might want to migrate to in the future. Although it's a bit
>> lacking at the moment, so it might need a bit more time to develop the
>> missing bits. [I'm CCing Gurchetan, who was investigating GBM-backed
>> gralloc usable for our purposes.]
>>
>> In any case, the missing flink API is quite easy to handle and can be
>> just stubbed out in a local header as you suggested. I don't think it
>> would hurt anyone and would definitely help us and anyone not willing
>> to export any private APIs from their gralloc and rely only on the
>> public HAL API.
>>
> Looks like I wasn't clear enough here, realyl sorry about that. No
> objection on nuking _any_ of the gem/flink paths, but hoping to have
> the behaviour consistent with the one described in
> get_native_buffer_fd.

 Did you mean having the PRIME FD in native_handle_t::data[0]?

 If so, it's more or less guaranteed by the API, because all file
 descriptors in handle have to be stored in first N (equals to
 native_handle_t::numFds) ints of native_handle_t::data[] for
 respective general code to properly transfer the FDs through binder
 when sharing between processes.

 Our gralloc currently supports only one PRIME FD per buffer (no
 separate memory planes for planar YUV) and stores it exactly in
 native_handle_t::data[0].

>>> Wasn't sure if the PRIME FD is at idx 0. Glad to hear it's there, thanks.
>>>
>
>>>
>
> Afaict the latter must provide reasonable result for
> hw_get_module(GRALLOC_HARDWARE_MODULE_ID...) and as it's missing the
> perform hook existing code should work just fine. Right ?

 Existing code would fail 

[Mesa-dev] [PATCH] mesa: Add GL_BGRA_EXT to the list of GenerateMipmap internal formats.

[Kenneth Graunke]

The GL_EXT_texture_format_BGRA extension specification defines a
GL_BGRA_EXT unsized internal format (which is a little odd - usually
BGRA is a pixel transfer format).  The extension is written against
the ES 1.0 specification, so it's a little hard to map, but I believe
it's effectively adding it to the table used here, so we should allow
it here as well.

Note that GL_EXT_texture_format_BGRA is always enabled (dummy_true),
so we don't need to check if it's enabled here.

This fixes mipmap generation in Skia and ChromeOS.

Signed-off-by: Kenneth Graunke 
References: https://bugs.chromium.org/p/chromium/issues/detail?id=630371
Cc: Stéphane Marchesin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/main/genmipmap.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/main/genmipmap.c b/src/mesa/main/genmipmap.c
index 5e780c9..c952c4f 100644
--- a/src/mesa/main/genmipmap.c
+++ b/src/mesa/main/genmipmap.c
@@ -85,10 +85,15 @@ 
_mesa_is_valid_generate_texture_mipmap_internalformat(struct gl_context *ctx,
*  not specified with an unsized internal format from table 8.3 or a
*  sized internal format that is both color-renderable and
*  texture-filterable according to table 8.10."
+   *
+   * GL_EXT_texture_format_BGRA adds a GL_BGRA_EXT unsized internal
+   * format, and includes it in a very similar looking table.  So we
+   * include it here as well.
*/
   return internalformat == GL_RGBA || internalformat == GL_RGB ||
  internalformat == GL_LUMINANCE_ALPHA ||
  internalformat == GL_LUMINANCE || internalformat == GL_ALPHA ||
+ internalformat == GL_BGRA_EXT ||
  (_mesa_is_es3_color_renderable(internalformat) &&
   _mesa_is_es3_texture_filterable(ctx, internalformat));
}
-- 
2.9.0

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

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

[Zhang, Boyuan]

Hi Andy,

I just submitted another patch set.

1. Fixed previously reported regression when using ffmpeg to encode.
2. Fixed I420 "width=720,height=480" garbage output issue.

Please give a try from your side.

Regards,
Boyuan


Hi Christian,

As stated above, this new patch set just submitted fixed the 2 issue reported 
by Andy. Main change is adding a new patch (8/9) to fix the regression issue, 
detailed information is written in the patch. I believe all basic functionality 
is working fine now if Andy confirmed the 2 fixes. And as discussed, other 
changes/issues will be addressed with the performance improvement in future. 

Please let me know whether this patch set is good enough for pushing to 
upstream?

Regards,
Boyuan 


-Original Message-
From: Andy Furniss [mailto:adf.li...@gmail.com] 
Sent: July-21-16 8:57 AM
To: Zhang, Boyuan; 'Christian König'; mesa-dev@lists.freedesktop.org
Subject: Re: [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

Zhang, Boyuan wrote:
> Hi Andy,
>
> Thanks very much for providing all the information.
>
> The I420 U V swapping issue still can't be reproduced from my side, I 
> will try it again later. CQP issue is fixed in the new patch set I 
> just submitted. Please use " ... vaapiencodeh264 rate-control=cqp 
> init-qp=x ..." command, where x can be any value b/w 0--51. Please 
> give a try and let me know the result. Other issues, e.g. encoding 
> speed, ffmpeg, will be addressed/investigated later in separate patch 
> as I mentioned. This initial patch set is to bring up VAAPI encode for 
> gstreamer with basic functionality working. I will update with you 
> once we make progress.

CQP is working OK now.

On the I420 I still see it whatever I try and have just managed to produce a 
totally trashed output.

Below produces "expected" output = colors are wrong for I420 but the vid is OK 
apart from that.

gst-launch-1.0 videotestsrc num-buffers=5 ! 
video/x-raw,format=I420,width=1280,height=720,framerate=1/1 ! 
vaapih264enc ! h264parse ! mp4mux ! filesink location=I420.mp4

gst-launch-1.0 videotestsrc num-buffers=5 ! 
video/x-raw,format=NV12,width=1280,height=720,framerate=1/1 ! 
vaapih264enc ! h264parse ! mp4mux ! filesink location=NV12.mp4

I then decided I would attach a png showing both outputs, to get it to fit I 
repeated above with width=720,height=480 and the result for
I420 was totally trashed, NV12 OK.

Replacing vaapih264enc with x264enc for the trashed case produces good output - 
so I don't think it's the input that is trashed at that res/pix_fmt.




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

[Mesa-dev] [PATCH 6/9] st/va: add preset values for VAAPI encode

[Boyuan Zhang]

Add some hardcoded values hardware needs mainly for rate control purpose. With 
previously hardcoded values for OMX, the rate control result is not correct. 
This change fixed the rate control result by setting correct values for Vaapi.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/picture.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 4bb60f2..4abf155 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -95,6 +95,32 @@ vlVaGetReferenceFrame(vlVaDriver *drv, VASurfaceID 
surface_id,
   *ref_frame = NULL;
 }
 
+static void
+getEncParamPreset(vlVaContext *context)
+{
+   //motion estimation preset
+   context->desc.h264enc.motion_est.motion_est_quarter_pixel = 0x0001;
+   context->desc.h264enc.motion_est.lsmvert = 0x0002;
+   context->desc.h264enc.motion_est.enc_disable_sub_mode = 0x0078;
+   context->desc.h264enc.motion_est.enc_en_ime_overw_dis_subm = 0x0001;
+   context->desc.h264enc.motion_est.enc_ime_overw_dis_subm_no = 0x0001;
+   context->desc.h264enc.motion_est.enc_ime2_search_range_x = 0x0004;
+   context->desc.h264enc.motion_est.enc_ime2_search_range_y = 0x0004;
+
+   //pic control preset
+   context->desc.h264enc.pic_ctrl.enc_cabac_enable = 0x0001;
+   context->desc.h264enc.pic_ctrl.enc_constraint_set_flags = 0x0040;
+
+   //rate control
+   context->desc.h264enc.rate_ctrl.vbv_buffer_size = 2000;
+   context->desc.h264enc.rate_ctrl.vbv_buf_lv = 48;
+   context->desc.h264enc.rate_ctrl.fill_data_enable = 1;
+   context->desc.h264enc.rate_ctrl.enforce_hrd = 1;
+   context->desc.h264enc.enable_vui = false;
+
+   context->desc.h264enc.ref_pic_mode = 0x0201;
+}
+
 static VAStatus
 handlePictureParameterBuffer(vlVaDriver *drv, vlVaContext *context, vlVaBuffer 
*buf)
 {
@@ -524,6 +550,7 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
 
if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
   coded_buf = context->coded_buf;
+  getEncParamPreset(context);
   context->decoder->begin_frame(context->decoder, context->target, 
>desc.base);
   context->decoder->encode_bitstream(context->decoder, context->target,
  coded_buf->derived_surface.resource, 
);
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/9] st/va: add conversion for yv12 to nv12in putimage

[Boyuan Zhang]

For putimage call, if image format is yv12 (or IYUV with U V field swap) and 
surface format is nv12, then we need to convert yv12 to nv12 and then copy the 
converted data from image to surface. We can't use the existing logic where 
surface is destroyed and re-created with yv12 format.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/image.c | 33 ++---
 1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index 1b956e3..d966cde 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -471,7 +471,9 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, 
VAImageID image,
   return VA_STATUS_ERROR_OPERATION_FAILED;
}
 
-   if (format != surf->buffer->buffer_format) {
+   if ((format != surf->buffer->buffer_format) &&
+ ((format != PIPE_FORMAT_YV12) || (surf->buffer->buffer_format != 
PIPE_FORMAT_NV12)) &&
+ ((format != PIPE_FORMAT_IYUV) || (surf->buffer->buffer_format != 
PIPE_FORMAT_NV12))) {
   struct pipe_video_buffer *tmp_buf;
   struct pipe_video_buffer templat = surf->templat;
 
@@ -513,12 +515,29 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, 
VAImageID image,
   unsigned width, height;
   if (!views[i]) continue;
   vlVaVideoSurfaceSize(surf, i, , );
-  for (j = 0; j < views[i]->texture->array_size; ++j) {
- struct pipe_box dst_box = {0, 0, j, width, height, 1};
- drv->pipe->transfer_inline_write(drv->pipe, views[i]->texture, 0,
-PIPE_TRANSFER_WRITE, _box,
-data[i] + pitches[i] * j,
-pitches[i] * views[i]->texture->array_size, 0);
+  if ((format == PIPE_FORMAT_YV12) || (format == PIPE_FORMAT_IYUV) &&
+(surf->buffer->buffer_format == PIPE_FORMAT_NV12)) {
+ struct pipe_transfer *transfer = NULL;
+ uint8_t *map = NULL;
+ struct pipe_box dst_box_1 = {0, 0, 0, width, height, 1};
+ map = drv->pipe->transfer_map(drv->pipe,
+   views[i]->texture,
+   0,
+   PIPE_TRANSFER_DISCARD_RANGE,
+   _box_1, );
+ if (map == NULL)
+return VA_STATUS_ERROR_OPERATION_FAILED;
+
+ u_copy_yv12_img_to_nv12_surf (data, map, width, height, pitches[i], 
transfer->stride, i);
+ pipe_transfer_unmap(drv->pipe, transfer);
+  } else {
+ for (j = 0; j < views[i]->texture->array_size; ++j) {
+struct pipe_box dst_box = {0, 0, j, width, height, 1};
+drv->pipe->transfer_inline_write(drv->pipe, views[i]->texture, 0,
+ PIPE_TRANSFER_WRITE, _box,
+ data[i] + pitches[i] * j,
+ pitches[i] * 
views[i]->texture->array_size, 0);
+ }
   }
}
pipe_mutex_unlock(drv->mutex);
-- 
2.7.4

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

[Mesa-dev] [PATCH 4/9] st/va: get rate control method from configattrib

[Boyuan Zhang]

Rate control method is passed from app to driver through config attrib list. 
That is why we need to store this rate control method to config. And later on, 
we will pass this value to context->desc.h264enc.rate_ctrl.rate_ctrl_method.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/config.c | 11 +++
 src/gallium/state_trackers/va/context.c|  2 ++
 src/gallium/state_trackers/va/va_private.h |  1 +
 3 files changed, 14 insertions(+)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 3aacc63..be151c8 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -176,6 +176,17 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
 
config->profile = p;
 
+   for (int i = 0; i rc = PIPE_H264_ENC_RATE_CONTROL_METHOD_CONSTANT;
+ else if (attrib_list[i].value == VA_RC_VBR)
+config->rc = PIPE_H264_ENC_RATE_CONTROL_METHOD_VARIABLE;
+ else
+config->rc = PIPE_H264_ENC_RATE_CONTROL_METHOD_DISABLE;
+  }
+   }
+
pipe_mutex_lock(drv->mutex);
*config_id = handle_table_add(drv->htab, config);
pipe_mutex_unlock(drv->mutex);
diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 8882cba..65ba7db 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -276,6 +276,8 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
 
context->desc.base.profile = config->profile;
context->desc.base.entry_point = config->entrypoint;
+   if (config->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE)
+  context->desc.h264enc.rate_ctrl.rate_ctrl_method = config->rc;
 
pipe_mutex_lock(drv->mutex);
*context_id = handle_table_add(drv->htab, context);
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 723983d..ad9010a 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -246,6 +246,7 @@ typedef struct {
 typedef struct {
VAEntrypoint entrypoint;
enum pipe_video_profile profile;
+   enum pipe_h264_enc_rate_control_method rc;
 } vlVaConfig;
 
 typedef struct {
-- 
2.7.4

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

[Mesa-dev] [PATCH 5/9] st/va: add functions for VAAPI encode

[Boyuan Zhang]

Add necessary functions/changes for VAAPI encoding to buffer and picture. These 
changes will allow driver to handle all Vaapi encode related operations. This 
patch doesn't change the Vaapi decode behaviour.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/buffer.c |   6 +
 src/gallium/state_trackers/va/picture.c| 172 -
 src/gallium/state_trackers/va/va_private.h |   3 +
 3 files changed, 179 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/va/buffer.c 
b/src/gallium/state_trackers/va/buffer.c
index 7d3167b..dfcebbe 100644
--- a/src/gallium/state_trackers/va/buffer.c
+++ b/src/gallium/state_trackers/va/buffer.c
@@ -133,6 +133,12 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, 
void **pbuff)
   if (!buf->derived_surface.transfer || !*pbuff)
  return VA_STATUS_ERROR_INVALID_BUFFER;
 
+  if (buf->type == VAEncCodedBufferType) {
+ ((VACodedBufferSegment*)buf->data)->buf = *pbuff;
+ ((VACodedBufferSegment*)buf->data)->size = buf->coded_size;
+ ((VACodedBufferSegment*)buf->data)->next = NULL;
+ *pbuff = buf->data;
+  }
} else {
   pipe_mutex_unlock(drv->mutex);
   *pbuff = buf->data;
diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 89ac024..4bb60f2 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -78,7 +78,8 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID 
context_id, VASurfaceID rende
   return VA_STATUS_SUCCESS;
}
 
-   context->decoder->begin_frame(context->decoder, context->target, 
>desc.base);
+   if (context->decoder->entrypoint != PIPE_VIDEO_ENTRYPOINT_ENCODE)
+  context->decoder->begin_frame(context->decoder, context->target, 
>desc.base);
 
return VA_STATUS_SUCCESS;
 }
@@ -278,6 +279,142 @@ handleVASliceDataBufferType(vlVaContext *context, 
vlVaBuffer *buf)
   num_buffers, (const void * const*)buffers, sizes);
 }
 
+static VAStatus
+handleVAEncMiscParameterTypeRateControl(vlVaContext *context, 
VAEncMiscParameterBuffer *misc)
+{
+   VAEncMiscParameterRateControl *rc = (VAEncMiscParameterRateControl 
*)misc->data;
+   if (context->desc.h264enc.rate_ctrl.rate_ctrl_method ==
+   PIPE_H264_ENC_RATE_CONTROL_METHOD_CONSTANT)
+  context->desc.h264enc.rate_ctrl.target_bitrate = rc->bits_per_second;
+   else
+  context->desc.h264enc.rate_ctrl.target_bitrate = rc->bits_per_second * 
rc->target_percentage;
+   context->desc.h264enc.rate_ctrl.peak_bitrate = rc->bits_per_second;
+   if (context->desc.h264enc.rate_ctrl.target_bitrate < 200)
+  context->desc.h264enc.rate_ctrl.vbv_buffer_size = 
MIN2((context->desc.h264enc.rate_ctrl.target_bitrate * 2.75), 200);
+   else
+  context->desc.h264enc.rate_ctrl.vbv_buffer_size = 
context->desc.h264enc.rate_ctrl.target_bitrate;
+   context->desc.h264enc.rate_ctrl.target_bits_picture =
+  context->desc.h264enc.rate_ctrl.target_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
+   context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
+  context->desc.h264enc.rate_ctrl.peak_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
+   context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0;
+
+   return VA_STATUS_SUCCESS;
+}
+
+static VAStatus
+handleVAEncSequenceParameterBufferType(vlVaDriver *drv, vlVaContext *context, 
vlVaBuffer *buf)
+{
+   VAEncSequenceParameterBufferH264 *h264 = (VAEncSequenceParameterBufferH264 
*)buf->data;
+   if (!context->decoder) {
+  context->templat.max_references = h264->max_num_ref_frames;
+  context->templat.level = h264->level_idc;
+  context->decoder = drv->pipe->create_video_codec(drv->pipe, 
>templat);
+  if (!context->decoder)
+ return VA_STATUS_ERROR_ALLOCATION_FAILED;
+   }
+   context->desc.h264enc.gop_size = h264->intra_idr_period;
+   context->desc.h264enc.rate_ctrl.frame_rate_num = h264->time_scale / 2;
+   context->desc.h264enc.rate_ctrl.frame_rate_den = 1;
+   return VA_STATUS_SUCCESS;
+}
+
+static VAStatus
+handleVAEncMiscParameterBufferType(vlVaContext *context, vlVaBuffer *buf)
+{
+   VAStatus vaStatus = VA_STATUS_SUCCESS;
+   VAEncMiscParameterBuffer *misc;
+   misc = buf->data;
+
+   switch (misc->type) {
+   case VAEncMiscParameterTypeRateControl:
+  vaStatus = handleVAEncMiscParameterTypeRateControl(context, misc);
+  break;
+
+   default:
+  break;
+   }
+
+   return vaStatus;
+}
+
+static VAStatus
+handleVAEncPictureParameterBufferType(vlVaDriver *drv, vlVaContext *context, 
vlVaBuffer *buf)
+{
+   VAEncPictureParameterBufferH264 *h264;
+   vlVaBuffer *coded_buf;
+
+   h264 = buf->data;
+   context->desc.h264enc.frame_num = h264->frame_num;
+   context->desc.h264enc.not_referenced = false;
+   context->desc.h264enc.is_idr = (h264->pic_fields.bits.idr_pic_flag == 1);
+   context->desc.h264enc.pic_order_cnt = 

[Mesa-dev] [PATCH 7/9] st/va: add enviromental variable to disable interlace

[Boyuan Zhang]

Add environmental variable to disable interlace mode. At VAAPI decoding stage, 
driver can not distinguish b/w pure decoding case and transcoding case. And 
since interlace encoding is not supported, we have to disable interlace for 
transcoding case. The temporary solution is to use enviromental variable to 
disable interlace mode.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/surface.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 8ce4143..63727b6 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -43,6 +43,8 @@
 
 #include "va_private.h"
 
+DEBUG_GET_ONCE_BOOL_OPTION(nointerlace, "VAAPI_DISABLE_INTERLACE", FALSE);
+
 #include 
 
 static const enum pipe_format vpp_surface_formats[] = {
@@ -620,6 +622,8 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
 
templat.width = width;
templat.height = height;
+   if (debug_get_option_nointerlace())
+  templat.interlaced = false;
 
memset(surfaces, VA_INVALID_ID, num_surfaces * sizeof(VASurfaceID));
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 8/9] st/va: add function to handle misc param type frame rate

[Boyuan Zhang]

Frame rate can be passed to driver either through 
VAEncSequenceParameterBufferType or VAEncMiscParameterTypeFrameRate. Previous 
code only implement the former one, which is used by Gstreamer-Vaapi. Now 
adding implementation for VAEncMiscParameterTypeFrameRate. Also adding default 
frame rate as 30 just in case application never provides frame rate information 
to driver.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/picture.c | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 4abf155..b187452 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -117,6 +117,13 @@ getEncParamPreset(vlVaContext *context)
context->desc.h264enc.rate_ctrl.fill_data_enable = 1;
context->desc.h264enc.rate_ctrl.enforce_hrd = 1;
context->desc.h264enc.enable_vui = false;
+   if (context->desc.h264enc.rate_ctrl.frame_rate_num == 0)
+  context->desc.h264enc.rate_ctrl.frame_rate_num = 30;
+   context->desc.h264enc.rate_ctrl.target_bits_picture =
+  context->desc.h264enc.rate_ctrl.target_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
+   context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
+  context->desc.h264enc.rate_ctrl.peak_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
+   context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0;
 
context->desc.h264enc.ref_pic_mode = 0x0201;
 }
@@ -319,16 +326,19 @@ handleVAEncMiscParameterTypeRateControl(vlVaContext 
*context, VAEncMiscParameter
   context->desc.h264enc.rate_ctrl.vbv_buffer_size = 
MIN2((context->desc.h264enc.rate_ctrl.target_bitrate * 2.75), 200);
else
   context->desc.h264enc.rate_ctrl.vbv_buffer_size = 
context->desc.h264enc.rate_ctrl.target_bitrate;
-   context->desc.h264enc.rate_ctrl.target_bits_picture =
-  context->desc.h264enc.rate_ctrl.target_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
-   context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
-  context->desc.h264enc.rate_ctrl.peak_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
-   context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0;
 
return VA_STATUS_SUCCESS;
 }
 
 static VAStatus
+handleVAEncMiscParameterTypeFrameRate(vlVaContext *context, 
VAEncMiscParameterBuffer *misc)
+{
+   VAEncMiscParameterFrameRate *fr = (VAEncMiscParameterFrameRate *)misc->data;
+   context->desc.h264enc.rate_ctrl.frame_rate_num = fr->framerate;
+   return VA_STATUS_SUCCESS;
+}
+
+static VAStatus
 handleVAEncSequenceParameterBufferType(vlVaDriver *drv, vlVaContext *context, 
vlVaBuffer *buf)
 {
VAEncSequenceParameterBufferH264 *h264 = (VAEncSequenceParameterBufferH264 
*)buf->data;
@@ -357,6 +367,10 @@ handleVAEncMiscParameterBufferType(vlVaContext *context, 
vlVaBuffer *buf)
   vaStatus = handleVAEncMiscParameterTypeRateControl(context, misc);
   break;
 
+   case VAEncMiscParameterTypeFrameRate:
+  vaStatus = handleVAEncMiscParameterTypeFrameRate(context, misc);
+  break;
+
default:
   break;
}
-- 
2.7.4

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

[Mesa-dev] [PATCH 9/9] st/va: enable h264 VAAPI encode

[Boyuan Zhang]

Enable H.264 VAAPI encoding through config. Currently only H.264 baseline is 
supported. Encode entrypoint is not accepted by driver.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/config.c | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index be151c8..aab01a0 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -74,6 +74,7 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx, VAProfile 
profile,
 {
struct pipe_screen *pscreen;
enum pipe_video_profile p;
+   int va_status = VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -90,12 +91,18 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx, VAProfile 
profile,
   return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
 
pscreen = VL_VA_PSCREEN(ctx);
-   if (!pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, 
PIPE_VIDEO_CAP_SUPPORTED))
-  return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
-
-   entrypoint_list[(*num_entrypoints)++] = VAEntrypointVLD;
+   if (pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, 
PIPE_VIDEO_CAP_SUPPORTED)) {
+  entrypoint_list[(*num_entrypoints)++] = VAEntrypointVLD;
+  va_status = VA_STATUS_SUCCESS;
+   }
+   if (pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_ENCODE, 
PIPE_VIDEO_CAP_SUPPORTED) &&
+   p == PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) {
+  entrypoint_list[(*num_entrypoints)++] = VAEntrypointEncSlice;
+  entrypoint_list[(*num_entrypoints)++] = VAEntrypointEncPicture;
+  va_status = VA_STATUS_SUCCESS;
+   }
 
-   return VA_STATUS_SUCCESS;
+   return va_status;;
 }
 
 VAStatus
@@ -114,7 +121,7 @@ vlVaGetConfigAttributes(VADriverContextP ctx, VAProfile 
profile, VAEntrypoint en
  value = VA_RT_FORMAT_YUV420;
  break;
   case VAConfigAttribRateControl:
- value = VA_RC_NONE;
+ value = VA_RC_CQP | VA_RC_CBR;
  break;
   default:
  value = VA_ATTRIB_NOT_SUPPORTED;
@@ -161,17 +168,20 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
   return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
 
pscreen = VL_VA_PSCREEN(ctx);
-   if (!pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, 
PIPE_VIDEO_CAP_SUPPORTED))
-  return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
-
-   if (entrypoint != VAEntrypointVLD)
+   if (entrypoint == VAEntrypointVLD) {
+  if (!pscreen->get_video_param(pscreen, p, 
PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_SUPPORTED))
+ return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
+   }
+   else if (entrypoint == VAEntrypointEncSlice) {
+  if (!pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_ENCODE, 
PIPE_VIDEO_CAP_SUPPORTED))
+ return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
+   }
+   else
   return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;
 
-#if 0
if (entrypoint == VAEntrypointEncSlice || entrypoint == 
VAEntrypointEncPicture)
   config->entrypoint = PIPE_VIDEO_ENTRYPOINT_ENCODE;
else
-#endif
   config->entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
 
config->profile = p;
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/9] vl/util: add copy func for yv12image to nv12surface

[Boyuan Zhang]

Add function to copy from yv12 image to nv12 surface for VAAPI putimage call. 
We need this function in VaPutImage call where copying from yv12 image to nv12 
surface for encoding. Existing function can't be used because it only work for 
copying from yv12 surface to nv12 image in Vaapi.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/auxiliary/util/u_video.h | 37 
 1 file changed, 37 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_video.h 
b/src/gallium/auxiliary/util/u_video.h
index 9196afc..86a7adc 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -130,6 +130,43 @@ u_copy_yv12_to_nv12(void *const *destination_data,
 }
 
 static inline void
+u_copy_yv12_img_to_nv12_surf(ubyte *const *src,
+ ubyte *dst,
+ unsigned width,
+ unsigned height,
+ unsigned src_stride,
+ unsigned dst_stride,
+ int field)
+{
+   if (field == 0) {
+  ubyte *src_0 = src[field];
+  for (int i = 0; i < height ; i++) {
+ memcpy(dst, src_0, width);
+ dst += dst_stride;
+ src_0 += src_stride;
+  }
+   } else if (field == 1) {
+  ubyte *src_1 = src[field];
+  ubyte *src_2 = src[field+1];
+  bool odd = false;
+  for (int i = 0; i < height ; i++) {
+ for (int j = 0; j < width*2 ; j++) {
+if (odd == false) {
+   dst[j] = src_1[j/2];
+   odd = true;
+} else {
+   dst[j] = src_2[j/2];
+   odd = false;
+}
+ }
+ dst += dst_stride;
+ src_1 += src_stride;
+ src_2 += src_stride;
+  }
+   }
+}
+
+static inline void
 u_copy_swap422_packed(void *const *destination_data,
uint32_t const *destination_pitches,
int src_plane, int src_field,
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/9] st/va: add encode entrypoint

[Boyuan Zhang]

VAAPI passes PIPE_VIDEO_ENTRYPOINT_ENCODE as entry point for encoding case. We 
will save this encode entry point in config. config_id was used as profile 
previously. Now, config has both profile and entrypoint field, and config_id is 
used to get the config object. Later on, we pass this entrypoint to 
context->templat.entrypoint instead of always hardcoded to 
PIPE_VIDEO_ENTRYPOINT_BITSTREAM for decoding case previously. Encode entrypoint 
is not accepted by driver until we enable Vaapi encode in later patch.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/config.c | 71 +++---
 src/gallium/state_trackers/va/context.c| 59 +++--
 src/gallium/state_trackers/va/surface.c| 14 --
 src/gallium/state_trackers/va/va_private.h |  5 +++
 4 files changed, 117 insertions(+), 32 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 9ca0aa8..3aacc63 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -34,6 +34,8 @@
 
 #include "va_private.h"
 
+#include "util/u_handle_table.h"
+
 DEBUG_GET_ONCE_BOOL_OPTION(mpeg4, "VAAPI_MPEG4_ENABLED", false)
 
 VAStatus
@@ -128,14 +130,29 @@ VAStatus
 vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint 
entrypoint,
  VAConfigAttrib *attrib_list, int num_attribs, VAConfigID 
*config_id)
 {
+   vlVaDriver *drv;
+   vlVaConfig *config;
struct pipe_screen *pscreen;
enum pipe_video_profile p;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
+   drv = VL_VA_DRIVER(ctx);
+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   config = CALLOC(1, sizeof(vlVaConfig));
+   if (!config)
+  return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) {
-  *config_id = PIPE_VIDEO_PROFILE_UNKNOWN;
+  config->entrypoint = VAEntrypointVideoProc;
+  config->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
+  pipe_mutex_lock(drv->mutex);
+  *config_id = handle_table_add(drv->htab, config);
+  pipe_mutex_unlock(drv->mutex);
   return VA_STATUS_SUCCESS;
}
 
@@ -150,7 +167,18 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
if (entrypoint != VAEntrypointVLD)
   return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;
 
-   *config_id = p;
+#if 0
+   if (entrypoint == VAEntrypointEncSlice || entrypoint == 
VAEntrypointEncPicture)
+  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_ENCODE;
+   else
+#endif
+  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
+
+   config->profile = p;
+
+   pipe_mutex_lock(drv->mutex);
+   *config_id = handle_table_add(drv->htab, config);
+   pipe_mutex_unlock(drv->mutex);
 
return VA_STATUS_SUCCESS;
 }
@@ -158,9 +186,27 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
 VAStatus
 vlVaDestroyConfig(VADriverContextP ctx, VAConfigID config_id)
 {
+   vlVaDriver *drv;
+   vlVaConfig *config;
+
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
+   drv = VL_VA_DRIVER(ctx);
+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   pipe_mutex_lock(drv->mutex);
+   config = handle_table_get(drv->htab, config_id);
+
+   if (!config)
+  return VA_STATUS_ERROR_INVALID_CONFIG;
+
+   FREE(config);
+   handle_table_remove(drv->htab, config_id);
+   pipe_mutex_unlock(drv->mutex);
+
return VA_STATUS_SUCCESS;
 }
 
@@ -168,18 +214,33 @@ VAStatus
 vlVaQueryConfigAttributes(VADriverContextP ctx, VAConfigID config_id, 
VAProfile *profile,
   VAEntrypoint *entrypoint, VAConfigAttrib 
*attrib_list, int *num_attribs)
 {
+   vlVaDriver *drv;
+   vlVaConfig *config;
+
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-   *profile = PipeToProfile(config_id);
+   drv = VL_VA_DRIVER(ctx);
+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   pipe_mutex_lock(drv->mutex);
+   config = handle_table_get(drv->htab, config_id);
+   pipe_mutex_unlock(drv->mutex);
+
+   if (!config)
+  return VA_STATUS_ERROR_INVALID_CONFIG;
+
+   *profile = PipeToProfile(config->profile);
 
-   if (config_id == PIPE_VIDEO_PROFILE_UNKNOWN) {
+   if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
   *entrypoint = VAEntrypointVideoProc;
   *num_attribs = 0;
   return VA_STATUS_SUCCESS;
}
 
-   *entrypoint = VAEntrypointVLD;
+   *entrypoint = config->entrypoint;
 
*num_attribs = 1;
attrib_list[0].type = VAConfigAttribRTFormat;
diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 402fbb2..8882cba 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -195,18 +195,23 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
 {
vlVaDriver *drv;
vlVaContext 

Re: [Mesa-dev] [PATCH 07/10] egl/android: Make drm_gralloc headers optional

[Stéphane Marchesin]

On Tue, Jul 19, 2016 at 6:36 AM, Rob Clark  wrote:
> On Tue, Jul 19, 2016 at 6:54 AM, Emil Velikov  
> wrote:
>> On 19 July 2016 at 04:21, Tomasz Figa  wrote:
>>> On Tue, Jul 19, 2016 at 2:35 AM, Emil Velikov  
>>> wrote:
 On 18 July 2016 at 16:38, Tomasz Figa  wrote:
> On Mon, Jul 18, 2016 at 11:58 PM, Emil Velikov  
> wrote:
>> On 18 July 2016 at 13:02, Tomasz Figa  wrote:
>>> On Mon, Jul 18, 2016 at 7:28 PM, Emil Velikov 
>>>  wrote:
 Hi Tomasz,

 On 15 July 2016 at 08:53, Tomasz Figa  wrote:

> +#define DRM_RENDER_DEV_NAME  "%s/renderD%d"
> +
> +static int
> +droid_open_device(_EGLDisplay *dpy)
> +{
> +   struct dri2_egl_display *dri2_dpy = dpy->DriverData;
> +   const int limit = 64;
> +   const int base = 128;
> +   int fd;
> +   int i;
> +
> +   for (i = 0; i < limit; ++i) {
> +  char *card_path;
> +  if (asprintf(_path, DRM_RENDER_DEV_NAME, DRM_DIR_NAME, 
> base + i) < 0)
 Why do we need any of this ? What gralloc implementation are you guys 
 using ?
>>>
>>> We are using our heavily rewritten fork of some old drm_gralloc
>>> release. It supports only render nodes and PRIME FDs and doesn't
>>> export the DRI device FD outside of its internals (which isn't
>>> actually even fully correct, at least for PRIME and render nodes, see
>>> my reply to Rob's comments).
>>>
>> That explain it, since https://chromium.googlesource.com/ does not
>> have gralloc, and
>> https://android.googlesource.com/platform/external/drm_gralloc/ has
>> both the DRM_FD define and the gem/flink function(s)?
>>
>> Can I suggest porting the fd drm_gralloc/gbm_gralloc patches to your
>> private copy/repo. This way we'll have some consistency throughout
>> gralloc implementations
>
> I'd prefer if any code using flink names was not added back. On top of
> that, our drm_gralloc doesn't really have much in common with that
> from android-x86 anymore (as I said, it was heavily rewritten) and
> there is not even a chance that with its current design flink names
> could even work.
>
> Also I'm wondering why we want to consider current brokenness of
> drm_gralloc as something to be consistent with. It's supposed to be a
> HAL library providing an uniform abstraction, but it exports private
> APIs on the side instead. Moreover, as I mentioned before, flink names
> are considered insecure and it would be really much better if we could
> just forget about them.
>
>> and you can use gbm_gralloc directly in the
>> (hopefully) not too distant future.
>
> I agree with this part, though. gbm_gralloc is definitely something
> that we might want to migrate to in the future. Although it's a bit
> lacking at the moment, so it might need a bit more time to develop the
> missing bits. [I'm CCing Gurchetan, who was investigating GBM-backed
> gralloc usable for our purposes.]
>
> In any case, the missing flink API is quite easy to handle and can be
> just stubbed out in a local header as you suggested. I don't think it
> would hurt anyone and would definitely help us and anyone not willing
> to export any private APIs from their gralloc and rely only on the
> public HAL API.
>
 Looks like I wasn't clear enough here, realyl sorry about that. No
 objection on nuking _any_ of the gem/flink paths, but hoping to have
 the behaviour consistent with the one described in
 get_native_buffer_fd.
>>>
>>> Did you mean having the PRIME FD in native_handle_t::data[0]?
>>>
>>> If so, it's more or less guaranteed by the API, because all file
>>> descriptors in handle have to be stored in first N (equals to
>>> native_handle_t::numFds) ints of native_handle_t::data[] for
>>> respective general code to properly transfer the FDs through binder
>>> when sharing between processes.
>>>
>>> Our gralloc currently supports only one PRIME FD per buffer (no
>>> separate memory planes for planar YUV) and stores it exactly in
>>> native_handle_t::data[0].
>>>
>> Wasn't sure if the PRIME FD is at idx 0. Glad to hear it's there, thanks.
>>

>>

 Afaict the latter must provide reasonable result for
 hw_get_module(GRALLOC_HARDWARE_MODULE_ID...) and as it's missing the
 perform hook existing code should work just fine. Right ?
>>>
>>> Existing code would fail with -1 as file descriptor, wouldn't it? Or
>>> I'm failing to see something?
>>>
>> Nope you're spot on - I had a dull moment. May I suggest revering the
>> patch which removed 

Re: [Mesa-dev] [PATCH] nvc0/mme: fix offsets used for indirect draws

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

On Thu, Jul 21, 2016 at 4:15 PM, Samuel Pitoiset
 wrote:
> This fixes a regression introduced in
> 1da704a94c57aa0b0cf8faaa3236fe47dfb8f88c because the offset has moved
> from 0x180 to 0x1a0, and the macros have to be re-compiled.
>
> Fixes: 1da704a ("nvc0: increase the tex handles area size in the driver")
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/nvc0/mme/com9097.mme   | 8 
>  src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme 
> b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
> index 7f76ec6..11c2056 100644
> --- a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
> +++ b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
> @@ -255,7 +255,7 @@ dei_draw_again:
> parm $r4 maddr 0x5f7 /* INDEX_BATCH_FIRST, start */
> parm $r4 send $r4 /* index_bias, send start */
> maddr 0x18e3 /* CB_POS */
> -   send 0x180 /* 256 + 128 */
> +   send 0x1a0 /* 256 + 160 */
> braz $r2 #dei_end
> parm $r5 send $r4 /* start_instance, send index_bias */
> send $r5 /* send start_instance */
> @@ -311,7 +311,7 @@ dai_draw_again:
> braz $r3 #dai_end
> parm $r4 send $r4 /* start_instance */
> maddr 0x18e3 /* CB_POS */
> -   send 0x180 /* 256 + 128 */
> +   send 0x1a0 /* 256 + 160 */
> send 0x0 /* send 0 as base_vertex */
> send $r4 /* send start_instance */
> send $r6 /* draw id */
> @@ -374,7 +374,7 @@ deic_draw_again:
> parm $r4 maddr 0x5f7 /* INDEX_BATCH_FIRST, start */
> parm $r4 send $r4 /* index_bias, send start */
> maddr 0x18e3 /* CB_POS */
> -   send 0x180 /* 256 + 128 */
> +   send 0x1a0 /* 256 + 160 */
> braz $r2 #deic_end
> parm $r5 send $r4 /* start_instance, send index_bias */
> send $r5 /* send start_instance */
> @@ -455,7 +455,7 @@ daic_draw_again:
> braz $r3 #daic_end
> parm $r4 send $r4 /* start_instance */
> maddr 0x18e3 /* CB_POS */
> -   send 0x180 /* 256 + 128 */
> +   send 0x1a0 /* 256 + 160 */
> send 0x0 /* send 0 as base_vertex */
> send $r4 /* send start_instance */
> send $r6 /* draw id */
> diff --git a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h 
> b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
> index ecadf7e..1c8f4bb 100644
> --- a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
> +++ b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
> @@ -140,7 +140,7 @@ uint32_t mme9097_draw_elts_indirect[] = {
> 0x017dc451,
> 0x2431,
> 0x0638c021,
> -   0x00600041,
> +   0x00680041,
> 0x0004d007,
> 0x2531,
> 0x2841,
> @@ -185,7 +185,7 @@ uint32_t mme9097_draw_arrays_indirect[] = {
> 0x0004d807,
> 0x2431,
> 0x0638c021,
> -   0x00600041,
> +   0x00680041,
> 0x0041,
> 0x2041,
> 0x3041,
> @@ -233,7 +233,7 @@ uint32_t mme9097_draw_elts_indirect_count[] = {
> 0x017dc451,
> 0x2431,
> 0x0638c021,
> -   0x00600041,
> +   0x00680041,
> 0x0004d007,
> 0x2531,
> 0x2841,
> @@ -300,7 +300,7 @@ uint32_t mme9097_draw_arrays_indirect_count[] = {
> 0x0004d807,
> 0x2431,
> 0x0638c021,
> -   0x00600041,
> +   0x00680041,
> 0x0041,
> 0x2041,
> 0x3041,
> --
> 2.8.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nvc0: fix offsets of MP perf counters input parameters

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

On Thu, Jul 21, 2016 at 4:15 PM, Samuel Pitoiset
 wrote:
> This fixes a regression introduced in
> 1da704a94c57aa0b0cf8faaa3236fe47dfb8f88c because the offset has moved
> from 0x600 to 0x620, and the kernels used for reading MP perf counters
> have to be re-assembled.
>
> This also fixes amd_performance_monitor_measure piglit.
>
> Fixes: 1da704a ("nvc0: increase the tex handles area size in the driver")
> Signed-off-by: Samuel Pitoiset 
> ---
>  .../drivers/nouveau/nvc0/nvc0_query_hw_sm.c| 30 
> +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
> index 944349d..d472120 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
> @@ -372,9 +372,9 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
>  * mov b32 $r6 $pm6
>  * mov b32 $r7 $pm7
>  * set $p0 0x1 eq u32 $r8 0x0
> -* mov b32 $r10 c7[0x600]
> +* mov b32 $r10 c7[0x620]
>  * ext u32 $r8 $r12 0x414
> -* mov b32 $r11 c7[0x604]
> +* mov b32 $r11 c7[0x624]
>  * sched 0x04 0x2e 0x04 0x20 0x20 0x28 0x04
>  * ext u32 $r9 $r12 0x208
>  * (not $p0) exit
> @@ -392,7 +392,7 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
>  * add b32 $r12 $c $r12 $r9
>  * st b128 wt g[$r10d] $r0q
>  * sched 0x4 0x2c 0x20 0x04 0x2e 0x00 0x00
> -* mov b32 $r0 c7[0x608]
> +* mov b32 $r0 c7[0x628]
>  * add b32 $r13 $r13 0x0 $c
>  * $p1 st b128 wt g[$r12d+0x40] $r4q
>  * st b32 wt g[$r12d+0x50] $r0
> @@ -410,9 +410,9 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
> 0x2c0028019c04ULL,
> 0x2c002c01dc04ULL,
> 0x190efc81dc03ULL,
> -   0x28005c1800029de4ULL,
> +   0x28005c1880029de4ULL,
> 0x7000c01050c21c03ULL,
> -   0x28005c181002dde4ULL,
> +   0x28005c189002dde4ULL,
> 0x204282020042e047ULL,
> 0x7000c00820c25c03ULL,
> 0x800021e7ULL,
> @@ -430,7 +430,7 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
> 0x480124c31c03ULL,
> 0x94a01fc5ULL,
> 0x22e04202c047ULL,
> -   0x28005c1820001de4ULL,
> +   0x28005c18a0001de4ULL,
> 0x08d35c42ULL,
> 0x940100c107c5ULL,
> 0x940140c01f85ULL,
> @@ -453,9 +453,9 @@ static const uint64_t nvf0_read_hw_sm_counters_code[] =
> 0x8640051c001aULL,
> 0x8640059c001eULL,
> 0xdb201c007f9c201eULL,
> -   0x64c03ce0c01c002aULL,
> +   0x64c03ce0c41c002aULL,
> 0xc0020a1c3021ULL,
> -   0x64c03ce0c09c002eULL,
> +   0x64c03ce0c49c002eULL,
> 0x0810a0808010b810ULL,
> 0xc001041c3025ULL,
> 0x1820003cULL,
> @@ -473,7 +473,7 @@ static const uint64_t nvf0_read_hw_sm_counters_code[] =
> 0xe084049c3032ULL,
> 0xfe80001c2800ULL,
> 0x08b81080b010ULL,
> -   0x64c03ce0c11c0002ULL,
> +   0x64c03ce0c51c0002ULL,
> 0xe08040007f9c3436ULL,
> 0xfe8020043010ULL,
> 0xfc80281c3000ULL,
> @@ -1105,14 +1105,14 @@ static const uint64_t nvc0_read_hw_sm_counters_code[] 
> =
>  * mov b32 $r6 $pm6
>  * mov b32 $r7 $pm7
>  * set $p0 0x1 eq u32 $r8 0x0
> -* mov b32 $r10 c15[0x600]
> -* mov b32 $r11 c15[0x604]
> +* mov b32 $r10 c15[0x620]
> +* mov b32 $r11 c15[0x624]
>  * ext u32 $r8 $r9 0x414
>  * (not $p0) exit
>  * mul $r8 u32 $r8 u32 48
>  * add b32 $r10 $c $r10 $r8
>  * add b32 $r11 $r11 0x0 $c
> -* mov b32 $r8 c15[0x608]
> +* mov b32 $r8 c15[0x628]
>  * st b128 wt g[$r10d+0x00] $r0q
>  * st b128 wt g[$r10d+0x10] $r4q
>  * st b32 wt g[$r10d+0x20] $r8
> @@ -1128,14 +1128,14 @@ static const uint64_t nvc0_read_hw_sm_counters_code[] 
> =
> 0x2c0028019c04ULL,
> 0x2c002c01dc04ULL,
> 0x190efc81dc03ULL,
> -   0x28007c1800029de4ULL,
> -   0x28007c181002dde4ULL,
> +   0x28007c1880029de4ULL,
> +   0x28007c189002dde4ULL,
> 0x7000c01050921c03ULL,
> 0x800021e7ULL,
> 0x1000c0821c02ULL,
> 0x480120a29c03ULL,
> 0x08b2dc42ULL,
> -   0x28007c1820021de4ULL,
> +   0x28007c18a0021de4ULL,
> 0x94a01fc5ULL,
> 0x940040a11fc5ULL,
> 0x940080a21f85ULL,
> --
> 2.8.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 6/9] st/mesa: remove excessive shader state dirtying

[Marek Olšák]

From: Marek Olšák 

This just needs to be done by st_validate_state.

v2: add "shaders_may_be_dirty" flags for not skipping st_validate_state
on _NEW_PROGRAM to detect real shader changes
---
 src/mesa/state_tracker/st_atom.c   | 13 +
 src/mesa/state_tracker/st_cb_bitmap.c  |  3 +-
 src/mesa/state_tracker/st_cb_compute.c |  3 +-
 src/mesa/state_tracker/st_cb_program.c | 53 --
 src/mesa/state_tracker/st_context.c|  6 
 src/mesa/state_tracker/st_context.h|  6 
 src/mesa/state_tracker/st_draw.c   |  6 ++--
 7 files changed, 33 insertions(+), 57 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom.c b/src/mesa/state_tracker/st_atom.c
index ef50ef9..06c523e 100644
--- a/src/mesa/state_tracker/st_atom.c
+++ b/src/mesa/state_tracker/st_atom.c
@@ -72,6 +72,14 @@ static void check_program_state( struct st_context *st )
 
if (ctx->GeometryProgram._Current != >gp->Base)
   st->dirty |= ST_NEW_GEOMETRY_PROGRAM;
+
+   if (ctx->TessCtrlProgram._Current != >tcp->Base)
+  st->dirty |= ST_NEW_TESSCTRL_PROGRAM;
+
+   if (ctx->TessEvalProgram._Current != >tep->Base)
+  st->dirty |= ST_NEW_TESSEVAL_PROGRAM;
+
+   st->gfx_shaders_may_be_dirty = false;
 }
 
 static void check_attrib_edgeflag(struct st_context *st)
@@ -135,8 +143,13 @@ void st_validate_state( struct st_context *st, enum 
st_pipeline pipeline )
  pipeline_mask &= ~ST_NEW_GS_RESOURCES;
   if (!ctx->Transform.ClipPlanesEnabled)
  pipeline_mask &= ~ST_NEW_CLIP_STATE;
+
   break;
case ST_PIPELINE_COMPUTE:
+  if (ctx->ComputeProgram._Current != >cp->Base)
+ st->dirty |= ST_NEW_COMPUTE_PROGRAM;
+
+  st->compute_shader_may_be_dirty = false;
   pipeline_mask = ST_PIPELINE_COMPUTE_STATE_MASK;
   break;
default:
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c 
b/src/mesa/state_tracker/st_cb_bitmap.c
index 5765ed2..0ee19fd 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -647,7 +647,8 @@ st_Bitmap(struct gl_context *ctx, GLint x, GLint y,
 * explicitly uploaded in the draw_bitmap_quad() function.
 */
if ((st->dirty | ctx->NewDriverState) & ~ST_NEW_CONSTANTS &
-   ST_PIPELINE_RENDER_STATE_MASK) {
+   ST_PIPELINE_RENDER_STATE_MASK ||
+   st->gfx_shaders_may_be_dirty) {
   st_validate_state(st, ST_PIPELINE_RENDER);
}
 
diff --git a/src/mesa/state_tracker/st_cb_compute.c 
b/src/mesa/state_tracker/st_cb_compute.c
index 677507d..88c1ee2 100644
--- a/src/mesa/state_tracker/st_cb_compute.c
+++ b/src/mesa/state_tracker/st_cb_compute.c
@@ -51,7 +51,8 @@ static void st_dispatch_compute_common(struct gl_context *ctx,
if (ctx->NewState)
   _mesa_update_state(ctx);
 
-   if ((st->dirty | ctx->NewDriverState) & ST_PIPELINE_COMPUTE_STATE_MASK)
+   if ((st->dirty | ctx->NewDriverState) & ST_PIPELINE_COMPUTE_STATE_MASK ||
+   st->compute_shader_may_be_dirty)
   st_validate_state(st, ST_PIPELINE_COMPUTE);
 
for (unsigned i = 0; i < 3; i++) {
diff --git a/src/mesa/state_tracker/st_cb_program.c 
b/src/mesa/state_tracker/st_cb_program.c
index 6264896..8291edb 100644
--- a/src/mesa/state_tracker/st_cb_program.c
+++ b/src/mesa/state_tracker/st_cb_program.c
@@ -49,57 +49,6 @@
 #include "st_atifs_to_tgsi.h"
 
 
-
-/**
- * Called via ctx->Driver.BindProgram() to bind an ARB vertex or
- * fragment program.
- */
-static void
-st_bind_program(struct gl_context *ctx, GLenum target, struct gl_program *prog)
-{
-   struct st_context *st = st_context(ctx);
-
-   switch (target) {
-   case GL_VERTEX_PROGRAM_ARB: 
-  st->dirty |= ST_NEW_VERTEX_PROGRAM;
-  break;
-   case GL_FRAGMENT_PROGRAM_ARB:
-  st->dirty |= ST_NEW_FRAGMENT_PROGRAM;
-  break;
-   case GL_GEOMETRY_PROGRAM_NV:
-  st->dirty |= ST_NEW_GEOMETRY_PROGRAM;
-  break;
-   case GL_TESS_CONTROL_PROGRAM_NV:
-  st->dirty |= ST_NEW_TESSCTRL_PROGRAM;
-  break;
-   case GL_TESS_EVALUATION_PROGRAM_NV:
-  st->dirty |= ST_NEW_TESSEVAL_PROGRAM;
-  break;
-   case GL_COMPUTE_PROGRAM_NV:
-  st->dirty |= ST_NEW_COMPUTE_PROGRAM;
-  break;
-   }
-}
-
-
-/**
- * Called via ctx->Driver.UseProgram() to bind a linked GLSL program
- * (vertex shader + fragment shader).
- */
-static void
-st_use_program(struct gl_context *ctx, struct gl_shader_program *shProg)
-{
-   struct st_context *st = st_context(ctx);
-
-   st->dirty |= ST_NEW_FRAGMENT_PROGRAM;
-   st->dirty |= ST_NEW_VERTEX_PROGRAM;
-   st->dirty |= ST_NEW_GEOMETRY_PROGRAM;
-   st->dirty |= ST_NEW_TESSCTRL_PROGRAM;
-   st->dirty |= ST_NEW_TESSEVAL_PROGRAM;
-   st->dirty |= ST_NEW_COMPUTE_PROGRAM;
-}
-
-
 /**
  * Called via ctx->Driver.NewProgram() to allocate a new vertex or
  * fragment program.
@@ -347,8 +296,6 @@ st_new_ati_fs(struct gl_context *ctx, struct 
ati_fragment_shader *curProg)
 void
 st_init_program_functions(struct dd_function_table *functions)
 {
-   functions->BindProgram = 

[Mesa-dev] [Bug 89599] symbol 'x86_64_entry_start' is already defined when building with LLVM/clang

[bugzilla-daemon]

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

--- Comment #14 from Tomasz Paweł Gajc  ---
(In reply to Matt Turner from comment #11)
> I sent a modified version of Tomasz's patch last week to mesa-dev.
> 
> Would anyone like to test it?
> 
> [PATCH] mapi: Massage code to allow clang to compile.

Thanks for this patch. It work fine with LLVM/clang-3.8.1 !

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

[Mesa-dev] [PATCH] nvc0/mme: fix offsets used for indirect draws

[Samuel Pitoiset]

This fixes a regression introduced in
1da704a94c57aa0b0cf8faaa3236fe47dfb8f88c because the offset has moved
from 0x180 to 0x1a0, and the macros have to be re-compiled.

Fixes: 1da704a ("nvc0: increase the tex handles area size in the driver")
Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nvc0/mme/com9097.mme   | 8 
 src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme 
b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
index 7f76ec6..11c2056 100644
--- a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
+++ b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
@@ -255,7 +255,7 @@ dei_draw_again:
parm $r4 maddr 0x5f7 /* INDEX_BATCH_FIRST, start */
parm $r4 send $r4 /* index_bias, send start */
maddr 0x18e3 /* CB_POS */
-   send 0x180 /* 256 + 128 */
+   send 0x1a0 /* 256 + 160 */
braz $r2 #dei_end
parm $r5 send $r4 /* start_instance, send index_bias */
send $r5 /* send start_instance */
@@ -311,7 +311,7 @@ dai_draw_again:
braz $r3 #dai_end
parm $r4 send $r4 /* start_instance */
maddr 0x18e3 /* CB_POS */
-   send 0x180 /* 256 + 128 */
+   send 0x1a0 /* 256 + 160 */
send 0x0 /* send 0 as base_vertex */
send $r4 /* send start_instance */
send $r6 /* draw id */
@@ -374,7 +374,7 @@ deic_draw_again:
parm $r4 maddr 0x5f7 /* INDEX_BATCH_FIRST, start */
parm $r4 send $r4 /* index_bias, send start */
maddr 0x18e3 /* CB_POS */
-   send 0x180 /* 256 + 128 */
+   send 0x1a0 /* 256 + 160 */
braz $r2 #deic_end
parm $r5 send $r4 /* start_instance, send index_bias */
send $r5 /* send start_instance */
@@ -455,7 +455,7 @@ daic_draw_again:
braz $r3 #daic_end
parm $r4 send $r4 /* start_instance */
maddr 0x18e3 /* CB_POS */
-   send 0x180 /* 256 + 128 */
+   send 0x1a0 /* 256 + 160 */
send 0x0 /* send 0 as base_vertex */
send $r4 /* send start_instance */
send $r6 /* draw id */
diff --git a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h 
b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
index ecadf7e..1c8f4bb 100644
--- a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
+++ b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
@@ -140,7 +140,7 @@ uint32_t mme9097_draw_elts_indirect[] = {
0x017dc451,
0x2431,
0x0638c021,
-   0x00600041,
+   0x00680041,
0x0004d007,
0x2531,
0x2841,
@@ -185,7 +185,7 @@ uint32_t mme9097_draw_arrays_indirect[] = {
0x0004d807,
0x2431,
0x0638c021,
-   0x00600041,
+   0x00680041,
0x0041,
0x2041,
0x3041,
@@ -233,7 +233,7 @@ uint32_t mme9097_draw_elts_indirect_count[] = {
0x017dc451,
0x2431,
0x0638c021,
-   0x00600041,
+   0x00680041,
0x0004d007,
0x2531,
0x2841,
@@ -300,7 +300,7 @@ uint32_t mme9097_draw_arrays_indirect_count[] = {
0x0004d807,
0x2431,
0x0638c021,
-   0x00600041,
+   0x00680041,
0x0041,
0x2041,
0x3041,
-- 
2.8.0

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

[Mesa-dev] [PATCH] nvc0: fix offsets of MP perf counters input parameters

[Samuel Pitoiset]

This fixes a regression introduced in
1da704a94c57aa0b0cf8faaa3236fe47dfb8f88c because the offset has moved
from 0x600 to 0x620, and the kernels used for reading MP perf counters
have to be re-assembled.

This also fixes amd_performance_monitor_measure piglit.

Fixes: 1da704a ("nvc0: increase the tex handles area size in the driver")
Signed-off-by: Samuel Pitoiset 
---
 .../drivers/nouveau/nvc0/nvc0_query_hw_sm.c| 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
index 944349d..d472120 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
@@ -372,9 +372,9 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
 * mov b32 $r6 $pm6
 * mov b32 $r7 $pm7
 * set $p0 0x1 eq u32 $r8 0x0
-* mov b32 $r10 c7[0x600]
+* mov b32 $r10 c7[0x620]
 * ext u32 $r8 $r12 0x414
-* mov b32 $r11 c7[0x604]
+* mov b32 $r11 c7[0x624]
 * sched 0x04 0x2e 0x04 0x20 0x20 0x28 0x04
 * ext u32 $r9 $r12 0x208
 * (not $p0) exit
@@ -392,7 +392,7 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
 * add b32 $r12 $c $r12 $r9
 * st b128 wt g[$r10d] $r0q
 * sched 0x4 0x2c 0x20 0x04 0x2e 0x00 0x00
-* mov b32 $r0 c7[0x608]
+* mov b32 $r0 c7[0x628]
 * add b32 $r13 $r13 0x0 $c
 * $p1 st b128 wt g[$r12d+0x40] $r4q
 * st b32 wt g[$r12d+0x50] $r0
@@ -410,9 +410,9 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
0x2c0028019c04ULL,
0x2c002c01dc04ULL,
0x190efc81dc03ULL,
-   0x28005c1800029de4ULL,
+   0x28005c1880029de4ULL,
0x7000c01050c21c03ULL,
-   0x28005c181002dde4ULL,
+   0x28005c189002dde4ULL,
0x204282020042e047ULL,
0x7000c00820c25c03ULL,
0x800021e7ULL,
@@ -430,7 +430,7 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
0x480124c31c03ULL,
0x94a01fc5ULL,
0x22e04202c047ULL,
-   0x28005c1820001de4ULL,
+   0x28005c18a0001de4ULL,
0x08d35c42ULL,
0x940100c107c5ULL,
0x940140c01f85ULL,
@@ -453,9 +453,9 @@ static const uint64_t nvf0_read_hw_sm_counters_code[] =
0x8640051c001aULL,
0x8640059c001eULL,
0xdb201c007f9c201eULL,
-   0x64c03ce0c01c002aULL,
+   0x64c03ce0c41c002aULL,
0xc0020a1c3021ULL,
-   0x64c03ce0c09c002eULL,
+   0x64c03ce0c49c002eULL,
0x0810a0808010b810ULL,
0xc001041c3025ULL,
0x1820003cULL,
@@ -473,7 +473,7 @@ static const uint64_t nvf0_read_hw_sm_counters_code[] =
0xe084049c3032ULL,
0xfe80001c2800ULL,
0x08b81080b010ULL,
-   0x64c03ce0c11c0002ULL,
+   0x64c03ce0c51c0002ULL,
0xe08040007f9c3436ULL,
0xfe8020043010ULL,
0xfc80281c3000ULL,
@@ -1105,14 +1105,14 @@ static const uint64_t nvc0_read_hw_sm_counters_code[] =
 * mov b32 $r6 $pm6
 * mov b32 $r7 $pm7
 * set $p0 0x1 eq u32 $r8 0x0
-* mov b32 $r10 c15[0x600]
-* mov b32 $r11 c15[0x604]
+* mov b32 $r10 c15[0x620]
+* mov b32 $r11 c15[0x624]
 * ext u32 $r8 $r9 0x414
 * (not $p0) exit
 * mul $r8 u32 $r8 u32 48
 * add b32 $r10 $c $r10 $r8
 * add b32 $r11 $r11 0x0 $c
-* mov b32 $r8 c15[0x608]
+* mov b32 $r8 c15[0x628]
 * st b128 wt g[$r10d+0x00] $r0q
 * st b128 wt g[$r10d+0x10] $r4q
 * st b32 wt g[$r10d+0x20] $r8
@@ -1128,14 +1128,14 @@ static const uint64_t nvc0_read_hw_sm_counters_code[] =
0x2c0028019c04ULL,
0x2c002c01dc04ULL,
0x190efc81dc03ULL,
-   0x28007c1800029de4ULL,
-   0x28007c181002dde4ULL,
+   0x28007c1880029de4ULL,
+   0x28007c189002dde4ULL,
0x7000c01050921c03ULL,
0x800021e7ULL,
0x1000c0821c02ULL,
0x480120a29c03ULL,
0x08b2dc42ULL,
-   0x28007c1820021de4ULL,
+   0x28007c18a0021de4ULL,
0x94a01fc5ULL,
0x940040a11fc5ULL,
0x940080a21f85ULL,
-- 
2.8.0

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

Re: [Mesa-dev] [PATCH] glsl: subroutine types cannot be compared

[Dave Airlie]

> On Mon, 2016-07-18 at 16:39 +0300, Andres Gomez wrote:
>> subroutine variables are to be used just in the way functions are
>> called. Although the spec doesn't say it explicitely, this means that
>> these variables are not to be used in any other way than those left
>> for function calls. Therefore, a comparison between 2 subroutine
>> variables should also cause a compilation error.
>>
>> From The OpenGL® Shading Language 4.40, page 117:
>>
>>   "  To use subroutines, a subroutine type is declared, one or more
>>  functions are associated with that subroutine type, and a
>>  subroutine variable of that type is declared. The function
>>  currently assigned to the variable function is then called by
>>  using function calling syntax replacing a function name with the
>>  name of the subroutine variable. Subroutine variables are
>>  uniforms, and are assigned to specific functions only through
>>  commands (UniformSubroutinesuiv) in the OpenGL API."
>>
>> From The OpenGL® Shading Language 4.40, page 118:
>>
>>   "  Subroutine uniform variables are called the same way functions
>>  are called. When a subroutine variable (or an element of a
>>  subroutine variable array) is associated with a particular
>>  function, all function calls through that variable will call that
>>  particular function."
>>
>> Fixes 
>> GL44-CTS.shader_subroutine.subroutines_cannot_be_assigned_float_int_values_or_be_compared
>>
>> Signed-off-by: Andres Gomez 

I prefer this one, please push it with Ian's r-b, and consider my one withdrawn.

Reviewed-by: Dave Airlie 

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

Re: [Mesa-dev] [PATCH] glsl/ast: don't allow subroutine uniform comparisons

[Ian Romanick]

On 07/19/2016 01:45 PM, Ian Romanick wrote:
> On 07/19/2016 06:54 AM, Andres Gomez wrote:
>> Hi,
>>
>> Just dropped:
>> https://lists.freedesktop.org/archives/mesa-dev/2016-July/123485.html
>>
>> I didn't realize there was already this thread open.
>>
>> On Tue, 2016-06-07 at 09:59 -0700, Ian Romanick wrote:
>>> On 06/06/2016 10:20 PM, Dave Airlie wrote:
 From: Dave Airlie 

 This fixes:
 GL45-CTS.shader_subroutine.subroutines_cannot_be_assigned_float_int_values_or_be_compared

 though I'm not 100% sure why this is illegal from the spec,
 but it makes us pass the test, and I really can't see a use case for this.
>>>
>>> I think the test is wrong.  Section 5.9 (Expressions) of the GLSL 4.5
>>> spec clearly says:
>>>
>>> The equality operators equal (==), and not equal (!=) operate on
>>> all types (except aggregates that contain opaque types).
>>
>> In my opinion, the specs are somehow contradictory or not completely
>> clear.
>>
>> AFAIU, subroutine variables are to be used just in the way functions
>> are called. Although the spec doesn't say it explicitly, this means
>> that these variables are not to be used in any other way than those
>> left for function calls. Therefore, a comparison between 2 subroutine
>> variables should also cause a compilation error.
>>
>> From The OpenGL® Shading Language 4.40, page 117:
>>
>>   "  To use subroutines, a subroutine type is declared, one or more
>>  functions are associated with that subroutine type, and a
>>  subroutine variable of that type is declared. The function
>>  currently assigned to the variable function is then called by
>>  using function calling syntax replacing a function name with the
>>  name of the subroutine variable. Subroutine variables are
>>  uniforms, and are assigned to specific functions only through
>>  commands (UniformSubroutinesuiv) in the OpenGL API."
>>
>> From The OpenGL® Shading Language 4.40, page 118:
>>
>>   "  Subroutine uniform variables are called the same way functions
>>  are called. When a subroutine variable (or an element of a
>>  subroutine variable array) is associated with a particular
>>  function, all function calls through that variable will call that
>>  particular function."
>>
>>> As much as anyone would use subroutines, you could imagine this being
>>> used like:
>>>
>>> value = foo(param1, param2);
>>> if (foo != bar)
>>> value += bar(param1, param2);
>>
>> If that would be the case, and we agree that subroutines can be
>> compared, then we have, at least, some other bug to correct.
>>
>> I've made some piglit tests with the following scenarios:
>>  * == comparison result:
>> * foo and bar point to the same subroutine function -> false
>> * foo and bar point to different subroutine functions -> false
>>  * != comparison result:
>> * foo and bar point to the same subroutine function -> false
>> * foo and bar point to different subroutine functions -> false
>>
>> So, what would be the conclusion? Do we allow subroutine variables 
>> comparison?
> 
> There is no conclusion yet.  I opened a Khronos gitlab tracker (right
> after Dave sent his original patch) for the CTS.  I'll try to get it on
> the conference call agenda for this week.

It is decided... the test will stand as-is, and the GLSL spec will be
updated to explicitly say that subroutine uniforms cannot be compared
using == or !=.

So... I think I like Andres's patch slightly better than Dave's, but I
don't care too much.  Either patch can have my

Reviewed-by: Ian Romanick 

>> FTR, I passed this patch through an "all" piglit run and through GL44 CTS 
>> and it doesn't cause any regression.
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Mesa-dev] [PATCH] mesa: Use AC_HEADER_MAJOR to include correct header for major().

[Matt Turner]

Gentoo has been smoke testing an upcoming change to glibc.

Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=580392
---
 configure.ac | 1 +
 src/gallium/winsys/svga/drm/vmw_screen.c | 7 ++-
 src/gbm/main/gbm.c   | 7 ++-
 src/loader/loader.c  | 7 +--
 4 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2668a69..d102e54 100644
--- a/configure.ac
+++ b/configure.ac
@@ -771,6 +771,7 @@ if test "x$enable_asm" = xyes; then
 esac
 fi
 
+AC_HEADER_MAJOR
 AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
 AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
 AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
diff --git a/src/gallium/winsys/svga/drm/vmw_screen.c 
b/src/gallium/winsys/svga/drm/vmw_screen.c
index 7fcb6d2..74c77c5 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen.c
@@ -31,7 +31,12 @@
 #include "util/u_memory.h"
 #include "pipe/p_compiler.h"
 #include "util/u_hash_table.h"
-#include 
+#ifdef MAJOR_IN_MKDEV
+#include 
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include 
+#endif
 #include 
 #include 
 
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 5a6e758..20ff3f2 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -31,7 +31,12 @@
 #include 
 #include 
 
-#include 
+#ifdef MAJOR_IN_MKDEV
+#include 
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include 
+#endif
 #include 
 #include 
 #include 
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 522fba3..56ffc5d 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -80,8 +80,11 @@
 #include "xmlpool.h"
 #endif
 #endif
-#ifdef HAVE_SYSFS
-#include 
+#ifdef MAJOR_IN_MKDEV
+#include 
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include 
 #endif
 #include "loader.h"
 
-- 
2.7.3

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

Re: [Mesa-dev] [PATCH 1/7] glsl: Separate overlapping sentinel nodes in exec_list.

[Matt Turner]

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

[Mesa-dev] [PATCH] os: add pipe_mutex_assert_locked()

[Rob Clark]

Would be nice if we could also have lockdep, like in the linux kernel.
But this is better than nothing.

Signed-off-by: Rob Clark 
---
 src/gallium/auxiliary/os/os_thread.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/gallium/auxiliary/os/os_thread.h 
b/src/gallium/auxiliary/os/os_thread.h
index be8adcc..ec8adbc 100644
--- a/src/gallium/auxiliary/os/os_thread.h
+++ b/src/gallium/auxiliary/os/os_thread.h
@@ -116,6 +116,22 @@ typedef mtx_t pipe_mutex;
 #define pipe_mutex_unlock(mutex) \
(void) mtx_unlock(&(mutex))
 
+#define pipe_mutex_assert_locked(mutex) \
+   __pipe_mutex_assert_locked(&(mutex))
+
+static inline void
+__pipe_mutex_assert_locked(pipe_mutex *mutex)
+{
+#ifdef DEBUG
+   /* NOTE: this would not work for recursive mutexes, but
+* pipe_mutex doesn't support those
+*/
+   int ret = mtx_trylock(mutex);
+   assert(ret == thrd_busy);
+   if (ret == thrd_success)
+  mtx_unlock(mutex);
+#endif
+}
 
 /* pipe_condvar
  */
-- 
2.7.4

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

[Mesa-dev] [Bug 89599] symbol 'x86_64_entry_start' is already defined when building with LLVM/clang

[bugzilla-daemon]

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

Matt Turner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Mesa-dev] [Bug 89599] symbol 'x86_64_entry_start' is already defined when building with LLVM/clang

[bugzilla-daemon]

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

--- Comment #13 from Matt Turner  ---
Thanks all. I've pushed the patch:

commit 5ec140c17b54c25920091501b665b9aa809cc5e8
Author: Matt Turner 
Date:   Mon Jul 11 10:44:25 2016 -0700

mapi: Massage code to allow clang to compile.

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

Re: [Mesa-dev] [PATCH] freedreno/a2xx: silence missing case 'SHADER_COMPUTE' warning

[Matt Turner]

On Tue, Jul 19, 2016 at 5:06 AM, Francesco Ansanelli
 wrote:
> ---
>  src/gallium/drivers/freedreno/a2xx/disasm-a2xx.c |3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/drivers/freedreno/a2xx/disasm-a2xx.c 
> b/src/gallium/drivers/freedreno/a2xx/disasm-a2xx.c
> index f00d5d4..54b3514 100644
> --- a/src/gallium/drivers/freedreno/a2xx/disasm-a2xx.c
> +++ b/src/gallium/drivers/freedreno/a2xx/disasm-a2xx.c
> @@ -111,6 +111,9 @@ static void print_export_comment(uint32_t num, enum 
> shader_t type)
> case 0:  name = "gl_FragColor"; break;
> }
> break;
> +   case SHADER_COMPUTE:
> +   unreachable("not reached");
> +   break;

There's no need for break after an unreachable().
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Include VUE handles for GS with invocations > 1.

[Ian Romanick]

On my oes_shader_io_blocks branch (which enables
GL_OES_geometry_shader), this fixes

deqp-gles31.functional.geometry_shading.instanced.draw_2_instances_geometry_2_invocations
deqp-gles31.functional.geometry_shading.instanced.draw_2_instances_geometry_8_invocations
deqp-gles31.functional.geometry_shading.instanced.draw_4_instances_geometry_2_invocations
deqp-gles31.functional.geometry_shading.instanced.draw_4_instances_geometry_8_invocations
deqp-gles31.functional.geometry_shading.instanced.draw_8_instances_geometry_2_invocations
deqp-gles31.functional.geometry_shading.instanced.draw_8_instances_geometry_8_invocations
deqp-gles31.functional.geometry_shading.instanced.geometry_2_invocations
deqp-gles31.functional.geometry_shading.instanced.geometry_32_invocations
deqp-gles31.functional.geometry_shading.instanced.geometry_8_invocations
deqp-gles31.functional.geometry_shading.instanced.geometry_max_invocations
deqp-gles31.functional.geometry_shading.instanced.geometry_output_different_2_invocations
deqp-gles31.functional.geometry_shading.instanced.geometry_output_different_32_invocations
deqp-gles31.functional.geometry_shading.instanced.geometry_output_different_8_invocations
deqp-gles31.functional.geometry_shading.instanced.geometry_output_different_max_invocations
deqp-gles31.functional.geometry_shading.instanced.invocation_output_vary_by_attribute
deqp-gles31.functional.geometry_shading.instanced.invocation_output_vary_by_texture
deqp-gles31.functional.geometry_shading.instanced.invocation_output_vary_by_uniform
deqp-gles31.functional.geometry_shading.query.primitives_generated_instanced

I see no more instancing related failures.

Tested-by: Ian Romanick 

On 07/20/2016 06:04 PM, Kenneth Graunke wrote:
> We always resort to the pull model for instanced GS inputs.  So, we'd
> better include the VUE handles, or else we can't actually pull anything.
> 
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 53e7183..f9af525 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -5581,7 +5581,7 @@ fs_visitor::setup_gs_payload()
>  * have to multiply by VerticesIn to obtain the total storage requirement.
>  */
> if (8 * vue_prog_data->urb_read_length * nir->info.gs.vertices_in >
> -   max_push_components) {
> +   max_push_components || gs_prog_data->invocations > 1) {
>gs_prog_data->base.include_vue_handles = true;
>  
>/* R3..RN: ICP Handles for each incoming vertex (when using pull 
> model) */
> 




signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 8/8] egldevice: implement eglQueryDisplayAttribEXT

[Adam Jackson]

On Thu, 2016-07-21 at 16:18 +0100, Daniel Stone wrote:
> On 21 July 2016 at 15:11, Emil Velikov  wrote:
> > I'd suggest opting for the drmDevice libdrm API. It can provide a list
> > of devices with all the nodes and other misc info. Thus we could use
> > the render/card/other node as any point as needed.
> 
> Indeed.
> 
> I don't believe Jonny is working on this anymore, and I'm pretty
> preoccupied, so it would be great if someone could pick this one up.

Happy to do so. glvnd's libEGL support gets a lot more useful if the
device enumeration API actually exists and works, so this is sort of
important to me.

drmDevice looks like a good start and we already require a libdrm that
has it. I might need to come up with a dummy implementation for
software (eg KHR_surfaceless_context) but that's easy enough. I'll
rework this series to target that instead of udev.

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

[Mesa-dev] [Bug 96903] Hoard renders thick white fog

[bugzilla-daemon]

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

--- Comment #2 from Ilia Mirkin  ---
BTW, I believe the correct solution here is to add a "force_glsl_version"
option to drirc. Should be easy to do with the executable name (hopefully it's
not "wine"). Can you test adding something like





into an appropriate place in your drirc? Probably have to play around with the
executable. You can also just stick that into the environment.

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

Re: [Mesa-dev] [PATCH 06/10] egl/android: Fix support for pbuffers

[Rob Herring]

On Thu, Jul 21, 2016 at 12:35 AM, Tomasz Figa  wrote:
> On Thu, Jul 21, 2016 at 6:19 AM, Rob Herring  wrote:
>> On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa  wrote:
>>> From: Nicolas Boichat 
>>>
>>> Existing image loader code supports creating images only for window
>>> surfaces. Moreover droid_create_surface() passes wrong surface type to
>>> dri2_get_dri_config(), resulting in incorrect configs being returned for
>>> pbuffers. This patch fixes these issues.
>>>
>>> In addition, the config generation code is fixed to include single
>>> buffered contexts required for pbuffers and make sure that generated
>>> configs support only surfaces which can handle their supported buffering
>>> modes.
>>>
>>> Signed-off-by: Nicolas Boichat 
>>> Signed-off-by: Tomasz Figa 
>>> ---

[...]

>>> @@ -728,6 +754,19 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
>>> _EGLDisplay *dpy)
>>>/* there is no front buffer so no OpenGL */
>>>dri2_conf->base.RenderableType &= ~EGL_OPENGL_BIT;
>>>dri2_conf->base.Conformant &= ~EGL_OPENGL_BIT;
>>> +
>>> +  for (j = 0; j < 2; j++) {
>>> + /* Unsupported color space variants should not affect surface 
>>> type. */
>>> + if (!dri2_conf->dri_single_config[j] && 
>>> !dri2_conf->dri_double_config[j])
>>> +continue;
>>> +
>>> + /* Pbuffers support only single buffering. */
>>> + if (!dri2_conf->dri_single_config[j])
>>> +dri2_conf->base.SurfaceType &= ~EGL_PBUFFER_BIT;
>>> + /* Windows support only double buffering. */
>>> + else if (!dri2_conf->dri_double_config[j])
>>> +dri2_conf->base.SurfaceType &= ~EGL_WINDOW_BIT;
>>> +  }
>>
>> I still don't know why this patch causes problems, but I don't think
>> this hunk is needed. The core DRI2 EGL code takes care of this. It's
>> not so obvious though. EGL_PBUFFER_BIT is cleared in dri2_add_config,
>> and dri2_get_dri_config returns single or double config based on the
>> surface type.
>
> Well, it just doesn't work correctly without this.
>
> If DRI driver exposes certain double buffered configs that don't have
> their equivalent single buffered configs then it will leave double
> buffered configs with EGL_PBUFFER_BIT set and dri2_get_dri_config()
> will return NULL at the time of eglCreateSurface(), which doesn't
> conform to the spec and will cause failures, because it is expected
> that if eglChooseConfig() is given EGL_PBUFFER_BIT then resulting
> config must support pbuffers. Similarly for EGL_WINDOW_BIT and
> single-buffered configs without double-buffered equivalents.
>
> Also I don't see where dri2_add_config() clears EGL_PBUFFER_BIT. I can
> see only EGL_PIXMAP_BIT.

Oh yes, you are correct. Sorry for the noise.

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

[Mesa-dev] [Bug 96979] Mesa 10.5.7 implementation error: Trying to disable permanently enabled extensions

[bugzilla-daemon]

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

--- Comment #9 from Ian Romanick  ---
(In reply to Ruslan Kabatsayev from comment #4)
> Trying this with Mesa 11.0.2 doesn't crash glxinfo, but I still get the
> following discrepancy:
> 
> $ glxinfo | grep GL_APPLE_texture_max_level
> $ MESA_EXTENSION_OVERRIDE=-GL_APPLE_texture_max_level glxinfo >/dev/null
> Mesa 11.0.2 implementation error: Trying to disable permanently enabled
> extensions: GL_APPLE_texture_max_level
> Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
> 
> I.e. despite the extension isn't listed by glxinfo, disabling it explicitly
> leads to error message saying that it's permanently enabled. It seems
> permanently enabled extensions should be present in
> glGetString(GL_EXTENSIONS) and similar API's results.

In this particular case, GL_APPLE_texture_max_level is an OpenGL ES 1.x and 2.x
extension.  I suspect the version of glxinfo you're using only shows desktop
OpenGL information, so it makes sense that it doesn't show the ES extension.

It is confusing that Mesa gives an error message for disabling a extension that
doesn't exist in the current API.  The code could be smarter about that.

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

[Mesa-dev] [Bug 96979] Mesa 10.5.7 implementation error: Trying to disable permanently enabled extensions

[bugzilla-daemon]

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

--- Comment #8 from Ian Romanick  ---
(In reply to Eero Tamminen from comment #7)
> Btw. If you're just testing whether Mesa would flip out on given HW and have
> an automated way of running your test-case (e.g. apitrace trace), you can
> override what PCI ID libdrm reports.  When underlying HW is faked, batches
> are dropped, but Mesa still does its own part.  As no rendering is then
> done, you cannot verify the results correctness though.

Right... except he's trying to override to a different kind of hardware (i915
vs i965), so that won't work.

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

Re: [Mesa-dev] [PATCH 03/36] isl/state: Use a valid alignment for 1-D textures

[Nanley Chery]

On Wed, Jun 29, 2016 at 05:37:22PM -0700, Jason Ekstrand wrote:
> The alignment we use doesn't matter (see the comment) but it should at
> least be an alignment we can represent with the enums.

This patch is,
Reviewed-by: Nanley Chery 

> ---
>  src/intel/isl/isl_surface_state.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/intel/isl/isl_surface_state.c 
> b/src/intel/isl/isl_surface_state.c
> index bfd4b65..1d354f3 100644
> --- a/src/intel/isl/isl_surface_state.c
> +++ b/src/intel/isl/isl_surface_state.c
> @@ -142,7 +142,7 @@ get_image_alignment(const struct isl_surf *surf)
>* true alignment is likely outside the enum range of HALIGN* and
>* VALIGN*.
>*/
> - return isl_extent3d(0, 0, 0);
> + return isl_extent3d(4, 4, 1);
>} else {
>   /* In Skylake, RENDER_SUFFACE_STATE.SurfaceVerticalAlignment is in 
> units
>* of surface elements (not pixels nor samples). For compressed 
> formats,
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 8/8] egldevice: implement eglQueryDisplayAttribEXT

[Daniel Stone]

Hi,

On 21 July 2016 at 15:11, Emil Velikov  wrote:
> On 21 July 2016 at 14:57, Adam Jackson  wrote:
>>> +   device_name = drv->QueryDeviceName(disp);
>>
>> This is /dev/dri/renderD128...
>>
>>> +   mtx_lock(_eglGlobal.Mutex);
>>> +
>>> +   assert(info->got_devices);
>>> +
>>> +   for (dev = info->devices; dev; dev = dev->Next) {
>>> +  const char *devname = udev_device_get_property_value(
>>> + dev->Info, "DEVNAME");
>>
>> And this is /dev/dri/card0, so querying the display will always fail.
>>
>> Obviously I can paper over this when there's only one device in the
>> list, but the whole reason I want this is to make multi-GPU work
>> better. Any ideas on a better approach here?
>>
> I'd suggest opting for the drmDevice libdrm API. It can provide a list
> of devices with all the nodes and other misc info. Thus we could use
> the render/card/other node as any point as needed.

Indeed.

I don't believe Jonny is working on this anymore, and I'm pretty
preoccupied, so it would be great if someone could pick this one up.

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

Re: [Mesa-dev] [PATCH 05/12] st/va: add encode entrypoint

[Zhang, Boyuan]

And I forgot to say, all the patches I submitted for code review is based on 
the latest Master. And confirmed from my side, all patches can be applied to 
the latest Master without any problem.

Regards,
Boyuan

-Original Message-
From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of 
Zhang, Boyuan
Sent: July-21-16 10:52 AM
To: 'Christian König'; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 05/12] st/va: add encode entrypoint

>> @@ -150,7 +167,18 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile 
>> profile, VAEntrypoint entrypoin
>>  if (entrypoint != VAEntrypointVLD)
>> return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;
>>  
>> -   *config_id = p;
>> +#if 0
>> +   if (entrypoint == VAEntrypointEncSlice || entrypoint == 
>> VAEntrypointEncPicture)
>> +  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_ENCODE;
>> +   else
>> +#endif
>> +  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;

>If you don't mind I'm just going ahead and replacing this with a switch/case 
>statement.
>
>Going to commit the patch with that change in the evening if you don't have 
>any objections, but you probably have to rebase your set on top of master then.
>
>Christian.

Yes sure, I'm totally fine with it. Thanks for the suggestion.

Regards,
Boyuan


-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: July-21-16 4:46 AM
To: Zhang, Boyuan; mesa-dev@lists.freedesktop.org
Cc: adf.li...@gmail.com
Subject: Re: [PATCH 05/12] st/va: add encode entrypoint

Am 21.07.2016 um 00:13 schrieb Boyuan Zhang:
> VAAPI passes PIPE_VIDEO_ENTRYPOINT_ENCODE as entry point for encoding case. 
> We will save this encode entry point in config. config_id was used as profile 
> previously. Now, config has both profile and entrypoint field, and config_id 
> is used to get the config object. Later on, we pass this entrypoint to 
> context->templat.entrypoint instead of always hardcoded to 
> PIPE_VIDEO_ENTRYPOINT_BITSTREAM for decoding case previously. Encode 
> entrypoint is not accepted by driver until we enable Vaapi encode in later 
> patch.
>
> Signed-off-by: Boyuan Zhang 
> ---
>   src/gallium/state_trackers/va/config.c | 71 
> +++---
>   src/gallium/state_trackers/va/context.c| 59 +++--
>   src/gallium/state_trackers/va/surface.c| 14 --
>   src/gallium/state_trackers/va/va_private.h |  5 +++
>   4 files changed, 117 insertions(+), 32 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/config.c
> b/src/gallium/state_trackers/va/config.c
> index 9ca0aa8..3aacc63 100644
> --- a/src/gallium/state_trackers/va/config.c
> +++ b/src/gallium/state_trackers/va/config.c
> @@ -34,6 +34,8 @@
>   
>   #include "va_private.h"
>   
> +#include "util/u_handle_table.h"
> +
>   DEBUG_GET_ONCE_BOOL_OPTION(mpeg4, "VAAPI_MPEG4_ENABLED", false)
>   
>   VAStatus
> @@ -128,14 +130,29 @@ VAStatus
>   vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint 
> entrypoint,
>VAConfigAttrib *attrib_list, int num_attribs, VAConfigID 
> *config_id)
>   {
> +   vlVaDriver *drv;
> +   vlVaConfig *config;
>  struct pipe_screen *pscreen;
>  enum pipe_video_profile p;
>   
>  if (!ctx)
> return VA_STATUS_ERROR_INVALID_CONTEXT;
>   
> +   drv = VL_VA_DRIVER(ctx);
> +
> +   if (!drv)
> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
> +
> +   config = CALLOC(1, sizeof(vlVaConfig));
> +   if (!config)
> +  return VA_STATUS_ERROR_ALLOCATION_FAILED;
> +
>  if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) {
> -  *config_id = PIPE_VIDEO_PROFILE_UNKNOWN;
> +  config->entrypoint = VAEntrypointVideoProc;
> +  config->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
> +  pipe_mutex_lock(drv->mutex);
> +  *config_id = handle_table_add(drv->htab, config);
> +  pipe_mutex_unlock(drv->mutex);
> return VA_STATUS_SUCCESS;
>  }
>   
> @@ -150,7 +167,18 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile 
> profile, VAEntrypoint entrypoin
>  if (entrypoint != VAEntrypointVLD)
> return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;
>   
> -   *config_id = p;
> +#if 0
> +   if (entrypoint == VAEntrypointEncSlice || entrypoint == 
> VAEntrypointEncPicture)
> +  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_ENCODE;
> +   else
> +#endif
> +  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;

If you don't mind I'm just going ahead and replacing this with a switch/case 
statement.

Going to commit the patch with that change in the evening if you don't have any 
objections, but you probably have to rebase your set on top of master then.

Christian.

> +
> +   config->profile = p;
> +
> +   pipe_mutex_lock(drv->mutex);
> +   *config_id = handle_table_add(drv->htab, config);
> +   pipe_mutex_unlock(drv->mutex);
>   
>  return VA_STATUS_SUCCESS;
>   }
> @@ -158,9 +186,27 @@ 

Re: [Mesa-dev] [PATCH] egl/dri2: Add reference count for dri2_egl_display

[Emil Velikov]

On 21 July 2016 at 01:44, Nicolas Boichat  wrote:
> On Wed, Jul 20, 2016 at 11:52 PM, Emil Velikov  
> wrote:
>> On 20 July 2016 at 15:42, Emil Velikov  wrote:
>>> On 20 July 2016 at 09:26, Nicolas Boichat  wrote:
 android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls
 eglTerminate, followed by eglReleaseThread. A similar case is
 observed in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=69622,
 where the test calls eglTerminate, then eglMakeCurrent(dpy, NULL, NULL, 
 NULL).

 With the current code, dri2_dpy structure is freed on eglTerminate
 call, so the display is not initialized when eglReleaseThread calls
 MakeCurrent with NULL parameters, to unbind the context, which
 causes a a segfault in drv->API.MakeCurrent (dri2_make_current),
 either in glFlush or in a latter call.

 eglTerminate specifies that "If contexts or surfaces associated
 with display is current to any thread, they are not released until
 they are no longer current as a result of eglMakeCurrent."

 However, to properly free the current context/surface (i.e., call
 glFlush, unbindContext, driDestroyContext), we still need the
 display vtbl (and possibly an active dri dpy connection). Therefore,
 we add some reference counter to dri2_egl_display, to make sure
 the structure is kept allocated as long as it is required.

>>> Looks very, just a couple of suggestions below.
>>>
 Signed-off-by: Nicolas Boichat 
 ---

 Replaces https://patchwork.freedesktop.org/patch/98874/.

  src/egl/drivers/dri2/egl_dri2.c | 96 
 -
  src/egl/drivers/dri2/egl_dri2.h |  4 ++
  2 files changed, 80 insertions(+), 20 deletions(-)

 diff --git a/src/egl/drivers/dri2/egl_dri2.c 
 b/src/egl/drivers/dri2/egl_dri2.c
 index ac2be86..00269d3 100644
 --- a/src/egl/drivers/dri2/egl_dri2.c
 +++ b/src/egl/drivers/dri2/egl_dri2.c
 @@ -761,6 +761,14 @@ dri2_create_screen(_EGLDisplay *disp)
  static EGLBoolean
  dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
  {
 +   EGLBoolean ret = EGL_FALSE;
 +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
 +
 +   if (dri2_dpy) {
 +  dri2_dpy->ref_count++;
 +  return EGL_TRUE;
 +   }
 +
>>> I'm not sure that reusing the dpy is what we want here. IMHO we should
>>> either call dri2_display_release (to release existing resources) or
>>> simply error out.
>>>
>> A bit more meat to it:
>> Upper layer(s) will ensure that upon second call to eglInitialize
>> (without a eglTerminate in between) we won't get here. Thus only case
>> we get this is on user misuse/leak  - missing explicit/implicit
>> eglMakeCurrent(...NULL, NULL) call while having called eglTerminate.
>
> Yes, that's how it's intended to work, "Initialized" boolean in
> _EGLDisplay structure protects against repeated calls (I added a
> comment to dri2_terminate, I should add the same in dri2_initialize).
>
>> If we ref count we exacerbate the leak. At the same time, returning
>> error in case of a user leak sounds silly, so dri2_display_release
>> might be like the better option ?
>
> That's right, we "leak" the display connection in this case:
>  - eglMakeCurrent(context1)
>  - eglTerminate
>  - never call any EGL function
>
> However that's a arguably an application bug, as we _must_ keep a
> reference to context1. Also, we still hold a reference to the display,
> so calling eglReleaseThread, eglMakeCurrent(NULL), or eglInitialize
> would free/reuse the display.
>
> To go along your lines, I first tried doing something like:
> while (dri2_egl_display(disp))
>dri2_display_release(disp);
>
> But then in this test case:
>  - eglMakeCurrent(context1)
>  - eglTerminate
>  - eglInitialize
>  - eglMakeCurrent(context2)
>
> context1 would permanently leak (similar to the issue we had with the
> previous patch). And eglMakeCurrent(context2) would crash trying to
> unbind context1 (didn't trace the exact nature of the crash, but I
> suppose the new display is not aware of context1). I wrote a small
> test case for this scenario:
> https://android-review.googlesource.com/#/c/249320/1 .
>
That said I fully agree with all the above - we cannot do much in case
of application bugs/user leaks.

> A more sensible option might be to call dri2_make_current(NULL). But
> IIUC, we'd need to do that on all threads, and it violates the spec
> "If contexts or surfaces associated with display is current to any
> thread, they are not released until they are no longer current as a
> result of eglMakeCurrent."
>
> In any case, I don't think the spec clearly says that eglTerminate
> should terminate all connections immediately: it just says
> "eglTerminate releases resources associated with an EGL display
> 

Re: [Mesa-dev] [PATCH 05/12] st/va: add encode entrypoint

[Zhang, Boyuan]

>> @@ -150,7 +167,18 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile 
>> profile, VAEntrypoint entrypoin
>>  if (entrypoint != VAEntrypointVLD)
>> return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;
>>  
>> -   *config_id = p;
>> +#if 0
>> +   if (entrypoint == VAEntrypointEncSlice || entrypoint == 
>> VAEntrypointEncPicture)
>> +  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_ENCODE;
>> +   else
>> +#endif
>> +  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;

>If you don't mind I'm just going ahead and replacing this with a switch/case 
>statement.
>
>Going to commit the patch with that change in the evening if you don't have 
>any objections, but you probably have to rebase your set on top of master then.
>
>Christian.

Yes sure, I'm totally fine with it. Thanks for the suggestion.

Regards,
Boyuan


-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de] 
Sent: July-21-16 4:46 AM
To: Zhang, Boyuan; mesa-dev@lists.freedesktop.org
Cc: adf.li...@gmail.com
Subject: Re: [PATCH 05/12] st/va: add encode entrypoint

Am 21.07.2016 um 00:13 schrieb Boyuan Zhang:
> VAAPI passes PIPE_VIDEO_ENTRYPOINT_ENCODE as entry point for encoding case. 
> We will save this encode entry point in config. config_id was used as profile 
> previously. Now, config has both profile and entrypoint field, and config_id 
> is used to get the config object. Later on, we pass this entrypoint to 
> context->templat.entrypoint instead of always hardcoded to 
> PIPE_VIDEO_ENTRYPOINT_BITSTREAM for decoding case previously. Encode 
> entrypoint is not accepted by driver until we enable Vaapi encode in later 
> patch.
>
> Signed-off-by: Boyuan Zhang 
> ---
>   src/gallium/state_trackers/va/config.c | 71 
> +++---
>   src/gallium/state_trackers/va/context.c| 59 +++--
>   src/gallium/state_trackers/va/surface.c| 14 --
>   src/gallium/state_trackers/va/va_private.h |  5 +++
>   4 files changed, 117 insertions(+), 32 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/config.c 
> b/src/gallium/state_trackers/va/config.c
> index 9ca0aa8..3aacc63 100644
> --- a/src/gallium/state_trackers/va/config.c
> +++ b/src/gallium/state_trackers/va/config.c
> @@ -34,6 +34,8 @@
>   
>   #include "va_private.h"
>   
> +#include "util/u_handle_table.h"
> +
>   DEBUG_GET_ONCE_BOOL_OPTION(mpeg4, "VAAPI_MPEG4_ENABLED", false)
>   
>   VAStatus
> @@ -128,14 +130,29 @@ VAStatus
>   vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint 
> entrypoint,
>VAConfigAttrib *attrib_list, int num_attribs, VAConfigID 
> *config_id)
>   {
> +   vlVaDriver *drv;
> +   vlVaConfig *config;
>  struct pipe_screen *pscreen;
>  enum pipe_video_profile p;
>   
>  if (!ctx)
> return VA_STATUS_ERROR_INVALID_CONTEXT;
>   
> +   drv = VL_VA_DRIVER(ctx);
> +
> +   if (!drv)
> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
> +
> +   config = CALLOC(1, sizeof(vlVaConfig));
> +   if (!config)
> +  return VA_STATUS_ERROR_ALLOCATION_FAILED;
> +
>  if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) {
> -  *config_id = PIPE_VIDEO_PROFILE_UNKNOWN;
> +  config->entrypoint = VAEntrypointVideoProc;
> +  config->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
> +  pipe_mutex_lock(drv->mutex);
> +  *config_id = handle_table_add(drv->htab, config);
> +  pipe_mutex_unlock(drv->mutex);
> return VA_STATUS_SUCCESS;
>  }
>   
> @@ -150,7 +167,18 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile 
> profile, VAEntrypoint entrypoin
>  if (entrypoint != VAEntrypointVLD)
> return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;
>   
> -   *config_id = p;
> +#if 0
> +   if (entrypoint == VAEntrypointEncSlice || entrypoint == 
> VAEntrypointEncPicture)
> +  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_ENCODE;
> +   else
> +#endif
> +  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;

If you don't mind I'm just going ahead and replacing this with a switch/case 
statement.

Going to commit the patch with that change in the evening if you don't have any 
objections, but you probably have to rebase your set on top of master then.

Christian.

> +
> +   config->profile = p;
> +
> +   pipe_mutex_lock(drv->mutex);
> +   *config_id = handle_table_add(drv->htab, config);
> +   pipe_mutex_unlock(drv->mutex);
>   
>  return VA_STATUS_SUCCESS;
>   }
> @@ -158,9 +186,27 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile 
> profile, VAEntrypoint entrypoin
>   VAStatus
>   vlVaDestroyConfig(VADriverContextP ctx, VAConfigID config_id)
>   {
> +   vlVaDriver *drv;
> +   vlVaConfig *config;
> +
>  if (!ctx)
> return VA_STATUS_ERROR_INVALID_CONTEXT;
>   
> +   drv = VL_VA_DRIVER(ctx);
> +
> +   if (!drv)
> +  return VA_STATUS_ERROR_INVALID_CONTEXT;
> +
> +   pipe_mutex_lock(drv->mutex);
> +   config = handle_table_get(drv->htab, config_id);
> +
> +   if 

Re: [Mesa-dev] [PATCH v2 1/2] vl: add a lanczos interpolation filter v2

[Christian König]

Am 21.07.2016 um 16:05 schrieb Nayan Deshmukh:

Hi Christian,

Yes, that is for pixel center adjustment.

let me give you an example, for lanczos I need frac(x) where x is the 
original
coordinate before scaling. To calculate that first I subtract 
half_pixel and then
multiply by the original surface size, which gives me the original 
coordinate.


eg. if the coordinate before scaling was 24.5 (total size 300) after 
2x it becomes
49. When the frag shader is executed we get 49.5/600 as the coordinate 
so what
I do is 49.5/600 - 0.5/600 = 49/600 and then multiply it with 300 to 
get 24.5 the

original coordinate.


Well in your case the coordinates are always between 0.0 and 1.0, so 
scaling doesn't affect the coordinate.


You could take a look at how I did that in the weave shader:
1. In the vertex shader I use 0..width instead of 0..1 for the range 
(from create_vert_shader() in vl_compositor.c):


* o_vtop.x = vtex.x
* o_vtop.y = vtex.y * tmp.x + 0.25f

2. Then in the fragment shader I just need to do the following to get 
the original coordinate to sample from:

* t_tc.y = (round(i_tc.y - 0.5) + 0.5) / height * 2

I use 0.25 and "height * 2" here because the top/bottom fields are 
always halve the height and shifted a bit up/down.


For your case that should just be:

o_vtex.x = i_vpos.x * video_width
o_vtex.y = i_vpos.y * video_height

In the vertex shader and then:

t_tc.x = (round(i_tc.x - 0.5) + 0.5) / video_width
t_tc.y = (round(i_tc.x - 0.5) + 0.5) / video_height

In the fragment shader to get the correct coordinate. No need to 
actually mess with the destination sizes here.


Regards,
Christian.



Regards,
Nayan.
On Thu, Jul 21, 2016 at 7:20 PM, Christian König 
> wrote:




This seems to be the reason for the artifacts.

+   ureg_SUB(shader, ureg_writemask(t_array[0],
TGSI_WRITEMASK_XY),
+i_vtex, half_pixel);


On debugging I found that after removing this ^^^ instruction the
artifacts are gone.
Not sure why is this happening but the filter is working fine.

Any ideas Christian?


Could it be that your values run out of the representable numeric
range? Otherwise I run out of ideas as well.

Additional to that I'm not 100% sure I get what are you trying to
do here. Is that for the pixel center adjustment?

Regards,
Christian.


Am 20.07.2016 um 14:02 schrieb Nayan Deshmukh:

Hi Christian,

Thanks for the review.


On Tue, Jul 19, 2016 at 4:58 PM, Christian König
> wrote:

Am 18.07.2016 um 21:55 schrieb Nayan Deshmukh:

v2: avoCould it be that your values run out of the
representable numeric range?iding dividing by zero when
calculating lanczos

Signed-off-by: Nayan Deshmukh >


That looks much better, but there are still quite a bunch of
artifacts.

Take a look at the attached screenshots. good.jpg was created
with hqscalling=0, bad with hqscalling=7.

Especially on the left side we have lines from top to bottom
where there shouldn't be any.

Regards,
Christian.


---
src/gallium/auxiliary/Makefile.sources  |   2 +
src/gallium/auxiliary/vl/vl_lanczos_filter.c | 447
+++
src/gallium/auxiliary/vl/vl_lanczos_filter.h |  63 
  3 files changed, 512 insertions(+)
  create mode 100644
src/gallium/auxiliary/vl/vl_lanczos_filter.c
  create mode 100644
src/gallium/auxiliary/vl/vl_lanczos_filter.h

diff --git a/src/gallium/auxiliary/Makefile.sources
b/src/gallium/auxiliary/Makefile.sources
index e0311bf..4eb0f65 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -330,6 +330,8 @@ VL_SOURCES := \
vl/vl_deint_filter.h \
vl/vl_idct.c \
vl/vl_idct.h \
+   vl/vl_lanczos_filter.c \
+   vl/vl_lanczos_filter.h \
vl/vl_matrix_filter.c \
vl/vl_matrix_filter.h \
vl/vl_mc.c \
diff --git a/src/gallium/auxiliary/vl/vl_lanczos_filter.c
b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
new file mode 100644
index 000..7c69555
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
@@ -0,0 +1,447 @@

+/**
+ *
+ * Copyright 2016 Nayan Deshmukh.
+ * All Rights Reserved.
  

Re: [Mesa-dev] [PATCH 8/8] egldevice: implement eglQueryDisplayAttribEXT

[Emil Velikov]

On 21 July 2016 at 14:57, Adam Jackson  wrote:
> On Fri, 2015-07-24 at 16:20 +0200, Jonny Lamb wrote:
>> This adds a new vfunc to _EGLDriver, QueryDeviceName, which should
>> return a const string of the device name (usually in the format
>> '/dev/dri/cardN').
>>
>> The EGLDevice could perhaps be cached in the EGLDisplay but there
>> usually aren't loads of devices and this lookup isn't particularly
>> costly so leave it as is for now.
>>
>> Right now this only works with the egl_dri2 driver.
>
> Ancient thread I know, but this doesn't work, at least in my wayland
> session.
>
>>  static EGLBoolean
>> +_eglQueryDeviceFromDisplay(_EGLDeviceInfo *info,
>> +   _EGLDriver *drv,
>> +   _EGLDisplay *disp,
>> +   EGLAttrib *value)
>> +{
>> +#ifdef HAVE_LIBUDEV
>> +   const char *device_name = NULL;
>> +   _EGLDevice *dev;
>> +   UDEV_SYMBOL(const char *, udev_device_get_property_value,
>> +   (struct udev_device *, const char *));
>> +
>> +   if (dlsym_failed)
>> +  return EGL_FALSE;
>> +
>> +   if (!drv->QueryDeviceName)
>> +  return EGL_FALSE;
>> +
>> +   device_name = drv->QueryDeviceName(disp);
>
> This is /dev/dri/renderD128...
>
>> +   mtx_lock(_eglGlobal.Mutex);
>> +
>> +   assert(info->got_devices);
>> +
>> +   for (dev = info->devices; dev; dev = dev->Next) {
>> +  const char *devname = udev_device_get_property_value(
>> + dev->Info, "DEVNAME");
>
> And this is /dev/dri/card0, so querying the display will always fail.
>
> Obviously I can paper over this when there's only one device in the
> list, but the whole reason I want this is to make multi-GPU work
> better. Any ideas on a better approach here?
>
I'd suggest opting for the drmDevice libdrm API. It can provide a list
of devices with all the nodes and other misc info. Thus we could use
the render/card/other node as any point as needed.

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

Re: [Mesa-dev] [PATCH v2 1/2] vl: add a lanczos interpolation filter v2

[Nayan Deshmukh]

Hi Christian,

Yes, that is for pixel center adjustment.

let me give you an example, for lanczos I need frac(x) where x is the
original
coordinate before scaling. To calculate that first I subtract half_pixel
and then
multiply by the original surface size, which gives me the original
coordinate.

eg. if the coordinate before scaling was 24.5 (total size 300) after 2x it
becomes
49. When the frag shader is executed we get 49.5/600 as the coordinate so
what
I do is 49.5/600 - 0.5/600 = 49/600 and then multiply it with 300 to get
24.5 the
original coordinate.

Regards,
Nayan.
On Thu, Jul 21, 2016 at 7:20 PM, Christian König 
wrote:

>
> This seems to be the reason for the artifacts.
>
>
>> +   ureg_SUB(shader, ureg_writemask(t_array[0], TGSI_WRITEMASK_XY),
>>> +i_vtex, half_pixel);
>>>
>>
> On debugging I found that after removing this ^^^ instruction the
> artifacts are gone.
> Not sure why is this happening but the filter is working fine.
>
> Any ideas Christian?
>
>
> Could it be that your values run out of the representable numeric range?
> Otherwise I run out of ideas as well.
>
> Additional to that I'm not 100% sure I get what are you trying to do here.
> Is that for the pixel center adjustment?
>
> Regards,
> Christian.
>
>
> Am 20.07.2016 um 14:02 schrieb Nayan Deshmukh:
>
> Hi Christian,
>
> Thanks for the review.
>
>
> On Tue, Jul 19, 2016 at 4:58 PM, Christian König 
> wrote:
>
>> Am 18.07.2016 um 21:55 schrieb Nayan Deshmukh:
>>
>>> v2: avoCould it be that your values run out of the representable numeric
>>> range?iding dividing by zero when calculating lanczos
>>>
>>> Signed-off-by: Nayan Deshmukh 
>>>
>>
>> That looks much better, but there are still quite a bunch of artifacts.
>>
>> Take a look at the attached screenshots. good.jpg was created with
>> hqscalling=0, bad with hqscalling=7.
>>
>> Especially on the left side we have lines from top to bottom where there
>> shouldn't be any.
>>
>> Regards,
>> Christian.
>>
>>
>> ---
>>>   src/gallium/auxiliary/Makefile.sources   |   2 +
>>>   src/gallium/auxiliary/vl/vl_lanczos_filter.c | 447
>>> +++
>>>   src/gallium/auxiliary/vl/vl_lanczos_filter.h |  63 
>>>   3 files changed, 512 insertions(+)
>>>   create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.c
>>>   create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.h
>>>
>>> diff --git a/src/gallium/auxiliary/Makefile.sources
>>> b/src/gallium/auxiliary/Makefile.sources
>>> index e0311bf..4eb0f65 100644
>>> --- a/src/gallium/auxiliary/Makefile.sources
>>> +++ b/src/gallium/auxiliary/Makefile.sources
>>> @@ -330,6 +330,8 @@ VL_SOURCES := \
>>> vl/vl_deint_filter.h \
>>> vl/vl_idct.c \
>>> vl/vl_idct.h \
>>> +   vl/vl_lanczos_filter.c \
>>> +   vl/vl_lanczos_filter.h \
>>> vl/vl_matrix_filter.c \
>>> vl/vl_matrix_filter.h \
>>> vl/vl_mc.c \
>>> diff --git a/src/gallium/auxiliary/vl/vl_lanczos_filter.c
>>> b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
>>> new file mode 100644
>>> index 000..7c69555
>>> --- /dev/null
>>> +++ b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
>>> @@ -0,0 +1,447 @@
>>>
>>> +/**
>>> + *
>>> + * Copyright 2016 Nayan Deshmukh.
>>> + * All Rights Reserved.
>>> + *
>>> + * Permission is hereby granted, free of charge, to any person
>>> obtaining a
>>> + * copy of this software and associated documentation files (the
>>> + * "Software"), to deal in the Software without restriction, including
>>> + * without limitation the rights to use, copy, modify, merge, publish,
>>> + * distribute, sub license, and/or sell copies of the Software, and to
>>> + * permit persons to whom the Software is furnished to do so, subject to
>>> + * the following conditions:
>>> + *
>>> + * The above copyright notice and this permission notice (including the
>>> + * next paragraph) shall be included in all copies or substantial
>>> portions
>>> + * of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> EXPRESS
>>> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>>> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> NON-INFRINGEMENT.
>>> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
>>> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
>>> CONTRACT,
>>> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
>>> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>>> + *
>>> +
>>> **/
>>> +
>>> +#include 
>>> +
>>> +#include "pipe/p_context.h"
>>> +
>>> +#include "tgsi/tgsi_ureg.h"
>>> +
>>> +#include "util/u_draw.h"
>>> +#include "util/u_memory.h"
>>> +#include "util/u_math.h"
>>> +#include "util/u_rect.h"
>>> +
>>> +#include "vl_types.h"
>>> 

Re: [Mesa-dev] [PATCH v2 1/2] vl: add a lanczos interpolation filter v2

[Christian König]

This seems to be the reason for the artifacts.

+   ureg_SUB(shader, ureg_writemask(t_array[0],
TGSI_WRITEMASK_XY),
+i_vtex, half_pixel);


On debugging I found that after removing this ^^^ instruction the 
artifacts are gone.

Not sure why is this happening but the filter is working fine.

Any ideas Christian?


Could it be that your values run out of the representable numeric range? 
Otherwise I run out of ideas as well.


Additional to that I'm not 100% sure I get what are you trying to do 
here. Is that for the pixel center adjustment?


Regards,
Christian.

Am 20.07.2016 um 14:02 schrieb Nayan Deshmukh:

Hi Christian,

Thanks for the review.


On Tue, Jul 19, 2016 at 4:58 PM, Christian König 
> wrote:


Am 18.07.2016 um 21:55 schrieb Nayan Deshmukh:

v2: avoiding dividing by zero when calculating lanczos

Signed-off-by: Nayan Deshmukh >


That looks much better, but there are still quite a bunch of
artifacts.

Take a look at the attached screenshots. good.jpg was created with
hqscalling=0, bad with hqscalling=7.

Especially on the left side we have lines from top to bottom where
there shouldn't be any.

Regards,
Christian.


---
  src/gallium/auxiliary/Makefile.sources   |   2 +
  src/gallium/auxiliary/vl/vl_lanczos_filter.c | 447
+++
  src/gallium/auxiliary/vl/vl_lanczos_filter.h |  63 
  3 files changed, 512 insertions(+)
  create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.c
  create mode 100644 src/gallium/auxiliary/vl/vl_lanczos_filter.h

diff --git a/src/gallium/auxiliary/Makefile.sources
b/src/gallium/auxiliary/Makefile.sources
index e0311bf..4eb0f65 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -330,6 +330,8 @@ VL_SOURCES := \
vl/vl_deint_filter.h \
vl/vl_idct.c \
vl/vl_idct.h \
+   vl/vl_lanczos_filter.c \
+   vl/vl_lanczos_filter.h \
vl/vl_matrix_filter.c \
vl/vl_matrix_filter.h \
vl/vl_mc.c \
diff --git a/src/gallium/auxiliary/vl/vl_lanczos_filter.c
b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
new file mode 100644
index 000..7c69555
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_lanczos_filter.c
@@ -0,0 +1,447 @@

+/**
+ *
+ * Copyright 2016 Nayan Deshmukh.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any
person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction,
including
+ * without limitation the rights to use, copy, modify, merge,
publish,
+ * distribute, sub license, and/or sell copies of the
Software, and to
+ * permit persons to whom the Software is furnished to do so,
subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice
(including the
+ * next paragraph) shall be included in all copies or
substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+

**/
+
+#include 
+
+#include "pipe/p_context.h"
+
+#include "tgsi/tgsi_ureg.h"
+
+#include "util/u_draw.h"
+#include "util/u_memory.h"
+#include "util/u_math.h"
+#include "util/u_rect.h"
+
+#include "vl_types.h"
+#include "vl_vertex_buffers.h"
+#include "vl_lanczos_filter.h"
+
+enum VS_OUTPUT
+{
+   VS_O_VPOS = 0,
+   VS_O_VTEX = 0
+};
+
+static void *
+create_vert_shader(struct vl_lanczos_filter *filter)
+{
+   struct ureg_program *shader;
+   struct 

Re: [Mesa-dev] [PATCH 8/8] egldevice: implement eglQueryDisplayAttribEXT

[Adam Jackson]

On Fri, 2015-07-24 at 16:20 +0200, Jonny Lamb wrote:
> This adds a new vfunc to _EGLDriver, QueryDeviceName, which should
> return a const string of the device name (usually in the format
> '/dev/dri/cardN').
> 
> The EGLDevice could perhaps be cached in the EGLDisplay but there
> usually aren't loads of devices and this lookup isn't particularly
> costly so leave it as is for now.
> 
> Right now this only works with the egl_dri2 driver.

Ancient thread I know, but this doesn't work, at least in my wayland
session.

>  static EGLBoolean
> +_eglQueryDeviceFromDisplay(_EGLDeviceInfo *info,
> +   _EGLDriver *drv,
> +   _EGLDisplay *disp,
> +   EGLAttrib *value)
> +{
> +#ifdef HAVE_LIBUDEV
> +   const char *device_name = NULL;
> +   _EGLDevice *dev;
> +   UDEV_SYMBOL(const char *, udev_device_get_property_value,
> +   (struct udev_device *, const char *));
> +
> +   if (dlsym_failed)
> +  return EGL_FALSE;
> +
> +   if (!drv->QueryDeviceName)
> +  return EGL_FALSE;
> +
> +   device_name = drv->QueryDeviceName(disp);

This is /dev/dri/renderD128...

> +   mtx_lock(_eglGlobal.Mutex);
> +
> +   assert(info->got_devices);
> +
> +   for (dev = info->devices; dev; dev = dev->Next) {
> +  const char *devname = udev_device_get_property_value(
> + dev->Info, "DEVNAME");

And this is /dev/dri/card0, so querying the display will always fail.

Obviously I can paper over this when there's only one device in the
list, but the whole reason I want this is to make multi-GPU work
better. Any ideas on a better approach here?

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

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

[Andy Furniss]

Zhang, Boyuan wrote:

Hi Andy,

Thanks very much for providing all the information.

The I420 U V swapping issue still can't be reproduced from my side, I
will try it again later. CQP issue is fixed in the new patch set I
just submitted. Please use " ... vaapiencodeh264 rate-control=cqp
init-qp=x ..." command, where x can be any value b/w 0--51. Please
give a try and let me know the result. Other issues, e.g. encoding
speed, ffmpeg, will be addressed/investigated later in separate patch
as I mentioned. This initial patch set is to bring up VAAPI encode
for gstreamer with basic functionality working. I will update with
you once we make progress.


CQP is working OK now.

On the I420 I still see it whatever I try and have just managed to
produce a totally trashed output.

Below produces "expected" output = colors are wrong for I420 but the
vid is OK apart from that.

gst-launch-1.0 videotestsrc num-buffers=5 ! 
video/x-raw,format=I420,width=1280,height=720,framerate=1/1 ! 
vaapih264enc ! h264parse ! mp4mux ! filesink location=I420.mp4


gst-launch-1.0 videotestsrc num-buffers=5 ! 
video/x-raw,format=NV12,width=1280,height=720,framerate=1/1 ! 
vaapih264enc ! h264parse ! mp4mux ! filesink location=NV12.mp4


I then decided I would attach a png showing both outputs, to get it
to fit I repeated above with width=720,height=480 and the result for
I420 was totally trashed, NV12 OK.

Replacing vaapih264enc with x264enc for the trashed case produces
good output - so I don't think it's the input that is trashed at that
res/pix_fmt.




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

[Mesa-dev] [Bug 96979] Mesa 10.5.7 implementation error: Trying to disable permanently enabled extensions

[bugzilla-daemon]

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

--- Comment #7 from Eero Tamminen  ---
Btw. If you're just testing whether Mesa would flip out on given HW and have an
automated way of running your test-case (e.g. apitrace trace), you can override
what PCI ID libdrm reports.  When underlying HW is faked, batches are dropped,
but Mesa still does its own part.  As no rendering is then done, you cannot
verify the results correctness though.

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

[Mesa-dev] [Bug 97019] [clover] build failure in llvm/codegen/native.cpp:129:52

[bugzilla-daemon]

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

Bug ID: 97019
   Summary: [clover] build failure in
llvm/codegen/native.cpp:129:52
   Product: Mesa
   Version: git
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: pontost...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Last 6-10 days i can not build mesa with opencl support
Mesa-git 2016.07.15-21
llvm 3.9-4.0 2016.07.15-21

[  287s] virgl_vtest_winsys.c: In function
'virgl_vtest_winsys_resource_cache_create':
[  287s] virgl_vtest_winsys.c:361:20: warning: 'ret' may be used uninitialized
in this function [-Wmaybe-uninitialized]
[  287s] if (!res && ret != -1) {
[  287s] ^
[  287s]   CCLD libvirglvtest.la
[  287s] make[4]: Leaving directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/winsys/virgl/vtest'
[  287s] Making all in winsys/sw/null
[  287s] make[4]: Entering directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/winsys/sw/null'
[  287s]   CC   null_sw_winsys.lo
[  287s]   CCLD libws_null.la
[  287s] make[4]: Leaving directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/winsys/sw/null'
[  287s] Making all in winsys/sw/dri
[  287s] make[4]: Entering directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/winsys/sw/dri'
[  287s]   CC   dri_sw_winsys.lo
[  287s]   CCLD libswdri.la
[  287s] make[4]: Leaving directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/winsys/sw/dri'
[  287s] Making all in winsys/sw/kms-dri
[  287s] make[4]: Entering directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/winsys/sw/kms-dri'
[  287s]   CC   kms_dri_sw_winsys.lo
[  287s]   CCLD libswkmsdri.la
[  287s] make[4]: Leaving directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/winsys/sw/kms-dri'
[  287s] Making all in winsys/sw/wrapper
[  287s] make[4]: Entering directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/winsys/sw/wrapper'
[  287s]   CC   wrapper_sw_winsys.lo
[  288s]   CCLD libwsw.la
[  288s] make[4]: Leaving directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/winsys/sw/wrapper'
[  288s] Making all in targets/pipe-loader
[  288s] make[4]: Entering directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/targets/pipe-loader'
[  288s]   CC   pipe_i965.lo
[  288s]   CC   pipe_nouveau.lo
[  288s]   CC   pipe_r300.lo
[  288s]   CC   pipe_r600.lo
[  288s]   CC   pipe_radeonsi.lo
[  288s]   CC   pipe_vmwgfx.lo
[  288s]   CC   pipe_swrast.lo
[  288s]   CXXLDpipe_i965.la
[  288s]   CXXLDpipe_nouveau.la
[  288s]   CXXLDpipe_r300.la
[  288s]   CXXLDpipe_r600.la
[  288s]   CXXLDpipe_radeonsi.la
[  289s]   CXXLDpipe_vmwgfx.la
[  289s]   CXXLDpipe_swrast.la
[  289s] make[4]: Leaving directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/targets/pipe-loader'
[  289s] Making all in state_trackers/clover
[  289s] make[4]: Entering directory
'/home/abuild/rpmbuild/BUILD/mesa/src/gallium/state_trackers/clover'
[  289s]   CXX  api/libclover_la-device.lo
[  289s]   CXX  api/libclover_la-event.lo
[  289s]   CXX  api/libclover_la-context.lo
[  289s]   CXX  api/libclover_la-interop.lo
[  289s]   CXX  api/libclover_la-dispatch.lo
[  290s]   CXX  api/libclover_la-kernel.lo
[  290s]   CXX  api/libclover_la-memory.lo
[  291s]   CXX  api/libclover_la-platform.lo
[  291s]   CXX  api/libclover_la-program.lo
[  292s]   CXX  api/libclover_la-queue.lo
[  292s]   CXX  api/libclover_la-sampler.lo
[  292s]   CXX  api/libclover_la-transfer.lo
[  294s]   CXX  core/libclover_la-context.lo
[  294s]   CXX  core/libclover_la-device.lo
[  294s]   CXX  core/libclover_la-event.lo
[  295s]   CXX  core/libclover_la-format.lo
[  295s]   CXX  core/libclover_la-kernel.lo
[  296s]   CXX  core/libclover_la-memory.lo
[  296s]   CXX  core/libclover_la-module.lo
[  297s]   CXX  core/libclover_la-platform.lo
[  298s]   CXX  core/libclover_la-program.lo
[  298s]   CXX  core/libclover_la-queue.lo
[  299s]   CXX  core/libclover_la-resource.lo
[  299s]   CXX  core/libclover_la-sampler.lo
[  299s]   CXX  core/libclover_la-timestamp.lo
[  300s]   CXX  tgsi/libcltgsi_la-compiler.lo
[  300s]   CXX  llvm/codegen/libclllvm_la-bitcode.lo
[  300s]   CXX  llvm/codegen/libclllvm_la-common.lo
[  300s]   CXX  llvm/codegen/libclllvm_la-native.lo
[  301s]   CXX  llvm/libclllvm_la-invocation.lo
[  302s]   CXXLDlibcltgsi.la
[  303s] llvm/codegen/native.cpp: In function 'std::vector
{anonymous}::emit_code(llvm::Module&, const clover::llvm::target&,
llvm::TargetMachine::CodeGenFileType, std::string&)':
[  303s] llvm/codegen/native.cpp:129:52: error: invalid initialization of
non-const reference of type 

Re: [Mesa-dev] [PATCH 1/8] nir: Add a pass for lowering away constant initializers

[Iago Toral]

I dropped a few minor comments in patches 1, 2, 4 and 5, I don't think
any of them are very relevant, so feel free to ignore them. Otherwise:

Patches 1-5 and 7-8 are:
Reviewed-by: Iago Toral Quiroga 

On Wed, 2016-07-20 at 15:28 -0700, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand 
> ---
>  src/compiler/Makefile.sources  |   1 +
>  src/compiler/nir/nir.h |   2 +
>  src/compiler/nir/nir_lower_constant_initializers.c | 102
> +
>  3 files changed, 105 insertions(+)
>  create mode 100644
> src/compiler/nir/nir_lower_constant_initializers.c
> 
> diff --git a/src/compiler/Makefile.sources
> b/src/compiler/Makefile.sources
> index 0ff9b23..127b62e 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -190,6 +190,7 @@ NIR_FILES = \
>   nir/nir_lower_bitmap.c \
>   nir/nir_lower_clamp_color_outputs.c \
>   nir/nir_lower_clip.c \
> + nir/nir_lower_constant_initializers.c \
>   nir/nir_lower_double_ops.c \
>   nir/nir_lower_double_packing.c \
>   nir/nir_lower_drawpixels.c \
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 54598a2..99c2fc0 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2330,6 +2330,8 @@ void nir_lower_io_types(nir_shader *shader);
>  void nir_lower_vars_to_ssa(nir_shader *shader);
>  
>  bool nir_remove_dead_variables(nir_shader *shader, nir_variable_mode
> modes);
> +bool nir_lower_constant_initializers(nir_shader *shader,
> + nir_variable_mode modes);
>  
>  void nir_move_vec_src_uses_to_dest(nir_shader *shader);
>  bool nir_lower_vec_to_movs(nir_shader *shader);
> diff --git a/src/compiler/nir/nir_lower_constant_initializers.c
> b/src/compiler/nir/nir_lower_constant_initializers.c
> new file mode 100644
> index 000..d0935e9
> --- /dev/null
> +++ b/src/compiler/nir/nir_lower_constant_initializers.c
> @@ -0,0 +1,102 @@
> +/*
> + * Copyright © 2016 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.
> + */
> +
> +#include "nir.h"
> +#include "nir_builder.h"
> +
> +static bool
> +deref_apply_constant_initializer(nir_deref_var *deref, void *state)
> +{
> +   struct nir_builder *b = state;
> +
> +   nir_load_const_instr *initializer =
> +  nir_deref_get_const_initializer_load(b->shader, deref);
> +   nir_builder_instr_insert(b, >instr);
> +
> +   nir_store_deref_var(b, deref, >def, 0xf);
> +
> +   return true;
> +}
> +
> +static bool
> +lower_const_initializer(struct nir_builder *b, struct exec_list
> *var_list)
> +{
> +   bool progress = false;
> +
> +   b->cursor = nir_before_cf_list(>impl->body);
> +
> +   nir_foreach_variable(var, var_list) {
> +  if (!var->constant_initializer)
> + continue;
> +
> +  progress = true;
> +
> +  nir_deref_var deref;
> +  deref.deref.deref_type = nir_deref_type_var,
> +  deref.deref.child = NULL;
> +  deref.deref.type = var->type,
> +  deref.var = var;
> +
> +  nir_deref_foreach_leaf(,
> deref_apply_constant_initializer, b);
> +
> +  var->constant_initializer = NULL;
> +   }
> +
> +   return progress;
> +}
> +
> +bool
> +nir_lower_constant_initializers(nir_shader *shader,
> nir_variable_mode modes)
> +{
> +   bool progress = false;
> +
> +   nir_builder builder;
> +   if (modes & ~nir_var_local)
> +  nir_builder_init(, nir_shader_get_entrypoint(shader)-
> >impl);
> +
> +   if (modes & nir_var_shader_out)
> +  progress |= lower_const_initializer(, 
> >outputs);
> +
> +   if (modes & nir_var_global)
> +  progress |= lower_const_initializer(, 
> >globals);
> +
> +   if (modes & nir_var_system_value)
> +  progress |= lower_const_initializer(, 
> >system_values);
> +
> +   if (modes & nir_var_local) {
> +   

[Mesa-dev] [Bug 96979] Mesa 10.5.7 implementation error: Trying to disable permanently enabled extensions

[bugzilla-daemon]

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

--- Comment #6 from Ruslan Kabatsayev  ---
(In reply to Emil Velikov from comment #5)
> Note that MESA_EXTENSION_OVERRIDE is aimed for development/workarounds and
> {en,dis}abling extension X does not magically {give,remove} all the
> functionality associated with it.

By developers do you mean Mesa developers? Or application developers too? I was
trying to use it to test Wine fallback code for the case when it would run on
i915, but without having to even use this hardware for this — by just disabling
the extensions i915 driver doesn't support/expose (based on glxinfo output on
i915 machine).

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

Re: [Mesa-dev] [PATCH 5/8] nir: Simplify nir_lower_gs_intrinsics

[Iago Toral]

On Wed, 2016-07-20 at 15:28 -0700, Jason Ekstrand wrote:
> It's only ever called on single-function shaders.  At this point,
> there are
> a lot of helpers that can make it all much simpler.

This is a nice clean-up.

I wonder if for passes like this that have the implicit requirement
that all function calls had been inlined previously, we should add an
assert to make that condition more explicit, or at least add that
requirement in the documentation of the pass itself.

> Signed-off-by: Jason Ekstrand 
> ---
>  src/compiler/nir/nir_lower_gs_intrinsics.c | 37 +---
> --
>  1 file changed, 16 insertions(+), 21 deletions(-)
> 
> diff --git a/src/compiler/nir/nir_lower_gs_intrinsics.c
> b/src/compiler/nir/nir_lower_gs_intrinsics.c
> index 9bbaf83..13a4399 100644
> --- a/src/compiler/nir/nir_lower_gs_intrinsics.c
> +++ b/src/compiler/nir/nir_lower_gs_intrinsics.c
> @@ -188,32 +188,27 @@ nir_lower_gs_intrinsics(nir_shader *shader)
> struct state state;
> state.progress = false;
>  
> -   /* Create the counter variable */
> -   nir_variable *var = rzalloc(shader, nir_variable);
> -   var->data.mode = nir_var_global;
> -   var->type = glsl_uint_type();
> -   var->name = "vertex_count";
> -   var->constant_initializer = rzalloc(shader, nir_constant); /*
> initialize to 0 */
> +   nir_function_impl *impl = nir_shader_get_entrypoint(shader)-
> >impl;
> +   assert(impl);
>  
> -   exec_list_push_tail(>globals, >node);
> -   state.vertex_count_var = var;
> +   nir_builder b;
> +   nir_builder_init(, impl);
> +   state.builder = 
>  
> -   nir_foreach_function(function, shader) {
> -  if (function->impl) {
> - nir_builder b;
> - nir_builder_init(, function->impl);
> - state.builder = 
> +   /* Create the counter variable */
> +   state.vertex_count_var =
> +  nir_local_variable_create(impl, glsl_uint_type(),
> "vertex_count");
> +   /* initialize to 0 */
> +   b.cursor = nir_before_cf_list(>body);
> +   nir_store_var(, state.vertex_count_var, nir_imm_int(, 0),
> 0x1);
>  
> - nir_foreach_block_safe(block, function->impl) {
> -rewrite_intrinsics(block, );
> - }
> +   nir_foreach_block_safe(block, impl)
> +  rewrite_intrinsics(block, );
>  
> - /* This only works because we have a single main()
> function. */
> - append_set_vertex_count(function->impl->end_block, );
> +   /* This only works because we have a single main() function. */
> +   append_set_vertex_count(impl->end_block, );
>  
> - nir_metadata_preserve(function->impl, 0);
> -  }
> -   }
> +   nir_metadata_preserve(impl, 0);
>  
> return state.progress;
>  }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 96979] Mesa 10.5.7 implementation error: Trying to disable permanently enabled extensions

[bugzilla-daemon]

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

--- Comment #5 from Emil Velikov  ---
With 12.0 (commit 21d43fe51ab5bcbc89ad5c61a51d3517c4243298) one should be able
to disable permanently enabled extensions in a way that glGetString{,i} honours
it.

IIRC the above patch depends it depends on other extensions work by Nanley so
picking it on top of 11.0.x might fare too well.

Note that MESA_EXTENSION_OVERRIDE is aimed for development/workarounds and
{en,dis}abling extension X does not magically {give,remove} all the
functionality associated with it.

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

Re: [Mesa-dev] [PATCH 4/8] nir/lower_returns: Stop using constant initializers

[Iago Toral]

I guess this isn't really necessary since we are going to lower
constant initializers away eventually, right? I have no objections to
saving the pass some work of course, just wondering if that's really
all there is to this change or if I am missing something else.

Iago

On Wed, 2016-07-20 at 15:28 -0700, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand 
> ---
>  src/compiler/nir/nir_lower_returns.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/src/compiler/nir/nir_lower_returns.c
> b/src/compiler/nir/nir_lower_returns.c
> index 8dbea6e..cf49d5b 100644
> --- a/src/compiler/nir/nir_lower_returns.c
> +++ b/src/compiler/nir/nir_lower_returns.c
> @@ -147,17 +147,18 @@ lower_returns_in_block(nir_block *block, struct
> lower_returns_state *state)
> nir_instr_remove(>instr);
>  
> nir_builder *b = >builder;
> -   b->cursor = nir_after_block(block);
>  
> /* Set the return flag */
> if (state->return_flag == NULL) {
>    state->return_flag =
>   nir_local_variable_create(b->impl, glsl_bool_type(),
> "return");
>  
> -  /* Set a default value of false */
> -  state->return_flag->constant_initializer =
> - rzalloc(state->return_flag, nir_constant);
> +  /* Initialize the variable to 0 */
> +  b->cursor = nir_before_cf_list(>impl->body);
> +  nir_store_var(b, state->return_flag, nir_imm_int(b,
> NIR_FALSE), 1);
> }
> +
> +   b->cursor = nir_after_block(block);
> nir_store_var(b, state->return_flag, nir_imm_int(b, NIR_TRUE),
> 1);
>  
> if (state->loop) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/8] nir: Add a pass for lowering away constant initializers

[Iago Toral]

On Wed, 2016-07-20 at 15:28 -0700, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand 
> ---
>  src/compiler/Makefile.sources  |   1 +
>  src/compiler/nir/nir.h |   2 +
>  src/compiler/nir/nir_lower_constant_initializers.c | 102
> +
>  3 files changed, 105 insertions(+)
>  create mode 100644
> src/compiler/nir/nir_lower_constant_initializers.c
> 
> diff --git a/src/compiler/Makefile.sources
> b/src/compiler/Makefile.sources
> index 0ff9b23..127b62e 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -190,6 +190,7 @@ NIR_FILES = \
>   nir/nir_lower_bitmap.c \
>   nir/nir_lower_clamp_color_outputs.c \
>   nir/nir_lower_clip.c \
> + nir/nir_lower_constant_initializers.c \
>   nir/nir_lower_double_ops.c \
>   nir/nir_lower_double_packing.c \
>   nir/nir_lower_drawpixels.c \
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 54598a2..99c2fc0 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2330,6 +2330,8 @@ void nir_lower_io_types(nir_shader *shader);
>  void nir_lower_vars_to_ssa(nir_shader *shader);
>  
>  bool nir_remove_dead_variables(nir_shader *shader, nir_variable_mode
> modes);
> +bool nir_lower_constant_initializers(nir_shader *shader,
> + nir_variable_mode modes);
>  
>  void nir_move_vec_src_uses_to_dest(nir_shader *shader);
>  bool nir_lower_vec_to_movs(nir_shader *shader);
> diff --git a/src/compiler/nir/nir_lower_constant_initializers.c
> b/src/compiler/nir/nir_lower_constant_initializers.c
> new file mode 100644
> index 000..d0935e9
> --- /dev/null
> +++ b/src/compiler/nir/nir_lower_constant_initializers.c
> @@ -0,0 +1,102 @@
> +/*
> + * Copyright © 2016 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.
> + */
> +
> +#include "nir.h"
> +#include "nir_builder.h"
> +
> +static bool
> +deref_apply_constant_initializer(nir_deref_var *deref, void *state)
> +{
> +   struct nir_builder *b = state;
> +
> +   nir_load_const_instr *initializer =
> +  nir_deref_get_const_initializer_load(b->shader, deref);
> +   nir_builder_instr_insert(b, >instr);
> +
> +   nir_store_deref_var(b, deref, >def, 0xf);
> +
> +   return true;
> +}
> +
> +static bool
> +lower_const_initializer(struct nir_builder *b, struct exec_list
> *var_list)
> +{
> +   bool progress = false;
> +
> +   b->cursor = nir_before_cf_list(>impl->body);
> +
> +   nir_foreach_variable(var, var_list) {
> +  if (!var->constant_initializer)
> + continue;
> +
> +  progress = true;
> +
> +  nir_deref_var deref;
> +  deref.deref.deref_type = nir_deref_type_var,
> +  deref.deref.child = NULL;
> +  deref.deref.type = var->type,
> +  deref.var = var;
> +
> +  nir_deref_foreach_leaf(,
> deref_apply_constant_initializer, b);
> +
> +  var->constant_initializer = NULL;
> +   }
> +
> +   return progress;
> +}
> +
> +bool
> +nir_lower_constant_initializers(nir_shader *shader,
> nir_variable_mode modes)
> +{
> +   bool progress = false;
> +
> +   nir_builder builder;
> +   if (modes & ~nir_var_local)
> +  nir_builder_init(, nir_shader_get_entrypoint(shader)-
> >impl);
> +
> +   if (modes & nir_var_shader_out)
> +  progress |= lower_const_initializer(, 
> >outputs);
> +
> +   if (modes & nir_var_global)
> +  progress |= lower_const_initializer(, 
> >globals);
> +
> +   if (modes & nir_var_system_value)
> +  progress |= lower_const_initializer(, 
> >system_values);
> +
> +   if (modes & nir_var_local) {
> +  nir_foreach_function(function, shader) {
> + if (!function->impl)
> +continue;
> +
> + nir_builder_init(, function->impl);
> + if (lower_const_initializer(, >impl-
> >locals)) {
> + 

Re: [Mesa-dev] [PATCH 2/8] anv/pipeline: Call nir_lower_constant_initializers

[Iago Toral]

On Wed, 2016-07-20 at 15:28 -0700, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand 
> ---
>  src/intel/vulkan/anv_pipeline.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_pipeline.c
> b/src/intel/vulkan/anv_pipeline.c
> index 3723423..df57182 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -149,6 +149,13 @@ anv_shader_compile_to_nir(struct anv_device
> *device,
>    nir_lower_returns(nir);
>    nir_validate_shader(nir);
>  
> +  /* We have to lower away local constant initializers right
> before we
> +   * inline functions.  That way they get properly initialized
> at the top
> +   * of the function and not at the top of its caller.
> +   */
> +  nir_lower_constant_initializers(nir, nir_var_local);
> +  nir_validate_shader(nir);
> +
>    nir_inline_functions(nir);
>    nir_validate_shader(nir);
>  
> @@ -165,6 +172,12 @@ anv_shader_compile_to_nir(struct anv_device
> *device,
>    nir_remove_dead_variables(nir, nir_var_system_value);
>    nir_validate_shader(nir);
>  
> +  /* Now that we've deleted all but the main function, we can go
> ahead and
> +   * lower the rest of the constant initializers.
> +   */
> +  nir_lower_constant_initializers(nir, ~0);

Couldn't we just use ~nir_var_local here?

> +  nir_validate_shader(nir);
> +
>    nir_propagate_invariant(nir);
>    nir_validate_shader(nir);
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/12] st/va: add encode entrypoint

[Christian König]

Am 20.07.2016 um 20:00 schrieb Zhang, Boyuan:


>Makes sense, but I suggest that in this case we should add at least a 
comment why this is still disabled.


>And it would look better if we have an "#if 0" or something like this in 
the code which gets explicitly removed with the last patch.


Sure, I agree. I will submit a new patch set to add this and other 
minor changes.


>The problem with slice level encoding is that we haven't fully 
implemented it. E.g. the last time I checked the h264encode test it 
would try to add an SPS and PPS in front of the slice data returned 
from our VA-API driver.


>Since our VA-API driver doesn't return slice data, but rather a full blown 
elementary stream you end up with a complete mess which looks 
something like this:


>SPS (added by the application), PPS (added by the application), Slice 
Header, SPS (added by the driver), PPS(added by the driver), Slice 
Header/Slice Data.


>That might work in some if not most cases, but is certainly not complaint 
to the VA-API specification.


>

>Christian.

I just tried to disable slice encoding support, and even Gstreamer is 
not working. It will give error message saying “unsupported HW profile”.


On the other hand, by exposing slice encoding, Gstreamer will still 
work as “Frame-in, Frame-out” mode. I didn’t see that Gstreamer will 
add extra headers. And by dumping the output 264 output, it seems 
gstreamer is using picture encoding. However, as my test shown, 
gstreamer will not work at all if we don’t expose slice encoding. Do 
you have any suggestions how we should do for this situation?




Good question. From the GStreamer source it looks like VA-API was 
switched from returning only slice data to a full blown elementary 
stream at some point.


Picture encoding seems to be only used for JPEG as far as I can see.

Anyway let's keep it like this for now and fix all the fallout we will 
run into later on.


Regards,
Christian.


Regards,

Boyuan

*From:*Christian König [mailto:deathsim...@vodafone.de]
*Sent:* July-20-16 4:48 AM
*To:* Zhang, Boyuan; mesa-dev@lists.freedesktop.org
*Cc:* adf.li...@gmail.com
*Subject:* Re: [PATCH 05/12] st/va: add encode entrypoint

Am 20.07.2016 um 06:12 schrieb Zhang, Boyuan:

>> @@ -150,7 +167,16 @@ vlVaCreateConfig(VADriverContextP ctx,
VAProfile profile, VAEntrypoint entrypoin
>>  if (entrypoint != VAEntrypointVLD)
>> return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;
>>
>> -   *config_id = p;
>> +   if (entrypoint == VAEntrypointEncSlice || entrypoint ==
VAEntrypointEncPicture)
>> +  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_ENCODE;
>> +   else
>> +  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;

>Well that doesn't make much sense here.

>First we return and error if the entrypoint isn't VAEntrypointVLD
and
>then check if it's an encoding entry point.

>Additional to that I already wondered if we are really going to
support
>slice level as well as picture level encoding.

>I think that it should only be one of the two.

>Regards,
>Christian.

Hi Christian,

Sorry for the confusion, The first 2 lines of codes

>>if (entrypoint != VAEntrypointVLD)
>> return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;

will actually be removed in the last patch where we enable the
VAAPI Encode (Patch 12/12). In other word, we don't accept
VAEncode entrypoint until the time we enable VAAPI Encode.
Therefore, we still only accept VAEntrypointVLD at this patch.


Makes sense, but I suggest that in this case we should add at least a 
comment why this is still disabled.


And it would look better if we have an "#if 0" or something like this 
in the code which gets explicitly removed with the last patch.



And we need to accept both picture level and slice level entrypoint. 
For some application, e.g. libva h264encode test, if we don't enable 
slice level encode, it will fail the call and report h264 encode is 
not supported. If we enable both, it will still use picture level 
encode. That's why I put both here.



The problem with slice level encoding is that we haven't fully 
implemented it. E.g. the last time I checked the h264encode test it 
would try to add an SPS and PPS in front of the slice data returned 
from our VA-API driver.


Since our VA-API driver doesn't return slice data, but rather a full 
blown elementary stream you end up with a complete mess which looks 
something like this:


SPS (added by the application), PPS (added by the application), Slice 
Header, SPS (added by the driver), PPS(added by the driver), Slice 
Header/Slice Data.


That might work in some if not most cases, but is certainly not 
complaint to the VA-API specification.


Christian.


Regards,

Boyuan



*From:*Christian König  


*Sent:* July 19, 

Re: [Mesa-dev] Mesa (master): Revert "radeon/llvm: Use alloca instructions for larger arrays"

[Matt Arsenault]

> On Jul 21, 2016, at 01:03, Michel Dänzer  wrote:
> 
> On 21.07.2016 00:04, Michel Dänzer wrote:
>> On 15.07.2016 05:15, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
>>> Module: Mesa
>>> Branch: master
>>> Commit: f84e9d749fbb6da73a60fb70e6725db773c9b8f8
>>> URL:
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f84e9d749fbb6da73a60fb70e6725db773c9b8f8
>>> 
>>> Author: Marek Olšák 
>>> Date:   Thu Jul 14 22:07:46 2016 +0200
>>> 
>>> Revert "radeon/llvm: Use alloca instructions for larger arrays"
>>> 
>>> This reverts commit 513fccdfb68e6a71180e21827f071617c93fd09b.
>>> 
>>> Bioshock Infinite hangs with that.
>> 
>> Unfortunately, this change caused the piglit test
>> shaders@glsl-fs-vec4-indexing-temp-dst-in-loop (and possibly others) to
>> hang my Kaveri. Any ideas for how we can get out of this conundrum?
> 
> The hang was introduced by LLVM SVN r275934 ("AMDGPU: Expand register
> indexing pseudos in custom inserter"). The good/bad (without/with
> r275934) shader dumps and the GALLIUM_DDEBUG=800 dump corresponding to
> the hang are attached.
> 
> 
> BTW, even with Marek's change above reverted, I still see some piglit
> regressions compared to last week, but I'm not sure if those are all
> related to the same LLVM change.
> 
> 
> -- 
> Earthling Michel Dänzer   |   http://www.amd.com 
> 
> Libre software enthusiast | Mesa and X developer
> 

This fixes the verifier error in it: https://reviews.llvm.org/D22616 

This fixes another issue which may be related: https://reviews.llvm.org/D22556 


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

Re: [Mesa-dev] [PATCH] vl/dri3: fix a memory leak from front buffer

[Christian König]

Am 14.07.2016 um 17:02 schrieb Leo Liu:

Inspired by fix for mem leak of vdpau interop, resource_from_handle
set texture reference count, that need to be decreased and released,
recall there is a similar case for DRI3, that is with VA-API glx
extension, there is temporary TFP(texture from pixmap), we target it
through dma-buf. leak happens when without count down the reference.

Checked and found with mpv vo=opengl case, there only one static TFP,
the leak happens once, but for totem player using gstreamer VA-API glx,
the dynamic TFP for each frame, so leak quite a bit.

This fixes mem leak for mpv and totem.

Signed-off-by: Leo Liu 
Cc: "12.0" 


Looks like I never replied on this :( I simply have to much on my todo list.

Patch is Reviewed-by: Christian König  if you 
haven't already pushed it.


Regards,
Christian.


---
  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index f7f572e..493e645 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -89,6 +89,7 @@ dri3_free_front_buffer(struct vl_dri3_screen *scrn,
  {
 xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
 xshmfence_unmap_shm(buffer->shm_fence);
+   pipe_resource_reference(>texture, NULL);
 FREE(buffer);
  }
  



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

Re: [Mesa-dev] [PATCH 05/12] st/va: add encode entrypoint

[Christian König]

Am 21.07.2016 um 00:13 schrieb Boyuan Zhang:

VAAPI passes PIPE_VIDEO_ENTRYPOINT_ENCODE as entry point for encoding case. We 
will save this encode entry point in config. config_id was used as profile 
previously. Now, config has both profile and entrypoint field, and config_id is 
used to get the config object. Later on, we pass this entrypoint to 
context->templat.entrypoint instead of always hardcoded to 
PIPE_VIDEO_ENTRYPOINT_BITSTREAM for decoding case previously. Encode entrypoint is 
not accepted by driver until we enable Vaapi encode in later patch.

Signed-off-by: Boyuan Zhang 
---
  src/gallium/state_trackers/va/config.c | 71 +++---
  src/gallium/state_trackers/va/context.c| 59 +++--
  src/gallium/state_trackers/va/surface.c| 14 --
  src/gallium/state_trackers/va/va_private.h |  5 +++
  4 files changed, 117 insertions(+), 32 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 9ca0aa8..3aacc63 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -34,6 +34,8 @@
  
  #include "va_private.h"
  
+#include "util/u_handle_table.h"

+
  DEBUG_GET_ONCE_BOOL_OPTION(mpeg4, "VAAPI_MPEG4_ENABLED", false)
  
  VAStatus

@@ -128,14 +130,29 @@ VAStatus
  vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint 
entrypoint,
   VAConfigAttrib *attrib_list, int num_attribs, VAConfigID 
*config_id)
  {
+   vlVaDriver *drv;
+   vlVaConfig *config;
 struct pipe_screen *pscreen;
 enum pipe_video_profile p;
  
 if (!ctx)

return VA_STATUS_ERROR_INVALID_CONTEXT;
  
+   drv = VL_VA_DRIVER(ctx);

+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   config = CALLOC(1, sizeof(vlVaConfig));
+   if (!config)
+  return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
 if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) {
-  *config_id = PIPE_VIDEO_PROFILE_UNKNOWN;
+  config->entrypoint = VAEntrypointVideoProc;
+  config->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
+  pipe_mutex_lock(drv->mutex);
+  *config_id = handle_table_add(drv->htab, config);
+  pipe_mutex_unlock(drv->mutex);
return VA_STATUS_SUCCESS;
 }
  
@@ -150,7 +167,18 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin

 if (entrypoint != VAEntrypointVLD)
return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;
  
-   *config_id = p;

+#if 0
+   if (entrypoint == VAEntrypointEncSlice || entrypoint == 
VAEntrypointEncPicture)
+  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_ENCODE;
+   else
+#endif
+  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;


If you don't mind I'm just going ahead and replacing this with a 
switch/case statement.


Going to commit the patch with that change in the evening if you don't 
have any objections, but you probably have to rebase your set on top of 
master then.


Christian.


+
+   config->profile = p;
+
+   pipe_mutex_lock(drv->mutex);
+   *config_id = handle_table_add(drv->htab, config);
+   pipe_mutex_unlock(drv->mutex);
  
 return VA_STATUS_SUCCESS;

  }
@@ -158,9 +186,27 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
  VAStatus
  vlVaDestroyConfig(VADriverContextP ctx, VAConfigID config_id)
  {
+   vlVaDriver *drv;
+   vlVaConfig *config;
+
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
  
+   drv = VL_VA_DRIVER(ctx);

+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   pipe_mutex_lock(drv->mutex);
+   config = handle_table_get(drv->htab, config_id);
+
+   if (!config)
+  return VA_STATUS_ERROR_INVALID_CONFIG;
+
+   FREE(config);
+   handle_table_remove(drv->htab, config_id);
+   pipe_mutex_unlock(drv->mutex);
+
 return VA_STATUS_SUCCESS;
  }
  
@@ -168,18 +214,33 @@ VAStatus

  vlVaQueryConfigAttributes(VADriverContextP ctx, VAConfigID config_id, 
VAProfile *profile,
VAEntrypoint *entrypoint, VAConfigAttrib 
*attrib_list, int *num_attribs)
  {
+   vlVaDriver *drv;
+   vlVaConfig *config;
+
 if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
  
-   *profile = PipeToProfile(config_id);

+   drv = VL_VA_DRIVER(ctx);
+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   pipe_mutex_lock(drv->mutex);
+   config = handle_table_get(drv->htab, config_id);
+   pipe_mutex_unlock(drv->mutex);
+
+   if (!config)
+  return VA_STATUS_ERROR_INVALID_CONFIG;
+
+   *profile = PipeToProfile(config->profile);
  
-   if (config_id == PIPE_VIDEO_PROFILE_UNKNOWN) {

+   if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
*entrypoint = VAEntrypointVideoProc;
*num_attribs = 0;
return VA_STATUS_SUCCESS;
 }
  
-   *entrypoint = VAEntrypointVLD;

+   *entrypoint = config->entrypoint;
  
 *num_attribs = 1;

 attrib_list[0].type = 

Re: [Mesa-dev] VAAPI egl interop on radeon

[Christian König]

Hi Jan,

I don't think we have implemented EGL interop on VA-API to this extend. 
All that is supported is exporting the handle of RGBA images, not 
directly decoded YUV data.


If you need decoding support with OpenGL/EGL interop on AMD hardware 
please use VDPAU instead.


Regards,
Christian.

Am 15.07.2016 um 11:25 schrieb Jan Burgmeier:

Hi,

I am developing an application which uses vaapi and egl. My goal is to 
use vaDeriveImage and vaAcquireBufferHandle to get the drm buffer id 
which then can be used to create a EGLImageKHR. My problem is, that on 
amd hardware (AMD GX-212ZC SOC with Radeon(TM) R1E Graphics and AMD 
GX-424CC SOC with Radeon(TM) R5E Graphics) vaDeriveImage fails with 
"invalid VASurfaceID" and when I do vaGetImage as a fallback to get 
the image vaAcquireBufferHandle fails with "invalid VABufferID". The 
same code works on Intel hardware.


Mesa version: 11.2.2

 - Should this work in general?
 - Is there any special setting needed?

Kind regards
Jan Burgmeier


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



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

[Mesa-dev] [Bug 96979] Mesa 10.5.7 implementation error: Trying to disable permanently enabled extensions

[bugzilla-daemon]

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

--- Comment #4 from Ruslan Kabatsayev  ---
Trying this with Mesa 11.0.2 doesn't crash glxinfo, but I still get the
following discrepancy:

$ glxinfo | grep GL_APPLE_texture_max_level
$ MESA_EXTENSION_OVERRIDE=-GL_APPLE_texture_max_level glxinfo >/dev/null
Mesa 11.0.2 implementation error: Trying to disable permanently enabled
extensions: GL_APPLE_texture_max_level
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa

I.e. despite the extension isn't listed by glxinfo, disabling it explicitly
leads to error message saying that it's permanently enabled. It seems
permanently enabled extensions should be present in glGetString(GL_EXTENSIONS)
and similar API's results.

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

Re: [Mesa-dev] [PATCH] i965: Include VUE handles for GS with invocations > 1.

[Samuel Iglesias Gonsálvez]

Reviewed-by: Samuel Iglesias Gonsálvez 

On 21/07/16 03:04, Kenneth Graunke wrote:
> We always resort to the pull model for instanced GS inputs.  So, we'd
> better include the VUE handles, or else we can't actually pull anything.
> 
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 53e7183..f9af525 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -5581,7 +5581,7 @@ fs_visitor::setup_gs_payload()
>  * have to multiply by VerticesIn to obtain the total storage requirement.
>  */
> if (8 * vue_prog_data->urb_read_length * nir->info.gs.vertices_in >
> -   max_push_components) {
> +   max_push_components || gs_prog_data->invocations > 1) {
>gs_prog_data->base.include_vue_handles = true;
>  
>/* R3..RN: ICP Handles for each incoming vertex (when using pull 
> model) */
> 



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] RFC Steps towards replacing the GLSL IR optimisations with NIR

[Timothy Arceri]

On Wed, 2016-07-20 at 20:57 +1000, Timothy Arceri wrote:
> Currently disabling these optimisations causes some major regressions
> mainly
> because cross shader removal of unused varyings is done in the GLSL
> IR linker.
> 
> I've spent some time today attempting to insert a glsl->nir
> conversion just
> before assigning varying locations. The idea was I could then call
> some nir
> optimisations, check what varyings are left in nir then remove the
> varyings
> from the producing GLSL IR stage and continue on (this happens in FS-
> >VS order).
> Ideally we would use the GLSL IR for validation and PIQ and would be
> able to
> hold onto the nir and reuse it in the backend. We should also be able
> to do
> the same for unused uniforms but thats not as useful.
> 
> Unfortunatly the order in which we do things currently e.g lowering
> UBOs
> after running link_uniforms is making things difficult and I dont yet
> have a solid plan to solve all the issues. However in order to create
> the nir I needed to first call the drivers GLSL processing pass and
> this
> proved to do a nice job of removing a bunch of instructions itself so
> I'm sending this as a first step.
> 
> Broadwell shader-db results:
> 
> total instructions in shared programs: 8649621 -> 8642352 (-0.08%)
> instructions in affected programs: 49023 -> 41754 (-14.83%)
> total loops in shared programs:2087 -> 2087 (0.00%)
> helped:359
> HURT:  5
> GAINED:0
> LOST:  0
> 
> There are two piglit tests failing with these changes:
> 
> tests/spec/arb_gpu_shader5/execution/samplemaskin-
> indirect.shader_test
> Fails because the uniform is now optimised away an can no longer be
> found.
> 
> tests/spec/glsl-1.50/execution/geometry/max-input-
> components.shader_test
> Fails to link on hsw, snb and ivb. There is no error message linking
> just
> fails, I'm still looking into the problem.

It seems the vec4 backend fails to spill registers when compiling the
gs.

> 
> Full shader-db results bellow in case anyone wants to dig further
> into these results.
> 
> helped:   shaders/closed/steam/tropico-5/99.shader_test FS SIMD16:
> 591 -> 590 (-0.17%)
> helped:   shaders/closed/UnrealEngine4/VehicleGame/42.shader_test FS
> SIMD16: 362 -> 361 (-0.28%)
> helped:   shaders/closed/steam/dota-2-reborn/1641.shader_test FS
> SIMD16: 334 -> 333 (-0.30%)
> helped:   shaders/closed/steam/dota-2-reborn/1925.shader_test FS
> SIMD16: 327 -> 326 (-0.31%)
> helped:   shaders/closed/steam/dota-2-reborn/1933.shader_test FS
> SIMD16: 326 -> 325 (-0.31%)
> helped:   shaders/closed/steam/dota-2-reborn/1967.shader_test FS
> SIMD16: 315 -> 314 (-0.32%)
> helped:   shaders/closed/steam/dota-2-reborn/1845.shader_test FS
> SIMD16: 313 -> 312 (-0.32%)
> helped:   shaders/closed/steam/dota-2-reborn/1717.shader_test FS
> SIMD16: 304 -> 303 (-0.33%)
> helped:   shaders/closed/UnrealEngine4/ReflectionsSubwayDemo/282.shad
> er_test FS SIMD16: 250 -> 249 (-0.40%)
> helped:   shaders/closed/steam/metro-2033-redux/3274.shader_test VS
> SIMD8: 221 -> 220 (-0.45%)
> helped:   shaders/closed/steam/metro-2033-redux/6530.shader_test VS
> SIMD8: 215 -> 214 (-0.47%)
> helped:   shaders/closed/steam/metro-2033-redux/6528.shader_test VS
> SIMD8: 215 -> 214 (-0.47%)
> helped:   shaders/closed/steam/metro-2033-redux/5977.shader_test VS
> SIMD8: 214 -> 213 (-0.47%)
> helped:   shaders/closed/steam/metro-2033-redux/4775.shader_test VS
> SIMD8: 214 -> 213 (-0.47%)
> helped:   shaders/closed/steam/metro-2033-redux/5603.shader_test VS
> SIMD8: 214 -> 213 (-0.47%)
> helped:   shaders/closed/steam/metro-2033-redux/5605.shader_test VS
> SIMD8: 214 -> 213 (-0.47%)
> helped:   shaders/closed/steam/metro-2033-redux/4943.shader_test VS
> SIMD8: 213 -> 212 (-0.47%)
> helped:   shaders/closed/steam/metro-2033-redux/4774.shader_test VS
> SIMD8: 211 -> 210 (-0.47%)
> helped:   shaders/closed/steam/metro-2033-redux/4773.shader_test VS
> SIMD8: 211 -> 210 (-0.47%)
> helped:   shaders/closed/steam/metro-2033-redux/4648.shader_test VS
> SIMD8: 208 -> 207 (-0.48%)
> helped:   shaders/closed/steam/metro-2033-redux/6529.shader_test VS
> SIMD8: 207 -> 206 (-0.48%)
> helped:   shaders/closed/steam/metro-2033-redux/3275.shader_test VS
> SIMD8: 207 -> 206 (-0.48%)
> helped:   shaders/closed/steam/metro-2033-redux/2478.shader_test VS
> SIMD8: 206 -> 205 (-0.49%)
> helped:   shaders/closed/steam/metro-2033-redux/5604.shader_test VS
> SIMD8: 206 -> 205 (-0.49%)
> helped:   shaders/closed/steam/metro-2033-redux/2479.shader_test VS
> SIMD8: 206 -> 205 (-0.49%)
> helped:   shaders/closed/steam/metro-2033-redux/5976.shader_test VS
> SIMD8: 206 -> 205 (-0.49%)
> helped:   shaders/closed/steam/metro-2033-redux/4942.shader_test VS
> SIMD8: 205 -> 204 (-0.49%)
> helped:   shaders/closed/steam/metro-2033-redux/4941.shader_test VS
> SIMD8: 205 -> 204 (-0.49%)
> helped: