Re: [Mesa-dev] [PATCH 12/14] mesa/vbo: Move src/mesa/vbo/vbo_exec_array.c -> src/mesa/main/draw.c

[Mathias Fröhlich]

Hi Brian,

On Tuesday, 30 October 2018 13:06:50 CET Brian Paul wrote:
> The series looks great, Mathias.
> 
> Reviewed-by: Brian Paul 

Thanks for that one!

> > @@ -2072,7 +2073,7 @@ vbo_initialize_exec_dispatch(const struct gl_context 
> > *ctx,
> >   void GLAPIENTRY
> >   _mesa_DrawArrays(GLenum mode, GLint first, GLsizei count)
> >   {
> > -   vbo_exec_DrawArrays(mode, first, count);
> > +   _mesa_exec_DrawArrays(mode, first, count);
> >   }
> 
> It would be nice to avoid this pattern of simply calling another 
> function like this.
> 
> The complication, though, is that the _mesa_exec_Draw*() functions get 
> put into the dispatch table, but the _mesa_Draw*() functions are 
> decorated with GLAPIENTRY since they're Windows dll export functions.
> 
> We'd have to decorate some entries in the dispatch table with 
> GLAPIENTRY, but that could involve some messy python script work.

Looking at that, at least both functions _mesa_DrawArrays and
vbo_exec_DrawArrays/_mesa_exec_DrawArrays have the GLAPIENTRY.
It's probably the pattern for all of these.

May be I don't quite understand, but to me that looks just like a naming
issue that got solved at one point by calling one function from an other?
And don't all dispatch table functions have the GLAPIENTRY as well as
the GLvertexformat functions?

> What do you think?
Now confused ...

I think it's just a level of indirection that was introduced for a reason
that went away at one point in the past. May be the reason was just the naming
that the vbo module used to have these vbo_ prefixes that are changed by this
patch?

... I still suspect that I have missed something obvious from your question - 
sorry.

best

Mathias


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

Re: [Mesa-dev] [PATCH] glsl/linker: Fix out variables linking during single stage

[Tapani Pälli]

On 10/31/18 12:57 AM, Timothy Arceri wrote:

On 30/10/18 10:14 pm, Tapani Pälli wrote:

Hi;

On 10/30/18 1:28 AM, Timothy Arceri wrote:

On 29/10/18 10:05 pm, Vadim Shovkoplias wrote:

Hi Timothy,

Thanks for the review. Piglit patch is updated with the additional 
out var: https://patchwork.freedesktop.org/patch/258899/
Original reporter confirmed that issue is finally fixed with the 
current patch and closed it.


Can I ask to push the patch please ?


I've pushed both. Thanks for the patches!


Unfortunately it seems this patch introduced regression in Intel CI, 
I'm getting following failures after this commit (7d66eddbbde):


piglit.spec.glsl-1_30.execution.tex-miplevel-selection 
texturelodoffset 2dshadow.snbm64
piglit.spec.glsl-1_30.execution.tex-miplevel-selection texturelod 
2dshadow.snbm64
piglit.spec.glsl-1_30.execution.tex-miplevel-selection texturelod 
cube.snbm64

generated.gpu-hang-otc-gfxtest-snbgt2-02.snbm64


I don't have a Sandy Bridge to test with but its really strange that 
this would break only one generation of hardware. Are you sure it was 
this patch?


Well .. not 100% sure but it looks like previous commit won't show these 
fails, it is strange. I'll do some runs today and try to figure it out.








Regards,
Vadym

сб, 27 окт. 2018 г. в 1:21, Timothy Arceri >:


    On Wed, Oct 24, 2018, at 3:28 AM, Vadym Shovkoplias wrote:
 > Since out variables are copied from shader objects instruction
 > streams to linked shader instruction steam it should be cloned
 > at first to keep source instruction steam unaltered.
 >
 > Fixes: 966a797e433 glsl/linker: Link all out vars from a shader
 > objects on a single stage
 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105731
 > Signed-off-by: Vadym Shovkoplias
    mailto:vadym.shovkopl...@globallogic.com>>

    Reviewed-by: Timothy Arceri mailto:tarc...@itsqueeze.com>>

    Also please either update the existing piglit or add a new one to
    better cover the use of the freed vars. From the bug report it 
seems

    adding another out var is enough to do it. Thanks.

 > ---
 >  src/compiler/glsl/linker.cpp | 3 ++-
 >  1 file changed, 2 insertions(+), 1 deletion(-)
 >
 > diff --git a/src/compiler/glsl/linker.cpp
    b/src/compiler/glsl/linker.cpp
 > index 7db34ebf95..8b1b03322a 100644
 > --- a/src/compiler/glsl/linker.cpp
 > +++ b/src/compiler/glsl/linker.cpp
 > @@ -2269,10 +2269,11 @@ link_output_variables(struct
    gl_linked_shader
 > *linked_shader,
 >           if (ir->ir_type != ir_type_variable)
 >              continue;
 >
 > -         ir_variable *const var = (ir_variable *) ir;
 > +         ir_variable *var = (ir_variable *) ir;
 >
 >           if (var->data.mode == ir_var_shader_out &&
 >                 !symbols->get_variable(var->name)) {
 > +            var = var->clone(linked_shader, NULL);
 >              symbols->add_variable(var);
 >              linked_shader->ir->push_head(var);
 >           }
 > --
 > 2.18.0
 >


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

Re: [Mesa-dev] [PATCH 09/14] vbo: Make no_current_update an argument to vbo_save_NotifyBegin.

[Mathias Fröhlich]

Good Morning,

On Tuesday, 30 October 2018 13:24:50 CET Eric Engestrom wrote:
> > @@ -1294,7 +1294,7 @@ static void GLAPIENTRY
> >  _save_OBE_Rectf(GLfloat x1, GLfloat y1, GLfloat x2, GLfloat y2)
> >  {
> > GET_CURRENT_CONTEXT(ctx);
> > -   vbo_save_NotifyBegin(ctx, GL_QUADS);
> > +   vbo_save_NotifyBegin(ctx, GL_QUADS, true);
> 
> I won't pretend to understand any of this code, but logic-wise I think
> this should be `false`, not `true`.
> If the change was on purpose, maybe it belongs in a separate patch with
> an explanation?

Good catch! That was actually not intended!
I have changed that locally to false!

Thanks
Mathias


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

[Mesa-dev] [Bug 108508] Graphic glitches with stream output support on OLAND AMD GPU GCN 1.0

[bugzilla-daemon]

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

--- Comment #16 from Vladimir  ---
renderdoccmd wine game.exe crashing too?

-- 
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/2] radeonsi: use better DCC clear codes

[Dieter Nützel]

Tested-by: Dieter Nützel 

I only have Polaris 20...;-)

Am 30.10.2018 21:03, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_clear.c | 26 -
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_clear.c
b/src/gallium/drivers/radeonsi/si_clear.c
index 8aa3355afc8..2900c31fd21 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -27,20 +27,29 @@

 #include "util/u_format.h"
 #include "util/u_pack_color.h"
 #include "util/u_surface.h"

 enum {
SI_CLEAR = SI_SAVE_FRAGMENT_STATE,
SI_CLEAR_SURFACE = SI_SAVE_FRAMEBUFFER | SI_SAVE_FRAGMENT_STATE,
 };

+enum si_dcc_clear_code
+{
+DCC_CLEAR_COLOR_ = 0x,
+DCC_CLEAR_COLOR_0001 = 0x40404040,
+DCC_CLEAR_COLOR_1110 = 0x80808080,
+DCC_CLEAR_COLOR_ = 0xC0C0C0C0,
+DCC_CLEAR_COLOR_REG  = 0x20202020,
+};
+
 static void si_alloc_separate_cmask(struct si_screen *sscreen,
struct si_texture *tex)
 {
if (tex->cmask_buffer || !tex->surface.cmask_size)
 return;

tex->cmask_buffer =
si_aligned_buffer_create(>b,
 SI_RESOURCE_FLAG_UNMAPPABLE,
 PIPE_USAGE_DEFAULT,
@@ -126,21 +135,21 @@ static bool vi_get_fast_clear_parameters(enum
pipe_format base_format,
const struct util_format_description *desc =
util_format_description(si_simplify_cb_format(surface_format));

/* 128-bit fast clear with different R,G,B values is unsupported. */
if (desc->block.bits == 128 &&
(color->ui[0] != color->ui[1] ||
 color->ui[0] != color->ui[2]))
return false;

*eliminate_needed = true;
-   *clear_value = 0x20202020U; /* use CB clear color registers */
+   *clear_value = DCC_CLEAR_COLOR_REG;

if (desc->layout != UTIL_FORMAT_LAYOUT_PLAIN)
return true; /* need ELIMINATE_FAST_CLEAR */

bool base_alpha_is_on_msb = vi_alpha_is_on_msb(base_format);
bool surf_alpha_is_on_msb = vi_alpha_is_on_msb(surface_format);

/* Formats with 3 channels can't have alpha. */
if (desc->nr_channels == 3)
alpha_channel = -1;
@@ -201,24 +210,31 @@ static bool vi_get_fast_clear_parameters(enum
pipe_format base_format,
values[i] != color_value)
return true; /* require ELIMINATE_FAST_CLEAR */
}

/* This doesn't need ELIMINATE_FAST_CLEAR.
 * CB uses both the DCC clear codes and the CB clear color registers,
 * so they must match.
 */
*eliminate_needed = false;

-   if (color_value)
-   *clear_value |= 0x80808080U;
-   if (alpha_value)
-   *clear_value |= 0x40404040U;
+   if (color_value) {
+   if (alpha_value)
+   *clear_value = DCC_CLEAR_COLOR_;
+   else
+   *clear_value = DCC_CLEAR_COLOR_1110;
+   } else {
+   if (alpha_value)
+   *clear_value = DCC_CLEAR_COLOR_0001;
+   else
+   *clear_value = DCC_CLEAR_COLOR_;
+   }
return true;
 }

 void vi_dcc_clear_level(struct si_context *sctx,
struct si_texture *tex,
unsigned level, unsigned clear_value)
 {
struct pipe_resource *dcc_buffer;
uint64_t dcc_offset, clear_size;

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

[Mesa-dev] [PATCH] radv/xfb: don't increase offset by component mask start.

[Dave Airlie]

From: Dave Airlie 

This is incorrect, the offset is into the buffer, and it's legal
to write

loc 0,0 -> buffer0, offset 0
loc 0,1 -> buffer1, offset 0

This fixes a bunch of piglits running on my zink xfb code on
radv.

Fixes: 6c21645046 (radv: emit stream outputs for vertex and tessellation stages)
---
 src/amd/vulkan/radv_nir_to_llvm.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index 5ea1755b2a6..f56eb01dc52 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -2512,9 +2512,6 @@ radv_emit_stream_output(struct radv_shader_context *ctx,
/* Get the first component. */
start = ffs(output->component_mask) - 1;
 
-   /* Adjust the destination offset. */
-   offset += start * 4;
-
/* Load the output as int. */
for (int i = 0; i < num_comps; i++) {
out[i] = ac_to_integer(>ac,
-- 
2.17.2

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

Re: [Mesa-dev] [PATCH 07/31] nir/opt_if: Rework condition propagation

[Timothy Arceri]

On 31/10/18 1:23 am, Jason Ekstrand wrote:
Weird.  I didn't expect this patch to have any impact whatsoever. I 
thought it was just moving around the way we emit stuff.


I think I've spotted the problem. Iago does patch 1 help with the 
regressions you are seeing.


https://patchwork.freedesktop.org/series/51789/



On October 30, 2018 08:40:01 Iago Toral  wrote:


Jason, JFYI, I have been looking into the cases where the boolean
bitsize lowering pass was producing worse instruction counts that the
default 32-bit pass and I have tracked it down to this patch. Reverting
this makes the instruction count much better for some tests, I'll check
why this happens tomorrow.

Iago

On Mon, 2018-10-22 at 17:13 -0500, Jason Ekstrand wrote:

Instead of doing our own constant folding, we just emit instructions
and
let constant folding happen.  This is substantially simpler and lets
us
use the nir_imm_bool helper instead of dealing with the const_value's
ourselves.
---
 src/compiler/nir/nir_opt_if.c | 91 -
--
 1 file changed, 30 insertions(+), 61 deletions(-)

diff --git a/src/compiler/nir/nir_opt_if.c
b/src/compiler/nir/nir_opt_if.c
index 0c94aa170b5..60368a0259e 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -377,31 +377,15 @@ opt_if_loop_terminator(nir_if *nif)
    return true;
 }

-static void
-replace_if_condition_use_with_const(nir_builder *b, nir_src *use,
-    nir_const_value nir_boolean,
-    bool if_condition)
-{
-   /* Create const */
-   nir_ssa_def *const_def = nir_build_imm(b, 1, 32, nir_boolean);
-
-   /* Rewrite use to use const */
-   nir_src new_src = nir_src_for_ssa(const_def);
-   if (if_condition)
-  nir_if_rewrite_condition(use->parent_if, new_src);
-   else
-  nir_instr_rewrite_src(use->parent_instr, use, new_src);
-}
-
 static bool
-evaluate_if_condition(nir_if *nif, nir_cursor cursor, uint32_t
*value)
+evaluate_if_condition(nir_if *nif, nir_cursor cursor, bool *value)
 {
    nir_block *use_block = nir_cursor_current_block(cursor);
    if (nir_block_dominates(nir_if_first_then_block(nif), use_block))
{
-  *value = NIR_TRUE;
+  *value = true;
   return true;
    } else if (nir_block_dominates(nir_if_first_else_block(nif),
use_block)) {
-  *value = NIR_FALSE;
+  *value = false;
   return true;
    } else {
   return false;
@@ -460,52 +444,31 @@ propagate_condition_eval(nir_builder *b, nir_if
*nif, nir_src *use_src,
  nir_src *alu_use, nir_alu_instr *alu,
  bool is_if_condition)
 {
-   bool progress = false;
+   bool bool_value;
+   if (!evaluate_if_condition(nif, b->cursor, _value))
+  return false;

-   nir_const_value bool_value;
    b->cursor = nir_before_src(alu_use, is_if_condition);
-   if (nir_op_infos[alu->op].num_inputs == 1) {
-  assert(alu->op == nir_op_inot || alu->op == nir_op_b2i);
-
-  if (evaluate_if_condition(nif, b->cursor, _value.u32[0]))
{
- assert(nir_src_bit_size(alu->src[0].src) == 32);
-
- nir_const_value result =
-    nir_eval_const_opcode(alu->op, 1, 32, _value);

- replace_if_condition_use_with_const(b, alu_use, result,
- is_if_condition);
- progress = true;
+   nir_ssa_def *def[2] = { };
+   for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
+  if (alu->src[i].src.ssa == use_src->ssa) {
+ def[i] = nir_imm_bool(b, bool_value);
+  } else {
+ def[i] = alu->src[i].src.ssa;
   }
-   } else {
-  assert(alu->op == nir_op_ior || alu->op == nir_op_iand);
-
-  if (evaluate_if_condition(nif, b->cursor, _value.u32[0]))
{
- nir_ssa_def *def[2];
- for (unsigned i = 0; i < 2; i++) {
-    if (alu->src[i].src.ssa == use_src->ssa) {
-   def[i] = nir_build_imm(b, 1, 32, bool_value);
-    } else {
-   def[i] = alu->src[i].src.ssa;
-    }
- }
-
- nir_ssa_def *nalu =
-    nir_build_alu(b, alu->op, def[0], def[1], NULL, NULL);
-
- /* Rewrite use to use new alu instruction */
- nir_src new_src = nir_src_for_ssa(nalu);
+   }
+   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1],
NULL, NULL);

- if (is_if_condition)
-    nir_if_rewrite_condition(alu_use->parent_if, new_src);
- else
-    nir_instr_rewrite_src(alu_use->parent_instr, alu_use,
new_src);
+   /* Rewrite use to use new alu instruction */
+   nir_src new_src = nir_src_for_ssa(nalu);

- progress = true;
-  }
-   }
+   if (is_if_condition)
+  nir_if_rewrite_condition(alu_use->parent_if, new_src);
+   else
+  nir_instr_rewrite_src(alu_use->parent_instr, alu_use,
new_src);

-   return progress;
+   return true;
 }

 static bool
@@ -527,11 +490,17 @@ evaluate_condition_use(nir_builder *b, nir_if
*nif, nir_src *use_src,
 

[Mesa-dev] [PATCH 1/2] nir: fix if condition propagation for alu use

[Timothy Arceri]

From: Timothy Arceri 

We need to update the cursor before we check if the alu use is
dominated by the if condition. Previously we were checking if
the current location of the alu instruction was dominated by
the if condition which would miss some optimisation opportunities.

Fixes: a3b4cb34589e ("nir/opt_if: Rework condition propagation")
---
 src/compiler/nir/nir_opt_if.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 1f2e1f21130..1fe95e53766 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -444,11 +444,10 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
  bool is_if_condition)
 {
bool bool_value;
+   b->cursor = nir_before_src(alu_use, is_if_condition);
if (!evaluate_if_condition(nif, b->cursor, _value))
   return false;
 
-   b->cursor = nir_before_src(alu_use, is_if_condition);
-
nir_ssa_def *def[2] = {0};
for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
   if (alu->src[i].src.ssa == use_src->ssa) {
-- 
2.17.2

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

[Mesa-dev] [PATCH 2/2] nir: allow propagation of if evaluation to all alu instructions

[Timothy Arceri]

With the simplifications to this pass in a3b4cb34589e2f1a68 we
can allow any alu instruction to be processed. For one this can
potentially help with bcsels.

No shader-db change.
---
 src/compiler/nir/nir_opt_if.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 1fe95e53766..38489676e6b 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -448,7 +448,7 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
if (!evaluate_if_condition(nif, b->cursor, _value))
   return false;
 
-   nir_ssa_def *def[2] = {0};
+   nir_ssa_def *def[4] = {0};
for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
   if (alu->src[i].src.ssa == use_src->ssa) {
  def[i] = nir_imm_bool(b, bool_value);
@@ -456,7 +456,7 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
  def[i] = alu->src[i].src.ssa;
   }
}
-   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], NULL, NULL);
+   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], def[2], 
def[3]);
 
/* Rewrite use to use new alu instruction */
nir_src new_src = nir_src_for_ssa(nalu);
@@ -469,19 +469,6 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
return true;
 }
 
-static bool
-can_propagate_through_alu(nir_src *src)
-{
-   if (src->parent_instr->type == nir_instr_type_alu &&
-   (nir_instr_as_alu(src->parent_instr)->op == nir_op_ior ||
-nir_instr_as_alu(src->parent_instr)->op == nir_op_iand ||
-nir_instr_as_alu(src->parent_instr)->op == nir_op_inot ||
-nir_instr_as_alu(src->parent_instr)->op == nir_op_b2i))
-  return true;
-
-   return false;
-}
-
 static bool
 evaluate_condition_use(nir_builder *b, nir_if *nif, nir_src *use_src,
bool is_if_condition)
@@ -502,7 +489,8 @@ evaluate_condition_use(nir_builder *b, nir_if *nif, nir_src 
*use_src,
   progress = true;
}
 
-   if (!is_if_condition && can_propagate_through_alu(use_src)) {
+   if (!is_if_condition &&
+   use_src->parent_instr->type == nir_instr_type_alu) {
   nir_alu_instr *alu = nir_instr_as_alu(use_src->parent_instr);
 
   nir_foreach_use_safe(alu_use, >dest.dest.ssa) {
-- 
2.17.2

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

Re: [Mesa-dev] [PATCH] gallium/util: don't let children of fork & exec inherit our thread affinity

[Gustaw Smolarczyk]

śr., 31 paź 2018 o 00:23 Marek Olšák  napisał(a):
>
> On Tue, Oct 30, 2018 at 7:11 PM Gustaw Smolarczyk  
> wrote:
>>
>> wt., 30 paź 2018 o 23:55 Marek Olšák  napisał(a):
>> >
>> > On Tue, Oct 30, 2018 at 6:32 PM Gustaw Smolarczyk  
>> > wrote:
>> >>
>> >> wt., 30 paź 2018, 23:01 Marek Olšák :
>> >>>
>> >>> On Mon, Oct 29, 2018 at 12:43 PM Michel Dänzer  
>> >>> wrote:
>> 
>>  On 2018-10-28 11:27 a.m., Gustaw Smolarczyk wrote:
>>  > pon., 17 wrz 2018 o 18:24 Michel Dänzer  
>>  > napisał(a):
>>  >>
>>  >> On 2018-09-15 3:04 a.m., Marek Olšák wrote:
>>  >>> On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer  
>>  >>> wrote:
>>  
>>   Last but not least, this doesn't solve the issue of apps such as
>>   blender, which spawn their own worker threads after initializing 
>>   OpenGL
>>   (possibly not themselves directly, but via the toolkit or another
>>   library; e.g. GTK+4 uses OpenGL by default), inheriting the thread 
>>   affinity.
>>  
>>  
>>   Due to these issues, setting the thread affinity needs to be 
>>   disabled by
>>   default, and only white-listed for applications where it's known 
>>   safe
>>   and beneficial. This sucks, but I'm afraid that's the reality until
>>   there's better API available which allows solving these issues.
>>  >>>
>>  >>> We don't have the bandwidth to maintain whitelists. This will either
>>  >>> have to be always on or always off.
>>  >>>
>>  >>> On the positive side, only Ryzens with multiple CCXs get all the
>>  >>> benefits and disadvantages.
>>  >>
>>  >> In other words, only people who spent relatively large amounts of 
>>  >> money
>>  >> for relatively high-end CPUs will be affected (I'm sure they'll be 
>>  >> glad
>>  >> to know that "common people" aren't affected. ;). Affected 
>>  >> applications
>>  >> will see their performance decreased by a factor of 2-8 (the number 
>>  >> of
>>  >> CCXs in the CPU).
>>  >>
>>  >> OTOH, only a relatively small number of games will get a significant
>>  >> benefit from the thread affinity, and the benefit will be smaller 
>>  >> than a
>>  >> factor of 2. This cannot justify risking a performance drop of up to 
>>  >> a
>>  >> factor of 8, no matter how small the risk.
>>  >>
>>  >> Therefore, the appropriate mechanism is a whitelist.
>>  >
>>  > Hi,
>>  >
>>  > What was the conclusion of this discussion? I don't see any
>>  > whitelist/blacklist for this feature.
>>  >
>>  > I have just tested blender and it still renders on only a single CCX
>>  > on mesa from git master. Also, there is a bug report that suggests
>>  > this regressed performance in at least one game [1].
>> 
>>  I hooked up that bug report to the 18.3 blocker bug.
>> 
>> 
>>  > If you think enabling it by default is the way to go, we should also
>>  > implement a blacklist so that it can be turned off in such cases.
>> 
>>  I stand by my opinion that a white-list is appropriate, not a
>>  black-list. It's pretty much the same as mesa_glthread.
>> >>>
>> >>>
>> >>> So you are saying that gallium multithreading show be slower than 
>> >>> singlethreading by default.
>> >>>
>> >>> Marek
>> >>
>> >>
>> >> Hi Marek,
>> >>
>> >> The Ryzen optimization helps a lot of applications (mostly games) and 
>> >> improves their performance, mostly because of the reduced cost of 
>> >> communication between application's GL API thread and driver's 
>> >> pipe/winsys threads.
>> >>
>> >> However, not all of the applications respond in the same way. The thread 
>> >> affinity management is hacky, by which I mean that this mechanism was not 
>> >> meant to mess with application threads from within library's threads. As 
>> >> an example, blender's threads, which use OpenGL "by accident", are forced 
>> >> to use the same CCX as the main gallium/winsys thread, even if they are 
>> >> many and want to work on as many CCXs as are possible. The thread that 
>> >> starts using GL spawns many more threads that don't use GL at all, and 
>> >> the current atfork mechanism doesn't help.
>> >>
>> >> The current mechanism of tweaking thread affinities doesn't work 
>> >> universally with all Linux applications. We need a mechanism of tweaking 
>> >> this behavior, either through a whitelist or through a blacklist. As any 
>> >> application using OpenGL can be affected, I would opt towards disabling 
>> >> this by default and providing a whitelist for applications we know it 
>> >> would help.
>> >
>> >
>> > Multithreading is slower than singlethreading. You are pretty much saying 
>> > that Mesa shouldn't use multithreading by default. Just think about that. 
>> > NVIDIA would destroy us at all price points. I'm not that insane to 
>> > disable the thread pinning 

Re: [Mesa-dev] [PATCH RFC] egl: Add a 565 pbuffer-only EGL config under X11.

[Eric Anholt]

Eric Anholt  writes:

> The CTS requires a 565-no-depth-no-stencil config for ES 3.0, but at depth
> 24 of X11 we wouldn't do so.  We can satisfy that bad requirement using a
> pbuffer-only visual with whatever other buffers the driver happens to have
> given us.

Anyone?  Still concerned about getting Mesa to pass the current
conformance suite.


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

Re: [Mesa-dev] [PATCH] intel/compiler: Stop assuming the entrypoint is called "main"

[Kenneth Graunke]

On Tuesday, October 30, 2018 9:26:29 AM PDT Jason Ekstrand wrote:
> This isn't true for Vulkan so we have to whack it to "main" in anv which
> is silly.  Instead of walking the list of functions and asserting that
> everything is named "main" and hoping there's only one function named
> "main", just use the nir_shader_get_entrypoint() helper which has better
> assertions anyway.
> ---
>  src/intel/compiler/brw_fs_nir.cpp   | 17 -
>  src/intel/compiler/brw_vec4_nir.cpp |  7 +--
>  src/intel/vulkan/anv_pipeline.c |  1 -
>  3 files changed, 5 insertions(+), 20 deletions(-)

Reviewed-by: Kenneth Graunke 


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 3/3] i965/gen9: Add workarounds for object preemption.

[Kenneth Graunke]

On Monday, October 29, 2018 10:19:54 AM PDT Rafael Antognolli wrote:
> Gen9 hardware requires some workarounds to disable preemption depending
> on the type of primitive being emitted.
> 
> We implement this by adding a new atom that tracks BRW_NEW_PRIMITIVE.
> Whenever it happens, we check the current type of primitive and
> enable/disable object preemption.
> 
> For now, we just ignore blorp.  The only primitive it emits is
> 3DPRIM_RECTLIST, and since it's not listed in the workarounds, we can
> safely leave preemption enabled when it happens. Or it will be disabled
> by a previous 3DPRIMITIVE, which should be fine too.
> 
> Signed-off-by: Rafael Antognolli 
> Cc: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 47 +++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index 740cb0c4d2e..3a01bab1ae1 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -5563,6 +5563,50 @@ static const struct brw_tracked_state 
> genX(blend_constant_color) = {
>  
>  /* -- */
>  
> +#if GEN_GEN == 9
> +
> +/**

 * Enable or disable preemption based on the current primitive type.
 * (This should only be necessary on Gen9 hardware, not Gen10+.)
 *

> + * Implement workarounds for preemption:
> + *- WaDisableMidObjectPreemptionForGSLineStripAdj
> + *- WaDisableMidObjectPreemptionForTrifanOrPolygon
> + */
> +static void
> +gen9_emit_preempt_wa(struct brw_context *brw)
> +{

I think this might be a bit easier to follow as

   bool object_preemption = true;

   if (brw->primitive == _3DPRIM_LINESTRIP_ADJ && brw->gs.enabled)
  object_preemption = false;

   if (brw->primitive == _3DPRIM_TRIFAN)
  object_preemption = false;

   brw_enable_obj_preemption(brw, object_preemption);

(with the comments of course.)

Do we need any stalling when whacking CS_CHICKEN1...?

Looking through the workarounds list, I believe that we also need to
disable mid-object preemption for _3DPRIM_LINELOOP (Gen9 WA #0816).

We may need to disable it if instance_count > 0 in the 3DPRIMITIVE
(Gen9 WA #0798).

We may also need to disable autostripping by whacking some chicken
registers if it's enabled (Gen9 WA #0799).  Which would be lame,
because that's likely a useful optimization.  I guess we could disable
preemption for TRILIST and LINELIST as well to be safe.

And GPGPU preemption looks like a mile long list of workarounds,
so let's not try it on Gen9.

> +   /* WaDisableMidObjectPreemptionForGSLineStripAdj
> +*
> +*WA: Disable mid-draw preemption when draw-call is a linestrip_adj 
> and
> +*GS is enabled.
> +*/
> +   bool object_preemption =
> +  !(brw->primitive == _3DPRIM_LINESTRIP_ADJ && brw->gs.enabled);
> +
> +   /* WaDisableMidObjectPreemptionForTrifanOrPolygon
> +*
> +*TriFan miscompare in Execlist Preemption test. Cut index that is on 
> a
> +*previous context. End the previous, the resume another context with 
> a
> +*tri-fan or polygon, and the vertex count is corrupted. If we prempt
> +*again we will cause corruption.
> +*
> +*WA: Disable mid-draw preemption when draw-call has a tri-fan.
> +*/
> +   object_preemption =
> +  object_preemption && !(brw->primitive == _3DPRIM_TRIFAN);
> +
> +   brw_enable_obj_preemption(brw, object_preemption);
> +}
> +
> +static const struct brw_tracked_state gen9_preempt_wa = {
> +   .dirty = {
> +  .mesa = 0,
> +  .brw = BRW_NEW_PRIMITIVE | BRW_NEW_GEOMETRY_PROGRAM,
> +   },
> +   .emit = gen9_emit_preempt_wa,
> +};
> +#endif
> +
> +/* -- */
> +
>  void
>  genX(init_atoms)(struct brw_context *brw)
>  {
> @@ -5867,6 +5911,9 @@ genX(init_atoms)(struct brw_context *brw)
>  
>(cut_index),
>_pma_fix,
> +#if GEN_GEN == 9
> +  _preempt_wa,
> +#endif
> };
>  #endif
>  
> 



signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 0/3] Add object level preemption to i965.

[Kenneth Graunke]

On Monday, October 29, 2018 10:19:51 AM PDT Rafael Antognolli wrote:
> Re-sending the series, this time adding preemption support only to i965,
> since We still don't have vulkan tests for this.
> 
> The proposed piglit test for this series can be found here:
> https://gitlab.freedesktop.org/rantogno/piglit/commits/review/context_preemption_v2
> 
> Cc: Kenneth Graunke 
> 
> Rafael Antognolli (3):
>   intel/genxml: Add register for object preemption.
>   i965/gen10+: Enable object level preemption.
>   i965/gen9: Add workarounds for object preemption.
> 
>  src/intel/genxml/gen10.xml|  8 
>  src/intel/genxml/gen11.xml|  8 
>  src/intel/genxml/gen9.xml |  8 
>  src/mesa/drivers/dri/i965/brw_context.h   |  2 +
>  src/mesa/drivers/dri/i965/brw_defines.h   |  5 ++
>  src/mesa/drivers/dri/i965/brw_state.h |  3 +-
>  src/mesa/drivers/dri/i965/brw_state_upload.c  | 25 ++
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 47 +++
>  8 files changed, 105 insertions(+), 1 deletion(-)
> 
> 

Patches 1-2 are:
Reviewed-by: Kenneth Graunke 

I sent some comments on patch 3.


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: don't let children of fork & exec inherit our thread affinity

[Marek Olšák]

On Tue, Oct 30, 2018 at 7:11 PM Gustaw Smolarczyk 
wrote:

> wt., 30 paź 2018 o 23:55 Marek Olšák  napisał(a):
> >
> > On Tue, Oct 30, 2018 at 6:32 PM Gustaw Smolarczyk 
> wrote:
> >>
> >> wt., 30 paź 2018, 23:01 Marek Olšák :
> >>>
> >>> On Mon, Oct 29, 2018 at 12:43 PM Michel Dänzer 
> wrote:
> 
>  On 2018-10-28 11:27 a.m., Gustaw Smolarczyk wrote:
>  > pon., 17 wrz 2018 o 18:24 Michel Dänzer 
> napisał(a):
>  >>
>  >> On 2018-09-15 3:04 a.m., Marek Olšák wrote:
>  >>> On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer <
> mic...@daenzer.net> wrote:
>  
>   Last but not least, this doesn't solve the issue of apps such as
>   blender, which spawn their own worker threads after initializing
> OpenGL
>   (possibly not themselves directly, but via the toolkit or another
>   library; e.g. GTK+4 uses OpenGL by default), inheriting the
> thread affinity.
>  
>  
>   Due to these issues, setting the thread affinity needs to be
> disabled by
>   default, and only white-listed for applications where it's known
> safe
>   and beneficial. This sucks, but I'm afraid that's the reality
> until
>   there's better API available which allows solving these issues.
>  >>>
>  >>> We don't have the bandwidth to maintain whitelists. This will
> either
>  >>> have to be always on or always off.
>  >>>
>  >>> On the positive side, only Ryzens with multiple CCXs get all the
>  >>> benefits and disadvantages.
>  >>
>  >> In other words, only people who spent relatively large amounts of
> money
>  >> for relatively high-end CPUs will be affected (I'm sure they'll be
> glad
>  >> to know that "common people" aren't affected. ;). Affected
> applications
>  >> will see their performance decreased by a factor of 2-8 (the
> number of
>  >> CCXs in the CPU).
>  >>
>  >> OTOH, only a relatively small number of games will get a
> significant
>  >> benefit from the thread affinity, and the benefit will be smaller
> than a
>  >> factor of 2. This cannot justify risking a performance drop of up
> to a
>  >> factor of 8, no matter how small the risk.
>  >>
>  >> Therefore, the appropriate mechanism is a whitelist.
>  >
>  > Hi,
>  >
>  > What was the conclusion of this discussion? I don't see any
>  > whitelist/blacklist for this feature.
>  >
>  > I have just tested blender and it still renders on only a single CCX
>  > on mesa from git master. Also, there is a bug report that suggests
>  > this regressed performance in at least one game [1].
> 
>  I hooked up that bug report to the 18.3 blocker bug.
> 
> 
>  > If you think enabling it by default is the way to go, we should also
>  > implement a blacklist so that it can be turned off in such cases.
> 
>  I stand by my opinion that a white-list is appropriate, not a
>  black-list. It's pretty much the same as mesa_glthread.
> >>>
> >>>
> >>> So you are saying that gallium multithreading show be slower than
> singlethreading by default.
> >>>
> >>> Marek
> >>
> >>
> >> Hi Marek,
> >>
> >> The Ryzen optimization helps a lot of applications (mostly games) and
> improves their performance, mostly because of the reduced cost of
> communication between application's GL API thread and driver's pipe/winsys
> threads.
> >>
> >> However, not all of the applications respond in the same way. The
> thread affinity management is hacky, by which I mean that this mechanism
> was not meant to mess with application threads from within library's
> threads. As an example, blender's threads, which use OpenGL "by accident",
> are forced to use the same CCX as the main gallium/winsys thread, even if
> they are many and want to work on as many CCXs as are possible. The thread
> that starts using GL spawns many more threads that don't use GL at all, and
> the current atfork mechanism doesn't help.
> >>
> >> The current mechanism of tweaking thread affinities doesn't work
> universally with all Linux applications. We need a mechanism of tweaking
> this behavior, either through a whitelist or through a blacklist. As any
> application using OpenGL can be affected, I would opt towards disabling
> this by default and providing a whitelist for applications we know it would
> help.
> >
> >
> > Multithreading is slower than singlethreading. You are pretty much
> saying that Mesa shouldn't use multithreading by default. Just think about
> that. NVIDIA would destroy us at all price points. I'm not that insane to
> disable the thread pinning by default.
>
> I have no idea what you are saying. The current implementation of
> multithreading doesn't work well with all applications on Ryzen, due
> to kernel scheduling application and gallium/winsys threads on
> different CCXs. However, thread pinning is not a universal solution
> for this problem. We can't express what we want at 

Re: [Mesa-dev] [PATCH] gallium/util: don't let children of fork & exec inherit our thread affinity

[Roland Scheidegger]

Am 30.10.18 um 23:55 schrieb Marek Olšák:
> On Tue, Oct 30, 2018 at 6:32 PM Gustaw Smolarczyk  > wrote:
> 
> wt., 30 paź 2018, 23:01 Marek Olšák  >:
> 
> On Mon, Oct 29, 2018 at 12:43 PM Michel Dänzer
> mailto:mic...@daenzer.net>> wrote:
> 
> On 2018-10-28 11:27 a.m., Gustaw Smolarczyk wrote:
> > pon., 17 wrz 2018 o 18:24 Michel Dänzer
> mailto:mic...@daenzer.net>> napisał(a):
> >>
> >> On 2018-09-15 3:04 a.m., Marek Olšák wrote:
> >>> On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer
> mailto:mic...@daenzer.net>> wrote:
> 
>  Last but not least, this doesn't solve the issue of
> apps such as
>  blender, which spawn their own worker threads after
> initializing OpenGL
>  (possibly not themselves directly, but via the toolkit
> or another
>  library; e.g. GTK+4 uses OpenGL by default), inheriting
> the thread affinity.
> 
> 
>  Due to these issues, setting the thread affinity needs
> to be disabled by
>  default, and only white-listed for applications where
> it's known safe
>  and beneficial. This sucks, but I'm afraid that's the
> reality until
>  there's better API available which allows solving these
> issues.
> >>>
> >>> We don't have the bandwidth to maintain whitelists. This
> will either
> >>> have to be always on or always off.
> >>>
> >>> On the positive side, only Ryzens with multiple CCXs get
> all the
> >>> benefits and disadvantages.
> >>
> >> In other words, only people who spent relatively large
> amounts of money
> >> for relatively high-end CPUs will be affected (I'm sure
> they'll be glad
> >> to know that "common people" aren't affected. ;).
> Affected applications
> >> will see their performance decreased by a factor of 2-8
> (the number of
> >> CCXs in the CPU).
> >>
> >> OTOH, only a relatively small number of games will get a
> significant
> >> benefit from the thread affinity, and the benefit will be
> smaller than a
> >> factor of 2. This cannot justify risking a performance
> drop of up to a
> >> factor of 8, no matter how small the risk.
> >>
> >> Therefore, the appropriate mechanism is a whitelist.
> >
> > Hi,
> >
> > What was the conclusion of this discussion? I don't see any
> > whitelist/blacklist for this feature.
> >
> > I have just tested blender and it still renders on only a
> single CCX
> > on mesa from git master. Also, there is a bug report that
> suggests
> > this regressed performance in at least one game [1].
> 
> I hooked up that bug report to the 18.3 blocker bug.
> 
> 
> > If you think enabling it by default is the way to go, we
> should also
> > implement a blacklist so that it can be turned off in such
> cases.
> 
> I stand by my opinion that a white-list is appropriate, not a
> black-list. It's pretty much the same as mesa_glthread.
> 
> 
> So you are saying that gallium multithreading show be slower
> than singlethreading by default.
> 
> Marek
> 
> 
> Hi Marek,
> 
> The Ryzen optimization helps a lot of applications (mostly games)
> and improves their performance, mostly because of the reduced cost
> of communication between application's GL API thread and driver's
> pipe/winsys threads.
> 
> However, not all of the applications respond in the same way. The
> thread affinity management is hacky, by which I mean that this
> mechanism was not meant to mess with application threads from within
> library's threads. As an example, blender's threads, which use
> OpenGL "by accident", are forced to use the same CCX as the main
> gallium/winsys thread, even if they are many and want to work on as
> many CCXs as are possible. The thread that starts using GL spawns
> many more threads that don't use GL at all, and the current atfork
> mechanism doesn't help.
> 
> The current mechanism of tweaking thread affinities doesn't work
> universally with all Linux applications. We need a mechanism of
> tweaking this behavior, either through a whitelist or through a
> blacklist. As any application using OpenGL can be 

Re: [Mesa-dev] [PATCH] gallium/util: don't let children of fork & exec inherit our thread affinity

[Gustaw Smolarczyk]

wt., 30 paź 2018 o 23:55 Marek Olšák  napisał(a):
>
> On Tue, Oct 30, 2018 at 6:32 PM Gustaw Smolarczyk  
> wrote:
>>
>> wt., 30 paź 2018, 23:01 Marek Olšák :
>>>
>>> On Mon, Oct 29, 2018 at 12:43 PM Michel Dänzer  wrote:

 On 2018-10-28 11:27 a.m., Gustaw Smolarczyk wrote:
 > pon., 17 wrz 2018 o 18:24 Michel Dänzer  napisał(a):
 >>
 >> On 2018-09-15 3:04 a.m., Marek Olšák wrote:
 >>> On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer  
 >>> wrote:
 
  Last but not least, this doesn't solve the issue of apps such as
  blender, which spawn their own worker threads after initializing 
  OpenGL
  (possibly not themselves directly, but via the toolkit or another
  library; e.g. GTK+4 uses OpenGL by default), inheriting the thread 
  affinity.
 
 
  Due to these issues, setting the thread affinity needs to be disabled 
  by
  default, and only white-listed for applications where it's known safe
  and beneficial. This sucks, but I'm afraid that's the reality until
  there's better API available which allows solving these issues.
 >>>
 >>> We don't have the bandwidth to maintain whitelists. This will either
 >>> have to be always on or always off.
 >>>
 >>> On the positive side, only Ryzens with multiple CCXs get all the
 >>> benefits and disadvantages.
 >>
 >> In other words, only people who spent relatively large amounts of money
 >> for relatively high-end CPUs will be affected (I'm sure they'll be glad
 >> to know that "common people" aren't affected. ;). Affected applications
 >> will see their performance decreased by a factor of 2-8 (the number of
 >> CCXs in the CPU).
 >>
 >> OTOH, only a relatively small number of games will get a significant
 >> benefit from the thread affinity, and the benefit will be smaller than a
 >> factor of 2. This cannot justify risking a performance drop of up to a
 >> factor of 8, no matter how small the risk.
 >>
 >> Therefore, the appropriate mechanism is a whitelist.
 >
 > Hi,
 >
 > What was the conclusion of this discussion? I don't see any
 > whitelist/blacklist for this feature.
 >
 > I have just tested blender and it still renders on only a single CCX
 > on mesa from git master. Also, there is a bug report that suggests
 > this regressed performance in at least one game [1].

 I hooked up that bug report to the 18.3 blocker bug.


 > If you think enabling it by default is the way to go, we should also
 > implement a blacklist so that it can be turned off in such cases.

 I stand by my opinion that a white-list is appropriate, not a
 black-list. It's pretty much the same as mesa_glthread.
>>>
>>>
>>> So you are saying that gallium multithreading show be slower than 
>>> singlethreading by default.
>>>
>>> Marek
>>
>>
>> Hi Marek,
>>
>> The Ryzen optimization helps a lot of applications (mostly games) and 
>> improves their performance, mostly because of the reduced cost of 
>> communication between application's GL API thread and driver's pipe/winsys 
>> threads.
>>
>> However, not all of the applications respond in the same way. The thread 
>> affinity management is hacky, by which I mean that this mechanism was not 
>> meant to mess with application threads from within library's threads. As an 
>> example, blender's threads, which use OpenGL "by accident", are forced to 
>> use the same CCX as the main gallium/winsys thread, even if they are many 
>> and want to work on as many CCXs as are possible. The thread that starts 
>> using GL spawns many more threads that don't use GL at all, and the current 
>> atfork mechanism doesn't help.
>>
>> The current mechanism of tweaking thread affinities doesn't work universally 
>> with all Linux applications. We need a mechanism of tweaking this behavior, 
>> either through a whitelist or through a blacklist. As any application using 
>> OpenGL can be affected, I would opt towards disabling this by default and 
>> providing a whitelist for applications we know it would help.
>
>
> Multithreading is slower than singlethreading. You are pretty much saying 
> that Mesa shouldn't use multithreading by default. Just think about that. 
> NVIDIA would destroy us at all price points. I'm not that insane to disable 
> the thread pinning by default.

I have no idea what you are saying. The current implementation of
multithreading doesn't work well with all applications on Ryzen, due
to kernel scheduling application and gallium/winsys threads on
different CCXs. However, thread pinning is not a universal solution
for this problem. We can't express what we want at the moment (i.e.
schedule a couple of threads next to each other, regardless of where
they really are) and the current work-around of using thread
affinities hurts reals applications (like Blender).

>

Re: [Mesa-dev] [PATCH 1/4] radv/winsys: remove unused surface_best()

[Dave Airlie]

For the series:

Reviewed-by: Dave Airlie 
On Tue, 30 Oct 2018 at 20:39, Samuel Pitoiset  wrote:
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_radeon_winsys.h| 3 ---
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c | 7 ---
>  2 files changed, 10 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_radeon_winsys.h 
> b/src/amd/vulkan/radv_radeon_winsys.h
> index 526661754f..7977d46229 100644
> --- a/src/amd/vulkan/radv_radeon_winsys.h
> +++ b/src/amd/vulkan/radv_radeon_winsys.h
> @@ -268,9 +268,6 @@ struct radeon_winsys {
> const struct ac_surf_info *surf_info,
> struct radeon_surf *surf);
>
> -   int (*surface_best)(struct radeon_winsys *ws,
> -   struct radeon_surf *surf);
> -
> struct radeon_winsys_fence *(*create_fence)();
> void (*destroy_fence)(struct radeon_winsys_fence *fence);
> bool (*fence_wait)(struct radeon_winsys *ws,
> diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c 
> b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c
> index e3ccb812a7..875ac70de1 100644
> --- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c
> +++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c
> @@ -97,14 +97,7 @@ static int radv_amdgpu_winsys_surface_init(struct 
> radeon_winsys *_ws,
> return ac_compute_surface(ws->addrlib, >info, , mode, 
> surf);
>  }
>
> -static int radv_amdgpu_winsys_surface_best(struct radeon_winsys *rws,
> -  struct radeon_surf *surf)
> -{
> -   return 0;
> -}
> -
>  void radv_amdgpu_surface_init_functions(struct radv_amdgpu_winsys *ws)
>  {
> ws->base.surface_init = radv_amdgpu_winsys_surface_init;
> -   ws->base.surface_best = radv_amdgpu_winsys_surface_best;
>  }
> --
> 2.19.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] radv: rename some parameters in Cmd{Begin, End}TransformFeedbackEXT()

[Dave Airlie]

Reviewed-by: Dave Airlie 
On Tue, 30 Oct 2018 at 19:08, Samuel Pitoiset  wrote:
>
> To match latest spec.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 63a1fd6dff..c43e12f6d6 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -4732,8 +4732,8 @@ static void radv_flush_vgt_streamout(struct 
> radv_cmd_buffer *cmd_buffer)
>
>  void radv_CmdBeginTransformFeedbackEXT(
>  VkCommandBuffer commandBuffer,
> -uint32_tfirstBuffer,
> -uint32_tbufferCount,
> +uint32_tfirstCounterBuffer,
> +uint32_tcounterBufferCount,
>  const VkBuffer* pCounterBuffers,
>  const VkDeviceSize* pCounterBufferOffsets)
>  {
> @@ -4744,8 +4744,8 @@ void radv_CmdBeginTransformFeedbackEXT(
>
> radv_flush_vgt_streamout(cmd_buffer);
>
> -   assert(firstBuffer + bufferCount <= MAX_SO_BUFFERS);
> -   for (uint32_t i = firstBuffer; i < bufferCount; i++) {
> +   assert(firstCounterBuffer + counterBufferCount <= MAX_SO_BUFFERS);
> +   for (uint32_t i = firstCounterBuffer; i < counterBufferCount; i++) {
> if (!(so->enabled_mask & (1 << i)))
> continue;
>
> @@ -4793,8 +4793,8 @@ void radv_CmdBeginTransformFeedbackEXT(
>
>  void radv_CmdEndTransformFeedbackEXT(
>  VkCommandBuffer commandBuffer,
> -uint32_tfirstBuffer,
> -uint32_tbufferCount,
> +uint32_tfirstCounterBuffer,
> +uint32_tcounterBufferCount,
>  const VkBuffer* pCounterBuffers,
>  const VkDeviceSize* pCounterBufferOffsets)
>  {
> @@ -4804,8 +4804,8 @@ void radv_CmdEndTransformFeedbackEXT(
>
> radv_flush_vgt_streamout(cmd_buffer);
>
> -   assert(firstBuffer + bufferCount <= MAX_SO_BUFFERS);
> -   for (uint32_t i = firstBuffer; i < bufferCount; i++) {
> +   assert(firstCounterBuffer + counterBufferCount <= MAX_SO_BUFFERS);
> +   for (uint32_t i = firstCounterBuffer; i < counterBufferCount; i++) {
> if (!(so->enabled_mask & (1 << i)))
> continue;
>
> --
> 2.19.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] radv: use pool->stride when calling radv_query_shader()

[Dave Airlie]

Reviewed-by: Dave Airlie 
On Wed, 31 Oct 2018 at 00:19, Samuel Pitoiset  wrote:
>
> Not needed to recompute the stride.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_query.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 5a326c9df54..318d6c7afee 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -1050,7 +1050,7 @@ void radv_CmdCopyQueryPoolResults(
> radv_query_shader(cmd_buffer, 
> _buffer->device->meta_state.query.occlusion_query_pipeline,
>   pool->bo, dst_buffer->bo, firstQuery * 
> pool->stride,
>   dst_buffer->offset + dstOffset,
> - get_max_db(cmd_buffer->device) * 16, stride,
> + pool->stride, stride,
>   queryCount, flags, 0, 0);
> break;
> case VK_QUERY_TYPE_PIPELINE_STATISTICS:
> @@ -1069,7 +1069,7 @@ void radv_CmdCopyQueryPoolResults(
> radv_query_shader(cmd_buffer, 
> _buffer->device->meta_state.query.pipeline_statistics_query_pipeline,
>   pool->bo, dst_buffer->bo, firstQuery * 
> pool->stride,
>   dst_buffer->offset + dstOffset,
> - pipelinestat_block_size * 2, stride, 
> queryCount, flags,
> + pool->stride, stride, queryCount, flags,
>   pool->pipeline_stats_mask,
>   pool->availability_offset + 4 * firstQuery);
> break;
> --
> 2.19.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] radv: use WAIT_REG_MEM_GREATER_OR_EQUAL instead of a magic value

[Dave Airlie]

Reviewed-by: Dave Airlie 
On Tue, 30 Oct 2018 at 21:27, Samuel Pitoiset  wrote:
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/sid.h| 1 +
>  src/amd/vulkan/radv_query.c | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
> index d88ecf5580..5c53133147 100644
> --- a/src/amd/common/sid.h
> +++ b/src/amd/common/sid.h
> @@ -146,6 +146,7 @@
>  #define PKT3_WAIT_REG_MEM  0x3C
>  #defineWAIT_REG_MEM_EQUAL  3
>  #defineWAIT_REG_MEM_NOT_EQUAL  4
> +#defineWAIT_REG_MEM_GREATER_OR_EQUAL   5
>  #define WAIT_REG_MEM_MEM_SPACE(x)   (((unsigned)(x) & 0x3) << 4)
>  #define WAIT_REG_MEM_PFP   (1 << 8)
>  #define PKT3_MEM_WRITE 0x3D /* not on CIK */
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 5a326c9df5..d61a272a74 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -1039,7 +1039,7 @@ void radv_CmdCopyQueryPoolResults(
>
> /* Waits on the upper word of the last DB 
> entry */
> radeon_emit(cs, PKT3(PKT3_WAIT_REG_MEM, 5, 
> 0));
> -   radeon_emit(cs, 5 | 
> WAIT_REG_MEM_MEM_SPACE(1));
> +   radeon_emit(cs, WAIT_REG_MEM_GREATER_OR_EQUAL 
> | WAIT_REG_MEM_MEM_SPACE(1));
> radeon_emit(cs, src_va);
> radeon_emit(cs, src_va >> 32);
> radeon_emit(cs, 0x8000); /* reference 
> value */
> --
> 2.19.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] glsl/linker: Fix out variables linking during single stage

[Timothy Arceri]

On 30/10/18 10:14 pm, Tapani Pälli wrote:

Hi;

On 10/30/18 1:28 AM, Timothy Arceri wrote:

On 29/10/18 10:05 pm, Vadim Shovkoplias wrote:

Hi Timothy,

Thanks for the review. Piglit patch is updated with the additional 
out var: https://patchwork.freedesktop.org/patch/258899/
Original reporter confirmed that issue is finally fixed with the 
current patch and closed it.


Can I ask to push the patch please ?


I've pushed both. Thanks for the patches!


Unfortunately it seems this patch introduced regression in Intel CI, I'm 
getting following failures after this commit (7d66eddbbde):


piglit.spec.glsl-1_30.execution.tex-miplevel-selection texturelodoffset 
2dshadow.snbm64
piglit.spec.glsl-1_30.execution.tex-miplevel-selection texturelod 
2dshadow.snbm64
piglit.spec.glsl-1_30.execution.tex-miplevel-selection texturelod 
cube.snbm64

generated.gpu-hang-otc-gfxtest-snbgt2-02.snbm64


I don't have a Sandy Bridge to test with but its really strange that 
this would break only one generation of hardware. Are you sure it was 
this patch?







Regards,
Vadym

сб, 27 окт. 2018 г. в 1:21, Timothy Arceri >:


    On Wed, Oct 24, 2018, at 3:28 AM, Vadym Shovkoplias wrote:
 > Since out variables are copied from shader objects instruction
 > streams to linked shader instruction steam it should be cloned
 > at first to keep source instruction steam unaltered.
 >
 > Fixes: 966a797e433 glsl/linker: Link all out vars from a shader
 > objects on a single stage
 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105731
 > Signed-off-by: Vadym Shovkoplias
    mailto:vadym.shovkopl...@globallogic.com>>

    Reviewed-by: Timothy Arceri mailto:tarc...@itsqueeze.com>>

    Also please either update the existing piglit or add a new one to
    better cover the use of the freed vars. From the bug report it seems
    adding another out var is enough to do it. Thanks.

 > ---
 >  src/compiler/glsl/linker.cpp | 3 ++-
 >  1 file changed, 2 insertions(+), 1 deletion(-)
 >
 > diff --git a/src/compiler/glsl/linker.cpp
    b/src/compiler/glsl/linker.cpp
 > index 7db34ebf95..8b1b03322a 100644
 > --- a/src/compiler/glsl/linker.cpp
 > +++ b/src/compiler/glsl/linker.cpp
 > @@ -2269,10 +2269,11 @@ link_output_variables(struct
    gl_linked_shader
 > *linked_shader,
 >           if (ir->ir_type != ir_type_variable)
 >              continue;
 >
 > -         ir_variable *const var = (ir_variable *) ir;
 > +         ir_variable *var = (ir_variable *) ir;
 >
 >           if (var->data.mode == ir_var_shader_out &&
 >                 !symbols->get_variable(var->name)) {
 > +            var = var->clone(linked_shader, NULL);
 >              symbols->add_variable(var);
 >              linked_shader->ir->push_head(var);
 >           }
 > --
 > 2.18.0
 >


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

Re: [Mesa-dev] [PATCH] gallium/util: don't let children of fork & exec inherit our thread affinity

[Marek Olšák]

On Tue, Oct 30, 2018 at 6:32 PM Gustaw Smolarczyk 
wrote:

> wt., 30 paź 2018, 23:01 Marek Olšák :
>
>> On Mon, Oct 29, 2018 at 12:43 PM Michel Dänzer 
>> wrote:
>>
>>> On 2018-10-28 11:27 a.m., Gustaw Smolarczyk wrote:
>>> > pon., 17 wrz 2018 o 18:24 Michel Dänzer 
>>> napisał(a):
>>> >>
>>> >> On 2018-09-15 3:04 a.m., Marek Olšák wrote:
>>> >>> On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer 
>>> wrote:
>>> 
>>>  Last but not least, this doesn't solve the issue of apps such as
>>>  blender, which spawn their own worker threads after initializing
>>> OpenGL
>>>  (possibly not themselves directly, but via the toolkit or another
>>>  library; e.g. GTK+4 uses OpenGL by default), inheriting the thread
>>> affinity.
>>> 
>>> 
>>>  Due to these issues, setting the thread affinity needs to be
>>> disabled by
>>>  default, and only white-listed for applications where it's known
>>> safe
>>>  and beneficial. This sucks, but I'm afraid that's the reality until
>>>  there's better API available which allows solving these issues.
>>> >>>
>>> >>> We don't have the bandwidth to maintain whitelists. This will either
>>> >>> have to be always on or always off.
>>> >>>
>>> >>> On the positive side, only Ryzens with multiple CCXs get all the
>>> >>> benefits and disadvantages.
>>> >>
>>> >> In other words, only people who spent relatively large amounts of
>>> money
>>> >> for relatively high-end CPUs will be affected (I'm sure they'll be
>>> glad
>>> >> to know that "common people" aren't affected. ;). Affected
>>> applications
>>> >> will see their performance decreased by a factor of 2-8 (the number of
>>> >> CCXs in the CPU).
>>> >>
>>> >> OTOH, only a relatively small number of games will get a significant
>>> >> benefit from the thread affinity, and the benefit will be smaller
>>> than a
>>> >> factor of 2. This cannot justify risking a performance drop of up to a
>>> >> factor of 8, no matter how small the risk.
>>> >>
>>> >> Therefore, the appropriate mechanism is a whitelist.
>>> >
>>> > Hi,
>>> >
>>> > What was the conclusion of this discussion? I don't see any
>>> > whitelist/blacklist for this feature.
>>> >
>>> > I have just tested blender and it still renders on only a single CCX
>>> > on mesa from git master. Also, there is a bug report that suggests
>>> > this regressed performance in at least one game [1].
>>>
>>> I hooked up that bug report to the 18.3 blocker bug.
>>>
>>>
>>> > If you think enabling it by default is the way to go, we should also
>>> > implement a blacklist so that it can be turned off in such cases.
>>>
>>> I stand by my opinion that a white-list is appropriate, not a
>>> black-list. It's pretty much the same as mesa_glthread.
>>>
>>
>> So you are saying that gallium multithreading show be slower than
>> singlethreading by default.
>>
>> Marek
>>
>
> Hi Marek,
>
> The Ryzen optimization helps a lot of applications (mostly games) and
> improves their performance, mostly because of the reduced cost of
> communication between application's GL API thread and driver's pipe/winsys
> threads.
>
> However, not all of the applications respond in the same way. The thread
> affinity management is hacky, by which I mean that this mechanism was not
> meant to mess with application threads from within library's threads. As an
> example, blender's threads, which use OpenGL "by accident", are forced to
> use the same CCX as the main gallium/winsys thread, even if they are many
> and want to work on as many CCXs as are possible. The thread that starts
> using GL spawns many more threads that don't use GL at all, and the current
> atfork mechanism doesn't help.
>
> The current mechanism of tweaking thread affinities doesn't work
> universally with all Linux applications. We need a mechanism of tweaking
> this behavior, either through a whitelist or through a blacklist. As any
> application using OpenGL can be affected, I would opt towards disabling
> this by default and providing a whitelist for applications we know it would
> help.
>

Multithreading is slower than singlethreading. You are pretty much saying
that Mesa shouldn't use multithreading by default. Just think about that.
NVIDIA would destroy us at all price points. I'm not that insane to disable
the thread pinning by default.

The thread affinity API is very bad for this, but it's the only thing we
have. Linux lacks a proper thread management API for the Zen architecture
and the Linux scheduler does the worst thing for Ryzen (it puts threads on
different CCXs), so the scheduler always works against us. It makes Ryzen
as slow as possible.

Only Blender is affected negatively and there is a patch for it. Blender is
open source, so it can just reset the thread affinity for new threads by
itself, or set a thread affinity that works best with Ryzen. Mesa can
contain the workaround out of courtesy.

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

[Mesa-dev] [PATCH] st/mesa: don't do L3 thread pinning for Blender

[Marek Olšák]

From: Marek Olšák 

so that all Blender threads are not forced to be on 1 CCX.

Fixes: 8d473f555a0
---
 src/gallium/auxiliary/pipe-loader/driinfo_gallium.h | 1 +
 src/gallium/include/state_tracker/st_api.h  | 1 +
 src/gallium/state_trackers/dri/dri_screen.c | 2 ++
 src/mesa/state_tracker/st_context.c | 1 +
 src/mesa/state_tracker/st_context.h | 1 +
 src/mesa/state_tracker/st_manager.c | 8 +---
 src/util/00-mesa-defaults.conf  | 4 
 src/util/xmlpool/t_options.h| 5 +
 8 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h 
b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
index 9db0dc01117..daa7ce7f6cc 100644
--- a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
+++ b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
@@ -24,17 +24,18 @@ DRI_CONF_SECTION_DEBUG
DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
DRI_CONF_ALLOW_GLSL_BUILTIN_CONST_EXPRESSION("false")
DRI_CONF_ALLOW_GLSL_RELAXED_ES("false")
DRI_CONF_ALLOW_GLSL_BUILTIN_VARIABLE_REDECLARATION("false")
DRI_CONF_ALLOW_GLSL_CROSS_STAGE_INTERPOLATION_MISMATCH("false")
DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION("false")
DRI_CONF_FORCE_GLSL_ABS_SQRT("false")
DRI_CONF_GLSL_CORRECT_DERIVATIVES_AFTER_DISCARD("false")
DRI_CONF_ALLOW_GLSL_LAYOUT_QUALIFIER_ON_FUNCTION_PARAMETERS("false")
DRI_CONF_FORCE_COMPAT_PROFILE("false")
+   DRI_CONF_DISABLE_L3_THREAD_PINNING("false")
 DRI_CONF_SECTION_END
 
 DRI_CONF_SECTION_MISCELLANEOUS
DRI_CONF_ALWAYS_HAVE_DEPTH_BUFFER("false")
DRI_CONF_GLSL_ZERO_INIT("false")
DRI_CONF_ALLOW_RGB10_CONFIGS("true")
 DRI_CONF_SECTION_END
diff --git a/src/gallium/include/state_tracker/st_api.h 
b/src/gallium/include/state_tracker/st_api.h
index 2b63b8a3d2a..26b52f8dc51 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -224,20 +224,21 @@ struct st_config_options
unsigned force_glsl_version;
boolean allow_glsl_extension_directive_midshader;
boolean allow_glsl_builtin_const_expression;
boolean allow_glsl_relaxed_es;
boolean allow_glsl_builtin_variable_redeclaration;
boolean allow_higher_compat_version;
boolean glsl_zero_init;
boolean force_glsl_abs_sqrt;
boolean allow_glsl_cross_stage_interpolation_mismatch;
boolean allow_glsl_layout_qualifier_on_function_parameters;
+   boolean disable_L3_thread_pinning;
unsigned char config_options_sha1[20];
 };
 
 /**
  * Represent the attributes of a context.
  */
 struct st_context_attribs
 {
/**
 * The profile and minimal version to support.
diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index 82a0988a634..b8bd92475cb 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -80,20 +80,22 @@ dri_fill_st_options(struct dri_screen *screen)
   driQueryOptionb(optionCache, 
"allow_glsl_builtin_variable_redeclaration");
options->allow_higher_compat_version =
   driQueryOptionb(optionCache, "allow_higher_compat_version");
options->glsl_zero_init = driQueryOptionb(optionCache, "glsl_zero_init");
options->force_glsl_abs_sqrt =
   driQueryOptionb(optionCache, "force_glsl_abs_sqrt");
options->allow_glsl_cross_stage_interpolation_mismatch =
   driQueryOptionb(optionCache, 
"allow_glsl_cross_stage_interpolation_mismatch");
options->allow_glsl_layout_qualifier_on_function_parameters =
   driQueryOptionb(optionCache, 
"allow_glsl_layout_qualifier_on_function_parameters");
+   options->disable_L3_thread_pinning =
+  driQueryOptionb(optionCache, "disable_L3_thread_pinning");
 
driComputeOptionsSha1(optionCache, options->config_options_sha1);
 }
 
 static unsigned
 dri_loader_get_cap(struct dri_screen *screen, enum dri_loader_cap cap)
 {
const __DRIdri2LoaderExtension *dri2_loader = screen->sPriv->dri2.loader;
const __DRIimageLoaderExtension *image_loader = screen->sPriv->image.loader;
 
diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index 354876746f4..4b19b140bcd 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -460,20 +460,21 @@ st_create_context_priv(struct gl_context *ctx, struct 
pipe_context *pipe,
   screen->get_param(screen, PIPE_CAP_QUERY_TIME_ELAPSED);
st->has_half_float_packing =
   screen->get_param(screen, PIPE_CAP_TGSI_PACK_HALF_FLOAT);
st->has_multi_draw_indirect =
   screen->get_param(screen, PIPE_CAP_MULTI_DRAW_INDIRECT);
 
st->has_hw_atomics =
   screen->get_shader_param(screen, PIPE_SHADER_FRAGMENT,
PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS)
   ? true : false;
+   st->disable_L3_thread_pinning = options->disable_L3_thread_pinning;
 

Re: [Mesa-dev] [PATCH] gallium/util: don't let children of fork & exec inherit our thread affinity

[Gustaw Smolarczyk]

wt., 30 paź 2018, 23:01 Marek Olšák :

> On Mon, Oct 29, 2018 at 12:43 PM Michel Dänzer  wrote:
>
>> On 2018-10-28 11:27 a.m., Gustaw Smolarczyk wrote:
>> > pon., 17 wrz 2018 o 18:24 Michel Dänzer 
>> napisał(a):
>> >>
>> >> On 2018-09-15 3:04 a.m., Marek Olšák wrote:
>> >>> On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer 
>> wrote:
>> 
>>  Last but not least, this doesn't solve the issue of apps such as
>>  blender, which spawn their own worker threads after initializing
>> OpenGL
>>  (possibly not themselves directly, but via the toolkit or another
>>  library; e.g. GTK+4 uses OpenGL by default), inheriting the thread
>> affinity.
>> 
>> 
>>  Due to these issues, setting the thread affinity needs to be
>> disabled by
>>  default, and only white-listed for applications where it's known safe
>>  and beneficial. This sucks, but I'm afraid that's the reality until
>>  there's better API available which allows solving these issues.
>> >>>
>> >>> We don't have the bandwidth to maintain whitelists. This will either
>> >>> have to be always on or always off.
>> >>>
>> >>> On the positive side, only Ryzens with multiple CCXs get all the
>> >>> benefits and disadvantages.
>> >>
>> >> In other words, only people who spent relatively large amounts of money
>> >> for relatively high-end CPUs will be affected (I'm sure they'll be glad
>> >> to know that "common people" aren't affected. ;). Affected applications
>> >> will see their performance decreased by a factor of 2-8 (the number of
>> >> CCXs in the CPU).
>> >>
>> >> OTOH, only a relatively small number of games will get a significant
>> >> benefit from the thread affinity, and the benefit will be smaller than
>> a
>> >> factor of 2. This cannot justify risking a performance drop of up to a
>> >> factor of 8, no matter how small the risk.
>> >>
>> >> Therefore, the appropriate mechanism is a whitelist.
>> >
>> > Hi,
>> >
>> > What was the conclusion of this discussion? I don't see any
>> > whitelist/blacklist for this feature.
>> >
>> > I have just tested blender and it still renders on only a single CCX
>> > on mesa from git master. Also, there is a bug report that suggests
>> > this regressed performance in at least one game [1].
>>
>> I hooked up that bug report to the 18.3 blocker bug.
>>
>>
>> > If you think enabling it by default is the way to go, we should also
>> > implement a blacklist so that it can be turned off in such cases.
>>
>> I stand by my opinion that a white-list is appropriate, not a
>> black-list. It's pretty much the same as mesa_glthread.
>>
>
> So you are saying that gallium multithreading show be slower than
> singlethreading by default.
>
> Marek
>

Hi Marek,

The Ryzen optimization helps a lot of applications (mostly games) and
improves their performance, mostly because of the reduced cost of
communication between application's GL API thread and driver's pipe/winsys
threads.

However, not all of the applications respond in the same way. The thread
affinity management is hacky, by which I mean that this mechanism was not
meant to mess with application threads from within library's threads. As an
example, blender's threads, which use OpenGL "by accident", are forced to
use the same CCX as the main gallium/winsys thread, even if they are many
and want to work on as many CCXs as are possible. The thread that starts
using GL spawns many more threads that don't use GL at all, and the current
atfork mechanism doesn't help.

The current mechanism of tweaking thread affinities doesn't work
universally with all Linux applications. We need a mechanism of tweaking
this behavior, either through a whitelist or through a blacklist. As any
application using OpenGL can be affected, I would opt towards disabling
this by default and providing a whitelist for applications we know it would
help.

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

[Mesa-dev] [Bug 107870] Undefined symbols for architecture x86_64: "_util_cpu_caps"

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #5 from Dylan Baker  ---
This time for sure!

-- 
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 108530] [Tracker] Mesa 18.3 Release Tracker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108530
Bug 108530 depends on bug 107870, which changed state.

Bug 107870 Summary: Undefined symbols for architecture x86_64: "_util_cpu_caps"
https://bugs.freedesktop.org/show_bug.cgi?id=107870

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

-- 
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] gallium/util: don't let children of fork & exec inherit our thread affinity

[Marek Olšák]

On Mon, Oct 29, 2018 at 12:43 PM Michel Dänzer  wrote:

> On 2018-10-28 11:27 a.m., Gustaw Smolarczyk wrote:
> > pon., 17 wrz 2018 o 18:24 Michel Dänzer  napisał(a):
> >>
> >> On 2018-09-15 3:04 a.m., Marek Olšák wrote:
> >>> On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer 
> wrote:
> 
>  Last but not least, this doesn't solve the issue of apps such as
>  blender, which spawn their own worker threads after initializing
> OpenGL
>  (possibly not themselves directly, but via the toolkit or another
>  library; e.g. GTK+4 uses OpenGL by default), inheriting the thread
> affinity.
> 
> 
>  Due to these issues, setting the thread affinity needs to be disabled
> by
>  default, and only white-listed for applications where it's known safe
>  and beneficial. This sucks, but I'm afraid that's the reality until
>  there's better API available which allows solving these issues.
> >>>
> >>> We don't have the bandwidth to maintain whitelists. This will either
> >>> have to be always on or always off.
> >>>
> >>> On the positive side, only Ryzens with multiple CCXs get all the
> >>> benefits and disadvantages.
> >>
> >> In other words, only people who spent relatively large amounts of money
> >> for relatively high-end CPUs will be affected (I'm sure they'll be glad
> >> to know that "common people" aren't affected. ;). Affected applications
> >> will see their performance decreased by a factor of 2-8 (the number of
> >> CCXs in the CPU).
> >>
> >> OTOH, only a relatively small number of games will get a significant
> >> benefit from the thread affinity, and the benefit will be smaller than a
> >> factor of 2. This cannot justify risking a performance drop of up to a
> >> factor of 8, no matter how small the risk.
> >>
> >> Therefore, the appropriate mechanism is a whitelist.
> >
> > Hi,
> >
> > What was the conclusion of this discussion? I don't see any
> > whitelist/blacklist for this feature.
> >
> > I have just tested blender and it still renders on only a single CCX
> > on mesa from git master. Also, there is a bug report that suggests
> > this regressed performance in at least one game [1].
>
> I hooked up that bug report to the 18.3 blocker bug.
>
>
> > If you think enabling it by default is the way to go, we should also
> > implement a blacklist so that it can be turned off in such cases.
>
> I stand by my opinion that a white-list is appropriate, not a
> black-list. It's pretty much the same as mesa_glthread.
>

So you are saying that gallium multithreading show be slower than
singlethreading by default.

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

[Mesa-dev] [PATCH] android: radv: add libmesa_git_sha1 static dependency

[Mauro Rossi]

libmesa_git_sha1 whole static dependency is added to get git_sha1.h header
and avoid following building error:

external/mesa/src/amd/vulkan/radv_device.c:46:10:
fatal error: 'git_sha1.h' file not found
 ^
1 error generated.

Fixes: 9d40ec2cf6 ("radv: Add support for VK_KHR_driver_properties.")
Signed-off-by: Mauro Rossi 
---
 src/amd/vulkan/Android.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
index 51b03561fa..9574bf54e5 100644
--- a/src/amd/vulkan/Android.mk
+++ b/src/amd/vulkan/Android.mk
@@ -74,7 +74,8 @@ LOCAL_C_INCLUDES := \
$(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util
 
 LOCAL_WHOLE_STATIC_LIBRARIES := \
-   libmesa_vulkan_util
+   libmesa_vulkan_util \
+   libmesa_git_sha1
 
 LOCAL_GENERATED_SOURCES += $(intermediates)/radv_entrypoints.c
 LOCAL_GENERATED_SOURCES += $(intermediates)/radv_entrypoints.h
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH mesa] tools/imgui: disable all warnings

[Lionel Landwerlin]

Yep :

Reviewed-by: Lionel Landwerlin 

On 30/10/2018 19:02, Eric Engestrom wrote:

This is an external project we have no control over, and will not be
fixing (other than by sometimes pulling the latest sources), so warnings
serve no purpose here.

Signed-off-by: Eric Engestrom 
---
  src/intel/tools/imgui/meson.build | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/tools/imgui/meson.build 
b/src/intel/tools/imgui/meson.build
index 8d6f37d4b3a160f0b3e5..bbc5101abade72519a5a 100644
--- a/src/intel/tools/imgui/meson.build
+++ b/src/intel/tools/imgui/meson.build
@@ -13,7 +13,7 @@ libintel_imgui_gtk = static_library(
'intel_imgui_gtk',
files('imgui_impl_gtk3.cpp', 'imgui_impl_opengl3.cpp'),
dependencies : libintel_imgui_gtk_deps,
-  cpp_args : ['-Wno-deprecated-declarations', '-Wno-parentheses'],
+  cpp_args : ['-w'],
install: false
  )
  



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

Re: [Mesa-dev] [PATCH 11/11] util: move u_cpu_detect to util

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Mon, Oct 29, 2018 at 4:52 PM Dylan Baker  wrote:

> Quoting Brian Paul (2018-10-29 12:24:13)
> > On 10/29/2018 12:57 PM, Dylan Baker wrote:
> > > CC: v...@freedesktop.org
> > > CC: Roland Scheidegger 
> > > Bugzilla:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D107870data=02%7C01%7Cbrianp%40vmware.com%7Cc877b18570db4c38c0dc08d63dd09044%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636764363328904415sdata=ZHwiXmydLEpHfNFcQ2O5%2BbatXTk5zZAHLoGGolwiijw%3Dreserved=0
> > > Fixes: 80825abb5d1a7491035880253ffd531c55acae6b
> > > ("move u_math to src/util")
> > > ---
> > >
> > > Roland, you noticed that the previous attempt to fix this issue broke
> windows.
> > > I've run scons with mingw cross compilation on Linux, but if you could
> test that
> > > this doesn't break the build on windows I'd appreciate it.
> >
> > I just applied the series to my tree and it seems to build and run fine
> > (with softpipe).
> >
> > Tested-by: Brian Paul 
> >
> > -Brian
>
> Thank you!
> ___
> 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 v4 2/3] mesa/st: enable EXT_sRGB_write_control for Gallium drivers that support it

[Ilia Mirkin]

On Tue, Oct 30, 2018 at 4:45 PM Marek Olšák  wrote:
>
> On Tue, Oct 23, 2018 at 1:30 PM Gert Wollny  wrote:
>>
>> From: Gert Wollny 
>>
>> With this patch the extension EXT_sRGB_write_control is enabled for
>> gallium drivers that support sRGB formats as render targets.
>>
>> Tested (and pass) on r600 (evergreen) and softpipe:
>>
>>   dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*
>>
>> with "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check for this), 
>> and
>>
>>   
>> dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported_enum
>>
>> when extension is manually disabled via MESA_EXTENSION_OVERRIDE
>>
>> v2: - always enable the extension when sRGB is supported (Ilia Mirkin).
>> - Correct handling by moving extension initialization to the
>>   place where gallium/st actually takes care of this. This also
>>   fixes properly disabling the extension via MESA_EXTENSION_OVERRIDE
>> - reinstate check for desktop GL and add check for the extension
>>   when creating the framebuffer
>>
>> v3: - Only create sRGB renderbuffers based on Visual.srgbCapable when
>>   on desktop GL.
>>
>> v4: - Use PIPE_FORMAT_B8G8R8A8_SRGB to check for the capability, since this
>>   is also the format that is used top check for EGL_KHR_gl_colorspace
>>   support.  virgl on a GLES host usually doesn't provide this format but
>>   one can make it available to signal that the host supports this
>>   extension.
>>
>> Signed-off-by: Gert Wollny 
>> ---
>>  src/gallium/docs/source/screen.rst |  3 +++
>>  src/mesa/state_tracker/st_extensions.c |  8 +-
>>  src/mesa/state_tracker/st_manager.c| 37 --
>>  3 files changed, 33 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/gallium/docs/source/screen.rst 
>> b/src/gallium/docs/source/screen.rst
>> index 0abd164494..da677eb04b 100644
>> --- a/src/gallium/docs/source/screen.rst
>> +++ b/src/gallium/docs/source/screen.rst
>> @@ -477,6 +477,9 @@ subpixel precision bias in bits during conservative 
>> rasterization.
>>0 means no limit.
>>  * ``PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET``: The maximum supported value 
>> for
>>of pipe_vertex_element::src_offset.
>> +* ``PIPE_CAP_SRGB_WRITE_CONTROL``: Indicates whether the drivers on GLES 
>> supports
>> +  enabling/disabling the conversion from linear space to sRGB at 
>> framebuffer or
>> +  blend time.
>>
>>  .. _pipe_capf:
>>
>> diff --git a/src/mesa/state_tracker/st_extensions.c 
>> b/src/mesa/state_tracker/st_extensions.c
>> index 798ee60875..38d6a3ed1d 100644
>> --- a/src/mesa/state_tracker/st_extensions.c
>> +++ b/src/mesa/state_tracker/st_extensions.c
>> @@ -1167,7 +1167,7 @@ void st_init_extensions(struct pipe_screen *screen,
>>consts->MaxFramebufferSamples =
>>   get_max_samples_for_formats(screen, ARRAY_SIZE(void_formats),
>>   void_formats, 32,
>> - PIPE_BIND_RENDER_TARGET);
>> + PIPE_BIND_RENDER_TARGET);
>>
>>if (extensions->AMD_framebuffer_multisample_advanced) {
>>   /* AMD_framebuffer_multisample_advanced */
>> @@ -1393,6 +1393,12 @@ void st_init_extensions(struct pipe_screen *screen,
>> }
>>  #endif
>>
>> +   extensions->EXT_sRGB_write_control =
>> + screen->is_format_supported(screen, PIPE_FORMAT_B8G8R8A8_SRGB,
>> + PIPE_TEXTURE_2D, 0, 0,
>> + (PIPE_BIND_DISPLAY_TARGET |
>> +  PIPE_BIND_RENDER_TARGET));
>
>
> This is kinda a hack because DISPLAY_TARGET has nothing to do with sRGB. sRGB 
> is a 3D/framebuffer feature, unrelated to the window system. The sRGB 
> property of the format is private within the application and is not visible 
> outside of it. The window system doesn't care what is and isn't sRGB. I think 
> you are just hiding a bug in your driver.

Yeah, it's unclear to me what GL_EXT_sRGB_write_control does beyond
using a sRGB framebuffer format for a FBO. Either you can handle that
format or you can't...

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

Re: [Mesa-dev] EXT_gpu_shader4 / GL_EXT_gpu_shader4.mbox

[Marek Olšák]

No, we just need to write piglit tests.

Marek

On Tue, Oct 23, 2018 at 11:27 PM Dieter Nützel  wrote:

> Hello Marek,
>
> better late then...
>
> Tested-by: Dieter Nützel 
>
> Merged it into current git (0ff1ccca25).
> Do you need any special tests?
>
> Dieter
>
> Am 08.09.2018 00:06, schrieb Marek Olšák:
> > Hi Dieter,
> >
> > Here:
> > https://cgit.freedesktop.org/~mareko/mesa/log/?h=ext_gpu_shader4
> >
> > Marek
> >
> > On Tue, Sep 4, 2018 at 8:43 PM, Dieter Nützel 
> > wrote:
> >> Hello Marek,
> >>
> >> what about
> >>
> >> GL_EXT_gpu_shader4.mbox
> >> and
> >> mesa-only-allow-EXT_gpu_shader4-in-the-compatibility-profile.mbox
> >>
> >> 2cond
> >> gallium-split-depth_clip-into-depth_clip_near-depth_clip_far.mbox
> >>
> >> didn't apply any longer, but I've tested it before latest commits, so
> >>
> >> tb for that, from me.
> >>
> >> Thanks,
> >> Dieter
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 2/3] mesa/st: enable EXT_sRGB_write_control for Gallium drivers that support it

[Marek Olšák]

On Tue, Oct 23, 2018 at 1:30 PM Gert Wollny  wrote:

> From: Gert Wollny 
>
> With this patch the extension EXT_sRGB_write_control is enabled for
> gallium drivers that support sRGB formats as render targets.
>
> Tested (and pass) on r600 (evergreen) and softpipe:
>
>   dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*
>
> with "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check for
> this), and
>
>
> dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported_enum
>
> when extension is manually disabled via MESA_EXTENSION_OVERRIDE
>
> v2: - always enable the extension when sRGB is supported (Ilia Mirkin).
> - Correct handling by moving extension initialization to the
>   place where gallium/st actually takes care of this. This also
>   fixes properly disabling the extension via MESA_EXTENSION_OVERRIDE
> - reinstate check for desktop GL and add check for the extension
>   when creating the framebuffer
>
> v3: - Only create sRGB renderbuffers based on Visual.srgbCapable when
>   on desktop GL.
>
> v4: - Use PIPE_FORMAT_B8G8R8A8_SRGB to check for the capability, since this
>   is also the format that is used top check for EGL_KHR_gl_colorspace
>   support.  virgl on a GLES host usually doesn't provide this format
> but
>   one can make it available to signal that the host supports this
>   extension.
>
> Signed-off-by: Gert Wollny 
> ---
>  src/gallium/docs/source/screen.rst |  3 +++
>  src/mesa/state_tracker/st_extensions.c |  8 +-
>  src/mesa/state_tracker/st_manager.c| 37 --
>  3 files changed, 33 insertions(+), 15 deletions(-)
>
> diff --git a/src/gallium/docs/source/screen.rst
> b/src/gallium/docs/source/screen.rst
> index 0abd164494..da677eb04b 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -477,6 +477,9 @@ subpixel precision bias in bits during conservative
> rasterization.
>0 means no limit.
>  * ``PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET``: The maximum supported value
> for
>of pipe_vertex_element::src_offset.
> +* ``PIPE_CAP_SRGB_WRITE_CONTROL``: Indicates whether the drivers on GLES
> supports
> +  enabling/disabling the conversion from linear space to sRGB at
> framebuffer or
> +  blend time.
>
>  .. _pipe_capf:
>
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index 798ee60875..38d6a3ed1d 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -1167,7 +1167,7 @@ void st_init_extensions(struct pipe_screen *screen,
>consts->MaxFramebufferSamples =
>   get_max_samples_for_formats(screen, ARRAY_SIZE(void_formats),
>   void_formats, 32,
> - PIPE_BIND_RENDER_TARGET);
> + PIPE_BIND_RENDER_TARGET);
>
>if (extensions->AMD_framebuffer_multisample_advanced) {
>   /* AMD_framebuffer_multisample_advanced */
> @@ -1393,6 +1393,12 @@ void st_init_extensions(struct pipe_screen *screen,
> }
>  #endif
>
> +   extensions->EXT_sRGB_write_control =
> + screen->is_format_supported(screen, PIPE_FORMAT_B8G8R8A8_SRGB,
> + PIPE_TEXTURE_2D, 0, 0,
> + (PIPE_BIND_DISPLAY_TARGET |
> +  PIPE_BIND_RENDER_TARGET));
>

This is kinda a hack because DISPLAY_TARGET has nothing to do with sRGB.
sRGB is a 3D/framebuffer feature, unrelated to the window system. The sRGB
property of the format is private within the application and is not visible
outside of it. The window system doesn't care what is and isn't sRGB. I
think you are just hiding a bug in your driver.

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

Re: [Mesa-dev] [PATCH] gallium/hud: fix power sensor readings for amdgpu users

[Marek Olšák]

Pushed, thanks!

Marek

On Sat, Oct 27, 2018 at 3:46 AM Andre Heider  wrote:

> amdgpu doesn't use the INPUT but the AVERAGE subfeature:
>
> $ sensors -u
> amdgpu-pci-0100
> Adapter: PCI adapter
> power1:
>   power1_average: 17.233
>   power1_cap: 180.000
>
> Signed-off-by: Andre Heider 
> ---
>  src/gallium/auxiliary/hud/hud_sensors_temp.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/auxiliary/hud/hud_sensors_temp.c
> b/src/gallium/auxiliary/hud/hud_sensors_temp.c
> index c26e7b9b2a..c226e89cc4 100644
> --- a/src/gallium/auxiliary/hud/hud_sensors_temp.c
> +++ b/src/gallium/auxiliary/hud/hud_sensors_temp.c
> @@ -122,6 +122,9 @@ get_sensor_values(struct sensors_temp_info *sti)
> case SENSORS_POWER_CURRENT:
>sf = sensors_get_subfeature(sti->chip, sti->feature,
>SENSORS_SUBFEATURE_POWER_INPUT);
> +  if (!sf)
> +  sf = sensors_get_subfeature(sti->chip, sti->feature,
> +  SENSORS_SUBFEATURE_POWER_AVERAGE);
>if (sf) {
>   /* Sensors API returns in WATTs, even though driver is reporting
> mW,
>* convert back to mW */
> --
> 2.19.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: calculate buffer size correctly for packed uniforms

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Mon, Oct 29, 2018 at 5:27 AM Timothy Arceri 
wrote:

> Fixes: edded1237607 ("mesa: rework ParameterList to allow packing")
> ---
>  src/mesa/state_tracker/st_atom_constbuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_atom_constbuf.c
> b/src/mesa/state_tracker/st_atom_constbuf.c
> index 6455e612e4e..fa147b89688 100644
> --- a/src/mesa/state_tracker/st_atom_constbuf.c
> +++ b/src/mesa/state_tracker/st_atom_constbuf.c
> @@ -92,7 +92,7 @@ st_upload_constants(struct st_context *st, struct
> gl_program *prog)
> /* update constants */
> if (params && params->NumParameters) {
>struct pipe_constant_buffer cb;
> -  const uint paramBytes = params->NumParameters * sizeof(GLfloat) * 4;
> +  const uint paramBytes = params->NumParameterValues *
> sizeof(GLfloat);
>
>/* Update the constants which come from fixed-function state, such
> as
> * transformation matrices, fog factors, etc.  The rest of the
> values in
> --
> 2.17.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

Re: [Mesa-dev] [PATCH] glsl_to_tgsi: don't create 64-bit integer MAD/FMA

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Sun, Oct 21, 2018 at 12:06 PM Rhys Perry 
wrote:

> TGSI has no I64MAD/U64MAD opcode.
>
> Fixes: 278580729a5 ('st/glsl_to_tgsi: add support for 64-bit integers')
> Signed-off-by: Rhys Perry 
> ---
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index dea91c7a18..e1e00b3e33 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -1274,6 +1274,10 @@ glsl_to_tgsi_visitor::try_emit_mad(ir_expression
> *ir, int mul_operand)
> st_src_reg a, b, c;
> st_dst_reg result_dst;
>
> +   // there is no TGSI opcode for this
> +   if (ir->type->is_integer_64())
> +  return false;
> +
> ir_expression *expr = ir->operands[mul_operand]->as_expression();
> if (!expr || expr->operation != ir_binop_mul)
>return false;
> --
> 2.17.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

Re: [Mesa-dev] [PATCH] st/glsl_to_nir: fix next_stage gathering

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Sat, Oct 20, 2018 at 12:03 AM Timothy Arceri 
wrote:

> ffs() just returns the bit that is set, we need to know what
> stage that bit represents so use u_bit_scan() instead.
>
> Fixes: 2ca5d9548fc4 ("st/glsl_to_nir: gather next_stage in shader_info")
> ---
>  src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> index 24776f7f9c4..18d5d308900 100644
> --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> @@ -373,7 +373,7 @@ st_glsl_to_nir(struct st_context *st, struct
> gl_program *prog,
>   ~prev_stages & shader_program->data->linked_stages;
>
>nir->info.next_stage = stages_mask ?
> - (gl_shader_stage) ffs(stages_mask) : MESA_SHADER_FRAGMENT;
> + (gl_shader_stage) u_bit_scan(_mask) :
> MESA_SHADER_FRAGMENT;
> } else {
>nir->info.next_stage = MESA_SHADER_FRAGMENT;
> }
> --
> 2.17.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] [PATCH 2/2] radeonsi: don't set the CB clear color registers for 0/1 clear colors on Raven2

[Marek Olšák]

From: Marek Olšák 

and add has_dcc_constant_encode.
---
 src/gallium/drivers/radeonsi/si_clear.c | 10 --
 src/gallium/drivers/radeonsi/si_pipe.c  |  1 +
 src/gallium/drivers/radeonsi/si_pipe.h  |  1 +
 src/gallium/drivers/radeonsi/si_state.c |  2 +-
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_clear.c 
b/src/gallium/drivers/radeonsi/si_clear.c
index 2900c31fd21..b13eecb9ec5 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -205,22 +205,22 @@ static bool vi_get_fast_clear_parameters(enum pipe_format 
base_format,
 
/* Check if all color values are equal if they are present. */
for (int i = 0; i < 4; ++i) {
if (desc->swizzle[i] <= PIPE_SWIZZLE_W &&
desc->swizzle[i] != alpha_channel &&
values[i] != color_value)
return true; /* require ELIMINATE_FAST_CLEAR */
}
 
/* This doesn't need ELIMINATE_FAST_CLEAR.
-* CB uses both the DCC clear codes and the CB clear color registers,
-* so they must match.
+* On chips predating Raven2, the DCC clear codes and the CB clear
+* color registers must match.
 */
*eliminate_needed = false;
 
if (color_value) {
if (alpha_value)
*clear_value = DCC_CLEAR_COLOR_;
else
*clear_value = DCC_CLEAR_COLOR_1110;
} else {
if (alpha_value)
@@ -541,20 +541,26 @@ static void si_do_fast_color_clear(struct si_context 
*sctx,
!(tex->dirty_level_mask & (1 << level))) {
tex->dirty_level_mask |= 1 << level;

p_atomic_inc(>screen->compressed_colortex_counter);
}
 
/* We can change the micro tile mode before a full clear. */
si_set_optimal_micro_tile_mode(sctx->screen, tex);
 
*buffers &= ~clear_bit;
 
+   /* Chips with DCC constant encoding don't need to set the clear
+* color registers for DCC clear values 0 and 1.
+*/
+   if (sctx->screen->has_dcc_constant_encode && !eliminate_needed)
+   continue;
+
if (si_set_clear_color(tex, fb->cbufs[i]->format, color)) {
sctx->framebuffer.dirty_cbufs |= 1 << i;
si_mark_atom_dirty(sctx, >atoms.s.framebuffer);
}
}
 }
 
 static void si_clear(struct pipe_context *ctx, unsigned buffers,
 const union pipe_color_union *color,
 double depth, unsigned stencil)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 490a3714836..ba406bee922 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -1022,20 +1022,21 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
sscreen->commutative_blend_add =
driQueryOptionb(config->options, 
"radeonsi_commutative_blend_add");
sscreen->clear_db_cache_before_clear =
driQueryOptionb(config->options, 
"radeonsi_clear_db_cache_before_clear");
sscreen->has_msaa_sample_loc_bug = (sscreen->info.family >= 
CHIP_POLARIS10 &&
sscreen->info.family <= 
CHIP_POLARIS12) ||
   sscreen->info.family == CHIP_VEGA10 
||
   sscreen->info.family == CHIP_RAVEN;
sscreen->has_ls_vgpr_init_bug = sscreen->info.family == CHIP_VEGA10 ||
sscreen->info.family == CHIP_RAVEN;
+   sscreen->has_dcc_constant_encode = sscreen->info.family == CHIP_RAVEN2;
 
if (sscreen->debug_flags & DBG(DPBB)) {
sscreen->dpbb_allowed = true;
} else {
/* Only enable primitive binning on APUs by default. */
/* TODO: Investigate if binning is profitable on Vega12. */
sscreen->dpbb_allowed = !(sscreen->debug_flags & DBG(NO_DPBB)) 
&&
(sscreen->info.family == CHIP_RAVEN ||
 sscreen->info.family == CHIP_RAVEN2);
}
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index 0807c8ddacc..023e0f0a0f9 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -438,20 +438,21 @@ struct si_screen {
unsignedeqaa_force_color_samples;
boolhas_clear_state;
boolhas_distributed_tess;
boolhas_draw_indirect_multi;
boolhas_out_of_order_rast;

[Mesa-dev] [PATCH 1/2] radeonsi: use better DCC clear codes

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_clear.c | 26 -
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_clear.c 
b/src/gallium/drivers/radeonsi/si_clear.c
index 8aa3355afc8..2900c31fd21 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -27,20 +27,29 @@
 
 #include "util/u_format.h"
 #include "util/u_pack_color.h"
 #include "util/u_surface.h"
 
 enum {
SI_CLEAR = SI_SAVE_FRAGMENT_STATE,
SI_CLEAR_SURFACE = SI_SAVE_FRAMEBUFFER | SI_SAVE_FRAGMENT_STATE,
 };
 
+enum si_dcc_clear_code
+{
+DCC_CLEAR_COLOR_ = 0x,
+DCC_CLEAR_COLOR_0001 = 0x40404040,
+DCC_CLEAR_COLOR_1110 = 0x80808080,
+DCC_CLEAR_COLOR_ = 0xC0C0C0C0,
+DCC_CLEAR_COLOR_REG  = 0x20202020,
+};
+
 static void si_alloc_separate_cmask(struct si_screen *sscreen,
struct si_texture *tex)
 {
if (tex->cmask_buffer || !tex->surface.cmask_size)
 return;
 
tex->cmask_buffer =
si_aligned_buffer_create(>b,
 SI_RESOURCE_FLAG_UNMAPPABLE,
 PIPE_USAGE_DEFAULT,
@@ -126,21 +135,21 @@ static bool vi_get_fast_clear_parameters(enum pipe_format 
base_format,
const struct util_format_description *desc =
util_format_description(si_simplify_cb_format(surface_format));
 
/* 128-bit fast clear with different R,G,B values is unsupported. */
if (desc->block.bits == 128 &&
(color->ui[0] != color->ui[1] ||
 color->ui[0] != color->ui[2]))
return false;
 
*eliminate_needed = true;
-   *clear_value = 0x20202020U; /* use CB clear color registers */
+   *clear_value = DCC_CLEAR_COLOR_REG;
 
if (desc->layout != UTIL_FORMAT_LAYOUT_PLAIN)
return true; /* need ELIMINATE_FAST_CLEAR */
 
bool base_alpha_is_on_msb = vi_alpha_is_on_msb(base_format);
bool surf_alpha_is_on_msb = vi_alpha_is_on_msb(surface_format);
 
/* Formats with 3 channels can't have alpha. */
if (desc->nr_channels == 3)
alpha_channel = -1;
@@ -201,24 +210,31 @@ static bool vi_get_fast_clear_parameters(enum pipe_format 
base_format,
values[i] != color_value)
return true; /* require ELIMINATE_FAST_CLEAR */
}
 
/* This doesn't need ELIMINATE_FAST_CLEAR.
 * CB uses both the DCC clear codes and the CB clear color registers,
 * so they must match.
 */
*eliminate_needed = false;
 
-   if (color_value)
-   *clear_value |= 0x80808080U;
-   if (alpha_value)
-   *clear_value |= 0x40404040U;
+   if (color_value) {
+   if (alpha_value)
+   *clear_value = DCC_CLEAR_COLOR_;
+   else
+   *clear_value = DCC_CLEAR_COLOR_1110;
+   } else {
+   if (alpha_value)
+   *clear_value = DCC_CLEAR_COLOR_0001;
+   else
+   *clear_value = DCC_CLEAR_COLOR_;
+   }
return true;
 }
 
 void vi_dcc_clear_level(struct si_context *sctx,
struct si_texture *tex,
unsigned level, unsigned clear_value)
 {
struct pipe_resource *dcc_buffer;
uint64_t dcc_offset, clear_size;
 
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH v3 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

[Jordan Justen]

On 2018-10-26 01:06:52, andrey simiklit wrote:
> Hi,
> 
> Could you please help me with a push. I don't have a right for it :-)
> 

I pushed these two patches. Thanks!

e4e0fd5ffe1 i965/batch: don't ignore the 'brw_new_batch' call for a 'new batch'
a9031bf9b55 i965/batch: avoid reverting batch buffer if saved state is an empty

-Jordan

> 
> On Thu, Oct 11, 2018 at 9:22 PM Jordan Justen 
> wrote:
> 
> > On 2018-10-11 03:01:56, andrey simiklit wrote:
> > > Hello,
> > >
> > > Thanks for reviewing.
> > > Please find my comment below.
> > >
> > > On Thu, Oct 11, 2018 at 12:37 AM Jordan Justen <
> > jordan.l.jus...@intel.com>
> > > wrote:
> > >
> > > > On 2018-09-12 09:05:44,  wrote:
> > > > > From: Andrii Simiklit 
> > > > >
> > > > > There's no point reverting to the last saved point if that save
> > point is
> > > > > the empty batch, we will just repeat ourselves.
> > > > >
> > > > > CC: Chris Wilson 
> > > > > Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
> > > > >  the batchbuffer state."
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
> > > > > ---
> > > > >  src/mesa/drivers/dri/i965/brw_compute.c   | 3 ++-
> > > > >  src/mesa/drivers/dri/i965/brw_draw.c  | 3 ++-
> > > > >  src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 3 ++-
> > > > >  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 7 +++
> > > > >  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 1 +
> > > > >  5 files changed, 14 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
> > > > b/src/mesa/drivers/dri/i965/brw_compute.c
> > > > > index de08fc3..5c8e3a5 100644
> > > > > --- a/src/mesa/drivers/dri/i965/brw_compute.c
> > > > > +++ b/src/mesa/drivers/dri/i965/brw_compute.c
> > > > > @@ -167,7 +167,7 @@ static void
> > > > >  brw_dispatch_compute_common(struct gl_context *ctx)
> > > > >  {
> > > > > struct brw_context *brw = brw_context(ctx);
> > > > > -   bool fail_next = false;
> > > > > +   bool fail_next;
> > > > >
> > > > > if (!_mesa_check_conditional_render(ctx))
> > > > >return;
> > > > > @@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context
> > *ctx)
> > > > > intel_batchbuffer_require_space(brw, 600);
> > > > > brw_require_statebuffer_space(brw, 2500);
> > > > > intel_batchbuffer_save_state(brw);
> > > > > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> > > > >
> > > > >   retry:
> > > > > brw->batch.no_wrap = true;
> > > > > diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> > > > b/src/mesa/drivers/dri/i965/brw_draw.c
> > > > > index 8536c04..19ee396 100644
> > > > > --- a/src/mesa/drivers/dri/i965/brw_draw.c
> > > > > +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> > > > > @@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > > > >  {
> > > > > struct brw_context *brw = brw_context(ctx);
> > > > > const struct gen_device_info *devinfo = >screen->devinfo;
> > > > > -   bool fail_next = false;
> > > > > +   bool fail_next;
> > > > >
> > > > > /* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to have
> > > > >  * atoms that happen on every draw call.
> > > > > @@ -898,6 +898,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > > > > intel_batchbuffer_require_space(brw, 1500);
> > > > > brw_require_statebuffer_space(brw, 2400);
> > > > > intel_batchbuffer_save_state(brw);
> > > > > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> > > >
> > > > It seems like this will cause the WARN_ONCE to be hit incorrectly.
> > > > What about adding a 'bool empty_state', and checking that before
> > > > fail_next in the code that follows. If empty_state is true, I guess
> > > > you want to flush, but not emit the WARN_ONCE?
> > > >
> > >
> > > We just predict that first step (non-failed branch without WARN_ONCE)
> > > which should make the batch an empty will not make sense
> > > because it is already empty and we immediately pass into a failed branch.
> > > All WARN_ONCE calls are conditional ('ret == -ENOSPC') there.
> > > I guess that if we came to the failed branch (I mean branch which
> > contains
> > > WARN_ONCE)
> > > then regardless a reason (due to 'empty state' or 'failed try') we rather
> > > should log a warning
> > > that there isn't left space to transfer a batch if it is true.
> >
> > Oh. You are right. It sounds like a reasonable warning message for
> > that case. So, there's no need to change the patch.
> >
> > -Jordan
> >
> > >
> > > What do you think about it?
> > > Should we log a warning if calls of
> > > 'brw_upload_render_state' + 'brw_emit_prim' functions
> > > for an empty batch lead to ENOSPC error?
> > >
> > > Anyway if it is unacceptable for you
> > > I can implement the solution which you suggested.
> > >
> > >
> > > >
> > > > With that change,
> > > > series Reviewed-by: Jordan Justen 
> > > >
> > > > As always, it could be nice to get an r-b, or acked-by from Ken. :)
> > 

Re: [Mesa-dev] [PATCH v3 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

[Kenneth Graunke]

On Friday, October 26, 2018 1:06:52 AM PDT andrey simiklit wrote:
> Hi,
> 
> Could you please help me with a push. I don't have a right for it :-)
> 
> Thanks,
> Andrii.

Thanks for fixing these up!

While we're here, there are several other variables where we track the
last known state of the GPU, which can go wrong if we roll back the
commands that actually set that state:

We may have rolled back a 3DSTATE_CONSTANT_* emit, so need to set

brw->*.base.push_constants_dirty = true;

We may have rolled back a 3DSTATE_URB_* emit, so need to set

brw->urb.{vghd}size = something that won't match so we re-emit

We may have rolled back 3DSTATE_DEPTH_BUFFER & friends, so we need
to somehow deal with:

brw->no_depth_or_stencil

There may be more.

Bonus points if you want to fix some of those up. :)  Thanks again!

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa] tools/imgui: disable all warnings

[Eric Engestrom]

This is an external project we have no control over, and will not be
fixing (other than by sometimes pulling the latest sources), so warnings
serve no purpose here.

Signed-off-by: Eric Engestrom 
---
 src/intel/tools/imgui/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/tools/imgui/meson.build 
b/src/intel/tools/imgui/meson.build
index 8d6f37d4b3a160f0b3e5..bbc5101abade72519a5a 100644
--- a/src/intel/tools/imgui/meson.build
+++ b/src/intel/tools/imgui/meson.build
@@ -13,7 +13,7 @@ libintel_imgui_gtk = static_library(
   'intel_imgui_gtk',
   files('imgui_impl_gtk3.cpp', 'imgui_impl_opengl3.cpp'),
   dependencies : libintel_imgui_gtk_deps,
-  cpp_args : ['-Wno-deprecated-declarations', '-Wno-parentheses'],
+  cpp_args : ['-w'],
   install: false
 )
 
-- 
Cheers,
  Eric

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

[Mesa-dev] [Bug 108508] Graphic glitches with stream output support on OLAND AMD GPU GCN 1.0

[bugzilla-daemon]

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

--- Comment #15 from Ahmed Elsayed  ---
It crashes with DXVK because I use the Windows version of RenderDoc. I will use
the Linux version of RenderDoc.

-- 
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] [RFC] freedreno: import libdrm_freedreno + redesign submit

[Rob Clark]

On Tue, Oct 30, 2018 at 1:34 PM Emil Velikov  wrote:
>
> On Tue, 30 Oct 2018 at 17:19, Rob Clark  wrote:
> > On Tue, Oct 30, 2018 at 11:27 AM Emil Velikov  
> > wrote:
>
> > > > > NOTE: if bisecting a build error takes you hear, try a clean build.
> > > > > There are a bunch of ways things can go wrong if you still have
> > > > > libdrm_freedreno cflags.
> > > >
> > > > Good note!
> > > > (and s/hear/here/)
> > > >
> > > Or to make the note disappear and minimise the chance to even getting
> > > here you can try the following:
> > >  - patch 1 - dummy copy, mention the sha used as base
> > >  - patch 2/3/4 - wire up Autoconf/Android/meson
> > >  - patch 5/... - polish (remove freedreno_drmif.h includes and others)
> > >
> >
> > fwiw, I'm not planning to remove libdrm_freedreno any time soon,
> > because (a) new libdrm vs old mesa combo, and (b) I do have some other
> > small utils that use libdrm_freedreno.  I'm just planning to not
> > change it.
> >
> Fair enough. I guess those tools will not benefit from the reduced CPU
> cycled, to warrant a rewrite.
>
> I would greatly appreciate if you can split things as mentioned earlier 
> though.
> After all you've used the exact same approach to create the lot.
>

Too late on that, it is already merged.  I had considered trying to
split up into (1) import, plus (2) redesign, but there was too much
churn related to converting the code over to mesa utils / data
structures / etc, so I gave up.

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

Re: [Mesa-dev] [PATCH 2/2] kmsro: Extend to include hx8357d.

[Eric Anholt]

Emil Velikov  writes:

> Hi Eric,
>
> On Thu, 25 Oct 2018 at 17:39, Eric Anholt  wrote:
>>
>> This allows vc4 to initialize on the Adafruit PiTFT 3.5" touchscreen with
>> the new tinydrm driver I just submitted.  If this series extending the
>> pl111/kmsro driver is accepted, then I'll extend kmsro with the other
>> tinydrm drivers as well.
>
> Have you considered teaching the DRI loader about this? Unlike the
> tegra driver there's nothing special going on here.
> Create a dumb buffer on the DC, export as dmabuf and let the GPU draw into it.

The problem with modifying mesa's loaders, as I mentioned in my other
reply, is that it means you need to update the xserver's loader and get
that deployed everywhere, as well.


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

[Mesa-dev] Mesa 18.3.0 release plan

[Emil Velikov]

Hi all,

Here is the tentative release plan for 18.3.0.

As many of you are well aware, it's time to the next branch point.
Although we were a bit slow on updating the calendar, it the dates
have been around for weeks.

 Oct 31 2018 - Feature freeze/Release candidate 1
 Nov 07 2018 - Release candidate 2
 Nov 14 2018 - Release candidate 3
 Nov 21 2018 - Release candidate 4/final release

This gives us a day until the branch point.

Note: In the spirit of keeping things clearer and more transparent, we
will be keeping track of any features planned for the release in
Bugzilla [1].

Do add a separate "Depends on" for each work you have planned.
Alternatively you can reply to this email and I'll add them for you.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=108530

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

Re: [Mesa-dev] [PATCH 3/4] intel/decoder: tools: Use engine for decoding batch instructions

[Toni Lönnberg]

The whole point of the patch series is that the decoder can't really be 
agnostic 
about the engine because it needs to decode the stuff differently depending on 
the engine the instruction is sent to. But if you feel more comfortable with 
the 
init-approach, I'll change it in v2, though to me it seems the exact same 
amount of complexity overall.

On Tue, Oct 30, 2018 at 05:11:05PM +, Lionel Landwerlin wrote:
> Yeah, true.
> Maybe put a default value on init (likely render) and let the caller of
> gen_print_batch() set the field on the line above.
> I could just like to leave the decode somewhat agnostic about what type of
> engine it's dealing with.
> 
> -
> Lionel
> 
> On 30/10/2018 16:21, Toni Lönnberg wrote:
> > The engine doesn't change inside a batch but it can change between batches,
> > right? The options are either to pass the engine around or have it in the
> > decoder context but it would need to be updated in the there before 
> > decoding a
> > new batch.
> > 
> > On Tue, Oct 30, 2018 at 02:58:32PM +, Lionel Landwerlin wrote:
> > > Since a batch will be given to a specific engine, the engine won't change
> > > change while decoding.
> > > So I would just store the engine into gen_batch_decode_ctx and set it in 
> > > the
> > > init function, that'll reduce the diff a bit.
> > > 
> > > Then just introduce a local find_instruction() function that calls
> > > gen_spec_find_instruction(ctx->spec, ctx->engine, p).
> > > 
> > > Thanks,
> > > 
> > > -
> > > Lionel
> > > 
> > > On 30/10/2018 14:32, Toni Lönnberg wrote:
> > > > The engine to which the batch was sent to is now passed along when 
> > > > decoding the
> > > > batch. This is needed so that we can distinguish between instructions 
> > > > as the
> > > > render and video pipe share some of the instruction opcodes.
> > > > ---
> > > >src/intel/common/gen_batch_decoder.c  | 21 
> > > > ++-
> > > >src/intel/common/gen_decoder.c|  4 ++--
> > > >src/intel/common/gen_decoder.h|  3 ++-
> > > >src/intel/tools/aubinator.c   |  5 ++---
> > > >src/intel/tools/aubinator_error_decode.c  | 19 -
> > > >src/mesa/drivers/dri/i965/intel_batchbuffer.c |  3 ++-
> > > >6 files changed, 37 insertions(+), 18 deletions(-)
> > > > 
> > > > diff --git a/src/intel/common/gen_batch_decoder.c 
> > > > b/src/intel/common/gen_batch_decoder.c
> > > > index 63f04627572..8bd256d10e9 100644
> > > > --- a/src/intel/common/gen_batch_decoder.c
> > > > +++ b/src/intel/common/gen_batch_decoder.c
> > > > @@ -195,7 +195,7 @@ ctx_print_buffer(struct gen_batch_decode_ctx *ctx,
> > > >static void
> > > >handle_state_base_address(struct gen_batch_decode_ctx *ctx, const 
> > > > uint32_t *p)
> > > >{
> > > > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > > > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > > > GEN_ENGINE_RENDER, p);
> > > >   struct gen_field_iterator iter;
> > > >   gen_field_iterator_init(, inst, p, 0, false);
> > > > @@ -309,7 +309,7 @@ static void
> > > >handle_media_interface_descriptor_load(struct gen_batch_decode_ctx 
> > > > *ctx,
> > > >   const uint32_t *p)
> > > >{
> > > > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > > > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > > > GEN_ENGINE_RENDER, p);
> > > >   struct gen_group *desc =
> > > >  gen_spec_find_struct(ctx->spec, "INTERFACE_DESCRIPTOR_DATA");
> > > > @@ -373,7 +373,7 @@ static void
> > > >handle_3dstate_vertex_buffers(struct gen_batch_decode_ctx *ctx,
> > > >  const uint32_t *p)
> > > >{
> > > > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > > > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > > > GEN_ENGINE_RENDER, p);
> > > >   struct gen_group *vbs = gen_spec_find_struct(ctx->spec, 
> > > > "VERTEX_BUFFER_STATE");
> > > >   struct gen_batch_decode_bo vb = {};
> > > > @@ -436,7 +436,7 @@ static void
> > > >handle_3dstate_index_buffer(struct gen_batch_decode_ctx *ctx,
> > > >const uint32_t *p)
> > > >{
> > > > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > > > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > > > GEN_ENGINE_RENDER, p);
> > > >   struct gen_batch_decode_bo ib = {};
> > > >   uint32_t ib_size = 0;
> > > > @@ -486,7 +486,7 @@ handle_3dstate_index_buffer(struct 
> > > > gen_batch_decode_ctx *ctx,
> > > >static void
> > > >decode_single_ksp(struct gen_batch_decode_ctx *ctx, const uint32_t 
> > > > *p)
> > > >{
> > > > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > > > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > > > 

[Mesa-dev] [Bug 108530] [Tracker] Mesa 18.3 Release Tracker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108530
Bug 108530 depends on bug 108082, which changed state.

Bug 108082 Summary: warning: unknown warning option '-Wno-format-truncation' 
[-Wunknown-warning-option]
https://bugs.freedesktop.org/show_bug.cgi?id=108082

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
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 108082] warning: unknown warning option '-Wno-format-truncation' [-Wunknown-warning-option]

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Emil Velikov  ---
Should be fixed with

commit 29283921b72fa9386322fc9eb301d00e88b634b6
Author: Emil Velikov 
Date:   Wed Oct 24 18:53:11 2018 +0100

m4: add Werror when checking for compiler flags

-- 
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] [RFC] freedreno: import libdrm_freedreno + redesign submit

[Emil Velikov]

On Tue, 30 Oct 2018 at 17:19, Rob Clark  wrote:
> On Tue, Oct 30, 2018 at 11:27 AM Emil Velikov  
> wrote:

> > > > NOTE: if bisecting a build error takes you hear, try a clean build.
> > > > There are a bunch of ways things can go wrong if you still have
> > > > libdrm_freedreno cflags.
> > >
> > > Good note!
> > > (and s/hear/here/)
> > >
> > Or to make the note disappear and minimise the chance to even getting
> > here you can try the following:
> >  - patch 1 - dummy copy, mention the sha used as base
> >  - patch 2/3/4 - wire up Autoconf/Android/meson
> >  - patch 5/... - polish (remove freedreno_drmif.h includes and others)
> >
>
> fwiw, I'm not planning to remove libdrm_freedreno any time soon,
> because (a) new libdrm vs old mesa combo, and (b) I do have some other
> small utils that use libdrm_freedreno.  I'm just planning to not
> change it.
>
Fair enough. I guess those tools will not benefit from the reduced CPU
cycled, to warrant a rewrite.

I would greatly appreciate if you can split things as mentioned earlier though.
After all you've used the exact same approach to create the lot.

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

Re: [Mesa-dev] [RFC] freedreno: import libdrm_freedreno + redesign submit

[Rob Clark]

On Tue, Oct 30, 2018 at 11:27 AM Emil Velikov  wrote:
>
> On Thu, 25 Oct 2018 at 10:32, Eric Engestrom  wrote:
> >
> > On Tuesday, 2018-10-23 10:49:26 -0400, 
> > mesa-dev-boun...@lists.freedesktop.org wrote:
> > > In the pursuit of lowering driver overhead, it became clear that some
> > > amount of redesign of how libdrm_freedreno constructs the submit ioctl
> > > would be needed.  In particular, as the gallium driver is starting to
> > > make heavier use of CP_SET_DRAW_STATE state groups/objects, the over-
> > > head of tracking cmd buffers and relocs becomes too much.  And for
> > > "streaming" state, which isn't ever reused (like uniform uploads) the
> > > overhead of allocating/freeing ringbuffer[1] objects is too high.
> > >
> > > This redesign makes two main changes:
> > >
> > >  1) Introduces a fd_submit object for tracking bos and cmds table
> > > for the submit ioctl, making ringbuffer objects more light-
> > > weight.  This was previously done in the ringbuffer.  But we
> > > have many ringbuffer instances involved in a submit (gmem +
> > > draw + potentially 1000's of state-group rbs), and only need
> > > a single bos and cmds table.  (Reloc table is still per-rb)
> > >
> > > The submit is also a convenient place for a slab allocator for
> > > ringbuffer objects.  Other options would have required locking
> > > because, while we can guarantee allocations will only happen on
> > > a single thread, free's could happen either on the application
> > > thread or the flush_queue thread.  With the slab allocator in
> > > the submit object, any frees that happen on the flush_queue
> > > thread happen after we know that the application thread is done
> > > with the submit.
> > >
> > >  2) Introduce a new "softpin" msm_ringbuffer_sp implementation that
> > > does not use relocs and only has cmds table entries for IB1 (ie.
> > > the cmdstream buffers that kernel needs to CP_INDIRECT_BUFFER
> > > to from the RB).  To do this properly will require some updates
> > > on the kernel side, so whether you get the softpin or legacy
> > > submit/ringbuffer implementation at runtime depends on your
> > > kernel version.
> > >
> > > To make all these changes in libdrm would basically require adding a
> > > libdrm_freedreno2, so this is a good point to just pull the libdrm code
> > > into mesa.  Plus it allows for using mesa's hashtable, slab allocator,
> > > etc.  And it lets us have asserts enabled for debug mesa buids but
> > > omitted for release builds.  And it makes life easier if further API
> > > changes become necessary.
> > >
> libdrm_freedreno made sense when there was more than one user. Since
> xf86-video-freedreno is a dead end it's better to make your life
> easier.
>
> > > At this point I haven't tried to pull in the kgsl backend.  Although
> > > I left the level of vfunc indirection which would make it possible
> > > to have other backends.  (And this was convenient to keep to allow
> > > for the "softpin" ringbuffer to coexist.)
> > >
> Does that code even work with the latest kernel kgsl code?
> I thought wasn't compatible for years.
>
> > > NOTE: if bisecting a build error takes you hear, try a clean build.
> > > There are a bunch of ways things can go wrong if you still have
> > > libdrm_freedreno cflags.
> >
> > Good note!
> > (and s/hear/here/)
> >
> Or to make the note disappear and minimise the chance to even getting
> here you can try the following:
>  - patch 1 - dummy copy, mention the sha used as base
>  - patch 2/3/4 - wire up Autoconf/Android/meson
>  - patch 5/... - polish (remove freedreno_drmif.h includes and others)
>

fwiw, I'm not planning to remove libdrm_freedreno any time soon,
because (a) new libdrm vs old mesa combo, and (b) I do have some other
small utils that use libdrm_freedreno.  I'm just planning to not
change it.

BR,
-R

> It'll make it far easier to verity, read and provide meaningful review.
>
> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/5] glsl: add has_implicit_uint_to_int_conversion()-helper

[Erik Faye-Lund]

This makes the code a bit easier to read, as well as reduces repetition,
especially when we add support for EXT_shader_implicit_conversions.

Signed-off-by: Erik Faye-Lund 
---
 src/compiler/glsl/ast_to_hir.cpp   | 3 +--
 src/compiler/glsl/glsl_parser_extras.h | 7 +++
 src/compiler/glsl_types.cpp| 3 +--
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 6d4b2c6aa5d..7f30a708855 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -250,8 +250,7 @@ get_implicit_conversion_operation(const glsl_type *to, 
const glsl_type *from,
   }
 
case GLSL_TYPE_UINT:
-  if (!state->is_version(400, 0) && !state->ARB_gpu_shader5_enable
-  && !state->MESA_shader_integer_functions_enable)
+  if (!state->has_implicit_uint_to_int_conversion())
  return (ir_expression_operation)0;
   switch (from->base_type) {
  case GLSL_TYPE_INT: return ir_unop_i2u;
diff --git a/src/compiler/glsl/glsl_parser_extras.h 
b/src/compiler/glsl/glsl_parser_extras.h
index edd41601c35..e1144a19c15 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -349,6 +349,13 @@ struct _mesa_glsl_parse_state {
   return is_version(120, 0);
}
 
+   bool has_implicit_uint_to_int_conversion() const
+   {
+  return ARB_gpu_shader5_enable ||
+ MESA_shader_integer_functions_enable ||
+ is_version(400, 0);
+   }
+
void process_version_directive(YYLTYPE *locp, int version,
   const char *ident);
 
diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index bcc36e50d7f..e6262371bd0 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -1446,8 +1446,7 @@ glsl_type::can_implicitly_convert_to(const glsl_type 
*desired,
 * state-dependent checks have already happened though, so allow anything
 * that's allowed in any shader version.
 */
-   if ((!state || state->is_version(400, 0) || state->ARB_gpu_shader5_enable ||
-state->MESA_shader_integer_functions_enable) &&
+   if ((!state || state->has_implicit_uint_to_int_conversion()) &&
  desired->base_type == GLSL_TYPE_UINT && this->base_type == 
GLSL_TYPE_INT)
   return true;
 
-- 
2.17.2

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

[Mesa-dev] [PATCH 3/5] glsl: fall back to inexact function-match

[Erik Faye-Lund]

In GLES, we currently either need an exact match with a local function,
or an exact match with a builtin.

However, if we add support for implicit conversions for GLES shaders,
we also need to fall back to a non-exact match in the case where there
were no builtin match either.

Luckily, we already have a variable ready with this, so let's just
return it if the builtin-search failed.

Signed-off-by: Erik Faye-Lund 
---
 src/compiler/glsl/ast_function.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index 1fa3f7561ae..50fd8bc5f5d 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -667,7 +667,7 @@ match_function_by_name(const char *name,
/* Local shader has no exact candidates; check the built-ins. */
_mesa_glsl_initialize_builtin_functions();
sig = _mesa_glsl_find_builtin_function(state, name, actual_parameters);
-   return sig;
+   return sig ? sig : local_sig;
 }
 
 static ir_function_signature *
-- 
2.17.2

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

[Mesa-dev] [PATCH 4/5] mesa/glsl: add support for EXT_shader_implicit_conversions

[Erik Faye-Lund]

EXT_shader_implicit_conversions adds support for implicit conversions
for GLES 3.1 and above.

This is essentially a subset of ARB_gpu_shader5, and augments
OES_gpu_shader5.

Signed-off-by: Erik Faye-Lund 
---
 src/compiler/glsl/glsl_parser_extras.cpp | 1 +
 src/compiler/glsl/glsl_parser_extras.h   | 5 -
 src/compiler/glsl/ir_function.cpp| 3 ++-
 src/mesa/main/extensions_table.h | 1 +
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index 1bdd7c4bf17..2a58908c226 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -718,6 +718,7 @@ static const _mesa_glsl_extension 
_mesa_glsl_supported_extensions[] = {
EXT(EXT_separate_shader_objects),
EXT(EXT_shader_framebuffer_fetch),
EXT(EXT_shader_framebuffer_fetch_non_coherent),
+   EXT(EXT_shader_implicit_conversions),
EXT(EXT_shader_integer_mix),
EXT_AEP(EXT_shader_io_blocks),
EXT(EXT_shader_samples_identical),
diff --git a/src/compiler/glsl/glsl_parser_extras.h 
b/src/compiler/glsl/glsl_parser_extras.h
index e1144a19c15..985200ecab5 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -346,13 +346,14 @@ struct _mesa_glsl_parse_state {
 
bool has_implicit_conversions() const
{
-  return is_version(120, 0);
+  return EXT_shader_implicit_conversions_enable || is_version(120, 0);
}
 
bool has_implicit_uint_to_int_conversion() const
{
   return ARB_gpu_shader5_enable ||
  MESA_shader_integer_functions_enable ||
+ EXT_shader_implicit_conversions_enable ||
  is_version(400, 0);
}
 
@@ -806,6 +807,8 @@ struct _mesa_glsl_parse_state {
bool EXT_shader_framebuffer_fetch_warn;
bool EXT_shader_framebuffer_fetch_non_coherent_enable;
bool EXT_shader_framebuffer_fetch_non_coherent_warn;
+   bool EXT_shader_implicit_conversions_enable;
+   bool EXT_shader_implicit_conversions_warn;
bool EXT_shader_integer_mix_enable;
bool EXT_shader_integer_mix_warn;
bool EXT_shader_io_blocks_enable;
diff --git a/src/compiler/glsl/ir_function.cpp 
b/src/compiler/glsl/ir_function.cpp
index 3ee0d170fb2..97262f0f4b9 100644
--- a/src/compiler/glsl/ir_function.cpp
+++ b/src/compiler/glsl/ir_function.cpp
@@ -274,7 +274,8 @@ choose_best_inexact_overload(_mesa_glsl_parse_state *state,
 * assume everything supported in any GLSL version is available.
 */
if (!state || state->is_version(400, 0) || state->ARB_gpu_shader5_enable ||
-   state->MESA_shader_integer_functions_enable) {
+   state->MESA_shader_integer_functions_enable ||
+   state->EXT_shader_implicit_conversions_enable) {
   for (ir_function_signature **sig = matches; sig < matches + num_matches; 
sig++) {
  if (is_best_inexact_overload(actual_parameters, matches, num_matches, 
*sig))
 return *sig;
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 47db1583135..e3bf7c9fcee 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -261,6 +261,7 @@ EXT(EXT_separate_shader_objects , dummy_true
 EXT(EXT_separate_specular_color , dummy_true   
  , GLL,  x ,  x ,  x , 1997)
 EXT(EXT_shader_framebuffer_fetch, EXT_shader_framebuffer_fetch 
  , GLL, GLC,  x , ES2, 2013)
 EXT(EXT_shader_framebuffer_fetch_non_coherent, 
EXT_shader_framebuffer_fetch_non_coherent, GLL, GLC,  x, ES2, 2018)
+EXT(EXT_shader_implicit_conversions , dummy_true   
  ,  x ,  x ,  x ,  31, 2013)
 EXT(EXT_shader_integer_mix  , EXT_shader_integer_mix   
  , GLL, GLC,  x ,  30, 2013)
 EXT(EXT_shader_io_blocks, dummy_true   
  ,  x ,  x ,  x ,  31, 2014)
 EXT(EXT_shader_samples_identical, EXT_shader_samples_identical 
  , GLL, GLC,  x ,  31, 2015)
-- 
2.17.2

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

[Mesa-dev] [PATCH 5/5] glsl: do not allow implicit casts of unsized array initializers

[Erik Faye-Lund]

The GLSL 4.6 specification (section 4.1.14. "Implicit Conversions")
says:

  "There are no implicit array or structure conversions. For
   example, an array of int cannot be implicitly converted to an
   array of float."

So let's add a check in place when assigning array initializers to
implicitly sized arrays, to avoid incorrectly allowing code on the
form:

int[] foo = float[](1.0, 2.0, 3.0)

This fixes the following dEQP test-cases:
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es31.invalid.arrays.int_to_float_vertex
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es31.invalid.arrays.int_to_float_fragment
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es31.invalid.arrays.int_to_uint_vertex
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es31.invalid.arrays.int_to_uint_fragment
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es31.invalid.arrays.uint_to_float_vertex
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es31.invalid.arrays.uint_to_float_fragment
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es32.invalid.arrays.int_to_float_vertex
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es32.invalid.arrays.int_to_float_fragment
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es32.invalid.arrays.int_to_uint_vertex
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es32.invalid.arrays.int_to_uint_fragment
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es32.invalid.arrays.uint_to_float_vertex
- 
dEQP-GLES31.functional.shaders.implicit_conversions.es32.invalid.arrays.uint_to_float_fragment

Signed-off-by: Erik Faye-Lund 
---
 src/compiler/glsl/ast_to_hir.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 7f30a708855..7671041a454 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -891,7 +891,8 @@ validate_assignment(struct _mesa_glsl_parse_state *state,
}
if (unsized_array) {
   if (is_initializer) {
- return rhs;
+ if (rhs->type->get_scalar_type() == lhs->type->get_scalar_type())
+return rhs;
   } else {
  _mesa_glsl_error(, state,
   "implicitly sized arrays cannot be assigned");
-- 
2.17.2

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

[Mesa-dev] [PATCH 1/5] glsl: add has_implicit_conversions()-helper

[Erik Faye-Lund]

This makes the code a bit easier to read, as well as will reduce
repetition when we add support for EXT_shader_implicit_conversions.

Signed-off-by: Erik Faye-Lund 
---
 src/compiler/glsl/ast_to_hir.cpp   | 2 +-
 src/compiler/glsl/glsl_parser_extras.h | 5 +
 src/compiler/glsl_types.cpp| 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 084b7021a9f..6d4b2c6aa5d 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -315,7 +315,7 @@ apply_implicit_conversion(const glsl_type *to, ir_rvalue * 
,
   return true;
 
/* Prior to GLSL 1.20, there are no implicit conversions */
-   if (!state->is_version(120, 0))
+   if (!state->has_implicit_conversions())
   return false;
 
/* From page 27 (page 33 of the PDF) of the GLSL 1.50 spec:
diff --git a/src/compiler/glsl/glsl_parser_extras.h 
b/src/compiler/glsl/glsl_parser_extras.h
index 966d848509c..edd41601c35 100644
--- a/src/compiler/glsl/glsl_parser_extras.h
+++ b/src/compiler/glsl/glsl_parser_extras.h
@@ -344,6 +344,11 @@ struct _mesa_glsl_parse_state {
   return ARB_bindless_texture_enable;
}
 
+   bool has_implicit_conversions() const
+   {
+  return is_version(120, 0);
+   }
+
void process_version_directive(YYLTYPE *locp, int version,
   const char *ident);
 
diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 70bce6ace8e..bcc36e50d7f 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -1425,7 +1425,7 @@ glsl_type::can_implicitly_convert_to(const glsl_type 
*desired,
 * state, we're doing intra-stage function linking where these checks have
 * already been done.
 */
-   if (state && !state->is_version(120, 0))
+   if (state && !state->has_implicit_conversions())
   return false;
 
/* There is no conversion among matrix types. */
-- 
2.17.2

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

Re: [Mesa-dev] [PATCH 3/4] intel/decoder: tools: Use engine for decoding batch instructions

[Lionel Landwerlin]

Yeah, true.
Maybe put a default value on init (likely render) and let the caller of 
gen_print_batch() set the field on the line above.
I could just like to leave the decode somewhat agnostic about what type 
of engine it's dealing with.


-
Lionel

On 30/10/2018 16:21, Toni Lönnberg wrote:

The engine doesn't change inside a batch but it can change between batches,
right? The options are either to pass the engine around or have it in the
decoder context but it would need to be updated in the there before decoding a
new batch.

On Tue, Oct 30, 2018 at 02:58:32PM +, Lionel Landwerlin wrote:

Since a batch will be given to a specific engine, the engine won't change
change while decoding.
So I would just store the engine into gen_batch_decode_ctx and set it in the
init function, that'll reduce the diff a bit.

Then just introduce a local find_instruction() function that calls
gen_spec_find_instruction(ctx->spec, ctx->engine, p).

Thanks,

-
Lionel

On 30/10/2018 14:32, Toni Lönnberg wrote:

The engine to which the batch was sent to is now passed along when decoding the
batch. This is needed so that we can distinguish between instructions as the
render and video pipe share some of the instruction opcodes.
---
   src/intel/common/gen_batch_decoder.c  | 21 ++-
   src/intel/common/gen_decoder.c|  4 ++--
   src/intel/common/gen_decoder.h|  3 ++-
   src/intel/tools/aubinator.c   |  5 ++---
   src/intel/tools/aubinator_error_decode.c  | 19 -
   src/mesa/drivers/dri/i965/intel_batchbuffer.c |  3 ++-
   6 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/src/intel/common/gen_batch_decoder.c 
b/src/intel/common/gen_batch_decoder.c
index 63f04627572..8bd256d10e9 100644
--- a/src/intel/common/gen_batch_decoder.c
+++ b/src/intel/common/gen_batch_decoder.c
@@ -195,7 +195,7 @@ ctx_print_buffer(struct gen_batch_decode_ctx *ctx,
   static void
   handle_state_base_address(struct gen_batch_decode_ctx *ctx, const uint32_t 
*p)
   {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  struct gen_field_iterator iter;
  gen_field_iterator_init(, inst, p, 0, false);
@@ -309,7 +309,7 @@ static void
   handle_media_interface_descriptor_load(struct gen_batch_decode_ctx *ctx,
  const uint32_t *p)
   {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  struct gen_group *desc =
 gen_spec_find_struct(ctx->spec, "INTERFACE_DESCRIPTOR_DATA");
@@ -373,7 +373,7 @@ static void
   handle_3dstate_vertex_buffers(struct gen_batch_decode_ctx *ctx,
 const uint32_t *p)
   {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  struct gen_group *vbs = gen_spec_find_struct(ctx->spec, 
"VERTEX_BUFFER_STATE");
  struct gen_batch_decode_bo vb = {};
@@ -436,7 +436,7 @@ static void
   handle_3dstate_index_buffer(struct gen_batch_decode_ctx *ctx,
   const uint32_t *p)
   {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  struct gen_batch_decode_bo ib = {};
  uint32_t ib_size = 0;
@@ -486,7 +486,7 @@ handle_3dstate_index_buffer(struct gen_batch_decode_ctx 
*ctx,
   static void
   decode_single_ksp(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
   {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  uint64_t ksp = 0;
  bool is_simd8 = false; /* vertex shaders on Gen8+ only */
@@ -528,7 +528,7 @@ decode_single_ksp(struct gen_batch_decode_ctx *ctx, const 
uint32_t *p)
   static void
   decode_ps_kernels(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
   {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  uint64_t ksp[3] = {0, 0, 0};
  bool enabled[3] = {false, false, false};
@@ -576,7 +576,7 @@ decode_ps_kernels(struct gen_batch_decode_ctx *ctx, const 
uint32_t *p)
   static void
   decode_3dstate_constant(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
   {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  struct gen_group *body =
 gen_spec_find_struct(ctx->spec, "3DSTATE_CONSTANT_BODY");
@@ -658,7 +658,7 @@ decode_dynamic_state_pointers(struct gen_batch_decode_ctx 
*ctx,
 const char 

[Mesa-dev] [PATCH 0/5] add support for EXT_shader_implicit_conversions

[Erik Faye-Lund]

EXT_shader_implicit_conversions is a useful extension that adds implicit
conversions to OpenGL ES 3.1. Since it's tested excensively in dEQP, and
Mesa already has support for implicit conversions, it seems reasonable to
allow for the extension. This ended up mostly as code-cleanups anyway.

While enabling this, one bug was discorvered due to a failing dEQP test
(see the last patch).

This makes 2068 dEQP-GLE31 tests go from NotSupported to Pass on i965.

No piglit regressions observed.

Erik Faye-Lund (5):
  glsl: add has_implicit_conversions()-helper
  glsl: add has_implicit_uint_to_int_conversion()-helper
  glsl: fall back to inexact function-match
  mesa/glsl: add support for EXT_shader_implicit_conversions
  glsl: do not allow implicit casts of unsized array initializers

 src/compiler/glsl/ast_function.cpp   |  2 +-
 src/compiler/glsl/ast_to_hir.cpp |  8 
 src/compiler/glsl/glsl_parser_extras.cpp |  1 +
 src/compiler/glsl/glsl_parser_extras.h   | 15 +++
 src/compiler/glsl/ir_function.cpp|  3 ++-
 src/compiler/glsl_types.cpp  |  5 ++---
 src/mesa/main/extensions_table.h |  1 +
 7 files changed, 26 insertions(+), 9 deletions(-)

-- 
2.17.2

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

Re: [Mesa-dev] [PATCH] intel/compiler: Stop assuming the entrypoint is called "main"

[Lionel Landwerlin]

On 30/10/2018 16:26, Jason Ekstrand wrote:

This isn't true for Vulkan so we have to whack it to "main" in anv which
is silly.  Instead of walking the list of functions and asserting that
everything is named "main" and hoping there's only one function named
"main", just use the nir_shader_get_entrypoint() helper which has better
assertions anyway.



There is this comment that might need updating in 
src/intel/compiler/brw_fs.cpp :


  /* Generate FS IR for main().  (the visitor only descends into
   * functions called "main").
   */
  emit_nir_code();

Either way:


Reviewed-by: Lionel Landwerlin 



---
  src/intel/compiler/brw_fs_nir.cpp   | 17 -
  src/intel/compiler/brw_vec4_nir.cpp |  7 +--
  src/intel/vulkan/anv_pipeline.c |  1 -
  3 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index 7930205d659..c845d87d59b 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -40,12 +40,7 @@ fs_visitor::emit_nir_code()
 nir_setup_uniforms();
 nir_emit_system_values();
  
-   /* get the main function and emit it */

-   nir_foreach_function(function, nir) {
-  assert(strcmp(function->name, "main") == 0);
-  assert(function->impl);
-  nir_emit_impl(function->impl);
-   }
+   nir_emit_impl(nir_shader_get_entrypoint((nir_shader *)nir));
  }
  
  void

@@ -267,13 +262,9 @@ fs_visitor::nir_emit_system_values()
}
 }
  
-   nir_foreach_function(function, nir) {

-  assert(strcmp(function->name, "main") == 0);
-  assert(function->impl);
-  nir_foreach_block(block, function->impl) {
- emit_system_values_block(block, this);
-  }
-   }
+   nir_function_impl *impl = nir_shader_get_entrypoint((nir_shader *)nir);
+   nir_foreach_block(block, impl)
+  emit_system_values_block(block, this);
  }
  
  /*

diff --git a/src/intel/compiler/brw_vec4_nir.cpp 
b/src/intel/compiler/brw_vec4_nir.cpp
index 5ccfd1f8940..19ee79367c8 100644
--- a/src/intel/compiler/brw_vec4_nir.cpp
+++ b/src/intel/compiler/brw_vec4_nir.cpp
@@ -37,12 +37,7 @@ vec4_visitor::emit_nir_code()
 if (nir->num_uniforms > 0)
nir_setup_uniforms();
  
-   /* get the main function and emit it */

-   nir_foreach_function(function, nir) {
-  assert(strcmp(function->name, "main") == 0);
-  assert(function->impl);
-  nir_emit_impl(function->impl);
-   }
+   nir_emit_impl(nir_shader_get_entrypoint((nir_shader *)nir));
  }
  
  void

diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 7c9b1230115..ad0f08253e7 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -191,7 +191,6 @@ anv_shader_compile_to_nir(struct anv_pipeline *pipeline,
   exec_node_remove(>node);
 }
 assert(exec_list_length(>functions) == 1);
-   entry_point->name = ralloc_strdup(entry_point, "main");
  
 /* Now that we've deleted all but the main function, we can go ahead and

  * lower the rest of the constant initializers.  We do this here so that



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

Re: [Mesa-dev] [PATCH 2/2] anv: Bump the advertised patch version to 90

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 29/10/2018 14:44, Jason Ekstrand wrote:

---
  src/intel/vulkan/anv_extensions.py | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index ab9240f9fd8..e9afe06bb13 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -47,7 +47,7 @@ class ApiVersion:
  self.version = version
  self.enable = _bool_to_c_expr(enable)
  
-API_PATCH_VERSION = 80

+API_PATCH_VERSION = 90
  
  # Supported API versions.  Each one is the maximum patch version for the given

  # version.  Version come in increasing order and each version is available if



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

[Mesa-dev] [PATCH] intel/compiler: Stop assuming the entrypoint is called "main"

[Jason Ekstrand]

This isn't true for Vulkan so we have to whack it to "main" in anv which
is silly.  Instead of walking the list of functions and asserting that
everything is named "main" and hoping there's only one function named
"main", just use the nir_shader_get_entrypoint() helper which has better
assertions anyway.
---
 src/intel/compiler/brw_fs_nir.cpp   | 17 -
 src/intel/compiler/brw_vec4_nir.cpp |  7 +--
 src/intel/vulkan/anv_pipeline.c |  1 -
 3 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index 7930205d659..c845d87d59b 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -40,12 +40,7 @@ fs_visitor::emit_nir_code()
nir_setup_uniforms();
nir_emit_system_values();
 
-   /* get the main function and emit it */
-   nir_foreach_function(function, nir) {
-  assert(strcmp(function->name, "main") == 0);
-  assert(function->impl);
-  nir_emit_impl(function->impl);
-   }
+   nir_emit_impl(nir_shader_get_entrypoint((nir_shader *)nir));
 }
 
 void
@@ -267,13 +262,9 @@ fs_visitor::nir_emit_system_values()
   }
}
 
-   nir_foreach_function(function, nir) {
-  assert(strcmp(function->name, "main") == 0);
-  assert(function->impl);
-  nir_foreach_block(block, function->impl) {
- emit_system_values_block(block, this);
-  }
-   }
+   nir_function_impl *impl = nir_shader_get_entrypoint((nir_shader *)nir);
+   nir_foreach_block(block, impl)
+  emit_system_values_block(block, this);
 }
 
 /*
diff --git a/src/intel/compiler/brw_vec4_nir.cpp 
b/src/intel/compiler/brw_vec4_nir.cpp
index 5ccfd1f8940..19ee79367c8 100644
--- a/src/intel/compiler/brw_vec4_nir.cpp
+++ b/src/intel/compiler/brw_vec4_nir.cpp
@@ -37,12 +37,7 @@ vec4_visitor::emit_nir_code()
if (nir->num_uniforms > 0)
   nir_setup_uniforms();
 
-   /* get the main function and emit it */
-   nir_foreach_function(function, nir) {
-  assert(strcmp(function->name, "main") == 0);
-  assert(function->impl);
-  nir_emit_impl(function->impl);
-   }
+   nir_emit_impl(nir_shader_get_entrypoint((nir_shader *)nir));
 }
 
 void
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 7c9b1230115..ad0f08253e7 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -191,7 +191,6 @@ anv_shader_compile_to_nir(struct anv_pipeline *pipeline,
  exec_node_remove(>node);
}
assert(exec_list_length(>functions) == 1);
-   entry_point->name = ralloc_strdup(entry_point, "main");
 
/* Now that we've deleted all but the main function, we can go ahead and
 * lower the rest of the constant initializers.  We do this here so that
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH 3/4] intel/decoder: tools: Use engine for decoding batch instructions

[Toni Lönnberg]

The engine doesn't change inside a batch but it can change between batches, 
right? The options are either to pass the engine around or have it in the 
decoder context but it would need to be updated in the there before decoding a 
new batch.

On Tue, Oct 30, 2018 at 02:58:32PM +, Lionel Landwerlin wrote:
> Since a batch will be given to a specific engine, the engine won't change
> change while decoding.
> So I would just store the engine into gen_batch_decode_ctx and set it in the
> init function, that'll reduce the diff a bit.
> 
> Then just introduce a local find_instruction() function that calls
> gen_spec_find_instruction(ctx->spec, ctx->engine, p).
> 
> Thanks,
> 
> -
> Lionel
> 
> On 30/10/2018 14:32, Toni Lönnberg wrote:
> > The engine to which the batch was sent to is now passed along when decoding 
> > the
> > batch. This is needed so that we can distinguish between instructions as the
> > render and video pipe share some of the instruction opcodes.
> > ---
> >   src/intel/common/gen_batch_decoder.c  | 21 ++-
> >   src/intel/common/gen_decoder.c|  4 ++--
> >   src/intel/common/gen_decoder.h|  3 ++-
> >   src/intel/tools/aubinator.c   |  5 ++---
> >   src/intel/tools/aubinator_error_decode.c  | 19 -
> >   src/mesa/drivers/dri/i965/intel_batchbuffer.c |  3 ++-
> >   6 files changed, 37 insertions(+), 18 deletions(-)
> > 
> > diff --git a/src/intel/common/gen_batch_decoder.c 
> > b/src/intel/common/gen_batch_decoder.c
> > index 63f04627572..8bd256d10e9 100644
> > --- a/src/intel/common/gen_batch_decoder.c
> > +++ b/src/intel/common/gen_batch_decoder.c
> > @@ -195,7 +195,7 @@ ctx_print_buffer(struct gen_batch_decode_ctx *ctx,
> >   static void
> >   handle_state_base_address(struct gen_batch_decode_ctx *ctx, const 
> > uint32_t *p)
> >   {
> > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > GEN_ENGINE_RENDER, p);
> >  struct gen_field_iterator iter;
> >  gen_field_iterator_init(, inst, p, 0, false);
> > @@ -309,7 +309,7 @@ static void
> >   handle_media_interface_descriptor_load(struct gen_batch_decode_ctx *ctx,
> >  const uint32_t *p)
> >   {
> > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > GEN_ENGINE_RENDER, p);
> >  struct gen_group *desc =
> > gen_spec_find_struct(ctx->spec, "INTERFACE_DESCRIPTOR_DATA");
> > @@ -373,7 +373,7 @@ static void
> >   handle_3dstate_vertex_buffers(struct gen_batch_decode_ctx *ctx,
> > const uint32_t *p)
> >   {
> > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > GEN_ENGINE_RENDER, p);
> >  struct gen_group *vbs = gen_spec_find_struct(ctx->spec, 
> > "VERTEX_BUFFER_STATE");
> >  struct gen_batch_decode_bo vb = {};
> > @@ -436,7 +436,7 @@ static void
> >   handle_3dstate_index_buffer(struct gen_batch_decode_ctx *ctx,
> >   const uint32_t *p)
> >   {
> > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > GEN_ENGINE_RENDER, p);
> >  struct gen_batch_decode_bo ib = {};
> >  uint32_t ib_size = 0;
> > @@ -486,7 +486,7 @@ handle_3dstate_index_buffer(struct gen_batch_decode_ctx 
> > *ctx,
> >   static void
> >   decode_single_ksp(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
> >   {
> > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > GEN_ENGINE_RENDER, p);
> >  uint64_t ksp = 0;
> >  bool is_simd8 = false; /* vertex shaders on Gen8+ only */
> > @@ -528,7 +528,7 @@ decode_single_ksp(struct gen_batch_decode_ctx *ctx, 
> > const uint32_t *p)
> >   static void
> >   decode_ps_kernels(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
> >   {
> > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > GEN_ENGINE_RENDER, p);
> >  uint64_t ksp[3] = {0, 0, 0};
> >  bool enabled[3] = {false, false, false};
> > @@ -576,7 +576,7 @@ decode_ps_kernels(struct gen_batch_decode_ctx *ctx, 
> > const uint32_t *p)
> >   static void
> >   decode_3dstate_constant(struct gen_batch_decode_ctx *ctx, const uint32_t 
> > *p)
> >   {
> > -   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
> > +   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
> > GEN_ENGINE_RENDER, p);
> >  struct gen_group *body =
> > gen_spec_find_struct(ctx->spec, "3DSTATE_CONSTANT_BODY");
> > @@ -658,7 +658,7 @@ decode_dynamic_state_pointers(struct 
> > 

Re: [Mesa-dev] [PATCH mesa] anv: only read the env once per process

[Jason Ekstrand]

NAK.  There's really no reason to do this.  If you're in the lost device
case, you've just done an ioctl (expensive) and got a GPU hang (5 second
watchdog timer).  Also, it adds complexity to something that very badly
needs to "just work".

--Jason

On Tue, Oct 30, 2018 at 11:09 AM Eric Engestrom 
wrote:

> Suggested-by: Emil Velikov 
> Signed-off-by: Eric Engestrom 
> ---
>  src/intel/vulkan/anv_device.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index ee35e013329005671391..d0e83546b1197e362874 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -2064,7 +2064,13 @@ _anv_device_set_lost(struct anv_device *device,
>   VK_ERROR_DEVICE_LOST, file, line, msg, ap);
> va_end(ap);
>
> -   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false))
> +   static bool abort_on_device_loss, env_read;
> +   if (!env_read) {
> +  abort_on_device_loss =
> env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false);
> +  env_read = true;
> +   }
> +
> +   if (abort_on_device_loss)
>abort();
>
> return err;
> --
> Cheers,
>   Eric
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] anv: only read the env once per process

[Eric Engestrom]

On Tuesday, 2018-10-30 16:09:49 +, Eric Engestrom wrote:
> Suggested-by: Emil Velikov 
> Signed-off-by: Eric Engestrom 
> ---

Sent the patch for the discussion, but I'm not sure this is that
important; this code is for when a device is lost, which is not very
common to say the least, and shaving off a few usec here isn't really
useful... come to think of it, this isn't worth the code complexity,
so I'm voting "leave it as is".

>  src/intel/vulkan/anv_device.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index ee35e013329005671391..d0e83546b1197e362874 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -2064,7 +2064,13 @@ _anv_device_set_lost(struct anv_device *device,
>   VK_ERROR_DEVICE_LOST, file, line, msg, ap);
> va_end(ap);
>  
> -   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false))
> +   static bool abort_on_device_loss, env_read;
> +   if (!env_read) {
> +  abort_on_device_loss = env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", 
> false);
> +  env_read = true;
> +   }
> +
> +   if (abort_on_device_loss)
>abort();
>  
> return err;
> -- 
> Cheers,
>   Eric
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa] anv: only read the env once per process

[Eric Engestrom]

Suggested-by: Emil Velikov 
Signed-off-by: Eric Engestrom 
---
 src/intel/vulkan/anv_device.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index ee35e013329005671391..d0e83546b1197e362874 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -2064,7 +2064,13 @@ _anv_device_set_lost(struct anv_device *device,
  VK_ERROR_DEVICE_LOST, file, line, msg, ap);
va_end(ap);
 
-   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false))
+   static bool abort_on_device_loss, env_read;
+   if (!env_read) {
+  abort_on_device_loss = env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", 
false);
+  env_read = true;
+   }
+
+   if (abort_on_device_loss)
   abort();
 
return err;
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [PATCH v2 2/4] Gallium: Add format PIPE_FORMAT_R8_SRGB

[Roland Scheidegger]

With the format ordering in svga_format.c as Ilia mentioned fixed
Reviewed-by: Roland Scheidegger 

Am 30.10.18 um 11:46 schrieb Gert Wollny:
> This format is needed to support EXT_texture_sRGB_R8. THe patch adds a new
> format enum, the format entries in Gallium and and svga, the mapping between
> sRGB and linear formats, and tests.
> 
>   v2: - add mapping to linear format for PIPE_FORMATR_R8_SRGB
>   v3: - Add texture format to svga format table since otherwise building
> mesa will fail when this driver is enabled. It was not tested
> whether the extension actually works.
>   v4: - svga: remove the SVGA specific format definitions and table entries
> and only add correct the location of PIPE_FORMAT_R8_SRGB in the
> format_conversion_table (Ilia Mirkin)
>   - Split patch (1/2) to separate Gallium part and mesa/st part.
> (Roland Scheidegger)
>   - Trim the commit message to only contain the relevant parts from the
> split.
> 
> Signed-off-by: Gert Wollny 
> ---
>  src/gallium/auxiliary/util/u_format.csv | 1 +
>  src/gallium/auxiliary/util/u_format.h   | 4 
>  src/gallium/auxiliary/util/u_format_tests.c | 4 
>  src/gallium/drivers/svga/svga_format.c  | 1 +
>  src/gallium/include/pipe/p_format.h | 2 ++
>  5 files changed, 12 insertions(+)
> 
> diff --git a/src/gallium/auxiliary/util/u_format.csv 
> b/src/gallium/auxiliary/util/u_format.csv
> index f9e4925f27..911ac07d32 100644
> --- a/src/gallium/auxiliary/util/u_format.csv
> +++ b/src/gallium/auxiliary/util/u_format.csv
> @@ -114,6 +114,7 @@ PIPE_FORMAT_I32_FLOAT , plain, 1, 1, f32 ,
>  , , , , r
>  
>  # SRGB formats
>  PIPE_FORMAT_L8_SRGB   , plain, 1, 1, un8 , , , , 
> xxx1, srgb 
> +PIPE_FORMAT_R8_SRGB   , plain, 1, 1, un8 , , , , 
> x001, srgb
>  PIPE_FORMAT_L8A8_SRGB , plain, 1, 1, un8 , un8 , , , 
> xxxy, srgb 
>  PIPE_FORMAT_R8G8B8_SRGB   , plain, 1, 1, un8 , un8 , un8 , , 
> xyz1, srgb 
>  PIPE_FORMAT_R8G8B8A8_SRGB , plain, 1, 1, un8 , un8 , un8 , un8 , 
> xyzw, srgb 
> diff --git a/src/gallium/auxiliary/util/u_format.h 
> b/src/gallium/auxiliary/util/u_format.h
> index e66849c16b..5bcfc1f115 100644
> --- a/src/gallium/auxiliary/util/u_format.h
> +++ b/src/gallium/auxiliary/util/u_format.h
> @@ -925,6 +925,8 @@ util_format_srgb(enum pipe_format format)
> switch (format) {
> case PIPE_FORMAT_L8_UNORM:
>return PIPE_FORMAT_L8_SRGB;
> +   case PIPE_FORMAT_R8_UNORM:
> +  return PIPE_FORMAT_R8_SRGB;
> case PIPE_FORMAT_L8A8_UNORM:
>return PIPE_FORMAT_L8A8_SRGB;
> case PIPE_FORMAT_R8G8B8_UNORM:
> @@ -1001,6 +1003,8 @@ util_format_linear(enum pipe_format format)
> switch (format) {
> case PIPE_FORMAT_L8_SRGB:
>return PIPE_FORMAT_L8_UNORM;
> +   case PIPE_FORMAT_R8_SRGB:
> +  return PIPE_FORMAT_R8_UNORM;
> case PIPE_FORMAT_L8A8_SRGB:
>return PIPE_FORMAT_L8A8_UNORM;
> case PIPE_FORMAT_R8G8B8_SRGB:
> diff --git a/src/gallium/auxiliary/util/u_format_tests.c 
> b/src/gallium/auxiliary/util/u_format_tests.c
> index 9c9a5838d1..dee52533c1 100644
> --- a/src/gallium/auxiliary/util/u_format_tests.c
> +++ b/src/gallium/auxiliary/util/u_format_tests.c
> @@ -236,6 +236,10 @@ util_format_test_cases[] =
> {PIPE_FORMAT_L8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xbc), 
> UNPACKED_1x1(0.502886458033, 0.502886458033, 0.502886458033, 1.0)},
> {PIPE_FORMAT_L8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xff), 
> UNPACKED_1x1(1.0, 1.0, 1.0, 1.0)},
>  
> +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0x00), 
> UNPACKED_1x1(0.0, 0.0, 0.0, 1.0)},
> +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xbc), 
> UNPACKED_1x1(0.502886458033, 0.0, 0.0, 1.0)},
> +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xff), 
> UNPACKED_1x1(1.0, 0.0, 0.0, 1.0)},
> +
> {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x), PACKED_1x16(0x), 
> UNPACKED_1x1(0.0, 0.0, 0.0, 0.0)},
> {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x), PACKED_1x16(0x00bc), 
> UNPACKED_1x1(0.502886458033, 0.502886458033, 0.502886458033, 0.0)},
> {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x), PACKED_1x16(0x00ff), 
> UNPACKED_1x1(1.0, 1.0, 1.0, 0.0)},
> diff --git a/src/gallium/drivers/svga/svga_format.c 
> b/src/gallium/drivers/svga/svga_format.c
> index 9f6a618706..bf1bbca3e2 100644
> --- a/src/gallium/drivers/svga/svga_format.c
> +++ b/src/gallium/drivers/svga/svga_format.c
> @@ -154,6 +154,7 @@ static const struct vgpu10_format_entry 
> format_conversion_table[] =
> { PIPE_FORMAT_R16G16B16_FLOAT,   SVGA3D_R16G16B16A16_FLOAT,  
> SVGA3D_FORMAT_INVALID,   SVGA3D_FORMAT_INVALID,   VF_W_TO_1 },
> { PIPE_FORMAT_R16G16B16A16_FLOAT,SVGA3D_R16G16B16A16_FLOAT,  
> SVGA3D_R16G16B16A16_FLOAT,   SVGA3D_R16G16B16A16_FLOAT,   TF_GEN_MIPS },
> { PIPE_FORMAT_L8_SRGB,   SVGA3D_FORMAT_INVALID,  
> 

[Mesa-dev] [Bug 108508] Graphic glitches with stream output support on OLAND AMD GPU GCN 1.0

[bugzilla-daemon]

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

--- Comment #14 from Ahmed Elsayed  ---
I tried many times to record both games with DXVK on but it failed to run. But
when I opened both games with DXVK off, the textures were very dark but there
were no graphic glitches.

-- 
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] anv: Handle the device loss abort in anv_device_set_lost

[Emil Velikov]

On Tue, 30 Oct 2018 at 15:07, Jason Ekstrand  wrote:
>
> On Tue, Oct 30, 2018 at 10:04 AM Emil Velikov  
> wrote:
>>
>> On Thu, 25 Oct 2018 at 17:47, Jason Ekstrand  wrote:
>> >
>> > ---
>> >  src/intel/vulkan/anv_device.c | 11 +++
>> >  src/intel/vulkan/anv_util.c   |  4 
>> >  2 files changed, 11 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
>> > index 79d3f052113..d62bdde078c 100644
>> > --- a/src/intel/vulkan/anv_device.c
>> > +++ b/src/intel/vulkan/anv_device.c
>> > @@ -2053,6 +2053,17 @@ void
>> >  anv_device_set_lost(struct anv_device *device, const char *msg, ...)
>> >  {
>> > device->_lost = true;
>> > +
>> > +   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false)) {
>>
>> If you're interested in shaving a micro second or two, you can do the
>> env_var_as_boolean once per device/instance/other.
>> Admittedly if the developer hits this path they have far greater
>> problems to deal with ;-)
>
>
> I don't think I care too much about aborting couple us faster. :P

The env. variable is read again and again, even if one doesn't abort.
But as said... quite a meh suggestion.

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

Re: [Mesa-dev] [PATCH 1/4] intel/decoder: tools: gen_engine enum location

[Toni Lönnberg]

I was thinking the exact same thing earlier but I didn't feel like changing too 
much of what was already there, thus keeping the enum. Can change it use the 
definition from uapi for v2.

On Tue, Oct 30, 2018 at 02:58:28PM +, Lionel Landwerlin wrote:
> I think we should switch to use drm_i915_gem_engine_class from
> include/drm-uapi/i915_drm.h and just have macro for class id -> mask.
> 
> On 30/10/2018 14:32, Toni Lönnberg wrote:
> > Moved the engine enum from aub_read.h to gen_decoder.h and changed it into a
> > bitmask. The enumeration needs to be defined in a single place that can be 
> > used
> > by the decoder and tools.
> > ---
> >   src/intel/common/gen_decoder.h | 6 ++
> >   src/intel/tools/aub_read.c | 1 +
> >   src/intel/tools/aub_read.h | 6 --
> >   3 files changed, 7 insertions(+), 6 deletions(-)
> > 
> > diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
> > index 4beed22d729..c2666d07e07 100644
> > --- a/src/intel/common/gen_decoder.h
> > +++ b/src/intel/common/gen_decoder.h
> > @@ -35,6 +35,12 @@
> >   extern "C" {
> >   #endif
> > +enum gen_engine {
> > +   GEN_ENGINE_RENDER  = (1 << 0),
> > +   GEN_ENGINE_VIDEO   = (1 << 1),
> > +   GEN_ENGINE_BLITTER = (1 << 2),
> > +};
> > +
> >   struct gen_spec;
> >   struct gen_group;
> >   struct gen_field;
> > diff --git a/src/intel/tools/aub_read.c b/src/intel/tools/aub_read.c
> > index d83e88ddced..7b951713b5b 100644
> > --- a/src/intel/tools/aub_read.c
> > +++ b/src/intel/tools/aub_read.c
> > @@ -28,6 +28,7 @@
> >   #include 
> >   #include "common/gen_gem.h"
> > +#include "common/gen_decoder.h"
> >   #include "util/macros.h"
> >   #include "aub_read.h"
> > diff --git a/src/intel/tools/aub_read.h b/src/intel/tools/aub_read.h
> > index e48ac3164bc..7f2f6f8105c 100644
> > --- a/src/intel/tools/aub_read.h
> > +++ b/src/intel/tools/aub_read.h
> > @@ -33,12 +33,6 @@
> >   extern "C" {
> >   #endif
> > -enum gen_engine {
> > -   GEN_ENGINE_RENDER = 1,
> > -   GEN_ENGINE_VIDEO = 2,
> > -   GEN_ENGINE_BLITTER = 3,
> > -};
> > -
> >   struct aub_read {
> >  /* Caller's data */
> >  void *user_data;
> 
> 
> ___
> 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 108601] gen_xmlpool.py fails if LANG=C.*

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Blocks||108530


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=108530
[Bug 108530] [Tracker] Mesa 18.3 Release Tracker
-- 
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 108530] [Tracker] Mesa 18.3 Release Tracker

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Depends on||108601


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=108601
[Bug 108601] gen_xmlpool.py fails if LANG=C.*
-- 
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 108601] gen_xmlpool.py fails if LANG=C.*

[bugzilla-daemon]

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

Bug ID: 108601
   Summary: gen_xmlpool.py fails if LANG=C.*
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: baker.dyla...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

This is due to gen_xmlpool.py writing to stdout, and stdout receiving unicode
code points.

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

Re: [Mesa-dev] [PATCH v2] autotools: library-dependency when no sse and 32-bit

[Dylan Baker]

Reviewed-by: Dylan Baker 

Quoting Sergii Romantsov (2018-10-30 02:45:14)
> Building of 32bit Mesa may fail if __SSE__ is not specified.
> Added missed dependency from libm.
> 
> CC: Dylan Baker 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
> Signed-off-by: Sergii Romantsov 
> ---
>  src/util/Makefile.am | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/util/Makefile.am b/src/util/Makefile.am
> index d79f2b3..85c7553 100644
> --- a/src/util/Makefile.am
> +++ b/src/util/Makefile.am
> @@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
> $(PTHREAD_LIBS) \
> $(CLOCK_LIB) \
> $(ZLIB_LIBS) \
> -   $(LIBATOMIC_LIBS)
> +   $(LIBATOMIC_LIBS) \
> +   -lm
>  
>  libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
>  libxmlconfig_la_CFLAGS = \
> -- 
> 2.7.4
> 


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

Re: [Mesa-dev] [PATCH mesa] meson: add note about intel tools build options

[Dylan Baker]

Reviewed-by: Dylan Baker 

Quoting Eric Engestrom (2018-10-30 04:28:56)
> Fixes: ea83a1d304dc97d1d155a "intel: tools: import ImGui"
> Signed-off-by: Eric Engestrom 
> ---
>  meson_options.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson_options.txt b/meson_options.txt
> index 606ae9de6a4f760f84e6..97b3c8f0461f5713a98e 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -302,7 +302,7 @@ option(
>type : 'array',
>value : [],
>choices : ['freedreno', 'glsl', 'intel', 'intel-ui', 'nir', 'nouveau', 
> 'xvmc', 'all'],
> -  description : 'List of tools to build.',
> +  description : 'List of tools to build. (Note: `intel-ui` selects `intel`)',
>  )
>  option(
>'power8',
> -- 
> Cheers,
>   Eric
> 


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

Re: [Mesa-dev] [RFC] freedreno: import libdrm_freedreno + redesign submit

[Emil Velikov]

On Thu, 25 Oct 2018 at 10:32, Eric Engestrom  wrote:
>
> On Tuesday, 2018-10-23 10:49:26 -0400, mesa-dev-boun...@lists.freedesktop.org 
> wrote:
> > In the pursuit of lowering driver overhead, it became clear that some
> > amount of redesign of how libdrm_freedreno constructs the submit ioctl
> > would be needed.  In particular, as the gallium driver is starting to
> > make heavier use of CP_SET_DRAW_STATE state groups/objects, the over-
> > head of tracking cmd buffers and relocs becomes too much.  And for
> > "streaming" state, which isn't ever reused (like uniform uploads) the
> > overhead of allocating/freeing ringbuffer[1] objects is too high.
> >
> > This redesign makes two main changes:
> >
> >  1) Introduces a fd_submit object for tracking bos and cmds table
> > for the submit ioctl, making ringbuffer objects more light-
> > weight.  This was previously done in the ringbuffer.  But we
> > have many ringbuffer instances involved in a submit (gmem +
> > draw + potentially 1000's of state-group rbs), and only need
> > a single bos and cmds table.  (Reloc table is still per-rb)
> >
> > The submit is also a convenient place for a slab allocator for
> > ringbuffer objects.  Other options would have required locking
> > because, while we can guarantee allocations will only happen on
> > a single thread, free's could happen either on the application
> > thread or the flush_queue thread.  With the slab allocator in
> > the submit object, any frees that happen on the flush_queue
> > thread happen after we know that the application thread is done
> > with the submit.
> >
> >  2) Introduce a new "softpin" msm_ringbuffer_sp implementation that
> > does not use relocs and only has cmds table entries for IB1 (ie.
> > the cmdstream buffers that kernel needs to CP_INDIRECT_BUFFER
> > to from the RB).  To do this properly will require some updates
> > on the kernel side, so whether you get the softpin or legacy
> > submit/ringbuffer implementation at runtime depends on your
> > kernel version.
> >
> > To make all these changes in libdrm would basically require adding a
> > libdrm_freedreno2, so this is a good point to just pull the libdrm code
> > into mesa.  Plus it allows for using mesa's hashtable, slab allocator,
> > etc.  And it lets us have asserts enabled for debug mesa buids but
> > omitted for release builds.  And it makes life easier if further API
> > changes become necessary.
> >
libdrm_freedreno made sense when there was more than one user. Since
xf86-video-freedreno is a dead end it's better to make your life
easier.

> > At this point I haven't tried to pull in the kgsl backend.  Although
> > I left the level of vfunc indirection which would make it possible
> > to have other backends.  (And this was convenient to keep to allow
> > for the "softpin" ringbuffer to coexist.)
> >
Does that code even work with the latest kernel kgsl code?
I thought wasn't compatible for years.

> > NOTE: if bisecting a build error takes you hear, try a clean build.
> > There are a bunch of ways things can go wrong if you still have
> > libdrm_freedreno cflags.
>
> Good note!
> (and s/hear/here/)
>
Or to make the note disappear and minimise the chance to even getting
here you can try the following:
 - patch 1 - dummy copy, mention the sha used as base
 - patch 2/3/4 - wire up Autoconf/Android/meson
 - patch 5/... - polish (remove freedreno_drmif.h includes and others)

It'll make it far easier to verity, read and provide meaningful review.

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

Re: [Mesa-dev] [PATCH 00/31] nir: Use a 1-bit data type for booleans

[Jason Ekstrand]

On Tue, Oct 30, 2018 at 2:50 AM Iago Toral  wrote:

> Some quick comments on this after experimenting with it:
>
> Intel hardware produces booleans of the same bit-size as the operations
> that generates them so I am working on expanding this to add another
> lowering pass that can lower them to smaller bit-sizes.
>
> I have a work-in-progress prototype of this and it is significantly
> easier, at least for us, to do this as a lowering pass in NIR SSA form
> than in the backend. Specifically, doing it in the backend means that
> we have to deal with propagating the bit-sizes of the booleans across
> operation chains and across CFG blocks, which isn't fun.
>
> There are still a few things that I am figuring out:
>
> Right now I lower instructions as I find them, deciding about the bit-
> size of the destination based on the bit-size of the sources. This
> usually works fine because by the time we reach an instruction that
> reads boolean sources we have already lowered the instructions that
> produced them. However, this also means that we need to make decisions
> about the bit-sizes of constant booleans before we know which bit-size
> is required for them, it could be that we need them as 32-bit booleans
> only, 16-bit booleans only, or maybe both. Right now I am assuming that
> constants are 32-bit always, which means that at the moment I have to
> inject a MOV when they are used in 16-bit instructions. We can probably
> do better, at least in some cases, if we inspect all uses of the
> constants before we lower them.
>

If we did a step of constant folding, wouldn't the constant booleans get
nicely folded to the right bit-size?


> Another thing we need to deal with is canonicalization. Some
> instructions may have boolean sources of different native bit-sizes and
> it looks like we need to choose a canonical bit-size for them in this
> case (at least in my experiments this seems to be required for Intel).
> For now I am just taking the bit-size of the first source as the
> canonical form, but we could try to be smarter about this. In the case
> of Intel I think this isn't too bad, because constant operands are
> usually second, so for instructions that use a boolean immediate, if we
> choose the first source as canonical, we can then adjust the imediate
> source without having to emit additional instructions. Unfortunately,
> the 16-bit integer tests in CTS are not good to test set for
> canonicalization, since they focus very specifically in 16-bit paths
> and I don't think we have many cases (if any) of boolean instructions
> mixing booleans of different bit-sizzes, so we will probably have to
> try and write our more tests to exercise these cases properly. Also, it
> might be that some hardware that supports multiple bit-sized booleans
> doesn't require canonicalization, in which case we might want to do
> this configurable.
>

Assuming a back-end that can properly handle 8 and 16-bit booleans, I
suspect "always go down" would be a reasonable for two reasons:

 1) It always uses no more bits than the biggest so it helps with register
pressure
 2) We can do the conversion "for free" either with a mixed-type operation
(or of D and W) or, if that doesn't work, by using a register region to
just reinterpret the D as a scattered out W.

For that matter, there's a part of me that's tempted to always spill to
8-bit for everything other than the comparison operation itself.  Again,
this is all dependent on having a competent back-end compiler which we
currently don't have. :-(


> Another thing I noticed, is that with phi sources the canonicalization
> aspect is a bit trickier, since we can't just insert conversions before
> the phi instructions (nir_validate complains that this is not allowed),
> so instead we need to get to the instruction that generated the ssa
> source and inject the conversion after it.
>

There's a nifty nir_before_src cursor builder function that correctly
handles phis.


> Last thing I noticed is that our backend optimizer is much better at
> optimizing 32-bit booleans that it is at optimizing 16-bit, so there
> are some cases where we end up producing worse code. Obviously this is
> not a problem of the NIR lowering pass though, it just means that we
> need to do better at optimizing 16-bit code in the backend.
>
> So all in all, I am quite happy with this. It is certainly easier than
> lowering in the backend and it gives us a more reasonable framework to
> work with. We still need to do some extra work if we want to do the
> best lowering for things like boolean constants or canonicalization,
> but since neither SPIR-V nor GLSL define multiple bit-sizes for
> booleans that would always have been something that drivers might need
> to address.
>
> Iago
>
>
> On Mon, 2018-10-22 at 17:13 -0500, Jason Ekstrand wrote:
> > This is something that Connor and I have talked about quite a bit
> > over the
> > last couple of months.  The core idea is to replace NIR's current 32-
> > bit
> > 

Re: [Mesa-dev] [PATCH 3/3] anv: Handle the device loss abort in anv_device_set_lost

[Jason Ekstrand]

On Tue, Oct 30, 2018 at 10:04 AM Emil Velikov 
wrote:

> On Thu, 25 Oct 2018 at 17:47, Jason Ekstrand  wrote:
> >
> > ---
> >  src/intel/vulkan/anv_device.c | 11 +++
> >  src/intel/vulkan/anv_util.c   |  4 
> >  2 files changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_device.c
> b/src/intel/vulkan/anv_device.c
> > index 79d3f052113..d62bdde078c 100644
> > --- a/src/intel/vulkan/anv_device.c
> > +++ b/src/intel/vulkan/anv_device.c
> > @@ -2053,6 +2053,17 @@ void
> >  anv_device_set_lost(struct anv_device *device, const char *msg, ...)
> >  {
> > device->_lost = true;
> > +
> > +   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false)) {
>
> If you're interested in shaving a micro second or two, you can do the
> env_var_as_boolean once per device/instance/other.
> Admittedly if the developer hits this path they have far greater
> problems to deal with ;-)
>

I don't think I care too much about aborting couple us faster. :P
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] anv: Handle the device loss abort in anv_device_set_lost

[Emil Velikov]

On Thu, 25 Oct 2018 at 17:47, Jason Ekstrand  wrote:
>
> ---
>  src/intel/vulkan/anv_device.c | 11 +++
>  src/intel/vulkan/anv_util.c   |  4 
>  2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 79d3f052113..d62bdde078c 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -2053,6 +2053,17 @@ void
>  anv_device_set_lost(struct anv_device *device, const char *msg, ...)
>  {
> device->_lost = true;
> +
> +   if (env_var_as_boolean("ANV_ABORT_ON_DEVICE_LOSS", false)) {

If you're interested in shaving a micro second or two, you can do the
env_var_as_boolean once per device/instance/other.
Admittedly if the developer hits this path they have far greater
problems to deal with ;-)

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

Re: [Mesa-dev] [PATCH 0/4] Engine parameter for instructions

[Lionel Landwerlin]

If you could put the branch somewhere so I could skim through the xml 
changes.


Thanks,

-
Lionel

On 30/10/2018 14:32, Toni Lönnberg wrote:

These patches add an engine parameter to the instructions defined in the genxml
files so that they can be distinguished when sending them to different engines.
By default, an instruction is defined to be used by all engines and is defined
for a specific engine by adding the parameter "engine" to the definition.
Currently the supported engines are "render", "video" and "blitter".

Toni Lönnberg (4):
   intel/decoder: tools: gen_engine enum location
   intel/decoder: Engine parameter for instructions
   intel/decoder: tools: Use engine for decoding batch instructions
   intel/genxml: Add engine definitions to render engine instruction

  src/intel/common/gen_batch_decoder.c  |  21 +-
  src/intel/common/gen_decoder.c|  13 +-
  src/intel/common/gen_decoder.h|  10 +-
  src/intel/genxml/gen10.xml| 206 -
  src/intel/genxml/gen11.xml| 208 +-
  src/intel/genxml/gen4.xml |  36 +--
  src/intel/genxml/gen45.xml|  38 ++--
  src/intel/genxml/gen5.xml |  44 ++--
  src/intel/genxml/gen6.xml |  94 
  src/intel/genxml/gen7.xml | 154 ++---
  src/intel/genxml/gen75.xml| 184 
  src/intel/genxml/gen8.xml | 202 -
  src/intel/genxml/gen9.xml | 208 +-
  src/intel/tools/aub_read.c|   1 +
  src/intel/tools/aub_read.h|   6 -
  src/intel/tools/aubinator.c   |   5 +-
  src/intel/tools/aubinator_error_decode.c  |  19 +-
  src/mesa/drivers/dri/i965/intel_batchbuffer.c |   3 +-
  18 files changed, 741 insertions(+), 711 deletions(-)



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

Re: [Mesa-dev] [PATCH 1/4] intel/decoder: tools: gen_engine enum location

[Lionel Landwerlin]

I think we should switch to use drm_i915_gem_engine_class from 
include/drm-uapi/i915_drm.h and just have macro for class id -> mask.


On 30/10/2018 14:32, Toni Lönnberg wrote:

Moved the engine enum from aub_read.h to gen_decoder.h and changed it into a
bitmask. The enumeration needs to be defined in a single place that can be used
by the decoder and tools.
---
  src/intel/common/gen_decoder.h | 6 ++
  src/intel/tools/aub_read.c | 1 +
  src/intel/tools/aub_read.h | 6 --
  3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index 4beed22d729..c2666d07e07 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -35,6 +35,12 @@
  extern "C" {
  #endif
  
+enum gen_engine {

+   GEN_ENGINE_RENDER  = (1 << 0),
+   GEN_ENGINE_VIDEO   = (1 << 1),
+   GEN_ENGINE_BLITTER = (1 << 2),
+};
+
  struct gen_spec;
  struct gen_group;
  struct gen_field;
diff --git a/src/intel/tools/aub_read.c b/src/intel/tools/aub_read.c
index d83e88ddced..7b951713b5b 100644
--- a/src/intel/tools/aub_read.c
+++ b/src/intel/tools/aub_read.c
@@ -28,6 +28,7 @@
  #include 
  
  #include "common/gen_gem.h"

+#include "common/gen_decoder.h"
  #include "util/macros.h"
  
  #include "aub_read.h"

diff --git a/src/intel/tools/aub_read.h b/src/intel/tools/aub_read.h
index e48ac3164bc..7f2f6f8105c 100644
--- a/src/intel/tools/aub_read.h
+++ b/src/intel/tools/aub_read.h
@@ -33,12 +33,6 @@
  extern "C" {
  #endif
  
-enum gen_engine {

-   GEN_ENGINE_RENDER = 1,
-   GEN_ENGINE_VIDEO = 2,
-   GEN_ENGINE_BLITTER = 3,
-};
-
  struct aub_read {
 /* Caller's data */
 void *user_data;



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

Re: [Mesa-dev] [PATCH 3/4] intel/decoder: tools: Use engine for decoding batch instructions

[Lionel Landwerlin]

Since a batch will be given to a specific engine, the engine won't 
change change while decoding.
So I would just store the engine into gen_batch_decode_ctx and set it in 
the init function, that'll reduce the diff a bit.


Then just introduce a local find_instruction() function that calls 
gen_spec_find_instruction(ctx->spec, ctx->engine, p).


Thanks,

-
Lionel

On 30/10/2018 14:32, Toni Lönnberg wrote:

The engine to which the batch was sent to is now passed along when decoding the
batch. This is needed so that we can distinguish between instructions as the
render and video pipe share some of the instruction opcodes.
---
  src/intel/common/gen_batch_decoder.c  | 21 ++-
  src/intel/common/gen_decoder.c|  4 ++--
  src/intel/common/gen_decoder.h|  3 ++-
  src/intel/tools/aubinator.c   |  5 ++---
  src/intel/tools/aubinator_error_decode.c  | 19 -
  src/mesa/drivers/dri/i965/intel_batchbuffer.c |  3 ++-
  6 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/src/intel/common/gen_batch_decoder.c 
b/src/intel/common/gen_batch_decoder.c
index 63f04627572..8bd256d10e9 100644
--- a/src/intel/common/gen_batch_decoder.c
+++ b/src/intel/common/gen_batch_decoder.c
@@ -195,7 +195,7 @@ ctx_print_buffer(struct gen_batch_decode_ctx *ctx,
  static void
  handle_state_base_address(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
  {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  
 struct gen_field_iterator iter;

 gen_field_iterator_init(, inst, p, 0, false);
@@ -309,7 +309,7 @@ static void
  handle_media_interface_descriptor_load(struct gen_batch_decode_ctx *ctx,
 const uint32_t *p)
  {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
 struct gen_group *desc =
gen_spec_find_struct(ctx->spec, "INTERFACE_DESCRIPTOR_DATA");
  
@@ -373,7 +373,7 @@ static void

  handle_3dstate_vertex_buffers(struct gen_batch_decode_ctx *ctx,
const uint32_t *p)
  {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
 struct gen_group *vbs = gen_spec_find_struct(ctx->spec, 
"VERTEX_BUFFER_STATE");
  
 struct gen_batch_decode_bo vb = {};

@@ -436,7 +436,7 @@ static void
  handle_3dstate_index_buffer(struct gen_batch_decode_ctx *ctx,
  const uint32_t *p)
  {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  
 struct gen_batch_decode_bo ib = {};

 uint32_t ib_size = 0;
@@ -486,7 +486,7 @@ handle_3dstate_index_buffer(struct gen_batch_decode_ctx 
*ctx,
  static void
  decode_single_ksp(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
  {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  
 uint64_t ksp = 0;

 bool is_simd8 = false; /* vertex shaders on Gen8+ only */
@@ -528,7 +528,7 @@ decode_single_ksp(struct gen_batch_decode_ctx *ctx, const 
uint32_t *p)
  static void
  decode_ps_kernels(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
  {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  
 uint64_t ksp[3] = {0, 0, 0};

 bool enabled[3] = {false, false, false};
@@ -576,7 +576,7 @@ decode_ps_kernels(struct gen_batch_decode_ctx *ctx, const 
uint32_t *p)
  static void
  decode_3dstate_constant(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
  {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
 struct gen_group *body =
gen_spec_find_struct(ctx->spec, "3DSTATE_CONSTANT_BODY");
  
@@ -658,7 +658,7 @@ decode_dynamic_state_pointers(struct gen_batch_decode_ctx *ctx,

const char *struct_type, const uint32_t *p,
int count)
  {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
  
 uint32_t state_offset = 0;
  
@@ -794,6 +794,7 @@ struct custom_decoder {
  
  void

  gen_print_batch(struct gen_batch_decode_ctx *ctx,
+enum gen_engine engine,
  const uint32_t *batch, uint32_t batch_size,
  uint64_t batch_addr)
  {
@@ -802,7 +803,7 @@ gen_print_batch(struct gen_batch_decode_ctx *ctx,
 struct 

Re: [Mesa-dev] [PATCH 2/2] kmsro: Extend to include hx8357d.

[Emil Velikov]

Hi Eric,

On Thu, 25 Oct 2018 at 17:39, Eric Anholt  wrote:
>
> This allows vc4 to initialize on the Adafruit PiTFT 3.5" touchscreen with
> the new tinydrm driver I just submitted.  If this series extending the
> pl111/kmsro driver is accepted, then I'll extend kmsro with the other
> tinydrm drivers as well.

Have you considered teaching the DRI loader about this? Unlike the
tegra driver there's nothing special going on here.
Create a dumb buffer on the DC, export as dmabuf and let the GPU draw into it.

Perhaps with we can have some code for the DC <> GPU mapping and at
later stage move it to an external file.
This way adding new combinations will be trivial addition to that,
instead of having yet another driver.

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

Re: [Mesa-dev] [PATCH] vulkan/wsi/wayland: Respect non-blocking AcquireNextImage

[Jason Ekstrand]

Acked-by: Jason Ekstrand 

On Tue, Oct 30, 2018 at 7:56 AM Daniel Stone  wrote:

> If the client has requested that AcquireNextImage not block at all, with
> a timeout of 0, then don't make any non-blocking calls.
>
> This will still potentially block infinitely given a non-infinte
> timeout, but the fix for that is much more involved.
>
> Signed-off-by: Daniel Stone 
> Cc: mesa-sta...@lists.freedesktop.org
> Cc: Chad Versace 
> Cc: Jason Ekstrand 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108540
> ---
>  src/vulkan/wsi/wsi_common_wayland.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/src/vulkan/wsi/wsi_common_wayland.c
> b/src/vulkan/wsi/wsi_common_wayland.c
> index e9cc22ec603..981243d8b14 100644
> --- a/src/vulkan/wsi/wsi_common_wayland.c
> +++ b/src/vulkan/wsi/wsi_common_wayland.c
> @@ -699,9 +699,14 @@ wsi_wl_swapchain_acquire_next_image(struct
> wsi_swapchain *wsi_chain,
>   }
>}
>
> -  /* This time we do a blocking dispatch because we can't go
> -   * anywhere until we get an event.
> +  /* We now have to do a blocking dispatch, because all our images
> +   * are in use and we cannot return one until the server does.
> However,
> +   * if the client has requested non-blocking ANI, then we tell it up
> front
> +   * that we have nothing to return.
> */
> +  if (info->timeout == 0)
> + return VK_NOT_READY;
> +
>int ret = wl_display_roundtrip_queue(chain->display->wl_display,
> chain->display->queue);
>if (ret < 0)
> --
> 2.19.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 10/12] util: s/0/NULL/ for pointer

[Emil Velikov]

On Mon, 29 Oct 2018 at 17:17, Eric Engestrom  wrote:
>
> Signed-off-by: Eric Engestrom 
> ---
>  src/util/u_dynarray.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/util/u_dynarray.h b/src/util/u_dynarray.h
> index c1aa79c8ac6ca8fce810..9bed2b9c25c879672e22 100644
> --- a/src/util/u_dynarray.h
> +++ b/src/util/u_dynarray.h
> @@ -134,7 +134,7 @@ util_dynarray_trim(struct util_dynarray *buf)
>   } else {
>  free(buf->data);
>   }
> - buf->data = 0;
> + buf->data = NULL;

Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH mesa 05/12] mesa: fix memset(0) of non-trivial structs

[Emil Velikov]

On Mon, 29 Oct 2018 at 17:17, Eric Engestrom  wrote:
>
> Signed-off-by: Eric Engestrom 

Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH mesa 07/12] i965: turn "unreachable" assert() into unreachable()

[Emil Velikov]

On Mon, 29 Oct 2018 at 17:17, Eric Engestrom  wrote:
>
> Signed-off-by: Eric Engestrom 
> ---
>  src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c 
> b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
> index b6bf96706f837606dcd6..627a18027cd13ada959b 100644
> --- a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
> +++ b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
> @@ -604,7 +604,7 @@ choose_copy_function(mem_copy_fn_type copy_type)
>return _memcpy_streaming_load;
>  #endif
> default:
> -  assert(!"unreachable");
> +  unreachable("unhandled copy_type");


I'd squash this with the Wswitch patch?

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

Re: [Mesa-dev] [PATCH mesa 08/12] i965: add missing case to fix -Wswitch

[Emil Velikov]

On Mon, 29 Oct 2018 at 17:17, Eric Engestrom  wrote:
>
> Signed-off-by: Eric Engestrom 

Reviewed-by: Emil Velikov 

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

[Mesa-dev] [PATCH 3/4] intel/decoder: tools: Use engine for decoding batch instructions

[Toni Lönnberg]

The engine to which the batch was sent to is now passed along when decoding the
batch. This is needed so that we can distinguish between instructions as the
render and video pipe share some of the instruction opcodes.
---
 src/intel/common/gen_batch_decoder.c  | 21 ++-
 src/intel/common/gen_decoder.c|  4 ++--
 src/intel/common/gen_decoder.h|  3 ++-
 src/intel/tools/aubinator.c   |  5 ++---
 src/intel/tools/aubinator_error_decode.c  | 19 -
 src/mesa/drivers/dri/i965/intel_batchbuffer.c |  3 ++-
 6 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/src/intel/common/gen_batch_decoder.c 
b/src/intel/common/gen_batch_decoder.c
index 63f04627572..8bd256d10e9 100644
--- a/src/intel/common/gen_batch_decoder.c
+++ b/src/intel/common/gen_batch_decoder.c
@@ -195,7 +195,7 @@ ctx_print_buffer(struct gen_batch_decode_ctx *ctx,
 static void
 handle_state_base_address(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
 {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
 
struct gen_field_iterator iter;
gen_field_iterator_init(, inst, p, 0, false);
@@ -309,7 +309,7 @@ static void
 handle_media_interface_descriptor_load(struct gen_batch_decode_ctx *ctx,
const uint32_t *p)
 {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
struct gen_group *desc =
   gen_spec_find_struct(ctx->spec, "INTERFACE_DESCRIPTOR_DATA");
 
@@ -373,7 +373,7 @@ static void
 handle_3dstate_vertex_buffers(struct gen_batch_decode_ctx *ctx,
   const uint32_t *p)
 {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
struct gen_group *vbs = gen_spec_find_struct(ctx->spec, 
"VERTEX_BUFFER_STATE");
 
struct gen_batch_decode_bo vb = {};
@@ -436,7 +436,7 @@ static void
 handle_3dstate_index_buffer(struct gen_batch_decode_ctx *ctx,
 const uint32_t *p)
 {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
 
struct gen_batch_decode_bo ib = {};
uint32_t ib_size = 0;
@@ -486,7 +486,7 @@ handle_3dstate_index_buffer(struct gen_batch_decode_ctx 
*ctx,
 static void
 decode_single_ksp(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
 {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
 
uint64_t ksp = 0;
bool is_simd8 = false; /* vertex shaders on Gen8+ only */
@@ -528,7 +528,7 @@ decode_single_ksp(struct gen_batch_decode_ctx *ctx, const 
uint32_t *p)
 static void
 decode_ps_kernels(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
 {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
 
uint64_t ksp[3] = {0, 0, 0};
bool enabled[3] = {false, false, false};
@@ -576,7 +576,7 @@ decode_ps_kernels(struct gen_batch_decode_ctx *ctx, const 
uint32_t *p)
 static void
 decode_3dstate_constant(struct gen_batch_decode_ctx *ctx, const uint32_t *p)
 {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
struct gen_group *body =
   gen_spec_find_struct(ctx->spec, "3DSTATE_CONSTANT_BODY");
 
@@ -658,7 +658,7 @@ decode_dynamic_state_pointers(struct gen_batch_decode_ctx 
*ctx,
   const char *struct_type, const uint32_t *p,
   int count)
 {
-   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, 
GEN_ENGINE_RENDER, p);
 
uint32_t state_offset = 0;
 
@@ -794,6 +794,7 @@ struct custom_decoder {
 
 void
 gen_print_batch(struct gen_batch_decode_ctx *ctx,
+enum gen_engine engine,
 const uint32_t *batch, uint32_t batch_size,
 uint64_t batch_addr)
 {
@@ -802,7 +803,7 @@ gen_print_batch(struct gen_batch_decode_ctx *ctx,
struct gen_group *inst;
 
for (p = batch; p < end; p += length) {
-  inst = gen_spec_find_instruction(ctx->spec, p);
+  inst = gen_spec_find_instruction(ctx->spec, engine, p);
   length = gen_group_get_length(inst, p);
   assert(inst == NULL || length > 0);
   length = MAX2(1, length);
@@ -871,7 +872,7 @@ gen_print_batch(struct gen_batch_decode_ctx *ctx,
 fprintf(ctx->fp, "Secondary batch at 0x%08"PRIx64" unavailable\n",
 

[Mesa-dev] [PATCH 2/4] intel/decoder: Engine parameter for instructions

[Toni Lönnberg]

Preliminary work for adding handling of different pipes to gen_decoder. Each
instruction needs to have a definition describing which engine it is meant for.
If left undefined, by default, the instruction is defined for all engines.
---
 src/intel/common/gen_decoder.c | 9 +
 src/intel/common/gen_decoder.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index 8148b2f1489..f4f8af3c5ae 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -165,6 +165,7 @@ create_group(struct parser_context *ctx,
group->fixed_length = fixed_length;
group->dword_length_field = NULL;
group->dw_length = 0;
+   group->engine = GEN_ENGINE_RENDER | GEN_ENGINE_VIDEO | GEN_ENGINE_BLITTER;
group->bias = 1;
 
for (int i = 0; atts[i]; i += 2) {
@@ -173,6 +174,14 @@ create_group(struct parser_context *ctx,
  group->dw_length = strtoul(atts[i + 1], , 0);
   } else if (strcmp(atts[i], "bias") == 0) {
  group->bias = strtoul(atts[i + 1], , 0);
+  } else if (strcmp(atts[i], "engine") == 0) {
+ if (strcmp(atts[i + 1], "render") == 0) {
+group->engine = GEN_ENGINE_RENDER;
+ } else if (strcmp(atts[i + 1], "video") == 0) {
+group->engine = GEN_ENGINE_VIDEO;
+ } else if (strcmp(atts[i + 1], "blitter") == 0) {
+group->engine = GEN_ENGINE_BLITTER;
+ }
   }
}
 
diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index c2666d07e07..b179ae8f380 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -108,6 +108,7 @@ struct gen_group {
struct gen_field *dword_length_field; /*  specific */
 
uint32_t dw_length;
+   uint32_t engine; /*  specific */
uint32_t bias; /*  specific */
uint32_t group_offset, group_count;
uint32_t group_size;
-- 
2.17.1

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

[Mesa-dev] [PATCH 0/4] Engine parameter for instructions

[Toni Lönnberg]

These patches add an engine parameter to the instructions defined in the genxml 
files so that they can be distinguished when sending them to different engines. 
By default, an instruction is defined to be used by all engines and is defined 
for a specific engine by adding the parameter "engine" to the definition. 
Currently the supported engines are "render", "video" and "blitter".

Toni Lönnberg (4):
  intel/decoder: tools: gen_engine enum location
  intel/decoder: Engine parameter for instructions
  intel/decoder: tools: Use engine for decoding batch instructions
  intel/genxml: Add engine definitions to render engine instruction

 src/intel/common/gen_batch_decoder.c  |  21 +-
 src/intel/common/gen_decoder.c|  13 +-
 src/intel/common/gen_decoder.h|  10 +-
 src/intel/genxml/gen10.xml| 206 -
 src/intel/genxml/gen11.xml| 208 +-
 src/intel/genxml/gen4.xml |  36 +--
 src/intel/genxml/gen45.xml|  38 ++--
 src/intel/genxml/gen5.xml |  44 ++--
 src/intel/genxml/gen6.xml |  94 
 src/intel/genxml/gen7.xml | 154 ++---
 src/intel/genxml/gen75.xml| 184 
 src/intel/genxml/gen8.xml | 202 -
 src/intel/genxml/gen9.xml | 208 +-
 src/intel/tools/aub_read.c|   1 +
 src/intel/tools/aub_read.h|   6 -
 src/intel/tools/aubinator.c   |   5 +-
 src/intel/tools/aubinator_error_decode.c  |  19 +-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c |   3 +-
 18 files changed, 741 insertions(+), 711 deletions(-)

-- 
2.17.1

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

[Mesa-dev] [PATCH 1/4] intel/decoder: tools: gen_engine enum location

[Toni Lönnberg]

Moved the engine enum from aub_read.h to gen_decoder.h and changed it into a
bitmask. The enumeration needs to be defined in a single place that can be used
by the decoder and tools.
---
 src/intel/common/gen_decoder.h | 6 ++
 src/intel/tools/aub_read.c | 1 +
 src/intel/tools/aub_read.h | 6 --
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index 4beed22d729..c2666d07e07 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -35,6 +35,12 @@
 extern "C" {
 #endif
 
+enum gen_engine {
+   GEN_ENGINE_RENDER  = (1 << 0),
+   GEN_ENGINE_VIDEO   = (1 << 1),
+   GEN_ENGINE_BLITTER = (1 << 2),
+};
+
 struct gen_spec;
 struct gen_group;
 struct gen_field;
diff --git a/src/intel/tools/aub_read.c b/src/intel/tools/aub_read.c
index d83e88ddced..7b951713b5b 100644
--- a/src/intel/tools/aub_read.c
+++ b/src/intel/tools/aub_read.c
@@ -28,6 +28,7 @@
 #include 
 
 #include "common/gen_gem.h"
+#include "common/gen_decoder.h"
 #include "util/macros.h"
 
 #include "aub_read.h"
diff --git a/src/intel/tools/aub_read.h b/src/intel/tools/aub_read.h
index e48ac3164bc..7f2f6f8105c 100644
--- a/src/intel/tools/aub_read.h
+++ b/src/intel/tools/aub_read.h
@@ -33,12 +33,6 @@
 extern "C" {
 #endif
 
-enum gen_engine {
-   GEN_ENGINE_RENDER = 1,
-   GEN_ENGINE_VIDEO = 2,
-   GEN_ENGINE_BLITTER = 3,
-};
-
 struct aub_read {
/* Caller's data */
void *user_data;
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH mesa 06/12] mesa: fix struct/class mismatch

[Emil Velikov]

On Mon, 29 Oct 2018 at 17:16, Eric Engestrom  wrote:
>
> Signed-off-by: Eric Engestrom 

Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH mesa 01/12] scons: drop unused HAVE_STDINT_H macro

[Emil Velikov]

On Mon, 29 Oct 2018 at 17:16, Eric Engestrom  wrote:
>
> Signed-off-by: Eric Engestrom 

I'd add some commit message here. The check/macro was required in the
earlier days, when MSVC did not provide the header.
Since the 2013 version (or was it earlier) it's around... just 14
years after the C99 standard ;-)

Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH mesa 12/12] egl: add messages to a few assert() and turn a couple into unreachable()

[Emil Velikov]

On Mon, 29 Oct 2018 at 17:16, Eric Engestrom  wrote:
>
> Signed-off-by: Eric Engestrom 
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 07/31] nir/opt_if: Rework condition propagation

[Jason Ekstrand]

Weird.  I didn't expect this patch to have any impact whatsoever. I thought 
it was just moving around the way we emit stuff.


On October 30, 2018 08:40:01 Iago Toral  wrote:


Jason, JFYI, I have been looking into the cases where the boolean
bitsize lowering pass was producing worse instruction counts that the
default 32-bit pass and I have tracked it down to this patch. Reverting
this makes the instruction count much better for some tests, I'll check
why this happens tomorrow.

Iago

On Mon, 2018-10-22 at 17:13 -0500, Jason Ekstrand wrote:

Instead of doing our own constant folding, we just emit instructions
and
let constant folding happen.  This is substantially simpler and lets
us
use the nir_imm_bool helper instead of dealing with the const_value's
ourselves.
---
 src/compiler/nir/nir_opt_if.c | 91 -
--
 1 file changed, 30 insertions(+), 61 deletions(-)

diff --git a/src/compiler/nir/nir_opt_if.c
b/src/compiler/nir/nir_opt_if.c
index 0c94aa170b5..60368a0259e 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -377,31 +377,15 @@ opt_if_loop_terminator(nir_if *nif)
return true;
 }

-static void
-replace_if_condition_use_with_const(nir_builder *b, nir_src *use,
-nir_const_value nir_boolean,
-bool if_condition)
-{
-   /* Create const */
-   nir_ssa_def *const_def = nir_build_imm(b, 1, 32, nir_boolean);
-
-   /* Rewrite use to use const */
-   nir_src new_src = nir_src_for_ssa(const_def);
-   if (if_condition)
-  nir_if_rewrite_condition(use->parent_if, new_src);
-   else
-  nir_instr_rewrite_src(use->parent_instr, use, new_src);
-}
-
 static bool
-evaluate_if_condition(nir_if *nif, nir_cursor cursor, uint32_t
*value)
+evaluate_if_condition(nir_if *nif, nir_cursor cursor, bool *value)
 {
nir_block *use_block = nir_cursor_current_block(cursor);
if (nir_block_dominates(nir_if_first_then_block(nif), use_block))
{
-  *value = NIR_TRUE;
+  *value = true;
   return true;
} else if (nir_block_dominates(nir_if_first_else_block(nif),
use_block)) {
-  *value = NIR_FALSE;
+  *value = false;
   return true;
} else {
   return false;
@@ -460,52 +444,31 @@ propagate_condition_eval(nir_builder *b, nir_if
*nif, nir_src *use_src,
  nir_src *alu_use, nir_alu_instr *alu,
  bool is_if_condition)
 {
-   bool progress = false;
+   bool bool_value;
+   if (!evaluate_if_condition(nif, b->cursor, _value))
+  return false;

-   nir_const_value bool_value;
b->cursor = nir_before_src(alu_use, is_if_condition);
-   if (nir_op_infos[alu->op].num_inputs == 1) {
-  assert(alu->op == nir_op_inot || alu->op == nir_op_b2i);
-
-  if (evaluate_if_condition(nif, b->cursor, _value.u32[0]))
{
- assert(nir_src_bit_size(alu->src[0].src) == 32);
-
- nir_const_value result =
-nir_eval_const_opcode(alu->op, 1, 32, _value);

- replace_if_condition_use_with_const(b, alu_use, result,
- is_if_condition);
- progress = true;
+   nir_ssa_def *def[2] = { };
+   for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
+  if (alu->src[i].src.ssa == use_src->ssa) {
+ def[i] = nir_imm_bool(b, bool_value);
+  } else {
+ def[i] = alu->src[i].src.ssa;
   }
-   } else {
-  assert(alu->op == nir_op_ior || alu->op == nir_op_iand);
-
-  if (evaluate_if_condition(nif, b->cursor, _value.u32[0]))
{
- nir_ssa_def *def[2];
- for (unsigned i = 0; i < 2; i++) {
-if (alu->src[i].src.ssa == use_src->ssa) {
-   def[i] = nir_build_imm(b, 1, 32, bool_value);
-} else {
-   def[i] = alu->src[i].src.ssa;
-}
- }
-
- nir_ssa_def *nalu =
-nir_build_alu(b, alu->op, def[0], def[1], NULL, NULL);
-
- /* Rewrite use to use new alu instruction */
- nir_src new_src = nir_src_for_ssa(nalu);
+   }
+   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1],
NULL, NULL);

- if (is_if_condition)
-nir_if_rewrite_condition(alu_use->parent_if, new_src);
- else
-nir_instr_rewrite_src(alu_use->parent_instr, alu_use,
new_src);
+   /* Rewrite use to use new alu instruction */
+   nir_src new_src = nir_src_for_ssa(nalu);

- progress = true;
-  }
-   }
+   if (is_if_condition)
+  nir_if_rewrite_condition(alu_use->parent_if, new_src);
+   else
+  nir_instr_rewrite_src(alu_use->parent_instr, alu_use,
new_src);

-   return progress;
+   return true;
 }

 static bool
@@ -527,11 +490,17 @@ evaluate_condition_use(nir_builder *b, nir_if
*nif, nir_src *use_src,
 {
bool progress = false;

-   nir_const_value value;
b->cursor = nir_before_src(use_src, is_if_condition);

-   if (evaluate_if_condition(nif, b->cursor, [0])) {
-  

[Mesa-dev] [PATCH] radv: use pool->stride when calling radv_query_shader()

[Samuel Pitoiset]

Not needed to recompute the stride.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_query.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 5a326c9df54..318d6c7afee 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1050,7 +1050,7 @@ void radv_CmdCopyQueryPoolResults(
radv_query_shader(cmd_buffer, 
_buffer->device->meta_state.query.occlusion_query_pipeline,
  pool->bo, dst_buffer->bo, firstQuery * 
pool->stride,
  dst_buffer->offset + dstOffset,
- get_max_db(cmd_buffer->device) * 16, stride,
+ pool->stride, stride,
  queryCount, flags, 0, 0);
break;
case VK_QUERY_TYPE_PIPELINE_STATISTICS:
@@ -1069,7 +1069,7 @@ void radv_CmdCopyQueryPoolResults(
radv_query_shader(cmd_buffer, 
_buffer->device->meta_state.query.pipeline_statistics_query_pipeline,
  pool->bo, dst_buffer->bo, firstQuery * 
pool->stride,
  dst_buffer->offset + dstOffset,
- pipelinestat_block_size * 2, stride, 
queryCount, flags,
+ pool->stride, stride, queryCount, flags,
  pool->pipeline_stats_mask,
  pool->availability_offset + 4 * firstQuery);
break;
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH 07/31] nir/opt_if: Rework condition propagation

[Iago Toral]

Jason, JFYI, I have been looking into the cases where the boolean
bitsize lowering pass was producing worse instruction counts that the
default 32-bit pass and I have tracked it down to this patch. Reverting
this makes the instruction count much better for some tests, I'll check
why this happens tomorrow.

Iago

On Mon, 2018-10-22 at 17:13 -0500, Jason Ekstrand wrote:
> Instead of doing our own constant folding, we just emit instructions
> and
> let constant folding happen.  This is substantially simpler and lets
> us
> use the nir_imm_bool helper instead of dealing with the const_value's
> ourselves.
> ---
>  src/compiler/nir/nir_opt_if.c | 91 -
> --
>  1 file changed, 30 insertions(+), 61 deletions(-)
> 
> diff --git a/src/compiler/nir/nir_opt_if.c
> b/src/compiler/nir/nir_opt_if.c
> index 0c94aa170b5..60368a0259e 100644
> --- a/src/compiler/nir/nir_opt_if.c
> +++ b/src/compiler/nir/nir_opt_if.c
> @@ -377,31 +377,15 @@ opt_if_loop_terminator(nir_if *nif)
> return true;
>  }
>  
> -static void
> -replace_if_condition_use_with_const(nir_builder *b, nir_src *use,
> -nir_const_value nir_boolean,
> -bool if_condition)
> -{
> -   /* Create const */
> -   nir_ssa_def *const_def = nir_build_imm(b, 1, 32, nir_boolean);
> -
> -   /* Rewrite use to use const */
> -   nir_src new_src = nir_src_for_ssa(const_def);
> -   if (if_condition)
> -  nir_if_rewrite_condition(use->parent_if, new_src);
> -   else
> -  nir_instr_rewrite_src(use->parent_instr, use, new_src);
> -}
> -
>  static bool
> -evaluate_if_condition(nir_if *nif, nir_cursor cursor, uint32_t
> *value)
> +evaluate_if_condition(nir_if *nif, nir_cursor cursor, bool *value)
>  {
> nir_block *use_block = nir_cursor_current_block(cursor);
> if (nir_block_dominates(nir_if_first_then_block(nif), use_block))
> {
> -  *value = NIR_TRUE;
> +  *value = true;
>return true;
> } else if (nir_block_dominates(nir_if_first_else_block(nif),
> use_block)) {
> -  *value = NIR_FALSE;
> +  *value = false;
>return true;
> } else {
>return false;
> @@ -460,52 +444,31 @@ propagate_condition_eval(nir_builder *b, nir_if
> *nif, nir_src *use_src,
>   nir_src *alu_use, nir_alu_instr *alu,
>   bool is_if_condition)
>  {
> -   bool progress = false;
> +   bool bool_value;
> +   if (!evaluate_if_condition(nif, b->cursor, _value))
> +  return false;
>  
> -   nir_const_value bool_value;
> b->cursor = nir_before_src(alu_use, is_if_condition);
> -   if (nir_op_infos[alu->op].num_inputs == 1) {
> -  assert(alu->op == nir_op_inot || alu->op == nir_op_b2i);
> -
> -  if (evaluate_if_condition(nif, b->cursor, _value.u32[0]))
> {
> - assert(nir_src_bit_size(alu->src[0].src) == 32);
> -
> - nir_const_value result =
> -nir_eval_const_opcode(alu->op, 1, 32, _value);
>  
> - replace_if_condition_use_with_const(b, alu_use, result,
> - is_if_condition);
> - progress = true;
> +   nir_ssa_def *def[2] = { };
> +   for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
> +  if (alu->src[i].src.ssa == use_src->ssa) {
> + def[i] = nir_imm_bool(b, bool_value);
> +  } else {
> + def[i] = alu->src[i].src.ssa;
>}
> -   } else {
> -  assert(alu->op == nir_op_ior || alu->op == nir_op_iand);
> -
> -  if (evaluate_if_condition(nif, b->cursor, _value.u32[0]))
> {
> - nir_ssa_def *def[2];
> - for (unsigned i = 0; i < 2; i++) {
> -if (alu->src[i].src.ssa == use_src->ssa) {
> -   def[i] = nir_build_imm(b, 1, 32, bool_value);
> -} else {
> -   def[i] = alu->src[i].src.ssa;
> -}
> - }
> -
> - nir_ssa_def *nalu =
> -nir_build_alu(b, alu->op, def[0], def[1], NULL, NULL);
> -
> - /* Rewrite use to use new alu instruction */
> - nir_src new_src = nir_src_for_ssa(nalu);
> +   }
> +   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1],
> NULL, NULL);
>  
> - if (is_if_condition)
> -nir_if_rewrite_condition(alu_use->parent_if, new_src);
> - else
> -nir_instr_rewrite_src(alu_use->parent_instr, alu_use,
> new_src);
> +   /* Rewrite use to use new alu instruction */
> +   nir_src new_src = nir_src_for_ssa(nalu);
>  
> - progress = true;
> -  }
> -   }
> +   if (is_if_condition)
> +  nir_if_rewrite_condition(alu_use->parent_if, new_src);
> +   else
> +  nir_instr_rewrite_src(alu_use->parent_instr, alu_use,
> new_src);
>  
> -   return progress;
> +   return true;
>  }
>  
>  static bool
> @@ -527,11 +490,17 @@ evaluate_condition_use(nir_builder *b, nir_if
> *nif, nir_src *use_src,
>  {
> bool progress = false;
>  
> -   nir_const_value value;
> b->cursor = 

Re: [Mesa-dev] [PATCH] vulkan/wsi/wayland: Respect non-blocking AcquireNextImage

[Eric Engestrom]

On Tuesday, 2018-10-30 12:56:53 +, Daniel Stone wrote:
> If the client has requested that AcquireNextImage not block at all, with
> a timeout of 0, then don't make any non-blocking calls.

Indeed; per spec:
> If timeout is zero, then vkAcquireNextImageKHR does not wait, and will
> either successfully acquire an image, or fail and return VK_NOT_READY
> if no image is available.

Reviewed-by: Eric Engestrom 

> 
> This will still potentially block infinitely given a non-infinte
> timeout, but the fix for that is much more involved.

Maybe we should add a comment/debug message about this?

8<
diff --git a/src/vulkan/wsi/wsi_common_wayland.c 
b/src/vulkan/wsi/wsi_common_wayland.c
index 86b3acec94e8b98b3dbf..d9852f464f9af2a32ab9 100644
--- a/src/vulkan/wsi/wsi_common_wayland.c
+++ b/src/vulkan/wsi/wsi_common_wayland.c
@@ -681,6 +681,16 @@ wsi_wl_swapchain_acquire_next_image(struct wsi_swapchain 
*wsi_chain,
 {
struct wsi_wl_swapchain *chain = (struct wsi_wl_swapchain *)wsi_chain;
 
+#ifdef DEBUG
+   /*
+* TODO: We need to implement this
+*/
+   if (info->timeout != 0 && info->timeout != UINT64_MAX)
+   {
+  fprintf(stderr, "timeout not supported; ignoring");
+   }
+#endif
+
int ret = wl_display_dispatch_queue_pending(chain->display->wl_display,
chain->display->queue);
/* XXX: I'm not sure if out-of-date is the right error here.  If
>8

> 
> Signed-off-by: Daniel Stone 
> Cc: mesa-sta...@lists.freedesktop.org
> Cc: Chad Versace 
> Cc: Jason Ekstrand 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108540
> ---
>  src/vulkan/wsi/wsi_common_wayland.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/src/vulkan/wsi/wsi_common_wayland.c 
> b/src/vulkan/wsi/wsi_common_wayland.c
> index e9cc22ec603..981243d8b14 100644
> --- a/src/vulkan/wsi/wsi_common_wayland.c
> +++ b/src/vulkan/wsi/wsi_common_wayland.c
> @@ -699,9 +699,14 @@ wsi_wl_swapchain_acquire_next_image(struct wsi_swapchain 
> *wsi_chain,
>   }
>}
>  
> -  /* This time we do a blocking dispatch because we can't go
> -   * anywhere until we get an event.
> +  /* We now have to do a blocking dispatch, because all our images
> +   * are in use and we cannot return one until the server does. However,
> +   * if the client has requested non-blocking ANI, then we tell it up 
> front
> +   * that we have nothing to return.
> */
> +  if (info->timeout == 0)
> + return VK_NOT_READY;
> +
>int ret = wl_display_roundtrip_queue(chain->display->wl_display,
> chain->display->queue);
>if (ret < 0)
> -- 
> 2.19.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

[Mesa-dev] [PATCH] vulkan/wsi/wayland: Respect non-blocking AcquireNextImage

[Daniel Stone]

If the client has requested that AcquireNextImage not block at all, with
a timeout of 0, then don't make any non-blocking calls.

This will still potentially block infinitely given a non-infinte
timeout, but the fix for that is much more involved.

Signed-off-by: Daniel Stone 
Cc: mesa-sta...@lists.freedesktop.org
Cc: Chad Versace 
Cc: Jason Ekstrand 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108540
---
 src/vulkan/wsi/wsi_common_wayland.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common_wayland.c 
b/src/vulkan/wsi/wsi_common_wayland.c
index e9cc22ec603..981243d8b14 100644
--- a/src/vulkan/wsi/wsi_common_wayland.c
+++ b/src/vulkan/wsi/wsi_common_wayland.c
@@ -699,9 +699,14 @@ wsi_wl_swapchain_acquire_next_image(struct wsi_swapchain 
*wsi_chain,
  }
   }
 
-  /* This time we do a blocking dispatch because we can't go
-   * anywhere until we get an event.
+  /* We now have to do a blocking dispatch, because all our images
+   * are in use and we cannot return one until the server does. However,
+   * if the client has requested non-blocking ANI, then we tell it up front
+   * that we have nothing to return.
*/
+  if (info->timeout == 0)
+ return VK_NOT_READY;
+
   int ret = wl_display_roundtrip_queue(chain->display->wl_display,
chain->display->queue);
   if (ret < 0)
-- 
2.19.1

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