[Mesa-dev] [PATCH 2/6] radeonsi/nir: don't add bindless samplers/images to declared bitmasks

[Timothy Arceri]

---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 7dd8314d4b5..01c8554272f 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -656,22 +656,22 @@ void si_nir_scan_shader(const struct nir_shader *nir,
 * eliminated struct dereferences.
 */
if (base_type == GLSL_TYPE_SAMPLER) {
-   info->samplers_declared |=
-   u_bit_consecutive(variable->data.binding, 
aoa_size);
-
if (variable->data.bindless) {
info->const_buffers_declared |= 1;
info->const_file_max[0] +=
glsl_count_attribute_slots(type, false);
+   } else {
+   info->samplers_declared |=
+   
u_bit_consecutive(variable->data.binding, aoa_size);
}
} else if (base_type == GLSL_TYPE_IMAGE) {
-   info->images_declared |=
-   u_bit_consecutive(variable->data.binding, 
aoa_size);
-
if (variable->data.bindless) {
info->const_buffers_declared |= 1;
info->const_file_max[0] +=
glsl_count_attribute_slots(type, false);
+   } else {
+   info->images_declared |=
+   
u_bit_consecutive(variable->data.binding, aoa_size);
}
} else if (base_type != GLSL_TYPE_ATOMIC_UINT) {
if (strncmp(variable->name, "state.", 6) == 0 ||
-- 
2.14.3

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

[Mesa-dev] [PATCH 1/6] st/mesa: stop calling _mesa_init_shader_object_functions()

[Timothy Arceri]

This sets the LinkShader function for the driver, but for the st we
set it properly with the following call to st_init_program_functions().
---
 src/mesa/state_tracker/st_context.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index a3da0f8f1fc..b0266bef8b5 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -714,7 +714,6 @@ void
 st_init_driver_functions(struct pipe_screen *screen,
  struct dd_function_table *functions)
 {
-   _mesa_init_shader_object_functions(functions);
_mesa_init_sampler_object_functions(functions);
 
st_init_draw_functions(functions);
-- 
2.14.3

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

[Mesa-dev] [PATCH 6/6] radeonsi/nir: tidy up si_nir_load_sampler_desc()

[Timothy Arceri]

This makes it easier to follow the code, and also initialises
dynamic_index which will be useful for adding bindless textures
support.
---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 362b7445cc5..f916575a1a1 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -880,14 +880,12 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi,
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
LLVMBuilderRef builder = ctx->ac.builder;
LLVMValueRef list = LLVMGetParam(ctx->main_fn, 
ctx->param_samplers_and_images);
-   LLVMValueRef index = dynamic_index;
+   LLVMValueRef index;
 
assert(!descriptor_set);
 
-   if (!index)
-   index = ctx->ac.i32_0;
-
-   index = LLVMBuildAdd(builder, index,
+   dynamic_index = dynamic_index ? dynamic_index : ctx->ac.i32_0;
+   index = LLVMBuildAdd(builder, dynamic_index,
 LLVMConstInt(ctx->ac.i32, base_index + 
constant_index, false),
 "");
 
-- 
2.14.3

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

[Mesa-dev] [PATCH 4/6] nir: dont lower bindless samplers

[Timothy Arceri]

We neeed to skip the var if its not a uniform here as well as checking
the bindless flag since UBOs can contain bindless samplers.
---
 src/compiler/nir/nir_lower_samplers_as_deref.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_lower_samplers_as_deref.c 
b/src/compiler/nir/nir_lower_samplers_as_deref.c
index b1272e25a92..2a2fb5b093f 100644
--- a/src/compiler/nir/nir_lower_samplers_as_deref.c
+++ b/src/compiler/nir/nir_lower_samplers_as_deref.c
@@ -157,7 +157,8 @@ static bool
 lower_sampler(nir_tex_instr *instr, struct lower_samplers_as_deref_state 
*state,
   nir_builder *b)
 {
-   if (!instr->texture)
+   if (!instr->texture || instr->texture->var->data.bindless ||
+   instr->texture->var->data.mode != nir_var_uniform)
   return false;
 
/* In GLSL, we only fill out the texture field.  The sampler is inferred */
@@ -195,6 +196,11 @@ lower_intrinsic(nir_intrinsic_instr *instr,
instr->intrinsic == nir_intrinsic_image_var_atomic_comp_swap ||
instr->intrinsic == nir_intrinsic_image_var_size) {
   b->cursor = nir_before_instr(>instr);
+
+  if (instr->variables[0]->var->data.bindless ||
+  instr->variables[0]->var->data.mode != nir_var_uniform)
+ return false;
+
   lower_deref(instr->variables[0], state, b);
   return true;
}
-- 
2.14.3

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

[Mesa-dev] [PATCH 3/6] st/glsl_to_nir: set paramater value offset as driver location for packed uniforms

[Timothy Arceri]

This allows us to simplify the code and will also be useful for supporting
bindless textures.
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp |  7 ++-
 src/mesa/state_tracker/st_nir.h   |  3 +--
 src/mesa/state_tracker/st_nir_lower_uniforms_to_ubo.c | 12 
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index f2d4b184d67..682328b398f 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -294,11 +294,16 @@ st_nir_assign_uniform_locations(struct gl_context *ctx,
  if (ctx->Const.PackedDriverUniformStorage) {
 loc = _mesa_add_sized_state_reference(prog->Parameters,
   stateTokens, comps, false);
+loc = prog->Parameters->ParameterValueOffset[loc];
  } else {
 loc = _mesa_add_state_reference(prog->Parameters, stateTokens);
  }
   } else {
  loc = st_nir_lookup_parameter_index(prog->Parameters, uniform->name);
+
+ if (ctx->Const.PackedDriverUniformStorage) {
+loc = prog->Parameters->ParameterValueOffset[loc];
+ }
   }
 
   uniform->data.driver_location = loc;
@@ -804,7 +809,7 @@ st_finalize_nir(struct st_context *st, struct gl_program 
*prog,
if (st->ctx->Const.PackedDriverUniformStorage) {
   NIR_PASS_V(nir, nir_lower_io, nir_var_uniform, st_glsl_type_dword_size,
  (nir_lower_io_options)0);
-  NIR_PASS_V(nir, st_nir_lower_uniforms_to_ubo, prog->Parameters);
+  NIR_PASS_V(nir, st_nir_lower_uniforms_to_ubo);
}
 
if (screen->get_param(screen, PIPE_CAP_NIR_SAMPLERS_AS_DEREF))
diff --git a/src/mesa/state_tracker/st_nir.h b/src/mesa/state_tracker/st_nir.h
index 3dd78fb1155..1c2e32a5e6f 100644
--- a/src/mesa/state_tracker/st_nir.h
+++ b/src/mesa/state_tracker/st_nir.h
@@ -36,8 +36,7 @@ struct nir_shader;
 void st_nir_lower_builtin(struct nir_shader *shader);
 void st_nir_lower_tex_src_plane(struct nir_shader *shader, unsigned free_slots,
 unsigned lower_2plane, unsigned lower_3plane);
-bool st_nir_lower_uniforms_to_ubo(struct nir_shader *shader,
-  const struct gl_program_parameter_list 
*params);
+bool st_nir_lower_uniforms_to_ubo(struct nir_shader *shader);
 
 void st_finalize_nir(struct st_context *st, struct gl_program *prog,
  struct gl_shader_program *shader_program,
diff --git a/src/mesa/state_tracker/st_nir_lower_uniforms_to_ubo.c 
b/src/mesa/state_tracker/st_nir_lower_uniforms_to_ubo.c
index b2f8f833bbb..1727f8214a0 100644
--- a/src/mesa/state_tracker/st_nir_lower_uniforms_to_ubo.c
+++ b/src/mesa/state_tracker/st_nir_lower_uniforms_to_ubo.c
@@ -36,8 +36,7 @@
 #include "program/prog_parameter.h"
 
 static bool
-lower_instr(nir_intrinsic_instr *instr, nir_builder *b,
-const struct gl_program_parameter_list *params)
+lower_instr(nir_intrinsic_instr *instr, nir_builder *b)
 {
b->cursor = nir_before_instr(>instr);
 
@@ -50,11 +49,9 @@ lower_instr(nir_intrinsic_instr *instr, nir_builder *b,
}
 
if (instr->intrinsic == nir_intrinsic_load_uniform) {
-  unsigned pvo = params->ParameterValueOffset[nir_intrinsic_base(instr)];
-
   nir_ssa_def *ubo_idx = nir_imm_int(b, 0);
   nir_ssa_def *ubo_offset =
- nir_iadd(b, nir_imm_int(b, 4 * pvo),
+ nir_iadd(b, nir_imm_int(b, 4 * nir_intrinsic_base(instr)),
   nir_imul(b, nir_imm_int(b, 4),
nir_ssa_for_src(b, instr->src[0], 1)));
 
@@ -77,8 +74,7 @@ lower_instr(nir_intrinsic_instr *instr, nir_builder *b,
 }
 
 bool
-st_nir_lower_uniforms_to_ubo(nir_shader *shader,
- const struct gl_program_parameter_list *params)
+st_nir_lower_uniforms_to_ubo(nir_shader *shader)
 {
bool progress = false;
 
@@ -90,7 +86,7 @@ st_nir_lower_uniforms_to_ubo(nir_shader *shader,
 nir_foreach_instr_safe(instr, block) {
if (instr->type == nir_instr_type_intrinsic)
   progress |= lower_instr(nir_instr_as_intrinsic(instr),
-  , params);
+  );
 }
  }
 
-- 
2.14.3

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

[Mesa-dev] [PATCH 5/6] radeonsi/nir: set uses_bindless_images for images

[Timothy Arceri]

V2: add missing intrinsics (Spotted-by: Samuel Pitoiset)
---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 01c8554272f..362b7445cc5 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -123,6 +123,13 @@ static void scan_instruction(struct tgsi_shader_info *info,
case nir_intrinsic_load_tess_level_outer:
info->reads_tess_factors = true;
break;
+   case nir_intrinsic_image_var_load:
+   case nir_intrinsic_image_var_size:
+   case nir_intrinsic_image_var_samples: {
+   nir_variable *var = intr->variables[0]->var;
+   if (var->data.bindless)
+   info->uses_bindless_images = true;
+   }
case nir_intrinsic_image_var_store:
case nir_intrinsic_image_var_atomic_add:
case nir_intrinsic_image_var_atomic_min:
@@ -131,7 +138,11 @@ static void scan_instruction(struct tgsi_shader_info *info,
case nir_intrinsic_image_var_atomic_or:
case nir_intrinsic_image_var_atomic_xor:
case nir_intrinsic_image_var_atomic_exchange:
-   case nir_intrinsic_image_var_atomic_comp_swap:
+   case nir_intrinsic_image_var_atomic_comp_swap: {
+   nir_variable *var = intr->variables[0]->var;
+   if (var->data.bindless)
+   info->uses_bindless_images = true;
+   }
case nir_intrinsic_store_ssbo:
case nir_intrinsic_ssbo_atomic_add:
case nir_intrinsic_ssbo_atomic_imin:
-- 
2.14.3

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

[Mesa-dev] Some radeonsi NIR bindless prep patches

[Timothy Arceri]

I've been sitting on these for a while so decided to send them out
while Karol and Jason sort out the core NIR patches.

The first patch is an unrelated clean up.

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

[Mesa-dev] [PATCH] loader: disable virgl driver when no 3D for virtio

[Lepton Wu]

If user are running mesa under old version of qemu or have turned off
GL at runtime, virtio gpu driver actually doesn't work. Adding a detection
here can make sure same disk image work with both cases.

Signed-off-by: Lepton Wu 
---
 src/loader/loader.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 43275484cc..2a689c52d6 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -381,6 +381,27 @@ out:
log_(driver ? _LOADER_DEBUG : _LOADER_WARNING,
  "pci id for fd %d: %04x:%04x, driver %s\n",
  fd, vendor_id, chip_id, driver);
+   if (!strcmp(driver, "virtio_gpu")) {
+  struct drm_virtgpu_getparam {
+ uint64_t param;
+ uint64_t value;
+  };
+  #define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw 
*/
+  struct drm_virtgpu_getparam args;
+  uint32_t gl = 0;
+  args.param = VIRTGPU_PARAM_3D_FEATURES;
+  args.value = (uint64_t)(uintptr_t)
+  #define DRM_VIRTGPU_GETPARAM0x03
+  #define DRM_IOCTL_VIRTGPU_GETPARAM \
+ DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_GETPARAM,\
+  struct drm_virtgpu_getparam)
+  int ret = drmIoctl(fd, DRM_IOCTL_VIRTGPU_GETPARAM, );
+  if (ret || !gl) {
+ /* Actually there is no virtio_2d driver, mesa will
+  * fallback to software driver */
+ return strdup("virtio_gpu_2d");
+  }
+   }
return driver;
 }
 
-- 
2.17.0.484.g0c8726318c-goog

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

[Mesa-dev] [RFC] Disable virgl driver when no 3D for virtio.

[Lepton Wu]

I know this looks like a hack. But just want to send this out for comments
to see how can I address this issue in mesa:
virgl driver enabled image can't work on legacy qemu or GL disabled qemu.

It seems another choice could be playing with MESA_LOADER_DRIVER_OVERRIDE to
override driver name, but that means everybody have to do something similar.
It should be better to fix this in mesa. Another possible solution
could be to add detection in virgl driver and let virgl handle the fallback
itself. Then it seems we have to duplicate code from kms_swrast or do some
non trivial refactoring?

Any thoughts? Thanks!


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

Re: [Mesa-dev] [PATCH 3/3] radv: implement a fast prefetch path for the vertex stage

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

on Polaris 20 / RX580
with F1 2017, smoketest

Dieter

Am 04.04.2018 12:12, schrieb Samuel Pitoiset:

This allows to start draws as soon as possible.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 40 
++--

 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
b/src/amd/vulkan/radv_cmd_buffer.c

index 393d9ba4f4..0e59f99799 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -640,39 +640,48 @@ radv_emit_shader_prefetch(struct radv_cmd_buffer
*cmd_buffer,

 static void
 radv_emit_prefetch_L2(struct radv_cmd_buffer *cmd_buffer,
- struct radv_pipeline *pipeline)
+ struct radv_pipeline *pipeline,
+ bool vertex_stage_only)
 {
struct radv_cmd_state *state = _buffer->state;
+   uint32_t mask = state->prefetch_L2_mask;

if (cmd_buffer->device->physical_device->rad_info.chip_class < CIK)
return;

-   if (state->prefetch_L2_mask & RADV_PREFETCH_VS)
+   if (vertex_stage_only) {
+   /* Fast prefetch path for starting draws as soon as possible.
+*/
+   mask = state->prefetch_L2_mask & (RADV_PREFETCH_VS |
+ 
RADV_PREFETCH_VBO_DESCRIPTORS);
+   }
+
+   if (mask & RADV_PREFETCH_VS)
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_VERTEX]);

-   if (state->prefetch_L2_mask & RADV_PREFETCH_VBO_DESCRIPTORS)
+   if (mask & RADV_PREFETCH_VBO_DESCRIPTORS)
si_cp_dma_prefetch(cmd_buffer, state->vb_va, state->vb_size);

-   if (state->prefetch_L2_mask & RADV_PREFETCH_TCS)
+   if (mask & RADV_PREFETCH_TCS)
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_TESS_CTRL]);

-   if (state->prefetch_L2_mask & RADV_PREFETCH_TES)
+   if (mask & RADV_PREFETCH_TES)
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_TESS_EVAL]);

-   if (state->prefetch_L2_mask & RADV_PREFETCH_GS) {
+   if (mask & RADV_PREFETCH_GS) {
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_GEOMETRY]);
radv_emit_shader_prefetch(cmd_buffer, pipeline->gs_copy_shader);
}

-   if (state->prefetch_L2_mask & RADV_PREFETCH_PS)
+   if (mask & RADV_PREFETCH_PS)
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_FRAGMENT]);

-   state->prefetch_L2_mask = 0;
+   state->prefetch_L2_mask &= ~mask;
 }

 static void
@@ -3042,7 +3051,7 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
 */
if (cmd_buffer->state.prefetch_L2_mask) {
radv_emit_prefetch_L2(cmd_buffer,
- cmd_buffer->state.pipeline);
+ cmd_buffer->state.pipeline, 
false);
}
} else {
/* If we don't wait for idle, start prefetches first, then set
@@ -3051,8 +3060,11 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
si_emit_cache_flush(cmd_buffer);

if (cmd_buffer->state.prefetch_L2_mask) {
+   /* Only prefetch the vertex shader and VBO descriptors
+* in order to start the draw as soon as possible.
+*/
radv_emit_prefetch_L2(cmd_buffer,
- cmd_buffer->state.pipeline);
+ cmd_buffer->state.pipeline, true);
}

 		if (!radv_upload_graphics_shader_descriptors(cmd_buffer, 
pipeline_is_dirty))

@@ -3060,6 +3072,14 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,

radv_emit_all_graphics_states(cmd_buffer, info);
radv_emit_draw_packets(cmd_buffer, info);
+
+   /* Prefetch the remaining shaders after the draw has been
+* started.
+*/
+   if (cmd_buffer->state.prefetch_L2_mask) {
+   radv_emit_prefetch_L2(cmd_buffer,
+ cmd_buffer->state.pipeline, 
false);
+   }
}

assert(cmd_buffer->cs->cdw <= cdw_max);

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

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Ilia Mirkin]

On Wed, Apr 4, 2018 at 12:12 PM, Emil Velikov  wrote:
> On 22 March 2018 at 00:39, Ilia Mirkin  wrote:
>> Just one bit of feedback, for the rest I either agree or have no opinion:
>>
>> On Wed, Mar 21, 2018 at 8:28 PM, Emil Velikov  
>> wrote:
>>>  * unfit and late nominations:
>>> * any rejections that are unfit based on the existing criteria can
>>>   be merged as long as:
>>>* subsystem specific patches are approved by the team
>>>  maintainer(s).
>>>* patches that cover multiple subsystems are approved by 50%+1
>>>  of the maintainers of the affected subsystems.
>>
>> I don't think 50% + 1 is workable. That would mean for a core mesa
>> patch, one would have to get like 5+ people to ack it. Seems like a
>> lot. (And I suspect will lead to debates about how to count "affected"
>> subsystems.) IMHO 2 is enough, i.e. the maintainer that wants it, and
>> another maintainer who thinks it's reasonable.
>>
> The presumption of 5+ people is based that we'll get at least 8
> sub-system maintainers.

That's what I mean -- you'll get quibbling over who's involved and
who's not. There are like 10 different drivers, each with a separate
maintainer, and they can all be variously affected by a patch.
Figuring out how to "count" properly is complicated and seemingly
unnecessary. 2's enough - this isn't for a poll, it's for a "someone
other than me thinks this is important", to counter a "unfit and late
nomination" style argument from the release engineer. Getting a lot of
people to *actively* support a patch is a straight path to nothing
happening. Getting one other person (out of the maintainer group)
seems reasonable. These types of (social) systems are fairly
self-policing -- if we really do run into serious problems, they can
be addressed then.

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

[Mesa-dev] GL_EXT_memory_object_fd on intel ?

[Stuart Axon]

Hi Mesa Devs,
   Do intel mesa devs take requests ?

I'm on the Linux Visual Artists group on Facebook and we've been wanting to 
implement something like Syphon (OSX) or Spout (windows) - where different 
processes can share textures.

it looks like GL_EXT_memory_object_fd is just the thing.  Mesamatrix shows this 
implemented on AMD, while Nvidia has it on it's commercial driver.

Is there any chance of this coming to Intel graphics ?

Best Regards
Stuart Axon

[Thanks Jani Nikula, for pointing me to here after I randomly mailed him this 
request.]

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

[Mesa-dev] [PATCH,v3] configure.ac/meson.build: Fix -latomic test

[Nicolas Boichat]

When compiling with LLVM 6.0 on x86 (32-bit) for Android, the test
fails to detect that -latomic is actually required, as the atomic
call is inlined.

In the code itself (src/util/disk_cache.c), we see this pattern:
p_atomic_add(cache->size, - (uint64_t)size);
where cache->size is an uint64_t *, and results in the following
link time error without -latomic:
src/util/disk_cache.c:628: error: undefined reference to '__atomic_fetch_add_8'

Fix the configure/meson test to replicate this pattern, which then
correctly realizes the need for -latomic.

Signed-off-by: Nicolas Boichat 
---

Changes since v1:
 - Updated meson.build as well (untested)

Changes since v2:
 - Moved * with the v in configure.ac

 configure.ac | 6 --
 meson.build  | 6 --
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index e874f8ebfb2..69981a6f3dd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -445,9 +445,11 @@ if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
 AC_MSG_CHECKING(whether -latomic is needed)
 AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #include 
-uint64_t v;
+struct {
+uint64_t *v;
+} x;
 int main() {
-return (int)__atomic_load_n(, __ATOMIC_ACQUIRE);
+return (int)__atomic_load_n(x.v, __ATOMIC_ACQUIRE);
 }]])], GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC=no, 
GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC=yes)
 AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC)
 if test "x$GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC" = xyes; then
diff --git a/meson.build b/meson.build
index ee2b4151e2f..c73b20f986c 100644
--- a/meson.build
+++ b/meson.build
@@ -845,8 +845,10 @@ if cc.compiles('int main() { int n; return 
__atomic_load_n(, __ATOMIC_ACQUIRE)
   # as ARM.
   if not cc.links('''#include 
  int main() {
-   uint64_t n;
-   return (int)__atomic_load_n(, __ATOMIC_ACQUIRE);
+   struct {
+ uint64_t *v;
+   } x;
+   return (int)__atomic_load_n(x.v, __ATOMIC_ACQUIRE);
  }''',
   name : 'GCC atomic builtins required -latomic')
 dep_atomic = cc.find_library('atomic')
-- 
2.17.0.484.g0c8726318c-goog

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

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Laura Ekstrand]

I forgot to note that you have to choose space->ignore in the diff options
on cgit in order to see the easy-to-read git diff.

On Wed, Apr 4, 2018 at 5:57 PM, Laura Ekstrand  wrote:

> Jean,
>
> The main problem is not the conversion to rst.  It's preserving the git
> history so that the patches are easily reviewable.
>
> I've started a branch here:  https://cgit.freedesktop.org/~
> ldeks/mesa?h=website2.  You see that the git diff shows me that the text
> of the website hasn't changed at all?
>
> I will probably squish the rename commits together at some point.  But the
> format changes have to be in separate patches so git recognizes that the
> text of the website hasn't really changed.
>
> Thanks.
>
> Laura
>
> On Tue, Apr 3, 2018 at 1:36 PM, Jean Hertel 
> wrote:
>
>> Hi Laura,
>>
>>
>> Aurelio Silves pointed me out that there is the possibility of using
>> pandoc for the conversion of mesa html sources to rst.
>>
>> You can take a look here: https://pandoc.org/index.html
>>
>> Depending on your distribution, probably there is a package for this.
>>
>>
>> Also, if there is anything else I can do, send me an email and I will do
>> the best I can to help.
>>
>> Kind Regards,
>>
>> Jean Hertel
>>
>>
>> --
>> *De:* Jean Hertel 
>> *Enviado:* segunda-feira, 2 de abril de 2018 21:19
>> *Para:* Laura Ekstrand
>>
>> *Cc:* Emil Velikov; Vedran Miletić; mesa-dev@lists.freedesktop.org;
>> Jason Ekstrand
>> *Assunto:* Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx
>>
>> Hi Laura,
>>
>> I haven't used any script.
>> I made all the HTML to rst translations by hand, file by file.
>>
>> Kind Regards,
>> Jean Hertel
>>
>> Em 2 de abril de 2018 19:09:34 BRT, Laura Ekstrand 
>> escreveu:
>>
>> Hi Jean,
>>
>> I'm going to play around with your patches to get them into a format that
>> Mesa devs can review.  This will blow the history away.
>>
>> The problem is that your workflow in 1 & 2 ruins the Git history for
>> reviewers.  It makes the patch series hard to read.
>>
>> Could you provide us with your script for translating HTML to rst?  Go
>> ahead and commit it to your repo as a patch.
>>
>> Thanks.
>>
>> Laura
>>
>> On Sun, Apr 1, 2018 at 6:12 AM, Jean Hertel 
>> wrote:
>>
>> Hi Laura,
>>
>>
>> The commits have the idea of being atomic, so it makes sense to have a
>> lot of them.
>>
>> Some of them are just fixes, and can be squashed.
>>
>>
>> Please keep in mind that no CSS file is supposed to live there, as we are
>> using an existing template from readTheDocs.
>>
>> The commits are doing mainly two things:
>>
>> 1 - Create a new file and translate the old HTML content into a rst
>> format.
>>
>> 2 - Delete the old file
>>
>> Kind Regards,
>>
>> Jean Hertel
>>
>> --
>> *De:* Laura Ekstrand 
>> *Enviado:* sábado, 31 de março de 2018 22:06
>> *Para:* Jean Hertel
>> *Cc:* Emil Velikov; Vedran Miletić; mesa-dev@lists.freedesktop.org;
>> Jason Ekstrand
>> *Assunto:* Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx
>>
>> Jean,
>>
>> I've taken at look at your sphinx-docs branch (
>> https://github.com/jlHertel/mesa).
>>
>> Oh my you have a lot of commits there!  It would be simpler for me to
>> review if you could squash some of them together.
>>
>> I am thinking a series on the order of 30 patches to start - just the
>> pretty CSS stuff in Sphinx.
>>
>> Once we get the page to look nicer, then we can start editing the content
>> for readability!!!
>>
>> Thanks.
>>
>> Laura
>>
>> On Sat, Mar 31, 2018 at 5:57 PM, Laura Ekstrand 
>> wrote:
>>
>> Hello Jean,
>>
>> Has anyone reviewed your patch series yet?   I would like to get these
>> website updates moving.
>>
>> Thanks.
>>
>> Laura
>>
>> On Tue, Jun 6, 2017 at 10:43 AM, Jean Hertel 
>> wrote:
>>
>> Hello Emil,
>>
>> I've updated the website with the new release notes template.
>>
>> Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html
>>
>>
>> What about rebasing my current work on top of mesa-master?
>> (Remembering that github comments referencing directly the commit will be
>> loss)
>>
>>
>> The repository: https://github.com/jlHertel/mesa
>> Demo site: http://mesa2.jeanhertel.com.br/
>>
>> Best regards,
>> Jean Hertel
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>>
>>
>>
>>
>> --
>> Enviado de meu dispositivo Android com K-9 mail. Desculpe-me pela
>> brevidade.
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Laura Ekstrand]

Jean,

The main problem is not the conversion to rst.  It's preserving the git
history so that the patches are easily reviewable.

I've started a branch here:
https://cgit.freedesktop.org/~ldeks/mesa?h=website2.  You see that the git
diff shows me that the text of the website hasn't changed at all?

I will probably squish the rename commits together at some point.  But the
format changes have to be in separate patches so git recognizes that the
text of the website hasn't really changed.

Thanks.

Laura

On Tue, Apr 3, 2018 at 1:36 PM, Jean Hertel  wrote:

> Hi Laura,
>
>
> Aurelio Silves pointed me out that there is the possibility of using
> pandoc for the conversion of mesa html sources to rst.
>
> You can take a look here: https://pandoc.org/index.html
>
> Depending on your distribution, probably there is a package for this.
>
>
> Also, if there is anything else I can do, send me an email and I will do
> the best I can to help.
>
> Kind Regards,
>
> Jean Hertel
>
>
> --
> *De:* Jean Hertel 
> *Enviado:* segunda-feira, 2 de abril de 2018 21:19
> *Para:* Laura Ekstrand
>
> *Cc:* Emil Velikov; Vedran Miletić; mesa-dev@lists.freedesktop.org; Jason
> Ekstrand
> *Assunto:* Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx
>
> Hi Laura,
>
> I haven't used any script.
> I made all the HTML to rst translations by hand, file by file.
>
> Kind Regards,
> Jean Hertel
>
> Em 2 de abril de 2018 19:09:34 BRT, Laura Ekstrand 
> escreveu:
>
> Hi Jean,
>
> I'm going to play around with your patches to get them into a format that
> Mesa devs can review.  This will blow the history away.
>
> The problem is that your workflow in 1 & 2 ruins the Git history for
> reviewers.  It makes the patch series hard to read.
>
> Could you provide us with your script for translating HTML to rst?  Go
> ahead and commit it to your repo as a patch.
>
> Thanks.
>
> Laura
>
> On Sun, Apr 1, 2018 at 6:12 AM, Jean Hertel 
> wrote:
>
> Hi Laura,
>
>
> The commits have the idea of being atomic, so it makes sense to have a lot
> of them.
>
> Some of them are just fixes, and can be squashed.
>
>
> Please keep in mind that no CSS file is supposed to live there, as we are
> using an existing template from readTheDocs.
>
> The commits are doing mainly two things:
>
> 1 - Create a new file and translate the old HTML content into a rst format.
>
> 2 - Delete the old file
>
> Kind Regards,
>
> Jean Hertel
>
> --
> *De:* Laura Ekstrand 
> *Enviado:* sábado, 31 de março de 2018 22:06
> *Para:* Jean Hertel
> *Cc:* Emil Velikov; Vedran Miletić; mesa-dev@lists.freedesktop.org; Jason
> Ekstrand
> *Assunto:* Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx
>
> Jean,
>
> I've taken at look at your sphinx-docs branch (
> https://github.com/jlHertel/mesa).
>
> Oh my you have a lot of commits there!  It would be simpler for me to
> review if you could squash some of them together.
>
> I am thinking a series on the order of 30 patches to start - just the
> pretty CSS stuff in Sphinx.
>
> Once we get the page to look nicer, then we can start editing the content
> for readability!!!
>
> Thanks.
>
> Laura
>
> On Sat, Mar 31, 2018 at 5:57 PM, Laura Ekstrand 
> wrote:
>
> Hello Jean,
>
> Has anyone reviewed your patch series yet?   I would like to get these
> website updates moving.
>
> Thanks.
>
> Laura
>
> On Tue, Jun 6, 2017 at 10:43 AM, Jean Hertel 
> wrote:
>
> Hello Emil,
>
> I've updated the website with the new release notes template.
>
> Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html
>
>
> What about rebasing my current work on top of mesa-master?
> (Remembering that github comments referencing directly the commit will be
> loss)
>
>
> The repository: https://github.com/jlHertel/mesa
> Demo site: http://mesa2.jeanhertel.com.br/
>
> Best regards,
> Jean Hertel
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
>
>
> --
> Enviado de meu dispositivo Android com K-9 mail. Desculpe-me pela
> brevidade.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 15/17] radeonsi: always prefetch later shaders after the draw packet

[Marek Olšák]

From: Marek Olšák 

so that the draw is started as soon as possible.

v2: only prefetch the API VS and VBO descriptors
---
 src/gallium/drivers/radeonsi/si_cp_dma.c | 89 +---
 src/gallium/drivers/radeonsi/si_pipe.h   |  2 +-
 src/gallium/drivers/radeonsi/si_state_draw.c | 10 +++-
 3 files changed, 75 insertions(+), 26 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c 
b/src/gallium/drivers/radeonsi/si_cp_dma.c
index 15bd305a350..1e26774ffee 100644
--- a/src/gallium/drivers/radeonsi/si_cp_dma.c
+++ b/src/gallium/drivers/radeonsi/si_cp_dma.c
@@ -514,80 +514,123 @@ static void cik_prefetch_shader_async(struct si_context 
*sctx,
 static void cik_prefetch_VBO_descriptors(struct si_context *sctx)
 {
if (!sctx->vertex_elements)
return;
 
cik_prefetch_TC_L2_async(sctx, >vb_descriptors_buffer->b.b,
 sctx->vb_descriptors_offset,
 sctx->vertex_elements->desc_list_byte_size);
 }
 
-void cik_emit_prefetch_L2(struct si_context *sctx)
+/**
+ * Prefetch shaders and VBO descriptors.
+ *
+ * \param vertex_stage_only  Whether only the the API VS and VBO descriptors
+ *   should be prefetched.
+ */
+void cik_emit_prefetch_L2(struct si_context *sctx, bool vertex_stage_only)
 {
+   unsigned mask = sctx->prefetch_L2_mask;
+   assert(mask);
+
/* Prefetch shaders and VBO descriptors to TC L2. */
if (sctx->b.chip_class >= GFX9) {
/* Choose the right spot for the VBO prefetch. */
if (sctx->tes_shader.cso) {
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_HS)
+   if (mask & SI_PREFETCH_HS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.hs);
-   if (sctx->prefetch_L2_mask & 
SI_PREFETCH_VBO_DESCRIPTORS)
+   if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
cik_prefetch_VBO_descriptors(sctx);
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_GS)
+   if (vertex_stage_only) {
+   sctx->prefetch_L2_mask &= ~(SI_PREFETCH_HS |
+   
SI_PREFETCH_VBO_DESCRIPTORS);
+   return;
+   }
+
+   if (mask & SI_PREFETCH_GS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.gs);
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
+   if (mask & SI_PREFETCH_VS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.vs);
} else if (sctx->gs_shader.cso) {
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_GS)
+   if (mask & SI_PREFETCH_GS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.gs);
-   if (sctx->prefetch_L2_mask & 
SI_PREFETCH_VBO_DESCRIPTORS)
+   if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
cik_prefetch_VBO_descriptors(sctx);
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
+   if (vertex_stage_only) {
+   sctx->prefetch_L2_mask &= ~(SI_PREFETCH_GS |
+   
SI_PREFETCH_VBO_DESCRIPTORS);
+   return;
+   }
+
+   if (mask & SI_PREFETCH_VS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.vs);
} else {
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
+   if (mask & SI_PREFETCH_VS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.vs);
-   if (sctx->prefetch_L2_mask & 
SI_PREFETCH_VBO_DESCRIPTORS)
+   if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
cik_prefetch_VBO_descriptors(sctx);
+   if (vertex_stage_only) {
+   sctx->prefetch_L2_mask &= ~(SI_PREFETCH_VS |
+   
SI_PREFETCH_VBO_DESCRIPTORS);
+   return;
+   }
}
} else {
/* SI-CI-VI */
/* Choose the right spot for the VBO prefetch. */
if (sctx->tes_shader.cso) {
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_LS)
+   if (mask & SI_PREFETCH_LS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.ls);
-   if (sctx->prefetch_L2_mask & 
SI_PREFETCH_VBO_DESCRIPTORS)
+   if (mask & 

Re: [Mesa-dev] [PATCH 1/2] dri: Add __DRI_IMAGE_FORMAT_SABGR8

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Apr 3, 2018 at 5:48 AM, Tapani Pälli  wrote:

> ping ..
>
> (currently Android-IA sets EGL_KHR_gl_colorspace to false because these
> are missing)
>
>
> On 03/19/2018 01:41 PM, Tapani Pälli wrote:
>
>> Add format definition and required plumbing to create images.
>> Note that there is no match to drm_fourcc definition, just like
>> with existing _DRI_IMAGE_FOURCC_SARGB.
>>
>> Signed-off-by: Tapani Pälli 
>> ---
>>   include/GL/internal/dri_interface.h| 2 ++
>>   src/loader/loader_dri3_helper.c| 2 ++
>>   src/mesa/drivers/dri/common/dri_util.c | 4 
>>   src/mesa/drivers/dri/common/utils.c| 1 +
>>   4 files changed, 9 insertions(+)
>>
>> diff --git a/include/GL/internal/dri_interface.h
>> b/include/GL/internal/dri_interface.h
>> index 4f4795c7ae..319a1fe4f9 100644
>> --- a/include/GL/internal/dri_interface.h
>> +++ b/include/GL/internal/dri_interface.h
>> @@ -1253,6 +1253,7 @@ struct __DRIdri2ExtensionRec {
>>   #define __DRI_IMAGE_FORMAT_YUYV 0x100f
>>   #define __DRI_IMAGE_FORMAT_XBGR2101010  0x1010
>>   #define __DRI_IMAGE_FORMAT_ABGR2101010  0x1011
>> +#define __DRI_IMAGE_FORMAT_SABGR8   0x1012
>> #define __DRI_IMAGE_USE_SHARE   0x0001
>>   #define __DRI_IMAGE_USE_SCANOUT   0x0002
>> @@ -1289,6 +1290,7 @@ struct __DRIdri2ExtensionRec {
>>   #define __DRI_IMAGE_FOURCC_ABGR   0x34324241
>>   #define __DRI_IMAGE_FOURCC_XBGR   0x34324258
>>   #define __DRI_IMAGE_FOURCC_SARGB  0x83324258
>> +#define __DRI_IMAGE_FOURCC_SABGR   0x84324258
>>   #define __DRI_IMAGE_FOURCC_ARGB21010100x30335241
>>   #define __DRI_IMAGE_FOURCC_XRGB21010100x30335258
>>   #define __DRI_IMAGE_FOURCC_ABGR21010100x30334241
>> diff --git a/src/loader/loader_dri3_helper.c
>> b/src/loader/loader_dri3_helper.c
>> index c1d94c3c21..f8cdd9c642 100644
>> --- a/src/loader/loader_dri3_helper.c
>> +++ b/src/loader/loader_dri3_helper.c
>> @@ -1022,6 +1022,7 @@ dri3_cpp_for_format(uint32_t format) {
>>  case  __DRI_IMAGE_FORMAT_XBGR2101010:
>>  case  __DRI_IMAGE_FORMAT_ABGR2101010:
>>  case  __DRI_IMAGE_FORMAT_SARGB8:
>> +   case  __DRI_IMAGE_FORMAT_SABGR8:
>> return 4;
>>  case  __DRI_IMAGE_FORMAT_NONE:
>>  default:
>> @@ -1041,6 +1042,7 @@ image_format_to_fourcc(int format)
>>  /* Convert from __DRI_IMAGE_FORMAT to __DRI_IMAGE_FOURCC (sigh) */
>>  switch (format) {
>>  case __DRI_IMAGE_FORMAT_SARGB8: return __DRI_IMAGE_FOURCC_SARGB;
>> +   case __DRI_IMAGE_FORMAT_SABGR8: return __DRI_IMAGE_FOURCC_SABGR;
>>  case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565;
>>  case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
>>  case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
>> diff --git a/src/mesa/drivers/dri/common/dri_util.c
>> b/src/mesa/drivers/dri/common/dri_util.c
>> index a34f38d611..214be4a3fc 100644
>> --- a/src/mesa/drivers/dri/common/dri_util.c
>> +++ b/src/mesa/drivers/dri/common/dri_util.c
>> @@ -892,6 +892,8 @@ driGLFormatToImageFormat(mesa_format format)
>> return __DRI_IMAGE_FORMAT_GR88;
>>  case MESA_FORMAT_NONE:
>> return __DRI_IMAGE_FORMAT_NONE;
>> +   case MESA_FORMAT_R8G8B8A8_SRGB:
>> +  return __DRI_IMAGE_FORMAT_SABGR8;
>>  case MESA_FORMAT_B8G8R8A8_SRGB:
>> return __DRI_IMAGE_FORMAT_SARGB8;
>>  default:
>> @@ -929,6 +931,8 @@ driImageFormatToGLFormat(uint32_t image_format)
>> return MESA_FORMAT_R16G16_UNORM;
>>  case __DRI_IMAGE_FORMAT_SARGB8:
>> return MESA_FORMAT_B8G8R8A8_SRGB;
>> +   case __DRI_IMAGE_FORMAT_SABGR8:
>> +  return MESA_FORMAT_R8G8B8A8_SRGB;
>>  case __DRI_IMAGE_FORMAT_NONE:
>> return MESA_FORMAT_NONE;
>>  default:
>> diff --git a/src/mesa/drivers/dri/common/utils.c
>> b/src/mesa/drivers/dri/common/utils.c
>> index 1cffd3ad08..fc5e2d19f3 100644
>> --- a/src/mesa/drivers/dri/common/utils.c
>> +++ b/src/mesa/drivers/dri/common/utils.c
>> @@ -208,6 +208,7 @@ driCreateConfigs(mesa_format format,
>> masks = masks_table[2];
>> break;
>>  case MESA_FORMAT_R8G8B8A8_UNORM:
>> +   case MESA_FORMAT_R8G8B8A8_SRGB:
>> masks = masks_table[5];
>> break;
>>  case MESA_FORMAT_R8G8B8X8_UNORM:
>>
>> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium/hud: add a simple HUD view that only draws text

[Marek Olšák]

From: Marek Olšák 

Add this prefix to the env var: "simple," For example:
GALLIUM_HUD=simple,fps

The X coordinates are the same, but the Y coordinates are different, because
there is only text.

'+' happens to behave the same as "\n".
',' happens to behave the same as "\n\n".
---
 src/gallium/auxiliary/hud/hud_context.c | 72 ++---
 src/gallium/auxiliary/hud/hud_private.h |  3 +-
 2 files changed, 60 insertions(+), 15 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index 4d2458eb2e4..1baaabbb38e 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -391,20 +391,40 @@ hud_pane_accumulate_vertices(struct hud_context *hud,
   assert(hud->whitelines.num_vertices + num/2 + 2 <= 
hud->whitelines.max_num_vertices);
   line_verts[num++] = pane->x1;
   line_verts[num++] = y;
   line_verts[num++] = pane->x2;
   line_verts[num++] = y;
}
 
hud->whitelines.num_vertices += num/2;
 }
 
+static void
+hud_pane_accumulate_vertices_simple(struct hud_context *hud,
+const struct hud_pane *pane)
+{
+   struct hud_graph *gr;
+   unsigned i;
+   char str[32];
+
+   /* draw info below the pane */
+   i = 0;
+   LIST_FOR_EACH_ENTRY(gr, >graph_list, head) {
+  unsigned x = pane->x1;
+  unsigned y = pane->y_simple + i*hud->font.glyph_height;
+
+  number_to_human_readable(gr->current_value, pane->type, str);
+  hud_draw_string(hud, x, y, "%s: %s", gr->name, str);
+  i++;
+   }
+}
+
 static void
 hud_pane_draw_colored_objects(struct hud_context *hud,
   const struct hud_pane *pane)
 {
struct hud_graph *gr;
unsigned i;
 
/* draw colored quads below the pane */
i = 0;
LIST_FOR_EACH_ENTRY(gr, >graph_list, head) {
@@ -540,20 +560,37 @@ hud_draw_results(struct hud_context *hud, struct 
pipe_resource *tex)
   hud->constants.scale[0] = 1;
   hud->constants.scale[1] = 1;
 
   cso_set_constant_buffer(cso, PIPE_SHADER_VERTEX, 0, >constbuf);
   cso_set_vertex_buffers(cso, cso_get_aux_vertex_buffer_slot(cso), 1,
  >bg.vbuf);
   cso_draw_arrays(cso, PIPE_PRIM_QUADS, 0, hud->bg.num_vertices);
}
pipe_resource_reference(>bg.vbuf.buffer.resource, NULL);
 
+   /* draw accumulated vertices for text */
+   if (hud->text.num_vertices) {
+  cso_set_vertex_buffers(cso, cso_get_aux_vertex_buffer_slot(cso), 1,
+ >text.vbuf);
+  cso_set_fragment_shader_handle(hud->cso, hud->fs_text);
+  cso_draw_arrays(cso, PIPE_PRIM_QUADS, 0, hud->text.num_vertices);
+   }
+   pipe_resource_reference(>text.vbuf.buffer.resource, NULL);
+
+   if (hud->simple) {
+  cso_restore_state(cso);
+  cso_restore_constant_buffer_slot0(cso, PIPE_SHADER_VERTEX);
+
+  pipe_surface_reference(, NULL);
+  return;
+   }
+
/* draw accumulated vertices for white lines */
cso_set_blend(cso, >no_blend);
 
hud->constants.color[0] = 1;
hud->constants.color[1] = 1;
hud->constants.color[2] = 1;
hud->constants.color[3] = 1;
hud->constants.translate[0] = 0;
hud->constants.translate[1] = 0;
hud->constants.scale[0] = 1;
@@ -561,31 +598,22 @@ hud_draw_results(struct hud_context *hud, struct 
pipe_resource *tex)
cso_set_constant_buffer(cso, PIPE_SHADER_VERTEX, 0, >constbuf);
 
if (hud->whitelines.num_vertices) {
   cso_set_vertex_buffers(cso, cso_get_aux_vertex_buffer_slot(cso), 1,
  >whitelines.vbuf);
   cso_set_fragment_shader_handle(hud->cso, hud->fs_color);
   cso_draw_arrays(cso, PIPE_PRIM_LINES, 0, hud->whitelines.num_vertices);
}
pipe_resource_reference(>whitelines.vbuf.buffer.resource, NULL);
 
-   /* draw accumulated vertices for text */
-   cso_set_blend(cso, >alpha_blend);
-   if (hud->text.num_vertices) {
-  cso_set_vertex_buffers(cso, cso_get_aux_vertex_buffer_slot(cso), 1,
- >text.vbuf);
-  cso_set_fragment_shader_handle(hud->cso, hud->fs_text);
-  cso_draw_arrays(cso, PIPE_PRIM_QUADS, 0, hud->text.num_vertices);
-   }
-   pipe_resource_reference(>text.vbuf.buffer.resource, NULL);
-
/* draw the rest */
+   cso_set_blend(cso, >alpha_blend);
cso_set_rasterizer(cso, >rasterizer_aa_lines);
LIST_FOR_EACH_ENTRY(pane, >pane_list, head) {
   if (pane)
  hud_pane_draw_colored_objects(hud, pane);
}
 
cso_restore_state(cso);
cso_restore_constant_buffer_slot0(cso, PIPE_SHADER_VERTEX);
 
pipe_surface_reference(, NULL);
@@ -671,21 +699,24 @@ hud_stop_queries(struct hud_context *hud, struct 
pipe_context *pipe)
  * per frame. It will eventually reach an equilibrium.
  */
 if (gr->current_value <
 LIST_ENTRY(struct hud_graph, next, head)->current_value) {
LIST_DEL(>head);

Re: [Mesa-dev] [PATCH 1/2] gallium/pp: use user constant buffers

[Timothy Arceri]

On 05/04/18 06:11, Marek Olšák wrote:

From: Marek Olšák 

This fixes a radeonsi crash. 


The constant buffer didn't follow the PIPE_CAP_CONSTBUF0_FLAGS rule.

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

---
  src/gallium/auxiliary/cso_cache/cso_context.c  | 17 
  src/gallium/auxiliary/cso_cache/cso_context.h  |  3 +++
  src/gallium/auxiliary/postprocess/pp_mlaa.c| 37 --
  src/gallium/auxiliary/postprocess/pp_private.h |  1 -
  4 files changed, 25 insertions(+), 33 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 3fa57f16ff4..3a3a63a3327 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -1540,20 +1540,37 @@ cso_set_constant_buffer_resource(struct cso_context 
*cso,
cb.buffer = buffer;
cb.buffer_offset = 0;
cb.buffer_size = buffer->width0;
cb.user_buffer = NULL;
cso_set_constant_buffer(cso, shader_stage, index, );
 } else {
cso_set_constant_buffer(cso, shader_stage, index, NULL);
 }
  }
  
+void

+cso_set_constant_user_buffer(struct cso_context *cso,
+ enum pipe_shader_type shader_stage,
+ unsigned index, void *ptr, unsigned size)
+{
+   if (ptr) {
+  struct pipe_constant_buffer cb;
+  cb.buffer = NULL;
+  cb.buffer_offset = 0;
+  cb.buffer_size = size;
+  cb.user_buffer = ptr;
+  cso_set_constant_buffer(cso, shader_stage, index, );
+   } else {
+  cso_set_constant_buffer(cso, shader_stage, index, NULL);
+   }
+}
+
  void
  cso_save_constant_buffer_slot0(struct cso_context *cso,
 enum pipe_shader_type shader_stage)
  {
 util_copy_constant_buffer(>aux_constbuf_saved[shader_stage],
   >aux_constbuf_current[shader_stage]);
  }
  
  void

  cso_restore_constant_buffer_slot0(struct cso_context *cso,
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h 
b/src/gallium/auxiliary/cso_cache/cso_context.h
index b1bc0813442..3a4e808f0c0 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.h
+++ b/src/gallium/auxiliary/cso_cache/cso_context.h
@@ -207,20 +207,23 @@ cso_set_shader_images(struct cso_context *cso,
  
  /* constant buffers */
  
  void cso_set_constant_buffer(struct cso_context *cso,

   enum pipe_shader_type shader_stage,
   unsigned index, struct pipe_constant_buffer *cb);
  void cso_set_constant_buffer_resource(struct cso_context *cso,
enum pipe_shader_type shader_stage,
unsigned index,
struct pipe_resource *buffer);
+void cso_set_constant_user_buffer(struct cso_context *cso,
+  enum pipe_shader_type shader_stage,
+  unsigned index, void *ptr, unsigned size);
  void cso_save_constant_buffer_slot0(struct cso_context *cso,
  enum pipe_shader_type shader_stage);
  void cso_restore_constant_buffer_slot0(struct cso_context *cso,
 enum pipe_shader_type shader_stage);
  
  
  /* drawing */
  
  void

  cso_draw_vbo(struct cso_context *cso,
diff --git a/src/gallium/auxiliary/postprocess/pp_mlaa.c 
b/src/gallium/auxiliary/postprocess/pp_mlaa.c
index 0edd01f3f5d..610cedbd1b3 100644
--- a/src/gallium/auxiliary/postprocess/pp_mlaa.c
+++ b/src/gallium/auxiliary/postprocess/pp_mlaa.c
@@ -50,76 +50,64 @@
  #include "util/u_inlines.h"
  #include "util/u_memory.h"
  #include "util/u_string.h"
  #include "pipe/p_screen.h"
  
  #define IMM_SPACE 80
  
  static float constants[] = { 1, 1, 0, 0 };

  static unsigned int dimensions[2] = { 0, 0 };
  
-/** Upload the constants. */

-static void
-up_consts(struct pp_queue_t *ppq)
-{
-   struct pipe_context *pipe = ppq->p->pipe;
-
-   pipe->buffer_subdata(pipe, ppq->constbuf, PIPE_TRANSFER_WRITE,
-0, sizeof(constants), constants);
-}
-
  /** Run function of the MLAA filter. */
  static void
  pp_jimenezmlaa_run(struct pp_queue_t *ppq, struct pipe_resource *in,
 struct pipe_resource *out, unsigned int n, bool iscolor)
  {
  
 struct pp_program *p = ppq->p;
  
 struct pipe_depth_stencil_alpha_state mstencil;

 struct pipe_sampler_view v_tmp, *arr[3];
  
 unsigned int w = 0;

 unsigned int h = 0;
  
 const struct pipe_stencil_ref ref = { {1} };
  
 /* Insufficient initialization checks. */

 assert(p);
 assert(ppq);
-   assert(ppq->constbuf);
 assert(ppq->areamaptex);
 assert(ppq->inner_tmp);
 assert(ppq->shaders[n]);
  
 w = p->framebuffer.width;

 h = p->framebuffer.height;
  
 memset(, 0, sizeof(mstencil));
  
 

Re: [Mesa-dev] [PATCH 2/2] gallium/pp: fix MLAA shaders

[Timothy Arceri]

On 05/04/18 06:11, Marek Olšák wrote:

From: Marek Olšák 



Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99549
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] i965: init image's planar_format in intel_create_image_from_texture

[James Xiong]

From: "Xiong, James" 

When creating a image from a texture, initialize the image's planar_format
with the texture's.

Signed-off-by: Xiong, James 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index dcb98da..7df8bc4 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -578,6 +578,7 @@ intel_create_image_from_texture(__DRIcontext *context, int 
target,
intel_setup_image_from_mipmap_tree(brw, image, iobj->mt, level, zoffset);
image->dri_format = driGLFormatToImageFormat(image->format);
image->has_depthstencil = iobj->mt->stencil_mt? true : false;
+   image->planar_format = iobj->planar_format;
if (image->dri_format == MESA_FORMAT_NONE) {
   *error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
   free(image);
-- 
2.7.4

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

[Mesa-dev] [PATCH 0/2] wrong fourcc was returned for imported images

[James Xiong]

From: "Xiong, James" 

The importer creates an image out of the imported FOURCC_NV12 texture,
the image's dri_format is set to R8(same as the first plane's format),
when it queries the image's fourcc, mesa goes through intel_image_format
table and returns FOURCC_R8.

The solution is to 1) set the image's planar_format using the texture's in
function intel_create_image_from_texture(). 2) when queried, return the
saved fourcc@planar_format

Xiong, James (2):
  i965: init image's planar_format in intel_create_image_from_texture
  i965: return the fourcc saved in __DRIimage

 src/mesa/drivers/dri/i965/intel_screen.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

-- 
2.7.4

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

[Mesa-dev] [PATCH 2/2] i965: return the fourcc saved in __DRIimage

[James Xiong]

From: "Xiong, James" 

The planar_format in __DRIimage contains the original fourcc
used to create the image, if it's set, return the saved fourcc
directly; Otherwise fall back to the old way.

Also we should validate the input parameter "value" first as it
might be NULL based on the SPEC.

v2: fall back to intel_lookup_fourcc() when planar_format is NULL
  (by Dongwon & Matt Roper)

Signed-off-by: Xiong, James 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 7df8bc4..aeecef3 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -388,10 +388,16 @@ intel_image_format_lookup(int fourcc)
return NULL;
 }
 
-static boolean intel_lookup_fourcc(int dri_format, int *fourcc)
+static boolean
+intel_image_get_fourcc(__DRIimage *image, int *fourcc)
 {
+   if (image->planar_format) {
+  *fourcc = image->planar_format->fourcc;
+  return true;
+   }
+
for (unsigned i = 0; i < ARRAY_SIZE(intel_image_formats); i++) {
-  if (intel_image_formats[i].planes[0].dri_format == dri_format) {
+  if (intel_image_formats[i].planes[0].dri_format == image->dri_format) {
  *fourcc = intel_image_formats[i].fourcc;
  return true;
   }
@@ -844,6 +850,9 @@ intel_create_image_with_modifiers(__DRIscreen *dri_screen,
 static GLboolean
 intel_query_image(__DRIimage *image, int attrib, int *value)
 {
+   if (value == NULL)
+  return false;
+
switch (attrib) {
case __DRI_IMAGE_ATTRIB_STRIDE:
   *value = image->pitch;
@@ -870,7 +879,7 @@ intel_query_image(__DRIimage *image, int attrib, int *value)
case __DRI_IMAGE_ATTRIB_FD:
   return !brw_bo_gem_export_to_prime(image->bo, value);
case __DRI_IMAGE_ATTRIB_FOURCC:
-  return intel_lookup_fourcc(image->dri_format, value);
+  return intel_image_get_fourcc(image, value);
case __DRI_IMAGE_ATTRIB_NUM_PLANES:
   if (isl_drm_modifier_has_aux(image->modifier)) {
  assert(!image->planar_format || image->planar_format->nplanes == 1);
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH v3 010/104] prog/nir: Simplify some load/store operations

[Eric Anholt]

Jason Ekstrand  writes:

> ---

This one is:

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] [PATCH] nir: rename variables in nir_lower_io_to_temporaries for clarity

[Caio Marcelo de Oliveira Filho]

In the emit_copies() function, the use of "newv" and "temp" names made
sense when only copies from temporaries to the new variables were
being done. But now there are other calls to copy with other pairings,
and "temp" doesn't always refer to a temporary created in this
pass. Use the names "dest" and "src" instead.
---
 .../nir/nir_lower_io_to_temporaries.c | 22 +--
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/compiler/nir/nir_lower_io_to_temporaries.c 
b/src/compiler/nir/nir_lower_io_to_temporaries.c
index 301ba65892..c3e1207f4e 100644
--- a/src/compiler/nir/nir_lower_io_to_temporaries.c
+++ b/src/compiler/nir/nir_lower_io_to_temporaries.c
@@ -40,34 +40,34 @@ struct lower_io_state {
 };
 
 static void
-emit_copies(nir_cursor cursor, nir_shader *shader, struct exec_list *new_vars,
-  struct exec_list *old_vars)
+emit_copies(nir_cursor cursor, nir_shader *shader, struct exec_list *dest_vars,
+struct exec_list *src_vars)
 {
-   assert(exec_list_length(new_vars) == exec_list_length(old_vars));
+   assert(exec_list_length(dest_vars) == exec_list_length(src_vars));
 
-   foreach_two_lists(new_node, new_vars, old_node, old_vars) {
-  nir_variable *newv = exec_node_data(nir_variable, new_node, node);
-  nir_variable *temp = exec_node_data(nir_variable, old_node, node);
+   foreach_two_lists(new_node, dest_vars, old_node, src_vars) {
+  nir_variable *dest = exec_node_data(nir_variable, new_node, node);
+  nir_variable *src = exec_node_data(nir_variable, old_node, node);
 
   /* No need to copy the contents of a non-fb_fetch_output output variable
* to the temporary allocated for it, since its initial value is
* undefined.
*/
-  if (temp->data.mode == nir_var_shader_out &&
-  !temp->data.fb_fetch_output)
+  if (src->data.mode == nir_var_shader_out &&
+  !src->data.fb_fetch_output)
  continue;
 
   /* Can't copy the contents of the temporary back to a read-only
* interface variable.  The value of the temporary won't have been
* modified by the shader anyway.
*/
-  if (newv->data.read_only)
+  if (dest->data.read_only)
  continue;
 
   nir_intrinsic_instr *copy =
  nir_intrinsic_instr_create(shader, nir_intrinsic_copy_var);
-  copy->variables[0] = nir_deref_var_create(copy, newv);
-  copy->variables[1] = nir_deref_var_create(copy, temp);
+  copy->variables[0] = nir_deref_var_create(copy, dest);
+  copy->variables[1] = nir_deref_var_create(copy, src);
 
   nir_instr_insert(cursor, >instr);
}
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH 1/2] gallium/pp: use user constant buffers

[Marek Olšák]

On Wed, Apr 4, 2018 at 5:41 PM, Ilia Mirkin  wrote:

> While I don't see anything obviously wrong in this patch, I also don't
> see any issues in the old code. What API misuse is this dealing with?
>

The constant buffer didn't follow the PIPE_CAP_CONSTBUF0_FLAGS rule.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Mark Janes]

Leo Liu  writes:

> On 04/04/2018 12:40 PM, Mark Janes wrote:
>> Leo Liu  writes:
>>
>>> On the CI family, firmware requires the destory command have to be the
>>> last command in the IB, moving feedback command after destroy is causing
>>> issues on CI cards, so we have to keep the previous logic that moves
>>> destroy back to the last command.
>>>
>>> But as the original issue fixed previously, with the newer family like 
>>> Vega10,
>>> feedback command have to be included inside of the task info command along
>>> with destroy command.
>>>
>>> Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
>>>
>>> Signed-off-by: Leo Liu 
>>> Cc: mesa-sta...@lists.freedesktop.org
>> These tags seem ambiguous to me.  If this commit fixes a specific
>> commit, then the patch should be applied only to stable branches which
>> contain that commit.
>>
>> However, the mesa-stable CC caused this patch to be applied to 17.3,
>> which does *not* contain the broken patch.
>>
>> Leo: did you intend for the mesa-stable CC to cause this patch to be
>> applied to older stable branches?
> I would like to have this patch apply to branches "17.2", "17.3", 
> "18.0", which got patch titled "radeon/vce: move destroy command before 
> feedback command"

Ok, I understand now.  You cc'd a buggy patch to stable, and the bug was
shipped in 17.3.1.

> And this Cc-ed patch is to fix "radeon/vce: move destroy command before 
> feedback command"
>
> Thanks,
> Leo
>
>
>>
>> Release managers: is there a protocol for how this specification should
>> be parsed, when considering a patch for stable?
>>
>>> ---
>>>   src/gallium/drivers/radeon/radeon_vce.c|  1 -
>>>   src/gallium/drivers/radeon/radeon_vce_40_2_2.c |  2 ++
>>>   src/gallium/drivers/radeon/radeon_vce_52.c | 18 ++
>>>   3 files changed, 12 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
>>> b/src/gallium/drivers/radeon/radeon_vce.c
>>> index 427bf01ed8..c84103e0ac 100644
>>> --- a/src/gallium/drivers/radeon/radeon_vce.c
>>> +++ b/src/gallium/drivers/radeon/radeon_vce.c
>>> @@ -247,7 +247,6 @@ static void rvce_destroy(struct pipe_video_codec 
>>> *encoder)
>>> enc->fb = 
>>> enc->session(enc);
>>> enc->destroy(enc);
>>> -   enc->feedback(enc);
>>> flush(enc);
>>> si_vid_destroy_buffer();
>>> }
>>> diff --git a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c 
>>> b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
>>> index f1db47d4bd..04e9d7f5e1 100644
>>> --- a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
>>> +++ b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
>>> @@ -421,6 +421,8 @@ static void destroy(struct rvce_encoder *enc)
>>>   {
>>> enc->task_info(enc, 0x0001, 0, 0, 0);
>>>   
>>> +   feedback(enc);
>>> +
>>> RVCE_BEGIN(0x0201); // destroy
>>> RVCE_END();
>>>   }
>>> diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
>>> b/src/gallium/drivers/radeon/radeon_vce_52.c
>>> index a941c476f6..421539c4bd 100644
>>> --- a/src/gallium/drivers/radeon/radeon_vce_52.c
>>> +++ b/src/gallium/drivers/radeon/radeon_vce_52.c
>>> @@ -458,14 +458,6 @@ static void config_extension(struct rvce_encoder *enc)
>>> RVCE_END();
>>>   }
>>>   
>>> -static void destroy(struct rvce_encoder *enc)
>>> -{
>>> -   enc->task_info(enc, 0x0001, 0, 0, 0);
>>> -
>>> -   RVCE_BEGIN(0x0201); // destroy
>>> -   RVCE_END();
>>> -}
>>> -
>>>   static void feedback(struct rvce_encoder *enc)
>>>   {
>>> RVCE_BEGIN(0x0505); // feedback buffer
>>> @@ -474,6 +466,16 @@ static void feedback(struct rvce_encoder *enc)
>>> RVCE_END();
>>>   }
>>>   
>>> +static void destroy(struct rvce_encoder *enc)
>>> +{
>>> +   enc->task_info(enc, 0x0001, 0, 0, 0);
>>> +
>>> +   feedback(enc);
>>> +
>>> +   RVCE_BEGIN(0x0201); // destroy
>>> +   RVCE_END();
>>> +}
>>> +
>>>   static void motion_estimation(struct rvce_encoder *enc)
>>>   {
>>> RVCE_BEGIN(0x0407); // motion estimation
>>> -- 
>>> 2.14.1
>>>
>>> ___
>>> mesa-stable mailing list
>>> mesa-sta...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] gallium/pp: use user constant buffers

[Ilia Mirkin]

While I don't see anything obviously wrong in this patch, I also don't
see any issues in the old code. What API misuse is this dealing with?

On Wed, Apr 4, 2018 at 4:11 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> This fixes a radeonsi crash.
> ---
>  src/gallium/auxiliary/cso_cache/cso_context.c  | 17 
>  src/gallium/auxiliary/cso_cache/cso_context.h  |  3 +++
>  src/gallium/auxiliary/postprocess/pp_mlaa.c| 37 
> --
>  src/gallium/auxiliary/postprocess/pp_private.h |  1 -
>  4 files changed, 25 insertions(+), 33 deletions(-)
>
> diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
> b/src/gallium/auxiliary/cso_cache/cso_context.c
> index 3fa57f16ff4..3a3a63a3327 100644
> --- a/src/gallium/auxiliary/cso_cache/cso_context.c
> +++ b/src/gallium/auxiliary/cso_cache/cso_context.c
> @@ -1540,20 +1540,37 @@ cso_set_constant_buffer_resource(struct cso_context 
> *cso,
>cb.buffer = buffer;
>cb.buffer_offset = 0;
>cb.buffer_size = buffer->width0;
>cb.user_buffer = NULL;
>cso_set_constant_buffer(cso, shader_stage, index, );
> } else {
>cso_set_constant_buffer(cso, shader_stage, index, NULL);
> }
>  }
>
> +void
> +cso_set_constant_user_buffer(struct cso_context *cso,
> + enum pipe_shader_type shader_stage,
> + unsigned index, void *ptr, unsigned size)
> +{
> +   if (ptr) {
> +  struct pipe_constant_buffer cb;
> +  cb.buffer = NULL;
> +  cb.buffer_offset = 0;
> +  cb.buffer_size = size;
> +  cb.user_buffer = ptr;
> +  cso_set_constant_buffer(cso, shader_stage, index, );
> +   } else {
> +  cso_set_constant_buffer(cso, shader_stage, index, NULL);
> +   }
> +}
> +
>  void
>  cso_save_constant_buffer_slot0(struct cso_context *cso,
> enum pipe_shader_type shader_stage)
>  {
> util_copy_constant_buffer(>aux_constbuf_saved[shader_stage],
>   >aux_constbuf_current[shader_stage]);
>  }
>
>  void
>  cso_restore_constant_buffer_slot0(struct cso_context *cso,
> diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h 
> b/src/gallium/auxiliary/cso_cache/cso_context.h
> index b1bc0813442..3a4e808f0c0 100644
> --- a/src/gallium/auxiliary/cso_cache/cso_context.h
> +++ b/src/gallium/auxiliary/cso_cache/cso_context.h
> @@ -207,20 +207,23 @@ cso_set_shader_images(struct cso_context *cso,
>
>  /* constant buffers */
>
>  void cso_set_constant_buffer(struct cso_context *cso,
>   enum pipe_shader_type shader_stage,
>   unsigned index, struct pipe_constant_buffer 
> *cb);
>  void cso_set_constant_buffer_resource(struct cso_context *cso,
>enum pipe_shader_type shader_stage,
>unsigned index,
>struct pipe_resource *buffer);
> +void cso_set_constant_user_buffer(struct cso_context *cso,
> +  enum pipe_shader_type shader_stage,
> +  unsigned index, void *ptr, unsigned size);
>  void cso_save_constant_buffer_slot0(struct cso_context *cso,
>  enum pipe_shader_type shader_stage);
>  void cso_restore_constant_buffer_slot0(struct cso_context *cso,
> enum pipe_shader_type shader_stage);
>
>
>  /* drawing */
>
>  void
>  cso_draw_vbo(struct cso_context *cso,
> diff --git a/src/gallium/auxiliary/postprocess/pp_mlaa.c 
> b/src/gallium/auxiliary/postprocess/pp_mlaa.c
> index 0edd01f3f5d..610cedbd1b3 100644
> --- a/src/gallium/auxiliary/postprocess/pp_mlaa.c
> +++ b/src/gallium/auxiliary/postprocess/pp_mlaa.c
> @@ -50,76 +50,64 @@
>  #include "util/u_inlines.h"
>  #include "util/u_memory.h"
>  #include "util/u_string.h"
>  #include "pipe/p_screen.h"
>
>  #define IMM_SPACE 80
>
>  static float constants[] = { 1, 1, 0, 0 };
>  static unsigned int dimensions[2] = { 0, 0 };
>
> -/** Upload the constants. */
> -static void
> -up_consts(struct pp_queue_t *ppq)
> -{
> -   struct pipe_context *pipe = ppq->p->pipe;
> -
> -   pipe->buffer_subdata(pipe, ppq->constbuf, PIPE_TRANSFER_WRITE,
> -0, sizeof(constants), constants);
> -}
> -
>  /** Run function of the MLAA filter. */
>  static void
>  pp_jimenezmlaa_run(struct pp_queue_t *ppq, struct pipe_resource *in,
> struct pipe_resource *out, unsigned int n, bool iscolor)
>  {
>
> struct pp_program *p = ppq->p;
>
> struct pipe_depth_stencil_alpha_state mstencil;
> struct pipe_sampler_view v_tmp, *arr[3];
>
> unsigned int w = 0;
> unsigned int h = 0;
>
> const struct pipe_stencil_ref ref = { {1} };
>
> /* Insufficient initialization checks. */
> assert(p);
> assert(ppq);
> -   assert(ppq->constbuf);
> assert(ppq->areamaptex);
> 

Re: [Mesa-dev] [PATCH 2/2] gallium/pp: fix MLAA shaders

[Ilia Mirkin]

This patch is

Reviewed-by: Ilia Mirkin 

On Wed, Apr 4, 2018 at 4:11 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> ---
>  src/gallium/auxiliary/postprocess/pp_mlaa.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/auxiliary/postprocess/pp_mlaa.h 
> b/src/gallium/auxiliary/postprocess/pp_mlaa.h
> index 85c14a786a3..3507f813781 100644
> --- a/src/gallium/auxiliary/postprocess/pp_mlaa.h
> +++ b/src/gallium/auxiliary/postprocess/pp_mlaa.h
> @@ -56,21 +56,21 @@ static const char depth1fs[] = "FRAG\n"
> "  0: TEX TEMP[0].x, IN[1].xyyy, SAMP[0], 2D\n"
> "  1: MOV TEMP[1].x, TEMP[0].\n"
> "  2: TEX TEMP[0].x, IN[1].zwww, SAMP[0], 2D\n"
> "  3: MOV TEMP[1].y, TEMP[0].\n"
> "  4: TEX TEMP[0].x, IN[2].xyyy, SAMP[0], 2D\n"
> "  5: MOV TEMP[1].z, TEMP[0].\n"
> "  6: TEX TEMP[0].x, IN[2].zwww, SAMP[0], 2D\n"
> "  7: MOV TEMP[1].w, TEMP[0].\n"
> "  8: TEX TEMP[0].x, IN[0].xyyy, SAMP[0], 2D\n"
> "  9: ADD TEMP[2], TEMP[0]., -TEMP[1]\n"
> -   " 10: ABS TEMP[0], TEMP[2]\n"
> +   " 10: MOV TEMP[0], |TEMP[2]|\n"
> " 11: SGE TEMP[2], TEMP[0], IMM[0].\n"
> " 12: DP4 TEMP[0].x, TEMP[2], IMM[0].\n"
> " 13: SEQ TEMP[1].x, TEMP[0]., IMM[0].\n"
> " 14: IF TEMP[1]. :16\n"
> " 15:   KILL\n"
> " 16: ENDIF\n"
> " 17: MOV OUT[0], TEMP[2]\n"
> " 18: END\n";
>
>
> @@ -89,21 +89,21 @@ static const char color1fs[] = "FRAG\n"
> "  1: DP3 TEMP[0].x, TEMP[1].xyzz, IMM[0]\n"
> "  2: TEX TEMP[1].xyz, IN[1].zwww, SAMP[0], 2D\n"
> "  3: DP3 TEMP[0].y, TEMP[1].xyzz, IMM[0].xyzz\n"
> "  4: TEX TEMP[1].xyz, IN[2].xyyy, SAMP[0], 2D\n"
> "  5: DP3 TEMP[0].z, TEMP[1].xyzz, IMM[0].xyzz\n"
> "  6: TEX TEMP[1].xyz, IN[2].zwww, SAMP[0], 2D\n"
> "  7: DP3 TEMP[0].w, TEMP[1].xyzz, IMM[0].xyzz\n"
> "  8: TEX TEMP[1].xyz, IN[0].xyyy, SAMP[0], 2D\n"
> "  9: DP3 TEMP[2].x, TEMP[1].xyzz, IMM[0].xyzz\n"
> " 10: ADD TEMP[1], TEMP[2]., -TEMP[0]\n"
> -   " 11: ABS TEMP[0], TEMP[1]\n"
> +   " 11: MOV TEMP[0], |TEMP[1]|\n"
> " 12: SGE TEMP[2], TEMP[0], IMM[0].\n"
> " 13: DP4 TEMP[0].x, TEMP[2], IMM[1].\n"
> " 14: SEQ TEMP[1].x, TEMP[0]., IMM[1].\n"
> " 15: IF TEMP[1]. :17\n"
> " 16:   KILL\n"
> " 17: ENDIF\n"
> " 18: MOV OUT[0], TEMP[2]\n"
> " 19: END\n";
>
>
> @@ -254,21 +254,21 @@ static const char blend2fs_2[] =
> " 61:   MOV TEMP[4], TEMP[1].xyyy\n"
> " 62:   MOV TEMP[4].w, IMM[0].\n"
> " 63:   TXL TEMP[5].x, TEMP[4], SAMP[2], 2D\n"
> " 64:   MOV TEMP[4].x, TEMP[5].\n"
> " 65:   MOV TEMP[5], TEMP[1].zwww\n"
> " 66:   MOV TEMP[5].w, IMM[0].\n"
> " 67:   TXL TEMP[1].x, TEMP[5], SAMP[2], 2D\n"
> " 68:   MOV TEMP[4].y, TEMP[1].\n"
> " 69:   MUL TEMP[5].xy, IMM[2]., TEMP[4].xyyy\n"
> " 70:   ROUND TEMP[1].xy, TEMP[5].xyyy\n"
> -   " 71:   ABS TEMP[4].xy, TEMP[3].xyyy\n"
> +   " 71:   MOV TEMP[4].xy, |TEMP[3].xyyy|\n"
> " 72:   MAD TEMP[3].xy, IMM[2]., TEMP[1].xyyy, TEMP[4].xyyy\n"
> " 73:   MUL TEMP[5].xyz, TEMP[3].xyyy, IMM[0].\n"
> " 74:   MOV TEMP[5].w, IMM[0].\n"
> " 75:   TXL TEMP[0].xy, TEMP[5], SAMP[0], 2D\n"
> " 76: ENDIF\n"
> " 77: SNE TEMP[1].x, TEMP[2]., IMM[0].\n"
> " 78: IF TEMP[1]. :151\n"
> " 79:   MOV TEMP[1].xy, IN[0].xyxx\n"
> " 80:   MOV TEMP[3].x, IMM[1].\n"
> " 81:   BGNLOOP :98\n"
> @@ -328,21 +328,21 @@ static const char blend2fs_2[] =
> "135:   MOV TEMP[3], TEMP[1].xyyy\n"
> "136:   MOV TEMP[3].w, IMM[0].\n"
> "137:   TXL TEMP[4].y, TEMP[3], SAMP[2], 2D\n"
> "138:   MOV TEMP[3].x, TEMP[4].\n"
> "139:   MOV TEMP[4], TEMP[1].zwww\n"
> "140:   MOV TEMP[4].w, IMM[0].\n"
> "141:   TXL TEMP[1].y, TEMP[4], SAMP[2], 2D\n"
> "142:   MOV TEMP[3].y, TEMP[1].\n"
> "143:   MUL TEMP[4].xy, IMM[2]., TEMP[3].xyyy\n"
> "144:   ROUND TEMP[1].xy, TEMP[4].xyyy\n"
> -   "145:   ABS TEMP[3].xy, TEMP[2].xyyy\n"
> +   "145:   MOV TEMP[3].xy, |TEMP[2].xyyy|\n"
> "146:   MAD TEMP[2].xy, IMM[2]., TEMP[1].xyyy, TEMP[3].xyyy\n"
> "147:   MUL TEMP[3].xyz, TEMP[2].xyyy, IMM[0].\n"
> "148:   MOV TEMP[3].w, IMM[0].\n"
> "149:   TXL TEMP[1].xy, TEMP[3], SAMP[0], 2D\n"
> "150:   MOV TEMP[0].zw, TEMP[1].yyxy\n"
> "151: ENDIF\n"
> "152: MOV OUT[0], TEMP[0]\n"
> "153: END\n";
>
>  #endif
> --
> 2.15.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 013/104] nir: Support deref instructions in remove_dead_variables

[Jason Ekstrand]

On Wed, Apr 4, 2018 at 1:53 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:

> Hi,
>
> > @@ -144,6 +197,45 @@ remove_dead_var_writes(nir_shader *shader, struct
> set *live)
> > nir_instr_remove(instr);
> >   }
> >}
> > +
> > +  /* We walk the list of instructions backwards because we're going
> to
> > +   * delete a deref and all of it's uses and we don't want to end up
> > +   * deleting stuff ahead of us.
> > +   */
> > +  nir_foreach_block(block, function->impl) {
> > + nir_foreach_instr_safe(instr, block) {
>
> The comment says backwards, the loop walks forwards.
>
> It seems to me propagating the mode needs to be forward, e.g. a deref
> will be marked mode = 0 because of a variable, then another deref that
> has the first as parent marked mode = 0. But I might be missing
> something.
>

Nope.  Just rebase fail on my part.  I'll drop the comment.


> > +switch (instr->type) {
> > +case nir_instr_type_deref: {
> > +   /* For deref instructions, propagate modes */
> > +   nir_deref_instr *deref = nir_instr_as_deref(instr);
> > +   if (deref->deref_type == nir_deref_type_var) {
> > +  deref->mode = deref->var->data.mode;
> > +   } else {
> > +  nir_deref_instr *parent =
> nir_deref_instr_parent(deref);
> > +  deref->mode = parent->mode;
> > +   }
>
> Should we write deref->mode only if the new mode is zero?
> I.e. deref->var->data.mode == 0 for the first case, and parent->mode
> == 0 for the else case.
>

In this case, the mode will either match or deref->var->data.mode will be
0.  I'm happy to add an if just to ensure we don't do anything we dind't
intend to.

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

[Mesa-dev] [PATCH v2 08/11] i965: Add and use a getter for depth miptree clear values

[Nanley Chery]

Balance the miptree API by having a getter for depth clear values.
---
 src/mesa/drivers/dri/i965/brw_misc_state.c| 15 ---
 src/mesa/drivers/dri/i965/gen6_depth_state.c  |  4 ++--
 src/mesa/drivers/dri/i965/gen7_misc_state.c   |  3 +--
 src/mesa/drivers/dri/i965/gen8_depth_state.c  |  3 ++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 19 +++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  5 +
 6 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 05517ebf587..27608d1d472 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -343,21 +343,6 @@ brw_emit_depthbuffer(struct brw_context *brw)
 width, height, tile_x, tile_y);
 }
 
-uint32_t
-brw_convert_depth_value(mesa_format format, float value)
-{
-   switch (format) {
-   case MESA_FORMAT_Z_FLOAT32:
-  return float_as_int(value);
-   case MESA_FORMAT_Z_UNORM16:
-  return value * ((1u << 16) - 1);
-   case MESA_FORMAT_Z24_UNORM_X8_UINT:
-  return value * ((1u << 24) - 1);
-   default:
-  unreachable("Invalid depth format");
-   }
-}
-
 void
 brw_emit_depth_stencil_hiz(struct brw_context *brw,
struct intel_mipmap_tree *depth_mt,
diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c 
b/src/mesa/drivers/dri/i965/gen6_depth_state.c
index 3a66b42fec1..3332a765dc1 100644
--- a/src/mesa/drivers/dri/i965/gen6_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
@@ -212,8 +212,8 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
  GEN5_DEPTH_CLEAR_VALID |
  (2 - 2));
if (depth_mt) {
-  OUT_BATCH(brw_convert_depth_value(depth_mt->format,
-depth_mt->fast_clear_color.f32[0]));
+  const struct gen_device_info *devinfo = >screen->devinfo;
+  OUT_BATCH(intel_miptree_get_depth_clear_value(devinfo, depth_mt));
} else {
   OUT_BATCH(0);
}
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c 
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 58f0a1bdbfd..7091ecf02a5 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -176,8 +176,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
BEGIN_BATCH(3);
OUT_BATCH(GEN7_3DSTATE_CLEAR_PARAMS << 16 | (3 - 2));
if (depth_mt) {
-  OUT_BATCH(brw_convert_depth_value(depth_mt->format,
-depth_mt->fast_clear_color.f32[0]));
+  OUT_BATCH(intel_miptree_get_depth_clear_value(devinfo, depth_mt));
} else {
   OUT_BATCH(0);
}
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c 
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index 27705d35df9..5679bced9ff 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -120,7 +120,8 @@ emit_depth_packets(struct brw_context *brw,
 
BEGIN_BATCH(3);
OUT_BATCH(GEN7_3DSTATE_CLEAR_PARAMS << 16 | (3 - 2));
-   OUT_BATCH(depth_mt ? depth_mt->fast_clear_color.u32[0] : 0);
+   OUT_BATCH(depth_mt ?
+ intel_miptree_get_depth_clear_value(devinfo, depth_mt) : 0);
OUT_BATCH(1);
ADVANCE_BATCH();
 
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 87c730452b5..dec2e614938 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3825,3 +3825,22 @@ intel_miptree_get_clear_color(const struct 
gen_device_info *devinfo,
   return mt->fast_clear_color;
}
 }
+
+uint32_t
+intel_miptree_get_depth_clear_value(const struct gen_device_info *devinfo,
+const struct intel_mipmap_tree *mt)
+{
+   if (devinfo->gen >= 8)
+  return mt->fast_clear_color.u32[0];
+
+   switch (mt->format) {
+   case MESA_FORMAT_Z_FLOAT32:
+  return mt->fast_clear_color.u32[0];
+   case MESA_FORMAT_Z_UNORM16:
+  return mt->fast_clear_color.f32[0] * ((1u << 16) - 1);
+   case MESA_FORMAT_Z24_UNORM_X8_UINT:
+  return mt->fast_clear_color.f32[0] * ((1u << 24) - 1);
+   default:
+  unreachable("Invalid depth format");
+   }
+}
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index e66a2a8d384..edf9a619218 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -732,6 +732,11 @@ intel_miptree_set_depth_clear_value(struct brw_context 
*brw,
 struct intel_mipmap_tree *mt,
 float clear_value);
 
+/* Get a clear value suitable for filling out an ISL depth state. */
+uint32_t
+intel_miptree_get_depth_clear_value(const struct gen_device_info *devinfo,
+const 

[Mesa-dev] [PATCH v2 11/11] i965/blorp: Also skip the fast clear if the clear color differs

[Nanley Chery]

If the aux state is CLEAR and clear color value has changed, only the
surface state must be updated. The bit-pattern in the aux buffer is
exactly the same.

Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index c6fa5195ee3..bf7164688bb 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1239,13 +1239,12 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
   const enum isl_aux_state aux_state =
  intel_miptree_get_aux_state(irb->mt, irb->mt_level, irb->mt_layer);
 
-  bool same_clear_color =
- !intel_miptree_set_clear_color(brw, irb->mt, >Color.ClearColor);
+  intel_miptree_set_clear_color(brw, irb->mt, >Color.ClearColor);
 
-  /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear
+  /* If the buffer is already in ISL_AUX_STATE_CLEAR, the clear
* is redundant and can be skipped.
*/
-  if (aux_state == ISL_AUX_STATE_CLEAR && same_clear_color)
+  if (aux_state == ISL_AUX_STATE_CLEAR)
  return;
 
   DBG("%s (fast) to mt %p level %d layers %d+%d\n", __FUNCTION__,
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 09/11] i965: Add and use a helper for depth miptree clear values

[Nanley Chery]

Add and use a comparison function to remove the last external user of
intel_miptree::fast_color_clear.
---
 src/mesa/drivers/dri/i965/brw_clear.c | 2 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 7 +++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 4 
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 8f7594baf59..653abae2d8f 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -175,7 +175,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
/* If we're clearing to a new clear value, then we need to resolve any clear
 * flags out of the HiZ buffer into the real depth buffer.
 */
-   if (mt->fast_clear_color.f32[0] != clear_value) {
+   if (!intel_miptree_has_depth_clear_value(mt, clear_value)) {
   for (uint32_t level = mt->first_level; level <= mt->last_level; level++) 
{
  if (!intel_miptree_level_has_hiz(mt, level))
 continue;
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index dec2e614938..c2363979564 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3775,6 +3775,13 @@ intel_miptree_get_aux_isl_usage(const struct brw_context 
*brw,
return mt->aux_usage;
 }
 
+bool
+intel_miptree_has_depth_clear_value(const struct intel_mipmap_tree *mt,
+float clear_value)
+{
+   return mt->fast_clear_color.f32[0] == clear_value;
+}
+
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index edf9a619218..1070921837f 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -715,6 +715,10 @@ bool
 intel_miptree_sample_with_hiz(struct brw_context *brw,
   struct intel_mipmap_tree *mt);
 
+bool
+intel_miptree_has_depth_clear_value(const struct intel_mipmap_tree *mt,
+float clear_value);
+
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 10/11] i965/brw_clear: Remove extra for-loop in brw_fast_clear_depth

[Nanley Chery]

Make the algorithm easier to follow.
---
 src/mesa/drivers/dri/i965/brw_clear.c | 31 ---
 1 file changed, 4 insertions(+), 27 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 653abae2d8f..cda47bcabac 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -215,26 +215,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
   intel_miptree_set_depth_clear_value(brw, mt, clear_value);
}
 
-   bool need_clear = false;
-   for (unsigned a = 0; a < num_layers; a++) {
-  enum isl_aux_state aux_state =
- intel_miptree_get_aux_state(mt, depth_irb->mt_level,
- depth_irb->mt_layer + a);
-
-  if (aux_state != ISL_AUX_STATE_CLEAR) {
- need_clear = true;
- break;
-  }
-   }
-
-   if (!need_clear) {
-  /* If all of the layers we intend to clear are already in the clear
-   * state then simply updating the miptree fast clear value is sufficient
-   * to change their clear value.
-   */
-  return true;
-   }
-
+   /* Fast-clear any of the layers that are not already in the clear state. */
for (unsigned a = 0; a < num_layers; a++) {
   enum isl_aux_state aux_state =
  intel_miptree_get_aux_state(mt, depth_irb->mt_level,
@@ -244,16 +225,12 @@ brw_fast_clear_depth(struct gl_context *ctx)
  intel_hiz_exec(brw, mt, depth_irb->mt_level,
 depth_irb->mt_layer + a, 1,
 ISL_AUX_OP_FAST_CLEAR);
+ intel_miptree_set_aux_state(brw, mt, depth_irb->mt_level,
+ depth_irb->mt_layer + a, 1,
+ ISL_AUX_STATE_CLEAR);
   }
}
 
-   /* Now, the HiZ buffer contains data that needs to be resolved to the depth
-* buffer.
-*/
-   intel_miptree_set_aux_state(brw, mt, depth_irb->mt_level,
-   depth_irb->mt_layer, num_layers,
-   ISL_AUX_STATE_CLEAR);
-
return true;
 }
 
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 00/11] Enable sRGB-encoded fast-clears on CNL

[Nanley Chery]

Compared to the v1, this v2 manages to restrict the uses of
intel_miptree::fast_clear_color to the miptree module with less churn.

Notes:
* Patches 8-10 have no reviews.
* Patches 10-11 are optional improvements found by inspection.

Jason Ekstrand (1):
  util/srgb: Add a float sRGB -> linear helper

Nanley Chery (10):
  i965: Use the brw_context for the clear color and value setters
  i965/miptree: Move the clear color and value setter implementations
  i965: Make the miptree clear color setter take a gl_color_union
  i965: Add and use a getter for the clear color
  i965/miptree: Extend the sRGB-blending WA to future platforms
  i965/meta_util: Re-enable sRGB-encoded fast-clears on CNL
  i965: Add and use a getter for depth miptree clear values
  i965: Add and use a helper for depth miptree clear values
  i965/brw_clear: Remove extra for-loop in brw_fast_clear_depth
  i965/blorp: Also skip the fast clear if the clear color differs

 src/mesa/drivers/dri/i965/brw_blorp.c| 14 ++--
 src/mesa/drivers/dri/i965/brw_clear.c| 35 ++
 src/mesa/drivers/dri/i965/brw_meta_util.c| 11 ---
 src/mesa/drivers/dri/i965/brw_misc_state.c   | 15 -
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  4 +-
 src/mesa/drivers/dri/i965/gen6_depth_state.c |  4 +-
 src/mesa/drivers/dri/i965/gen7_misc_state.c  |  3 +-
 src/mesa/drivers/dri/i965/gen8_depth_state.c |  3 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 85 +++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h| 43 ++--
 src/util/format_srgb.h   | 14 
 11 files changed, 138 insertions(+), 93 deletions(-)

-- 
2.16.2

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

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

[Nanley Chery]

From: Jason Ekstrand 

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

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

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

[Mesa-dev] [PATCH v2 05/11] i965: Add and use a getter for the clear color

[Nanley Chery]

Use a getter which allows CNL to sample from sRGB textures correctly.

Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_blorp.c|  4 +++-
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  4 +++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 25 
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  7 +++
 4 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 6ab5267ddea..c6fa5195ee3 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -172,7 +172,9 @@ blorp_surf_for_miptree(struct brw_context *brw,
   /* We only really need a clear color if we also have an auxiliary
* surface.  Without one, it does nothing.
*/
-  surf->clear_color = mt->fast_clear_color;
+  surf->clear_color =
+ intel_miptree_get_clear_color(devinfo, mt, mt->surf.format,
+   !is_render_target);
 
   surf->aux_surf = aux_surf;
   surf->aux_addr = (struct blorp_address) {
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 caa92d7d878..2c9e986b184 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -178,7 +178,9 @@ brw_emit_surface_state(struct brw_context *brw,
   /* We only really need a clear color if we also have an auxiliary
* surface.  Without one, it does nothing.
*/
-  clear_color = mt->fast_clear_color;
+  clear_color =
+ intel_miptree_get_clear_color(devinfo, mt, view.format,
+   view.usage & 
ISL_SURF_USAGE_TEXTURE_BIT);
}
 
void *state = brw_state_batch(brw,
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 7aa0e7920d3..c21c4d8bae1 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -46,6 +46,9 @@
 #include "main/texcompress_etc.h"
 #include "main/teximage.h"
 #include "main/streaming-load-memcpy.h"
+
+#include "util/format_srgb.h"
+
 #include "x86/common_x86_asm.h"
 
 #define FILE_DEBUG_FLAG DEBUG_MIPTREE
@@ -3800,3 +3803,25 @@ intel_miptree_set_depth_clear_value(struct brw_context 
*brw,
}
return false;
 }
+
+union isl_color_value
+intel_miptree_get_clear_color(const struct gen_device_info *devinfo,
+  const struct intel_mipmap_tree *mt,
+  enum isl_format view_format,
+  bool sampling)
+{
+   /* Prior to gen10, the clear color can be used unchanged. From gen10
+* onwards, HW no longer gamma-corrects the clear color for sampling
+* operations.
+*/
+   if (devinfo->gen >= 10 && isl_format_is_srgb(view_format) && sampling) {
+  union isl_color_value linear_color = mt->fast_clear_color;
+  for (unsigned i = 0; i < 3; i++) {
+ linear_color.f32[i] =
+util_format_srgb_to_linear_float(mt->fast_clear_color.f32[i]);
+  }
+  return linear_color;
+   } else {
+  return mt->fast_clear_color;
+   }
+}
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 961f8fe812e..e66a2a8d384 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -720,6 +720,13 @@ intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
   const union gl_color_union *color);
 
+/* Get a clear color suitable for filling out an ISL surface state. */
+union isl_color_value
+intel_miptree_get_clear_color(const struct gen_device_info *devinfo,
+  const struct intel_mipmap_tree *mt,
+  enum isl_format view_format,
+  bool sampling);
+
 bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 07/11] i965/meta_util: Re-enable sRGB-encoded fast-clears on CNL

[Nanley Chery]

The paths which sample with the clear color are now using a getter which
performs the sRGB decode needed to enable this fast clear.

This path can be exercised by fast-clearing a texture, then performing
an operation which requires sRGB decoding. Test coverage for this
feature is provided with the following tests:

* Shader texture calls:
  - spec@ext_texture_srgb@tex-srgb

* Shader texelfetch calls:
  - spec@arb_framebuffer_srgb@fbo-fast-clear
  - spec@arb_framebuffer_srgb@msaa-fast-clear

* Blending:
  - spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend

* Blitting:
  - spec@arb_framebuffer_srgb@blit texture srgb msaa enabled clear

Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_meta_util.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c 
b/src/mesa/drivers/dri/i965/brw_meta_util.c
index b31181521c7..d292f5a8e24 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_util.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
@@ -293,18 +293,7 @@ brw_is_color_fast_clear_compatible(struct brw_context *brw,
brw->mesa_to_isl_render_format[mt->format])
   return false;
 
-   const bool srgb_rb = _mesa_get_srgb_format_linear(mt->format) != mt->format;
-  /* Gen10 doesn't automatically decode the clear color of sRGB buffers. Since
-   * we currently don't perform this decode in software, avoid a fast-clear
-   * altogether. TODO: Do this in software.
-   */
const mesa_format format = _mesa_get_render_format(ctx, mt->format);
-   if (devinfo->gen >= 10 && srgb_rb) {
-  perf_debug("sRGB fast clear not enabled for (%s)",
- _mesa_get_format_name(format));
-  return false;
-   }
-
if (_mesa_is_format_integer_color(format)) {
   if (devinfo->gen >= 8) {
  perf_debug("Integer fast clear not enabled for (%s)",
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 01/11] i965: Use the brw_context for the clear color and value setters

[Nanley Chery]

Do what all the other functions in the miptree API do.

Reviewed-by: Topi Pohjolainen 
Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 2 +-
 src/mesa/drivers/dri/i965/brw_clear.c | 2 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 44064fc0cf3..f5a653fff97 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1241,7 +1241,7 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
>Color.ClearColor);
 
   bool same_clear_color =
- !intel_miptree_set_clear_color(ctx, irb->mt, clear_color);
+ !intel_miptree_set_clear_color(brw, irb->mt, clear_color);
 
   /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear
* is redundant and can be skipped.
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 8aa83722ee9..8f7594baf59 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -212,7 +212,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
  }
   }
 
-  intel_miptree_set_depth_clear_value(ctx, mt, clear_value);
+  intel_miptree_set_depth_clear_value(brw, mt, clear_value);
}
 
bool need_clear = false;
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 07c85807e80..0c24b93e3da 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -717,26 +717,26 @@ intel_miptree_sample_with_hiz(struct brw_context *brw,
 
 
 static inline bool
-intel_miptree_set_clear_color(struct gl_context *ctx,
+intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
   union isl_color_value clear_color)
 {
if (memcmp(>fast_clear_color, _color, sizeof(clear_color)) != 0) {
   mt->fast_clear_color = clear_color;
-  ctx->NewDriverState |= BRW_NEW_AUX_STATE;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
   return true;
}
return false;
 }
 
 static inline bool
-intel_miptree_set_depth_clear_value(struct gl_context *ctx,
+intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
 float clear_value)
 {
if (mt->fast_clear_color.f32[0] != clear_value) {
   mt->fast_clear_color.f32[0] = clear_value;
-  ctx->NewDriverState |= BRW_NEW_AUX_STATE;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
   return true;
}
return false;
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 06/11] i965/miptree: Extend the sRGB-blending WA to future platforms

[Nanley Chery]

The blending issue seems to be present on CNL as well.

Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index c21c4d8bae1..87c730452b5 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -2704,11 +2704,11 @@ intel_miptree_render_aux_usage(struct brw_context *brw,
  return ISL_AUX_USAGE_NONE;
   }
 
-  /* gen9 hardware technically supports non-0/1 clear colors with sRGB
+  /* gen9+ hardware technically supports non-0/1 clear colors with sRGB
* formats.  However, there are issues with blending where it doesn't
* properly apply the sRGB curve to the clear color when blending.
*/
-  if (devinfo->gen == 9 && blend_enabled &&
+  if (devinfo->gen >= 9 && blend_enabled &&
   isl_format_is_srgb(render_format) &&
   !isl_color_value_is_zero_one(mt->fast_clear_color, render_format))
  return ISL_AUX_USAGE_NONE;
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 03/11] i965: Make the miptree clear color setter take a gl_color_union

[Nanley Chery]

We want to hide the internal details of how the miptree's clear color
is calculated.

Reviewed-by: Topi Pohjolainen 
Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 5 +
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 6 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index f5a653fff97..6ab5267ddea 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1236,12 +1236,9 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
if (can_fast_clear) {
   const enum isl_aux_state aux_state =
  intel_miptree_get_aux_state(irb->mt, irb->mt_level, irb->mt_layer);
-  union isl_color_value clear_color =
- brw_meta_convert_fast_clear_color(brw, irb->mt,
-   >Color.ClearColor);
 
   bool same_clear_color =
- !intel_miptree_set_clear_color(brw, irb->mt, clear_color);
+ !intel_miptree_set_clear_color(brw, irb->mt, >Color.ClearColor);
 
   /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear
* is redundant and can be skipped.
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 163accf023b..7aa0e7920d3 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -36,6 +36,7 @@
 
 #include "brw_blorp.h"
 #include "brw_context.h"
+#include "brw_meta_util.h"
 #include "brw_state.h"
 
 #include "main/enums.h"
@@ -3774,8 +3775,11 @@ intel_miptree_get_aux_isl_usage(const struct brw_context 
*brw,
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-  union isl_color_value clear_color)
+  const union gl_color_union *color)
 {
+   const union isl_color_value clear_color =
+  brw_meta_convert_fast_clear_color(brw, mt, color);
+
if (memcmp(>fast_clear_color, _color, sizeof(clear_color)) != 0) {
   mt->fast_clear_color = clear_color;
   brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 600296904ba..961f8fe812e 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -718,7 +718,7 @@ intel_miptree_sample_with_hiz(struct brw_context *brw,
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-  union isl_color_value clear_color);
+  const union gl_color_union *color);
 
 bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 02/11] i965/miptree: Move the clear color and value setter implementations

[Nanley Chery]

These will get more complex in later commits.

Reviewed-by: Topi Pohjolainen 
Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 26 ++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 25 -
 2 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 23cb40f3226..163accf023b 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3770,3 +3770,29 @@ intel_miptree_get_aux_isl_usage(const struct brw_context 
*brw,
 
return mt->aux_usage;
 }
+
+bool
+intel_miptree_set_clear_color(struct brw_context *brw,
+  struct intel_mipmap_tree *mt,
+  union isl_color_value clear_color)
+{
+   if (memcmp(>fast_clear_color, _color, sizeof(clear_color)) != 0) {
+  mt->fast_clear_color = clear_color;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
+  return true;
+   }
+   return false;
+}
+
+bool
+intel_miptree_set_depth_clear_value(struct brw_context *brw,
+struct intel_mipmap_tree *mt,
+float clear_value)
+{
+   if (mt->fast_clear_color.f32[0] != clear_value) {
+  mt->fast_clear_color.f32[0] = clear_value;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
+  return true;
+   }
+   return false;
+}
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 0c24b93e3da..600296904ba 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -715,32 +715,15 @@ bool
 intel_miptree_sample_with_hiz(struct brw_context *brw,
   struct intel_mipmap_tree *mt);
 
-
-static inline bool
+bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-  union isl_color_value clear_color)
-{
-   if (memcmp(>fast_clear_color, _color, sizeof(clear_color)) != 0) {
-  mt->fast_clear_color = clear_color;
-  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
-  return true;
-   }
-   return false;
-}
+  union isl_color_value clear_color);
 
-static inline bool
+bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
-float clear_value)
-{
-   if (mt->fast_clear_color.f32[0] != clear_value) {
-  mt->fast_clear_color.f32[0] = clear_value;
-  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
-  return true;
-   }
-   return false;
-}
+float clear_value);
 
 #ifdef __cplusplus
 }
-- 
2.16.2

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

Re: [Mesa-dev] [PATCH v3 013/104] nir: Support deref instructions in remove_dead_variables

[Caio Marcelo de Oliveira Filho]

Hi,

> @@ -144,6 +197,45 @@ remove_dead_var_writes(nir_shader *shader, struct set 
> *live)
> nir_instr_remove(instr);
>   }
>}
> +
> +  /* We walk the list of instructions backwards because we're going to
> +   * delete a deref and all of it's uses and we don't want to end up
> +   * deleting stuff ahead of us.
> +   */
> +  nir_foreach_block(block, function->impl) {
> + nir_foreach_instr_safe(instr, block) {

The comment says backwards, the loop walks forwards.

It seems to me propagating the mode needs to be forward, e.g. a deref
will be marked mode = 0 because of a variable, then another deref that
has the first as parent marked mode = 0. But I might be missing
something.


> +switch (instr->type) {
> +case nir_instr_type_deref: {
> +   /* For deref instructions, propagate modes */
> +   nir_deref_instr *deref = nir_instr_as_deref(instr);
> +   if (deref->deref_type == nir_deref_type_var) {
> +  deref->mode = deref->var->data.mode;
> +   } else {
> +  nir_deref_instr *parent = nir_deref_instr_parent(deref);
> +  deref->mode = parent->mode;
> +   }

Should we write deref->mode only if the new mode is zero?
I.e. deref->var->data.mode == 0 for the first case, and parent->mode
== 0 for the else case.


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

[Mesa-dev] [PATCH] ac/nir: Add workaround for GFX9 buffer views.

[Bas Nieuwenhuizen]

On GFX9 whether the buffer size is interpreted as elements or bytes
depends on whether IDXEN is enabled in the instruction. If the index
is a constant zero, LLVM optimizes IDXEN to 0.

Now the size in elements is interpreted in bytes which of course
results in out of bounds accesses.

The correct fix is most likely to disable the LLVM optimization,
but we need something to work with LLVM <= 6.0.

radeonsi does the max between stride and element count on the CPU
but that results in the size intrinsics returning the wrong size
for the buffer. This would cause CTS errors for radv.

v2: Also include the store changes.

Fixes: e38685cc62e 'Revert "radv: disable support for VEGA for now."'
(backported from 4503ff760c794c3bb15b978a47c530037d56498e for 17.3)
---
 src/amd/common/ac_llvm_build.c  | 20 
 src/amd/common/ac_llvm_build.h  |  8 
 src/amd/common/ac_nir_to_llvm.c | 36 ++--
 src/amd/common/ac_shader_abi.h  |  4 
 4 files changed, 62 insertions(+), 6 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index e5cd23e025..f193f71c3e 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -960,6 +960,26 @@ LLVMValueRef ac_build_buffer_load_format(struct 
ac_llvm_context *ctx,
  AC_FUNC_ATTR_READONLY);
 }
 
+LLVMValueRef ac_build_buffer_load_format_gfx9_safe(struct ac_llvm_context *ctx,
+  LLVMValueRef rsrc,
+  LLVMValueRef vindex,
+  LLVMValueRef voffset,
+  bool can_speculate)
+{
+   LLVMValueRef elem_count = LLVMBuildExtractElement(ctx->builder, rsrc, 
LLVMConstInt(ctx->i32, 2, 0), "");
+   LLVMValueRef stride = LLVMBuildExtractElement(ctx->builder, rsrc, 
LLVMConstInt(ctx->i32, 1, 0), "");
+   stride = LLVMBuildLShr(ctx->builder, stride, LLVMConstInt(ctx->i32, 16, 
0), "");
+
+   LLVMValueRef new_elem_count = LLVMBuildSelect(ctx->builder,
+ 
LLVMBuildICmp(ctx->builder, LLVMIntUGT, elem_count, stride, ""),
+ elem_count, stride, "");
+
+   LLVMValueRef new_rsrc = LLVMBuildInsertElement(ctx->builder, rsrc, 
new_elem_count,
+  LLVMConstInt(ctx->i32, 
2, 0), "");
+
+   return ac_build_buffer_load_format(ctx, new_rsrc, vindex, voffset, 
can_speculate);
+}
+
 /**
  * Set range metadata on an instruction.  This can only be used on load and
  * call instructions.  If you know an instruction can only produce the values
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index aa2a2899ab..d4264f2879 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -188,6 +188,14 @@ LLVMValueRef ac_build_buffer_load_format(struct 
ac_llvm_context *ctx,
 LLVMValueRef voffset,
 bool can_speculate);
 
+/* load_format that handles the stride & element count better if idxen is
+ * disabled by LLVM. */
+LLVMValueRef ac_build_buffer_load_format_gfx9_safe(struct ac_llvm_context *ctx,
+  LLVMValueRef rsrc,
+  LLVMValueRef vindex,
+  LLVMValueRef voffset,
+  bool can_speculate);
+
 LLVMValueRef
 ac_get_thread_id(struct ac_llvm_context *ctx);
 
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index b696cb8a45..8ee80b1a67 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2257,11 +2257,19 @@ static LLVMValueRef build_tex_intrinsic(struct 
ac_nir_context *ctx,
struct ac_image_args *args)
 {
if (instr->sampler_dim == GLSL_SAMPLER_DIM_BUF) {
-   return ac_build_buffer_load_format(>ac,
-  args->resource,
-  args->addr,
-  LLVMConstInt(ctx->ac.i32, 0, 
false),
-  true);
+   if (ctx->abi->gfx9_stride_size_workaround) {
+   return ac_build_buffer_load_format_gfx9_safe(>ac,
+
args->resource,
+args->addr,
+
ctx->ac.i32_0,
+true);
+   } else {
+   return 

Re: [Mesa-dev] [PATCH] gallium: add CAP for postprocess filters

[Marek Olšák]

On Wed, Apr 4, 2018 at 10:30 AM, Roland Scheidegger 
wrote:

> Am 04.04.2018 um 05:42 schrieb Timothy Arceri:
> > On 04/04/18 13:22, Roland Scheidegger wrote:
> >> Am 04.04.2018 um 05:03 schrieb Timothy Arceri:
> >>> On 04/04/18 12:44, Roland Scheidegger wrote:
>  Am 04.04.2018 um 04:32 schrieb Timothy Arceri:
> > On 04/04/18 11:58, Roland Scheidegger wrote:
> >> AFAIK these filters (and I've never looked into them) should be
> >> transparent to hw drivers. Hence a cap bit doesn't make sense, and
> if
> >> it's broken we shouldn't just paper over this.
> >
> > I created a CAP because the AMD devs have no interest in supporting
> > this
> > feature [1]. Even if they are transparent to drivers I don't see why
> > drivers should be forced to enable them if they don't want to. CCing
> > Marek for his opinion.
> 
>  I still don't see why using cap bits for bugs is a good idea.
> >>>
> >>> Well I see it as a CAP for an unwanted feature that just happens to not
> >>> work currently.
> >>>
>  (Even more so if the bug actually would be in the postprocess, but
> I've
>  no idea there really.)
> >>>
> >>> It's crashing in src/gallium/drivers/radeonsi/si_state_draw.c
> >>
> >> Doesn't necessarily mean the bug is in the driver.
> >> Not sure it's really worth fixing it this way neither - people are
> >> probably just as confused why pp won't work than they are if it's
> >> crashing...
> >
> > Well I can either update the webpage to say its disabled for radeonsi or
> > I can close the bugs as won't fix and let people wonder why its crashing
> > potentially filling another bug report. The first bug was filed a year
> > ago and nobody seems to want to fix it. Either way I don't care to much
> > but disabling the feature seems like a better way to go than just
> > letting it crash forever.
>
> Alright, if the bug is that old I suppose there's really no interest in
> actually fixing it...
> So I suppose that would be an improvement...
>

I've just fixed it. The patches are on the ML.

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

[Mesa-dev] [PATCH 1/2] gallium/pp: use user constant buffers

[Marek Olšák]

From: Marek Olšák 

This fixes a radeonsi crash.
---
 src/gallium/auxiliary/cso_cache/cso_context.c  | 17 
 src/gallium/auxiliary/cso_cache/cso_context.h  |  3 +++
 src/gallium/auxiliary/postprocess/pp_mlaa.c| 37 --
 src/gallium/auxiliary/postprocess/pp_private.h |  1 -
 4 files changed, 25 insertions(+), 33 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 3fa57f16ff4..3a3a63a3327 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -1540,20 +1540,37 @@ cso_set_constant_buffer_resource(struct cso_context 
*cso,
   cb.buffer = buffer;
   cb.buffer_offset = 0;
   cb.buffer_size = buffer->width0;
   cb.user_buffer = NULL;
   cso_set_constant_buffer(cso, shader_stage, index, );
} else {
   cso_set_constant_buffer(cso, shader_stage, index, NULL);
}
 }
 
+void
+cso_set_constant_user_buffer(struct cso_context *cso,
+ enum pipe_shader_type shader_stage,
+ unsigned index, void *ptr, unsigned size)
+{
+   if (ptr) {
+  struct pipe_constant_buffer cb;
+  cb.buffer = NULL;
+  cb.buffer_offset = 0;
+  cb.buffer_size = size;
+  cb.user_buffer = ptr;
+  cso_set_constant_buffer(cso, shader_stage, index, );
+   } else {
+  cso_set_constant_buffer(cso, shader_stage, index, NULL);
+   }
+}
+
 void
 cso_save_constant_buffer_slot0(struct cso_context *cso,
enum pipe_shader_type shader_stage)
 {
util_copy_constant_buffer(>aux_constbuf_saved[shader_stage],
  >aux_constbuf_current[shader_stage]);
 }
 
 void
 cso_restore_constant_buffer_slot0(struct cso_context *cso,
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h 
b/src/gallium/auxiliary/cso_cache/cso_context.h
index b1bc0813442..3a4e808f0c0 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.h
+++ b/src/gallium/auxiliary/cso_cache/cso_context.h
@@ -207,20 +207,23 @@ cso_set_shader_images(struct cso_context *cso,
 
 /* constant buffers */
 
 void cso_set_constant_buffer(struct cso_context *cso,
  enum pipe_shader_type shader_stage,
  unsigned index, struct pipe_constant_buffer *cb);
 void cso_set_constant_buffer_resource(struct cso_context *cso,
   enum pipe_shader_type shader_stage,
   unsigned index,
   struct pipe_resource *buffer);
+void cso_set_constant_user_buffer(struct cso_context *cso,
+  enum pipe_shader_type shader_stage,
+  unsigned index, void *ptr, unsigned size);
 void cso_save_constant_buffer_slot0(struct cso_context *cso,
 enum pipe_shader_type shader_stage);
 void cso_restore_constant_buffer_slot0(struct cso_context *cso,
enum pipe_shader_type shader_stage);
 
 
 /* drawing */
 
 void
 cso_draw_vbo(struct cso_context *cso,
diff --git a/src/gallium/auxiliary/postprocess/pp_mlaa.c 
b/src/gallium/auxiliary/postprocess/pp_mlaa.c
index 0edd01f3f5d..610cedbd1b3 100644
--- a/src/gallium/auxiliary/postprocess/pp_mlaa.c
+++ b/src/gallium/auxiliary/postprocess/pp_mlaa.c
@@ -50,76 +50,64 @@
 #include "util/u_inlines.h"
 #include "util/u_memory.h"
 #include "util/u_string.h"
 #include "pipe/p_screen.h"
 
 #define IMM_SPACE 80
 
 static float constants[] = { 1, 1, 0, 0 };
 static unsigned int dimensions[2] = { 0, 0 };
 
-/** Upload the constants. */
-static void
-up_consts(struct pp_queue_t *ppq)
-{
-   struct pipe_context *pipe = ppq->p->pipe;
-
-   pipe->buffer_subdata(pipe, ppq->constbuf, PIPE_TRANSFER_WRITE,
-0, sizeof(constants), constants);
-}
-
 /** Run function of the MLAA filter. */
 static void
 pp_jimenezmlaa_run(struct pp_queue_t *ppq, struct pipe_resource *in,
struct pipe_resource *out, unsigned int n, bool iscolor)
 {
 
struct pp_program *p = ppq->p;
 
struct pipe_depth_stencil_alpha_state mstencil;
struct pipe_sampler_view v_tmp, *arr[3];
 
unsigned int w = 0;
unsigned int h = 0;
 
const struct pipe_stencil_ref ref = { {1} };
 
/* Insufficient initialization checks. */
assert(p);
assert(ppq);
-   assert(ppq->constbuf);
assert(ppq->areamaptex);
assert(ppq->inner_tmp);
assert(ppq->shaders[n]);
 
w = p->framebuffer.width;
h = p->framebuffer.height;
 
memset(, 0, sizeof(mstencil));
 
cso_set_stencil_ref(p->cso, );
 
/* Init the pixel size constant */
if (dimensions[0] != p->framebuffer.width ||
dimensions[1] != p->framebuffer.height) {
   constants[0] = 1.0f / p->framebuffer.width;
   constants[1] = 1.0f / p->framebuffer.height;
 
-  

[Mesa-dev] [PATCH 2/2] gallium/pp: fix MLAA shaders

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/auxiliary/postprocess/pp_mlaa.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/postprocess/pp_mlaa.h 
b/src/gallium/auxiliary/postprocess/pp_mlaa.h
index 85c14a786a3..3507f813781 100644
--- a/src/gallium/auxiliary/postprocess/pp_mlaa.h
+++ b/src/gallium/auxiliary/postprocess/pp_mlaa.h
@@ -56,21 +56,21 @@ static const char depth1fs[] = "FRAG\n"
"  0: TEX TEMP[0].x, IN[1].xyyy, SAMP[0], 2D\n"
"  1: MOV TEMP[1].x, TEMP[0].\n"
"  2: TEX TEMP[0].x, IN[1].zwww, SAMP[0], 2D\n"
"  3: MOV TEMP[1].y, TEMP[0].\n"
"  4: TEX TEMP[0].x, IN[2].xyyy, SAMP[0], 2D\n"
"  5: MOV TEMP[1].z, TEMP[0].\n"
"  6: TEX TEMP[0].x, IN[2].zwww, SAMP[0], 2D\n"
"  7: MOV TEMP[1].w, TEMP[0].\n"
"  8: TEX TEMP[0].x, IN[0].xyyy, SAMP[0], 2D\n"
"  9: ADD TEMP[2], TEMP[0]., -TEMP[1]\n"
-   " 10: ABS TEMP[0], TEMP[2]\n"
+   " 10: MOV TEMP[0], |TEMP[2]|\n"
" 11: SGE TEMP[2], TEMP[0], IMM[0].\n"
" 12: DP4 TEMP[0].x, TEMP[2], IMM[0].\n"
" 13: SEQ TEMP[1].x, TEMP[0]., IMM[0].\n"
" 14: IF TEMP[1]. :16\n"
" 15:   KILL\n"
" 16: ENDIF\n"
" 17: MOV OUT[0], TEMP[2]\n"
" 18: END\n";
 
 
@@ -89,21 +89,21 @@ static const char color1fs[] = "FRAG\n"
"  1: DP3 TEMP[0].x, TEMP[1].xyzz, IMM[0]\n"
"  2: TEX TEMP[1].xyz, IN[1].zwww, SAMP[0], 2D\n"
"  3: DP3 TEMP[0].y, TEMP[1].xyzz, IMM[0].xyzz\n"
"  4: TEX TEMP[1].xyz, IN[2].xyyy, SAMP[0], 2D\n"
"  5: DP3 TEMP[0].z, TEMP[1].xyzz, IMM[0].xyzz\n"
"  6: TEX TEMP[1].xyz, IN[2].zwww, SAMP[0], 2D\n"
"  7: DP3 TEMP[0].w, TEMP[1].xyzz, IMM[0].xyzz\n"
"  8: TEX TEMP[1].xyz, IN[0].xyyy, SAMP[0], 2D\n"
"  9: DP3 TEMP[2].x, TEMP[1].xyzz, IMM[0].xyzz\n"
" 10: ADD TEMP[1], TEMP[2]., -TEMP[0]\n"
-   " 11: ABS TEMP[0], TEMP[1]\n"
+   " 11: MOV TEMP[0], |TEMP[1]|\n"
" 12: SGE TEMP[2], TEMP[0], IMM[0].\n"
" 13: DP4 TEMP[0].x, TEMP[2], IMM[1].\n"
" 14: SEQ TEMP[1].x, TEMP[0]., IMM[1].\n"
" 15: IF TEMP[1]. :17\n"
" 16:   KILL\n"
" 17: ENDIF\n"
" 18: MOV OUT[0], TEMP[2]\n"
" 19: END\n";
 
 
@@ -254,21 +254,21 @@ static const char blend2fs_2[] =
" 61:   MOV TEMP[4], TEMP[1].xyyy\n"
" 62:   MOV TEMP[4].w, IMM[0].\n"
" 63:   TXL TEMP[5].x, TEMP[4], SAMP[2], 2D\n"
" 64:   MOV TEMP[4].x, TEMP[5].\n"
" 65:   MOV TEMP[5], TEMP[1].zwww\n"
" 66:   MOV TEMP[5].w, IMM[0].\n"
" 67:   TXL TEMP[1].x, TEMP[5], SAMP[2], 2D\n"
" 68:   MOV TEMP[4].y, TEMP[1].\n"
" 69:   MUL TEMP[5].xy, IMM[2]., TEMP[4].xyyy\n"
" 70:   ROUND TEMP[1].xy, TEMP[5].xyyy\n"
-   " 71:   ABS TEMP[4].xy, TEMP[3].xyyy\n"
+   " 71:   MOV TEMP[4].xy, |TEMP[3].xyyy|\n"
" 72:   MAD TEMP[3].xy, IMM[2]., TEMP[1].xyyy, TEMP[4].xyyy\n"
" 73:   MUL TEMP[5].xyz, TEMP[3].xyyy, IMM[0].\n"
" 74:   MOV TEMP[5].w, IMM[0].\n"
" 75:   TXL TEMP[0].xy, TEMP[5], SAMP[0], 2D\n"
" 76: ENDIF\n"
" 77: SNE TEMP[1].x, TEMP[2]., IMM[0].\n"
" 78: IF TEMP[1]. :151\n"
" 79:   MOV TEMP[1].xy, IN[0].xyxx\n"
" 80:   MOV TEMP[3].x, IMM[1].\n"
" 81:   BGNLOOP :98\n"
@@ -328,21 +328,21 @@ static const char blend2fs_2[] =
"135:   MOV TEMP[3], TEMP[1].xyyy\n"
"136:   MOV TEMP[3].w, IMM[0].\n"
"137:   TXL TEMP[4].y, TEMP[3], SAMP[2], 2D\n"
"138:   MOV TEMP[3].x, TEMP[4].\n"
"139:   MOV TEMP[4], TEMP[1].zwww\n"
"140:   MOV TEMP[4].w, IMM[0].\n"
"141:   TXL TEMP[1].y, TEMP[4], SAMP[2], 2D\n"
"142:   MOV TEMP[3].y, TEMP[1].\n"
"143:   MUL TEMP[4].xy, IMM[2]., TEMP[3].xyyy\n"
"144:   ROUND TEMP[1].xy, TEMP[4].xyyy\n"
-   "145:   ABS TEMP[3].xy, TEMP[2].xyyy\n"
+   "145:   MOV TEMP[3].xy, |TEMP[2].xyyy|\n"
"146:   MAD TEMP[2].xy, IMM[2]., TEMP[1].xyyy, TEMP[3].xyyy\n"
"147:   MUL TEMP[3].xyz, TEMP[2].xyyy, IMM[0].\n"
"148:   MOV TEMP[3].w, IMM[0].\n"
"149:   TXL TEMP[1].xy, TEMP[3], SAMP[0], 2D\n"
"150:   MOV TEMP[0].zw, TEMP[1].yyxy\n"
"151: ENDIF\n"
"152: MOV OUT[0], TEMP[0]\n"
"153: END\n";
 
 #endif
-- 
2.15.1

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

[Mesa-dev] [Bug 105832] radeonsi NIR missing bindless textures support

[bugzilla-daemon]

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

--- Comment #18 from b...@besd.de  ---
I've also changed shader capture to name shaders after the sha1 of their source
+ program number and noticed that shader-db compiles some of them twice with
different results (happens for TGSI as well but makes comparisons difficult):
R600_DEBUG=nir ./run shaders/metro2033redux/ | sort

shaders/metro2033redux/fa37761e70a58456b26005791e1ae0ea1f8398b03876.shader_test
- LLVM diagnostic (remark): :0:0: 215 instructions in function
shaders/metro2033redux/fa37761e70a58456b26005791e1ae0ea1f8398b03876.shader_test
- LLVM diagnostic (remark): :0:0: 324 instructions in function
shaders/metro2033redux/fa37761e70a58456b26005791e1ae0ea1f8398b03876.shader_test
- Shader Stats: SGPRS: 56 VGPRS: 36 Code Size: 1060 LDS: 0 Scratch: 0 Max
Waves: 7 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0
shaders/metro2033redux/fa37761e70a58456b26005791e1ae0ea1f8398b03876.shader_test
- Shader Stats: SGPRS: 64 VGPRS: 32 Code Size: 1720 LDS: 0 Scratch: 0 Max
Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0
shaders/metro2033redux/fa70500e637e4e51c3c907df268522ec48430dc82798.shader_test
- LLVM diagnostic (remark): :0:0: 250 instructions in function
shaders/metro2033redux/fa70500e637e4e51c3c907df268522ec48430dc82798.shader_test
- LLVM diagnostic (remark): :0:0: 87 instructions in function
shaders/metro2033redux/fa70500e637e4e51c3c907df268522ec48430dc82798.shader_test
- Shader Stats: SGPRS: 40 VGPRS: 28 Code Size: 484 LDS: 0 Scratch: 0 Max Waves:
8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0
shaders/metro2033redux/fa70500e637e4e51c3c907df268522ec48430dc82798.shader_test
- Shader Stats: SGPRS: 48 VGPRS: 32 Code Size: 1300 LDS: 0 Scratch: 0 Max
Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0

-- 
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] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Leo Liu]

On 04/04/2018 12:40 PM, Mark Janes wrote:

Leo Liu  writes:


On the CI family, firmware requires the destory command have to be the
last command in the IB, moving feedback command after destroy is causing
issues on CI cards, so we have to keep the previous logic that moves
destroy back to the last command.

But as the original issue fixed previously, with the newer family like Vega10,
feedback command have to be included inside of the task info command along
with destroy command.

Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")

Signed-off-by: Leo Liu 
Cc: mesa-sta...@lists.freedesktop.org

These tags seem ambiguous to me.  If this commit fixes a specific
commit, then the patch should be applied only to stable branches which
contain that commit.

However, the mesa-stable CC caused this patch to be applied to 17.3,
which does *not* contain the broken patch.

Leo: did you intend for the mesa-stable CC to cause this patch to be
applied to older stable branches?
I would like to have this patch apply to branches "17.2", "17.3", 
"18.0", which got patch titled "radeon/vce: move destroy command before 
feedback command"


And this Cc-ed patch is to fix "radeon/vce: move destroy command before 
feedback command"


Thanks,
Leo




Release managers: is there a protocol for how this specification should
be parsed, when considering a patch for stable?


---
  src/gallium/drivers/radeon/radeon_vce.c|  1 -
  src/gallium/drivers/radeon/radeon_vce_40_2_2.c |  2 ++
  src/gallium/drivers/radeon/radeon_vce_52.c | 18 ++
  3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 427bf01ed8..c84103e0ac 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -247,7 +247,6 @@ static void rvce_destroy(struct pipe_video_codec *encoder)
enc->fb = 
enc->session(enc);
enc->destroy(enc);
-   enc->feedback(enc);
flush(enc);
si_vid_destroy_buffer();
}
diff --git a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c 
b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
index f1db47d4bd..04e9d7f5e1 100644
--- a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
+++ b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
@@ -421,6 +421,8 @@ static void destroy(struct rvce_encoder *enc)
  {
enc->task_info(enc, 0x0001, 0, 0, 0);
  
+	feedback(enc);

+
RVCE_BEGIN(0x0201); // destroy
RVCE_END();
  }
diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
b/src/gallium/drivers/radeon/radeon_vce_52.c
index a941c476f6..421539c4bd 100644
--- a/src/gallium/drivers/radeon/radeon_vce_52.c
+++ b/src/gallium/drivers/radeon/radeon_vce_52.c
@@ -458,14 +458,6 @@ static void config_extension(struct rvce_encoder *enc)
RVCE_END();
  }
  
-static void destroy(struct rvce_encoder *enc)

-{
-   enc->task_info(enc, 0x0001, 0, 0, 0);
-
-   RVCE_BEGIN(0x0201); // destroy
-   RVCE_END();
-}
-
  static void feedback(struct rvce_encoder *enc)
  {
RVCE_BEGIN(0x0505); // feedback buffer
@@ -474,6 +466,16 @@ static void feedback(struct rvce_encoder *enc)
RVCE_END();
  }
  
+static void destroy(struct rvce_encoder *enc)

+{
+   enc->task_info(enc, 0x0001, 0, 0, 0);
+
+   feedback(enc);
+
+   RVCE_BEGIN(0x0201); // destroy
+   RVCE_END();
+}
+
  static void motion_estimation(struct rvce_encoder *enc)
  {
RVCE_BEGIN(0x0407); // motion estimation
--
2.14.1

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


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

Re: [Mesa-dev] [PATCH, v2] CHROMIUM: configure.ac/meson.build: Fix -latomic test

[Matt Turner]

On Thu, Mar 29, 2018 at 4:10 PM, Nicolas Boichat  wrote:
> On Fri, Mar 30, 2018 at 2:26 AM, Matt Turner  wrote:
>> On Thu, Mar 29, 2018 at 1:31 AM, Nicolas Boichat  
>> wrote:
>>> From: Nicolas Boichat 
>>>
>>> When compiling with LLVM 6.0, the test fails to detect that
>>> -latomic is actually required, as the atomic call is inlined.
>>>
>>> In the code itself (src/util/disk_cache.c), we see this pattern:
>>> p_atomic_add(cache->size, - (uint64_t)size);
>>> where cache->size is an uint64_t *, and results in the following
>>> link time error without -latomic:
>>> src/util/disk_cache.c:628: error: undefined reference to 
>>> '__atomic_fetch_add_8'
>>>
>>> Fix the configure/meson test to replicate this pattern, which then
>>> correctly realizes the need for -latomic.
>>>
>>> Signed-off-by: Nicolas Boichat 
>>> ---
>>>
>>> Changes since v1:
>>>  - Updated meson.build as well (untested)
>>>
>>>  configure.ac | 6 --
>>>  meson.build  | 6 --
>>>  2 files changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index e874f8ebfb2..eff9a0ef88f 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -445,9 +445,11 @@ if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
>>>  AC_MSG_CHECKING(whether -latomic is needed)
>>>  AC_LINK_IFELSE([AC_LANG_SOURCE([[
>>>  #include 
>>> -uint64_t v;
>>> +struct {
>>> +uint64_t* v;
>>
>> I wouldn't care expect that you put the * with the v in the Meson case. :)
>
> Argh ,-( I'll send a v3, let's see if anyone has further comments, first.
>
>> Also, on what platform does this occur?
>
> This is ARC++ (Android 32-bit x86) with clang version:
> Android (4639204 based on r316199) clang version 6.0.1
> (https://android.googlesource.com/toolchain/clang
> 279c0d3a962121a6d1d535e7b0b5d9d36d3c829d)
> (https://android.googlesource.com/toolchain/llvm
> aadd87ffb6a2eafcb577913073d46b20195a9cdc) (based on LLVM 6.0.1svn)
>
>> Looking at this code, I would expect it to behave the same as before.
>> Do you have an idea why this fixes it, or why the original code didn't
>> work? I'm guess it's about the compiler's ability to recognize that it
>> knows the location of the variable.
>
> With the original code, objdump looks like this:
>
> 08048400 :
>  8048400:   53  push   %ebx
>  8048401:   56  push   %esi
>  8048402:   e8 00 00 00 00  call   8048407 
>  8048407:   5e  pop%esi
>  8048408:   81 c6 ed 1b 00 00   add$0x1bed,%esi
>  804840e:   31 c0   xor%eax,%eax
>  8048410:   31 d2   xor%edx,%edx
>  8048412:   31 c9   xor%ecx,%ecx
>  8048414:   31 db   xor%ebx,%ebx
>  8048416:   f0 0f c7 8e 24 00 00lock cmpxchg8b 0x24(%esi)
>  804841d:   00
>  804841e:   5e  pop%esi
>  804841f:   5b  pop%ebx
>  8048420:   c3  ret
>
> Looks like LLVM figures out that  is constant, and uses some 64-bit
> atomic swap operations on it directly.
>
> With the updated code (building with -latomic, it fails otherwise)
> 08048480 :
>  8048480:   53  push   %ebx
>  8048481:   83 ec 08sub$0x8,%esp
>  8048484:   e8 00 00 00 00  call   8048489 
>  8048489:   5b  pop%ebx
>  804848a:   81 c3 6b 1b 00 00   add$0x1b6b,%ebx
>  8048490:   83 ec 08sub$0x8,%esp
>  8048493:   6a 02   push   $0x2
>  8048495:   ff b3 8c 10 00 00   pushl  0x108c(%ebx)
>  804849b:   e8 05 00 00 00  call   80484a5 <__atomic_load_8>
>  80484a0:   83 c4 18add$0x18,%esp
>  80484a3:   5b  pop%ebx
>  80484a4:   c3  ret
>
> I think the the code is trying to protect both x.v (address) _and_ its
> value *x.v? Or maybe LLVM does not see the pattern... (I don't see why
> cmpxchg8b wouldn't work here too, otherwise...)
>
> Actually, the test can be made simpler, by just using:
> uint64_t *v;
> ...
> __atomic_load_n(v, ...
>
> But then it does not match the usage pattern in the code, so I feel a
> little bit more confident that the current test will actually capture
> when -latomic is needed.

Yeah. That makes sense, and seems like a good idea to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Mark Janes]

Emil Velikov  writes:

> On 4 April 2018 at 17:40, Mark Janes  wrote:
>> Leo Liu  writes:
>>
>>> On the CI family, firmware requires the destory command have to be the
>>> last command in the IB, moving feedback command after destroy is causing
>>> issues on CI cards, so we have to keep the previous logic that moves
>>> destroy back to the last command.
>>>
>>> But as the original issue fixed previously, with the newer family like 
>>> Vega10,
>>> feedback command have to be included inside of the task info command along
>>> with destroy command.
>>>
>>> Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
>>>
>>> Signed-off-by: Leo Liu 
>>> Cc: mesa-sta...@lists.freedesktop.org
>>
>> These tags seem ambiguous to me.  If this commit fixes a specific
>> commit, then the patch should be applied only to stable branches which
>> contain that commit.
>>
>> However, the mesa-stable CC caused this patch to be applied to 17.3,
>> which does *not* contain the broken patch.
>>
>> Leo: did you intend for the mesa-stable CC to cause this patch to be
>> applied to older stable branches?
>>
>> Release managers: is there a protocol for how this specification should
>> be parsed, when considering a patch for stable?
>>
> If the Fixes tag, reference a commit that is missing in specific
> stable branch then obviously the fix is not suitable.
> Hence the stable piece than be ignored + alongside a reply to the
> patch that it will not be in $stable_branch because $reason.

OK, we have violated this policy at least a couple times in the previous
release, based on my audits:

  2f67c9b17518cf0d2fe946e39e5b8ff5ec2797c5
  i965/vec4: Fix null destination register in 3-source instructions

  6f69b63896ce2352aaa25f89287133f7f2ba1fab
  radeon/vce: move feedback command inside of destroy function

> Even if offending commit is not part of $stable_branch, getting into
> the habit and cross-referencing is very beneficial.
> Some customers may use non-stable branch, hence having track of which
> fixes they need is a smart move.
>
> HTH
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Mark Janes]

"Juan A. Suarez Romero"  writes:

> On Wed, 2018-04-04 at 10:07 -0700, Mark Janes wrote:
>> Emil Velikov  writes:
>> > In detail:
>> >  * make the patch queue, release date and blockers accessible at any
>> >point in time:
>> > * queued patches can be accessed, via a branch - say wip/17.3,
>> >   wip/18.0, wip/18.1, etc. The branch _will be_ rebased, although
>> >   normally reverts are recommended.
>> 
>> I created a bot that applies commits from master to wip stable branches
>> and tests in CI.  It runs several times a day and identifies patches
>> that do not cherry-pick cleanly.  Branches are here:
>> 
>>  https://github.com/janesma/mesa/tree/wip/17.3
>>  https://github.com/janesma/mesa/tree/wip/18.0
>> 
>> I've sent a couple of mails to developers when their recent patches
>> don't apply.  So far it handles about 85% of the commits containing
>> stable tags without intervention.
>> 
>
> Cool! I was thinking on a similar approach here:
>
> * Everytime a push happens, a job/bot scans the pushed patches, and creates a
> pull request with the stable patches. If some of the patches that does not
> apply, then it sends an email to the authors informing.

IMO, automating messages to developers will generate undesired noise on
mailing lists.  We should have a real person moderate the notifications,
until they prove to be consistently actionable.

> I group all the stable patches in one PR because when a push is done,
> I assume that all the patches belong to the same feature/bugfix, and
> thus it makes sense to deal with them as in one PR.

PRs seem like an unnecessary complication.  My proof-of-concept script
simply applies all commits with stable tags to an arbitrary wip branch,
based on the stable branch policies.

CI triggers from the wip branch as with any developer CI branch.

> * There's a bot that is listening for the PR. Everytime a new PR
> arrives, it starts the proper testing. If test is successful, it
> automatically merges the PR; otherwise it just sends an email
> informing the failure. An important point here is that if a PR is
> under testing, then the bot waits until the test finishes and the PR
> under testing is either merged or rejected. If it is merged, the bot
> rebases the new PR and starts the test. This way, we guarantee the
> test is done with a version that won't change after while the test is
> happening. If you are more interested, I was thinking on using Marge
> bot for this.

Fewer/smaller dependencies is better.  What does gitlab + marge buy us
over a single script?

To be clear, my script is gross at the moment.  I just hacked to get
something that would match the stable policy, and provide immediate
feedback when commits are pushed.  It could be cleaned up and shared if
anyone wants it.

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #11 from Tapani Pälli  ---
(In reply to sergio.callegari from comment #9)
> A quick question... the patch being mentioned is related to the part of xorg
> that usually gets packaged as xserver-xorg-core, right? Not to the
> individual video drivers such as those packaged in xserver-xorg-video-intel,
> correct?
> 
> I am asking because ubuntu has various PPAs providing updated graphic
> stacks, but all of them appear to be currently shipping the updated
> video-xxx packages but no updated core package for xorg.

Yes, it would be the xore package. The change is not in individual driver but
the server glx code.

-- 
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] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Emil Velikov]

On 4 April 2018 at 17:40, Mark Janes  wrote:
> Leo Liu  writes:
>
>> On the CI family, firmware requires the destory command have to be the
>> last command in the IB, moving feedback command after destroy is causing
>> issues on CI cards, so we have to keep the previous logic that moves
>> destroy back to the last command.
>>
>> But as the original issue fixed previously, with the newer family like 
>> Vega10,
>> feedback command have to be included inside of the task info command along
>> with destroy command.
>>
>> Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
>>
>> Signed-off-by: Leo Liu 
>> Cc: mesa-sta...@lists.freedesktop.org
>
> These tags seem ambiguous to me.  If this commit fixes a specific
> commit, then the patch should be applied only to stable branches which
> contain that commit.
>
> However, the mesa-stable CC caused this patch to be applied to 17.3,
> which does *not* contain the broken patch.
>
> Leo: did you intend for the mesa-stable CC to cause this patch to be
> applied to older stable branches?
>
> Release managers: is there a protocol for how this specification should
> be parsed, when considering a patch for stable?
>
If the Fixes tag, reference a commit that is missing in specific
stable branch then obviously the fix is not suitable.
Hence the stable piece than be ignored + alongside a reply to the
patch that it will not be in $stable_branch because $reason.

Even if offending commit is not part of $stable_branch, getting into
the habit and cross-referencing is very beneficial.
Some customers may use non-stable branch, hence having track of which
fixes they need is a smart move.

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

[Mesa-dev] [Bug 105567] meson/ninja: 1. mesa/vdpau incorrect symlinks in DESTDIR and 2. Ddri-drivers-path Dvdpau-libs-path overrides DESTDIR

[bugzilla-daemon]

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

--- Comment #5 from Dylan Baker  ---
patch here:
https://patchwork.freedesktop.org/patch/214930/

As a side note, feel free to CC me on any meson related things.

The missing version script should be fixed for 18.0.1, the change is in master
as bc2fdb9759dc702ec351a044b3fd408c0701fedb.

I've also sent a patch to fix the xa version which is missing:
https://patchwork.freedesktop.org/series/41150/

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

[Mesa-dev] [PATCH] meson: Set .so version for xa like autotools does

[Dylan Baker]

Fixes: 0ba909f0f111824223bc38563d1a6bc73e69c2cc
   ("meson: build gallium xa state tracker")
Signed-off-by: Dylan Baker 
---
 src/gallium/targets/xa/meson.build | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/targets/xa/meson.build 
b/src/gallium/targets/xa/meson.build
index ea6e1296dae..733ef54ff85 100644
--- a/src/gallium/targets/xa/meson.build
+++ b/src/gallium/targets/xa/meson.build
@@ -30,6 +30,7 @@ if with_ld_version_script
   xa_link_depends += files('xa.sym')
 endif
 
+_xa_version = '.'.join(xa_version)
 
 libxatracker = shared_library(
   'xatracker',
@@ -49,12 +50,13 @@ libxatracker = shared_library(
   dependencies : [
 dep_thread, driver_nouveau, driver_i915, driver_svga, driver_freedreno,
   ],
+  version : _xa_version,
   install : true,
 )
 
 pkg.generate(
   name : 'xatracker',
   description : 'Xorg gallium3D acceleration library',
-  version : '.'.join(xa_version),
+  version : _xa_version,
   libraries : libxatracker,
 )
-- 
2.16.3

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Juan A. Suarez Romero]

On Wed, 2018-04-04 at 09:40 -0700, Mark Janes wrote:
> Leo Liu  writes:
> 
> > On the CI family, firmware requires the destory command have to be the
> > last command in the IB, moving feedback command after destroy is causing
> > issues on CI cards, so we have to keep the previous logic that moves
> > destroy back to the last command.
> > 
> > But as the original issue fixed previously, with the newer family like 
> > Vega10,
> > feedback command have to be included inside of the task info command along
> > with destroy command.
> > 
> > Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
> > 
> > Signed-off-by: Leo Liu 
> > Cc: mesa-sta...@lists.freedesktop.org
> 
> These tags seem ambiguous to me.  If this commit fixes a specific
> commit, then the patch should be applied only to stable branches which
> contain that commit.
> 
> However, the mesa-stable CC caused this patch to be applied to 17.3,
> which does *not* contain the broken patch.
> 
> Leo: did you intend for the mesa-stable CC to cause this patch to be
> applied to older stable branches?
> 
> Release managers: is there a protocol for how this specification should
> be parsed, when considering a patch for stable?
> 

In my case, if a patch is nominated, then it is applied to the proper stable
branch. I understand that while the patch probably fixes a commit, it makes
sense per se as a valid independent patch.

But I think we should modify our script to warn us in this situation and just
clarify with the author about the intention.


J.A.


> > ---
> >  src/gallium/drivers/radeon/radeon_vce.c|  1 -
> >  src/gallium/drivers/radeon/radeon_vce_40_2_2.c |  2 ++
> >  src/gallium/drivers/radeon/radeon_vce_52.c | 18 ++
> >  3 files changed, 12 insertions(+), 9 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
> > b/src/gallium/drivers/radeon/radeon_vce.c
> > index 427bf01ed8..c84103e0ac 100644
> > --- a/src/gallium/drivers/radeon/radeon_vce.c
> > +++ b/src/gallium/drivers/radeon/radeon_vce.c
> > @@ -247,7 +247,6 @@ static void rvce_destroy(struct pipe_video_codec 
> > *encoder)
> > enc->fb = 
> > enc->session(enc);
> > enc->destroy(enc);
> > -   enc->feedback(enc);
> > flush(enc);
> > si_vid_destroy_buffer();
> > }
> > diff --git a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c 
> > b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> > index f1db47d4bd..04e9d7f5e1 100644
> > --- a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> > +++ b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> > @@ -421,6 +421,8 @@ static void destroy(struct rvce_encoder *enc)
> >  {
> > enc->task_info(enc, 0x0001, 0, 0, 0);
> >  
> > +   feedback(enc);
> > +
> > RVCE_BEGIN(0x0201); // destroy
> > RVCE_END();
> >  }
> > diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
> > b/src/gallium/drivers/radeon/radeon_vce_52.c
> > index a941c476f6..421539c4bd 100644
> > --- a/src/gallium/drivers/radeon/radeon_vce_52.c
> > +++ b/src/gallium/drivers/radeon/radeon_vce_52.c
> > @@ -458,14 +458,6 @@ static void config_extension(struct rvce_encoder *enc)
> > RVCE_END();
> >  }
> >  
> > -static void destroy(struct rvce_encoder *enc)
> > -{
> > -   enc->task_info(enc, 0x0001, 0, 0, 0);
> > -
> > -   RVCE_BEGIN(0x0201); // destroy
> > -   RVCE_END();
> > -}
> > -
> >  static void feedback(struct rvce_encoder *enc)
> >  {
> > RVCE_BEGIN(0x0505); // feedback buffer
> > @@ -474,6 +466,16 @@ static void feedback(struct rvce_encoder *enc)
> > RVCE_END();
> >  }
> >  
> > +static void destroy(struct rvce_encoder *enc)
> > +{
> > +   enc->task_info(enc, 0x0001, 0, 0, 0);
> > +
> > +   feedback(enc);
> > +
> > +   RVCE_BEGIN(0x0201); // destroy
> > +   RVCE_END();
> > +}
> > +
> >  static void motion_estimation(struct rvce_encoder *enc)
> >  {
> > RVCE_BEGIN(0x0407); // motion estimation
> > -- 
> > 2.14.1
> > 
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Juan A. Suarez Romero]

On Wed, 2018-04-04 at 10:07 -0700, Mark Janes wrote:
> Emil Velikov  writes:
> 
> > Hi all,
> > 
> > Having gone through the thread a few times, I believe it can be
> > summarised as follows:
> >  * Greater transparency is needed.
> >  * Subsystem/team maintainers.
> >  * Unfit and late nominations.
> >  * Developers/everyone should be more involved.
> >  * Greater automation must be explored.
> > 
> > 
> > NOTES:
> >  * Some of the details are not listed in the thread, but have been
> >raised in one form or another.
> >  * The details focuses more on the goals, than the actual means.
> >  * Above said, some details may have been missed - I'm mere human.
> > 
> > 
> > In detail:
> >  * make the patch queue, release date and blockers accessible at any
> >point in time:
> > * queued patches can be accessed, via a branch - say wip/17.3,
> >   wip/18.0, wip/18.1, etc. The branch _will be_ rebased, although
> >   normally reverts are recommended.
> 
> I created a bot that applies commits from master to wip stable branches
> and tests in CI.  It runs several times a day and identifies patches
> that do not cherry-pick cleanly.  Branches are here:
> 
>  https://github.com/janesma/mesa/tree/wip/17.3
>  https://github.com/janesma/mesa/tree/wip/18.0
> 
> I've sent a couple of mails to developers when their recent patches
> don't apply.  So far it handles about 85% of the commits containing
> stable tags without intervention.
> 

Cool! I was thinking on a similar approach here:

* Everytime a push happens, a job/bot scans the pushed patches, and creates a
pull request with the stable patches. If some of the patches that does not
apply, then it sends an email to the authors informing. I group all the stable
patches in one PR because when a push is done, I assume that all the patches
belong to the same feature/bugfix, and thus it makes sense to deal with them as
in one PR.

* There's a bot that is listening for the PR. Everytime a new PR arrives, it
starts the proper testing. If test is successful, it automatically merges the
PR; otherwise it just sends an email informing the failure. An important point
here is that if a PR is under testing, then the bot waits until the test
finishes and the PR under testing is either merged or rejected. If it is merged,
the bot rebases the new PR and starts the test. This way, we guarantee the test
is done with a version that won't change after while the test is happening. If
you are more interested, I was thinking on using Marge bot for this.


J.A.



> > * rejected patches must be listed alongside the reason why and
> >   author+reviewer must be informed (email & IRC?) ASAP.
> >* we already document and track those in .cherry-ignore. can we
> >  reuse that?
> > 
> > * patches with trivial conflicts can be merged to the wip branch
> >   after another release manager, or patch author/reviewer has
> >   confirmed the changes.
> > 
> > * patches that require backports will be rejected. usual rejection
> >   procedure applies (described above).
> > 
> > * if there is delay due to extra testing time or otherwise, the
> >   release manager must list the blocking issues and ETA must be
> >   provided. ETA must be updated before it's reached. it may be
> >   worth having the ETA and rejections in a single place - inside
> >   the wip/ branch, html page, elsewhere.
> > 
> > * the current metabug with release blockers must be made more
> >   obvious.
> > 
> > * release manager can contact Phoronix and/or similar media to
> >   publicise expected delays, blockers or seek request for testing.
> > 
> > 
> >  * teams are encouraged to have one or multiple maintainers. some of
> >the goals of having such people include:
> > * individuals that have greater interaction with the team and
> >   knowledge about the team plans. rough examples include:
> >* backport/bug is needed, yet person is not available - on a
> >  leave (sick, sabbatical, other) or busy with other things.
> >* team has higher priority with details not publicly available.
> > 
> > * can approve unfit or late nominations - see next section.
> > * to ensure cover and minimise stress it's encouraged to have
> >   multiple maintainers per team and they are rotated regularly.
> > * list of maintainers must be documented
> > 
> > 
> >  * unfit and late nominations:
> > * any rejections that are unfit based on the existing criteria can
> >   be merged as long as:
> >* subsystem specific patches are approved by the team
> >  maintainer(s).
> >* patches that cover multiple subsystems are approved by 50%+1
> >  of the maintainers of the affected subsystems.
> > 
> > * late nominations can be made after the pre-release announcement.
> >   they must be approved by the subsystem maintainers up-to X hours
> >   

Re: [Mesa-dev] [PATCH 1/4] mesa: add INTEL_blackhole_render

[Lionel Landwerlin]

On 04/04/18 17:51, Emil Velikov wrote:

On 4 April 2018 at 15:48, Lionel Landwerlin
 wrote:

On 15/03/18 16:03, Emil Velikov wrote:


Spec says "OpenGL 3.0 is required" so GLL + GLC should become 30
Wrt GLES side the spec does not mention anything - is that ES1, ES2,
which version etc.
Worth keeping it simple and update the spec to say ES2+?
The patch implements Enable/Disable, yet IsEnabled is missing.

Actually the gl.xml was set to enable it for GL/GLES2, although written
against the ES3 spec.


The "supported" section in the XML should reflect the supported API.
I don't think it supports gles3 or any other form of explicit version check.

The version checks are only on mesa's extensions_table.h. IIRC that
one is there because some apps assume that the extension is advertised
only if all the dependencies are met.
Layman example: I need GL3.0 and extension FOO. Since the FOO already
requires GL3.0, I can omit the GL3.0 check.

Since the spec says GL 3.0 and (any) GLES, I'd make the line "30, 30, ES1, ES2"


Thanks a lot. I just figured what GLL/GLC means ;)



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



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

[Mesa-dev] [PATCH] meson: fix megadriver symlinking

[Dylan Baker]

Which should be relative instead of absolute.

Fixes: f7f1b30f81e842db6057591470ce3cb6d4fb2795
   ("meson: extend install_megadrivers script to handle symmlinking")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105567
Signed-off-by: Dylan Baker 
---
 bin/install_megadrivers.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/install_megadrivers.py b/bin/install_megadrivers.py
index 86bfa359188..7931a544bd2 100755
--- a/bin/install_megadrivers.py
+++ b/bin/install_megadrivers.py
@@ -58,7 +58,7 @@ def main():
 while ext != '.so':
 if os.path.exists(name):
 os.unlink(name)
-os.symlink(driver, name)
+os.symlink(each, name)
 name, ext = os.path.splitext(name)
 finally:
 os.chdir(ret)
-- 
2.16.3

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

[Mesa-dev] [Bug 105567] meson/ninja: 1. mesa/vdpau incorrect symlinks in DESTDIR and 2. Ddri-drivers-path Dvdpau-libs-path overrides DESTDIR

[bugzilla-daemon]

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

--- Comment #4 from Jan Alexander Steffens (heftig)  ---
Arch Linux currently carries two patches (fix-install.diff and
fix-versions.diff) to reduce to differences between the Meson product and the
Autotools one; it also adds the project version script that was missing from
the 18.0.0 tarball.

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

Re: [Mesa-dev] [PATCH 02/17] ac/surface: don't set the display flag for obviously unsupported cases

[Marek Olšák]

On Wed, Apr 4, 2018 at 9:01 AM, Michel Dänzer  wrote:

> On 2018-04-04 02:57 PM, Marek Olšák wrote:
> > On Wed, Apr 4, 2018, 6:18 AM Michel Dänzer  > > wrote:
> >
> > On 2018-04-04 03:59 AM, Marek Olšák wrote:
> > > From: Marek Olšák  >>
> > >
> > > This enables the tile swizzle for some cases of the displayable
> > micro mode,
> > > and it also fixes an addrlib assertion failure on Vega.
> > > ---
> > >  src/amd/common/ac_surface.c | 18 ++
> > >  1 file changed, 14 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/src/amd/common/ac_surface.c
> b/src/amd/common/ac_surface.c
> > > index b294cd85259..2b20a553d51 100644
> > > --- a/src/amd/common/ac_surface.c
> > > +++ b/src/amd/common/ac_surface.c
> > > @@ -408,20 +408,29 @@ static unsigned
> > cik_get_macro_tile_index(struct radeon_surf *surf)
> > >   tileb = 8 * 8 * surf->bpe;
> > >   tileb = MIN2(surf->u.legacy.tile_split, tileb);
> > >
> > >   for (index = 0; tileb > 64; index++)
> > >   tileb >>= 1;
> > >
> > >   assert(index < 16);
> > >   return index;
> > >  }
> > >
> > > +static bool get_display_flag(const struct ac_surf_config *config,
> > > +  const struct radeon_surf *surf)
> > > +{
> > > + return surf->flags & RADEON_SURF_SCANOUT &&
> > > +!(surf->flags & RADEON_SURF_FMASK) &&
> > > +config->info.samples <= 1 &&
> > > +surf->bpe >= 4 && surf->bpe <= 8;
> >
> > surf->bpe is the number of bytes used to store each pixel, right? If
> so,
> > this cannot exclude surf->bpe < 4, since 16 bpp and 8 bpp formats
> can be
> > displayed.
> >
> >
> > Sure, but what are the chances they will be displayed with the current
> > stack? GLX doesn't have 16bpp visuals for on-screen rendering.
>
> Maybe not when the X server runs at depth 24, but it can also run at
> depths 8, 15 & 16, in which case displayable surfaces with bpe == 1 or 2
> are needed even before GLX even comes into the picture.
>

OK. Let me ask differently. Do we wanna support displayable 8, 15, and 16
bpp? Can we just say that we don't support those?

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

[Mesa-dev] [Bug 105567] meson/ninja: 1. mesa/vdpau incorrect symlinks in DESTDIR and 2. Ddri-drivers-path Dvdpau-libs-path overrides DESTDIR

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Dylan Baker  ---
I'm sorry I let this slip so long, someone had sent a patch to fix this and I'd
asked them to make some changes and that never happened. I'm sending a patch
for this.

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

[Mesa-dev] [Bug 105567] meson/ninja: 1. mesa/vdpau incorrect symlinks in DESTDIR and 2. Ddri-drivers-path Dvdpau-libs-path overrides DESTDIR

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |baker.dyla...@gmail.com
   |org |

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

Tasev  changed:

   What|Removed |Added

 CC||tasev.stefano...@skynet.be

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #10 from Tasev  ---
Hi,
Same bug here after upgrading today to mesa 18.0 on both Broadwell and Skylake
mobile.

mesa 18.0.0 from padoka PPA stable
X.Org version: 1.19.5
KDE Neon
KDE Frameworks 5.44.0
Qt 5.10
KDE Plasma 5.12.4
kernel 4.13.0-38-generic (ubuntu) (tested also with 4.15 and 4.16)
intel driver 2.99.917 + git

For info, no problem on ivybridge and ironlake mobile with the same config.

-- 
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] [RFC] Mesa 17.3.x release problems and process improvements

[Mark Janes]

Emil Velikov  writes:

> Hi all,
>
> Having gone through the thread a few times, I believe it can be
> summarised as follows:
>  * Greater transparency is needed.
>  * Subsystem/team maintainers.
>  * Unfit and late nominations.
>  * Developers/everyone should be more involved.
>  * Greater automation must be explored.
>
>
> NOTES:
>  * Some of the details are not listed in the thread, but have been
>raised in one form or another.
>  * The details focuses more on the goals, than the actual means.
>  * Above said, some details may have been missed - I'm mere human.
>
>
> In detail:
>  * make the patch queue, release date and blockers accessible at any
>point in time:
> * queued patches can be accessed, via a branch - say wip/17.3,
>   wip/18.0, wip/18.1, etc. The branch _will be_ rebased, although
>   normally reverts are recommended.

I created a bot that applies commits from master to wip stable branches
and tests in CI.  It runs several times a day and identifies patches
that do not cherry-pick cleanly.  Branches are here:

 https://github.com/janesma/mesa/tree/wip/17.3
 https://github.com/janesma/mesa/tree/wip/18.0

I've sent a couple of mails to developers when their recent patches
don't apply.  So far it handles about 85% of the commits containing
stable tags without intervention.

> * rejected patches must be listed alongside the reason why and
>   author+reviewer must be informed (email & IRC?) ASAP.
>* we already document and track those in .cherry-ignore. can we
>  reuse that?
>
> * patches with trivial conflicts can be merged to the wip branch
>   after another release manager, or patch author/reviewer has
>   confirmed the changes.
>
> * patches that require backports will be rejected. usual rejection
>   procedure applies (described above).
>
> * if there is delay due to extra testing time or otherwise, the
>   release manager must list the blocking issues and ETA must be
>   provided. ETA must be updated before it's reached. it may be
>   worth having the ETA and rejections in a single place - inside
>   the wip/ branch, html page, elsewhere.
>
> * the current metabug with release blockers must be made more
>   obvious.
>
> * release manager can contact Phoronix and/or similar media to
>   publicise expected delays, blockers or seek request for testing.
>
>
>  * teams are encouraged to have one or multiple maintainers. some of
>the goals of having such people include:
> * individuals that have greater interaction with the team and
>   knowledge about the team plans. rough examples include:
>* backport/bug is needed, yet person is not available - on a
>  leave (sick, sabbatical, other) or busy with other things.
>* team has higher priority with details not publicly available.
>
> * can approve unfit or late nominations - see next section.
> * to ensure cover and minimise stress it's encouraged to have
>   multiple maintainers per team and they are rotated regularly.
> * list of maintainers must be documented
>
>
>  * unfit and late nominations:
> * any rejections that are unfit based on the existing criteria can
>   be merged as long as:
>* subsystem specific patches are approved by the team
>  maintainer(s).
>* patches that cover multiple subsystems are approved by 50%+1
>  of the maintainers of the affected subsystems.
>
> * late nominations can be made after the pre-release announcement.
>   they must be approved by the subsystem maintainers up-to X hours
>   before the actual release. approval specifics are identical to the
>   ones listed in 'unfit' section just above.
>
>
>  * developers/everyone should be more involved:
> * with the patch queue accessible at any point, everyone is
>   encouraged to keep an eye open and report issues.
>
> * developers should be more active in providing backports and
>   updating the status of release blocking bugs.
>
> * release managers and team maintainers must check with developer
>   (via email, IRC, other) if no action has been made for X days.
>
> * everyone is encouraged to provide a piglit/dEQP/etc testing
>   summary (via email, attachment, html page., etc). if they do,
>   please ensure that summary consistently available, regardless if
>   there's any regressions or not. if extra time is needed reply to
>   the list informing release managers
>
> * in case of regressions bisection must be provided.
>
>
>  * testing - pre and post merge, automation:
>
>NOTE: implementation specifics is up-to each team, with goals of:
>a) results must be accessible reasonably easy
>b) high level documentation of the setup and contact points are
>   documented
>
> * with over 120 developers contributing to mesa, ambiguous patch
>   nominations will always exist.

[Mesa-dev] [Bug 105847] Profile GL3bc is not available on X11GraphicsDevice

[bugzilla-daemon]

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

--- Comment #1 from Emil Velikov  ---
Some of the previous scilab reports indicate that the jogl has some funky
driver detection code - see bug 103078.

If the suggestion from there (reinstating the "Gallium 0.4") makes things work
again, then we can call this a duplicate.

-- 
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 1/4] mesa: add INTEL_blackhole_render

[Emil Velikov]

On 4 April 2018 at 15:48, Lionel Landwerlin
 wrote:
> On 15/03/18 16:03, Emil Velikov wrote:
>
>> Spec says "OpenGL 3.0 is required" so GLL + GLC should become 30
>> Wrt GLES side the spec does not mention anything - is that ES1, ES2,
>> which version etc.
>> Worth keeping it simple and update the spec to say ES2+?
>
>> The patch implements Enable/Disable, yet IsEnabled is missing.
>
> Actually the gl.xml was set to enable it for GL/GLES2, although written
> against the ES3 spec.
>
The "supported" section in the XML should reflect the supported API.
I don't think it supports gles3 or any other form of explicit version check.

The version checks are only on mesa's extensions_table.h. IIRC that
one is there because some apps assume that the extension is advertised
only if all the dependencies are met.
Layman example: I need GL3.0 and extension FOO. Since the FOO already
requires GL3.0, I can omit the GL3.0 check.

Since the spec says GL 3.0 and (any) GLES, I'd make the line "30, 30, ES1, ES2"

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Mark Janes]

Leo Liu  writes:

> On the CI family, firmware requires the destory command have to be the
> last command in the IB, moving feedback command after destroy is causing
> issues on CI cards, so we have to keep the previous logic that moves
> destroy back to the last command.
>
> But as the original issue fixed previously, with the newer family like Vega10,
> feedback command have to be included inside of the task info command along
> with destroy command.
>
> Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
>
> Signed-off-by: Leo Liu 
> Cc: mesa-sta...@lists.freedesktop.org

These tags seem ambiguous to me.  If this commit fixes a specific
commit, then the patch should be applied only to stable branches which
contain that commit.

However, the mesa-stable CC caused this patch to be applied to 17.3,
which does *not* contain the broken patch.

Leo: did you intend for the mesa-stable CC to cause this patch to be
applied to older stable branches?

Release managers: is there a protocol for how this specification should
be parsed, when considering a patch for stable?

> ---
>  src/gallium/drivers/radeon/radeon_vce.c|  1 -
>  src/gallium/drivers/radeon/radeon_vce_40_2_2.c |  2 ++
>  src/gallium/drivers/radeon/radeon_vce_52.c | 18 ++
>  3 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
> b/src/gallium/drivers/radeon/radeon_vce.c
> index 427bf01ed8..c84103e0ac 100644
> --- a/src/gallium/drivers/radeon/radeon_vce.c
> +++ b/src/gallium/drivers/radeon/radeon_vce.c
> @@ -247,7 +247,6 @@ static void rvce_destroy(struct pipe_video_codec *encoder)
>   enc->fb = 
>   enc->session(enc);
>   enc->destroy(enc);
> - enc->feedback(enc);
>   flush(enc);
>   si_vid_destroy_buffer();
>   }
> diff --git a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c 
> b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> index f1db47d4bd..04e9d7f5e1 100644
> --- a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> +++ b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> @@ -421,6 +421,8 @@ static void destroy(struct rvce_encoder *enc)
>  {
>   enc->task_info(enc, 0x0001, 0, 0, 0);
>  
> + feedback(enc);
> +
>   RVCE_BEGIN(0x0201); // destroy
>   RVCE_END();
>  }
> diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
> b/src/gallium/drivers/radeon/radeon_vce_52.c
> index a941c476f6..421539c4bd 100644
> --- a/src/gallium/drivers/radeon/radeon_vce_52.c
> +++ b/src/gallium/drivers/radeon/radeon_vce_52.c
> @@ -458,14 +458,6 @@ static void config_extension(struct rvce_encoder *enc)
>   RVCE_END();
>  }
>  
> -static void destroy(struct rvce_encoder *enc)
> -{
> - enc->task_info(enc, 0x0001, 0, 0, 0);
> -
> - RVCE_BEGIN(0x0201); // destroy
> - RVCE_END();
> -}
> -
>  static void feedback(struct rvce_encoder *enc)
>  {
>   RVCE_BEGIN(0x0505); // feedback buffer
> @@ -474,6 +466,16 @@ static void feedback(struct rvce_encoder *enc)
>   RVCE_END();
>  }
>  
> +static void destroy(struct rvce_encoder *enc)
> +{
> + enc->task_info(enc, 0x0001, 0, 0, 0);
> +
> + feedback(enc);
> +
> + RVCE_BEGIN(0x0201); // destroy
> + RVCE_END();
> +}
> +
>  static void motion_estimation(struct rvce_encoder *enc)
>  {
>   RVCE_BEGIN(0x0407); // motion estimation
> -- 
> 2.14.1
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Emil Velikov]

On 22 March 2018 at 00:39, Ilia Mirkin  wrote:
> Just one bit of feedback, for the rest I either agree or have no opinion:
>
> On Wed, Mar 21, 2018 at 8:28 PM, Emil Velikov  
> wrote:
>>  * unfit and late nominations:
>> * any rejections that are unfit based on the existing criteria can
>>   be merged as long as:
>>* subsystem specific patches are approved by the team
>>  maintainer(s).
>>* patches that cover multiple subsystems are approved by 50%+1
>>  of the maintainers of the affected subsystems.
>
> I don't think 50% + 1 is workable. That would mean for a core mesa
> patch, one would have to get like 5+ people to ack it. Seems like a
> lot. (And I suspect will lead to debates about how to count "affected"
> subsystems.) IMHO 2 is enough, i.e. the maintainer that wants it, and
> another maintainer who thinks it's reasonable.
>
The presumption of 5+ people is based that we'll get at least 8
sub-system maintainers.

As of now, there has been only one person to clearly step forward - Mark.
Even if we get as many, the idea is to have broad consensus or at
least awareness.

An explicit NACK (as you mentioned later) is perfect, but it has
fairly big assumption.
Namely: other maintainers will review/test the patch, before actual
release (with it) is made.

Sure 50% might be too much and we can make it lower (say 30%), but
you'd want more representative size than 2.
Feature releases are a collective work of over 100 people, while
stable releases average of around 15.

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

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #17 from Ben Clapp  ---
(In reply to Samuel Pitoiset from comment #16)
> Thanks, are you still using the same dolphin? If not, can you report the
> version number, please?

Currently using commit dea30e08b for dolphin (was latest commit in master
branch about two days ago).

-- 
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 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #16 from Samuel Pitoiset  ---
Thanks, are you still using the same dolphin? If not, can you report the
version number, please?

-- 
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 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #15 from Ben Clapp  ---
Created attachment 138586
  --> https://bugs.freedesktop.org/attachment.cgi?id=138586=edit
vulkaninfo output when using mesa 18.0.

I already had attached my vulkaninfo, but that was back when I was using
17.2.x, so here's an updated version.

-- 
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 00/14] Enable sRGB-encoded fast-clears on CannonLake

[Nanley Chery]

On Tue, Apr 03, 2018 at 03:50:38PM -0700, Jason Ekstrand wrote:
> I think I've reviewed all the ones that make significant functional
> changes.  The exception is the patch that makes us not do a fast depth
> clear.  I think what you did is probably better but I haven't thought about
> it enough to be sure.
> 

I can drop this patch. Although I think it's an improvement, I should
probably find some benchmarks to substantiate the claim.

> I'm not sure what I think about the last several that mostly move code
> around.  On the one hand, it kind-of unifies the "should we fast-clear"
> question into intel_mipmap_tree.c.  On the other hand, it pulls it away
> from the function that actually does the clear spreads the code out more.
> Multiple times in the past, I've wanted to pull the guts of the color
> clearing code out of brw_blorp.c and into brw_clear.c and just have
> brw_clear_miptree and brw_ccs/mcs_clear_miptree helpers.  Then all of those
> decisions would be together in brw_clear.c.  In any case, I'll think on it
> more.
> 

I understand your concern. There are multiple ways to go about hiding
::fast_clear_color and the one I went for (with super-powered setters)
does have the issues you bring up. I'll send out a v2 that accomplishes
hiding it in a less invasive manner. Please, let me know which version
you prefer (if either).

-Nanley

> --Jason
> 
> 
> On Fri, Mar 30, 2018 at 11:12 AM, Nanley Chery 
> wrote:
> 
> > Starting with CannonLake, the sampler no longer decodes the surface
> > state clear color when using an sRGB-formatted texture. This change
> > requires that our driver perform this decode in software instead. We
> > accounted for this change initially by disabling fast-clears when sRGB
> > encode was enabled. This series implements the software decode and
> > re-enables sRGB-encoded fast-clears.
> >
> > The software decode is performed through a new getter for the miptree
> > clear color. To keep the miptree API balanced and to discourage its
> > users from accessing the clear color field directly, we add a getter for
> > the depth clear value and change the existing setters so that the user
> > no longer needs to know the current clear color to perform an efficient
> > clear operation.
> >
> > Two piglit tests have been modified to test that the linearization of
> > the clear color occurs (when appropriate) for shader texture() calls and
> > on framebuffer blit sources. The modification patches can be found here:
> > https://lists.freedesktop.org/archives/piglit/2018-March/023996.html
> >
> > Jason Ekstrand (1):
> >   util/srgb: Add a float sRGB -> linear helper
> >
> > Nanley Chery (13):
> >   i965: Use the brw_context for the clear color and value setters
> >   i965/miptree: Move the clear color and value setter implementations
> >   i965: Make the miptree clear color setter take a gl_color_union
> >   i965/miptree: Add and use a getter for the clear color
> >   i965/miptree: Extend the sRGB-blending WA to future platforms
> >   i965/meta_util: Re-enable sRGB-encoded fast-clears on CNL
> >   i965: Add and use a getter for depth miptree clear values
> >   i965: Allow failure when setting the depth clear value
> >   i965/brw_clear: Don't resolve to change the depth clear value
> >   i965/brw_clear: Delete redundant code
> >   i965/blorp: Also skip the fast clear if the clear color differs
> >   i965/miptree: Allow failure when setting the clear color
> >   i965/blorp: Delete redundant code
> >
> >  src/mesa/drivers/dri/i965/brw_blorp.c|  60 +++--
> >  src/mesa/drivers/dri/i965/brw_clear.c|  45 +--
> >  src/mesa/drivers/dri/i965/brw_meta_util.c|  11 --
> >  src/mesa/drivers/dri/i965/brw_misc_state.c   |  15 ---
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |   4 +-
> >  src/mesa/drivers/dri/i965/gen6_depth_state.c |   4 +-
> >  src/mesa/drivers/dri/i965/gen7_misc_state.c  |   3 +-
> >  src/mesa/drivers/dri/i965/gen8_depth_state.c |   3 +-
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 165
> > ++-
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  53 
> >  src/util/format_srgb.h   |  14 ++
> >  11 files changed, 233 insertions(+), 144 deletions(-)
> >
> > --
> > 2.16.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 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #14 from Samuel Pitoiset  ---
Can you attach your vulkaninfo too?

-- 
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 1/4] nir/split_var_copies: handle IMAGE and SAMPLER for bindless vars

[Jason Ekstrand]

On Wed, Apr 4, 2018 at 3:33 AM, Timothy Arceri 
wrote:

> On 04/04/18 20:20, Karol Herbst wrote:
>
>> On Wed, Apr 4, 2018 at 2:23 AM, Jason Ekstrand 
>> wrote:
>>
>>> I have a very strong feeling that this isn't the only place where
>>> reading/writing IMAGE and SAMPLER variables is going to cause NIR
>>> heartburn.
>>> For example, we have special cases in nir_validate for SUBROUTINE
>>> variables
>>> and we probably need IMAGE and SAMPLER support everywhere we have
>>> SUBROUTINE
>>> plus some (since you can write to them now as well).
>>>
>>>
>> yeah. I was just making piglit happy here. I guess I will try to run
>> it with some games using bindless_textures and fix all the crashes I
>> encounter there at least. More piglit tests might be useful as well.
>> Sadly I don't see any bindless_textures tests in the CTS :(
>>
>
> I don't think games really use the spec to its full extent either. I had
> Dawn of War 3 working without issue with just the uniform support
> implemented on radeonsi.
>

Sounds like someone gets to write some more piglit tests. :-)

--Jason


>
>>
>>> On Tue, Apr 3, 2018 at 6:21 AM, Karol Herbst  wrote:
>>>

 Signed-off-by: Karol Herbst 
 ---
   src/compiler/nir/nir_split_var_copies.c | 4 
   1 file changed, 4 insertions(+)

 diff --git a/src/compiler/nir/nir_split_var_copies.c
 b/src/compiler/nir/nir_split_var_copies.c
 index bc3ceedbdb8..231a89add4d 100644
 --- a/src/compiler/nir/nir_split_var_copies.c
 +++ b/src/compiler/nir/nir_split_var_copies.c
 @@ -241,6 +241,10 @@ split_var_copies_block(nir_block *block, struct
 split_var_copies_state *state)
   ralloc_steal(state->dead_ctx, instr);
}
break;
 +  /* for bindless those are uint64 */
 +  case GLSL_TYPE_IMAGE:
 +  case GLSL_TYPE_SAMPLER:
 + assert(src_head->var->data.bindless);
 case GLSL_TYPE_INT:
 case GLSL_TYPE_UINT:
 case GLSL_TYPE_INT16:
 --
 2.14.3

 ___
 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] nir: add support for bindless_texture samplers

[Jason Ekstrand]

On Wed, Apr 4, 2018 at 3:18 AM, Karol Herbst  wrote:

> On Wed, Apr 4, 2018 at 2:16 AM, Jason Ekstrand 
> wrote:
> > On Tue, Apr 3, 2018 at 6:21 AM, Karol Herbst  wrote:
> >>
> >> Signed-off-by: Karol Herbst 
> >> ---
> >>  src/compiler/glsl/glsl_to_nir.cpp | 17 +++--
> >>  src/compiler/nir/nir.h|  1 +
> >>  src/compiler/nir/nir_print.c  |  3 +++
> >>  3 files changed, 19 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/compiler/glsl/glsl_to_nir.cpp
> >> b/src/compiler/glsl/glsl_to_nir.cpp
> >> index dbb58d82e8f..8e2d96a2361 100644
> >> --- a/src/compiler/glsl/glsl_to_nir.cpp
> >> +++ b/src/compiler/glsl/glsl_to_nir.cpp
> >> @@ -1971,6 +1971,8 @@ nir_visitor::visit(ir_texture *ir)
> >>  {
> >> unsigned num_srcs;
> >> nir_texop op;
> >> +   bool bindless =
> >> ir->sampler->variable_referenced()->contains_bindless();
> >> +
> >> switch (ir->op) {
> >> case ir_tex:
> >>op = nir_texop_tex;
> >> @@ -2044,6 +2046,8 @@ nir_visitor::visit(ir_texture *ir)
> >>num_srcs++;
> >> if (ir->offset != NULL)
> >>num_srcs++;
> >> +   if (bindless)
> >> +  num_srcs=+;
> >>
> >> nir_tex_instr *instr = nir_tex_instr_create(this->shader,
> num_srcs);
> >>
> >> @@ -2069,10 +2073,19 @@ nir_visitor::visit(ir_texture *ir)
> >>unreachable("not reached");
> >> }
> >>
> >> -   instr->texture = evaluate_deref(>instr, ir->sampler);
> >> -
> >> unsigned src_number = 0;
> >>
> >> +   /* for bindless we use the handle src */
> >> +   if (bindless) {
> >> +  instr->texture = NULL;
> >> +  instr->src[src_number].src =
> >> + nir_src_for_ssa(evaluate_rvalue(ir->sampler));
> >> +  instr->src[src_number].src_type = nir_tex_src_handle;
> >> +  src_number++;
> >> +   } else {
> >> +  instr->texture = evaluate_deref(>instr, ir->sampler);
> >> +   }
> >> +
> >> if (ir->coordinate != NULL) {
> >>instr->coord_components = ir->coordinate->type->vector_elements;
> >>instr->src[src_number].src =
> >> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> >> index f33049d7134..e4d626d263e 100644
> >> --- a/src/compiler/nir/nir.h
> >> +++ b/src/compiler/nir/nir.h
> >> @@ -1218,6 +1218,7 @@ typedef enum {
> >> nir_tex_src_texture_offset, /* < dynamically uniform indirect offset
> >> */
> >> nir_tex_src_sampler_offset, /* < dynamically uniform indirect offset
> >> */
> >> nir_tex_src_plane,  /* < selects plane for planar textures
> */
> >> +   nir_tex_src_handle, /* < handle for bindless samples */
> >
> >
> > Do we want to have separate texture and sampler handles?  We don't care
> for
> > GL but I kind-of think we will for Vulkan.
> >
>
> Don't know. Never looked into vulkan yet. I could rename it to
> sample_handle for now and we can add the texture handle later for
> vulkan?
>

Sure.  Or we can just add both now and add nir_print support for both and
then we have them.  It's just an enum.  It's not like it costs us much.


> >>
> >> nir_num_tex_src_types
> >>  } nir_tex_src_type;
> >>
> >> diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
> >> index 21f13097651..c9431555f2f 100644
> >> --- a/src/compiler/nir/nir_print.c
> >> +++ b/src/compiler/nir/nir_print.c
> >> @@ -778,6 +778,9 @@ print_tex_instr(nir_tex_instr *instr, print_state
> >> *state)
> >>case nir_tex_src_plane:
> >>   fprintf(fp, "(plane)");
> >>   break;
> >> +  case nir_tex_src_handle:
> >> + fprintf(fp, "(handle)");
> >> + break;
> >>
> >>default:
> >>   unreachable("Invalid texture source type");
> >> --
> >> 2.14.3
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] mesa: add INTEL_blackhole_render

[Lionel Landwerlin]

On 15/03/18 16:03, Emil Velikov wrote:

+EXT(INTEL_blackhole_render  , INTEL_blackhole_render   
  , GLL, GLC,  x , ES2, 2018)

Spec says "OpenGL 3.0 is required" so GLL + GLC should become 30
Wrt GLES side the spec does not mention anything - is that ES1, ES2,
which version etc.
Worth keeping it simple and update the spec to say ES2+?

The patch implements Enable/Disable, yet IsEnabled is missing.
Actually the gl.xml was set to enable it for GL/GLES2, although written 
against the ES3 spec.


Looking at the other extensions, they don't seem to specify what version 
of GLES it applies to.


So I'm still not quite sure what I should put into this extension table :|

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

Re: [Mesa-dev] [PATCH] gallium: add CAP for postprocess filters

[Roland Scheidegger]

Am 04.04.2018 um 05:42 schrieb Timothy Arceri:
> On 04/04/18 13:22, Roland Scheidegger wrote:
>> Am 04.04.2018 um 05:03 schrieb Timothy Arceri:
>>> On 04/04/18 12:44, Roland Scheidegger wrote:
 Am 04.04.2018 um 04:32 schrieb Timothy Arceri:
> On 04/04/18 11:58, Roland Scheidegger wrote:
>> AFAIK these filters (and I've never looked into them) should be
>> transparent to hw drivers. Hence a cap bit doesn't make sense, and if
>> it's broken we shouldn't just paper over this.
>
> I created a CAP because the AMD devs have no interest in supporting
> this
> feature [1]. Even if they are transparent to drivers I don't see why
> drivers should be forced to enable them if they don't want to. CCing
> Marek for his opinion.

 I still don't see why using cap bits for bugs is a good idea.
>>>
>>> Well I see it as a CAP for an unwanted feature that just happens to not
>>> work currently.
>>>
 (Even more so if the bug actually would be in the postprocess, but I've
 no idea there really.)
>>>
>>> It's crashing in src/gallium/drivers/radeonsi/si_state_draw.c
>>
>> Doesn't necessarily mean the bug is in the driver.
>> Not sure it's really worth fixing it this way neither - people are
>> probably just as confused why pp won't work than they are if it's
>> crashing...
> 
> Well I can either update the webpage to say its disabled for radeonsi or
> I can close the bugs as won't fix and let people wonder why its crashing
> potentially filling another bug report. The first bug was filed a year
> ago and nobody seems to want to fix it. Either way I don't care to much
> but disabling the feature seems like a better way to go than just
> letting it crash forever.

Alright, if the bug is that old I suppose there's really no interest in
actually fixing it...
So I suppose that would be an improvement...

Roland


>>
>>
>> Roland
>>
>>>

 Roland

>
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D99549-23c3=DwICaQ=uilaK90D4TOVoH58JNXRgQ=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0=s23eRwsegKslN9P2JpzYmfnEOt7uPtVLO6XI3-BR_h4=LnLvs_TtyuJE3MWrA16CVWgkwxKkfKCuXHJDbtO3KGo=
>
>
>
>
>>
>> Roland
>>
>> Am 03.04.2018 um 13:38 schrieb Timothy Arceri:
>>> For radeonsi these seem to have been somewhat broken for over a
>>> year, and as of recently they cause the driver to crash.
>>>
>>> This patch adds a CAP for the filters and enables the CAP for all
>>> driver except radeonsi.
>>>
>>> Bugzilla:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D99549=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0=FsyE0Iv-1HkgmJ_6JgvnISAuUbjQthRX9OcSu3BUhgc=5iJ7ErqsBvMPRH06U44_GD_7EvtIFP8hzyKeeDtIxxE=
>>>
>>>
>>>
>>> Bugzilla:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D105026=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0=FsyE0Iv-1HkgmJ_6JgvnISAuUbjQthRX9OcSu3BUhgc=PeI7pgvz9cprwPELTcdw_TUZHrtj1tt6KjHa-4rVRtY=
>>>
>>>
>>>
>>> ---
>>>     src/gallium/docs/source/screen.rst   |  2 ++
>>>     src/gallium/drivers/etnaviv/etnaviv_screen.c |  1 +
>>>     src/gallium/drivers/freedreno/freedreno_screen.c |  1 +
>>>     src/gallium/drivers/i915/i915_screen.c   |  1 +
>>>     src/gallium/drivers/llvmpipe/lp_screen.c |  1 +
>>>     src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  1 +
>>>     src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  1 +
>>>     src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  1 +
>>>     src/gallium/drivers/r300/r300_screen.c   |  1 +
>>>     src/gallium/drivers/r600/r600_pipe.c |  1 +
>>>     src/gallium/drivers/radeonsi/si_get.c    |  1 +
>>>     src/gallium/drivers/softpipe/sp_screen.c |  1 +
>>>     src/gallium/drivers/svga/svga_screen.c   |  1 +
>>>     src/gallium/drivers/swr/swr_screen.cpp   |  1 +
>>>     src/gallium/drivers/vc4/vc4_screen.c |  1 +
>>>     src/gallium/drivers/vc5/vc5_screen.c |  1 +
>>>     src/gallium/drivers/virgl/virgl_screen.c |  2 ++
>>>     src/gallium/include/pipe/p_defines.h |  1 +
>>>     src/gallium/state_trackers/dri/dri_screen.c  | 15
>>> ---
>>>     19 files changed, 28 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/src/gallium/docs/source/screen.rst
>>> b/src/gallium/docs/source/screen.rst
>>> index 3837360fb40..22aba928580 100644
>>> --- a/src/gallium/docs/source/screen.rst
>>> +++ b/src/gallium/docs/source/screen.rst
>>> @@ -420,6 +420,8 @@ The integer capabilities:
>>>   by the driver, and the driver can throw assertion failures.
>>>     * 

Re: [Mesa-dev] [PATCH v3 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Mike Lothian]

Are you able to push this for me on my behalf?

On Wed, 4 Apr 2018 at 15:04 Kyriazis, George 
wrote:

> Thank you!
>
> Reviewed-By: George Kyriazis 
>
> On Apr 4, 2018, at 3:22 AM, Mike Lothian  wrote:
>
> Include llvm/Transforms/Utils.h with the newest LLVM 7
>
> v2: Include with " " rather than < > (Vinson Lee)
>
> v3: Use LLVM_VERSION_MAJOR rather than HAVE_LLVM (George Kyriazis)
>
> Signed-of-by: Mike Lothian 
> Tested-by: Vinson Lee 
> ---
> src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> index 031bced8a0..19f68c2bb6 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> @@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
> #include "llvm/Support/DynamicLibrary.h"
> #include "llvm/Transforms/IPO.h"
> #include "llvm/Transforms/Scalar.h"
> +#if LLVM_VERSION_MAJOR >= 7
> +#include "llvm/Transforms/Utils.h"
> +#endif
> #include "llvm/Support/Host.h"
> #include "llvm/Support/DynamicLibrary.h"
>
> --
> 2.17.0
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #13 from Ben Clapp  ---
Created attachment 138583
  --> https://bugs.freedesktop.org/attachment.cgi?id=138583=edit
Dump of unoptimized shaders in scene with incorrect rendering of vertex color.

OK, here's your shader dumps attached to the ticket, both optimized and
optimized.
There may be some unrelated shaders included in the dump due to the way
dolphin/shader dumping works, but not sure there's much I can do about that.
Let me know if you need anything else.

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

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #12 from Ben Clapp  ---
Created attachment 138582
  --> https://bugs.freedesktop.org/attachment.cgi?id=138582=edit
Dump of optimized shaders in scene with incorrect rendering of vertex color.

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #9 from sergio.calleg...@gmail.com ---
A quick question... the patch being mentioned is related to the part of xorg
that usually gets packaged as xserver-xorg-core, right? Not to the individual
video drivers such as those packaged in xserver-xorg-video-intel, correct?

I am asking because ubuntu has various PPAs providing updated graphic stacks,
but all of them appear to be currently shipping the updated video-xxx packages
but no updated core package for xorg.

-- 
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 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #8 from sergio.calleg...@gmail.com ---
I do not know if the following information is relevant, but in doubt I am
providing it:

I was the original reporter of
https://bugs.freedesktop.org/show_bug.cgi?id=103699. The issue with the firefox
menus has been fixed for a while on my system and even with mesa 18, I get the
firefox menus fine.

It is unclear to me if the issue is with something that should not happen with
the opengl visuals or with something that happens but is then mismanaged by
kwin. To assure that the kwin developers are aware of the issue, I have cross
posted on their bug repo as https://bugs.kde.org/show_bug.cgi?id=392716

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

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #11 from Timothy Arceri  ---
(In reply to Ben Clapp from comment #10)
> Regarding the freeze when using the OpenGL backend with Mesa 18.0, it seems
> a different user has already reported that bug:
> https://bugs.dolphin-emu.org/issues/10904
> https://bugs.freedesktop.org/show_bug.cgi?id=105339
> 
> Apologies for the late response Timothy.
> 
> >Do you think you could get a dump of the NIR and LLVM IR for the shaders in 
> >question and attach it here? You can use the following environment var to 
> >dump ?the shaders: RADV_DEBUG=shaders
> I'm struggling to properly dump the shaders because RADV now has an on-disk
> shader cache, and RADV_DEBUG=shaders seems to only print out shaders when
> they are actually compiled for the first time.
> How can I clear and/or disable the shader cache?

RADV_DEBUG=nocache or MESA_GLSL_CACHE_DISABLE=1 should do it. Also you can dump
the unoptimised LLVM IR with RADV_DEBUG=preoptir which can be useful sometimes.

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #7 from Tapani Pälli  ---
I see the patch in "server-1.19-branch" but it looks like there has not been a
release which would include the fix :/ Release 1.19.7 will have it.

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

Re: [Mesa-dev] [PATCH v3 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Kyriazis, George]

Thank you!

Reviewed-By: George Kyriazis 
>

On Apr 4, 2018, at 3:22 AM, Mike Lothian 
> wrote:

Include llvm/Transforms/Utils.h with the newest LLVM 7

v2: Include with " " rather than < > (Vinson Lee)

v3: Use LLVM_VERSION_MAJOR rather than HAVE_LLVM (George Kyriazis)

Signed-of-by: Mike Lothian >
Tested-by: Vinson Lee >
---
src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
index 031bced8a0..19f68c2bb6 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
#include "llvm/Support/DynamicLibrary.h"
#include "llvm/Transforms/IPO.h"
#include "llvm/Transforms/Scalar.h"
+#if LLVM_VERSION_MAJOR >= 7
+#include "llvm/Transforms/Utils.h"
+#endif
#include "llvm/Support/Host.h"
#include "llvm/Support/DynamicLibrary.h"

--
2.17.0


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

Re: [Mesa-dev] Status of radeonsi NIR

[Benedikt Schemmer]

RX460 4GB

Am 04.04.2018 um 15:59 schrieb Timothy Arceri:
> On 04/04/18 22:53, Benedikt Schemmer wrote:
>> Hi Timothy,
>>
>> another game that is behaving strangly is Metro 2033 Redux, also crashes
>> earlier with apitrace attached. This time TGSI and NIR crash at about
>> the same time (press any key to continue screen)
>> Without apitrace TGSI works fine, NIR crashes like above.
> 
> Strange. This game works fine for me on NIR, what card did you say you
> were testing on?
> 
>>
>> ==> metronir <==
>> 2059446 glDisableVertexAttribArray(index = 8)
>> 2059447 glDisableVertexAttribArray(index = 9)
>> 2059448 glDisableVertexAttribArray(index = 10)
>> 2059449 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer
>> = 3)
>> 2059450 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
>> blob(352), usage = GL_DYNAMIC_DRAW)
>> 2059451 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 720, type
>> = GL_UNSIGNED_SHORT, indices = 0x176a6, basevertex = 15823)
>> 2059452 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer
>> = 3)
>> 2059453 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
>> blob(352), usage = GL_DYNAMIC_DRAW)
>> 2059454 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 711, type
>> = GL_UNSIGNED_SHORT, indices = 0x17c46, basevertex = 16303)
>> 2059455 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer
>> = 3)
>>
>> ==> metrotgsi <==
>> 1744537 glEnableVertexAttribArray(index = 4)
>> 1744538 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
>> stride = 32, pointer = 0x18)
>> 1744539 glVertexAttribDivisor(index = 4, divisor = 0)
>> 1744540 glDisableVertexAttribArray(index = 5)
>> 1744541 glDisableVertexAttribArray(index = 6)
>> 1744542 glDisableVertexAttribArray(index = 7)
>> 1744543 glDisableVertexAttribArray(index = 8)
>> 1744544 glDisableVertexAttribArray(index = 9)
>> 1744545 glDisableVertexAttribArray(index = 10)
>> 1744546 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer
>> = 3)
>>
>> ==> metrotgsi2 <==
>> 2141178 glVertexAttribDivisor(index = 1, divisor = 0)
>> 2141179 glEnableVertexAttribArray(index = 2)
>> 2141180 glVertexAttribPointer(index = 2, size = 4, type =
>> GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x10)
>> 2141181 glVertexAttribDivisor(index = 2, divisor = 0)
>> 2141182 glEnableVertexAttribArray(index = 3)
>> 2141183 glVertexAttribPointer(index = 3, size = 4, type =
>> GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x14)
>> 2141184 glVertexAttribDivisor(index = 3, divisor = 0)
>> 2141185 glEnableVertexAttribArray(index = 4)
>> 2141186 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
>> stride = 32, pointer = 0x18)
>> 2141187 glVertexAttribDivisor(index = 4, divisor = 0) // incomplete
>>
>>
>> Am 04.04.2018 um 14:06 schrieb Timothy Arceri:
>>> On 04/04/18 21:51, Benedikt Schemmer wrote:
 Hi Timothy,

 thanks for looking into this.

 Dead Island still crashes for me with NIR.
>>>
>>> Just to make sure, are you building a 32bit version of Mesa? If not you
>>> might be running your system Mesa. If you are definitely building Mesa
>>> 32bit then I'll take a closer look tomorrow.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of radeonsi NIR

[Timothy Arceri]

On 04/04/18 22:53, Benedikt Schemmer wrote:

Hi Timothy,

another game that is behaving strangly is Metro 2033 Redux, also crashes
earlier with apitrace attached. This time TGSI and NIR crash at about
the same time (press any key to continue screen)
Without apitrace TGSI works fine, NIR crashes like above.


Strange. This game works fine for me on NIR, what card did you say you 
were testing on?




==> metronir <==
2059446 glDisableVertexAttribArray(index = 8)
2059447 glDisableVertexAttribArray(index = 9)
2059448 glDisableVertexAttribArray(index = 10)
2059449 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)
2059450 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
blob(352), usage = GL_DYNAMIC_DRAW)
2059451 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 720, type
= GL_UNSIGNED_SHORT, indices = 0x176a6, basevertex = 15823)
2059452 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)
2059453 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
blob(352), usage = GL_DYNAMIC_DRAW)
2059454 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 711, type
= GL_UNSIGNED_SHORT, indices = 0x17c46, basevertex = 16303)
2059455 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)

==> metrotgsi <==
1744537 glEnableVertexAttribArray(index = 4)
1744538 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
stride = 32, pointer = 0x18)
1744539 glVertexAttribDivisor(index = 4, divisor = 0)
1744540 glDisableVertexAttribArray(index = 5)
1744541 glDisableVertexAttribArray(index = 6)
1744542 glDisableVertexAttribArray(index = 7)
1744543 glDisableVertexAttribArray(index = 8)
1744544 glDisableVertexAttribArray(index = 9)
1744545 glDisableVertexAttribArray(index = 10)
1744546 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)

==> metrotgsi2 <==
2141178 glVertexAttribDivisor(index = 1, divisor = 0)
2141179 glEnableVertexAttribArray(index = 2)
2141180 glVertexAttribPointer(index = 2, size = 4, type =
GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x10)
2141181 glVertexAttribDivisor(index = 2, divisor = 0)
2141182 glEnableVertexAttribArray(index = 3)
2141183 glVertexAttribPointer(index = 3, size = 4, type =
GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x14)
2141184 glVertexAttribDivisor(index = 3, divisor = 0)
2141185 glEnableVertexAttribArray(index = 4)
2141186 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
stride = 32, pointer = 0x18)
2141187 glVertexAttribDivisor(index = 4, divisor = 0) // incomplete


Am 04.04.2018 um 14:06 schrieb Timothy Arceri:

On 04/04/18 21:51, Benedikt Schemmer wrote:

Hi Timothy,

thanks for looking into this.

Dead Island still crashes for me with NIR.


Just to make sure, are you building a 32bit version of Mesa? If not you
might be running your system Mesa. If you are definitely building Mesa
32bit then I'll take a closer look tomorrow.

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

Tapani Pälli  changed:

   What|Removed |Added

 CC||lem...@gmail.com

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #6 from Tapani Pälli  ---
Pretty sure this is the same bug, I'm not sure if the Xorg patch is in place
since 32bit visual seems to be srgb capable (see 's'), it shouldn't be like
this with the patch:

--- 8< ---
0x086 32 tc  0  32  0 r  y .   8  8  8  8 .  s  0 24  8  0  0  0  0  0 0 None

-- 
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 3/3] radv: implement a fast prefetch path for the vertex stage

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

for the series.

On Wed, Apr 4, 2018 at 12:12 PM, Samuel Pitoiset
 wrote:
> This allows to start draws as soon as possible.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 40 
> ++--
>  1 file changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 393d9ba4f4..0e59f99799 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -640,39 +640,48 @@ radv_emit_shader_prefetch(struct radv_cmd_buffer 
> *cmd_buffer,
>
>  static void
>  radv_emit_prefetch_L2(struct radv_cmd_buffer *cmd_buffer,
> - struct radv_pipeline *pipeline)
> + struct radv_pipeline *pipeline,
> + bool vertex_stage_only)
>  {
> struct radv_cmd_state *state = _buffer->state;
> +   uint32_t mask = state->prefetch_L2_mask;
>
> if (cmd_buffer->device->physical_device->rad_info.chip_class < CIK)
> return;
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_VS)
> +   if (vertex_stage_only) {
> +   /* Fast prefetch path for starting draws as soon as possible.
> +*/
> +   mask = state->prefetch_L2_mask & (RADV_PREFETCH_VS |
> + 
> RADV_PREFETCH_VBO_DESCRIPTORS);
> +   }
> +
> +   if (mask & RADV_PREFETCH_VS)
> radv_emit_shader_prefetch(cmd_buffer,
>   
> pipeline->shaders[MESA_SHADER_VERTEX]);
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_VBO_DESCRIPTORS)
> +   if (mask & RADV_PREFETCH_VBO_DESCRIPTORS)
> si_cp_dma_prefetch(cmd_buffer, state->vb_va, state->vb_size);
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_TCS)
> +   if (mask & RADV_PREFETCH_TCS)
> radv_emit_shader_prefetch(cmd_buffer,
>   
> pipeline->shaders[MESA_SHADER_TESS_CTRL]);
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_TES)
> +   if (mask & RADV_PREFETCH_TES)
> radv_emit_shader_prefetch(cmd_buffer,
>   
> pipeline->shaders[MESA_SHADER_TESS_EVAL]);
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_GS) {
> +   if (mask & RADV_PREFETCH_GS) {
> radv_emit_shader_prefetch(cmd_buffer,
>   
> pipeline->shaders[MESA_SHADER_GEOMETRY]);
> radv_emit_shader_prefetch(cmd_buffer, 
> pipeline->gs_copy_shader);
> }
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_PS)
> +   if (mask & RADV_PREFETCH_PS)
> radv_emit_shader_prefetch(cmd_buffer,
>   
> pipeline->shaders[MESA_SHADER_FRAGMENT]);
>
> -   state->prefetch_L2_mask = 0;
> +   state->prefetch_L2_mask &= ~mask;
>  }
>
>  static void
> @@ -3042,7 +3051,7 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
>  */
> if (cmd_buffer->state.prefetch_L2_mask) {
> radv_emit_prefetch_L2(cmd_buffer,
> - cmd_buffer->state.pipeline);
> + cmd_buffer->state.pipeline, 
> false);
> }
> } else {
> /* If we don't wait for idle, start prefetches first, then set
> @@ -3051,8 +3060,11 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
> si_emit_cache_flush(cmd_buffer);
>
> if (cmd_buffer->state.prefetch_L2_mask) {
> +   /* Only prefetch the vertex shader and VBO descriptors
> +* in order to start the draw as soon as possible.
> +*/
> radv_emit_prefetch_L2(cmd_buffer,
> - cmd_buffer->state.pipeline);
> + cmd_buffer->state.pipeline, 
> true);
> }
>
> if (!radv_upload_graphics_shader_descriptors(cmd_buffer, 
> pipeline_is_dirty))
> @@ -3060,6 +3072,14 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
>
> radv_emit_all_graphics_states(cmd_buffer, info);
> radv_emit_draw_packets(cmd_buffer, info);
> +
> +   /* Prefetch the remaining shaders after the draw has been
> +* started.
> +*/
> +   if (cmd_buffer->state.prefetch_L2_mask) {
> +   radv_emit_prefetch_L2(cmd_buffer,
> + cmd_buffer->state.pipeline, 
> false);
> +   }
> }
>
> assert(cmd_buffer->cs->cdw <= cdw_max);
> --
> 2.16.3
>

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #10 from Ben Clapp  ---
Regarding the freeze when using the OpenGL backend with Mesa 18.0, it seems a
different user has already reported that bug:
https://bugs.dolphin-emu.org/issues/10904
https://bugs.freedesktop.org/show_bug.cgi?id=105339

Apologies for the late response Timothy.

>Do you think you could get a dump of the NIR and LLVM IR for the shaders in 
>question and attach it here? You can use the following environment var to dump 
>?the shaders: RADV_DEBUG=shaders
I'm struggling to properly dump the shaders because RADV now has an on-disk
shader cache, and RADV_DEBUG=shaders seems to only print out shaders when they
are actually compiled for the first time.
How can I clear and/or disable the shader cache?

>You also might be able to catch the attention of some devs if you jump on the 
>freenode #radeon IRC channel.
I'm already lurking in there, but perhaps I'll actually say something over
there sometime soon.

-- 
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] Status of radeonsi NIR

[Benedikt Schemmer]

Just for baseline:
I have no problem running and creating apitraces from
Bioshock Infinite or TombRaider, I think both 32-bit
CAT Interstellar which is 64-bit

using this command
R600_DEBUG=nir apitrace trace --output=/home/nano/bio2 %command%

and building either the 64 or 32 bit version of apitrace

Am 04.04.2018 um 14:06 schrieb Timothy Arceri:
> On 04/04/18 21:51, Benedikt Schemmer wrote:
>> Hi Timothy,
>>
>> thanks for looking into this.
>>
>> Dead Island still crashes for me with NIR.
> 
> Just to make sure, are you building a 32bit version of Mesa? If not you
> might be running your system Mesa. If you are definitely building Mesa
> 32bit then I'll take a closer look tomorrow.
R600_DEBUG=nir apitrace trace --output=/home/nano/bio2 %command%
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/17] ac/surface: don't set the display flag for obviously unsupported cases

[Michel Dänzer]

On 2018-04-04 02:57 PM, Marek Olšák wrote:
> On Wed, Apr 4, 2018, 6:18 AM Michel Dänzer  > wrote:
> 
> On 2018-04-04 03:59 AM, Marek Olšák wrote:
> > From: Marek Olšák >
> >
> > This enables the tile swizzle for some cases of the displayable
> micro mode,
> > and it also fixes an addrlib assertion failure on Vega.
> > ---
> >  src/amd/common/ac_surface.c | 18 ++
> >  1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> > index b294cd85259..2b20a553d51 100644
> > --- a/src/amd/common/ac_surface.c
> > +++ b/src/amd/common/ac_surface.c
> > @@ -408,20 +408,29 @@ static unsigned
> cik_get_macro_tile_index(struct radeon_surf *surf)
> >       tileb = 8 * 8 * surf->bpe;
> >       tileb = MIN2(surf->u.legacy.tile_split, tileb);
> >
> >       for (index = 0; tileb > 64; index++)
> >               tileb >>= 1;
> >
> >       assert(index < 16);
> >       return index;
> >  }
> >
> > +static bool get_display_flag(const struct ac_surf_config *config,
> > +                          const struct radeon_surf *surf)
> > +{
> > +     return surf->flags & RADEON_SURF_SCANOUT &&
> > +            !(surf->flags & RADEON_SURF_FMASK) &&
> > +            config->info.samples <= 1 &&
> > +            surf->bpe >= 4 && surf->bpe <= 8;
> 
> surf->bpe is the number of bytes used to store each pixel, right? If so,
> this cannot exclude surf->bpe < 4, since 16 bpp and 8 bpp formats can be
> displayed.
> 
> 
> Sure, but what are the chances they will be displayed with the current
> stack? GLX doesn't have 16bpp visuals for on-screen rendering.

Maybe not when the X server runs at depth 24, but it can also run at
depths 8, 15 & 16, in which case displayable surfaces with bpe == 1 or 2
are needed even before GLX even comes into the picture.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 15/17] radeonsi: always prefetch later shaders after the draw packet

[Marek Olšák]

On Wed, Apr 4, 2018, 6:07 AM Samuel Pitoiset 
wrote:

>
>
> On 04/04/2018 03:59 AM, Marek Olšák wrote:
> > From: Marek Olšák 
> >
> > so that the draw is started as soon as possible.
> > ---
> >   src/gallium/drivers/radeonsi/si_cp_dma.c | 68
> ++--
> >   src/gallium/drivers/radeonsi/si_pipe.h   |  2 +-
> >   src/gallium/drivers/radeonsi/si_state_draw.c | 11 -
> >   src/util/bitscan.h   |  8 
> >   4 files changed, 61 insertions(+), 28 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c
> b/src/gallium/drivers/radeonsi/si_cp_dma.c
> > index 15bd305a350..ea2c7cf7198 100644
> > --- a/src/gallium/drivers/radeonsi/si_cp_dma.c
> > +++ b/src/gallium/drivers/radeonsi/si_cp_dma.c
> > @@ -514,80 +514,98 @@ static void cik_prefetch_shader_async(struct
> si_context *sctx,
> >   static void cik_prefetch_VBO_descriptors(struct si_context *sctx)
> >   {
> >   if (!sctx->vertex_elements)
> >   return;
> >
> >   cik_prefetch_TC_L2_async(sctx, >vb_descriptors_buffer->b.b,
> >sctx->vb_descriptors_offset,
> >
> sctx->vertex_elements->desc_list_byte_size);
> >   }
> >
> > -void cik_emit_prefetch_L2(struct si_context *sctx)
> > +/**
> > + * Prefetch shaders and VBO descriptors.
> > + *
> > + * \param first_two  Whether only the first 2 items should be
> prefetched,
> > + *   which are usually the API VS and VBO descriptors.
> > + */
> > +void cik_emit_prefetch_L2(struct si_context *sctx, bool first_two)
> >   {
> > + unsigned mask;
> > +
> > + assert(sctx->prefetch_L2_mask);
> > +
> > + if (first_two) {
> > + mask = 1 << u_bit_scan16(>prefetch_L2_mask);
> > +
> > + if (sctx->prefetch_L2_mask)
> > + mask |= 1 << u_bit_scan16(>prefetch_L2_mask);
>
> Where do you reset the prefetch L2 mask ? It looks like to me that you
> are going to prefetch VS/VBOs twice in the fast draw path.
>

u_bit_scan16 clears the returned bit.

Marek

> + } else {
> > + mask = sctx->prefetch_L2_mask;
> > + sctx->prefetch_L2_mask = 0;
> > + }
> > +
> >   /* Prefetch shaders and VBO descriptors to TC L2. */
> >   if (sctx->b.chip_class >= GFX9) {
> >   /* Choose the right spot for the VBO prefetch. */
> >   if (sctx->tes_shader.cso) {
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_HS)
> > + if (mask & SI_PREFETCH_HS)
> >   cik_prefetch_shader_async(sctx,
> sctx->queued.named.hs);
> > - if (sctx->prefetch_L2_mask &
> SI_PREFETCH_VBO_DESCRIPTORS)
> > + if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
> >   cik_prefetch_VBO_descriptors(sctx);
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_GS)
> > + if (mask & SI_PREFETCH_GS)
> >   cik_prefetch_shader_async(sctx, sctx->
> queued.named.gs);
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
> > + if (mask & SI_PREFETCH_VS)
> >   cik_prefetch_shader_async(sctx,
> sctx->queued.named.vs);
> >   } else if (sctx->gs_shader.cso) {
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_GS)
> > + if (mask & SI_PREFETCH_GS)
> >   cik_prefetch_shader_async(sctx, sctx->
> queued.named.gs);
> > - if (sctx->prefetch_L2_mask &
> SI_PREFETCH_VBO_DESCRIPTORS)
> > + if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
> >   cik_prefetch_VBO_descriptors(sctx);
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
> > + if (mask & SI_PREFETCH_VS)
> >   cik_prefetch_shader_async(sctx,
> sctx->queued.named.vs);
> >   } else {
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
> > + if (mask & SI_PREFETCH_VS)
> >   cik_prefetch_shader_async(sctx,
> sctx->queued.named.vs);
> > - if (sctx->prefetch_L2_mask &
> SI_PREFETCH_VBO_DESCRIPTORS)
> > + if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
> >   cik_prefetch_VBO_descriptors(sctx);
> >   }
> >   } else {
> >   /* SI-CI-VI */
> >   /* Choose the right spot for the VBO prefetch. */
> >   if (sctx->tes_shader.cso) {
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_LS)
> > + if (mask & SI_PREFETCH_LS)
> >   cik_prefetch_shader_async(sctx, sctx->
> queued.named.ls);
> > - if (sctx->prefetch_L2_mask &
> SI_PREFETCH_VBO_DESCRIPTORS)
> > +

Re: [Mesa-dev] [PATCH 02/17] ac/surface: don't set the display flag for obviously unsupported cases

[Marek Olšák]

On Wed, Apr 4, 2018, 6:18 AM Michel Dänzer  wrote:

> On 2018-04-04 03:59 AM, Marek Olšák wrote:
> > From: Marek Olšák 
> >
> > This enables the tile swizzle for some cases of the displayable micro
> mode,
> > and it also fixes an addrlib assertion failure on Vega.
> > ---
> >  src/amd/common/ac_surface.c | 18 ++
> >  1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> > index b294cd85259..2b20a553d51 100644
> > --- a/src/amd/common/ac_surface.c
> > +++ b/src/amd/common/ac_surface.c
> > @@ -408,20 +408,29 @@ static unsigned cik_get_macro_tile_index(struct
> radeon_surf *surf)
> >   tileb = 8 * 8 * surf->bpe;
> >   tileb = MIN2(surf->u.legacy.tile_split, tileb);
> >
> >   for (index = 0; tileb > 64; index++)
> >   tileb >>= 1;
> >
> >   assert(index < 16);
> >   return index;
> >  }
> >
> > +static bool get_display_flag(const struct ac_surf_config *config,
> > +  const struct radeon_surf *surf)
> > +{
> > + return surf->flags & RADEON_SURF_SCANOUT &&
> > +!(surf->flags & RADEON_SURF_FMASK) &&
> > +config->info.samples <= 1 &&
> > +surf->bpe >= 4 && surf->bpe <= 8;
>
> surf->bpe is the number of bytes used to store each pixel, right? If so,
> this cannot exclude surf->bpe < 4, since 16 bpp and 8 bpp formats can be
> displayed.
>

Sure, but what are the chances they will be displayed with the current
stack? GLX doesn't have 16bpp visuals for on-screen rendering.

Marek


>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of radeonsi NIR

[Benedikt Schemmer]

Hi Timothy,

another game that is behaving strangly is Metro 2033 Redux, also crashes
earlier with apitrace attached. This time TGSI and NIR crash at about
the same time (press any key to continue screen)
Without apitrace TGSI works fine, NIR crashes like above.

==> metronir <==
2059446 glDisableVertexAttribArray(index = 8)
2059447 glDisableVertexAttribArray(index = 9)
2059448 glDisableVertexAttribArray(index = 10)
2059449 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)
2059450 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
blob(352), usage = GL_DYNAMIC_DRAW)
2059451 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 720, type
= GL_UNSIGNED_SHORT, indices = 0x176a6, basevertex = 15823)
2059452 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)
2059453 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
blob(352), usage = GL_DYNAMIC_DRAW)
2059454 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 711, type
= GL_UNSIGNED_SHORT, indices = 0x17c46, basevertex = 16303)
2059455 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)

==> metrotgsi <==
1744537 glEnableVertexAttribArray(index = 4)
1744538 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
stride = 32, pointer = 0x18)
1744539 glVertexAttribDivisor(index = 4, divisor = 0)
1744540 glDisableVertexAttribArray(index = 5)
1744541 glDisableVertexAttribArray(index = 6)
1744542 glDisableVertexAttribArray(index = 7)
1744543 glDisableVertexAttribArray(index = 8)
1744544 glDisableVertexAttribArray(index = 9)
1744545 glDisableVertexAttribArray(index = 10)
1744546 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)

==> metrotgsi2 <==
2141178 glVertexAttribDivisor(index = 1, divisor = 0)
2141179 glEnableVertexAttribArray(index = 2)
2141180 glVertexAttribPointer(index = 2, size = 4, type =
GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x10)
2141181 glVertexAttribDivisor(index = 2, divisor = 0)
2141182 glEnableVertexAttribArray(index = 3)
2141183 glVertexAttribPointer(index = 3, size = 4, type =
GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x14)
2141184 glVertexAttribDivisor(index = 3, divisor = 0)
2141185 glEnableVertexAttribArray(index = 4)
2141186 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
stride = 32, pointer = 0x18)
2141187 glVertexAttribDivisor(index = 4, divisor = 0) // incomplete


Am 04.04.2018 um 14:06 schrieb Timothy Arceri:
> On 04/04/18 21:51, Benedikt Schemmer wrote:
>> Hi Timothy,
>>
>> thanks for looking into this.
>>
>> Dead Island still crashes for me with NIR.
> 
> Just to make sure, are you building a 32bit version of Mesa? If not you
> might be running your system Mesa. If you are definitely building Mesa
> 32bit then I'll take a closer look tomorrow.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of radeonsi NIR

[Benedikt Schemmer]

No I dont.

32-bit is a problem, because Ubuntu wants to literally deinstall itself
before letting me do that (some dependency nonsense).

So I only build 64-bit myself.

For 32-bit & backup 64-bit I use the oibaf ppa which I updated this morning.

I wouldnt spend to much time right now, because mesa git feels a bit
broken. If I switch to stable versions like 17.3.8 most problems
disappear (but so does NIR I guess ;)


Am 04.04.2018 um 14:06 schrieb Timothy Arceri:
> On 04/04/18 21:51, Benedikt Schemmer wrote:
>> Hi Timothy,
>>
>> thanks for looking into this.
>>
>> Dead Island still crashes for me with NIR.
> 
> Just to make sure, are you building a 32bit version of Mesa? If not you
> might be running your system Mesa. If you are definitely building Mesa
> 32bit then I'll take a closer look tomorrow.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev