Re: [Mesa-dev] [PATCH v2 2/3] anv/blorp: consider multiview and view masks for tracking pending clear aspects

[Jason Ekstrand]

Do we really want to wait until a subpass that uses the given view or do we
just want to clear all of the relevant slices in the first subpass that
touches it?  I haven't really thought about this much.

On Fri, Jan 5, 2018 at 8:38 AM, Iago Toral Quiroga 
wrote:

> When multiview is active a subpass clear may only clear a subset of the
> attachment layers. Other subpasses in the same render pass may also
> clear too and we want to honor those clears as well, however, we need to
> ensure that we only clear a layer once, on the first subpass that uses
> a particular layer (view) of a given attachment.
>
> This means that when we check if a subpass attachment needs to be cleared
> we need to check if all the layers used by that subpass (as indicated by
> its view_mask) have already been cleared in previous subpasses or not, in
> which case, we must clear any pending layers used by the subpass, and only
> those pending.
>
> Fixes work-in-progress CTS tests:
> dEQP-VK.multiview.readback_implicit_clear.*
> ---
>  src/intel/vulkan/anv_blorp.c | 56 ++
> ++
>  1 file changed, 52 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index 18fa4a4ae5..0dac20ea80 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1110,6 +1110,39 @@ enum subpass_stage {
> SUBPASS_STAGE_RESOLVE,
>  };
>
> +/**
> + * Goes through all the previous subpasses to the current subpass and
> collects
> + * information about the layers (views) of the given attachment that have
> + * already been cleared by previous subpasses. The function return the
> layers
> + * (views), if any, that still need to be cleared when current subpass
> starts.
> + */
> +static uint32_t
> +subpass_views_with_pending_clear(const struct anv_cmd_buffer *cmd_buffer,
> + const uint32_t att_idx)
> +{
> +   const struct anv_cmd_state *cmd_state = _buffer->state;
> +   const struct anv_render_pass *pass = cmd_state->pass;
> +   const struct anv_subpass *subpass = cmd_state->subpass;
> +
> +   if (!subpass->view_mask)
> +  return 0;
> +
> +   uint32_t cleared_views = 0;
> +   uint32_t subpass_idx = 0;
> +   const struct anv_subpass *s = >subpasses[subpass_idx];
> +   while (s != subpass) {
> +  for (uint32_t i = 0; i < s->color_count; i++) {
> + uint32_t idx = s->color_attachments[i].attachment;
> + if (idx != att_idx)
> +continue;
> + cleared_views |= s->view_mask;
> +  }
> +  s = >subpasses[++subpass_idx];
> +   }
> +
> +   return subpass->view_mask & (~cleared_views);
> +}
> +
>  static bool
>  subpass_needs_clear(const struct anv_cmd_buffer *cmd_buffer)
>  {
> @@ -1142,7 +1175,6 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer
> *cmd_buffer)
> const struct anv_cmd_state *cmd_state = _buffer->state;
> const VkRect2D render_area = cmd_buffer->state.render_area;
>
> -
> if (!subpass_needs_clear(cmd_buffer))
>return;
>
> @@ -1205,7 +1237,9 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer
> *cmd_buffer)
>   assert(image->n_planes == 1);
>   if (cmd_state->subpass->view_mask) {
>  uint32_t view_idx;
> -for_each_bit(view_idx, cmd_state->subpass->view_mask) {
> +uint32_t pending_clear_mask =
> +   subpass_views_with_pending_clear(cmd_buffer, a);
> +for_each_bit(view_idx, pending_clear_mask) {
> blorp_fast_clear(, ,
> iview->planes[0].isl.format,
>  iview->planes[0].isl.base_level,
>  view_idx, 1,
> @@ -1227,7 +1261,9 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer
> *cmd_buffer)
>   assert(image->n_planes == 1);
>   if (cmd_state->subpass->view_mask) {
>  uint32_t view_idx;
> -for_each_bit(view_idx, cmd_state->subpass->view_mask) {
> +uint32_t pending_clear_mask =
> +   subpass_views_with_pending_clear(cmd_buffer, a);
> +for_each_bit(view_idx, pending_clear_mask) {
> blorp_clear(, , iview->planes[0].isl.format,
> anv_swizzle_for_render(iview->
> planes[0].isl.swizzle),
> iview->planes[0].isl.base_level,
> @@ -1249,7 +1285,19 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer
> *cmd_buffer)
>   }
>}
>
> -  att_state->pending_clear_aspects = 0;
> +  if (!cmd_state->subpass->view_mask) {
> + att_state->pending_clear_aspects = 0;
> +  } else {
> + /* If multiview is enabled, then we are only done clearing when
> the
> +  * last subpass that uses this attachment has been processed,
> +  */
> + uint32_t last_subpass_idx =
> +cmd_state->pass->attachments[a].last_subpass_idx;
> + const struct anv_subpass *last_subpass =
> +   

Re: [Mesa-dev] [PATCH 1/2] anv/blorp: only clear enabled views when multiview is used

[Jason Ekstrand]

On Fri, Jan 5, 2018 at 1:28 AM, Iago Toral Quiroga 
wrote:

> ---
>  src/intel/vulkan/anv_blorp.c | 55 ++
> ++
>  1 file changed, 40 insertions(+), 15 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index e244468e03..18fa4a4ae5 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1203,25 +1203,50 @@ anv_cmd_buffer_clear_subpass(struct
> anv_cmd_buffer *cmd_buffer)
>  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT |
> ANV_PIPE_CS_STALL_BIT;
>
>   assert(image->n_planes == 1);
> - blorp_fast_clear(, , iview->planes[0].isl.format,
> -  iview->planes[0].isl.base_level,
> -  iview->planes[0].isl.base_array_layer,
> fb->layers,
> -  render_area.offset.x, render_area.offset.y,
> -  render_area.offset.x + render_area.extent.width,
> -  render_area.offset.y +
> render_area.extent.height);
> -
> + if (cmd_state->subpass->view_mask) {
> +uint32_t view_idx;
> +for_each_bit(view_idx, cmd_state->subpass->view_mask) {
> +   blorp_fast_clear(, ,
> iview->planes[0].isl.format,
> +iview->planes[0].isl.base_level,
> +view_idx, 1,
>

iview->planes[0].isl.base_array_layer + view_idx


> +render_area.offset.x,
> render_area.offset.y,
> +render_area.offset.x +
> render_area.extent.width,
> +render_area.offset.y +
> render_area.extent.height);
> +}
> + } else {
> +blorp_fast_clear(, , iview->planes[0].isl.format,
> + iview->planes[0].isl.base_level,
> + iview->planes[0].isl.base_array_layer,
> fb->layers,
> + render_area.offset.x, render_area.offset.y,
> + render_area.offset.x +
> render_area.extent.width,
> + render_area.offset.y +
> render_area.extent.height);
> + }
>   cmd_buffer->state.pending_pipe_bits |=
>  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT |
> ANV_PIPE_CS_STALL_BIT;
>} else {
>   assert(image->n_planes == 1);
> - blorp_clear(, , iview->planes[0].isl.format,
> - anv_swizzle_for_render(iview->
> planes[0].isl.swizzle),
> - iview->planes[0].isl.base_level,
> - iview->planes[0].isl.base_array_layer, fb->layers,
> - render_area.offset.x, render_area.offset.y,
> - render_area.offset.x + render_area.extent.width,
> - render_area.offset.y + render_area.extent.height,
> - vk_to_isl_color(att_state->clear_value.color),
> NULL);
> + if (cmd_state->subpass->view_mask) {
> +uint32_t view_idx;
> +for_each_bit(view_idx, cmd_state->subpass->view_mask) {
> +   blorp_clear(, , iview->planes[0].isl.format,
> +   anv_swizzle_for_render(iview->
> planes[0].isl.swizzle),
> +   iview->planes[0].isl.base_level,
> +   view_idx, 1,
>

iview->planes[0].isl.base_array_layer + view_idx

With that fixed, this would be

Reviewed-by: Jason Ekstrand 


> +   render_area.offset.x, render_area.offset.y,
> +   render_area.offset.x +
> render_area.extent.width,
> +   render_area.offset.y +
> render_area.extent.height,
> +   vk_to_isl_color(att_state->clear_value.color),
> NULL);
> +}
> + } else {
> +blorp_clear(, , iview->planes[0].isl.format,
> +anv_swizzle_for_render(iview->
> planes[0].isl.swizzle),
> +iview->planes[0].isl.base_level,
> +iview->planes[0].isl.base_array_layer,
> fb->layers,
> +render_area.offset.x, render_area.offset.y,
> +render_area.offset.x + render_area.extent.width,
> +render_area.offset.y + render_area.extent.height,
> +vk_to_isl_color(att_state->clear_value.color),
> NULL);
> + }
>}
>
>att_state->pending_clear_aspects = 0;
> --
> 2.11.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965/miptree: Take an aux_usage in prepare/finish_render

[Iago Toral]

Both patches are:
Reviewed-by: Iago Toral Quiroga 

On Tue, 2018-01-23 at 01:33 -0800, Jason Ekstrand wrote:
> Both callers of intel_miptree_prepare/finish_render have to call
> intel_miptree_render_aux_usage anyway for other reasons.  They may as
> well pass the result in instead of us calling it again.
> 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c |  4 ++--
>  src/mesa/drivers/dri/i965/brw_draw.c  |  4 ++--
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 ++
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  6 ++
>  4 files changed, 8 insertions(+), 16 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index 680121b..c49b634 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -1267,7 +1267,7 @@ do_single_blorp_clear(struct brw_context *brw,
> struct gl_framebuffer *fb,
>enum isl_aux_usage aux_usage =
>   intel_miptree_render_aux_usage(brw, irb->mt, isl_format,
> false);
>intel_miptree_prepare_render(brw, irb->mt, level, irb-
> >mt_layer,
> -   num_layers, isl_format, false);
> +   num_layers, aux_usage);
>  
>struct isl_surf isl_tmp[2];
>struct blorp_surf surf;
> @@ -1286,7 +1286,7 @@ do_single_blorp_clear(struct brw_context *brw,
> struct gl_framebuffer *fb,
>blorp_batch_finish();
>  
>intel_miptree_finish_render(brw, irb->mt, level, irb-
> >mt_layer,
> -  num_layers, isl_format, false);
> +  num_layers, aux_usage);
> }
>  
> return;
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index fc349ad..21b4a43 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -551,7 +551,7 @@ brw_predraw_resolve_framebuffer(struct
> brw_context *brw)
>  
>intel_miptree_prepare_render(brw, irb->mt, irb->mt_level,
> irb->mt_layer, irb->layer_count,
> -   isl_format, blend_enabled);
> +   aux_usage);
>  
>brw_cache_flush_for_render(brw, irb->mt->bo,
>   isl_format, aux_usage);
> @@ -629,7 +629,7 @@ brw_postdraw_set_buffers_need_resolve(struct
> brw_context *brw)
>  
>intel_miptree_finish_render(brw, irb->mt, irb->mt_level,
>irb->mt_layer, irb->layer_count,
> -  isl_format, blend_enabled);
> +  aux_usage);
> }
>  }
>  
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index b56a51e..a74b7b5 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -2718,11 +2718,8 @@ void
>  intel_miptree_prepare_render(struct brw_context *brw,
>   struct intel_mipmap_tree *mt, uint32_t
> level,
>   uint32_t start_layer, uint32_t
> layer_count,
> - enum isl_format render_format,
> - bool blend_enabled)
> + enum isl_aux_usage aux_usage)
>  {
> -   enum isl_aux_usage aux_usage =
> -  intel_miptree_render_aux_usage(brw, mt, render_format,
> blend_enabled);
> intel_miptree_prepare_access(brw, mt, level, 1, start_layer,
> layer_count,
>  aux_usage, aux_usage !=
> ISL_AUX_USAGE_NONE);
>  }
> @@ -2731,13 +2728,10 @@ void
>  intel_miptree_finish_render(struct brw_context *brw,
>  struct intel_mipmap_tree *mt, uint32_t
> level,
>  uint32_t start_layer, uint32_t
> layer_count,
> -enum isl_format render_format,
> -bool blend_enabled)
> +enum isl_aux_usage aux_usage)
>  {
> assert(_mesa_is_format_color_format(mt->format));
>  
> -   enum isl_aux_usage aux_usage =
> -  intel_miptree_render_aux_usage(brw, mt, render_format,
> blend_enabled);
> intel_miptree_finish_write(brw, mt, level, start_layer,
> layer_count,
>aux_usage);
>  }
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> index 5b7d7ef..355c4cc 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> @@ -656,14 +656,12 @@ void
>  intel_miptree_prepare_render(struct brw_context *brw,
>   struct intel_mipmap_tree *mt, uint32_t
> level,
>   uint32_t start_layer, uint32_t
> layer_count,
> -   

Re: [Mesa-dev] [PATCH 1/1] nir: Use a freelist in nir_opt_dce to avoid spamming ralloc

[Thomas Helland]

2018-01-21 23:58 GMT+01:00 Eric Anholt :
> Thomas Helland  writes:
>
>> Also, allocate worklist_elem in groups of 20, to reduce the burden of
>> allocation. Do not use rzalloc, as there is no need. This lets us drop
>> the number of calls to ralloc from aproximately 10% of all calls to
>> ralloc(130 000 calls), down to a mere 2000 calls to ralloc_array_size.
>> This cuts the runtime of shader-db by 1%, while at the same time
>> reducing the number of stalled cycles, executed cycles, and executed
>> instructions by about 1 % as reported by perf. I did a five-run
>> benchmark pre and post and got a statistical variance less than 0.1% pre
>> and post. This was with i965's ir validation polluting the benchmark, so
>> the numbers are even better in release builds.
>>
>> Performance change as found with perf-diff:
>> 4.74% -0.23%  libc-2.26.so[.] _int_malloc
>> 1.88% -0.21%  libc-2.26.so[.] malloc
>> 2.27% +0.16%  libmesa_dri_drivers.so  [.] match_value.part.7
>> 2.95% -0.12%  libc-2.26.so[.] _int_free
>>   +0.11%  libmesa_dri_drivers.so  [.] worklist_push
>> 1.22% -0.08%  libc-2.26.so[.] malloc_consolidate
>> 0.16% -0.06%  libmesa_dri_drivers.so  [.] mark_live_cb
>> 1.21% +0.06%  libmesa_dri_drivers.so  [.] match_expression.part.6
>> 0.75% -0.05%  libc-2.26.so[.] cfree@GLIBC_2.2.5
>> 0.50% -0.05%  libmesa_dri_drivers.so  [.] ralloc_size
>> 0.57% +0.04%  libmesa_dri_drivers.so  [.] nir_replace_instr
>> 1.29% -0.04%  libmesa_dri_drivers.so  [.] unsafe_free
>
> I'm curious, since a NIR instruction worklist seems like a generally
> useful thing to have:
>
> Could nir_worklist.c keep the implementation of this?
>
> Also, I wonder if it wouldn't be even better to have a u_dynarray of
> instructions in the worklist, with push/pop on the end of the array, and
> a struct set tracking the instructions in the array to avoid
> double-adding.  I actually don't know if that would be better or not, so
> I'd be happy with the worklist management just moved to nir_worklist.c.

I'll look into this to see what I can do. nir_worklist.c at this time has only
a block worklist. This numbers all the blocks, uses a bitset for checking
if the item is present, and uses an array with an index pointing to the
start of the queue of blocks in the buffer.

The same scheme could be easily used for ssa-defs, as these are
also numbered. I actually did this for the VRP pass I wrote years ago.

However, for instructions we do not have a way of numbering them,
so a different scheme would have to be used. A dynarray + set type
of thing, us you're suggesting, might get us where we want.
I'll see what I can come up with.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv/pipeline: lower constant initializers on output variables earlier

[Iago Toral]

This is still waiting for review, any takers?

On Wed, 2018-01-17 at 09:08 +0100, Iago Toral Quiroga wrote:
> If a shader only writes to an output via a constant initializer we
> need to lower it before we call nir_remove_dead_variables so that
> this pass sees the stores from the initializer and doesn't kill the
> output.
> 
> Fixes test failures in new work-in-progress CTS tests:
> dEQP-VK.spirv_assembly.instruction.graphics.variable_init.output_vert
> dEQP-VK.spirv_assembly.instruction.graphics.variable_init.output_frag
> ---
>  src/intel/vulkan/anv_pipeline.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_pipeline.c
> b/src/intel/vulkan/anv_pipeline.c
> index 4e66f8665f..fe0a3fc30a 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -179,6 +179,11 @@ anv_shader_compile_to_nir(struct anv_pipeline
> *pipeline,
> assert(exec_list_length(>functions) == 1);
> entry_point->name = ralloc_strdup(entry_point, "main");
>  
> +   /* Make sure we lower constant initializers on output variables
> so that
> +* nir_remove_dead_variables below sees the corresponding stores
> +*/
> +   NIR_PASS_V(nir, nir_lower_constant_initializers,
> nir_var_shader_out);
> +
> NIR_PASS_V(nir, nir_remove_dead_variables,
>nir_var_shader_in | nir_var_shader_out |
> nir_var_system_value);
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/3] anv/blorp: only clear enabled views when multiview is used

[Iago Toral]

This is still unreviewed, any chances that someone can have a look and
provide feedback? This is required to pass new tests that will be
merged in CTS soon.

Iago

On Fri, 2018-01-05 at 17:38 +0100, Iago Toral Quiroga wrote:
> ---
>  src/intel/vulkan/anv_blorp.c | 55 
> 
>  1 file changed, 40 insertions(+), 15 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_blorp.c
> b/src/intel/vulkan/anv_blorp.c
> index e244468e03..18fa4a4ae5 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1203,25 +1203,50 @@ anv_cmd_buffer_clear_subpass(struct
> anv_cmd_buffer *cmd_buffer)
>  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT |
> ANV_PIPE_CS_STALL_BIT;
>  
>   assert(image->n_planes == 1);
> - blorp_fast_clear(, , iview-
> >planes[0].isl.format,
> -  iview->planes[0].isl.base_level,
> -  iview->planes[0].isl.base_array_layer, fb-
> >layers,
> -  render_area.offset.x,
> render_area.offset.y,
> -  render_area.offset.x +
> render_area.extent.width,
> -  render_area.offset.y +
> render_area.extent.height);
> -
> + if (cmd_state->subpass->view_mask) {
> +uint32_t view_idx;
> +for_each_bit(view_idx, cmd_state->subpass->view_mask) {
> +   blorp_fast_clear(, , iview-
> >planes[0].isl.format,
> +iview->planes[0].isl.base_level,
> +view_idx, 1,
> +render_area.offset.x,
> render_area.offset.y,
> +render_area.offset.x +
> render_area.extent.width,
> +render_area.offset.y +
> render_area.extent.height);
> +}
> + } else {
> +blorp_fast_clear(, , iview-
> >planes[0].isl.format,
> + iview->planes[0].isl.base_level,
> + iview->planes[0].isl.base_array_layer,
> fb->layers,
> + render_area.offset.x,
> render_area.offset.y,
> + render_area.offset.x +
> render_area.extent.width,
> + render_area.offset.y +
> render_area.extent.height);
> + }
>   cmd_buffer->state.pending_pipe_bits |=
>  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT |
> ANV_PIPE_CS_STALL_BIT;
>} else {
>   assert(image->n_planes == 1);
> - blorp_clear(, , iview->planes[0].isl.format,
> - anv_swizzle_for_render(iview-
> >planes[0].isl.swizzle),
> - iview->planes[0].isl.base_level,
> - iview->planes[0].isl.base_array_layer, fb-
> >layers,
> - render_area.offset.x, render_area.offset.y,
> - render_area.offset.x +
> render_area.extent.width,
> - render_area.offset.y +
> render_area.extent.height,
> - vk_to_isl_color(att_state->clear_value.color),
> NULL);
> + if (cmd_state->subpass->view_mask) {
> +uint32_t view_idx;
> +for_each_bit(view_idx, cmd_state->subpass->view_mask) {
> +   blorp_clear(, , iview-
> >planes[0].isl.format,
> +   anv_swizzle_for_render(iview-
> >planes[0].isl.swizzle),
> +   iview->planes[0].isl.base_level,
> +   view_idx, 1,
> +   render_area.offset.x,
> render_area.offset.y,
> +   render_area.offset.x +
> render_area.extent.width,
> +   render_area.offset.y +
> render_area.extent.height,
> +   vk_to_isl_color(att_state-
> >clear_value.color), NULL);
> +}
> + } else {
> +blorp_clear(, , iview->planes[0].isl.format,
> +anv_swizzle_for_render(iview-
> >planes[0].isl.swizzle),
> +iview->planes[0].isl.base_level,
> +iview->planes[0].isl.base_array_layer, fb-
> >layers,
> +render_area.offset.x, render_area.offset.y,
> +render_area.offset.x +
> render_area.extent.width,
> +render_area.offset.y +
> render_area.extent.height,
> +vk_to_isl_color(att_state-
> >clear_value.color), NULL);
> + }
>}
>  
>att_state->pending_clear_aspects = 0;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] Revert "anv/meson: Make anv_entrypoints_gen.py depend on anv_extensions.py"

[Samuel Iglesias Gonsálvez]

I am not a meson expert but changes look fine. The series is:

Reviewed-by: Samuel Iglesias Gonsálvez 

Sam

On 23/01/18 18:44, Dylan Baker wrote:
> This reverts commit 10d1b0be8e9c463dbc35cd66968299f33c76672c.
>
> This is unnecessary, the depend_files argument is for adding
> dependencies on files that are not part of the input, which is already
> done.
>
> cc: Jason Ekstrand 
> cc: Samuel Iglesias Gonsálvez 
> Fixes: 10d1b0be8e9c463dbc35cd66968299f33c76672c
> Signed-off-by: Dylan Baker 
> ---
>  src/intel/vulkan/meson.build | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
> index 69ec26e19b6..d0712f318c7 100644
> --- a/src/intel/vulkan/meson.build
> +++ b/src/intel/vulkan/meson.build
> @@ -20,8 +20,7 @@
>  
>  anv_entrypoints = custom_target(
>'anv_entrypoints.[ch]',
> -  input : ['anv_entrypoints_gen.py', vk_api_xml, 
> vk_android_native_buffer_xml,
> -   'anv_extensions.py'],
> +  input : ['anv_entrypoints_gen.py', vk_api_xml, 
> vk_android_native_buffer_xml],
>output : ['anv_entrypoints.h', 'anv_entrypoints.c'],
>command : [
>  prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@',



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] anv: correct a duplicate check in an assert

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 23.01.2018 00:57, Grazvydas Ignotas wrote:

Looks like checking both sources was intended, instead of the first one
twice. Found with Coccinelle, coccinellery/xand/xand.cocci semantic patch.

Signed-off-by: Grazvydas Ignotas 
---
  src/intel/vulkan/anv_nir_apply_pipeline_layout.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_nir_apply_pipeline_layout.c 
b/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
index 978a8a5..6775f9b 100644
--- a/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
+++ b/src/intel/vulkan/anv_nir_apply_pipeline_layout.c
@@ -145,11 +145,11 @@ lower_res_reindex_intrinsic(nir_intrinsic_instr *intrin,
  
 /* For us, the resource indices are just indices into the binding table and

  * array elements are sequential.  A resource_reindex just turns into an
  * add of the two indices.
  */
-   assert(intrin->src[0].is_ssa && intrin->src[0].is_ssa);
+   assert(intrin->src[0].is_ssa && intrin->src[1].is_ssa);
 nir_ssa_def *new_index = nir_iadd(b, intrin->src[0].ssa,
  intrin->src[1].ssa);
  
 assert(intrin->dest.is_ssa);

 nir_ssa_def_rewrite_uses(>dest.ssa, nir_src_for_ssa(new_index));


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

Re: [Mesa-dev] [PATCH] i965: Mark the workaround BO with EXEC_OBJECT_WRITE in BLORP.

[Kenneth Graunke]

On Tuesday, January 23, 2018 1:32:53 AM PST Chris Wilson wrote:
> Quoting Kenneth Graunke (2018-01-23 09:28:20)
> > The purpose of the workaround BO is to write to it.
> 
> Do you care for the serialisation here? I thought the purpose of the wa
> was just for write-only memory, so lying to the kernel to disable write
> hazards is acceptable.
> -Chris

We don't usually read it, so it should be fine, but I don't like lying
about things...it was more an oversight than an intentional way to avoid
synchronization.  What synchronization would there be, anyway, assuming
we don't ever read it or map it?

I thought we still read it for register checks, though it appears that
we now allocate a dedicated BO for that purpose.  Plus, screen creation
time is long done by the time we have a context and start using BLORP...

So basically, I don't like lying.  Is there really an advantage to it?


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

[Mesa-dev] [PATCH] radv: enable two other DB_EQAA bits.

[Dave Airlie]

From: Dave Airlie 

amdvlk appears to enable these bits always, no explaination of why.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_pipeline.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 62faa3e..ab1a517 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -837,7 +837,10 @@ radv_pipeline_init_multisample_state(struct radv_pipeline 
*pipeline,
ms->pa_sc_line_cntl = S_028BDC_DX10_DIAMOND_TEST_ENA(1);
ms->pa_sc_aa_config = 0;
ms->db_eqaa = S_028804_HIGH_QUALITY_INTERSECTIONS(1) |
-   S_028804_STATIC_ANCHOR_ASSOCIATIONS(1);
+   S_028804_STATIC_ANCHOR_ASSOCIATIONS(1) |
+   S_028804_INCOHERENT_EQAA_READS(1) |
+   S_028804_INTERPOLATE_COMP_Z(1);
+
ms->pa_sc_mode_cntl_1 =
S_028A4C_WALK_FENCE_ENABLE(1) | //TODO linear dst fixes
S_028A4C_WALK_FENCE_SIZE(num_tile_pipes == 2 ? 2 : 3) |
-- 
2.9.5

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

[Mesa-dev] [PATCH] radv: don't enable tc compat for d32s8 + 4/8 samples

[Dave Airlie]

From: Dave Airlie 

This seems to be broken, at least the cts tests fail.

This fixes:
dEQP-VK.renderpass.suballocation.multisample.d32_sfloat_s8_uint.samples_4
dEQP-VK.renderpass.suballocation.multisample.d32_sfloat_s8_uint.samples_8

2 samples seems to pass fine, amdvlk doesn't appear to enable TC for
possibly some other reasons here.

This is most likely a hack.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_image.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 54b2b52..66249e5 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -116,7 +116,7 @@ radv_init_surface(struct radv_device *device,
pCreateInfo->mipLevels <= 1 &&
device->physical_device->rad_info.chip_class >= VI &&
((pCreateInfo->format == VK_FORMAT_D32_SFLOAT ||
- pCreateInfo->format == VK_FORMAT_D32_SFLOAT_S8_UINT) ||
+ (pCreateInfo->samples < 4 && pCreateInfo->format == 
VK_FORMAT_D32_SFLOAT_S8_UINT)) ||
 (device->physical_device->rad_info.chip_class >= GFX9 &&
  pCreateInfo->format == VK_FORMAT_D16_UNORM)))
surface->flags |= RADEON_SURF_TC_COMPATIBLE_HTILE;
-- 
2.9.5

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

Re: [Mesa-dev] [PATCH 1/3] st/glsl_to_tgsi: move nir detection earlier and set nir options

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

on RX580
with UH (even wireframe mode works, now - GREAT!), UV, US, glmark2, 
Blender 2.79, DiRT Rally, F1 2017 and smoketest --- all I throw at it.


Together with:
[Mesa-dev] [PATCH] ac/nir: call glsl_get_sampler_dim() only once, where 
possible (v2)


Only hang/crash with kdm (kwin_x11).

[15868.010794] si_shader:1[11314]: segfault at 56380736ff00 ip 
fc02a9d7 sp c2a39e16 error 4 in 
libc-2.26.so[7f2bc0888000+1b1000]
[15886.284911] si_shader:1[11363]: segfault at 55eb639f6840 ip 
2a5bdb2f sp 84185b19 error 4 in 
libc-2.26.so[7ff1ea2fc000+1b1000]
[15893.520909] si_shader:0[11386]: segfault at 55aac936c5b8 ip 
2387ffc1 sp 1b4ed48c error 4 in 
libc-2.26.so[7fe738b1a000+1b1000]
[16010.416710] plasmashell[13310]: segfault at 5630544ddfe0 ip 
4cd489a5 sp ab5ed265 error 4 in 
libc-2.26.so[7f7104df2000+1b1000]


I tried it with R600_DEBUG=sisched,nir in /etc/environment...
that was too much at this point ;-)

Dieter

Am 24.01.2018 01:4[Mesa-dev] [PATCH 1/3] st/glsl_to_tgsi: move nir 
detection earlier and set nir options1, schrieb Timothy Arceri:

We move the nir check before the shader cache call so that we can
call a nir based caching function in a following patch.
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp  | 10 ++---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 36 
+++---

 2 files changed, 30 insertions(+), 16 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 21b3640b2c..9e627be6da 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -304,14 +304,8 @@ st_glsl_to_nir(struct st_context *st, struct
gl_program *prog,
struct gl_shader_program *shader_program,
gl_shader_stage stage)
 {
-   struct pipe_screen *pscreen = st->pipe->screen;
-   enum pipe_shader_type ptarget = pipe_shader_type_from_mesa(stage);
-   const nir_shader_compiler_options *options;
-
-   assert(pscreen->get_compiler_options);   /* drivers using NIR must
implement this */
-
-   options = (const nir_shader_compiler_options *)
-  pscreen->get_compiler_options(pscreen, PIPE_SHADER_IR_NIR, 
ptarget);

+   const nir_shader_compiler_options *options =
+  
st->ctx->Const.ShaderCompilerOptions[prog->info.stage].NirOptions;

assert(options);

if (prog->nir)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index f44f02ad9d..f496bcfe59 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -6917,15 +6917,41 @@ extern "C" {
 GLboolean
 st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog)
 {
+   struct pipe_screen *pscreen = ctx->st->pipe->screen;
+
+   bool use_nir = false;
+   for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
+  if (prog->_LinkedShaders[i] == NULL)
+ continue;
+
+  gl_shader_stage stage = prog->_LinkedShaders[i]->Stage;
+  enum pipe_shader_type ptarget = 
pipe_shader_type_from_mesa(stage);

+  enum pipe_shader_ir preferred_ir = (enum pipe_shader_ir)
+ pscreen->get_shader_param(pscreen, ptarget,
+   PIPE_SHADER_CAP_PREFERRED_IR);
+  use_nir = preferred_ir == PIPE_SHADER_IR_NIR;
+
+  if (use_nir) {
+ const nir_shader_compiler_options *options;
+
+ /* drivers using NIR must implement this */
+ assert(pscreen->get_compiler_options);
+
+ options = (const nir_shader_compiler_options *)
+pscreen->get_compiler_options(pscreen,
PIPE_SHADER_IR_NIR, ptarget);
+ assert(options);
+
+ ctx->Const.ShaderCompilerOptions[stage].NirOptions = options;
+  }
+   }
+
/* Return early if we are loading the shader from on-disk cache */
if (st_load_tgsi_from_disk_cache(ctx, prog)) {
   return GL_TRUE;
}

-   struct pipe_screen *pscreen = ctx->st->pipe->screen;
assert(prog->data->LinkStatus);

-   bool use_nir = false;
for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
   if (prog->_LinkedShaders[i] == NULL)
  continue;
@@ -6945,12 +6971,6 @@ st_link_shader(struct gl_context *ctx, struct
gl_shader_program *prog)
   unsigned if_threshold = pscreen->get_shader_param(pscreen, 
ptarget,


PIPE_SHADER_CAP_LOWER_IF_THRESHOLD);

-  enum pipe_shader_ir preferred_ir = (enum pipe_shader_ir)
- pscreen->get_shader_param(pscreen, ptarget,
-   PIPE_SHADER_CAP_PREFERRED_IR);
-  if (preferred_ir == PIPE_SHADER_IR_NIR)
- use_nir = true;
-
   /* If there are forms of indirect addressing that the driver
* cannot handle, perform the lowering pass.
*/

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

[Mesa-dev] [Bug 101814] es2gears_wayland only achieves 40 FPS (in Weston and Gnome Shell)

[bugzilla-daemon]

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

--- Comment #4 from Daniel van Vugt  ---
Thanks. It looks like mesa-demos hasn't had a release for 2 years...

https://cgit.freedesktop.org/mesa/demos/

So this fix still isn't released either. Any idea of when a release might
happen?

-- 
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] vbo: fix incorrect min/max_index values in display list draw call

[Brian Paul]

On 01/23/2018 05:59 PM, Clayton Craft wrote:

On Tue, Jan 23, 2018 at 11:44:01AM -0700, Brian Paul wrote:

This fixes another regression from commit 8e4efdc895ea ("vbo: optimize
some display list drawing").  The problem was the min_index, max_index
values passed to the vbo drawing function were not computed to compensate
for the biased prim::start values.

I have confirmed that this resolves the regression on G33.


Great!

Please add a 'Fixes' tag so that this is applied to the new stable 
branch, plus

a 'Tested-by: clayton.a.cr...@intel.com' tag.


Will do.

A review by someone would be good, but I won't wait too long.

-Brian





https://bugs.freedesktop.org/show_bug.cgi?id=104746
https://bugs.freedesktop.org/show_bug.cgi?id=104742
https://bugs.freedesktop.org/show_bug.cgi?id=104690
---
src/mesa/vbo/vbo_save.h  | 3 ++-
src/mesa/vbo/vbo_save_api.c  | 3 +++
src/mesa/vbo/vbo_save_draw.c | 5 +++--
3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 04b9e38..51ea9cc 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -74,7 +74,8 @@ struct vbo_save_vertex_list {
   GLuint current_size;

   GLuint buffer_offset;    /**< in bytes */
-   GLuint vertex_count;
+   GLuint start_vertex; /**< first vertex used by any 
primitive */

+   GLuint vertex_count; /**< number of vertices in this list */
   GLuint wrap_count;    /* number of copied vertices at start */
   GLboolean dangling_attr_ref;    /* current attr implicitly referenced
   outside the list */
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index e0fe5fd..11c40a2 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -563,6 +563,9 @@ compile_vertex_list(struct gl_context *ctx)
  for (unsigned i = 0; i < save->prim_count; i++) {
 save->prims[i].start += start_offset;
  }
+  node->start_vertex = start_offset;
+   } else {
+  node->start_vertex = 0;
   }

   /* Reset our structures for the next run of vertices:
diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 97e0fa0..221aa57 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -349,13 +349,14 @@ vbo_save_playback_vertex_list(struct gl_context 
*ctx, void *data)

 _mesa_update_state(ctx);

  if (node->vertex_count > 0) {
+ GLuint min_index = node->start_vertex;
+ GLuint max_index = min_index + node->vertex_count - 1;
 vbo_context(ctx)->draw_prims(ctx,
  node->prims,
  node->prim_count,
  NULL,
  GL_TRUE,
-  0,    /* Node is a VBO, so this 
is ok */

-  node->vertex_count - 1,
+  min_index, max_index,
  NULL, 0, NULL);
  }
   }
--
2.7.4

___
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] radv: add multisample Z optimisation from amdvlk

[Dave Airlie]

From: Dave Airlie 

This was just found while reading for other stuff,
rc/core/hw/gfxip/gfx6/gfx6DepthStencilView.cpp.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_pipeline.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 41a206a..62faa3e 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -714,6 +714,9 @@ radv_pipeline_init_depth_stencil_state(struct radv_pipeline 
*pipeline,
   
S_028800_Z_WRITE_ENABLE(vkds->depthWriteEnable ? 1 : 0) |
   S_028800_ZFUNC(vkds->depthCompareOp) |
   
S_028800_DEPTH_BOUNDS_ENABLE(vkds->depthBoundsTestEnable ? 1 : 0);
+
+   /* from amdvlk: For 4xAA and 8xAA need to decompress on flush 
for better performance */
+   ds->db_render_override2 |= 
S_028010_DECOMPRESS_Z_ON_FLUSH(attachment->samples > 2);
}
 
if (has_stencil_attachment && vkds->stencilTestEnable) {
-- 
2.9.5

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

Re: [Mesa-dev] [PATCH] ac/nir: call glsl_get_sampler_dim() only once, where possible (v2)

[Dieter Nützel]

Tested-by: Dieter Nützel 

on RX580
with UH, UV, US, glmark2, Blender 2.79, DiRT Rally, F1 2017 and 
smoketest


Together with:
Mesa-dev] [PATCH 1/3] st/glsl_to_tgsi: move nir detection earlier and 
set nir options


Am 23.01.2018 21:14, schrieb Kai Wasserbäch:

Changes since v1:
  * Rebased on top of e68150de263156a3f3d1b609b6506c5649967f61 and
82adf53308c137ce0dc5f2d5da4e7cc40c5b808c.

Cc: Timothy Arceri 
Tested-by: Dieter Nützel  (v1)
Signed-off-by: Kai Wasserbäch 
---

Hey,
if you accept this patch, please commit it for me – I do not have 
commit

access. This is v2, which is needed since the above mentioned changes
by Timothy went in first.

Thanks,
Kai

 src/amd/common/ac_nir_to_llvm.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c 
b/src/amd/common/ac_nir_to_llvm.c

index cc3af77386..0fba5a1068 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3620,7 +3620,9 @@ static LLVMValueRef visit_image_load(struct
ac_nir_context *ctx,
type = instr->variables[0]->deref.child->type;

type = glsl_without_array(type);
-   if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
+
+   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
+   if (dim == GLSL_SAMPLER_DIM_BUF) {
params[0] = get_sampler_desc(ctx, instr->variables[0],
AC_DESC_BUFFER, NULL, true, false);
params[1] = LLVMBuildExtractElement(ctx->ac.builder, 
get_src(ctx,
instr->src[0]),
ctx->ac.i32_0, ""); /* 
vindex */
@@ -3634,10 +3636,10 @@ static LLVMValueRef visit_image_load(struct
ac_nir_context *ctx,
res = ac_to_integer(>ac, res);
} else {
bool is_da = glsl_sampler_type_is_array(type) ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE ||
-glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D 
||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS_MS;
+dim == GLSL_SAMPLER_DIM_CUBE ||
+dim == GLSL_SAMPLER_DIM_3D ||
+dim == GLSL_SAMPLER_DIM_SUBPASS ||
+dim == GLSL_SAMPLER_DIM_SUBPASS_MS;
LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
LLVMValueRef glc = ctx->ac.i1false;
LLVMValueRef slc = ctx->ac.i1false;
@@ -3677,12 +3679,13 @@ static void visit_image_store(struct
ac_nir_context *ctx,
char intrinsic_name[64];
const nir_variable *var = instr->variables[0]->var;
const struct glsl_type *type = glsl_without_array(var->type);
+   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
LLVMValueRef glc = ctx->ac.i1false;
bool force_glc = ctx->ac.chip_class == SI;
if (force_glc)
glc = ctx->ac.i1true;

-   if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
+   if (dim == GLSL_SAMPLER_DIM_BUF) {
 		params[0] = ac_to_float(>ac, get_src(ctx, instr->src[2])); /* 
data */

params[1] = get_sampler_desc(ctx, instr->variables[0],
AC_DESC_BUFFER, NULL, true, true);
params[2] = LLVMBuildExtractElement(ctx->ac.builder, 
get_src(ctx,
instr->src[0]),
@@ -3694,8 +3697,8 @@ static void visit_image_store(struct 
ac_nir_context *ctx,

   params, 6, 0);
} else {
bool is_da = glsl_sampler_type_is_array(type) ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE ||
-glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D;
+dim == GLSL_SAMPLER_DIM_CUBE ||
+dim == GLSL_SAMPLER_DIM_3D;
LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
LLVMValueRef slc = ctx->ac.i1false;

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

[Mesa-dev] [PATCH] radv: move spi_baryc_cntl to pipeline

[Dave Airlie]

From: Dave Airlie 

We need to enable the pos float location 2 mode anytime we have
persample not just when forced by the frag shader.

This fixes:
dEQP-VK.pipeline.multisample.min_sample_shading*

Fixes: 58c97a079 (radv: enable location at sample when persample is forced.)
Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_cmd_buffer.c | 6 +-
 src/amd/vulkan/radv_pipeline.c   | 3 +++
 src/amd/vulkan/radv_private.h| 1 +
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 1143aa0..6d512c6 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -990,7 +990,6 @@ radv_emit_fragment_shader(struct radv_cmd_buffer 
*cmd_buffer,
 {
struct radv_shader_variant *ps;
uint64_t va;
-   unsigned spi_baryc_cntl = S_0286E0_FRONT_FACE_ALL_BITS(1);
struct radv_blend_state *blend = >graphics.blend;
assert (pipeline->shaders[MESA_SHADER_FRAGMENT]);
 
@@ -1012,13 +1011,10 @@ radv_emit_fragment_shader(struct radv_cmd_buffer 
*cmd_buffer,
radeon_set_context_reg(cmd_buffer->cs, R_0286D0_SPI_PS_INPUT_ADDR,
   ps->config.spi_ps_input_addr);
 
-   if (ps->info.info.ps.force_persample)
-   spi_baryc_cntl |= S_0286E0_POS_FLOAT_LOCATION(2);
-
radeon_set_context_reg(cmd_buffer->cs, R_0286D8_SPI_PS_IN_CONTROL,
   S_0286D8_NUM_INTERP(ps->info.fs.num_interp));
 
-   radeon_set_context_reg(cmd_buffer->cs, R_0286E0_SPI_BARYC_CNTL, 
spi_baryc_cntl);
+   radeon_set_context_reg(cmd_buffer->cs, R_0286E0_SPI_BARYC_CNTL, 
pipeline->graphics.spi_baryc_cntl);
 
radeon_set_context_reg(cmd_buffer->cs, R_028710_SPI_SHADER_Z_FORMAT,
   pipeline->graphics.shader_z_format);
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 21333b8..41a206a 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -861,6 +861,8 @@ radv_pipeline_init_multisample_state(struct radv_pipeline 
*pipeline,

S_028BE0_MAX_SAMPLE_DIST(radv_cayman_get_maxdist(log_samples)) |
S_028BE0_MSAA_EXPOSED_SAMPLES(log_samples); /* 
CM_R_028BE0_PA_SC_AA_CONFIG */
ms->pa_sc_mode_cntl_1 |= 
S_028A4C_PS_ITER_SAMPLE(ps_iter_samples > 1);
+   if (ps_iter_samples > 1)
+   pipeline->graphics.spi_baryc_cntl |= 
S_0286E0_POS_FLOAT_LOCATION(2);
}
 
const struct VkPipelineRasterizationStateRasterizationOrderAMD 
*raster_order =
@@ -2449,6 +2451,7 @@ radv_pipeline_init(struct radv_pipeline *pipeline,
radv_generate_graphics_pipeline_key(pipeline, 
pCreateInfo, has_view_index),
pStages);
 
+   pipeline->graphics.spi_baryc_cntl = S_0286E0_FRONT_FACE_ALL_BITS(1);
radv_pipeline_init_depth_stencil_state(pipeline, pCreateInfo, extra);
radv_pipeline_init_raster_state(pipeline, pCreateInfo);
radv_pipeline_init_multisample_state(pipeline, pCreateInfo);
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 711ae71..f650b9a 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1239,6 +1239,7 @@ struct radv_pipeline {
struct radv_binning_state bin;
uint32_t db_shader_control;
uint32_t shader_z_format;
+   uint32_t spi_baryc_cntl;
unsigned prim;
unsigned gs_out;
uint32_t vgt_gs_mode;
-- 
2.9.5

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

Re: [Mesa-dev] Add interpolateAt builtin support to the radeonsi nir backend

[Timothy Arceri]

On 24/01/18 11:44, Dieter Nützel wrote:

Rebase underway? ;-)


Please direct these type of questions to IRC, rather than creating extra 
traffic and threads on the mailing list.




Am 15.01.2018 04:46, schrieb Timothy Arceri:

This series is intended to be applied on top of the previous serires
that ebales glsl 450 starting with:

[PATCH 1/5] ac/radeonsi: add tcs load outputs support

___
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] vbo: fix incorrect min/max_index values in display list draw call

[Clayton Craft]

On Tue, Jan 23, 2018 at 11:44:01AM -0700, Brian Paul wrote:

This fixes another regression from commit 8e4efdc895ea ("vbo: optimize
some display list drawing").  The problem was the min_index, max_index
values passed to the vbo drawing function were not computed to compensate
for the biased prim::start values.

I have confirmed that this resolves the regression on G33.
Please add a 'Fixes' tag so that this is applied to the new stable branch, plus
a 'Tested-by: clayton.a.cr...@intel.com' tag.



https://bugs.freedesktop.org/show_bug.cgi?id=104746
https://bugs.freedesktop.org/show_bug.cgi?id=104742
https://bugs.freedesktop.org/show_bug.cgi?id=104690
---
src/mesa/vbo/vbo_save.h  | 3 ++-
src/mesa/vbo/vbo_save_api.c  | 3 +++
src/mesa/vbo/vbo_save_draw.c | 5 +++--
3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 04b9e38..51ea9cc 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -74,7 +74,8 @@ struct vbo_save_vertex_list {
   GLuint current_size;

   GLuint buffer_offset;/**< in bytes */
-   GLuint vertex_count;
+   GLuint start_vertex; /**< first vertex used by any primitive */
+   GLuint vertex_count; /**< number of vertices in this list */
   GLuint wrap_count;   /* number of copied vertices at start */
   GLboolean dangling_attr_ref; /* current attr implicitly referenced
   outside the list */
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index e0fe5fd..11c40a2 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -563,6 +563,9 @@ compile_vertex_list(struct gl_context *ctx)
  for (unsigned i = 0; i < save->prim_count; i++) {
 save->prims[i].start += start_offset;
  }
+  node->start_vertex = start_offset;
+   } else {
+  node->start_vertex = 0;
   }

   /* Reset our structures for the next run of vertices:
diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 97e0fa0..221aa57 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -349,13 +349,14 @@ vbo_save_playback_vertex_list(struct gl_context *ctx, 
void *data)
 _mesa_update_state(ctx);

  if (node->vertex_count > 0) {
+ GLuint min_index = node->start_vertex;
+ GLuint max_index = min_index + node->vertex_count - 1;
 vbo_context(ctx)->draw_prims(ctx,
  node->prims,
  node->prim_count,
  NULL,
  GL_TRUE,
-  0,/* Node is a VBO, so this is ok */
-  node->vertex_count - 1,
+  min_index, max_index,
  NULL, 0, NULL);
  }
   }
--
2.7.4

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


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

Re: [Mesa-dev] [PATCH] radv: don't use hw resolve for certain image formats. (v2)

[Dieter Nützel]

Hello Dave,

is this one obsolete or should it go before the 2 committed but without 
the first line (duplicate)?


Dieter

Am 23.01.2018 06:29, schrieb Dave Airlie:

From: Dave Airlie 

From reading AMDVLK it currently never uses hw resolve paths.

This patch limits the paths we used the hw resolve for,
and fixes a larger number of the:
dEQP-VK.renderpass.suballocation.multisample* tests.

radeonsi actually has the no-int and no-depth rules
already so port those.

I've also added a >= 16 color format component bit size,
to avoid what radeonsi says is buggy behaviour. I wonder
if we should be doing meta format key for resolves.

This still leaves depth resolves and 16-bit formats at 8-bit
samples failing.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_meta_resolve.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index 49326fe..4c74027 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -26,6 +26,7 @@

 #include "radv_meta.h"
 #include "radv_private.h"
+#include "vk_format.h"
 #include "nir/nir_builder.h"
 #include "sid.h"

@@ -323,6 +324,12 @@ static void
radv_pick_resolve_method_images(struct radv_image *src_image,
uint32_t queue_mask = radv_image_queue_family_mask(dest_image,

cmd_buffer->queue_family_index,

cmd_buffer->queue_family_index);
+
+   if (vk_format_is_int(src_image->vk_format) ||
+   vk_format_is_depth_or_stencil(src_image->vk_format) ||
+   vk_format_get_component_bits(src_image->vk_format,
VK_FORMAT_COLORSPACE_RGB, 0) >= 16)
+   *method = RESOLVE_COMPUTE;
+
 	if (radv_layout_dcc_compressed(dest_image, dest_image_layout, 
queue_mask)) {

*method = RESOLVE_FRAGMENT;
} else if (dest_image->surface.micro_tile_mode !=
src_image->surface.micro_tile_mode) {

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

Re: [Mesa-dev] [PATCH 2/3] st: add nir shader disk cache support

[Timothy Arceri]

I should note that compute support is missing (asserts) as I was unable 
to test it with radeonsi currently.


On 24/01/18 11:41, Timothy Arceri wrote:

---
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |   2 +-
  src/mesa/state_tracker/st_program.c|   6 +-
  src/mesa/state_tracker/st_shader_cache.c   | 133 +++--
  src/mesa/state_tracker/st_shader_cache.h   |   8 +-
  4 files changed, 115 insertions(+), 34 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index f496bcfe59..e42405f2fa 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -6946,7 +6946,7 @@ st_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
 }
  
 /* Return early if we are loading the shader from on-disk cache */

-   if (st_load_tgsi_from_disk_cache(ctx, prog)) {
+   if (st_load_ir_from_disk_cache(ctx, prog, use_nir)) {
return GL_TRUE;
 }
  
diff --git a/src/mesa/state_tracker/st_program.c b/src/mesa/state_tracker/st_program.c

index 1116b5afbc..de9c5d1654 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -539,7 +539,7 @@ st_translate_vertex_program(struct st_context *st,
  
 if (stvp->glsl_to_tgsi) {

stvp->glsl_to_tgsi = NULL;
-  st_store_tgsi_in_disk_cache(st, >Base);
+  st_store_ir_in_disk_cache(st, >Base, false);
 }
  
 return stvp->tgsi.tokens != NULL;

@@ -996,7 +996,7 @@ st_translate_fragment_program(struct st_context *st,
  
 if (stfp->glsl_to_tgsi) {

stfp->glsl_to_tgsi = NULL;
-  st_store_tgsi_in_disk_cache(st, >Base);
+  st_store_ir_in_disk_cache(st, >Base, false);
 }
  
 return stfp->tgsi.tokens != NULL;

@@ -1412,7 +1412,7 @@ st_translate_program_common(struct st_context *st,
 outputMapping,
 _state->stream_output);
  
-   st_store_tgsi_in_disk_cache(st, prog);

+   st_store_ir_in_disk_cache(st, prog, false);
  
 if ((ST_DEBUG & DEBUG_TGSI) && (ST_DEBUG & DEBUG_MESA)) {

_mesa_print_program(prog);
diff --git a/src/mesa/state_tracker/st_shader_cache.c 
b/src/mesa/state_tracker/st_shader_cache.c
index a971b0d7ee..0f79a410a1 100644
--- a/src/mesa/state_tracker/st_shader_cache.c
+++ b/src/mesa/state_tracker/st_shader_cache.c
@@ -26,6 +26,8 @@
  #include "st_program.h"
  #include "st_shader_cache.h"
  #include "compiler/glsl/program.h"
+#include "compiler/nir/nir.h"
+#include "compiler/nir/nir_serialize.h"
  #include "pipe/p_shader_tokens.h"
  #include "program/ir_to_mesa.h"
  #include "util/u_memory.h"
@@ -44,20 +46,33 @@ write_stream_out_to_cache(struct blob *blob,
  sizeof(tgsi->stream_output));
  }
  
+static void

+copy_blob_to_driver_cache_blob(struct blob *blob, struct gl_program *prog)
+{
+   prog->driver_cache_blob = ralloc_size(NULL, blob->size);
+   memcpy(prog->driver_cache_blob, blob->data, blob->size);
+   prog->driver_cache_blob_size = blob->size;
+}
+
  static void
  write_tgsi_to_cache(struct blob *blob, const struct tgsi_token *tokens,
  struct gl_program *prog, unsigned num_tokens)
  {
 blob_write_uint32(blob, num_tokens);
 blob_write_bytes(blob, tokens, num_tokens * sizeof(struct tgsi_token));
+   copy_blob_to_driver_cache_blob(blob, prog);
+}
  
-   prog->driver_cache_blob = ralloc_size(NULL, blob->size);

-   memcpy(prog->driver_cache_blob, blob->data, blob->size);
-   prog->driver_cache_blob_size = blob->size;
+static void
+write_nir_to_cache(struct blob *blob, struct gl_program *prog)
+{
+   nir_serialize(blob, prog->nir);
+   copy_blob_to_driver_cache_blob(blob, prog);
  }
  
-void

-st_serialise_tgsi_program(struct gl_context *ctx, struct gl_program *prog)
+static void
+st_serialise_ir_program(struct gl_context *ctx, struct gl_program *prog,
+bool nir)
  {
 struct blob blob;
 blob_init();
@@ -73,8 +88,12 @@ st_serialise_tgsi_program(struct gl_context *ctx, struct 
gl_program *prog)
 sizeof(stvp->result_to_output));
  
write_stream_out_to_cache(, >tgsi);

-  write_tgsi_to_cache(, stvp->tgsi.tokens, prog,
-  stvp->num_tgsi_tokens);
+
+  if (nir)
+ write_nir_to_cache(, prog);
+  else
+ write_tgsi_to_cache(, stvp->tgsi.tokens, prog,
+ stvp->num_tgsi_tokens);
break;
 }
 case MESA_SHADER_TESS_CTRL:
@@ -83,20 +102,29 @@ st_serialise_tgsi_program(struct gl_context *ctx, struct 
gl_program *prog)
struct st_common_program *stcp = (struct st_common_program *) prog;
  
write_stream_out_to_cache(, >tgsi);

-  write_tgsi_to_cache(, stcp->tgsi.tokens, prog,
-  stcp->num_tgsi_tokens);
+
+  if (nir)
+ write_nir_to_cache(, prog);
+  else
+ write_tgsi_to_cache(, stcp->tgsi.tokens, 

Re: [Mesa-dev] Add interpolateAt builtin support to the radeonsi nir backend

[Dieter Nützel]

Rebase underway? ;-)

Am 15.01.2018 04:46, schrieb Timothy Arceri:

This series is intended to be applied on top of the previous serires
that ebales glsl 450 starting with:

[PATCH 1/5] ac/radeonsi: add tcs load outputs support

___
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 3/3] st/radeonsi: enable disk cache for nir

[Timothy Arceri]

---
 src/gallium/drivers/radeonsi/si_pipe.c |  4 
 src/mesa/state_tracker/st_program.c| 15 +++
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 676d199618..c096165b03 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -621,10 +621,6 @@ static void si_disk_cache_create(struct si_screen *sscreen)
if (sscreen->debug_flags & DBG_ALL_SHADERS)
return;
 
-   /* TODO: remove this once gallium supports a nir cache */
-   if (sscreen->debug_flags & DBG(NIR))
-   return;
-
uint32_t mesa_timestamp;
if (disk_cache_get_function_timestamp(si_disk_cache_create,
  _timestamp)) {
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index de9c5d1654..b3926eaa02 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -466,6 +466,7 @@ st_translate_vertex_program(struct st_context *st,
   >tgsi.stream_output);
   }
 
+  st_store_ir_in_disk_cache(st, >Base, true);
   return true;
}
 
@@ -900,9 +901,11 @@ st_translate_fragment_program(struct st_context *st,
   }
}
 
-   /* We have already compiler to NIR so just return */
-   if (stfp->shader_program)
+   /* We have already compiled to NIR so just return */
+   if (stfp->shader_program) {
+  st_store_ir_in_disk_cache(st, >Base, true);
   return true;
+   }
 
ureg = ureg_create_with_screen(PIPE_SHADER_FRAGMENT, st->pipe->screen);
if (ureg == NULL)
@@ -1472,6 +1475,7 @@ st_translate_geometry_program(struct st_context *st,
/* We have already compiled to NIR so just return */
if (stgp->shader_program) {
   st_translate_program_stream_output(>Base, 
>tgsi.stream_output);
+  st_store_ir_in_disk_cache(st, >Base, true);
   return true;
}
 
@@ -1571,8 +1575,10 @@ st_translate_tessctrl_program(struct st_context *st,
struct ureg_program *ureg;
 
/* We have already compiled to NIR so just return */
-   if (sttcp->shader_program)
+   if (sttcp->shader_program) {
+  st_store_ir_in_disk_cache(st, >Base, true);
   return true;
+   }
 
ureg = ureg_create_with_screen(PIPE_SHADER_TESS_CTRL, st->pipe->screen);
if (ureg == NULL)
@@ -1602,6 +1608,7 @@ st_translate_tesseval_program(struct st_context *st,
/* We have already compiled to NIR so just return */
if (sttep->shader_program) {
   st_translate_program_stream_output(>Base, 
>tgsi.stream_output);
+  st_store_ir_in_disk_cache(st, >Base, true);
   return true;
}
 
@@ -1652,7 +1659,7 @@ st_translate_compute_program(struct st_context *st,
   /* no compute variants: */
   st_finalize_nir(st, >Base, stcp->shader_program,
   (struct nir_shader *) stcp->tgsi.prog);
-
+  st_store_ir_in_disk_cache(st, >Base, true);
   return true;
}
 
-- 
2.14.3

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

[Mesa-dev] [PATCH 2/3] st: add nir shader disk cache support

[Timothy Arceri]

---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp |   2 +-
 src/mesa/state_tracker/st_program.c|   6 +-
 src/mesa/state_tracker/st_shader_cache.c   | 133 +++--
 src/mesa/state_tracker/st_shader_cache.h   |   8 +-
 4 files changed, 115 insertions(+), 34 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index f496bcfe59..e42405f2fa 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -6946,7 +6946,7 @@ st_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
}
 
/* Return early if we are loading the shader from on-disk cache */
-   if (st_load_tgsi_from_disk_cache(ctx, prog)) {
+   if (st_load_ir_from_disk_cache(ctx, prog, use_nir)) {
   return GL_TRUE;
}
 
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 1116b5afbc..de9c5d1654 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -539,7 +539,7 @@ st_translate_vertex_program(struct st_context *st,
 
if (stvp->glsl_to_tgsi) {
   stvp->glsl_to_tgsi = NULL;
-  st_store_tgsi_in_disk_cache(st, >Base);
+  st_store_ir_in_disk_cache(st, >Base, false);
}
 
return stvp->tgsi.tokens != NULL;
@@ -996,7 +996,7 @@ st_translate_fragment_program(struct st_context *st,
 
if (stfp->glsl_to_tgsi) {
   stfp->glsl_to_tgsi = NULL;
-  st_store_tgsi_in_disk_cache(st, >Base);
+  st_store_ir_in_disk_cache(st, >Base, false);
}
 
return stfp->tgsi.tokens != NULL;
@@ -1412,7 +1412,7 @@ st_translate_program_common(struct st_context *st,
outputMapping,
_state->stream_output);
 
-   st_store_tgsi_in_disk_cache(st, prog);
+   st_store_ir_in_disk_cache(st, prog, false);
 
if ((ST_DEBUG & DEBUG_TGSI) && (ST_DEBUG & DEBUG_MESA)) {
   _mesa_print_program(prog);
diff --git a/src/mesa/state_tracker/st_shader_cache.c 
b/src/mesa/state_tracker/st_shader_cache.c
index a971b0d7ee..0f79a410a1 100644
--- a/src/mesa/state_tracker/st_shader_cache.c
+++ b/src/mesa/state_tracker/st_shader_cache.c
@@ -26,6 +26,8 @@
 #include "st_program.h"
 #include "st_shader_cache.h"
 #include "compiler/glsl/program.h"
+#include "compiler/nir/nir.h"
+#include "compiler/nir/nir_serialize.h"
 #include "pipe/p_shader_tokens.h"
 #include "program/ir_to_mesa.h"
 #include "util/u_memory.h"
@@ -44,20 +46,33 @@ write_stream_out_to_cache(struct blob *blob,
 sizeof(tgsi->stream_output));
 }
 
+static void
+copy_blob_to_driver_cache_blob(struct blob *blob, struct gl_program *prog)
+{
+   prog->driver_cache_blob = ralloc_size(NULL, blob->size);
+   memcpy(prog->driver_cache_blob, blob->data, blob->size);
+   prog->driver_cache_blob_size = blob->size;
+}
+
 static void
 write_tgsi_to_cache(struct blob *blob, const struct tgsi_token *tokens,
 struct gl_program *prog, unsigned num_tokens)
 {
blob_write_uint32(blob, num_tokens);
blob_write_bytes(blob, tokens, num_tokens * sizeof(struct tgsi_token));
+   copy_blob_to_driver_cache_blob(blob, prog);
+}
 
-   prog->driver_cache_blob = ralloc_size(NULL, blob->size);
-   memcpy(prog->driver_cache_blob, blob->data, blob->size);
-   prog->driver_cache_blob_size = blob->size;
+static void
+write_nir_to_cache(struct blob *blob, struct gl_program *prog)
+{
+   nir_serialize(blob, prog->nir);
+   copy_blob_to_driver_cache_blob(blob, prog);
 }
 
-void
-st_serialise_tgsi_program(struct gl_context *ctx, struct gl_program *prog)
+static void
+st_serialise_ir_program(struct gl_context *ctx, struct gl_program *prog,
+bool nir)
 {
struct blob blob;
blob_init();
@@ -73,8 +88,12 @@ st_serialise_tgsi_program(struct gl_context *ctx, struct 
gl_program *prog)
sizeof(stvp->result_to_output));
 
   write_stream_out_to_cache(, >tgsi);
-  write_tgsi_to_cache(, stvp->tgsi.tokens, prog,
-  stvp->num_tgsi_tokens);
+
+  if (nir)
+ write_nir_to_cache(, prog);
+  else
+ write_tgsi_to_cache(, stvp->tgsi.tokens, prog,
+ stvp->num_tgsi_tokens);
   break;
}
case MESA_SHADER_TESS_CTRL:
@@ -83,20 +102,29 @@ st_serialise_tgsi_program(struct gl_context *ctx, struct 
gl_program *prog)
   struct st_common_program *stcp = (struct st_common_program *) prog;
 
   write_stream_out_to_cache(, >tgsi);
-  write_tgsi_to_cache(, stcp->tgsi.tokens, prog,
-  stcp->num_tgsi_tokens);
+
+  if (nir)
+ write_nir_to_cache(, prog);
+  else
+ write_tgsi_to_cache(, stcp->tgsi.tokens, prog,
+ stcp->num_tgsi_tokens);
   break;
}
case MESA_SHADER_FRAGMENT: {
   struct st_fragment_program *stfp = (struct st_fragment_program *) prog;
 
-  write_tgsi_to_cache(, 

[Mesa-dev] [PATCH 1/3] st/glsl_to_tgsi: move nir detection earlier and set nir options

[Timothy Arceri]

We move the nir check before the shader cache call so that we can
call a nir based caching function in a following patch.
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp  | 10 ++---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 36 +++---
 2 files changed, 30 insertions(+), 16 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 21b3640b2c..9e627be6da 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -304,14 +304,8 @@ st_glsl_to_nir(struct st_context *st, struct gl_program 
*prog,
struct gl_shader_program *shader_program,
gl_shader_stage stage)
 {
-   struct pipe_screen *pscreen = st->pipe->screen;
-   enum pipe_shader_type ptarget = pipe_shader_type_from_mesa(stage);
-   const nir_shader_compiler_options *options;
-
-   assert(pscreen->get_compiler_options);   /* drivers using NIR must 
implement this */
-
-   options = (const nir_shader_compiler_options *)
-  pscreen->get_compiler_options(pscreen, PIPE_SHADER_IR_NIR, ptarget);
+   const nir_shader_compiler_options *options =
+  st->ctx->Const.ShaderCompilerOptions[prog->info.stage].NirOptions;
assert(options);
 
if (prog->nir)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index f44f02ad9d..f496bcfe59 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -6917,15 +6917,41 @@ extern "C" {
 GLboolean
 st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog)
 {
+   struct pipe_screen *pscreen = ctx->st->pipe->screen;
+
+   bool use_nir = false;
+   for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
+  if (prog->_LinkedShaders[i] == NULL)
+ continue;
+
+  gl_shader_stage stage = prog->_LinkedShaders[i]->Stage;
+  enum pipe_shader_type ptarget = pipe_shader_type_from_mesa(stage);
+  enum pipe_shader_ir preferred_ir = (enum pipe_shader_ir)
+ pscreen->get_shader_param(pscreen, ptarget,
+   PIPE_SHADER_CAP_PREFERRED_IR);
+  use_nir = preferred_ir == PIPE_SHADER_IR_NIR;
+
+  if (use_nir) {
+ const nir_shader_compiler_options *options;
+
+ /* drivers using NIR must implement this */
+ assert(pscreen->get_compiler_options);
+
+ options = (const nir_shader_compiler_options *)
+pscreen->get_compiler_options(pscreen, PIPE_SHADER_IR_NIR, 
ptarget);
+ assert(options);
+
+ ctx->Const.ShaderCompilerOptions[stage].NirOptions = options;
+  }
+   }
+
/* Return early if we are loading the shader from on-disk cache */
if (st_load_tgsi_from_disk_cache(ctx, prog)) {
   return GL_TRUE;
}
 
-   struct pipe_screen *pscreen = ctx->st->pipe->screen;
assert(prog->data->LinkStatus);
 
-   bool use_nir = false;
for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
   if (prog->_LinkedShaders[i] == NULL)
  continue;
@@ -6945,12 +6971,6 @@ st_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
   unsigned if_threshold = pscreen->get_shader_param(pscreen, ptarget,
 
PIPE_SHADER_CAP_LOWER_IF_THRESHOLD);
 
-  enum pipe_shader_ir preferred_ir = (enum pipe_shader_ir)
- pscreen->get_shader_param(pscreen, ptarget,
-   PIPE_SHADER_CAP_PREFERRED_IR);
-  if (preferred_ir == PIPE_SHADER_IR_NIR)
- use_nir = true;
-
   /* If there are forms of indirect addressing that the driver
* cannot handle, perform the lowering pass.
*/
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH v2 16/24] anv/cmd_buffer: Re-arrange the logic around UNDEFINED fast-clears

[Nanley Chery]

On Fri, Jan 19, 2018 at 03:47:33PM -0800, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/genX_cmd_buffer.c | 31 ++-
>  1 file changed, 14 insertions(+), 17 deletions(-)
> 

This patch is
Reviewed-by: Nanley Chery 

> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 67d3839..77fdadf 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -692,29 +692,26 @@ transition_color_buffer(struct anv_cmd_buffer 
> *cmd_buffer,
> * We don't have any data to show that this is a problem, but we want 
> to
> * avoid causing difficult-to-debug problems.
> */
> -  if ((GEN_GEN >= 9 && image->samples == 1) || image->samples > 1) {
> +  if (GEN_GEN >= 9 && image->samples == 1) {
> + for (uint32_t l = 0; l < level_count; l++) {
> +const uint32_t level = base_level + l;
> +const uint32_t level_layer_count =
> +   MIN2(layer_count, anv_image_aux_layers(image, aspect, level));
> +anv_image_ccs_op(cmd_buffer, image, aspect, level,
> + base_layer, level_layer_count,
> + ISL_AUX_OP_FAST_CLEAR, false);
> + }
> +  } else if (image->samples > 1) {
>   if (image->samples == 4 || image->samples == 16) {
>  anv_perf_warn(cmd_buffer->device->instance, image,
>"Doing a potentially unnecessary fast-clear to "
>"define an MCS buffer.");
>   }
>  
> - if (image->samples == 1) {
> -for (uint32_t l = 0; l < level_count; l++) {
> -   const uint32_t level = base_level + l;
> -   const uint32_t level_layer_count =
> -  MIN2(layer_count, anv_image_aux_layers(image, aspect, 
> level));
> -   anv_image_ccs_op(cmd_buffer, image, aspect, level,
> -base_layer, level_layer_count,
> -ISL_AUX_OP_FAST_CLEAR, false);
> -}
> - } else {
> -assert(image->samples > 1);
> -assert(base_level == 0 && level_count == 1);
> -anv_image_mcs_op(cmd_buffer, image, aspect,
> - base_layer, layer_count,
> - ISL_AUX_OP_FAST_CLEAR, false);
> - }
> + assert(base_level == 0 && level_count == 1);
> + anv_image_mcs_op(cmd_buffer, image, aspect,
> +  base_layer, layer_count,
> +  ISL_AUX_OP_FAST_CLEAR, false);
>}
>/* At this point, some elements of the CCS buffer may have the 
> fast-clear
> * bit-arrangement. As the user writes to a subresource, we need to 
> have
> -- 
> 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] meson builds don't read dri options

[Dylan Baker]

Quoting Kenneth Graunke (2018-01-23 15:04:18)
> On Tuesday, January 23, 2018 10:34:25 AM PST Dylan Baker wrote:
> > There's a bug in our meson build, and I sent a patch. We need to join_dirs 
> > with
> > get_option('prefix'). I got a little confused because when you pass a 
> > relative
> > directory to meson's `install` option it will autotmatically make it 
> > absolute,
> > but when you pass it to a C define it doesn't.
> 
> sysconfdir isn't always a subdirectory of prefix though.
> 
> By default, sysconfdir is $prefix/etc (i.e. /usr/local/etc).  But
> tho most common distro setting is prefix = /usr and sysconfdir = /etc.
> 
> So unless Meson makes sysconfdir "../etc" in that case, I don't think
> joining prefix and sysconfdir will do what you want...?

In that case shouldn't you pass sysconfdir as an absolute path to meson though?

If we can assume that we could do something like:

sysdir = get_option('sysconfigdir')
if not sysdir.startswith('/')  # TODO: windows
  sysdir = join_paths(get_option('prefix'), sysdir)
endif


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

Re: [Mesa-dev] [PATCH v2] meson: Don't confuse the install and search paths for dri drivers

[Dylan Baker]

Sure enough, it does use ':'

You might want to send the patch to the list and CC Emil, and probably stable.
Although Emil also mentioned that maybe it would just be better to delete this
option since we have LIBGL_DRIVERS_PATH.

Quoting Eric Engestrom (2018-01-23 15:28:50)
> On Tuesday, 2018-01-23 21:53:14 +, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-01-18 15:02:46)
> > > On Thursday, 2018-01-18 17:09:33 +, Dylan Baker wrote:
> > > > Currently there is not a separate option for setting the search path of
> > > > DRI drivers in meson, like there is in scons and autotools. This is an
> > > > oversight and needs to be fixed. This adds an extra option
> > > > `dri-search-path`, which will default to the value of
> > > > `dri-drivers-path`, like autotools does.
> > > > 
> > > > v2: - Split input list before joining.
> > > > 
> > > > Reported-by: Ilia Mirkin 
> > > > Signed-off-by: Dylan Baker 
> > > > ---
> > > >  meson.build | 6 ++
> > > >  meson_options.txt   | 8 +++-
> > > >  src/egl/meson.build | 2 +-
> > > >  src/gbm/meson.build | 2 +-
> > > >  src/glx/meson.build | 3 ++-
> > > >  5 files changed, 17 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/meson.build b/meson.build
> > > > index f3179c38062..8bab43681e9 100644
> > > > --- a/meson.build
> > > > +++ b/meson.build
> > > > @@ -57,6 +57,12 @@ dri_drivers_path = get_option('dri-drivers-path')
> > > >  if dri_drivers_path == ''
> > > >dri_drivers_path = join_paths(get_option('libdir'), 'dri')
> > > >  endif
> > > > +_search = get_option('dri-search-path')
> > > > +if _search != ''
> > > > +  dri_search_path = ';'.join(_search.split(','))
> > > 
> > > s/;/:/
> > 
> > The autotools help string says semi-colon. Does the help string need to be
> > updated?
> 
> I had checked the code, I didn't think to check if there was
> documentation for this.
> 
> All 3 users that I saw (egl, gbm, glx) use ':' as the delimiter:
> src/egl/drivers/dri2/egl_dri2.c:525
> src/gbm/backends/dri/gbm_dri.c:338
> src/glx/dri_common.c:120
> 
> So it looks like you found an error in the autotools doc :)
> 
> 8<
> diff --git a/configure.ac b/configure.ac
> index e236a3c54f..7209e42c55 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1852,7 +1852,7 @@ AC_SUBST([DRI_DRIVER_INSTALL_DIR])
>  dnl Extra search path for DRI drivers
>  AC_ARG_WITH([dri-searchpath],
>  [AS_HELP_STRING([--with-dri-searchpath=DIRS...],
> -[semicolon delimited DRI driver search directories 
> @<:@${libdir}/dri@:>@])],
> +[colon delimited DRI driver search directories 
> @<:@${libdir}/dri@:>@])],
>  [DRI_DRIVER_SEARCH_DIR="$withval"],
>  [DRI_DRIVER_SEARCH_DIR='${DRI_DRIVER_INSTALL_DIR}'])
>  AC_SUBST([DRI_DRIVER_SEARCH_DIR])
> >8
> 
> > 
> > > 
> > > Reviewed-by: Eric Engestrom 
> > > 
> > > > +else
> > > > +  dri_search_path = dri_drivers_path
> > > > +endif
> > > >  
> > > >  with_gles1 = get_option('gles1')
> > > >  with_gles2 = get_option('gles2')
> > > > diff --git a/meson_options.txt b/meson_options.txt
> > > > index 894378985fd..e541659733f 100644
> > > > --- a/meson_options.txt
> > > > +++ b/meson_options.txt
> > > > @@ -41,7 +41,13 @@ option(
> > > >'dri-drivers-path',
> > > >type : 'string',
> > > >value : '',
> > > > -  description : 'Location of dri drivers. Default: $libdir/dri.'
> > > > +  description : 'Location to install dri drivers. Default: 
> > > > $libdir/dri.'
> > > > +)
> > > > +option(
> > > > +  'dri-search-path',
> > > > +  type : 'string',
> > > > +  value : '',
> > > > +  description : 'Locations to search for dri drivers, passed as comma 
> > > > separated list. Default: dri-drivers-path.'
> > > >  )
> > > >  option(
> > > >'gallium-drivers',
> > > > diff --git a/src/egl/meson.build b/src/egl/meson.build
> > > > index df6e8b49dac..6cd04567b0d 100644
> > > > --- a/src/egl/meson.build
> > > > +++ b/src/egl/meson.build
> > > > @@ -160,7 +160,7 @@ libegl = shared_library(
> > > >c_args : [
> > > >  c_vis_args,
> > > >  c_args_for_egl,
> > > > -'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir),
> > > > +'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
> > > >  '-D_EGL_BUILT_IN_DRIVER_DRI2',
> > > >  
> > > > '-D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_@0@'.format(egl_native_platform.to_upper()),
> > > >],
> > > > diff --git a/src/gbm/meson.build b/src/gbm/meson.build
> > > > index 14b9e960360..2f5d1c6ddd7 100644
> > > > --- a/src/gbm/meson.build
> > > > +++ b/src/gbm/meson.build
> > > > @@ -38,7 +38,7 @@ incs_gbm = [
> > > >  if with_dri2
> > > >files_gbm += files('backends/dri/gbm_dri.c', 
> > > > 'backends/dri/gbm_driint.h')
> > > >deps_gbm += dep_libdrm # TODO: pthread-stubs
> > > > -  args_gbm += '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir)
> > > > +  args_gbm += '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path)
> > > >  endif
> > > >  if 

Re: [Mesa-dev] [PATCH] radv: fix sample_mask_in loading. (v3)

[Bas Nieuwenhuizen]

On Wed, Jan 24, 2018 at 12:00 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This is ported from radeonsi and fixes:
> dEQP-VK.pipeline.multisample_shader_builtin.sample_mask.bit_*
>
> v2: don't call this path for radeonsi, it does it in the epilog.
> use the radeonsi code path.
> v3: handle NULL pCreateInfo->pMultisampleState properly (Samuel)
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 29 -
>  src/amd/common/ac_nir_to_llvm.h |  2 ++
>  src/amd/vulkan/radv_pipeline.c  | 29 -
>  src/amd/vulkan/radv_private.h   |  2 ++
>  4 files changed, 56 insertions(+), 6 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index cc3af77..8ae8650 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -4049,6 +4049,30 @@ static LLVMValueRef load_sample_pos(struct 
> ac_nir_context *ctx)
> return ac_build_gather_values(>ac, values, 2);
>  }
>
> +static LLVMValueRef load_sample_mask_in(struct ac_nir_context *ctx)
> +{
> +   uint8_t log2_ps_iter_samples = 
> ctx->nctx->shader_info->info.ps.force_persample ? 
> ctx->nctx->options->key.fs.log2_num_samples : 
> ctx->nctx->options->key.fs.log2_ps_iter_samples;
> +
> +   /* The bit pattern matches that used by fixed function fragment
> +* processing. */
> +   static const uint16_t ps_iter_masks[] = {
> +   0x, /* not used */
> +   0x,
> +   0x,
> +   0x0101,
> +   0x0001,
> +   };
> +   assert(log2_ps_iter_samples < ARRAY_SIZE(ps_iter_masks));
> +
> +   uint32_t ps_iter_mask = ps_iter_masks[log2_ps_iter_samples];
> +
> +   LLVMValueRef result, sample_id;
> +   sample_id = unpack_param(>ac, ctx->abi->ancillary, 8, 4);
> +   sample_id = LLVMBuildShl(ctx->ac.builder, LLVMConstInt(ctx->ac.i32, 
> ps_iter_mask, false), sample_id, "");
> +   result = LLVMBuildAnd(ctx->ac.builder, sample_id, 
> ctx->abi->sample_coverage, "");
> +   return result;
> +}
> +
>  static LLVMValueRef visit_interp(struct nir_to_llvm_context *ctx,
>  const nir_intrinsic_instr *instr)
>  {
> @@ -4353,7 +4377,10 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
> result = load_sample_pos(ctx);
> break;
> case nir_intrinsic_load_sample_mask_in:
> -   result = ctx->abi->sample_coverage;
> +   if (ctx->nctx)
> +   result = load_sample_mask_in(ctx);
> +   else
> +   result = ctx->abi->sample_coverage;
> break;
> case nir_intrinsic_load_frag_coord: {
> LLVMValueRef values[4] = {
> diff --git a/src/amd/common/ac_nir_to_llvm.h b/src/amd/common/ac_nir_to_llvm.h
> index 62ea38b..1656289 100644
> --- a/src/amd/common/ac_nir_to_llvm.h
> +++ b/src/amd/common/ac_nir_to_llvm.h
> @@ -60,6 +60,8 @@ struct ac_tcs_variant_key {
>
>  struct ac_fs_variant_key {
> uint32_t col_format;
> +   uint8_t log2_ps_iter_samples;
> +   uint8_t log2_num_samples;
> uint32_t is_int8;
> uint32_t is_int10;
> uint32_t multisample : 1;
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index a49fe05..416b80f 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -798,6 +798,18 @@ radv_pipeline_init_raster_state(struct radv_pipeline 
> *pipeline,
>
>  }
>
> +static uint8_t radv_pipeline_get_ps_iter_samples(const 
> VkPipelineMultisampleStateCreateInfo *vkms)
> +{
> +   uint32_t num_samples = vkms->rasterizationSamples;
> +   uint32_t ps_iter_samples = num_samples;

I think ps_iter_samples should default to 1 without
vkm->sampleShadingEnable. (It will be overridden anyway when forcing
per sample shading).

With that:

Reviewed-by: Bas Nieuwenhuizen 

> +
> +   if (vkms->sampleShadingEnable) {
> +   ps_iter_samples = ceil(vkms->minSampleShading * num_samples);
> +   ps_iter_samples = util_next_power_of_two(ps_iter_samples);
> +   }
> +   return ps_iter_samples;
> +}
> +
>  static void
>  radv_pipeline_init_multisample_state(struct radv_pipeline *pipeline,
>  const VkGraphicsPipelineCreateInfo 
> *pCreateInfo)
> @@ -813,9 +825,9 @@ radv_pipeline_init_multisample_state(struct radv_pipeline 
> *pipeline,
> else
> ms->num_samples = 1;
>
> -   if (vkms && vkms->sampleShadingEnable) {
> -   ps_iter_samples = ceil(vkms->minSampleShading * 
> ms->num_samples);
> -   } else if 
> (pipeline->shaders[MESA_SHADER_FRAGMENT]->info.info.ps.force_persample) {
> +   if (vkms)
> +   ps_iter_samples = radv_pipeline_get_ps_iter_samples(vkms);
> +   if 

Re: [Mesa-dev] [PATCH 0.5/5] i965/tiled_memcpy: linear_to_ytiled a cache line at a time

[Chris Wilson]

Quoting Scott D Phillips (2018-01-23 14:42:43)
> TileY's low 6 address bits are: v1 v0 u3 u2 u1 u0
> Thus a cache line in the tiled surface is composed of a 2d area of
> 16x4 bytes of the linear surface.
> 
> Add a special case where the area being copied is 4-line aligned
> and a multiple of 4-lines so that entire cache lines will be
> written at a time.

Looks correct (mechanics of aligning to the WCB are sound). You can also
apply the same to ytiled_to_linear and use movntdqa for fast WC
readback.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 04/22] clover: Disallow creating libraries from other libraries

[Pierre Moreau]

On 2018-01-23 — 15:16, Francisco Jerez wrote:
> Pierre Moreau  writes:
> 
> > On 2018-01-23 — 14:04, Francisco Jerez wrote:
> >> Pierre Moreau  writes:
> >> 
> >> > If creating a library, do not allow non-compiled object in it, as
> >> > executables are not allowed, and libraries would make it really hard to
> >> > enforce the "-enable-link-options" flag.
> >> >
> >> > Signed-off-by: Pierre Moreau 
> >> > ---
> >> >  src/gallium/state_trackers/clover/api/program.cpp | 19 
> >> > ---
> >> >  1 file changed, 16 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
> >> > b/src/gallium/state_trackers/clover/api/program.cpp
> >> > index 6044179587..8f0b103a4d 100644
> >> > --- a/src/gallium/state_trackers/clover/api/program.cpp
> >> > +++ b/src/gallium/state_trackers/clover/api/program.cpp
> >> > @@ -251,9 +251,13 @@ clCompileProgram(cl_program d_prog, cl_uint 
> >> > num_devs,
> >> >  namespace {
> >> > ref_vector
> >> > validate_link_devices(const ref_vector ,
> >> > - const ref_vector _devs) {
> >> > + const ref_vector _devs,
> >> > + const std::string ) {
> >> >std::vector devs;
> >> >  
> >> > +  const std::string flag = "-create-library";
> 
> This seems to be unused.
> 
> >> > +  const bool create_library = opts.find("-create-library") != 
> >> > std::string::npos;
> >> > +
> >> >for (auto  : all_devs) {
> >> >   const auto has_binary = [&](const program ) {
> >> >  const auto t = prog.build(dev).binary_type();
> >> > @@ -261,10 +265,19 @@ namespace {
> >> > t == CL_PROGRAM_BINARY_TYPE_LIBRARY;
> >> >   };
> >> >  
> >> > + // If creating a library, do not allow non-compiled object in 
> >> > it, as
> >> > + // executables are not allowed, and libraries would make it 
> >> > really
> >> > + // hard to enforce the "-enable-link-options".
> >> > + if (create_library && any_of([&](const program ) {
> >> > +  const auto t = prog.build(dev).binary_type();
> >> > +  return t != CL_PROGRAM_BINARY_TYPE_COMPILED_OBJECT;
> >> > +   }, progs))
> >> > +throw error(CL_INVALID_OPERATION);
> >> > +
> >> 
> >> Do you have any spec quote justifying this?  "Hard" is hardly a
> >> justification for emitting an unexpected API error ;).  If doing such a
> >> thing would rely on unimplemented behavior somewhere else it would
> >> probably be cleaner to assert-fail wherever an implementation is missing
> >> rather than returning an API error under conditions not expected by the
> >> application.
> >
> > Re-reading the spec, I am quite sure that libraries can’t be made of 
> > libraries.
> > From Section 5.6.5.1:
> >
> >> The following options can be specified when creating a library of compiled 
> >> binaries.
> >>
> >> -create-library
> >> Create a library of compiled binaries specified in input_programs 
> >> argument to
> >> clLinkProgram
> >
> 
> Fair enough, can you add this sentence as a spec quote to the comment
> above?  With that taken into account:

And I’ll also remove the sentence about it being ”hard”. :-)

Thank you very much for all the reviews! Much appreciated!

> 
> Reviewed-by: Francisco Jerez 
> 
> > and earlier on, in Section 5.6.3 when defining clLinkProgram, it makes the
> > distinction between compiled binaries, libraries, and executables:
> >
> >> input_programs is an array of program objects that are compiled binaries or
> >> libraries that are to be linked to create the program executable.
> >
> > (both extracts come from the 1.2 specification)
> >
> >> 
> >> >   // According to the CL 1.2 spec, when "all programs specified 
> >> > [..]
> >> >   // contain a compiled binary or library for the device [..] a 
> >> > link is
> >> >   // performed",
> >> > - if (all_of(has_binary, progs))
> >> > + else if (all_of(has_binary, progs))
> >> >  devs.push_back();
> >> >  
> >> >   // otherwise if "none of the programs contain a compiled 
> >> > binary or
> >> > @@ -290,7 +303,7 @@ clLinkProgram(cl_context d_ctx, cl_uint num_devs, 
> >> > const cl_device_id *d_devs,
> >> > auto prog = create(ctx);
> >> > auto devs = validate_link_devices(progs,
> >> >   (d_devs ? objs(d_devs, num_devs) :
> >> > -  
> >> > ref_vector(ctx.devices(;
> >> > +  
> >> > ref_vector(ctx.devices())), opts);
> >> >  
> >> > validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
> >> >  
> >> > -- 
> >> > 2.16.0



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

Re: [Mesa-dev] [PATCH v2 04/22] clover: Disallow creating libraries from other libraries

[Francisco Jerez]

Pierre Moreau  writes:

> On 2018-01-23 — 14:04, Francisco Jerez wrote:
>> Pierre Moreau  writes:
>> 
>> > If creating a library, do not allow non-compiled object in it, as
>> > executables are not allowed, and libraries would make it really hard to
>> > enforce the "-enable-link-options" flag.
>> >
>> > Signed-off-by: Pierre Moreau 
>> > ---
>> >  src/gallium/state_trackers/clover/api/program.cpp | 19 ---
>> >  1 file changed, 16 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
>> > b/src/gallium/state_trackers/clover/api/program.cpp
>> > index 6044179587..8f0b103a4d 100644
>> > --- a/src/gallium/state_trackers/clover/api/program.cpp
>> > +++ b/src/gallium/state_trackers/clover/api/program.cpp
>> > @@ -251,9 +251,13 @@ clCompileProgram(cl_program d_prog, cl_uint num_devs,
>> >  namespace {
>> > ref_vector
>> > validate_link_devices(const ref_vector ,
>> > - const ref_vector _devs) {
>> > + const ref_vector _devs,
>> > + const std::string ) {
>> >std::vector devs;
>> >  
>> > +  const std::string flag = "-create-library";

This seems to be unused.

>> > +  const bool create_library = opts.find("-create-library") != 
>> > std::string::npos;
>> > +
>> >for (auto  : all_devs) {
>> >   const auto has_binary = [&](const program ) {
>> >  const auto t = prog.build(dev).binary_type();
>> > @@ -261,10 +265,19 @@ namespace {
>> > t == CL_PROGRAM_BINARY_TYPE_LIBRARY;
>> >   };
>> >  
>> > + // If creating a library, do not allow non-compiled object in 
>> > it, as
>> > + // executables are not allowed, and libraries would make it 
>> > really
>> > + // hard to enforce the "-enable-link-options".
>> > + if (create_library && any_of([&](const program ) {
>> > +  const auto t = prog.build(dev).binary_type();
>> > +  return t != CL_PROGRAM_BINARY_TYPE_COMPILED_OBJECT;
>> > +   }, progs))
>> > +throw error(CL_INVALID_OPERATION);
>> > +
>> 
>> Do you have any spec quote justifying this?  "Hard" is hardly a
>> justification for emitting an unexpected API error ;).  If doing such a
>> thing would rely on unimplemented behavior somewhere else it would
>> probably be cleaner to assert-fail wherever an implementation is missing
>> rather than returning an API error under conditions not expected by the
>> application.
>
> Re-reading the spec, I am quite sure that libraries can’t be made of 
> libraries.
> From Section 5.6.5.1:
>
>> The following options can be specified when creating a library of compiled 
>> binaries.
>>
>> -create-library
>> Create a library of compiled binaries specified in input_programs 
>> argument to
>> clLinkProgram
>

Fair enough, can you add this sentence as a spec quote to the comment
above?  With that taken into account:

Reviewed-by: Francisco Jerez 

> and earlier on, in Section 5.6.3 when defining clLinkProgram, it makes the
> distinction between compiled binaries, libraries, and executables:
>
>> input_programs is an array of program objects that are compiled binaries or
>> libraries that are to be linked to create the program executable.
>
> (both extracts come from the 1.2 specification)
>
>> 
>> >   // According to the CL 1.2 spec, when "all programs specified 
>> > [..]
>> >   // contain a compiled binary or library for the device [..] a 
>> > link is
>> >   // performed",
>> > - if (all_of(has_binary, progs))
>> > + else if (all_of(has_binary, progs))
>> >  devs.push_back();
>> >  
>> >   // otherwise if "none of the programs contain a compiled binary 
>> > or
>> > @@ -290,7 +303,7 @@ clLinkProgram(cl_context d_ctx, cl_uint num_devs, 
>> > const cl_device_id *d_devs,
>> > auto prog = create(ctx);
>> > auto devs = validate_link_devices(progs,
>> >   (d_devs ? objs(d_devs, num_devs) :
>> > -  ref_vector(ctx.devices(;
>> > +  ref_vector(ctx.devices())), 
>> > opts);
>> >  
>> > validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
>> >  
>> > -- 
>> > 2.16.0


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

Re: [Mesa-dev] [PATCH v2] meson: Don't confuse the install and search paths for dri drivers

[Eric Engestrom]

On Tuesday, 2018-01-23 21:53:14 +, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-01-18 15:02:46)
> > On Thursday, 2018-01-18 17:09:33 +, Dylan Baker wrote:
> > > Currently there is not a separate option for setting the search path of
> > > DRI drivers in meson, like there is in scons and autotools. This is an
> > > oversight and needs to be fixed. This adds an extra option
> > > `dri-search-path`, which will default to the value of
> > > `dri-drivers-path`, like autotools does.
> > > 
> > > v2: - Split input list before joining.
> > > 
> > > Reported-by: Ilia Mirkin 
> > > Signed-off-by: Dylan Baker 
> > > ---
> > >  meson.build | 6 ++
> > >  meson_options.txt   | 8 +++-
> > >  src/egl/meson.build | 2 +-
> > >  src/gbm/meson.build | 2 +-
> > >  src/glx/meson.build | 3 ++-
> > >  5 files changed, 17 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/meson.build b/meson.build
> > > index f3179c38062..8bab43681e9 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -57,6 +57,12 @@ dri_drivers_path = get_option('dri-drivers-path')
> > >  if dri_drivers_path == ''
> > >dri_drivers_path = join_paths(get_option('libdir'), 'dri')
> > >  endif
> > > +_search = get_option('dri-search-path')
> > > +if _search != ''
> > > +  dri_search_path = ';'.join(_search.split(','))
> > 
> > s/;/:/
> 
> The autotools help string says semi-colon. Does the help string need to be
> updated?

I had checked the code, I didn't think to check if there was
documentation for this.

All 3 users that I saw (egl, gbm, glx) use ':' as the delimiter:
src/egl/drivers/dri2/egl_dri2.c:525
src/gbm/backends/dri/gbm_dri.c:338
src/glx/dri_common.c:120

So it looks like you found an error in the autotools doc :)

8<
diff --git a/configure.ac b/configure.ac
index e236a3c54f..7209e42c55 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1852,7 +1852,7 @@ AC_SUBST([DRI_DRIVER_INSTALL_DIR])
 dnl Extra search path for DRI drivers
 AC_ARG_WITH([dri-searchpath],
 [AS_HELP_STRING([--with-dri-searchpath=DIRS...],
-[semicolon delimited DRI driver search directories 
@<:@${libdir}/dri@:>@])],
+[colon delimited DRI driver search directories 
@<:@${libdir}/dri@:>@])],
 [DRI_DRIVER_SEARCH_DIR="$withval"],
 [DRI_DRIVER_SEARCH_DIR='${DRI_DRIVER_INSTALL_DIR}'])
 AC_SUBST([DRI_DRIVER_SEARCH_DIR])
>8

> 
> > 
> > Reviewed-by: Eric Engestrom 
> > 
> > > +else
> > > +  dri_search_path = dri_drivers_path
> > > +endif
> > >  
> > >  with_gles1 = get_option('gles1')
> > >  with_gles2 = get_option('gles2')
> > > diff --git a/meson_options.txt b/meson_options.txt
> > > index 894378985fd..e541659733f 100644
> > > --- a/meson_options.txt
> > > +++ b/meson_options.txt
> > > @@ -41,7 +41,13 @@ option(
> > >'dri-drivers-path',
> > >type : 'string',
> > >value : '',
> > > -  description : 'Location of dri drivers. Default: $libdir/dri.'
> > > +  description : 'Location to install dri drivers. Default: $libdir/dri.'
> > > +)
> > > +option(
> > > +  'dri-search-path',
> > > +  type : 'string',
> > > +  value : '',
> > > +  description : 'Locations to search for dri drivers, passed as comma 
> > > separated list. Default: dri-drivers-path.'
> > >  )
> > >  option(
> > >'gallium-drivers',
> > > diff --git a/src/egl/meson.build b/src/egl/meson.build
> > > index df6e8b49dac..6cd04567b0d 100644
> > > --- a/src/egl/meson.build
> > > +++ b/src/egl/meson.build
> > > @@ -160,7 +160,7 @@ libegl = shared_library(
> > >c_args : [
> > >  c_vis_args,
> > >  c_args_for_egl,
> > > -'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir),
> > > +'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
> > >  '-D_EGL_BUILT_IN_DRIVER_DRI2',
> > >  
> > > '-D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_@0@'.format(egl_native_platform.to_upper()),
> > >],
> > > diff --git a/src/gbm/meson.build b/src/gbm/meson.build
> > > index 14b9e960360..2f5d1c6ddd7 100644
> > > --- a/src/gbm/meson.build
> > > +++ b/src/gbm/meson.build
> > > @@ -38,7 +38,7 @@ incs_gbm = [
> > >  if with_dri2
> > >files_gbm += files('backends/dri/gbm_dri.c', 
> > > 'backends/dri/gbm_driint.h')
> > >deps_gbm += dep_libdrm # TODO: pthread-stubs
> > > -  args_gbm += '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir)
> > > +  args_gbm += '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path)
> > >  endif
> > >  if with_platform_wayland
> > >deps_gbm += dep_wayland_server
> > > diff --git a/src/glx/meson.build b/src/glx/meson.build
> > > index 04cd647ee49..508e7583ee5 100644
> > > --- a/src/glx/meson.build
> > > +++ b/src/glx/meson.build
> > > @@ -128,7 +128,8 @@ else
> > >  endif
> > >  
> > >  gl_lib_cargs = [
> > > -  '-D_REENTRANT', '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir),
> > > +  '-D_REENTRANT',
> > > +  '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
> > >  ]
> > >  
> > >  if dep_xxf86vm != [] and dep_xxf86vm.found()
> > 

Re: [Mesa-dev] [PATCH v2 03/22] clover/api: Fail if trying to build a non-executable binary

[Francisco Jerez]

Pierre Moreau  writes:

> On 2018-01-23 — 14:03, Francisco Jerez wrote:
>> Pierre Moreau  writes:
>> 
>> > From the OpenCL 1.2 Specification, Section 5.6.2 (about clBuildProgram:
>> >
>> >> If program is created with clCreateProgramWithBinary, then the
>> >> program binary must be an executable binary (not a compiled binary or
>> >> library).
>> >
>> > Signed-off-by: Pierre Moreau 
>> > ---
>> >  src/gallium/state_trackers/clover/api/program.cpp | 8 
>> >  1 file changed, 8 insertions(+)
>> >
>> > diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
>> > b/src/gallium/state_trackers/clover/api/program.cpp
>> > index 9d59668f8f..6044179587 100644
>> > --- a/src/gallium/state_trackers/clover/api/program.cpp
>> > +++ b/src/gallium/state_trackers/clover/api/program.cpp
>> > @@ -186,6 +186,14 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
>> > if (prog.has_source) {
>> >prog.compile(devs, opts);
>> >prog.link(devs, opts, { prog });
>> > +   } else if (any_of([&](const device ){
>> > + return prog.build(dev).binary_type() != 
>> > CL_PROGRAM_BINARY_TYPE_EXECUTABLE;
>> > + }, objs(d_devs, num_devs))) {
>> 
>> Shouldn't this be using the range of devices the application requested
>> to build for (which might be the whole set of devices associated with
>> prog if d_devs was null) instead of the objs expression?
>
> I had missed that part of the specification, when d_devs is null. I’ll fix the
> code, and reformat the specification extract as suggested further down.
>

I think this could just use the "devs" variable defined above, but from
the look of it the current definition probably has a bug, it should be
using prog.devices() instead of prog.context().devices() in cases where
d_devs is specified as NULL.

>> 
>> > +  // OpenCL 1.2 Specification, Section 5.6.2:
>> > +  // > If program is created with clCreateProgramWithBinary, then the
>> > +  // > program binary must be an executable binary (not a compiled 
>> > binary or
>> > +  // > library).
>> 
>> I'd format this like:
>> 
>> |  // According to the OpenCL 1.2 specification, "if program is created 
>> with
>> |  // clCreateProgramWithBinary, then the program binary must be an 
>> executable
>> |  // binary (not a compiled binary or library)."
>> 
>> > +  throw error(CL_INVALID_BINARY);
>> > }
>> >  
>> > return CL_SUCCESS;
>> > -- 
>> > 2.16.0


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

Re: [Mesa-dev] [PATCH v2 02/22] clover: Add additional functions to query supported IRs

[Pierre Moreau]

On 2018-01-23 — 14:03, Francisco Jerez wrote:
> Pierre Moreau  writes:
> 
> > Signed-off-by: Pierre Moreau 
> > ---
> >  src/gallium/state_trackers/clover/core/device.cpp | 11 +++
> >  src/gallium/state_trackers/clover/core/device.hpp |  3 +++
> >  2 files changed, 14 insertions(+)
> >
> > diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
> > b/src/gallium/state_trackers/clover/core/device.cpp
> > index 9dd7eed3f1..7eaa0ca2cb 100644
> > --- a/src/gallium/state_trackers/clover/core/device.cpp
> > +++ b/src/gallium/state_trackers/clover/core/device.cpp
> > @@ -247,6 +247,12 @@ device::ir_format() const {
> >pipe, PIPE_SHADER_COMPUTE, PIPE_SHADER_CAP_PREFERRED_IR);
> >  }
> >  
> > +cl_uint
> > +device::supported_irs() const {
> > +   return (enum pipe_shader_ir) pipe->get_shader_param(
> > +  pipe, PIPE_SHADER_COMPUTE, PIPE_SHADER_CAP_SUPPORTED_IRS);
> > +}
> > +
> 
> I don't think we need this as a public method of clover::device, the
> bitmask can be a local variable definition within supports_ir below.

If we need to iterate over those IRs until we find one that suits us (for
example, one to each we can convert from LLVM IR or SPIR-V), then that function
could be of some use, but that’s pretty much the only one I can think of, and
it shouldn’t happen that often, making the overhead of calling the function
multiple times through supports_ir() relatively small.
I’ll follow your suggestion.

> 
> >  std::string
> >  device::ir_target() const {
> > std::vector target = get_compute_param(
> > @@ -268,3 +274,8 @@ std::string
> >  device::device_clc_version() const {
> >  return "1.1";
> >  }
> > +
> > +bool
> > +device::supports_ir(cl_uint ir) const {
> > +   return supported_irs() & (1 << ir);
> > +}
> > diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
> > b/src/gallium/state_trackers/clover/core/device.hpp
> > index 85cd031676..eed644e919 100644
> > --- a/src/gallium/state_trackers/clover/core/device.hpp
> > +++ b/src/gallium/state_trackers/clover/core/device.hpp
> > @@ -80,9 +80,12 @@ namespace clover {
> >std::string device_version() const;
> >std::string device_clc_version() const;
> >enum pipe_shader_ir ir_format() const;
> > +  cl_uint supported_irs() const;
> >std::string ir_target() const;
> >enum pipe_endian endianness() const;
> >  
> > +  bool supports_ir(cl_uint ir) const;
> 
> The argument of this method is a pipe_shader_ir enumerant, we should
> declare it as such.

This is true. I thought I had changed that already, but apparently not.

> 
> > +
> >friend class command_queue;
> >friend class root_resource;
> >friend class hard_event;
> > -- 
> > 2.16.0



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

Re: [Mesa-dev] [PATCH v2 03/22] clover/api: Fail if trying to build a non-executable binary

[Pierre Moreau]

On 2018-01-23 — 14:03, Francisco Jerez wrote:
> Pierre Moreau  writes:
> 
> > From the OpenCL 1.2 Specification, Section 5.6.2 (about clBuildProgram:
> >
> >> If program is created with clCreateProgramWithBinary, then the
> >> program binary must be an executable binary (not a compiled binary or
> >> library).
> >
> > Signed-off-by: Pierre Moreau 
> > ---
> >  src/gallium/state_trackers/clover/api/program.cpp | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
> > b/src/gallium/state_trackers/clover/api/program.cpp
> > index 9d59668f8f..6044179587 100644
> > --- a/src/gallium/state_trackers/clover/api/program.cpp
> > +++ b/src/gallium/state_trackers/clover/api/program.cpp
> > @@ -186,6 +186,14 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
> > if (prog.has_source) {
> >prog.compile(devs, opts);
> >prog.link(devs, opts, { prog });
> > +   } else if (any_of([&](const device ){
> > + return prog.build(dev).binary_type() != 
> > CL_PROGRAM_BINARY_TYPE_EXECUTABLE;
> > + }, objs(d_devs, num_devs))) {
> 
> Shouldn't this be using the range of devices the application requested
> to build for (which might be the whole set of devices associated with
> prog if d_devs was null) instead of the objs expression?

I had missed that part of the specification, when d_devs is null. I’ll fix the
code, and reformat the specification extract as suggested further down.

> 
> > +  // OpenCL 1.2 Specification, Section 5.6.2:
> > +  // > If program is created with clCreateProgramWithBinary, then the
> > +  // > program binary must be an executable binary (not a compiled 
> > binary or
> > +  // > library).
> 
> I'd format this like:
> 
> |  // According to the OpenCL 1.2 specification, "if program is created 
> with
> |  // clCreateProgramWithBinary, then the program binary must be an 
> executable
> |  // binary (not a compiled binary or library)."
> 
> > +  throw error(CL_INVALID_BINARY);
> > }
> >  
> > return CL_SUCCESS;
> > -- 
> > 2.16.0



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

Re: [Mesa-dev] [PATCH v2 04/22] clover: Disallow creating libraries from other libraries

[Pierre Moreau]

On 2018-01-23 — 14:04, Francisco Jerez wrote:
> Pierre Moreau  writes:
> 
> > If creating a library, do not allow non-compiled object in it, as
> > executables are not allowed, and libraries would make it really hard to
> > enforce the "-enable-link-options" flag.
> >
> > Signed-off-by: Pierre Moreau 
> > ---
> >  src/gallium/state_trackers/clover/api/program.cpp | 19 ---
> >  1 file changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
> > b/src/gallium/state_trackers/clover/api/program.cpp
> > index 6044179587..8f0b103a4d 100644
> > --- a/src/gallium/state_trackers/clover/api/program.cpp
> > +++ b/src/gallium/state_trackers/clover/api/program.cpp
> > @@ -251,9 +251,13 @@ clCompileProgram(cl_program d_prog, cl_uint num_devs,
> >  namespace {
> > ref_vector
> > validate_link_devices(const ref_vector ,
> > - const ref_vector _devs) {
> > + const ref_vector _devs,
> > + const std::string ) {
> >std::vector devs;
> >  
> > +  const std::string flag = "-create-library";
> > +  const bool create_library = opts.find("-create-library") != 
> > std::string::npos;
> > +
> >for (auto  : all_devs) {
> >   const auto has_binary = [&](const program ) {
> >  const auto t = prog.build(dev).binary_type();
> > @@ -261,10 +265,19 @@ namespace {
> > t == CL_PROGRAM_BINARY_TYPE_LIBRARY;
> >   };
> >  
> > + // If creating a library, do not allow non-compiled object in it, 
> > as
> > + // executables are not allowed, and libraries would make it really
> > + // hard to enforce the "-enable-link-options".
> > + if (create_library && any_of([&](const program ) {
> > +  const auto t = prog.build(dev).binary_type();
> > +  return t != CL_PROGRAM_BINARY_TYPE_COMPILED_OBJECT;
> > +   }, progs))
> > +throw error(CL_INVALID_OPERATION);
> > +
> 
> Do you have any spec quote justifying this?  "Hard" is hardly a
> justification for emitting an unexpected API error ;).  If doing such a
> thing would rely on unimplemented behavior somewhere else it would
> probably be cleaner to assert-fail wherever an implementation is missing
> rather than returning an API error under conditions not expected by the
> application.

Re-reading the spec, I am quite sure that libraries can’t be made of libraries.
From Section 5.6.5.1:

> The following options can be specified when creating a library of compiled 
> binaries.
>
> -create-library
> Create a library of compiled binaries specified in input_programs 
> argument to
> clLinkProgram

and earlier on, in Section 5.6.3 when defining clLinkProgram, it makes the
distinction between compiled binaries, libraries, and executables:

> input_programs is an array of program objects that are compiled binaries or
> libraries that are to be linked to create the program executable.

(both extracts come from the 1.2 specification)

> 
> >   // According to the CL 1.2 spec, when "all programs specified [..]
> >   // contain a compiled binary or library for the device [..] a 
> > link is
> >   // performed",
> > - if (all_of(has_binary, progs))
> > + else if (all_of(has_binary, progs))
> >  devs.push_back();
> >  
> >   // otherwise if "none of the programs contain a compiled binary or
> > @@ -290,7 +303,7 @@ clLinkProgram(cl_context d_ctx, cl_uint num_devs, const 
> > cl_device_id *d_devs,
> > auto prog = create(ctx);
> > auto devs = validate_link_devices(progs,
> >   (d_devs ? objs(d_devs, num_devs) :
> > -  ref_vector(ctx.devices(;
> > +  ref_vector(ctx.devices())), 
> > opts);
> >  
> > validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
> >  
> > -- 
> > 2.16.0



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

Re: [Mesa-dev] [PATCH 2/5] i965/miptree: Use cpu tiling/detiling when mapping

[Chris Wilson]

Quoting Scott D Phillips (2018-01-10 07:16:59)
> +/* Compute extent parameters for use with tiled_memcpy functions.
> + * xs are in units of bytes and ys are in units of strides. */
> +static inline void
> +tile_extents(struct intel_mipmap_tree *mt, struct intel_miptree_map *map,
> + unsigned int level, unsigned int slice, unsigned int *x1,
> + unsigned int *x2, unsigned int *y1, unsigned int *y2)
> +{
> +   unsigned int block_width, block_height, block_bytes;
> +   unsigned int x0_el, y0_el;
> +
> +   _mesa_get_format_block_size(mt->format, _width, _height);
> +   block_bytes = _mesa_get_format_bytes(mt->format);
> +
> +   assert(map->x % block_width == 0);
> +   assert(map->y % block_height == 0);
> +
> +   intel_miptree_get_image_offset(mt, level, slice, _el, _el);
> +   *x1 = (map->x / block_width + x0_el) * block_bytes;
> +   *y1 = map->y / block_height + y0_el;
> +   *x2 = *x1 + DIV_ROUND_UP(map->w, block_width) * block_bytes;
> +   *y2 = *y1 + DIV_ROUND_UP(map->h, block_height);
*x2 = (DIV_ROUND_UP(map->x + map->w, block_width) + x0_el) * block_bytes;
*y2 = DIV_ROUND_UP(map->y + map->h, block_height) + y0_el;

Otherwise you may underestimate the aligned block extents. Consider the
case where map->w == block_width, but map->x is misaligned. x1 is then
truncated to the start of the block, and x2 is moved to the end of that
block, but to the left of map->x + map->w.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] meson builds don't read dri options

[Kenneth Graunke]

On Tuesday, January 23, 2018 10:34:25 AM PST Dylan Baker wrote:
> There's a bug in our meson build, and I sent a patch. We need to join_dirs 
> with
> get_option('prefix'). I got a little confused because when you pass a relative
> directory to meson's `install` option it will autotmatically make it absolute,
> but when you pass it to a C define it doesn't.

sysconfdir isn't always a subdirectory of prefix though.

By default, sysconfdir is $prefix/etc (i.e. /usr/local/etc).  But
tho most common distro setting is prefix = /usr and sysconfdir = /etc.

So unless Meson makes sysconfdir "../etc" in that case, I don't think
joining prefix and sysconfdir will do what you want...?


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 v2 00/22] Introducing SPIR-V support to clover

[Karol Herbst]

On Tue, Jan 23, 2018 at 11:46 PM, Francisco Jerez  wrote:
> Pierre Moreau  writes:
>
>> On 2018-01-23 — 14:02, Francisco Jerez wrote:
>>> Karol Herbst  writes:
>>>
>>> > there seem to be some patches missing?
>>> >
>>> > On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau  
>>> > wrote:
>>> >> Hello,
>>> >>
>>> >> Here is the second version of my initial series for adding SPIR-V 
>>> >> support to
>>> >> clover, after the RFC back in May 2017.
>>> >>
>>> >> For recap, the focus of this series is to let clover accept SPIR-V 
>>> >> binaries
>>> >> through the cl_khr_il_program extension (from OpenCL 1.2 and on), as 
>>> >> well as
>>> >> through some core features (since OpenCL 2.1). Even if OpenCL 2.1 
>>> >> support in
>>> >> clover is some way off, there is another motivation for supporting 
>>> >> SPIR-V in
>>> >> clover, as multiple drivers are interested in adding OpenCL support by
>>> >> converting SPIR-V to NIR.
>>> >>
>>> >> Note: the series is based on master + Karol’s patch “clover: add 
>>> >> functions up
>>> >> to 2.2 to ICD dispatch table”.
>>> >>
>>> >>
>>> >> The various patches can be split in different categories:
>>> >>
>>> >> * Patches 1 through 7: some clover clean-up, adding and moving some
>>> >>   functionalities around to make the implementation easier in the rest 
>>> >> of the
>>> >>   series.
>>> >>
>>> >> * Patches 8 through 13: define SPIR-V as a new IR, add a new frontend to 
>>> >> clover
>>> >>   to deal with SPIR-V, and edit compile and link operations to handle 
>>> >> SPIR-V as
>>> >>   well.
>>> >>
>>> >> * Patches 14 through 19: implement cl_khr_il_program
>>> >>
>>> >> * Patches 20 through 22: implement OpenCL 2.1 support on top of
>>> >>   cl_khr_il_program
>>> >>
>>> >>
>>> >> Changes since the RFC
>>> >> -
>>> >>
>>> >> * Most SPIR-V utilities were dropped, and the remaining ones have been 
>>> >> moved to
>>> >>   the clover SPIR-V frontend rather than sitting in 
>>> >> src/gallium/auxiliary/spirv.
>>> >>
>>> >> * The SPIR-V linker has been completely dropped from this series and 
>>> >> instead
>>> >>   merge in SPIRV-Tools [1].
>>> >>
>>> >> * Since SPIRV-Tools now exports a pkgconfig .pc file, use it for 
>>> >> detecting the
>>> >>   library.
>>> >>
>>> >> * Integrate the series with Meson.
>>> >>
>>> >> * Use pipe_llvm_program_header to pass in the size of the SPIR-V module, 
>>> >> rather
>>> >>   than adding a new attribute to pipe_compute_state, as suggested by 
>>> >> Francisco
>>> >>   Jerez.
>>> >>
>>> >> * Check that the device supports the capabilities defined in the SPIR-V 
>>> >> binary.
>>> >>
>>> >> * Check that the platform/device supports the extensions used in the 
>>> >> SPIR-V
>>> >>   binary.
>>> >>
>>> >> * Fix the implementation responsible for filling up the symbols of the 
>>> >> clover
>>> >>   module based on the input SPIR-V binary.
>>> >>
>>> >> * No longer raw SPIR-V binaries through clCreateProgramWithBinary, but 
>>> >> instead
>>> >>   keep the current de-serialisation of the clover module, which may 
>>> >> contain a
>>> >>   SPIR-V binary.
>>> >>
>>> >> * Track whether a library was created with the --enable-link-options 
>>> >> flag or
>>> >>   not. This is currently not useful as the linker ignores most link 
>>> >> options,
>>> >>   but it will become useful when the linker handles those options.
>>> >>
>>> >> * Implement cl_khr_il_program.
>>> >>
>>> >> * Most of patches 1 through 8 (apart from patch 2).
>>> >>
>>> >>
>>> >> Discussions
>>> >> ---
>>> >>
>>> >> * Before, when linking different modules together, you knew that all 
>>> >> modules
>>> >>   would use the same IR, as all were created using 
>>> >> clCreateProgramWithSource,
>>> >>   therefore the linker could just call the linking function 
>>> >> corresponding to
>>> >>   the target’s preferred IR. But with the introduction of
>>> >>   clCreateProgramWithIL(KHR)?, we can now end up in a case where we try 
>>> >> to link
>>> >>   a module using NIR as IR (created through clCreateProgramWithSource, 
>>> >> assuming
>>> >>   that is the driver’s preferred IR), with another module using SPIR-V 
>>> >> as IR
>>> >>   (created through clCreateProgramWithIL). How do we handle such a case: 
>>> >> should
>>> >>   we translate the SPIR-V to NIR and use a NIR linker on them, or 
>>> >> convert NIR
>>> >>   to SPIR-V and use the SPIR-V linker? NIR and LLVM IR can be handled
>>> >>   relatively easily, but what about TGSI?
>>> >>
>>> >
>>> > I think we will never be able to convert all IRs into any other IR, so
>>> > that I would suggest to leave those IRs unconverted until they get
>>> > linked together and there the code can decide on a common IR for
>>> > linking. So if we get source code, we can parse it to llvm IR and
>>> > leave it like that until it gets linked. Converting back and forth
>>> > would require us to write all those conversion paths and I am 

Re: [Mesa-dev] [PATCH v2 12/24] anv/cmd_buffer: Add a mark_image_written helper

[Nanley Chery]

On Mon, Jan 22, 2018 at 05:25:31PM -0800, Jason Ekstrand wrote:
> On Mon, Jan 22, 2018 at 3:22 PM, Nanley Chery  wrote:
> 
> > On Fri, Jan 19, 2018 at 03:47:29PM -0800, Jason Ekstrand wrote:
> > > Currently, this helper does nothing but we call it every place where an
> > > image is written through the render pipeline.  This will allow us to
> > > properly mark the aux state so that we can handle resolves correctly.
> > > ---
> > >  src/intel/vulkan/anv_blorp.c   | 44 ++
> > +++-
> > >  src/intel/vulkan/anv_cmd_buffer.c  | 15 +
> > >  src/intel/vulkan/anv_genX.h|  8 +++
> > >  src/intel/vulkan/anv_private.h |  9 
> > >  src/intel/vulkan/genX_cmd_buffer.c | 44 ++
> > 
> > >  5 files changed, 119 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > > index e4e4135..05efc6d 100644
> > > --- a/src/intel/vulkan/anv_blorp.c
> > > +++ b/src/intel/vulkan/anv_blorp.c
> > > @@ -283,6 +283,10 @@ void anv_CmdCopyImage(
> > >  get_blorp_surf_for_anv_image(cmd_buffer->device,
> > >   dst_image, 1UL << aspect_bit,
> > >   ANV_AUX_USAGE_DEFAULT,
> > _surf);
> > > +anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image,
> > > +  1UL << aspect_bit,
> > > +  dst_surf.aux_usage,
> > dst_level,
> > > +  dst_base_layer,
> > layer_count);
> > >
> > >  for (unsigned i = 0; i < layer_count; i++) {
> > > blorp_copy(, _surf, src_level, src_base_layer
> > + i,
> > > @@ -298,6 +302,9 @@ void anv_CmdCopyImage(
> > >ANV_AUX_USAGE_DEFAULT, _surf);
> > >   get_blorp_surf_for_anv_image(cmd_buffer->device, dst_image,
> > dst_mask,
> > >ANV_AUX_USAGE_DEFAULT, _surf);
> > > + anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image,
> > dst_mask,
> > > +   dst_surf.aux_usage,
> > dst_level,
> > > +   dst_base_layer, layer_count);
> > >
> > >   for (unsigned i = 0; i < layer_count; i++) {
> > >  blorp_copy(, _surf, src_level, src_base_layer + i,
> > > @@ -386,6 +393,13 @@ copy_buffer_to_image(struct anv_cmd_buffer
> > *cmd_buffer,
> > >  buffer_row_pitch, buffer_format,
> > >  , _isl_surf);
> > >
> > > +  if ( == dst) {
> > > + anv_cmd_buffer_mark_image_written(cmd_buffer, anv_image,
> > > +   aspect, dst->surf.aux_usage,
> > > +   dst->level,
> > > +   dst->offset.z, extent.depth);
> > > +  }
> > > +
> > >for (unsigned z = 0; z < extent.depth; z++) {
> > >   blorp_copy(, >surf, src->level, src->offset.z,
> > >  >surf, dst->level, dst->offset.z,
> > > @@ -545,6 +559,12 @@ void anv_CmdBlitImage(
> > >bool flip_y = flip_coords(_y0, _y1, _y0, _y1);
> > >
> > >const unsigned num_layers = dst_end - dst_start;
> > > +  anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image,
> > > +dst_res->aspectMask,
> > > +dst.aux_usage,
> > > +dst_res->mipLevel,
> > > +dst_start, num_layers);
> > > +
> > >for (unsigned i = 0; i < num_layers; i++) {
> > >   unsigned dst_z = dst_start + i;
> > >   unsigned src_z = src_start + i * src_z_step;
> > > @@ -558,7 +578,6 @@ void anv_CmdBlitImage(
> > >  dst_x0, dst_y0, dst_x1, dst_y1,
> > >  gl_filter, flip_x, flip_y);
> > >}
> > > -
> >
> >   ^
> > Random line deletion? Not a big deal.
> >
> 
> Yup.  Rebase fail. Dropped.
> 
> 
> > > }
> > >
> > > blorp_batch_finish();
> > > @@ -818,6 +837,11 @@ void anv_CmdClearColorImage(
> > >  layer_count = anv_minify(image->extent.depth, level);
> > >   }
> > >
> > > + anv_cmd_buffer_mark_image_written(cmd_buffer, image,
> > > +   pRanges[r].aspectMask,
> > > +   surf.aux_usage, level,
> > > +   base_layer, layer_count);
> > > +
> > >   blorp_clear(, ,
> > >   src_format.isl_format, src_format.swizzle,
> > >   level, base_layer, layer_count,
> > > @@ -1215,6 +1239,13 @@ anv_cmd_buffer_clear_subpass(struct
> > anv_cmd_buffer *cmd_buffer)
> > >  

Re: [Mesa-dev] [PATCH v2 00/22] Introducing SPIR-V support to clover

[Francisco Jerez]

Pierre Moreau  writes:

> On 2018-01-23 — 14:02, Francisco Jerez wrote:
>> Karol Herbst  writes:
>> 
>> > there seem to be some patches missing?
>> >
>> > On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau  
>> > wrote:
>> >> Hello,
>> >>
>> >> Here is the second version of my initial series for adding SPIR-V support 
>> >> to
>> >> clover, after the RFC back in May 2017.
>> >>
>> >> For recap, the focus of this series is to let clover accept SPIR-V 
>> >> binaries
>> >> through the cl_khr_il_program extension (from OpenCL 1.2 and on), as well 
>> >> as
>> >> through some core features (since OpenCL 2.1). Even if OpenCL 2.1 support 
>> >> in
>> >> clover is some way off, there is another motivation for supporting SPIR-V 
>> >> in
>> >> clover, as multiple drivers are interested in adding OpenCL support by
>> >> converting SPIR-V to NIR.
>> >>
>> >> Note: the series is based on master + Karol’s patch “clover: add 
>> >> functions up
>> >> to 2.2 to ICD dispatch table”.
>> >>
>> >>
>> >> The various patches can be split in different categories:
>> >>
>> >> * Patches 1 through 7: some clover clean-up, adding and moving some
>> >>   functionalities around to make the implementation easier in the rest of 
>> >> the
>> >>   series.
>> >>
>> >> * Patches 8 through 13: define SPIR-V as a new IR, add a new frontend to 
>> >> clover
>> >>   to deal with SPIR-V, and edit compile and link operations to handle 
>> >> SPIR-V as
>> >>   well.
>> >>
>> >> * Patches 14 through 19: implement cl_khr_il_program
>> >>
>> >> * Patches 20 through 22: implement OpenCL 2.1 support on top of
>> >>   cl_khr_il_program
>> >>
>> >>
>> >> Changes since the RFC
>> >> -
>> >>
>> >> * Most SPIR-V utilities were dropped, and the remaining ones have been 
>> >> moved to
>> >>   the clover SPIR-V frontend rather than sitting in 
>> >> src/gallium/auxiliary/spirv.
>> >>
>> >> * The SPIR-V linker has been completely dropped from this series and 
>> >> instead
>> >>   merge in SPIRV-Tools [1].
>> >>
>> >> * Since SPIRV-Tools now exports a pkgconfig .pc file, use it for 
>> >> detecting the
>> >>   library.
>> >>
>> >> * Integrate the series with Meson.
>> >>
>> >> * Use pipe_llvm_program_header to pass in the size of the SPIR-V module, 
>> >> rather
>> >>   than adding a new attribute to pipe_compute_state, as suggested by 
>> >> Francisco
>> >>   Jerez.
>> >>
>> >> * Check that the device supports the capabilities defined in the SPIR-V 
>> >> binary.
>> >>
>> >> * Check that the platform/device supports the extensions used in the 
>> >> SPIR-V
>> >>   binary.
>> >>
>> >> * Fix the implementation responsible for filling up the symbols of the 
>> >> clover
>> >>   module based on the input SPIR-V binary.
>> >>
>> >> * No longer raw SPIR-V binaries through clCreateProgramWithBinary, but 
>> >> instead
>> >>   keep the current de-serialisation of the clover module, which may 
>> >> contain a
>> >>   SPIR-V binary.
>> >>
>> >> * Track whether a library was created with the --enable-link-options flag 
>> >> or
>> >>   not. This is currently not useful as the linker ignores most link 
>> >> options,
>> >>   but it will become useful when the linker handles those options.
>> >>
>> >> * Implement cl_khr_il_program.
>> >>
>> >> * Most of patches 1 through 8 (apart from patch 2).
>> >>
>> >>
>> >> Discussions
>> >> ---
>> >>
>> >> * Before, when linking different modules together, you knew that all 
>> >> modules
>> >>   would use the same IR, as all were created using 
>> >> clCreateProgramWithSource,
>> >>   therefore the linker could just call the linking function corresponding 
>> >> to
>> >>   the target’s preferred IR. But with the introduction of
>> >>   clCreateProgramWithIL(KHR)?, we can now end up in a case where we try 
>> >> to link
>> >>   a module using NIR as IR (created through clCreateProgramWithSource, 
>> >> assuming
>> >>   that is the driver’s preferred IR), with another module using SPIR-V as 
>> >> IR
>> >>   (created through clCreateProgramWithIL). How do we handle such a case: 
>> >> should
>> >>   we translate the SPIR-V to NIR and use a NIR linker on them, or convert 
>> >> NIR
>> >>   to SPIR-V and use the SPIR-V linker? NIR and LLVM IR can be handled
>> >>   relatively easily, but what about TGSI?
>> >>
>> >
>> > I think we will never be able to convert all IRs into any other IR, so
>> > that I would suggest to leave those IRs unconverted until they get
>> > linked together and there the code can decide on a common IR for
>> > linking. So if we get source code, we can parse it to llvm IR and
>> > leave it like that until it gets linked. Converting back and forth
>> > would require us to write all those conversion paths and I am assume
>> > this wouldn't be worth the trouble.
>> >
>> 
>> I think it would be more straightforward to compile source programs into
>> SPIRV if the driver supports it (or if it supports any other IR that
>> 

[Mesa-dev] [PATCH] radv: fix sample_mask_in loading. (v3)

[Dave Airlie]

From: Dave Airlie 

This is ported from radeonsi and fixes:
dEQP-VK.pipeline.multisample_shader_builtin.sample_mask.bit_*

v2: don't call this path for radeonsi, it does it in the epilog.
use the radeonsi code path.
v3: handle NULL pCreateInfo->pMultisampleState properly (Samuel)

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 29 -
 src/amd/common/ac_nir_to_llvm.h |  2 ++
 src/amd/vulkan/radv_pipeline.c  | 29 -
 src/amd/vulkan/radv_private.h   |  2 ++
 4 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index cc3af77..8ae8650 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4049,6 +4049,30 @@ static LLVMValueRef load_sample_pos(struct 
ac_nir_context *ctx)
return ac_build_gather_values(>ac, values, 2);
 }
 
+static LLVMValueRef load_sample_mask_in(struct ac_nir_context *ctx)
+{
+   uint8_t log2_ps_iter_samples = 
ctx->nctx->shader_info->info.ps.force_persample ? 
ctx->nctx->options->key.fs.log2_num_samples : 
ctx->nctx->options->key.fs.log2_ps_iter_samples;
+
+   /* The bit pattern matches that used by fixed function fragment
+* processing. */
+   static const uint16_t ps_iter_masks[] = {
+   0x, /* not used */
+   0x,
+   0x,
+   0x0101,
+   0x0001,
+   };
+   assert(log2_ps_iter_samples < ARRAY_SIZE(ps_iter_masks));
+
+   uint32_t ps_iter_mask = ps_iter_masks[log2_ps_iter_samples];
+
+   LLVMValueRef result, sample_id;
+   sample_id = unpack_param(>ac, ctx->abi->ancillary, 8, 4);
+   sample_id = LLVMBuildShl(ctx->ac.builder, LLVMConstInt(ctx->ac.i32, 
ps_iter_mask, false), sample_id, "");
+   result = LLVMBuildAnd(ctx->ac.builder, sample_id, 
ctx->abi->sample_coverage, "");
+   return result;
+}
+
 static LLVMValueRef visit_interp(struct nir_to_llvm_context *ctx,
 const nir_intrinsic_instr *instr)
 {
@@ -4353,7 +4377,10 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
result = load_sample_pos(ctx);
break;
case nir_intrinsic_load_sample_mask_in:
-   result = ctx->abi->sample_coverage;
+   if (ctx->nctx)
+   result = load_sample_mask_in(ctx);
+   else
+   result = ctx->abi->sample_coverage;
break;
case nir_intrinsic_load_frag_coord: {
LLVMValueRef values[4] = {
diff --git a/src/amd/common/ac_nir_to_llvm.h b/src/amd/common/ac_nir_to_llvm.h
index 62ea38b..1656289 100644
--- a/src/amd/common/ac_nir_to_llvm.h
+++ b/src/amd/common/ac_nir_to_llvm.h
@@ -60,6 +60,8 @@ struct ac_tcs_variant_key {
 
 struct ac_fs_variant_key {
uint32_t col_format;
+   uint8_t log2_ps_iter_samples;
+   uint8_t log2_num_samples;
uint32_t is_int8;
uint32_t is_int10;
uint32_t multisample : 1;
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index a49fe05..416b80f 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -798,6 +798,18 @@ radv_pipeline_init_raster_state(struct radv_pipeline 
*pipeline,
 
 }
 
+static uint8_t radv_pipeline_get_ps_iter_samples(const 
VkPipelineMultisampleStateCreateInfo *vkms)
+{
+   uint32_t num_samples = vkms->rasterizationSamples;
+   uint32_t ps_iter_samples = num_samples;
+
+   if (vkms->sampleShadingEnable) {
+   ps_iter_samples = ceil(vkms->minSampleShading * num_samples);
+   ps_iter_samples = util_next_power_of_two(ps_iter_samples);
+   }
+   return ps_iter_samples;
+}
+
 static void
 radv_pipeline_init_multisample_state(struct radv_pipeline *pipeline,
 const VkGraphicsPipelineCreateInfo 
*pCreateInfo)
@@ -813,9 +825,9 @@ radv_pipeline_init_multisample_state(struct radv_pipeline 
*pipeline,
else
ms->num_samples = 1;
 
-   if (vkms && vkms->sampleShadingEnable) {
-   ps_iter_samples = ceil(vkms->minSampleShading * 
ms->num_samples);
-   } else if 
(pipeline->shaders[MESA_SHADER_FRAGMENT]->info.info.ps.force_persample) {
+   if (vkms)
+   ps_iter_samples = radv_pipeline_get_ps_iter_samples(vkms);
+   if (vkms && !vkms->sampleShadingEnable && 
pipeline->shaders[MESA_SHADER_FRAGMENT]->info.info.ps.force_persample) {
ps_iter_samples = ms->num_samples;
}
 
@@ -838,7 +850,7 @@ radv_pipeline_init_multisample_state(struct radv_pipeline 
*pipeline,
 
if (ms->num_samples > 1) {
unsigned log_samples = util_logbase2(ms->num_samples);
-   unsigned log_ps_iter_samples = 
util_logbase2(util_next_power_of_two(ps_iter_samples));
+   unsigned 

Re: [Mesa-dev] [PATCH v2 00/22] Introducing SPIR-V support to clover

[Pierre Moreau]

On 2018-01-23 — 14:02, Francisco Jerez wrote:
> Karol Herbst  writes:
> 
> > there seem to be some patches missing?
> >
> > On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau  
> > wrote:
> >> Hello,
> >>
> >> Here is the second version of my initial series for adding SPIR-V support 
> >> to
> >> clover, after the RFC back in May 2017.
> >>
> >> For recap, the focus of this series is to let clover accept SPIR-V binaries
> >> through the cl_khr_il_program extension (from OpenCL 1.2 and on), as well 
> >> as
> >> through some core features (since OpenCL 2.1). Even if OpenCL 2.1 support 
> >> in
> >> clover is some way off, there is another motivation for supporting SPIR-V 
> >> in
> >> clover, as multiple drivers are interested in adding OpenCL support by
> >> converting SPIR-V to NIR.
> >>
> >> Note: the series is based on master + Karol’s patch “clover: add functions 
> >> up
> >> to 2.2 to ICD dispatch table”.
> >>
> >>
> >> The various patches can be split in different categories:
> >>
> >> * Patches 1 through 7: some clover clean-up, adding and moving some
> >>   functionalities around to make the implementation easier in the rest of 
> >> the
> >>   series.
> >>
> >> * Patches 8 through 13: define SPIR-V as a new IR, add a new frontend to 
> >> clover
> >>   to deal with SPIR-V, and edit compile and link operations to handle 
> >> SPIR-V as
> >>   well.
> >>
> >> * Patches 14 through 19: implement cl_khr_il_program
> >>
> >> * Patches 20 through 22: implement OpenCL 2.1 support on top of
> >>   cl_khr_il_program
> >>
> >>
> >> Changes since the RFC
> >> -
> >>
> >> * Most SPIR-V utilities were dropped, and the remaining ones have been 
> >> moved to
> >>   the clover SPIR-V frontend rather than sitting in 
> >> src/gallium/auxiliary/spirv.
> >>
> >> * The SPIR-V linker has been completely dropped from this series and 
> >> instead
> >>   merge in SPIRV-Tools [1].
> >>
> >> * Since SPIRV-Tools now exports a pkgconfig .pc file, use it for detecting 
> >> the
> >>   library.
> >>
> >> * Integrate the series with Meson.
> >>
> >> * Use pipe_llvm_program_header to pass in the size of the SPIR-V module, 
> >> rather
> >>   than adding a new attribute to pipe_compute_state, as suggested by 
> >> Francisco
> >>   Jerez.
> >>
> >> * Check that the device supports the capabilities defined in the SPIR-V 
> >> binary.
> >>
> >> * Check that the platform/device supports the extensions used in the SPIR-V
> >>   binary.
> >>
> >> * Fix the implementation responsible for filling up the symbols of the 
> >> clover
> >>   module based on the input SPIR-V binary.
> >>
> >> * No longer raw SPIR-V binaries through clCreateProgramWithBinary, but 
> >> instead
> >>   keep the current de-serialisation of the clover module, which may 
> >> contain a
> >>   SPIR-V binary.
> >>
> >> * Track whether a library was created with the --enable-link-options flag 
> >> or
> >>   not. This is currently not useful as the linker ignores most link 
> >> options,
> >>   but it will become useful when the linker handles those options.
> >>
> >> * Implement cl_khr_il_program.
> >>
> >> * Most of patches 1 through 8 (apart from patch 2).
> >>
> >>
> >> Discussions
> >> ---
> >>
> >> * Before, when linking different modules together, you knew that all 
> >> modules
> >>   would use the same IR, as all were created using 
> >> clCreateProgramWithSource,
> >>   therefore the linker could just call the linking function corresponding 
> >> to
> >>   the target’s preferred IR. But with the introduction of
> >>   clCreateProgramWithIL(KHR)?, we can now end up in a case where we try to 
> >> link
> >>   a module using NIR as IR (created through clCreateProgramWithSource, 
> >> assuming
> >>   that is the driver’s preferred IR), with another module using SPIR-V as 
> >> IR
> >>   (created through clCreateProgramWithIL). How do we handle such a case: 
> >> should
> >>   we translate the SPIR-V to NIR and use a NIR linker on them, or convert 
> >> NIR
> >>   to SPIR-V and use the SPIR-V linker? NIR and LLVM IR can be handled
> >>   relatively easily, but what about TGSI?
> >>
> >
> > I think we will never be able to convert all IRs into any other IR, so
> > that I would suggest to leave those IRs unconverted until they get
> > linked together and there the code can decide on a common IR for
> > linking. So if we get source code, we can parse it to llvm IR and
> > leave it like that until it gets linked. Converting back and forth
> > would require us to write all those conversion paths and I am assume
> > this wouldn't be worth the trouble.
> >
> 
> I think it would be more straightforward to compile source programs into
> SPIRV if the driver supports it (or if it supports any other IR that
> could possibly be translated from SPIRV after link time, e.g. NIR or
> maybe even TGSI).  That means that there is a single canonical IR for
> each CL device and we don't need to deal with linking 

[Mesa-dev] [PATCH 0.5/5] i965/tiled_memcpy: linear_to_ytiled a cache line at a time

[Scott D Phillips]

TileY's low 6 address bits are: v1 v0 u3 u2 u1 u0
Thus a cache line in the tiled surface is composed of a 2d area of
16x4 bytes of the linear surface.

Add a special case where the area being copied is 4-line aligned
and a multiple of 4-lines so that entire cache lines will be
written at a time.

On Apollolake, this increases tiling throughput to wc maps by
83.1412% +/- 1.81446%
---
 src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 63 ++
 1 file changed, 55 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c 
b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
index e2b7b3496d..e45f3fec1e 100644
--- a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
+++ b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
@@ -287,8 +287,8 @@ linear_to_xtiled(uint32_t x0, uint32_t x1, uint32_t x2, 
uint32_t x3,
  */
 static inline void
 linear_to_ytiled(uint32_t x0, uint32_t x1, uint32_t x2, uint32_t x3,
- uint32_t y0, uint32_t y1,
- char *dst, const char *src,
+ uint32_t y0, uint32_t y3,
+ char *dst, const char *src0,
  int32_t src_pitch,
  uint32_t swizzle_bit,
  mem_copy_fn mem_copy,
@@ -306,6 +306,9 @@ linear_to_ytiled(uint32_t x0, uint32_t x1, uint32_t x2, 
uint32_t x3,
const uint32_t column_width = ytile_span;
const uint32_t bytes_per_column = column_width * ytile_height;
 
+   uint32_t y1 = ALIGN_UP(y0, 4);
+   uint32_t y2 = ALIGN_DOWN(y3, 4);
+
uint32_t xo0 = (x0 % ytile_span) + (x0 / ytile_span) * bytes_per_column;
uint32_t xo1 = (x1 % ytile_span) + (x1 / ytile_span) * bytes_per_column;
 
@@ -319,26 +322,70 @@ linear_to_ytiled(uint32_t x0, uint32_t x1, uint32_t x2, 
uint32_t x3,
 
uint32_t x, yo;
 
-   src += (ptrdiff_t)y0 * src_pitch;
+   const char *src = src0 + (ptrdiff_t)y1 * src_pitch;
 
-   for (yo = y0 * column_width; yo < y1 * column_width; yo += column_width) {
+   for (yo = y1 * column_width; yo < y2 * column_width; yo += 4 * 
column_width) {
   uint32_t xo = xo1;
   uint32_t swizzle = swizzle1;
 
-  mem_copy(dst + ((xo0 + yo) ^ swizzle0), src + x0, x1 - x0);
+  if (x0 != x1) {
+ mem_copy(dst + ((xo0 + yo + 0 * column_width) ^ swizzle0), src + x0 + 
0 * src_pitch, x1 - x0);
+ mem_copy(dst + ((xo0 + yo + 1 * column_width) ^ swizzle0), src + x0 + 
1 * src_pitch, x1 - x0);
+ mem_copy(dst + ((xo0 + yo + 2 * column_width) ^ swizzle0), src + x0 + 
2 * src_pitch, x1 - x0);
+ mem_copy(dst + ((xo0 + yo + 3 * column_width) ^ swizzle0), src + x0 + 
3 * src_pitch, x1 - x0);
+  }
 
   /* Step by spans/columns.  As it happens, the swizzle bit flips
* at each step so we don't need to calculate it explicitly.
*/
   for (x = x1; x < x2; x += ytile_span) {
- mem_copy_align16(dst + ((xo + yo) ^ swizzle), src + x, ytile_span);
+ mem_copy_align16(dst + ((xo + yo + 0 * column_width) ^ swizzle), src 
+ x + 0 * src_pitch, ytile_span);
+ mem_copy_align16(dst + ((xo + yo + 1 * column_width) ^ swizzle), src 
+ x + 1 * src_pitch, ytile_span);
+ mem_copy_align16(dst + ((xo + yo + 2 * column_width) ^ swizzle), src 
+ x + 2 * src_pitch, ytile_span);
+ mem_copy_align16(dst + ((xo + yo + 3 * column_width) ^ swizzle), src 
+ x + 3 * src_pitch, ytile_span);
  xo += bytes_per_column;
  swizzle ^= swizzle_bit;
   }
 
-  mem_copy_align16(dst + ((xo + yo) ^ swizzle), src + x2, x3 - x2);
+  if (x2 != x3) {
+ mem_copy_align16(dst + ((xo + yo + 0 * column_width) ^ swizzle), src 
+ x2 + 0 * src_pitch, x3 - x2);
+ mem_copy_align16(dst + ((xo + yo + 1 * column_width) ^ swizzle), src 
+ x2 + 1 * src_pitch, x3 - x2);
+ mem_copy_align16(dst + ((xo + yo + 2 * column_width) ^ swizzle), src 
+ x2 + 2 * src_pitch, x3 - x2);
+ mem_copy_align16(dst + ((xo + yo + 3 * column_width) ^ swizzle), src 
+ x2 + 3 * src_pitch, x3 - x2);
+  }
 
-  src += src_pitch;
+  src += 4 * src_pitch;
+   }
+
+   if (y0 != y1 || y2 != y3) {
+  src = src0 + (ptrdiff_t)y0 * src_pitch;
+
+  for (yo = y0 * column_width; yo < y3 * column_width; yo += column_width) 
{
+ uint32_t xo = xo1;
+ uint32_t swizzle = swizzle1;
+
+ if (yo >= y1 * column_width && yo < y2 * column_width) {
+if (y2 == y3)
+   break;
+yo = y2 * column_width;
+src = src0 + y2 * src_pitch;
+ }
+
+ mem_copy(dst + ((xo0 + yo) ^ swizzle0), src + x0, x1 - x0);
+
+ /* Step by spans/columns.  As it happens, the swizzle bit flips
+  * at each step so we don't need to calculate it explicitly.
+  */
+ for (x = x1; x < x2; x += ytile_span) {
+mem_copy_align16(dst + ((xo + yo) ^ swizzle), src + x, ytile_span);
+xo += bytes_per_column;
+swizzle ^= swizzle_bit;
+ }
+
+ 

Re: [Mesa-dev] [PATCH v2 13/22] clover: Handle the case when linking SPIR-V binaries together

[Pierre Moreau]

On 2018-01-23 — 14:08, Francisco Jerez wrote:
> Pierre Moreau  writes:
> 
> > Signed-off-by: Pierre Moreau 
> > ---
> >  src/gallium/state_trackers/clover/core/program.cpp | 22 
> > +-
> >  1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
> > b/src/gallium/state_trackers/clover/core/program.cpp
> > index 15d559cd93..976213ef95 100644
> > --- a/src/gallium/state_trackers/clover/core/program.cpp
> > +++ b/src/gallium/state_trackers/clover/core/program.cpp
> > @@ -22,6 +22,7 @@
> >  
> >  #include "core/program.hpp"
> >  #include "llvm/invocation.hpp"
> > +#include "spirv/invocation.hpp"
> >  #include "tgsi/invocation.hpp"
> >  
> >  using namespace clover;
> > @@ -80,11 +81,22 @@ program::link(const ref_vector , const 
> > std::string ,
> >std::string log = _builds[].log;
> >  
> >try {
> > - const module m = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
> > -   tgsi::link_program(ms) :
> > -   llvm::link_program(ms, dev.ir_format(),
> > -  dev.ir_target(), opts, log));
> > - _builds[] = { m, opts, log };
> > + switch (dev.ir_format()) {
> > + case PIPE_SHADER_IR_TGSI:
> > +_builds[] = { tgsi::link_program(ms), opts, log };
> > +break;
> > + case PIPE_SHADER_IR_LLVM:
> > + case PIPE_SHADER_IR_NATIVE:
> > + case PIPE_SHADER_IR_NIR:
> > +_builds[] = { llvm::link_program(ms, dev.ir_format(),
> > + dev.ir_target(), opts, 
> > log),
> > +  opts, log };
> > +break;
> > + case PIPE_SHADER_IR_SPIRV:
> > +_builds[] = { clover::spirv::link_program(ms, opts, log), 
> > opts,
> > +  log };
> > +break;
> > + }
> 
> I'd prefer to implement this in a separate "module link_program(ms, dev,
> opts, log)" demux-function with the switch-case statement that calls the
> right linking function based on the IR of the program (and possibly
> converts it into the drivers's preferred IR in the future).  Then just do
> the following in this block:
> 
> | _builds[] = { link_program(ms, dev, opts, log), opts, log };

This sounds like a good idea, as it will make it cleaner and easier to also
handle translating to other IRs.

> 
> >} catch (...) {
> >   _builds[] = { module(), opts, log };
> >   throw;
> > -- 
> > 2.16.0



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

Re: [Mesa-dev] [PATCH v2 10/22] clover/spirv: Import spirv.hpp11 version 1.0 (rev 12)

[Francisco Jerez]

Pierre Moreau  writes:

> On 2018-01-23 — 14:06, Francisco Jerez wrote:
>> Pierre Moreau  writes:
>> 
>> > Signed-off-by: Pierre Moreau 
>> > ---
>> >  .../state_trackers/clover/spirv/spirv.hpp11| 997 
>> > +
>> >  1 file changed, 997 insertions(+)
>> >  create mode 100644 src/gallium/state_trackers/clover/spirv/spirv.hpp11
>> 
>> Can you import this with an hpp extension please?  All other .hpp files
>> under clover/ are also C++11, no need to confuse text editors.  With
>> that fixed:
>
> I kept the original ending from SPIRV-Headers, but they need to differentiate
> it from the other C++ header which does not use C++11 features. I could drop
> it, but I am a little concerned that someone might think it would be the
> spirv.hpp file from SPIRV-Headers, which it isn’t.
> If you think this is not an issue, I will drop it.
>

I doubt that will cause any issues, it's just a private header in the
clover/spirv module.

>> 
>> Acked-by: Francisco Jerez 
>> 
>> >
>> > diff --git a/src/gallium/state_trackers/clover/spirv/spirv.hpp11 
>> > b/src/gallium/state_trackers/clover/spirv/spirv.hpp11
>> > new file mode 100644
>> > index 00..792eeb1aa0
>> > --- /dev/null
>> > +++ b/src/gallium/state_trackers/clover/spirv/spirv.hpp11
>> > @@ -0,0 +1,997 @@
>> > +// Copyright (c) 2014-2017 The Khronos Group Inc.
>> > +// 
>> > +// Permission is hereby granted, free of charge, to any person obtaining 
>> > a copy
>> > +// of this software and/or associated documentation files (the 
>> > "Materials"),
>> > +// to deal in the Materials without restriction, including without 
>> > limitation
>> > +// the rights to use, copy, modify, merge, publish, distribute, 
>> > sublicense,
>> > +// and/or sell copies of the Materials, and to permit persons to whom the
>> > +// Materials are furnished to do so, subject to the following conditions:
>> > +// 
>> > +// The above copyright notice and this permission notice shall be 
>> > included in
>> > +// all copies or substantial portions of the Materials.
>> > +// 
>> > +// MODIFICATIONS TO THIS FILE MAY MEAN IT NO LONGER ACCURATELY REFLECTS 
>> > KHRONOS
>> > +// STANDARDS. THE UNMODIFIED, NORMATIVE VERSIONS OF KHRONOS 
>> > SPECIFICATIONS AND
>> > +// HEADER INFORMATION ARE LOCATED AT https://www.khronos.org/registry/ 
>> > +// 
>> > +// THE MATERIALS ARE 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 MATERIALS OR THE USE OR OTHER 
>> > DEALINGS
>> > +// IN THE MATERIALS.
>> > +
>> > +// This header is automatically generated by the same tool that creates
>> > +// the Binary Section of the SPIR-V specification.
>> > +
>> > +// Enumeration tokens for SPIR-V, in various styles:
>> > +//   C, C++, C++11, JSON, Lua, Python
>> > +// 
>> > +// - C will have tokens with a "Spv" prefix, e.g.: SpvSourceLanguageGLSL
>> > +// - C++ will have tokens in the "spv" name space, e.g.: 
>> > spv::SourceLanguageGLSL
>> > +// - C++11 will use enum classes in the spv namespace, e.g.: 
>> > spv::SourceLanguage::GLSL
>> > +// - Lua will use tables, e.g.: spv.SourceLanguage.GLSL
>> > +// - Python will use dictionaries, e.g.: spv['SourceLanguage']['GLSL']
>> > +// 
>> > +// Some tokens act like mask values, which can be OR'd together,
>> > +// while others are mutually exclusive.  The mask-like ones have
>> > +// "Mask" in their name, and a parallel enum that has the shift
>> > +// amount (1 << x) for each corresponding enumerant.
>> > +
>> > +#ifndef spirv_HPP
>> > +#define spirv_HPP
>> > +
>> > +namespace spv {
>> > +
>> > +typedef unsigned int Id;
>> > +
>> > +#define SPV_VERSION 0x1
>> > +#define SPV_REVISION 12
>> > +
>> > +static const unsigned int MagicNumber = 0x07230203;
>> > +static const unsigned int Version = 0x0001;
>> > +static const unsigned int Revision = 12;
>> > +static const unsigned int OpCodeMask = 0x;
>> > +static const unsigned int WordCountShift = 16;
>> > +
>> > +enum class SourceLanguage : unsigned {
>> > +Unknown = 0,
>> > +ESSL = 1,
>> > +GLSL = 2,
>> > +OpenCL_C = 3,
>> > +OpenCL_CPP = 4,
>> > +HLSL = 5,
>> > +Max = 0x7fff,
>> > +};
>> > +
>> > +enum class ExecutionModel : unsigned {
>> > +Vertex = 0,
>> > +TessellationControl = 1,
>> > +TessellationEvaluation = 2,
>> > +Geometry = 3,
>> > +Fragment = 4,
>> > +GLCompute = 5,
>> > +Kernel = 6,
>> > +Max = 0x7fff,
>> > +};
>> > +
>> > +enum class AddressingModel : unsigned {
>> > +Logical = 0,
>> > +Physical32 = 1,
>> > +

Re: [Mesa-dev] [PATCH v2 15/22] include/CL: Add cl_khr_il_program

[Pierre Moreau]

On 2018-01-23 — 14:08, Francisco Jerez wrote:
> Pierre Moreau  writes:
> 
> > Signed-off-by: Pierre Moreau 
> 
> Same comment as Karol, let's update the header instead.

I will do that. Though that won’t impact this patch, as cl_khr_il_program is
not part of the official OpenCL headers. I have sent a pull request to their
repo, but have yet to hear back from someone with merge rights.

> 
> > ---
> >  include/CL/cl_ext.h | 34 ++
> >  1 file changed, 34 insertions(+)
> >
> > diff --git a/include/CL/cl_ext.h b/include/CL/cl_ext.h
> > index 710bea8837..2e4845d27d 100644
> > --- a/include/CL/cl_ext.h
> > +++ b/include/CL/cl_ext.h
> > @@ -308,6 +308,40 @@ typedef struct _cl_mem_ion_host_ptr
> >  
> >  #endif /* CL_VERSION_1_1 */
> >  
> > +
> > +/***
> > + * cl_khr_il_program extension *
> > + ***/
> > +
> > +#ifndef cl_khr_il_program
> > +#define cl_khr_il_program 1
> > +
> > +/* New property to clGetDeviceInfo for retrieving supported intermediate
> > + * languages
> > + */
> > +#define CL_DEVICE_IL_VERSION_KHR0x105B
> > +
> > +/* New property to clGetProgramInfo for retrieving for retrieving the IL 
> > of a
> > + * program
> > + */
> > +#define CL_PROGRAM_IL_KHR   0x1169
> > +
> > +extern CL_API_ENTRY cl_program
> > +  CL_API_CALL clCreateProgramWithILKHR(
> > +  cl_context /* context */,
> > +  const void * /* il */,
> > +  size_t /* length */,
> > +  cl_int * /* errcode_ret */) CL_EXT_SUFFIX__VERSION_1_2;
> > +
> > +typedef CL_API_ENTRY cl_program
> > +  (CL_API_CALL *clCreateProgramWithILKHR_fn)(
> > +  cl_context /* context */,
> > +  const void * /* il */,
> > +  size_t /* length */,
> > +  cl_int * /* errcode_ret */) CL_EXT_SUFFIX__VERSION_1_2;
> > +
> > +#endif /* cl_khr_il_program */
> > +
> >  #ifdef __cplusplus
> >  }
> >  #endif
> > -- 
> > 2.16.0



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

Re: [Mesa-dev] [PATCH v2 18/22] clover/api: Implement CL_DEVICE_IL_VERSION_KHR

[Francisco Jerez]

Pierre Moreau  writes:

> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/api/device.cpp | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
> b/src/gallium/state_trackers/clover/api/device.cpp
> index 4e274c5005..6bede21ca4 100644
> --- a/src/gallium/state_trackers/clover/api/device.cpp
> +++ b/src/gallium/state_trackers/clover/api/device.cpp
> @@ -333,6 +333,11 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>buf.as_string() = dev.supported_extensions();
>break;
>  
> +   case CL_DEVICE_IL_VERSION_KHR:

This should probably just throw CL_INVALID_VALUE if PIPE_SHADER_IR_SPIRV
is unsupported.

> +  buf.as_string() =
> + std::string(dev.supports_ir(PIPE_SHADER_IR_SPIRV) ? "SPIR-V_1.0" : 
> "");
> +  break;
> +
> case CL_DEVICE_PLATFORM:
>buf.as_scalar() = desc(dev.platform);
>break;
> -- 
> 2.16.0


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

Re: [Mesa-dev] ***SPAM*** [PATCH v2 16/22] clover: Implement clCreateProgramWithILKHR

[Francisco Jerez]

Pierre Moreau  writes:

> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/api/dispatch.hpp |  4 ++
>  src/gallium/state_trackers/clover/api/program.cpp  | 29 -
>  src/gallium/state_trackers/clover/core/program.cpp | 68 
> +-
>  src/gallium/state_trackers/clover/core/program.hpp | 14 +
>  4 files changed, 110 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp 
> b/src/gallium/state_trackers/clover/api/dispatch.hpp
> index 0910e19422..21bd379fe6 100644
> --- a/src/gallium/state_trackers/clover/api/dispatch.hpp
> +++ b/src/gallium/state_trackers/clover/api/dispatch.hpp
> @@ -900,6 +900,10 @@ namespace clover {
> cl_int
> IcdGetPlatformIDsKHR(cl_uint num_entries, cl_platform_id *rd_platforms,
>  cl_uint *rnum_platforms);
> +
> +   cl_program
> +   CreateProgramWithILKHR(cl_context d_ctx, const void *il,
> +  const size_t length, cl_int *r_errcode);

Make the the length argument non-const to match the spec's type
signature.

>  }
>  
>  #endif
> diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
> b/src/gallium/state_trackers/clover/api/program.cpp
> index 6ec87ad128..ed3b679c7c 100644
> --- a/src/gallium/state_trackers/clover/api/program.cpp
> +++ b/src/gallium/state_trackers/clover/api/program.cpp
> @@ -22,6 +22,7 @@
>  
>  #include "api/util.hpp"
>  #include "core/program.hpp"
> +#include "spirv/invocation.hpp"
>  #include "util/u_debug.h"
>  
>  #include 
> @@ -128,6 +129,30 @@ clCreateProgramWithBinary(cl_context d_ctx, cl_uint n,
> return NULL;
>  }
>  
> +cl_program
> +clover::CreateProgramWithILKHR(cl_context d_ctx, const void *il,
> +   const size_t length, cl_int *r_errcode) try {
> +   auto  = obj(d_ctx);
> +
> +   if (!il || !length)
> +  throw error(CL_INVALID_VALUE);
> +
> +   uint32_t type = UINT32_MAX;

Since you're using pipe_shader_ir enumerants to represent the IL format
it would be a good idea to declare the IL type variables as such here
and below.

> +   if (spirv::is_binary_spirv(reinterpret_cast(il)))
> +  type = PIPE_SHADER_IR_SPIRV;
> +
> +   if (type == UINT32_MAX)
> +  throw error(CL_INVALID_VALUE);
> +
> +   // initialize a program object with it.

Capitalize the comment.

> +   ret_error(r_errcode, CL_SUCCESS);
> +   return new program(ctx, il, length, type);
> +
> +} catch (error ) {
> +   ret_error(r_errcode, e);
> +   return NULL;
> +}
> +
>  CLOVER_API cl_program
>  clCreateProgramWithBuiltInKernels(cl_context d_ctx, cl_uint n,
>const cl_device_id *d_devs,
> @@ -183,7 +208,7 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
>  
> validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
>  
> -   if (prog.has_source) {
> +   if (prog.has_source || prog.has_il) {
>prog.compile(devs, opts);
>prog.link(devs, opts, { prog });
> } else if (any_of([&](const device ){
> @@ -221,7 +246,7 @@ clCompileProgram(cl_program d_prog, cl_uint num_devs,
> if (bool(num_headers) != bool(header_names))
>throw error(CL_INVALID_VALUE);
>  
> -   if (!prog.has_source)
> +   if (!prog.has_source && !prog.has_il)
>throw error(CL_INVALID_OPERATION);
>  
> for_each([&](const char *name, const program ) {
> diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
> b/src/gallium/state_trackers/clover/core/program.cpp
> index 976213ef95..b9ba38d4e6 100644
> --- a/src/gallium/state_trackers/clover/core/program.cpp
> +++ b/src/gallium/state_trackers/clover/core/program.cpp
> @@ -24,24 +24,51 @@
>  #include "llvm/invocation.hpp"
>  #include "spirv/invocation.hpp"
>  #include "tgsi/invocation.hpp"
> +#include "spirv/invocation.hpp"
> +
> +#include 
>  
>  using namespace clover;
>  
>  program::program(clover::context , const std::string ) :
> -   has_source(true), context(ctx), _source(source), _kernel_ref_counter(0) {
> +   has_source(true), has_il(false), il_type(UINT32_MAX), context(ctx),
> +   _source(source), _kernel_ref_counter(0), _il(nullptr), _length(0) {
>  }
>  
>  program::program(clover::context ,
>   const ref_vector ,
>   const std::vector ) :
> -   has_source(false), context(ctx),
> -   _devices(devs), _kernel_ref_counter(0) {
> +   has_source(false), has_il(false), il_type(UINT32_MAX), context(ctx),
> +   _devices(devs), _kernel_ref_counter(0), _il(nullptr), _length(0) {
> for_each([&](device , const module ) {
>   _builds[] = { bin };
>},
>devs, binaries);
>  }
>  
> +program::program(clover::context , const void *il, const size_t length,

il/length (and their program member counterparts) look like an
open-coded std::vector.

> + const uint32_t type) :
> +   has_source(false), has_il(true), il_type(type), context(ctx),
> +   _kernel_ref_counter(0), 

Re: [Mesa-dev] [PATCH v2 10/22] clover/spirv: Import spirv.hpp11 version 1.0 (rev 12)

[Pierre Moreau]

On 2018-01-23 — 14:06, Francisco Jerez wrote:
> Pierre Moreau  writes:
> 
> > Signed-off-by: Pierre Moreau 
> > ---
> >  .../state_trackers/clover/spirv/spirv.hpp11| 997 
> > +
> >  1 file changed, 997 insertions(+)
> >  create mode 100644 src/gallium/state_trackers/clover/spirv/spirv.hpp11
> 
> Can you import this with an hpp extension please?  All other .hpp files
> under clover/ are also C++11, no need to confuse text editors.  With
> that fixed:

I kept the original ending from SPIRV-Headers, but they need to differentiate
it from the other C++ header which does not use C++11 features. I could drop
it, but I am a little concerned that someone might think it would be the
spirv.hpp file from SPIRV-Headers, which it isn’t.
If you think this is not an issue, I will drop it.

> 
> Acked-by: Francisco Jerez 
> 
> >
> > diff --git a/src/gallium/state_trackers/clover/spirv/spirv.hpp11 
> > b/src/gallium/state_trackers/clover/spirv/spirv.hpp11
> > new file mode 100644
> > index 00..792eeb1aa0
> > --- /dev/null
> > +++ b/src/gallium/state_trackers/clover/spirv/spirv.hpp11
> > @@ -0,0 +1,997 @@
> > +// Copyright (c) 2014-2017 The Khronos Group Inc.
> > +// 
> > +// Permission is hereby granted, free of charge, to any person obtaining a 
> > copy
> > +// of this software and/or associated documentation files (the 
> > "Materials"),
> > +// to deal in the Materials without restriction, including without 
> > limitation
> > +// the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > +// and/or sell copies of the Materials, and to permit persons to whom the
> > +// Materials are furnished to do so, subject to the following conditions:
> > +// 
> > +// The above copyright notice and this permission notice shall be included 
> > in
> > +// all copies or substantial portions of the Materials.
> > +// 
> > +// MODIFICATIONS TO THIS FILE MAY MEAN IT NO LONGER ACCURATELY REFLECTS 
> > KHRONOS
> > +// STANDARDS. THE UNMODIFIED, NORMATIVE VERSIONS OF KHRONOS SPECIFICATIONS 
> > AND
> > +// HEADER INFORMATION ARE LOCATED AT https://www.khronos.org/registry/ 
> > +// 
> > +// THE MATERIALS ARE 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 MATERIALS OR THE USE OR OTHER 
> > DEALINGS
> > +// IN THE MATERIALS.
> > +
> > +// This header is automatically generated by the same tool that creates
> > +// the Binary Section of the SPIR-V specification.
> > +
> > +// Enumeration tokens for SPIR-V, in various styles:
> > +//   C, C++, C++11, JSON, Lua, Python
> > +// 
> > +// - C will have tokens with a "Spv" prefix, e.g.: SpvSourceLanguageGLSL
> > +// - C++ will have tokens in the "spv" name space, e.g.: 
> > spv::SourceLanguageGLSL
> > +// - C++11 will use enum classes in the spv namespace, e.g.: 
> > spv::SourceLanguage::GLSL
> > +// - Lua will use tables, e.g.: spv.SourceLanguage.GLSL
> > +// - Python will use dictionaries, e.g.: spv['SourceLanguage']['GLSL']
> > +// 
> > +// Some tokens act like mask values, which can be OR'd together,
> > +// while others are mutually exclusive.  The mask-like ones have
> > +// "Mask" in their name, and a parallel enum that has the shift
> > +// amount (1 << x) for each corresponding enumerant.
> > +
> > +#ifndef spirv_HPP
> > +#define spirv_HPP
> > +
> > +namespace spv {
> > +
> > +typedef unsigned int Id;
> > +
> > +#define SPV_VERSION 0x1
> > +#define SPV_REVISION 12
> > +
> > +static const unsigned int MagicNumber = 0x07230203;
> > +static const unsigned int Version = 0x0001;
> > +static const unsigned int Revision = 12;
> > +static const unsigned int OpCodeMask = 0x;
> > +static const unsigned int WordCountShift = 16;
> > +
> > +enum class SourceLanguage : unsigned {
> > +Unknown = 0,
> > +ESSL = 1,
> > +GLSL = 2,
> > +OpenCL_C = 3,
> > +OpenCL_CPP = 4,
> > +HLSL = 5,
> > +Max = 0x7fff,
> > +};
> > +
> > +enum class ExecutionModel : unsigned {
> > +Vertex = 0,
> > +TessellationControl = 1,
> > +TessellationEvaluation = 2,
> > +Geometry = 3,
> > +Fragment = 4,
> > +GLCompute = 5,
> > +Kernel = 6,
> > +Max = 0x7fff,
> > +};
> > +
> > +enum class AddressingModel : unsigned {
> > +Logical = 0,
> > +Physical32 = 1,
> > +Physical64 = 2,
> > +Max = 0x7fff,
> > +};
> > +
> > +enum class MemoryModel : unsigned {
> > +Simple = 0,
> > +GLSL450 = 1,
> > +OpenCL = 2,
> > +Max = 0x7fff,
> > +};
> > +
> > +enum class ExecutionMode : unsigned {
> > +Invocations = 0,
> > +  

Re: [Mesa-dev] [PATCH v2 13/22] clover: Handle the case when linking SPIR-V binaries together

[Francisco Jerez]

Pierre Moreau  writes:

> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/core/program.cpp | 22 
> +-
>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
> b/src/gallium/state_trackers/clover/core/program.cpp
> index 15d559cd93..976213ef95 100644
> --- a/src/gallium/state_trackers/clover/core/program.cpp
> +++ b/src/gallium/state_trackers/clover/core/program.cpp
> @@ -22,6 +22,7 @@
>  
>  #include "core/program.hpp"
>  #include "llvm/invocation.hpp"
> +#include "spirv/invocation.hpp"
>  #include "tgsi/invocation.hpp"
>  
>  using namespace clover;
> @@ -80,11 +81,22 @@ program::link(const ref_vector , const 
> std::string ,
>std::string log = _builds[].log;
>  
>try {
> - const module m = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
> -   tgsi::link_program(ms) :
> -   llvm::link_program(ms, dev.ir_format(),
> -  dev.ir_target(), opts, log));
> - _builds[] = { m, opts, log };
> + switch (dev.ir_format()) {
> + case PIPE_SHADER_IR_TGSI:
> +_builds[] = { tgsi::link_program(ms), opts, log };
> +break;
> + case PIPE_SHADER_IR_LLVM:
> + case PIPE_SHADER_IR_NATIVE:
> + case PIPE_SHADER_IR_NIR:
> +_builds[] = { llvm::link_program(ms, dev.ir_format(),
> + dev.ir_target(), opts, log),
> +  opts, log };
> +break;
> + case PIPE_SHADER_IR_SPIRV:
> +_builds[] = { clover::spirv::link_program(ms, opts, log), 
> opts,
> +  log };
> +break;
> + }

I'd prefer to implement this in a separate "module link_program(ms, dev,
opts, log)" demux-function with the switch-case statement that calls the
right linking function based on the IR of the program (and possibly
converts it into the drivers's preferred IR in the future).  Then just do
the following in this block:

| _builds[] = { link_program(ms, dev, opts, log), opts, log };

>} catch (...) {
>   _builds[] = { module(), opts, log };
>   throw;
> -- 
> 2.16.0


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

Re: [Mesa-dev] [PATCH v2 15/22] include/CL: Add cl_khr_il_program

[Francisco Jerez]

Pierre Moreau  writes:

> Signed-off-by: Pierre Moreau 

Same comment as Karol, let's update the header instead.

> ---
>  include/CL/cl_ext.h | 34 ++
>  1 file changed, 34 insertions(+)
>
> diff --git a/include/CL/cl_ext.h b/include/CL/cl_ext.h
> index 710bea8837..2e4845d27d 100644
> --- a/include/CL/cl_ext.h
> +++ b/include/CL/cl_ext.h
> @@ -308,6 +308,40 @@ typedef struct _cl_mem_ion_host_ptr
>  
>  #endif /* CL_VERSION_1_1 */
>  
> +
> +/***
> + * cl_khr_il_program extension *
> + ***/
> +
> +#ifndef cl_khr_il_program
> +#define cl_khr_il_program 1
> +
> +/* New property to clGetDeviceInfo for retrieving supported intermediate
> + * languages
> + */
> +#define CL_DEVICE_IL_VERSION_KHR0x105B
> +
> +/* New property to clGetProgramInfo for retrieving for retrieving the IL of a
> + * program
> + */
> +#define CL_PROGRAM_IL_KHR   0x1169
> +
> +extern CL_API_ENTRY cl_program
> +  CL_API_CALL clCreateProgramWithILKHR(
> +  cl_context /* context */,
> +  const void * /* il */,
> +  size_t /* length */,
> +  cl_int * /* errcode_ret */) CL_EXT_SUFFIX__VERSION_1_2;
> +
> +typedef CL_API_ENTRY cl_program
> +  (CL_API_CALL *clCreateProgramWithILKHR_fn)(
> +  cl_context /* context */,
> +  const void * /* il */,
> +  size_t /* length */,
> +  cl_int * /* errcode_ret */) CL_EXT_SUFFIX__VERSION_1_2;
> +
> +#endif /* cl_khr_il_program */
> +
>  #ifdef __cplusplus
>  }
>  #endif
> -- 
> 2.16.0


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

Re: [Mesa-dev] [PATCH v2 14/22] clover: Add a pointer property to return ILs

[Francisco Jerez]

Pierre Moreau  writes:

> OpenCL 2.1, and cl_khr_il_program, gives the ability to query for a
> program’s IL, which is returned as a pointer.
>
> Signed-off-by: Pierre Moreau 

I'm not convinced this is correct, but...  It seems fully unnecessary, I
think you should be using a property_vector instead.

> ---
>  .../state_trackers/clover/core/property.hpp| 39 
> ++
>  1 file changed, 39 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/core/property.hpp 
> b/src/gallium/state_trackers/clover/core/property.hpp
> index 7f8e17684d..5beac372e7 100644
> --- a/src/gallium/state_trackers/clover/core/property.hpp
> +++ b/src/gallium/state_trackers/clover/core/property.hpp
> @@ -23,6 +23,7 @@
>  #ifndef CLOVER_CORE_PROPERTY_HPP
>  #define CLOVER_CORE_PROPERTY_HPP
>  
> +#include 
>  #include 
>  
>  #include "util/range.hpp"
> @@ -84,6 +85,19 @@ namespace clover {
>private:
>   property_buffer 
>};
> +
> +  template
> +  class property_pointer {
> +  public:
> + property_pointer(property_buffer ) : buf(buf) {
> + }
> +
> + inline property_pointer &
> + operator=(const std::pair );
> +
> +  private:
> + property_buffer 
> +  };
> };
>  
> ///
> @@ -118,6 +132,12 @@ namespace clover {
>   return { *this };
>}
>  
> +  template
> +  detail::property_pointer
> +  as_pointer() {
> + return { *this };
> +  }
> +
>template
>iterator_range
>allocate(size_t n) {
> @@ -133,6 +153,17 @@ namespace clover {
>  return { };
>}
>  
> +  void
> +  allocate_raw(const void *v, size_t n) {
> + if (r_buf && size < n)
> +throw error(CL_INVALID_VALUE);
> +
> + if (r_size)
> +*r_size = n;
> +
> + std::memcpy(r_buf, v, n);
> +  }
> +
> private:
>void *const r_buf;
>const size_t size;
> @@ -178,6 +209,14 @@ namespace clover {
>   return *this;
>}
>  
> +  template
> +  inline property_pointer &
> +  property_pointer::operator=(const std::pair ) {
> + buf.allocate_raw(v.first, v.second);
> +
> + return *this;
> +  }
> +
>inline property_string &
>property_string::operator=(const std::string ) {
>   auto r = buf.allocate(v.size() + 1);
> -- 
> 2.16.0


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

Re: [Mesa-dev] [PATCH v2 12/22] clover: Refuse to compile source code to SPIR-V

[Francisco Jerez]

Pierre Moreau  writes:

> Creating a program using clCreateProgramWithSource to SPIR-V requires a
> non-upstreamed version of LLVM and clang, therefore it is currently not
> supported.
>
> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/core/program.cpp | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
> b/src/gallium/state_trackers/clover/core/program.cpp
> index ae4b50a879..15d559cd93 100644
> --- a/src/gallium/state_trackers/clover/core/program.cpp
> +++ b/src/gallium/state_trackers/clover/core/program.cpp
> @@ -51,6 +51,10 @@ program::compile(const ref_vector , const 
> std::string ,
>   std::string log;
>  
>   try {
> +if (dev.ir_format() == PIPE_SHADER_IR_SPIRV) {
> +   log = "Compiling from source to SPIR-V is not supported 
> yet\n";
> +   throw error(CL_INVALID_DEVICE);
> +}

Since this is a valid condition according to the API spec I'd prefer to
assert that dev.ir_format() is one of the supported values until
upstream LLVM supports SPIRV as target.

>  const module m = (dev.ir_format() == PIPE_SHADER_IR_TGSI ?
>tgsi::compile_program(_source, log) :
>llvm::compile_program(_source, headers,
> -- 
> 2.16.0


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

Re: [Mesa-dev] [PATCH v2 10/22] clover/spirv: Import spirv.hpp11 version 1.0 (rev 12)

[Francisco Jerez]

Pierre Moreau  writes:

> Signed-off-by: Pierre Moreau 
> ---
>  .../state_trackers/clover/spirv/spirv.hpp11| 997 
> +
>  1 file changed, 997 insertions(+)
>  create mode 100644 src/gallium/state_trackers/clover/spirv/spirv.hpp11

Can you import this with an hpp extension please?  All other .hpp files
under clover/ are also C++11, no need to confuse text editors.  With
that fixed:

Acked-by: Francisco Jerez 

>
> diff --git a/src/gallium/state_trackers/clover/spirv/spirv.hpp11 
> b/src/gallium/state_trackers/clover/spirv/spirv.hpp11
> new file mode 100644
> index 00..792eeb1aa0
> --- /dev/null
> +++ b/src/gallium/state_trackers/clover/spirv/spirv.hpp11
> @@ -0,0 +1,997 @@
> +// Copyright (c) 2014-2017 The Khronos Group Inc.
> +// 
> +// Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> +// of this software and/or associated documentation files (the "Materials"),
> +// to deal in the Materials without restriction, including without limitation
> +// the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +// and/or sell copies of the Materials, and to permit persons to whom the
> +// Materials are furnished to do so, subject to the following conditions:
> +// 
> +// The above copyright notice and this permission notice shall be included in
> +// all copies or substantial portions of the Materials.
> +// 
> +// MODIFICATIONS TO THIS FILE MAY MEAN IT NO LONGER ACCURATELY REFLECTS 
> KHRONOS
> +// STANDARDS. THE UNMODIFIED, NORMATIVE VERSIONS OF KHRONOS SPECIFICATIONS 
> AND
> +// HEADER INFORMATION ARE LOCATED AT https://www.khronos.org/registry/ 
> +// 
> +// THE MATERIALS ARE 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 MATERIALS OR THE USE OR OTHER 
> DEALINGS
> +// IN THE MATERIALS.
> +
> +// This header is automatically generated by the same tool that creates
> +// the Binary Section of the SPIR-V specification.
> +
> +// Enumeration tokens for SPIR-V, in various styles:
> +//   C, C++, C++11, JSON, Lua, Python
> +// 
> +// - C will have tokens with a "Spv" prefix, e.g.: SpvSourceLanguageGLSL
> +// - C++ will have tokens in the "spv" name space, e.g.: 
> spv::SourceLanguageGLSL
> +// - C++11 will use enum classes in the spv namespace, e.g.: 
> spv::SourceLanguage::GLSL
> +// - Lua will use tables, e.g.: spv.SourceLanguage.GLSL
> +// - Python will use dictionaries, e.g.: spv['SourceLanguage']['GLSL']
> +// 
> +// Some tokens act like mask values, which can be OR'd together,
> +// while others are mutually exclusive.  The mask-like ones have
> +// "Mask" in their name, and a parallel enum that has the shift
> +// amount (1 << x) for each corresponding enumerant.
> +
> +#ifndef spirv_HPP
> +#define spirv_HPP
> +
> +namespace spv {
> +
> +typedef unsigned int Id;
> +
> +#define SPV_VERSION 0x1
> +#define SPV_REVISION 12
> +
> +static const unsigned int MagicNumber = 0x07230203;
> +static const unsigned int Version = 0x0001;
> +static const unsigned int Revision = 12;
> +static const unsigned int OpCodeMask = 0x;
> +static const unsigned int WordCountShift = 16;
> +
> +enum class SourceLanguage : unsigned {
> +Unknown = 0,
> +ESSL = 1,
> +GLSL = 2,
> +OpenCL_C = 3,
> +OpenCL_CPP = 4,
> +HLSL = 5,
> +Max = 0x7fff,
> +};
> +
> +enum class ExecutionModel : unsigned {
> +Vertex = 0,
> +TessellationControl = 1,
> +TessellationEvaluation = 2,
> +Geometry = 3,
> +Fragment = 4,
> +GLCompute = 5,
> +Kernel = 6,
> +Max = 0x7fff,
> +};
> +
> +enum class AddressingModel : unsigned {
> +Logical = 0,
> +Physical32 = 1,
> +Physical64 = 2,
> +Max = 0x7fff,
> +};
> +
> +enum class MemoryModel : unsigned {
> +Simple = 0,
> +GLSL450 = 1,
> +OpenCL = 2,
> +Max = 0x7fff,
> +};
> +
> +enum class ExecutionMode : unsigned {
> +Invocations = 0,
> +SpacingEqual = 1,
> +SpacingFractionalEven = 2,
> +SpacingFractionalOdd = 3,
> +VertexOrderCw = 4,
> +VertexOrderCcw = 5,
> +PixelCenterInteger = 6,
> +OriginUpperLeft = 7,
> +OriginLowerLeft = 8,
> +EarlyFragmentTests = 9,
> +PointMode = 10,
> +Xfb = 11,
> +DepthReplacing = 12,
> +DepthGreater = 14,
> +DepthLess = 15,
> +DepthUnchanged = 16,
> +LocalSize = 17,
> +LocalSizeHint = 18,
> +InputPoints = 19,
> +InputLines = 20,
> +InputLinesAdjacency = 21,
> +Triangles = 22,
> +InputTrianglesAdjacency = 23,
> +Quads = 24,
> +Isolines = 25,
> +

Re: [Mesa-dev] [PATCH v2 07/22] clover: Move platform extensions definitions to clover/platform.cpp

[Francisco Jerez]

Pierre Moreau  writes:

> Signed-off-by: Pierre Moreau 

Reviewed-by: Francisco Jerez 

> ---
>  src/gallium/state_trackers/clover/api/platform.cpp  | 4 ++--
>  src/gallium/state_trackers/clover/core/platform.cpp | 5 +
>  src/gallium/state_trackers/clover/core/platform.hpp | 2 ++
>  3 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/platform.cpp 
> b/src/gallium/state_trackers/clover/api/platform.cpp
> index ed86163311..887dfd0a22 100644
> --- a/src/gallium/state_trackers/clover/api/platform.cpp
> +++ b/src/gallium/state_trackers/clover/api/platform.cpp
> @@ -50,7 +50,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
> cl_platform_info param,
>  size_t size, void *r_buf, size_t *r_size) try {
> property_buffer buf { r_buf, size, r_size };
>  
> -   obj(d_platform);
> +   auto  = obj(d_platform);
>  
> switch (param) {
> case CL_PLATFORM_PROFILE:
> @@ -74,7 +74,7 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
> cl_platform_info param,
>break;
>  
> case CL_PLATFORM_EXTENSIONS:
> -  buf.as_string() = "cl_khr_icd";
> +  buf.as_string() = platform.supported_extensions();
>break;
>  
> case CL_PLATFORM_ICD_SUFFIX_KHR:
> diff --git a/src/gallium/state_trackers/clover/core/platform.cpp 
> b/src/gallium/state_trackers/clover/core/platform.cpp
> index 489e8dc5a8..ddd63fc5a0 100644
> --- a/src/gallium/state_trackers/clover/core/platform.cpp
> +++ b/src/gallium/state_trackers/clover/core/platform.cpp
> @@ -39,3 +39,8 @@ platform::platform() : adaptor_range(evals(), devs) {
>}
> }
>  }
> +
> +std::string
> +platform::supported_extensions() const {
> +   return "cl_khr_icd";
> +}
> diff --git a/src/gallium/state_trackers/clover/core/platform.hpp 
> b/src/gallium/state_trackers/clover/core/platform.hpp
> index e849645bbe..b94434c983 100644
> --- a/src/gallium/state_trackers/clover/core/platform.hpp
> +++ b/src/gallium/state_trackers/clover/core/platform.hpp
> @@ -40,6 +40,8 @@ namespace clover {
>platform &
>operator=(const platform ) = delete;
>  
> +  std::string supported_extensions() const;
> +
> protected:
>std::vector devs;
> };
> -- 
> 2.16.0


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

Re: [Mesa-dev] [PATCH v2 06/22] clover: Move device extensions definitions to core/device.cpp

[Francisco Jerez]

Pierre Moreau  writes:

> Signed-off-by: Pierre Moreau 

Reviewed-by: Francisco Jerez 

> ---
>  src/gallium/state_trackers/clover/api/device.cpp  | 11 +--
>  src/gallium/state_trackers/clover/core/device.cpp | 14 ++
>  src/gallium/state_trackers/clover/core/device.hpp |  1 +
>  3 files changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
> b/src/gallium/state_trackers/clover/api/device.cpp
> index 576555a9af..4e274c5005 100644
> --- a/src/gallium/state_trackers/clover/api/device.cpp
> +++ b/src/gallium/state_trackers/clover/api/device.cpp
> @@ -330,16 +330,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>break;
>  
> case CL_DEVICE_EXTENSIONS:
> -  buf.as_string() =
> - "cl_khr_byte_addressable_store"
> - " cl_khr_global_int32_base_atomics"
> - " cl_khr_global_int32_extended_atomics"
> - " cl_khr_local_int32_base_atomics"
> - " cl_khr_local_int32_extended_atomics"
> - + std::string(dev.has_int64_atomics() ? " 
> cl_khr_int64_base_atomics" : "")
> - + std::string(dev.has_int64_atomics() ? " 
> cl_khr_int64_extended_atomics" : "")
> - + std::string(dev.has_doubles() ? " cl_khr_fp64" : "")
> - + std::string(dev.has_halves() ? " cl_khr_fp16" : "");
> +  buf.as_string() = dev.supported_extensions();
>break;
>  
> case CL_DEVICE_PLATFORM:
> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
> b/src/gallium/state_trackers/clover/core/device.cpp
> index 7eaa0ca2cb..9fb233aa72 100644
> --- a/src/gallium/state_trackers/clover/core/device.cpp
> +++ b/src/gallium/state_trackers/clover/core/device.cpp
> @@ -279,3 +279,17 @@ bool
>  device::supports_ir(cl_uint ir) const {
> return supported_irs() & (1 << ir);
>  }
> +
> +std::string
> +device::supported_extensions() const {
> +   return
> +  "cl_khr_byte_addressable_store"
> +  " cl_khr_global_int32_base_atomics"
> +  " cl_khr_global_int32_extended_atomics"
> +  " cl_khr_local_int32_base_atomics"
> +  " cl_khr_local_int32_extended_atomics"
> +  + std::string(has_int64_atomics() ? " cl_khr_int64_base_atomics" : "")
> +  + std::string(has_int64_atomics() ? " cl_khr_int64_extended_atomics" : 
> "")
> +  + std::string(has_doubles() ? " cl_khr_fp64" : "")
> +  + std::string(has_halves() ? " cl_khr_fp16" : "");
> +}
> diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
> b/src/gallium/state_trackers/clover/core/device.hpp
> index eed644e919..98b9637ace 100644
> --- a/src/gallium/state_trackers/clover/core/device.hpp
> +++ b/src/gallium/state_trackers/clover/core/device.hpp
> @@ -83,6 +83,7 @@ namespace clover {
>cl_uint supported_irs() const;
>std::string ir_target() const;
>enum pipe_endian endianness() const;
> +  std::string supported_extensions() const;
>  
>bool supports_ir(cl_uint ir) const;
>  
> -- 
> 2.16.0


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

Re: [Mesa-dev] [PATCH v2 01/22] clover/api: Fix tab indentation to spaces

[Francisco Jerez]

Pierre Moreau  writes:

> Signed-off-by: Pierre Moreau 

Acked-by: Francisco Jerez 

> ---
>  src/gallium/state_trackers/clover/api/device.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
> b/src/gallium/state_trackers/clover/api/device.cpp
> index 3572bb0c92..576555a9af 100644
> --- a/src/gallium/state_trackers/clover/api/device.cpp
> +++ b/src/gallium/state_trackers/clover/api/device.cpp
> @@ -326,7 +326,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>  #ifdef MESA_GIT_SHA1
>  " (" MESA_GIT_SHA1 ")"
>  #endif
> - ;
> +;
>break;
>  
> case CL_DEVICE_EXTENSIONS:
> -- 
> 2.16.0


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

Re: [Mesa-dev] [PATCH v2 04/22] clover: Disallow creating libraries from other libraries

[Francisco Jerez]

Pierre Moreau  writes:

> If creating a library, do not allow non-compiled object in it, as
> executables are not allowed, and libraries would make it really hard to
> enforce the "-enable-link-options" flag.
>
> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/api/program.cpp | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
> b/src/gallium/state_trackers/clover/api/program.cpp
> index 6044179587..8f0b103a4d 100644
> --- a/src/gallium/state_trackers/clover/api/program.cpp
> +++ b/src/gallium/state_trackers/clover/api/program.cpp
> @@ -251,9 +251,13 @@ clCompileProgram(cl_program d_prog, cl_uint num_devs,
>  namespace {
> ref_vector
> validate_link_devices(const ref_vector ,
> - const ref_vector _devs) {
> + const ref_vector _devs,
> + const std::string ) {
>std::vector devs;
>  
> +  const std::string flag = "-create-library";
> +  const bool create_library = opts.find("-create-library") != 
> std::string::npos;
> +
>for (auto  : all_devs) {
>   const auto has_binary = [&](const program ) {
>  const auto t = prog.build(dev).binary_type();
> @@ -261,10 +265,19 @@ namespace {
> t == CL_PROGRAM_BINARY_TYPE_LIBRARY;
>   };
>  
> + // If creating a library, do not allow non-compiled object in it, as
> + // executables are not allowed, and libraries would make it really
> + // hard to enforce the "-enable-link-options".
> + if (create_library && any_of([&](const program ) {
> +  const auto t = prog.build(dev).binary_type();
> +  return t != CL_PROGRAM_BINARY_TYPE_COMPILED_OBJECT;
> +   }, progs))
> +throw error(CL_INVALID_OPERATION);
> +

Do you have any spec quote justifying this?  "Hard" is hardly a
justification for emitting an unexpected API error ;).  If doing such a
thing would rely on unimplemented behavior somewhere else it would
probably be cleaner to assert-fail wherever an implementation is missing
rather than returning an API error under conditions not expected by the
application.

>   // According to the CL 1.2 spec, when "all programs specified [..]
>   // contain a compiled binary or library for the device [..] a link 
> is
>   // performed",
> - if (all_of(has_binary, progs))
> + else if (all_of(has_binary, progs))
>  devs.push_back();
>  
>   // otherwise if "none of the programs contain a compiled binary or
> @@ -290,7 +303,7 @@ clLinkProgram(cl_context d_ctx, cl_uint num_devs, const 
> cl_device_id *d_devs,
> auto prog = create(ctx);
> auto devs = validate_link_devices(progs,
>   (d_devs ? objs(d_devs, num_devs) :
> -  ref_vector(ctx.devices(;
> +  ref_vector(ctx.devices())), 
> opts);
>  
> validate_build_common(prog, num_devs, d_devs, pfn_notify, user_data);
>  
> -- 
> 2.16.0


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

Re: [Mesa-dev] [PATCH v2 03/22] clover/api: Fail if trying to build a non-executable binary

[Francisco Jerez]

Pierre Moreau  writes:

> From the OpenCL 1.2 Specification, Section 5.6.2 (about clBuildProgram:
>
>> If program is created with clCreateProgramWithBinary, then the
>> program binary must be an executable binary (not a compiled binary or
>> library).
>
> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/api/program.cpp | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
> b/src/gallium/state_trackers/clover/api/program.cpp
> index 9d59668f8f..6044179587 100644
> --- a/src/gallium/state_trackers/clover/api/program.cpp
> +++ b/src/gallium/state_trackers/clover/api/program.cpp
> @@ -186,6 +186,14 @@ clBuildProgram(cl_program d_prog, cl_uint num_devs,
> if (prog.has_source) {
>prog.compile(devs, opts);
>prog.link(devs, opts, { prog });
> +   } else if (any_of([&](const device ){
> + return prog.build(dev).binary_type() != 
> CL_PROGRAM_BINARY_TYPE_EXECUTABLE;
> + }, objs(d_devs, num_devs))) {

Shouldn't this be using the range of devices the application requested
to build for (which might be the whole set of devices associated with
prog if d_devs was null) instead of the objs expression?

> +  // OpenCL 1.2 Specification, Section 5.6.2:
> +  // > If program is created with clCreateProgramWithBinary, then the
> +  // > program binary must be an executable binary (not a compiled 
> binary or
> +  // > library).

I'd format this like:

|  // According to the OpenCL 1.2 specification, "if program is created with
|  // clCreateProgramWithBinary, then the program binary must be an 
executable
|  // binary (not a compiled binary or library)."

> +  throw error(CL_INVALID_BINARY);
> }
>  
> return CL_SUCCESS;
> -- 
> 2.16.0


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

Re: [Mesa-dev] [PATCH v2 02/22] clover: Add additional functions to query supported IRs

[Francisco Jerez]

Pierre Moreau  writes:

> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/core/device.cpp | 11 +++
>  src/gallium/state_trackers/clover/core/device.hpp |  3 +++
>  2 files changed, 14 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
> b/src/gallium/state_trackers/clover/core/device.cpp
> index 9dd7eed3f1..7eaa0ca2cb 100644
> --- a/src/gallium/state_trackers/clover/core/device.cpp
> +++ b/src/gallium/state_trackers/clover/core/device.cpp
> @@ -247,6 +247,12 @@ device::ir_format() const {
>pipe, PIPE_SHADER_COMPUTE, PIPE_SHADER_CAP_PREFERRED_IR);
>  }
>  
> +cl_uint
> +device::supported_irs() const {
> +   return (enum pipe_shader_ir) pipe->get_shader_param(
> +  pipe, PIPE_SHADER_COMPUTE, PIPE_SHADER_CAP_SUPPORTED_IRS);
> +}
> +

I don't think we need this as a public method of clover::device, the
bitmask can be a local variable definition within supports_ir below.

>  std::string
>  device::ir_target() const {
> std::vector target = get_compute_param(
> @@ -268,3 +274,8 @@ std::string
>  device::device_clc_version() const {
>  return "1.1";
>  }
> +
> +bool
> +device::supports_ir(cl_uint ir) const {
> +   return supported_irs() & (1 << ir);
> +}
> diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
> b/src/gallium/state_trackers/clover/core/device.hpp
> index 85cd031676..eed644e919 100644
> --- a/src/gallium/state_trackers/clover/core/device.hpp
> +++ b/src/gallium/state_trackers/clover/core/device.hpp
> @@ -80,9 +80,12 @@ namespace clover {
>std::string device_version() const;
>std::string device_clc_version() const;
>enum pipe_shader_ir ir_format() const;
> +  cl_uint supported_irs() const;
>std::string ir_target() const;
>enum pipe_endian endianness() const;
>  
> +  bool supports_ir(cl_uint ir) const;

The argument of this method is a pipe_shader_ir enumerant, we should
declare it as such.

> +
>friend class command_queue;
>friend class root_resource;
>friend class hard_event;
> -- 
> 2.16.0


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

Re: [Mesa-dev] [PATCH v2 00/22] Introducing SPIR-V support to clover

[Francisco Jerez]

Karol Herbst  writes:

> there seem to be some patches missing?
>
> On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau  wrote:
>> Hello,
>>
>> Here is the second version of my initial series for adding SPIR-V support to
>> clover, after the RFC back in May 2017.
>>
>> For recap, the focus of this series is to let clover accept SPIR-V binaries
>> through the cl_khr_il_program extension (from OpenCL 1.2 and on), as well as
>> through some core features (since OpenCL 2.1). Even if OpenCL 2.1 support in
>> clover is some way off, there is another motivation for supporting SPIR-V in
>> clover, as multiple drivers are interested in adding OpenCL support by
>> converting SPIR-V to NIR.
>>
>> Note: the series is based on master + Karol’s patch “clover: add functions up
>> to 2.2 to ICD dispatch table”.
>>
>>
>> The various patches can be split in different categories:
>>
>> * Patches 1 through 7: some clover clean-up, adding and moving some
>>   functionalities around to make the implementation easier in the rest of the
>>   series.
>>
>> * Patches 8 through 13: define SPIR-V as a new IR, add a new frontend to 
>> clover
>>   to deal with SPIR-V, and edit compile and link operations to handle SPIR-V 
>> as
>>   well.
>>
>> * Patches 14 through 19: implement cl_khr_il_program
>>
>> * Patches 20 through 22: implement OpenCL 2.1 support on top of
>>   cl_khr_il_program
>>
>>
>> Changes since the RFC
>> -
>>
>> * Most SPIR-V utilities were dropped, and the remaining ones have been moved 
>> to
>>   the clover SPIR-V frontend rather than sitting in 
>> src/gallium/auxiliary/spirv.
>>
>> * The SPIR-V linker has been completely dropped from this series and instead
>>   merge in SPIRV-Tools [1].
>>
>> * Since SPIRV-Tools now exports a pkgconfig .pc file, use it for detecting 
>> the
>>   library.
>>
>> * Integrate the series with Meson.
>>
>> * Use pipe_llvm_program_header to pass in the size of the SPIR-V module, 
>> rather
>>   than adding a new attribute to pipe_compute_state, as suggested by 
>> Francisco
>>   Jerez.
>>
>> * Check that the device supports the capabilities defined in the SPIR-V 
>> binary.
>>
>> * Check that the platform/device supports the extensions used in the SPIR-V
>>   binary.
>>
>> * Fix the implementation responsible for filling up the symbols of the clover
>>   module based on the input SPIR-V binary.
>>
>> * No longer raw SPIR-V binaries through clCreateProgramWithBinary, but 
>> instead
>>   keep the current de-serialisation of the clover module, which may contain a
>>   SPIR-V binary.
>>
>> * Track whether a library was created with the --enable-link-options flag or
>>   not. This is currently not useful as the linker ignores most link options,
>>   but it will become useful when the linker handles those options.
>>
>> * Implement cl_khr_il_program.
>>
>> * Most of patches 1 through 8 (apart from patch 2).
>>
>>
>> Discussions
>> ---
>>
>> * Before, when linking different modules together, you knew that all modules
>>   would use the same IR, as all were created using clCreateProgramWithSource,
>>   therefore the linker could just call the linking function corresponding to
>>   the target’s preferred IR. But with the introduction of
>>   clCreateProgramWithIL(KHR)?, we can now end up in a case where we try to 
>> link
>>   a module using NIR as IR (created through clCreateProgramWithSource, 
>> assuming
>>   that is the driver’s preferred IR), with another module using SPIR-V as IR
>>   (created through clCreateProgramWithIL). How do we handle such a case: 
>> should
>>   we translate the SPIR-V to NIR and use a NIR linker on them, or convert NIR
>>   to SPIR-V and use the SPIR-V linker? NIR and LLVM IR can be handled
>>   relatively easily, but what about TGSI?
>>
>
> I think we will never be able to convert all IRs into any other IR, so
> that I would suggest to leave those IRs unconverted until they get
> linked together and there the code can decide on a common IR for
> linking. So if we get source code, we can parse it to llvm IR and
> leave it like that until it gets linked. Converting back and forth
> would require us to write all those conversion paths and I am assume
> this wouldn't be worth the trouble.
>

I think it would be more straightforward to compile source programs into
SPIRV if the driver supports it (or if it supports any other IR that
could possibly be translated from SPIRV after link time, e.g. NIR or
maybe even TGSI).  That means that there is a single canonical IR for
each CL device and we don't need to deal with linking different
combinations of IRs together.  If the driver doesn't support SPIRV nor
any of the IRs derived from it, it better support LLVM IR instead, so we
can just use that as canonical IR within the state tracker, and possibly
accept the same representation as input to clCreateProgramWithIL()
instead of SPIRV.

>> * In that regard, is anyone using the TGSI frontend in clover? If not, 

Re: [Mesa-dev] [PATCH v2 08/22] include/pipe: Define SPIRV as an IR

[Pierre Moreau]

On 2018-01-23 — 13:33, Francisco Jerez wrote:
> Pierre Moreau  writes:
> 
> > On 2018-01-23 — 14:07, Jan Vesely wrote:
> >> On Tue, 2018-01-23 at 01:33 +0100, Pierre Moreau wrote:
> >> > Signed-off-by: Pierre Moreau 
> >> > ---
> >> >  src/gallium/include/pipe/p_defines.h | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> > 
> >> > diff --git a/src/gallium/include/pipe/p_defines.h 
> >> > b/src/gallium/include/pipe/p_defines.h
> >> > index b34e7a8570..082d4c4d87 100644
> >> > --- a/src/gallium/include/pipe/p_defines.h
> >> > +++ b/src/gallium/include/pipe/p_defines.h
> >> > @@ -896,6 +896,7 @@ enum pipe_shader_ir
> >> > PIPE_SHADER_IR_LLVM,
> >> > PIPE_SHADER_IR_NATIVE,
> >> > PIPE_SHADER_IR_NIR,
> >> > +   PIPE_SHADER_IR_SPIRV
> >> 
> >> Why is this needed/useful? presumably the pipe driver will convert
> >> SPIRV to NIR or LLVM anyway, why not convert it in clover and pass one
> >> of the already existing IRs ?
> >> 
> >> Jan
> >
> > It is true it’s not really needed for this series, it’s mainly for my SPIR-V
> > frontend for Nouveau. I could drop it from this series for now, especially 
> > if
> > SPIR-V get directly translated to another IR and never stays as such, or 
> > going
> > the opposite and always keeping SPIR-V until the very last moment.
> >
> 
> I don't have any objection against plumbing through SPIRV directly if
> that's the path you're planning to pursue.  But wouldn't it make sense
> to have working back-end code able to consume it as input before adding
> a new IR to the pipe driver interface?  Otherwise this is basically dead
> code.

A one liner, but still dead code nonetheless. You are right, it should be part
of the series adding a SPIR-V consumer to Nouveau.

I guess half of this series is dead code as well, as there is currently nothing
that can be done with the SPIR-V binary: 1) no driver can consume it directly,
2) it can’t be translated to LLVM IR because there is no upstream code for that
currently, and 3) spirv_to_nir does not currently support OpenCL SPIR-V.

> 
> > Pierre
> >
> >> 
> >> >  };
> >> >  
> >> >  /**



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

[Mesa-dev] [PATCH] meson: correctly set SYSCONFDIR for loading dirrc

[Dylan Baker]

Fixes: d1992255bb29 ("meson: Add build Intel "anv" vulkan driver")
Reported-by: Marc Dietrich 
Signed-off-by: Dylan Baker 
---
 src/util/meson.build | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/util/meson.build b/src/util/meson.build
index fa591c92e56..b23dba3a985 100644
--- a/src/util/meson.build
+++ b/src/util/meson.build
@@ -112,8 +112,12 @@ libxmlconfig = static_library(
   files_xmlconfig,
   include_directories : inc_common,
   dependencies : [dep_expat, dep_m],
-  c_args : [c_msvc_compat_args, c_vis_args,
-'-DSYSCONFDIR="@0@"'.format(get_option('sysconfdir'))],
+  c_args : [
+c_msvc_compat_args, c_vis_args,
+'-DSYSCONFDIR="@0@"'.format(
+  join_paths(get_option('prefix'), get_option('sysconfdir'))
+),
+  ],
   build_by_default : false,
 )
 
-- 
2.16.0

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

Re: [Mesa-dev] [PATCH v2] meson: Don't confuse the install and search paths for dri drivers

[Dylan Baker]

Quoting Emil Velikov (2018-01-19 10:28:18)
> On 17 January 2018 at 21:34, Dylan Baker  wrote:
> > Currently there is not a separate option for setting the search path of
> > DRI drivers in meson, like there is in scons and autotools. This is an
> > oversight and needs to be fixed. This adds an extra option
> > `dri-search-path`, which will default to the value of
> > `dri-drivers-path`, like autotools does.
> >
> > v2: - Split input list before joining.
> >
> I was wondering for a while, if we really need both options in autotools.
> 
> Esp. since to use a custom loader one needs to
> LD_PRELOAD/LD_LIBRARY_PATH it already.
> Thus adding the LIBGL_DRIVERS_PATH is trivial, either way.
> 
> The following approach is a bit shorter and easier to read.
> 
> dri_search_path = get_option('dri-search-path')
> iif dri_search_path == ''
>   dri_search_path = dri_drivers_path
> endif
> 
> -Emil

That won't actually do what we want, because the argument is comma
delimited, but the pound define needs to be semi-colon delimited. I picked this 
approach
because when we move to a newer meson version we can take advantage of meson's
native array type argument, which use commas.

I'd be happy to drop this option if you want to drop it from autotools as well.

Dylan


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

Re: [Mesa-dev] meson builds don't read dri options

[Dylan Baker]

There's a bug in our meson build, and I sent a patch. We need to join_dirs with
get_option('prefix'). I got a little confused because when you pass a relative
directory to meson's `install` option it will autotmatically make it absolute,
but when you pass it to a C define it doesn't.

Quoting Kenneth Graunke (2018-01-23 10:00:56)
> On Tuesday, January 23, 2018 3:31:23 AM PST Marc Dietrich wrote:
> > Hi Dylan,
> > 
> > running "Heaven" fails with "error: #extension directive is not allowed in 
> > the 
> > middle of a shader" because drirc (which contains an exception for this 
> > program) is somehow not read in meson builds.
> > 
> > Marc
> 
> Hey Dylan,
> 
> Marc is right, this is not working correctly.  driParseConfigFiles has:
> 
> char *filenames[2] = { SYSCONFDIR "/drirc", NULL};
> 
> where SYSCONFDIR comes from Meson's get_option('sysconfdir').
> 
> The issue is that SYSCONFDIR is apparently getting expanded to "etc",
> so it's looking for "etc/drirc".
> 
> sysconfdir is supposed to default to $(prefix)/etc, so /usr/local/etc:
> https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
> 
> I wonder if this is a Meson bug or if we're handling sysconfdir wrong.
> 
> --Ken


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

Re: [Mesa-dev] [PATCH v2] meson: Don't confuse the install and search paths for dri drivers

[Dylan Baker]

Quoting Eric Engestrom (2018-01-18 15:02:46)
> On Thursday, 2018-01-18 17:09:33 +, Dylan Baker wrote:
> > Currently there is not a separate option for setting the search path of
> > DRI drivers in meson, like there is in scons and autotools. This is an
> > oversight and needs to be fixed. This adds an extra option
> > `dri-search-path`, which will default to the value of
> > `dri-drivers-path`, like autotools does.
> > 
> > v2: - Split input list before joining.
> > 
> > Reported-by: Ilia Mirkin 
> > Signed-off-by: Dylan Baker 
> > ---
> >  meson.build | 6 ++
> >  meson_options.txt   | 8 +++-
> >  src/egl/meson.build | 2 +-
> >  src/gbm/meson.build | 2 +-
> >  src/glx/meson.build | 3 ++-
> >  5 files changed, 17 insertions(+), 4 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index f3179c38062..8bab43681e9 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -57,6 +57,12 @@ dri_drivers_path = get_option('dri-drivers-path')
> >  if dri_drivers_path == ''
> >dri_drivers_path = join_paths(get_option('libdir'), 'dri')
> >  endif
> > +_search = get_option('dri-search-path')
> > +if _search != ''
> > +  dri_search_path = ';'.join(_search.split(','))
> 
> s/;/:/

The autotools help string says semi-colon. Does the help string need to be
updated?

> 
> Reviewed-by: Eric Engestrom 
> 
> > +else
> > +  dri_search_path = dri_drivers_path
> > +endif
> >  
> >  with_gles1 = get_option('gles1')
> >  with_gles2 = get_option('gles2')
> > diff --git a/meson_options.txt b/meson_options.txt
> > index 894378985fd..e541659733f 100644
> > --- a/meson_options.txt
> > +++ b/meson_options.txt
> > @@ -41,7 +41,13 @@ option(
> >'dri-drivers-path',
> >type : 'string',
> >value : '',
> > -  description : 'Location of dri drivers. Default: $libdir/dri.'
> > +  description : 'Location to install dri drivers. Default: $libdir/dri.'
> > +)
> > +option(
> > +  'dri-search-path',
> > +  type : 'string',
> > +  value : '',
> > +  description : 'Locations to search for dri drivers, passed as comma 
> > separated list. Default: dri-drivers-path.'
> >  )
> >  option(
> >'gallium-drivers',
> > diff --git a/src/egl/meson.build b/src/egl/meson.build
> > index df6e8b49dac..6cd04567b0d 100644
> > --- a/src/egl/meson.build
> > +++ b/src/egl/meson.build
> > @@ -160,7 +160,7 @@ libegl = shared_library(
> >c_args : [
> >  c_vis_args,
> >  c_args_for_egl,
> > -'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir),
> > +'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
> >  '-D_EGL_BUILT_IN_DRIVER_DRI2',
> >  
> > '-D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_@0@'.format(egl_native_platform.to_upper()),
> >],
> > diff --git a/src/gbm/meson.build b/src/gbm/meson.build
> > index 14b9e960360..2f5d1c6ddd7 100644
> > --- a/src/gbm/meson.build
> > +++ b/src/gbm/meson.build
> > @@ -38,7 +38,7 @@ incs_gbm = [
> >  if with_dri2
> >files_gbm += files('backends/dri/gbm_dri.c', 'backends/dri/gbm_driint.h')
> >deps_gbm += dep_libdrm # TODO: pthread-stubs
> > -  args_gbm += '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir)
> > +  args_gbm += '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path)
> >  endif
> >  if with_platform_wayland
> >deps_gbm += dep_wayland_server
> > diff --git a/src/glx/meson.build b/src/glx/meson.build
> > index 04cd647ee49..508e7583ee5 100644
> > --- a/src/glx/meson.build
> > +++ b/src/glx/meson.build
> > @@ -128,7 +128,8 @@ else
> >  endif
> >  
> >  gl_lib_cargs = [
> > -  '-D_REENTRANT', '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir),
> > +  '-D_REENTRANT',
> > +  '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
> >  ]
> >  
> >  if dep_xxf86vm != [] and dep_xxf86vm.found()
> > -- 
> > 2.15.1
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH 4/4] meson: add convenience variable for anv_extensions.py depdendency

[Dylan Baker]

Signed-off-by: Dylan Baker 
---
 src/intel/vulkan/meson.build | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index 1be389b67e3..41dba420cb4 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -18,6 +18,8 @@
 # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 # SOFTWARE.
 
+anv_extensions_py = files('anv_extensions.py')
+
 anv_entrypoints = custom_target(
   'anv_entrypoints.[ch]',
   input : ['anv_entrypoints_gen.py', vk_api_xml, vk_android_native_buffer_xml],
@@ -26,7 +28,7 @@ anv_entrypoints = custom_target(
 prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@',
 '--outdir', meson.current_build_dir(),
   ],
-  depend_files : files('anv_extensions.py'),
+  depend_files : anv_extensions_py,
 )
 
 anv_extensions_c = custom_target(
@@ -37,7 +39,7 @@ anv_extensions_c = custom_target(
 prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@',
 '--out-c', '@OUTPUT@',
   ],
-  depend_files : files('anv_extensions.py'),
+  depend_files : anv_extensions_py,
 )
 
 anv_extensions_h = custom_target(
@@ -48,7 +50,7 @@ anv_extensions_h = custom_target(
 prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@',
 '--out-h', '@OUTPUT@',
   ],
-  depend_files : files('anv_extensions.py'),
+  depend_files : anv_extensions_py,
 )
 
 intel_icd = custom_target(
@@ -60,7 +62,7 @@ intel_icd = custom_target(
 '--lib-path', join_paths(get_option('prefix'), get_option('libdir')),
 '--out', '@OUTPUT@',
   ],
-  depend_files : files('anv_extensions.py'),
+  depend_files : anv_extensions_py,
   build_by_default : true,
   install_dir : with_vulkan_icd_dir,
   install : true,
-- 
2.16.0

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

[Mesa-dev] [PATCH 2/4] meson: use depend_files to track extra file dependencies

[Dylan Baker]

cc: Jason Ekstrand 
cc: Samuel Iglesias Gonsálvez 
Fixes: f93994080993bda ("anv: Split anv_extensions.py into two files")
Signed-off-by: Dylan Baker 
---
 src/intel/vulkan/meson.build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index d0712f318c7..3f1a2de9fd3 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -31,13 +31,13 @@ anv_entrypoints = custom_target(
 
 anv_extensions_c = custom_target(
   'anv_extensions.c',
-  input : ['anv_extensions_gen.py', vk_api_xml, vk_android_native_buffer_xml,
-   'anv_extensions.py'],
+  input : ['anv_extensions_gen.py', vk_api_xml, vk_android_native_buffer_xml],
   output : 'anv_extensions.c',
   command : [
 prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@',
 '--out-c', '@OUTPUT@',
   ],
+  depend_files : files('anv_extensions.py'),
 )
 
 anv_extensions_h = custom_target(
-- 
2.16.0

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

[Mesa-dev] [PATCH 3/4] meson: use depend_files for adding extra file dependencies

[Dylan Baker]

cc: Jason Ekstrand 
cc: Samuel Iglesias Gonsálvez 
Fixes: dd088d4bec74f37ffe4 ("anv/extensions: Generate a header file with 
extension tables")
Signed-off-by: Dylan Baker 
---
 src/intel/vulkan/meson.build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index 3f1a2de9fd3..1be389b67e3 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -42,13 +42,13 @@ anv_extensions_c = custom_target(
 
 anv_extensions_h = custom_target(
   'anv_extensions.h',
-  input : ['anv_extensions_gen.py', vk_api_xml, vk_android_native_buffer_xml,
-   'anv_extensions.py'],
+  input : ['anv_extensions_gen.py', vk_api_xml, vk_android_native_buffer_xml],
   output : 'anv_extensions.h',
   command : [
 prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@',
 '--out-h', '@OUTPUT@',
   ],
+  depend_files : files('anv_extensions.py'),
 )
 
 intel_icd = custom_target(
-- 
2.16.0

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

Re: [Mesa-dev] meson builds don't read dri options

[Dylan Baker]

Hi Marc,

I have two theories

1) Is your locale non-english by chance? generation of drirc support for
translations is still on the list

2) The search path may not be correct, I'll double check that now.

Quoting Marc Dietrich (2018-01-23 03:31:23)
> Hi Dylan,
> 
> running "Heaven" fails with "error: #extension directive is not allowed in 
> the 
> middle of a shader" because drirc (which contains an exception for this 
> program) is somehow not read in meson builds.
> 
> Marc


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

Re: [Mesa-dev] [PATCH] meson: fix some defines misspelled errors in meson.build

[Dylan Baker]

This needs to go into the 18.0 release. CC'ing stable.


Quoting Eric Engestrom (2018-01-23 07:46:14)
> On Tuesday, 2018-01-23 15:49:43 +0100, Marc Dietrich wrote:
> > Defines
> > - HAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
> > - HAVE_FUNC_ATTRIBUTE_VISIBILITY
> > were misspelled.
> 
> Wow, good catch!
> Reviewed-by: Eric Engestrom 
> 
> and pushed :)
> 
> Out of curiosity, did you find those by hand, or do you have a tool that
> catches defines misspellings like these?
> I'm asking because I toyed with the idea of building such a tool, having
> not found one online, but I never actually did it.
> 
> > 
> > Signed-off-by: Marc Dietrich 
> > ---
> >  meson.build | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index c95c44641f..9e3b98641f 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -682,14 +682,14 @@ if cc.compiles('struct __attribute__((packed)) foo { 
> > int bar; };',
> >  endif
> >  if cc.compiles('int *foo(void) __attribute__((returns_nonnull));',
> > name : '__attribute__((returns_nonnull))')
> > -  pre_args += '-DHAVE_FUNC_ATTRIBUTE_NONNULL'
> > +  pre_args += '-DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL'
> >  endif
> >  if cc.compiles('''int foo_def(void) __attribute__((visibility("default")));
> >int foo_hid(void) __attribute__((visibility("hidden")));
> >int foo_int(void) 
> > __attribute__((visibility("internal")));
> >int foo_pro(void) 
> > __attribute__((visibility("protected")));''',
> > name : '__attribute__((visibility(...)))')
> > -  pre_args += '-DHAVE_FUNC_ATTRIBUTE_VISBILITY'
> > +  pre_args += '-DHAVE_FUNC_ATTRIBUTE_VISIBILITY'
> >  endif
> >  if cc.compiles('int foo(void) { return 0; } int bar(void) 
> > __attribute__((alias("foo")));',
> > name : '__attribute__((alias(...)))')
> > -- 
> > 2.16.0
> > 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH 1/4] Revert "anv/meson: Make anv_entrypoints_gen.py depend on anv_extensions.py"

[Dylan Baker]

This reverts commit 10d1b0be8e9c463dbc35cd66968299f33c76672c.

This is unnecessary, the depend_files argument is for adding
dependencies on files that are not part of the input, which is already
done.

cc: Jason Ekstrand 
cc: Samuel Iglesias Gonsálvez 
Fixes: 10d1b0be8e9c463dbc35cd66968299f33c76672c
Signed-off-by: Dylan Baker 
---
 src/intel/vulkan/meson.build | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index 69ec26e19b6..d0712f318c7 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -20,8 +20,7 @@
 
 anv_entrypoints = custom_target(
   'anv_entrypoints.[ch]',
-  input : ['anv_entrypoints_gen.py', vk_api_xml, vk_android_native_buffer_xml,
-   'anv_extensions.py'],
+  input : ['anv_entrypoints_gen.py', vk_api_xml, vk_android_native_buffer_xml],
   output : ['anv_entrypoints.h', 'anv_entrypoints.c'],
   command : [
 prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@',
-- 
2.16.0

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

Re: [Mesa-dev] [PATCH] meson: remove lib prefix from libd3dadapter9.so

[Dylan Baker]

I've added Eric and I's rbs and a fixes tag and pushed to master.

Thanks for fixing this!

Quoting Christoph Haag (2018-01-20 09:53:13)
> ---
>  src/gallium/targets/d3dadapter9/meson.build | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/targets/d3dadapter9/meson.build 
> b/src/gallium/targets/d3dadapter9/meson.build
> index 61bb5649ae..5476e80e70 100644
> --- a/src/gallium/targets/d3dadapter9/meson.build
> +++ b/src/gallium/targets/d3dadapter9/meson.build
> @@ -68,6 +68,7 @@ libgallium_nine = shared_library(
>  driver_swrast, driver_r300, driver_r600, driver_radeonsi, driver_nouveau,
>  driver_i915, driver_svga,
>],
> +  name_prefix : '',
>version : '.'.join(nine_version),
>install : true,
>install_dir : d3d_drivers_path,
> -- 
> 2.16.0
> 


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

[Mesa-dev] [PATCH] st/glsl_to_nir: remove reallocation of sampler/image location

[Timothy Arceri]

As far as I can tell this always just reassigns the same value.

Also as we don't curretly store UniformHash in the shader cache
removing this will help with adding a shader cache to gallium
nir drivers.
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 8 
 1 file changed, 8 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index c7843cada5..21b3640b2c 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -242,18 +242,10 @@ st_nir_assign_uniform_locations(struct gl_program *prog,
  continue;
 
   if (uniform->type->is_sampler() || uniform->type->is_image()) {
- unsigned val = 0;
- bool found = shader_program->UniformHash->get(val, uniform->name);
  if (uniform->type->is_sampler())
 loc = shaderidx++;
  else
 loc = imageidx++;
- assert(found);
- (void) found; /* silence unused var warning */
- /* this ensure that nir_lower_samplers looks at the correct
-  * shader_program->UniformStorage[location]:
-  */
- uniform->data.location = val;
   } else if (strncmp(uniform->name, "gl_", 3) == 0) {
  const gl_state_index *const stateTokens = (gl_state_index 
*)uniform->state_slots[0].tokens;
  /* This state reference has already been setup by ir_to_mesa, but 
we'll
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH v2 08/22] include/pipe: Define SPIRV as an IR

[Francisco Jerez]

Pierre Moreau  writes:

> On 2018-01-23 — 14:07, Jan Vesely wrote:
>> On Tue, 2018-01-23 at 01:33 +0100, Pierre Moreau wrote:
>> > Signed-off-by: Pierre Moreau 
>> > ---
>> >  src/gallium/include/pipe/p_defines.h | 1 +
>> >  1 file changed, 1 insertion(+)
>> > 
>> > diff --git a/src/gallium/include/pipe/p_defines.h 
>> > b/src/gallium/include/pipe/p_defines.h
>> > index b34e7a8570..082d4c4d87 100644
>> > --- a/src/gallium/include/pipe/p_defines.h
>> > +++ b/src/gallium/include/pipe/p_defines.h
>> > @@ -896,6 +896,7 @@ enum pipe_shader_ir
>> > PIPE_SHADER_IR_LLVM,
>> > PIPE_SHADER_IR_NATIVE,
>> > PIPE_SHADER_IR_NIR,
>> > +   PIPE_SHADER_IR_SPIRV
>> 
>> Why is this needed/useful? presumably the pipe driver will convert
>> SPIRV to NIR or LLVM anyway, why not convert it in clover and pass one
>> of the already existing IRs ?
>> 
>> Jan
>
> It is true it’s not really needed for this series, it’s mainly for my SPIR-V
> frontend for Nouveau. I could drop it from this series for now, especially if
> SPIR-V get directly translated to another IR and never stays as such, or going
> the opposite and always keeping SPIR-V until the very last moment.
>

I don't have any objection against plumbing through SPIRV directly if
that's the path you're planning to pursue.  But wouldn't it make sense
to have working back-end code able to consume it as input before adding
a new IR to the pipe driver interface?  Otherwise this is basically dead
code.

> Pierre
>
>> 
>> >  };
>> >  
>> >  /**


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

Re: [Mesa-dev] [PATCH v2 09/22] configure.ac, meson: Check for SPIRV-Tools

[Pierre Moreau]

On 2018-01-23 — 14:20, Jan Vesely wrote:
> On Tue, 2018-01-23 at 01:33 +0100, Pierre Moreau wrote:
> > Signed-off-by: Pierre Moreau 
> 
> do these tools handle the original SPIR format as well? can this be
> used to support cl_khr_spir?
> 
> Jan

They do not I’m afraid. I just saw that SPIR-Tools [1] exists, hosted by
Khronos as well, but I haven’t interacted with those tools in the slightest.

[1]: https://github.com/KhronosGroup/SPIR-Tools

Pierre

> 
> > ---
> >  configure.ac | 5 +
> >  meson.build  | 2 ++
> >  2 files changed, 7 insertions(+)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 7c1fbe0ed1..8c50ea6792 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -2373,6 +2373,11 @@ AM_CONDITIONAL(HAVE_CLOVER_ICD, test 
> > "x$enable_opencl_icd" = xyes)
> >  AC_SUBST([OPENCL_LIBNAME])
> >  AC_SUBST([CLANG_RESOURCE_DIR])
> >  
> > +AS_IF([test "x$enable_opencl" = xyes], [
> > +PKG_CHECK_MODULES([SPIRV_TOOLS], [SPIRV-Tools >= 2017.3])])
> > +AC_SUBST([SPIRV_TOOLS_CFLAGS])
> > +AC_SUBST([SPIRV_TOOLS_LIBS])
> > +
> >  dnl
> >  dnl Gallium configuration
> >  dnl
> > diff --git a/meson.build b/meson.build
> > index f3179c3806..78315020fa 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -596,10 +596,12 @@ if _opencl != 'disabled'
> >  
> ># TODO: alitvec?
> >dep_clc = dependency('libclc')
> > +  dep_spirv_tools = dependency('SPIRV-Tools', version : '>= 2017.3')
> >with_gallium_opencl = true
> >with_opencl_icd = _opencl == 'icd'
> >  else
> >dep_clc = []
> > +  dep_spirv_tools = []
> >with_gallium_opencl = false
> >with_gallium_icd = false
> >  endif


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

Re: [Mesa-dev] [PATCH v2 08/22] include/pipe: Define SPIRV as an IR

[Pierre Moreau]

On 2018-01-23 — 14:07, Jan Vesely wrote:
> On Tue, 2018-01-23 at 01:33 +0100, Pierre Moreau wrote:
> > Signed-off-by: Pierre Moreau 
> > ---
> >  src/gallium/include/pipe/p_defines.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/src/gallium/include/pipe/p_defines.h 
> > b/src/gallium/include/pipe/p_defines.h
> > index b34e7a8570..082d4c4d87 100644
> > --- a/src/gallium/include/pipe/p_defines.h
> > +++ b/src/gallium/include/pipe/p_defines.h
> > @@ -896,6 +896,7 @@ enum pipe_shader_ir
> > PIPE_SHADER_IR_LLVM,
> > PIPE_SHADER_IR_NATIVE,
> > PIPE_SHADER_IR_NIR,
> > +   PIPE_SHADER_IR_SPIRV
> 
> Why is this needed/useful? presumably the pipe driver will convert
> SPIRV to NIR or LLVM anyway, why not convert it in clover and pass one
> of the already existing IRs ?
> 
> Jan

It is true it’s not really needed for this series, it’s mainly for my SPIR-V
frontend for Nouveau. I could drop it from this series for now, especially if
SPIR-V get directly translated to another IR and never stays as such, or going
the opposite and always keeping SPIR-V until the very last moment.

Pierre

> 
> >  };
> >  
> >  /**


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

Re: [Mesa-dev] [PATCH 00/20] Add support for GL_EXT_semaphore v3

[Andres Rodriguez]

Also, the associated piglit patches:
https://lists.freedesktop.org/archives/piglit/2017-December/023600.html


On 2018-01-23 01:13 PM, Andres Rodriguez wrote:



On 2018-01-23 01:04 PM, Andres Rodriguez wrote:

Rebased on latest mesa and dropped the gallium fence->semaphore rename.


There is also a new bugfix on patch 7. See v3 notes there.



Andres Rodriguez (20):
   gallium: add type parameter to create_fence_fd
   gallium: introduce PIPE_CAP_SEMAPHORE_SIGNAL
   gallium: introduce PIPE_FD_TYPE_SYNCOBJ
   gallium: add fence_server_signal()
   u_threaded_context: add support for fence_server_signal v2
   mesa/st: introduce EXT_semaphore and EXT_semaphore_fd v2
   mesa: add support for semaphore object creation/import/delete v3
   mesa/st: add support for semaphore object create/import/delete v2
   mesa: add semaphore parameter stub v2
   mesa: add support for semaphore object signal/wait v2
   mesa/st: add support for semaphore object signal/wait v3
   mesa: implement buffer/texture barriers for semaphore signal/wait v2
   winsys/amdgpu: add support for syncobj signaling v3
   radeonsi: add support for importing PIPE_FD_TYPE_SYNCOBJ semaphores
   radeonsi: implement semaphore_server_signal v2
   radeonsi: fix fence_server_sync() holding up extra work v2
   radeonsi: advertise support for GL_EXT_semaphore
   mesa: fix error codes for importing memory/semaphore FDs
   mesa: fix glGet for ext_external_objects parameters
   mesa: check for invalid index on UUID glGet queries

  src/gallium/auxiliary/util/u_tests.c   |   7 +-
  src/gallium/auxiliary/util/u_threaded_context.c    |  25 ++-
  .../auxiliary/util/u_threaded_context_calls.h  |   1 +
  src/gallium/docs/source/context.rst    |  31 +++
  src/gallium/docs/source/screen.rst |   2 +
  src/gallium/drivers/etnaviv/etnaviv_fence.c    |   4 +-
  src/gallium/drivers/etnaviv/etnaviv_fence.h    |   3 +-
  src/gallium/drivers/etnaviv/etnaviv_screen.c   |   1 +
  src/gallium/drivers/freedreno/freedreno_fence.c    |   4 +-
  src/gallium/drivers/freedreno/freedreno_fence.h    |   3 +-
  src/gallium/drivers/freedreno/freedreno_screen.c   |   1 +
  src/gallium/drivers/i915/i915_screen.c |   1 +
  src/gallium/drivers/llvmpipe/lp_screen.c   |   1 +
  src/gallium/drivers/nouveau/nv30/nv30_screen.c |   1 +
  src/gallium/drivers/nouveau/nv50/nv50_screen.c |   1 +
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c |   1 +
  src/gallium/drivers/r300/r300_screen.c |   1 +
  src/gallium/drivers/r600/r600_pipe.c   |   1 +
  src/gallium/drivers/radeon/radeon_winsys.h |  12 ++
  src/gallium/drivers/radeonsi/si_fence.c    | 113 ---
  src/gallium/drivers/radeonsi/si_get.c  |   3 +
  src/gallium/drivers/radeonsi/si_pipe.c |   1 -
  src/gallium/drivers/softpipe/sp_screen.c   |   1 +
  src/gallium/drivers/svga/svga_pipe_flush.c |   4 +-
  src/gallium/drivers/svga/svga_screen.c |   1 +
  src/gallium/drivers/swr/swr_screen.cpp |   1 +
  src/gallium/drivers/vc4/vc4_screen.c   |   1 +
  src/gallium/drivers/virgl/virgl_screen.c   |   1 +
  src/gallium/include/pipe/p_context.h   |  14 +-
  src/gallium/include/pipe/p_defines.h   |   7 +
  src/gallium/state_trackers/dri/dri_helpers.c   |   2 +-
  src/gallium/winsys/amdgpu/drm/amdgpu_cs.c  |  83 +++-
  src/gallium/winsys/amdgpu/drm/amdgpu_cs.h  |   4 +
  src/mesa/Makefile.sources  |   2 +
  src/mesa/main/dd.h |  58 ++
  src/mesa/main/extensions_table.h   |   2 +
  src/mesa/main/externalobjects.c    | 224 
-

  src/mesa/main/externalobjects.h    |  31 ++-
  src/mesa/main/get.c    |   7 +
  src/mesa/main/get_hash_params.py   |   5 +
  src/mesa/main/mtypes.h |  10 +
  src/mesa/main/shared.c |  17 ++
  src/mesa/meson.build   |   2 +
  src/mesa/state_tracker/st_cb_semaphoreobjects.c    | 129 
  src/mesa/state_tracker/st_cb_semaphoreobjects.h    |  25 +++
  src/mesa/state_tracker/st_context.c    |   2 +
  src/mesa/state_tracker/st_extensions.c |   2 +
  47 files changed, 805 insertions(+), 48 deletions(-)
  create mode 100644 src/mesa/state_tracker/st_cb_semaphoreobjects.c
  create mode 100644 src/mesa/state_tracker/st_cb_semaphoreobjects.h


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

Re: [Mesa-dev] [PATCH 2/2] [RFC] radv: use separate bindings for graphics and compute descriptors

[Bas Nieuwenhuizen]

On Tue, Jan 23, 2018 at 2:27 PM, Samuel Pitoiset
 wrote:
> The Vulkan spec says:
>
>"pipelineBindPoint is a VkPipelineBindPoint indicating whether
> the descriptors will be used by graphics pipelines or compute
> pipelines. There is a separate set of bind points for each of
> graphics and compute, so binding one does not disturb the other."
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104732
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 138 
> ++-
>  src/amd/vulkan/radv_meta.c   |  21 +-
>  src/amd/vulkan/radv_private.h|  53 +--
>  3 files changed, 159 insertions(+), 53 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 1143aa085f..540dc8a057 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -261,7 +261,8 @@ radv_cmd_buffer_destroy(struct radv_cmd_buffer 
> *cmd_buffer)
> if (cmd_buffer->upload.upload_bo)
> 
> cmd_buffer->device->ws->buffer_destroy(cmd_buffer->upload.upload_bo);
> cmd_buffer->device->ws->cs_destroy(cmd_buffer->cs);
> -   free(cmd_buffer->push_descriptors.set.mapped_ptr);
> +   free(cmd_buffer->graphics_push_descriptors.set.mapped_ptr);
> +   free(cmd_buffer->compute_push_descriptors.set.mapped_ptr);
> vk_free(_buffer->pool->alloc, cmd_buffer);
>  }
>
> @@ -482,21 +483,31 @@ radv_save_pipeline(struct radv_cmd_buffer *cmd_buffer,
>  }
>
>  void radv_set_descriptor_set(struct radv_cmd_buffer *cmd_buffer,
> +VkPipelineBindPoint bind_point,
>  struct radv_descriptor_set *set,
>  unsigned idx)
>  {
> -   cmd_buffer->descriptors[idx] = set;
> +   struct radv_descriptor_state *descriptors_state =
> +   radv_get_descriptors_state(cmd_buffer, bind_point);
> +   struct radv_descriptor_set **descriptors =
> +   radv_get_descriptors_set(cmd_buffer, bind_point);
> +
> +   descriptors[idx] = set;
> if (set)
> -   cmd_buffer->state.valid_descriptors |= (1u << idx);
> +   descriptors_state->valid |= (1u << idx);
> else
> -   cmd_buffer->state.valid_descriptors &= ~(1u << idx);
> -   cmd_buffer->state.descriptors_dirty |= (1u << idx);
> -
> +   descriptors_state->valid &= ~(1u << idx);
> +   descriptors_state->dirty |= (1u << idx);
>  }
>
>  static void
> -radv_save_descriptors(struct radv_cmd_buffer *cmd_buffer)
> +radv_save_descriptors(struct radv_cmd_buffer *cmd_buffer,
> + VkPipelineBindPoint bind_point)
>  {
> +   struct radv_descriptor_state *descriptors_state =
> +   radv_get_descriptors_state(cmd_buffer, bind_point);
> +   struct radv_descriptor_set **descriptors =
> +   radv_get_descriptors_set(cmd_buffer, bind_point);
> struct radv_device *device = cmd_buffer->device;
> struct radeon_winsys_cs *cs = cmd_buffer->cs;
> uint32_t data[MAX_SETS * 2] = {};
> @@ -507,8 +518,8 @@ radv_save_descriptors(struct radv_cmd_buffer *cmd_buffer)
> MAYBE_UNUSED unsigned cdw_max = radeon_check_space(device->ws,
>cmd_buffer->cs, 4 
> + MAX_SETS * 2);
>
> -   for_each_bit(i, cmd_buffer->state.valid_descriptors) {
> -   struct radv_descriptor_set *set = cmd_buffer->descriptors[i];
> +   for_each_bit(i, descriptors_state->valid) {
> +   struct radv_descriptor_set *set = descriptors[i];
> data[i * 2] = (uintptr_t)set;
> data[i * 2 + 1] = (uintptr_t)set >> 32;
> }
> @@ -1705,9 +1716,12 @@ radv_emit_descriptor_set_userdata(struct 
> radv_cmd_buffer *cmd_buffer,
>  }
>
>  static void
> -radv_flush_push_descriptors(struct radv_cmd_buffer *cmd_buffer)
> +radv_flush_push_descriptors(struct radv_cmd_buffer *cmd_buffer,
> +   VkPipelineBindPoint bind_point)
>  {
> -   struct radv_descriptor_set *set = _buffer->push_descriptors.set;
> +   struct radv_push_descriptor_set *push_descriptors =
> +   radv_get_push_descriptors(cmd_buffer, bind_point);
> +   struct radv_descriptor_set *set = _descriptors->set;
> unsigned bo_offset;
>
> if (!radv_cmd_buffer_upload_data(cmd_buffer, set->size, 32,
> @@ -1720,8 +1734,13 @@ radv_flush_push_descriptors(struct radv_cmd_buffer 
> *cmd_buffer)
>  }
>
>  static void
> -radv_flush_indirect_descriptor_sets(struct radv_cmd_buffer *cmd_buffer)
> +radv_flush_indirect_descriptor_sets(struct radv_cmd_buffer *cmd_buffer,
> +   VkPipelineBindPoint bind_point)
>  {
> +   struct radv_descriptor_set **descriptors =
> +   radv_get_descriptors_set(cmd_buffer, bind_point);

[Mesa-dev] [PATCH] ac/nir: call glsl_get_sampler_dim() only once, where possible (v2)

[Kai Wasserbäch]

Changes since v1:
  * Rebased on top of e68150de263156a3f3d1b609b6506c5649967f61 and
82adf53308c137ce0dc5f2d5da4e7cc40c5b808c.

Cc: Timothy Arceri 
Tested-by: Dieter Nützel  (v1)
Signed-off-by: Kai Wasserbäch 
---

Hey,
if you accept this patch, please commit it for me – I do not have commit
access. This is v2, which is needed since the above mentioned changes
by Timothy went in first.

Thanks,
Kai

 src/amd/common/ac_nir_to_llvm.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index cc3af77386..0fba5a1068 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3620,7 +3620,9 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
type = instr->variables[0]->deref.child->type;
 
type = glsl_without_array(type);
-   if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
+
+   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
+   if (dim == GLSL_SAMPLER_DIM_BUF) {
params[0] = get_sampler_desc(ctx, instr->variables[0], 
AC_DESC_BUFFER, NULL, true, false);
params[1] = LLVMBuildExtractElement(ctx->ac.builder, 
get_src(ctx, instr->src[0]),
ctx->ac.i32_0, ""); /* 
vindex */
@@ -3634,10 +3636,10 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
res = ac_to_integer(>ac, res);
} else {
bool is_da = glsl_sampler_type_is_array(type) ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE ||
-glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D 
||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS_MS;
+dim == GLSL_SAMPLER_DIM_CUBE ||
+dim == GLSL_SAMPLER_DIM_3D ||
+dim == GLSL_SAMPLER_DIM_SUBPASS ||
+dim == GLSL_SAMPLER_DIM_SUBPASS_MS;
LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
LLVMValueRef glc = ctx->ac.i1false;
LLVMValueRef slc = ctx->ac.i1false;
@@ -3677,12 +3679,13 @@ static void visit_image_store(struct ac_nir_context 
*ctx,
char intrinsic_name[64];
const nir_variable *var = instr->variables[0]->var;
const struct glsl_type *type = glsl_without_array(var->type);
+   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
LLVMValueRef glc = ctx->ac.i1false;
bool force_glc = ctx->ac.chip_class == SI;
if (force_glc)
glc = ctx->ac.i1true;
 
-   if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
+   if (dim == GLSL_SAMPLER_DIM_BUF) {
params[0] = ac_to_float(>ac, get_src(ctx, instr->src[2])); 
/* data */
params[1] = get_sampler_desc(ctx, instr->variables[0], 
AC_DESC_BUFFER, NULL, true, true);
params[2] = LLVMBuildExtractElement(ctx->ac.builder, 
get_src(ctx, instr->src[0]),
@@ -3694,8 +3697,8 @@ static void visit_image_store(struct ac_nir_context *ctx,
   params, 6, 0);
} else {
bool is_da = glsl_sampler_type_is_array(type) ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE ||
-glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D;
+dim == GLSL_SAMPLER_DIM_CUBE ||
+dim == GLSL_SAMPLER_DIM_3D;
LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
LLVMValueRef slc = ctx->ac.i1false;
 
-- 
2.15.1

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

Re: [Mesa-dev] Logging infrastructure?

[Ilia Mirkin]

On Jan 22, 2018 09:02, "Kenneth Graunke"  wrote:

On Thursday, January 18, 2018 1:44:47 PM PST Chuck Atkins wrote:
> Is there a logging infrastructure currently available to drivers in Mesa?
> I was looking to clean up some of swr's debug / info output and have it
> conditional on the MESA_DEBUG and LIBGL_DEBUG variables but then I
realized
> that it's really something useful all across mesa so there may already be
> something there for it.  If not though, I'd be interested in adding some
> very light weight functions for just that purpose could be used by any
> driver rather than just fprintf(stderr, ...);
>
>
> - Chuck

What about Gallium's pipe_debug_message / pipe_debug_callback?


That's mostly there for KHR_debug and related functionality.

P.s. sorry about the empty mail from a minute ago.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Logging infrastructure?

[Ilia Mirkin]

On Jan 22, 2018 09:02, "Kenneth Graunke"  wrote:

On Thursday, January 18, 2018 1:44:47 PM PST Chuck Atkins wrote:
> Is there a logging infrastructure currently available to drivers in Mesa?
> I was looking to clean up some of swr's debug / info output and have it
> conditional on the MESA_DEBUG and LIBGL_DEBUG variables but then I
realized
> that it's really something useful all across mesa so there may already be
> something there for it.  If not though, I'd be interested in adding some
> very light weight functions for just that purpose could be used by any
> driver rather than just fprintf(stderr, ...);
>
>
> - Chuck

What about Gallium's pipe_debug_message / pipe_debug_callback?





--Ken

___
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] radv: don't use hw resolve for integer image formats

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Tue, Jan 23, 2018 at 6:52 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> From reading AMDVLK it currently never uses hw resolve paths.
>
> This patch takes from radeonsi which doesn't use hw resolve
> for integer formats, and does the same for radv.
>
> This fixes:
> dEQP-VK.renderpass.suballocation.multisample*uint tests.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_meta_resolve.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_meta_resolve.c 
> b/src/amd/vulkan/radv_meta_resolve.c
> index d44e16e..d2b9c3c 100644
> --- a/src/amd/vulkan/radv_meta_resolve.c
> +++ b/src/amd/vulkan/radv_meta_resolve.c
> @@ -26,6 +26,7 @@
>
>  #include "radv_meta.h"
>  #include "radv_private.h"
> +#include "vk_format.h"
>  #include "nir/nir_builder.h"
>  #include "sid.h"
>
> @@ -351,6 +352,10 @@ static void radv_pick_resolve_method_images(struct 
> radv_image *src_image,
> uint32_t queue_mask = radv_image_queue_family_mask(dest_image,
>
> cmd_buffer->queue_family_index,
>
> cmd_buffer->queue_family_index);
> +
> +   if (vk_format_is_int(src_image->vk_format))
> +   *method = RESOLVE_COMPUTE;
> +
> if (radv_layout_dcc_compressed(dest_image, dest_image_layout, 
> queue_mask)) {
> *method = RESOLVE_FRAGMENT;
> } else if (dest_image->surface.micro_tile_mode != 
> src_image->surface.micro_tile_mode) {
> --
> 2.9.5
>
> ___
> 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 1/2] radv: add fs_key meta format support to resolve passes.

[Bas Nieuwenhuizen]

On Tue, Jan 23, 2018 at 6:52 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> Some of the hw resolve passes need the SPI color format setup
> correctly.
>
> This fixes lots of 16-bit and 32-bit format tests in
> dEQP-VK.renderpass.suballocation.multisample*
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_meta_resolve.c | 87 
> ++
>  src/amd/vulkan/radv_private.h  |  4 +-
>  2 files changed, 61 insertions(+), 30 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_resolve.c 
> b/src/amd/vulkan/radv_meta_resolve.c
> index 49326fe..d44e16e 100644
> --- a/src/amd/vulkan/radv_meta_resolve.c
> +++ b/src/amd/vulkan/radv_meta_resolve.c
> @@ -50,7 +50,7 @@ build_nir_fs(void)
>  }
>
>  static VkResult
> -create_pass(struct radv_device *device)
> +create_pass(struct radv_device *device, VkFormat vk_format, VkRenderPass 
> *pass)
>  {
> VkResult result;
> VkDevice device_h = radv_device_to_handle(device);
> @@ -59,7 +59,7 @@ create_pass(struct radv_device *device)
> int i;
>
> for (i = 0; i < 2; i++) {
> -   attachments[i].format = VK_FORMAT_UNDEFINED;
> +   attachments[i].format = vk_format;
> attachments[i].samples = 1;
> attachments[i].loadOp = VK_ATTACHMENT_LOAD_OP_LOAD;
> attachments[i].storeOp = VK_ATTACHMENT_STORE_OP_STORE;
> @@ -99,14 +99,16 @@ create_pass(struct radv_device *device)
> 
> .dependencyCount = 0,
>  },
>alloc,
> -  >meta_state.resolve.pass);
> +  pass);
>
> return result;
>  }
>
>  static VkResult
>  create_pipeline(struct radv_device *device,
> -VkShaderModule vs_module_h)
> +VkShaderModule vs_module_h,
> +VkPipeline *pipeline,
> +VkRenderPass pass)
>  {
> VkResult result;
> VkDevice device_h = radv_device_to_handle(device);
> @@ -129,12 +131,14 @@ create_pipeline(struct radv_device *device,
> .pPushConstantRanges = NULL,
> };
>
> -   result = radv_CreatePipelineLayout(radv_device_to_handle(device),
> -  _create_info,
> -  >meta_state.alloc,
> -  
> >meta_state.resolve.p_layout);
> -   if (result != VK_SUCCESS)
> -   goto cleanup;
> +   if (!device->meta_state.resolve.p_layout) {
> +   result = 
> radv_CreatePipelineLayout(radv_device_to_handle(device),
> +  _create_info,
> +  >meta_state.alloc,
> +  
> >meta_state.resolve.p_layout);
> +   if (result != VK_SUCCESS)
> +   goto cleanup;
> +   }
>
> result = radv_graphics_pipeline_create(device_h,
>
> radv_pipeline_cache_to_handle(>meta_state.cache),
> @@ -212,15 +216,14 @@ create_pipeline(struct radv_device *device,
> },
> },
> .layout = 
> device->meta_state.resolve.p_layout,
> - 
>  .renderPass = 
> device->meta_state.resolve.pass,
> +   .renderPass = pass,
>   
>  .subpass = 0,
>   
>  },
>&(struct 
> radv_graphics_pipeline_create_info) {
>.use_rectlist = true,
>.custom_blend_mode = 
> V_028808_CB_RESOLVE,
>},
> -  >meta_state.alloc,
> -  
> >meta_state.resolve.pipeline);
> +  >meta_state.alloc, 
> pipeline);
> if (result != VK_SUCCESS)
> goto cleanup;
>
> @@ -236,19 +239,37 @@ radv_device_finish_meta_resolve_state(struct 
> radv_device *device)
>  {
> struct radv_meta_state *state = >meta_state;
>
> -   

Re: [Mesa-dev] [PATCH v2 09/22] configure.ac, meson: Check for SPIRV-Tools

[Jan Vesely]

On Tue, 2018-01-23 at 01:33 +0100, Pierre Moreau wrote:
> Signed-off-by: Pierre Moreau 

do these tools handle the original SPIR format as well? can this be
used to support cl_khr_spir?

Jan

> ---
>  configure.ac | 5 +
>  meson.build  | 2 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/configure.ac b/configure.ac
> index 7c1fbe0ed1..8c50ea6792 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2373,6 +2373,11 @@ AM_CONDITIONAL(HAVE_CLOVER_ICD, test 
> "x$enable_opencl_icd" = xyes)
>  AC_SUBST([OPENCL_LIBNAME])
>  AC_SUBST([CLANG_RESOURCE_DIR])
>  
> +AS_IF([test "x$enable_opencl" = xyes], [
> +PKG_CHECK_MODULES([SPIRV_TOOLS], [SPIRV-Tools >= 2017.3])])
> +AC_SUBST([SPIRV_TOOLS_CFLAGS])
> +AC_SUBST([SPIRV_TOOLS_LIBS])
> +
>  dnl
>  dnl Gallium configuration
>  dnl
> diff --git a/meson.build b/meson.build
> index f3179c3806..78315020fa 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -596,10 +596,12 @@ if _opencl != 'disabled'
>  
># TODO: alitvec?
>dep_clc = dependency('libclc')
> +  dep_spirv_tools = dependency('SPIRV-Tools', version : '>= 2017.3')
>with_gallium_opencl = true
>with_opencl_icd = _opencl == 'icd'
>  else
>dep_clc = []
> +  dep_spirv_tools = []
>with_gallium_opencl = false
>with_gallium_icd = false
>  endif


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 v4 02/10] mesa/st/glsl_to_tgsi: Add some operators for glsl_to_tgsi related classes

[Brian Paul]

Just some nit-picks below.


On 01/23/2018 03:11 AM, Gert Wollny wrote:

Add the equal operator and the "<<" stream write operator for the
st_*_reg classes and the "<<" operator to the instruction class, and
make use of these operators in the debugging output.
---
  src/mesa/state_tracker/st_glsl_to_tgsi_private.cpp | 168 +
  src/mesa/state_tracker/st_glsl_to_tgsi_private.h   |  19 +++
  .../state_tracker/st_glsl_to_tgsi_temprename.cpp   | 105 +++--
  3 files changed, 204 insertions(+), 88 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_private.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi_private.cpp
index b664fa7ec3..b098a20754 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi_private.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi_private.cpp
@@ -26,6 +26,7 @@
  #include "st_glsl_to_tgsi_private.h"
  #include 
  #include 
+#include 
  
  static int swizzle_for_type(const glsl_type *type, int component = 0)

  {
@@ -179,6 +180,81 @@ st_src_reg st_src_reg::get_abs()
 return reg;
  }
  
+bool operator == (const st_src_reg& lhs, const st_src_reg& rhs)

+{
+   bool result;
+
+   if (lhs.type != rhs.type ||
+   lhs.file != rhs.file ||
+   lhs.index != rhs.index ||
+   lhs.swizzle != rhs.swizzle ||
+   lhs.index2D != rhs.index2D ||
+   lhs.has_index2 != rhs.has_index2 ||
+   lhs.array_id != rhs.array_id ||
+   lhs.negate != rhs.negate ||
+   lhs.abs != rhs.abs ||
+   lhs.double_reg2 != rhs.double_reg2 ||
+   lhs.is_double_vertex_input != rhs.is_double_vertex_input)
+  return false;
+
+


Just one empty line.  Same below.


+   if (lhs.reladdr) {
+  if (!rhs.reladdr)
+ return false;
+  result = (*lhs.reladdr == *rhs.reladdr);
+   } else {
+  result = !rhs.reladdr;
+   }
+
+   if (lhs.reladdr2) {
+  if (!rhs.reladdr2)
+ return false;
+  result &= (*lhs.reladdr2 == *rhs.reladdr2);
+   } else {
+  result &= !rhs.reladdr2;
+   }


Maybe insert empty line here though.  Same below.


+   return result;
+}
+
+static const char swz_txt[] = "xyzw";
+
+std::ostream& operator << (std::ostream& os, const st_src_reg& reg)
+{
+


rm empty line here.


+   if (reg.negate)
+  os << "-";
+   if (reg.abs)
+  os << "|";
+
+   os << _mesa_register_file_name(reg.file);
+
+   if (reg.file == PROGRAM_ARRAY) {
+  os << "(" << reg.array_id << ")";
+   }
+   if (reg.has_index2) {
+  os << "[";
+  if (reg.reladdr2) {
+ os << *reg.reladdr2;
+  }
+  os << "+" << reg.index2D << "]";
+   }
+   os << "[";
+   if (reg.reladdr) {
+  os << *reg.reladdr;
+   }
+   os << reg.index << "].";
+   for (int i = 0; i < 4; ++i) {
+  int swz = GET_SWZ(reg.swizzle, i);
+  if (swz < 4)
+ os << swz_txt[swz];
+  else
+ os << "_";
+   }
+   if (reg.abs)
+  os << "|";
+   return os;
+}
+
  st_dst_reg::st_dst_reg(st_src_reg reg)
  {
 this->type = reg.type;
@@ -250,3 +326,95 @@ void st_dst_reg::operator=(const st_dst_reg )
 this->has_index2 = reg.has_index2;
 this->array_id = reg.array_id;
  }
+
+bool operator == (const st_dst_reg& lhs, const st_dst_reg& rhs)
+{
+   bool result;
+
+   if (lhs.type != rhs.type ||
+   lhs.file != rhs.file ||
+   lhs.index != rhs.index ||
+   lhs.writemask != rhs.writemask ||
+   lhs.index2D != rhs.index2D ||
+   lhs.has_index2 != rhs.has_index2 ||
+   lhs.array_id != rhs.array_id)
+  return false;
+
+
+   if (lhs.reladdr) {
+  if (!rhs.reladdr)
+ return false;
+  result = (*lhs.reladdr == *rhs.reladdr);
+   } else {
+  result = !rhs.reladdr;
+   }
+
+   if (lhs.reladdr2) {
+  if (!rhs.reladdr2)
+ return false;
+  result &= (*lhs.reladdr2 == *rhs.reladdr2);
+   } else {
+  result &= !rhs.reladdr2;
+   }
+   return result;
+}
+
+std::ostream& operator << (std::ostream& os, const st_dst_reg& reg)
+{
+
+   os << _mesa_register_file_name(reg.file);
+   if (reg.file == PROGRAM_ARRAY) {
+  os << "(" << reg.array_id << ")";
+   }
+   if (reg.has_index2) {
+  os << "[";
+  if (reg.reladdr2) {
+ os << *reg.reladdr2;
+  }
+  os << "+" << reg.index2D << "]";
+   }
+   os << "[";
+   if (reg.reladdr) {
+  os << *reg.reladdr;
+   }
+   os << reg.index << "].";
+   for (int i = 0; i < 4; ++i) {
+  if (1 << i & reg.writemask)
+ os << swz_txt[i];
+  else
+ os << "_";
+   }
+
+   return os;
+}
+
+void glsl_to_tgsi_instruction::print(std::ostream& os) const
+{
+   os << tgsi_get_opcode_name(info->opcode) << " ";
+
+   bool has_operators = false;
+   for (unsigned j = 0; j < num_inst_dst_regs(this); j++) {
+  has_operators = true;
+  if (j > 0)
+ os << ", ";
+  os << dst[j];
+   }
+
+   if (has_operators)
+  os << " := ";
+
+   for (unsigned j = 0; j < num_inst_src_regs(this); j++) {
+  if (j > 0)
+ os << ", ";
+  os << src[j];
+   }
+
+   if (tex_offset_num_offset > 0) {

Re: [Mesa-dev] [PATCH v4 03/10] mesa/st/tests: Fix zero-byte allocation leaks

[Brian Paul]

On 01/23/2018 03:11 AM, Gert Wollny wrote:

Don't allocate a zero-sized array, when no texture offsets are given.

Reviewed-by: Nicolai Hähnle 
Signed-off-by: Gert Wollny 
---
  .../tests/test_glsl_to_tgsi_lifetime.cpp   | 23 +++---
  1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/src/mesa/state_tracker/tests/test_glsl_to_tgsi_lifetime.cpp 
b/src/mesa/state_tracker/tests/test_glsl_to_tgsi_lifetime.cpp
index 93f4020ebf..d0ac8b1020 100644
--- a/src/mesa/state_tracker/tests/test_glsl_to_tgsi_lifetime.cpp
+++ b/src/mesa/state_tracker/tests/test_glsl_to_tgsi_lifetime.cpp
@@ -1374,10 +1374,14 @@ MockShader::MockShader(const 
vector& source):
   next_instr->dst[k] = create_dst_register(i.dst[k].first, 
i.dst[k].second);
}
next_instr->tex_offset_num_offset = i.tex_offsets.size();
-  next_instr->tex_offsets = new st_src_reg[i.tex_offsets.size()];
-  for (unsigned k = 0; k < i.tex_offsets.size(); ++k) {
- next_instr->tex_offsets[k] = 
create_src_register(i.tex_offsets[k].first,
-  
i.tex_offsets[k].second);
+  if (next_instr->tex_offset_num_offset > 0) {
+ next_instr->tex_offsets = new st_src_reg[i.tex_offsets.size()];
+ for (unsigned k = 0; k < i.tex_offsets.size(); ++k) {
+next_instr->tex_offsets[k] = 
create_src_register(i.tex_offsets[k].first,
+ 
i.tex_offsets[k].second);
+ }
+  } else {
+ next_instr->tex_offsets = nullptr;
}
program->push_tail(next_instr);
 }
@@ -1407,10 +1411,15 @@ MockShader::MockShader(const vector& 
source):
   next_instr->dst[k] = create_dst_register(i.dst[k]);
}
next_instr->tex_offset_num_offset = i.tex_offsets.size();
-  next_instr->tex_offsets = new st_src_reg[i.tex_offsets.size()];
-  for (unsigned k = 0; k < i.tex_offsets.size(); ++k) {
- next_instr->tex_offsets[k] = create_src_register(i.tex_offsets[k]);
+  if (next_instr->tex_offset_num_offset > 0) {
+ next_instr->tex_offsets = new st_src_reg[i.tex_offsets.size()];
+ for (unsigned k = 0; k < i.tex_offsets.size(); ++k) {
+next_instr->tex_offsets[k] = create_src_register(i.tex_offsets[k]);
+ }
+  } else {
+ next_instr->tex_offsets = nullptr;
}
+


Stray whitespace change?


program->push_tail(next_instr);
 }
 ++num_temps;



Could you repost all the patches in the final series?

Otherwise, for 1,2,3,6: Reviewed-by: Brian Paul 


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

Re: [Mesa-dev] [PATCH v2 08/22] include/pipe: Define SPIRV as an IR

[Jan Vesely]

On Tue, 2018-01-23 at 01:33 +0100, Pierre Moreau wrote:
> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/include/pipe/p_defines.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/include/pipe/p_defines.h 
> b/src/gallium/include/pipe/p_defines.h
> index b34e7a8570..082d4c4d87 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -896,6 +896,7 @@ enum pipe_shader_ir
> PIPE_SHADER_IR_LLVM,
> PIPE_SHADER_IR_NATIVE,
> PIPE_SHADER_IR_NIR,
> +   PIPE_SHADER_IR_SPIRV

Why is this needed/useful? presumably the pipe driver will convert
SPIRV to NIR or LLVM anyway, why not convert it in clover and pass one
of the already existing IRs ?

Jan

>  };
>  
>  /**


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

[Mesa-dev] [Bug 104752] Account Request for Chuck Atkins

[bugzilla-daemon]

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

Brian Paul  changed:

   What|Removed |Added

  Component|Other   |New Accounts
Product|Mesa|freedesktop.org
   Assignee|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes
   |org |ktop.org
 QA Contact|mesa-dev@lists.freedesktop. |
   |org |

--- Comment #5 from Brian Paul  ---
OK by me.  Reassigning to fd.o admins.

-- 
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 104742] [swrast] piglit gl-1.4-dlist-multidrawarrays regression

[bugzilla-daemon]

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

--- Comment #1 from Brian Paul  ---
Vinson, I posted a patch to mesa-dev to which fixes this and 104746.  If you
can test too, that'd be helpful.

-- 
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] swr: refactor swr_create_screen to allow for proper cleanup on error

[Emil Velikov]

On 22 January 2018 at 18:02, Chuck Atkins  wrote:
> Hi Emil,
>
>> Fixes: a4be2bcee2f ("swr: allow a single swr architecture to be builtin")
>
>
> It doesn't fix anything that was broken from that commit.  The issues with
> error handling were already present before then, it's just that the changes
> in a4be2bcee2f were substantial so this commit works off the result of the
> previous.  So really it would be "Depends on: " rather than "Fixes: ".
>
Right - "depends on" is better, yet we don't have the concept/tools to
handle it.

>
>>
>> Right this cleans up after the following commit - please include the tag.
>> Don't bother re-sending.
>
>
> Not sure how I would go about that since I don't have push access.  The ML
> is really the only mechanism I have to send commits to the git repo.  Given
> that I've been submitting patches from time to time for the past two years
> or so (not often, but every few months I have a handful), should I go ahead
> and apply for an account now?
>
My bad - I thought you already had one. Your acc. request should be
sorted out shortly.

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

[Mesa-dev] [Bug 104749] rasterizer/jitter/JitManager.cpp:252:91: error: no matching function for call to ‘llvm::DIBuilder::createBasicType(const char [8], int, llvm::dwarf::TypeKind)’

[bugzilla-daemon]

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

--- Comment #1 from Juan A. Suarez  ---
Tracked to:

commit 01ab218bbc5c8058a99077a6bc3dc9884e9d218a
Author: George Kyriazis 
Date:   Fri Jan 19 15:46:59 2018 -0600

swr/rast: Initial work for debugging support.

Adds ability to step into jitted llvm IR in Visual Studio.
- Updated llvm type generation script to also generate corresponding debug
types.
- New module pass inserts debug metadata into the IR for each function

Disabled by default.

Reviewed-by: Bruce Cherniak 

 .../swr/rasterizer/codegen/gen_llvm_types.py   |  10 +-
 .../swr/rasterizer/codegen/templates/gen_llvm.hpp  |  12 ++
 .../drivers/swr/rasterizer/jitter/JitManager.cpp   | 157 +++--
 .../drivers/swr/rasterizer/jitter/JitManager.h |  24 
 .../drivers/swr/rasterizer/jitter/builder_misc.cpp |   2 +-
 .../drivers/swr/rasterizer/jitter/jit_pch.hpp  |   2 +-
 6 files changed, 191 insertions(+), 16 deletions(-)

-- 
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] [PATCH] vbo: fix incorrect min/max_index values in display list draw call

[Brian Paul]

This fixes another regression from commit 8e4efdc895ea ("vbo: optimize
some display list drawing").  The problem was the min_index, max_index
values passed to the vbo drawing function were not computed to compensate
for the biased prim::start values.

https://bugs.freedesktop.org/show_bug.cgi?id=104746
https://bugs.freedesktop.org/show_bug.cgi?id=104742
https://bugs.freedesktop.org/show_bug.cgi?id=104690
---
 src/mesa/vbo/vbo_save.h  | 3 ++-
 src/mesa/vbo/vbo_save_api.c  | 3 +++
 src/mesa/vbo/vbo_save_draw.c | 5 +++--
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/mesa/vbo/vbo_save.h b/src/mesa/vbo/vbo_save.h
index 04b9e38..51ea9cc 100644
--- a/src/mesa/vbo/vbo_save.h
+++ b/src/mesa/vbo/vbo_save.h
@@ -74,7 +74,8 @@ struct vbo_save_vertex_list {
GLuint current_size;
 
GLuint buffer_offset;/**< in bytes */
-   GLuint vertex_count;
+   GLuint start_vertex; /**< first vertex used by any primitive */
+   GLuint vertex_count; /**< number of vertices in this list */
GLuint wrap_count;  /* number of copied vertices at start */
GLboolean dangling_attr_ref;/* current attr implicitly referenced
outside the list */
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index e0fe5fd..11c40a2 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -563,6 +563,9 @@ compile_vertex_list(struct gl_context *ctx)
   for (unsigned i = 0; i < save->prim_count; i++) {
  save->prims[i].start += start_offset;
   }
+  node->start_vertex = start_offset;
+   } else {
+  node->start_vertex = 0;
}
 
/* Reset our structures for the next run of vertices:
diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 97e0fa0..221aa57 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -349,13 +349,14 @@ vbo_save_playback_vertex_list(struct gl_context *ctx, 
void *data)
  _mesa_update_state(ctx);
 
   if (node->vertex_count > 0) {
+ GLuint min_index = node->start_vertex;
+ GLuint max_index = min_index + node->vertex_count - 1;
  vbo_context(ctx)->draw_prims(ctx,
   node->prims,
   node->prim_count,
   NULL,
   GL_TRUE,
-  0,/* Node is a VBO, so this is ok */
-  node->vertex_count - 1,
+  min_index, max_index,
   NULL, 0, NULL);
   }
}
-- 
2.7.4

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

[Mesa-dev] [Bug 104752] Account Request for Chuck Atkins

[bugzilla-daemon]

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

--- Comment #4 from Emil Velikov  ---
Ack from me.

-- 
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 10/20] mesa: add support for semaphore object signal/wait v3

[Andres Rodriguez]

Memory synchronization is left for a future patch.

v2: flush vertices/bitmaps moved to mesa/main
v3: removed spaces before/after braces

Signed-off-by: Andres Rodriguez 
---
 src/mesa/main/dd.h  | 14 ++
 src/mesa/main/externalobjects.c | 38 ++
 2 files changed, 52 insertions(+)

diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 376dd35ae9..abbc4d5f5c 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -1150,6 +1150,20 @@ struct dd_function_table {
 */
void (*DeleteSemaphoreObject)(struct gl_context *ctx,
  struct gl_semaphore_object *semObj);
+
+   /**
+* Introduce an operation to wait for the semaphore object in the GL
+* server's command stream
+*/
+   void (*ServerWaitSemaphoreObject)(struct gl_context *ctx,
+ struct gl_semaphore_object *semObj);
+
+   /**
+* Introduce an operation to signal the semaphore object in the GL
+* server's command stream
+*/
+   void (*ServerSignalSemaphoreObject)(struct gl_context *ctx,
+   struct gl_semaphore_object *semObj);
/*@}*/
 
/**
diff --git a/src/mesa/main/externalobjects.c b/src/mesa/main/externalobjects.c
index b72fe13d04..9ba70c8e7f 100644
--- a/src/mesa/main/externalobjects.c
+++ b/src/mesa/main/externalobjects.c
@@ -23,6 +23,7 @@
 
 #include "macros.h"
 #include "mtypes.h"
+#include "context.h"
 #include "externalobjects.h"
 #include "teximage.h"
 #include "texobj.h"
@@ -713,7 +714,26 @@ _mesa_WaitSemaphoreEXT(GLuint semaphore,
const GLuint *textures,
const GLenum *srcLayouts)
 {
+   GET_CURRENT_CONTEXT(ctx);
+   struct gl_semaphore_object *semObj;
+
+
+   if (!ctx->Extensions.EXT_semaphore) {
+  _mesa_error(ctx, GL_INVALID_OPERATION, 
"glWaitSemaphoreEXT(unsupported)");
+  return;
+   }
+
+   ASSERT_OUTSIDE_BEGIN_END(ctx);
+
+   semObj = _mesa_lookup_semaphore_object(ctx, semaphore);
+   if (!semObj)
+  return;
+
+   FLUSH_VERTICES(ctx, 0);
+   FLUSH_CURRENT(ctx, 0);
 
+   /* TODO: memory barriers and layout transitions */
+   ctx->Driver.ServerWaitSemaphoreObject(ctx, semObj);
 }
 
 void GLAPIENTRY
@@ -724,7 +744,25 @@ _mesa_SignalSemaphoreEXT(GLuint semaphore,
  const GLuint *textures,
  const GLenum *dstLayouts)
 {
+   GET_CURRENT_CONTEXT(ctx);
+   struct gl_semaphore_object *semObj;
+
+   if (!ctx->Extensions.EXT_semaphore) {
+  _mesa_error(ctx, GL_INVALID_OPERATION, 
"glSignalSemaphoreEXT(unsupported)");
+  return;
+   }
+
+   ASSERT_OUTSIDE_BEGIN_END(ctx);
+
+   semObj = _mesa_lookup_semaphore_object(ctx, semaphore);
+   if (!semObj)
+  return;
+
+   FLUSH_VERTICES(ctx, 0);
+   FLUSH_CURRENT(ctx, 0);
 
+   /* TODO: memory barriers and layout transitions */
+   ctx->Driver.ServerSignalSemaphoreObject(ctx, semObj);
 }
 
 void GLAPIENTRY
-- 
2.14.1

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

[Mesa-dev] [PATCH] Revert "radv: Initialize DCC on transition from preinitialized."

[Andres Rodriguez]

This reverts commit 2ce11ac11fee594ca01608c4006b38c0c8ea37ff.

SteamVR has been updated to correctly use UNDEFINED as the initial
layout transition state. So we should go back to behaving according to
the spec in radv.

Fixes: 44fcf58744 "radv: Disable DCC for GENERAL layout and compute transfer 
dest."
Signed-off-by: Andres Rodriguez 
---
 src/amd/vulkan/radv_cmd_buffer.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 172f95e7c9..67799a13cc 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4026,9 +4026,7 @@ static void radv_handle_dcc_image_transition(struct 
radv_cmd_buffer *cmd_buffer,
 unsigned dst_queue_mask,
 const VkImageSubresourceRange 
*range)
 {
-   if (src_layout == VK_IMAGE_LAYOUT_PREINITIALIZED) {
-   radv_initialize_dcc(cmd_buffer, image, 0xu);
-   } else if (src_layout == VK_IMAGE_LAYOUT_UNDEFINED) {
+   if (src_layout == VK_IMAGE_LAYOUT_UNDEFINED) {
radv_initialize_dcc(cmd_buffer, image,
radv_layout_dcc_compressed(image, 
dst_layout, dst_queue_mask) ?
 0x20202020u : 0xu);
-- 
2.14.1

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

[Mesa-dev] [ANNOUNCE] mesa 18.0.0-rc2

[Emil Velikov]

This release corrects the version number, to follow the standard naming scheme.

Emil Velikov (1):
  Update version to 18.0.0-rc2

git tag: mesa-18.0.0-rc2

https://mesa.freedesktop.org/archive/mesa-18.0.0-rc2.tar.gz
MD5:  755ced6e9039d2f3394b09a99e3ed2e2  mesa-18.0.0-rc2.tar.gz
SHA1: 0066bb08b7f2db8b249f0d6aaf876161098ef6b6  mesa-18.0.0-rc2.tar.gz
SHA256: a36dbade45756a5abf19cd4fa65b9394cb6ec1511e64ed4d0965d473c64eaddb
 mesa-18.0.0-rc2.tar.gz
SHA512: 
5e8bbbf0f5807c11983556cdbe0141a2a67f69b19bada35b0b6b08a586328d9b99aae28503e1a6615f4e1c3a9aa121abe8cef0e0819f2fc556a61ceaea328fc7
 mesa-18.0.0-rc2.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-18.0.0-rc2.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-18.0.0-rc2.tar.xz
MD5:  821580e93b3f11263deb34b16b6378b3  mesa-18.0.0-rc2.tar.xz
SHA1: 24d67df8444ac7e65f9bbe0fc67fabad389fd3c5  mesa-18.0.0-rc2.tar.xz
SHA256: 0eb88a367aea65226e9c5c2073b35b8f9fa65eb1149bf38ec5e27e61955c5d78
 mesa-18.0.0-rc2.tar.xz
SHA512: 
aada4caf4c2021bc1e7c071b32ed0ccbbbfe415bc1cb5a80eee3911b1b11a2bd87a10e99c5a152790709488afbdb60e87b4b66c2ca22c0cf89c029fb10c6e8b3
 mesa-18.0.0-rc2.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-18.0.0-rc2.tar.xz.sig
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/20] mesa: add support for semaphore object signal/wait v2

[Brian Paul]

On 01/23/2018 11:05 AM, Andres Rodriguez wrote:

Memory synchronization is left for a future patch.

v2: flush vertices/bitmaps moved to mesa/main

Signed-off-by: Andres Rodriguez 
---
  src/mesa/main/dd.h  | 14 ++
  src/mesa/main/externalobjects.c | 38 ++
  2 files changed, 52 insertions(+)

diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 376dd35ae9..abbc4d5f5c 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -1150,6 +1150,20 @@ struct dd_function_table {
  */
 void (*DeleteSemaphoreObject)(struct gl_context *ctx,
   struct gl_semaphore_object *semObj);
+
+   /**
+* Introduce an operation to wait for the semaphore object in the GL
+* server's command stream
+*/
+   void (*ServerWaitSemaphoreObject)(struct gl_context *ctx,
+ struct gl_semaphore_object *semObj);
+
+   /**
+* Introduce an operation to signal the semaphore object in the GL
+* server's command stream
+*/
+   void (*ServerSignalSemaphoreObject)(struct gl_context *ctx,
+   struct gl_semaphore_object *semObj);
 /*@}*/
  
 /**

diff --git a/src/mesa/main/externalobjects.c b/src/mesa/main/externalobjects.c
index b72fe13d04..4fb3ca07a9 100644
--- a/src/mesa/main/externalobjects.c
+++ b/src/mesa/main/externalobjects.c
@@ -23,6 +23,7 @@
  
  #include "macros.h"

  #include "mtypes.h"
+#include "context.h"
  #include "externalobjects.h"
  #include "teximage.h"
  #include "texobj.h"
@@ -713,7 +714,26 @@ _mesa_WaitSemaphoreEXT(GLuint semaphore,
 const GLuint *textures,
 const GLenum *srcLayouts)
  {
+   GET_CURRENT_CONTEXT(ctx);
+   struct gl_semaphore_object *semObj;
+
+
+   if (!ctx->Extensions.EXT_semaphore) {
+  _mesa_error(ctx, GL_INVALID_OPERATION, 
"glWaitSemaphoreEXT(unsupported)");
+  return;
+   }
+
+   ASSERT_OUTSIDE_BEGIN_END(ctx);
+
+   semObj = _mesa_lookup_semaphore_object(ctx, semaphore);
+   if (!semObj)
+  return;
+
+   FLUSH_VERTICES( ctx, 0 );
+   FLUSH_CURRENT( ctx, 0 );
  
+   /* TODO: memory barriers and layout transitions */

+   ctx->Driver.ServerWaitSemaphoreObject(ctx, semObj);
  }
  
  void GLAPIENTRY

@@ -724,7 +744,25 @@ _mesa_SignalSemaphoreEXT(GLuint semaphore,
   const GLuint *textures,
   const GLenum *dstLayouts)
  {
+   GET_CURRENT_CONTEXT(ctx);
+   struct gl_semaphore_object *semObj;
+
+   if (!ctx->Extensions.EXT_semaphore) {
+  _mesa_error(ctx, GL_INVALID_OPERATION, 
"glSignalSemaphoreEXT(unsupported)");
+  return;
+   }
+
+   ASSERT_OUTSIDE_BEGIN_END(ctx);
+
+   semObj = _mesa_lookup_semaphore_object(ctx, semaphore);
+   if (!semObj)
+  return;
+
+   FLUSH_VERTICES( ctx, 0 );
+   FLUSH_CURRENT( ctx, 0 );


Old code sometimes had spaces after '(' and before ')', but let's not do 
that anymore.


-Brian


  
+   /* TODO: memory barriers and layout transitions */

+   ctx->Driver.ServerSignalSemaphoreObject(ctx, semObj);
  }
  
  void GLAPIENTRY




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