Re: [Mesa-dev] [PATCH] anv/gen7_pipeline: Use MSDISPMODE_PERSAMPLE for non-multisampled fbo

[Anuj Phogat]

On Wed, Sep 21, 2016 at 11:49 AM, Jason Ekstrand  wrote:
> This seems odd... When can it even happen that we have persample_dispatch
> set in wm_surface_state and have only one sample?  Does this fix a test
> case?
>
No, It just fixes a simulator warning. It's recommended in graphics spec
for gen7. Also look at gen7_wm_state.c.

>
> On Sep 21, 2016 9:14 PM, "Anuj Phogat"  wrote:
>>
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/intel/vulkan/gen7_pipeline.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/intel/vulkan/gen7_pipeline.c
>> b/src/intel/vulkan/gen7_pipeline.c
>> index 878308b..5150ef9 100644
>> --- a/src/intel/vulkan/gen7_pipeline.c
>> +++ b/src/intel/vulkan/gen7_pipeline.c
>> @@ -267,7 +267,8 @@ genX(graphics_pipeline_create)(
>>
>>   wm.MultisampleRasterizationMode= samples > 1 ?
>>MSRASTMODE_ON_PATTERN :
>> MSRASTMODE_OFF_PIXEL;
>> - wm.MultisampleDispatchMode =
>> wm_prog_data->persample_dispatch ?
>> + wm.MultisampleDispatchMode = ((samples == 1) ||
>> +   (samples > 1 &&
>> wm_prog_data->persample_dispatch)) ?
>>MSDISPMODE_PERSAMPLE :
>> MSDISPMODE_PERPIXEL;
>>}
>> }
>> --
>> 2.5.5
>>
>> ___
>> 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 00/15] Compile GLSL to ir_builder

[Kenneth Graunke]

Hi Ian,

I just sent out a four patch series that I think will accomplish a lot
of what you were trying to do with the "do post-link optimizations, but
only for built-ins" patches.  But it deletes code.

https://lists.freedesktop.org/archives/mesa-dev/2016-September/129437.html

I'd been playing with this on and off for a few years, but there were
a few functional regressions I hadn't solved, and I wasn't sure about
the minor shader-db regressions.  Everything works now though.

--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 3/4] glsl: Delete ftransform support from builtin_functions.cpp.

[Kenneth Graunke]

This is now handled directly by ast_function.cpp.

Signed-off-by: Kenneth Graunke 
---
 src/compiler/glsl/builtin_functions.cpp | 30 --
 1 file changed, 4 insertions(+), 26 deletions(-)

diff --git a/src/compiler/glsl/builtin_functions.cpp 
b/src/compiler/glsl/builtin_functions.cpp
index 19ef99e..102c039 100644
--- a/src/compiler/glsl/builtin_functions.cpp
+++ b/src/compiler/glsl/builtin_functions.cpp
@@ -585,10 +585,6 @@ public:
 private:
void *mem_ctx;
 
-   /** Global variables used by built-in functions. */
-   ir_variable *gl_ModelViewProjectionMatrix;
-   ir_variable *gl_Vertex;
-
void create_shader();
void create_intrinsics();
void create_builtins();
@@ -905,9 +901,7 @@ enum image_function_flags {
  *  @{
  */
 builtin_builder::builtin_builder()
-   : shader(NULL),
- gl_ModelViewProjectionMatrix(NULL),
- gl_Vertex(NULL)
+   : shader(NULL)
 {
mem_ctx = NULL;
 }
@@ -974,16 +968,6 @@ builtin_builder::create_shader()
 */
shader = _mesa_new_shader(0, MESA_SHADER_VERTEX);
shader->symbols = new(mem_ctx) glsl_symbol_table;
-
-   gl_ModelViewProjectionMatrix =
-  new(mem_ctx) ir_variable(glsl_type::mat4_type,
-   "gl_ModelViewProjectionMatrix",
-   ir_var_uniform);
-
-   shader->symbols->add_variable(gl_ModelViewProjectionMatrix);
-
-   gl_Vertex = in_var(glsl_type::vec4_type, "gl_Vertex");
-   shader->symbols->add_variable(gl_Vertex);
 }
 
 /** @} */
@@ -3978,15 +3962,9 @@ builtin_builder::_ftransform()
 {
MAKE_SIG(glsl_type::vec4_type, compatibility_vs_only, 0);
 
-   body.emit(ret(new(mem_ctx) ir_expression(ir_binop_mul,
-  glsl_type::vec4_type,
-  var_ref(gl_ModelViewProjectionMatrix),
-  var_ref(gl_Vertex;
-
-   /* FINISHME: Once the ir_expression() constructor handles type inference
-*   for matrix operations, we can simplify this to:
-*
-*body.emit(ret(mul(gl_ModelViewProjectionMatrix, gl_Vertex)));
+   /* ftransform() refers to global variables, and is always emitted
+* directly by ast_function.cpp.  Just emit a prototype here so we
+* can recognize calls to it.
 */
return sig;
 }
-- 
2.10.0

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

[Mesa-dev] [PATCH 4/4] glsl: Delete linker stuff relating to built-in functions.

[Kenneth Graunke]

Now that we generate built-in functions inline, there's no need to link
against the built-in shader, and no built-in prototypes to consider.

This lets us delete a bunch of code.

Signed-off-by: Kenneth Graunke 
---
 src/compiler/glsl/link_functions.cpp | 32 +++
 src/compiler/glsl/linker.cpp | 42 +++-
 2 files changed, 16 insertions(+), 58 deletions(-)

diff --git a/src/compiler/glsl/link_functions.cpp 
b/src/compiler/glsl/link_functions.cpp
index b4aae5e..e4f77be 100644
--- a/src/compiler/glsl/link_functions.cpp
+++ b/src/compiler/glsl/link_functions.cpp
@@ -32,7 +32,7 @@
 
 static ir_function_signature *
 find_matching_signature(const char *name, const exec_list *actual_parameters,
-glsl_symbol_table *symbols, bool use_builtin);
+glsl_symbol_table *symbols);
 
 namespace {
 
@@ -74,12 +74,15 @@ public:
   assert(callee != NULL);
   const char *const name = callee->function_name();
 
+  /* We don't actually need to find intrinsics; they're not real */
+  if (callee->is_intrinsic)
+ return visit_continue;
+
   /* Determine if the requested function signature already exists in the
* final linked shader.  If it does, use it as the target of the call.
*/
   ir_function_signature *sig =
- find_matching_signature(name, >parameters, linked->symbols,
- ir->use_builtin);
+ find_matching_signature(name, >parameters, linked->symbols);
   if (sig != NULL) {
 ir->callee = sig;
 return visit_continue;
@@ -90,8 +93,7 @@ public:
*/
   for (unsigned i = 0; i < num_shaders; i++) {
  sig = find_matching_signature(name, >actual_parameters,
-   shader_list[i]->symbols,
-   ir->use_builtin);
+   shader_list[i]->symbols);
  if (sig)
 break;
   }
@@ -122,9 +124,7 @@ public:
 
   ir_function_signature *linked_sig =
 f->exact_matching_signature(NULL, >parameters);
-  if ((linked_sig == NULL)
- || ((linked_sig != NULL)
- && (linked_sig->is_builtin() != ir->use_builtin))) {
+  if (linked_sig == NULL) {
 linked_sig = new(linked) ir_function_signature(callee->return_type);
 f->add_signature(linked_sig);
   }
@@ -314,22 +314,16 @@ private:
  */
 ir_function_signature *
 find_matching_signature(const char *name, const exec_list *actual_parameters,
-glsl_symbol_table *symbols, bool use_builtin)
+glsl_symbol_table *symbols)
 {
ir_function *const f = symbols->get_function(name);
 
if (f) {
   ir_function_signature *sig =
- f->matching_signature(NULL, actual_parameters, use_builtin);
-
-  if (sig && (sig->is_defined || sig->is_intrinsic)) {
- /* If this function expects to bind to a built-in function and the
-  * signature that we found isn't a built-in, keep looking.  Also keep
-  * looking if we expect a non-built-in but found a built-in.
-  */
- if (use_builtin == sig->is_builtin())
-return sig;
-  }
+ f->matching_signature(NULL, actual_parameters, false);
+
+  if (sig && (sig->is_defined || sig->is_intrinsic))
+ return sig;
}
 
return NULL;
diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 606d006..929a653 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -2098,14 +2098,13 @@ link_intrastage_shaders(void *mem_ctx,
   continue;
 
foreach_in_list(ir_function_signature, sig, >signatures) {
-  if (!sig->is_defined || sig->is_builtin())
+  if (!sig->is_defined)
  continue;
 
   ir_function_signature *other_sig =
  other->exact_matching_signature(NULL, >parameters);
 
-  if ((other_sig != NULL) && other_sig->is_defined
-  && !other_sig->is_builtin()) {
+  if (other_sig != NULL && other_sig->is_defined) {
  linker_error(prog, "function `%s' is multiply defined\n",
   f->name);
  return NULL;
@@ -2171,42 +2170,7 @@ link_intrastage_shaders(void *mem_ctx,
  insertion_point, true, linked);
}
 
-   /* Check if any shader needs built-in functions. */
-   bool need_builtins = false;
-   for (unsigned i = 0; i < num_shaders; i++) {
-  if (shader_list[i]->info.uses_builtin_functions) {
- need_builtins = true;
- break;
-  }
-   }
-
-   bool ok;
-   if (need_builtins) {
-  /* Make a temporary array one larger than shader_list, which will hold
-   * the built-in function shader as well.
-   */
-  gl_shader 

[Mesa-dev] [PATCH 1/4] glsl: Check TCS barrier restrictions at ast_to_hir time, not link time.

[Kenneth Graunke]

We want to check prior to optimization - otherwise we might fail to
detect cases where barrier() is in control flow which is always taken
(and therefore gets optimized away).

We don't currently loop unroll if there are function calls inside;
otherwise we might have a problem detecting barrier() in loops that
get unrolled as well.

Tapani's switch handling code adds a loop around switch statements, so
even with the mess of if ladders, we'll properly reject it.

Enforcing these rules at compile time makes more sense more sense than
link time.  Doing it at ast-to-hir time (rather than as an IR pass)
allows us to emit an error message with proper line numbers.
(Otherwise, I would have preferred the IR pass...)

Fixes spec/arb_tessellation_shader/compiler/barrier-switch-always.tesc.

Signed-off-by: Kenneth Graunke 
---
 src/compiler/glsl/ast_function.cpp | 19 
 src/compiler/glsl/linker.cpp   | 99 --
 2 files changed, 19 insertions(+), 99 deletions(-)

diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index ea3ac87..7e62ab7 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -2143,6 +2143,25 @@ ast_function_expression::hir(exec_list *instructions,
  /* an error has already been emitted */
  value = ir_rvalue::error_value(ctx);
   } else {
+ if (state->stage == MESA_SHADER_TESS_CTRL &&
+ sig->is_builtin() && strcmp(func_name, "barrier") == 0) {
+if (state->current_function == NULL ||
+strcmp(state->current_function->function_name(), "main") != 0) 
{
+   _mesa_glsl_error(, state,
+"barrier() may only be used in main()");
+}
+
+if (state->found_return) {
+   _mesa_glsl_error(, state,
+"barrier() may not be used after return");
+}
+
+if (instructions != >current_function->body) {
+   _mesa_glsl_error(, state,
+"barrier() may not be used in control flow");
+}
+ }
+
  value = generate_call(instructions, sig,
_parameters, sub_var, array_idx, state);
  if (!value) {
diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index f3eece2..606d006 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -260,97 +260,6 @@ public:
}
 };
 
-class barrier_use_visitor : public ir_hierarchical_visitor {
-public:
-   barrier_use_visitor(gl_shader_program *prog)
-  : prog(prog), in_main(false), after_return(false), control_flow(0)
-   {
-   }
-
-   virtual ~barrier_use_visitor()
-   {
-  /* empty */
-   }
-
-   virtual ir_visitor_status visit_enter(ir_function *ir)
-   {
-  if (strcmp(ir->name, "main") == 0)
- in_main = true;
-
-  return visit_continue;
-   }
-
-   virtual ir_visitor_status visit_leave(ir_function *)
-   {
-  in_main = false;
-  after_return = false;
-  return visit_continue;
-   }
-
-   virtual ir_visitor_status visit_leave(ir_return *)
-   {
-  after_return = true;
-  return visit_continue;
-   }
-
-   virtual ir_visitor_status visit_enter(ir_if *)
-   {
-  ++control_flow;
-  return visit_continue;
-   }
-
-   virtual ir_visitor_status visit_leave(ir_if *)
-   {
-  --control_flow;
-  return visit_continue;
-   }
-
-   virtual ir_visitor_status visit_enter(ir_loop *)
-   {
-  ++control_flow;
-  return visit_continue;
-   }
-
-   virtual ir_visitor_status visit_leave(ir_loop *)
-   {
-  --control_flow;
-  return visit_continue;
-   }
-
-   /* FINISHME: `switch` is not expressed at the IR level -- it's already
-* been lowered to a mess of `if`s. We'll correctly disallow any use of
-* barrier() in a conditional path within the switch, but not in a path
-* which is always hit.
-*/
-
-   virtual ir_visitor_status visit_enter(ir_call *ir)
-   {
-  if (ir->use_builtin && strcmp(ir->callee_name(), "barrier") == 0) {
- /* Use of barrier(); determine if it is legal: */
- if (!in_main) {
-linker_error(prog, "Builtin barrier() may only be used in main");
-return visit_stop;
- }
-
- if (after_return) {
-linker_error(prog, "Builtin barrier() may not be used after 
return");
-return visit_stop;
- }
-
- if (control_flow != 0) {
-linker_error(prog, "Builtin barrier() may not be used inside 
control flow");
-return visit_stop;
- }
-  }
-  return visit_continue;
-   }
-
-private:
-   gl_shader_program *prog;
-   bool in_main, after_return;
-   int control_flow;
-};
-
 /**
  * Visitor that determines the highest stream id to which a (geometry) shader
  * emits vertices. It also checks whether 

[Mesa-dev] [PATCH 2/4] glsl: Immediately inline built-ins rather than generating calls.

[Kenneth Graunke]

In the past, we imported the prototypes of built-in functions, generated
calls to those, and waited until link time to resolve the calls and
import the actual code for the built-in functions.

This severely limited our compile-time optimization opportunities: even
trivial functions like dot() were represented as function calls.  We
also had no way of reasoning about those calls; they could have been
1,000 line functions with side-effects for all we knew.

Practically all built-in functions are trivial translations to
ir_expression opcodes, so it makes sense to just generate those inline.
Since we eventually inline all functions anyway, we may as well just do
it for all built-in functions.

There's only one snag: built-in functions that refer to built-in global
variables need those remapped to the variables in the shader being
compiled, rather than the ones in the built-in shader.  Currently,
ftransform() is the only function matching those criteria, so it seemed
easier to just make it a special case.

On Skylake:

total instructions in shared programs: 12023491 -> 12024010 (0.00%)
instructions in affected programs: 77595 -> 78114 (0.67%)
helped: 97
HURT: 309

total cycles in shared programs: 137239044 -> 137295498 (0.04%)
cycles in affected programs: 16714026 -> 16770480 (0.34%)
helped: 4663
HURT: 4923

while these statistics are in the wrong direction, the number of
hurt programs is small (309 / 41282 = 0.75%), and I don't think
anything can be done about it.  A change like this significantly
alters the order in which optimizations are performed.

Signed-off-by: Kenneth Graunke 
---
 src/compiler/glsl/ast_function.cpp | 46 ++
 1 file changed, 22 insertions(+), 24 deletions(-)

diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index 7e62ab7..ac3b52d 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -430,7 +430,8 @@ generate_call(exec_list *instructions, 
ir_function_signature *sig,
   exec_list *actual_parameters,
   ir_variable *sub_var,
   ir_rvalue *array_idx,
-  struct _mesa_glsl_parse_state *state)
+  struct _mesa_glsl_parse_state *state,
+  bool inline_immediately)
 {
void *ctx = state;
exec_list post_call_conversions;
@@ -542,6 +543,10 @@ generate_call(exec_list *instructions, 
ir_function_signature *sig,
ir_call *call = new(ctx) ir_call(sig, deref,
 actual_parameters, sub_var, array_idx);
instructions->push_tail(call);
+   if (inline_immediately) {
+  call->generate_inline(call);
+  call->remove();
+   }
 
/* Also emit any necessary out-parameter conversions. */
instructions->append_list(_call_conversions);
@@ -557,19 +562,18 @@ match_function_by_name(const char *name,
exec_list *actual_parameters,
struct _mesa_glsl_parse_state *state)
 {
-   void *ctx = state;
ir_function *f = state->symbols->get_function(name);
ir_function_signature *local_sig = NULL;
ir_function_signature *sig = NULL;
 
/* Is the function hidden by a record type constructor? */
if (state->symbols->get_type(name))
-  goto done; /* no match */
+  return sig; /* no match */
 
/* Is the function hidden by a variable (impossible in 1.10)? */
if (!state->symbols->separate_function_namespace
&& state->symbols->get_variable(name))
-  goto done; /* no match */
+  return sig; /* no match */
 
if (f != NULL) {
   /* In desktop GL, the presence of a user-defined signature hides any
@@ -583,31 +587,15 @@ match_function_by_name(const char *name,
   sig = local_sig = f->matching_signature(state, actual_parameters,
   allow_builtins, _exact);
   if (is_exact)
- goto done;
+ return sig;
 
   if (!allow_builtins)
- goto done;
+ return sig;
}
 
/* 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);
-
- done:
-   if (sig != NULL) {
-  /* If the match is from a linked built-in shader, import the
-   * prototype.
-   */
-  if (sig != local_sig) {
- if (f == NULL) {
-f = new(ctx) ir_function(name);
-state->symbols->add_global_function(f);
-emit_function(state, f);
- }
- sig = sig->clone_prototype(f, NULL);
- f->add_signature(sig);
-  }
-   }
return sig;
 }
 
@@ -2142,6 +2130,16 @@ ast_function_expression::hir(exec_list *instructions,
  this->expressions)) {
  /* an error has already been emitted */
  value = ir_rvalue::error_value(ctx);
+  } else if (sig->is_builtin() && strcmp(func_name, 

[Mesa-dev] [PATCH 0/4] glsl: Builtins, now!

[Kenneth Graunke]

Hello,

This series reworks the GLSL compiler to inline built-in functions
immediately, at compile time, rather than importing prototypes and
linking against an extra shader later on.

Without this, compile time optimizations are nearly useless.  For example,
trying to use a dot product would generate:

   (call dot ...)

which would not be turned into

   (expression dot ...)

until link time, when we actually import the functions, and finally inline.

Function calls are opaque, and most optimization passes freak out and bail
when they see them.  For example, loop unrolling wouldn't happen at compile
time at all if a loop contains a built-in function call.  This is pretty bad.

Most built-in functions turn into opcodes, or tiny expression trees.
It makes sense to simply inline them immediately.  Some are larger
(such as atan).  But we eventually inline them all today anyway, so
I don't see any downside to doing it sooner rather than later.

Ian recently sent out a patch series that adds a lot of flags for
"do this optimization anyway, but only for built-ins", in an attempt
to clean up this (call ...) mess.  I think this series should also
solve those problems, but it deletes a bunch of code, rather than
adding more code.

The downside is that the shader-db statistics aren't great today,
but I don't think there's a lot we can do about that.  This changes
the optimization order significantly.  Overall, the difference was
pretty small, so I think I'm OK with it.

Thoughts?

--Ken

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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #9 from Tobias Droste  ---
Ah should have mentioned it:

This is with radeon+radeonsi (no amdpgu) so it's probably not the kernel.

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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #8 from Tobias Droste  ---
On the first screenshot you can clearly see the FPS going down to 0 multiple
times. 
Though looking at the graph only the first 2 drops could be explained by shader
compiles if I interpret this correctly. I can't tell what's happening after
that.

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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #7 from Tobias Droste  ---
Created attachment 126717
  --> https://bugs.freedesktop.org/attachment.cgi?id=126717=edit
Screenshot with GALLIUM_HUD of the first 2min30s of the game (good)

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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #6 from Tobias Droste  ---
Created attachment 126716
  --> https://bugs.freedesktop.org/attachment.cgi?id=126716=edit
Screenshot with GALLIUM_HUD of the first 1min30s of the game (good)

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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #5 from Tobias Droste  ---
Created attachment 126715
  --> https://bugs.freedesktop.org/attachment.cgi?id=126715=edit
Screenshot with GALLIUM_HUD of the first 10s of the game (bad)

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

[Mesa-dev] Expose ES 3.2 symbols in libGLESv2.so?

[Kenneth Graunke]

Commit 5921f372c89a68fac6ddefc009442721d9df4db2 exposed GLES 3.1 symbols
in libGLESv2.so.  Are we supposed to do the same thing for GLES 3.2?

I imagine we're supposed to, but I'm not certain what spec actually
defines the ABI or where to look.


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] [AppVeyor] mesa master #2238 failed

[AppVeyor]

Build mesa 2238 failed


Commit 6c648cdac8 by Kenneth Graunke on 9/21/2016 6:51 PM:

docs: Mark ES 3.2 "all done" for i965/gen9+.


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH] gallium/util: add comment on util_is_format_compatible()

[Jose Fonseca]

On 21/09/16 16:25, Brian Paul wrote:

From reading the code, it's not obvious what is src/dest compatible.
The list of a->b copy-compatible formats comes from Jose's original
check-in message, with some format name updates.
---
 src/gallium/auxiliary/util/u_format.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_format.c 
b/src/gallium/auxiliary/util/u_format.c
index cbdb5ce..8881618 100644
--- a/src/gallium/auxiliary/util/u_format.c
+++ b/src/gallium/auxiliary/util/u_format.c
@@ -457,6 +457,30 @@ util_format_write_4i(enum pipe_format format,
format_desc->pack_rgba_sint(dst_row, dst_stride, src_row, src_stride, w, h);
 }

+/**
+ * Check if we can safely memcopy from the source format to the dest format.
+ * This basically covers the cases of a "used" channel copied to a typeless
+ * channel, plus some 1-channel cases.
+ * Examples of compatiblie copy formats include:
+ *b8g8r8a8_unorm -> b8g8r8x8_unorm
+ *a8r8g8b8_unorm -> x8r8g8b8_unorm
+ *b5g5r5a1_unorm -> b5g5r5x1_unorm
+ *b4g4r4a4_unorm -> b4g4r4x4_unorm
+ *l8_unorm -> r8_unorm
+ *i8_unorm -> l8_unorm
+ *i8_unorm -> a8_unorm
+ *i8_unorm -> r8_unorm
+ *l16_unorm -> r16_unorm
+ *z24_unorm_s8_uint -> z24x8_unorm
+ *s8_uint_z24_unorm -> x8z24_unorm
+ *r8g8b8a8_unorm -> r8g8b8x8_unorm
+ *a8b8g8r8_srgb -> x8b8g8r8_srgb
+ *b8g8r8a8_srgb -> b8g8r8x8_srgb
+ *a8r8g8b8_srgb -> x8r8g8b8_srgb
+ *a8b8g8r8_unorm -> x8b8g8r8_unorm
+ *r10g10b10a2_uscaled -> r10g10b10x2_uscaled
+ *r10sg10sb10sa2u_norm -> r10g10b10x2_snorm
+ */
 boolean
 util_is_format_compatible(const struct util_format_description *src_desc,
   const struct util_format_description *dst_desc)



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

Re: [Mesa-dev] [PATCH] anv/gen7_pipeline: Use MSDISPMODE_PERSAMPLE for non-multisampled fbo

[Jason Ekstrand]

This seems odd... When can it even happen that we have persample_dispatch
set in wm_surface_state and have only one sample?  Does this fix a test
case?

On Sep 21, 2016 9:14 PM, "Anuj Phogat"  wrote:

> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/vulkan/gen7_pipeline.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_
> pipeline.c
> index 878308b..5150ef9 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -267,7 +267,8 @@ genX(graphics_pipeline_create)(
>
>   wm.MultisampleRasterizationMode= samples > 1 ?
>MSRASTMODE_ON_PATTERN :
> MSRASTMODE_OFF_PIXEL;
> - wm.MultisampleDispatchMode = 
> wm_prog_data->persample_dispatch
> ?
> + wm.MultisampleDispatchMode = ((samples == 1) ||
> +   (samples > 1 &&
> wm_prog_data->persample_dispatch)) ?
>MSDISPMODE_PERSAMPLE :
> MSDISPMODE_PERPIXEL;
>}
> }
> --
> 2.5.5
>
> ___
> 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] intel/isl: Add an assert to check zero width/height surface

[Jason Ekstrand]

The genxml packing structs will assert this for you. I'm guessing it did
and you found it rather obtuse. :-)

Rb

On Sep 21, 2016 9:16 PM, "Anuj Phogat"  wrote:

> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/isl/isl_surface_state.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/intel/isl/isl_surface_state.c
> b/src/intel/isl/isl_surface_state.c
> index 1a1a819..b20f767 100644
> --- a/src/intel/isl/isl_surface_state.c
> +++ b/src/intel/isl/isl_surface_state.c
> @@ -249,6 +249,9 @@ isl_genX(surf_fill_state_s)(const struct isl_device
> *dev, void *state,
> s.IntegerSurfaceFormat = isl_format_has_int_channel(s.SurfaceFormat);
>  #endif
>
> +   assert(info->surf->logical_level0_px.width > 0 &&
> +  info->surf->logical_level0_px.height > 0);
> +
> s.Width = info->surf->logical_level0_px.width - 1;
> s.Height = info->surf->logical_level0_px.height - 1;
>
> --
> 2.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] svga: minor simplification in svga_validate_surface_view()

[Charmaine Lee]

For the series, Reviewed-by: Charmaine Lee 


From: Brian Paul 
Sent: Wednesday, September 21, 2016 8:25 AM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee
Subject: [PATCH 2/2] svga: minor simplification in svga_validate_surface_view()

Get rid of unneeded local var.
---
 src/gallium/drivers/svga/svga_surface.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_surface.c 
b/src/gallium/drivers/svga/svga_surface.c
index 42636bc..7cc7ef1 100644
--- a/src/gallium/drivers/svga/svga_surface.c
+++ b/src/gallium/drivers/svga/svga_surface.c
@@ -405,9 +405,9 @@ svga_validate_surface_view(struct svga_context *svga, 
struct svga_surface *s)
 {
enum pipe_error ret = PIPE_OK;
enum pipe_shader_type shader;
-   struct pipe_surface *surf = NULL;

assert(svga_have_vgpu10(svga));
+   assert(s);

SVGA_STATS_TIME_PUSH(svga_sws(svga),
 SVGA_STATS_TIME_VALIDATESURFACEVIEW);
@@ -481,12 +481,11 @@ svga_validate_surface_view(struct svga_context *svga, 
struct svga_surface *s)
  goto done;
   }
}
-   surf = >base;

 done:
SVGA_STATS_TIME_POP(svga_sws(svga));

-   return surf;
+   return >base;
 }


--
1.9.1

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

[Mesa-dev] [PATCH] anv/blorp: Handle zero width/height copying in copy_buffer_to_image

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/anv_blorp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index cb61070..de33dce 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -273,6 +273,10 @@ copy_buffer_to_image(struct anv_cmd_buffer *cmd_buffer,
 
   VkExtent3D extent =
  anv_sanitize_image_extent(anv_image->type, pRegions[r].imageExtent);
+
+  if (extent.width == 0 || extent.height == 0)
+ return;
+
   if (anv_image->type != VK_IMAGE_TYPE_3D) {
  image.offset.z = pRegions[r].imageSubresource.baseArrayLayer;
  extent.depth = pRegions[r].imageSubresource.layerCount;
-- 
2.5.5

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

[Mesa-dev] [PATCH] intel/isl: Add an assert to check zero width/height surface

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/isl/isl_surface_state.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/intel/isl/isl_surface_state.c 
b/src/intel/isl/isl_surface_state.c
index 1a1a819..b20f767 100644
--- a/src/intel/isl/isl_surface_state.c
+++ b/src/intel/isl/isl_surface_state.c
@@ -249,6 +249,9 @@ isl_genX(surf_fill_state_s)(const struct isl_device *dev, 
void *state,
s.IntegerSurfaceFormat = isl_format_has_int_channel(s.SurfaceFormat);
 #endif
 
+   assert(info->surf->logical_level0_px.width > 0 &&
+  info->surf->logical_level0_px.height > 0);
+
s.Width = info->surf->logical_level0_px.width - 1;
s.Height = info->surf->logical_level0_px.height - 1;
 
-- 
2.5.5

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

[Mesa-dev] [PATCH] i965/gen8+: Enable GL_OES_viewport_array

[Anuj Phogat]

Signed-off-by: Anuj Phogat 

---
This patch requires below series:
https://patchwork.freedesktop.org/series/12594/
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 93eb966..53bd7cc 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -404,6 +404,7 @@ intelInitExtensions(struct gl_context *ctx)
   ctx->Extensions.ARB_ES3_2_compatibility = true;
   ctx->Extensions.OES_geometry_shader = true;
   ctx->Extensions.OES_texture_cube_map_array = true;
+  ctx->Extensions.OES_viewport_array = true;
}
 
if (brw->gen >= 9) {
-- 
2.5.5

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

[Mesa-dev] [PATCH] anv/gen7_pipeline: Use MSDISPMODE_PERSAMPLE for non-multisampled fbo

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen7_pipeline.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 878308b..5150ef9 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -267,7 +267,8 @@ genX(graphics_pipeline_create)(
 
  wm.MultisampleRasterizationMode= samples > 1 ?
   MSRASTMODE_ON_PATTERN : 
MSRASTMODE_OFF_PIXEL;
- wm.MultisampleDispatchMode = 
wm_prog_data->persample_dispatch ?
+ wm.MultisampleDispatchMode = ((samples == 1) ||
+   (samples > 1 && 
wm_prog_data->persample_dispatch)) ?
   MSDISPMODE_PERSAMPLE : 
MSDISPMODE_PERPIXEL;
   }
}
-- 
2.5.5

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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #4 from Andreas Hartmetz  ---
I have the same problem. Assuming the problem was shader compilation, what
could be done about it, though? Optimizing shader compilation by a factor of 10
seems unrealistic, a disk cache for shaders has been rejected (right?) and
would not always help, e.g. when somebody with a car that uses a new asset
joins.

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

Re: [Mesa-dev] [PATCH 0/2] Implement lanczos interpolation filter

[Nayan Deshmukh]

Hi Andy,



On Wed, Sep 21, 2016 at 9:30 PM, Andy Furniss  wrote:

> Andy Furniss wrote:
>
>> Andy Furniss wrote:
>>
>>> Andy Furniss wrote:
>>>
 Andy Furniss wrote:

 bz2 compressed vid showing the issue -
>
> https://drive.google.com/open?id=0BxP5-S1t9VEEUE5sbUFBV20zSms
>

 To be clear this is just the test rez vid I used so you can
 possibly recreate the issue your self.

>>>
>>> Hmm, interesting, with bicubic, hqscaling=1 this vid behaves
>>> differently with mplayer compared to mpv, the latter looks like
>>> it's scaling a bit, maybe there's an off by one somewhere in mpv
>>> code.
>>>
>>
>> I don't know if it's the cause, but looking for differences between
>> mplayer and mpv it seems that mpv sets video mixer height so it's
>> divisible by 32 but mplayer doesn't. For this 720p sample it uses 736
>> and mplayer uses 720.
>>
>> vdp_video_mixer_create(1, 1, {11}, 3, {0, 1, 2}, {1280, 736, 0}, -)
>>
>> for output surfaces and render calls it uses 720.
>>
>> So does the bicubic code see/use this 736 somewhere?
>>
>
> To answer my own question - it does.
>
> Putting a printf in vl_bicubic.c create_frag_shader video_height = 736
>
> We intialize the filters with height of video mixer, So that explains the
difference.

I was not able to make any progress with offsets nor the artifacts. Can you
try
testing the lanczos filter by removing this line form create_frag_shader :-

ureg_SUB(shader, ureg_writemask(t_array[1], TGSI_WRITEMASK_XY),
ureg_src(t_array[1]), half_pixel);

I am not able to replicate the offset issue in my system, though the
artifacts
issue is reproducible for all levels except 2 and 4

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

Re: [Mesa-dev] [PATCH] gallium/util: add comment on util_is_format_compatible()

[Roland Scheidegger]

Am 21.09.2016 um 17:25 schrieb Brian Paul:
> From reading the code, it's not obvious what is src/dest compatible.
> The list of a->b copy-compatible formats comes from Jose's original
> check-in message, with some format name updates.
> ---
>  src/gallium/auxiliary/util/u_format.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/src/gallium/auxiliary/util/u_format.c 
> b/src/gallium/auxiliary/util/u_format.c
> index cbdb5ce..8881618 100644
> --- a/src/gallium/auxiliary/util/u_format.c
> +++ b/src/gallium/auxiliary/util/u_format.c
> @@ -457,6 +457,30 @@ util_format_write_4i(enum pipe_format format,
> format_desc->pack_rgba_sint(dst_row, dst_stride, src_row, src_stride, w, 
> h);
>  }
>  
> +/**
> + * Check if we can safely memcopy from the source format to the dest format.
> + * This basically covers the cases of a "used" channel copied to a typeless
> + * channel, plus some 1-channel cases.
> + * Examples of compatiblie copy formats include:
compatible

> + *b8g8r8a8_unorm -> b8g8r8x8_unorm
> + *a8r8g8b8_unorm -> x8r8g8b8_unorm
> + *b5g5r5a1_unorm -> b5g5r5x1_unorm
> + *b4g4r4a4_unorm -> b4g4r4x4_unorm
> + *l8_unorm -> r8_unorm
> + *i8_unorm -> l8_unorm
> + *i8_unorm -> a8_unorm
> + *i8_unorm -> r8_unorm
> + *l16_unorm -> r16_unorm
> + *z24_unorm_s8_uint -> z24x8_unorm
> + *s8_uint_z24_unorm -> x8z24_unorm
> + *r8g8b8a8_unorm -> r8g8b8x8_unorm
> + *a8b8g8r8_srgb -> x8b8g8r8_srgb
> + *b8g8r8a8_srgb -> b8g8r8x8_srgb
> + *a8r8g8b8_srgb -> x8r8g8b8_srgb
> + *a8b8g8r8_unorm -> x8b8g8r8_unorm
> + *r10g10b10a2_uscaled -> r10g10b10x2_uscaled
> + *r10sg10sb10sa2u_norm -> r10g10b10x2_snorm
> + */
>  boolean
>  util_is_format_compatible(const struct util_format_description *src_desc,
>const struct util_format_description *dst_desc)
> 

Otherwise looks good to me. (Though I'm always thinking this doesn't
really do the right thing, since you can't determine if formats are
compatible with resource_copy_region as the unorm/uint/float etc.
foramts aren't compatible here. But this is how it has to work for now...)

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

Re: [Mesa-dev] [PATCH 0/2] Implement lanczos interpolation filter

[Andy Furniss]

Andy Furniss wrote:

Andy Furniss wrote:

Andy Furniss wrote:

Andy Furniss wrote:


bz2 compressed vid showing the issue -

https://drive.google.com/open?id=0BxP5-S1t9VEEUE5sbUFBV20zSms


To be clear this is just the test rez vid I used so you can
possibly recreate the issue your self.


Hmm, interesting, with bicubic, hqscaling=1 this vid behaves
differently with mplayer compared to mpv, the latter looks like
it's scaling a bit, maybe there's an off by one somewhere in mpv
code.


I don't know if it's the cause, but looking for differences between
mplayer and mpv it seems that mpv sets video mixer height so it's
divisible by 32 but mplayer doesn't. For this 720p sample it uses 736
and mplayer uses 720.

vdp_video_mixer_create(1, 1, {11}, 3, {0, 1, 2}, {1280, 736, 0}, -)

for output surfaces and render calls it uses 720.

So does the bicubic code see/use this 736 somewhere?


To answer my own question - it does.

Putting a printf in vl_bicubic.c create_frag_shader video_height = 736








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

Re: [Mesa-dev] [PATCH] gallium/util: add comment on util_is_format_compatible()

[Nicolai Hähnle]

Reviewed-by: Nicolai Hähnle 

On 21.09.2016 17:25, Brian Paul wrote:

From reading the code, it's not obvious what is src/dest compatible.
The list of a->b copy-compatible formats comes from Jose's original
check-in message, with some format name updates.
---
 src/gallium/auxiliary/util/u_format.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_format.c 
b/src/gallium/auxiliary/util/u_format.c
index cbdb5ce..8881618 100644
--- a/src/gallium/auxiliary/util/u_format.c
+++ b/src/gallium/auxiliary/util/u_format.c
@@ -457,6 +457,30 @@ util_format_write_4i(enum pipe_format format,
format_desc->pack_rgba_sint(dst_row, dst_stride, src_row, src_stride, w, h);
 }

+/**
+ * Check if we can safely memcopy from the source format to the dest format.
+ * This basically covers the cases of a "used" channel copied to a typeless
+ * channel, plus some 1-channel cases.
+ * Examples of compatiblie copy formats include:
+ *b8g8r8a8_unorm -> b8g8r8x8_unorm
+ *a8r8g8b8_unorm -> x8r8g8b8_unorm
+ *b5g5r5a1_unorm -> b5g5r5x1_unorm
+ *b4g4r4a4_unorm -> b4g4r4x4_unorm
+ *l8_unorm -> r8_unorm
+ *i8_unorm -> l8_unorm
+ *i8_unorm -> a8_unorm
+ *i8_unorm -> r8_unorm
+ *l16_unorm -> r16_unorm
+ *z24_unorm_s8_uint -> z24x8_unorm
+ *s8_uint_z24_unorm -> x8z24_unorm
+ *r8g8b8a8_unorm -> r8g8b8x8_unorm
+ *a8b8g8r8_srgb -> x8b8g8r8_srgb
+ *b8g8r8a8_srgb -> b8g8r8x8_srgb
+ *a8r8g8b8_srgb -> x8r8g8b8_srgb
+ *a8b8g8r8_unorm -> x8b8g8r8_unorm
+ *r10g10b10a2_uscaled -> r10g10b10x2_uscaled
+ *r10sg10sb10sa2u_norm -> r10g10b10x2_snorm
+ */
 boolean
 util_is_format_compatible(const struct util_format_description *src_desc,
   const struct util_format_description *dst_desc)


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

[Mesa-dev] [PATCH] gallium/util: add comment on util_is_format_compatible()

[Brian Paul]

From reading the code, it's not obvious what is src/dest compatible.
The list of a->b copy-compatible formats comes from Jose's original
check-in message, with some format name updates.
---
 src/gallium/auxiliary/util/u_format.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_format.c 
b/src/gallium/auxiliary/util/u_format.c
index cbdb5ce..8881618 100644
--- a/src/gallium/auxiliary/util/u_format.c
+++ b/src/gallium/auxiliary/util/u_format.c
@@ -457,6 +457,30 @@ util_format_write_4i(enum pipe_format format,
format_desc->pack_rgba_sint(dst_row, dst_stride, src_row, src_stride, w, h);
 }
 
+/**
+ * Check if we can safely memcopy from the source format to the dest format.
+ * This basically covers the cases of a "used" channel copied to a typeless
+ * channel, plus some 1-channel cases.
+ * Examples of compatiblie copy formats include:
+ *b8g8r8a8_unorm -> b8g8r8x8_unorm
+ *a8r8g8b8_unorm -> x8r8g8b8_unorm
+ *b5g5r5a1_unorm -> b5g5r5x1_unorm
+ *b4g4r4a4_unorm -> b4g4r4x4_unorm
+ *l8_unorm -> r8_unorm
+ *i8_unorm -> l8_unorm
+ *i8_unorm -> a8_unorm
+ *i8_unorm -> r8_unorm
+ *l16_unorm -> r16_unorm
+ *z24_unorm_s8_uint -> z24x8_unorm
+ *s8_uint_z24_unorm -> x8z24_unorm
+ *r8g8b8a8_unorm -> r8g8b8x8_unorm
+ *a8b8g8r8_srgb -> x8b8g8r8_srgb
+ *b8g8r8a8_srgb -> b8g8r8x8_srgb
+ *a8r8g8b8_srgb -> x8r8g8b8_srgb
+ *a8b8g8r8_unorm -> x8b8g8r8_unorm
+ *r10g10b10a2_uscaled -> r10g10b10x2_uscaled
+ *r10sg10sb10sa2u_norm -> r10g10b10x2_snorm
+ */
 boolean
 util_is_format_compatible(const struct util_format_description *src_desc,
   const struct util_format_description *dst_desc)
-- 
1.9.1

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

[Mesa-dev] [PATCH 1/2] svga: remove disable_shader debug variable

[Brian Paul]

Never used, AFAIK.
---
 src/gallium/drivers/svga/svga_context.c   | 2 --
 src/gallium/drivers/svga/svga_context.h   | 2 --
 src/gallium/drivers/svga/svga_pipe_draw.c | 6 --
 3 files changed, 10 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index 1008510..52fc654 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -50,7 +50,6 @@
 DEBUG_GET_ONCE_BOOL_OPTION(no_swtnl, "SVGA_NO_SWTNL", FALSE)
 DEBUG_GET_ONCE_BOOL_OPTION(force_swtnl, "SVGA_FORCE_SWTNL", FALSE);
 DEBUG_GET_ONCE_BOOL_OPTION(use_min_mipmap, "SVGA_USE_MIN_MIPMAP", FALSE);
-DEBUG_GET_ONCE_NUM_OPTION(disable_shader, "SVGA_DISABLE_SHADER", ~0);
 DEBUG_GET_ONCE_BOOL_OPTION(no_line_width, "SVGA_NO_LINE_WIDTH", FALSE);
 DEBUG_GET_ONCE_BOOL_OPTION(force_hw_line_stipple, 
"SVGA_FORCE_HW_LINE_STIPPLE", FALSE);
 
@@ -163,7 +162,6 @@ struct pipe_context *svga_context_create(struct pipe_screen 
*screen,
svga->debug.no_swtnl = debug_get_option_no_swtnl();
svga->debug.force_swtnl = debug_get_option_force_swtnl();
svga->debug.use_min_mipmap = debug_get_option_use_min_mipmap();
-   svga->debug.disable_shader = debug_get_option_disable_shader();
svga->debug.no_line_width = debug_get_option_no_line_width();
svga->debug.force_hw_line_stipple = 
debug_get_option_force_hw_line_stipple();
 
diff --git a/src/gallium/drivers/svga/svga_context.h 
b/src/gallium/drivers/svga/svga_context.h
index cbc4a9c..5148372 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -441,8 +441,6 @@ struct svga_context
   /* incremented for each shader */
   unsigned shader_id;
 
-  unsigned disable_shader;
-
   boolean no_line_width;
   boolean force_hw_line_stipple;
 
diff --git a/src/gallium/drivers/svga/svga_pipe_draw.c 
b/src/gallium/drivers/svga/svga_pipe_draw.c
index f9d0f0f..d0ceab3 100644
--- a/src/gallium/drivers/svga/svga_pipe_draw.c
+++ b/src/gallium/drivers/svga/svga_pipe_draw.c
@@ -222,12 +222,6 @@ svga_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
 
svga_update_state_retry( svga, SVGA_STATE_NEED_SWTNL );
 
-#ifdef DEBUG
-   if (svga->curr.vs->base.id == svga->debug.disable_shader ||
-   svga->curr.fs->base.id == svga->debug.disable_shader)
-  goto done;
-#endif
-
if (svga->state.sw.need_swtnl) {
   svga->hud.num_fallbacks++;  /* for SVGA_QUERY_NUM_FALLBACKS */
   if (!needed_swtnl) {
-- 
1.9.1

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

[Mesa-dev] [PATCH 2/2] svga: minor simplification in svga_validate_surface_view()

[Brian Paul]

Get rid of unneeded local var.
---
 src/gallium/drivers/svga/svga_surface.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_surface.c 
b/src/gallium/drivers/svga/svga_surface.c
index 42636bc..7cc7ef1 100644
--- a/src/gallium/drivers/svga/svga_surface.c
+++ b/src/gallium/drivers/svga/svga_surface.c
@@ -405,9 +405,9 @@ svga_validate_surface_view(struct svga_context *svga, 
struct svga_surface *s)
 {
enum pipe_error ret = PIPE_OK;
enum pipe_shader_type shader;
-   struct pipe_surface *surf = NULL;
 
assert(svga_have_vgpu10(svga));
+   assert(s);
 
SVGA_STATS_TIME_PUSH(svga_sws(svga),
 SVGA_STATS_TIME_VALIDATESURFACEVIEW);
@@ -481,12 +481,11 @@ svga_validate_surface_view(struct svga_context *svga, 
struct svga_surface *s)
  goto done;
   }
}
-   surf = >base;

 done:
SVGA_STATS_TIME_POP(svga_sws(svga));
 
-   return surf;
+   return >base;
 }
 
 
-- 
1.9.1

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

Re: [Mesa-dev] OSMesa multiple context problem?

[Brian Paul]

On 09/21/2016 08:14 AM, Randall Frank wrote:

Hello,
I have been working around an issue with the OSMesa interface a bit
and was curious if others see this as a bug.  An example that triggers
the issue is:

#include 
#include 
#include 
#include 

int main(int iargs, const char *argv[])
{
 void *pBuf0Ptr, *pBuf1Ptr, *pBuf2Ptr;
 GLsizei iBuf0Width = 720, iBuf0Height = 480;
 GLsizei iBuf1Width = 720, iBuf1Height = 480;
 GLsizei iBuf2Width = 120, iBuf2Height = 120;
 OSMesaContext ctx0, ctx1;
 GLboolean bOk;

 pBuf0Ptr = memalign(iBuf0Width*iBuf0Height*4, 4);
 pBuf1Ptr = memalign(iBuf1Width*iBuf1Height*4, 4);
 pBuf2Ptr = memalign(iBuf2Width*iBuf2Height*4, 4);

 ctx0 = OSMesaCreateContext(GL_RGBA, NULL);
 ctx1 = OSMesaCreateContext(GL_RGBA, NULL);

 bOk = OSMesaMakeCurrent(ctx0, pBuf0Ptr, GL_UNSIGNED_BYTE,
iBuf0Width, iBuf0Height);
 glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
 glFlush();

 bOk = OSMesaMakeCurrent(ctx1, pBuf1Ptr, GL_UNSIGNED_BYTE,
iBuf1Width, iBuf1Height);
 glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
 glFlush();

 bOk = OSMesaMakeCurrent(ctx1, pBuf2Ptr, GL_UNSIGNED_BYTE,
iBuf2Width, iBuf2Height);
 glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
 glFlush();

 bOk = OSMesaMakeCurrent(ctx0, pBuf0Ptr, GL_UNSIGNED_BYTE,
iBuf0Width, iBuf0Height);
 glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
 glFlush();

 exit(0);
}

When I link this to an gallium enabled Mesa build I get a crash during
the flush to the previous context in osmesa_st_framebuffer_flush_front().

I looked into it a bit and I believe there may be an issue with
osmesa_find_buffer(). Since the two contexts initially use the same size
buffers, this function returns the same osmesa_buffer for each context.
This causes a problem when we change the size of one of the contexts
during an OSMesaMakeCurrent() and it changes the buffer fields that are
effectively (incorrectly?) shared.  The flush on the change of context
then crashes...

At least that is my read of the issue. Is this interpretation correct?
If so is there a patch or should we put one together?


Hi Randy,

I don't know if the gallium version of OSMesa has ever got much 
multi-context exercise so I'm not too surprised to hear of a bug.  I 
think you're on the right track.  If you can work it out that'd be 
great.  I don't have much free time right now.


-Brian


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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer  ---
(In reply to Silvan Jegen from comment #2)
> Just to clarify: the trace also includes loading of the game itself (which
> takes a long time too) as well as in-game menu navigation.

Right, replaying the trace crashes for me after the shader compilations on
startup, so my CPU profile only covered that. Maybe you can try getting a CPU
profile of one of the other stalls.

Otherwise, maybe try setting the environment variable
GALLIUM_HUD=.dfps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage,cpu+temperature+GPU-load,.dnum-bytes-moved,.dbuffer-wait-time,.dnum-compilations+num-shaders-created
for either running the game itself or replaying the trace, and taking a
screenshot within one minute after one of the other stalls. That should allow
at least confirming or ruling out that the other stalls are due to shader
compilation as well.

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

Re: [Mesa-dev] [PATCH 0/2] Implement lanczos interpolation filter

[Andy Furniss]

Andy Furniss wrote:

Andy Furniss wrote:

Andy Furniss wrote:


bz2 compressed vid showing the issue -

https://drive.google.com/open?id=0BxP5-S1t9VEEUE5sbUFBV20zSms


To be clear this is just the test rez vid I used so you can
possibly recreate the issue your self.


Hmm, interesting, with bicubic, hqscaling=1 this vid behaves
differently with mplayer compared to mpv, the latter looks like
it's scaling a bit, maybe there's an off by one somewhere in mpv
code.


I don't know if it's the cause, but looking for differences between
mplayer and mpv it seems that mpv sets video mixer height so it's
divisible by 32 but mplayer doesn't. For this 720p sample it uses 736
and mplayer uses 720.

vdp_video_mixer_create(1, 1, {11}, 3, {0, 1, 2}, {1280, 736, 0}, -)

for output surfaces and render calls it uses 720.

So does the bicubic code see/use this 736 somewhere?

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

[Mesa-dev] OSMesa multiple context problem?

[Randall Frank]

Hello,
   I have been working around an issue with the OSMesa interface a bit 
and was curious if others see this as a bug.  An example that triggers 
the issue is:


#include 
#include 
#include 
#include 

int main(int iargs, const char *argv[])
{
void *pBuf0Ptr, *pBuf1Ptr, *pBuf2Ptr;
GLsizei iBuf0Width = 720, iBuf0Height = 480;
GLsizei iBuf1Width = 720, iBuf1Height = 480;
GLsizei iBuf2Width = 120, iBuf2Height = 120;
OSMesaContext ctx0, ctx1;
GLboolean bOk;

pBuf0Ptr = memalign(iBuf0Width*iBuf0Height*4, 4);
pBuf1Ptr = memalign(iBuf1Width*iBuf1Height*4, 4);
pBuf2Ptr = memalign(iBuf2Width*iBuf2Height*4, 4);

ctx0 = OSMesaCreateContext(GL_RGBA, NULL);
ctx1 = OSMesaCreateContext(GL_RGBA, NULL);

bOk = OSMesaMakeCurrent(ctx0, pBuf0Ptr, GL_UNSIGNED_BYTE, 
iBuf0Width, iBuf0Height);

glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glFlush();

bOk = OSMesaMakeCurrent(ctx1, pBuf1Ptr, GL_UNSIGNED_BYTE, 
iBuf1Width, iBuf1Height);

glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glFlush();

bOk = OSMesaMakeCurrent(ctx1, pBuf2Ptr, GL_UNSIGNED_BYTE, 
iBuf2Width, iBuf2Height);

glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glFlush();

bOk = OSMesaMakeCurrent(ctx0, pBuf0Ptr, GL_UNSIGNED_BYTE, 
iBuf0Width, iBuf0Height);

glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glFlush();

exit(0);
}

When I link this to an gallium enabled Mesa build I get a crash during 
the flush to the previous context in osmesa_st_framebuffer_flush_front().


I looked into it a bit and I believe there may be an issue with 
osmesa_find_buffer(). Since the two contexts initially use the same size 
buffers, this function returns the same osmesa_buffer for each context.  
This causes a problem when we change the size of one of the contexts 
during an OSMesaMakeCurrent() and it changes the buffer fields that are 
effectively (incorrectly?) shared.  The flush on the change of context 
then crashes...


At least that is my read of the issue. Is this interpretation correct?  
If so is there a patch or should we put one together?


--
Thanks
rjf.

---
rjfr...@ensight.com voice:919-363-0883 fax:919-363-0833
Computational Engineering International www.ensight.com
2166 North Salem St,  Suite 101,  Apex,  NC  27523-6456

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

[Mesa-dev] [PATCH 1/2] i915: Enable EGL_KHR_gl_texture_3D_image

[Adam Jackson]

Signed-off-by: Adam Jackson 
---
 src/mesa/drivers/dri/i915/intel_screen.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index 19f7a6a..a78e250 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -748,6 +748,9 @@ i915_query_renderer_integer(__DRIscreen *psp, int param, 
unsigned int *value)
case __DRI2_RENDERER_UNIFIED_MEMORY_ARCHITECTURE:
   value[0] = 1;
   return 0;
+   case __DRI2_RENDERER_HAS_TEXTURE_3D:
+  value[0] = 1;
+  return 0;
default:
   return driQueryRendererIntegerCommon(psp, param, value);
}
-- 
2.9.3

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

[Mesa-dev] [PATCH 2/2] i965: Enable EGL_KHR_gl_texture_3D_image

[Adam Jackson]

Signed-off-by: Adam Jackson 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 82d4203..63b02530 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -916,6 +916,9 @@ brw_query_renderer_integer(__DRIscreen *dri_screen,
case __DRI2_RENDERER_UNIFIED_MEMORY_ARCHITECTURE:
   value[0] = 1;
   return 0;
+   case __DRI2_RENDERER_HAS_TEXTURE_3D:
+  value[0] = 1;
+  return 0;
default:
   return driQueryRendererIntegerCommon(dri_screen, param, value);
}
-- 
2.9.3

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

[Mesa-dev] [PATCH 0/2] intel: Enable EGL_KHR_gl_texture_3D_image

[Adam Jackson]

This extension is a prerequisite for EGL 1.5, but the Intel drivers don't
report support for it, and I'm not really sure why, the driver code certainly
looks prepared for it. That said, I haven't tested either of these patches, and
I'm not aware of any apps using the feature (certainly nothing in piglit).

- ajax

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

Re: [Mesa-dev] [PATCH] nir/spirv: Bring back the spirv2nir helper binary

[Jason Ekstrand]

On Wed, Sep 21, 2016 at 4:58 AM, Matt Turner  wrote:

> On Fri, Sep 16, 2016 at 6:59 AM, Jason Ekstrand 
> wrote:
> > This was something that I wrote in the early days of the spirv_to_nir
> code
> > but deleted once we had a real driver.  However, in the absence of a
> > shader_runner equivalent, it's extremely useful for debugging the
> > spirv_to_nir code so let's bring it back.
> > ---
> >  src/compiler/Makefile.nir.am   | 17 +
> >  src/compiler/spirv/spirv2nir.c | 55 ++
> 
> >  2 files changed, 72 insertions(+)
> >  create mode 100644 src/compiler/spirv/spirv2nir.c
> >
> > diff --git a/src/compiler/Makefile.nir.am b/src/compiler/Makefile.nir.am
> > index 9aac214..69ff7b1 100644
> > --- a/src/compiler/Makefile.nir.am
> > +++ b/src/compiler/Makefile.nir.am
> > @@ -53,6 +53,23 @@ nir/nir_opt_algebraic.c: nir/nir_opt_algebraic.py
> nir/nir_algebraic.py
> > $(MKDIR_GEN)
> > $(PYTHON_GEN) $(srcdir)/nir/nir_opt_algebraic.py > $@ || ($(RM)
> $@; false)
> >
> > +noinst_PROGRAMS += spirv2nir
> > +
> > +spirv2nir_SOURCES = \
> > +   spirv/spirv2nir.c
> > +
> > +spirv2nir_CPPFLAGS =   \
> > +   $(AM_CPPFLAGS)  \
> > +   -I$(top_builddir)/src/compiler/nir  \
> > +   -I$(top_srcdir)/src/compiler/nir\
> > +   -I$(top_srcdir)/src/compiler/spirv
> > +
> > +spirv2nir_LDADD =  \
> > +   nir/libnir.la   \
> > +   $(top_builddir)/src/util/libmesautil.la \
> > +   -lm -lstdc++\
>
> Instead of -lstdc++, I think you should to add
> nodist_EXTRA_spirv2nir_SOURCES = dummy.cpp.
>

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

Re: [Mesa-dev] [PATCH v3 0/3] Make eglExportDMABUFImageMESA return corresponding offset.

[Emil Velikov]

On 20 September 2016 at 09:32, Weng, Chuanbo  wrote:
> Hi Emil,
> What you mentioned about style issue in last round is:
> Please move the variable declaration in local scope and add 
> space between ){
> I think I have fixed these issue in this version. Maybe I have 
> misunderstood your meaning.

Reading back, I could have been more verbose. Please skim through the
patches in master, for future reference.

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

Re: [Mesa-dev] [PATCH] nir/spirv: Bring back the spirv2nir helper binary

[Matt Turner]

On Fri, Sep 16, 2016 at 6:59 AM, Jason Ekstrand  wrote:
> This was something that I wrote in the early days of the spirv_to_nir code
> but deleted once we had a real driver.  However, in the absence of a
> shader_runner equivalent, it's extremely useful for debugging the
> spirv_to_nir code so let's bring it back.
> ---
>  src/compiler/Makefile.nir.am   | 17 +
>  src/compiler/spirv/spirv2nir.c | 55 
> ++
>  2 files changed, 72 insertions(+)
>  create mode 100644 src/compiler/spirv/spirv2nir.c
>
> diff --git a/src/compiler/Makefile.nir.am b/src/compiler/Makefile.nir.am
> index 9aac214..69ff7b1 100644
> --- a/src/compiler/Makefile.nir.am
> +++ b/src/compiler/Makefile.nir.am
> @@ -53,6 +53,23 @@ nir/nir_opt_algebraic.c: nir/nir_opt_algebraic.py 
> nir/nir_algebraic.py
> $(MKDIR_GEN)
> $(PYTHON_GEN) $(srcdir)/nir/nir_opt_algebraic.py > $@ || ($(RM) $@; 
> false)
>
> +noinst_PROGRAMS += spirv2nir
> +
> +spirv2nir_SOURCES = \
> +   spirv/spirv2nir.c
> +
> +spirv2nir_CPPFLAGS =   \
> +   $(AM_CPPFLAGS)  \
> +   -I$(top_builddir)/src/compiler/nir  \
> +   -I$(top_srcdir)/src/compiler/nir\
> +   -I$(top_srcdir)/src/compiler/spirv
> +
> +spirv2nir_LDADD =  \
> +   nir/libnir.la   \
> +   $(top_builddir)/src/util/libmesautil.la \
> +   -lm -lstdc++\

Instead of -lstdc++, I think you should to add
nodist_EXTRA_spirv2nir_SOURCES = dummy.cpp.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Problem with RX 480 on Alien: Isolation and Dota 2

[Marek Olšák]

You can use the GALLIUM_HUD environment variable to find out the cause
of those hiccups. Just set it before running steam. Type
"GALLIUM_HUD=help glxgears" - that should print the available options.

From the top of my head, the useful graphs are:
- num-evictions (TTM overhead as the number of buffers moved)
- num-bytes-moved (TTM overhead as the number of bytes moved)
- num-compilations (compiler invocations)

There are also a bunch of useful things like various VRAM and GTT
usage stats, GPU-load, etc.

Marek

On Tue, Sep 20, 2016 at 1:25 AM, Romain Failliot
 wrote:
> 2016-09-19 18:40 GMT-04:00 Marek Olšák :
>> Do you mean the PC is frozen for 2 minutes or just occasional hiccups
>> for 2 minutes?
>
> Occasional hiccups for 2 minutes. The game works well, I wander around
> and, from time to time, it freezes for a random duration between 2
> seconds and 2 minutes (on average I'd say it's 30 seconds) and then
> the game continues like nothing happened (the sound still works during
> the freeze though).
>
> I played yesterday for instance and I had 10 minutes without any
> freeze and then 2 freezes in less than a minute. It's really random,
> but it seems to be related to the new places I visit, once I had one
> or more freezes in an area, I won't have the freeze a freeze in this
> area anymore. That's why I think it could be linked to shader
> compilation.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

Frederic Romagne  changed:

   What|Removed |Added

 CC||frederic.roma...@gmail.com

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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 CC||ved...@miletic.net

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

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #2 from Silvan Jegen  ---
(In reply to Michel Dänzer from comment #1)
> Looks like most of the cycles at the start of the apitrace are spent in the
> GLSL compiler frontend, in particular in do_common_optimization.

Just to clarify: the trace also includes loading of the game itself (which
takes a long time too) as well as in-game menu navigation. Loading the in-game
menus (especially the options) takes a long time too so it *could* be related.

I quit the game after about 1 minute of play time so the last one to two
minutes of the trace should be the actual game.

Thanks for looking into it!

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

Re: [Mesa-dev] [PATCH] nir: Allow opt_peephole_sel to be more aggressive in flattening IFs.

[Ian Romanick]

Reviewed-by: Ian Romanick 

On 09/10/2016 12:43 AM, Eric Anholt wrote:
> VC4 was running into a major performance regression from enabling control
> flow in the glmark2 conditionals test, because of short if statements
> containing an ffract.
> 
> This pass seems like it was was trying to ensure that we only flattened
> IFs that should be entirely a win by guaranteeing that there would be
> fewer bcsels than there were MOVs otherwise.  However, if the number of
> ALU ops is small, we can avoid the overhead of branching (which itself
> costs cycles) and still get a win, even if it means moving real
> instructions out of the THEN/ELSE blocks.
> 
> For now, just turn on aggressive flattening on vc4.  i965 will need some
> tuning to avoid regressions.  It does looks like this may be useful to
> replace freedreno code.
> 
> Improves glmark2 -b conditionals:fragment-steps=5:vertex-steps=0 from 47
> fps to 95 fps on vc4.
> 
> vc4 shader-db:
> total instructions in shared programs: 83220 -> 78887 (-5.21%)
> instructions in affected programs: 21095 -> 16762 (-20.54%)
> total uniforms in shared programs: 25977 -> 25606 (-1.43%)
> uniforms in affected programs: 4196 -> 3825 (-8.84%)
> total estimated cycles in shared programs: 195563 -> 192153 (-1.74%)
> estimated cycles in affected programs: 30171 -> 26761 (-11.30%)
> 
> (This doesn't even count the test being optimized, due to a limitation in
> shader-db-2)
> ---
>  src/compiler/nir/nir.h |  2 +-
>  src/compiler/nir/nir_opt_peephole_select.c | 82 
> --
>  src/gallium/drivers/vc4/vc4_program.c  |  2 +-
>  src/mesa/drivers/dri/i965/brw_nir.c|  2 +-
>  4 files changed, 57 insertions(+), 31 deletions(-)
> 
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index c1cf94001f65..f56f67690d34 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2589,7 +2589,7 @@ bool nir_opt_dead_cf(nir_shader *shader);
>  
>  void nir_opt_gcm(nir_shader *shader);
>  
> -bool nir_opt_peephole_select(nir_shader *shader);
> +bool nir_opt_peephole_select(nir_shader *shader, unsigned limit);
>  
>  bool nir_opt_remove_phis(nir_shader *shader);
>  
> diff --git a/src/compiler/nir/nir_opt_peephole_select.c 
> b/src/compiler/nir/nir_opt_peephole_select.c
> index 633e9f486c08..6a73d737077c 100644
> --- a/src/compiler/nir/nir_opt_peephole_select.c
> +++ b/src/compiler/nir/nir_opt_peephole_select.c
> @@ -32,23 +32,33 @@
>   * Implements a small peephole optimization that looks for
>   *
>   * if (cond) {
> - *
> + *
>   * } else {
> - *
> + *
>   * }
>   * phi
>   * ...
>   * phi
>   *
> - * and replaces it with a series of selects.  It can also handle the case
> - * where, instead of being empty, the if may contain some move operations
> - * whose only use is one of the following phi nodes.  This happens all the
> - * time when the SSA form comes from a conditional assignment with a
> - * swizzle.
> + * and replaces it with:
> + *
> + * 
> + * 
> + * bcsel
> + * ...
> + * bcsel
> + *
> + * where the SSA defs are ALU operations or other cheap instructions (not
> + * texturing, for example).
> + *
> + * If the number of ALU operations in the branches is greater than the limit
> + * parameter, then the optimization is skipped.  In limit=0 mode, the SSA 
> defs
> + * must only be MOVs which we expect to get copy-propagated away once they're
> + * out of the inner blocks.
>   */
>  
>  static bool
> -block_check_for_allowed_instrs(nir_block *block)
> +block_check_for_allowed_instrs(nir_block *block, unsigned *count, bool 
> alu_ok)
>  {
> nir_foreach_instr(instr, block) {
>switch (instr->type) {
> @@ -67,6 +77,11 @@ block_check_for_allowed_instrs(nir_block *block)
>  }
>  break;
>  
> + case nir_intrinsic_load_uniform:
> +if (!alu_ok)
> +   return false;
> +break;
> +
>   default:
>  return false;
>   }
> @@ -89,29 +104,36 @@ block_check_for_allowed_instrs(nir_block *block)
>   case nir_op_vec2:
>   case nir_op_vec3:
>   case nir_op_vec4:
> -/* It must be a move-like operation. */
>  break;
>   default:
> -return false;
> +if (!alu_ok) {
> +   /* It must be a move-like operation. */
> +   return false;
> +}
> +break;
>   }
>  
> - /* Can't handle saturate */
> - if (mov->dest.saturate)
> -return false;
> -
>   /* It must be SSA */
>   if (!mov->dest.dest.is_ssa)
>  return false;
>  
> - /* It cannot have any if-uses */
> - if (!list_empty(>dest.dest.ssa.if_uses))
> -return false;
> + if (alu_ok) {
> +(*count)++;
> + } else {
> +/* Can't handle saturate */
> +if (mov->dest.saturate)

Re: [Mesa-dev] [PATCH] glsl: optimize copy_propagation_elements pass

[Tapani Pälli]

Gentle ping to Eric ..

On 09/16/2016 06:21 PM, Tapani Pälli wrote:

Changes make copy_propagation_elements pass faster, reducing link
time spent in test case of bug 94477. Does not fix the actual issue
but brings down the total time. No regressions seen in CI.

Signed-off-by: Tapani Pälli 
---

For performance measurements, Martina reported in the bug 8x speedup
to the test case shader link time when using this patch together with
commit 2cd02e30d2e1677762d34f1831b8e609970ef0f3

  .../glsl/opt_copy_propagation_elements.cpp | 187 -
  1 file changed, 145 insertions(+), 42 deletions(-)

diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp 
b/src/compiler/glsl/opt_copy_propagation_elements.cpp
index e4237cc..1c5060a 100644
--- a/src/compiler/glsl/opt_copy_propagation_elements.cpp
+++ b/src/compiler/glsl/opt_copy_propagation_elements.cpp
@@ -46,6 +46,7 @@
  #include "ir_basic_block.h"
  #include "ir_optimization.h"
  #include "compiler/glsl_types.h"
+#include "util/hash_table.h"
  
  static bool debug = false;
  
@@ -76,6 +77,18 @@ public:

 int swizzle[4];
  };
  
+/* Class that refers to acp_entry in another exec_list. Used

+ * when making removals based on rhs.
+ */
+class acp_ref : public exec_node
+{
+public:
+   acp_ref(acp_entry *e)
+   {
+  entry = e;
+   }
+   acp_entry *entry;
+};
  
  class kill_entry : public exec_node

  {
@@ -98,14 +111,42 @@ public:
this->killed_all = false;
this->mem_ctx = ralloc_context(NULL);
this->shader_mem_ctx = NULL;
-  this->acp = new(mem_ctx) exec_list;
this->kills = new(mem_ctx) exec_list;
+
+  create_acp();
 }
 ~ir_copy_propagation_elements_visitor()
 {
ralloc_free(mem_ctx);
 }
  
+   void create_acp()

+   {
+  lhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+  rhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+   _mesa_key_pointer_equal);
+   }
+
+   void destroy_acp()
+   {
+  _mesa_hash_table_destroy(lhs_ht, NULL);
+  _mesa_hash_table_destroy(rhs_ht, NULL);
+   }
+
+   void populate_acp(hash_table *lhs, hash_table *rhs)
+   {
+  struct hash_entry *entry;
+  hash_table_foreach(lhs, entry)
+  {
+ _mesa_hash_table_insert(lhs_ht, entry->key, entry->data);
+  }
+  hash_table_foreach(rhs, entry)
+  {
+ _mesa_hash_table_insert(rhs_ht, entry->key, entry->data);
+  }
+   }
+
 void handle_loop(ir_loop *, bool keep_acp);
 virtual ir_visitor_status visit_enter(class ir_loop *);
 virtual ir_visitor_status visit_enter(class ir_function_signature *);
@@ -120,8 +161,10 @@ public:
 void kill(kill_entry *k);
 void handle_if_block(exec_list *instructions);
  
-   /** List of acp_entry: The available copies to propagate */

-   exec_list *acp;
+   /** Hash of acp_entry: The available copies to propagate */
+   hash_table *lhs_ht;
+   hash_table *rhs_ht;
+
 /**
  * List of kill_entry: The variables whose values were killed in this
  * block.
@@ -147,23 +190,29 @@ 
ir_copy_propagation_elements_visitor::visit_enter(ir_function_signature *ir)
  * block.  Any instructions at global scope will be shuffled into
  * main() at link time, so they're irrelevant to us.
  */
-   exec_list *orig_acp = this->acp;
 exec_list *orig_kills = this->kills;
 bool orig_killed_all = this->killed_all;
  
-   this->acp = new(mem_ctx) exec_list;

+   hash_table *orig_lhs_ht = lhs_ht;
+   hash_table *orig_rhs_ht = rhs_ht;
+
 this->kills = new(mem_ctx) exec_list;
 this->killed_all = false;
  
+   create_acp();

+
 visit_list_elements(this, >body);
  
-   ralloc_free(this->acp);

 ralloc_free(this->kills);
  
+   destroy_acp();

+
 this->kills = orig_kills;
-   this->acp = orig_acp;
 this->killed_all = orig_killed_all;
  
+   lhs_ht = orig_lhs_ht;

+   rhs_ht = orig_rhs_ht;
+
 return visit_continue_with_parent;
  }
  
@@ -249,17 +298,19 @@ ir_copy_propagation_elements_visitor::handle_rvalue(ir_rvalue **ir)

 /* Try to find ACP entries covering swizzle_chan[], hoping they're
  * the same source variable.
  */
-   foreach_in_list(acp_entry, entry, this->acp) {
-  if (var == entry->lhs) {
-for (int c = 0; c < chans; c++) {
-   if (entry->write_mask & (1 << swizzle_chan[c])) {
-  source[c] = entry->rhs;
-  source_chan[c] = entry->swizzle[swizzle_chan[c]];
+   hash_entry *ht_entry = _mesa_hash_table_search(lhs_ht, var);
+   if (ht_entry) {
+  exec_list *ht_list = (exec_list *) ht_entry->data;
+  foreach_in_list(acp_entry, entry, ht_list) {
+ for (int c = 0; c < chans; c++) {
+if (entry->write_mask & (1 << swizzle_chan[c])) {
+   source[c] = entry->rhs;
+   source_chan[c] = entry->swizzle[swizzle_chan[c]];
  
 

Re: [Mesa-dev] [PATCH] i965: Enable ES 3.2 on Skylake.

[Matt Turner]

On Wed, Sep 21, 2016 at 7:35 AM, Kenneth Graunke  wrote:
> It's already advertised because the version.c extension checks are
> fulfilled, but we didn't actually claim support, so trying to create
> a ES 3.2 context would fail.
>
> It's all done, and the CTS results look good, so let's turn it on.
>
> Signed-off-by: Kenneth Graunke 

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