date:20190111

Re: [Mesa-dev] [PATCH] st/dri: fix dri2_format_table for argb1555 and rgb565

2019-01-11 Thread Kristian Høgsberg

Reviewed-by: Kristian H. Kristensen 

On Fri, Jan 11, 2019 at 3:19 PM Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> The bug caused that rgb565 framebuffers used argb1555.
>
> Fixes: 433ca3127a3b94bfe9a513e7c7ce594e09e1359f
> ---
>  src/gallium/state_trackers/dri/dri2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 6fc07e42f74..ebbbabb6492 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -85,21 +85,21 @@ static const struct dri2_format_mapping 
> dri2_format_table[] = {
>{ __DRI_IMAGE_FOURCC_ARGB,  __DRI_IMAGE_FORMAT_ARGB,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_BGRA_UNORM },
>{ __DRI_IMAGE_FOURCC_ABGR,  __DRI_IMAGE_FORMAT_ABGR,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_RGBA_UNORM },
>{ __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_FORMAT_SARGB8,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_BGRA_SRGB },
>{ __DRI_IMAGE_FOURCC_XRGB,  __DRI_IMAGE_FORMAT_XRGB,
>  __DRI_IMAGE_COMPONENTS_RGB,   PIPE_FORMAT_BGRX_UNORM },
>{ __DRI_IMAGE_FOURCC_XBGR,  __DRI_IMAGE_FORMAT_XBGR,
>  __DRI_IMAGE_COMPONENTS_RGB,   PIPE_FORMAT_RGBX_UNORM },
> -  { __DRI_IMAGE_FOURCC_ARGB1555,  __DRI_IMAGE_FORMAT_RGB565,
> +  { __DRI_IMAGE_FOURCC_ARGB1555,  __DRI_IMAGE_FORMAT_ARGB1555,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_B5G5R5A1_UNORM },
>{ __DRI_IMAGE_FOURCC_RGB565,__DRI_IMAGE_FORMAT_RGB565,
>  __DRI_IMAGE_COMPONENTS_RGB,   PIPE_FORMAT_B5G6R5_UNORM },
>{ __DRI_IMAGE_FOURCC_R8,__DRI_IMAGE_FORMAT_R8,
>  __DRI_IMAGE_COMPONENTS_R, PIPE_FORMAT_R8_UNORM },
>{ __DRI_IMAGE_FOURCC_R16,   __DRI_IMAGE_FORMAT_R16,
>  __DRI_IMAGE_COMPONENTS_R, PIPE_FORMAT_R16_UNORM },
>{ __DRI_IMAGE_FOURCC_GR88,  __DRI_IMAGE_FORMAT_GR88,
>  __DRI_IMAGE_COMPONENTS_RG,PIPE_FORMAT_RG88_UNORM },
>{ __DRI_IMAGE_FOURCC_GR1616,__DRI_IMAGE_FORMAT_GR88,
> --
> 2.17.1
>
> ___
> 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] st/dri: fix dri2_format_table for argb1555 and rgb565

2019-01-11 Thread Rob Clark

On Fri, Jan 11, 2019 at 6:19 PM Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> The bug caused that rgb565 framebuffers used argb1555.
>
> Fixes: 433ca3127a3b94bfe9a513e7c7ce594e09e1359f
> ---
>  src/gallium/state_trackers/dri/dri2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index 6fc07e42f74..ebbbabb6492 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -85,21 +85,21 @@ static const struct dri2_format_mapping 
> dri2_format_table[] = {
>{ __DRI_IMAGE_FOURCC_ARGB,  __DRI_IMAGE_FORMAT_ARGB,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_BGRA_UNORM },
>{ __DRI_IMAGE_FOURCC_ABGR,  __DRI_IMAGE_FORMAT_ABGR,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_RGBA_UNORM },
>{ __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_FORMAT_SARGB8,
>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_BGRA_SRGB },
>{ __DRI_IMAGE_FOURCC_XRGB,  __DRI_IMAGE_FORMAT_XRGB,
>  __DRI_IMAGE_COMPONENTS_RGB,   PIPE_FORMAT_BGRX_UNORM },
>{ __DRI_IMAGE_FOURCC_XBGR,  __DRI_IMAGE_FORMAT_XBGR,
>  __DRI_IMAGE_COMPONENTS_RGB,   PIPE_FORMAT_RGBX_UNORM },
> -  { __DRI_IMAGE_FOURCC_ARGB1555,  __DRI_IMAGE_FORMAT_RGB565,
> +  { __DRI_IMAGE_FOURCC_ARGB1555,  __DRI_IMAGE_FORMAT_ARGB1555,

Hey, I had only just made the exact same change locally, debugging
deqp w/ a 565 visual

(I'm still getting lots of fails, although the small # I've looked at
so far look like precision issues, so not sure if deqp actually even
works properly at less than 8b/component..)

anyways,

Reviewed-by: Rob Clark 


>  __DRI_IMAGE_COMPONENTS_RGBA,  PIPE_FORMAT_B5G5R5A1_UNORM },
>{ __DRI_IMAGE_FOURCC_RGB565,__DRI_IMAGE_FORMAT_RGB565,
>  __DRI_IMAGE_COMPONENTS_RGB,   PIPE_FORMAT_B5G6R5_UNORM },
>{ __DRI_IMAGE_FOURCC_R8,__DRI_IMAGE_FORMAT_R8,
>  __DRI_IMAGE_COMPONENTS_R, PIPE_FORMAT_R8_UNORM },
>{ __DRI_IMAGE_FOURCC_R16,   __DRI_IMAGE_FORMAT_R16,
>  __DRI_IMAGE_COMPONENTS_R, PIPE_FORMAT_R16_UNORM },
>{ __DRI_IMAGE_FOURCC_GR88,  __DRI_IMAGE_FORMAT_GR88,
>  __DRI_IMAGE_COMPONENTS_RG,PIPE_FORMAT_RG88_UNORM },
>{ __DRI_IMAGE_FOURCC_GR1616,__DRI_IMAGE_FORMAT_GR88,
> --
> 2.17.1
>
> ___
> 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 05/12] nir: rename global/local to private/function memory

2019-01-11 Thread Karol Herbst

On Fri, Jan 11, 2019 at 8:50 PM Kenneth Graunke  wrote:
>
> On Friday, January 11, 2019 9:32:20 AM PST Eric Anholt wrote:
> > Jason Ekstrand  writes:
> >
> > > On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke 
> > > wrote:
> > >
> > >> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> > >> > On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote:
> > >> > > Those names (nir_var_func_local, nir_var_thread_local, and
> > >> > > nir_var_thread_global) make more sense to me than private/function.
> > >> > >
> > >> > > Another option is `nir_var_local_temp` and `nir_var_shader_temp`,
> > >> > > indicating that they're just temporary variables, and not anything
> > >> > > with special semantics like memory.  shader_temp would pair well with
> > >> > > the existing shader_in/shader_out, since they have the same scope.
> > >> > >
> > >> > > I might also consider adding 'mem' to variables representing memory.
> > >> > >
> > >> > > So that would look like...
> > >> > >
> > >> > >nir_var_shader_in
> > >> > >nir_var_shader_out
> > >> > >nir_var_shader_temp  (formerly local/function)
> > >> > >nir_var_local_temp   (formerly global/private)
> > >> > >
> > >> >
> > >> > Are those flipped?
> > >>
> > >> Gah!  Sorry.  Yes.
> > >>
> > >>nir_var_shader_in
> > >>nir_var_shader_out
> > >>nir_var_shader_temp  (formerly global/private)
> > >>nir_var_local_temp   (formerly local/function)
> > >>nir_var_uniform
> > >>nir_var_system_value
> > >>nir_var_mem_ubo  (added mem)
> > >>nir_var_mem_ssbo (added mem)
> > >>nir_var_mem_shared   (added mem)
> > >>nir_var_mem_global   (the new global memory type being introduced)
> > >>
> > >
> > > I can work with that.  I do think I'd mildly prefer function_temp over
> > > local_temp but I think the adding of _temp is an improvement.
> >
> > I like the _temp suggestion a lot!  And I think I'm also mildly in favor
> > of function_temp.
> >
> > (Also, thanks to taking naming seriously, to everyone involved here.
> > It's hard.)
>
> Yep, it's not easy.  Karol, sorry for being grumpy the other day, it
> wasn't a very constructive email on my part.  I agree that the names
> should change, for all the reasons you suggested.
>

no worries. I should have probably pinged a few more people,
especially with a patch like that.

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

Re: [Mesa-dev] [PATCH 1/7] mesa: implement ARB/KHR_parallel_shader_compile

2019-01-11 Thread Marek Olšák

On Thu, Jan 3, 2019 at 2:40 PM Ian Romanick  wrote:

> On 11/28/18 6:59 PM, Marek Olšák wrote:
> > From: Marek Olšák 
> >
> > Tested by piglit.
>
> It doesn't look like there are any piglit test
>
> > ---
> >  docs/features.txt   |  2 +-
> >  docs/relnotes/19.0.0.html   |  2 ++
> >  src/mapi/glapi/gen/gl_API.xml   | 15 ++-
> >  src/mesa/main/dd.h  |  7 +++
> >  src/mesa/main/extensions_table.h|  2 ++
> >  src/mesa/main/get_hash_params.py|  3 +++
> >  src/mesa/main/hint.c| 12 
> >  src/mesa/main/hint.h|  4 
> >  src/mesa/main/mtypes.h  |  1 +
> >  src/mesa/main/shaderapi.c   | 10 ++
> >  src/mesa/main/tests/dispatch_sanity.cpp |  4 
> >  11 files changed, 60 insertions(+), 2 deletions(-)
> >
> > diff --git a/docs/features.txt b/docs/features.txt
> > index 8999e42519c..7b827de6a92 100644
> > --- a/docs/features.txt
> > +++ b/docs/features.txt
> > @@ -295,21 +295,21 @@ GLES3.2, GLSL ES 3.2 -- all DONE: i965/gen9+,
> radeonsi, virgl
> >GL_OES_texture_storage_multisample_2d_array   DONE (all
> drivers that support GL_ARB_texture_multisample)
> >
> >  Khronos, ARB, and OES extensions that are not part of any OpenGL or
> OpenGL ES version:
> >
> >GL_ARB_bindless_texture   DONE (nvc0,
> radeonsi)
> >GL_ARB_cl_event   not started
> >GL_ARB_compute_variable_group_sizeDONE (nvc0,
> radeonsi)
> >GL_ARB_ES3_2_compatibilityDONE
> (i965/gen8+, radeonsi, virgl)
> >GL_ARB_fragment_shader_interlock  DONE (i965)
> >GL_ARB_gpu_shader_int64   DONE
> (i965/gen8+, nvc0, radeonsi, softpipe, llvmpipe)
> > -  GL_ARB_parallel_shader_compilenot started,
> but Chia-I Wu did some related work in 2014
> > +  GL_ARB_parallel_shader_compileDONE (all
> drivers)
> >GL_ARB_post_depth_coverageDONE (i965,
> nvc0)
> >GL_ARB_robustness_isolation   not started
> >GL_ARB_sample_locations   DONE (nvc0)
> >GL_ARB_seamless_cubemap_per_texture   DONE
> (freedreno, i965, nvc0, radeonsi, r600, softpipe, swr, virgl)
> >GL_ARB_shader_ballot  DONE
> (i965/gen8+, nvc0, radeonsi)
> >GL_ARB_shader_clock   DONE
> (i965/gen7+, nv50, nvc0, r600, radeonsi, virgl)
> >GL_ARB_shader_stencil_export  DONE
> (i965/gen9+, r600, radeonsi, softpipe, llvmpipe, swr, virgl)
> >GL_ARB_shader_viewport_layer_arrayDONE
> (i965/gen6+, nvc0, radeonsi)
> >GL_ARB_sparse_buffer  DONE
> (radeonsi/CIK+)
> >GL_ARB_sparse_texture not started
> > diff --git a/docs/relnotes/19.0.0.html b/docs/relnotes/19.0.0.html
> > index bc1776e8f4e..540482bca5f 100644
> > --- a/docs/relnotes/19.0.0.html
> > +++ b/docs/relnotes/19.0.0.html
> > @@ -33,24 +33,26 @@ Compatibility contexts may report a lower version
> depending on each driver.
> >  SHA256 checksums
> >  
> >  TBD.
> >  
> >
> >
> >  New features
> >
> >  
> >  GL_AMD_texture_texture4 on all GL 4.0 drivers.
> > +GL_ARB_parallel_shader_compile on all drivers.
> >  GL_EXT_shader_implicit_conversions on all drivers (ES
> extension).
> >  GL_EXT_texture_compression_bptc on all GL 4.0 drivers (ES
> extension).
> >  GL_EXT_texture_compression_rgtc on all GL 3.0 drivers (ES
> extension).
> >  GL_EXT_texture_view on drivers supporting texture views (ES
> extension).
> > +GL_KHR_parallel_shader_compile on all drivers.
> >  GL_OES_texture_view on drivers supporting texture views (ES
> extension).
> >  
> >
> >  Bug fixes
> >
> >  
> >  TBD
> >  
> >
> >  Changes
> > diff --git a/src/mapi/glapi/gen/gl_API.xml
> b/src/mapi/glapi/gen/gl_API.xml
> > index f4d0808f13b..4ce691b361b 100644
> > --- a/src/mapi/glapi/gen/gl_API.xml
> > +++ b/src/mapi/glapi/gen/gl_API.xml
> > @@ -8402,21 +8402,34 @@
> >  
> >  
> >  
> >  
> >  
> >
> >  
> >
> >  http://www.w3.org/2001/XInclude"/>
> >
> > -
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > + alias="MaxShaderCompilerThreadsKHR">
> > +
> > +
> > +
> > +
> > +
> >
> >  http://www.w3.org/2001/XInclude"/>
> >
> >  
> >
> >  
> >value="0x8001"/>
> >value="0x8002"/>
> >value="0x8003"/>
> >value="0x8004"/>
> > diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
> > index f14c3e04e91..92b6ecac33c 100644
> > --- a/src/mesa/main/dd.h
> > +++ b/src/mesa/main/dd.h
> > @@ -1292,20 +1292,27 @@ struct dd_function_table {
> > /**
> >  * Called to initialize gl_program::driver_cache_blob

[Mesa-dev] [PATCH] spirv: Emit switch conditions on-the-fly

2019-01-11 Thread Jason Ekstrand

Instead of emitting all of the conditions for the cases of a switch
statement up-front, emit them on-the-fly as we emit the code for each
case.  The original justification for this was that we were going to
have to build a default case anyway which would need them all.  However,
we can just trust CSE to clean up the mess in that case.  Emitting each
condition right before the if statement that uses it reduces register
pressure and, in one customer benchmark, gets rid of spilling and
improves performance by about 2x.
---
 src/compiler/spirv/vtn_cfg.c | 62 +++-
 1 file changed, 26 insertions(+), 36 deletions(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index aef1b7e18fb..34a910accc6 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -852,6 +852,30 @@ vtn_emit_branch(struct vtn_builder *b, enum 
vtn_branch_type branch_type,
}
 }
 
+static nir_ssa_def *
+vtn_switch_case_condition(struct vtn_builder *b, struct vtn_switch *swtch,
+  nir_ssa_def *sel, struct vtn_case *cse)
+{
+   if (cse->is_default) {
+  nir_ssa_def *any = nir_imm_false(&b->nb);
+  list_for_each_entry(struct vtn_case, other, &swtch->cases, link) {
+ if (cse->is_default)
+continue;
+
+ any = nir_ior(&b->nb, any,
+   vtn_switch_case_condition(b, swtch, sel, other));
+  }
+  return any;
+   } else {
+  nir_ssa_def *cond = nir_imm_false(&b->nb);
+  util_dynarray_foreach(&cse->values, uint64_t, val) {
+ nir_ssa_def *imm = nir_imm_intN_t(&b->nb, *val, sel->bit_size);
+ cond = nir_ior(&b->nb, cond, nir_ieq(&b->nb, sel, imm));
+  }
+  return cond;
+   }
+}
+
 static void
 vtn_emit_cf_list(struct vtn_builder *b, struct list_head *cf_list,
  nir_variable *switch_fall_var, bool *has_switch_break,
@@ -978,46 +1002,13 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
 nir_local_variable_create(b->nb.impl, glsl_bool_type(), "fall");
  nir_store_var(&b->nb, fall_var, nir_imm_false(&b->nb), 1);
 
- /* Next, we gather up all of the conditions.  We have to do this
-  * up-front because we also need to build an "any" condition so
-  * that we can use !any for default.
-  */
- const int num_cases = list_length(&vtn_switch->cases);
- NIR_VLA(nir_ssa_def *, conditions, num_cases);
-
  nir_ssa_def *sel = vtn_ssa_value(b, vtn_switch->selector)->def;
- /* An accumulation of all conditions.  Used for the default */
- nir_ssa_def *any = NULL;
-
- int i = 0;
- list_for_each_entry(struct vtn_case, cse, &vtn_switch->cases, link) {
-if (cse->is_default) {
-   conditions[i++] = NULL;
-   continue;
-}
-
-nir_ssa_def *cond = NULL;
-util_dynarray_foreach(&cse->values, uint64_t, val) {
-   nir_ssa_def *imm = nir_imm_intN_t(&b->nb, *val, sel->bit_size);
-   nir_ssa_def *is_val = nir_ieq(&b->nb, sel, imm);
-
-   cond = cond ? nir_ior(&b->nb, cond, is_val) : is_val;
-}
-
-any = any ? nir_ior(&b->nb, any, cond) : cond;
-conditions[i++] = cond;
- }
- vtn_assert(i == num_cases);
 
  /* Now we can walk the list of cases and actually emit code */
- i = 0;
  list_for_each_entry(struct vtn_case, cse, &vtn_switch->cases, link) {
 /* Figure out the condition */
-nir_ssa_def *cond = conditions[i++];
-if (cse->is_default) {
-   vtn_assert(cond == NULL);
-   cond = nir_inot(&b->nb, any);
-}
+nir_ssa_def *cond =
+   vtn_switch_case_condition(b, vtn_switch, sel, cse);
 /* Take fallthrough into account */
 cond = nir_ior(&b->nb, cond, nir_load_var(&b->nb, fall_var));
 
@@ -1030,7 +1021,6 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
 
 nir_pop_if(&b->nb, case_if);
  }
- vtn_assert(i == num_cases);
 
  break;
   }
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH 4/6] anv/blorp: Refactor MSAA resolves into an exportable helper function

2019-01-11 Thread Iago Toral

On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> This function is modeled after the aux_op functions except that it
> has a
> lot more parameters because it deals with two images as well as
> source
> and destination regions.
> ---
>  src/intel/vulkan/anv_blorp.c   | 225 ++-
> --
>  src/intel/vulkan/anv_private.h |  14 ++
>  2 files changed, 107 insertions(+), 132 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_blorp.c
> b/src/intel/vulkan/anv_blorp.c
> index eee7a8c3b3c..2f8d502e289 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1169,63 +1169,52 @@ enum subpass_stage {
> SUBPASS_STAGE_RESOLVE,
>  };
>  
> -static void
> -resolve_surface(struct blorp_batch *batch,
> -struct blorp_surf *src_surf,
> -uint32_t src_level, uint32_t src_layer,
> -struct blorp_surf *dst_surf,
> -uint32_t dst_level, uint32_t dst_layer,
> -uint32_t src_x, uint32_t src_y, uint32_t dst_x,
> uint32_t dst_y,
> -uint32_t width, uint32_t height,
> -enum blorp_filter filter)
> -{
> -   blorp_blit(batch,
> -  src_surf, src_level, src_layer,
> -  ISL_FORMAT_UNSUPPORTED, ISL_SWIZZLE_IDENTITY,
> -  dst_surf, dst_level, dst_layer,
> -  ISL_FORMAT_UNSUPPORTED, ISL_SWIZZLE_IDENTITY,
> -  src_x, src_y, src_x + width, src_y + height,
> -  dst_x, dst_y, dst_x + width, dst_y + height,
> -  filter, false, false);
> -}
> -
> -static void
> -resolve_image(struct anv_device *device,
> -  struct blorp_batch *batch,
> -  const struct anv_image *src_image,
> -  VkImageLayout src_image_layout,
> -  uint32_t src_level, uint32_t src_layer,
> -  const struct anv_image *dst_image,
> -  VkImageLayout dst_image_layout,
> -  uint32_t dst_level, uint32_t dst_layer,
> -  VkImageAspectFlags aspect_mask,
> -  uint32_t src_x, uint32_t src_y, uint32_t dst_x,
> uint32_t dst_y,
> -  uint32_t width, uint32_t height)
> +void
> +anv_image_msaa_resolve(struct anv_cmd_buffer *cmd_buffer,
> +   const struct anv_image *src_image,
> +   enum isl_aux_usage src_aux_usage,
> +   uint32_t src_level, uint32_t src_base_layer,
> +   const struct anv_image *dst_image,
> +   enum isl_aux_usage dst_aux_usage,
> +   uint32_t dst_level, uint32_t dst_base_layer,
> +   VkImageAspectFlagBits aspect,
> +   uint32_t src_x, uint32_t src_y,
> +   uint32_t dst_x, uint32_t dst_y,
> +   uint32_t width, uint32_t height,
> +   uint32_t layer_count,
> +   enum blorp_filter filter)
>  {
> -   struct anv_cmd_buffer *cmd_buffer = batch->driver_batch;
> +   struct blorp_batch batch;
> +   blorp_batch_init(&cmd_buffer->device->blorp, &batch, cmd_buffer,
> 0);
>  
> assert(src_image->type == VK_IMAGE_TYPE_2D);
> assert(src_image->samples > 1);
> assert(dst_image->type == VK_IMAGE_TYPE_2D);
> assert(dst_image->samples == 1);
> assert(src_image->n_planes == dst_image->n_planes);
> +   assert(!src_image->format->can_ycbcr);
> +   assert(!dst_image->format->can_ycbcr);
>  
> -   uint32_t aspect_bit;
> -
> -   anv_foreach_image_aspect_bit(aspect_bit, src_image, aspect_mask)
> {
> -  struct blorp_surf src_surf, dst_surf;
> -  get_blorp_surf_for_anv_image(device, src_image, 1UL <<
> aspect_bit,
> -   src_image_layout,
> ISL_AUX_USAGE_NONE,
> -   &src_surf);
> -  get_blorp_surf_for_anv_image(device, dst_image, 1UL <<
> aspect_bit,
> -   dst_image_layout,
> ISL_AUX_USAGE_NONE,
> -   &dst_surf);
> -  anv_cmd_buffer_mark_image_written(cmd_buffer, dst_image,
> -1UL << aspect_bit,
> -dst_surf.aux_usage,
> -dst_level, dst_layer, 1);
> -
> -  enum blorp_filter filter;
> +   struct blorp_surf src_surf, dst_surf;
> +   get_blorp_surf_for_anv_image(cmd_buffer->device, src_image,
> aspect,
> +ANV_IMAGE_LAYOUT_EXPLICIT_AUX,
> +src_aux_usage, &src_surf);
> +   if (src_aux_usage == ISL_AUX_USAGE_MCS) {
> +  src_surf.clear_color_addr = anv_to_blorp_address(
> + anv_image_get_clear_color_addr(cmd_buffer->device,
> src_image,
> +VK_IMAGE_ASPECT_COLOR_BIT));
> +   }
> +   get_blorp_surf_for_anv_image(cmd_buffer->device, dst_image,
> aspect,
> +ANV_IMAGE_LAYOUT_EXPLICIT_AUX,
> +

Re: [Mesa-dev] [PATCH 6/6] anv: Implement VK_KHR_depth_stencil_resolve

2019-01-11 Thread Iago Toral

On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/anv_device.c  |  28 ++
>  src/intel/vulkan/anv_extensions.py |   1 +
>  src/intel/vulkan/anv_pass.c|  37 +++-
>  src/intel/vulkan/anv_private.h |   3 +
>  src/intel/vulkan/genX_cmd_buffer.c | 136
> +
>  5 files changed, 204 insertions(+), 1 deletion(-)
> 
> diff --git a/src/intel/vulkan/anv_device.c
> b/src/intel/vulkan/anv_device.c
> index 2a3919d2949..3761846bb7f 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -1138,6 +1138,34 @@ void anv_GetPhysicalDeviceProperties2(
>   break;
>}
>  
> +  case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERTIES_KH
> R: {
> + VkPhysicalDeviceDepthStencilResolvePropertiesKHR *props =
> +(VkPhysicalDeviceDepthStencilResolvePropertiesKHR *)ext;
> +
> + /* We support all of the depth resolve modes */
> + props->supportedDepthResolveModes =
> +VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR |
> +VK_RESOLVE_MODE_AVERAGE_BIT_KHR |
> +VK_RESOLVE_MODE_MIN_BIT_KHR |
> +VK_RESOLVE_MODE_MAX_BIT_KHR;
> +
> + /* Average doesn't make sense for stencil so we don't
> support that */
> + props->supportedStencilResolveModes =
> +VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR;
> + if (pdevice->info.gen >= 8) {
> +/* The advanced stencil resolve modes currently require
> stencil
> + * sampling be supported by the hardware.
> + */
> +props->supportedStencilResolveModes |=
> +   VK_RESOLVE_MODE_MIN_BIT_KHR |
> +   VK_RESOLVE_MODE_MAX_BIT_KHR;
> + }
> +
> + props->independentResolveNone = VK_TRUE;
> + props->independentResolve = VK_TRUE;
> + break;
> +  }
> +
>case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR:
> {
>   VkPhysicalDeviceDriverPropertiesKHR *driver_props =
>  (VkPhysicalDeviceDriverPropertiesKHR *) ext;
> diff --git a/src/intel/vulkan/anv_extensions.py
> b/src/intel/vulkan/anv_extensions.py
> index 388845003aa..2ea4cab0e97 100644
> --- a/src/intel/vulkan/anv_extensions.py
> +++ b/src/intel/vulkan/anv_extensions.py
> @@ -76,6 +76,7 @@ EXTENSIONS = [
>  Extension('VK_KHR_bind_memory2',  1, True),
>  Extension('VK_KHR_create_renderpass2',1, True),
>  Extension('VK_KHR_dedicated_allocation',  1, True),
> +Extension('VK_KHR_depth_stencil_resolve', 1, True),
>  Extension('VK_KHR_descriptor_update_template',1, True),
>  Extension('VK_KHR_device_group',  1, True),
>  Extension('VK_KHR_device_group_creation', 1, True),
> diff --git a/src/intel/vulkan/anv_pass.c
> b/src/intel/vulkan/anv_pass.c
> index 7b17cc06935..196cf3ff8fd 100644
> --- a/src/intel/vulkan/anv_pass.c
> +++ b/src/intel/vulkan/anv_pass.c
> @@ -74,6 +74,10 @@ anv_render_pass_compile(struct anv_render_pass
> *pass)
>subpass->depth_stencil_attachment->attachment ==
> VK_ATTACHMENT_UNUSED)
>   subpass->depth_stencil_attachment = NULL;
>  
> +  if (subpass->ds_resolve_attachment &&
> +  subpass->ds_resolve_attachment->attachment ==
> VK_ATTACHMENT_UNUSED)
> + subpass->ds_resolve_attachment = NULL;
> +

This is a nitpick, but since we setup subpass->ds_resolve_attachment in
anv_CreateRenderPass2KHR(), should't we just do this sanitation there?

>for (uint32_t j = 0; j < subpass->attachment_count; j++) {
>   struct anv_subpass_attachment *subpass_att = &subpass-
> >attachments[j];
>   if (subpass_att->attachment == VK_ATTACHMENT_UNUSED)
> @@ -116,6 +120,16 @@ anv_render_pass_compile(struct anv_render_pass
> *pass)
>  color_att->usage |= VK_IMAGE_USAGE_TRANSFER_SRC_BIT;
>   }
>}
> +
> +  if (subpass->ds_resolve_attachment) {
> + struct anv_subpass_attachment *ds_att =
> +subpass->depth_stencil_attachment;
> + UNUSED struct anv_subpass_attachment *resolve_att =
> +subpass->ds_resolve_attachment;
> +
> + assert(resolve_att->usage ==
> VK_IMAGE_USAGE_TRANSFER_DST_BIT);
> + ds_att->usage |= VK_IMAGE_USAGE_TRANSFER_SRC_BIT;
> +  }
> }
>  
> /* From the Vulkan 1.0.39 spec:
> @@ -342,10 +356,15 @@ VkResult anv_CreateRenderPass(
>  static unsigned
>  num_subpass_attachments2(const VkSubpassDescription2KHR *desc)
>  {
> +   const VkSubpassDescriptionDepthStencilResolveKHR *ds_resolve =
> +  vk_find_struct_const(desc->pNext,
> +   SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE
> _KHR);
> +
> return desc->inputAttachmentCount +
>desc->colorAttachmentCount +
>(desc->pResolveAttachments ? desc->colorAttachmentCount :
> 0) +
> -  (desc->pDepthStencilAttac

Re: [Mesa-dev] [PATCH 1/6] vulkan: Update the XML and headers to 1.1.97

2019-01-11 Thread Iago Toral

I dropped a comment in patch 4 which may or may not be relevant and
then a couple nitpicks in patch 6 that you can take or ignore. Either
way, the series is:

Reviewed-by: Iago Toral Quiroga 

On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> ---
>  include/vulkan/vulkan.h |   2 +-
>  include/vulkan/vulkan_android.h |   2 +-
>  include/vulkan/vulkan_core.h| 155 +++-
>  include/vulkan/vulkan_fuchsia.h |   2 +-
>  include/vulkan/vulkan_ios.h |   2 +-
>  include/vulkan/vulkan_macos.h   |   2 +-
>  include/vulkan/vulkan_vi.h  |   2 +-
>  include/vulkan/vulkan_wayland.h |   2 +-
>  include/vulkan/vulkan_win32.h   |   2 +-
>  include/vulkan/vulkan_xcb.h |   2 +-
>  include/vulkan/vulkan_xlib.h|   2 +-
>  include/vulkan/vulkan_xlib_xrandr.h |   2 +-
>  src/vulkan/registry/vk.xml  | 175 +++---
> --
>  13 files changed, 311 insertions(+), 41 deletions(-)
> 
> diff --git a/include/vulkan/vulkan.h b/include/vulkan/vulkan.h
> index 77da63783e6..a3be4af6c46 100644
> --- a/include/vulkan/vulkan.h
> +++ b/include/vulkan/vulkan.h
> @@ -2,7 +2,7 @@
>  #define VULKAN_H_ 1
>  
>  /*
> -** Copyright (c) 2015-2018 The Khronos Group Inc.
> +** Copyright (c) 2015-2019 The Khronos Group Inc.
>  **
>  ** Licensed under the Apache License, Version 2.0 (the "License");
>  ** you may not use this file except in compliance with the License.
> diff --git a/include/vulkan/vulkan_android.h
> b/include/vulkan/vulkan_android.h
> index 07aaeda28e3..e70376c8867 100644
> --- a/include/vulkan/vulkan_android.h
> +++ b/include/vulkan/vulkan_android.h
> @@ -6,7 +6,7 @@ extern "C" {
>  #endif
>  
>  /*
> -** Copyright (c) 2015-2018 The Khronos Group Inc.
> +** Copyright (c) 2015-2019 The Khronos Group Inc.
>  **
>  ** Licensed under the Apache License, Version 2.0 (the "License");
>  ** you may not use this file except in compliance with the License.
> diff --git a/include/vulkan/vulkan_core.h
> b/include/vulkan/vulkan_core.h
> index 72542c72ec8..caeecd9bed1 100644
> --- a/include/vulkan/vulkan_core.h
> +++ b/include/vulkan/vulkan_core.h
> @@ -6,7 +6,7 @@ extern "C" {
>  #endif
>  
>  /*
> -** Copyright (c) 2015-2018 The Khronos Group Inc.
> +** Copyright (c) 2015-2019 The Khronos Group Inc.
>  **
>  ** Licensed under the Apache License, Version 2.0 (the "License");
>  ** you may not use this file except in compliance with the License.
> @@ -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 96
> +#define VK_HEADER_VERSION 97
>  
>  
>  #define VK_NULL_HANDLE 0
> @@ -148,6 +148,7 @@ typedef enum VkResult {
>  VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT =
> -1000158000,
>  VK_ERROR_FRAGMENTATION_EXT = -1000161000,
>  VK_ERROR_NOT_PERMITTED_EXT = -1000174001,
> +VK_ERROR_INVALID_DEVICE_ADDRESS_EXT = -1000244000,
>  VK_ERROR_OUT_OF_POOL_MEMORY_KHR = VK_ERROR_OUT_OF_POOL_MEMORY,
>  VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR =
> VK_ERROR_INVALID_EXTERNAL_HANDLE,
>  VK_RESULT_BEGIN_RANGE = VK_ERROR_FRAGMENTED_POOL,
> @@ -444,6 +445,8 @@ typedef enum VkStructureType {
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATU
> RES_EXT = 1000190002,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR =
> 1000196000,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR
> = 1000197000,
> +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERTI
> ES_KHR = 1000199000,
> +VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR
> = 1000199001,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEA
> TURES_NV = 1000201000,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_NV =
> 1000202000,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_NV =
> 1000202001,
> @@ -460,7 +463,14 @@ typedef enum VkStructureType {
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_PROPERTIE
> S_EXT = 1000218001,
>  VK_STRUCTURE_TYPE_RENDER_PASS_FRAGMENT_DENSITY_MAP_CREATE_INFO_E
> XT = 1000218002,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCALAR_BLOCK_LAYOUT_FEATURES_E
> XT = 1000221000,
> +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT =
> 1000237000,
> +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PRIORITY_FEATURES_EXT =
> 1000238000,
> +VK_STRUCTURE_TYPE_MEMORY_PRIORITY_ALLOCATE_INFO_EXT =
> 1000238001,
> +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT =
> 1000244000,
> +VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_EXT = 1000244001,
> +VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_CREATE_INFO_EXT =
> 1000244002,
>  VK_STRUCTURE_TYPE_IMAGE_STENCIL_USAGE_CREATE_INFO_EXT =
> 1000246000,
> +VK_STRUCTURE_TYPE_VALIDATION_FEATURES_EXT = 1000247000,
>  VK_STRUCTURE_TYPE_DEBUG_R

Re: [Mesa-dev] Please bring back __GL_FSAA_MODE

2019-01-11 Thread Tom Butler

Thanks Marek, what would need to happen to get this enabled
again? Will simply reverting the commit that took it out work? If
so is there any chance of getting this put back officially or
would I have to manually compile the driver each release?

In particular I'm looking to get FSAA working in older games via
wine, mostly they don't support antialiasing which is a shame
because there's plenty of GPU power going to waste which could be
fixing the jaggles. On nvidia __GL_FSAA_MODE works as intended
provided you set wine's OffScreenRenderingMode to "backbuffer"
which slightly impacts performance but doesn't matter for older
games. I'd love to see the functionality return for AMD GPUs.

Kind Regards,
Tom

On 27/11/2018 22:30, Marek Olšák wrote:

Yes, it could be added back.

Marek

On Tue, Nov 27, 2018 at 3:15 AM Tom Butler
wrote:

Hello,

I realise this was removed for a reason (
https://lists.freedesktop.org/archives/mesa-dev/2014-September/067864.html

) but there are cases where it is useful. In older games that
do not
support native FSAA being able to force it in the driver is
the only way
to enable it.

A quick google search for AMD linux force msaa shows that I'm
not the
only one who would like to see this feature return:

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1024166-radeon-eqaa-anti-aliasing-support-merged-to-mesa-18-2?p=1024185#post1024185

https://bbs.archlinux.org/viewtopic.php?id=225425

https://www.reddit.com/r/linux_gaming/comments/671yzm/forcing_antialiasing_with_mesa_radeon_driver/

https://github.com/dscharrer/void/blob/master/hacks/forcemsaa.c

I understand it does cause issues in some cases but there are
times when
it is useful. Could it be reintroduced with a more relevant
name that
implies it shouldn't be used? E.g. GALLIUM_LEGACY_MSAA or
GALLIUM_FORCE_MSAA_EXPERIMENTAL. That way it would lower users

1 2 >

1 - 100 of 114 matches

Mail list logo