[Mesa-dev] [Bug 103699] Latest mesa breaks firefox on kde plasma with compositing on

[bugzilla-daemon]

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

--- Comment #19 from Tapani Pälli  ---
Created attachment 135745
  --> https://bugs.freedesktop.org/attachment.cgi?id=135745=edit
fix/workaround

I've sent this patch to xorg-devel for review/discussion. Problem is that GLX
may pick sRGB capable config for 32bit visual that is used for translucent
windows and compositor (kwin) does not seem to do blending properly in this
case as it seems not aware of sRGB at all. Another bug indicated that
gnome-shell may have the same issue so I'm proposing to disable sRGB globally
32bit visual for now.

-- 
You are receiving this mail because:
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] i965: fix KHR-GL46.enhanced_layouts.varying_* failures

[Clayton Craft]

This resolves following test failures by partially
reverting "mesa: shrink VERT_ATTRIB bitfields to 32 bits":
KHR-GL46.enhanced_layouts.varying_array_locations
KHR-GL46.enhanced_layouts.varying_locations
KHR-GL46.enhanced_layouts.varying_structure_locations

Fixes: 78942e7dbfd234c ("mesa: shrink VERT_ATTRIB bitfields to 32 bits")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103942
Suggested-by: Marek Olšák 
---
 src/mesa/drivers/dri/i965/brw_draw_upload.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c 
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index 2204bf474b..9b81999ea0 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -458,7 +458,7 @@ brw_prepare_vertices(struct brw_context *brw)
/* BRW_NEW_VS_PROG_DATA */
const struct brw_vs_prog_data *vs_prog_data =
   brw_vs_prog_data(brw->vs.base.prog_data);
-   GLbitfield vs_inputs = vs_prog_data->inputs_read;
+   GLbitfield64 vs_inputs = vs_prog_data->inputs_read;
const unsigned char *ptr = NULL;
GLuint interleaved = 0;
unsigned int min_index = brw->vb.min_index + brw->basevertex;
@@ -487,16 +487,16 @@ brw_prepare_vertices(struct brw_context *brw)
/* Accumulate the list of enabled arrays. */
brw->vb.nr_enabled = 0;
while (vs_inputs) {
-  GLuint first = ffs(vs_inputs) - 1;
+  GLuint first = ffsll(vs_inputs) - 1;
   assert (first < 64);
   GLuint index =
  first - 
DIV_ROUND_UP(_mesa_bitcount_64(vs_prog_data->double_inputs_read &
 BITFIELD64_MASK(first)), 2);
   struct brw_vertex_element *input = >vb.inputs[index];
   input->is_dual_slot = (vs_prog_data->double_inputs_read & 
BITFIELD64_BIT(first)) != 0;
-  vs_inputs &= ~BITFIELD_BIT(first);
+  vs_inputs &= ~BITFIELD64_BIT(first);
   if (input->is_dual_slot)
- vs_inputs &= ~BITFIELD_BIT(first + 1);
+ vs_inputs &= ~BITFIELD64_BIT(first + 1);
   brw->vb.enabled[brw->vb.nr_enabled++] = input;
}
 
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH] mesa: Document ati_fragment_shader::cur_pass

[Roland Scheidegger]

I really don't think you wanted to remove the cur_pass variable there :-).
With that fixed,
Reviewed-by: Roland Scheidegger 

Am 28.11.2017 um 04:10 schrieb Ian Romanick:
> From: Ian Romanick 
> 
> Signed-off-by: Ian Romanick 
> ---
> Having this information would have helped me review recent patches from
> Miklós...
> 
>  src/mesa/main/mtypes.h | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 2f21633..e753438 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -2390,8 +2390,16 @@ struct ati_fragment_shader
> GLubyte numArithInstr[2];
> GLubyte regsAssigned[2];
> GLubyte NumPasses; /**< 1 or 2 */
> -   GLubyte cur_pass;
> +
> +   /**
> +* cur_pass distinguishes between the texture and arithmetic phases.  
> There
> +* are a maximum of two passes, and each pass has a texture phase followed
> +* by an arithmetic phase.  Hence cur_pass being 0 means currently texture
> +* instructions are specified for the first pass. cur_pass 1 arithmetic 
> for
> +* the first pass. cur_pass 2/3 correspond to the second pass accordingly.
> +*/
> GLubyte last_optype;
> +
> GLboolean interpinp1;
> GLboolean isValid;
> GLuint swizzlerq;
> 

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

Re: [Mesa-dev] [PATCH 2/3] radv: Use the suffixed versions of VK_QUEUE_GLOBAL_PRIORITY_*

[Ian Romanick]

On 11/27/2017 07:08 PM, Jason Ekstrand wrote:
> On Mon, Nov 27, 2017 at 7:00 PM, Ian Romanick  > wrote:
> 
> I am strongly in favor of this precedent.  One thing that has annoyed me
> for years about Mesa's OpenGL code is the use of mixed suffixes through
> the code base as an extension progresses from vendor -> EXT -> ARB
> -> core.
> 
> 
> I'm having a bit of trouble with English, I'm afraid.  I'm not sure if
> that means you like the patch or hate it.  In any case, the related
> extension is *not* in core and the lack of suffixes was a bug. The
> header/XML update I sent out as patch 1/3 will break the radv build if
> we don't have this patch.

I like it, and I think we should do it in GL too.

> --Jason
>  
> 
> On 11/27/2017 06:36 PM, Jason Ekstrand wrote:
> > ---
> >  src/amd/vulkan/radv_device.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_device.c
> b/src/amd/vulkan/radv_device.c
> > index 722c768..8e5ae0b 100644
> > --- a/src/amd/vulkan/radv_device.c
> > +++ b/src/amd/vulkan/radv_device.c
> > @@ -895,13 +895,13 @@ radv_get_queue_global_priority(const
> VkDeviceQueueGlobalPriorityCreateInfoEXT *p
> >               return RADEON_CTX_PRIORITY_MEDIUM;
> >
> >       switch(pObj->globalPriority) {
> > -     case VK_QUEUE_GLOBAL_PRIORITY_REALTIME:
> > +     case VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT:
> >               return RADEON_CTX_PRIORITY_REALTIME;
> > -     case VK_QUEUE_GLOBAL_PRIORITY_HIGH:
> > +     case VK_QUEUE_GLOBAL_PRIORITY_HIGH_EXT:
> >               return RADEON_CTX_PRIORITY_HIGH;
> > -     case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM:
> > +     case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT:
> >               return RADEON_CTX_PRIORITY_MEDIUM;
> > -     case VK_QUEUE_GLOBAL_PRIORITY_LOW:
> > +     case VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT:
> >               return RADEON_CTX_PRIORITY_LOW;
> >       default:
> >               unreachable("Illegal global priority value");
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 20/29] anv/cmd_buffer: Decide whether or not to HiZ clear up-front

[Jason Ekstrand]

This moves the decision out of begin_subpass and into BeginRenderPass
like the decision for color clears.  We use a similar name for the
function for depth/stencil as for color even though no aux usage is
really getting computed.
---
 src/intel/vulkan/genX_cmd_buffer.c | 84 +++---
 1 file changed, 50 insertions(+), 34 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 57685bd..3f90c1a 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -346,6 +346,52 @@ color_attachment_compute_aux_usage(struct anv_device * 
device,
}
 }
 
+static void
+depth_stencil_attachment_compute_aux_usage(struct anv_device *device,
+   struct anv_cmd_state *cmd_state,
+   uint32_t att, VkRect2D render_area)
+{
+   struct anv_attachment_state *att_state = _state->attachments[att];
+   struct anv_image_view *iview = cmd_state->framebuffer->attachments[att];
+
+   /* These will be initialized after the first subpass transition. */
+   att_state->aux_usage = ISL_AUX_USAGE_NONE;
+   att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
+
+   if (att_state->aux_usage != ISL_AUX_USAGE_HIZ) {
+  att_state->fast_clear = false;
+  return;
+   } else if (!(att_state->pending_clear_aspects & VK_IMAGE_ASPECT_DEPTH_BIT)) 
{
+  /* If we're just clearing stencil, we can always HiZ clear */
+  att_state->fast_clear = true;
+  return;
+   }
+
+   if (!blorp_can_hiz_clear_depth(GEN_GEN,
+  iview->planes[0].isl.format,
+  iview->image->samples,
+  render_area.offset.x,
+  render_area.offset.y,
+  render_area.offset.x +
+  render_area.extent.width,
+  render_area.offset.y +
+  render_area.extent.height)) {
+  att_state->fast_clear = false;
+   } else if (att_state->clear_value.depthStencil.depth != ANV_HZ_FC_VAL) {
+  att_state->fast_clear = false;
+   } else if (GEN_GEN == 8 &&
+  anv_can_sample_with_hiz(>info, iview->image)) {
+  /* Only gen9+ supports returning ANV_HZ_FC_VAL when sampling a
+   * fast-cleared portion of a HiZ buffer. Testing has revealed that Gen8
+   * only supports returning 0.0f. Gens prior to gen8 do not support this
+   * feature at all.
+   */
+  att_state->fast_clear = false;
+   } else {
+  att_state->fast_clear = true;
+   }
+}
+
 static bool
 need_input_attachment_state(const struct anv_render_pass_attachment *att)
 {
@@ -1052,12 +1098,9 @@ genX(cmd_buffer_setup_attachments)(struct anv_cmd_buffer 
*cmd_buffer,
 add_image_view_relocs(cmd_buffer, iview, 0,
   state->attachments[i].color);
  } else {
-/* This field will be initialized after the first subpass
- * transition.
- */
-state->attachments[i].aux_usage = ISL_AUX_USAGE_NONE;
-
-state->attachments[i].input_aux_usage = ISL_AUX_USAGE_NONE;
+depth_stencil_attachment_compute_aux_usage(cmd_buffer->device,
+   state, i,
+   begin->renderArea);
  }
 
  if (need_input_attachment_state(>attachments[i])) {
@@ -3228,34 +3271,7 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
VK_IMAGE_ASPECT_STENCIL_BIT));
 
   if (att_state->pending_clear_aspects) {
- bool clear_with_hiz = att_state->aux_usage == ISL_AUX_USAGE_HIZ;
- if (clear_with_hiz &&
- (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_DEPTH_BIT)) {
-if (!blorp_can_hiz_clear_depth(GEN_GEN,
-   iview->planes[0].isl.format,
-   iview->image->samples,
-   render_area.offset.x,
-   render_area.offset.y,
-   render_area.offset.x +
-   render_area.extent.width,
-   render_area.offset.y +
-   render_area.extent.height)) {
-   clear_with_hiz = false;
-} else if (att_state->clear_value.depthStencil.depth != 
ANV_HZ_FC_VAL) {
-   clear_with_hiz = false;
-} else if (GEN_GEN == 8 &&
-   anv_can_sample_with_hiz(_buffer->device->info,
-   iview->image)) {
-   /* Only gen9+ supports returning ANV_HZ_FC_VAL when sampling a
-* fast-cleared 

[Mesa-dev] [PATCH] mesa: Document ati_fragment_shader::cur_pass

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
Having this information would have helped me review recent patches from
Miklós...

 src/mesa/main/mtypes.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 2f21633..e753438 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2390,8 +2390,16 @@ struct ati_fragment_shader
GLubyte numArithInstr[2];
GLubyte regsAssigned[2];
GLubyte NumPasses; /**< 1 or 2 */
-   GLubyte cur_pass;
+
+   /**
+* cur_pass distinguishes between the texture and arithmetic phases.  There
+* are a maximum of two passes, and each pass has a texture phase followed
+* by an arithmetic phase.  Hence cur_pass being 0 means currently texture
+* instructions are specified for the first pass. cur_pass 1 arithmetic for
+* the first pass. cur_pass 2/3 correspond to the second pass accordingly.
+*/
GLubyte last_optype;
+
GLboolean interpinp1;
GLboolean isValid;
GLuint swizzlerq;
-- 
2.9.5

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

[Mesa-dev] [PATCH 21/29] anv/cmd_buffer: Iterate all subpass attachments when clearing

[Jason Ekstrand]

This unifies things a bit because we now handle depth and stencil at the
same time.  It also ensures that clears happen for input attachments.
---
 src/intel/vulkan/genX_cmd_buffer.c | 69 --
 1 file changed, 28 insertions(+), 41 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 3f90c1a..e5e0d1c 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3219,58 +3219,43 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
 
VkRect2D render_area = cmd_buffer->state.render_area;
struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
-   for (uint32_t i = 0; i < subpass->color_count; ++i) {
-  const uint32_t a = subpass->color_attachments[i].attachment;
+
+   for (uint32_t i = 0; i < subpass->attachment_count; ++i) {
+  const uint32_t a = subpass->attachments[i].attachment;
   if (a == VK_ATTACHMENT_UNUSED)
  continue;
 
   assert(a < cmd_state->pass->attachment_count);
   struct anv_attachment_state *att_state = _state->attachments[a];
 
-  if (!att_state->pending_clear_aspects)
- continue;
-
-  assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
-
   struct anv_image_view *iview = fb->attachments[a];
   const struct anv_image *image = iview->image;
 
-  /* Multi-planar images are not supported as attachments */
-  assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
-  assert(image->n_planes == 1);
-
-  if (att_state->fast_clear) {
- anv_image_ccs_op(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
-  iview->planes[0].isl.base_level,
-  iview->planes[0].isl.base_array_layer,
-  fb->layers,
-  ISL_AUX_OP_FAST_CLEAR, false);
-  } else {
- anv_image_clear_color(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
-   att_state->aux_usage,
-   iview->planes[0].isl.format,
-   iview->planes[0].isl.swizzle,
-   iview->planes[0].isl.base_level,
-   iview->planes[0].isl.base_array_layer,
-   fb->layers, render_area,
-   vk_to_isl_color(att_state->clear_value.color));
-  }
-
-  att_state->pending_clear_aspects = 0;
-   }
-
-   if (subpass->depth_stencil_attachment.attachment != VK_ATTACHMENT_UNUSED) {
-  const uint32_t a = subpass->depth_stencil_attachment.attachment;
-
-  assert(a < cmd_state->pass->attachment_count);
-  struct anv_attachment_state *att_state = _state->attachments[a];
-  struct anv_image_view *iview = fb->attachments[a];
-  const struct anv_image *image = iview->image;
+  if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_COLOR_BIT) {
+ assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
 
-  assert(image->aspects & (VK_IMAGE_ASPECT_DEPTH_BIT |
-   VK_IMAGE_ASPECT_STENCIL_BIT));
+ /* Multi-planar images are not supported as attachments */
+ assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+ assert(image->n_planes == 1);
 
-  if (att_state->pending_clear_aspects) {
+ if (att_state->fast_clear) {
+anv_image_ccs_op(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
+ iview->planes[0].isl.base_level,
+ iview->planes[0].isl.base_array_layer,
+ fb->layers,
+ ISL_AUX_OP_FAST_CLEAR, false);
+ } else {
+anv_image_clear_color(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
+  att_state->aux_usage,
+  iview->planes[0].isl.format,
+  iview->planes[0].isl.swizzle,
+  iview->planes[0].isl.base_level,
+  iview->planes[0].isl.base_array_layer,
+  fb->layers, render_area,
+  
vk_to_isl_color(att_state->clear_value.color));
+ }
+  } else if (att_state->pending_clear_aspects & (VK_IMAGE_ASPECT_DEPTH_BIT 
|
+ 
VK_IMAGE_ASPECT_STENCIL_BIT)) {
  if (att_state->fast_clear) {
 /* We currently only support HiZ for single-layer images */
 assert(iview->planes[0].isl.base_level == 0);
@@ -3293,6 +3278,8 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
   
att_state->clear_value.depthStencil.depth,
   
att_state->clear_value.depthStencil.stencil);
  }
+  } else  {
+ 

[Mesa-dev] [PATCH 15/29] anv/cmd_buffer: Add begin/end_subpass helpers

[Jason Ekstrand]

Having begin/end_subpass is a bit nicer than the begin/next/end hooks
that Vulkan gives us.
---
 src/intel/vulkan/genX_cmd_buffer.c | 55 +-
 1 file changed, 31 insertions(+), 24 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index bbe97f5..6f2fa0a 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3138,10 +3138,11 @@ cmd_buffer_subpass_sync_fast_clear_values(struct 
anv_cmd_buffer *cmd_buffer)
 
 
 static void
-genX(cmd_buffer_set_subpass)(struct anv_cmd_buffer *cmd_buffer,
- struct anv_subpass *subpass)
+cmd_buffer_begin_subpass(struct anv_cmd_buffer *cmd_buffer,
+ struct anv_subpass *subpass)
 {
cmd_buffer->state.subpass = subpass;
+   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
 
cmd_buffer->state.dirty |= ANV_CMD_DIRTY_RENDER_TARGETS;
 
@@ -3155,6 +3156,10 @@ genX(cmd_buffer_set_subpass)(struct anv_cmd_buffer 
*cmd_buffer,
if (GEN_GEN == 7)
   cmd_buffer->state.vb_dirty |= ~0;
 
+   /* Accumulate any subpass flushes that need to happen before the subpass */
+   cmd_buffer->state.pending_pipe_bits |=
+  cmd_buffer->state.pass->subpass_flushes[subpass_id];
+
/* Perform transitions to the subpass layout before any writes have
 * occurred.
 */
@@ -3174,6 +3179,26 @@ genX(cmd_buffer_set_subpass)(struct anv_cmd_buffer 
*cmd_buffer,
anv_cmd_buffer_clear_subpass(cmd_buffer);
 }
 
+static void
+cmd_buffer_end_subpass(struct anv_cmd_buffer *cmd_buffer)
+{
+   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
+
+   anv_cmd_buffer_resolve_subpass(cmd_buffer);
+
+   /* Perform transitions to the final layout after all writes have occurred.
+*/
+   cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
+
+   /* Accumulate any subpass flushes that need to happen after the subpass.
+* Yes, they do get accumulated twice in the NextSubpass case but since
+* genX_CmdNextSubpass just calls end/begin back-to-back, we just end up
+* ORing the bits in twice so it's harmless.
+*/
+   cmd_buffer->state.pending_pipe_bits |=
+  cmd_buffer->state.pass->subpass_flushes[subpass_id + 1];
+}
+
 void genX(CmdBeginRenderPass)(
 VkCommandBuffer commandBuffer,
 const VkRenderPassBeginInfo*pRenderPassBegin,
@@ -3197,10 +3222,7 @@ void genX(CmdBeginRenderPass)(
 
genX(flush_pipeline_select_3d)(cmd_buffer);
 
-   cmd_buffer->state.pending_pipe_bits |=
-  cmd_buffer->state.pass->subpass_flushes[0];
-
-   genX(cmd_buffer_set_subpass)(cmd_buffer, pass->subpasses);
+   cmd_buffer_begin_subpass(cmd_buffer, pass->subpasses);
 }
 
 void genX(CmdNextSubpass)(
@@ -3214,17 +3236,9 @@ void genX(CmdNextSubpass)(
 
assert(cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_PRIMARY);
 
-   anv_cmd_buffer_resolve_subpass(cmd_buffer);
-
-   /* Perform transitions to the final layout after all writes have occurred.
-*/
-   cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
-
-   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
-   cmd_buffer->state.pending_pipe_bits |=
-  cmd_buffer->state.pass->subpass_flushes[subpass_id];
+   cmd_buffer_end_subpass(cmd_buffer);
 
-   genX(cmd_buffer_set_subpass)(cmd_buffer, cmd_buffer->state.subpass + 1);
+   cmd_buffer_begin_subpass(cmd_buffer, cmd_buffer->state.subpass + 1);
 }
 
 void genX(CmdEndRenderPass)(
@@ -3235,14 +3249,7 @@ void genX(CmdEndRenderPass)(
if (anv_batch_has_error(_buffer->batch))
   return;
 
-   anv_cmd_buffer_resolve_subpass(cmd_buffer);
-
-   /* Perform transitions to the final layout after all writes have occurred.
-*/
-   cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
-
-   cmd_buffer->state.pending_pipe_bits |=
-  
cmd_buffer->state.pass->subpass_flushes[cmd_buffer->state.pass->subpass_count];
+   cmd_buffer_end_subpass(cmd_buffer);
 
cmd_buffer->state.hiz_enabled = false;
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 17/29] anv/cmd_buffer: Move the color portion of clear_subpass into begin_subpass

[Jason Ekstrand]

This doesn't really change much now but it will give us more/better
control over clears in the future.  The one interesting functional
change here is that we are now re-emitting 3DSTATE_DEPTH_BUFFERS and
friends for each clear.  However, this only happens at begin_subpass
time so it shouldn't be substantially more expensive.
---
 src/intel/vulkan/anv_blorp.c   | 115 +++--
 src/intel/vulkan/anv_private.h |   8 +++
 src/intel/vulkan/genX_cmd_buffer.c |  46 ++-
 3 files changed, 86 insertions(+), 83 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 46e2eb0..7401234 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1138,17 +1138,6 @@ subpass_needs_clear(const struct anv_cmd_buffer 
*cmd_buffer)
const struct anv_cmd_state *cmd_state = _buffer->state;
uint32_t ds = cmd_state->subpass->depth_stencil_attachment.attachment;
 
-   for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
-  uint32_t a = cmd_state->subpass->color_attachments[i].attachment;
-  if (a == VK_ATTACHMENT_UNUSED)
- continue;
-
-  assert(a < cmd_state->pass->attachment_count);
-  if (cmd_state->attachments[a].pending_clear_aspects) {
- return true;
-  }
-   }
-
if (ds != VK_ATTACHMENT_UNUSED) {
   assert(ds < cmd_state->pass->attachment_count);
   if (cmd_state->attachments[ds].pending_clear_aspects)
@@ -1182,77 +1171,6 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
};
 
struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
-   for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
-  const uint32_t a = cmd_state->subpass->color_attachments[i].attachment;
-  if (a == VK_ATTACHMENT_UNUSED)
- continue;
-
-  assert(a < cmd_state->pass->attachment_count);
-  struct anv_attachment_state *att_state = _state->attachments[a];
-
-  if (!att_state->pending_clear_aspects)
- continue;
-
-  assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
-
-  struct anv_image_view *iview = fb->attachments[a];
-  const struct anv_image *image = iview->image;
-  struct blorp_surf surf;
-  get_blorp_surf_for_anv_image(cmd_buffer->device,
-   image, VK_IMAGE_ASPECT_COLOR_BIT,
-   att_state->aux_usage, );
-
-  if (att_state->fast_clear) {
- surf.clear_color = vk_to_isl_color(att_state->clear_value.color);
-
- /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
-  *
-  *"After Render target fast clear, pipe-control with color cache
-  *write-flush must be issued before sending any DRAW commands on
-  *that render target."
-  *
-  * This comment is a bit cryptic and doesn't really tell you what's
-  * going or what's really needed.  It appears that fast clear ops are
-  * not properly synchronized with other drawing.  This means that we
-  * cannot have a fast clear operation in the pipe at the same time as
-  * other regular drawing operations.  We need to use a PIPE_CONTROL
-  * to ensure that the contents of the previous draw hit the render
-  * target before we resolve and then use a second PIPE_CONTROL after
-  * the resolve to ensure that it is completed before any additional
-  * drawing occurs.
-  */
- cmd_buffer->state.pending_pipe_bits |=
-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);
-
- cmd_buffer->state.pending_pipe_bits |=
-ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
-  } else {
- assert(image->n_planes == 1);
- anv_cmd_buffer_mark_image_written(cmd_buffer, image,
-   VK_IMAGE_ASPECT_COLOR_BIT,
-   att_state->aux_usage,
-   iview->planes[0].isl.base_level);
-
- 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,
-  

Re: [Mesa-dev] [PATCH 2/4] mesa: fix crash when an ATI_fs pass begins with an alpha inst

[Ian Romanick]

On 11/27/2017 01:27 PM, Roland Scheidegger wrote:
> Am 27.11.2017 um 21:29 schrieb Ian Romanick:
>> On 11/20/2017 06:04 PM, Roland Scheidegger wrote:
>>> Am 21.11.2017 um 01:40 schrieb Ian Romanick:
 On 11/20/2017 04:07 PM, Miklós Máté wrote:
> This fixes crash when:
> - first pass begins with alpha inst
> - first pass ends with color inst, second pass begins with alpha inst
>
> Also, use the symbolic name instead of a number.
> Piglit: spec/ati_fragment_shader/api-alphafirst
>
> Signed-off-by: Miklós Máté 
> ---
>  src/mesa/main/atifragshader.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/atifragshader.c b/src/mesa/main/atifragshader.c
> index 49ddb6e5af..d6fc37ac8f 100644
> --- a/src/mesa/main/atifragshader.c
> +++ b/src/mesa/main/atifragshader.c
> @@ -598,8 +598,10 @@ _mesa_FragmentOpXATI(GLint optype, GLuint arg_count, 
> GLenum op, GLuint dst,
>curProg->cur_pass=3;
>  
> /* decide whether this is a new instruction or not ... all color 
> instructions are new,
> -  and alpha instructions might also be new if there was no preceding 
> color inst */
> -   if ((optype == 0) || (curProg->last_optype == optype)) {
> +  and alpha instructions might also be new if there was no preceding 
> color inst,
> +  and this may be the first inst of the pass */

 I know the code previously used this same formatting, but the Mesa style
 is for the */ of a multi-line comment to be on its own line.  Each other
 line should also start with a *.  And line-wrap around 78 characters.
 Like:

/* Decide whether this is a new instruction or not.  All color 
 instructions
 * are new, and alpha instructions might also be new if there was no
 * preceding color inst.  This may also be the first inst of the pass.
 */

> +   if ((optype == ATI_FRAGMENT_SHADER_COLOR_OP) || (curProg->last_optype 
> == optype)
> + || (curProg->numArithInstr[curProg->cur_pass >> 1] == 0)) {

 I lost the debate about where the || (or &&) should go... it should be
 on the previous line.  Most of the parenthesis are unnecessary, and the
 second line should line up with the opening (.

 On a side topic... if anyone understands how
 ati_fragment_shader::cur_pass works, it would be really great if they
 could document it in mtypes.h.
>>>
>>> This just indicates which pass is currently being specified. Some
>>> instructions will trigger a new pass, some instructions are only valid
>>> in the first or second pass and so on, and you can have a maximum of 2
>>> passes.
>>
>> Which is the confusing part.  ATI fragment shaders can have two passes,
>> but, as far as I can tell by reading the code,
>> ati_fragment_shader::cur_pass can have a maximum value of... 5?  At
>> least 4 for sure.
> Ah yes I wasn't very accurate there.
> unlike NumPasses, cur_pass distinguishes between the texture and
> arithmetic phases. Hence cur_pass being 0 means currently texture
> instructions are specified for the first pass. cur_pass 1 arithmetic for
> the first pass. cur_pass 2/3 correspond to the second pass accordingly.
> I can't see though how you could get values larger than 3 (if the value
> is 3 and there's some instruction which would increase it, that should
> be an error).

I can believe what you're saying about 3 being the maximum... I was
going from memory of last week rather than looking at the code again. :)

> Roland
> 
>>> I guess it's a bit awkward how this needs to work due to the shader
>>> being specified bit-by-bit rather than all at once, but the actual
>>> concept is very similar to the multiple phases of d3d9 and r300 (and
>>> didn't i915 have something similar too). Of course, if you translate it
>>> away (on everything but r200) then only the error checking aspect of it
>>> really matters in the end.
>>>
>>> FWIW the patches all look correct to me, apparently there were quite
>>> some errors in there (I think it was mostly verified with doom3 at that
>>> time...).

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

[Mesa-dev] [PATCH 14/29] anv/cmd_buffer: Apply subpass flushes before set_subpass

[Jason Ekstrand]

This seems slightly more correct because it means that the flushes
happen before any clears or resolves implied by the subpass transition.
---
 src/intel/vulkan/genX_cmd_buffer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 2d47179..bbe97f5 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3197,10 +3197,10 @@ void genX(CmdBeginRenderPass)(
 
genX(flush_pipeline_select_3d)(cmd_buffer);
 
-   genX(cmd_buffer_set_subpass)(cmd_buffer, pass->subpasses);
-
cmd_buffer->state.pending_pipe_bits |=
   cmd_buffer->state.pass->subpass_flushes[0];
+
+   genX(cmd_buffer_set_subpass)(cmd_buffer, pass->subpasses);
 }
 
 void genX(CmdNextSubpass)(
@@ -3220,11 +3220,11 @@ void genX(CmdNextSubpass)(
 */
cmd_buffer_subpass_transition_layouts(cmd_buffer, true);
 
-   genX(cmd_buffer_set_subpass)(cmd_buffer, cmd_buffer->state.subpass + 1);
-
uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
cmd_buffer->state.pending_pipe_bits |=
   cmd_buffer->state.pass->subpass_flushes[subpass_id];
+
+   genX(cmd_buffer_set_subpass)(cmd_buffer, cmd_buffer->state.subpass + 1);
 }
 
 void genX(CmdEndRenderPass)(
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 29/29] anv: Use blorp_ccs_ambiguate instead of fast-clears

[Jason Ekstrand]

Even though the blorp pass looks a bit on the sketchy side, the end
result in the Vulkan driver is very nice.  Instead of having this weird
case where you do a fast clear and then maybe have to resolve, we just
do the ambiguate and are done with it.  The ambiguate does exactly what
we want of setting all the CCS values to 0 which puts it inot the
pass-through state.
---
 src/intel/vulkan/anv_blorp.c   |  5 +
 src/intel/vulkan/genX_cmd_buffer.c | 40 ++
 2 files changed, 7 insertions(+), 38 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 45d7b12..84ac720 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1705,6 +1705,11 @@ anv_image_ccs_op(struct anv_cmd_buffer *cmd_buffer,
 surf.surf->format, isl_to_blorp_fast_clear_op(ccs_op));
   break;
case ISL_AUX_OP_AMBIGUATE:
+  for (uint32_t a = 0; a < layer_count; a++) {
+ const uint32_t layer = base_layer + a;
+ blorp_ccs_ambiguate(, , level, layer);
+  }
+  break;
default:
   unreachable("Unsupported CCS operation");
}
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index dcd5a8f..e8a4d90 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -614,17 +614,7 @@ init_fast_clear_state_entry(struct anv_cmd_buffer 
*cmd_buffer,
uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
enum isl_aux_usage aux_usage = image->planes[plane].aux_usage;
 
-   /* The resolve flag should updated to signify that fast-clear/compression
-* data needs to be removed when leaving the undefined layout. Such data
-* may need to be removed if it would cause accesses to the color buffer
-* to return incorrect data. The fast clear data in CCS_D buffers should
-* be removed because CCS_D isn't enabled all the time.
-*/
-   if (aux_usage == ISL_AUX_USAGE_NONE) {
-  set_image_needs_resolve_bits(cmd_buffer, image, aspect, level, ~0);
-   } else {
-  clear_image_needs_resolve_bits(cmd_buffer, image, aspect, level, ~0);
-   }
+   clear_image_needs_resolve_bits(cmd_buffer, image, aspect, level, ~0);
 
/* The fast clear value dword(s) will be copied into a surface state object.
 * Ensure that the restrictions of the fields in the dword(s) are followed.
@@ -830,7 +820,7 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
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);
+ ISL_AUX_OP_AMBIGUATE, false);
  }
   } else if (image->samples > 1) {
  if (image->samples == 4 || image->samples == 16) {
@@ -844,32 +834,6 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
   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
-   * the associated CCS elements enter the ambiguated state. This enables
-   * reads (implicit or explicit) to reflect the user-written data instead
-   * of the clear color. The only time such elements will not change their
-   * state as described above, is in a final layout that doesn't have CCS
-   * enabled. In this case, we must force the associated CCS buffers of the
-   * specified range to enter the ambiguated state in advance.
-   */
-  if (image->samples == 1 &&
-  image->planes[plane].aux_usage != ISL_AUX_USAGE_CCS_E &&
-  final_layout != VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL) {
- /* The CCS_D buffer may not be enabled in the final layout. Call this
-  * function again with a initial layout of COLOR_ATTACHMENT_OPTIMAL
-  * to perform a resolve.
-  */
-  anv_perf_warn(cmd_buffer->device->instance, image,
-"Performing an additional resolve for CCS_D layout "
-"transition. Consider always leaving it on or "
-"performing an ambiguation pass.");
- transition_color_buffer(cmd_buffer, image, aspect,
- base_level, level_count,
- base_layer, layer_count,
- VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL,
- final_layout);
-  }
   return;
}
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 05/29] anv/image: Update a comment

[Jason Ekstrand]

This got lost in all of the aspect vs. plane rebasing of YCBCR.
---
 src/intel/vulkan/anv_image.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index ba932ba..a872149 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -710,7 +710,7 @@ void anv_GetImageSubresourceLayout(
  *
  * @param devinfo The device information of the Intel GPU.
  * @param image The image that may contain a collection of buffers.
- * @param plane The plane of the image to be accessed.
+ * @param aspect The aspect of the image to be accessed.
  * @param layout The current layout of the image aspect(s).
  *
  * @return The primary buffer that should be used for the given layout.
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 13/29] anv/cmd_buffer: Rework aux tracking

[Jason Ekstrand]

This makes us start tracking two bits per level for aux to describe both
whether or not something is fast-cleared and whether or not it is
compressed as opposed to a single "needs resolve" bit.  The previous
scheme only worked because we assumed that CCS_E compressed images would
always be read with CCS_E enabled and so they didn't need any sort of
resolve if there was no fast clear color.

The assumptions of the previous scheme held because the one case where
we do need a full resolve when CCS_E is enabled is for window-system
images.  Since we only ever allowed X-tiled window-system images, CCS
was entirely disabled on gen9+ and we never got CCS_E.  With the advent
of Y-tiled window-system buffers, we now need to properly support doing
a full resolve images marked CCS_E.  This requires us to track things
more granularly because, if the client does two back-to-back transitions
where we first do a partial resolve and then a full resolve, we need
both resolves to happen.
---
 src/intel/vulkan/anv_private.h |  10 +--
 src/intel/vulkan/genX_cmd_buffer.c | 158 ++---
 2 files changed, 135 insertions(+), 33 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index f805246..e875705 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2476,16 +2476,16 @@ anv_fast_clear_state_entry_size(const struct anv_device 
*device)
 {
assert(device);
/* Entry contents:
-*   ++
-*   | clear value dword(s) | needs resolve dword |
-*   ++
+*   +-+
+*   | clear value dword(s) | needs resolve dwords |
+*   +-+
 */
 
-   /* Ensure that the needs resolve dword is in fact dword-aligned to enable
+   /* Ensure that the needs resolve dwords are in fact dword-aligned to enable
 * GPU memcpy operations.
 */
assert(device->isl_dev.ss.clear_value_size % 4 == 0);
-   return device->isl_dev.ss.clear_value_size + 4;
+   return device->isl_dev.ss.clear_value_size + 8;
 }
 
 static inline struct anv_address
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 6aeffa3..2d47179 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -404,6 +404,22 @@ transition_depth_buffer(struct anv_cmd_buffer *cmd_buffer,
0, 0, 1, hiz_op);
 }
 
+/** Bitfield representing the needed resolves.
+ *
+ * This bitfield represents the kinds of compression we may or may not have in
+ * a given image.  The ANV_IMAGE_NEEDS_* can be ANDed with the ANV_IMAGE_HAS
+ * bits to determine when a given resolve actually needs to happen.
+ *
+ * For convenience of dealing with MI_PREDICATE, we blow these two bits out
+ * into two dwords in the image meatadata page.
+ */
+enum anv_image_resolve_bits {
+   ANV_IMAGE_HAS_FAST_CLEAR_BIT   = 0x1,
+   ANV_IMAGE_HAS_COMPRESSION_BIT  = 0x2,
+   ANV_IMAGE_NEEDS_PARTIAL_RESOLVE_BITS   = 0x1,
+   ANV_IMAGE_NEEDS_FULL_RESOLVE_BITS  = 0x3,
+};
+
 #define MI_PREDICATE_SRC0  0x2400
 #define MI_PREDICATE_SRC1  0x2408
 
@@ -411,23 +427,62 @@ transition_depth_buffer(struct anv_cmd_buffer *cmd_buffer,
  * performed properly.
  */
 static void
-set_image_needs_resolve(struct anv_cmd_buffer *cmd_buffer,
-const struct anv_image *image,
-VkImageAspectFlagBits aspect,
-unsigned level, bool needs_resolve)
+set_image_needs_resolve_bits(struct anv_cmd_buffer *cmd_buffer,
+ const struct anv_image *image,
+ VkImageAspectFlagBits aspect,
+ unsigned level,
+ enum anv_image_resolve_bits set_bits)
 {
assert(cmd_buffer && image);
assert(image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
assert(level < anv_image_aux_levels(image, aspect));
 
-   /* The HW docs say that there is no way to guarantee the completion of
-* the following command. We use it nevertheless because it shows no
-* issues in testing is currently being used in the GL driver.
-*/
-   anv_batch_emit(_buffer->batch, GENX(MI_STORE_DATA_IMM), sdi) {
-  sdi.Address = anv_image_get_needs_resolve_addr(cmd_buffer->device,
- image, aspect, level);
-  sdi.ImmediateData = needs_resolve;
+   const struct anv_address resolve_flag_addr =
+  anv_image_get_needs_resolve_addr(cmd_buffer->device,
+   image, aspect, level);
+
+   if (set_bits & ANV_IMAGE_HAS_FAST_CLEAR_BIT) {
+  anv_batch_emit(_buffer->batch, GENX(MI_STORE_DATA_IMM), sdi) {
+ sdi.Address = resolve_flag_addr;
+ sdi.ImmediateData = 1;
+  }
+   }
+   if (set_bits & 

[Mesa-dev] [PATCH 19/29] anv/cmd_buffer: Move the rest of clear_subpass into begin_subpass

[Jason Ekstrand]

---
 src/intel/vulkan/anv_blorp.c   | 243 -
 src/intel/vulkan/anv_private.h |  17 ++-
 src/intel/vulkan/genX_cmd_buffer.c |  68 ++-
 3 files changed, 188 insertions(+), 140 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 7401234..45d7b12 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1132,143 +1132,6 @@ enum subpass_stage {
SUBPASS_STAGE_RESOLVE,
 };
 
-static bool
-subpass_needs_clear(const struct anv_cmd_buffer *cmd_buffer)
-{
-   const struct anv_cmd_state *cmd_state = _buffer->state;
-   uint32_t ds = cmd_state->subpass->depth_stencil_attachment.attachment;
-
-   if (ds != VK_ATTACHMENT_UNUSED) {
-  assert(ds < cmd_state->pass->attachment_count);
-  if (cmd_state->attachments[ds].pending_clear_aspects)
- return true;
-   }
-
-   return false;
-}
-
-void
-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;
-
-   /* Because this gets called within a render pass, we tell blorp not to
-* trash our depth and stencil buffers.
-*/
-   struct blorp_batch batch;
-   blorp_batch_init(_buffer->device->blorp, , cmd_buffer,
-BLORP_BATCH_NO_EMIT_DEPTH_STENCIL);
-
-   VkClearRect clear_rect = {
-  .rect = cmd_buffer->state.render_area,
-  .baseArrayLayer = 0,
-  .layerCount = cmd_buffer->state.framebuffer->layers,
-   };
-
-   struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
-
-   const uint32_t ds = cmd_state->subpass->depth_stencil_attachment.attachment;
-   assert(ds == VK_ATTACHMENT_UNUSED || ds < 
cmd_state->pass->attachment_count);
-
-   if (ds != VK_ATTACHMENT_UNUSED &&
-   cmd_state->attachments[ds].pending_clear_aspects) {
-
-  VkClearAttachment clear_att = {
- .aspectMask = cmd_state->attachments[ds].pending_clear_aspects,
- .clearValue = cmd_state->attachments[ds].clear_value,
-  };
-
-
-  const uint8_t gen = cmd_buffer->device->info.gen;
-  bool clear_with_hiz = gen >= 8 && cmd_state->attachments[ds].aux_usage ==
-ISL_AUX_USAGE_HIZ;
-  const struct anv_image_view *iview = fb->attachments[ds];
-
-  if (clear_with_hiz) {
- const bool clear_depth = clear_att.aspectMask &
-  VK_IMAGE_ASPECT_DEPTH_BIT;
- const bool clear_stencil = clear_att.aspectMask &
-VK_IMAGE_ASPECT_STENCIL_BIT;
-
- /* Check against restrictions for depth buffer clearing. A great GPU
-  * performance benefit isn't expected when using the HZ sequence for
-  * stencil-only clears. Therefore, we don't emit a HZ op sequence for
-  * a stencil clear in addition to using the BLORP-fallback for depth.
-  */
- if (clear_depth) {
-if (!blorp_can_hiz_clear_depth(gen, iview->planes[0].isl.format,
-   iview->image->samples,
-   render_area.offset.x,
-   render_area.offset.y,
-   render_area.offset.x +
-   render_area.extent.width,
-   render_area.offset.y +
-   render_area.extent.height)) {
-   clear_with_hiz = false;
-} else if (clear_att.clearValue.depthStencil.depth !=
-   ANV_HZ_FC_VAL) {
-   /* Don't enable fast depth clears for any color not equal to
-* ANV_HZ_FC_VAL.
-*/
-   clear_with_hiz = false;
-} else if (gen == 8 &&
-   anv_can_sample_with_hiz(_buffer->device->info,
-   iview->image)) {
-   /* Only gen9+ supports returning ANV_HZ_FC_VAL when sampling a
-* fast-cleared portion of a HiZ buffer. Testing has revealed
-* that Gen8 only supports returning 0.0f. Gens prior to gen8 do
-* not support this feature at all.
-*/
-   clear_with_hiz = false;
-}
- }
-
- if (clear_with_hiz) {
-blorp_gen8_hiz_clear_attachments(, iview->image->samples,
- render_area.offset.x,
- render_area.offset.y,
- render_area.offset.x +
- render_area.extent.width,
- render_area.offset.y +
- render_area.extent.height,
-  

Re: [Mesa-dev] [PATCH 2/3] radv: Use the suffixed versions of VK_QUEUE_GLOBAL_PRIORITY_*

[Jason Ekstrand]

On Mon, Nov 27, 2017 at 7:00 PM, Ian Romanick  wrote:

> I am strongly in favor of this precedent.  One thing that has annoyed me
> for years about Mesa's OpenGL code is the use of mixed suffixes through
> the code base as an extension progresses from vendor -> EXT -> ARB -> core.
>

I'm having a bit of trouble with English, I'm afraid.  I'm not sure if that
means you like the patch or hate it.  In any case, the related extension is
*not* in core and the lack of suffixes was a bug. The header/XML update I
sent out as patch 1/3 will break the radv build if we don't have this patch.

--Jason


> On 11/27/2017 06:36 PM, Jason Ekstrand wrote:
> > ---
> >  src/amd/vulkan/radv_device.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> > index 722c768..8e5ae0b 100644
> > --- a/src/amd/vulkan/radv_device.c
> > +++ b/src/amd/vulkan/radv_device.c
> > @@ -895,13 +895,13 @@ radv_get_queue_global_priority(const
> VkDeviceQueueGlobalPriorityCreateInfoEXT *p
> >   return RADEON_CTX_PRIORITY_MEDIUM;
> >
> >   switch(pObj->globalPriority) {
> > - case VK_QUEUE_GLOBAL_PRIORITY_REALTIME:
> > + case VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT:
> >   return RADEON_CTX_PRIORITY_REALTIME;
> > - case VK_QUEUE_GLOBAL_PRIORITY_HIGH:
> > + case VK_QUEUE_GLOBAL_PRIORITY_HIGH_EXT:
> >   return RADEON_CTX_PRIORITY_HIGH;
> > - case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM:
> > + case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT:
> >   return RADEON_CTX_PRIORITY_MEDIUM;
> > - case VK_QUEUE_GLOBAL_PRIORITY_LOW:
> > + case VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT:
> >   return RADEON_CTX_PRIORITY_LOW;
> >   default:
> >   unreachable("Illegal global priority value");
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 09/29] anv/cmd_buffer: Generalize transition_color_buffer

[Jason Ekstrand]

This moves it to being based on layout_to_aux_usage instead of being
hard-coded based on bits of a priori knowledge of how transitions
interact with layouts.  This conceptually simplifies things because
we're now using layout_to_aux_usage and layout_supports_fast_clear to
make resolve decisions so changes to those functions will do what one
expects.

This fixes a potential bug with window system integration on gen9+ where
we wouldn't do a resolve when transitioning to the PRESENT_SRC layout
because we just assume that everything that handles CCS_E can handle it
all the time.  When handing a CCS_E image off to the window system, we
may need to do a full resolve if the window system does not support the
CCS_E modifier.  The only reason why this hasn't been a problem yet is
because we don't support modifiers in Vulkan WSI and so we always get X
tiling which implies no CCS on gen9+.
---
 src/intel/vulkan/genX_cmd_buffer.c | 53 +-
 1 file changed, 41 insertions(+), 12 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index be717eb..65cc85d 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -593,6 +593,7 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
 VkImageLayout initial_layout,
 VkImageLayout final_layout)
 {
+   const struct gen_device_info *devinfo = _buffer->device->info;
/* Validate the inputs. */
assert(cmd_buffer);
assert(image && image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
@@ -733,17 +734,48 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
  VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL,
  final_layout);
   }
-   } else if (initial_layout != VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL) {
-  /* Resolves are only necessary if the subresource may contain blocks
-   * fast-cleared to values unsupported in other layouts. This only occurs
-   * if the initial layout is COLOR_ATTACHMENT_OPTIMAL.
-   */
-  return;
-   } else if (image->samples > 1) {
-  /* MCS buffers don't need resolving. */
   return;
}
 
+   /* If initial aux usage is NONE, there is nothing to resolve */
+   enum isl_aux_usage initial_aux_usage =
+  anv_layout_to_aux_usage(devinfo, image, aspect, initial_layout);
+   if (initial_aux_usage == ISL_AUX_USAGE_NONE)
+  return;
+
+   enum isl_aux_op resolve_op = ISL_AUX_OP_NONE;
+
+   /* If the initial layout supports fast clear but the final one does not,
+* then we need at least a partial resolve.
+*/
+   if (anv_layout_supports_fast_clear(devinfo, image, aspect, initial_layout) 
&&
+   !anv_layout_supports_fast_clear(devinfo, image, aspect, final_layout))
+  resolve_op = ISL_AUX_OP_PARTIAL_RESOLVE;
+
+   enum isl_aux_usage final_aux_usage =
+  anv_layout_to_aux_usage(devinfo, image, aspect, final_layout);
+   if (initial_aux_usage == ISL_AUX_USAGE_CCS_E &&
+   final_aux_usage != ISL_AUX_USAGE_CCS_E)
+  resolve_op = ISL_AUX_OP_FULL_RESOLVE;
+
+   /* CCS_D only supports full resolves and BLORP will assert on us if we try
+* to do a partial resolve on a CCS_D surface.
+*/
+   if (resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE &&
+   initial_aux_usage == ISL_AUX_USAGE_CCS_D)
+  resolve_op = ISL_AUX_OP_FULL_RESOLVE;
+
+   if (resolve_op == ISL_AUX_OP_NONE)
+  return;
+
+   /* Even though the above code can theoretically handle multiple resolve
+* types such as CCS_D -> CCS_E, the predication code below can't.  We only
+* really handle a couple of cases.
+*/
+   assert(initial_aux_usage == ISL_AUX_USAGE_NONE ||
+  final_aux_usage == ISL_AUX_USAGE_NONE ||
+  initial_aux_usage == final_aux_usage);
+
/* Perform a resolve to synchronize data between the main and aux buffer.
 * Before we begin, we must satisfy the cache flushing requirement specified
 * in the Sky Lake PRM Vol. 7, "MCS Buffer for Render Target(s)":
@@ -774,10 +806,7 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
   genX(load_needs_resolve_predicate)(cmd_buffer, image, aspect, level);
 
   anv_image_ccs_op(cmd_buffer, image, aspect, level,
-   base_layer, layer_count,
-   image->planes[plane].aux_usage == ISL_AUX_USAGE_CCS_E ?
-   ISL_AUX_OP_PARTIAL_RESOLVE : ISL_AUX_OP_FULL_RESOLVE,
-   true);
+   base_layer, layer_count, resolve_op, true);
 
   genX(set_image_needs_resolve)(cmd_buffer, image, aspect, level, false);
}
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 25/29] anv/cmd_buffer: Avoid unnecessary transitions before fast clears

[Jason Ekstrand]

Previously, we would always apply the layout transition at the beginning
of the subpass and then do the clear whether fast or slow.  This meant
that there were some cases, specifically when the initial layout is
VK_IMAGE_LAYOUT_UNDEFINED, where we would end up doing a fast-clear or
ambiguate followed immediately by a fast-clear.  This probably isn't
terribly expensive, but it is a waste that we can avoid easily enough
now that we're doing everything at the same time in begin_subpass.
---
 src/intel/vulkan/genX_cmd_buffer.c | 146 +++--
 1 file changed, 106 insertions(+), 40 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 2c4ab38..3473fdd 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3009,6 +3009,101 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
VkRect2D render_area = cmd_buffer->state.render_area;
struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
 
+   /* First, walk through the attachments and handle any full-surface
+* fast-clears.  These are special because they do an implicit layout
+* transition and allow us to potentially avoid a resolve later.
+*/
+   for (uint32_t i = 0; i < subpass->attachment_count; ++i) {
+  const uint32_t a = subpass->attachments[i].attachment;
+  if (a == VK_ATTACHMENT_UNUSED)
+ continue;
+
+  assert(a < cmd_state->pass->attachment_count);
+  struct anv_attachment_state *att_state = _state->attachments[a];
+
+  struct anv_image_view *iview = fb->attachments[a];
+  const struct anv_image *image = iview->image;
+
+  if (!att_state->pending_clear_aspects)
+ continue;
+
+  if (!att_state->fast_clear)
+ continue;
+
+  if (render_area.offset.x != 0 ||
+  render_area.offset.y != 0 ||
+  render_area.extent.width != iview->extent.width ||
+  render_area.extent.height != iview->extent.height)
+ continue;
+
+  if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_COLOR_BIT) {
+ assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+
+ /* Multi-planar images are not supported as attachments */
+ assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+ assert(image->n_planes == 1);
+
+ anv_image_ccs_op(cmd_buffer, image, VK_IMAGE_ASPECT_COLOR_BIT,
+  iview->planes[0].isl.base_level,
+  iview->planes[0].isl.base_array_layer,
+  fb->layers,
+  ISL_AUX_OP_FAST_CLEAR, false);
+
+ genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color.state,
+  image, VK_IMAGE_ASPECT_COLOR_BIT,
+  iview->planes[0].isl.base_level,
+  true /* copy from ss */);
+
+ /* Fast-clears impact whether or not a resolve will be necessary. */
+ if (image->planes[0].aux_usage == ISL_AUX_USAGE_CCS_E &&
+ att_state->clear_color_is_zero) {
+/* This image always has the auxiliary buffer enabled. We can
+ * mark the subresource as not needing a resolve because the
+ * clear color will match what's in every RENDER_SURFACE_STATE
+ * object when it's being used for sampling.
+ */
+clear_image_needs_resolve_bits(cmd_buffer, iview->image,
+   VK_IMAGE_ASPECT_COLOR_BIT,
+   iview->planes[0].isl.base_level,
+   ANV_IMAGE_HAS_FAST_CLEAR_BIT);
+ } else {
+set_image_needs_resolve_bits(cmd_buffer, iview->image,
+ VK_IMAGE_ASPECT_COLOR_BIT,
+ iview->planes[0].isl.base_level,
+ ANV_IMAGE_HAS_FAST_CLEAR_BIT);
+ }
+
+ att_state->pending_clear_aspects = 0;
+ att_state->current_layout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
+  }
+
+  /* We only key the HiZ clear off of DEPTH_BIT because a fast stencil
+   * clear doesn't reset the HiZ buffer contents the way we want.
+   */
+  if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
+ /* We currently only support HiZ for single-layer images */
+ assert(iview->planes[0].isl.base_level == 0);
+ assert(iview->planes[0].isl.base_array_layer == 0);
+ assert(fb->layers == 1);
+
+ anv_image_hiz_clear(cmd_buffer, image,
+ att_state->pending_clear_aspects,
+ iview->planes[0].isl.base_level,
+ iview->planes[0].isl.base_array_layer,
+ fb->layers, render_area,
+ 

[Mesa-dev] [PATCH 28/29] anv/cmd_buffer: Re-arrange the logic around UNDEFINED fast-clears

[Jason Ekstrand]

---
 src/intel/vulkan/genX_cmd_buffer.c | 31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 9e584c1..dcd5a8f 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -823,29 +823,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] [PATCH 18/29] intel/blorp: Add a blorp_hiz_clear_depth_stencil helper

[Jason Ekstrand]

This is similar to blorp_gen8_hiz_clear_attachments except that it takes
actual images instead of trusting in the already set depth state.
---
 src/intel/blorp/blorp.h   | 11 ++
 src/intel/blorp/blorp_clear.c | 50 +++
 2 files changed, 61 insertions(+)

diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
index a1dd571..208b2db 100644
--- a/src/intel/blorp/blorp.h
+++ b/src/intel/blorp/blorp.h
@@ -170,6 +170,17 @@ blorp_can_hiz_clear_depth(uint8_t gen, enum isl_format 
format,
   uint32_t num_samples,
   uint32_t x0, uint32_t y0,
   uint32_t x1, uint32_t y1);
+void
+blorp_hiz_clear_depth_stencil(struct blorp_batch *batch,
+  const struct blorp_surf *depth,
+  const struct blorp_surf *stencil,
+  uint32_t level,
+  uint32_t start_layer, uint32_t num_layers,
+  uint32_t x0, uint32_t y0,
+  uint32_t x1, uint32_t y1,
+  bool clear_depth, float depth_value,
+  bool clear_stencil, uint8_t stencil_value);
+
 
 void
 blorp_gen8_hiz_clear_attachments(struct blorp_batch *batch,
diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
index 8e7bc9f..ec859c2 100644
--- a/src/intel/blorp/blorp_clear.c
+++ b/src/intel/blorp/blorp_clear.c
@@ -612,6 +612,56 @@ blorp_can_hiz_clear_depth(uint8_t gen, enum isl_format 
format,
return true;
 }
 
+void
+blorp_hiz_clear_depth_stencil(struct blorp_batch *batch,
+  const struct blorp_surf *depth,
+  const struct blorp_surf *stencil,
+  uint32_t level,
+  uint32_t start_layer, uint32_t num_layers,
+  uint32_t x0, uint32_t y0,
+  uint32_t x1, uint32_t y1,
+  bool clear_depth, float depth_value,
+  bool clear_stencil, uint8_t stencil_value)
+{
+   struct blorp_params params;
+   blorp_params_init();
+
+   /* This requires WM_HZ_OP which only exists on gen8+ */
+   assert(ISL_DEV_GEN(batch->blorp->isl_dev) >= 8);
+
+   params.hiz_op = BLORP_HIZ_OP_DEPTH_CLEAR;
+   params.num_layers = 1;
+
+   params.x0 = x0;
+   params.y0 = y0;
+   params.x1 = x1;
+   params.y1 = y1;
+
+   for (uint32_t l = 0; l < num_layers; l++) {
+  const uint32_t layer = start_layer + l;
+  if (clear_stencil) {
+ brw_blorp_surface_info_init(batch->blorp, , stencil,
+ level, layer,
+ ISL_FORMAT_UNSUPPORTED, true);
+ params.stencil_mask = 0xff;
+ params.stencil_ref = stencil_value;
+ params.num_samples = params.stencil.surf.samples;
+  }
+
+  if (clear_depth) {
+ brw_blorp_surface_info_init(batch->blorp, , depth,
+ level, layer,
+ ISL_FORMAT_UNSUPPORTED, true);
+ params.depth.clear_color.f32[0] = depth_value;
+ params.depth_format =
+isl_format_get_depth_format(depth->surf->format, false);
+ params.num_samples = params.depth.surf.samples;
+  }
+
+  batch->blorp->exec(batch, );
+   }
+}
+
 /* Given a depth stencil attachment, this function performs a fast depth clear
  * on a depth portion and a regular clear on the stencil portion. When
  * performing a fast depth clear on the depth portion, the HiZ buffer is simply
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 27/29] anv/cmd_buffer: Pull the undefined layout condition into the if

[Jason Ekstrand]

Now that this isn't a multi-case if and it's just the one case, it's a
bit clearer if the condition is just part of the if instead of being
pulled out into a boolean variable.
---
 src/intel/vulkan/genX_cmd_buffer.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 3473fdd..9e584c1 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -793,20 +793,15 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
   anv_image_aux_layers(image, aspect, base_level) - 
base_layer);
last_level_num = base_level + level_count;
 
-   /* Record whether or not the layout is undefined. Pre-initialized images
-* with auxiliary buffers have a non-linear layout and are thus undefined.
-*/
assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
-   const bool undef_layout = initial_layout == VK_IMAGE_LAYOUT_UNDEFINED ||
- initial_layout == VK_IMAGE_LAYOUT_PREINITIALIZED;
 
-   /* Do preparatory work before the resolve operation or return early if no
-* resolve is actually needed.
-*/
-   if (undef_layout) {
+   if (initial_layout == VK_IMAGE_LAYOUT_UNDEFINED ||
+   initial_layout == VK_IMAGE_LAYOUT_PREINITIALIZED) {
   /* A subresource in the undefined layout may have been aliased and
* populated with any arrangement of bits. Therefore, we must initialize
* the related aux buffer and clear buffer entry with desirable values.
+   * An initial layout of PREINITIALIZED is the same as UNDEFINED for
+   * images with VK_IMAGE_TILING_OPTIMAL.
*
* Initialize the relevant clear buffer entries.
*/
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 04/29] anv/blorp: Rework HiZ ops to look like MCS and CCS

[Jason Ekstrand]

---
 src/intel/vulkan/anv_blorp.c   | 38 ++
 src/intel/vulkan/anv_private.h |  9 +
 src/intel/vulkan/genX_cmd_buffer.c | 11 ++-
 3 files changed, 33 insertions(+), 25 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index f10adf0..da273d6 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1568,26 +1568,30 @@ anv_image_copy_to_shadow(struct anv_cmd_buffer 
*cmd_buffer,
blorp_batch_finish();
 }
 
-void
-anv_gen8_hiz_op_resolve(struct anv_cmd_buffer *cmd_buffer,
-const struct anv_image *image,
-enum blorp_hiz_op op)
+static enum blorp_hiz_op
+isl_to_blorp_hiz_op(enum isl_aux_op isl_op)
 {
-   assert(image);
+   switch (isl_op) {
+   case ISL_AUX_OP_FAST_CLEAR:   return BLORP_HIZ_OP_DEPTH_CLEAR;
+   case ISL_AUX_OP_FULL_RESOLVE: return BLORP_HIZ_OP_DEPTH_RESOLVE;
+   case ISL_AUX_OP_AMBIGUATE:return BLORP_HIZ_OP_HIZ_RESOLVE;
+   default:
+  unreachable("Unsupported HiZ aux op");
+   }
+}
 
+void
+anv_image_hiz_op(struct anv_cmd_buffer *cmd_buffer,
+ const struct anv_image *image,
+ VkImageAspectFlagBits aspect, uint32_t level,
+ uint32_t base_layer, uint32_t layer_count,
+ enum isl_aux_op hiz_op)
+{
+   assert(aspect == VK_IMAGE_ASPECT_DEPTH_BIT);
+   assert(base_layer + layer_count <= anv_image_aux_layers(image, aspect, 0));
assert(anv_image_aspect_to_plane(image->aspects,
 VK_IMAGE_ASPECT_DEPTH_BIT) == 0);
 
-   /* Don't resolve depth buffers without an auxiliary HiZ buffer and
-* don't perform such a resolve on gens that don't support it.
-*/
-   if (cmd_buffer->device->info.gen < 8 ||
-   image->planes[0].aux_usage != ISL_AUX_USAGE_HIZ)
-  return;
-
-   assert(op == BLORP_HIZ_OP_HIZ_RESOLVE ||
-  op == BLORP_HIZ_OP_DEPTH_RESOLVE);
-
struct blorp_batch batch;
blorp_batch_init(_buffer->device->blorp, , cmd_buffer, 0);
 
@@ -1597,7 +1601,9 @@ anv_gen8_hiz_op_resolve(struct anv_cmd_buffer *cmd_buffer,
 ISL_AUX_USAGE_HIZ, );
surf.clear_color.f32[0] = ANV_HZ_FC_VAL;
 
-   blorp_hiz_op(, , 0, 0, 1, op);
+   blorp_hiz_op(, , level, base_layer, layer_count,
+isl_to_blorp_hiz_op(hiz_op));
+
blorp_batch_finish();
 }
 
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index dc44ab6..5dd95a3 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2530,10 +2530,11 @@ anv_can_sample_with_hiz(const struct gen_device_info * 
const devinfo,
 }
 
 void
-anv_gen8_hiz_op_resolve(struct anv_cmd_buffer *cmd_buffer,
-const struct anv_image *image,
-enum blorp_hiz_op op);
-
+anv_image_hiz_op(struct anv_cmd_buffer *cmd_buffer,
+ const struct anv_image *image,
+ VkImageAspectFlagBits aspect, uint32_t level,
+ uint32_t base_layer, uint32_t layer_count,
+ enum isl_aux_op hiz_op);
 void
 anv_image_mcs_op(struct anv_cmd_buffer *cmd_buffer,
  const struct anv_image *image,
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 2e7a2cc..0c1ae83 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -388,19 +388,20 @@ transition_depth_buffer(struct anv_cmd_buffer *cmd_buffer,
   anv_layout_to_aux_usage(_buffer->device->info, image,
   VK_IMAGE_ASPECT_DEPTH_BIT, final_layout);
 
-   enum blorp_hiz_op hiz_op;
+   enum isl_aux_op hiz_op;
if (hiz_enabled && !enable_hiz) {
-  hiz_op = BLORP_HIZ_OP_DEPTH_RESOLVE;
+  hiz_op = ISL_AUX_OP_FULL_RESOLVE;
} else if (!hiz_enabled && enable_hiz) {
-  hiz_op = BLORP_HIZ_OP_HIZ_RESOLVE;
+  hiz_op = ISL_AUX_OP_AMBIGUATE;
} else {
   assert(hiz_enabled == enable_hiz);
   /* If the same buffer will be used, no resolves are necessary. */
-  hiz_op = BLORP_HIZ_OP_NONE;
+  hiz_op = ISL_AUX_OP_NONE;
}
 
if (hiz_op != BLORP_HIZ_OP_NONE)
-  anv_gen8_hiz_op_resolve(cmd_buffer, image, hiz_op);
+  anv_image_hiz_op(cmd_buffer, image, VK_IMAGE_ASPECT_DEPTH_BIT,
+   0, 0, 1, hiz_op);
 }
 
 #define MI_PREDICATE_SRC0  0x2400
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 24/29] anv/cmd_buffer: Do subpass image transitions in begin/end_subpass

[Jason Ekstrand]

---
 src/intel/vulkan/genX_cmd_buffer.c | 187 +
 1 file changed, 65 insertions(+), 122 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 7901b0c..2c4ab38 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -2982,120 +2982,6 @@ cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer 
*cmd_buffer)
cmd_buffer->state.hiz_enabled = info.hiz_usage == ISL_AUX_USAGE_HIZ;
 }
 
-
-/**
- * @brief Perform any layout transitions required at the beginning and/or end
- *of the current subpass for depth buffers.
- *
- * TODO: Consider preprocessing the attachment reference array at render pass
- *   create time to determine if no layout transition is needed at the
- *   beginning and/or end of each subpass.
- *
- * @param cmd_buffer The command buffer the transition is happening within.
- * @param subpass_end If true, marks that the transition is happening at the
- *end of the subpass.
- */
-static void
-cmd_buffer_subpass_transition_layouts(struct anv_cmd_buffer * const cmd_buffer,
-  const bool subpass_end)
-{
-   /* We need a non-NULL command buffer. */
-   assert(cmd_buffer);
-
-   const struct anv_cmd_state * const cmd_state = _buffer->state;
-   const struct anv_subpass * const subpass = cmd_state->subpass;
-
-   /* This function must be called within a subpass. */
-   assert(subpass);
-
-   /* If there are attachment references, the array shouldn't be NULL.
-*/
-   if (subpass->attachment_count > 0)
-  assert(subpass->attachments);
-
-   /* Iterate over the array of attachment references. */
-   for (const VkAttachmentReference *att_ref = subpass->attachments;
-att_ref < subpass->attachments + subpass->attachment_count; att_ref++) 
{
-
-  /* If the attachment is unused, we can't perform a layout transition. */
-  if (att_ref->attachment == VK_ATTACHMENT_UNUSED)
- continue;
-
-  /* This attachment index shouldn't go out of bounds. */
-  assert(att_ref->attachment < cmd_state->pass->attachment_count);
-
-  const struct anv_render_pass_attachment * const att_desc =
- _state->pass->attachments[att_ref->attachment];
-  struct anv_attachment_state * const att_state =
- _buffer->state.attachments[att_ref->attachment];
-
-  /* The attachment should not be used in a subpass after its last. */
-  assert(att_desc->last_subpass_idx >= anv_get_subpass_id(cmd_state));
-
-  if (subpass_end && anv_get_subpass_id(cmd_state) <
-  att_desc->last_subpass_idx) {
- /* We're calling this function on a buffer twice in one subpass and
-  * this is not the last use of the buffer. The layout should not have
-  * changed from the first call and no transition is necessary.
-  */
- assert(att_state->current_layout == att_ref->layout ||
-att_state->current_layout ==
-VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL);
- continue;
-  }
-
-  /* The attachment index must be less than the number of attachments
-   * within the framebuffer.
-   */
-  assert(att_ref->attachment < cmd_state->framebuffer->attachment_count);
-
-  const struct anv_image_view * const iview =
- cmd_state->framebuffer->attachments[att_ref->attachment];
-  const struct anv_image * const image = iview->image;
-
-  /* Get the appropriate target layout for this attachment. */
-  VkImageLayout target_layout;
-
-  /* A resolve is necessary before use as an input attachment if the clear
-   * color or auxiliary buffer usage isn't supported by the sampler.
-   */
-  const bool input_needs_resolve =
-(att_state->fast_clear && !att_state->clear_color_is_zero_one) ||
-att_state->input_aux_usage != att_state->aux_usage;
-  if (subpass_end) {
- target_layout = att_desc->final_layout;
-  } else if (iview->aspect_mask & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV &&
- !input_needs_resolve) {
- /* Layout transitions before the final only help to enable sampling as
-  * an input attachment. If the input attachment supports sampling
-  * using the auxiliary surface, we can skip such transitions by making
-  * the target layout one that is CCS-aware.
-  */
- target_layout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
-  } else {
- target_layout = att_ref->layout;
-  }
-
-  /* Perform the layout transition. */
-  if (image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
- transition_depth_buffer(cmd_buffer, image,
- att_state->current_layout, target_layout);
- att_state->aux_usage =
-anv_layout_to_aux_usage(_buffer->device->info, image,
-VK_IMAGE_ASPECT_DEPTH_BIT, target_layout);
-  

[Mesa-dev] [PATCH 11/29] anv/cmd_buffer: Add a mark_image_written helper

[Jason Ekstrand]

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   | 36 
 src/intel/vulkan/anv_cmd_buffer.c  | 12 
 src/intel/vulkan/anv_genX.h|  6 ++
 src/intel/vulkan/anv_private.h |  7 +++
 src/intel/vulkan/genX_cmd_buffer.c | 17 +
 5 files changed, 78 insertions(+)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index da273d6..46e2eb0 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -271,6 +271,7 @@ void anv_CmdCopyImage(
 
   assert(anv_image_aspects_compatible(src_mask, dst_mask));
 
+  const uint32_t dst_level = pRegions[r].dstSubresource.mipLevel;
   if (_mesa_bitcount(src_mask) > 1) {
  uint32_t aspect_bit;
  anv_foreach_image_aspect_bit(aspect_bit, src_image, src_mask) {
@@ -281,6 +282,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);
 
 for (unsigned i = 0; i < layer_count; i++) {
blorp_copy(, _surf, 
pRegions[r].srcSubresource.mipLevel,
@@ -298,6 +303,8 @@ 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);
 
  for (unsigned i = 0; i < layer_count; i++) {
 blorp_copy(, _surf, pRegions[r].srcSubresource.mipLevel,
@@ -387,6 +394,12 @@ copy_buffer_to_image(struct anv_cmd_buffer *cmd_buffer,
 extent.width, extent.height,
 buffer_row_pitch, buffer_format,
 , _isl_surf);
+  if (dst->surf.aux_usage != ISL_AUX_USAGE_NONE) {
+ assert(dst == );
+ anv_cmd_buffer_mark_image_written(cmd_buffer, anv_image,
+   aspect, dst->surf.aux_usage,
+   dst->level);
+  }
 
   for (unsigned z = 0; z < extent.depth; z++) {
  blorp_copy(, >surf, src->level, src->offset.z,
@@ -497,6 +510,10 @@ void anv_CmdBlitImage(
   get_blorp_surf_for_anv_image(cmd_buffer->device,
dst_image, dst_res->aspectMask,
ANV_AUX_USAGE_DEFAULT, );
+  anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image,
+dst_res->aspectMask,
+dst.aux_usage,
+dst_res->mipLevel);
 
   struct anv_format_plane src_format =
  anv_get_format_plane(_buffer->device->info, src_image->vk_format,
@@ -820,6 +837,10 @@ 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);
+
  blorp_clear(, ,
  src_format.isl_format, src_format.swizzle,
  level, base_layer, layer_count,
@@ -1215,6 +1236,11 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
 ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
   } else {
  assert(image->n_planes == 1);
+ anv_cmd_buffer_mark_image_written(cmd_buffer, image,
+   VK_IMAGE_ASPECT_COLOR_BIT,
+   att_state->aux_usage,
+   iview->planes[0].isl.base_level);
+
  blorp_clear(, , iview->planes[0].isl.format,
  anv_swizzle_for_render(iview->planes[0].isl.swizzle),
  iview->planes[0].isl.base_level,
@@ -1355,6 +1381,8 @@ resolve_image(struct anv_device *device,
   uint32_t src_x, uint32_t src_y, uint32_t dst_x, uint32_t dst_y,
   uint32_t width, uint32_t height)
 {
+   struct anv_cmd_buffer *cmd_buffer = batch->driver_batch;
+
assert(src_image->type == VK_IMAGE_TYPE_2D);
assert(src_image->samples > 1);
  

[Mesa-dev] [PATCH 10/29] anv/cmd_buffer: Add an anv_genX_call macro

[Jason Ekstrand]

This is copied and pasted from the similar macro we added to ISL.
---
 src/intel/vulkan/anv_cmd_buffer.c | 40 ---
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/src/intel/vulkan/anv_cmd_buffer.c 
b/src/intel/vulkan/anv_cmd_buffer.c
index 69acafa..7e7580c 100644
--- a/src/intel/vulkan/anv_cmd_buffer.c
+++ b/src/intel/vulkan/anv_cmd_buffer.c
@@ -323,24 +323,34 @@ VkResult anv_ResetCommandBuffer(
return anv_cmd_buffer_reset(cmd_buffer);
 }
 
+#define anv_genX_call(devinfo, func, ...)  \
+   switch ((devinfo)->gen) {   \
+   case 7: \
+  if ((devinfo)->is_haswell) { \
+ gen75_##func(__VA_ARGS__);\
+  } else { \
+ gen7_##func(__VA_ARGS__); \
+  }\
+  break;   \
+   case 8: \
+  gen8_##func(__VA_ARGS__);\
+  break;   \
+   case 9: \
+  gen9_##func(__VA_ARGS__);\
+  break;   \
+   case 10:\
+  gen10_##func(__VA_ARGS__);   \
+  break;   \
+   default:\
+  assert(!"Unknown hardware generation");  \
+   }
+
 void
 anv_cmd_buffer_emit_state_base_address(struct anv_cmd_buffer *cmd_buffer)
 {
-   switch (cmd_buffer->device->info.gen) {
-   case 7:
-  if (cmd_buffer->device->info.is_haswell)
- return gen75_cmd_buffer_emit_state_base_address(cmd_buffer);
-  else
- return gen7_cmd_buffer_emit_state_base_address(cmd_buffer);
-   case 8:
-  return gen8_cmd_buffer_emit_state_base_address(cmd_buffer);
-   case 9:
-  return gen9_cmd_buffer_emit_state_base_address(cmd_buffer);
-   case 10:
-  return gen10_cmd_buffer_emit_state_base_address(cmd_buffer);
-   default:
-  unreachable("unsupported gen\n");
-   }
+   anv_genX_call(_buffer->device->info,
+ cmd_buffer_emit_state_base_address,
+ cmd_buffer);
 }
 
 void anv_CmdBindPipeline(
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 12/29] anv/cmd_buffer: Drop the genX from get/set_needs_resolve

[Jason Ekstrand]

They are static functions so there's no real need to have the genX and
it just makes the function names longer.
---
 src/intel/vulkan/genX_cmd_buffer.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 7d040bd..6aeffa3 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -411,7 +411,7 @@ transition_depth_buffer(struct anv_cmd_buffer *cmd_buffer,
  * performed properly.
  */
 static void
-genX(set_image_needs_resolve)(struct anv_cmd_buffer *cmd_buffer,
+set_image_needs_resolve(struct anv_cmd_buffer *cmd_buffer,
 const struct anv_image *image,
 VkImageAspectFlagBits aspect,
 unsigned level, bool needs_resolve)
@@ -432,10 +432,10 @@ genX(set_image_needs_resolve)(struct anv_cmd_buffer 
*cmd_buffer,
 }
 
 static void
-genX(load_needs_resolve_predicate)(struct anv_cmd_buffer *cmd_buffer,
-   const struct anv_image *image,
-   VkImageAspectFlagBits aspect,
-   unsigned level)
+load_needs_resolve_predicate(struct anv_cmd_buffer *cmd_buffer,
+ const struct anv_image *image,
+ VkImageAspectFlagBits aspect,
+ unsigned level)
 {
assert(cmd_buffer && image);
assert(image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
@@ -488,8 +488,8 @@ init_fast_clear_state_entry(struct anv_cmd_buffer 
*cmd_buffer,
 * to return incorrect data. The fast clear data in CCS_D buffers should
 * be removed because CCS_D isn't enabled all the time.
 */
-   genX(set_image_needs_resolve)(cmd_buffer, image, aspect, level,
- aux_usage == ISL_AUX_USAGE_NONE);
+   set_image_needs_resolve(cmd_buffer, image, aspect, level,
+   aux_usage == ISL_AUX_USAGE_NONE);
 
/* The fast clear value dword(s) will be copied into a surface state object.
 * Ensure that the restrictions of the fields in the dword(s) are followed.
@@ -812,12 +812,12 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
  layer_count = MIN2(layer_count, anv_image_aux_layers(image, aspect, 
level));
   }
 
-  genX(load_needs_resolve_predicate)(cmd_buffer, image, aspect, level);
+  load_needs_resolve_predicate(cmd_buffer, image, aspect, level);
 
   anv_image_ccs_op(cmd_buffer, image, aspect, level,
base_layer, layer_count, resolve_op, true);
 
-  genX(set_image_needs_resolve)(cmd_buffer, image, aspect, level, false);
+  set_image_needs_resolve(cmd_buffer, image, aspect, level, false);
}
 
cmd_buffer->state.pending_pipe_bits |=
@@ -2992,15 +2992,15 @@ cmd_buffer_subpass_sync_fast_clear_values(struct 
anv_cmd_buffer *cmd_buffer)
  * will match what's in every RENDER_SURFACE_STATE object when it's
  * being used for sampling.
  */
-genX(set_image_needs_resolve)(cmd_buffer, iview->image,
-  VK_IMAGE_ASPECT_COLOR_BIT,
-  iview->planes[0].isl.base_level,
-  false);
+set_image_needs_resolve(cmd_buffer, iview->image,
+VK_IMAGE_ASPECT_COLOR_BIT,
+iview->planes[0].isl.base_level,
+false);
  } else {
-genX(set_image_needs_resolve)(cmd_buffer, iview->image,
-  VK_IMAGE_ASPECT_COLOR_BIT,
-  iview->planes[0].isl.base_level,
-  true);
+set_image_needs_resolve(cmd_buffer, iview->image,
+VK_IMAGE_ASPECT_COLOR_BIT,
+iview->planes[0].isl.base_level,
+true);
  }
   } else if (rp_att->load_op == VK_ATTACHMENT_LOAD_OP_LOAD) {
  /* The attachment may have been fast-cleared in a previous render
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 00/29] anv: Rework resolves and fast clears

[Jason Ekstrand]

This patch series is a major rework of the aux tracking and fast clear code
in our Vulkan driver.  It's broken up into three basic pieces:

 1) Patches 1-13 rework the way layout transitions work and add some
additional granularity to our aux tracking scheme.  This is required to
support Y-tiled window system buffers where we have CCS_E but need to
do a full resolve prior to handing it off to the window system.  The
current code does a partial resolve if and only if CCS_E is enabled.
These patches may get back-ported to 17.3 because it seems that people
are hitting issues with this somewhere in Chrome.

 2) Patches 14-25 rework the code we have for doing fast clears, setting up
indirect clear colors, and doing implicit layout transitions.  In
particular, we pull them all together into a single begin/end_subpass
function pair instead of scattering them across multiple functions in
genX_cmd_buffer.c and anv_blorp.c.  This allows us to avoid the
redundant fast-clear that you get when you have LOAD_OP_CLEAR combined
with IMAGE_LAYOUT_UNDEFINED.

 3) Patches 26-29 revive my old CCS ambiguate pass and make us use that
instead of a fast-clear for initializing CCS buffers on gen9+.  This
should allow us to avoid some unneeded resolves in a couple of corner
cases.  It also simplifies transition_color_buffer a decent bit.

I've organized this patch series in order of priority both in terms of time
and in terms of importance.  If the third chunk doesn't land for a while or
never at all, I'm not going to cry over it, but I do think it's quite a bit
better.

Cc: Nanley Chery 

Jason Ekstrand (29):
  intel/isl: Codify AUX operations in an enum
  anv/blorp: Rework image clear/resolve helpers
  anv/blorp: Support ISL_AUX_USAGE_HIZ in surf_for_anv_image
  anv/blorp: Rework HiZ ops to look like MCS and CCS
  anv/image: Update a comment
  anv/image: Add a helper for determining when fast clears are supported
  anv/image: Support color aspects in layout_to_aux_usage
  anv/cmd_buffer: Recurse in transition_color_buffer instead of falling
through
  anv/cmd_buffer: Generalize transition_color_buffer
  anv/cmd_buffer: Add an anv_genX_call macro
  anv/cmd_buffer: Add a mark_image_written helper
  anv/cmd_buffer: Drop the genX from get/set_needs_resolve
  anv/cmd_buffer: Rework aux tracking
  anv/cmd_buffer: Apply subpass flushes before set_subpass
  anv/cmd_buffer: Add begin/end_subpass helpers
  anv/cmd_buffer: Pass a subpass id into begin_subpass
  anv/cmd_buffer: Move the color portion of clear_subpass into
begin_subpass
  intel/blorp: Add a blorp_hiz_clear_depth_stencil helper
  anv/cmd_buffer: Move the rest of clear_subpass into begin_subpass
  anv/cmd_buffer: Decide whether or not to HiZ clear up-front
  anv/cmd_buffer: Iterate all subpass attachments when clearing
  anv/cmd_buffer: Add a concept of pending load aspects
  anv/cmd_buffer: Sync clear values in begin_subpass
  anv/cmd_buffer: Do subpass image transitions in begin/end_subpass
  anv/cmd_buffer: Avoid unnecessary transitions before fast clears
  intel/blorp: Add a CCS ambiguation pass
  anv/cmd_buffer: Pull the undefined layout condition into the if
  anv/cmd_buffer: Re-arrange the logic around UNDEFINED fast-clears
  anv: Use blorp_ccs_ambiguate instead of fast-clears

 src/intel/blorp/blorp.h|  16 +
 src/intel/blorp/blorp_clear.c  | 156 
 src/intel/isl/isl.h|  74 ++--
 src/intel/vulkan/anv_blorp.c   | 661 +++---
 src/intel/vulkan/anv_cmd_buffer.c  |  52 ++-
 src/intel/vulkan/anv_genX.h|   6 +
 src/intel/vulkan/anv_image.c   | 108 -
 src/intel/vulkan/anv_private.h |  86 +++-
 src/intel/vulkan/genX_cmd_buffer.c | 795 +++--
 9 files changed, 1249 insertions(+), 705 deletions(-)

-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 16/29] anv/cmd_buffer: Pass a subpass id into begin_subpass

[Jason Ekstrand]

This is a bit less awkward than passing in the subpass because it means
we don't have to extract the subpass id from the subpass.
---
 src/intel/vulkan/genX_cmd_buffer.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 6f2fa0a..56036f7 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3136,13 +3136,11 @@ cmd_buffer_subpass_sync_fast_clear_values(struct 
anv_cmd_buffer *cmd_buffer)
}
 }
 
-
 static void
 cmd_buffer_begin_subpass(struct anv_cmd_buffer *cmd_buffer,
- struct anv_subpass *subpass)
+ uint32_t subpass_id)
 {
-   cmd_buffer->state.subpass = subpass;
-   uint32_t subpass_id = anv_get_subpass_id(_buffer->state);
+   cmd_buffer->state.subpass = _buffer->state.pass->subpasses[subpass_id];
 
cmd_buffer->state.dirty |= ANV_CMD_DIRTY_RENDER_TARGETS;
 
@@ -3222,7 +3220,7 @@ void genX(CmdBeginRenderPass)(
 
genX(flush_pipeline_select_3d)(cmd_buffer);
 
-   cmd_buffer_begin_subpass(cmd_buffer, pass->subpasses);
+   cmd_buffer_begin_subpass(cmd_buffer, 0);
 }
 
 void genX(CmdNextSubpass)(
@@ -3236,9 +3234,9 @@ void genX(CmdNextSubpass)(
 
assert(cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_PRIMARY);
 
+   uint32_t prev_subpass = anv_get_subpass_id(_buffer->state);
cmd_buffer_end_subpass(cmd_buffer);
-
-   cmd_buffer_begin_subpass(cmd_buffer, cmd_buffer->state.subpass + 1);
+   cmd_buffer_begin_subpass(cmd_buffer, prev_subpass + 1);
 }
 
 void genX(CmdEndRenderPass)(
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 06/29] anv/image: Add a helper for determining when fast clears are supported

[Jason Ekstrand]

---
 src/intel/vulkan/anv_image.c   | 58 ++
 src/intel/vulkan/anv_private.h |  5 
 2 files changed, 63 insertions(+)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index a872149..561da28 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -837,6 +837,64 @@ anv_layout_to_aux_usage(const struct gen_device_info * 
const devinfo,
unreachable("layout is not a VkImageLayout enumeration member.");
 }
 
+/**
+ * This function returns true if the given image in the given VkImageLayout
+ * supports unresolved fast-clears.
+ *
+ * @param devinfo The device information of the Intel GPU.
+ * @param image The image that may contain a collection of buffers.
+ * @param aspect The aspect of the image to be accessed.
+ * @param layout The current layout of the image aspect(s).
+ */
+bool
+anv_layout_supports_fast_clear(const struct gen_device_info * const devinfo,
+   const struct anv_image * const image,
+   const VkImageAspectFlagBits aspect,
+   const VkImageLayout layout)
+{
+   /* The aspect must be exactly one of the image aspects. */
+   assert(_mesa_bitcount(aspect) == 1 && (aspect & image->aspects));
+
+   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
+
+   /* If there is no auxiliary surface allocated, there are no fast-clears */
+   if (image->planes[plane].aux_surface.isl.size == 0)
+  return false;
+
+   /* All images that use an auxiliary surface are required to be tiled. */
+   assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
+
+   /* Stencil has no aux */
+   assert(aspect != VK_IMAGE_ASPECT_STENCIL_BIT);
+
+   if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT) {
+  /* For depth images (with HiZ), the layout supports fast-clears if and
+   * only if it supports HiZ.
+   */
+  enum isl_aux_usage aux_usage =
+ anv_layout_to_aux_usage(devinfo, image, aspect, layout);
+  return aux_usage == ISL_AUX_USAGE_HIZ;
+   }
+
+   assert(image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
+
+   /* Multisample fast-clear is not yet supported. */
+   if (image->samples > 1)
+  return false;
+
+   /* The only layout which actually supports fast-clears today is
+* VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL.  Some day in the future
+* this may change if our ability to track clear colors improves.
+*/
+   switch (layout) {
+   case VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL:
+  return true;
+
+   default:
+  return false;
+   }
+}
+
 
 static struct anv_state
 alloc_surface_state(struct anv_device *device)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 5dd95a3..461bfed 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2559,6 +2559,11 @@ anv_layout_to_aux_usage(const struct gen_device_info * 
const devinfo,
 const struct anv_image *image,
 const VkImageAspectFlagBits aspect,
 const VkImageLayout layout);
+bool
+anv_layout_supports_fast_clear(const struct gen_device_info * const devinfo,
+   const struct anv_image * const image,
+   const VkImageAspectFlagBits aspect,
+   const VkImageLayout layout);
 
 /* This is defined as a macro so that it works for both
  * VkImageSubresourceRange and VkImageSubresourceLayers
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 01/29] intel/isl: Codify AUX operations in an enum

[Jason Ekstrand]

Right now, we have different entrypoints and enums in blorp for these
different operations.  This provides us a central enum which we can
begin to transition to.
---
 src/intel/isl/isl.h | 74 +++--
 1 file changed, 49 insertions(+), 25 deletions(-)

diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index e3acb0e..fda2411 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -661,31 +661,8 @@ enum isl_aux_usage {
  *
  * Drawing with or without aux enabled may implicitly cause the surface to
  * transition between these states.  There are also four types of auxiliary
- * compression operations which cause an explicit transition:
- *
- *1) Fast Clear:  This operation writes the magic "clear" value to the
- *   auxiliary surface.  This operation will safely transition any slice
- *   of a surface from any state to the clear state so long as the entire
- *   slice is fast cleared at once.  A fast clear that only covers part of
- *   a slice of a surface is called a partial fast clear.
- *
- *2) Full Resolve:  This operation combines the auxiliary surface data
- *   with the primary surface data and writes the result to the primary.
- *   For HiZ, the docs call this a depth resolve.  For CCS, the hardware
- *   full resolve operation does both a full resolve and an ambiguate so
- *   it actually takes you all the way to the pass-through state.
- *
- *3) Partial Resolve:  This operation considers blocks which are in the
- *   "clear" state and writes the clear value directly into the primary or
- *   auxiliary surface.  Once this operation completes, the surface is
- *   still compressed but no longer references the clear color.  This
- *   operation is only available for CCS.
- *
- *4) Ambiguate:  This operation throws away the current auxiliary data and
- *   replaces it with the magic pass-through value.  If an ambiguate
- *   operation is performed when the primary surface does not contain 100%
- *   of the data, data will be lost.  This operation is only implemented
- *   in hardware for depth where it is called a HiZ resolve.
+ * compression operations which cause an explicit transition which are
+ * described by the isl_aux_op enum below.
  *
  * Not all operations are valid or useful in all states.  The diagram below
  * contains a complete description of the states and all valid and useful
@@ -787,6 +764,53 @@ enum isl_aux_state {
ISL_AUX_STATE_AUX_INVALID,
 };
 
+/**
+ * Enum which describes explicit aux transition operations.
+ */
+enum isl_aux_op {
+   ISL_AUX_OP_NONE,
+
+   /** Fast Clear
+*
+* This operation writes the magic "clear" value to the auxiliary surface.
+* This operation will safely transition any slice of a surface from any
+* state to the clear state so long as the entire slice is fast cleared at
+* once.  A fast clear that only covers part of a slice of a surface is
+* called a partial fast clear.
+*/
+   ISL_AUX_OP_FAST_CLEAR,
+
+   /** Full Resolve
+*
+* This operation combines the auxiliary surface data with the primary
+* surface data and writes the result to the primary.  For HiZ, the docs
+* call this a depth resolve.  For CCS, the hardware full resolve operation
+* does both a full resolve and an ambiguate so it actually takes you all
+* the way to the pass-through state.
+*/
+   ISL_AUX_OP_FULL_RESOLVE,
+
+   /** Partial Resolve
+*
+* This operation considers blocks which are in the "clear" state and
+* writes the clear value directly into the primary or auxiliary surface.
+* Once this operation completes, the surface is still compressed but no
+* longer references the clear color.  This operation is only available
+* for CCS_E.
+*/
+   ISL_AUX_OP_PARTIAL_RESOLVE,
+
+   /** Ambiguate
+*
+* This operation throws away the current auxiliary data and replaces it
+* with the magic pass-through value.  If an ambiguate operation is
+* performed when the primary surface does not contain 100% of the data,
+* data will be lost.  This operation is only implemented in hardware for
+* depth where it is called a HiZ resolve.
+*/
+   ISL_AUX_OP_AMBIGUATE,
+};
+
 /* TODO(chadv): Explain */
 enum isl_array_pitch_span {
ISL_ARRAY_PITCH_SPAN_FULL,
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 08/29] anv/cmd_buffer: Recurse in transition_color_buffer instead of falling through

[Jason Ekstrand]

---
 src/intel/vulkan/genX_cmd_buffer.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 0c1ae83..be717eb 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -719,20 +719,19 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
   if (image->samples == 1 &&
   image->planes[plane].aux_usage != ISL_AUX_USAGE_CCS_E &&
   final_layout != VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL) {
- /* The CCS_D buffer may not be enabled in the final layout. Continue
-  * executing this function to perform a resolve.
+ /* The CCS_D buffer may not be enabled in the final layout. Call this
+  * function again with a initial layout of COLOR_ATTACHMENT_OPTIMAL
+  * to perform a resolve.
   */
   anv_perf_warn(cmd_buffer->device->instance, image,
 "Performing an additional resolve for CCS_D layout "
 "transition. Consider always leaving it on or "
 "performing an ambiguation pass.");
-  } else {
- /* Writes in the final layout will be aware of the auxiliary buffer.
-  * In addition, the clear buffer entries and the auxiliary buffers
-  * have been populated with values that will result in correct
-  * rendering.
-  */
- return;
+ transition_color_buffer(cmd_buffer, image, aspect,
+ base_level, level_count,
+ base_layer, layer_count,
+ VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL,
+ final_layout);
   }
} else if (initial_layout != VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL) {
   /* Resolves are only necessary if the subresource may contain blocks
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 23/29] anv/cmd_buffer: Sync clear values in begin_subpass

[Jason Ekstrand]

This is quite a bit cleaner because we now sync the clear values at the
same time as we do the fast clear.  For loading the clear values into
the surface state, we now do it once when we handle the LOAD_OP_LOAD
instead of every subpass.
---
 src/intel/vulkan/anv_private.h |   8 ++
 src/intel/vulkan/genX_cmd_buffer.c | 154 +
 2 files changed, 60 insertions(+), 102 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index f4b0f90..4137a9a 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2823,6 +2823,14 @@ anv_subpass_view_count(const struct anv_subpass *subpass)
return MAX2(1, _mesa_bitcount(subpass->view_mask));
 }
 
+static inline bool
+anv_subpass_att_is_color(const struct anv_subpass *subpass,
+ const VkAttachmentReference *att)
+{
+   return att >= subpass->color_attachments &&
+  att < subpass->color_attachments + subpass->color_count;
+}
+
 struct anv_render_pass_attachment {
/* TODO: Consider using VkAttachmentDescription instead of storing each of
 * its members individually.
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 0915d1a..7901b0c 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3096,99 +3096,6 @@ cmd_buffer_subpass_transition_layouts(struct 
anv_cmd_buffer * const cmd_buffer,
}
 }
 
-/* Update the clear value dword(s) in surface state objects or the fast clear
- * state buffer entry for the color attachments used in this subpass.
- */
-static void
-cmd_buffer_subpass_sync_fast_clear_values(struct anv_cmd_buffer *cmd_buffer)
-{
-   assert(cmd_buffer && cmd_buffer->state.subpass);
-
-   const struct anv_cmd_state *state = _buffer->state;
-
-   /* Iterate through every color attachment used in this subpass. */
-   for (uint32_t i = 0; i < state->subpass->color_count; ++i) {
-
-  /* The attachment should be one of the attachments described in the
-   * render pass and used in the subpass.
-   */
-  const uint32_t a = state->subpass->color_attachments[i].attachment;
-  if (a == VK_ATTACHMENT_UNUSED)
- continue;
-
-  assert(a < state->pass->attachment_count);
-
-  /* Store some information regarding this attachment. */
-  const struct anv_attachment_state *att_state = >attachments[a];
-  const struct anv_image_view *iview = state->framebuffer->attachments[a];
-  const struct anv_render_pass_attachment *rp_att =
- >pass->attachments[a];
-
-  if (att_state->aux_usage == ISL_AUX_USAGE_NONE)
- continue;
-
-  /* The fast clear state entry must be updated if a fast clear is going to
-   * happen. The surface state must be updated if the clear value from a
-   * prior fast clear may be needed.
-   */
-  if (att_state->pending_clear_aspects && att_state->fast_clear) {
- /* Update the fast clear state entry. */
- genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color.state,
-  iview->image,
-  VK_IMAGE_ASPECT_COLOR_BIT,
-  iview->planes[0].isl.base_level,
-  true /* copy from ss */);
-
- /* Fast-clears impact whether or not a resolve will be necessary. */
- if (iview->image->planes[0].aux_usage == ISL_AUX_USAGE_CCS_E &&
- att_state->clear_color_is_zero) {
-/* This image always has the auxiliary buffer enabled. We can mark
- * the subresource as not needing a resolve because the clear color
- * will match what's in every RENDER_SURFACE_STATE object when it's
- * being used for sampling.
- */
-clear_image_needs_resolve_bits(cmd_buffer, iview->image,
-   VK_IMAGE_ASPECT_COLOR_BIT,
-   iview->planes[0].isl.base_level,
-   ANV_IMAGE_HAS_FAST_CLEAR_BIT);
- } else {
-set_image_needs_resolve_bits(cmd_buffer, iview->image,
- VK_IMAGE_ASPECT_COLOR_BIT,
- iview->planes[0].isl.base_level,
- ANV_IMAGE_HAS_FAST_CLEAR_BIT);
- }
-  } else if (rp_att->load_op == VK_ATTACHMENT_LOAD_OP_LOAD) {
- /* The attachment may have been fast-cleared in a previous render
-  * pass and the value is needed now. Update the surface state(s).
-  *
-  * TODO: Do this only once per render pass instead of every subpass.
-  */
- genX(copy_fast_clear_dwords)(cmd_buffer, att_state->color.state,
-  iview->image,
-  VK_IMAGE_ASPECT_COLOR_BIT,
-

[Mesa-dev] [PATCH 26/29] intel/blorp: Add a CCS ambiguation pass

[Jason Ekstrand]

---
 src/intel/blorp/blorp.h   |   5 ++
 src/intel/blorp/blorp_clear.c | 106 ++
 2 files changed, 111 insertions(+)

diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
index 208b2db..dda0bf9 100644
--- a/src/intel/blorp/blorp.h
+++ b/src/intel/blorp/blorp.h
@@ -215,6 +215,11 @@ blorp_ccs_resolve(struct blorp_batch *batch,
   enum blorp_fast_clear_op resolve_op);
 
 void
+blorp_ccs_ambiguate(struct blorp_batch *batch,
+struct blorp_surf *surf,
+uint32_t level, uint32_t layer);
+
+void
 blorp_mcs_partial_resolve(struct blorp_batch *batch,
   struct blorp_surf *surf,
   enum isl_format format,
diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
index ec859c2..af4d1c7 100644
--- a/src/intel/blorp/blorp_clear.c
+++ b/src/intel/blorp/blorp_clear.c
@@ -931,3 +931,109 @@ blorp_mcs_partial_resolve(struct blorp_batch *batch,
 
batch->blorp->exec(batch, );
 }
+
+/** Clear a CCS to the "uncompressed" state
+ *
+ * This pass is the CCS equivalent of a "HiZ resolve".  It sets the CCS values
+ * for a given layer/level of a surface to 0x0 which is the "uncompressed"
+ * state which tells the sampler to go look at the main surface.
+ */
+void
+blorp_ccs_ambiguate(struct blorp_batch *batch,
+struct blorp_surf *surf,
+uint32_t level, uint32_t layer)
+{
+   struct blorp_params params;
+   blorp_params_init();
+
+   assert(ISL_DEV_GEN(batch->blorp->isl_dev) >= 9);
+
+   const struct isl_format_layout *aux_fmtl =
+  isl_format_get_layout(surf->aux_surf->format);
+   assert(aux_fmtl->txc == ISL_TXC_CCS);
+
+   params.dst = (struct brw_blorp_surface_info) {
+  .enabled = true,
+  .addr = surf->aux_addr,
+  .view = {
+ .usage = ISL_SURF_USAGE_RENDER_TARGET_BIT,
+ .format = ISL_FORMAT_R32G32B32A32_UINT,
+ .base_level = 0,
+ .base_array_layer = 0,
+ .levels = 1,
+ .array_len = 1,
+ .swizzle = ISL_SWIZZLE_IDENTITY,
+  },
+   };
+
+   uint32_t z = 0;
+   if (surf->surf->dim == ISL_SURF_DIM_3D) {
+  z = layer;
+  layer = 0;
+   }
+
+   uint32_t offset_B, x_offset_el, y_offset_el;
+   isl_surf_get_image_offset_el(surf->aux_surf, level, layer, z,
+_offset_el, _offset_el);
+   isl_tiling_get_intratile_offset_el(surf->aux_surf->tiling, aux_fmtl->bpb,
+  surf->aux_surf->row_pitch,
+  x_offset_el, y_offset_el,
+  _B, _offset_el, _offset_el);
+   params.dst.addr.offset += offset_B;
+
+   const uint32_t width_px = minify(surf->surf->logical_level0_px.width, 
level);
+   const uint32_t height_px = minify(surf->surf->logical_level0_px.height, 
level);
+   const uint32_t width_el = DIV_ROUND_UP(width_px, aux_fmtl->bw);
+   const uint32_t height_el = DIV_ROUND_UP(height_px, aux_fmtl->bh);
+
+   /* We're going to map it as a regular RGBA32_UINT surface.  We need to
+* downscale a good deal.  From the Sky Lake PRM Vol. 12 in the section on
+* planes:
+*
+*"The Color Control Surface (CCS) contains the compression status
+*of the cache-line pairs. The compression state of the cache-line
+*pair is specified by 2 bits in the CCS.  Each CCS cache-line
+*represents an area on the main surface of 16x16 sets of 128 byte
+*Y-tiled cache-line-pairs. CCS is always Y tiled."
+*
+* Each 2-bit surface element in the CCS corresponds to a single cache-line
+* pair in the main surface.  This means that 16x16 el block in the CCS
+* maps to a Y-tiled cache line.  Fortunately, CCS layouts are calculated
+* with a very large alignment so we can round up without worrying about
+* overdraw.
+*/
+   assert(x_offset_el % 16 == 0 && y_offset_el % 4 == 0);
+   const uint32_t x_offset_rgba_px = x_offset_el / 16;
+   const uint32_t y_offset_rgba_px = y_offset_el / 4;
+   const uint32_t width_rgba_px = DIV_ROUND_UP(width_el, 16);
+   const uint32_t height_rgba_px = DIV_ROUND_UP(height_el, 4);
+
+   MAYBE_UNUSED bool ok =
+  isl_surf_init(batch->blorp->isl_dev, ,
+.dim = ISL_SURF_DIM_2D,
+.format = ISL_FORMAT_R32G32B32A32_UINT,
+.width = width_rgba_px + x_offset_rgba_px,
+.height = height_rgba_px + y_offset_rgba_px,
+.depth = 1,
+.levels = 1,
+.array_len = 1,
+.samples = 1,
+.row_pitch = surf->aux_surf->row_pitch,
+.usage = ISL_SURF_USAGE_RENDER_TARGET_BIT,
+.tiling_flags = ISL_TILING_Y0_BIT);
+   assert(ok);
+
+   params.x0 = x_offset_rgba_px;
+   params.y0 = y_offset_rgba_px;
+   params.x1 = x_offset_rgba_px + width_rgba_px;
+   

[Mesa-dev] [PATCH 02/29] anv/blorp: Rework image clear/resolve helpers

[Jason Ekstrand]

This replaces image_fast_clear and ccs_resolve with two new helpers that
simply perform an isl_aux_op whatever that may be on CCS or MCS.  This
is a bit cleaner as it separates performing the aux operation from which
blorp helper we have to call to do it.
---
 src/intel/vulkan/anv_blorp.c   | 218 ++---
 src/intel/vulkan/anv_private.h |  23 ++--
 src/intel/vulkan/genX_cmd_buffer.c |  28 +++--
 3 files changed, 165 insertions(+), 104 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index e244468..7c8a673 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1439,75 +1439,6 @@ fast_clear_aux_usage(const struct anv_image *image,
 }
 
 void
-anv_image_fast_clear(struct anv_cmd_buffer *cmd_buffer,
- const struct anv_image *image,
- VkImageAspectFlagBits aspect,
- const uint32_t base_level, const uint32_t level_count,
- const uint32_t base_layer, uint32_t layer_count)
-{
-   assert(image->type == VK_IMAGE_TYPE_3D || image->extent.depth == 1);
-
-   if (image->type == VK_IMAGE_TYPE_3D) {
-  assert(base_layer == 0);
-  assert(layer_count == anv_minify(image->extent.depth, base_level));
-   }
-
-   struct blorp_batch batch;
-   blorp_batch_init(_buffer->device->blorp, , cmd_buffer, 0);
-
-   struct blorp_surf surf;
-   get_blorp_surf_for_anv_image(cmd_buffer->device, image, aspect,
-fast_clear_aux_usage(image, aspect),
-);
-
-   /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
-*
-*"After Render target fast clear, pipe-control with color cache
-*write-flush must be issued before sending any DRAW commands on
-*that render target."
-*
-* This comment is a bit cryptic and doesn't really tell you what's going
-* or what's really needed.  It appears that fast clear ops are not
-* properly synchronized with other drawing.  This means that we cannot
-* have a fast clear operation in the pipe at the same time as other
-* regular drawing operations.  We need to use a PIPE_CONTROL to ensure
-* that the contents of the previous draw hit the render target before we
-* resolve and then use a second PIPE_CONTROL after the resolve to ensure
-* that it is completed before any additional drawing occurs.
-*/
-   cmd_buffer->state.pending_pipe_bits |=
-  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
-
-   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
-   uint32_t width_div = image->format->planes[plane].denominator_scales[0];
-   uint32_t height_div = image->format->planes[plane].denominator_scales[1];
-
-   for (uint32_t l = 0; l < level_count; l++) {
-  const uint32_t level = base_level + l;
-
-  const VkExtent3D extent = {
- .width = anv_minify(image->extent.width, level),
- .height = anv_minify(image->extent.height, level),
- .depth = anv_minify(image->extent.depth, level),
-  };
-
-  if (image->type == VK_IMAGE_TYPE_3D)
- layer_count = extent.depth;
-
-  assert(level < anv_image_aux_levels(image, aspect));
-  assert(base_layer + layer_count <= anv_image_aux_layers(image, aspect, 
level));
-  blorp_fast_clear(, , surf.surf->format,
-   level, base_layer, layer_count,
-   0, 0,
-   extent.width / width_div,
-   extent.height / height_div);
-   }
-
-   cmd_buffer->state.pending_pipe_bits |=
-  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
-}
-
-void
 anv_cmd_buffer_resolve_subpass(struct anv_cmd_buffer *cmd_buffer)
 {
struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
@@ -1681,36 +1612,153 @@ anv_gen8_hiz_op_resolve(struct anv_cmd_buffer 
*cmd_buffer,
 }
 
 void
-anv_ccs_resolve(struct anv_cmd_buffer * const cmd_buffer,
-const struct anv_image * const image,
-VkImageAspectFlagBits aspect,
-const uint8_t level,
-const uint32_t start_layer, const uint32_t layer_count,
-const enum blorp_fast_clear_op op)
+anv_image_mcs_op(struct anv_cmd_buffer *cmd_buffer,
+ const struct anv_image *image,
+ VkImageAspectFlagBits aspect,
+ uint32_t base_layer, uint32_t layer_count,
+ enum isl_aux_op mcs_op, bool predicate)
 {
-   assert(cmd_buffer && image);
+   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+   assert(image->samples > 1);
+   assert(base_layer + layer_count <= anv_image_aux_layers(image, aspect, 0));
 
-   uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
+   /* We don't support planar images with multisampling yet */
+   assert(image->n_planes == 1);
+
+   struct blorp_batch batch;
+   

[Mesa-dev] [PATCH 03/29] anv/blorp: Support ISL_AUX_USAGE_HIZ in surf_for_anv_image

[Jason Ekstrand]

If the function gets passed ANV_AUX_USAGE_DEFAULT, it still has the old
behavior of setting ISL_AUX_USAGE_NONE for depth/stencil which is what
we want for blits/copies.
---
 src/intel/vulkan/anv_blorp.c | 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 7c8a673..f10adf0 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -193,12 +193,13 @@ get_blorp_surf_for_anv_image(const struct anv_device 
*device,
 {
uint32_t plane = anv_image_aspect_to_plane(image->aspects, aspect);
 
-   if (aux_usage == ANV_AUX_USAGE_DEFAULT)
+   if (aux_usage == ANV_AUX_USAGE_DEFAULT) {
   aux_usage = image->planes[plane].aux_usage;
 
-   if (aspect == VK_IMAGE_ASPECT_STENCIL_BIT ||
-   aux_usage == ISL_AUX_USAGE_HIZ)
-  aux_usage = ISL_AUX_USAGE_NONE;
+  if (aspect == VK_IMAGE_ASPECT_STENCIL_BIT ||
+  aux_usage == ISL_AUX_USAGE_HIZ)
+ aux_usage = ISL_AUX_USAGE_NONE;
+   }
 
const struct anv_surface *surface = >planes[plane].surface;
*blorp_surf = (struct blorp_surf) {
@@ -1593,18 +1594,7 @@ anv_gen8_hiz_op_resolve(struct anv_cmd_buffer 
*cmd_buffer,
struct blorp_surf surf;
get_blorp_surf_for_anv_image(cmd_buffer->device,
 image, VK_IMAGE_ASPECT_DEPTH_BIT,
-ISL_AUX_USAGE_NONE, );
-
-   /* Manually add the aux HiZ surf */
-   surf.aux_surf = >planes[0].aux_surface.isl,
-   surf.aux_addr = (struct blorp_address) {
-  .buffer = image->planes[0].bo,
-  .offset = image->planes[0].bo_offset +
-image->planes[0].aux_surface.offset,
-  .mocs = cmd_buffer->device->default_mocs,
-   };
-   surf.aux_usage = ISL_AUX_USAGE_HIZ;
-
+ISL_AUX_USAGE_HIZ, );
surf.clear_color.f32[0] = ANV_HZ_FC_VAL;
 
blorp_hiz_op(, , 0, 0, 1, op);
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 22/29] anv/cmd_buffer: Add a concept of pending load aspects

[Jason Ekstrand]

These are the same as pending clear aspects only for the "load"
operation.
---
 src/intel/vulkan/anv_private.h |  1 +
 src/intel/vulkan/genX_cmd_buffer.c | 22 --
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index b881157..f4b0f90 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1670,6 +1670,7 @@ struct anv_attachment_state {
 
VkImageLayoutcurrent_layout;
VkImageAspectFlags   pending_clear_aspects;
+   VkImageAspectFlags   pending_load_aspects;
bool fast_clear;
VkClearValue clear_value;
bool clear_color_is_zero_one;
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index e5e0d1c..0915d1a 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -1050,26 +1050,36 @@ genX(cmd_buffer_setup_attachments)(struct 
anv_cmd_buffer *cmd_buffer,
  struct anv_render_pass_attachment *att = >attachments[i];
  VkImageAspectFlags att_aspects = vk_format_aspects(att->format);
  VkImageAspectFlags clear_aspects = 0;
+ VkImageAspectFlags load_aspects = 0;
 
  if (att_aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV) {
 /* color attachment */
 if (att->load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
clear_aspects |= VK_IMAGE_ASPECT_COLOR_BIT;
+} else if (att->load_op == VK_ATTACHMENT_LOAD_OP_LOAD) {
+   load_aspects |= VK_IMAGE_ASPECT_COLOR_BIT;
 }
  } else {
 /* depthstencil attachment */
-if ((att_aspects & VK_IMAGE_ASPECT_DEPTH_BIT) &&
-att->load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
-   clear_aspects |= VK_IMAGE_ASPECT_DEPTH_BIT;
+if (att_aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
+   if (att->load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
+  clear_aspects |= VK_IMAGE_ASPECT_DEPTH_BIT;
+   } else if (att->load_op == VK_ATTACHMENT_LOAD_OP_LOAD) {
+  load_aspects |= VK_IMAGE_ASPECT_DEPTH_BIT;
+   }
 }
-if ((att_aspects & VK_IMAGE_ASPECT_STENCIL_BIT) &&
-att->stencil_load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
-   clear_aspects |= VK_IMAGE_ASPECT_STENCIL_BIT;
+if (att_aspects & VK_IMAGE_ASPECT_STENCIL_BIT) {
+   if (att->stencil_load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
+  clear_aspects |= VK_IMAGE_ASPECT_STENCIL_BIT;
+   } else if (att->stencil_load_op == VK_ATTACHMENT_LOAD_OP_LOAD) {
+  load_aspects |= VK_IMAGE_ASPECT_STENCIL_BIT;
+   }
 }
  }
 
  state->attachments[i].current_layout = att->initial_layout;
  state->attachments[i].pending_clear_aspects = clear_aspects;
+ state->attachments[i].pending_load_aspects = load_aspects;
  if (clear_aspects)
 state->attachments[i].clear_value = begin->pClearValues[i];
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 07/29] anv/image: Support color aspects in layout_to_aux_usage

[Jason Ekstrand]

---
 src/intel/vulkan/anv_image.c | 48 ++--
 1 file changed, 29 insertions(+), 19 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 561da28..7e89f75 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -748,12 +748,6 @@ anv_layout_to_aux_usage(const struct gen_device_info * 
const devinfo,
/* Stencil has no aux */
assert(aspect != VK_IMAGE_ASPECT_STENCIL_BIT);
 
-   /* The following switch currently only handles depth stencil aspects.
-* TODO: Handle the color aspect.
-*/
-   if (image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV)
-  return image->planes[plane].aux_usage;
-
switch (layout) {
 
/* Invalid Layouts */
@@ -773,28 +767,38 @@ anv_layout_to_aux_usage(const struct gen_device_info * 
const devinfo,
 
 
/* Transfer Layouts
-*
-* This buffer could be a depth buffer used in a transfer operation. BLORP
-* currently doesn't use HiZ for transfer operations so we must use the main
-* buffer for this layout. TODO: Enable HiZ in BLORP.
 */
case VK_IMAGE_LAYOUT_GENERAL:
case VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL:
case VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL:
-  return ISL_AUX_USAGE_NONE;
+  if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT) {
+ /* This buffer could be a depth buffer used in a transfer operation.
+  * BLORP currently doesn't use HiZ for transfer operations so we must
+  * use the main buffer for this layout. TODO: Enable HiZ in BLORP.
+  */
+ assert(image->planes[plane].aux_usage == ISL_AUX_USAGE_HIZ);
+ return ISL_AUX_USAGE_NONE;
+  } else {
+ assert(image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
+ return image->planes[plane].aux_usage;
+  }
 
 
/* Sampling Layouts */
case VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL:
+   case VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR:
   assert((image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV) == 0);
   /* Fall-through */
case VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL:
-   case VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR:
-  assert(aspect == VK_IMAGE_ASPECT_DEPTH_BIT);
-  if (anv_can_sample_with_hiz(devinfo, image))
- return ISL_AUX_USAGE_HIZ;
-  else
- return ISL_AUX_USAGE_NONE;
+  if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT) {
+ if (anv_can_sample_with_hiz(devinfo, image))
+return ISL_AUX_USAGE_HIZ;
+ else
+return ISL_AUX_USAGE_NONE;
+  } else {
+ return image->planes[plane].aux_usage;
+  }
+
 
case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR:
   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
@@ -819,8 +823,14 @@ anv_layout_to_aux_usage(const struct gen_device_info * 
const devinfo,
 
/* Rendering Layouts */
case VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL:
-  assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
-  unreachable("Color images are not yet supported.");
+  assert(aspect & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV);
+  if (image->planes[plane].aux_usage == ISL_AUX_USAGE_NONE) {
+ assert(image->samples == 1);
+ return ISL_AUX_USAGE_CCS_D;
+  } else {
+ assert(image->planes[plane].aux_usage != ISL_AUX_USAGE_CCS_D);
+ return image->planes[plane].aux_usage;
+  }
 
case VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL:
case VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL_KHR:
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH 2/3] radv: Use the suffixed versions of VK_QUEUE_GLOBAL_PRIORITY_*

[Ian Romanick]

I am strongly in favor of this precedent.  One thing that has annoyed me
for years about Mesa's OpenGL code is the use of mixed suffixes through
the code base as an extension progresses from vendor -> EXT -> ARB -> core.

On 11/27/2017 06:36 PM, Jason Ekstrand wrote:
> ---
>  src/amd/vulkan/radv_device.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 722c768..8e5ae0b 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -895,13 +895,13 @@ radv_get_queue_global_priority(const 
> VkDeviceQueueGlobalPriorityCreateInfoEXT *p
>   return RADEON_CTX_PRIORITY_MEDIUM;
>  
>   switch(pObj->globalPriority) {
> - case VK_QUEUE_GLOBAL_PRIORITY_REALTIME:
> + case VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT:
>   return RADEON_CTX_PRIORITY_REALTIME;
> - case VK_QUEUE_GLOBAL_PRIORITY_HIGH:
> + case VK_QUEUE_GLOBAL_PRIORITY_HIGH_EXT:
>   return RADEON_CTX_PRIORITY_HIGH;
> - case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM:
> + case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT:
>   return RADEON_CTX_PRIORITY_MEDIUM;
> - case VK_QUEUE_GLOBAL_PRIORITY_LOW:
> + case VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT:
>   return RADEON_CTX_PRIORITY_LOW;
>   default:
>   unreachable("Illegal global priority value");
> 

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

Re: [Mesa-dev] [PATCH mesa 0/7] remove upstreamed specs

[Ian Romanick]

On 11/23/2017 05:32 AM, Emil Velikov wrote:
> Hi Eric,
> 
> On 22 November 2017 at 17:59, Eric Engestrom  
> wrote:
>> A recent thread [1] made me check our local specs to see which ones were
>> upstream. This series removes the ones that are identical upstream
>> (modulo "TBD" extension numbers in some cases).
>>
>> There are a few more specs left that are upstream, but have typo fixes
>> that I'm going to submit to Khronos, and I'll remove the local copies
>> once the fixes have been upstreamed:
> The idea sounds great, just some minor comments - mostly about
> potential deprecation.
> 
>> - EGL_MESA_drm_image
> The extension, lacks information about error handling (et al) and is
> no longer used.
> There is even an extra bitmask in eglmesaext.h that's quite meh thing to do.
> Perhaps we should consider officially deprecating it as hinted earlier [1]
> 
> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-June/161575.html
> 
>> - GLX_MESA_release_buffers
> Extension is implemented only for Xlib based libGL. The DRI codepath
> has a TODO for at least 7 years.
> Worth checking if anyone uses it and not just deprecate the extension?
> 
>> Eric Engestrom (7):
>>   docs/specs: remove upstreamed spec EGL_MESA_platform_surfaceless
>>   docs/specs: remove upstreamed spec MESA_image_dma_buf_export
>>   docs/specs: remove upstreamed spec MESA_shader_integer_functions
>>   docs/specs: remove upstreamed spec EXT_shader_integer_mix
> 
>>   docs/specs: remove upstreamed spec MESA_agp_offset
>>   docs/specs: remove upstreamed spec MESA_pixmap_colormap
>>   docs/specs: remove upstreamed spec MESA_set_3dfx_mode
> These three are also Xlib libGL only. Above idea applies.

MESA_agp_offset wasn't Xlib, but it is long dead.  It was killed by
ARB_vertex_buffer_object.  MESA_set_3dfx_mode dead when we stopped
supporting the Glide (3dfx's proprietary, low-level graphics API) Mesa
driver.  Neither of these have been supported by any Mesa driver in
many, many years, and they will never come back from that grave.

>>
> There are a few references to the spec files in docs/. Can you update those?
> 
> The series looks OK, yet blessing from veterans is appreciated
> Acked-by: Emil Velikov 
> 
> 
> Thanks
> Emil
> ___
> 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: Implemnet VK_EXT_external_memory_dma_buf

[Jason Ekstrand]

---

This is only compile-tested as there are no tests for this extension at
present.  However, I'd really like use the DMA_BUF handle type in my WSI
rework instead of using OPAQUE_FD and trusting that the exported FD really
is a prime FD.

 src/amd/vulkan/radv_device.c  | 8 ++--
 src/amd/vulkan/radv_extensions.py | 1 +
 src/amd/vulkan/radv_formats.c | 8 ++--
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 8e5ae0b..4517227 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -2166,7 +2166,9 @@ VkResult radv_alloc_memory(VkDevice   
 _device,
 
if (import_info) {
assert(import_info->handleType ==
-  VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR);
+  VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR ||
+  import_info->handleType ==
+  VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT);
mem->bo = device->ws->buffer_from_fd(device->ws, 
import_info->fd,
 NULL, NULL);
if (!mem->bo) {
@@ -3540,7 +3542,9 @@ VkResult radv_GetMemoryFdKHR(VkDevice _device,
 
/* We support only one handle type. */
assert(pGetFdInfo->handleType ==
-  VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR);
+  VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR ||
+  pGetFdInfo->handleType ==
+  VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT);
 
bool ret = radv_get_memory_fd(device, memory, pFD);
if (ret == false)
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index eeb679d..4af137c 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -78,6 +78,7 @@ EXTENSIONS = [
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
 Extension('VK_KHX_multiview', 1, True),
 Extension('VK_EXT_debug_report',  8, True),
+Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_global_priority',   1, 
'device->rad_info.has_ctx_priority'),
 Extension('VK_AMD_draw_indirect_count',   1, True),
 Extension('VK_AMD_rasterization_order',   1, 
'device->rad_info.chip_class >= VI && device->rad_info.max_se >= 2'),
diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index 5c79ea7..c008c1b 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -1182,7 +1182,8 @@ get_external_image_format_properties(const 
VkPhysicalDeviceImageFormatInfo2KHR *
switch (pImageFormatInfo->type) {
case VK_IMAGE_TYPE_2D:
flags = 
VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_KHR|VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_KHR|VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_KHR;
-   compat_flags = export_flags = 
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR;
+   compat_flags = export_flags = 
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR |
+ 
VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT;
break;
default:
break;
@@ -1241,6 +1242,7 @@ VkResult radv_GetPhysicalDeviceImageFormatProperties2KHR(
if (external_info && external_info->handleType != 0) {
switch (external_info->handleType) {
case VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR:
+   case VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT:
get_external_image_format_properties(base_info, 
_props->externalMemoryProperties);
break;
default:
@@ -1309,9 +1311,11 @@ void radv_GetPhysicalDeviceExternalBufferPropertiesKHR(
VkExternalMemoryHandleTypeFlagsKHR compat_flags = 0;
switch(pExternalBufferInfo->handleType) {
case VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR:
+   case VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT:
flags = VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_KHR |
VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_KHR;
-   compat_flags = export_flags = 
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR;
+   compat_flags = export_flags = 
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR |
+ 
VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT;
break;
default:
break;
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH mesa 0/7] remove upstreamed specs

[Ian Romanick]

On 11/27/2017 02:24 AM, Eric Engestrom wrote:
> On Sunday, 2017-11-26 17:24:09 -0800, Eric Anholt wrote:
>> Eric Engestrom  writes:
>>
>>> On Wednesday, 2017-11-22 12:28:17 -0800, Eric Anholt wrote:
 Jordan Justen  writes:

> On 2017-11-22 09:59:34, Eric Engestrom wrote:
>> A recent thread [1] made me check our local specs to see which ones were
>> upstream. This series removes the ones that are identical upstream
>> (modulo "TBD" extension numbers in some cases).
>
> While I don't have too strong of an opinion on it, I think we should
> keep a copy of Mesa specs that are in the upstream registry.
>
> I think it makes sense to send a patch to mesa-dev for new Mesa specs
> or changes to Mesa specs. Having a copy in docs/specs works well for
> that.

 The downside is that that process means that we'll inevitably keep stale
 or divergent copies in Mesa, when the canonical location for GL specs is
 Khronos.  We do have a reasonable process for modifying Khronos's specs
 now, which we didn't before.
>>>
>>> Exactly, our local copies are not the authority, Khronos is.
>>>
>>> Changes to specs should be sent to Khronos, on the relevant repo, by
>>> creating a pull request like I've now done for the specs I mentioned
>>> in the cover letter:
>>> https://github.com/KhronosGroup/EGL-Registry/pull/36
>>> https://github.com/KhronosGroup/OpenGL-Registry/pull/132
>>> https://github.com/KhronosGroup/OpenGL-Registry/pull/133
>>> https://github.com/KhronosGroup/OpenGL-Registry/pull/134
>>> https://github.com/KhronosGroup/OpenGL-Registry/pull/135
>>> https://github.com/KhronosGroup/OpenGL-Registry/pull/136
>>> https://github.com/KhronosGroup/OpenGL-Registry/pull/137
>>>

 I think we should get all our specs out and into the Khronos.
>>>
>>> Ack; should I let the specs authors do this themselves, or push them for
>>> them?
>>
>> If you have the time and energy to upstream them, I think that would be
>> quite welcome.
> 
> Not right now, probably not before Christmas either.
> 
>> I'm sure a lot of these are basically forgotten and
>> people's original motivation for the extensions has faded away.
> 
> That's my worry; what's the point of taking time to upstream them if
> they're dead? Who will explain why we need them and argue the case in
> Khronos?

If the extension is or was ever shipped, that's justification enough to
get it in the registry.  If there are extensions that never shipped,
then there's probably no point.  I haven't looked at the list of
extensions yet, so I may be talking out of my hat...

> I think what I'll do is send a series to mark the remaining extensions
> as deprecated, and CC all the people involved in each extension, and let
> that series sit for a while.
> 
> If people come out and say "no, I still want this extension", they can
> explain why and I'll pass on the explanations to Khronos if they can't.
> If I don't hear anything after a few months, I'll go ahead and push the
> deprecation patches.
> 
> Does that sound like a plan?
> ___
> 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 2/3] radv: Use the suffixed versions of VK_QUEUE_GLOBAL_PRIORITY_*

[Jason Ekstrand]

---
 src/amd/vulkan/radv_device.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 722c768..8e5ae0b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -895,13 +895,13 @@ radv_get_queue_global_priority(const 
VkDeviceQueueGlobalPriorityCreateInfoEXT *p
return RADEON_CTX_PRIORITY_MEDIUM;
 
switch(pObj->globalPriority) {
-   case VK_QUEUE_GLOBAL_PRIORITY_REALTIME:
+   case VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT:
return RADEON_CTX_PRIORITY_REALTIME;
-   case VK_QUEUE_GLOBAL_PRIORITY_HIGH:
+   case VK_QUEUE_GLOBAL_PRIORITY_HIGH_EXT:
return RADEON_CTX_PRIORITY_HIGH;
-   case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM:
+   case VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT:
return RADEON_CTX_PRIORITY_MEDIUM;
-   case VK_QUEUE_GLOBAL_PRIORITY_LOW:
+   case VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT:
return RADEON_CTX_PRIORITY_LOW;
default:
unreachable("Illegal global priority value");
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 3/3] anv: Implement VK_EXT_external_memory_dma_buf

[Jason Ekstrand]

This is a modified version of the patch originally sent by Chad Versace.
The primary difference is that this version claims that OPQAUE_FD and
DMA_BUF are compatible handle types.
---
 src/intel/vulkan/anv_device.c  | 13 ++---
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_formats.c |  8 ++--
 3 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index b5577ee..df929e4 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1563,11 +1563,11 @@ VkResult anv_AllocateMemory(
 * ignored.
 */
if (fd_info && fd_info->handleType) {
-  /* At the moment, we only support the OPAQUE_FD memory type which is
-   * just a GEM buffer.
-   */
+  /* At the moment, we support only the below handle types. */
   assert(fd_info->handleType ==
- VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR);
+   VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR ||
+ fd_info->handleType ==
+   VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT);
 
   result = anv_bo_cache_import(device, >bo_cache,
fd_info->fd, >bo);
@@ -1641,9 +1641,8 @@ VkResult anv_GetMemoryFdKHR(
 
assert(pGetFdInfo->sType == VK_STRUCTURE_TYPE_MEMORY_GET_FD_INFO_KHR);
 
-   /* We support only one handle type. */
-   assert(pGetFdInfo->handleType ==
-  VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR);
+   assert(pGetFdInfo->handleType == 
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR ||
+  pGetFdInfo->handleType == 
VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT);
 
return anv_bo_cache_export(dev, >bo_cache, mem->bo, pFd);
 }
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index b1e984b..093c89f 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -86,6 +86,7 @@ EXTENSIONS = [
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
 Extension('VK_KHX_multiview', 1, True),
 Extension('VK_EXT_debug_report',  8, True),
+Extension('VK_EXT_external_memory_dma_buf',   1, True),
 ]
 
 class VkVersion:
diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index 810f26c..4075ae8 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -866,9 +866,11 @@ static const VkExternalMemoryPropertiesKHR prime_fd_props 
= {
  VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_KHR,
/* For the moment, let's not support mixing and matching */
.exportFromImportedHandleTypes =
-  VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR,
+  VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR |
+  VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT,
.compatibleHandleTypes =
-  VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR,
+  VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR |
+  VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT,
 };
 
 VkResult anv_GetPhysicalDeviceImageFormatProperties2KHR(
@@ -923,6 +925,7 @@ VkResult anv_GetPhysicalDeviceImageFormatProperties2KHR(
if (external_info && external_info->handleType != 0) {
   switch (external_info->handleType) {
   case VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR:
+  case VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT:
  if (external_props)
 external_props->externalMemoryProperties = prime_fd_props;
  break;
@@ -1005,6 +1008,7 @@ void anv_GetPhysicalDeviceExternalBufferPropertiesKHR(
 
switch (pExternalBufferInfo->handleType) {
case VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR:
+   case VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT:
   pExternalBufferProperties->externalMemoryProperties = prime_fd_props;
   return;
default:
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 1/3] vulkan: Update the XML and headers to 1.0.66

[Jason Ekstrand]

---
 include/vulkan/vulkan.h| 69 ++--
 src/vulkan/registry/vk.xml | 71 --
 2 files changed, 116 insertions(+), 24 deletions(-)

diff --git a/include/vulkan/vulkan.h b/include/vulkan/vulkan.h
index 048866c..ec67abe 100644
--- a/include/vulkan/vulkan.h
+++ b/include/vulkan/vulkan.h
@@ -43,7 +43,7 @@ extern "C" {
 #define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
 #define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
 // Version of this file
-#define VK_HEADER_VERSION 64
+#define VK_HEADER_VERSION 66
 
 
 #define VK_NULL_HANDLE 0
@@ -355,6 +355,9 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_VALIDATION_CACHE_CREATE_INFO_EXT = 100016,
 VK_STRUCTURE_TYPE_SHADER_MODULE_VALIDATION_CACHE_CREATE_INFO_EXT = 
1000160001,
 VK_STRUCTURE_TYPE_DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_EXT = 
1000174000,
+VK_STRUCTURE_TYPE_IMPORT_MEMORY_HOST_POINTER_INFO_EXT = 1000178000,
+VK_STRUCTURE_TYPE_MEMORY_HOST_POINTER_PROPERTIES_EXT = 1000178001,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_HOST_PROPERTIES_EXT = 
1000178002,
 VK_STRUCTURE_TYPE_BEGIN_RANGE = VK_STRUCTURE_TYPE_APPLICATION_INFO,
 VK_STRUCTURE_TYPE_END_RANGE = VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO,
 VK_STRUCTURE_TYPE_RANGE_SIZE = 
(VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO - 
VK_STRUCTURE_TYPE_APPLICATION_INFO + 1),
@@ -4195,6 +4198,9 @@ typedef enum VkExternalMemoryHandleTypeFlagBitsKHR {
 VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT_KHR = 0x0010,
 VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_HEAP_BIT_KHR = 0x0020,
 VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT_KHR = 0x0040,
+VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT = 0x0200,
+VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT = 0x0080,
+VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_MAPPED_FOREIGN_MEMORY_BIT_EXT = 
0x0100,
 VK_EXTERNAL_MEMORY_HANDLE_TYPE_FLAG_BITS_MAX_ENUM_KHR = 0x7FFF
 } VkExternalMemoryHandleTypeFlagBitsKHR;
 typedef VkFlags VkExternalMemoryHandleTypeFlagsKHR;
@@ -6616,6 +6622,17 @@ VKAPI_ATTR VkResult VKAPI_CALL vkCreateMacOSSurfaceMVK(
 #endif
 #endif /* VK_USE_PLATFORM_MACOS_MVK */
 
+#define VK_EXT_external_memory_dma_buf 1
+#define VK_EXT_EXTERNAL_MEMORY_DMA_BUF_SPEC_VERSION 1
+#define VK_EXT_EXTERNAL_MEMORY_DMA_BUF_EXTENSION_NAME 
"VK_EXT_external_memory_dma_buf"
+
+
+#define VK_EXT_queue_family_foreign 1
+#define VK_EXT_QUEUE_FAMILY_FOREIGN_SPEC_VERSION 1
+#define VK_EXT_QUEUE_FAMILY_FOREIGN_EXTENSION_NAME 
"VK_EXT_queue_family_foreign"
+#define VK_QUEUE_FAMILY_FOREIGN_EXT   (~0U-2)
+
+
 #define VK_EXT_sampler_filter_minmax 1
 #define VK_EXT_SAMPLER_FILTER_MINMAX_SPEC_VERSION 1
 #define VK_EXT_SAMPLER_FILTER_MINMAX_EXTENSION_NAME 
"VK_EXT_sampler_filter_minmax"
@@ -6907,18 +6924,18 @@ VKAPI_ATTR VkResult VKAPI_CALL 
vkGetValidationCacheDataEXT(
 
 
 #define VK_EXT_global_priority 1
-#define VK_EXT_GLOBAL_PRIORITY_SPEC_VERSION 1
+#define VK_EXT_GLOBAL_PRIORITY_SPEC_VERSION 2
 #define VK_EXT_GLOBAL_PRIORITY_EXTENSION_NAME "VK_EXT_global_priority"
 
 
 typedef enum VkQueueGlobalPriorityEXT {
-VK_QUEUE_GLOBAL_PRIORITY_LOW = 128,
-VK_QUEUE_GLOBAL_PRIORITY_MEDIUM = 256,
-VK_QUEUE_GLOBAL_PRIORITY_HIGH = 512,
-VK_QUEUE_GLOBAL_PRIORITY_REALTIME = 1024,
-VK_QUEUE_GLOBAL_PRIORITY_BEGIN_RANGE_EXT = VK_QUEUE_GLOBAL_PRIORITY_LOW,
-VK_QUEUE_GLOBAL_PRIORITY_END_RANGE_EXT = VK_QUEUE_GLOBAL_PRIORITY_REALTIME,
-VK_QUEUE_GLOBAL_PRIORITY_RANGE_SIZE_EXT = 
(VK_QUEUE_GLOBAL_PRIORITY_REALTIME - VK_QUEUE_GLOBAL_PRIORITY_LOW + 1),
+VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT = 128,
+VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT = 256,
+VK_QUEUE_GLOBAL_PRIORITY_HIGH_EXT = 512,
+VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT = 1024,
+VK_QUEUE_GLOBAL_PRIORITY_BEGIN_RANGE_EXT = 
VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT,
+VK_QUEUE_GLOBAL_PRIORITY_END_RANGE_EXT = 
VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT,
+VK_QUEUE_GLOBAL_PRIORITY_RANGE_SIZE_EXT = 
(VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT - VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT + 1),
 VK_QUEUE_GLOBAL_PRIORITY_MAX_ENUM_EXT = 0x7FFF
 } VkQueueGlobalPriorityEXT;
 
@@ -6930,6 +6947,40 @@ typedef struct VkDeviceQueueGlobalPriorityCreateInfoEXT {
 
 
 
+#define VK_EXT_external_memory_host 1
+#define VK_EXT_EXTERNAL_MEMORY_HOST_SPEC_VERSION 1
+#define VK_EXT_EXTERNAL_MEMORY_HOST_EXTENSION_NAME 
"VK_EXT_external_memory_host"
+
+typedef struct VkImportMemoryHostPointerInfoEXT {
+VkStructureType  sType;
+const void*  pNext;
+VkExternalMemoryHandleTypeFlagBitsKHRhandleType;
+void*pHostPointer;
+} VkImportMemoryHostPointerInfoEXT;
+
+typedef struct VkMemoryHostPointerPropertiesEXT {
+VkStructureTypesType;
+void*  pNext;
+uint32_t   memoryTypeBits;
+} VkMemoryHostPointerPropertiesEXT;
+

[Mesa-dev] [Bug 103945] FireFox Error Abort with flash objects

[bugzilla-daemon]

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

--- Comment #1 from Timothy Arceri  ---
Mesa 11.0.7 is very old and no longer supported, you should try a newer Mesa
version. Also you should provide details of the hardware you are running.

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

[Mesa-dev] [Bug 103945] FireFox Error Abort with flash objects

[bugzilla-daemon]

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

Bug ID: 103945
   Summary: FireFox Error Abort with flash objects
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: wuqingxiang2...@126.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 135740
  --> https://bugs.freedesktop.org/attachment.cgi?id=135740=edit
The error informations on terminal window.

When I open a new web with some flash objects on FireFox.
It must close with this errors as above.

ATTENTION: default value of option force_s3tc_enable overridden by environment.
Mesa 11.0.7 implementation error: Invalid GLSL version in
shading_language_version()
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
Mesa 11.0.7 implementation error: Invalid GLSL version in
shading_language_version()
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
Mesa 11.0.7 implementation error: Invalid GLSL version in
shading_language_version()
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
Mesa 11.0.7 implementation error: Invalid GLSL version in
shading_language_version()
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
Mesa 11.0.7 implementation error: Invalid GLSL version in
shading_language_version()
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
Mesa 11.0.7 implementation error: Invalid GLSL version in
shading_language_version()
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
[31063] ###!!! ABORT: X_GLXDestroyPixmap: GLXBadPixmap; 2 requests ago: file
/builddir/build/BUILD/firefox-52.5.0/firefox-52.5.0esr/toolkit/xre/nsX11ErrorHandler.cpp,
line 147
[31063] ###!!! ABORT: X_GLXDestroyPixmap: GLXBadPixmap; 2 requests ago: file
/builddir/build/BUILD/firefox-52.5.0/firefox-52.5.0esr/toolkit/xre/nsX11ErrorHandler.cpp,
line 147
Segmentation fault

-- 
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 v3] util: Add Mesa ARB_get_program_binary helper functions

[Timothy Arceri]

From: Jordan Justen 

V2 (Timothy Arceri):
 - add extra code comment
 - stop passing around void *binary and just pass
   program_binary_header *hdr instead.
 - move to src/mesa/main rather than src/util

Signed-off-by: Jordan Justen 
Reviewed-by: Timothy Arceri 
---
 src/mesa/Makefile.sources  |   2 +
 src/mesa/main/program_binary.c | 149 +
 src/mesa/main/program_binary.h |  70 +++
 src/mesa/meson.build   |   2 +
 4 files changed, 223 insertions(+)
 create mode 100644 src/mesa/main/program_binary.c
 create mode 100644 src/mesa/main/program_binary.h

diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 6da1e3fef9d..d8b1eb1f995 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -166,20 +166,22 @@ MAIN_FILES = \
main/pixel.c \
main/pixel.h \
main/pixelstore.c \
main/pixelstore.h \
main/pixeltransfer.c \
main/pixeltransfer.h \
main/points.c \
main/points.h \
main/polygon.c \
main/polygon.h \
+   main/program_binary.c \
+   main/program_binary.h \
main/program_resource.c \
main/program_resource.h \
main/querymatrix.c \
main/querymatrix.h \
main/queryobj.c \
main/queryobj.h \
main/rastpos.c \
main/rastpos.h \
main/readpix.c \
main/readpix.h \
diff --git a/src/mesa/main/program_binary.c b/src/mesa/main/program_binary.c
new file mode 100644
index 000..c5fd71bc922
--- /dev/null
+++ b/src/mesa/main/program_binary.c
@@ -0,0 +1,149 @@
+/*
+ * Mesa 3-D graphics library
+ *
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/**
+ * \file program_binary.c
+ *
+ * Helper functions for serializing a binary program.
+ */
+
+
+#include "main/mtypes.h"
+#include "util/crc32.h"
+#include "program_binary.h"
+
+/**
+ * Mesa supports one binary format, but it must differentiate between formats
+ * produced by different drivers and different Mesa versions.
+ *
+ * Mesa uses a uint32_t value to specify an internal format. The only format
+ * defined has one uint32_t value of 0, followed by 20 bytes specifying a sha1
+ * that uniquely identifies the Mesa driver type and version.
+ */
+
+struct program_binary_header {
+   /* If internal_format is 0, it must be followed by the 20 byte sha1 that
+* identifies the Mesa driver and version supported. If we want to support
+* something besides a sha1, then a new internal_format value can be added.
+*/
+   uint32_t internal_format;
+   uint8_t sha1[20];
+   /* Fields following sha1 can be changed since the sha1 will guarantee that
+* the binary only works with the same Mesa version.
+*/
+   uint32_t size;
+   uint32_t crc32;
+};
+
+unsigned
+get_program_binary_header_size(void)
+{
+   return sizeof(struct program_binary_header);
+}
+
+bool
+write_program_binary(const void *payload, unsigned payload_size,
+ const void *sha1, void *binary, unsigned binary_size,
+ GLenum *binary_format)
+{
+   struct program_binary_header *hdr = binary;
+
+   if (binary_size < sizeof(*hdr))
+  return false;
+
+   /* binary_size is the size of the buffer provided by the application.
+* Make sure our program (payload) will fit in the buffer.
+*/
+   if (payload_size > binary_size - sizeof(*hdr))
+  return false;
+
+   hdr->internal_format = 0;
+   memcpy(hdr->sha1, sha1, sizeof(hdr->sha1));
+   memcpy(hdr + 1, payload, payload_size);
+   hdr->size = payload_size;
+
+   hdr->crc32 = util_hash_crc32(hdr + 1, payload_size);
+   *binary_format = GL_PROGRAM_BINARY_FORMAT_MESA;
+
+   return true;
+}
+
+static bool
+simple_header_checks(const struct program_binary_header *hdr, unsigned length)
+{
+   if (hdr == 

Re: [Mesa-dev] [PATCH 08/24] mesa: add gl_constants::SpirVCapabilities

[Ian Romanick]

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> From: Nicolai Hähnle 
> 
> For drivers to declare which SPIR-V features they support.
> ---
>  src/mesa/main/mtypes.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index f19477eb027..bf7c4ddc051 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -4010,6 +4010,9 @@ struct gl_constants
>  
> /** When drivers are OK with mapped buffers during draw and other calls. 
> */
> bool AllowMappedBuffersDuringExecution;
> +
> +   /** GL_ARB_gl_spirv */
> +   struct nir_spirv_supported_capabilities *SpirVCapabilities;

Is there an advantage to the extra indirection?  I know most drivers
won't use this yet, but I expect that many will eventually.  Also,
nir_spirv_supported_capabilities is pretty small.

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

Re: [Mesa-dev] [PATCH 06/24] mesa: implement SPIR-V loading in glShaderBinary

[Ian Romanick]

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> From: Nicolai Hähnle 
> 
> v2: Add a gl_shader_spirv_data member to gl_shader, which already
>encapsulates a gl_spirv_module where the binary will be saved.
>(Eduardo Lima)
> ---
>  src/mesa/main/glspirv.c   | 52 
> +++
>  src/mesa/main/glspirv.h   |  5 +
>  src/mesa/main/mtypes.h|  4 
>  src/mesa/main/shaderapi.c | 41 ++---
>  src/mesa/main/shaderobj.c |  2 ++
>  5 files changed, 101 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
> index d4724ad245c..390fa9e6984 100644
> --- a/src/mesa/main/glspirv.c
> +++ b/src/mesa/main/glspirv.c
> @@ -23,6 +23,8 @@
>  
>  #include "glspirv.h"
>  
> +#include "errors.h"
> +
>  #include "util/u_atomic.h"
>  
>  void
> @@ -61,6 +63,56 @@ _mesa_shader_spirv_data_reference(struct 
> gl_shader_spirv_data **dest,
>p_atomic_inc(>RefCount);
>  }
>  
> +void
> +_mesa_spirv_shader_binary(struct gl_context *ctx,
> +  GLint n, struct gl_shader **shaders,
> +  const void* binary, GLint length)

Since _mesa_ShaderBinary will already check length < 0, make length
size_t.  You can also make n be unsigned or plain int.

> +{
> +   struct gl_spirv_module *module;
> +   struct gl_shader_spirv_data *spirv_data;
> +
> +   if (!ctx->Extensions.ARB_gl_spirv) {
> +  _mesa_error(ctx, GL_INVALID_OPERATION, "glShaderBinary(SPIR-V)");
> +  return;
> +   }

I think this error should get moved to _mesa_ShaderBinary with the rest
of the API error checks.

> +
> +   if (n <= 0)
> +  return;

_mesa_ShaderBinary already checks n < 0.  Maybe just elide the call to
_mesa_spirv_shader_binary if n == 0?

> +
> +   assert(length >= 0);
> +
> +   module = malloc(sizeof(*module) + (size_t)length);
> +   if (!module) {
> +  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glShaderBinary");
> +  return;
> +   }
> +
> +   p_atomic_set(>RefCount, 0);
> +   module->Length = length;
> +   memcpy(>Binary[0], binary, length);
> +
> +   for (int i = 0; i < n; ++i) {
> +  struct gl_shader *sh = shaders[i];
> +
> +  spirv_data = rzalloc(NULL, struct gl_shader_spirv_data);
> +  _mesa_shader_spirv_data_reference(>spirv_data, spirv_data);
> +  _mesa_spirv_module_reference(_data->SpirVModule, module);
> +
> +  sh->SpirVBinary = GL_TRUE;

It didn't occur to me while reviewing the earlier patch, but if
SpirVBinary is never visible to the API, we should use bool, true, and
false instead of the GL types.

> +  sh->CompileStatus = compile_failure;
> +
> +  free((void *)sh->Source);
> +  sh->Source = NULL;
> +  free((void *)sh->FallbackSource);
> +  sh->FallbackSource = NULL;
> +
> +  ralloc_free(sh->ir);
> +  sh->ir = NULL;
> +  ralloc_free(sh->symbols);
> +  sh->symbols = NULL;
> +   }
> +}
> +
>  void GLAPIENTRY
>  _mesa_SpecializeShaderARB(GLuint shader,
>const GLchar *pEntryPoint,
> diff --git a/src/mesa/main/glspirv.h b/src/mesa/main/glspirv.h
> index b8a0125ea9f..5ffaa230629 100644
> --- a/src/mesa/main/glspirv.h
> +++ b/src/mesa/main/glspirv.h
> @@ -71,6 +71,11 @@ void
>  _mesa_shader_spirv_data_reference(struct gl_shader_spirv_data **dest,
>struct gl_shader_spirv_data *src);
>  
> +void
> +_mesa_spirv_shader_binary(struct gl_context *ctx,
> +  GLint n, struct gl_shader **shaders,
> +  const void* binary, GLint length);
> +
>  /**
>   * \name API functions
>   */
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index cfc763f043e..f19477eb027 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -88,6 +88,7 @@ struct st_context;
>  struct gl_uniform_storage;
>  struct prog_instruction;
>  struct gl_program_parameter_list;
> +struct gl_shader_spirv_data;
>  struct set;
>  struct set_entry;
>  struct vbo_context;
> @@ -2637,6 +2638,9 @@ struct gl_shader
> GLuint TransformFeedbackBufferStride[MAX_FEEDBACK_BUFFERS];
>  
> struct gl_shader_info info;
> +
> +   /* ARB_gl_spirv related data */
> +   struct gl_shader_spirv_data *spirv_data;
>  };
>  
>  
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index 9090bee9fb0..240d9fe6cbc 100644
> --- a/src/mesa/main/shaderapi.c
> +++ b/src/mesa/main/shaderapi.c
> @@ -42,6 +42,7 @@
>  #include "main/context.h"
>  #include "main/dispatch.h"
>  #include "main/enums.h"
> +#include "main/glspirv.h"
>  #include "main/hash.h"
>  #include "main/mtypes.h"
>  #include "main/pipelineobj.h"
> @@ -1054,6 +1055,17 @@ set_shader_source(struct gl_shader *sh, const GLchar 
> *source)
>  {
> assert(sh);
>  
> +   /* The GL_ARB_gl_spirv spec adds the following to the end of the 
> description
> +* of ShaderSource:
> +*
> +*   "If  was previously associated with a SPIR-V module 

Re: [Mesa-dev] [PATCH 05/24] mesa/glspirv: Add struct gl_shader_spirv_data

[Ian Romanick]

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> This is a per-shader structure holding the SPIR-V data associated with the
> shader (binary module, specialization constants and entry-point).
> 
> This is needed because both gl_shader and gl_linked_shader need to share this
> data. Instead of copying the data, we pass a reference to it upon program
> linking. That's why it is reference-counted.
> 
> This struct is created and associated with the shader upon calling
> glShaderBinary(), then subsequently filled up by the call to
> glSpecializeShaderARB().
> ---
>  src/mesa/main/glspirv.c | 19 +++
>  src/mesa/main/glspirv.h | 25 +
>  2 files changed, 44 insertions(+)
> 
> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
> index eb869356632..d4724ad245c 100644
> --- a/src/mesa/main/glspirv.c
> +++ b/src/mesa/main/glspirv.c
> @@ -42,6 +42,25 @@ _mesa_spirv_module_reference(struct gl_spirv_module **dest,
>p_atomic_inc(>RefCount);
>  }
>  
> +void
> +_mesa_shader_spirv_data_reference(struct gl_shader_spirv_data **dest,
> +  struct gl_shader_spirv_data *src)
> +{
> +   struct gl_shader_spirv_data *old = *dest;
> +
> +   if (old) {
> +  if (p_atomic_dec_zero(>RefCount)) {
> + _mesa_spirv_module_reference(&(*dest)->SpirVModule, NULL);
> + ralloc_free(old);
> +  }
> +   }

Same trivial comment here as on the previous patch, and the same

Reviewed-by: Ian Romanick 

> +
> +   *dest = src;
> +
> +   if (src)
> +  p_atomic_inc(>RefCount);
> +}
> +
>  void GLAPIENTRY
>  _mesa_SpecializeShaderARB(GLuint shader,
>const GLchar *pEntryPoint,
> diff --git a/src/mesa/main/glspirv.h b/src/mesa/main/glspirv.h
> index 4e033735cfe..b8a0125ea9f 100644
> --- a/src/mesa/main/glspirv.h
> +++ b/src/mesa/main/glspirv.h
> @@ -42,10 +42,35 @@ struct gl_spirv_module {
> char Binary[0];
>  };
>  
> +/**
> + * SPIR-V data needed to compile and link a SPIR-V shader.
> + *
> + * It includes a SPIR-V binary that is potentially shared among different
> + * shaders; and shader-specific specialization constants and entry point.
> + *
> + * It is reference-counted because it is shared between gl_shader and its
> + * corresponding gl_linked_shader.
> + */
> +struct gl_shader_spirv_data {
> +   GLint RefCount;
> +
> +   struct gl_spirv_module *SpirVModule;
> +
> +   GLchar *SpirVEntryPoint;
> +
> +   GLuint NumSpecializationConstants;
> +   GLuint *SpecializationConstantsIndex;
> +   GLuint *SpecializationConstantsValue;
> +};
> +
>  void
>  _mesa_spirv_module_reference(struct gl_spirv_module **dest,
>   struct gl_spirv_module *src);
>  
> +void
> +_mesa_shader_spirv_data_reference(struct gl_shader_spirv_data **dest,
> +  struct gl_shader_spirv_data *src);
> +
>  /**
>   * \name API functions
>   */
> 

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

Re: [Mesa-dev] [PATCH 04/24] mesa/glspirv: Add struct gl_spirv_module

[Ian Romanick]

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> From: Nicolai Hähnle 
> 
> v2: Make the SPIR-V module struct part of a larger gl_shader_spirv_data
> struct that will be introduced later, and don't reference it directly
> in gl_shader. (Eduardo Lima)
> ---
>  src/mesa/main/glspirv.c | 19 +++
>  src/mesa/main/glspirv.h | 16 
>  2 files changed, 35 insertions(+)
> 
> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
> index 57068023091..eb869356632 100644
> --- a/src/mesa/main/glspirv.c
> +++ b/src/mesa/main/glspirv.c
> @@ -23,6 +23,25 @@
>  
>  #include "glspirv.h"
>  
> +#include "util/u_atomic.h"
> +
> +void
> +_mesa_spirv_module_reference(struct gl_spirv_module **dest,
> + struct gl_spirv_module *src)
> +{
> +   struct gl_spirv_module *old = *dest;
> +
> +   if (old) {
> +  if (p_atomic_dec_zero(>RefCount))
> + free(old);
> +   }

I feel like this reads better as:

   if (old && p_atomic_dec_zero(>RefCount))
  free(old);

With or without that change, this patch is

Reviewed-by: Ian Romanick 

> +
> +   *dest = src;
> +
> +   if (src)
> +  p_atomic_inc(>RefCount);
> +}
> +
>  void GLAPIENTRY
>  _mesa_SpecializeShaderARB(GLuint shader,
>const GLchar *pEntryPoint,
> diff --git a/src/mesa/main/glspirv.h b/src/mesa/main/glspirv.h
> index 1de88717faa..4e033735cfe 100644
> --- a/src/mesa/main/glspirv.h
> +++ b/src/mesa/main/glspirv.h
> @@ -31,6 +31,22 @@ extern "C" {
>  #endif
>  
>  /**
> + * A SPIR-V module contains the raw SPIR-V binary as set by ShaderBinary.
> + *
> + * It is reference-counted, because the same module can be attached to 
> multiple
> + * shader objects simultaneously.
> + */
> +struct gl_spirv_module {
> +   unsigned RefCount;
> +   GLint Length;
> +   char Binary[0];
> +};
> +
> +void
> +_mesa_spirv_module_reference(struct gl_spirv_module **dest,
> + struct gl_spirv_module *src);
> +
> +/**
>   * \name API functions
>   */
>  /*@{*/
> 

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

Re: [Mesa-dev] [PATCH 03/24] mesa: refuse to compile SPIR-V shaders or link mixed shaders

[Ian Romanick]

This patch is

Reviewed-by: Ian Romanick 

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> From: Nicolai Hähnle 
> 
> Note that gl_shader::CompileStatus will also indicate whether a shader
> has been successfully specialized.
> ---
>  src/mesa/main/shaderapi.c   | 12 
>  src/mesa/program/ir_to_mesa.cpp | 17 -
>  2 files changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index 5db335b695b..9090bee9fb0 100644
> --- a/src/mesa/main/shaderapi.c
> +++ b/src/mesa/main/shaderapi.c
> @@ -1081,6 +1081,18 @@ _mesa_compile_shader(struct gl_context *ctx, struct 
> gl_shader *sh)
> if (!sh)
>return;
>  
> +   /* The GL_ARB_gl_spirv spec says:
> +*
> +*"Add a new error for the CompileShader command:
> +*
> +*  An INVALID_OPERATION error is generated if the SPIR_V_BINARY_ARB
> +*  state of  is TRUE."
> +*/
> +   if (sh->SpirVBinary) {
> +  _mesa_error(ctx, GL_INVALID_OPERATION, "glCompileShader(SPIR-V)");
> +  return;
> +   }
> +
> if (!sh->Source) {
>/* If the user called glCompileShader without first calling
> * glShaderSource, we should fail to compile, but not raise a GL_ERROR.
> diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
> index 327fd61d422..ddc1705097d 100644
> --- a/src/mesa/program/ir_to_mesa.cpp
> +++ b/src/mesa/program/ir_to_mesa.cpp
> @@ -3064,6 +3064,7 @@ void
>  _mesa_glsl_link_shader(struct gl_context *ctx, struct gl_shader_program 
> *prog)
>  {
> unsigned int i;
> +   GLboolean spirv;
>  
> _mesa_clear_shader_program_data(ctx, prog);
>  
> @@ -3073,7 +3074,21 @@ _mesa_glsl_link_shader(struct gl_context *ctx, struct 
> gl_shader_program *prog)
>  
> for (i = 0; i < prog->NumShaders; i++) {
>if (!prog->Shaders[i]->CompileStatus) {
> -  linker_error(prog, "linking with uncompiled shader");
> +  linker_error(prog, "linking with uncompiled/unspecialized shader");
> +  }
> +
> +  if (!i) {
> + spirv = prog->Shaders[i]->SpirVBinary;
> +  } else if (spirv != prog->Shaders[i]->SpirVBinary) {
> + /* The GL_ARB_gl_spirv spec adds a new bullet point to the list of
> +  * reasons LinkProgram can fail:
> +  *
> +  *"All the shader objects attached to  do not have the
> +  * same value for the SPIR_V_BINARY_ARB state."
> +  */
> + linker_error(prog,
> +  "not all attached shaders have the same "
> +  "SPIR_V_BINARY_ARB state");
>}
> }
>  
> 

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

Re: [Mesa-dev] [PATCH 01/24] mesa: add GL_ARB_gl_spirv boilerplate

[Ian Romanick]

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> From: Nicolai Hähnle 
> 
> ---
>  src/mapi/glapi/gen/ARB_gl_spirv.xml | 21 ++
>  src/mapi/glapi/gen/Makefile.am  |  1 +
>  src/mapi/glapi/gen/gl_API.xml   |  4 +++
>  src/mapi/glapi/gen/gl_genexec.py|  1 +
>  src/mesa/Makefile.sources   |  2 ++
>  src/mesa/main/extensions_table.h|  1 +
>  src/mesa/main/glspirv.c | 33 +
>  src/mesa/main/glspirv.h | 51 
> +
>  src/mesa/main/mtypes.h  |  1 +
>  src/mesa/main/tests/dispatch_sanity.cpp |  3 ++
>  10 files changed, 118 insertions(+)
>  create mode 100644 src/mapi/glapi/gen/ARB_gl_spirv.xml
>  create mode 100644 src/mesa/main/glspirv.c
>  create mode 100644 src/mesa/main/glspirv.h
> 
> diff --git a/src/mapi/glapi/gen/ARB_gl_spirv.xml 
> b/src/mapi/glapi/gen/ARB_gl_spirv.xml
> new file mode 100644
> index 000..0dd615480f7
> --- /dev/null
> +++ b/src/mapi/glapi/gen/ARB_gl_spirv.xml
> @@ -0,0 +1,21 @@
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> index 87d8517b7ba..35e37e95a9f 100644
> --- a/src/mapi/glapi/gen/Makefile.am
> +++ b/src/mapi/glapi/gen/Makefile.am
> @@ -144,6 +144,7 @@ API_XML = \
>   ARB_framebuffer_object.xml \
>   ARB_get_program_binary.xml \
>   ARB_get_texture_sub_image.xml \
> + ARB_gl_spirv.xml \
>   ARB_gpu_shader_fp64.xml \
>   ARB_gpu_shader_int64.xml \
>   ARB_gpu_shader5.xml \
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index eb1d9b83b27..d3594cfe195 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -8400,6 +8400,10 @@
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>  
> +
> +
> + xmlns:xi="http://www.w3.org/2001/XInclude"/>
> +
>  
>  
>  
> diff --git a/src/mapi/glapi/gen/gl_genexec.py 
> b/src/mapi/glapi/gen/gl_genexec.py
> index b7b22328ff8..aaff9f230b3 100644
> --- a/src/mapi/glapi/gen/gl_genexec.py
> +++ b/src/mapi/glapi/gen/gl_genexec.py
> @@ -77,6 +77,7 @@ header = """/**
>  #include "main/eval.h"
>  #include "main/externalobjects.h"
>  #include "main/get.h"
> +#include "main/glspirv.h"
>  #include "main/feedback.h"
>  #include "main/fog.h"
>  #include "main/fbobject.h"
> diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> index 6da1e3fef9d..e9680bf004c 100644
> --- a/src/mesa/Makefile.sources
> +++ b/src/mesa/Makefile.sources
> @@ -118,6 +118,8 @@ MAIN_FILES = \
>   main/getstring.c \
>   main/glformats.c \
>   main/glformats.h \
> + main/glspirv.c \
> + main/glspirv.h \
>   main/glthread.c \
>   main/glthread.h \
>   main/glheader.h \
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index 5b66e7d30df..ab15ceb9414 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -72,6 +72,7 @@ EXT(ARB_framebuffer_object  , 
> ARB_framebuffer_object
>  EXT(ARB_framebuffer_sRGB, EXT_framebuffer_sRGB   
> , GLL, GLC,  x ,  x , 1998)
>  EXT(ARB_get_program_binary  , dummy_true 
> , GLL, GLC,  x ,  x , 2010)
>  EXT(ARB_get_texture_sub_image   , dummy_true 
> , GLL, GLC,  x ,  x , 2014)
> +EXT(ARB_gl_spirv, ARB_gl_spirv   
> ,  x,  GLC,  x ,  x , 2016)
>  EXT(ARB_gpu_shader5 , ARB_gpu_shader5
> ,  x , GLC,  x ,  x , 2010)
>  EXT(ARB_gpu_shader_fp64 , ARB_gpu_shader_fp64
> ,  x , GLC,  x ,  x , 2010)
>  EXT(ARB_gpu_shader_int64, ARB_gpu_shader_int64   
> ,  x , GLC,  x ,  x , 2015)
> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
> new file mode 100644
> index 000..57068023091
> --- /dev/null
> +++ b/src/mesa/main/glspirv.c
> @@ -0,0 +1,33 @@
> +/*
> + * Copyright 2017 Advanced Micro Devices, Inc.

Is this the copyright you intended? :)

> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * on the rights to use, copy, modify, merge, publish, distribute, sub
> + * license, and/or sell copies of the Software, and to permit persons to whom
> + * the Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * 

Re: [Mesa-dev] [PATCH 01/24] mesa: add GL_ARB_gl_spirv boilerplate

[Ian Romanick]

On 11/27/2017 02:15 PM, Ian Romanick wrote:
> On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
>> From: Nicolai Hähnle 
>>
>> ---
>>  src/mapi/glapi/gen/ARB_gl_spirv.xml | 21 ++
>>  src/mapi/glapi/gen/Makefile.am  |  1 +
>>  src/mapi/glapi/gen/gl_API.xml   |  4 +++
>>  src/mapi/glapi/gen/gl_genexec.py|  1 +
>>  src/mesa/Makefile.sources   |  2 ++
>>  src/mesa/main/extensions_table.h|  1 +
>>  src/mesa/main/glspirv.c | 33 +
>>  src/mesa/main/glspirv.h | 51 
>> +
>>  src/mesa/main/mtypes.h  |  1 +
>>  src/mesa/main/tests/dispatch_sanity.cpp |  3 ++
>>  10 files changed, 118 insertions(+)
>>  create mode 100644 src/mapi/glapi/gen/ARB_gl_spirv.xml
>>  create mode 100644 src/mesa/main/glspirv.c
>>  create mode 100644 src/mesa/main/glspirv.h
>>
>> diff --git a/src/mapi/glapi/gen/ARB_gl_spirv.xml 
>> b/src/mapi/glapi/gen/ARB_gl_spirv.xml
>> new file mode 100644
>> index 000..0dd615480f7
>> --- /dev/null
>> +++ b/src/mapi/glapi/gen/ARB_gl_spirv.xml
>> @@ -0,0 +1,21 @@
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
>> index 87d8517b7ba..35e37e95a9f 100644
>> --- a/src/mapi/glapi/gen/Makefile.am
>> +++ b/src/mapi/glapi/gen/Makefile.am
>> @@ -144,6 +144,7 @@ API_XML = \
>>  ARB_framebuffer_object.xml \
>>  ARB_get_program_binary.xml \
>>  ARB_get_texture_sub_image.xml \
>> +ARB_gl_spirv.xml \
>>  ARB_gpu_shader_fp64.xml \
>>  ARB_gpu_shader_int64.xml \
>>  ARB_gpu_shader5.xml \
>> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
>> index eb1d9b83b27..d3594cfe195 100644
>> --- a/src/mapi/glapi/gen/gl_API.xml
>> +++ b/src/mapi/glapi/gen/gl_API.xml
>> @@ -8400,6 +8400,10 @@
>>  
>>  > xmlns:xi="http://www.w3.org/2001/XInclude"/>
>>  
>> +
>> +
>> +> xmlns:xi="http://www.w3.org/2001/XInclude"/>
>> +
>>  
>>  
>>  
>> diff --git a/src/mapi/glapi/gen/gl_genexec.py 
>> b/src/mapi/glapi/gen/gl_genexec.py
>> index b7b22328ff8..aaff9f230b3 100644
>> --- a/src/mapi/glapi/gen/gl_genexec.py
>> +++ b/src/mapi/glapi/gen/gl_genexec.py
>> @@ -77,6 +77,7 @@ header = """/**
>>  #include "main/eval.h"
>>  #include "main/externalobjects.h"
>>  #include "main/get.h"
>> +#include "main/glspirv.h"
>>  #include "main/feedback.h"
>>  #include "main/fog.h"
>>  #include "main/fbobject.h"
>> diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
>> index 6da1e3fef9d..e9680bf004c 100644
>> --- a/src/mesa/Makefile.sources
>> +++ b/src/mesa/Makefile.sources
>> @@ -118,6 +118,8 @@ MAIN_FILES = \
>>  main/getstring.c \
>>  main/glformats.c \
>>  main/glformats.h \
>> +main/glspirv.c \
>> +main/glspirv.h \
>>  main/glthread.c \
>>  main/glthread.h \
>>  main/glheader.h \
>> diff --git a/src/mesa/main/extensions_table.h 
>> b/src/mesa/main/extensions_table.h
>> index 5b66e7d30df..ab15ceb9414 100644
>> --- a/src/mesa/main/extensions_table.h
>> +++ b/src/mesa/main/extensions_table.h
>> @@ -72,6 +72,7 @@ EXT(ARB_framebuffer_object  , 
>> ARB_framebuffer_object
>>  EXT(ARB_framebuffer_sRGB, EXT_framebuffer_sRGB  
>>  , GLL, GLC,  x ,  x , 1998)
>>  EXT(ARB_get_program_binary  , dummy_true
>>  , GLL, GLC,  x ,  x , 2010)
>>  EXT(ARB_get_texture_sub_image   , dummy_true
>>  , GLL, GLC,  x ,  x , 2014)
>> +EXT(ARB_gl_spirv, ARB_gl_spirv  
>>  ,  x,  GLC,  x ,  x , 2016)
>>  EXT(ARB_gpu_shader5 , ARB_gpu_shader5   
>>  ,  x , GLC,  x ,  x , 2010)
>>  EXT(ARB_gpu_shader_fp64 , ARB_gpu_shader_fp64   
>>  ,  x , GLC,  x ,  x , 2010)
>>  EXT(ARB_gpu_shader_int64, ARB_gpu_shader_int64  
>>  ,  x , GLC,  x ,  x , 2015)
>> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
>> new file mode 100644
>> index 000..57068023091
>> --- /dev/null
>> +++ b/src/mesa/main/glspirv.c
>> @@ -0,0 +1,33 @@
>> +/*
>> + * Copyright 2017 Advanced Micro Devices, Inc.
> 
> Is this the copyright you intended? :)

I missed that this was originally Nicolai's patch, so the answer is yes. :)

>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the 
>> "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * on the rights to use, copy, modify, merge, publish, distribute, sub
>> + * license, and/or sell copies of the Software, and to permit persons to 
>> 

Re: [Mesa-dev] [PATCH mesa 0/7] remove upstreamed specs

[Adam Jackson]

On Thu, 2017-11-23 at 16:32 +, Emil Velikov wrote:
> On 23 November 2017 at 16:04, Eric Engestrom  
> wrote:
> > On Thursday, 2017-11-23 13:32:47 +, Emil Velikov wrote:
> > > 
> > > > - GLX_MESA_release_buffers
> > > 
> > > Extension is implemented only for Xlib based libGL. The DRI codepath
> > > has a TODO for at least 7 years.
> > > Worth checking if anyone uses it and not just deprecate the extension?
> > 
> > I don't know much about GLX, so I'll let someone else do this.
> 
> Ack. in the interim, can you grep your systems for any existing users?
> Looking from the opposite end - quick search shows that only Mesa has
> implemented the said extensions.

I'm not surprised. The issue that extension tries to address is by far
most painful for the xlib backend (and dri-swrast I suppose). For
actual direct rendering the ancillary buffers are owned by the window
system, the only client-side "memory leak" is the drawable's entry in
the hash table. And honestly who cares, by the time your drawable is
destroyed from under you you're probably about to exit anyway.

Personally I don't see a lot of value in the xlib backend, but someone
clearly does since we have two copies of it now (src/mesa/drivers/x11 
and src/gallium/state_trackers/glx/xlib). So I don't know if I'd call
the extension Obsolete, but I'd probably discourage anyone from caring
about it, if you need it you're already in a deeply non-performant code
path.

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

Re: [Mesa-dev] [PATCH 10/24] spirv_extensions: add GL_ARB_spirv_extensions boilerplate

[Ian Romanick]

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro 
> 
> ---
>  src/mapi/glapi/gen/ARB_spirv_extensions.xml | 13 
>  src/mapi/glapi/gen/Makefile.am  |  1 +
>  src/mapi/glapi/gen/gl_API.xml   |  2 ++
>  src/mesa/Makefile.sources   |  2 ++
>  src/mesa/main/extensions_table.h|  1 +
>  src/mesa/main/get.c |  6 
>  src/mesa/main/get_hash_params.py|  3 ++
>  src/mesa/main/getstring.c   |  7 +
>  src/mesa/main/mtypes.h  |  1 +
>  src/mesa/main/spirvextensions.c | 42 +
>  src/mesa/main/spirvextensions.h | 49 
> +
>  11 files changed, 127 insertions(+)
>  create mode 100644 src/mapi/glapi/gen/ARB_spirv_extensions.xml
>  create mode 100644 src/mesa/main/spirvextensions.c
>  create mode 100644 src/mesa/main/spirvextensions.h

Could these files be renamed spirv_extensions.[ch]?

> 
> diff --git a/src/mapi/glapi/gen/ARB_spirv_extensions.xml 
> b/src/mapi/glapi/gen/ARB_spirv_extensions.xml
> new file mode 100644
> index 000..103393104c2
> --- /dev/null
> +++ b/src/mapi/glapi/gen/ARB_spirv_extensions.xml
> @@ -0,0 +1,13 @@
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> index 35e37e95a9f..9a7a268adbf 100644
> --- a/src/mapi/glapi/gen/Makefile.am
> +++ b/src/mapi/glapi/gen/Makefile.am
> @@ -167,6 +167,7 @@ API_XML = \
>   ARB_shader_subroutine.xml \
>   ARB_shader_storage_buffer_object.xml \
>   ARB_sparse_buffer.xml \
> + ARB_spirv_extensions.xml \
>   ARB_sync.xml \
>   ARB_tessellation_shader.xml \
>   ARB_texture_barrier.xml \
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index d3594cfe195..6b81160b5a1 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -8404,6 +8404,8 @@
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>  
> + xmlns:xi="http://www.w3.org/2001/XInclude"/>
> +
>  
>  
>  
> diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> index e9680bf004c..944c8bcc812 100644
> --- a/src/mesa/Makefile.sources
> +++ b/src/mesa/Makefile.sources
> @@ -203,6 +203,8 @@ MAIN_FILES = \
>   main/shader_query.cpp \
>   main/shared.c \
>   main/shared.h \
> + main/spirvextensions.c \
> + main/spirvextensions.h \
>   main/state.c \
>   main/state.h \
>   main/stencil.c \
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index ab15ceb9414..06deabd0640 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -129,6 +129,7 @@ EXT(ARB_shading_language_420pack, 
> ARB_shading_language_420pack
>  EXT(ARB_shading_language_packing, ARB_shading_language_packing   
> , GLL, GLC,  x ,  x , 2011)
>  EXT(ARB_shadow  , ARB_shadow 
> , GLL,  x ,  x ,  x , 2001)
>  EXT(ARB_sparse_buffer   , ARB_sparse_buffer  
> , GLL, GLC,  x ,  x , 2014)
> +EXT(ARB_spirv_extensions, ARB_spirv_extensions   
> ,  x,  GLC,  x ,  x , 2016)
>  EXT(ARB_stencil_texturing   , ARB_stencil_texturing  
> , GLL, GLC,  x ,  x , 2012)
>  EXT(ARB_sync, ARB_sync   
> , GLL, GLC,  x ,  x , 2003)
>  EXT(ARB_tessellation_shader , ARB_tessellation_shader
> ,  x , GLC,  x ,  x , 2009)
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index ea8d932b182..c97ec9efde9 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -34,6 +34,7 @@
>  #include "get.h"
>  #include "macros.h"
>  #include "mtypes.h"
> +#include "spirvextensions.h"
>  #include "state.h"
>  #include "texcompress.h"
>  #include "texstate.h"
> @@ -1151,6 +1152,11 @@ find_custom_value(struct gl_context *ctx, const struct 
> value_desc *d, union valu
>   }
>}
>break;
> +
> +   /* ARB_spirv_extensions */
> +   case GL_NUM_SPIR_V_EXTENSIONS:
> +  v->value_int = _mesa_get_spirv_extension_count(ctx);
> +  break;
> }
>  }
>  
> diff --git a/src/mesa/main/get_hash_params.py 
> b/src/mesa/main/get_hash_params.py
> index 20ef6e4977a..4378cc1cabe 100644
> --- a/src/mesa/main/get_hash_params.py
> +++ b/src/mesa/main/get_hash_params.py
> @@ -378,6 +378,9 @@ descriptor=[
>  # GL_ARB_sampler_objects / GL 3.3 / GLES 3.0
>[ "SAMPLER_BINDING", "LOC_CUSTOM, TYPE_INT, GL_SAMPLER_BINDING, NO_EXTRA" 
> ],
>  
> +# GL_ARB_spirv_extensions
> +  [ "NUM_SPIR_V_EXTENSIONS", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ],
> +
>  # GL_ARB_sync
>[ "MAX_SERVER_WAIT_TIMEOUT", "CONTEXT_INT64(Const.MaxServerWaitTimeout), 
> 

Re: [Mesa-dev] [PATCH 12/24] spirv_extensions: define spirv_extensions_supported

[Ian Romanick]

On 11/27/2017 01:25 PM, Ian Romanick wrote:
> On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
>> From: Alejandro Piñeiro 
>>
>> Add a struct to maintain which SPIR-V extensions are supported, and an
>> utility method to initialize it based on
>> nir_spirv_supported_capabilities.
>> ---
>>  src/compiler/spirv/spirv_extensions.c | 29 +
>>  src/compiler/spirv/spirv_extensions.h | 12 
>>  2 files changed, 41 insertions(+)
>>
>> diff --git a/src/compiler/spirv/spirv_extensions.c 
>> b/src/compiler/spirv/spirv_extensions.c
>> index 64d61c49d31..8263b693abd 100644
>> --- a/src/compiler/spirv/spirv_extensions.c
>> +++ b/src/compiler/spirv/spirv_extensions.c
>> @@ -59,3 +59,32 @@ spirv_extensions_to_string(SpvExtension ext)
>>  
>> return "unknown";
>>  }
>> +
>> +/**
>> + * Sets the supported flags for known SPIR-V extensions based on the
>> + * capabilites supported (spirv capabilities based on the spirv to nir
>> + * support).
>> + *
>> + * One could argue that makes more sense in the other way around, as from 
>> the
>> + * spec pov capabilities are enable for a given extension. But from our pov,
>> + * we support or not (depending on the driver) some given capability, and
>> + * spirv_to_nir check for capabilities not extensions. Also we usually fill
>> + * first the supported capabilities, that are not always related to an
>> + * extension.
>> + */
>> +void
>> +fill_supported_spirv_extensions(struct spirv_supported_extensions *ext,
>> +const struct 
>> nir_spirv_supported_capabilities *cap)
> 
> Since this is exposed outside this file, this function should have some
> sort of a namespace prefix.  I'm not sure what it should be, though.
> 
>> +{
>> +   for (unsigned i = 0; i < SPV_EXTENSIONS_COUNT; i++)
>> +  ext->supported[i] = false;
>> +
>> +   ext->count = 0;
>> +
>> +   ext->supported[SPV_KHR_shader_draw_parameters] = cap->draw_parameters;
>> +   ext->supported[SPV_KHR_multiview] = cap->multiview;
>> +   ext->supported[SPV_KHR_variable_pointers] = cap->variable_pointers;
>> +
>> +   for (unsigned i = 0; i < SPV_EXTENSIONS_COUNT; i++)
>> +  if (ext->supported[i]) ext->count++;
> 
>for (unsigned i = 0; i < SPV_EXTENSIONS_COUNT; i++) {
>   if (ext->supported[i])
>  ext->count++;
>}
> 
>> +}
>> diff --git a/src/compiler/spirv/spirv_extensions.h 
>> b/src/compiler/spirv/spirv_extensions.h
>> index 54bc7f2dbe0..22238b727d7 100644
>> --- a/src/compiler/spirv/spirv_extensions.h
>> +++ b/src/compiler/spirv/spirv_extensions.h
>> @@ -25,6 +25,7 @@
>>  #define _SPIRV_EXTENSIONS_H_
>>  
>>  #include "compiler/nir/nir.h"
>> +#include "nir_spirv.h"
>>  
>>  #ifdef __cplusplus
>>  extern "C" {
>> @@ -60,8 +61,19 @@ typedef enum SpvExtension_ {
>> SPV_EXTENSIONS_COUNT
>>  } SpvExtension;
>>  
>> +struct spirv_supported_extensions {
>> +   /** Flags the supported extensions. Array to make it easier to iterate. 
>> */
>> +   bool supported[SPV_EXTENSIONS_COUNT];
>> +
>> +   /** Number of supported extensions */
>> +   unsigned int count;
> 
> I see this is used by _mesa_get_spirv_extension_count, but I don't see
> where that is used.  Did I miss it?

Never mind.  Patch 10 showed up out-of-order, so I did miss it.

>> +};
>> +
>>  const char *spirv_extensions_to_string(SpvExtension ext);
>>  
>> +void fill_supported_spirv_extensions(struct spirv_supported_extensions *ext,
>> + const struct 
>> nir_spirv_supported_capabilities *cap);
>> +
>>  #ifdef __cplusplus
>>  }
>>  #endif
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 10-bit Mesa/Gallium support

[Alex Deucher]

On Mon, Nov 27, 2017 at 5:01 PM, Adam Jackson  wrote:
> On Thu, 2017-11-23 at 18:35 +0100, Marek Olšák wrote:
>> Hi everybody,
>>
>> Mario, feel free to push your patches if you haven't yet. (except the
>> workaround)
>>
>> For AMD, I applied Mario's patches (except Wayland - that didn't
>> apply) and added initial Gallium support:
>> https://cgit.freedesktop.org/~mareko/mesa/log/?h=10bit
>>
>> What's the status of Glamor?
>
> Probably not working at all:
>
> https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_transfer.c#n26

I think we have a branch internally somewhere with support added to
glamor.  I though Nicolai had sent it out a while ago, but maybe I'm
mixing it up with something else.

Alex

>
> At best I'd expect things to be largely unaccelerated. At the moment
> glamor assumes pictures are either [ax]rgb or a8 because it doesn't
> know about ARB_texture_view/ARB_texture_storage/ARB_sampler_objects.
> The last, at least, has a work-in-progress branch here:
>
> https://github.com/anholt/xserver/tree/glamor-sampler-objects
>
> - ajax
> ___
> 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 07/24] spirv_extensions: rename nir_spirv_supported_extensions

[Ian Romanick]

This patch is

Reviewed-by: Ian Romanick 

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro 
> 
> Renamed to nir_spirv_supported_capabilities.
> 
> The original name seemed to suggest that it was directly related to
> the SPIR-V extensions supported, but that is not the case. For
> example, float64 was supported on SPIR-V 1.0 core, without the need of
> any extra extension.
> 
> Additionally, this is used at spirv_to_nir to check if a given
> capability is supported or not (see spv_check_supported), not if a
> given extension is supported or not.
> 
> One could argue that it should be renamed to something like
> nir_spirv_supported_extra_capabilities (or similar) as not all the
> capabilities are flagged there. In any case, that name seemed too long.
> 
> This rename was triggered by the need of really maintain the SPIR-V
> supported extensions as part of ARB_spirv_extensions implementation,
> making that struct name confusing.
> ---
>  src/amd/vulkan/radv_shader.c  | 4 ++--
>  src/compiler/spirv/nir_spirv.h| 4 ++--
>  src/compiler/spirv/spirv_to_nir.c | 6 +++---
>  src/compiler/spirv/vtn_private.h  | 2 +-
>  src/intel/vulkan/anv_pipeline.c   | 4 ++--
>  5 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> index 32edf2abd22..cea61333ebc 100644
> --- a/src/amd/vulkan/radv_shader.c
> +++ b/src/amd/vulkan/radv_shader.c
> @@ -196,7 +196,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
>   spec_entries[i].data32 = *(const 
> uint32_t *)data;
>   }
>   }
> - const struct nir_spirv_supported_extensions supported_ext = {
> + const struct nir_spirv_supported_capabilities supported_cap = {
>   .draw_parameters = true,
>   .float64 = true,
>   .image_read_without_format = true,
> @@ -208,7 +208,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
>   };
>   entry_point = spirv_to_nir(spirv, module->size / 4,
>  spec_entries, num_spec_entries,
> -stage, entrypoint_name, 
> _ext, _options);
> +stage, entrypoint_name, 
> _cap, _options);
>   nir = entry_point->shader;
>   assert(nir->info.stage == stage);
>   nir_validate_shader(nir);
> diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_spirv.h
> index 83577fb5d23..0204e81d091 100644
> --- a/src/compiler/spirv/nir_spirv.h
> +++ b/src/compiler/spirv/nir_spirv.h
> @@ -42,7 +42,7 @@ struct nir_spirv_specialization {
> };
>  };
>  
> -struct nir_spirv_supported_extensions {
> +struct nir_spirv_supported_capabilities {
> bool float64;
> bool image_ms_array;
> bool tessellation;
> @@ -58,7 +58,7 @@ nir_function *spirv_to_nir(const uint32_t *words, size_t 
> word_count,
> struct nir_spirv_specialization *specializations,
> unsigned num_specializations,
> gl_shader_stage stage, const char 
> *entry_point_name,
> -   const struct nir_spirv_supported_extensions *ext,
> +   const struct nir_spirv_supported_capabilities 
> *cap,
> const nir_shader_compiler_options *options);
>  
>  #ifdef __cplusplus
> diff --git a/src/compiler/spirv/spirv_to_nir.c 
> b/src/compiler/spirv/spirv_to_nir.c
> index 027efab88d7..6034228ed36 100644
> --- a/src/compiler/spirv/spirv_to_nir.c
> +++ b/src/compiler/spirv/spirv_to_nir.c
> @@ -2672,7 +2672,7 @@ stage_for_execution_model(SpvExecutionModel model)
>  }
>  
>  #define spv_check_supported(name, cap) do {  \
> -  if (!(b->ext && b->ext->name)) \
> +  if (!(b->cap && b->cap->name)) \
>   vtn_warn("Unsupported SPIR-V capability: %s",  \
>spirv_capability_to_string(cap)); \
> } while(0)
> @@ -3313,7 +3313,7 @@ nir_function *
>  spirv_to_nir(const uint32_t *words, size_t word_count,
>   struct nir_spirv_specialization *spec, unsigned num_spec,
>   gl_shader_stage stage, const char *entry_point_name,
> - const struct nir_spirv_supported_extensions *ext,
> + const struct nir_spirv_supported_capabilities *cap,
>   const nir_shader_compiler_options *options)
>  {
> const uint32_t *word_end = words + word_count;
> @@ -3336,7 +3336,7 @@ spirv_to_nir(const uint32_t *words, size_t word_count,
> exec_list_make_empty(>functions);
> b->entry_point_stage = stage;
> b->entry_point_name = entry_point_name;
> -   b->ext = ext;
> +   b->cap = cap;
>  
> /* Handle all the preamble instructions */
> words = 

Re: [Mesa-dev] [PATCH 09/24] i965: initialize SPIR-V capabilities

[Ian Romanick]

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro 
> 
> Needed for ARB_gl_spirv. Right now those are the same that the intel
> vulkan driver, but those are not shared. From the ARB_spirv_extensions
> spec:
> 
>"3. If a new GL extension is added that includes SPIR-V support via
>a new SPIR-V extension does it's SPIR-V extension also get
>enumerated by the SPIR_V_EXTENSIONS_ARB query?.
> 
>RESOLVED. Yes. It's good to include it for consistency. Any SPIR-V
>functionality supported beyond the SPIR-V version that is required
>for the GL API version should be enumerated."
> 
> Reading between lines, there is the possibility of specific GL
> extensions enabling specific SPIR-V extensions (so capabilities). That
> would mean that it is possible that OpenGL and Vulkan not having the
> same capabilities supported, even for the same driver. So for now we
> keep them separate. Perhaps in the future it is better to keep them
> the same and synced.

Hm... I wonder if we should enable SPIR-V extensions based on OpenGL
extensions rather than from lower-level NIR capabilities.  I guess that
would have other potential problems.

> v2: Fix off-tree compilation, including full path to nir/nir.h inside
>spirv/nir_spirv.h. (Eduardo Lima)
> ---
>  src/compiler/spirv/nir_spirv.h  |  2 +-
>  src/mesa/drivers/dri/i965/brw_context.c | 23 +++
>  src/mesa/main/context.c |  2 ++
>  3 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_spirv.h
> index 0204e81d091..d975254047a 100644
> --- a/src/compiler/spirv/nir_spirv.h
> +++ b/src/compiler/spirv/nir_spirv.h
> @@ -28,7 +28,7 @@
>  #ifndef _NIR_SPIRV_H_
>  #define _NIR_SPIRV_H_
>  
> -#include "nir/nir.h"
> +#include "compiler/nir/nir.h"
>  
>  #ifdef __cplusplus
>  extern "C" {
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 19d5a2e3503..b85f36cfbbd 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -75,6 +75,7 @@
>  #include "util/debug.h"
>  #include "isl/isl.h"
>  
> +#include "compiler/spirv/nir_spirv.h"
>  /***
>   * Mesa's Driver Functions
>   ***/
> @@ -331,6 +332,24 @@ brw_init_driver_functions(struct brw_context *brw,
>functions->GetSamplePosition = gen6_get_sample_position;
>  }
>  
> +static struct nir_spirv_supported_capabilities *
> +brw_initialize_spirv_supported_capabilities(struct brw_context *brw)
> +{
> +   const struct gen_device_info *devinfo = >screen->devinfo;
> +   struct nir_spirv_supported_capabilities *cap =
> +  MALLOC_STRUCT(nir_spirv_supported_capabilities);

calloc?

> +
> +   cap->float64 = devinfo->gen >= 8;
> +   cap->int64 = devinfo->gen >= 8;
> +   cap->tessellation = true;
> +   cap->draw_parameters = true;
> +   cap->image_write_without_format = true;
> +   cap->multiview = true;
> +   cap->variable_pointers = true;
> +
> +   return cap;
> +}
> +
>  static void
>  brw_initialize_context_constants(struct brw_context *brw)
>  {
> @@ -697,6 +716,10 @@ brw_initialize_context_constants(struct brw_context *brw)
>  
> if (!(ctx->Const.ContextFlags & GL_CONTEXT_FLAG_DEBUG_BIT))
>ctx->Const.AllowMappedBuffersDuringExecution = true;
> +
> +   /* GL_ARB_gl_spirv */
> +   ctx->Const.SpirVCapabilities =
> +  brw_initialize_spirv_supported_capabilities(brw);

I think this should only occur when the GL version is >= 3.3.

>  }
>  
>  static void
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index 61099eb39f2..837c1138998 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -1378,6 +1378,8 @@ _mesa_free_context_data( struct gl_context *ctx )
> if (ctx == _mesa_get_current_context()) {
>_mesa_make_current(NULL, NULL, NULL);
> }
> +
> +   free(ctx->Const.SpirVCapabilities);
>  }
>  
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 10-bit Mesa/Gallium support

[Adam Jackson]

On Thu, 2017-11-23 at 18:35 +0100, Marek Olšák wrote:
> Hi everybody,
> 
> Mario, feel free to push your patches if you haven't yet. (except the
> workaround)
> 
> For AMD, I applied Mario's patches (except Wayland - that didn't
> apply) and added initial Gallium support:
> https://cgit.freedesktop.org/~mareko/mesa/log/?h=10bit
> 
> What's the status of Glamor?

Probably not working at all:

https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_transfer.c#n26

At best I'd expect things to be largely unaccelerated. At the moment
glamor assumes pictures are either [ax]rgb or a8 because it doesn't
know about ARB_texture_view/ARB_texture_storage/ARB_sampler_objects.
The last, at least, has a work-in-progress branch here:

https://github.com/anholt/xserver/tree/glamor-sampler-objects

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

Re: [Mesa-dev] [PATCH] mesa/gles: adjust internal format in glTexSubImage2D error checks

[Matt Turner]

Thanks Tapani.

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

Re: [Mesa-dev] [PATCH] glsl: Fix typo nagivation -> navigation

[Timothy Arceri]

On 27/11/17 23:02, Nicolai Hähnle wrote:

Reviewed-by: Nicolai Hähnle 



Pushed. Thanks!



On 25.11.2017 15:08, Gwan-gyeong Mun wrote:

Signed-off-by: Mun Gwan-gyeong 
---
  src/compiler/glsl/ir_hierarchical_visitor.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/glsl/ir_hierarchical_visitor.h 
b/src/compiler/glsl/ir_hierarchical_visitor.h

index 824b05e73d..5f5acd041b 100644
--- a/src/compiler/glsl/ir_hierarchical_visitor.h
+++ b/src/compiler/glsl/ir_hierarchical_visitor.h
@@ -54,7 +54,7 @@ enum ir_visitor_status {
   * returning \c visit_stop), or stop visiting sibling nodes (by 
returning \c

   * visit_continue_with_parent).
   *
- * These two changes combine to allow nagivation of children to be 
implemented
+ * These two changes combine to allow navigation of children to be 
implemented
   * in the composite's \c accept method.  The \c accept method for a 
leaf-node
   * class will simply call the \c visit method, as usual, and pass 
its return
   * value on.  The \c accept method for internal-node classes will 
call the \c






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

Re: [Mesa-dev] [PATCH] mesa/st: glsl_to_tgsi: Dissolve arrays who's elements are only accessed directly

[Timothy Arceri]

On 28/11/17 01:01, Gert Wollny wrote:

Am Montag, den 27.11.2017, 12:14 +0100 schrieb Gert Wollny:

Am Sonntag, den 26.11.2017, 18:01 -0800 schrieb Eric Anholt:



This looks like something that should be done with (at most) a
small change to opt_array_splitting.cpp, rather than reimplementing
it here.


It seems that the reason the arrays are not split there is that in
the case of the given piglits, the arrays are accessed in loops, and
only because the loops are completely unrolled (on r600), the array
elements are then no longer addressed indirectly and can be split.





Since I have not yet looked at that part of the code I wonder now
whether it one can simply move the "optimize_split_arrays" step past
the loop unrolling, or whether one should duplicate that step.


Okay, now I see that the optimization is run various times, so it is
not clear to me why the array is not split in
glsl-1.50/execution/geometry/max-input-components

There the array that doesn't get split is declared like

in blk {
   float f[min(gl_MaxGeometryInputComponents,
   gl_MaxVertexOutputComponents)];
} ins[];

The typical IR for the element access then looks like this

(if
  (expression bool != (array_ref
   (record_ref
(array_ref
 (var_ref ins)
  (constant int (4))
 )
   f)
  (constant int (81)) )
(constant float (4082.00)) ) (
 (assign  (x) (var_ref ok)  (constant bool (0)) )
   )
   ())

in TGSI this is.

   FSNE TEMP[851].x := ARRAY(1)[81]., IMM[83].
  
i.e. direct addressing.



If I understand the comments in opt_array_splitting, arrays of arrays
are not properly handled there. Curretly, I don't see how I can fix
this, because I simply didn't look at any code there before.


There is more to it than that. We don't even split varyings at all 
currently.


"This skips uniform/varying arrays, which would need careful handling 
due to their ir->location fields tying them to the GL API and other 
shader stages."


This is enforced in get_variable_entry() via:

   if (var->data.mode != ir_var_auto &&
   var->data.mode != ir_var_temporary)
  return NULL;

As per my previous email I don't think there is much value in putting a 
bunch of work into this pass.




Best,
Gert


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

Re: [Mesa-dev] [PATCH 2/4] mesa: fix crash when an ATI_fs pass begins with an alpha inst

[Roland Scheidegger]

Am 27.11.2017 um 21:29 schrieb Ian Romanick:
> On 11/20/2017 06:04 PM, Roland Scheidegger wrote:
>> Am 21.11.2017 um 01:40 schrieb Ian Romanick:
>>> On 11/20/2017 04:07 PM, Miklós Máté wrote:
 This fixes crash when:
 - first pass begins with alpha inst
 - first pass ends with color inst, second pass begins with alpha inst

 Also, use the symbolic name instead of a number.
 Piglit: spec/ati_fragment_shader/api-alphafirst

 Signed-off-by: Miklós Máté 
 ---
  src/mesa/main/atifragshader.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

 diff --git a/src/mesa/main/atifragshader.c b/src/mesa/main/atifragshader.c
 index 49ddb6e5af..d6fc37ac8f 100644
 --- a/src/mesa/main/atifragshader.c
 +++ b/src/mesa/main/atifragshader.c
 @@ -598,8 +598,10 @@ _mesa_FragmentOpXATI(GLint optype, GLuint arg_count, 
 GLenum op, GLuint dst,
curProg->cur_pass=3;
  
 /* decide whether this is a new instruction or not ... all color 
 instructions are new,
 -  and alpha instructions might also be new if there was no preceding 
 color inst */
 -   if ((optype == 0) || (curProg->last_optype == optype)) {
 +  and alpha instructions might also be new if there was no preceding 
 color inst,
 +  and this may be the first inst of the pass */
>>>
>>> I know the code previously used this same formatting, but the Mesa style
>>> is for the */ of a multi-line comment to be on its own line.  Each other
>>> line should also start with a *.  And line-wrap around 78 characters.
>>> Like:
>>>
>>>/* Decide whether this is a new instruction or not.  All color 
>>> instructions
>>> * are new, and alpha instructions might also be new if there was no
>>> * preceding color inst.  This may also be the first inst of the pass.
>>> */
>>>
 +   if ((optype == ATI_FRAGMENT_SHADER_COLOR_OP) || (curProg->last_optype 
 == optype)
 + || (curProg->numArithInstr[curProg->cur_pass >> 1] == 0)) {
>>>
>>> I lost the debate about where the || (or &&) should go... it should be
>>> on the previous line.  Most of the parenthesis are unnecessary, and the
>>> second line should line up with the opening (.
>>>
>>> On a side topic... if anyone understands how
>>> ati_fragment_shader::cur_pass works, it would be really great if they
>>> could document it in mtypes.h.
>>
>> This just indicates which pass is currently being specified. Some
>> instructions will trigger a new pass, some instructions are only valid
>> in the first or second pass and so on, and you can have a maximum of 2
>> passes.
> 
> Which is the confusing part.  ATI fragment shaders can have two passes,
> but, as far as I can tell by reading the code,
> ati_fragment_shader::cur_pass can have a maximum value of... 5?  At
> least 4 for sure.
Ah yes I wasn't very accurate there.
unlike NumPasses, cur_pass distinguishes between the texture and
arithmetic phases. Hence cur_pass being 0 means currently texture
instructions are specified for the first pass. cur_pass 1 arithmetic for
the first pass. cur_pass 2/3 correspond to the second pass accordingly.
I can't see though how you could get values larger than 3 (if the value
is 3 and there's some instruction which would increase it, that should
be an error).

Roland


> 
>> I guess it's a bit awkward how this needs to work due to the shader
>> being specified bit-by-bit rather than all at once, but the actual
>> concept is very similar to the multiple phases of d3d9 and r300 (and
>> didn't i915 have something similar too). Of course, if you translate it
>> away (on everything but r200) then only the error checking aspect of it
>> really matters in the end.
>>
>> FWIW the patches all look correct to me, apparently there were quite
>> some errors in there (I think it was mostly verified with doom3 at that
>> time...).
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/24] spirv_extensions: define spirv_extensions_supported

[Ian Romanick]

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro 
> 
> Add a struct to maintain which SPIR-V extensions are supported, and an
> utility method to initialize it based on
> nir_spirv_supported_capabilities.
> ---
>  src/compiler/spirv/spirv_extensions.c | 29 +
>  src/compiler/spirv/spirv_extensions.h | 12 
>  2 files changed, 41 insertions(+)
> 
> diff --git a/src/compiler/spirv/spirv_extensions.c 
> b/src/compiler/spirv/spirv_extensions.c
> index 64d61c49d31..8263b693abd 100644
> --- a/src/compiler/spirv/spirv_extensions.c
> +++ b/src/compiler/spirv/spirv_extensions.c
> @@ -59,3 +59,32 @@ spirv_extensions_to_string(SpvExtension ext)
>  
> return "unknown";
>  }
> +
> +/**
> + * Sets the supported flags for known SPIR-V extensions based on the
> + * capabilites supported (spirv capabilities based on the spirv to nir
> + * support).
> + *
> + * One could argue that makes more sense in the other way around, as from the
> + * spec pov capabilities are enable for a given extension. But from our pov,
> + * we support or not (depending on the driver) some given capability, and
> + * spirv_to_nir check for capabilities not extensions. Also we usually fill
> + * first the supported capabilities, that are not always related to an
> + * extension.
> + */
> +void
> +fill_supported_spirv_extensions(struct spirv_supported_extensions *ext,
> +const struct 
> nir_spirv_supported_capabilities *cap)

Since this is exposed outside this file, this function should have some
sort of a namespace prefix.  I'm not sure what it should be, though.

> +{
> +   for (unsigned i = 0; i < SPV_EXTENSIONS_COUNT; i++)
> +  ext->supported[i] = false;
> +
> +   ext->count = 0;
> +
> +   ext->supported[SPV_KHR_shader_draw_parameters] = cap->draw_parameters;
> +   ext->supported[SPV_KHR_multiview] = cap->multiview;
> +   ext->supported[SPV_KHR_variable_pointers] = cap->variable_pointers;
> +
> +   for (unsigned i = 0; i < SPV_EXTENSIONS_COUNT; i++)
> +  if (ext->supported[i]) ext->count++;

   for (unsigned i = 0; i < SPV_EXTENSIONS_COUNT; i++) {
  if (ext->supported[i])
 ext->count++;
   }

> +}
> diff --git a/src/compiler/spirv/spirv_extensions.h 
> b/src/compiler/spirv/spirv_extensions.h
> index 54bc7f2dbe0..22238b727d7 100644
> --- a/src/compiler/spirv/spirv_extensions.h
> +++ b/src/compiler/spirv/spirv_extensions.h
> @@ -25,6 +25,7 @@
>  #define _SPIRV_EXTENSIONS_H_
>  
>  #include "compiler/nir/nir.h"
> +#include "nir_spirv.h"
>  
>  #ifdef __cplusplus
>  extern "C" {
> @@ -60,8 +61,19 @@ typedef enum SpvExtension_ {
> SPV_EXTENSIONS_COUNT
>  } SpvExtension;
>  
> +struct spirv_supported_extensions {
> +   /** Flags the supported extensions. Array to make it easier to iterate. */
> +   bool supported[SPV_EXTENSIONS_COUNT];
> +
> +   /** Number of supported extensions */
> +   unsigned int count;

I see this is used by _mesa_get_spirv_extension_count, but I don't see
where that is used.  Did I miss it?

> +};
> +
>  const char *spirv_extensions_to_string(SpvExtension ext);
>  
> +void fill_supported_spirv_extensions(struct spirv_supported_extensions *ext,
> + const struct 
> nir_spirv_supported_capabilities *cap);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> 

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

Re: [Mesa-dev] [PATCH 11/24] spirv_extensions: add list of extensions and to_string method

[Ian Romanick]

On 11/15/2017 05:22 AM, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro 
> 
> Ideally this should be generated somehow. One option would be gather
> all the extension dependencies listed on the core grammar, but there
> would be the possibility of not including some of the extensions.
> 
> Note that spirv-tools is doing it just slightly better, as it has a
> hardcoded list of extensions manually took from the registry, that
> they parse to get the enum and the to_string method (see
> generate_grammar_tables.py).
> ---
>  src/compiler/Makefile.sources |  2 +
>  src/compiler/spirv/spirv_extensions.c | 61 +++
>  src/compiler/spirv/spirv_extensions.h | 69 
> +++
>  3 files changed, 132 insertions(+)
>  create mode 100644 src/compiler/spirv/spirv_extensions.c
>  create mode 100644 src/compiler/spirv/spirv_extensions.h
> 
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index 2ab8e163a26..f198456c751 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -293,6 +293,8 @@ SPIRV_FILES = \
>   spirv/GLSL.std.450.h \
>   spirv/nir_spirv.h \
>   spirv/spirv.h \
> + spirv/spirv_extensions.c \
> + spirv/spirv_extensions.h \
>   spirv/spirv_info.h \
>   spirv/spirv_to_nir.c \
>   spirv/vtn_alu.c \
> diff --git a/src/compiler/spirv/spirv_extensions.c 
> b/src/compiler/spirv/spirv_extensions.c
> new file mode 100644
> index 000..64d61c49d31
> --- /dev/null
> +++ b/src/compiler/spirv/spirv_extensions.c
> @@ -0,0 +1,61 @@
> +/*
> + * Copyright © 2017 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include "spirv.h"
> +#include "spirv_extensions.h"
> +
> +const char *
> +spirv_extensions_to_string(SpvExtension ext)
> +{
> +   switch (ext) {
> +   case SPV_AMD_shader_explicit_vertex_parameter: return 
> "SPV_AMD_shader_explicit_vertex_parameter";
> +   case SPV_AMD_shader_trinary_minmax: return 
> "SPV_AMD_shader_trinary_minmax";
> +   case SPV_AMD_gcn_shader: return "SPV_AMD_gcn_shader";
> +   case SPV_KHR_shader_ballot: return "SPV_KHR_shader_ballot";
> +   case SPV_AMD_shader_ballot: return "SPV_AMD_shader_ballot";
> +   case SPV_AMD_gpu_shader_half_float: return 
> "SPV_AMD_gpu_shader_half_float";
> +   case SPV_KHR_shader_draw_parameters: return 
> "SPV_KHR_shader_draw_parameters";
> +   case SPV_KHR_subgroup_vote: return "SPV_KHR_subgroup_vote";
> +   case SPV_KHR_16bit_storage: return "SPV_KHR_16bit_storage";
> +   case SPV_KHR_device_group: return "SPV_KHR_device_group";
> +   case SPV_KHR_multiview: return "SPV_KHR_multiview";
> +   case SPV_NVX_multiview_per_view_attributes: return 
> "SPV_NVX_multiview_per_view_attributes";
> +   case SPV_NV_viewport_array2: return "SPV_NV_viewport_array2";
> +   case SPV_NV_stereo_view_rendering: return "SPV_NV_stereo_view_rendering";
> +   case SPV_NV_sample_mask_override_coverage: return 
> "SPV_NV_sample_mask_override_coverage";
> +   case SPV_NV_geometry_shader_passthrough: return 
> "SPV_NV_geometry_shader_passthrough";
> +   case SPV_AMD_texture_gather_bias_lod: return 
> "SPV_AMD_texture_gather_bias_lod";
> +   case SPV_KHR_storage_buffer_storage_class: return 
> "SPV_KHR_storage_buffer_storage_class";
> +   case SPV_KHR_variable_pointers: return "SPV_KHR_variable_pointers";
> +   case SPV_AMD_gpu_shader_int16: return "SPV_AMD_gpu_shader_int16";
> +   case SPV_KHR_post_depth_coverage: return "SPV_KHR_post_depth_coverage";
> +   case SPV_KHR_shader_atomic_counter_ops: return 
> "SPV_KHR_shader_atomic_counter_ops";
> +   case SPV_EXT_shader_stencil_export: return 
> "SPV_EXT_shader_stencil_export";
> +   case SPV_EXT_shader_viewport_index_layer: return 
> "SPV_EXT_shader_viewport_index_layer";
> +   case SPV_AMD_shader_image_load_store_lod: return 

Re: [Mesa-dev] [PATCH] util: hash_table: move NULL assert to string hashing function

[Ian Romanick]

On 11/27/2017 08:27 AM, Lionel Landwerlin wrote:
> Hash maps might use pointer keys (which people surely might want to
> use to hash values) in which case a 0 value is perfectly acceptable.
> It's only if the hash function needs to deference the pointer that we
> want to be sure it's not NULL.
> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/util/hash_table.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/util/hash_table.c b/src/util/hash_table.c
> index b7421a0144c..8a4de565fcc 100644
> --- a/src/util/hash_table.c
> +++ b/src/util/hash_table.c
> @@ -296,8 +296,6 @@ hash_table_insert(struct hash_table *ht, uint32_t hash,
> uint32_t start_hash_address, hash_address;
> struct hash_entry *available_entry = NULL;
>  
> -   assert(key != NULL);
> -
> if (ht->entries >= ht->max_entries) {
>_mesa_hash_table_rehash(ht, ht->size_index + 1);
> } else if (ht->deleted_entries + ht->entries >= ht->max_entries) {
> @@ -481,6 +479,8 @@ _mesa_hash_string(const void *_key)
> uint32_t hash = _mesa_fnv32_1a_offset_bias;
> const char *key = _key;
>  
> +   assert(key != NULL);
> +

Should probably also add this check to _mesa_fnv32_1a_accumulate_block
or _mesa_hash_data too.

> while (*key != 0) {
>hash = _mesa_fnv32_1a_accumulate(hash, *key);
>key++;
> 

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

Re: [Mesa-dev] [PATCH] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Robert Foss]

Hey Rob,

On Mon, 2017-11-27 at 13:42 -0600, Rob Herring wrote:
> On Mon, Nov 27, 2017 at 8:14 AM, Robert Foss  om> wrote:
> > From: Tomasz Figa 
> > 
> > There is no API available to properly query the
> > IMPLEMENTATION_DEFINED
> > format. As a workaround we rely here on gralloc allocating either
> > an arbitrary YCbCr 4:2:0 or RGBX_, with the latter being
> > recognized
> > by lock_ycbcr failing.
> > 
> > Reviewed-on: https://chromium-review.googlesource.com/566793
> > 
> > Signed-off-by: Tomasz Figa 
> > Reviewed-by: Chad Versace 
> > Signed-off-by: Robert Foss 
> > ---
> >  src/egl/drivers/dri2/platform_android.c | 39
> > +++--
> >  1 file changed, 37 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/egl/drivers/dri2/platform_android.c
> > b/src/egl/drivers/dri2/platform_android.c
> > index 63223e9a69..ae914d79c1 100644
> > --- a/src/egl/drivers/dri2/platform_android.c
> > +++ b/src/egl/drivers/dri2/platform_android.c
> > @@ -59,6 +59,10 @@ static const struct droid_yuv_format
> > droid_yuv_formats[] = {
> > { HAL_PIXEL_FORMAT_YCbCr_420_888,   0, 1,
> > __DRI_IMAGE_FOURCC_YUV420 },
> > { HAL_PIXEL_FORMAT_YCbCr_420_888,   1, 1,
> > __DRI_IMAGE_FOURCC_YVU420 },
> > { HAL_PIXEL_FORMAT_YV12,1, 1,
> > __DRI_IMAGE_FOURCC_YVU420 },
> > +   /* HACK: See droid_create_image_from_prime_fd() and b/32077885.
> > */
> > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 2,
> > __DRI_IMAGE_FOURCC_NV12 },
> > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 1,
> > __DRI_IMAGE_FOURCC_YUV420 },
> > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   1, 1,
> > __DRI_IMAGE_FOURCC_YVU420 },
> >  };
> > 
> >  static int
> > @@ -90,6 +94,11 @@ get_format_bpp(int native)
> > 
> > switch (native) {
> > case HAL_PIXEL_FORMAT_RGBA_:
> > +   case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
> > +  /*
> > +   * HACK: Hardcode this to RGBX_ as per cros_gralloc
> > hack.
> 
> Does this work with other grallocs?

Not necessarily, it is implementation specific.
The implementation specific part is lock_ycbcr() failing for non YUV
formats, which allows the application to disambiguate between YCbCr
4:2:0 or RGBX_.

> 
> > +   * TODO: Remove this once b/32077885 is fixed.
> 
> Is that a public bug? A full url would be better if so.

Unfortunately it isn't, I maintained the link since it is better than
nothing. And to be clear, I don't have access to that URL either at
this moment.


Rob.

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 mesa 16/16] util: use NDEBUG to guard asserts

[Ian Romanick]

On 11/27/2017 10:46 AM, Dylan Baker wrote:
> Quoting Eric Engestrom (2017-11-27 09:46:57)
>> On Saturday, 2017-11-25 18:45:14 +0100, Gert Wollny wrote:
>>> Am Freitag, den 24.11.2017, 18:07 + schrieb Eric Engestrom:
 Signed-off-by: Eric Engestrom 
 ---
  src/util/ralloc.c | 18 +-
  src/util/slab.c   |  4 ++--
  2 files changed, 11 insertions(+), 11 deletions(-)

 diff --git a/src/util/ralloc.c b/src/util/ralloc.c
 index 42cfa2e391d52df68db2..b52079ac075a0fe11944 100644
 --- a/src/util/ralloc.c
 +++ b/src/util/ralloc.c
 @@ -61,7 +61,7 @@ struct
  #endif
 ralloc_header
  {
 -#ifdef DEBUG
 +#ifndef NDEBUG
 /* A canary value used to determine whether a pointer is
 ralloc'd. */
 unsigned canary;
  #endif
 @@ -88,7 +88,7 @@ get_header(const void *ptr)
  {
 ralloc_header *info = (ralloc_header *) (((char *) ptr) -
     sizeof(ralloc_header));
 -#ifdef DEBUG
 +#ifndef NDEBUG
 assert(info->canary == CANARY);
  #endif
>>>
>>> With NDEBUG defined "assert" already translates to a no-op, hence the
>>> extra "#ifndef NDEBUG" block is not needed (same for the other asserts
>>> below and in the other patches). 
>>
>> Indeed, I did so many of those conversions that I wasn't thinking about
>> that anymore. Thanks for catching that, I'll remove the include guards
>> altogether around plain asserts()s.
> 
> Is that true in this case? info->canary is only defined if NDEBUG is not
> defined, so this will fail to compile since those symbols are undefined, 
> right?

The parameters to a preprocessor macro are (basically) just text.  They
are not evaluated until after the macro is expanded.  I'm 93.2% sure
removing the guards around the assert() should be fine in this case.

As for changing the other guards (here and in the other patches), I'm a
little less sure.  There are two different debugging macros that have
two different, partially historical, meanings.

NDEBUG is part of ANSI C.  When NDEBUG is defined, assert() expands to
nothing.  In Mesa, individual assertions are usually cheap, but there
may be a lot of them.  As far as I'm aware, some distros build most
packages without NDEBUG defined because some developers (incorrectly)
use assertions in place of regular error checks or have necessary code
inside the assertion.  Mesa has had some bugs of this nature in the past.

DEBUG is a Mesa invention.  It has been used over the years to enable
much more expensive checks.  Both GLSL IR and NIR use DEBUG to enable
expensive shader IR validation, for example.  I also thought that the
ralloc code used DEBUG to enable periodic validation of allocation
headers and parent / child lists, but I may be mistaken there.

I think there is value in being able to enable cheap and expensive debug
checks independently.  Enabling IR validation after every optimization
pass makes a shader-db run take an excruciating amount of time.  At the
same time, I still want to have some checks to detect problems that I
may have created.

The existing situation is a bit confusing.  At times people use DEBUG
when they probably want NDEBUG.  I think part of the problem is that
DEBUG is such a generic name, and I think a lot of people don't know
about NDEBUG.  There are a few ways we could probably clean this up, but
I don't have strong feeling for which would be best.

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



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 4/4] mesa: fix validate for secondary interpolator

[Ian Romanick]

On 11/21/2017 04:22 PM, Miklós Máté wrote:
> On 21/11/17 02:09, Ian Romanick wrote:
>> On 11/20/2017 04:07 PM, Miklós Máté wrote:
>>> This patch fixes multiple problems:
>>> - the interpolator check was duplicated
>>> - both had arg instead of argRep
>>> - I split it into color and alpha for better readability and error msg
>>> - the DOT4 check only applies to color instruction according to the spec
>> For the sake of reviewers and the next person to look at this code, a
>> spec quotation or two in the code would be really helpful.
> Should I add spec quotations to these two error checks or to all of them?

Usually people will only use newer coding style in the code that they
add or directly change.  So I would only ask that you don't add more
extra () and add the spec quotes to the code you are modifying.  If you
feel like sending additional patches to modernize the rest of the file,
I'll be happy to review them.  Don't feel compelled to make those extra
changes, though... especially if you have more work in progress.

>>> - made the DOT4 check fatal, and improved the error msg
>>>
>>> Piglit: spec/ati_fragment_shader/error08-secondary
>>>
>>> Signed-off-by: Miklós Máté 
>>> ---
>>>   src/mesa/main/atifragshader.c | 23 ---
>>>   1 file changed, 12 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/src/mesa/main/atifragshader.c
>>> b/src/mesa/main/atifragshader.c
>>> index 313ba0c66d..1bca8267b8 100644
>>> --- a/src/mesa/main/atifragshader.c
>>> +++ b/src/mesa/main/atifragshader.c
>>> @@ -171,15 +171,15 @@ static int check_arith_arg(struct
>>> ati_fragment_shader *curProg,
>>>     _mesa_error(ctx, GL_INVALID_ENUM, "C/AFragmentOpATI(arg)");
>>>     return 0;
>>>  }
>>> -   if ((arg == GL_SECONDARY_INTERPOLATOR_ATI) && (((optype == 0) &&
>>> (argRep == GL_ALPHA)) ||
>>> -  ((optype == 1) && ((arg == GL_ALPHA) || (argRep == GL_NONE) {
>>> -  _mesa_error(ctx, GL_INVALID_OPERATION,
>>> "C/AFragmentOpATI(sec_interp)");
>>> -  return 0;
>>> -   }
>>> -   if ((arg == GL_SECONDARY_INTERPOLATOR_ATI) && (((optype == 0) &&
>>> (argRep == GL_ALPHA)) ||
>>> -  ((optype == 1) && ((arg == GL_ALPHA) || (argRep == GL_NONE) {
>>> -  _mesa_error(ctx, GL_INVALID_OPERATION,
>>> "C/AFragmentOpATI(sec_interp)");
>>> -  return 0;
>> Adding this comment here makes it clear that the code is correct.
>>
>>     /* The ATI_fragment_shader spec says:
>>  *
>>  *    The error INVALID_OPERATION is generated by
>>  *    ColorFragmentOp[1..3]ATI if  is
>> SECONDARY_INTERPOLATOR_ATI
>>  *    and  is ALPHA, or by AlphaFragmentOp[1..3]ATI
>> if 
>>  *    is SECONDARY_INTERPOLATOR_ATI and  is ALPHA or
>> NONE, ...
>>  */
>>
>>> +   if (arg == GL_SECONDARY_INTERPOLATOR_ATI) {
>>> +  if ((optype == ATI_FRAGMENT_SHADER_COLOR_OP) && (argRep ==
>>> GL_ALPHA)) {
>> Like before, drop the unnecessary ().
> There are lots of unnecessary () in this file. Should I attempt to
> remove them all? Should I do it in this patch or in a separate one?
> 
>>
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> "CFragmentOpATI(sec_interp)");
>>> + return 0;
>>> +  } else if ((optype == ATI_FRAGMENT_SHADER_ALPHA_OP) &&
>>> +    ((argRep == GL_ALPHA) || (argRep == GL_NONE))) {
>> Remove extra () and line up with the opening (.
>>
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> "AFragmentOpATI(sec_interp)");
>>> + return 0;
>>> +  }
>>>  }
>>>  if ((curProg->cur_pass == 1) &&
>>>     ((arg == GL_PRIMARY_COLOR_ARB) || (arg ==
>>> GL_SECONDARY_INTERPOLATOR_ATI))) {
>>> @@ -642,10 +642,11 @@ _mesa_FragmentOpXATI(GLint optype, GLuint
>>> arg_count, GLenum op, GLuint dst,
>>>    return;
>>>     }
>>>  }
>> Same here regarding the comment.
>>
>>     /* The ATI_fragment_shader spec says:
>>  *
>>  *    The error INVALID_OPERATION is generated by...
>> ColorFragmentOp2ATI
>>  *    if  is DOT4_ATI and  is
>> SECONDARY_INTERPOLATOR_ATI and
>>  *     is ALPHA or NONE.
>>  */
>>
>>> -   if ((op == GL_DOT4_ATI) &&
>>> +   if ((optype == ATI_FRAGMENT_SHADER_COLOR_OP) && (op ==
>>> GL_DOT4_ATI) &&
>>>     (((arg1 == GL_SECONDARY_INTERPOLATOR_ATI) && ((arg1Rep ==
>>> GL_ALPHA) || (arg1Rep == GL_NONE))) ||
>>>     (((arg2 == GL_SECONDARY_INTERPOLATOR_ATI) && ((arg2Rep ==
>>> GL_ALPHA) || (arg2Rep == GL_NONE)) {
>>> -  _mesa_error(ctx, GL_INVALID_OPERATION,
>>> "C/AFragmentOpATI(sec_interp)");
>>> +  _mesa_error(ctx, GL_INVALID_OPERATION,
>>> "C/AFragmentOpATI(sec_interpDOT4)");
>>> +  return;
>>>  }
>>>    if (!check_arith_arg(curProg, optype, arg1, arg1Rep)) {
>>>
> 

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

Re: [Mesa-dev] [PATCH 2/4] mesa: fix crash when an ATI_fs pass begins with an alpha inst

[Ian Romanick]

On 11/20/2017 06:04 PM, Roland Scheidegger wrote:
> Am 21.11.2017 um 01:40 schrieb Ian Romanick:
>> On 11/20/2017 04:07 PM, Miklós Máté wrote:
>>> This fixes crash when:
>>> - first pass begins with alpha inst
>>> - first pass ends with color inst, second pass begins with alpha inst
>>>
>>> Also, use the symbolic name instead of a number.
>>> Piglit: spec/ati_fragment_shader/api-alphafirst
>>>
>>> Signed-off-by: Miklós Máté 
>>> ---
>>>  src/mesa/main/atifragshader.c | 6 --
>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/mesa/main/atifragshader.c b/src/mesa/main/atifragshader.c
>>> index 49ddb6e5af..d6fc37ac8f 100644
>>> --- a/src/mesa/main/atifragshader.c
>>> +++ b/src/mesa/main/atifragshader.c
>>> @@ -598,8 +598,10 @@ _mesa_FragmentOpXATI(GLint optype, GLuint arg_count, 
>>> GLenum op, GLuint dst,
>>>curProg->cur_pass=3;
>>>  
>>> /* decide whether this is a new instruction or not ... all color 
>>> instructions are new,
>>> -  and alpha instructions might also be new if there was no preceding 
>>> color inst */
>>> -   if ((optype == 0) || (curProg->last_optype == optype)) {
>>> +  and alpha instructions might also be new if there was no preceding 
>>> color inst,
>>> +  and this may be the first inst of the pass */
>>
>> I know the code previously used this same formatting, but the Mesa style
>> is for the */ of a multi-line comment to be on its own line.  Each other
>> line should also start with a *.  And line-wrap around 78 characters.
>> Like:
>>
>>/* Decide whether this is a new instruction or not.  All color 
>> instructions
>> * are new, and alpha instructions might also be new if there was no
>> * preceding color inst.  This may also be the first inst of the pass.
>> */
>>
>>> +   if ((optype == ATI_FRAGMENT_SHADER_COLOR_OP) || (curProg->last_optype 
>>> == optype)
>>> + || (curProg->numArithInstr[curProg->cur_pass >> 1] == 0)) {
>>
>> I lost the debate about where the || (or &&) should go... it should be
>> on the previous line.  Most of the parenthesis are unnecessary, and the
>> second line should line up with the opening (.
>>
>> On a side topic... if anyone understands how
>> ati_fragment_shader::cur_pass works, it would be really great if they
>> could document it in mtypes.h.
> 
> This just indicates which pass is currently being specified. Some
> instructions will trigger a new pass, some instructions are only valid
> in the first or second pass and so on, and you can have a maximum of 2
> passes.

Which is the confusing part.  ATI fragment shaders can have two passes,
but, as far as I can tell by reading the code,
ati_fragment_shader::cur_pass can have a maximum value of... 5?  At
least 4 for sure.

> I guess it's a bit awkward how this needs to work due to the shader
> being specified bit-by-bit rather than all at once, but the actual
> concept is very similar to the multiple phases of d3d9 and r300 (and
> didn't i915 have something similar too). Of course, if you translate it
> away (on everything but r200) then only the error checking aspect of it
> really matters in the end.
> 
> FWIW the patches all look correct to me, apparently there were quite
> some errors in there (I think it was mostly verified with doom3 at that
> time...).
> 
> Roland
> 
>>>if (curProg->numArithInstr[curProg->cur_pass >> 1] > 7) {
>>>  _mesa_error(ctx, GL_INVALID_OPERATION, "C/AFragmentOpATI(instrCount)");
>>>  return;
>>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0=E021TggYOgVksqpASyumbrMCSKMsRIh5__J3WER0vyw=ek3znIpxIGsT2v0AG80jt9petuMBJvX1nXseAg81aYA=
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] i965: Kicking off fp16 glsl support

[Chema Casanova]

El 27/11/17 a las 21:11, Matt Turner escribió:
> 1-14, except 4 are
>
> Reviewed-by: Matt Turner 
>
> I started getting to things that made me realize I needed to review
> Igalia's work before I continued here.

I'm submitting tomorrow the v4 for our VK_KHR_16bit_storage series. So
better have a look to the new one.

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

Re: [Mesa-dev] [PATCH 1/2] docs/llvmpipe.html: Add ppc64le as alternative architecture to x86.

[Matt Turner]

On Mon, Nov 27, 2017 at 11:44 AM, Ben Crocker  wrote:
> Power8, Power8NV, and Power9 are supported on an equal footing
> with X86.
>
> Cc: "17.2" "17.3" 
> Signed-off-by: Ben Crocker 
> ---
>  docs/llvmpipe.html | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html
> index 12dccb5eae..5f93c0b807 100644
> --- a/docs/llvmpipe.html
> +++ b/docs/llvmpipe.html
> @@ -20,7 +20,7 @@
>  The Gallium llvmpipe driver is a software rasterizer that uses LLVM to
>  do runtime code generation.
>  Shaders, point/line/triangle rasterization and vertex processing are
> -implemented with LLVM IR which is translated to x86 or x86-64 machine
> +implemented with LLVM IR which is translated to x86, x86-64, or ppc64le 
> machine
>  code.
>  Also, the driver is multithreaded to take advantage of multiple CPU cores
>  (up to 8 at this time).
> @@ -32,18 +32,30 @@ It's the fastest software rasterizer for Mesa.
>
>  
>  
> -   An x86 or amd64 processor; 64-bit mode recommended.
> +   For x86 or amd64 processors, 64-bit mode is recommended.
> 
> Support for SSE2 is strongly encouraged.  Support for SSE3 and SSE4.1 will
> yield the most efficient code.  The fewer features the CPU has the more
> -   likely is that you run into underperforming, buggy, or incomplete code.
> +   likely it is that you will run into underperforming, buggy, or incomplete 
> code.
> 
> +
> +
> +   
> + For ppc64le processors, use of Altivec (the Vector Facility)
> + is recommended if Altivec is supported.
> +   
> +   

Someone can fix-up on commit -- the  and  are reversed here.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] docs/llvmpipe.html: Add ppc64le as alternative architecture to x86.

[Ben Crocker]

Power8, Power8NV, and Power9 are supported on an equal footing
with X86.

Cc: "17.2" "17.3" 
Signed-off-by: Ben Crocker 
---
 docs/llvmpipe.html | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html
index 12dccb5eae..5f93c0b807 100644
--- a/docs/llvmpipe.html
+++ b/docs/llvmpipe.html
@@ -20,7 +20,7 @@
 The Gallium llvmpipe driver is a software rasterizer that uses LLVM to
 do runtime code generation.
 Shaders, point/line/triangle rasterization and vertex processing are
-implemented with LLVM IR which is translated to x86 or x86-64 machine
+implemented with LLVM IR which is translated to x86, x86-64, or ppc64le machine
 code.
 Also, the driver is multithreaded to take advantage of multiple CPU cores
 (up to 8 at this time).
@@ -32,18 +32,30 @@ It's the fastest software rasterizer for Mesa.
 
 
 
-   An x86 or amd64 processor; 64-bit mode recommended.
+   For x86 or amd64 processors, 64-bit mode is recommended.

Support for SSE2 is strongly encouraged.  Support for SSE3 and SSE4.1 will
yield the most efficient code.  The fewer features the CPU has the more
-   likely is that you run into underperforming, buggy, or incomplete code.
+   likely it is that you will run into underperforming, buggy, or incomplete 
code.

+
+
+   
+ For ppc64le processors, use of Altivec (the Vector Facility)
+ is recommended if Altivec is supported.
+   
+   
+ Use of VSX, the Vector-Scalar Facility, is recommended if VSX is 
supported,
+ AND if LLVM version 4.0 or later is installed.
+   
+
+

See /proc/cpuinfo to know what your CPU supports.

 
 
-   LLVM: version 3.4 recommended; 3.3 or later required.
+   Unless otherwise stated, LLVM version 3.4 is recommended; 3.3 or later 
is required.

For Linux, on a recent Debian based distribution do:

-- 
2.13.6

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

[Mesa-dev] [PATCH 2/2] docs/llvmpipe.html: Minor edits

[Ben Crocker]

Language and spelling fixups in three places.

Cc: "17.2" "17.3" 
Signed-off-by: Ben Crocker 
---
 docs/llvmpipe.html | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html
index 5f93c0b807..a36a31ece3 100644
--- a/docs/llvmpipe.html
+++ b/docs/llvmpipe.html
@@ -63,7 +63,7 @@ It's the fastest software rasterizer for Mesa.
  aptitude install llvm-dev
 

-   If you want development snaptshot builds of LLVM for Debian and derived
+   If you want development snapshot builds of LLVM for Debian and derived
distributions like Ubuntu, you can use the APT repository at https://apt.llvm.org/; title="Debian Development packages for LLVM"
>apt.llvm.org, which are maintained by Debian's LLVM maintainer.
@@ -246,8 +246,8 @@ build/linux-???-debug/gallium/drivers/llvmpipe:
 
 
 
-Some of this tests can output results and benchmarks to a tab-separated-file
-for posterior analysis, e.g.:
+Some of these tests can output results and benchmarks to a tab-separated file
+for later analysis, e.g.:
 
 
   build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend -o blend.tsv
@@ -258,8 +258,8 @@ for posterior analysis, e.g.:
 
 
 
-  When looking to this code by the first time start in lp_state_fs.c, and 
-  then skim through the lp_bld_* functions called in there, and the comments
+  When looking at this code for the first time start in lp_state_fs.c, and
+  then skim through the lp_bld_* functions called there, and the comments
   at the top of the lp_bld_*.c functions.
 
 
-- 
2.13.6

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

Re: [Mesa-dev] [PATCH v2 2/2] i965/cnl: Correctly sample from fast-cleared sRGB textures

[Jason Ekstrand]

On Mon, Nov 27, 2017 at 11:37 AM, Roland Scheidegger 
wrote:

> If you use a float input color, does it mean it isn't quantized?
> I'm just wondering if you actually get (slightly) different values with
> sampling from fast-cleared surfaces than you'd get when you'd have
> cleared the surface normally.
> In any case, patch 1/2 of this series looks alright (I was just
> wondering why you needed it...), can't really review this one...
>

I think we can end up hitting that problem.  However, this patch doesn't
really make things any worse.  I've considered a time or two exactly how we
can fix that problem properly and it's going to take a bit of work.


> Roland
>
>
> Am 27.11.2017 um 20:02 schrieb Nanley Chery:
> > When sampling from fast-cleared sRGB textures on gen10, the hardware
> > will not decode the clear color to linear. We must therefore do it in
> > software.
> >
> > This makes the following piglit tests pass:
> > * spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend
> > * spec@arb_framebuffer_srgb@fbo-fast-clear
> > * spec@arb_framebuffer_srgb@msaa-fast-clear
> > * spec@ext_texture_srgb@fbo-fast-clear
> > * spec@ext_texture_srgb@multisample-fast-clear gl_ext_texture_srgb
> >
> > v2 (Jason Ekstrand):
> > - Update some comments.
> > - Simplify assertions.
> > - Use an sRGB-to-linear helper.
> >
> > Signed-off-by: Nanley Chery 
> > ---
> >  src/mesa/drivers/dri/i965/brw_blorp.c|  7 +++
> >  src/mesa/drivers/dri/i965/brw_meta_util.c| 26
> 
> >  src/mesa/drivers/dri/i965/brw_meta_util.h|  5 +
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  9 +++-
> >  4 files changed, 46 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> > index 38284d3b85..b10e9b95b7 100644
> > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > @@ -328,6 +328,13 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
> > struct blorp_surf src_surf, dst_surf;
> > blorp_surf_for_miptree(brw, _surf, src_mt, src_aux_usage, false,
> >_level, src_layer, 1, _surfs[0]);
> > +   if (devinfo->gen >= 10 && isl_format_is_srgb(src_isl_format) &&
> > +   src_clear_supported) {
> > +  src_surf.clear_color =
> > + gen10_convert_srgb_fast_clear_color(devinfo, src_isl_format,
> > + src_mt->fast_clear_color);
> > +   }
> > +
> > blorp_surf_for_miptree(brw, _surf, dst_mt, dst_aux_usage, true,
> >_level, dst_layer, 1, _surfs[1]);
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c
> b/src/mesa/drivers/dri/i965/brw_meta_util.c
> > index d292f5a8e2..d1ce9d46ea 100644
> > --- a/src/mesa/drivers/dri/i965/brw_meta_util.c
> > +++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
> > @@ -315,6 +315,32 @@ brw_is_color_fast_clear_compatible(struct
> brw_context *brw,
> > return true;
> >  }
> >
> > +/* When sampling from fast-cleared sRGB textures on gen10, the hardware
> > + * will not decode the clear color to linear. We must therefore do it in
> > + * software.
> > + */
> > +union isl_color_value
> > +gen10_convert_srgb_fast_clear_color(const struct gen_device_info
> *devinfo,
> > +enum isl_format format,
> > +const union isl_color_value color)
> > +{
> > +   /* Gen10 supports fast-clearing three of GL's sRGB formats. */
> > +   assert(devinfo->gen >= 10);
> > +   assert(format == ISL_FORMAT_R8G8B8A8_UNORM_SRGB ||
> > +  format == ISL_FORMAT_B8G8R8A8_UNORM_SRGB ||
> > +  format == ISL_FORMAT_B8G8R8X8_UNORM_SRGB);
> > +
> > +   /* According to do_single_blorp_clear(), fast-clears for
> texture-views are
> > +* disabled. This means that we only have to do channel-to-channel
> format
> > +* conversions.
> > +*/
> > +   union isl_color_value override_color = color;
> > +   for (unsigned i = 0; i < 3; i++)
> > +  override_color.f32[i] = util_format_srgb_to_linear_
> float(color.f32[i]);
> > +
> > +   return override_color;
> > +}
> > +
> >  /**
> >   * Convert the given color to a bitfield suitable for ORing into DWORD
> 7 of
> >   * SURFACE_STATE (DWORD 12-15 on SKL+).
> > diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.h
> b/src/mesa/drivers/dri/i965/brw_meta_util.h
> > index 4b3408df15..ee0b3bd3e1 100644
> > --- a/src/mesa/drivers/dri/i965/brw_meta_util.h
> > +++ b/src/mesa/drivers/dri/i965/brw_meta_util.h
> > @@ -42,6 +42,11 @@ brw_meta_mirror_clip_and_scissor(const struct
> gl_context *ctx,
> >   GLfloat *dstX1, GLfloat *dstY1,
> >   bool *mirror_x, bool *mirror_y);
> >
> > +union isl_color_value
> > +gen10_convert_srgb_fast_clear_color(const struct gen_device_info
> *devinfo,
> > +   

[Mesa-dev] [PATCH 0/2] docs/llvmpipe.html: Add PPC64LE

[Ben Crocker]

IBM PPC64LE (Power8, Power8NV, and Power9) are supported on an equal
footing with X86.

Ben Crocker (2):
  docs/llvmpipe.html: Add ppc64le as alternative architecture to x86.
  docs/llvmpipe.html: Minor edits

 docs/llvmpipe.html | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

-- 
2.13.6

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

Re: [Mesa-dev] [PATCH v2 2/2] i965/cnl: Correctly sample from fast-cleared sRGB textures

[Jason Ekstrand]

On Mon, Nov 27, 2017 at 11:41 AM, Nanley Chery 
wrote:

> On Mon, Nov 27, 2017 at 11:02:15AM -0800, Nanley Chery wrote:
> > When sampling from fast-cleared sRGB textures on gen10, the hardware
> > will not decode the clear color to linear. We must therefore do it in
> > software.
> >
> > This makes the following piglit tests pass:
> > * spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend
> > * spec@arb_framebuffer_srgb@fbo-fast-clear
> > * spec@arb_framebuffer_srgb@msaa-fast-clear
> > * spec@ext_texture_srgb@fbo-fast-clear
> > * spec@ext_texture_srgb@multisample-fast-clear gl_ext_texture_srgb
> >
> > v2 (Jason Ekstrand):
> > - Update some comments.
> > - Simplify assertions.
> > - Use an sRGB-to-linear helper.
> >
> > Signed-off-by: Nanley Chery 
> > ---
> >  src/mesa/drivers/dri/i965/brw_blorp.c|  7 +++
> >  src/mesa/drivers/dri/i965/brw_meta_util.c| 26
> 
> >  src/mesa/drivers/dri/i965/brw_meta_util.h|  5 +
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  9 +++-
> >  4 files changed, 46 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> > index 38284d3b85..b10e9b95b7 100644
> > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > @@ -328,6 +328,13 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
> > struct blorp_surf src_surf, dst_surf;
> > blorp_surf_for_miptree(brw, _surf, src_mt, src_aux_usage, false,
> >_level, src_layer, 1, _surfs[0]);
> > +   if (devinfo->gen >= 10 && isl_format_is_srgb(src_isl_format) &&
> > +   src_clear_supported) {
> > +  src_surf.clear_color =
> > + gen10_convert_srgb_fast_clear_color(devinfo, src_isl_format,
> > + src_mt->fast_clear_color);
> > +   }
> > +
> > blorp_surf_for_miptree(brw, _surf, dst_mt, dst_aux_usage, true,
> >_level, dst_layer, 1, _surfs[1]);
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c
> b/src/mesa/drivers/dri/i965/brw_meta_util.c
> > index d292f5a8e2..d1ce9d46ea 100644
> > --- a/src/mesa/drivers/dri/i965/brw_meta_util.c
> > +++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
> > @@ -315,6 +315,32 @@ brw_is_color_fast_clear_compatible(struct
> brw_context *brw,
> > return true;
> >  }
> >
> > +/* When sampling from fast-cleared sRGB textures on gen10, the hardware
> > + * will not decode the clear color to linear. We must therefore do it in
> > + * software.
> > + */
> > +union isl_color_value
> > +gen10_convert_srgb_fast_clear_color(const struct gen_device_info
> *devinfo,
> > +enum isl_format format,
> > +const union isl_color_value color)
> > +{
> > +   /* Gen10 supports fast-clearing three of GL's sRGB formats. */
> > +   assert(devinfo->gen >= 10);
> > +   assert(format == ISL_FORMAT_R8G8B8A8_UNORM_SRGB ||
> > +  format == ISL_FORMAT_B8G8R8A8_UNORM_SRGB ||
> > +  format == ISL_FORMAT_B8G8R8X8_UNORM_SRGB);
> > +
> > +   /* According to do_single_blorp_clear(), fast-clears for
> texture-views are
> > +* disabled. This means that we only have to do channel-to-channel
> format
> > +* conversions.
> > +*/
> > +   union isl_color_value override_color = color;
> > +   for (unsigned i = 0; i < 3; i++)
> > +  override_color.f32[i] = util_format_srgb_to_linear_
> float(color.f32[i]);
> > +
> > +   return override_color;
> > +}
> > +
> >  /**
> >   * Convert the given color to a bitfield suitable for ORing into DWORD
> 7 of
> >   * SURFACE_STATE (DWORD 12-15 on SKL+).
> > diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.h
> b/src/mesa/drivers/dri/i965/brw_meta_util.h
> > index 4b3408df15..ee0b3bd3e1 100644
> > --- a/src/mesa/drivers/dri/i965/brw_meta_util.h
> > +++ b/src/mesa/drivers/dri/i965/brw_meta_util.h
> > @@ -42,6 +42,11 @@ brw_meta_mirror_clip_and_scissor(const struct
> gl_context *ctx,
> >   GLfloat *dstX1, GLfloat *dstY1,
> >   bool *mirror_x, bool *mirror_y);
> >
> > +union isl_color_value
> > +gen10_convert_srgb_fast_clear_color(const struct gen_device_info
> *devinfo,
> > +enum isl_format format,
> > +const union isl_color_value color);
> > +
> >  union isl_color_value
> >  brw_meta_convert_fast_clear_color(const struct brw_context *brw,
> >const struct intel_mipmap_tree *mt,
> > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > index adf60a840b..315b96e9c4 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > @@ -51,6 +51,7 @@
> >  

Re: [Mesa-dev] [PATCH v2 2/2] i965/cnl: Correctly sample from fast-cleared sRGB textures

[Jason Ekstrand]

On Mon, Nov 27, 2017 at 11:02 AM, Nanley Chery 
wrote:

> When sampling from fast-cleared sRGB textures on gen10, the hardware
> will not decode the clear color to linear. We must therefore do it in
> software.
>
> This makes the following piglit tests pass:
> * spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend
> * spec@arb_framebuffer_srgb@fbo-fast-clear
> * spec@arb_framebuffer_srgb@msaa-fast-clear
> * spec@ext_texture_srgb@fbo-fast-clear
> * spec@ext_texture_srgb@multisample-fast-clear gl_ext_texture_srgb
>
> v2 (Jason Ekstrand):
> - Update some comments.
> - Simplify assertions.
> - Use an sRGB-to-linear helper.
>
> Signed-off-by: Nanley Chery 
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c|  7 +++
>  src/mesa/drivers/dri/i965/brw_meta_util.c| 26
> 
>  src/mesa/drivers/dri/i965/brw_meta_util.h|  5 +
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  9 +++-
>  4 files changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index 38284d3b85..b10e9b95b7 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -328,6 +328,13 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
> struct blorp_surf src_surf, dst_surf;
> blorp_surf_for_miptree(brw, _surf, src_mt, src_aux_usage, false,
>_level, src_layer, 1, _surfs[0]);
> +   if (devinfo->gen >= 10 && isl_format_is_srgb(src_isl_format) &&
> +   src_clear_supported) {
> +  src_surf.clear_color =
> + gen10_convert_srgb_fast_clear_color(devinfo, src_isl_format,
> + src_mt->fast_clear_color);
> +   }
>

Hrm... I don't think this is quite correct.  There are other places
(dst_surf here, partial slow clears, etc.) where we need a proper clear
color.  I think we want this code to go in blorp_surf_for_miptree so that
it gets properly handled in all the call sites.  Unfortunately, this
probably means that blorp_surf_for_miptree will have to take a view
format... and that will break blorp_copy...

Ugh.  This makes me want to resurrect my entire "store it as a pixel value"
series.

We may be able to get around this issue by defining a convention (probably
the gen9 one for now) and shoving it all into ISL.


> +
> blorp_surf_for_miptree(brw, _surf, dst_mt, dst_aux_usage, true,
>_level, dst_layer, 1, _surfs[1]);
>
> diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c
> b/src/mesa/drivers/dri/i965/brw_meta_util.c
> index d292f5a8e2..d1ce9d46ea 100644
> --- a/src/mesa/drivers/dri/i965/brw_meta_util.c
> +++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
> @@ -315,6 +315,32 @@ brw_is_color_fast_clear_compatible(struct
> brw_context *brw,
> return true;
>  }
>
> +/* When sampling from fast-cleared sRGB textures on gen10, the hardware
> + * will not decode the clear color to linear. We must therefore do it in
> + * software.
> + */
> +union isl_color_value
> +gen10_convert_srgb_fast_clear_color(const struct gen_device_info
> *devinfo,
> +enum isl_format format,
> +const union isl_color_value color)
> +{
> +   /* Gen10 supports fast-clearing three of GL's sRGB formats. */
> +   assert(devinfo->gen >= 10);
> +   assert(format == ISL_FORMAT_R8G8B8A8_UNORM_SRGB ||
> +  format == ISL_FORMAT_B8G8R8A8_UNORM_SRGB ||
> +  format == ISL_FORMAT_B8G8R8X8_UNORM_SRGB);
> +
> +   /* According to do_single_blorp_clear(), fast-clears for texture-views
> are
> +* disabled. This means that we only have to do channel-to-channel
> format
> +* conversions.
> +*/
> +   union isl_color_value override_color = color;
> +   for (unsigned i = 0; i < 3; i++)
> +  override_color.f32[i] = util_format_srgb_to_linear_
> float(color.f32[i]);
> +
> +   return override_color;
> +}
> +
>  /**
>   * Convert the given color to a bitfield suitable for ORing into DWORD 7
> of
>   * SURFACE_STATE (DWORD 12-15 on SKL+).
> diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.h
> b/src/mesa/drivers/dri/i965/brw_meta_util.h
> index 4b3408df15..ee0b3bd3e1 100644
> --- a/src/mesa/drivers/dri/i965/brw_meta_util.h
> +++ b/src/mesa/drivers/dri/i965/brw_meta_util.h
> @@ -42,6 +42,11 @@ brw_meta_mirror_clip_and_scissor(const struct
> gl_context *ctx,
>   GLfloat *dstX1, GLfloat *dstY1,
>   bool *mirror_x, bool *mirror_y);
>
> +union isl_color_value
> +gen10_convert_srgb_fast_clear_color(const struct gen_device_info
> *devinfo,
> +enum isl_format format,
> +const union isl_color_value color);
> +
>  union isl_color_value
>  brw_meta_convert_fast_clear_color(const struct brw_context *brw,
>  

Re: [Mesa-dev] [PATCH] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Rob Herring]

On Mon, Nov 27, 2017 at 8:14 AM, Robert Foss  wrote:
> From: Tomasz Figa 
>
> There is no API available to properly query the IMPLEMENTATION_DEFINED
> format. As a workaround we rely here on gralloc allocating either
> an arbitrary YCbCr 4:2:0 or RGBX_, with the latter being recognized
> by lock_ycbcr failing.
>
> Reviewed-on: https://chromium-review.googlesource.com/566793
>
> Signed-off-by: Tomasz Figa 
> Reviewed-by: Chad Versace 
> Signed-off-by: Robert Foss 
> ---
>  src/egl/drivers/dri2/platform_android.c | 39 
> +++--
>  1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 63223e9a69..ae914d79c1 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -59,6 +59,10 @@ static const struct droid_yuv_format droid_yuv_formats[] = 
> {
> { HAL_PIXEL_FORMAT_YCbCr_420_888,   0, 1, __DRI_IMAGE_FOURCC_YUV420 },
> { HAL_PIXEL_FORMAT_YCbCr_420_888,   1, 1, __DRI_IMAGE_FOURCC_YVU420 },
> { HAL_PIXEL_FORMAT_YV12,1, 1, __DRI_IMAGE_FOURCC_YVU420 },
> +   /* HACK: See droid_create_image_from_prime_fd() and b/32077885. */
> +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 2, 
> __DRI_IMAGE_FOURCC_NV12 },
> +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 1, 
> __DRI_IMAGE_FOURCC_YUV420 },
> +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   1, 1, 
> __DRI_IMAGE_FOURCC_YVU420 },
>  };
>
>  static int
> @@ -90,6 +94,11 @@ get_format_bpp(int native)
>
> switch (native) {
> case HAL_PIXEL_FORMAT_RGBA_:
> +   case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
> +  /*
> +   * HACK: Hardcode this to RGBX_ as per cros_gralloc hack.

Does this work with other grallocs?

> +   * TODO: Remove this once b/32077885 is fixed.

Is that a public bug? A full url would be better if so.

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

Re: [Mesa-dev] [PATCH v2 2/2] i965/cnl: Correctly sample from fast-cleared sRGB textures

[Nanley Chery]

On Mon, Nov 27, 2017 at 11:02:15AM -0800, Nanley Chery wrote:
> When sampling from fast-cleared sRGB textures on gen10, the hardware
> will not decode the clear color to linear. We must therefore do it in
> software.
> 
> This makes the following piglit tests pass:
> * spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend
> * spec@arb_framebuffer_srgb@fbo-fast-clear
> * spec@arb_framebuffer_srgb@msaa-fast-clear
> * spec@ext_texture_srgb@fbo-fast-clear
> * spec@ext_texture_srgb@multisample-fast-clear gl_ext_texture_srgb
> 
> v2 (Jason Ekstrand):
> - Update some comments.
> - Simplify assertions.
> - Use an sRGB-to-linear helper.
> 
> Signed-off-by: Nanley Chery 
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c|  7 +++
>  src/mesa/drivers/dri/i965/brw_meta_util.c| 26 
> 
>  src/mesa/drivers/dri/i965/brw_meta_util.h|  5 +
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  9 +++-
>  4 files changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index 38284d3b85..b10e9b95b7 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -328,6 +328,13 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
> struct blorp_surf src_surf, dst_surf;
> blorp_surf_for_miptree(brw, _surf, src_mt, src_aux_usage, false,
>_level, src_layer, 1, _surfs[0]);
> +   if (devinfo->gen >= 10 && isl_format_is_srgb(src_isl_format) &&
> +   src_clear_supported) {
> +  src_surf.clear_color =
> + gen10_convert_srgb_fast_clear_color(devinfo, src_isl_format,
> + src_mt->fast_clear_color);
> +   }
> +
> blorp_surf_for_miptree(brw, _surf, dst_mt, dst_aux_usage, true,
>_level, dst_layer, 1, _surfs[1]);
>  
> diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c 
> b/src/mesa/drivers/dri/i965/brw_meta_util.c
> index d292f5a8e2..d1ce9d46ea 100644
> --- a/src/mesa/drivers/dri/i965/brw_meta_util.c
> +++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
> @@ -315,6 +315,32 @@ brw_is_color_fast_clear_compatible(struct brw_context 
> *brw,
> return true;
>  }
>  
> +/* When sampling from fast-cleared sRGB textures on gen10, the hardware
> + * will not decode the clear color to linear. We must therefore do it in
> + * software.
> + */
> +union isl_color_value
> +gen10_convert_srgb_fast_clear_color(const struct gen_device_info *devinfo,
> +enum isl_format format,
> +const union isl_color_value color)
> +{
> +   /* Gen10 supports fast-clearing three of GL's sRGB formats. */
> +   assert(devinfo->gen >= 10);
> +   assert(format == ISL_FORMAT_R8G8B8A8_UNORM_SRGB ||
> +  format == ISL_FORMAT_B8G8R8A8_UNORM_SRGB ||
> +  format == ISL_FORMAT_B8G8R8X8_UNORM_SRGB);
> +
> +   /* According to do_single_blorp_clear(), fast-clears for texture-views are
> +* disabled. This means that we only have to do channel-to-channel format
> +* conversions.
> +*/
> +   union isl_color_value override_color = color;
> +   for (unsigned i = 0; i < 3; i++)
> +  override_color.f32[i] = util_format_srgb_to_linear_float(color.f32[i]);
> +
> +   return override_color;
> +}
> +
>  /**
>   * Convert the given color to a bitfield suitable for ORing into DWORD 7 of
>   * SURFACE_STATE (DWORD 12-15 on SKL+).
> diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.h 
> b/src/mesa/drivers/dri/i965/brw_meta_util.h
> index 4b3408df15..ee0b3bd3e1 100644
> --- a/src/mesa/drivers/dri/i965/brw_meta_util.h
> +++ b/src/mesa/drivers/dri/i965/brw_meta_util.h
> @@ -42,6 +42,11 @@ brw_meta_mirror_clip_and_scissor(const struct gl_context 
> *ctx,
>   GLfloat *dstX1, GLfloat *dstY1,
>   bool *mirror_x, bool *mirror_y);
>  
> +union isl_color_value
> +gen10_convert_srgb_fast_clear_color(const struct gen_device_info *devinfo,
> +enum isl_format format,
> +const union isl_color_value color);
> +
>  union isl_color_value
>  brw_meta_convert_fast_clear_color(const struct brw_context *brw,
>const struct intel_mipmap_tree *mt,
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index adf60a840b..315b96e9c4 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -51,6 +51,7 @@
>  #include "intel_buffer_objects.h"
>  
>  #include "brw_context.h"
> +#include "brw_meta_util.h"
>  #include "brw_state.h"
>  #include "brw_defines.h"
>  #include "brw_wm.h"
> @@ -174,7 +175,13 @@ brw_emit_surface_state(struct brw_context *brw,
>/* We only really need a 

Re: [Mesa-dev] [PATCH v2 2/2] i965/cnl: Correctly sample from fast-cleared sRGB textures

[Roland Scheidegger]

If you use a float input color, does it mean it isn't quantized?
I'm just wondering if you actually get (slightly) different values with
sampling from fast-cleared surfaces than you'd get when you'd have
cleared the surface normally.
In any case, patch 1/2 of this series looks alright (I was just
wondering why you needed it...), can't really review this one...

Roland


Am 27.11.2017 um 20:02 schrieb Nanley Chery:
> When sampling from fast-cleared sRGB textures on gen10, the hardware
> will not decode the clear color to linear. We must therefore do it in
> software.
> 
> This makes the following piglit tests pass:
> * spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend
> * spec@arb_framebuffer_srgb@fbo-fast-clear
> * spec@arb_framebuffer_srgb@msaa-fast-clear
> * spec@ext_texture_srgb@fbo-fast-clear
> * spec@ext_texture_srgb@multisample-fast-clear gl_ext_texture_srgb
> 
> v2 (Jason Ekstrand):
> - Update some comments.
> - Simplify assertions.
> - Use an sRGB-to-linear helper.
> 
> Signed-off-by: Nanley Chery 
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c|  7 +++
>  src/mesa/drivers/dri/i965/brw_meta_util.c| 26 
> 
>  src/mesa/drivers/dri/i965/brw_meta_util.h|  5 +
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  9 +++-
>  4 files changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index 38284d3b85..b10e9b95b7 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -328,6 +328,13 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
> struct blorp_surf src_surf, dst_surf;
> blorp_surf_for_miptree(brw, _surf, src_mt, src_aux_usage, false,
>_level, src_layer, 1, _surfs[0]);
> +   if (devinfo->gen >= 10 && isl_format_is_srgb(src_isl_format) &&
> +   src_clear_supported) {
> +  src_surf.clear_color =
> + gen10_convert_srgb_fast_clear_color(devinfo, src_isl_format,
> + src_mt->fast_clear_color);
> +   }
> +
> blorp_surf_for_miptree(brw, _surf, dst_mt, dst_aux_usage, true,
>_level, dst_layer, 1, _surfs[1]);
>  
> diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c 
> b/src/mesa/drivers/dri/i965/brw_meta_util.c
> index d292f5a8e2..d1ce9d46ea 100644
> --- a/src/mesa/drivers/dri/i965/brw_meta_util.c
> +++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
> @@ -315,6 +315,32 @@ brw_is_color_fast_clear_compatible(struct brw_context 
> *brw,
> return true;
>  }
>  
> +/* When sampling from fast-cleared sRGB textures on gen10, the hardware
> + * will not decode the clear color to linear. We must therefore do it in
> + * software.
> + */
> +union isl_color_value
> +gen10_convert_srgb_fast_clear_color(const struct gen_device_info *devinfo,
> +enum isl_format format,
> +const union isl_color_value color)
> +{
> +   /* Gen10 supports fast-clearing three of GL's sRGB formats. */
> +   assert(devinfo->gen >= 10);
> +   assert(format == ISL_FORMAT_R8G8B8A8_UNORM_SRGB ||
> +  format == ISL_FORMAT_B8G8R8A8_UNORM_SRGB ||
> +  format == ISL_FORMAT_B8G8R8X8_UNORM_SRGB);
> +
> +   /* According to do_single_blorp_clear(), fast-clears for texture-views are
> +* disabled. This means that we only have to do channel-to-channel format
> +* conversions.
> +*/
> +   union isl_color_value override_color = color;
> +   for (unsigned i = 0; i < 3; i++)
> +  override_color.f32[i] = util_format_srgb_to_linear_float(color.f32[i]);
> +
> +   return override_color;
> +}
> +
>  /**
>   * Convert the given color to a bitfield suitable for ORing into DWORD 7 of
>   * SURFACE_STATE (DWORD 12-15 on SKL+).
> diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.h 
> b/src/mesa/drivers/dri/i965/brw_meta_util.h
> index 4b3408df15..ee0b3bd3e1 100644
> --- a/src/mesa/drivers/dri/i965/brw_meta_util.h
> +++ b/src/mesa/drivers/dri/i965/brw_meta_util.h
> @@ -42,6 +42,11 @@ brw_meta_mirror_clip_and_scissor(const struct gl_context 
> *ctx,
>   GLfloat *dstX1, GLfloat *dstY1,
>   bool *mirror_x, bool *mirror_y);
>  
> +union isl_color_value
> +gen10_convert_srgb_fast_clear_color(const struct gen_device_info *devinfo,
> +enum isl_format format,
> +const union isl_color_value color);
> +
>  union isl_color_value
>  brw_meta_convert_fast_clear_color(const struct brw_context *brw,
>const struct intel_mipmap_tree *mt,
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index adf60a840b..315b96e9c4 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ 

[Mesa-dev] [PATCH] Android: disable warnings causing errors

[Rob Herring]

AOSP master has changed the build default to -Werror making all the
warnings errors. Override that with -Wno-error.

Signed-off-by: Rob Herring 
---
 Android.common.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Android.common.mk b/Android.common.mk
index 5671c1c1a595..fcd9a874d538 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -31,6 +31,7 @@ LOCAL_C_INCLUDES += \
 
 MESA_VERSION := $(shell cat $(MESA_TOP)/VERSION)
 LOCAL_CFLAGS += \
+   -Wno-error \
-Wno-unused-parameter \
-Wno-pointer-arith \
-Wno-missing-field-initializers \
-- 
2.14.1

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

Re: [Mesa-dev] i965: Kicking off fp16 glsl support

[Matt Turner]

1-14, except 4 are

Reviewed-by: Matt Turner 

I started getting to things that made me realize I needed to review
Igalia's work before I continued here.


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

[Mesa-dev] [PATCH v2 2/2] i965/cnl: Correctly sample from fast-cleared sRGB textures

[Nanley Chery]

When sampling from fast-cleared sRGB textures on gen10, the hardware
will not decode the clear color to linear. We must therefore do it in
software.

This makes the following piglit tests pass:
* spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend
* spec@arb_framebuffer_srgb@fbo-fast-clear
* spec@arb_framebuffer_srgb@msaa-fast-clear
* spec@ext_texture_srgb@fbo-fast-clear
* spec@ext_texture_srgb@multisample-fast-clear gl_ext_texture_srgb

v2 (Jason Ekstrand):
- Update some comments.
- Simplify assertions.
- Use an sRGB-to-linear helper.

Signed-off-by: Nanley Chery 
---
 src/mesa/drivers/dri/i965/brw_blorp.c|  7 +++
 src/mesa/drivers/dri/i965/brw_meta_util.c| 26 
 src/mesa/drivers/dri/i965/brw_meta_util.h|  5 +
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  9 +++-
 4 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 38284d3b85..b10e9b95b7 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -328,6 +328,13 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
struct blorp_surf src_surf, dst_surf;
blorp_surf_for_miptree(brw, _surf, src_mt, src_aux_usage, false,
   _level, src_layer, 1, _surfs[0]);
+   if (devinfo->gen >= 10 && isl_format_is_srgb(src_isl_format) &&
+   src_clear_supported) {
+  src_surf.clear_color =
+ gen10_convert_srgb_fast_clear_color(devinfo, src_isl_format,
+ src_mt->fast_clear_color);
+   }
+
blorp_surf_for_miptree(brw, _surf, dst_mt, dst_aux_usage, true,
   _level, dst_layer, 1, _surfs[1]);
 
diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c 
b/src/mesa/drivers/dri/i965/brw_meta_util.c
index d292f5a8e2..d1ce9d46ea 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_util.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
@@ -315,6 +315,32 @@ brw_is_color_fast_clear_compatible(struct brw_context *brw,
return true;
 }
 
+/* When sampling from fast-cleared sRGB textures on gen10, the hardware
+ * will not decode the clear color to linear. We must therefore do it in
+ * software.
+ */
+union isl_color_value
+gen10_convert_srgb_fast_clear_color(const struct gen_device_info *devinfo,
+enum isl_format format,
+const union isl_color_value color)
+{
+   /* Gen10 supports fast-clearing three of GL's sRGB formats. */
+   assert(devinfo->gen >= 10);
+   assert(format == ISL_FORMAT_R8G8B8A8_UNORM_SRGB ||
+  format == ISL_FORMAT_B8G8R8A8_UNORM_SRGB ||
+  format == ISL_FORMAT_B8G8R8X8_UNORM_SRGB);
+
+   /* According to do_single_blorp_clear(), fast-clears for texture-views are
+* disabled. This means that we only have to do channel-to-channel format
+* conversions.
+*/
+   union isl_color_value override_color = color;
+   for (unsigned i = 0; i < 3; i++)
+  override_color.f32[i] = util_format_srgb_to_linear_float(color.f32[i]);
+
+   return override_color;
+}
+
 /**
  * Convert the given color to a bitfield suitable for ORing into DWORD 7 of
  * SURFACE_STATE (DWORD 12-15 on SKL+).
diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.h 
b/src/mesa/drivers/dri/i965/brw_meta_util.h
index 4b3408df15..ee0b3bd3e1 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_util.h
+++ b/src/mesa/drivers/dri/i965/brw_meta_util.h
@@ -42,6 +42,11 @@ brw_meta_mirror_clip_and_scissor(const struct gl_context 
*ctx,
  GLfloat *dstX1, GLfloat *dstY1,
  bool *mirror_x, bool *mirror_y);
 
+union isl_color_value
+gen10_convert_srgb_fast_clear_color(const struct gen_device_info *devinfo,
+enum isl_format format,
+const union isl_color_value color);
+
 union isl_color_value
 brw_meta_convert_fast_clear_color(const struct brw_context *brw,
   const struct intel_mipmap_tree *mt,
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index adf60a840b..315b96e9c4 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -51,6 +51,7 @@
 #include "intel_buffer_objects.h"
 
 #include "brw_context.h"
+#include "brw_meta_util.h"
 #include "brw_state.h"
 #include "brw_defines.h"
 #include "brw_wm.h"
@@ -174,7 +175,13 @@ brw_emit_surface_state(struct brw_context *brw,
   /* We only really need a clear color if we also have an auxiliary
* surface.  Without one, it does nothing.
*/
-  clear_color = mt->fast_clear_color;
+  if (devinfo->gen >= 10 && isl_format_is_srgb(view.format)) {
+ clear_color =
+gen10_convert_srgb_fast_clear_color(devinfo, 

[Mesa-dev] [PATCH v2 1/2] util/srgb: Add a float sRGB -> linear helper

[Nanley Chery]

From: Jason Ekstrand 

Reviewed-by: Nanley Chery 
---
 src/util/format_srgb.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/util/format_srgb.h b/src/util/format_srgb.h
index 34b50afe3d..596af56f4c 100644
--- a/src/util/format_srgb.h
+++ b/src/util/format_srgb.h
@@ -54,6 +54,20 @@ extern const unsigned
 util_format_linear_to_srgb_helper_table[104];
 
 
+static inline float
+util_format_srgb_to_linear_float(float cs)
+{
+   if (cs <= 0.0f)
+  return 0.0f;
+   else if (cs <= 0.04045f)
+  return cs / 12.92f;
+   else if (cs < 1.0f)
+  return powf((cs + 0.055) / 1.055f, 2.4f);
+   else
+  return 1.0f;
+}
+
+
 static inline float
 util_format_linear_to_srgb_float(float cl)
 {
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH 10/51] glsl: Allow 16-bit math

[Matt Turner]

On 11/24, Topi Pohjolainen wrote:

Signed-off-by: Topi Pohjolainen 
---
src/compiler/glsl/ir_validate.cpp | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/ir_validate.cpp 
b/src/compiler/glsl/ir_validate.cpp
index 735e862141..d246af866d 100644
--- a/src/compiler/glsl/ir_validate.cpp
+++ b/src/compiler/glsl/ir_validate.cpp
@@ -272,7 +272,8 @@ ir_validate::visit_leave(ir_expression *ir)
   case ir_unop_rsq:
   case ir_unop_sqrt:
  assert(ir->type->is_float() ||
- ir->type->is_double());
+ ir->type->is_double() ||
+ ir->type->base_type == GLSL_TYPE_FLOAT16);
  assert(ir->type == ir->operands[0]->type);
  break;

@@ -281,7 +282,9 @@ ir_validate::visit_leave(ir_expression *ir)
   case ir_unop_exp2:
   case ir_unop_log2:
   case ir_unop_saturate:
-  assert(ir->operands[0]->type->is_float());
+  assert(ir->operands[0]->type->is_float() ||
+ (ir->operands[0]->type->get_scalar_type()->base_type ==
+  GLSL_TYPE_FLOAT16));


Same comment about is_half_float()


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

Re: [Mesa-dev] [PATCH 09/51] glsl: Allow 16-bit neg() and dot()

[Matt Turner]

On 11/24, Topi Pohjolainen wrote:

Signed-off-by: Topi Pohjolainen 
---
src/compiler/glsl/ir_validate.cpp | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/compiler/glsl/ir_validate.cpp 
b/src/compiler/glsl/ir_validate.cpp
index a20f52e527..735e862141 100644
--- a/src/compiler/glsl/ir_validate.cpp
+++ b/src/compiler/glsl/ir_validate.cpp
@@ -263,7 +263,8 @@ ir_validate::visit_leave(ir_expression *ir)
  assert(ir->operands[0]->type->base_type == GLSL_TYPE_INT ||
 ir->operands[0]->type->is_float() ||
 ir->operands[0]->type->is_double() ||
- ir->operands[0]->type->base_type == GLSL_TYPE_INT64);
+ ir->operands[0]->type->base_type == GLSL_TYPE_INT64 ||
+ ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT16);
  assert(ir->type == ir->operands[0]->type);
  break;

@@ -742,9 +743,11 @@ ir_validate::visit_leave(ir_expression *ir)

   case ir_binop_dot:
  assert(ir->type == glsl_type::float_type ||
- ir->type == glsl_type::double_type);
+ ir->type == glsl_type::double_type ||
+ ir->type->base_type == GLSL_TYPE_FLOAT16);
  assert(ir->operands[0]->type->is_float() ||
- ir->operands[0]->type->is_double());
+ ir->operands[0]->type->is_double() ||
+ ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT16);


I think we should have an is_half_float() function since already have
is_float/is_double.


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

Re: [Mesa-dev] [PATCH mesa 16/16] util: use NDEBUG to guard asserts

[Dylan Baker]

Quoting Eric Engestrom (2017-11-27 09:46:57)
> On Saturday, 2017-11-25 18:45:14 +0100, Gert Wollny wrote:
> > Am Freitag, den 24.11.2017, 18:07 + schrieb Eric Engestrom:
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > >  src/util/ralloc.c | 18 +-
> > >  src/util/slab.c   |  4 ++--
> > >  2 files changed, 11 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/src/util/ralloc.c b/src/util/ralloc.c
> > > index 42cfa2e391d52df68db2..b52079ac075a0fe11944 100644
> > > --- a/src/util/ralloc.c
> > > +++ b/src/util/ralloc.c
> > > @@ -61,7 +61,7 @@ struct
> > >  #endif
> > > ralloc_header
> > >  {
> > > -#ifdef DEBUG
> > > +#ifndef NDEBUG
> > > /* A canary value used to determine whether a pointer is
> > > ralloc'd. */
> > > unsigned canary;
> > >  #endif
> > > @@ -88,7 +88,7 @@ get_header(const void *ptr)
> > >  {
> > > ralloc_header *info = (ralloc_header *) (((char *) ptr) -
> > >     sizeof(ralloc_header));
> > > -#ifdef DEBUG
> > > +#ifndef NDEBUG
> > > assert(info->canary == CANARY);
> > >  #endif
> > 
> > With NDEBUG defined "assert" already translates to a no-op, hence the
> > extra "#ifndef NDEBUG" block is not needed (same for the other asserts
> > below and in the other patches). 
> 
> Indeed, I did so many of those conversions that I wasn't thinking about
> that anymore. Thanks for catching that, I'll remove the include guards
> altogether around plain asserts()s.

Is that true in this case? info->canary is only defined if NDEBUG is not
defined, so this will fail to compile since those symbols are undefined, right?

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] [PATCH 07/51] glsl: Add conversion ops to/from 16-bit floats

[Matt Turner]

On 11/24, Topi Pohjolainen wrote:

Signed-off-by: Topi Pohjolainen 
---
src/compiler/glsl/glsl_to_nir.cpp| 2 ++
src/compiler/glsl/ir.cpp | 8 
src/compiler/glsl/ir_expression_operation.py | 5 +
src/compiler/glsl/ir_validate.cpp| 8 
src/mesa/program/ir_to_mesa.cpp  | 2 ++
src/mesa/state_tracker/st_glsl_to_tgsi.cpp   | 3 +++
6 files changed, 28 insertions(+)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index 289f8be031..14c358465b 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -1561,6 +1561,8 @@ nir_visitor::visit(ir_expression *ir)
   case ir_unop_d2b:
   case ir_unop_i2d:
   case ir_unop_u2d:
+   case ir_unop_h2f:
+   case ir_unop_f2h:
   case ir_unop_i642i:
   case ir_unop_i642u:
   case ir_unop_i642f:
diff --git a/src/compiler/glsl/ir.cpp b/src/compiler/glsl/ir.cpp
index 2c61dd9d64..a901ec5683 100644
--- a/src/compiler/glsl/ir.cpp
+++ b/src/compiler/glsl/ir.cpp
@@ -281,6 +281,7 @@ ir_expression::ir_expression(int op, ir_rvalue *op0)
   case ir_unop_i2f:
   case ir_unop_u2f:
   case ir_unop_d2f:
+   case ir_unop_h2f:
   case ir_unop_bitcast_i2f:
   case ir_unop_bitcast_u2f:
   case ir_unop_i642f:
@@ -334,6 +335,13 @@ ir_expression::ir_expression(int op, ir_rvalue *op0)
  this->type = glsl_type::get_instance(GLSL_TYPE_UINT64,
   op0->type->vector_elements, 1);
  break;
+
+   case ir_unop_f2h:
+  this->type = glsl_type::get_instance(GLSL_TYPE_FLOAT16,
+  op0->type->vector_elements, 1);


Tabs on this line.


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

Re: [Mesa-dev] [PATCH 01/51] nir: Prepare constant folding for 16-bits

[Pohjolainen, Topi]

On Mon, Nov 27, 2017 at 11:42:53AM -0800, Matt Turner wrote:
> On 11/24, Topi Pohjolainen wrote:
> > Signed-off-by: Topi Pohjolainen 
> > ---
> > src/compiler/nir/nir_opt_constant_folding.c | 2 ++
> > 1 file changed, 2 insertions(+)
> > 
> > diff --git a/src/compiler/nir/nir_opt_constant_folding.c 
> > b/src/compiler/nir/nir_opt_constant_folding.c
> > index d6be807b3d..b63660ea4d 100644
> > --- a/src/compiler/nir/nir_opt_constant_folding.c
> > +++ b/src/compiler/nir/nir_opt_constant_folding.c
> > @@ -78,6 +78,8 @@ constant_fold_alu_instr(nir_alu_instr *instr, void 
> > *mem_ctx)
> >j++) {
> >  if (load_const->def.bit_size == 64)
> > src[i].u64[j] = load_const->value.u64[instr->src[i].swizzle[j]];
> > + else if (load_const->def.bit_size == 16)
> > +src[i].u16[j] = 
> > load_const->value.u16[instr->src[i].swizzle[j]];
> >  else
> > src[i].u32[j] = load_const->value.u32[instr->src[i].swizzle[j]];
> 
> I dislike that we handle 64-bit, 16-bit, and 32-bit in that order, but
> it's not a big deal.

Ah, right. I tried to keep the diff as small as possible and didn't pay
attention to what the code looks like. I agree.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] meson: add Wundef to the build flags

[Dylan Baker]

Quoting Dylan Baker (2017-11-27 10:40:18)
> Although now that I think about it, meson does have a b_undef option, so
> actually the right way to do this is to add
> 'b_undef=true' to the default options in the project() call.
> 
> Sorry for the confusion,
> 
> Dylan
> 

And I can't read documentation apparently. My original rb stands, please ignore
the above.

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] [PATCH 04/51] glsl: Print 16-bit constants

[Pohjolainen, Topi]

On Mon, Nov 27, 2017 at 11:40:49AM -0800, Matt Turner wrote:
> On 11/24, Topi Pohjolainen wrote:
> > ---
> > src/compiler/glsl/ir_print_visitor.cpp | 1 +
> > 1 file changed, 1 insertion(+)
> > 
> > diff --git a/src/compiler/glsl/ir_print_visitor.cpp 
> > b/src/compiler/glsl/ir_print_visitor.cpp
> > index ea14cdeb6c..ab9a35d73f 100644
> > --- a/src/compiler/glsl/ir_print_visitor.cpp
> > +++ b/src/compiler/glsl/ir_print_visitor.cpp
> > @@ -482,6 +482,7 @@ void ir_print_visitor::visit(ir_constant *ir)
> >  case GLSL_TYPE_UINT:  fprintf(f, "%u", ir->value.u[i]); break;
> >  case GLSL_TYPE_INT:   fprintf(f, "%d", ir->value.i[i]); break;
> >  case GLSL_TYPE_FLOAT:
> > +case GLSL_TYPE_FLOAT16:
> 
> Are fp16 values stored as 32-bit floats in ir->value.f[]? That seems
> surprising.

Right. This needs more thought I guess. In the GLSL lowering pass I'm only
changing types at the moment and the conversion of constants from 32-bits
to 16-bits later in GLSL -> NIR. See patch:

glsl: Add support for 16-bit float constants in nir-conversion

> 
> > if (ir->value.f[i] == 0.0f)
> >/* 0.0 == -0.0, so print with %f to get the proper sign. */
> >fprintf(f, "%f", ir->value.f[i]);
> > -- 
> > 2.11.0
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH mesa 02/16] anv: tie anv_assert() enablement to regular assert()

[Eric Engestrom]

On Sunday, 2017-11-26 10:12:46 +1100, Timothy Arceri wrote:
> On 25/11/17 08:02, Timothy Arceri wrote:
> > On 25/11/17 05:07, Eric Engestrom wrote:
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > >   src/intel/vulkan/anv_private.h | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/src/intel/vulkan/anv_private.h
> > > b/src/intel/vulkan/anv_private.h
> > > index 6d4e43f2e687cbf26ccd..6474abf0f3694c7fcd3a 100644
> > > --- a/src/intel/vulkan/anv_private.h
> > > +++ b/src/intel/vulkan/anv_private.h
> > > @@ -382,7 +382,7 @@ void anv_debug_report(struct anv_instance *instance,
> > >  } while (0)
> > >   /* A non-fatal assert.  Useful for debugging. */
> > > -#ifdef DEBUG
> > > +#ifndef NDEBUG
> > 
> > I'm confused by all these assert patches. Doesn't NDEBUG mean no debug
> > or non-debug why are you switching things around? Won't this add all
> > this code to release builds and remove it from debug builds?
> 
> Oh you are using ifndef, I still don't get what you are trying to do with
> these patches. Can you please explain?

Like the title says, the point is to align the behaviour of our various
custom asserts with the standard asserts.
Having them behave differently (read: be enabled or disabled
asynchronously) can only lead to confusion, and possibly breakages.

(Try to compile a debug build with asserts off or a release build with
asserts on without patch 12/16 "compiler: use NDEBUG to guard asserts",
for instance. Although to be fair, that's the only actual breakage I've
seen so far.)

This confusion was caused by our autoconf script defining NDEBUG when
DEBUG wasn't defined, which lead some people to believe these are
interchangeable and/or always tied to each other, but this isn't true
with other build systems, such as meson.

> 
> > 
> > 
> > >   #define anv_assert(x) ({ \
> > >  if (unlikely(!(x))) \
> > >     intel_loge("%s:%d ASSERT: %s", __FILE__, __LINE__, #x); \
> > > 
> > ___
> > 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/5] meson: add Wundef to the build flags

[Dylan Baker]

Although now that I think about it, meson does have a b_undef option, so
actually the right way to do this is to add
'b_undef=true' to the default options in the project() call.

Sorry for the confusion,

Dylan

Quoting Dylan Baker (2017-11-27 10:22:40)
> This seems reasonable,
> Reviewed-by: Dylan Baker 
> 
> Quoting Emil Velikov (2017-11-24 06:25:03)
> > From: Emil Velikov 
> > 
> > Analogous to the other build systems.
> > 
> > Cc: Eric Engestrom 
> > Cc: Dylan Baker 
> > Signed-off-by: Emil Velikov 
> > ---
> >  meson.build | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index 53013e47ec4..2e704e18c93 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -468,7 +468,7 @@ endif
> >  
> >  # Check for generic C arguments
> >  c_args = []
> > -foreach a : ['-Wall', '-Werror=implicit-function-declaration',
> > +foreach a : ['-Wall', '-Wundef', '-Werror=implicit-function-declaration',
> >   '-Werror=missing-prototypes', '-fno-math-errno',
> >   '-fno-trapping-math', '-Qunused-arguments']
> >if cc.has_argument(a)
> > @@ -483,7 +483,7 @@ endif
> >  # Check for generic C++ arguments
> >  cpp = meson.get_compiler('cpp')
> >  cpp_args = []
> > -foreach a : ['-Wall', '-fno-math-errno', '-fno-trapping-math',
> > +foreach a : ['-Wall', '-Wundef', '-fno-math-errno', '-fno-trapping-math',
> >   '-Qunused-arguments', '-Wno-non-virtual-dtor']
> >if cpp.has_argument(a)
> >  cpp_args += a
> > -- 
> > 2.14.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

Re: [Mesa-dev] [PATCH 0/7] [RFC] meson: build src/glx/windows

[Dylan Baker]

I had a few comments on the "build src/glx/windows" patch, but the rest of the
patches are:
Reviewed-by: Dylan Baker 

Quoting Jon Turney (2017-11-27 05:58:27)
> This series lets me build a mesa for Cygwin configured with:
> 
>  -Ddri-drivers=swrast -Dgallium-drivers= -Dplatforms=x11,surfaceless 
> -Dglx=dri -Dvulkan-drivers= 
> 
> I'm really not sure about (2/8), the autotools build does something totally 
> different...
> 
> Dylan Baker (2):
>   meson: fix generated source inclusion on macOS and Windows
>   meson: Don't build egl on macOS or Windows
> 
> Jon Turney (5):
>   meson: set windows glx defines
>   meson: set _GNU_SOURCE on cygwin
>   meson: build src/glx/windows
>   meson: don't require dri2proto for darwin or windows
>   meson: fix deps and underlinkage of libGL
> 
>  meson.build | 19 +-
>  src/glx/meson.build | 26 ++--
>  src/glx/windows/meson.build | 48 
> +
>  src/mapi/glapi/meson.build  |  2 +-
>  4 files changed, 79 insertions(+), 16 deletions(-)
>  create mode 100644 src/glx/windows/meson.build
> 
> -- 
> 2.15.0
> 


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 5/7] meson: build src/glx/windows

[Dylan Baker]

Quoting Jon Turney (2017-11-27 05:58:32)
> ---
>  src/glx/meson.build | 25 +--
>  src/glx/windows/meson.build | 48 
> +
>  2 files changed, 63 insertions(+), 10 deletions(-)
>  create mode 100644 src/glx/windows/meson.build
> 
> diff --git a/src/glx/meson.build b/src/glx/meson.build
> index deef3ed2235..a7eb48a0069 100644
> --- a/src/glx/meson.build
> +++ b/src/glx/meson.build
> @@ -18,8 +18,7 @@
>  # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
> THE
>  # SOFTWARE.
>  
> -# TODO: 
> -#subdir('windows')
> +subdir('windows')
>  
>  files_libglx = files(
>'clientattrib.c',
> @@ -63,6 +62,8 @@ files_libglx = files(
>  )
>  
>  extra_libs_libglx = []
> +extra_deps_libgl = []
> +extra_ld_args_libgl = []
>  
>  if with_dri
>files_libglx += files(
> @@ -99,11 +100,15 @@ if with_dri_platform == 'apple'
>files_libglx += files('applegl_glx.c')
>  elif with_dri_platform == 'windows'
>files_libglx += files('driwindows_glx.c')
> -  # TODO
> -  #extra_libs_libglx += [
> -#libwindowsdri,
> -#libwindowsglx,
> -  #]
> +  extra_libs_libglx += [
> +libwindowsdri,
> +libwindowsglx,
> +  ]
> +  extra_deps_libgl = [
> +meson.get_compiler('c').find_library('gdi32'),
> +meson.get_compiler('c').find_library('opengl32')

You should (though I haven't tested), be able to replace the last call with:
dependency('opengl')

(There is code for this in meson, but there's a lot of TODO's around it).

> +  ]
> +  extra_ld_args_libgl = '-Wl,--disable-stdcall-fixup'
>  endif
>  
>  dri_driver_dir = join_paths(get_option('prefix'), dri_drivers_path)
> @@ -139,7 +144,7 @@ libglx = static_library(
>],
>c_args : [c_vis_args, gl_lib_cargs,
>  '-DGL_LIB_NAME="lib@0@.so.@1@"'.format(gl_lib_name, 
> gl_lib_version.split('.')[0])],
> -  link_with : [libloader, libloader_dri3_helper, libmesa_util, libxmlconfig],
> +  link_with : [libloader, libloader_dri3_helper, libmesa_util, libxmlconfig, 
> extra_libs_libglx],
>dependencies : [dep_libdrm, dep_dri2proto, dep_glproto, dep_x11, 
> dep_glvnd],
>build_by_default : false,
>  )
> @@ -161,9 +166,9 @@ if with_glx == 'dri'
>  ],
>  link_with : [libglapi_static, libglapi],
>  link_whole : libglx,
> -link_args : [ld_args_bsymbolic, ld_args_gc_sections],
> +link_args : [ld_args_bsymbolic, ld_args_gc_sections, 
> extra_ld_args_libgl],
>  dependencies : [dep_libdrm, dep_dl, dep_m, dep_thread, dep_x11,
> -dep_xcb_dri2, dep_xcb_dri3],
> +dep_xcb_dri2, dep_xcb_dri3, extra_deps_libgl],
>  version : gl_lib_version,
>  install : true,
>)
> diff --git a/src/glx/windows/meson.build b/src/glx/windows/meson.build
> new file mode 100644
> index 000..1e66094b4ba
> --- /dev/null
> +++ b/src/glx/windows/meson.build
> @@ -0,0 +1,48 @@

Even if you don't care about the Copyright line, could you add the MIT text at
the top?

> +# protocol defines for the Windows-DRI server extension
> +
> +files_windowsdriproto = files(
> + 'windowsdriconst.h',
> + 'windowsdristr.h',
> + )
> +
> +install_headers(
> +  files_windowsdriproto,
> +  subdir: 'X11/extensions',
> +)
> +
> +pkg.generate(
> +  name : 'windowsdriproto',
> +  description : 'Windows-DRI extension headers',
> +  version : '1.0.0',
> +)
> +
> +# library for using the Windows-DRI server extension
> +files_libwindowsdri = files(
> +  'xwindowsdri.c',
> +  'xwindowsdri.h',
> +)
> +
> +libwindowsdri = static_library(
> +  'driwindows',
> +  [ files_libwindowsdri, files_windowsdriproto],
  ^ extra whitespace

> +  dependencies: dep_xext,
> +  build_by_default: false,
> +)
> +
> +# library for native GL on windows
> +files_libwindowsglx = files(
> +  'windowsgl.c',
> +  'windowsgl.h',
> +  'windowsgl_internal.h',
> +  'windows_drawable.c',
> +  'wgl.c',
> +  'wgl.h',
> +)
> +
> +libwindowsglx = static_library(
> +  'glxwindows',
> +  [ files_libwindowsglx, files_windowsdriproto],
  ^ here too

> +  include_directories: [inc_include, inc_src, inc_glapi],
> +  c_args : [c_vis_args],
> +  build_by_default: false,
> +)
> -- 
> 2.15.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

Re: [Mesa-dev] [PATCH 01/51] nir: Prepare constant folding for 16-bits

[Matt Turner]

On 11/24, Topi Pohjolainen wrote:

Signed-off-by: Topi Pohjolainen 
---
src/compiler/nir/nir_opt_constant_folding.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/src/compiler/nir/nir_opt_constant_folding.c 
b/src/compiler/nir/nir_opt_constant_folding.c
index d6be807b3d..b63660ea4d 100644
--- a/src/compiler/nir/nir_opt_constant_folding.c
+++ b/src/compiler/nir/nir_opt_constant_folding.c
@@ -78,6 +78,8 @@ constant_fold_alu_instr(nir_alu_instr *instr, void *mem_ctx)
   j++) {
 if (load_const->def.bit_size == 64)
src[i].u64[j] = load_const->value.u64[instr->src[i].swizzle[j]];
+ else if (load_const->def.bit_size == 16)
+src[i].u16[j] = load_const->value.u16[instr->src[i].swizzle[j]];
 else
src[i].u32[j] = load_const->value.u32[instr->src[i].swizzle[j]];


I dislike that we handle 64-bit, 16-bit, and 32-bit in that order, but
it's not a big deal.


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

Re: [Mesa-dev] [PATCH 04/51] glsl: Print 16-bit constants

[Matt Turner]

On 11/24, Topi Pohjolainen wrote:

---
src/compiler/glsl/ir_print_visitor.cpp | 1 +
1 file changed, 1 insertion(+)

diff --git a/src/compiler/glsl/ir_print_visitor.cpp 
b/src/compiler/glsl/ir_print_visitor.cpp
index ea14cdeb6c..ab9a35d73f 100644
--- a/src/compiler/glsl/ir_print_visitor.cpp
+++ b/src/compiler/glsl/ir_print_visitor.cpp
@@ -482,6 +482,7 @@ void ir_print_visitor::visit(ir_constant *ir)
 case GLSL_TYPE_UINT:  fprintf(f, "%u", ir->value.u[i]); break;
 case GLSL_TYPE_INT:   fprintf(f, "%d", ir->value.i[i]); break;
 case GLSL_TYPE_FLOAT:
+case GLSL_TYPE_FLOAT16:


Are fp16 values stored as 32-bit floats in ir->value.f[]? That seems
surprising.


if (ir->value.f[i] == 0.0f)
   /* 0.0 == -0.0, so print with %f to get the proper sign. */
   fprintf(f, "%f", ir->value.f[i]);
--
2.11.0

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


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