Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[Kenneth Graunke]

On Thursday, February 7, 2019 3:35:01 AM PST andrey simiklit wrote:
> ping. the piglit test was pushed)
> 
> Thanks,
> Andrii.

I landed this today.  Thanks!

--Ken


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 v3 2/5] i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.

[Eleni Maria Stea]

Hello,

On Thu, 7 Feb 2019 15:46:29 -0800
Nanley Chery  wrote:


> > -  !(mode & BRW_MAP_DIRECT_BIT)) {
> > +  !(mode & BRW_MAP_DIRECT_BIT) &&
> > +  !(intel_miptree_needs_fake_etc(brw, mt))) {
> >intel_miptree_map_etc(brw, mt, map, level, slice);  
> 
> Out of curiosity, is there any reason you wait until patch 5 to delete
> this case?

No, I just removed this lines together with the unreached map/unmap_etc
functions. I will move the change to this patch.

> 
> > } else if (mt->stencil_mt && !(mode & BRW_MAP_DIRECT_BIT)) {
> >intel_miptree_map_depthstencil(brw, mt, map, level, slice);
> > @@ -3816,6 +3839,7 @@ intel_miptree_unmap(struct brw_context *brw,
> >  unsigned int slice)
> >  {
> > struct intel_miptree_map *map =
> > mt->level[level].slice[slice].map;
> > +   int level_w, level_h;
> >  
> > assert(mt->surf.samples == 1);
> >  
> > @@ -3825,10 +3849,20 @@ intel_miptree_unmap(struct brw_context *brw,
> > DBG("%s: mt %p (%s) level %d slice %d\n", __func__,
> > mt, _mesa_get_format_name(mt->format), level, slice);
> >  
> > +   level_w = minify(mt->surf.phys_level0_sa.width,
> > +level - mt->first_level);
> > +   level_h = minify(mt->surf.phys_level0_sa.height,
> > +level - mt->first_level);
> > +
> > if (map->unmap)
> >map->unmap(brw, mt, map, level, slice);
> >  
> > intel_miptree_release_map(mt, level, slice);
> > +
> > +   if (intel_miptree_has_etc_shadow(brw, mt) &&
> > mt->shadow_needs_update) {
> > +  intel_miptree_update_etc_shadow(brw, mt, level, slice,
> > level_w,
> > +  level_h);
> > +   }  
> 
> With the next patch applied, the change in this function becomes
> unnecessary. Is there any reason you're leaving it around?

Right, if we force the update before the rendering, we don't need to
copy the data during the unmap. I will remove it, sorry I dismissed
it in the previous email.
 
> >  }
> >  
> >  enum isl_surf_dim
> > @@ -3943,3 +3977,81 @@ intel_miptree_get_clear_color(const struct
> > gen_device_info *devinfo, return mt->fast_clear_color;
> > }
> >  }
> > +
> > +static void
> > +intel_miptree_update_etc_shadow(struct brw_context *brw,
> > +struct intel_mipmap_tree *mt,
> > +unsigned int level,
> > +unsigned int slice,
> > +int level_w,
> > +int level_h)
> > +{
> > +   struct intel_mipmap_tree *smt;
> > +   ptrdiff_t etc_stride, shadow_stride;
> > +   GLbitfield etc_mode, shadow_mode;
> > +   void *mptr, *sptr;
> > +
> > +   assert(intel_miptree_has_etc_shadow(brw, mt));
> > +   if (!mt->shadow_needs_update)
> > +  return;
> > +
> > +   mt->shadow_needs_update = false;
> > +   smt = mt->shadow_mt;
> > +
> > +   etc_mode = GL_MAP_READ_BIT;
> > +   shadow_mode = GL_MAP_WRITE_BIT | GL_MAP_INVALIDATE_RANGE_BIT;
> > +
> > +   intel_miptree_map(brw, mt, level, slice, 0, 0, level_w, level_h,
> > + etc_mode, , _stride);
> > +   intel_miptree_map(brw, smt, level, slice, 0, 0, level_w,
> > level_h,
> > + shadow_mode, , _stride);
> > +
> > +   if (mt->format == MESA_FORMAT_ETC1_RGB8) {
> > +  _mesa_etc1_unpack_rgba(sptr, shadow_stride, mptr,
> > etc_stride,
> > + level_w, level_h);
> > +   } else {
> > +  /* destination and source images must have the same swizzle
> > */
> > +  bool is_bgra = (smt->format == MESA_FORMAT_B8G8R8A8_SRGB);
> > +  _mesa_unpack_etc2_format(sptr, shadow_stride, mptr,
> > etc_stride,
> > +   level_w, level_h, mt->format,
> > is_bgra);
> > +   }
> > +
> > +   intel_miptree_unmap(brw, mt, level, slice);
> > +   intel_miptree_unmap(brw, smt, level, slice);
> > +}
> > +
> > +void
> > +intel_miptree_update_etc_shadow_levels(struct brw_context *brw,
> > +   struct intel_mipmap_tree
> > *mt) +{
> > +   struct intel_mipmap_tree *smt;
> > +   int num_slices;
> > +   int level_w, level_h;
> > +
> > +   assert(mt);
> > +   assert(mt->surf.size_B > 0);
> > +
> > +   assert(intel_miptree_has_etc_shadow(brw, mt));
> > +
> > +   smt = mt->shadow_mt;
> > +
> > +   level_w = smt->surf.logical_level0_px.width;
> > +   level_h = smt->surf.logical_level0_px.height;
> > +
> > +   num_slices = smt->surf.logical_level0_px.array_len;
> > +
> > +   for (int level = smt->first_level; level <= smt->last_level;
> > level++)
> > +   {
> > +  for (unsigned int slice = 0; slice < num_slices; slice++) {
> > + intel_miptree_update_etc_shadow(brw, mt, level, slice,
> > level_w,
> > + level_h);
> > +  }
> > +
> > +  level_w = minify(mt->surf.logical_level0_px.width,
> > +   level - mt->first_level);
> > +  level_h 

Re: [Mesa-dev] [PATCH v3 12/44] nir: add new fadd, fsub, fmul opcodes taking into account rounding mode

[Samuel Iglesias Gonsálvez]

On 2/6/19 12:47 PM, Connor Abbott wrote:
> 
> 
> On Wed, Feb 6, 2019 at 11:46 AM Samuel Iglesias Gonsálvez
> mailto:sigles...@igalia.com>> wrote:
> 
> According to Vulkan spec, the new execution modes affect only
> correctly rounded SPIR-V instructions, which includes fadd,
> fsub and fmul.
> 
> Signed-off-by: Samuel Iglesias Gonsálvez  >
> ---
>  src/compiler/nir/nir_opcodes.py | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/src/compiler/nir/nir_opcodes.py
> b/src/compiler/nir/nir_opcodes.py
> index f8997444c28..7b45d38f460 100644
> --- a/src/compiler/nir/nir_opcodes.py
> +++ b/src/compiler/nir/nir_opcodes.py
> @@ -453,9 +453,15 @@ def binop_convert(name, out_type, in_type,
> alg_props, const_expr):
>     opcode(name, 0, out_type, [0, 0], [in_type, in_type],
>            False, alg_props, const_expr, "")
> 
> +def binop_convert_rounding_mode(name, out_type, in_type, alg_props,
> const_expr, rounding_mode):
> +   opcode(name, 0, out_type, [0, 0], [in_type, in_type], False,
> alg_props, const_expr, rounding_mode)
> +
>  def binop(name, ty, alg_props, const_expr):
>     binop_convert(name, ty, ty, alg_props, const_expr)
> 
> +def binop_rounding_mode(name, ty, alg_props, const_expr,
> rounding_mode):
> +   binop_convert_rounding_mode(name, ty, ty, alg_props, const_expr,
> rounding_mode)
> +
>  def binop_compare(name, ty, alg_props, const_expr):
>     binop_convert(name, tbool1, ty, alg_props, const_expr)
> 
> @@ -490,13 +496,24 @@ def binop_reduce(name, output_size,
> output_type, src_type, prereduce_expr,
>            final(reduce_(reduce_(src0, src1), reduce_(src2, src3))), "")
> 
>  binop("fadd", tfloat, commutative + associative, "src0 + src1")
> +binop_rounding_mode("fadd_rtne", tfloat, commutative + associative,
> +                    "_mesa_roundeven(src0 + src1)", "_rtne")
> 
> 
> There are two things wrong here:
> - The default floating-point environment, and the one Mesa expects, does
> round-to-nearest-even so it's rtz that needs special handling.
> - _mesa_roundeven here is a no-op (it'll implicitly expand to a double
> and then convert back to a float). The rounding actually happens as part
> of the addition itself. I'm not sure if adding as double (with
> round-to-nearest-even) and then rounding back to a float will work, but
> that definitely won't work for doubles. I think you'll have to implement
> round-to-zero addition yourself, or fiddle with the CPU's floating-point
> environment.
> 
> The same goes multiply and fma.
>  

In order to avoid flooding the ML with more patches, I created a MR with
the suggested changes:

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/223

Please take a look at them and let me know if now it is fine.

Thanks,

Sam

> 
> +binop_rounding_mode("fadd_rtz", tfloat, commutative + associative,
> "src0 + src1", "_rtz")
> +
>  binop("iadd", tint, commutative + associative, "src0 + src1")
>  binop("uadd_sat", tuint, commutative,
>        "(src0 + src1) < src0 ? UINT64_MAX : (src0 + src1)")
>  binop("fsub", tfloat, "", "src0 - src1")
> +binop_rounding_mode("fsub_rtne", tfloat, "",
> +                    "_mesa_roundeven(src0 - src1)", "_rtne")
> +binop_rounding_mode("fsub_rtz", tfloat, "", "src0 - src1", "_rtz")
>  binop("isub", tint, "", "src0 - src1")
> 
>  binop("fmul", tfloat, commutative + associative, "src0 * src1")
> +binop_rounding_mode("fmul_rtne", tfloat, commutative + associative,
> +                    "_mesa_roundeven(src0 * src1)", "_rtne")
> +binop_rounding_mode("fmul_rtz", tfloat, commutative + associative,
> "src0 * src1", "_rtz")
> +
>  # low 32-bits of signed/unsigned integer multiply
>  binop("imul", tint, commutative + associative, "src0 * src1")
> 
> -- 
> 2.19.1
> 
> ___
> 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

[Mesa-dev] [MR] WIP: VK_KHR_shader_float_controls implementation on ANV

[Samuel Iglesias Gonsálvez]

First three versions of this branch were sent for review to the mailing
list. In order to avoid flooding the list with more emails, I create
this MR to continue the review process there.

Reminder: this patch series relies on VK_KHR_shader_float16_int8 patch
series which is currently under review. For that reason, I mark this
Merge Request as Work In Progress.

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/223



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

[Mesa-dev] [PATCH] radv/llvm: initialise passes static member.

[Dave Airlie]

From: Dave Airlie 

Fixes coverity warning
---
 src/amd/vulkan/radv_llvm_helper.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_llvm_helper.cpp 
b/src/amd/vulkan/radv_llvm_helper.cpp
index f651593ca62..d1e1e376f90 100644
--- a/src/amd/vulkan/radv_llvm_helper.cpp
+++ b/src/amd/vulkan/radv_llvm_helper.cpp
@@ -29,7 +29,7 @@ class radv_llvm_per_thread_info {
 public:
radv_llvm_per_thread_info(enum radeon_family arg_family,
enum ac_target_machine_options arg_tm_options)
-   : family(arg_family), tm_options(arg_tm_options) {}
+   : family(arg_family), tm_options(arg_tm_options), passes(NULL) 
{}
 
~radv_llvm_per_thread_info()
{
-- 
2.20.1

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

[Mesa-dev] [PATCH] glsl: glsl to nir fix uninit static class member.

[Dave Airlie]

From: Dave Airlie 

The constructor should init this to NULL
---
 src/compiler/glsl/glsl_to_nir.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index 09599e4cee7..d62de862fac 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -180,6 +180,7 @@ nir_visitor::nir_visitor(nir_shader *shader)
this->overload_table = _mesa_pointer_hash_table_create(NULL);
this->result = NULL;
this->impl = NULL;
+   this->deref = NULL;
memset(>b, 0, sizeof(this->b));
 }
 
-- 
2.20.1

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

[Mesa-dev] svga coverity warnings

[Dave Airlie]

One of our internal coverity scans pointed these out, they looked valid.

Dave.

12. mesa-18.3.3/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c:323:
use_invalid: Using "rep", which points to an out-of-scope variable
"s_arg.rep".
Expand

13. mesa-18.3.3/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c:315:
use_invalid: Using "rep", which points to an out-of-scope variable
"s_arg.rep".
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: remove alloc parameter from pipeline init

[Dave Airlie]

From: Dave Airlie 

clang points out this isn't used.
---
 src/amd/vulkan/radv_pipeline.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index ab56a273a2c..fb6c61cf3f0 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -3543,8 +3543,7 @@ radv_pipeline_init(struct radv_pipeline *pipeline,
   struct radv_device *device,
   struct radv_pipeline_cache *cache,
   const VkGraphicsPipelineCreateInfo *pCreateInfo,
-  const struct radv_graphics_pipeline_create_info *extra,
-  const VkAllocationCallbacks *alloc)
+  const struct radv_graphics_pipeline_create_info *extra)
 {
VkResult result;
bool has_view_index = false;
@@ -3553,8 +3552,6 @@ radv_pipeline_init(struct radv_pipeline *pipeline,
struct radv_subpass *subpass = pass->subpasses + pCreateInfo->subpass;
if (subpass->view_mask)
has_view_index = true;
-   if (alloc == NULL)
-   alloc = >alloc;
 
pipeline->device = device;
pipeline->layout = 
radv_pipeline_layout_from_handle(pCreateInfo->layout);
@@ -3682,7 +3679,7 @@ radv_graphics_pipeline_create(
return vk_error(device->instance, VK_ERROR_OUT_OF_HOST_MEMORY);
 
result = radv_pipeline_init(pipeline, device, cache,
-   pCreateInfo, extra, pAllocator);
+   pCreateInfo, extra);
if (result != VK_SUCCESS) {
radv_pipeline_destroy(device, pipeline, pAllocator);
return result;
-- 
2.20.1

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

[Mesa-dev] [PATCH] intel/dump_gpu: Disambiguate between BOs from different GEM handle spaces.

[Francisco Jerez]

This fixes a rather astonishing problem that came up while debugging
an issue in the Vulkan CTS.  Apparently the Vulkan CTS framework has
the tendency to create multiple VkDevices, each one with a separate
DRM device FD and therefore a disjoint GEM buffer object handle space.
Because the intel_dump_gpu tool wasn't making any distinction between
buffers from the different handle spaces, it was confusing the
instruction state pools from both devices, which happened to have the
exact same GEM handle and PPGTT virtual address, but completely
different shader contents.  This was causing the simulator to believe
that the vertex pipeline was executing a fragment shader, which didn't
end up well.
---
 src/intel/tools/intel_dump_gpu.c | 41 ++--
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/src/intel/tools/intel_dump_gpu.c b/src/intel/tools/intel_dump_gpu.c
index ffe49b10108..19e054c894c 100644
--- a/src/intel/tools/intel_dump_gpu.c
+++ b/src/intel/tools/intel_dump_gpu.c
@@ -58,6 +58,7 @@ static FILE *output_file = NULL;
 static int verbose = 0;
 static bool device_override;
 
+#define MAX_FD_COUNT 64
 #define MAX_BO_COUNT 64 * 1024
 
 struct bo {
@@ -94,12 +95,13 @@ fail_if(int cond, const char *format, ...)
 }
 
 static struct bo *
-get_bo(uint32_t handle)
+get_bo(unsigned fd, uint32_t handle)
 {
struct bo *bo;
 
fail_if(handle >= MAX_BO_COUNT, "bo handle too large\n");
-   bo = [handle];
+   fail_if(fd >= MAX_FD_COUNT, "bo fd too large\n");
+   bo = [handle + fd * MAX_BO_COUNT];
 
return bo;
 }
@@ -115,7 +117,7 @@ static uint32_t device = 0;
 static struct aub_file aub_file;
 
 static void *
-relocate_bo(struct bo *bo, const struct drm_i915_gem_execbuffer2 *execbuffer2,
+relocate_bo(int fd, struct bo *bo, const struct drm_i915_gem_execbuffer2 
*execbuffer2,
 const struct drm_i915_gem_exec_object2 *obj)
 {
const struct drm_i915_gem_exec_object2 *exec_objects =
@@ -137,7 +139,7 @@ relocate_bo(struct bo *bo, const struct 
drm_i915_gem_execbuffer2 *execbuffer2,
  handle = relocs[i].target_handle;
 
   aub_write_reloc(, ((char *)relocated) + relocs[i].offset,
-  get_bo(handle)->offset + relocs[i].delta);
+  get_bo(fd, handle)->offset + relocs[i].delta);
}
 
return relocated;
@@ -226,7 +228,7 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 
*execbuffer2)
 
for (uint32_t i = 0; i < execbuffer2->buffer_count; i++) {
   obj = _objects[i];
-  bo = get_bo(obj->handle);
+  bo = get_bo(fd, obj->handle);
 
   /* If bo->size == 0, this means they passed us an invalid
* buffer.  The kernel will reject it and so should we.
@@ -262,13 +264,13 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 
*execbuffer2)
 
batch_index = (execbuffer2->flags & I915_EXEC_BATCH_FIRST) ? 0 :
   execbuffer2->buffer_count - 1;
-   batch_bo = get_bo(exec_objects[batch_index].handle);
+   batch_bo = get_bo(fd, exec_objects[batch_index].handle);
for (uint32_t i = 0; i < execbuffer2->buffer_count; i++) {
   obj = _objects[i];
-  bo = get_bo(obj->handle);
+  bo = get_bo(fd, obj->handle);
 
   if (obj->relocation_count > 0)
- data = relocate_bo(bo, execbuffer2, obj);
+ data = relocate_bo(fd, bo, execbuffer2, obj);
   else
  data = bo->map;
 
@@ -306,11 +308,12 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 
*execbuffer2)
 }
 
 static void
-add_new_bo(int handle, uint64_t size, void *map)
+add_new_bo(unsigned fd, int handle, uint64_t size, void *map)
 {
-   struct bo *bo = [handle];
+   struct bo *bo = [handle + fd * MAX_BO_COUNT];
 
fail_if(handle >= MAX_BO_COUNT, "bo handle out of range\n");
+   fail_if(fd >= MAX_FD_COUNT, "bo fd out of range\n");
fail_if(size == 0, "bo size is invalid\n");
 
bo->size = size;
@@ -318,9 +321,9 @@ add_new_bo(int handle, uint64_t size, void *map)
 }
 
 static void
-remove_bo(int handle)
+remove_bo(int fd, int handle)
 {
-   struct bo *bo = get_bo(handle);
+   struct bo *bo = get_bo(fd, handle);
 
if (bo->map && !IS_USERPTR(bo->map))
   munmap(bo->map, bo->size);
@@ -383,7 +386,7 @@ maybe_init(void)
}
fclose(config);
 
-   bos = calloc(MAX_BO_COUNT, sizeof(bos[0]));
+   bos = calloc(MAX_FD_COUNT * MAX_BO_COUNT, sizeof(bos[0]));
fail_if(bos == NULL, "out of memory\n");
 }
 
@@ -455,7 +458,7 @@ ioctl(int fd, unsigned long request, ...)
 
  ret = libc_ioctl(fd, request, argp);
  if (ret == 0)
-add_new_bo(create->handle, create->size, NULL);
+add_new_bo(fd, create->handle, create->size, NULL);
 
  return ret;
   }
@@ -465,15 +468,16 @@ ioctl(int fd, unsigned long request, ...)
 
  ret = libc_ioctl(fd, request, argp);
  if (ret == 0)
-add_new_bo(userptr->handle, userptr->user_size,
+add_new_bo(fd, userptr->handle, userptr->user_size,

[Mesa-dev] [PATCH] intel/eu: Add an EOT parameter to send_indirect_[split]_message

[Jason Ekstrand]

For split indirect sends we have to put the EOT parameter in the
extended descriptor as well as the instruction itself so just calling
brw_inst_set_eot is insufficient.  Moving the EOT handling handling into
the send_indirect_[split]_message helper lets us handle it properly.
---
 src/intel/compiler/brw_eu.h   |  6 --
 src/intel/compiler/brw_eu_emit.c  | 25 ++-
 src/intel/compiler/brw_fs_generator.cpp   | 11 +-
 src/intel/compiler/brw_vec4_generator.cpp |  6 --
 4 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
index 104cbece9b3..ac8ff69a7e0 100644
--- a/src/intel/compiler/brw_eu.h
+++ b/src/intel/compiler/brw_eu.h
@@ -911,7 +911,8 @@ brw_send_indirect_message(struct brw_codegen *p,
   struct brw_reg dst,
   struct brw_reg payload,
   struct brw_reg desc,
-  unsigned desc_imm);
+  unsigned desc_imm,
+  bool eot);
 
 void
 brw_send_indirect_split_message(struct brw_codegen *p,
@@ -922,7 +923,8 @@ brw_send_indirect_split_message(struct brw_codegen *p,
 struct brw_reg desc,
 unsigned desc_imm,
 struct brw_reg ex_desc,
-unsigned ex_desc_imm);
+unsigned ex_desc_imm,
+bool eot);
 
 void brw_ff_sync(struct brw_codegen *p,
   struct brw_reg dest,
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 9be82d1b87c..4440c84760b 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -2481,7 +2481,8 @@ brw_send_indirect_message(struct brw_codegen *p,
   struct brw_reg dst,
   struct brw_reg payload,
   struct brw_reg desc,
-  unsigned desc_imm)
+  unsigned desc_imm,
+  bool eot)
 {
const struct gen_device_info *devinfo = p->devinfo;
struct brw_inst *send;
@@ -2518,6 +2519,7 @@ brw_send_indirect_message(struct brw_codegen *p,
brw_set_dest(p, send, dst);
brw_set_src0(p, send, retype(payload, BRW_REGISTER_TYPE_UD));
brw_inst_set_sfid(devinfo, send, sfid);
+   brw_inst_set_eot(devinfo, send, eot);
 }
 
 void
@@ -2529,7 +2531,8 @@ brw_send_indirect_split_message(struct brw_codegen *p,
 struct brw_reg desc,
 unsigned desc_imm,
 struct brw_reg ex_desc,
-unsigned ex_desc_imm)
+unsigned ex_desc_imm,
+bool eot)
 {
const struct gen_device_info *devinfo = p->devinfo;
struct brw_inst *send;
@@ -2574,13 +2577,13 @@ brw_send_indirect_split_message(struct brw_codegen *p,
* so the caller can specify additional descriptor bits with the
* desc_imm immediate.
*
-   * Even though the instruction dispatcher always pulls the SFID from the
-   * instruction itself, the extended descriptor sent to the actual unit
-   * gets the SFID from the extended descriptor which comes from the
-   * address register.  If we don't OR it in, the external unit gets
-   * confused and hangs the GPU.
+   * Even though the instruction dispatcher always pulls the SFID and EOT
+   * fields from the instruction itself, actual external unit which
+   * processes the message gets the SFID and EOT from the extended
+   * descriptor which comes from the address register.  If we don't OR
+   * those two bits in, the external unit may get confused and hang.
*/
-  brw_OR(p, addr, ex_desc, brw_imm_ud(ex_desc_imm | sfid));
+  brw_OR(p, addr, ex_desc, brw_imm_ud(ex_desc_imm | sfid | eot << 5));
 
   brw_pop_insn_state(p);
   ex_desc = addr;
@@ -2613,6 +2616,7 @@ brw_send_indirect_split_message(struct brw_codegen *p,
}
 
brw_inst_set_sfid(devinfo, send, sfid);
+   brw_inst_set_eot(devinfo, send, eot);
 }
 
 static void
@@ -2645,7 +2649,7 @@ brw_send_indirect_surface_message(struct brw_codegen *p,
   surface = addr;
}
 
-   brw_send_indirect_message(p, sfid, dst, payload, surface, desc_imm);
+   brw_send_indirect_message(p, sfid, dst, payload, surface, desc_imm, false);
 }
 
 static bool
@@ -3164,7 +3168,8 @@ brw_pixel_interpolator_query(struct brw_codegen *p,
  dest,
  mrf,
  vec1(data),
- desc);
+ desc,
+ false);
 }
 
 void
diff --git a/src/intel/compiler/brw_fs_generator.cpp 

[Mesa-dev] [Bug 109446] Shadow of the Tomb Raider Trial freezes the system at startup

[bugzilla-daemon]

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

--- Comment #4 from fin4...@hotmail.com ---
Feature request: Allow the end user choose the Mesa llvm version.
Why: llvm and Mesa are separate projects and llvm can cause problems in gaming.
Mesa is difficult to build and that is why Oiba ppa uses buggy llvm 7.1.

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

Re: [Mesa-dev] [PATCH] kmsro: Silence warning if missing

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Thu, Feb 7, 2019 at 11:55 PM Eric Anholt  wrote:
>
> Alyssa Rosenzweig  writes:
>
> > Regardless of whether the build uses kmsro, kmsro is the default driver
> > descriptor when the static loader is used. Thus, in an edge case where
> > the static loader is used, no static targets are loaded, and kmsro is
> > not compiled, a spurious warning is printed. There's no harm in
> > executing the stub function in this case, but it's not "an error" to not
> > have kmsro in the build; the driver missing warning should not printed
> > kmsro.
> >
> > Signed-off-by: Alyssa Rosenzweig 
> > Reported-by: Karol Herbst 
>
> Reviewed-by: Eric Anholt 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 5/5] i965: Enabled the OES_copy_image extension on Gen 7 GPUs

[Nanley Chery]

On Thu, Feb 07, 2019 at 07:17:32PM +0200, Eleni Maria Stea wrote:
> On Thu, 7 Feb 2019 11:18:59 -0500
> Ilia Mirkin  wrote:
> 
> > On Thu, Feb 7, 2019 at 2:49 AM Eleni Maria Stea 
> > wrote:
> > >
> > > On Wed, 6 Feb 2019 12:12:27 -0800
> > > Nanley Chery  wrote:
> > >  
> > > > > +   * For now, we can't enable OES_texture_view on Gen 7
> > > > > because of
> > > > > +   * some piglit failures coming from
> > > > > +   * piglit/tests/spec/arb_texture_view/rendering-formats.c
> > > > > that need
> > > > > +   * investigation.
> > > > > */  
> > > >
> > > > What kind of failures are you seeing? I'd imagine texture views to
> > > > work with this version of your series.
> > > >  
> > >
> > > Hi Nanley,
> > >
> > > If you run the piglit test: arb_texture_view-rendering-format, and
> > > grep for failures on HSW:
> > >
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_R32F" : "fail"}}
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16F" : "fail"}}
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16I" : "fail"}}
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16_SNORM" : "fail"}}
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RGBA8I" : "fail"}}
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RGBA8_SNORM" :
> > > "fail"}}
> > >
> > > I remember seeing similar errors on Ivy too. They must be
> > > irrelevant to the ETC support but as this test passes on BDW where
> > > the extension is enabled, I didn't enable it on Gen 7 for the
> > > moment. I think I had discussed about these failures with Kenneth
> > > before I disabled them, but I didn't investigated them further
> > > after that.  
> > 
> > Do you also see the failures with desktop GL (and ARB_texture_view)?
> > If not, that'd be very surprising.
> > 
> > Note that the piglit test arb_texture_view-rendering-formats is the
> > desktop GL test. arb_texture_view-rendering-formats_gles3 is the ES
> > version.
> > 

Good point.

> >   -ilia
> > 
> 
> Hi Ilia,
> 
> I just checked on HSW and IVY with my final patches (sent a few minutes
> before your reply) and:
> 
> HSW:
> 
> extension disabled: the desktop test passes but we receive the following
> error several times:
> 
> User Error: GL_INVALID_OPERATION in glTextureView(internalformat X not
> compatible with origtexture Y) in each subtest.
> 
> extension enabled: I see the same error but now both the desktop and
> gles versions pass (which wasn't the case when I checked last week with
> my previous patches)
> 
> I could probably enable it now on gen >= 75, if you and Nanley (CC-ed)
> are OK with this decision. What do you think?

If I execute the following on my HSW:

$ MESA_EXTENSION_OVERRIDE=GL_OES_texture_view \
  ./bin/arb_texture_view-rendering-formats_gles3 | grep fail

I still get the errors you mentioned above: 

PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_R32F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16I" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16_SNORM" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RGBA8I" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RGBA8_SNORM" : "fail"}}

This is with a mesa that doesn't have your patches applied, but that
shouldn't matter with the formats listed above.

If I ran the test above correctly, I think we should leave it disabled.

-Nanley

> 
> on Ivy:
> ---
> extension disabled: the desktop version of the test
> fails with the failures below (and the gles is skipped) 
> 
> extension enabled: both the desktop and the gles versions
> fail and the failures are the same (see below)
> 
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RG32F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RG32UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RG32I" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RGBA16F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RGBA16UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RGBA16" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGB16_SNORM as GL_RGB16F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGB16_SNORM as GL_RGB16" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_R32F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_R32UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_R32I" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RG16F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RG16UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RG16" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8I" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8_SNORM" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGB10_A2UI" : "fail"}}
> 

Re: [Mesa-dev] [PATCH v3 2/5] i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.

[Nanley Chery]

On Thu, Feb 07, 2019 at 06:00:19PM +0200, Eleni Maria Stea wrote:
> GPUs Gen < 8 cannot sample ETC2 formats. So far, they converted the
> compressed EAC/ETC2 images to non-compressed RGBA images. When
> GetCompressed* functions were called, the pixels were returned in this
> RGBA format and not the compressed format that was expected.
> 
> Trying to fix this problem, we use a secondary shadow miptree to store the
> decompressed data for the rendering and the main miptree to store the
> compressed for the Get functions to work. Each time that the main miptree
> is written with compressed data, we decompress them to RGB and update the
> shadow. Then we use the shadow for rendering.
> 
> v2:
>- Fixes in the commit message (Nanley Chery)
>- Reversed the changes in brw_get_texture_swizzle and swapped the b, g
>values at the time that we decompress the data in the function:
>intel_miptree_update_etc_shadow of intel_mipmap_tree.c (Nanley Chery)
>- Simplified the format checks in the miptree_create function of the
>intel_mipmap_tree.c and reserved the call of the
>intel_lower_compressed_format for the case that we are faking the ETC
>support (Nanley Chery)
>- Removed the check for the auxiliary usage for the shadow miptree at
>creation (miptree_create of intel_mipmap_tree.c) as we won't use
>auxiliary buffers with these types of trees (Nanley Chery)
>- Set the etc_format of the non-ETC miptrees to MESA_FORMAT_NONE and
>removed the unecessary checks (Nanley Chery)
>- Fixed an unrelated indentation change (Nanley Chery)
>- Modified the function intel_miptree_finish_write to set the
>mt->shadow_needs_update to true to catch all the cases when we need to
>update the miptree (Nanley Chery)
>- In order to update the shadow miptree during the unmap of the
>main and always map the main (Nanley Chery) the following change was
>necessary: Splitted the previous update function that was updating all
>the mipmap levels and use two functions instead: one that updates one
>level and one that updates all of them. Used the first during unmap
>and the second before the rendering.
>- Removed the BRW_MAP_ETC_BIT flag and the mechanism to decide which
>miptree should be mapped each time and reversed all the changes in the
>higher level texture functions that upload data to textures as they
>aren't needed anymore.
>- Replaced the boolean needs_fake_etc with an inline function that
>checks when we need to fake the ETC compression (Nanley Chery)
>- Removed the initialization of the strides in the update function as
>the values will be overwritten by the intel_miptree_map call (Nanley
>Chery)
>- Used minify instead of division in the new update function
>intel_miptree_update_etc_shadow_levels in intel_mipmap_tree.c (Nanley
>Chery)
>- Removed the depth from the calculation of the number of slices in
>the new update function (intel_miptree_update_etc_shadow_levels of
>intel_mipmap_tree.c) as we don't need to support 3D ETC images.
>(Nanley Chery)
> 
> v3:
>   - Renamed the rgba_fmt in function miptree_create
>   (intel_mipmap_tree.c) to decomp_format as the format is not always in
>   rgba order. (Nanley Chery)
>   - Documented the new usage for the shadow miptree in the comment above
>   the field in the intel_miptree struct in intel_mipmap_tree.h (Nanley
>   Chery)
>   - Removed the redundant flags from the mapping of the miptrees in
>   intel_miptree_update_etc_shadow of intel_mipmap_tree.c (Nanley Chery)
>   - Fixed the switch from surface's logical level to physical level in
>   the intel_miptree_update_etc_shadow_levels of intel_mipmap_tree.c
>   (Nanley Chery)
>   - Excluded the Baytrail GPUs from the check for the ETC emulation as
>   they support the ETC formats natively. (Nanley Chery)
>   - Simplified the check if the format is BGRA in
>   intel_miptree_update_etc_shadow of intel_mipmap_tree.c (Nanley Chery)
> ---
>  .../drivers/dri/i965/brw_wm_surface_state.c   |   5 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 130 --
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  24 
>  3 files changed, 149 insertions(+), 10 deletions(-)
> 
> 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 618e2ab35bc..c2cf34aee71 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -521,7 +521,7 @@ static void brw_update_texture_surface(struct gl_context 
> *ctx,
>*/
>   mesa_fmt = mt->format;
>} else if (mt->etc_format != MESA_FORMAT_NONE) {
> - mesa_fmt = mt->format;
> + mesa_fmt = mt->shadow_mt->format;
>} else if (plane > 0) {
>   mesa_fmt = mt->format;
>} else {
> @@ -581,6 +581,9 @@ static void brw_update_texture_surface(struct gl_context 
> *ctx,
>  

Re: [Mesa-dev] [PATCH] kmsro: Silence warning if missing

[Eric Anholt]

Alyssa Rosenzweig  writes:

> Regardless of whether the build uses kmsro, kmsro is the default driver
> descriptor when the static loader is used. Thus, in an edge case where
> the static loader is used, no static targets are loaded, and kmsro is
> not compiled, a spurious warning is printed. There's no harm in
> executing the stub function in this case, but it's not "an error" to not
> have kmsro in the build; the driver missing warning should not printed
> kmsro.
>
> Signed-off-by: Alyssa Rosenzweig 
> Reported-by: Karol Herbst 

Reviewed-by: Eric Anholt 


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

[Mesa-dev] [Bug 109535] [Tracker] Mesa 19.0 release tracker

[bugzilla-daemon]

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

Jason Ekstrand  changed:

   What|Removed |Added

 Depends on||109582


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109582
[Bug 109582] Performance regressions in Mesa 19.0.0-rc2
-- 
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 109535] [Tracker] Mesa 19.0 release tracker

[bugzilla-daemon]

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

Jason Ekstrand  changed:

   What|Removed |Added

 Depends on||109581


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109581
[Bug 109581] [BISECTED] Nothing is Rendered on Sascha Willem's "subpasses" demo
-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] radeonsi: use SDMA for uploading data through const_uploader

[Alex Deucher]

On Thu, Feb 7, 2019 at 2:47 PM Axel Davy  wrote:
>
> On 07/02/2019 02:22, Marek Olšák wrote:
> >
> > + bool use_sdma_upload = sscreen->info.has_dedicated_vram && 
> > sctx->dma_cs && debug_get_bool_option("SDMA", true);
> > + sctx->b.const_uploader = u_upload_create(>b, 256 * 1024,
> > +  0, PIPE_USAGE_DEFAULT,
> > +  SI_RESOURCE_FLAG_32BIT |
> > +  (use_sdma_upload ?
> > +   
> > SI_RESOURCE_FLAG_UPLOAD_FLUSH_EXPLICIT_VIA_SDMA :
> > +   
> > (sscreen->cpdma_prefetch_writes_memory ?
> > +0 : 
> > SI_RESOURCE_FLAG_READ_ONLY)));
> > + if (!sctx->b.const_uploader)
> > + goto fail;
> > +
> > + if (use_sdma_upload)
> > + u_upload_enable_flush_explicit(sctx->b.const_uploader);
> > +
>
>
> I see that APU are not affected by the change.
>
> Are they affected by the issue this patch aims to fix though ? If so,
> wouldn't it make sense to switch to PIPE_USAGE_STREAM for APUs ?

They are not affected.  "VRAM" on APUs is just carved out system
memory so the driver can access it directly.  No need to go through
the PCI BAR interface.  All of "VRAM" is visible to the CPU on APUs.

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

Re: [Mesa-dev] [PATCH 4/4] radeonsi: use SDMA for uploading data through const_uploader

[Axel Davy]

On 07/02/2019 02:22, Marek Olšák wrote:
  
+	bool use_sdma_upload = sscreen->info.has_dedicated_vram && sctx->dma_cs && debug_get_bool_option("SDMA", true);

+   sctx->b.const_uploader = u_upload_create(>b, 256 * 1024,
+0, PIPE_USAGE_DEFAULT,
+SI_RESOURCE_FLAG_32BIT |
+(use_sdma_upload ?
+ 
SI_RESOURCE_FLAG_UPLOAD_FLUSH_EXPLICIT_VIA_SDMA :
+ 
(sscreen->cpdma_prefetch_writes_memory ?
+  0 : 
SI_RESOURCE_FLAG_READ_ONLY)));
+   if (!sctx->b.const_uploader)
+   goto fail;
+
+   if (use_sdma_upload)
+   u_upload_enable_flush_explicit(sctx->b.const_uploader);
+



I see that APU are not affected by the change.

Are they affected by the issue this patch aims to fix though ? If so, 
wouldn't it make sense to switch to PIPE_USAGE_STREAM for APUs ?



Axel

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

[Mesa-dev] [Bug 109543] After upgrade mesa to 19.0.0~rc1 all vulkan based application stop working ["vulkan-cube" received SIGSEGV in radv_pipeline_init_blend_state at ../src/amd/vulkan/radv_pipeline.

[bugzilla-daemon]

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

--- Comment #10 from Gustaw Smolarczyk  ---
Hi,

After messing for a while with godbolt, it seems like GCC 9 considers literal
scope to end with a block and not a function [1], or at least this is my
assumption. In the godbolt example you can see the "1" assignments being
dropped from the assembly when they are inside the switch scope.

When a literal assignment (like the following in radv_meta_blit.c
build_pipeline function) happens inside a switch case, GCC 9 probably drops it:

--- SNIP ---

switch(aspect) {
case VK_IMAGE_ASPECT_COLOR_BIT:
vk_pipeline_info.pColorBlendState =
&(VkPipelineColorBlendStateCreateInfo) {
.sType =
VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_STATE_CREATE_INFO,
.attachmentCount = 1,
.pAttachments = (VkPipelineColorBlendAttachmentState []) {
{ .colorWriteMask =
VK_COLOR_COMPONENT_A_BIT |
VK_COLOR_COMPONENT_R_BIT |
VK_COLOR_COMPONENT_G_BIT |
VK_COLOR_COMPONENT_B_BIT },
}
};
break;

--- SNIP ---

You could work this around by giving names to the literals and putting them in
the function scope (not inside any block). As I am not familiar with the C
standard, I am not sure if what GCC 9 assumes is legal or not.


[1] https://godbolt.org/z/wTuMH-

-- 
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 109543] After upgrade mesa to 19.0.0~rc1 all vulkan based application stop working ["vulkan-cube" received SIGSEGV in radv_pipeline_init_blend_state at ../src/amd/vulkan/radv_pipeline.

[bugzilla-daemon]

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

--- Comment #9 from mikhail.v.gavri...@gmail.com ---
With mesa 19.0.0 rc2 I has same crashes.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1206254

-- 
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 109543] After upgrade mesa to 19.0.0~rc1 all vulkan based application stop working ["vulkan-cube" received SIGSEGV in radv_pipeline_init_blend_state at ../src/amd/vulkan/radv_pipeline.

[bugzilla-daemon]

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

--- Comment #8 from mikhail.v.gavri...@gmail.com ---
Created attachment 143323
  --> https://bugs.freedesktop.org/attachment.cgi?id=143323=edit
vulkan-cube backtrace + mesa 19.0.0 rc2

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

Re: [Mesa-dev] [PATCH v2 5/5] i965: Enabled the OES_copy_image extension on Gen 7 GPUs

[Ilia Mirkin]

On Thu, Feb 7, 2019 at 12:17 PM Eleni Maria Stea  wrote:
>
> On Thu, 7 Feb 2019 11:18:59 -0500
> Ilia Mirkin  wrote:
>
> > On Thu, Feb 7, 2019 at 2:49 AM Eleni Maria Stea 
> > wrote:
> > >
> > > On Wed, 6 Feb 2019 12:12:27 -0800
> > > Nanley Chery  wrote:
> > >
> > > > > +   * For now, we can't enable OES_texture_view on Gen 7
> > > > > because of
> > > > > +   * some piglit failures coming from
> > > > > +   * piglit/tests/spec/arb_texture_view/rendering-formats.c
> > > > > that need
> > > > > +   * investigation.
> > > > > */
> > > >
> > > > What kind of failures are you seeing? I'd imagine texture views to
> > > > work with this version of your series.
> > > >
> > >
> > > Hi Nanley,
> > >
> > > If you run the piglit test: arb_texture_view-rendering-format, and
> > > grep for failures on HSW:
> > >
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_R32F" : "fail"}}
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16F" : "fail"}}
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16I" : "fail"}}
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16_SNORM" : "fail"}}
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RGBA8I" : "fail"}}
> > > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RGBA8_SNORM" :
> > > "fail"}}
> > >
> > > I remember seeing similar errors on Ivy too. They must be
> > > irrelevant to the ETC support but as this test passes on BDW where
> > > the extension is enabled, I didn't enable it on Gen 7 for the
> > > moment. I think I had discussed about these failures with Kenneth
> > > before I disabled them, but I didn't investigated them further
> > > after that.
> >
> > Do you also see the failures with desktop GL (and ARB_texture_view)?
> > If not, that'd be very surprising.
> >
> > Note that the piglit test arb_texture_view-rendering-formats is the
> > desktop GL test. arb_texture_view-rendering-formats_gles3 is the ES
> > version.
> >
> >   -ilia
> >
>
> Hi Ilia,
>
> I just checked on HSW and IVY with my final patches (sent a few minutes
> before your reply) and:
>
> HSW:
> 
> extension disabled: the desktop test passes but we receive the following
> error several times:
>
> User Error: GL_INVALID_OPERATION in glTextureView(internalformat X not
> compatible with origtexture Y) in each subtest.
>
> extension enabled: I see the same error but now both the desktop and
> gles versions pass (which wasn't the case when I checked last week with
> my previous patches)
>
> I could probably enable it now on gen >= 75, if you and Nanley (CC-ed)
> are OK with this decision. What do you think?
>
> on Ivy:
> ---
> extension disabled: the desktop version of the test
> fails with the failures below (and the gles is skipped)
>
> extension enabled: both the desktop and the gles versions
> fail and the failures are the same (see below)
>
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RG32F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RG32UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RG32I" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RGBA16F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RGBA16UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RGBA16" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGB16_SNORM as GL_RGB16F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGB16_SNORM as GL_RGB16" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_R32F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_R32UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_R32I" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RG16F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RG16UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RG16" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8I" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8_SNORM" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGB10_A2UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGB10_A2" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8 as GL_R32F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_R32F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_R32UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_R32I" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RG16F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RG16UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RG16I" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RG16" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RG16_SNORM" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RGBA8UI" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RGBA8" : "fail"}}
> PIGLIT: 

Re: [Mesa-dev] [PATCH] freedreno: Fix meson build.

[Kristian Høgsberg]

On Thu, Feb 7, 2019 at 8:03 AM Daniel Stone  wrote:
>
> On Thu, 7 Feb 2019 at 14:59, Eric Engestrom  wrote:
> > On Wednesday, 2019-02-06 18:36:09 +, Vinson Lee wrote:
> > > ../src/gallium/drivers/freedreno/freedreno_resource.c: In function 
> > > ‘fd_resource_create_with_modifiers’:
> > > ../src/gallium/drivers/freedreno/freedreno_resource.c:884:30: error: 
> > > ‘DRM_FORMAT_MOD_QCOM_COMPRESSED’ undeclared (first use in this function)
> > >allow_ubwc = find_modifier(DRM_FORMAT_MOD_QCOM_COMPRESSED, modifiers, 
> > > count);
> >
> > That's a weird error... I would've expected the `#include `
> > to fail with a "No such file". If you copied the wrong part of the error
> > message, can you update that?
>
> Presumably it just finds an outdated copy of drm_fourcc.h, which
> doesn't have the Qualcomm modifier, from the system include path.

Yes - I recommend not having include/drm-uapi in the include path and
instead include kernel headers as #include "drm-uapi/drm_fourcc.h" to
avoid pulling in system headers.

Kristian

> Cheers,
> Daniel
> ___
> 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 v2 5/5] i965: Enabled the OES_copy_image extension on Gen 7 GPUs

[Eleni Maria Stea]

On Thu, 7 Feb 2019 11:18:59 -0500
Ilia Mirkin  wrote:

> On Thu, Feb 7, 2019 at 2:49 AM Eleni Maria Stea 
> wrote:
> >
> > On Wed, 6 Feb 2019 12:12:27 -0800
> > Nanley Chery  wrote:
> >  
> > > > +   * For now, we can't enable OES_texture_view on Gen 7
> > > > because of
> > > > +   * some piglit failures coming from
> > > > +   * piglit/tests/spec/arb_texture_view/rendering-formats.c
> > > > that need
> > > > +   * investigation.
> > > > */  
> > >
> > > What kind of failures are you seeing? I'd imagine texture views to
> > > work with this version of your series.
> > >  
> >
> > Hi Nanley,
> >
> > If you run the piglit test: arb_texture_view-rendering-format, and
> > grep for failures on HSW:
> >
> > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_R32F" : "fail"}}
> > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16F" : "fail"}}
> > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16I" : "fail"}}
> > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16_SNORM" : "fail"}}
> > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RGBA8I" : "fail"}}
> > PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RGBA8_SNORM" :
> > "fail"}}
> >
> > I remember seeing similar errors on Ivy too. They must be
> > irrelevant to the ETC support but as this test passes on BDW where
> > the extension is enabled, I didn't enable it on Gen 7 for the
> > moment. I think I had discussed about these failures with Kenneth
> > before I disabled them, but I didn't investigated them further
> > after that.  
> 
> Do you also see the failures with desktop GL (and ARB_texture_view)?
> If not, that'd be very surprising.
> 
> Note that the piglit test arb_texture_view-rendering-formats is the
> desktop GL test. arb_texture_view-rendering-formats_gles3 is the ES
> version.
> 
>   -ilia
> 

Hi Ilia,

I just checked on HSW and IVY with my final patches (sent a few minutes
before your reply) and:

HSW:

extension disabled: the desktop test passes but we receive the following
error several times:

User Error: GL_INVALID_OPERATION in glTextureView(internalformat X not
compatible with origtexture Y) in each subtest.

extension enabled: I see the same error but now both the desktop and
gles versions pass (which wasn't the case when I checked last week with
my previous patches)

I could probably enable it now on gen >= 75, if you and Nanley (CC-ed)
are OK with this decision. What do you think?

on Ivy:
---
extension disabled: the desktop version of the test
fails with the failures below (and the gles is skipped) 

extension enabled: both the desktop and the gles versions
fail and the failures are the same (see below)

PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RG32F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RG32UI" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RG32I" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RGBA16F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RGBA16UI" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA16_SNORM as GL_RGBA16" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGB16_SNORM as GL_RGB16F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGB16_SNORM as GL_RGB16" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_R32F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_R32UI" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_R32I" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RG16F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RG16UI" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RG16" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8UI" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8I" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGBA8_SNORM" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGB10_A2UI" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RG16_SNORM as GL_RGB10_A2" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8 as GL_R32F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_R32F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_R32UI" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_R32I" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RG16F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RG16UI" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RG16I" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RG16" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RG16_SNORM" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RGBA8UI" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RGBA8" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RGB10_A2UI" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGBA8_SNORM as GL_RGB10_A2" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_R32F" : "fail"}}
PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16F" : 

[Mesa-dev] [Bug 109575] Mesa-19.0.0-rc1 : Computer Crashes trying to run anything Vulkan

[bugzilla-daemon]

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

--- Comment #4 from LunarG  ---
I'm also seeing this same system crash on Ubuntu 18.04.1 using Radeon R9 380
card.

Happens when trying to run Sascha Willems Bloom sample.

-- 
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 3/6] gallium/auxiliary/vl: Rename csc_matrix and increase its size.

[Zhu, James]

Rename csc_matrix to shader_params, and increase shader_params size
to store more constants for compute shader,

Signed-off-by: James Zhu 
Reviewed-by: Christian König 
---
 src/gallium/auxiliary/vl/vl_compositor.c | 10 +-
 src/gallium/auxiliary/vl/vl_compositor.h |  2 +-
 src/gallium/auxiliary/vl/vl_compositor_gfx.c |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index de6cf17..4509913 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -439,7 +439,7 @@ vl_compositor_set_csc_matrix(struct vl_compositor_state *s,
 
assert(s);
 
-   float *ptr = pipe_buffer_map(s->pipe, s->csc_matrix,
+   float *ptr = pipe_buffer_map(s->pipe, s->shader_params,
PIPE_TRANSFER_WRITE | 
PIPE_TRANSFER_DISCARD_RANGE,
_transfer);
 
@@ -750,15 +750,15 @@ vl_compositor_init_state(struct vl_compositor_state *s, 
struct pipe_context *pip
 * Const buffer contains the color conversion matrix and bias vectors
 */
/* XXX: Create with IMMUTABLE/STATIC... although it does change every once 
in a long while... */
-   s->csc_matrix = pipe_buffer_create_const0
+   s->shader_params = pipe_buffer_create_const0
(
   pipe->screen,
   PIPE_BIND_CONSTANT_BUFFER,
   PIPE_USAGE_DEFAULT,
-  sizeof(csc_matrix) + 2*sizeof(float)
+  sizeof(csc_matrix) + 4*sizeof(float) + 6*sizeof(int)
);
 
-   if (!s->csc_matrix)
+   if (!s->shader_params)
   return false;
 
vl_compositor_clear_layers(s);
@@ -776,5 +776,5 @@ vl_compositor_cleanup_state(struct vl_compositor_state *s)
assert(s);
 
vl_compositor_clear_layers(s);
-   pipe_resource_reference(>csc_matrix, NULL);
+   pipe_resource_reference(>shader_params, NULL);
 }
diff --git a/src/gallium/auxiliary/vl/vl_compositor.h 
b/src/gallium/auxiliary/vl/vl_compositor.h
index aa843c3..c34bad0 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.h
+++ b/src/gallium/auxiliary/vl/vl_compositor.h
@@ -90,7 +90,7 @@ struct vl_compositor_state
 
bool scissor_valid;
struct pipe_scissor_state scissor;
-   struct pipe_resource *csc_matrix;
+   struct pipe_resource *shader_params;
 
union pipe_color_union clear_color;
 
diff --git a/src/gallium/auxiliary/vl/vl_compositor_gfx.c 
b/src/gallium/auxiliary/vl/vl_compositor_gfx.c
index 93e418a..62db005 100644
--- a/src/gallium/auxiliary/vl/vl_compositor_gfx.c
+++ b/src/gallium/auxiliary/vl/vl_compositor_gfx.c
@@ -719,7 +719,7 @@ vl_compositor_gfx_render(struct vl_compositor_state *s,
c->pipe->bind_vs_state(c->pipe, c->vs);
c->pipe->set_vertex_buffers(c->pipe, 0, 1, >vertex_buf);
c->pipe->bind_vertex_elements_state(c->pipe, c->vertex_elems_state);
-   pipe_set_constant_buffer(c->pipe, PIPE_SHADER_FRAGMENT, 0, s->csc_matrix);
+   pipe_set_constant_buffer(c->pipe, PIPE_SHADER_FRAGMENT, 0, 
s->shader_params);
c->pipe->bind_rasterizer_state(c->pipe, c->rast);
 
draw_layers(c, s, dirty_area);
-- 
2.7.4

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

[Mesa-dev] [PATCH v3 5/6] gallium/auxiliary/vl: Add compute shader initilization, assign and cleanup

[Zhu, James]

Add compute shader initilization, assign and cleanup in vl_compositor API.

Signed-off-by: James Zhu 
Reviewed-by: Christian König 
---
 src/gallium/auxiliary/vl/vl_compositor.c | 31 ++-
 src/gallium/auxiliary/vl/vl_compositor.h |  3 +++
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index 4509913..da4b02d 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -28,12 +28,31 @@
 #include "util/u_sampler.h"
 
 #include "vl_compositor_gfx.h"
+#include "vl_compositor_cs.h"
 
 static bool
 init_shaders(struct vl_compositor *c)
 {
assert(c);
 
+   c->cs_video_buffer = vl_compositor_cs_create_shader(c, 
compute_shader_video_buffer);
+   if (!c->cs_video_buffer) {
+  debug_printf("Unable to create video_buffer compute shader.\n");
+  return false;
+   }
+
+   c->cs_weave_rgb = vl_compositor_cs_create_shader(c, compute_shader_weave);
+   if (!c->cs_weave_rgb) {
+  debug_printf("Unable to create weave_rgb compute shader.\n");
+  return false;
+   }
+
+   c->cs_rgba = vl_compositor_cs_create_shader(c, compute_shader_rgba);
+   if (!c->cs_rgba) {
+  debug_printf("Unable to create RGB-to-RGB compute shader.\n");
+  return false;
+   }
+
c->vs = create_vert_shader(c);
if (!c->vs) {
   debug_printf("Unable to create vertex shader.\n");
@@ -106,6 +125,9 @@ static void cleanup_shaders(struct vl_compositor *c)
c->pipe->delete_fs_state(c->pipe, c->fs_rgba);
c->pipe->delete_fs_state(c->pipe, c->fs_rgb_yuv.y);
c->pipe->delete_fs_state(c->pipe, c->fs_rgb_yuv.uv);
+   c->pipe->delete_compute_state(c->pipe, c->cs_video_buffer);
+   c->pipe->delete_compute_state(c->pipe, c->cs_weave_rgb);
+   c->pipe->delete_compute_state(c->pipe, c->cs_rgba);
 }
 
 static bool
@@ -409,6 +431,7 @@ vl_compositor_clear_layers(struct vl_compositor_state *s)
   s->layers[i].clearing = i ? false : true;
   s->layers[i].blend = NULL;
   s->layers[i].fs = NULL;
+  s->layers[i].cs = NULL;
   s->layers[i].viewport.scale[2] = 1;
   s->layers[i].viewport.translate[2] = 0;
   s->layers[i].rotate = VL_COMPOSITOR_ROTATE_0;
@@ -533,6 +556,7 @@ vl_compositor_set_buffer_layer(struct vl_compositor_state 
*s,
   switch(deinterlace) {
   case VL_COMPOSITOR_WEAVE:
  s->layers[layer].fs = c->fs_weave_rgb;
+ s->layers[layer].cs = c->cs_weave_rgb;
  break;
 
   case VL_COMPOSITOR_BOB_TOP:
@@ -540,6 +564,7 @@ vl_compositor_set_buffer_layer(struct vl_compositor_state 
*s,
  s->layers[layer].src.tl.y += half_a_line;
  s->layers[layer].src.br.y += half_a_line;
  s->layers[layer].fs = c->fs_video_buffer;
+ s->layers[layer].cs = c->cs_video_buffer;
  break;
 
   case VL_COMPOSITOR_BOB_BOTTOM:
@@ -547,11 +572,14 @@ vl_compositor_set_buffer_layer(struct vl_compositor_state 
*s,
  s->layers[layer].src.tl.y -= half_a_line;
  s->layers[layer].src.br.y -= half_a_line;
  s->layers[layer].fs = c->fs_video_buffer;
+ s->layers[layer].cs = c->cs_video_buffer;
  break;
   }
 
-   } else
+   } else {
   s->layers[layer].fs = c->fs_video_buffer;
+  s->layers[layer].cs = c->cs_video_buffer;
+   }
 }
 
 void
@@ -601,6 +629,7 @@ vl_compositor_set_rgba_layer(struct vl_compositor_state *s,
 
s->used_layers |= 1 << layer;
s->layers[layer].fs = c->fs_rgba;
+   s->layers[layer].cs = c->cs_rgba;
s->layers[layer].samplers[0] = c->sampler_linear;
s->layers[layer].samplers[1] = NULL;
s->layers[layer].samplers[2] = NULL;
diff --git a/src/gallium/auxiliary/vl/vl_compositor.h 
b/src/gallium/auxiliary/vl/vl_compositor.h
index 5fa1b6c..b0ed7f5 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.h
+++ b/src/gallium/auxiliary/vl/vl_compositor.h
@@ -117,6 +117,9 @@ struct vl_compositor
void *fs_video_buffer;
void *fs_weave_rgb;
void *fs_rgba;
+   void *cs_video_buffer;
+   void *cs_weave_rgb;
+   void *cs_rgba;
 
struct {
   struct {
-- 
2.7.4

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

[Mesa-dev] [PATCH v3 6/6] gallium/auxiliary/vl: Add video compute shader render

[Zhu, James]

Add video compute shader render and set it to default when
pipe support it.

Signed-off-by: James Zhu 
Reviewed-by: Christian König 
---
 src/gallium/auxiliary/vl/vl_compositor.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index da4b02d..5308887 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -730,7 +730,12 @@ vl_compositor_render(struct vl_compositor_state *s,
  boolclear_dirty)
 {
assert(s);
-   vl_compositor_gfx_render(s, c, dst_surface, dirty_area, clear_dirty);
+
+   if (c->pipe->screen->get_param(c->pipe->screen, PIPE_CAP_COMPUTE) &&
+   s->layers->cs)
+  vl_compositor_cs_render(s, c, dst_surface, dirty_area, clear_dirty);
+   else
+  vl_compositor_gfx_render(s, c, dst_surface, dirty_area, clear_dirty);
 }
 
 bool
-- 
2.7.4

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

[Mesa-dev] [PATCH v3 0/6] Add compute shader support on video compositor render

[Zhu, James]

V3:
  Rename csc_matrix to shader_params
  Remove debug option CS_COMPOSITOR_RENDER, and set compute shader video 
compositor render as default when hardware supports.

James Zhu (6):
  gallium/auxiliary/vl: Move dirty define to header file
  gallium/auxiliary/vl: Split vl_compositor graphic shaders from
vl_compositor API
  gallium/auxiliary/vl: Rename csc_matrix and increase its size.
  gallium/auxiliary/vl: Add compute shader to support video compositor
render
  gallium/auxiliary/vl: Add compute shader initilization, assign and
cleanup
  gallium/auxiliary/vl: Add video compute shader render

 src/gallium/auxiliary/Makefile.sources   |   4 +
 src/gallium/auxiliary/meson.build|   4 +
 src/gallium/auxiliary/vl/vl_compositor.c | 732 ++-
 src/gallium/auxiliary/vl/vl_compositor.h |   8 +-
 src/gallium/auxiliary/vl/vl_compositor_cs.c  | 408 +++
 src/gallium/auxiliary/vl/vl_compositor_cs.h  |  56 ++
 src/gallium/auxiliary/vl/vl_compositor_gfx.c | 726 ++
 src/gallium/auxiliary/vl/vl_compositor_gfx.h |  88 
 8 files changed, 1332 insertions(+), 694 deletions(-)
 create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.c
 create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.h
 create mode 100644 src/gallium/auxiliary/vl/vl_compositor_gfx.c
 create mode 100644 src/gallium/auxiliary/vl/vl_compositor_gfx.h

-- 
2.7.4

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

[Mesa-dev] [PATCH v3 2/6] gallium/auxiliary/vl: Split vl_compositor graphic shaders from vl_compositor API

[Zhu, James]

Split vl_compositor graphic shaders from vl_compositor API in order to share
vl_compositor API with vl_compositor compute shader later.

Signed-off-by: James Zhu 
Reviewed-by: Christian König 
---
 src/gallium/auxiliary/Makefile.sources   |   2 +
 src/gallium/auxiliary/meson.build|   2 +
 src/gallium/auxiliary/vl/vl_compositor.c | 691 +
 src/gallium/auxiliary/vl/vl_compositor_gfx.c | 726 +++
 src/gallium/auxiliary/vl/vl_compositor_gfx.h |  88 
 5 files changed, 821 insertions(+), 688 deletions(-)
 create mode 100644 src/gallium/auxiliary/vl/vl_compositor_gfx.c
 create mode 100644 src/gallium/auxiliary/vl/vl_compositor_gfx.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index 50e8808..a40917b 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -348,6 +348,8 @@ VL_SOURCES := \
vl/vl_bicubic_filter.h \
vl/vl_compositor.c \
vl/vl_compositor.h \
+   vl/vl_compositor_gfx.c \
+   vl/vl_compositor_gfx.h \
vl/vl_csc.c \
vl/vl_csc.h \
vl/vl_decoder.c \
diff --git a/src/gallium/auxiliary/meson.build 
b/src/gallium/auxiliary/meson.build
index 57f7e69..97063b4 100644
--- a/src/gallium/auxiliary/meson.build
+++ b/src/gallium/auxiliary/meson.build
@@ -445,6 +445,8 @@ files_libgalliumvl = files(
   'vl/vl_bicubic_filter.h',
   'vl/vl_compositor.c',
   'vl/vl_compositor.h',
+  'vl/vl_compositor_gfx.c',
+  'vl/vl_compositor_gfx.h',
   'vl/vl_csc.c',
   'vl/vl_csc.h',
   'vl/vl_decoder.c',
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index 41f9e5e..de6cf17 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -25,447 +25,9 @@
  *
  **/
 
-#include 
-
-#include "pipe/p_compiler.h"
-#include "pipe/p_context.h"
-
-#include "util/u_memory.h"
-#include "util/u_draw.h"
-#include "util/u_surface.h"
-#include "util/u_upload_mgr.h"
 #include "util/u_sampler.h"
 
-#include "tgsi/tgsi_ureg.h"
-
-#include "vl_csc.h"
-#include "vl_types.h"
-#include "vl_compositor.h"
-
-enum VS_OUTPUT
-{
-   VS_O_VPOS = 0,
-   VS_O_COLOR = 0,
-   VS_O_VTEX = 0,
-   VS_O_VTOP,
-   VS_O_VBOTTOM,
-};
-
-static void *
-create_vert_shader(struct vl_compositor *c)
-{
-   struct ureg_program *shader;
-   struct ureg_src vpos, vtex, color;
-   struct ureg_dst tmp;
-   struct ureg_dst o_vpos, o_vtex, o_color;
-   struct ureg_dst o_vtop, o_vbottom;
-
-   shader = ureg_create(PIPE_SHADER_VERTEX);
-   if (!shader)
-  return false;
-
-   vpos = ureg_DECL_vs_input(shader, 0);
-   vtex = ureg_DECL_vs_input(shader, 1);
-   color = ureg_DECL_vs_input(shader, 2);
-   tmp = ureg_DECL_temporary(shader);
-   o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
-   o_color = ureg_DECL_output(shader, TGSI_SEMANTIC_COLOR, VS_O_COLOR);
-   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
-   o_vtop = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTOP);
-   o_vbottom = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VBOTTOM);
-
-   /*
-* o_vpos = vpos
-* o_vtex = vtex
-* o_color = color
-*/
-   ureg_MOV(shader, o_vpos, vpos);
-   ureg_MOV(shader, o_vtex, vtex);
-   ureg_MOV(shader, o_color, color);
-
-   /*
-* tmp.x = vtex.w / 2
-* tmp.y = vtex.w / 4
-*
-* o_vtop.x = vtex.x
-* o_vtop.y = vtex.y * tmp.x + 0.25f
-* o_vtop.z = vtex.y * tmp.y + 0.25f
-* o_vtop.w = 1 / tmp.x
-*
-* o_vbottom.x = vtex.x
-* o_vbottom.y = vtex.y * tmp.x - 0.25f
-* o_vbottom.z = vtex.y * tmp.y - 0.25f
-* o_vbottom.w = 1 / tmp.y
-*/
-   ureg_MUL(shader, ureg_writemask(tmp, TGSI_WRITEMASK_X),
-ureg_scalar(vtex, TGSI_SWIZZLE_W), ureg_imm1f(shader, 0.5f));
-   ureg_MUL(shader, ureg_writemask(tmp, TGSI_WRITEMASK_Y),
-ureg_scalar(vtex, TGSI_SWIZZLE_W), ureg_imm1f(shader, 0.25f));
-
-   ureg_MOV(shader, ureg_writemask(o_vtop, TGSI_WRITEMASK_X), vtex);
-   ureg_MAD(shader, ureg_writemask(o_vtop, TGSI_WRITEMASK_Y), 
ureg_scalar(vtex, TGSI_SWIZZLE_Y),
-ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_X), ureg_imm1f(shader, 
0.25f));
-   ureg_MAD(shader, ureg_writemask(o_vtop, TGSI_WRITEMASK_Z), 
ureg_scalar(vtex, TGSI_SWIZZLE_Y),
-ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_Y), ureg_imm1f(shader, 
0.25f));
-   ureg_RCP(shader, ureg_writemask(o_vtop, TGSI_WRITEMASK_W),
-ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_X));
-
-   ureg_MOV(shader, ureg_writemask(o_vbottom, TGSI_WRITEMASK_X), vtex);
-   ureg_MAD(shader, ureg_writemask(o_vbottom, TGSI_WRITEMASK_Y), 
ureg_scalar(vtex, TGSI_SWIZZLE_Y),
-ureg_scalar(ureg_src(tmp), TGSI_SWIZZLE_X), ureg_imm1f(shader, 
-0.25f));
-   ureg_MAD(shader, ureg_writemask(o_vbottom, TGSI_WRITEMASK_Z), 
ureg_scalar(vtex, 

[Mesa-dev] [PATCH v3 4/6] gallium/auxiliary/vl: Add compute shader to support video compositor render

[Zhu, James]

Add compute shader to support video compositor render.

Signed-off-by: James Zhu 
Acked-by: Christian König 
---
 src/gallium/auxiliary/Makefile.sources  |   2 +
 src/gallium/auxiliary/meson.build   |   2 +
 src/gallium/auxiliary/vl/vl_compositor.h|   1 +
 src/gallium/auxiliary/vl/vl_compositor_cs.c | 408 
 src/gallium/auxiliary/vl/vl_compositor_cs.h |  56 
 5 files changed, 469 insertions(+)
 create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.c
 create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index a40917b..02cc5df 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -350,6 +350,8 @@ VL_SOURCES := \
vl/vl_compositor.h \
vl/vl_compositor_gfx.c \
vl/vl_compositor_gfx.h \
+   vl/vl_compositor_cs.c \
+   vl/vl_compositor_cs.h \
vl/vl_csc.c \
vl/vl_csc.h \
vl/vl_decoder.c \
diff --git a/src/gallium/auxiliary/meson.build 
b/src/gallium/auxiliary/meson.build
index 97063b4..6e5109e 100644
--- a/src/gallium/auxiliary/meson.build
+++ b/src/gallium/auxiliary/meson.build
@@ -447,6 +447,8 @@ files_libgalliumvl = files(
   'vl/vl_compositor.h',
   'vl/vl_compositor_gfx.c',
   'vl/vl_compositor_gfx.h',
+  'vl/vl_compositor_cs.c',
+  'vl/vl_compositor_cs.h',
   'vl/vl_csc.c',
   'vl/vl_csc.h',
   'vl/vl_decoder.c',
diff --git a/src/gallium/auxiliary/vl/vl_compositor.h 
b/src/gallium/auxiliary/vl/vl_compositor.h
index c34bad0..5fa1b6c 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.h
+++ b/src/gallium/auxiliary/vl/vl_compositor.h
@@ -72,6 +72,7 @@ struct vl_compositor_layer
struct pipe_viewport_state viewport;
 
void *fs;
+   void *cs;
void *samplers[3];
void *blend;
 
diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c 
b/src/gallium/auxiliary/vl/vl_compositor_cs.c
new file mode 100644
index 000..8ab44f3
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c
@@ -0,0 +1,408 @@
+/**
+ *
+ * Copyright 2019 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: James Zhu 
+ *
+ **/
+
+#include 
+
+#include "tgsi/tgsi_text.h"
+#include "vl_compositor_cs.h"
+
+struct cs_viewport {
+   float scale_x;
+   float scale_y;
+   struct u_rect area;
+   int translate_x;
+   int translate_y;
+};
+
+char *compute_shader_video_buffer =
+  "COMP\n"
+  "PROPERTY CS_FIXED_BLOCK_WIDTH 8\n"
+  "PROPERTY CS_FIXED_BLOCK_HEIGHT 8\n"
+  "PROPERTY CS_FIXED_BLOCK_DEPTH 1\n"
+
+  "DCL SV[0], THREAD_ID\n"
+  "DCL SV[1], BLOCK_ID\n"
+
+  "DCL CONST[0..5]\n"
+  "DCL SVIEW[0..2], RECT, FLOAT\n"
+  "DCL SAMP[0..2]\n"
+
+  "DCL IMAGE[0], 2D, WR\n"
+  "DCL TEMP[0..7]\n"
+
+  "IMM[0] UINT32 { 8, 8, 1, 0}\n"
+  "IMM[1] FLT32 { 1.0, 2.0, 0.0, 0.0}\n"
+
+  "UMAD TEMP[0], SV[1], IMM[0], SV[0]\n"
+
+  /* Drawn area check */
+  "USGE TEMP[1].xy, TEMP[0].xyxy, CONST[4].xyxy\n"
+  "USLT TEMP[1].zw, TEMP[0].xyxy, CONST[4].zwzw\n"
+  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
+  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
+  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
+
+  "UIF TEMP[1]\n"
+ /* Translate */
+ "UADD TEMP[2].xy, TEMP[0], -CONST[5].xyxy\n"
+ "U2F TEMP[2], TEMP[2]\n"
+ "DIV TEMP[3], TEMP[2], IMM[1].\n"
+
+ /* Scale */
+ "DIV TEMP[2], TEMP[2], CONST[3].zwzw\n"
+ "DIV TEMP[3], TEMP[3], CONST[3].zwzw\n"
+
+ /* Fetch texels */
+ "TEX_LZ TEMP[4].x, TEMP[2], SAMP[0], RECT\n"
+ "TEX_LZ TEMP[4].y, TEMP[3], SAMP[1], RECT\n"

[Mesa-dev] [PATCH v3 1/6] gallium/auxiliary/vl: Move dirty define to header file

[Zhu, James]

Move dirty define to header file to share with compute shader.

Signed-off-by: James Zhu 
Reviewed-by: Christian König 
---
 src/gallium/auxiliary/vl/vl_compositor.c | 15 ++-
 src/gallium/auxiliary/vl/vl_compositor.h |  2 ++
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index 159a295..41f9e5e 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -42,9 +42,6 @@
 #include "vl_types.h"
 #include "vl_compositor.h"
 
-#define MIN_DIRTY (0)
-#define MAX_DIRTY (1 << 15)
-
 enum VS_OUTPUT
 {
VS_O_VPOS = 0,
@@ -899,8 +896,8 @@ gen_vertex_data(struct vl_compositor *c, struct 
vl_compositor_state *s, struct u
  dirty->y1 <= drawn.y1) {
 
// We clear the dirty area anyway, no need for 
clear_render_target
-   dirty->x0 = dirty->y0 = MAX_DIRTY;
-   dirty->x1 = dirty->y1 = MIN_DIRTY;
+   dirty->x0 = dirty->y0 = VL_COMPOSITOR_MAX_DIRTY;
+   dirty->x1 = dirty->y1 = VL_COMPOSITOR_MIN_DIRTY;
 }
  }
   }
@@ -1030,8 +1027,8 @@ vl_compositor_reset_dirty_area(struct u_rect *dirty)
 {
assert(dirty);
 
-   dirty->x0 = dirty->y0 = MIN_DIRTY;
-   dirty->x1 = dirty->y1 = MAX_DIRTY;
+   dirty->x0 = dirty->y0 = VL_COMPOSITOR_MIN_DIRTY;
+   dirty->x1 = dirty->y1 = VL_COMPOSITOR_MAX_DIRTY;
 }
 
 void
@@ -1378,8 +1375,8 @@ vl_compositor_render(struct vl_compositor_state *s,
 
   c->pipe->clear_render_target(c->pipe, dst_surface, >clear_color,
0, 0, dst_surface->width, 
dst_surface->height, false);
-  dirty_area->x0 = dirty_area->y0 = MAX_DIRTY;
-  dirty_area->x1 = dirty_area->y1 = MIN_DIRTY;
+  dirty_area->x0 = dirty_area->y0 = VL_COMPOSITOR_MAX_DIRTY;
+  dirty_area->x1 = dirty_area->y1 = VL_COMPOSITOR_MIN_DIRTY;
}
 
c->pipe->set_framebuffer_state(c->pipe, >fb_state);
diff --git a/src/gallium/auxiliary/vl/vl_compositor.h 
b/src/gallium/auxiliary/vl/vl_compositor.h
index 8819176..aa843c3 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.h
+++ b/src/gallium/auxiliary/vl/vl_compositor.h
@@ -44,6 +44,8 @@ struct pipe_context;
  */
 
 #define VL_COMPOSITOR_MAX_LAYERS 16
+#define VL_COMPOSITOR_MIN_DIRTY (0)
+#define VL_COMPOSITOR_MAX_DIRTY (1 << 15)
 
 /* deinterlace allgorithem */
 enum vl_compositor_deinterlace
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH v2 5/5] i965: Enabled the OES_copy_image extension on Gen 7 GPUs

[Ilia Mirkin]

On Thu, Feb 7, 2019 at 2:49 AM Eleni Maria Stea  wrote:
>
> On Wed, 6 Feb 2019 12:12:27 -0800
> Nanley Chery  wrote:
>
> > > +   * For now, we can't enable OES_texture_view on Gen 7
> > > because of
> > > +   * some piglit failures coming from
> > > +   * piglit/tests/spec/arb_texture_view/rendering-formats.c
> > > that need
> > > +   * investigation.
> > > */
> >
> > What kind of failures are you seeing? I'd imagine texture views to
> > work with this version of your series.
> >
>
> Hi Nanley,
>
> If you run the piglit test: arb_texture_view-rendering-format, and grep
> for failures on HSW:
>
> PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_R32F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16F" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16I" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RG16_SNORM" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RGBA8I" : "fail"}}
> PIGLIT: {"subtest": {"clear GL_RGB10_A2 as GL_RGBA8_SNORM" : "fail"}}
>
> I remember seeing similar errors on Ivy too. They must be irrelevant to
> the ETC support but as this test passes on BDW where the extension is
> enabled, I didn't enable it on Gen 7 for the moment. I think I had
> discussed about these failures with Kenneth before I disabled them, but
> I didn't investigated them further after that.

Do you also see the failures with desktop GL (and ARB_texture_view)?
If not, that'd be very surprising.

Note that the piglit test arb_texture_view-rendering-formats is the
desktop GL test. arb_texture_view-rendering-formats_gles3 is the ES
version.

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

[Mesa-dev] [Bug 109548] Seeing visual corruption in totem after installing amdgpu 18.50 in Ubuntu 18.04.1

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #5 from Michel Dänzer  ---
AMD's Leo Liu confirmed this is a gstreamer-vaapi bug, and posted a description
of the problem and a suggestion for a possible fix to the gstreamer development
mailing list.

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

Re: [Mesa-dev] [PATCH] freedreno: Fix meson build.

[Daniel Stone]

On Thu, 7 Feb 2019 at 14:59, Eric Engestrom  wrote:
> On Wednesday, 2019-02-06 18:36:09 +, Vinson Lee wrote:
> > ../src/gallium/drivers/freedreno/freedreno_resource.c: In function 
> > ‘fd_resource_create_with_modifiers’:
> > ../src/gallium/drivers/freedreno/freedreno_resource.c:884:30: error: 
> > ‘DRM_FORMAT_MOD_QCOM_COMPRESSED’ undeclared (first use in this function)
> >allow_ubwc = find_modifier(DRM_FORMAT_MOD_QCOM_COMPRESSED, modifiers, 
> > count);
>
> That's a weird error... I would've expected the `#include `
> to fail with a "No such file". If you copied the wrong part of the error
> message, can you update that?

Presumably it just finds an outdated copy of drm_fourcc.h, which
doesn't have the Qualcomm modifier, from the system include path.

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

[Mesa-dev] [PATCH v3 0/5] improved the support for ETC2 formats on Gen 7

[Eleni Maria Stea]

Intel Gen7 GPUs don't support the ETC2 formats natively and in order to
show the pixels properly we convert them to RGBA and create RGBA miptrees.
The problem with that is that the GetCompressed* functions that should
return the compressed pixel values return the RGBA instead.

These patches are an attempt to give a solution to this problem, by
using 2 miptrees: the main to stores the ETC values and the generic
shadow (mt->shadow) to store the RGBA. Each time that the main miptree
is unmapped we unpack the ETC to RGBA and we update the shadow. Similarly,
we update all the mipmap levels of the image (if necessary) before the
drawing, for the CopyImageSubData to work.

Also, the OES_copy_image extension that couldn't work on Gen 7 due to the
lack of the ETC support is now enabled back.

Finally, the following glcts and piglit tests pass:

On HSW (previously failing):

KHR-GL46.direct_state_access.textures_compressed_subimage

On HSW and IVB (previously disabled):
-
dEQP-GLES31.functional.texture.border_clamp.formats.compressed_srgb8_alpha8_etc2_eac.*
   (6 tests)
dEQP-GLES31.functional.texture.border_clamp.formats.compressed_srgb8_etc2.*
   (6 tests)
dEQP-GLES31.functional.texture.border_clamp.formats.compressed_srgb8_punchthrough_alpha1_etc2.*
   (6 tests)

On HSW, IVB, SNB (previously disabled):
---
dEQP-GLES3.functional.texture.format.compressed.*
   (12 tests)
dEQP-GLES3.functional.texture.wrap.etc2_eac_srgb8_alpha8.*
   (36 tests)
dEQP-GLES3.functional.texture.wrap.etc2_srgb8.*
   (36 tests)
dEQP-GLES3.functional.texture.wrap.etc2_srgb8_punchthrough_alpha1.*
   (36 tests)

piglit.spec.!opengl es 3_0.oes_compressed_etc2_texture-miptree_gles3 
   (srgb8, srgb8-alpha, srgb8-punchthrough-alpha1)
piglit.spec.arb_es3_compatibility.oes_compressed_etc2_texture-miptree
   (srgb8 compat, srgb8 core, srgb8-alpha8 compat, srgb8-alpha8 core,
srgb8-punchthrough-alpha1 compat, srgb8-punchthrough-alpha1 core)
(9 tests)

Total tests passing: 148
---

Eleni Maria Stea (4):
  i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.
  i965: Fixed the CopyImageSubData for ETC2 on Gen < 8
  i965: Enabled the OES_copy_image extension on Gen 7 GPUs
  i965: Removed unused intel_miptree_map_etc/intel_miptree_unmap_etc

Nanley Chery (1):
  i965: Rename intel_mipmap_tree::r8stencil_* -> ::shadow_*

 src/mesa/drivers/dri/i965/brw_draw.c  |   5 +
 .../drivers/dri/i965/brw_wm_surface_state.c   |  13 +-
 src/mesa/drivers/dri/i965/intel_extensions.c  |  16 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 201 +++---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  38 +++-
 5 files changed, 183 insertions(+), 90 deletions(-)

-- 
2.20.1

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

[Mesa-dev] [PATCH v3 3/5] i965: Fixed the CopyImageSubData for ETC2 on Gen < 8

[Eleni Maria Stea]

For CopyImageSubData to copy the data during the 1st draw call, we need
to update the shadow tree right before the rendering.

v2:
  - Added assertion that the miptree doesn't need update at the time we
  update the texture surface. (Nanley Chery)
---
 src/mesa/drivers/dri/i965/brw_draw.c | 5 +
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index ec4fe0b096f..d00e0a726b1 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -559,6 +559,11 @@ brw_predraw_resolve_inputs(struct brw_context *brw, bool 
rendering,
   tex_obj->mt->format == MESA_FORMAT_S_UINT8) {
  intel_update_r8stencil(brw, tex_obj->mt);
   }
+
+  if (intel_miptree_has_etc_shadow(brw, tex_obj->mt) &&
+  tex_obj->mt->shadow_needs_update) {
+ intel_miptree_update_etc_shadow_levels(brw, tex_obj->mt);
+  }
}
 
/* Resolve color for each active shader image. */
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 c2cf34aee71..437c7c82555 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -582,7 +582,7 @@ static void brw_update_texture_surface(struct gl_context 
*ctx,
  mt = mt->shadow_mt;
  format = ISL_FORMAT_R8_UINT;
   } else if (intel_miptree_needs_fake_etc(brw, mt)) {
- assert(mt->shadow_mt);
+ assert(mt->shadow_mt && !mt->shadow_needs_update);
  mt = mt->shadow_mt;
   }
 
-- 
2.20.1

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

[Mesa-dev] [PATCH v3 5/5] i965: Removed unused intel_miptree_map_etc/intel_miptree_unmap_etc

[Eleni Maria Stea]

Functions intel_miptree_(map|unmap)_etc are not reached anymore, as we
now use the shadow_mt of each compressed ETC miptree for the emulation.
We removed the functions.

v2:
  - In the previous patch series, we only removed the assertions that
  the tree was mapped for writing. We can now safely remove the whole
  functions as they won't be reached anymore. (Nanley Chery)
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 59 ---
 1 file changed, 59 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index c7367fc385f..a40f606f351 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3476,61 +3476,6 @@ intel_miptree_map_s8(struct brw_context *brw,
map->unmap = intel_miptree_unmap_s8;
 }
 
-static void
-intel_miptree_unmap_etc(struct brw_context *brw,
-struct intel_mipmap_tree *mt,
-struct intel_miptree_map *map,
-unsigned int level,
-unsigned int slice)
-{
-   uint32_t image_x;
-   uint32_t image_y;
-   intel_miptree_get_image_offset(mt, level, slice, _x, _y);
-
-   image_x += map->x;
-   image_y += map->y;
-
-   uint8_t *dst = intel_miptree_map_raw(brw, mt, GL_MAP_WRITE_BIT)
-+ image_y * mt->surf.row_pitch_B
-+ image_x * mt->cpp;
-
-   if (mt->etc_format == MESA_FORMAT_ETC1_RGB8)
-  _mesa_etc1_unpack_rgba(dst, mt->surf.row_pitch_B,
- map->ptr, map->stride,
- map->w, map->h);
-   else
-  _mesa_unpack_etc2_format(dst, mt->surf.row_pitch_B,
-   map->ptr, map->stride,
-  map->w, map->h, mt->etc_format, true);
-
-   intel_miptree_unmap_raw(mt);
-   free(map->buffer);
-}
-
-static void
-intel_miptree_map_etc(struct brw_context *brw,
-  struct intel_mipmap_tree *mt,
-  struct intel_miptree_map *map,
-  unsigned int level,
-  unsigned int slice)
-{
-   assert(mt->etc_format != MESA_FORMAT_NONE);
-   if (mt->etc_format == MESA_FORMAT_ETC1_RGB8) {
-  assert(mt->format == MESA_FORMAT_R8G8B8X8_UNORM);
-   }
-
-   assert(map->mode & GL_MAP_WRITE_BIT);
-   assert(map->mode & GL_MAP_INVALIDATE_RANGE_BIT);
-
-   intel_miptree_access_raw(brw, mt, level, slice, true);
-
-   map->stride = _mesa_format_row_stride(mt->etc_format, map->w);
-   map->buffer = malloc(_mesa_format_image_size(mt->etc_format,
-map->w, map->h, 1));
-   map->ptr = map->buffer;
-   map->unmap = intel_miptree_unmap_etc;
-}
-
 /**
  * Mapping functions for packed depth/stencil miptrees backed by real separate
  * miptrees for depth and stencil.
@@ -3803,10 +3748,6 @@ intel_miptree_map(struct brw_context *brw,
 
if (mt->format == MESA_FORMAT_S_UINT8) {
   intel_miptree_map_s8(brw, mt, map, level, slice);
-   } else if (mt->etc_format != MESA_FORMAT_NONE &&
-  !(mode & BRW_MAP_DIRECT_BIT) &&
-  !(intel_miptree_needs_fake_etc(brw, mt))) {
-  intel_miptree_map_etc(brw, mt, map, level, slice);
} else if (mt->stencil_mt && !(mode & BRW_MAP_DIRECT_BIT)) {
   intel_miptree_map_depthstencil(brw, mt, map, level, slice);
} else if (use_intel_mipree_map_blit(brw, mt, map)) {
-- 
2.20.1

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

[Mesa-dev] [PATCH v3 4/5] i965: Enabled the OES_copy_image extension on Gen 7 GPUs

[Eleni Maria Stea]

OES_copy_image extension was disabled on Gen7 due to the lack of support
for ETC2 images. Enabled it back. (Kenneth Graunke)

v2:
  - Removed the blank lines in the comments above OES_copy_image and
  OES_texture_view extensions in intel_extensions.c (Nanley Chery)
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 3a95be58a63..d2a6aa185c2 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -287,14 +287,22 @@ intelInitExtensions(struct gl_context *ctx)
}
 
if (devinfo->gen >= 8 || devinfo->is_baytrail) {
-  /* For now, we only enable OES_copy_image on platforms that support
-   * ETC2 natively in hardware.  We would need more hacks to support it
-   * elsewhere. Same with OES_texture_view.
+  /* For now, we can't enable OES_texture_view on Gen 7 because of
+   * some piglit failures coming from
+   * piglit/tests/spec/arb_texture_view/rendering-formats.c that need
+   * investigation.
*/
-  ctx->Extensions.OES_copy_image = true;
   ctx->Extensions.OES_texture_view = true;
}
 
+   if (devinfo->gen >= 7) {
+  /* We can safely enable OES_copy_image on Gen 7, since we emulate
+   * the ETC2 support using the shadow_miptree to store the
+   * compressed data.
+   */
+  ctx->Extensions.OES_copy_image = true;
+   }
+
if (devinfo->gen >= 8) {
   ctx->Extensions.ARB_gpu_shader_int64 = true;
   /* requires ARB_gpu_shader_int64 */
-- 
2.20.1

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

[Mesa-dev] [PATCH v3 2/5] i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.

[Eleni Maria Stea]

GPUs Gen < 8 cannot sample ETC2 formats. So far, they converted the
compressed EAC/ETC2 images to non-compressed RGBA images. When
GetCompressed* functions were called, the pixels were returned in this
RGBA format and not the compressed format that was expected.

Trying to fix this problem, we use a secondary shadow miptree to store the
decompressed data for the rendering and the main miptree to store the
compressed for the Get functions to work. Each time that the main miptree
is written with compressed data, we decompress them to RGB and update the
shadow. Then we use the shadow for rendering.

v2:
   - Fixes in the commit message (Nanley Chery)
   - Reversed the changes in brw_get_texture_swizzle and swapped the b, g
   values at the time that we decompress the data in the function:
   intel_miptree_update_etc_shadow of intel_mipmap_tree.c (Nanley Chery)
   - Simplified the format checks in the miptree_create function of the
   intel_mipmap_tree.c and reserved the call of the
   intel_lower_compressed_format for the case that we are faking the ETC
   support (Nanley Chery)
   - Removed the check for the auxiliary usage for the shadow miptree at
   creation (miptree_create of intel_mipmap_tree.c) as we won't use
   auxiliary buffers with these types of trees (Nanley Chery)
   - Set the etc_format of the non-ETC miptrees to MESA_FORMAT_NONE and
   removed the unecessary checks (Nanley Chery)
   - Fixed an unrelated indentation change (Nanley Chery)
   - Modified the function intel_miptree_finish_write to set the
   mt->shadow_needs_update to true to catch all the cases when we need to
   update the miptree (Nanley Chery)
   - In order to update the shadow miptree during the unmap of the
   main and always map the main (Nanley Chery) the following change was
   necessary: Splitted the previous update function that was updating all
   the mipmap levels and use two functions instead: one that updates one
   level and one that updates all of them. Used the first during unmap
   and the second before the rendering.
   - Removed the BRW_MAP_ETC_BIT flag and the mechanism to decide which
   miptree should be mapped each time and reversed all the changes in the
   higher level texture functions that upload data to textures as they
   aren't needed anymore.
   - Replaced the boolean needs_fake_etc with an inline function that
   checks when we need to fake the ETC compression (Nanley Chery)
   - Removed the initialization of the strides in the update function as
   the values will be overwritten by the intel_miptree_map call (Nanley
   Chery)
   - Used minify instead of division in the new update function
   intel_miptree_update_etc_shadow_levels in intel_mipmap_tree.c (Nanley
   Chery)
   - Removed the depth from the calculation of the number of slices in
   the new update function (intel_miptree_update_etc_shadow_levels of
   intel_mipmap_tree.c) as we don't need to support 3D ETC images.
   (Nanley Chery)

v3:
  - Renamed the rgba_fmt in function miptree_create
  (intel_mipmap_tree.c) to decomp_format as the format is not always in
  rgba order. (Nanley Chery)
  - Documented the new usage for the shadow miptree in the comment above
  the field in the intel_miptree struct in intel_mipmap_tree.h (Nanley
  Chery)
  - Removed the redundant flags from the mapping of the miptrees in
  intel_miptree_update_etc_shadow of intel_mipmap_tree.c (Nanley Chery)
  - Fixed the switch from surface's logical level to physical level in
  the intel_miptree_update_etc_shadow_levels of intel_mipmap_tree.c
  (Nanley Chery)
  - Excluded the Baytrail GPUs from the check for the ETC emulation as
  they support the ETC formats natively. (Nanley Chery)
  - Simplified the check if the format is BGRA in
  intel_miptree_update_etc_shadow of intel_mipmap_tree.c (Nanley Chery)
---
 .../drivers/dri/i965/brw_wm_surface_state.c   |   5 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 130 --
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  24 
 3 files changed, 149 insertions(+), 10 deletions(-)

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 618e2ab35bc..c2cf34aee71 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -521,7 +521,7 @@ static void brw_update_texture_surface(struct gl_context 
*ctx,
   */
  mesa_fmt = mt->format;
   } else if (mt->etc_format != MESA_FORMAT_NONE) {
- mesa_fmt = mt->format;
+ mesa_fmt = mt->shadow_mt->format;
   } else if (plane > 0) {
  mesa_fmt = mt->format;
   } else {
@@ -581,6 +581,9 @@ static void brw_update_texture_surface(struct gl_context 
*ctx,
  assert(mt->shadow_mt && !mt->shadow_needs_update);
  mt = mt->shadow_mt;
  format = ISL_FORMAT_R8_UINT;
+  } else if (intel_miptree_needs_fake_etc(brw, mt)) {
+ assert(mt->shadow_mt);
+ mt = mt->shadow_mt;
   

[Mesa-dev] [PATCH v3 1/5] i965: Rename intel_mipmap_tree::r8stencil_* -> ::shadow_*

[Eleni Maria Stea]

From: Nanley Chery 

Use more generic field names. We'll reuse these fields for a workaround
with ASTC miptrees.

Reviewed-by: Eleni Maria Stea 
---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  8 
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 16 
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h| 14 +++---
 3 files changed, 19 insertions(+), 19 deletions(-)

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 b067a174056..618e2ab35bc 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -571,15 +571,15 @@ static void brw_update_texture_surface(struct gl_context 
*ctx,
 
   if (obj->StencilSampling && firstImage->_BaseFormat == GL_DEPTH_STENCIL) 
{
  if (devinfo->gen <= 7) {
-assert(mt->r8stencil_mt && 
!mt->stencil_mt->r8stencil_needs_update);
-mt = mt->r8stencil_mt;
+assert(mt->shadow_mt && !mt->stencil_mt->shadow_needs_update);
+mt = mt->shadow_mt;
  } else {
 mt = mt->stencil_mt;
  }
  format = ISL_FORMAT_R8_UINT;
   } else if (devinfo->gen <= 7 && mt->format == MESA_FORMAT_S_UINT8) {
- assert(mt->r8stencil_mt && !mt->r8stencil_needs_update);
- mt = mt->r8stencil_mt;
+ assert(mt->shadow_mt && !mt->shadow_needs_update);
+ mt = mt->shadow_mt;
  format = ISL_FORMAT_R8_UINT;
   }
 
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index b4e3524aa51..479188fd1c8 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1214,7 +1214,7 @@ intel_miptree_release(struct intel_mipmap_tree **mt)
 
   brw_bo_unreference((*mt)->bo);
   intel_miptree_release(&(*mt)->stencil_mt);
-  intel_miptree_release(&(*mt)->r8stencil_mt);
+  intel_miptree_release(&(*mt)->shadow_mt);
   intel_miptree_aux_buffer_free((*mt)->aux_buf);
   free_aux_state_map((*mt)->aux_state);
 
@@ -2427,7 +2427,7 @@ intel_miptree_finish_write(struct brw_context *brw,
switch (mt->aux_usage) {
case ISL_AUX_USAGE_NONE:
   if (mt->format == MESA_FORMAT_S_UINT8 && devinfo->gen <= 7)
- mt->r8stencil_needs_update = true;
+ mt->shadow_needs_update = true;
   break;
 
case ISL_AUX_USAGE_MCS:
@@ -2933,9 +2933,9 @@ intel_update_r8stencil(struct brw_context *brw,
 
assert(src->surf.size_B > 0);
 
-   if (!mt->r8stencil_mt) {
+   if (!mt->shadow_mt) {
   assert(devinfo->gen > 6); /* Handle MIPTREE_LAYOUT_GEN6_HIZ_STENCIL */
-  mt->r8stencil_mt = make_surface(
+  mt->shadow_mt = make_surface(
 brw,
 src->target,
 MESA_FORMAT_R_UINT8,
@@ -2949,13 +2949,13 @@ intel_update_r8stencil(struct brw_context *brw,
 ISL_TILING_Y0_BIT,
 ISL_SURF_USAGE_TEXTURE_BIT,
 BO_ALLOC_BUSY, 0, NULL);
-  assert(mt->r8stencil_mt);
+  assert(mt->shadow_mt);
}
 
-   if (src->r8stencil_needs_update == false)
+   if (src->shadow_needs_update == false)
   return;
 
-   struct intel_mipmap_tree *dst = mt->r8stencil_mt;
+   struct intel_mipmap_tree *dst = mt->shadow_mt;
 
for (int level = src->first_level; level <= src->last_level; level++) {
   const unsigned depth = src->surf.dim == ISL_SURF_DIM_3D ?
@@ -2975,7 +2975,7 @@ intel_update_r8stencil(struct brw_context *brw,
}
 
brw_cache_flush_for_read(brw, dst->bo);
-   src->r8stencil_needs_update = false;
+   src->shadow_needs_update = false;
 }
 
 static void *
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 17668944adc..1a7507023a1 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -294,16 +294,16 @@ struct intel_mipmap_tree
struct intel_mipmap_tree *stencil_mt;
 
/**
-* \brief Stencil texturing miptree for sampling from a stencil texture
+* \brief Shadow miptree for sampling when the main isn't supported by HW.
 *
-* Some hardware doesn't support sampling from the stencil texture as
-* required by the GL_ARB_stencil_texturing extenion. To workaround this we
-* blit the texture into a new texture that can be sampled.
+* To workaround various sampler bugs and limitations, we blit the main
+* texture into a new texture that can be sampled.
 *
-* \see intel_update_r8stencil()
+* This miptree may be used for:
+* - Stencil texturing (pre-BDW) as required by GL_ARB_stencil_texturing.
 */
-   struct intel_mipmap_tree *r8stencil_mt;
-   bool r8stencil_needs_update;
+   struct intel_mipmap_tree *shadow_mt;
+   bool shadow_needs_update;
 
/**
 * \brief CCS, 

[Mesa-dev] [Bug 109574] Blender 2.8

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer  ---
These messages:

Received X11 Error:
error code:   182
request code: 156
minor code:   34
error text:   GLXBadFBConfig
[...]
Received X11 Error:
error code:   8
request code: 156
minor code:   34
error text:   BadMatch (invalid parameter attributes)

indicate that blender fails to create a GLX context multiple times. Do you get
these messages on the other system with an HD 2600 Pro as well? If not, it
might be helpful if you attach the Xorg log files and the outputs of glxinfo
from both systems.

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

Re: [Mesa-dev] [PATCH v2 1/7] gallium/auxiliary/vl: Move dirty define to header file

[James Zhu]

On 2019-02-07 9:23 a.m., Christian König wrote:
> Am 07.02.19 um 15:21 schrieb James Zhu:
>> On 2019-02-07 4:49 a.m., Christian König wrote:
>>> Patches #1, #2, #5, #7  are Reviewed-by: Christian König
>>> 
>>>
>>> Patch #3 the csc_matrix need a better name since we now store more and
>>> more additional info in there, but that can as well be a follow up 
>>> patch.
>> csc_matrix is used by upper stack.Let me figure out how to use 2nd
>> constant buffer to hold additional info.
>
> Actually you don't need to add a second one.
>
> We should just rename the variable because there is now more in the 
> buffer than the csc matrix.
>
> Something like shader_params or something similar.

Okay, let me just rename it.

James

>
> Christian.
>
>>
>> James
>>
>>> Patch #4 is Acked-by: Christian König 
>>>
>>> Patch #6 I think there was a simpler option for this.
>>>
>>> And when the compute shaders reach the same level of functionality as
>>> the GFX shaders we should make this the default, depending on the
>>> hardware capabilities.
>> Sure.
>>
>> James
>>
>>> Christian.
>>>
>>> Am 06.02.19 um 20:44 schrieb Zhu, James:
 Move dirty define to header file to share with compute shader.

 Signed-off-by: James Zhu 
 ---
    src/gallium/auxiliary/vl/vl_compositor.c | 15 ++-
    src/gallium/auxiliary/vl/vl_compositor.h |  2 ++
    2 files changed, 8 insertions(+), 9 deletions(-)

 diff --git a/src/gallium/auxiliary/vl/vl_compositor.c
 b/src/gallium/auxiliary/vl/vl_compositor.c
 index 159a295..41f9e5e 100644
 --- a/src/gallium/auxiliary/vl/vl_compositor.c
 +++ b/src/gallium/auxiliary/vl/vl_compositor.c
 @@ -42,9 +42,6 @@
    #include "vl_types.h"
    #include "vl_compositor.h"
    -#define MIN_DIRTY (0)
 -#define MAX_DIRTY (1 << 15)
 -
    enum VS_OUTPUT
    {
   VS_O_VPOS = 0,
 @@ -899,8 +896,8 @@ gen_vertex_data(struct vl_compositor *c, struct
 vl_compositor_state *s, struct u
     dirty->y1 <= drawn.y1) {
     // We clear the dirty area anyway, no need for
 clear_render_target
 -   dirty->x0 = dirty->y0 = MAX_DIRTY;
 -   dirty->x1 = dirty->y1 = MIN_DIRTY;
 +   dirty->x0 = dirty->y0 = VL_COMPOSITOR_MAX_DIRTY;
 +   dirty->x1 = dirty->y1 = VL_COMPOSITOR_MIN_DIRTY;
    }
     }
  }
 @@ -1030,8 +1027,8 @@ vl_compositor_reset_dirty_area(struct u_rect
 *dirty)
    {
   assert(dirty);
    -   dirty->x0 = dirty->y0 = MIN_DIRTY;
 -   dirty->x1 = dirty->y1 = MAX_DIRTY;
 +   dirty->x0 = dirty->y0 = VL_COMPOSITOR_MIN_DIRTY;
 +   dirty->x1 = dirty->y1 = VL_COMPOSITOR_MAX_DIRTY;
    }
      void
 @@ -1378,8 +1375,8 @@ vl_compositor_render(struct vl_compositor_state
 *s,
        c->pipe->clear_render_target(c->pipe, dst_surface,
 >clear_color,
   0, 0, dst_surface->width,
 dst_surface->height, false);
 -  dirty_area->x0 = dirty_area->y0 = MAX_DIRTY;
 -  dirty_area->x1 = dirty_area->y1 = MIN_DIRTY;
 +  dirty_area->x0 = dirty_area->y0 = VL_COMPOSITOR_MAX_DIRTY;
 +  dirty_area->x1 = dirty_area->y1 = VL_COMPOSITOR_MIN_DIRTY;
   }
     c->pipe->set_framebuffer_state(c->pipe, >fb_state);
 diff --git a/src/gallium/auxiliary/vl/vl_compositor.h
 b/src/gallium/auxiliary/vl/vl_compositor.h
 index 8819176..aa843c3 100644
 --- a/src/gallium/auxiliary/vl/vl_compositor.h
 +++ b/src/gallium/auxiliary/vl/vl_compositor.h
 @@ -44,6 +44,8 @@ struct pipe_context;
     */
      #define VL_COMPOSITOR_MAX_LAYERS 16
 +#define VL_COMPOSITOR_MIN_DIRTY (0)
 +#define VL_COMPOSITOR_MAX_DIRTY (1 << 15)
      /* deinterlace allgorithem */
    enum vl_compositor_deinterlace
>> ___
>> 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] freedreno: Fix meson build.

[Eric Engestrom]

On Wednesday, 2019-02-06 18:36:09 +, Vinson Lee wrote:
> ../src/gallium/drivers/freedreno/freedreno_resource.c: In function 
> ‘fd_resource_create_with_modifiers’:
> ../src/gallium/drivers/freedreno/freedreno_resource.c:884:30: error: 
> ‘DRM_FORMAT_MOD_QCOM_COMPRESSED’ undeclared (first use in this function)
>allow_ubwc = find_modifier(DRM_FORMAT_MOD_QCOM_COMPRESSED, modifiers, 
> count);
>   ^

That's a weird error... I would've expected the `#include `
to fail with a "No such file". If you copied the wrong part of the error
message, can you update that?

Regardless, the patch is correct:
Reviewed-by: Eric Engestrom 

> 
> Fixes: 1ce5d757d04a ("freedreno: core buffer modifier support")
> Signed-off-by: Vinson Lee 
> ---
>  src/gallium/drivers/freedreno/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/freedreno/meson.build 
> b/src/gallium/drivers/freedreno/meson.build
> index 1e3a3037014b..25aa8ecdb455 100644
> --- a/src/gallium/drivers/freedreno/meson.build
> +++ b/src/gallium/drivers/freedreno/meson.build
> @@ -209,7 +209,7 @@ files_libfreedreno = files(
>  )
>  
>  freedreno_includes = [
> -  inc_src, inc_include, inc_gallium, inc_gallium_aux,
> +  inc_src, inc_include, inc_drm_uapi, inc_gallium, inc_gallium_aux,
>inc_freedreno, include_directories('ir3'),
>  ]
>  
> -- 
> 2.19.1.dropbox.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109574] Blender 2.8

[bugzilla-daemon]

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

--- Comment #1 from Gert Wollny  ---
The HD 2600 Pro and  HD 4850 are slightly different hardware, so that the
shader code generated by the drivers might be somewhat different. 

In any case, you can try to run blender with

  R600_DEBUG=nosb blender 

and see whether this helps. If this doesn't help then you please add the
logging output by running 

  R600_DUMP_SHADERS=1 blender 

from both computers. This will print the shaders and one might be able to spot
a difference that gives an idea where to look.

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

Re: [Mesa-dev] [PATCH] st/va:Add support for indirect manner by returning VA_STATUS_ERROR_OPERATION_FAILED

[Liu, Leo]

VA spec regarding VAImage:

This operation is only possible on implementations with
  * direct rendering capabilities and internal surface formats that can be
  * represented with a VAImage. When the operation is not possible this 
interface
  * will return VA_STATUS_ERROR_OPERATION_FAILED. Clients should then 
fall back
  * to using vaCreateImage + vaPutImage to accomplish the same task in an
  * indirect manner.

This is similar to your commit message, so please add it something like 
"based on VA spec..." to your commit message.

With that fixed, the patch is:

Reviewed-by: Leo Liu 

On 2019-02-07 5:09 a.m., Guttula, Suresh wrote:
> This patch will return VA_STATUS_ERROR_OPERATION_FAILED incase vaDeriveImage()
> failed for non-contiguous planes.This error string is required to support
> indirect manner i.e. vaCreateImage()+vaPutImage() incase vaDeriveImage()
> failed with VA_STATUS_ERROR_OPERATION_FAILED.
>
> Signed-off-by: suresh guttula 
> ---
>   src/gallium/state_trackers/va/image.c | 7 +--
>   1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/va/image.c 
> b/src/gallium/state_trackers/va/image.c
> index 807fc83..f7e0db0 100644
> --- a/src/gallium/state_trackers/va/image.c
> +++ b/src/gallium/state_trackers/va/image.c
> @@ -212,9 +212,12 @@ vlVaDeriveImage(VADriverContextP ctx, VASurfaceID 
> surface, VAImage *image)
>   
>  surf = handle_table_get(drv->htab, surface);
>   
> -   if (!surf || !surf->buffer || surf->buffer->interlaced)
> +   if (!surf || !surf->buffer)
> return VA_STATUS_ERROR_INVALID_SURFACE;
>   
> +   if (surf->buffer->interlaced)
> + return VA_STATUS_ERROR_OPERATION_FAILED;
> +
>  surfaces = surf->buffer->get_surfaces(surf->buffer);
>  if (!surfaces || !surfaces[0]->texture)
> return VA_STATUS_ERROR_ALLOCATION_FAILED;
> @@ -261,7 +264,7 @@ vlVaDeriveImage(VADriverContextP ctx, VASurfaceID 
> surface, VAImage *image)
>  default:
> /* VaDeriveImage is designed for contiguous planes. */
> FREE(img);
> -  return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT;
> +  return VA_STATUS_ERROR_OPERATION_FAILED;
>  }
>   
>  img_buf = CALLOC(1, sizeof(vlVaBuffer));
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/7] gallium/auxiliary/vl: Move dirty define to header file

[Christian König]

Am 07.02.19 um 15:21 schrieb James Zhu:

On 2019-02-07 4:49 a.m., Christian König wrote:

Patches #1, #2, #5, #7  are Reviewed-by: Christian König


Patch #3 the csc_matrix need a better name since we now store more and
more additional info in there, but that can as well be a follow up patch.

csc_matrix is used by upper stack.Let me figure out how to use 2nd
constant buffer to hold additional info.


Actually you don't need to add a second one.

We should just rename the variable because there is now more in the 
buffer than the csc matrix.


Something like shader_params or something similar.

Christian.



James


Patch #4 is Acked-by: Christian König 

Patch #6 I think there was a simpler option for this.

And when the compute shaders reach the same level of functionality as
the GFX shaders we should make this the default, depending on the
hardware capabilities.

Sure.

James


Christian.

Am 06.02.19 um 20:44 schrieb Zhu, James:

Move dirty define to header file to share with compute shader.

Signed-off-by: James Zhu 
---
   src/gallium/auxiliary/vl/vl_compositor.c | 15 ++-
   src/gallium/auxiliary/vl/vl_compositor.h |  2 ++
   2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c
b/src/gallium/auxiliary/vl/vl_compositor.c
index 159a295..41f9e5e 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -42,9 +42,6 @@
   #include "vl_types.h"
   #include "vl_compositor.h"
   -#define MIN_DIRTY (0)
-#define MAX_DIRTY (1 << 15)
-
   enum VS_OUTPUT
   {
  VS_O_VPOS = 0,
@@ -899,8 +896,8 @@ gen_vertex_data(struct vl_compositor *c, struct
vl_compositor_state *s, struct u
    dirty->y1 <= drawn.y1) {
    // We clear the dirty area anyway, no need for
clear_render_target
-   dirty->x0 = dirty->y0 = MAX_DIRTY;
-   dirty->x1 = dirty->y1 = MIN_DIRTY;
+   dirty->x0 = dirty->y0 = VL_COMPOSITOR_MAX_DIRTY;
+   dirty->x1 = dirty->y1 = VL_COMPOSITOR_MIN_DIRTY;
   }
    }
     }
@@ -1030,8 +1027,8 @@ vl_compositor_reset_dirty_area(struct u_rect
*dirty)
   {
  assert(dirty);
   -   dirty->x0 = dirty->y0 = MIN_DIRTY;
-   dirty->x1 = dirty->y1 = MAX_DIRTY;
+   dirty->x0 = dirty->y0 = VL_COMPOSITOR_MIN_DIRTY;
+   dirty->x1 = dirty->y1 = VL_COMPOSITOR_MAX_DIRTY;
   }
     void
@@ -1378,8 +1375,8 @@ vl_compositor_render(struct vl_compositor_state
*s,
       c->pipe->clear_render_target(c->pipe, dst_surface,
>clear_color,
  0, 0, dst_surface->width,
dst_surface->height, false);
-  dirty_area->x0 = dirty_area->y0 = MAX_DIRTY;
-  dirty_area->x1 = dirty_area->y1 = MIN_DIRTY;
+  dirty_area->x0 = dirty_area->y0 = VL_COMPOSITOR_MAX_DIRTY;
+  dirty_area->x1 = dirty_area->y1 = VL_COMPOSITOR_MIN_DIRTY;
  }
    c->pipe->set_framebuffer_state(c->pipe, >fb_state);
diff --git a/src/gallium/auxiliary/vl/vl_compositor.h
b/src/gallium/auxiliary/vl/vl_compositor.h
index 8819176..aa843c3 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.h
+++ b/src/gallium/auxiliary/vl/vl_compositor.h
@@ -44,6 +44,8 @@ struct pipe_context;
    */
     #define VL_COMPOSITOR_MAX_LAYERS 16
+#define VL_COMPOSITOR_MIN_DIRTY (0)
+#define VL_COMPOSITOR_MAX_DIRTY (1 << 15)
     /* deinterlace allgorithem */
   enum vl_compositor_deinterlace

___
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 v2 1/7] gallium/auxiliary/vl: Move dirty define to header file

[James Zhu]

On 2019-02-07 4:49 a.m., Christian König wrote:
> Patches #1, #2, #5, #7  are Reviewed-by: Christian König 
> 
>
> Patch #3 the csc_matrix need a better name since we now store more and 
> more additional info in there, but that can as well be a follow up patch.

csc_matrix is used by upper stack.Let me figure out how to use 2nd 
constant buffer to hold additional info.

James

>
> Patch #4 is Acked-by: Christian König 
>
> Patch #6 I think there was a simpler option for this.
>
> And when the compute shaders reach the same level of functionality as 
> the GFX shaders we should make this the default, depending on the 
> hardware capabilities.

Sure.

James

>
> Christian.
>
> Am 06.02.19 um 20:44 schrieb Zhu, James:
>> Move dirty define to header file to share with compute shader.
>>
>> Signed-off-by: James Zhu 
>> ---
>>   src/gallium/auxiliary/vl/vl_compositor.c | 15 ++-
>>   src/gallium/auxiliary/vl/vl_compositor.h |  2 ++
>>   2 files changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
>> b/src/gallium/auxiliary/vl/vl_compositor.c
>> index 159a295..41f9e5e 100644
>> --- a/src/gallium/auxiliary/vl/vl_compositor.c
>> +++ b/src/gallium/auxiliary/vl/vl_compositor.c
>> @@ -42,9 +42,6 @@
>>   #include "vl_types.h"
>>   #include "vl_compositor.h"
>>   -#define MIN_DIRTY (0)
>> -#define MAX_DIRTY (1 << 15)
>> -
>>   enum VS_OUTPUT
>>   {
>>  VS_O_VPOS = 0,
>> @@ -899,8 +896,8 @@ gen_vertex_data(struct vl_compositor *c, struct 
>> vl_compositor_state *s, struct u
>>    dirty->y1 <= drawn.y1) {
>>    // We clear the dirty area anyway, no need for 
>> clear_render_target
>> -   dirty->x0 = dirty->y0 = MAX_DIRTY;
>> -   dirty->x1 = dirty->y1 = MIN_DIRTY;
>> +   dirty->x0 = dirty->y0 = VL_COMPOSITOR_MAX_DIRTY;
>> +   dirty->x1 = dirty->y1 = VL_COMPOSITOR_MIN_DIRTY;
>>   }
>>    }
>>     }
>> @@ -1030,8 +1027,8 @@ vl_compositor_reset_dirty_area(struct u_rect 
>> *dirty)
>>   {
>>  assert(dirty);
>>   -   dirty->x0 = dirty->y0 = MIN_DIRTY;
>> -   dirty->x1 = dirty->y1 = MAX_DIRTY;
>> +   dirty->x0 = dirty->y0 = VL_COMPOSITOR_MIN_DIRTY;
>> +   dirty->x1 = dirty->y1 = VL_COMPOSITOR_MAX_DIRTY;
>>   }
>>     void
>> @@ -1378,8 +1375,8 @@ vl_compositor_render(struct vl_compositor_state 
>> *s,
>>       c->pipe->clear_render_target(c->pipe, dst_surface, 
>> >clear_color,
>>  0, 0, dst_surface->width, 
>> dst_surface->height, false);
>> -  dirty_area->x0 = dirty_area->y0 = MAX_DIRTY;
>> -  dirty_area->x1 = dirty_area->y1 = MIN_DIRTY;
>> +  dirty_area->x0 = dirty_area->y0 = VL_COMPOSITOR_MAX_DIRTY;
>> +  dirty_area->x1 = dirty_area->y1 = VL_COMPOSITOR_MIN_DIRTY;
>>  }
>>    c->pipe->set_framebuffer_state(c->pipe, >fb_state);
>> diff --git a/src/gallium/auxiliary/vl/vl_compositor.h 
>> b/src/gallium/auxiliary/vl/vl_compositor.h
>> index 8819176..aa843c3 100644
>> --- a/src/gallium/auxiliary/vl/vl_compositor.h
>> +++ b/src/gallium/auxiliary/vl/vl_compositor.h
>> @@ -44,6 +44,8 @@ struct pipe_context;
>>    */
>>     #define VL_COMPOSITOR_MAX_LAYERS 16
>> +#define VL_COMPOSITOR_MIN_DIRTY (0)
>> +#define VL_COMPOSITOR_MAX_DIRTY (1 << 15)
>>     /* deinterlace allgorithem */
>>   enum vl_compositor_deinterlace
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] freedreno: Fix meson build.

[Rob Clark]

On Wed, Feb 6, 2019 at 1:36 PM Vinson Lee  wrote:
>
> ../src/gallium/drivers/freedreno/freedreno_resource.c: In function 
> ‘fd_resource_create_with_modifiers’:
> ../src/gallium/drivers/freedreno/freedreno_resource.c:884:30: error: 
> ‘DRM_FORMAT_MOD_QCOM_COMPRESSED’ undeclared (first use in this function)
>allow_ubwc = find_modifier(DRM_FORMAT_MOD_QCOM_COMPRESSED, modifiers, 
> count);
>   ^
>
> Fixes: 1ce5d757d04a ("freedreno: core buffer modifier support")
> Signed-off-by: Vinson Lee 

hmm, no idea how I didn't hit that, but this looks like the right thing to do

Reviewed-by: Rob Clark 

> ---
>  src/gallium/drivers/freedreno/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/freedreno/meson.build 
> b/src/gallium/drivers/freedreno/meson.build
> index 1e3a3037014b..25aa8ecdb455 100644
> --- a/src/gallium/drivers/freedreno/meson.build
> +++ b/src/gallium/drivers/freedreno/meson.build
> @@ -209,7 +209,7 @@ files_libfreedreno = files(
>  )
>
>  freedreno_includes = [
> -  inc_src, inc_include, inc_gallium, inc_gallium_aux,
> +  inc_src, inc_include, inc_drm_uapi, inc_gallium, inc_gallium_aux,
>inc_freedreno, include_directories('ir3'),
>  ]
>
> --
> 2.19.1.dropbox.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[andrey simiklit]

ping. the piglit test was pushed)

Thanks,
Andrii.

On Tue, Jan 22, 2019 at 1:31 PM andrey simiklit 
wrote:

> Hello,
>
> Could somebody help me with a push of the following patch?
> https://patchwork.freedesktop.org/patch/254397
>
> This fix is needed to fix these fails:
>
> https://mesa-ci.01.org/global_logic/builds/56/group/ac3c5a0dc1f15492570367c6c8ec835c
>
> When this fix is pushed we will be able to remove the following test:
> tex-upside-down-miptree
> from Intel CI "[expected-crashes]" sections.
>
> Thanks,
> Andrii.
>
> On Mon, Jan 14, 2019 at 3:05 PM andrey simiklit 
> wrote:
>
>> Hello,
>>
>> The test for this issue is pushed to the piglit.
>> It would be great to push the mesa fix too if it is still an acceptable
>> for all :)
>>
>> Thanks,
>> Andrii.
>> On Sat, Oct 20, 2018 at 12:29 PM andrey simiklit <
>> asimiklit.w...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> On Fri, Oct 19, 2018 at 15:14 Kenneth Graunke 
>>> wrote:
>>>
 On Thursday, October 11, 2018 12:12:38 PM PDT Kenneth Graunke wrote:
 > On Thursday, October 11, 2018 11:58:40 AM PDT Kenneth Graunke wrote:
 > > On Tuesday, October 2, 2018 9:16:01 AM PDT asimiklit.w...@gmail.com
 wrote:
 > > > From: Andrii Simiklit 
 > > >
 > > > I guess that when we calculating the width0, height0, depth0
 > > > to use for function 'intel_miptree_create' we need to consider
 > > > the 'base level' like it is done in the
 'intel_miptree_create_for_teximage'
 > > > function.
 > > >
 > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
 > > > Signed-off-by: Andrii Simiklit 
 > > > ---
 > > >  .../drivers/dri/i965/intel_tex_validate.c | 26
 ++-
 > > >  1 file changed, 25 insertions(+), 1 deletion(-)
 > >
 > > I believe this patch is correct - we're assembling things into a new
 > > miptree, which we start at level 0 - so we need the sizes for level
 0.
 > >
 > > Alternatively, we might be able to pass validate_first_level instead
 > > of 0 when calling intel_miptree_create, to make one that's only good
 > > up until the new base...and have to re-assemble it the next time
 they
 > > change the base.  It would save memory potentially.  But more
 copies.
 > > I don't have a strong preference which is better.
 > >
 > > Please do make a Piglit or dEQP test for this.
 > >
 > > Reviewed-by: Kenneth Graunke 
 >
 > Sorry, withdrawing my review. :(  Chris Forbes pointed out on IRC that
 > your reproducer case is backwards:
 >
 > miplevel 0 - 1x1
 > miplevel 1 - 2x2
 > miplevel 2 - 4x4
 >
 > That's upside down.  A proper miptree would have the base be largest:
 >
 > miplevel 0 - 4x4
 > miplevel 1 - 2x2
 > miplevel 2 - 1x1
 >
 > So, yes, I could see this tripping an assert...but such a crazy
 texture
 > will never be mipmap complete.  If they're expecting mipmapping, then
 > it seems like they should get a fallback black texture (which normally
 > happens for incomplete textures).  If not, maybe they should get a
 > single miplevel?  Either way, seems like we should detect insanity and
 > bail, rather than change size calculations for the normal sane case.
 >

 So...looked at this again.  I'm not sure why upside-down matters.

 At DrawArrays time, we have a single miplevel (base = 2), and are trying
 to put that single miplevel's image into a miptree.  We do properly
 ignore levels 0..1 as they're beyond the base.

 We appear to use level 0 as the actual base, and want to store our
 single level at level 2.  Other places (TexImage) seem to work that way
 too.

 But, we're creating the miplevel with level 0 as the base, but where
 level 0 has the dimensions of level 2.  This doesn't work.  And your
 patch fixes that.

 I tried making the actual base of the unified tree be level 2, rather
 than level 0...so that the BaseLevel is the actual base...but tons of
 things broke.

 So, back to Reviewed-by.  I think once we get a Piglit test, I'm happy
 to land this patch.
>>>
>>>
>>> Thanks for reviewing :-) I will start to work on it as soon as come back
>>> from vacation (on Monday)
>>>
>>>

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

Re: [Mesa-dev] [PATCH v3 12/44] nir: add new fadd, fsub, fmul opcodes taking into account rounding mode

[Samuel Iglesias Gonsálvez]

On 2/6/19 12:47 PM, Connor Abbott wrote:
> 
> 
> On Wed, Feb 6, 2019 at 11:46 AM Samuel Iglesias Gonsálvez
> mailto:sigles...@igalia.com>> wrote:
> 
> According to Vulkan spec, the new execution modes affect only
> correctly rounded SPIR-V instructions, which includes fadd,
> fsub and fmul.
> 
> Signed-off-by: Samuel Iglesias Gonsálvez  >
> ---
>  src/compiler/nir/nir_opcodes.py | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/src/compiler/nir/nir_opcodes.py
> b/src/compiler/nir/nir_opcodes.py
> index f8997444c28..7b45d38f460 100644
> --- a/src/compiler/nir/nir_opcodes.py
> +++ b/src/compiler/nir/nir_opcodes.py
> @@ -453,9 +453,15 @@ def binop_convert(name, out_type, in_type,
> alg_props, const_expr):
>     opcode(name, 0, out_type, [0, 0], [in_type, in_type],
>            False, alg_props, const_expr, "")
> 
> +def binop_convert_rounding_mode(name, out_type, in_type, alg_props,
> const_expr, rounding_mode):
> +   opcode(name, 0, out_type, [0, 0], [in_type, in_type], False,
> alg_props, const_expr, rounding_mode)
> +
>  def binop(name, ty, alg_props, const_expr):
>     binop_convert(name, ty, ty, alg_props, const_expr)
> 
> +def binop_rounding_mode(name, ty, alg_props, const_expr,
> rounding_mode):
> +   binop_convert_rounding_mode(name, ty, ty, alg_props, const_expr,
> rounding_mode)
> +
>  def binop_compare(name, ty, alg_props, const_expr):
>     binop_convert(name, tbool1, ty, alg_props, const_expr)
> 
> @@ -490,13 +496,24 @@ def binop_reduce(name, output_size,
> output_type, src_type, prereduce_expr,
>            final(reduce_(reduce_(src0, src1), reduce_(src2, src3))), "")
> 
>  binop("fadd", tfloat, commutative + associative, "src0 + src1")
> +binop_rounding_mode("fadd_rtne", tfloat, commutative + associative,
> +                    "_mesa_roundeven(src0 + src1)", "_rtne")
> 
> 
> There are two things wrong here:
> - The default floating-point environment, and the one Mesa expects, does
> round-to-nearest-even so it's rtz that needs special handling.
> - _mesa_roundeven here is a no-op (it'll implicitly expand to a double
> and then convert back to a float). The rounding actually happens as part
> of the addition itself. I'm not sure if adding as double (with
> round-to-nearest-even) and then rounding back to a float will work, but
> that definitely won't work for doubles. I think you'll have to implement
> round-to-zero addition yourself, or fiddle with the CPU's floating-point
> environment.
> 
> The same goes multiply and fma.
>  

OK, thanks for the feedback. I will implement the needed RTZ ops and
send a new version.

Sam

> 
> +binop_rounding_mode("fadd_rtz", tfloat, commutative + associative,
> "src0 + src1", "_rtz")
> +
>  binop("iadd", tint, commutative + associative, "src0 + src1")
>  binop("uadd_sat", tuint, commutative,
>        "(src0 + src1) < src0 ? UINT64_MAX : (src0 + src1)")
>  binop("fsub", tfloat, "", "src0 - src1")
> +binop_rounding_mode("fsub_rtne", tfloat, "",
> +                    "_mesa_roundeven(src0 - src1)", "_rtne")
> +binop_rounding_mode("fsub_rtz", tfloat, "", "src0 - src1", "_rtz")
>  binop("isub", tint, "", "src0 - src1")
> 
>  binop("fmul", tfloat, commutative + associative, "src0 * src1")
> +binop_rounding_mode("fmul_rtne", tfloat, commutative + associative,
> +                    "_mesa_roundeven(src0 * src1)", "_rtne")
> +binop_rounding_mode("fmul_rtz", tfloat, commutative + associative,
> "src0 * src1", "_rtz")
> +
>  # low 32-bits of signed/unsigned integer multiply
>  binop("imul", tint, commutative + associative, "src0 * src1")
> 
> -- 
> 2.19.1
> 
> ___
> 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 v2 1/7] gallium/auxiliary/vl: Move dirty define to header file

[Christian König]

Patches #1, #2, #5, #7  are Reviewed-by: Christian König 



Patch #3 the csc_matrix need a better name since we now store more and 
more additional info in there, but that can as well be a follow up patch.


Patch #4 is Acked-by: Christian König 

Patch #6 I think there was a simpler option for this.

And when the compute shaders reach the same level of functionality as 
the GFX shaders we should make this the default, depending on the 
hardware capabilities.


Christian.

Am 06.02.19 um 20:44 schrieb Zhu, James:

Move dirty define to header file to share with compute shader.

Signed-off-by: James Zhu 
---
  src/gallium/auxiliary/vl/vl_compositor.c | 15 ++-
  src/gallium/auxiliary/vl/vl_compositor.h |  2 ++
  2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index 159a295..41f9e5e 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -42,9 +42,6 @@
  #include "vl_types.h"
  #include "vl_compositor.h"
  
-#define MIN_DIRTY (0)

-#define MAX_DIRTY (1 << 15)
-
  enum VS_OUTPUT
  {
 VS_O_VPOS = 0,
@@ -899,8 +896,8 @@ gen_vertex_data(struct vl_compositor *c, struct 
vl_compositor_state *s, struct u
   dirty->y1 <= drawn.y1) {
  
 // We clear the dirty area anyway, no need for clear_render_target

-   dirty->x0 = dirty->y0 = MAX_DIRTY;
-   dirty->x1 = dirty->y1 = MIN_DIRTY;
+   dirty->x0 = dirty->y0 = VL_COMPOSITOR_MAX_DIRTY;
+   dirty->x1 = dirty->y1 = VL_COMPOSITOR_MIN_DIRTY;
  }
   }
}
@@ -1030,8 +1027,8 @@ vl_compositor_reset_dirty_area(struct u_rect *dirty)
  {
 assert(dirty);
  
-   dirty->x0 = dirty->y0 = MIN_DIRTY;

-   dirty->x1 = dirty->y1 = MAX_DIRTY;
+   dirty->x0 = dirty->y0 = VL_COMPOSITOR_MIN_DIRTY;
+   dirty->x1 = dirty->y1 = VL_COMPOSITOR_MAX_DIRTY;
  }
  
  void

@@ -1378,8 +1375,8 @@ vl_compositor_render(struct vl_compositor_state *s,
  
c->pipe->clear_render_target(c->pipe, dst_surface, >clear_color,

 0, 0, dst_surface->width, 
dst_surface->height, false);
-  dirty_area->x0 = dirty_area->y0 = MAX_DIRTY;
-  dirty_area->x1 = dirty_area->y1 = MIN_DIRTY;
+  dirty_area->x0 = dirty_area->y0 = VL_COMPOSITOR_MAX_DIRTY;
+  dirty_area->x1 = dirty_area->y1 = VL_COMPOSITOR_MIN_DIRTY;
 }
  
 c->pipe->set_framebuffer_state(c->pipe, >fb_state);

diff --git a/src/gallium/auxiliary/vl/vl_compositor.h 
b/src/gallium/auxiliary/vl/vl_compositor.h
index 8819176..aa843c3 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.h
+++ b/src/gallium/auxiliary/vl/vl_compositor.h
@@ -44,6 +44,8 @@ struct pipe_context;
   */
  
  #define VL_COMPOSITOR_MAX_LAYERS 16

+#define VL_COMPOSITOR_MIN_DIRTY (0)
+#define VL_COMPOSITOR_MAX_DIRTY (1 << 15)
  
  /* deinterlace allgorithem */

  enum vl_compositor_deinterlace


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

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Timur Kristóf]

Tested-By: Timur Kristóf 

It may be worth to note that the issue addressed was with an external
GPU (through Thunderbolt 3) and the performance benefit may be less
extreme on a system on which the bandwidth isn't as constrained.
(Also, the TB3 eGPU is still outperformed by a normal PCI-E GPU.)

Cheers & best regards,
Tim

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

[Mesa-dev] [Bug 109543] After upgrade mesa to 19.0.0~rc1 all vulkan based application stop working ["vulkan-cube" received SIGSEGV in radv_pipeline_init_blend_state at ../src/amd/vulkan/radv_pipeline.

[bugzilla-daemon]

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

--- Comment #7 from mikhail.v.gavri...@gmail.com ---
(In reply to Samuel Pitoiset from comment #6)
> Could be an issue related to GCC 9.

Can you test MESA with GCC9 ?

-- 
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 109543] After upgrade mesa to 19.0.0~rc1 all vulkan based application stop working ["vulkan-cube" received SIGSEGV in radv_pipeline_init_blend_state at ../src/amd/vulkan/radv_pipeline.

[bugzilla-daemon]

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

--- Comment #6 from Samuel Pitoiset  ---
Could be an issue related to GCC 9.

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