[Mesa-dev] [Bug 96979] Mesa 10.5.7 implementation error: Trying to disable permanently enabled extensions

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96979

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #10 from Timothy Arceri  ---
(In reply to Emil Velikov from comment #5)
> With 12.0 (commit 21d43fe51ab5bcbc89ad5c61a51d3517c4243298) one should be
> able to disable permanently enabled extensions in a way that glGetString{,i}
> honours it.
> 
> IIRC the above patch depends it depends on other extensions work by Nanley
> so picking it on top of 11.0.x might fare too well.
> 
> Note that MESA_EXTENSION_OVERRIDE is aimed for development/workarounds and
> {en,dis}abling extension X does not magically {give,remove} all the
> functionality associated with it.

Assuming this was fixed. Closing.

-- 
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 103921] llvmpipe consume all resources on GPU Vega RX (amdgpu driver) with mesa 17.2.4 if disabled IGPU

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103921

--- Comment #3 from mikhail.v.gavri...@gmail.com ---
> llvmpipe should work with amdgpu same as with VESA driver without consuming 
> all CPU resources.

it means llvmpipe with vesa driver is possible use but llvmpipe with amdgpu
impossible use because driver consume for unknown reason much more resources
than with vesa driver.

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


[Mesa-dev] [Bug 103921] llvmpipe consume all resources on GPU Vega RX (amdgpu driver) with mesa 17.2.4 if disabled IGPU

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103921

--- Comment #2 from mikhail.v.gavri...@gmail.com ---
You don't understand me.
I know how llvmpipe work.
I just want to say that in described case llvmpipe consume resources abnormaly
(mean much more than usual)

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


[Mesa-dev] [Bug 97067] WebGL: conformance/glsl/misc/shaders-with-invariance.html Fail

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=97067

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #5 from Timothy Arceri  ---
(In reply to Tapani Pälli from comment #4)
> This test is passing on i965 with following versions:
> 
> Google Chrome 55.0.2883.87
> Mesa 17.0.0-devel (git-0252ba2)

Works with recent radeonsi too. Closing.

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


[Mesa-dev] [Bug 98473] Mesa fails to build with flex 2.6.2

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98473

Timothy Arceri  changed:

   What|Removed |Added

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

-- 
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 98471] [TRACKER] Mesa 13.0 release tracker

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98471
Bug 98471 depends on bug 98473, which changed state.

Bug 98473 Summary: Mesa fails to build with flex 2.6.2
https://bugs.freedesktop.org/show_bug.cgi?id=98473

   What|Removed |Added

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

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


[Mesa-dev] [Bug 103921] llvmpipe consume all resources on GPU Vega RX (amdgpu driver) with mesa 17.2.4 if disabled IGPU

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103921

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #1 from Timothy Arceri  ---
You want to be using radeonsi not llvmpipe. llvmpipe is a software renderer and
will indeed be slow.

-- 
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 103672] _mesa_meta_GenerateMipmap sub-optimal code and possible bug

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103672

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes
   |org |ktop.org
  Component|Mesa core   |Drivers/DRI/i965
 QA Contact|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes
   |org |ktop.org

--- Comment #1 from Timothy Arceri  ---
Moving to i965 as it is the only driver to use this.

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


[Mesa-dev] [Bug 105846] Assertion failure @ st_atom_array.c:675 when playing Natural Selection 2

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105846

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #13 from Timothy Arceri  ---
(In reply to las from comment #12)
> Just crashed with MESA_VERBOSE=all and MESA_DEBUG=context, but I got a nice
> error message:
> Mesa: User error: GL_INVALID_OPERATION in glVertexAttribPointer(non-VBO
> array)
> ns2_linux: ../src/mesa/state_tracker/st_atom_array.c:675:
> setup_non_interleaved_attribs: Assertion `attrib->Ptr' failed.

It's likely a game bug considering the error message but this could be
confirmed if you grab an apitrace [1] of the crash and upload it to google
drive (or somewhere like that) and link to it from here.

https://github.com/apitrace/apitrace/wiki/Steam

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


[Mesa-dev] [Bug 105730] [llvmpipe] 109 piglit failures, 19264 crashes on ppc (ppc64, mesa-18.0.0)

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105730

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #6 from Timothy Arceri  ---
(In reply to erhard_f from comment #0)
> Created attachment 138337 [details]
> results from 'pigllit run all'
> 
> My G5 had some fun running piglit with llvmpipe on Big Endian ppc64. Just
> wanted to share the results.
> 

Thanks for your interest in Mesa but unless you are willing to create patches
this information is not all that for tracking in a bug report. Things change
fast and anyone interested in fixing it can just run piglit to get the latests
results.

With this is mind I'm going to close this bug report. If you wish to discuss
Big Endian support the mailing list or IRC are probably better forums.

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


[Mesa-dev] [PATCH] vulkan: Drop vk_android_native_buffer.xml

2018-04-09 Thread Jason Ekstrand
All the information in vk_android_native_buffer.xml is now in vk.xml.
The only exception is the extension type attribute which we can work
around in the generators while we wait for the XML to be fixed.

Cc: Dylan Baker 
Cc: Tapani Pälli 
---
 src/amd/vulkan/Makefile.am   |  3 --
 src/amd/vulkan/meson.build   |  4 +-
 src/amd/vulkan/radv_extensions.py| 17 +++-
 src/intel/Android.vulkan.mk  |  6 +--
 src/intel/Makefile.vulkan.am | 13 ++
 src/intel/vulkan/anv_extensions_gen.py   | 17 +++-
 src/intel/vulkan/meson.build | 12 +++---
 src/vulkan/Android.mk|  4 +-
 src/vulkan/Makefile.am   |  5 +--
 src/vulkan/meson.build   |  1 -
 src/vulkan/registry/vk_android_native_buffer.xml | 52 
 11 files changed, 26 insertions(+), 108 deletions(-)
 delete mode 100644 src/vulkan/registry/vk_android_native_buffer.xml

diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 00b8082..18f263a 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -117,13 +117,11 @@ nodist_EXTRA_libvulkan_radeon_la_SOURCES = dummy.cpp
 libvulkan_radeon_la_SOURCES = $(VULKAN_GEM_FILES)
 
 vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
-vk_android_native_buffer_xml = 
$(top_srcdir)/src/vulkan/registry/vk_android_native_buffer.xml
 
 radv_entrypoints.c: radv_entrypoints_gen.py radv_extensions.py 
$(vulkan_api_xml)
$(MKDIR_GEN)
$(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_entrypoints_gen.py \
--xml $(vulkan_api_xml) \
-   --xml $(vk_android_native_buffer_xml) \
--outdir $(builddir)
 radv_entrypoints.h: radv_entrypoints.c
 
@@ -132,7 +130,6 @@ radv_extensions.c: radv_extensions.py \
$(MKDIR_GEN)
$(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_extensions.py \
--xml $(vulkan_api_xml) \
-   --xml $(vk_android_native_buffer_xml) \
--out-c radv_extensions.c \
--out-h radv_extensions.h
 radv_extensions.h: radv_extensions.c
diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
index c3a6a81..b5a99fe 100644
--- a/src/amd/vulkan/meson.build
+++ b/src/amd/vulkan/meson.build
@@ -31,10 +31,10 @@ radv_entrypoints = custom_target(
 
 radv_extensions_c = custom_target(
   'radv_extensions.c',
-  input : ['radv_extensions.py', vk_api_xml, vk_android_native_buffer_xml],
+  input : ['radv_extensions.py', vk_api_xml],
   output : ['radv_extensions.c', 'radv_extensions.h'],
   command : [
-prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@', 
'--out-c', '@OUTPUT0@',
+prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--out-c', '@OUTPUT0@',
 '--out-h', '@OUTPUT1@'
   ],
 )
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index a25db63..a680f42 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -159,18 +159,13 @@ def _init_exts_from_xml(xml):
 if ext_name not in ext_name_map:
 continue
 
-# Workaround for VK_ANDROID_native_buffer. Its  element in
-# vk.xml lists it as supported="disabled" and provides only a stub
-# definition.  Its  element in Mesa's custom
-# vk_android_native_buffer.xml, though, lists it as
-# supported='android-vendor' and fully defines the extension. We want
-# to skip the  element in vk.xml.
-if ext_elem.attrib['supported'] == 'disabled':
-assert ext_name == 'VK_ANDROID_native_buffer'
-continue
-
 ext = ext_name_map[ext_name]
-ext.type = ext_elem.attrib['type']
+if ext_name == 'VK_ANDROID_native_buffer':
+# VK_ANDROID_native_buffer is missing the type specifier.  Just
+# hard-code it to be a device extension for now.
+ext.type = 'device'
+else:
+ext.type = ext_elem.attrib['type']
 
 _TEMPLATE_H = Template(COPYRIGHT + """
 #ifndef RADV_EXTENSIONS_H
diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 0ec0d78..09dc228 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -67,8 +67,7 @@ $(intermediates)/vulkan/dummy.c:
 $(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c
$(VK_ENTRYPOINTS_SCRIPT) \
--outdir $(dir $@) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
-   --xml 
$(MESA_TOP)/src/vulkan/registry/vk_android_native_buffer.xml
+   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
 
 LOCAL_EXPORT_C_INCLUDE_DIRS := \
 $(intermediates)
@@ -245,21 +244,18 @@ $(intermediates)/vulkan/anv_entrypoints.c:
@mkdir -p $(dir $@)
$(VK_ENTRYPOINTS_SCRIPT) \
--xml 

[Mesa-dev] [PATCH 08/10] glsl: use NIR function inlining for drivers that use glsl_to_nir

2018-04-09 Thread Timothy Arceri
---
 src/compiler/glsl/glsl_to_nir.cpp | 20 
 1 file changed, 20 insertions(+)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index 5a36963607e..55c01024669 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -26,6 +26,7 @@
  */
 
 #include "glsl_to_nir.h"
+#include "ir_optimization.h"
 #include "ir_visitor.h"
 #include "ir_hierarchical_visitor.h"
 #include "ir.h"
@@ -161,6 +162,25 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
v2.run(sh->ir);
visit_exec_list(sh->ir, );
 
+   nir_validate_shader(shader);
+
+   /* We have to lower away local constant initializers right before we
+* inline functions.  That way they get properly initialized at the top
+* of the function and not at the top of its caller.
+*/
+   nir_lower_constant_initializers(shader, nir_var_local);
+   nir_lower_returns(shader);
+   nir_inline_functions(shader);
+
+   /* Now that we have inlined everything remove all of the functions except
+* main().
+*/
+   foreach_list_typed_safe(nir_function, function, node, &(shader)->functions){
+  if (strcmp("main", function->name) != 0) {
+ exec_node_remove(>node);
+  }
+   }
+
nir_lower_constant_initializers(shader, (nir_variable_mode)~0);
 
/* Remap the locations to slots so those requiring two slots will occupy
-- 
2.17.0

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


[Mesa-dev] [PATCH 05/10] glsl: make a copy of array indices that are used to deref a function out param

2018-04-09 Thread Timothy Arceri
Fixes new piglit test:
tests/spec/glsl-1.20/execution/qualifiers/vs-out-conversion-int-to-float-vec4-index.shader_test
---
 src/compiler/glsl/ast_function.cpp | 94 ++
 1 file changed, 94 insertions(+)

diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index 94e0a16a9c0..eab18446ef8 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -348,6 +348,93 @@ verify_parameter_modes(_mesa_glsl_parse_state *state,
return true;
 }
 
+static void
+copy_index_derefs_to_temps(void *mem_ctx, ir_rvalue *param,
+   exec_list *before_instructions)
+{
+   /* Loop through the IR copying array indices until we find a swizzle,
+* costant or variable ref.
+*/
+   ir_rvalue *ir = param;
+   while (ir != NULL) {
+  switch (ir->ir_type) {
+  case ir_type_dereference_record: {
+ ir_dereference_record *r = (ir_dereference_record *) ir;
+ ir = r->record->as_dereference();
+ break;
+  }
+
+  case ir_type_swizzle: {
+ ir_swizzle *s = (ir_swizzle *) ir;
+ ir = s->val->as_dereference();
+ break;
+  }
+
+  case ir_type_expression: {
+ ir_expression *expr = (ir_expression* ) ir;
+ for (unsigned int i = 0; i < expr->num_operands; i++) {
+copy_index_derefs_to_temps(mem_ctx, expr->operands[i],
+   before_instructions);
+ }
+
+ ir = NULL;
+ break;
+  }
+
+  case ir_type_dereference_array: {
+ ir_dereference_array *a = (ir_dereference_array *) ir;
+ ir = a->array->as_dereference();
+
+ ir_rvalue *idx = a->array_index;
+ copy_index_derefs_to_temps(mem_ctx, idx, before_instructions);
+
+ if (idx->as_dereference_variable()) {
+ir_variable *var = idx->variable_referenced();
+
+/* If the index is read only it cannot change so there is no need
+ * to copy it.
+ */
+if (var->data.read_only || var->data.memory_read_only)
+   break;
+ }
+
+ ir_variable *tmp = new(mem_ctx) ir_variable(idx->type, "idx_tmp",
+ ir_var_temporary);
+ before_instructions->push_tail(tmp);
+
+ ir_dereference_variable *const deref_tmp_1 =
+new(mem_ctx) ir_dereference_variable(tmp);
+ ir_assignment *const assignment =
+new(mem_ctx) ir_assignment(deref_tmp_1,
+   idx->clone(mem_ctx, NULL));
+ before_instructions->push_tail(assignment);
+
+ /* Replace the array index with a dereference of the new temporary.
+  */
+ ir_dereference_variable *const deref_tmp_2 =
+new(mem_ctx) ir_dereference_variable(tmp);
+ a->array_index = deref_tmp_2;
+ break;
+  }
+
+  case ir_type_dereference_variable: {
+ ir = NULL;
+ break;
+  }
+
+  case ir_type_constant: {
+ /* Nothing to do for constants */
+ ir = NULL;
+ break;
+  }
+
+  default:
+ unreachable("Unexpected deref type");
+ break;
+  }
+   }
+}
+
 static void
 fix_parameter(void *mem_ctx, ir_rvalue *actual, const glsl_type *formal_type,
   exec_list *before_instructions, exec_list *after_instructions,
@@ -362,6 +449,13 @@ fix_parameter(void *mem_ctx, ir_rvalue *actual, const 
glsl_type *formal_type,
&& (expr == NULL || expr->operation != ir_binop_vector_extract))
   return;
 
+   /* An array index could also be an out variable so we need to make a copy
+* of them before the function is called.
+*/
+   if (!actual->as_dereference_variable()) {
+  copy_index_derefs_to_temps(mem_ctx, actual, before_instructions);
+   }
+
/* To convert an out parameter, we need to create a temporary variable to
 * hold the value before conversion, and then perform the conversion after
 * the function call returns.
-- 
2.17.0

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


[Mesa-dev] [PATCH 07/10] nir: return early when lowering a return at the end of a function

2018-04-09 Thread Timothy Arceri
Otherwise we create unused conditional return flags and things
get unnecessarily ugly fast when lowering nested functions.
---
 src/compiler/nir/nir_lower_returns.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/compiler/nir/nir_lower_returns.c 
b/src/compiler/nir/nir_lower_returns.c
index 423192adb8a..e1ba5f2ad64 100644
--- a/src/compiler/nir/nir_lower_returns.c
+++ b/src/compiler/nir/nir_lower_returns.c
@@ -27,6 +27,7 @@
 
 struct lower_returns_state {
nir_builder builder;
+   nir_function_impl *impl;
struct exec_list *cf_list;
nir_loop *loop;
nir_variable *return_flag;
@@ -180,6 +181,12 @@ lower_returns_in_block(nir_block *block, struct 
lower_returns_state *state)
 
nir_instr_remove(>instr);
 
+   /* If this is a return in the last block of the function there is nothing
+* more to do once its removed.
+*/
+   if (block == nir_impl_last_block(state->impl))
+  return true;
+
nir_builder *b = >builder;
 
/* Set the return flag */
@@ -252,6 +259,7 @@ nir_lower_returns_impl(nir_function_impl *impl)
 {
struct lower_returns_state state;
 
+   state.impl = impl;
state.cf_list = >body;
state.loop = NULL;
state.return_flag = NULL;
-- 
2.17.0

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


[Mesa-dev] [PATCH 10/10] i965: use the optimise conservatively option for GLSL IR

2018-04-09 Thread Timothy Arceri
Shader-db compile times on IVB:

With this patch:

Thread 1 took 368.68 seconds and compiled 16434 shaders
Thread 2 took 372.83 seconds and compiled 16930 shaders
Thread 3 took 370.27 seconds and compiled 16891 shaders
Thread 0 took 377.69 seconds and compiled 16753 shaders

Without this patch:

Thread 0 took 406.49 seconds and compiled 16501 shaders
Thread 3 took 402.31 seconds and compiled 17305 shaders
Thread 1 took 404.31 seconds and compiled 16533 shaders
Thread 2 took 401.41 seconds and compiled 16669 shaders

Shader-db results IVB:

total instructions in shared programs: 9995922 -> 9995889 (-0.00%)
instructions in affected programs: 21378 -> 21345 (-0.15%)
helped: 58
HURT: 63

total cycles in shared programs: 230938039 -> 230940598 (0.00%)
cycles in affected programs: 2580108 -> 2582667 (0.10%)
helped: 954
HURT: 1146
---
 src/mesa/drivers/dri/i965/brw_context.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 01a3e16583d..3710413fe36 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -399,6 +399,8 @@ brw_initialize_context_constants(struct brw_context *brw)
ctx->Const.MaxCombinedShaderOutputResources =
   MAX_IMAGE_UNITS + BRW_MAX_DRAW_BUFFERS;
 
+   ctx->Const.GLSLOptimizeConservatively = true;
+
/* The timestamp register we can read for glGetTimestamp() is
 * sometimes only 32 bits, before scaling to nanoseconds (depending
 * on kernel).
-- 
2.17.0

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


[Mesa-dev] [PATCH 06/10] glsl: copy function out to temp if we don't directly ref a variable

2018-04-09 Thread Timothy Arceri
Otherwise we can end up with IR that looks like this:

(
  (declare (temporary ) vec4 f@8)
  (assign  (xyzw) (var_ref f@8)  (var_ref f) )
  (call f16  ((swiz y (var_ref f@8) )))

  (assign  (xyzw) (var_ref f)  (var_ref f@8) )
))

When we really need:

  (declare (temporary ) float inout_tmp)
  (assign  (x) (var_ref inout_tmp)  (swiz y (var_ref f) ))
  (call f16  ((var_ref inout_tmp) ))

  (assign  (y) (var_ref f)  (swiz y (swiz  (var_ref inout_tmp) )))
  (declare (temporary ) void void_var)

The GLSL IR function inlining code seemed to produce correct code
even without this but we need the correct IR for GLSL IR -> NIR to
be able to understand whats going on.
---
 src/compiler/glsl/ast_function.cpp | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index eab18446ef8..fff911e76d0 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -446,7 +446,8 @@ fix_parameter(void *mem_ctx, ir_rvalue *actual, const 
glsl_type *formal_type,
 * nothing needs to be done to fix the parameter.
 */
if (formal_type == actual->type
-   && (expr == NULL || expr->operation != ir_binop_vector_extract))
+   && (expr == NULL || expr->operation != ir_binop_vector_extract) &&
+   actual->as_dereference_variable())
   return;
 
/* An array index could also be an out variable so we need to make a copy
@@ -496,7 +497,7 @@ fix_parameter(void *mem_ctx, ir_rvalue *actual, const 
glsl_type *formal_type,
   ir_dereference_variable *const deref_tmp_1 =
  new(mem_ctx) ir_dereference_variable(tmp);
   ir_assignment *const assignment =
- new(mem_ctx) ir_assignment(deref_tmp_1, actual);
+ new(mem_ctx) ir_assignment(deref_tmp_1, actual->clone(mem_ctx, NULL));
   before_instructions->push_tail(assignment);
}
 
-- 
2.17.0

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


[Mesa-dev] [PATCH 04/10] glsl: always clone deref in evaluate_deref()

2018-04-09 Thread Timothy Arceri
NIR validation will failing without this once we start using
glsl_to_nir() for functions other than main. i.e. once we stop
lowering all functions in GLSL IR.
---
 src/compiler/glsl/glsl_to_nir.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index c4b3b4315d4..5a36963607e 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -213,8 +213,7 @@ nir_deref_var *
 nir_visitor::evaluate_deref(nir_instr *mem_ctx, ir_instruction *ir)
 {
ir->accept(this);
-   ralloc_steal(mem_ctx, this->deref_head);
-   return this->deref_head;
+   return nir_deref_var_clone(this->deref_head, mem_ctx);
 }
 
 static nir_constant *
-- 
2.17.0

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


[Mesa-dev] [PATCH 09/10] i965: stop calling nir_lower_returns()

2018-04-09 Thread Timothy Arceri
We now call this for all drivers in glsl_to_nir() instead.
---
 src/mesa/drivers/dri/i965/brw_program.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index fc77926d6e0..8c3ac70280f 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -84,7 +84,6 @@ brw_create_nir(struct brw_context *brw,
   assert (nir);
 
   nir_remove_dead_variables(nir, nir_var_shader_in | nir_var_shader_out);
-  nir_lower_returns(nir);
   nir_validate_shader(nir);
   NIR_PASS_V(nir, nir_lower_io_to_temporaries,
  nir_shader_get_entrypoint(nir), true, false);
-- 
2.17.0

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


[Mesa-dev] [PATCH 03/10] glsl: add function support to glsl_to_nir

2018-04-09 Thread Timothy Arceri
This support was missing because currently we always let GLSL IR
inline the functions.
---
 src/compiler/glsl/glsl_to_nir.cpp | 76 +++
 1 file changed, 68 insertions(+), 8 deletions(-)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index dbb58d82e8f..c4b3b4315d4 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -489,8 +489,24 @@ nir_visitor::create_function(ir_function_signature *ir)
 
nir_function *func = nir_function_create(shader, ir->function_name());
 
-   assert(ir->parameters.is_empty());
-   assert(ir->return_type == glsl_type::void_type);
+   func->num_params = ir->parameters.length();
+   func->params = ralloc_array(shader, nir_parameter, func->num_params);
+
+   unsigned np = 0;
+   foreach_in_list(ir_variable, param, >parameters) {
+   func->params[np].type = param->type;
+  if (param->data.mode == ir_var_function_inout) {
+ func->params[np].param_type = nir_parameter_inout;
+  } else if (param->data.mode == ir_var_function_out) {
+ func->params[np].param_type = nir_parameter_out;
+  } else {
+ func->params[np].param_type = nir_parameter_in;
+  }
+  np++;
+   }
+   assert(np == func->num_params);
+
+   func->return_type = ir->return_type;
 
_mesa_hash_table_insert(this->overload_table, ir, func);
 }
@@ -518,9 +534,11 @@ nir_visitor::visit(ir_function_signature *ir)
   nir_function_impl *impl = nir_function_impl_create(func);
   this->impl = impl;
 
-  assert(strcmp(func->name, "main") == 0);
-  assert(ir->parameters.is_empty());
-  assert(func->return_type == glsl_type::void_type);
+  unsigned i = 0;
+  foreach_in_list(ir_variable, param, >parameters) {
+ _mesa_hash_table_insert(var_table, param, impl->params[i]);
+ i++;
+  }
 
   this->is_global = false;
 
@@ -620,7 +638,24 @@ nir_visitor::visit(ir_return *ir)
  nir_intrinsic_instr_create(this->shader, nir_intrinsic_copy_var);
 
   copy->variables[0] = nir_deref_var_create(copy, this->impl->return_var);
-  copy->variables[1] = evaluate_deref(>instr, ir->value);
+
+  nir_ssa_def *val = evaluate_rvalue(ir->value);
+
+  nir_variable *var =
+ nir_local_variable_create(this->impl, ir->value->type, "return_temp");
+
+  nir_intrinsic_instr *store =
+ nir_intrinsic_instr_create(this->shader, nir_intrinsic_store_var);
+  store->num_components = ir->value->type->vector_elements;
+  nir_intrinsic_set_write_mask(store, (1 << store->num_components) - 1);
+  store->variables[0] = nir_deref_var_create(store, var);
+  store->src[0] = nir_src_for_ssa(val);
+
+  nir_builder_instr_insert(, >instr);
+
+  copy->variables[1] = nir_deref_var_clone(store->variables[0], 
>instr);
+
+  nir_builder_instr_insert(, >instr);
}
 
nir_jump_instr *instr = nir_jump_instr_create(this->shader, 
nir_jump_return);
@@ -1241,11 +1276,36 @@ nir_visitor::visit(ir_call *ir)
 
unsigned i = 0;
foreach_in_list(ir_dereference, param, >actual_parameters) {
-  instr->params[i] = evaluate_deref(>instr, param);
+
+  nir_deref_var *param_deref;
+  if (!param->as_dereference_variable()) {
+ ir_rvalue *param_rvalue = param->as_rvalue();
+ nir_variable *var =
+nir_local_variable_create(this->impl, param_rvalue->type,
+  "param_temp");
+
+ nir_ssa_def *val = evaluate_rvalue(param_rvalue);
+
+ nir_intrinsic_instr *store =
+nir_intrinsic_instr_create(this->shader, nir_intrinsic_store_var);
+ store->num_components = param_rvalue->type->vector_elements;
+ nir_intrinsic_set_write_mask(store, (1 << store->num_components) - 1);
+ store->variables[0] = nir_deref_var_create(store, var);
+ store->src[0] = nir_src_for_ssa(val);
+
+ nir_builder_instr_insert(, >instr);
+ param_deref = nir_deref_var_clone(store->variables[0], >instr);
+  } else {
+ param_deref = evaluate_deref(>instr, param);
+  }
+
+  instr->params[i] = param_deref;
   i++;
}
 
-   instr->return_deref = evaluate_deref(>instr, ir->return_deref);
+   if (ir->return_deref)
+  instr->return_deref = evaluate_deref(>instr, ir->return_deref);
+
nir_builder_instr_insert(, >instr);
 }
 
-- 
2.17.0

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


[Mesa-dev] [PATCH 02/10] glsl: add missing include to ir_optimization.h

2018-04-09 Thread Timothy Arceri
---
 src/compiler/glsl/ir_optimization.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compiler/glsl/ir_optimization.h 
b/src/compiler/glsl/ir_optimization.h
index 81049a479e8..f5d2bea0cd5 100644
--- a/src/compiler/glsl/ir_optimization.h
+++ b/src/compiler/glsl/ir_optimization.h
@@ -30,6 +30,8 @@
 #ifndef GLSL_IR_OPTIMIZATION_H
 #define GLSL_IR_OPTIMIZATION_H
 
+#include "ir.h"
+
 /* Operations for lower_instructions() */
 #define SUB_TO_ADD_NEG 0x01
 #define FDIV_TO_MUL_RCP0x02
-- 
2.17.0

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


[Mesa-dev] [PATCH 01/10] glsl: replace some asserts with unreachable when processing the ast

2018-04-09 Thread Timothy Arceri
---
 src/compiler/glsl/ast_to_hir.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 168ab7eec2f..4d7383c580f 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -1396,7 +1396,7 @@ ast_expression::do_hir(exec_list *instructions,
 
switch (this->oper) {
case ast_aggregate:
-  assert(!"ast_aggregate: Should never get here.");
+  unreachable("ast_aggregate: Should never get here.");
   break;
 
case ast_assign: {
@@ -1973,14 +1973,14 @@ ast_expression::do_hir(exec_list *instructions,
}
 
case ast_unsized_array_dim:
-  assert(!"ast_unsized_array_dim: Should never get here.");
+  unreachable("ast_unsized_array_dim: Should never get here.");
   break;
 
case ast_function_call:
   /* Should *NEVER* get here.  ast_function_call should always be handled
* by ast_function_expression::hir.
*/
-  assert(0);
+  unreachable("ast_function_call: handled elsewhere ");
   break;
 
case ast_identifier: {
-- 
2.17.0

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


[Mesa-dev] NIR function inlining for faster compile times

2018-04-09 Thread Timothy Arceri
This series is part of an effort to reduce the regression in compile
times when switching radeonsi from TGIS -> NIR. But it also turns
out to be quite handy for i965 too.

The idea is to make better use of GLSLOptimizeConservatively.
Currently TGSI must ignore the flag until all functions have been
inlined by the GLSL IR opts. Since NIR can do function inlining we
can drop the post linking opts calls for Gallium drivers that use
NIR and just use the faster NIR opts instead. The patches to do
this will come in a follow-up series since it requires some
refactoring and testing and I wanted to get this out for review.

For i965 this series enables GLSLOptimizeConservatively for a nice
boost in compile times and very little change in shader-db.


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


[Mesa-dev] [PATCH v2] nv50/ir: make a copy of tex src if it's referenced multiple times

2018-04-09 Thread Ilia Mirkin
For nv50 we coalesce the srcs and defs into a single node. As such, we
can end up with impossible constraints if the source is referenced
after the tex operation (which, due to the coalescing of values, will
have overwritten it).

This logic already exists for inserting moves for MERGE/UNION sources.
It's the exact same idea here, so leverage that code, which also
includes a few optimizations around not extending live ranges
unnecessarily.

Signed-off-by: Ilia Mirkin 
---

v1 -> v2: make use of existing logic in insertConstraintMoves

 src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 86 --
 1 file changed, 49 insertions(+), 37 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 3a0e56e1385..7d107aca68d 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -257,6 +257,7 @@ private:
private:
   virtual bool visit(BasicBlock *);
 
+  void insertConstraintMove(Instruction *, int s);
   bool insertConstraintMoves();
 
   void condenseDefs(Instruction *);
@@ -2216,6 +2217,8 @@ 
RegAlloc::InsertConstraintsPass::texConstraintNV50(TexInstruction *tex)
for (c = 0; tex->srcExists(c) || tex->defExists(c); ++c) {
   if (!tex->srcExists(c))
  tex->setSrc(c, new_LValue(func, tex->getSrc(0)->asLValue()));
+  else
+ insertConstraintMove(tex, c);
   if (!tex->defExists(c))
  tex->setDef(c, new_LValue(func, tex->getDef(0)->asLValue()));
}
@@ -2288,6 +2291,51 @@ RegAlloc::InsertConstraintsPass::visit(BasicBlock *bb)
return true;
 }
 
+void
+RegAlloc::InsertConstraintsPass::insertConstraintMove(Instruction *cst, int s)
+{
+   const uint8_t size = cst->src(s).getSize();
+
+   assert(cst->getSrc(s)->defs.size() == 1); // still SSA
+
+   Instruction *defi = cst->getSrc(s)->defs.front()->getInsn();
+   bool imm = defi->op == OP_MOV &&
+  defi->src(0).getFile() == FILE_IMMEDIATE;
+   bool load = defi->op == OP_LOAD &&
+  defi->src(0).getFile() == FILE_MEMORY_CONST &&
+  !defi->src(0).isIndirect(0);
+   // catch some cases where don't really need MOVs
+   if (cst->getSrc(s)->refCount() == 1 && !defi->constrainedDefs()) {
+  if (imm || load) {
+ // Move the defi right before the cst. No point in expanding
+ // the range.
+ defi->bb->remove(defi);
+ cst->bb->insertBefore(cst, defi);
+  }
+  return;
+   }
+
+   LValue *lval = new_LValue(func, cst->src(s).getFile());
+   lval->reg.size = size;
+
+   Instruction *mov = new_Instruction(func, OP_MOV, typeOfSize(size));
+   mov->setDef(0, lval);
+   mov->setSrc(0, cst->getSrc(s));
+
+   if (load) {
+  mov->op = OP_LOAD;
+  mov->setSrc(0, defi->getSrc(0));
+   } else if (imm) {
+  mov->setSrc(0, defi->getSrc(0));
+   }
+
+   if (defi->getPredicate())
+  mov->setPredicate(defi->cc, defi->getPredicate());
+
+   cst->setSrc(s, mov->getDef(0));
+   cst->bb->insertBefore(cst, mov);
+}
+
 // Insert extra moves so that, if multiple register constraints on a value are
 // in conflict, these conflicts can be resolved.
 bool
@@ -2328,46 +2376,10 @@ RegAlloc::InsertConstraintsPass::insertConstraintMoves()
cst->bb->insertBefore(cst, mov);
continue;
 }
-assert(cst->getSrc(s)->defs.size() == 1); // still SSA
-
-Instruction *defi = cst->getSrc(s)->defs.front()->getInsn();
-bool imm = defi->op == OP_MOV &&
-   defi->src(0).getFile() == FILE_IMMEDIATE;
-bool load = defi->op == OP_LOAD &&
-   defi->src(0).getFile() == FILE_MEMORY_CONST &&
-   !defi->src(0).isIndirect(0);
-// catch some cases where don't really need MOVs
-if (cst->getSrc(s)->refCount() == 1 && !defi->constrainedDefs()) {
-   if (imm || load) {
-  // Move the defi right before the cst. No point in expanding
-  // the range.
-  defi->bb->remove(defi);
-  cst->bb->insertBefore(cst, defi);
-   }
-   continue;
-}
 
-LValue *lval = new_LValue(func, cst->src(s).getFile());
-lval->reg.size = size;
-
-mov = new_Instruction(func, OP_MOV, typeOfSize(size));
-mov->setDef(0, lval);
-mov->setSrc(0, cst->getSrc(s));
-
-if (load) {
-   mov->op = OP_LOAD;
-   mov->setSrc(0, defi->getSrc(0));
-} else if (imm) {
-   mov->setSrc(0, defi->getSrc(0));
-}
-
-cst->setSrc(s, mov->getDef(0));
-cst->bb->insertBefore(cst, mov);
+insertConstraintMove(cst, s);
 
 cst->getDef(0)->asLValue()->noSpill = 1; // doesn't help
-
-if (cst->op == OP_UNION)
-   mov->setPredicate(defi->cc, 

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

2018-04-09 Thread Jason Ekstrand
On Mon, Apr 9, 2018 at 5:21 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:

> Hi,
>
> > >> Question: nir_deref_instr_get_variable will walk the deref instr
> > >> chain, but does it even make sense if there's a array or struct in
> > >> this deref chain? Should this be asserted?
> > >>
> > >
> > > That's an interesting question.  Certainly, at this point in the patch
> > > series, we can't make that assumption.  This is because we haven't
> checked
> > > the mode yet.  However, once we can assume deref instructions, we can
> check
> > > the mode and then go on to find the var.  Maybe something like this
> > > (untested):
> > >
> > > https://gitlab.freedesktop.org/jekstrand/mesa/commit/
> > > 33aee39955eff842d6ea263da2f36e60287e62ee
> > >
> >
> > It turns out that there is one system value which is an array:
> > gl_SampleMask.  However, due to details, we only ever load element 0 so
> we
> > can ignore the array deref in that case.  Unfortunately, this means that
> we
> > can't do any better than what we have here. :-(
>
> I think we could still be strict while handling that case, by being
> explicit about it in the middle of the patch you shared:
>
> nir_deref *deref = nir_src_as_deref(load_deref->src[0]);
> if (deref->mode != nir_var_system_value) {
>continue;
> }
>
> if (deref->deref_type != nir_deref_type_var) {
>assert(deref->deref_type == nir_deref_type_array);
>assert(nir_instr_get_variable(deref)->data.location ==
> SYSTEM_VALUE_SAMPLE_MASK);
>/* Short explanation that we only load ever position zero, maybe
> even assert... */
>deref = nir_deref_instr_parent(deref);
> }
>
> assert(deref->deref_type == nir_deref_type_var);
> nir_variable *var = deref->var;
>
> Would something like that work?
>

I took another swing at it, and this one seems to make Jenkins happy:

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


Re: [Mesa-dev] [PATCH v3 000/104] nir: Move to using instructions for derefs

2018-04-09 Thread Jason Ekstrand
On Mon, Apr 9, 2018 at 6:20 PM, Jason Ekstrand  wrote:

> On Mon, Apr 9, 2018 at 4:58 PM, Caio Marcelo de Oliveira Filho <
> caio.olive...@intel.com> wrote:
>
>> Hi,
>>
>> Given the fixes you already made based on my comments. Patches 1-20,
>> 22-27, 29-43, and 61 (multiview!) are
>>
>> Reviewed-by: Caio Marcelo de Oliveira Filho 
>>
>> Patches 46-47 and 49 seem to be valid regardless the rest of the code,
>> so I'd consider getting them in independently. They are also R-b'ed.
>>
>
Good call.  I'll go ahead and land those once my Jenkins run completes.

--Jason


> Thanks!
>
>
>> I've skipped 21 and 28 because I wanted to give a deeper look at the
>> originals.
>>
>> From the perspective of someone that is living with deref_vars for
>> just a short time, I like the idea of removing one special
>> construction (derefs) and rely on instructions instead.
>>
>> Which made me wonder: was there a special factor that led NIR to start
>> with the "old-school derefs" in the first place? Other day Curro asked
>> about one of the "selling points" of NIR being it did not have all
>> those nodes representing dereferences. I digged up an old comment to
>> what I think he was referring to
>>
>> https://lists.freedesktop.org/archives/mesa-dev/2014-Februar
>> y/053477.html
>>
>> - All the ir_dereference chains blow up the memory usage, and the
>> constant pointer chasing in the recursive algorithms needed to handle
>> them is not just cache-unfriendly but "cache-mean."
>>
>> How does deref_instructions avoid being "cache-mean" as their
>> "predecessors"? Was the blow up more a result of how the instructions
>> were structured than the fact it had those dereferences nodes?
>>
>
> The blow up was mostly due to the fact that GLSL IR uses dereferences for
> *everything*.  NIR, in contrast, uses SSA defs for 95% of all temporary
> values so there simply aren't as many deref chains in play.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 057/104] nir,spirv: Rework function calls

2018-04-09 Thread Jason Ekstrand
+ A bunch of potentially interested parties.

On Mon, Apr 9, 2018 at 4:25 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:

> Hi,
>
> >  typedef struct {
> > -   nir_parameter_type param_type;
> > -   const struct glsl_type *type;
> > +   uint8_t num_components;
> > +   uint8_t bit_size;
> >  } nir_parameter;
>
> (...)
>
> > @@ -683,18 +692,12 @@ validate_tex_instr(nir_tex_instr *instr,
> validate_state *state)
> >  static void
> >  validate_call_instr(nir_call_instr *instr, validate_state *state)
> >  {
> > -   if (instr->return_deref == NULL) {
> > -  validate_assert(state, glsl_type_is_void(instr->
> callee->return_type));
> > -   } else {
> > -  validate_assert(state, instr->return_deref->deref.type ==
> instr->callee->return_type);
> > -  validate_deref_var(instr, instr->return_deref, state);
> > -   }
> > -
> > validate_assert(state, instr->num_params ==
> instr->callee->num_params);
> >
> > for (unsigned i = 0; i < instr->num_params; i++) {
> > -  validate_assert(state, instr->callee->params[i].type ==
> instr->params[i]->deref.type);
> > -  validate_deref_var(instr, instr->params[i], state);
> > +  validate_src(>params[i], state,
> > +   instr->callee->params[i].bit_size,
> > +   instr->callee->params[i].num_components);
> > }
> >  }
>
> Question: I might be misreading, but it seems like we are losing the
> type information for functions. Isn't that something worth keeping,
> maybe in some other way, e.g. load_param specifying the expected type?
>

That's a very good question!  To be honest, I'm not sure what the answer
is.  At the moment, the type information is fairly useless for most of what
we use functions for.  Really, all we need is something that NIR can
inline.  As it is, we're not really preserving the types from SPIR-V
because of the gymnastics we're doing to handle pointers.

If we did want to preserve types, we'd need to have more detailed type
information.  In particular, we'd need to be able to provide pointer types
and maybe combined image-sampler types.  And along with those pointer
types, we'd need to somehow express those pointer's storage requirements.

The philosophy behind this commit is that, if we don't have a good match to
SPIR-V anyway, we might as well just chuck that information and do whatever
makes our lives the easiest.  My philosophy here may be flawed and I'm
happy to hear arguments in favor of keeping the information.  The best
argument I can come up with for keeping the information is if we find
ourselves wanting to do some sort of linking in the future where we have to
match functions by both name and type.  If we want to do that, however,
we'll need all the SPIR-V type information.

Thoughts?

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


Re: [Mesa-dev] [PATCH] nv50/ir: make a copy of tex src if it's referenced multiple times

2018-04-09 Thread Ilia Mirkin
On Mon, Apr 9, 2018 at 10:23 PM, Ilia Mirkin  wrote:
> For nv50 we coalesce the srcs and defs into a single node (some ops
> can't take a separate src and dst, while others can only handle one reg
> in the short encoding mode).
>
> [Side-note: the ops for which there is an encoding that can take a src
> should instead use the RA's register preference facility.]

For posterity, turns out that I was mistaken. All the tex ops
apparently can only take a single register, even when it's a wide
encoding (LTDST vs LTSRC in envydis, but both reference the same
bitfield). I'm going to reword the description accordingly.

>
> Signed-off-by: Ilia Mirkin 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> index 3a0e56e1385..f5ce1b4a0b0 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> @@ -2216,6 +2216,16 @@ 
> RegAlloc::InsertConstraintsPass::texConstraintNV50(TexInstruction *tex)
> for (c = 0; tex->srcExists(c) || tex->defExists(c); ++c) {
>if (!tex->srcExists(c))
>   tex->setSrc(c, new_LValue(func, tex->getSrc(0)->asLValue()));
> +  else if (tex->getSrc(c)->refCount() > 1) {
> + // Disconnect source from the single definition since it's about to
> + // get merged with the defs (due to JOIN_MASK_TEX).
> + LValue *lval = new_LValue(func, FILE_GPR);
> + Instruction *mov = new_Instruction(func, OP_MOV, TYPE_U32);
> + mov->setSrc(0, tex->getSrc(c));
> + mov->setDef(0, lval);
> + tex->bb->insertBefore(tex, mov);
> + tex->setSrc(c, lval);
> +  }
>if (!tex->defExists(c))
>   tex->setDef(c, new_LValue(func, tex->getDef(0)->asLValue()));
> }
> --
> 2.16.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] nv50/ir: make a copy of tex src if it's referenced multiple times

2018-04-09 Thread Ilia Mirkin
For nv50 we coalesce the srcs and defs into a single node (some ops
can't take a separate src and dst, while others can only handle one reg
in the short encoding mode).

[Side-note: the ops for which there is an encoding that can take a src
should instead use the RA's register preference facility.]

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 3a0e56e1385..f5ce1b4a0b0 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -2216,6 +2216,16 @@ 
RegAlloc::InsertConstraintsPass::texConstraintNV50(TexInstruction *tex)
for (c = 0; tex->srcExists(c) || tex->defExists(c); ++c) {
   if (!tex->srcExists(c))
  tex->setSrc(c, new_LValue(func, tex->getSrc(0)->asLValue()));
+  else if (tex->getSrc(c)->refCount() > 1) {
+ // Disconnect source from the single definition since it's about to
+ // get merged with the defs (due to JOIN_MASK_TEX).
+ LValue *lval = new_LValue(func, FILE_GPR);
+ Instruction *mov = new_Instruction(func, OP_MOV, TYPE_U32);
+ mov->setSrc(0, tex->getSrc(c));
+ mov->setDef(0, lval);
+ tex->bb->insertBefore(tex, mov);
+ tex->setSrc(c, lval);
+  }
   if (!tex->defExists(c))
  tex->setDef(c, new_LValue(func, tex->getDef(0)->asLValue()));
}
-- 
2.16.1

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


Re: [Mesa-dev] [PATCH v3 002/104] nir: Add a deref instruction type

2018-04-09 Thread Jason Ekstrand
On Mon, Apr 9, 2018 at 4:41 PM, Bas Nieuwenhuizen 
wrote:

> On Tue, Apr 10, 2018 at 12:37 AM, Rob Clark  wrote:
> > On Mon, Apr 9, 2018 at 1:35 AM, Jason Ekstrand 
> wrote:
> >> Rather lively discussion we've got going here...
> >>
> >> On Sun, Apr 8, 2018 at 3:23 PM, Rob Clark  wrote:
> >>>
> >>> On Sun, Apr 8, 2018 at 5:54 PM, Bas Nieuwenhuizen
> >>>  wrote:
> >>> > On Sun, Apr 8, 2018 at 11:40 PM, Rob Clark 
> wrote:
> >>> >> On Sun, Apr 8, 2018 at 5:20 PM, Bas Nieuwenhuizen
> >>> >>  wrote:
> >>> >>>
> >>> >>> You mean insert it into the fatptr every time deref_cast is called?
> >>> >>>
> >>> >>> Wouldn't that blow up the IR size significantly for very little
> >>> >>> benefit?
> >>> >>
> >>> >> in an easy to clean up way, so meh?
> >>> >
> >>> > We can't clean it up if we want to keep the information. Also nir is
> >>> > pretty slow to compile already, so I'd like not to add a significant
> >>> > number of instruction for very little benefit.
> >>
> >>
> >> Really?  I mean, I can believe it, but do you have any actual numbers to
> >> back this up?  It's considerably faster than some other IRs we have in
> mesa
> >> though they are known to be pretty big pigs if we're honest.  I'm very
> open
> >> to any suggestions on how to improve compile times.  If NIR is
> fundamentally
> >> a pig, we should fix that.
> >>
> >
> > just a side-note, I guess mostly obvious but just pointing it out
> > because it has caught others by surprise.  Debug mesa builds by
> > default run nir_validate after every pass (unless you NIR_VALIDATE=0).
> > And this adds a *lot* of overhead (for a *lot* of debugging benefit)..
> >
> > But if nir seems slow when running shader-db/etc, if you are using a
> > debug build at least make sure to NIR_VALIDATE=0 (or better yet use a
> > release build) when measuring performance
>
> Yeah I was aware of that. Given this discussions I've actually run
> some numbers for radv with a cold shader cache:
>
> time total: 76.507337 sec
> spirv 1.625971 sec
> nir_to_llvm 10.146195 sec
> llvm 46.058714 sec
>

Ok, that's more-or-less what I would have expected.  I'm a bit surprised
that spirv_to_nir is so expensive but there's some crazy juggling we have
to do in there.  We could probably improve it.


> hence total - spirv - nir_to_llvm - llvm = ~18.7 sec which is mostly due
> to nir.
>

Which is only 40% of the time you spend in LLVM. :-)  If you're letting NIR
optimize, I expect it to take some real time but it doesn't look too bad.

I'm a bit surprised how long nir_to_llvm takes though...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 000/104] nir: Move to using instructions for derefs

2018-04-09 Thread Jason Ekstrand
On Mon, Apr 9, 2018 at 4:58 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:

> Hi,
>
> Given the fixes you already made based on my comments. Patches 1-20,
> 22-27, 29-43, and 61 (multiview!) are
>
> Reviewed-by: Caio Marcelo de Oliveira Filho 
>
> Patches 46-47 and 49 seem to be valid regardless the rest of the code,
> so I'd consider getting them in independently. They are also R-b'ed.
>

Thanks!


> I've skipped 21 and 28 because I wanted to give a deeper look at the
> originals.
>
> From the perspective of someone that is living with deref_vars for
> just a short time, I like the idea of removing one special
> construction (derefs) and rely on instructions instead.
>
> Which made me wonder: was there a special factor that led NIR to start
> with the "old-school derefs" in the first place? Other day Curro asked
> about one of the "selling points" of NIR being it did not have all
> those nodes representing dereferences. I digged up an old comment to
> what I think he was referring to
>
> https://lists.freedesktop.org/archives/mesa-dev/2014-
> February/053477.html
>
> - All the ir_dereference chains blow up the memory usage, and the
> constant pointer chasing in the recursive algorithms needed to handle
> them is not just cache-unfriendly but "cache-mean."
>
> How does deref_instructions avoid being "cache-mean" as their
> "predecessors"? Was the blow up more a result of how the instructions
> were structured than the fact it had those dereferences nodes?
>

The blow up was mostly due to the fact that GLSL IR uses dereferences for
*everything*.  NIR, in contrast, uses SSA defs for 95% of all temporary
values so there simply aren't as many deref chains in play.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH mesa 07/21] vulkan: Add EXT_acquire_xlib_display [v2]

2018-04-09 Thread Jason Ekstrand
As with patch 1, I've gone through and made a pile of style changes to
bring things back under 80 characters.  You can find it on this branch:

https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/drm-lease-v3-whitespace

I also fixed a couple of the comments below.

On Wed, Mar 7, 2018 at 11:25 PM, Keith Packard  wrote:

> This extension adds the ability to borrow an X RandR output for
> temporary use directly by a Vulkan application. For DRM, we use the
> Linux resource leasing mechanism.
>
> v2:
> Clean up xlib_lease detection
>
> * Use separate temporary '_xlib_lease' variable to hold the
>   option value to avoid changin the type of a variable.
>
> * Use boolean expressions instead of additional if statements
>   to compute resulting with_xlib_lease value.
>
> * Simplify addition of VK_USE_PLATFORM_XLIB_XRANDR_KHR to
>   vulkan_wsi_args
>
>   Suggested-by: Eric Engestrom 
>
> Move mode list from wsi_display to wsi_display_connector
>
> Fix scope for wsi_display_mode and wsi_display_connector allocs
>
>   Suggested-by: Jason Ekstrand 
>
> Signed-off-by: Keith Packard 
> ---
>  configure.ac|  32 +++
>  meson.build |  11 +
>  meson_options.txt   |   7 +
>  src/vulkan/Makefile.am  |   5 +
>  src/vulkan/wsi/meson.build  |   5 +
>  src/vulkan/wsi/wsi_common_display.c | 470 ++
> ++
>  src/vulkan/wsi/wsi_common_display.h |  17 ++
>  7 files changed, 547 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 7fcb3220eaa..bf649f9fed7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1560,6 +1560,7 @@ AM_CONDITIONAL(HAVE_APPLEDRI, test "x$enable_dri" =
> xyes -a "x$dri_platform" = x
>  AM_CONDITIONAL(HAVE_LMSENSORS, test "x$enable_lmsensors" = xyes )
>  AM_CONDITIONAL(HAVE_GALLIUM_EXTRA_HUD, test "x$enable_gallium_extra_hud"
> = xyes )
>  AM_CONDITIONAL(HAVE_WINDOWSDRI, test "x$enable_dri" = xyes -a
> "x$dri_platform" = xwindows )
> +AM_CONDITIONAL(HAVE_XLEASE, test "x$have_xlease" = xyes )
>
>  AC_ARG_ENABLE([shared-glapi],
>  [AS_HELP_STRING([--enable-shared-glapi],
> @@ -1853,6 +1854,18 @@ if test x"$enable_dri3" = xyes; then
>  PKG_CHECK_MODULES([XCB_DRI3], [$dri3_modules])
>  fi
>
> +
> +if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q
> 'drm'; then
> +have_xlease=yes
> +else
> +have_xlease=no
> +fi
> +
> +if test x"$have_xlease" = xyes; then
> +randr_modules="x11-xcb xcb-randr"
> +PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
> +fi
> +
>  AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
>  AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q
> 'wayland')
>  AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
> @@ -1860,6 +1873,25 @@ AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo
> "$platforms" | grep -q 'drm')
>  AM_CONDITIONAL(HAVE_PLATFORM_SURFACELESS, echo "$platforms" | grep -q
> 'surfaceless')
>  AM_CONDITIONAL(HAVE_PLATFORM_ANDROID, echo "$platforms" | grep -q
> 'android')
>
> +AC_ARG_ENABLE(xlib-lease,
> +[AS_HELP_STRING([--enable-xlib-lease]
> +[enable VK_acquire_xlib_display using X leases])],
> +[enable_xlib_lease=$enableval], [enable_xlib_lease=auto])
> +case "x$enable_xlib_lease" in
> +xyes)
> +;;
> +xno)
> +;;
> +*)
> +if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q
> 'drm'; then
> +enable_xlib_lease=yes
> +else
> +enable_xlib_lease=no
> +fi
> +esac
> +
> +AM_CONDITIONAL(HAVE_XLIB_LEASE, test "x$enable_xlib_lease" = xyes)
> +
>  dnl
>  dnl More DRI setup
>  dnl
> diff --git a/meson.build b/meson.build
> index 788aed6e159..68081e9fcc3 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -265,6 +265,13 @@ if _platforms != ''
>egl_native_platform = _split[0]
>  endif
>
> +_xlib_lease = get_option('xlib-lease')
> +if _xlib_lease == 'auto'
> +  with_xlib_lease = with_platform_x11 and with_platform_display
> +else
> +  with_xlib_lease = _xlib_lease == 'true'
> +endif
> +
>  with_glx = get_option('glx')
>  if with_glx == 'auto'
>if with_dri
> @@ -1202,6 +1209,7 @@ dep_xcb_present = []
>  dep_xcb_sync = []
>  dep_xcb_xfixes = []
>  dep_xshmfence = []
> +dep_xcb_xrandr = []
>  if with_platform_x11
>if with_glx == 'xlib' or with_glx == 'gallium-xlib'
>  dep_x11 = dependency('x11')
> @@ -1241,6 +1249,9 @@ if with_platform_x11
>if with_egl
>  dep_xcb_xfixes = dependency('xcb-xfixes')
>endif
> +  if with_xlib_lease
> +dep_xcb_xrandr = dependency('xcb-randr', version : '>= 1.12')
> +  endif
>  endif
>
>  if get_option('gallium-extra-hud')
> diff --git a/meson_options.txt b/meson_options.txt
> index a573290b774..70318e1041f 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -286,3 

Re: [Mesa-dev] [PATCH] RFC gallium: add 64 bit integer formats

2018-04-09 Thread Karol Herbst
On Tue, Apr 10, 2018 at 2:43 AM, Ilia Mirkin  wrote:
> On Mon, Apr 9, 2018 at 8:39 PM, Karol Herbst  wrote:
>> unsigneds are needed by ARB_bindless_texture 64 bit vertex attribs, both for
>> NV_vertex_attrib_integer64.
>>
>> Fixes the new piglit sampler-vertex-attrib-input-output test I sent some days
>> ago for bindless_texture.
>>
>> The change inside vbo_attrtype_to_double_flag is what I am most concerned
>> about. Maybe I should add another flag for 64 bit ints. Or rework what 
>> Doubles
>> mean in gl_array_attributes. Or Rename that to is64Bit and rework all users 
>> of
>> Doubles.
>>
>> Any suggestions?
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/gallium/drivers/svga/svga_format.c |  8 
>>  src/gallium/include/pipe/p_format.h|  9 +
>>  src/mesa/main/glformats.c  |  3 +++
>>  src/mesa/state_tracker/st_atom_array.c | 30 +++---
>>  src/mesa/vbo/vbo_private.h |  2 +-
>>  5 files changed, 48 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/gallium/drivers/svga/svga_format.c 
>> b/src/gallium/drivers/svga/svga_format.c
>> index 20a6e6b159f..f01a0e79c72 100644
>> --- a/src/gallium/drivers/svga/svga_format.c
>> +++ b/src/gallium/drivers/svga/svga_format.c
>> @@ -369,6 +369,14 @@ static const struct vgpu10_format_entry 
>> format_conversion_table[] =
>> { PIPE_FORMAT_A1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>> { PIPE_FORMAT_X1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>> { PIPE_FORMAT_A4B4G4R4_UNORM,SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>> +   { PIPE_FORMAT_R64_UINT,  SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>> +   { PIPE_FORMAT_R64G64_UINT,   SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>> +   { PIPE_FORMAT_R64G64B64_UINT,SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>> +   { PIPE_FORMAT_R64G64B64A64_UINT, SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>> +   { PIPE_FORMAT_R64_SINT,  SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>> +   { PIPE_FORMAT_R64G64_SINT,   SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>> +   { PIPE_FORMAT_R64G64B64_SINT,SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>> +   { PIPE_FORMAT_R64G64B64A64_SINT, SVGA3D_FORMAT_INVALID,  
>> SVGA3D_FORMAT_INVALID,   0 },
>>  };
>>
>>
>> diff --git a/src/gallium/include/pipe/p_format.h 
>> b/src/gallium/include/pipe/p_format.h
>> index 57399800fa4..df698856b70 100644
>> --- a/src/gallium/include/pipe/p_format.h
>> +++ b/src/gallium/include/pipe/p_format.h
>> @@ -396,6 +396,15 @@ enum pipe_format {
>> PIPE_FORMAT_X1B5G5R5_UNORM  = 310,
>> PIPE_FORMAT_A4B4G4R4_UNORM  = 311,
>>
>> +   PIPE_FORMAT_R64_UINT= 312,
>> +   PIPE_FORMAT_R64G64_UINT = 313,
>> +   PIPE_FORMAT_R64G64B64_UINT  = 314,
>> +   PIPE_FORMAT_R64G64B64A64_UINT   = 315,
>> +   PIPE_FORMAT_R64_SINT= 316,
>> +   PIPE_FORMAT_R64G64_SINT = 317,
>> +   PIPE_FORMAT_R64G64B64_SINT  = 318,
>> +   PIPE_FORMAT_R64G64B64A64_SINT   = 319,
>> +
>> PIPE_FORMAT_COUNT
>>  };
>>
>> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
>> index 1e797c24c2a..feafd97f5ee 100644
>> --- a/src/mesa/main/glformats.c
>> +++ b/src/mesa/main/glformats.c
>> @@ -543,6 +543,9 @@ _mesa_bytes_per_vertex_attrib(GLint comps, GLenum type)
>> case GL_INT:
>> case GL_UNSIGNED_INT:
>>return comps * sizeof(GLint);
>> +   /* ARB_bindless_texture */
>> +   case GL_UNSIGNED_INT64_ARB:
>> +  return comps * sizeof(GLuint64EXT);
>> case GL_FLOAT:
>>return comps * sizeof(GLfloat);
>> case GL_HALF_FLOAT_ARB:
>> diff --git a/src/mesa/state_tracker/st_atom_array.c 
>> b/src/mesa/state_tracker/st_atom_array.c
>> index 2fd67e8d840..1c3f677d4bf 100644
>> --- a/src/mesa/state_tracker/st_atom_array.c
>> +++ b/src/mesa/state_tracker/st_atom_array.c
>> @@ -230,6 +230,27 @@ static const uint16_t vertex_formats[][4][4] = {
>>   PIPE_FORMAT_R32G32B32A32_FIXED
>>},
>> },
>> +   {{0}}, /* gap */
>> +   { /* GL_INT64_ARB */
>> +  {0},
>> +  {0},
>> +  {
>> + PIPE_FORMAT_R64_SINT,
>> + PIPE_FORMAT_R64G64_SINT,
>> + PIPE_FORMAT_R64G64B64_SINT,
>> + PIPE_FORMAT_R64G64B64A64_SINT
>> +  },
>> +   },
>> +   { /* GL_UNSIGNED_INT64_ARB */
>> +  {0},
>> +  {0},
>> +  {
>> + PIPE_FORMAT_R64_UINT,
>> + PIPE_FORMAT_R64G64_UINT,
>> + PIPE_FORMAT_R64G64B64_UINT,
>> + PIPE_FORMAT_R64G64B64A64_UINT
>> +  },
>> +   },
>
> Since these are never actually passed in via a single vertex attrib,
> is there 

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

2018-04-09 Thread Timothy Arceri



On 10/04/18 06:29, Marek Olšák wrote:

Do you need break statements?


Whoops the first one does. I'll add a /* fall through */ comment to the 
second one. Thanks.




Marek

On Thu, Apr 5, 2018 at 1:34 AM, Timothy Arceri > wrote:


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

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

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





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


Re: [Mesa-dev] [PATCH mesa] u_endian: use non-underscore-prefixed BYTE_ORDER names

2018-04-09 Thread Matt Turner
On Mon, Apr 9, 2018 at 1:35 AM, Jonathan Gray  wrote:
> What happened with this patch?  It seems the problem it is fixing got
> cherry-picked into 17.3 but the fix for master (and now 17.3) is still
> not merged?

I think Eric's on holiday now, so I wouldn't expect a speedy response
-- but without any context I would guess nothing happened with the
patch since no one replied to it in the last 12 days. He cc'd you,
which is usually an invitation for review :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] RFC gallium: add 64 bit integer formats

2018-04-09 Thread Ilia Mirkin
On Mon, Apr 9, 2018 at 8:39 PM, Karol Herbst  wrote:
> unsigneds are needed by ARB_bindless_texture 64 bit vertex attribs, both for
> NV_vertex_attrib_integer64.
>
> Fixes the new piglit sampler-vertex-attrib-input-output test I sent some days
> ago for bindless_texture.
>
> The change inside vbo_attrtype_to_double_flag is what I am most concerned
> about. Maybe I should add another flag for 64 bit ints. Or rework what Doubles
> mean in gl_array_attributes. Or Rename that to is64Bit and rework all users of
> Doubles.
>
> Any suggestions?
>
> Signed-off-by: Karol Herbst 
> ---
>  src/gallium/drivers/svga/svga_format.c |  8 
>  src/gallium/include/pipe/p_format.h|  9 +
>  src/mesa/main/glformats.c  |  3 +++
>  src/mesa/state_tracker/st_atom_array.c | 30 +++---
>  src/mesa/vbo/vbo_private.h |  2 +-
>  5 files changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/svga/svga_format.c 
> b/src/gallium/drivers/svga/svga_format.c
> index 20a6e6b159f..f01a0e79c72 100644
> --- a/src/gallium/drivers/svga/svga_format.c
> +++ b/src/gallium/drivers/svga/svga_format.c
> @@ -369,6 +369,14 @@ static const struct vgpu10_format_entry 
> format_conversion_table[] =
> { PIPE_FORMAT_A1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
> { PIPE_FORMAT_X1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
> { PIPE_FORMAT_A4B4G4R4_UNORM,SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
> +   { PIPE_FORMAT_R64_UINT,  SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
> +   { PIPE_FORMAT_R64G64_UINT,   SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
> +   { PIPE_FORMAT_R64G64B64_UINT,SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
> +   { PIPE_FORMAT_R64G64B64A64_UINT, SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
> +   { PIPE_FORMAT_R64_SINT,  SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
> +   { PIPE_FORMAT_R64G64_SINT,   SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
> +   { PIPE_FORMAT_R64G64B64_SINT,SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
> +   { PIPE_FORMAT_R64G64B64A64_SINT, SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   0 },
>  };
>
>
> diff --git a/src/gallium/include/pipe/p_format.h 
> b/src/gallium/include/pipe/p_format.h
> index 57399800fa4..df698856b70 100644
> --- a/src/gallium/include/pipe/p_format.h
> +++ b/src/gallium/include/pipe/p_format.h
> @@ -396,6 +396,15 @@ enum pipe_format {
> PIPE_FORMAT_X1B5G5R5_UNORM  = 310,
> PIPE_FORMAT_A4B4G4R4_UNORM  = 311,
>
> +   PIPE_FORMAT_R64_UINT= 312,
> +   PIPE_FORMAT_R64G64_UINT = 313,
> +   PIPE_FORMAT_R64G64B64_UINT  = 314,
> +   PIPE_FORMAT_R64G64B64A64_UINT   = 315,
> +   PIPE_FORMAT_R64_SINT= 316,
> +   PIPE_FORMAT_R64G64_SINT = 317,
> +   PIPE_FORMAT_R64G64B64_SINT  = 318,
> +   PIPE_FORMAT_R64G64B64A64_SINT   = 319,
> +
> PIPE_FORMAT_COUNT
>  };
>
> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> index 1e797c24c2a..feafd97f5ee 100644
> --- a/src/mesa/main/glformats.c
> +++ b/src/mesa/main/glformats.c
> @@ -543,6 +543,9 @@ _mesa_bytes_per_vertex_attrib(GLint comps, GLenum type)
> case GL_INT:
> case GL_UNSIGNED_INT:
>return comps * sizeof(GLint);
> +   /* ARB_bindless_texture */
> +   case GL_UNSIGNED_INT64_ARB:
> +  return comps * sizeof(GLuint64EXT);
> case GL_FLOAT:
>return comps * sizeof(GLfloat);
> case GL_HALF_FLOAT_ARB:
> diff --git a/src/mesa/state_tracker/st_atom_array.c 
> b/src/mesa/state_tracker/st_atom_array.c
> index 2fd67e8d840..1c3f677d4bf 100644
> --- a/src/mesa/state_tracker/st_atom_array.c
> +++ b/src/mesa/state_tracker/st_atom_array.c
> @@ -230,6 +230,27 @@ static const uint16_t vertex_formats[][4][4] = {
>   PIPE_FORMAT_R32G32B32A32_FIXED
>},
> },
> +   {{0}}, /* gap */
> +   { /* GL_INT64_ARB */
> +  {0},
> +  {0},
> +  {
> + PIPE_FORMAT_R64_SINT,
> + PIPE_FORMAT_R64G64_SINT,
> + PIPE_FORMAT_R64G64B64_SINT,
> + PIPE_FORMAT_R64G64B64A64_SINT
> +  },
> +   },
> +   { /* GL_UNSIGNED_INT64_ARB */
> +  {0},
> +  {0},
> +  {
> + PIPE_FORMAT_R64_UINT,
> + PIPE_FORMAT_R64G64_UINT,
> + PIPE_FORMAT_R64G64B64_UINT,
> + PIPE_FORMAT_R64G64B64A64_UINT
> +  },
> +   },

Since these are never actually passed in via a single vertex attrib,
is there any way to not add these at all, and just handle the
conversion from 64-bit to 2x 32-bit entirely internally to st/mesa?
(Note that R64_FLOAT *can* be actually passed to a driver, and it is
*not* the 

[Mesa-dev] [PATCH] RFC gallium: add 64 bit integer formats

2018-04-09 Thread Karol Herbst
unsigneds are needed by ARB_bindless_texture 64 bit vertex attribs, both for
NV_vertex_attrib_integer64.

Fixes the new piglit sampler-vertex-attrib-input-output test I sent some days
ago for bindless_texture.

The change inside vbo_attrtype_to_double_flag is what I am most concerned
about. Maybe I should add another flag for 64 bit ints. Or rework what Doubles
mean in gl_array_attributes. Or Rename that to is64Bit and rework all users of
Doubles.

Any suggestions?

Signed-off-by: Karol Herbst 
---
 src/gallium/drivers/svga/svga_format.c |  8 
 src/gallium/include/pipe/p_format.h|  9 +
 src/mesa/main/glformats.c  |  3 +++
 src/mesa/state_tracker/st_atom_array.c | 30 +++---
 src/mesa/vbo/vbo_private.h |  2 +-
 5 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_format.c 
b/src/gallium/drivers/svga/svga_format.c
index 20a6e6b159f..f01a0e79c72 100644
--- a/src/gallium/drivers/svga/svga_format.c
+++ b/src/gallium/drivers/svga/svga_format.c
@@ -369,6 +369,14 @@ static const struct vgpu10_format_entry 
format_conversion_table[] =
{ PIPE_FORMAT_A1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
{ PIPE_FORMAT_X1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
{ PIPE_FORMAT_A4B4G4R4_UNORM,SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
+   { PIPE_FORMAT_R64_UINT,  SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
+   { PIPE_FORMAT_R64G64_UINT,   SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
+   { PIPE_FORMAT_R64G64B64_UINT,SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
+   { PIPE_FORMAT_R64G64B64A64_UINT, SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
+   { PIPE_FORMAT_R64_SINT,  SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
+   { PIPE_FORMAT_R64G64_SINT,   SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
+   { PIPE_FORMAT_R64G64B64_SINT,SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
+   { PIPE_FORMAT_R64G64B64A64_SINT, SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   0 },
 };
 
 
diff --git a/src/gallium/include/pipe/p_format.h 
b/src/gallium/include/pipe/p_format.h
index 57399800fa4..df698856b70 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -396,6 +396,15 @@ enum pipe_format {
PIPE_FORMAT_X1B5G5R5_UNORM  = 310,
PIPE_FORMAT_A4B4G4R4_UNORM  = 311,
 
+   PIPE_FORMAT_R64_UINT= 312,
+   PIPE_FORMAT_R64G64_UINT = 313,
+   PIPE_FORMAT_R64G64B64_UINT  = 314,
+   PIPE_FORMAT_R64G64B64A64_UINT   = 315,
+   PIPE_FORMAT_R64_SINT= 316,
+   PIPE_FORMAT_R64G64_SINT = 317,
+   PIPE_FORMAT_R64G64B64_SINT  = 318,
+   PIPE_FORMAT_R64G64B64A64_SINT   = 319,
+
PIPE_FORMAT_COUNT
 };
 
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 1e797c24c2a..feafd97f5ee 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -543,6 +543,9 @@ _mesa_bytes_per_vertex_attrib(GLint comps, GLenum type)
case GL_INT:
case GL_UNSIGNED_INT:
   return comps * sizeof(GLint);
+   /* ARB_bindless_texture */
+   case GL_UNSIGNED_INT64_ARB:
+  return comps * sizeof(GLuint64EXT);
case GL_FLOAT:
   return comps * sizeof(GLfloat);
case GL_HALF_FLOAT_ARB:
diff --git a/src/mesa/state_tracker/st_atom_array.c 
b/src/mesa/state_tracker/st_atom_array.c
index 2fd67e8d840..1c3f677d4bf 100644
--- a/src/mesa/state_tracker/st_atom_array.c
+++ b/src/mesa/state_tracker/st_atom_array.c
@@ -230,6 +230,27 @@ static const uint16_t vertex_formats[][4][4] = {
  PIPE_FORMAT_R32G32B32A32_FIXED
   },
},
+   {{0}}, /* gap */
+   { /* GL_INT64_ARB */
+  {0},
+  {0},
+  {
+ PIPE_FORMAT_R64_SINT,
+ PIPE_FORMAT_R64G64_SINT,
+ PIPE_FORMAT_R64G64B64_SINT,
+ PIPE_FORMAT_R64G64B64A64_SINT
+  },
+   },
+   { /* GL_UNSIGNED_INT64_ARB */
+  {0},
+  {0},
+  {
+ PIPE_FORMAT_R64_UINT,
+ PIPE_FORMAT_R64G64_UINT,
+ PIPE_FORMAT_R64G64B64_UINT,
+ PIPE_FORMAT_R64G64B64A64_UINT
+  },
+   },
 };
 
 
@@ -244,7 +265,7 @@ st_pipe_vertex_format(const struct gl_array_attributes 
*attrib)
const bool normalized = attrib->Normalized;
const bool integer = attrib->Integer;
GLenum16 type = attrib->Type;
-   unsigned index;
+   unsigned index = integer*2 + normalized;
 
assert(size >= 1 && size <= 4);
assert(format == GL_RGBA || format == GL_BGRA);
@@ -298,11 +319,14 @@ st_pipe_vertex_format(const struct gl_array_attributes 
*attrib)
  return PIPE_FORMAT_B8G8R8A8_UNORM;
   }
   break;
+   case GL_UNSIGNED_INT64_ARB:
+   case GL_INT64_ARB:
+ 

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

2018-04-09 Thread Caio Marcelo de Oliveira Filho
Hi,

> >> Question: nir_deref_instr_get_variable will walk the deref instr
> >> chain, but does it even make sense if there's a array or struct in
> >> this deref chain? Should this be asserted?
> >>
> >
> > That's an interesting question.  Certainly, at this point in the patch
> > series, we can't make that assumption.  This is because we haven't checked
> > the mode yet.  However, once we can assume deref instructions, we can check
> > the mode and then go on to find the var.  Maybe something like this
> > (untested):
> >
> > https://gitlab.freedesktop.org/jekstrand/mesa/commit/
> > 33aee39955eff842d6ea263da2f36e60287e62ee
> >
> 
> It turns out that there is one system value which is an array:
> gl_SampleMask.  However, due to details, we only ever load element 0 so we
> can ignore the array deref in that case.  Unfortunately, this means that we
> can't do any better than what we have here. :-(

I think we could still be strict while handling that case, by being
explicit about it in the middle of the patch you shared:

nir_deref *deref = nir_src_as_deref(load_deref->src[0]);
if (deref->mode != nir_var_system_value) {
   continue;
}

if (deref->deref_type != nir_deref_type_var) {
   assert(deref->deref_type == nir_deref_type_array);
   assert(nir_instr_get_variable(deref)->data.location == 
SYSTEM_VALUE_SAMPLE_MASK);
   /* Short explanation that we only load ever position zero, maybe even 
assert... */
   deref = nir_deref_instr_parent(deref);
}

assert(deref->deref_type == nir_deref_type_var);
nir_variable *var = deref->var;

Would something like that work?


Thanks,
Caio






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


Re: [Mesa-dev] [PATCH] intel: aubinator: print out addresses of invalid instructions

2018-04-09 Thread Lionel Landwerlin

On 09/04/18 17:04, Scott D Phillips wrote:

Lionel Landwerlin  writes:


Signed-off-by: Lionel Landwerlin 
---
  src/intel/tools/gen_batch_decoder.c | 22 +-
  1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/src/intel/tools/gen_batch_decoder.c 
b/src/intel/tools/gen_batch_decoder.c
index 1a8794c84e7..b56aea53f1d 100644
--- a/src/intel/tools/gen_batch_decoder.c
+++ b/src/intel/tools/gen_batch_decoder.c
@@ -57,6 +57,7 @@ gen_batch_decode_ctx_finish(struct gen_batch_decode_ctx *ctx)
  }
  
  #define CSI "\e["

+#define RED_COLORCSI "31m"
  #define BLUE_HEADER  CSI "0;44m"
  #define GREEN_HEADER CSI "1;42m"
  #define NORMAL   CSI "0m"
@@ -734,14 +735,22 @@ gen_print_batch(struct gen_batch_decode_ctx *ctx,
length = gen_group_get_length(inst, p);
assert(inst == NULL || length > 0);
length = MAX2(1, length);
+
+  const char *reset_color = ctx->flags & GEN_BATCH_DECODE_IN_COLOR ? NORMAL : 
"";
+
+  uint64_t offset;
+  if (ctx->flags & GEN_BATCH_DECODE_OFFSETS)
+ offset = batch_addr + ((char *)p - (char *)batch);
+  else
+ offset = 0;
+
if (inst == NULL) {
- fprintf(ctx->fp, "unknown instruction %08x\n", p[0]);
+ fprintf(ctx->fp, "%s0x%08"PRIx64": unknown instruction %08x%s\n",
+ RED_COLOR, offset, p[0], reset_color);

I guess the RED_COLOR here should conditionally be "" when
!GEN_BATCH_DECODE_IN_COLOR, otherwise we'll print red and never stop.
With that,

Reviewed-by: Scott D Phillips 


Oops, will fix, thanks!




   continue;
}
  
-  const char *color, *reset_color;

-  uint64_t offset;
-
+  const char *color;
const char *inst_name = gen_group_get_name(inst);
if (ctx->flags & GEN_BATCH_DECODE_IN_COLOR) {
   reset_color = NORMAL;
@@ -759,11 +768,6 @@ gen_print_batch(struct gen_batch_decode_ctx *ctx,
   reset_color = "";
}
  
-  if (ctx->flags & GEN_BATCH_DECODE_OFFSETS)

- offset = batch_addr + ((char *)p - (char *)batch);
-  else
- offset = 0;
-
fprintf(ctx->fp, "%s0x%08"PRIx64":  0x%08x:  %-80s%s\n",
color, offset, p[0], inst_name, reset_color);
  
--

2.17.0

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



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


Re: [Mesa-dev] [PATCH v3 000/104] nir: Move to using instructions for derefs

2018-04-09 Thread Caio Marcelo de Oliveira Filho
Hi,

Given the fixes you already made based on my comments. Patches 1-20,
22-27, 29-43, and 61 (multiview!) are

Reviewed-by: Caio Marcelo de Oliveira Filho 

Patches 46-47 and 49 seem to be valid regardless the rest of the code,
so I'd consider getting them in independently. They are also R-b'ed.

I've skipped 21 and 28 because I wanted to give a deeper look at the
originals.

From the perspective of someone that is living with deref_vars for
just a short time, I like the idea of removing one special
construction (derefs) and rely on instructions instead.

Which made me wonder: was there a special factor that led NIR to start
with the "old-school derefs" in the first place? Other day Curro asked
about one of the "selling points" of NIR being it did not have all
those nodes representing dereferences. I digged up an old comment to
what I think he was referring to

https://lists.freedesktop.org/archives/mesa-dev/2014-February/053477.html

- All the ir_dereference chains blow up the memory usage, and the
constant pointer chasing in the recursive algorithms needed to handle
them is not just cache-unfriendly but "cache-mean."

How does deref_instructions avoid being "cache-mean" as their
"predecessors"? Was the blow up more a result of how the instructions
were structured than the fact it had those dereferences nodes?


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


Re: [Mesa-dev] [PATCH mesa 05/21] anv: Add EXT_direct_mode_display to anv driver

2018-04-09 Thread Jason Ekstrand
On Wed, Mar 7, 2018 at 11:25 PM, Keith Packard  wrote:

> Add support for the EXT_direct_mode_display extension. This just
> provides the vkReleaseDisplayEXT function.
>
> Signed-off-by: Keith Packard 
> ---
>  src/intel/vulkan/anv_extensions.py |  1 +
>  src/intel/vulkan/anv_wsi_display.c | 11 +++
>  2 files changed, 12 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_extensions.py b/src/intel/vulkan/anv_
> extensions.py
> index c23c0a87bb9..0c29e00c2fe 100644
> --- a/src/intel/vulkan/anv_extensions.py
> +++ b/src/intel/vulkan/anv_extensions.py
> @@ -108,6 +108,7 @@ EXTENSIONS = [
>  Extension('VK_KHR_xlib_surface',  6,
> 'VK_USE_PLATFORM_XLIB_KHR'),
>  Extension('VK_KHR_multiview', 1, True),
>  Extension('VK_KHR_display',  23,
> 'VK_USE_PLATFORM_DISPLAY_KHR'),
> +Extension('VK_EXT_direct_mode_display',   1,
> 'VK_USE_PLATFORM_DISPLAY_KHR'),
>

Alphabetize, please. :-)


>  Extension('VK_EXT_debug_report',  8, True),
>  Extension('VK_EXT_external_memory_dma_buf',   1, True),
>  Extension('VK_EXT_global_priority',   1,
> diff --git a/src/intel/vulkan/anv_wsi_display.c
> b/src/intel/vulkan/anv_wsi_display.c
> index 9b00d7f02e4..e6f67f7dec9 100644
> --- a/src/intel/vulkan/anv_wsi_display.c
> +++ b/src/intel/vulkan/anv_wsi_display.c
> @@ -127,3 +127,14 @@ anv_CreateDisplayPlaneSurfaceKHR(VkInstance
>   _instance
>
> return wsi_create_display_surface(_instance, alloc, create_info,
> surface);
>  }
> +
> +VkResult
> +anv_ReleaseDisplayEXT(VkPhysicalDevice physical_device,
> +   VkDisplayKHR display)
> +{
> +   ANV_FROM_HANDLE(anv_physical_device, pdevice, physical_device);
> +
> +   return wsi_release_display(physical_device,
> +  >wsi_device,
> +  display);
> +}
> --
> 2.16.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH mesa 04/21] vulkan: Add EXT_direct_mode_display

2018-04-09 Thread Jason Ekstrand
On Wed, Mar 7, 2018 at 11:25 PM, Keith Packard  wrote:

> Add support for the EXT_direct_mode_display extension. This just
> provides the vkReleaseDisplayEXT function.
>
> Signed-off-by: Keith Packard 
> ---
>  src/vulkan/wsi/wsi_common_display.c | 17 +
>  src/vulkan/wsi/wsi_common_display.h |  5 +
>  2 files changed, 22 insertions(+)
>
> diff --git a/src/vulkan/wsi/wsi_common_display.c
> b/src/vulkan/wsi/wsi_common_display.c
> index be31043f3de..45626541022 100644
> --- a/src/vulkan/wsi/wsi_common_display.c
> +++ b/src/vulkan/wsi/wsi_common_display.c
> @@ -1399,3 +1399,20 @@ wsi_display_finish_wsi(struct wsi_device
> *wsi_device,
>vk_free(alloc, wsi);
> }
>  }
> +
> +/*
> + * Implement vkReleaseDisplay
> + */
> +VkResult
> +wsi_release_display(VkPhysicalDevicephysical_device,
> +struct wsi_device   *wsi_device,
> +VkDisplayKHRdisplay)
> +{
> +   struct wsi_display   *wsi = (struct wsi_display *)
> wsi_device->wsi[VK_ICD_WSI_PLATFORM_DISPLAY];
> +
> +   if (wsi->fd >= 0) {
> +  close(wsi->fd);
> +  wsi->fd = -1;
>

This seems a bit odd.  Why is the FD not stored in the display?  What if
you acquire multiple displays for two-player VR?  If the master FD passed
in is not -1, we could just create a VkDisplayKHR object containing it.


> +   }
> +   return VK_SUCCESS;
> +}
> diff --git a/src/vulkan/wsi/wsi_common_display.h
> b/src/vulkan/wsi/wsi_common_display.h
> index b414a226293..5fbb6925e4a 100644
> --- a/src/vulkan/wsi/wsi_common_display.h
> +++ b/src/vulkan/wsi/wsi_common_display.h
> @@ -69,4 +69,9 @@ wsi_create_display_surface(VkInstance instance,
> const VkDisplaySurfaceCreateInfoKHR
> *pCreateInfo,
> VkSurfaceKHR *pSurface);
>
> +VkResult
> +wsi_release_display(VkPhysicalDevicephysical_device,
> +struct wsi_device   *wsi_device,
> +VkDisplayKHRdisplay);
> +
>  #endif
> --
> 2.16.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 002/104] nir: Add a deref instruction type

2018-04-09 Thread Bas Nieuwenhuizen
On Tue, Apr 10, 2018 at 12:37 AM, Rob Clark  wrote:
> On Mon, Apr 9, 2018 at 1:35 AM, Jason Ekstrand  wrote:
>> Rather lively discussion we've got going here...
>>
>> On Sun, Apr 8, 2018 at 3:23 PM, Rob Clark  wrote:
>>>
>>> On Sun, Apr 8, 2018 at 5:54 PM, Bas Nieuwenhuizen
>>>  wrote:
>>> > On Sun, Apr 8, 2018 at 11:40 PM, Rob Clark  wrote:
>>> >> On Sun, Apr 8, 2018 at 5:20 PM, Bas Nieuwenhuizen
>>> >>  wrote:
>>> >>>
>>> >>> You mean insert it into the fatptr every time deref_cast is called?
>>> >>>
>>> >>> Wouldn't that blow up the IR size significantly for very little
>>> >>> benefit?
>>> >>
>>> >> in an easy to clean up way, so meh?
>>> >
>>> > We can't clean it up if we want to keep the information. Also nir is
>>> > pretty slow to compile already, so I'd like not to add a significant
>>> > number of instruction for very little benefit.
>>
>>
>> Really?  I mean, I can believe it, but do you have any actual numbers to
>> back this up?  It's considerably faster than some other IRs we have in mesa
>> though they are known to be pretty big pigs if we're honest.  I'm very open
>> to any suggestions on how to improve compile times.  If NIR is fundamentally
>> a pig, we should fix that.
>>
>
> just a side-note, I guess mostly obvious but just pointing it out
> because it has caught others by surprise.  Debug mesa builds by
> default run nir_validate after every pass (unless you NIR_VALIDATE=0).
> And this adds a *lot* of overhead (for a *lot* of debugging benefit)..
>
> But if nir seems slow when running shader-db/etc, if you are using a
> debug build at least make sure to NIR_VALIDATE=0 (or better yet use a
> release build) when measuring performance

Yeah I was aware of that. Given this discussions I've actually run
some numbers for radv with a cold shader cache:

time total: 76.507337 sec
spirv 1.625971 sec
nir_to_llvm 10.146195 sec
llvm 46.058714 sec

hence total - spirv - nir_to_llvm - llvm = ~18.7 sec which is mostly due to nir.

Honestly a lot less than I expected, looks like the LLVM stuff is
spread over more functions and hence the nir stuff is higher in my
profiles.
>
> BR,
> -R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH mesa 02/21] anv: Add KHR_display extension to anv [v4]

2018-04-09 Thread Jason Ekstrand
On Wed, Mar 7, 2018 at 11:25 PM, Keith Packard  wrote:

> This adds support for the KHR_display extension to the anv Vulkan
> driver. The driver now attempts to open the master DRM node when the
> KHR_display extension is requested so that the common winsys code can
> perform the necessary operations.
>
> v2: Make sure primary fd is usable
>
> When KHR_display is selected, we try to open the primary node
> instead of the render node in case the user wants to use
> KHR_display for presentation. However, if we're actually going
> to end up using RandR leases, then we don't care if the
> resulting fd can't be used for display, but the kernel also
> prevents us from using it for drawing when someone else has
> master.
>
> v3:
> Simplify addition of VK_USE_PLATFORM_DISPLAY_KHR to vulkan_wsi_args
>
> Suggested-by: Eric Engestrom 
>
> v4:
> Adapt primary node usage to new wsi_device_init API
>
> Signed-off-by: Keith Packard 
> ---
>  src/intel/Makefile.sources |   3 +
>  src/intel/Makefile.vulkan.am   |   7 ++
>  src/intel/vulkan/anv_device.c  |  21 ++
>  src/intel/vulkan/anv_extensions.py |   1 +
>  src/intel/vulkan/anv_extensions_gen.py |   5 +-
>  src/intel/vulkan/anv_wsi_display.c | 129
> +
>  src/intel/vulkan/meson.build   |   5 ++
>  7 files changed, 169 insertions(+), 2 deletions(-)
>  create mode 100644 src/intel/vulkan/anv_wsi_display.c
>
> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
> index 91c71a8dfaf..6c6b57c603d 100644
> --- a/src/intel/Makefile.sources
> +++ b/src/intel/Makefile.sources
> @@ -250,6 +250,9 @@ VULKAN_WSI_WAYLAND_FILES := \
>  VULKAN_WSI_X11_FILES := \
> vulkan/anv_wsi_x11.c
>
> +VULKAN_WSI_DISPLAY_FILES := \
> +   vulkan/anv_wsi_display.c
> +
>  VULKAN_GEM_FILES := \
> vulkan/anv_gem.c
>
> diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
> index 6b71df6319a..9b6b68abef9 100644
> --- a/src/intel/Makefile.vulkan.am
> +++ b/src/intel/Makefile.vulkan.am
> @@ -193,6 +193,13 @@ VULKAN_SOURCES += $(VULKAN_WSI_WAYLAND_FILES)
>  VULKAN_LIB_DEPS += $(WAYLAND_CLIENT_LIBS)
>  endif
>
> +if HAVE_PLATFORM_DISPLAY
> +VULKAN_CPPFLAGS += \
> +   -DVK_USE_PLATFORM_DISPLAY_KHR
> +
> +VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
> +endif
> +
>  noinst_LTLIBRARIES += vulkan/libvulkan_common.la
>  vulkan_libvulkan_common_la_SOURCES = $(VULKAN_SOURCES)
>  vulkan_libvulkan_common_la_CFLAGS = $(VULKAN_CFLAGS)
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index ab61e0ce339..de1d5af2137 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -278,6 +278,7 @@ anv_physical_device_init_uuids(struct
> anv_physical_device *device)
>  static VkResult
>  anv_physical_device_init(struct anv_physical_device *device,
>   struct anv_instance *instance,
> + const char *primary_path,
>   const char *path)
>  {
> VkResult result;
> @@ -444,6 +445,25 @@ anv_physical_device_init(struct anv_physical_device
> *device,
> anv_physical_device_get_supported_extensions(device,
>
>  >supported_extensions);
>
> +   if (instance->enabled_extensions.KHR_display) {
> +  master_fd = open(path, O_RDWR | O_CLOEXEC);
> +  if (master_fd >= 0) {
> + /* prod the device with a GETPARAM call which will fail if
> +  * we don't have permission to even render on this device
> +  */
> + drm_i915_getparam_t gp;
> + memset(, '\0', sizeof(gp));
> + int devid = 0;
> + gp.param = I915_PARAM_CHIPSET_ID;
> + gp.value = 
> + int ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
> + if (ret < 0) {
> +close(master_fd);
> +master_fd = -1;
> + }
> +  }
> +   }
> +
> device->local_fd = fd;
> device->master_fd = master_fd;
> return VK_SUCCESS;
> @@ -641,6 +661,7 @@ anv_enumerate_devices(struct anv_instance *instance)
>
>   result = anv_physical_device_init(>physicalDevice,
>  instance,
> +devices[i]->nodes[DRM_NODE_PRIMARY],
>  devices[i]->nodes[DRM_NODE_RENDER]);
>   if (result != VK_ERROR_INCOMPATIBLE_DRIVER)
>  break;
> diff --git a/src/intel/vulkan/anv_extensions.py b/src/intel/vulkan/anv_
> extensions.py
> index d0b70a04055..c23c0a87bb9 100644
> --- a/src/intel/vulkan/anv_extensions.py
> +++ b/src/intel/vulkan/anv_extensions.py
> @@ -107,6 +107,7 @@ EXTENSIONS = [
>  Extension('VK_KHR_xcb_surface',   6,
> 'VK_USE_PLATFORM_XCB_KHR'),
>  Extension('VK_KHR_xlib_surface',  6,
> 'VK_USE_PLATFORM_XLIB_KHR'),
>  Extension('VK_KHR_multiview',   

Re: [Mesa-dev] [PATCH v3 057/104] nir,spirv: Rework function calls

2018-04-09 Thread Caio Marcelo de Oliveira Filho
Hi,

>  typedef struct {
> -   nir_parameter_type param_type;
> -   const struct glsl_type *type;
> +   uint8_t num_components;
> +   uint8_t bit_size;
>  } nir_parameter;

(...)

> @@ -683,18 +692,12 @@ validate_tex_instr(nir_tex_instr *instr, validate_state 
> *state)
>  static void
>  validate_call_instr(nir_call_instr *instr, validate_state *state)
>  {
> -   if (instr->return_deref == NULL) {
> -  validate_assert(state, glsl_type_is_void(instr->callee->return_type));
> -   } else {
> -  validate_assert(state, instr->return_deref->deref.type == 
> instr->callee->return_type);
> -  validate_deref_var(instr, instr->return_deref, state);
> -   }
> -
> validate_assert(state, instr->num_params == instr->callee->num_params);
>  
> for (unsigned i = 0; i < instr->num_params; i++) {
> -  validate_assert(state, instr->callee->params[i].type == 
> instr->params[i]->deref.type);
> -  validate_deref_var(instr, instr->params[i], state);
> +  validate_src(>params[i], state,
> +   instr->callee->params[i].bit_size,
> +   instr->callee->params[i].num_components);
> }
>  }

Question: I might be misreading, but it seems like we are losing the
type information for functions. Isn't that something worth keeping,
maybe in some other way, e.g. load_param specifying the expected type?


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


Re: [Mesa-dev] [PATCH mesa 01/21] vulkan: Add KHR_display extension using DRM [v4]

2018-04-09 Thread Jason Ekstrand
Sorry for the multitude of replies. :-(

On Wed, Mar 7, 2018 at 11:24 PM, Keith Packard  wrote:

> This adds support for the KHR_display extension support to the vulkan
> WSI layer. Driver support will be added separately.
>
> v2:
> * fix double ;; in wsi_common_display.c
>
> * Move mode list from wsi_display to wsi_display_connector
>
> * Fix scope for wsi_display_mode andwsi_display_connector
>   allocs
>
> * Switch all allocations to vk_zalloc instead of vk_alloc.
>
> * Fix DRM failure in
>   wsi_display_get_physical_device_display_properties
>
>   When DRM fails, or when we don't have a master fd
>   (presumably due to application errors), just return 0
>   properties from this function, which is at least a valid
>   response.
>
> * Use vk_outarray for all property queries
>
>   This is a bit less error-prone than open-coding the same
>   stuff.
>
> * Remove VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR from surface caps
>
>   Until we have multi-plane support, we shouldn't pretend to
>   have any multi-plane semantics, even if undefined.
>
> Suggested-by: Jason Ekstrand 
>
> * Simplify addition of VK_USE_PLATFORM_DISPLAY_KHR to
>   vulkan_wsi_args
>
> Suggested-by: Eric Engestrom 
>
> v3:
> Add separate 'display_fd' and 'render_fd' arguments to
> wsi_device_init API. This allows drivers to use different FDs
> for the different aspects of the device.
>
> Use largest mode as display size when no preferred mode.
>
> If the display doesn't provide a preferred mode, we'll assume
> that the largest supported mode is the "physical size" of the
> device and report that.
>
> v4:
> Make wsi_image_state enumeration values uppercase.
> Follow more common mesa conventions.
>
> Remove 'render_fd' from wsi_device_init API.  The
> wsi_common_display code doesn't use this fd at all, so stop
> passing it in. This avoids any potential confusion over which
> fd to use when creating display-relative object handles.
>
> Remove call to wsi_create_prime_image which would never have
> been reached as the necessary condition (use_prime_blit) is
> never set.
>
> whitespace cleanups in wsi_common_display.c
>
> Suggested-by: Jason Ekstrand 
>
> Add depth/bpp info to available surface formats.  Instead of
> hard-coding depth 24 bpp 32 in the drmModeAddFB call, use the
> requested format to find suitable values.
>
> Destroy kernel buffers and FBs when swapchain is destroyed. We
> were leaking both of these kernel objects across swapchain
> destruction.
>
> Note that wsi_display_wait_for_event waits for anything to
> happen.  wsi_display_wait_for_event is simply a yield so that
> the caller can then check to see if the desired state change
> has occurred.
>
> Record swapchain failures in chain for later return. If some
> asynchronous swapchain activity fails, we need to tell the
> application eventually. Record the failure in the swapchain
> and report it at the next acquire_next_image or queue_present
> call.
>
> Fix error returns from wsi_display_setup_connector.  If a
> malloc failed, then the result should be
> VK_ERROR_OUT_OF_HOST_MEMORY. Otherwise, the associated ioctl
> failed and we're either VT switched away, or our lease has
> been revoked, in which case we should return
> VK_ERROR_OUT_OF_DATE_KHR.
>
> Make sure both sides of if/else brace use matches
>
> Note that we assume drmModeSetCrtc is synchronous. Add a
> comment explaining why we can idle any previous displayed
> image as soon as the mode set returns.
>
> Note that EACCES from drmModePageFlip means VT inactive.  When
> vt switched away drmModePageFlip returns EACCES. Poll once a
> second waiting until we get some other return value back.
>
> Clean up after alloc failure in
> wsi_display_surface_create_swapchain. Destroy any created
> images, free the swapchain.
>
> Remove physical_device from wsi_display_init_wsi. We never
> need this value, so remove it from the API and from the
> internal wsi_display structure.
>
> Use drmModeAddFB2 in wsi_display_image_init.  This takes a drm
> format instead of depth/bpp, which provides more control over
> the format of the data.
>
> Signed-off-by: Keith Packard 
> ---
>  configure.ac|1 +
>  meson.build |4 +-
>  src/amd/vulkan/radv_device.c|8 +
>  

Re: [Mesa-dev] [PATCH 04/11] gallium: Use Array._DrawVAO in st_atom_array.c.

2018-04-09 Thread Mathias Fröhlich
Hi Marek,

On Saturday, 7 April 2018 01:53:58 CEST Marek Olšák wrote:
> So interleaved attribs are unsupported, right?
> 
> is_interleaved_arrays was probably slowing things down, so I'm OK with that.

I am currently away from all the source code and be back at about the 22.4.

But out of my head: The main purpose of the is_interleaved_arrays that I could 
spot is to minimize the vbo's that are send down the pipeline. In the non vbo 
case the is_interleaved_arrays check did nothing I could finally spot?
The buffer itself is marked as user buffer and we need a new vbuffer because 
of the pointer value anyway? Correct?

So, the VAO now contains all the redundancy information. And thanks to this 
bitmask sieves we can easily collect the arrays belonging to a specific 
precollapsed binding point.
So, the is_interleaved is fully there in the vbo case. Even better as before. 
It sees even 4 attributes distributed across two pairwise interleaved vbo 
arrays.

So even if you are fine, if you tell me that the user buffer code can make use 
of the same sharing finally, I can take a look at that and establish the same 
sort of sharing here.

best

Mathias


> 
> Marek
> 
> On Sun, Apr 1, 2018 at 2:13 PM,  wrote:
> > From: Mathias Fröhlich 
> > 
> > Finally make use of the binding information in the VAO when
> > setting up arrays for draw.
> > 
> > Signed-off-by: Mathias Fröhlich 
> > ---
> > 
> >  src/mesa/state_tracker/st_atom_array.c | 448
> > 
> > +
> > 
> >  1 file changed, 124 insertions(+), 324 deletions(-)
> > 
> > diff --git a/src/mesa/state_tracker/st_atom_array.c
> > b/src/mesa/state_tracker/st_atom_array.c
> > index 2fd67e8d84..46934a718a 100644
> > --- a/src/mesa/state_tracker/st_atom_array.c
> > +++ b/src/mesa/state_tracker/st_atom_array.c
> > @@ -48,6 +48,7 @@
> > 
> >  #include "main/bufferobj.h"
> >  #include "main/glformats.h"
> >  #include "main/varray.h"
> > 
> > +#include "main/arrayobj.h"
> > 
> >  /* vertex_formats[gltype - GL_BYTE][integer*2 + normalized][size - 1] */
> >  static const uint16_t vertex_formats[][4][4] = {
> > 
> > @@ -306,79 +307,6 @@ st_pipe_vertex_format(const struct
> > gl_array_attributes *attrib)
> > 
> > return vertex_formats[type - GL_BYTE][index][size-1];
> >  
> >  }
> > 
> > -static const struct gl_vertex_array *
> > -get_client_array(const struct gl_vertex_array *arrays,
> > - unsigned mesaAttr)
> > -{
> > -   /* st_program uses 0x to denote a double placeholder attribute
> > */
> > -   if (mesaAttr == ST_DOUBLE_ATTRIB_PLACEHOLDER)
> > -  return NULL;
> > -   return [mesaAttr];
> > -}
> > -
> > -/**
> > - * Examine the active arrays to determine if we have interleaved
> > - * vertex arrays all living in one VBO, or all living in user space.
> > - */
> > -static GLboolean
> > -is_interleaved_arrays(const struct st_vertex_program *vp,
> > -  const struct gl_vertex_array *arrays,
> > -  unsigned num_inputs)
> > -{
> > -   GLuint attr;
> > -   const struct gl_buffer_object *firstBufObj = NULL;
> > -   GLint firstStride = -1;
> > -   const GLubyte *firstPtr = NULL;
> > -   GLboolean userSpaceBuffer = GL_FALSE;
> > -
> > -   for (attr = 0; attr < num_inputs; attr++) {
> > -  const struct gl_vertex_array *array;
> > -  const struct gl_vertex_buffer_binding *binding;
> > -  const struct gl_array_attributes *attrib;
> > -  const GLubyte *ptr;
> > -  const struct gl_buffer_object *bufObj;
> > -  GLsizei stride;
> > -
> > -  array = get_client_array(arrays, vp->index_to_input[attr]);
> > -  if (!array)
> > -continue;
> > -
> > -  binding = array->BufferBinding;
> > -  attrib = array->VertexAttrib;
> > -  stride = binding->Stride; /* in bytes */
> > -  ptr = _mesa_vertex_attrib_address(attrib, binding);
> > -
> > -  /* To keep things simple, don't allow interleaved zero-stride
> > attribs. */
> > -  if (stride == 0)
> > - return false;
> > -
> > -  bufObj = binding->BufferObj;
> > -  if (attr == 0) {
> > - /* save info about the first array */
> > - firstStride = stride;
> > - firstPtr = ptr;
> > - firstBufObj = bufObj;
> > - userSpaceBuffer = !_mesa_is_bufferobj(bufObj);
> > -  }
> > -  else {
> > - /* check if other arrays interleave with the first, in same
> > buffer */
> > - if (stride != firstStride)
> > -return GL_FALSE; /* strides don't match */
> > -
> > - if (bufObj != firstBufObj)
> > -return GL_FALSE; /* arrays in different VBOs */
> > -
> > - if (llabs(ptr - firstPtr) > firstStride)
> > -return GL_FALSE; /* arrays start too far apart */
> > -
> > - if ((!_mesa_is_bufferobj(bufObj)) != userSpaceBuffer)
> > -return GL_FALSE; /* mix of VBO and user-space arrays */
> > -  }
> 

[Mesa-dev] [PATCH 1/1] i965: Make sure the shadow buffers have enough space

2018-04-09 Thread James Xiong
From: "Xiong, James" 

On non-LLC platforms, we malloc shadow batch/state buffers
of the same sizes as our batch/state buffers' GEM allocations.
However the buffer allocator reuses similar-sized gem objects,
it returns a buffer larger than we asked for in some cases
and we end up with smaller shadow buffers. If we utilize the
full-size of the over-allocated batch/state buffers, we may wind
up accessing beyond the bounds of the shadow buffers and cause
segmentation fault and/or memory corruption.

A few examples:
 casebatch  state
 request bo   shadow request bo  shadow
init020K 20K  20K16K 16K 16K
grow_buffer 130K 32K  30K24K 24K 24K
grow_buffer 248K 48K  48K36K 40K 36K
grow_buffer 372K 80K  72K60K 64K 60K
grow_buffer 4120K128K 120K   -   -   -

batch #1, #3, #4; state #2 and #3 are problematic. We can change
the order to allocate the bo first, then allocate the shadow
buffer using the bo's size so that the shadow buffer have at
least an equivalent size of the gem allocation.

Another problem: even though the state/batch buffer could grow,
when checking if it runs out space, we always compare with the
initial batch/state sizes. To utilize the entire buffers, change
to compare with the actual sizes.

Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Xiong, James 
---
 src/mesa/drivers/dri/i965/brw_context.h   |  1 +
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 49 +--
 2 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index f049d08..39aae08 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -477,6 +477,7 @@ struct brw_growing_bo {
struct brw_bo *partial_bo;
uint32_t *partial_bo_map;
unsigned partial_bytes;
+   unsigned shadow_size;
 };
 
 struct intel_batchbuffer {
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 7286140..facbbf8 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -107,12 +107,6 @@ intel_batchbuffer_init(struct brw_context *brw)
 
batch->use_shadow_copy = !devinfo->has_llc;
 
-   if (batch->use_shadow_copy) {
-  batch->batch.map = malloc(BATCH_SZ);
-  batch->map_next = batch->batch.map;
-  batch->state.map = malloc(STATE_SZ);
-   }
-
init_reloc_list(>batch_relocs, 250);
init_reloc_list(>state_relocs, 250);
 
@@ -212,10 +206,25 @@ intel_batchbuffer_reset(struct brw_context *brw)
batch->last_bo = batch->batch.bo;
 
recreate_growing_buffer(brw, >batch, "batchbuffer", BATCH_SZ);
-   batch->map_next = batch->batch.map;
 
recreate_growing_buffer(brw, >state, "statebuffer", STATE_SZ);
 
+   if (batch->use_shadow_copy) {
+  if (batch->batch.shadow_size < batch->batch.bo->size) {
+ free(batch->batch.map);
+ batch->batch.map = malloc(batch->batch.bo->size);
+ batch->batch.shadow_size = batch->batch.bo->size;
+  }
+
+  if (batch->state.shadow_size < batch->state.bo->size) {
+ free(batch->state.map);
+ batch->state.map = malloc(batch->state.bo->size);
+ batch->state.shadow_size = batch->state.bo->size;
+  }
+   }
+
+   batch->map_next = batch->batch.map;
+
/* Avoid making 0 a valid state offset - otherwise the decoder will try
 * and decode data when we use offset 0 as a null pointer.
 */
@@ -361,7 +370,8 @@ grow_buffer(struct brw_context *brw,
* breaking existing pointers the caller may still be using.  Just
* malloc a new copy and memcpy it like the normal BO path.
*/
-  grow->map = malloc(new_size);
+  grow->map = malloc(new_bo->size);
+  grow->shadow_size = new_bo->size;
} else {
   grow->map = brw_bo_map(brw, new_bo, MAP_READ | MAP_WRITE);
}
@@ -467,15 +477,17 @@ intel_batchbuffer_require_space(struct brw_context *brw, 
GLuint sz,
}
 
const unsigned batch_used = USED_BATCH(*batch) * 4;
-   if (batch_used + sz >= BATCH_SZ && !batch->no_wrap) {
-  intel_batchbuffer_flush(brw);
-   } else if (batch_used + sz >= batch->batch.bo->size) {
-  const unsigned new_size =
- MIN2(batch->batch.bo->size + batch->batch.bo->size / 2,
-  MAX_BATCH_SIZE);
-  grow_buffer(brw, >batch, batch_used, new_size);
-  batch->map_next = (void *) batch->batch.map + batch_used;
-  assert(batch_used + sz < batch->batch.bo->size);
+   if (batch_used + sz >= batch->batch.bo->size) {
+  if (!batch->no_wrap) {
+ intel_batchbuffer_flush(brw);
+  } else {
+ const unsigned new_size =
+MIN2(batch->batch.bo->size + batch->batch.bo->size / 2,
+ MAX_BATCH_SIZE);
+   

Re: [Mesa-dev] [PATCH mesa 01/21] vulkan: Add KHR_display extension using DRM [v4]

2018-04-09 Thread Jason Ekstrand
On Wed, Mar 7, 2018 at 11:24 PM, Keith Packard  wrote:

>
> +/*
> + * Implement vkGetPhysicalDeviceDisplayPropertiesKHR (VK_KHR_display)
> + */
> +VkResult
> +wsi_display_get_physical_device_display_properties(VkPhysicalDevice
>physical_device,
> +   struct wsi_device
>   *wsi_device,
> +   uint32_t
>*property_count,
> +
>  VkDisplayPropertiesKHR   *properties)
> +{
> +   struct wsi_display   *wsi = (struct wsi_display *)
> wsi_device->wsi[VK_ICD_WSI_PLATFORM_DISPLAY];
> +   drmModeResPtrmode_res;
> +
> +   if (wsi->fd < 0)
> +  goto bail;
> +
> +   mode_res = drmModeGetResources(wsi->fd);
> +
> +   if (!mode_res)
> +  goto bail;
>

If you move the VK_OUTARRAY_MAKE up higher, both of the "goto bail"s can be
"return vk_outarray_status()".  Not a big deal though; what you have
is probably fine.


> +
> +   VK_OUTARRAY_MAKE(conn, properties, property_count);
> +
> +   /* Get current information */
> +
> +   for (int c = 0; c < mode_res->count_connectors; c++) {
> +  struct wsi_display_connector *connector =
> + wsi_display_get_connector(wsi_device, mode_res->connectors[c]);
> +
> +  if (!connector) {
> + drmModeFreeResources(mode_res);
> + return VK_ERROR_OUT_OF_HOST_MEMORY;
> +  }
> +
> +  if (connector->connected) {
> + vk_outarray_append(, prop) {
> +wsi_display_fill_in_display_properties(wsi_device,
> +   connector,
> +   prop);
> + }
> +  }
> +   }
> +
> +   drmModeFreeResources(mode_res);
> +
> +   return vk_outarray_status();
> +
> +bail:
> +   *property_count = 0;
> +   return VK_SUCCESS;
> +}
> +
> +/*
> + * Implement vkGetPhysicalDeviceDisplayPlanePropertiesKHR (VK_KHR_display
> + */
> +VkResult
> +wsi_display_get_physical_device_display_plane_properties(VkPhysicalDevice
>  physical_device,
> + struct
> wsi_device  *wsi_device,
> + uint32_t
>*property_count,
> +
>  VkDisplayPlanePropertiesKHR*properties)
> +{
> +   struct wsi_display   *wsi = (struct wsi_display *)
> wsi_device->wsi[VK_ICD_WSI_PLATFORM_DISPLAY];
> +   struct wsi_display_connector *connector;
> +
> +   VK_OUTARRAY_MAKE(conn, properties, property_count);
> +
> +   int stack_index = 0;
> +
> +   LIST_FOR_EACH_ENTRY(connector, >connectors, list) {
> +  vk_outarray_append(, prop) {
> + if (connector && connector->active) {
> +prop->currentDisplay = wsi_display_connector_to_handl
> e(connector);
> +prop->currentStackIndex = stack_index++;
>

In your branch, this is 0.  Why the change?


> + } else {
> +prop->currentDisplay = NULL;
>

This should probably be VK_NULL_HANDLE


> +prop->currentStackIndex = 0;
> + }
> +  }
> +   }
> +   return vk_outarray_status();
> +}


[...]


> +static const VkPresentModeKHR available_present_modes[] = {
> +   VK_PRESENT_MODE_FIFO_KHR,
> +};
> +
> +static VkResult
> +wsi_display_surface_get_present_modes(VkIcdSurfaceBase  *surface,
> +  uint32_t
> *present_mode_count,
> +  VkPresentModeKHR  *present_modes)
> +{
> +   VK_OUTARRAY_MAKE(conn, present_modes, present_mode_count);
> +
> +   for (unsigned int c = 0; c < ARRAY_SIZE(available_present_modes);
> c++) {
> +  vk_outarray_append(, present) {
> + *present = available_present_modes[c];
> +  }
> +   }
>

I don't think the array is helpful here.  We can just do a
vk_outarray_append with FIFO and call it good.  If anything, it's probably
worse since other present modes will probably be dependent on things such
as whether or not the driver exposes ASYNC.


> +
> +   return vk_outarray_status();
> +}
> +
> +static void
> +wsi_display_destroy_buffer(struct wsi_display *wsi,
> +   uint32_t buffer)
> +{
> +   (void) drmIoctl(wsi->fd, DRM_IOCTL_MODE_DESTROY_DUMB,
> +   &((struct drm_mode_destroy_dumb) { .handle = buffer
> }));
> +}
>

[...]


> +static VkResult
> +wsi_display_acquire_next_image(struct wsi_swapchain *drv_chain,
> +   uint64_t timeout,
> +   VkSemaphore  semaphore,
> +   uint32_t *image_index)
> +{
> +   struct wsi_display_swapchain *chain = (struct wsi_display_swapchain
> *)drv_chain;
> +   struct wsi_display   *wsi = chain->wsi;
> +   int  ret = 0;
> +   VkResult result = VK_SUCCESS;
> +
> +   /* Bail early if the swapchain is broken */
> +   if (chain->status != 

Re: [Mesa-dev] [PATCH v3 002/104] nir: Add a deref instruction type

2018-04-09 Thread Rob Clark
On Mon, Apr 9, 2018 at 1:35 AM, Jason Ekstrand  wrote:
> Rather lively discussion we've got going here...
>
> On Sun, Apr 8, 2018 at 3:23 PM, Rob Clark  wrote:
>>
>> On Sun, Apr 8, 2018 at 5:54 PM, Bas Nieuwenhuizen
>>  wrote:
>> > On Sun, Apr 8, 2018 at 11:40 PM, Rob Clark  wrote:
>> >> On Sun, Apr 8, 2018 at 5:20 PM, Bas Nieuwenhuizen
>> >>  wrote:
>> >>>
>> >>> You mean insert it into the fatptr every time deref_cast is called?
>> >>>
>> >>> Wouldn't that blow up the IR size significantly for very little
>> >>> benefit?
>> >>
>> >> in an easy to clean up way, so meh?
>> >
>> > We can't clean it up if we want to keep the information. Also nir is
>> > pretty slow to compile already, so I'd like not to add a significant
>> > number of instruction for very little benefit.
>
>
> Really?  I mean, I can believe it, but do you have any actual numbers to
> back this up?  It's considerably faster than some other IRs we have in mesa
> though they are known to be pretty big pigs if we're honest.  I'm very open
> to any suggestions on how to improve compile times.  If NIR is fundamentally
> a pig, we should fix that.
>

just a side-note, I guess mostly obvious but just pointing it out
because it has caught others by surprise.  Debug mesa builds by
default run nir_validate after every pass (unless you NIR_VALIDATE=0).
And this adds a *lot* of overhead (for a *lot* of debugging benefit)..

But if nir seems slow when running shader-db/etc, if you are using a
debug build at least make sure to NIR_VALIDATE=0 (or better yet use a
release build) when measuring performance

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


Re: [Mesa-dev] [PATCH] gallium: move ddebug, noop, rbug, trace to auxiliary to improve build times

2018-04-09 Thread Dylan Baker
Are you building LLVM yourself, or is that a build that comes with your distro?
Also, what is your distro?

Quoting Marek Olšák (2018-04-09 14:27:10)
> See:
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=
> f55d1f806e6b6c33af559de166d08ec8fa3ebe90
> 
> Marek
> 
> On Mon, Apr 9, 2018 at 5:08 PM, Dylan Baker  wrote:
> 
> Quoting Marek Olšák (2018-04-09 13:44:27)
> > meson fails to link LLVM on my setup, so I can't use it, therefore all 
> my
> meson
> > changes are untested.
> >
> > Even if meson worked, I have to use make, because that's what users use.
> >
> > This change simplifies the meson build too.
> >
> > Marek
> >
> 
> What happens with LLVM on your system?
>
> Dylan
> 
> 


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] gallium: move ddebug, noop, rbug, trace to auxiliary to improve build times

2018-04-09 Thread Marek Olšák
See:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=f55d1f806e6b6c33af559de166d08ec8fa3ebe90

Marek

On Mon, Apr 9, 2018 at 5:08 PM, Dylan Baker  wrote:

> Quoting Marek Olšák (2018-04-09 13:44:27)
> > meson fails to link LLVM on my setup, so I can't use it, therefore all
> my meson
> > changes are untested.
> >
> > Even if meson worked, I have to use make, because that's what users use.
> >
> > This change simplifies the meson build too.
> >
> > Marek
> >
>
> What happens with LLVM on your system?
>
> Dylan
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] radeonsi: correct si_vgt_param_key on big endian machines

2018-04-09 Thread Marek Olšák
On Mon, Apr 9, 2018 at 5:19 PM, Gert Wollny  wrote:

> Am Montag, den 09.04.2018, 14:03 -0400 schrieb Marek Olšák:
> > On Mon, Apr 9, 2018 at 10:51 AM, Bas Vermeulen 
> > wrote:
> Which solution is better depends on what is done more often: reading
> the index or writing to the bit fields.
>
> > > I am working on a new version of this patch. I have one version
> > > which does away with all the bitfields, and uses functions to
> > > update the index.
> This emulates the code the compiler would create, but it requires that
> for each bit field setters (and getters?) must be implemented.
>
> > > Another approach would be to change the union to a struct, and use
> > > a function to get the index.
> This method has the advantage that only the access to the index needs
> new implementation.
>
> > > Yet another approach would be to keep the contents of the union and
> > > the index in one struct, and use a function to
> > > (re)calculate the index.
> I don't think that would make much sense.
>
> There is another option: Check at configuration time whether the bit
> field layout is like the low or the high endian layout you already
> implemented, and instead of basing the selection of the struct layout
> on the big/low-endianess of the architecture, base it on this test.
>
> It would probably be prudent to test both layouts and then fail
> configuration if non of the two reflect the actual layout (at which
> point one would have to thing about how to implement all the bit
> shifting properly).
>
> > >
> > > Which would you prefer?
> > >
> >
> > I don't mind bitfields. They make the code nice and tiny. Shifts
> > would decrease readability.
> The problem is, that the layout of bitfields is compiler dependend.
>

We can fix it after we discover that it's a real problem on a compiler we
care about.

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


Re: [Mesa-dev] [PATCH] radeonsi: correct si_vgt_param_key on big endian machines

2018-04-09 Thread Gert Wollny
Am Montag, den 09.04.2018, 14:03 -0400 schrieb Marek Olšák:
> On Mon, Apr 9, 2018 at 10:51 AM, Bas Vermeulen 
> wrote:
Which solution is better depends on what is done more often: reading
the index or writing to the bit fields. 

> > I am working on a new version of this patch. I have one version
> > which does away with all the bitfields, and uses functions to
> > update the index.
This emulates the code the compiler would create, but it requires that
for each bit field setters (and getters?) must be implemented. 

> > Another approach would be to change the union to a struct, and use
> > a function to get the index.
This method has the advantage that only the access to the index needs
new implementation.

> > Yet another approach would be to keep the contents of the union and
> > the index in one struct, and use a function to
> > (re)calculate the index.
I don't think that would make much sense. 

There is another option: Check at configuration time whether the bit
field layout is like the low or the high endian layout you already
implemented, and instead of basing the selection of the struct layout
on the big/low-endianess of the architecture, base it on this test.

It would probably be prudent to test both layouts and then fail
configuration if non of the two reflect the actual layout (at which
point one would have to thing about how to implement all the bit
shifting properly). 

> > 
> > Which would you prefer?
> > 
> 
> I don't mind bitfields. They make the code nice and tiny. Shifts
> would decrease readability.
The problem is, that the layout of bitfields is compiler dependend. 

Best, 
Gert

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


[Mesa-dev] [PATCH] radv: move save/restore operations close to the slow clears

2018-04-09 Thread Samuel Pitoiset
This removes the emission of unnecessary states, for example
when performing a fast depth stencil clear (ie. clearing htile),
we don't need to save/restore the graphics pipeline.

For GFX9 chips that have the scissor bug workaround, that
should also reduce the number of partial flushes.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_meta_bufimage.c |  8 +
 src/amd/vulkan/radv_meta_clear.c| 47 +
 2 files changed, 22 insertions(+), 33 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_bufimage.c 
b/src/amd/vulkan/radv_meta_bufimage.c
index 69e15d3213..5018ce1f2e 100644
--- a/src/amd/vulkan/radv_meta_bufimage.c
+++ b/src/amd/vulkan/radv_meta_bufimage.c
@@ -1242,8 +1242,14 @@ radv_meta_clear_image_cs(struct radv_cmd_buffer 
*cmd_buffer,
 {
VkPipeline pipeline = cmd_buffer->device->meta_state.cleari.pipeline;
struct radv_device *device = cmd_buffer->device;
+   struct radv_meta_saved_state saved_state;
struct radv_image_view dst_iview;
 
+   radv_meta_save(_state, cmd_buffer,
+  RADV_META_SAVE_COMPUTE_PIPELINE |
+  RADV_META_SAVE_CONSTANTS |
+  RADV_META_SAVE_DESCRIPTORS);
+
create_iview(cmd_buffer, dst, _iview);
cleari_bind_descriptors(cmd_buffer, _iview);
 
@@ -1268,4 +1274,6 @@ radv_meta_clear_image_cs(struct radv_cmd_buffer 
*cmd_buffer,
  push_constants);
 
radv_unaligned_dispatch(cmd_buffer, dst->image->info.width, 
dst->image->info.height, 1);
+
+   radv_meta_restore(_state, cmd_buffer);
 }
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index 016c1ee296..833e3cebab 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -342,6 +342,7 @@ emit_color_clear(struct radv_cmd_buffer *cmd_buffer,
unsigned fs_key = radv_format_meta_fs_key(iview->vk_format);
VkClearColorValue clear_value = clear_att->clearValue.color;
VkCommandBuffer cmd_buffer_h = radv_cmd_buffer_to_handle(cmd_buffer);
+   struct radv_meta_saved_state saved_state;
VkPipeline pipeline;
 
if (fs_key == -1) {
@@ -359,6 +360,10 @@ emit_color_clear(struct radv_cmd_buffer *cmd_buffer,
assert(clear_att->aspectMask == VK_IMAGE_ASPECT_COLOR_BIT);
assert(clear_att->colorAttachment < subpass->color_count);
 
+   radv_meta_save(_state, cmd_buffer,
+  RADV_META_SAVE_GRAPHICS_PIPELINE |
+  RADV_META_SAVE_CONSTANTS);
+
radv_CmdPushConstants(radv_cmd_buffer_to_handle(cmd_buffer),
  device->meta_state.clear_color_p_layout,
  VK_SHADER_STAGE_FRAGMENT_BIT, 0, 16,
@@ -397,6 +402,8 @@ emit_color_clear(struct radv_cmd_buffer *cmd_buffer,
}
 
radv_cmd_buffer_set_subpass(cmd_buffer, subpass, false);
+
+   radv_meta_restore(_state, cmd_buffer);
 }
 
 
@@ -613,12 +620,17 @@ emit_depthstencil_clear(struct radv_cmd_buffer 
*cmd_buffer,
const uint32_t samples = iview->image->info.samples;
const uint32_t samples_log2 = ffs(samples) - 1;
VkCommandBuffer cmd_buffer_h = radv_cmd_buffer_to_handle(cmd_buffer);
+   struct radv_meta_saved_state saved_state;
 
assert(pass_att != VK_ATTACHMENT_UNUSED);
 
if (!(aspects & VK_IMAGE_ASPECT_DEPTH_BIT))
clear_value.depth = 1.0f;
 
+   radv_meta_save(_state, cmd_buffer,
+  RADV_META_SAVE_GRAPHICS_PIPELINE |
+  RADV_META_SAVE_CONSTANTS);
+
radv_CmdPushConstants(radv_cmd_buffer_to_handle(cmd_buffer),
  device->meta_state.clear_depth_p_layout,
  VK_SHADER_STAGE_VERTEX_BIT, 0, 4,
@@ -664,6 +676,8 @@ emit_depthstencil_clear(struct radv_cmd_buffer *cmd_buffer,
radv_CmdSetStencilReference(cmd_buffer_h, 
VK_STENCIL_FACE_FRONT_BIT,
  prev_reference);
}
+
+   radv_meta_restore(_state, cmd_buffer);
 }
 
 static bool
@@ -1165,17 +1179,12 @@ void
 radv_cmd_buffer_clear_subpass(struct radv_cmd_buffer *cmd_buffer)
 {
struct radv_cmd_state *cmd_state = _buffer->state;
-   struct radv_meta_saved_state saved_state;
enum radv_cmd_flush_bits pre_flush = 0;
enum radv_cmd_flush_bits post_flush = 0;
 
if (!radv_subpass_needs_clear(cmd_buffer))
return;
 
-   radv_meta_save(_state, cmd_buffer,
-  RADV_META_SAVE_GRAPHICS_PIPELINE |
-  RADV_META_SAVE_CONSTANTS);
-
for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
uint32_t a = 
cmd_state->subpass->color_attachments[i].attachment;
 
@@ -1210,7 +1219,6 @@ radv_cmd_buffer_clear_subpass(struct radv_cmd_buffer 
*cmd_buffer)
  _flush);
  

Re: [Mesa-dev] [PATCH] gallium: move ddebug, noop, rbug, trace to auxiliary to improve build times

2018-04-09 Thread Dylan Baker
Quoting Marek Olšák (2018-04-09 13:44:27)
> meson fails to link LLVM on my setup, so I can't use it, therefore all my 
> meson
> changes are untested.
> 
> Even if meson worked, I have to use make, because that's what users use.
> 
> This change simplifies the meson build too.
> 
> Marek
> 

What happens with LLVM on your system?

Dylan


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


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

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105567

--- Comment #10 from Dylan Baker  ---
My suspicion was correct, we're not handling absolute paths and DESTDIR
correctly. I think that this patch should resolve it:
https://patchwork.freedesktop.org/patch/216020/

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


[Mesa-dev] [PATCH 2/2] bin/install_megadrivers: rename a few variables to make things clearer

2018-04-09 Thread Dylan Baker
Originally the "each" variable was just a part of the "drivers"
variable. It's not anymore so it's a bit ambiguous.

Signed-off-by: Dylan Baker 
---
 bin/install_megadrivers.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/bin/install_megadrivers.py b/bin/install_megadrivers.py
index c04a2a3eb34..8d9ed9c6dce 100755
--- a/bin/install_megadrivers.py
+++ b/bin/install_megadrivers.py
@@ -46,23 +46,23 @@ def main():
 os.makedirs(to)
 shutil.copy(args.megadriver, master)
 
-for each in args.drivers:
-driver = os.path.join(to, each)
+for driver in args.drivers:
+abs_driver = os.path.join(to, driver)
 
-if os.path.exists(driver):
-os.unlink(driver)
-print('installing {} to {}'.format(args.megadriver, driver))
-os.link(master, driver)
+if os.path.exists(abs_driver):
+os.unlink(abs_driver)
+print('installing {} to {}'.format(args.megadriver, abs_driver))
+os.link(master, abs_driver)
 
 try:
 ret = os.getcwd()
 os.chdir(to)
 
-name, ext = os.path.splitext(each)
+name, ext = os.path.splitext(driver)
 while ext != '.so':
 if os.path.exists(name):
 os.unlink(name)
-os.symlink(each, name)
+os.symlink(driver, name)
 name, ext = os.path.splitext(name)
 finally:
 os.chdir(ret)
-- 
2.17.0

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


[Mesa-dev] [PATCH 1/2] bin/install_megadrivers: fix DESTDIR and -D*-path

2018-04-09 Thread Dylan Baker
This fixes -Ddri-drivers-path, -Dvdpau-libs-path, etc. with DESTDIR when
those paths are absolute. Currently due to the way python's os.path.join
handles absolute paths these will ignore DESTDIR, which is bad. This
fixes them to be relative to DESTDIR if that is set.

Fixes: 3218056e0eb375eeda470058d06add1532acd6d4
   ("meson: Build i965 and dri stack")
Signed-off-by: Dylan Baker 
---
 bin/install_megadrivers.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/bin/install_megadrivers.py b/bin/install_megadrivers.py
index 7931a544bd2..c04a2a3eb34 100755
--- a/bin/install_megadrivers.py
+++ b/bin/install_megadrivers.py
@@ -1,6 +1,6 @@
 #!/usr/bin/env python
 # encoding=utf-8
-# Copyright © 2017 Intel Corporation
+# Copyright © 2017-2018 Intel Corporation
 
 # Permission is hereby granted, free of charge, to any person obtaining a copy
 # of this software and associated documentation files (the "Software"), to deal
@@ -35,7 +35,11 @@ def main():
 parser.add_argument('drivers', nargs='+')
 args = parser.parse_args()
 
-to = os.path.join(os.environ.get('MESON_INSTALL_DESTDIR_PREFIX'), 
args.libdir)
+if os.path.isabs(args.libdir):
+to = os.path.join(os.environ.get('DESTDIR', '/'), args.libdir[1:])
+else:
+to = os.path.join(os.environ['MESON_INSTALL_DESTDIR_PREFIX'], 
args.libdir)
+
 master = os.path.join(to, os.path.basename(args.megadriver))
 
 if not os.path.exists(to):
-- 
2.17.0

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


[Mesa-dev] [Bug 105918] Mesa 18.0.0-2 video color issues and distorted video with system hang on restart (Apple Mac Pro 6, 1 with AMD D300 GPUs)

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105918

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Timothy Arceri  ---


*** This bug has been marked as a duplicate of bug 104597 ***

-- 
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 2/2] st/mesa: finalise tcs/tes/geom NIR before storing it to the cache

2018-04-09 Thread Marek Olšák
For the series:

Reviewed-by: Marek Olšák 

Marek

On Thu, Apr 5, 2018 at 3:37 AM, Timothy Arceri 
wrote:

> We don't create variants of the NIR so here we finalise it before
> caching to avoid unnecessary processing when restoring it.
> ---
>  src/mesa/state_tracker/st_program.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_program.c
> b/src/mesa/state_tracker/st_program.c
> index a740c874c9e..3f8df31da18 100644
> --- a/src/mesa/state_tracker/st_program.c
> +++ b/src/mesa/state_tracker/st_program.c
> @@ -1473,6 +1473,9 @@ st_translate_geometry_program(struct st_context *st,
>
> /* We have already compiled to NIR so just return */
> if (stgp->shader_program) {
> +  /* No variants */
> +  st_finalize_nir(st, >Base, stgp->shader_program,
> +  stgp->tgsi.ir.nir);
>st_translate_program_stream_output(>Base,
> >tgsi.stream_output);
>st_store_ir_in_disk_cache(st, >Base, true);
>return true;
> @@ -1530,8 +1533,6 @@ st_get_basic_variant(struct st_context *st,
>  if (prog->tgsi.type == PIPE_SHADER_IR_NIR) {
> tgsi.type = PIPE_SHADER_IR_NIR;
> tgsi.ir.nir = nir_shader_clone(NULL, prog->tgsi.ir.nir);
> -   st_finalize_nir(st, >Base, prog->shader_program,
> -tgsi.ir.nir);
>  tgsi.stream_output = prog->tgsi.stream_output;
>  } else
> tgsi = prog->tgsi;
> @@ -1575,6 +1576,9 @@ st_translate_tessctrl_program(struct st_context *st,
>
> /* We have already compiled to NIR so just return */
> if (sttcp->shader_program) {
> +  /* No variants */
> +  st_finalize_nir(st, >Base, sttcp->shader_program,
> +  sttcp->tgsi.ir.nir);
>st_store_ir_in_disk_cache(st, >Base, true);
>return true;
> }
> @@ -1606,6 +1610,9 @@ st_translate_tesseval_program(struct st_context *st,
>
> /* We have already compiled to NIR so just return */
> if (sttep->shader_program) {
> +  /* No variants */
> +  st_finalize_nir(st, >Base, sttep->shader_program,
> +  sttep->tgsi.ir.nir);
>st_translate_program_stream_output(>Base,
> >tgsi.stream_output);
>st_store_ir_in_disk_cache(st, >Base, true);
>return true;
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gallium: move ddebug, noop, rbug, trace to auxiliary to improve build times

2018-04-09 Thread Marek Olšák
meson fails to link LLVM on my setup, so I can't use it, therefore all my
meson changes are untested.

Even if meson worked, I have to use make, because that's what users use.

This change simplifies the meson build too.

Marek


On Mon, Apr 9, 2018 at 2:21 PM, Dylan Baker  wrote:

> Have you tried using the meson build if you're that concerned about build
> times?
> The plan remains to remove the autotools build at some point, so creating a
> massive amount of churn in the autotools build that may or may not break
> something to get some amount of speedup when you could just change tools
> and get
> a better speedup seems odd to me.
>
> (meson -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=radeonsi)
> for reference, with cold ccache:
> ninja -C build-si -j6  703.15s user 56.77s system 383% cpu 3:17.94 total
>
> and a hot:
> ninja -C build-si -j6  54.36s user 6.72s system 340% cpu 17.929 total
>
> compared to autotools
> (./configure --without-dri-drivers --without-vulkan-drivers
> --with-gallium-drivers=radeonsi)
> cold:
> make -j6  827.63s user 72.89s system 339% cpu 4:25.34 total
>
> hot:
> make -j6  175.09s user 24.42s system 278% cpu 1:11.64 total
>
> Just to be clear, meson/ninja doesn't suffer from the recursive make
> problem
> that autotools does. There is no way you can get the same level of
> performance
> from make without reducing the autotools build to gibberish.
>
> Dylan
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 105960] [bisected] meson build test fails with: undefined reference to `etna_pm_create_query'

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105960

Clayton Craft  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Clayton Craft  ---
Yep, that seems to have fixed it, thanks!

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


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

2018-04-09 Thread Marek Olšák
If you add break statements into patch 5, the series is:

Reviewed-by: Marek Olšák 

Marek

On Thu, Apr 5, 2018 at 1:34 AM, Timothy Arceri 
wrote:

> This makes it easier to follow the code, and also initialises
> dynamic_index which will be useful for adding bindless textures
> support.
> ---
>  src/gallium/drivers/radeonsi/si_shader_nir.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
> b/src/gallium/drivers/radeonsi/si_shader_nir.c
> index 362b7445cc5..f916575a1a1 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_nir.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
> @@ -880,14 +880,12 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi,
> struct si_shader_context *ctx = si_shader_context_from_abi(abi);
> LLVMBuilderRef builder = ctx->ac.builder;
> LLVMValueRef list = LLVMGetParam(ctx->main_fn,
> ctx->param_samplers_and_images);
> -   LLVMValueRef index = dynamic_index;
> +   LLVMValueRef index;
>
> assert(!descriptor_set);
>
> -   if (!index)
> -   index = ctx->ac.i32_0;
> -
> -   index = LLVMBuildAdd(builder, index,
> +   dynamic_index = dynamic_index ? dynamic_index : ctx->ac.i32_0;
> +   index = LLVMBuildAdd(builder, dynamic_index,
>  LLVMConstInt(ctx->ac.i32, base_index +
> constant_index, false),
>  "");
>
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2018-04-09 Thread Marek Olšák
Do you need break statements?

Marek

On Thu, Apr 5, 2018 at 1:34 AM, Timothy Arceri 
wrote:

> V2: add missing intrinsics (Spotted-by: Samuel Pitoiset)
> ---
>  src/gallium/drivers/radeonsi/si_shader_nir.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
> b/src/gallium/drivers/radeonsi/si_shader_nir.c
> index 01c8554272f..362b7445cc5 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_nir.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
> @@ -123,6 +123,13 @@ static void scan_instruction(struct tgsi_shader_info
> *info,
> case nir_intrinsic_load_tess_level_outer:
> info->reads_tess_factors = true;
> break;
> +   case nir_intrinsic_image_var_load:
> +   case nir_intrinsic_image_var_size:
> +   case nir_intrinsic_image_var_samples: {
> +   nir_variable *var = intr->variables[0]->var;
> +   if (var->data.bindless)
> +   info->uses_bindless_images = true;
> +   }
> case nir_intrinsic_image_var_store:
> case nir_intrinsic_image_var_atomic_add:
> case nir_intrinsic_image_var_atomic_min:
> @@ -131,7 +138,11 @@ static void scan_instruction(struct tgsi_shader_info
> *info,
> case nir_intrinsic_image_var_atomic_or:
> case nir_intrinsic_image_var_atomic_xor:
> case nir_intrinsic_image_var_atomic_exchange:
> -   case nir_intrinsic_image_var_atomic_comp_swap:
> +   case nir_intrinsic_image_var_atomic_comp_swap: {
> +   nir_variable *var = intr->variables[0]->var;
> +   if (var->data.bindless)
> +   info->uses_bindless_images = true;
> +   }
> case nir_intrinsic_store_ssbo:
> case nir_intrinsic_ssbo_atomic_add:
> case nir_intrinsic_ssbo_atomic_imin:
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] docs/release-calendar: update to include 18.1 and 18.2

2018-04-09 Thread Dylan Baker
Quoting Emil Velikov (2018-04-09 11:02:45)
> From: Emil Velikov 
> 
> Dylan has kindly stepped up to help with 18.1.0, while I've taken the
> liberty to nominate Andres for 18.2.0 ;-)
> 
> As always, people are welcome to swap/adjust where needed.
> 
> Cc: Dylan Baker 
> Cc: Andres Gomez 
> Cc: Juan A. Suarez Romero 
> Signed-off-by: Emil Velikov 
> ---
>  docs/release-calendar.html | 84 
> --
>  1 file changed, 82 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/release-calendar.html b/docs/release-calendar.html
> index 8f588ab46c..cbaed4d5d9 100644
> --- a/docs/release-calendar.html
> +++ b/docs/release-calendar.html
> @@ -43,10 +43,10 @@ if you'd like to nominate a patch in the next stable 
> release.
>  2018-04-06
>  17.3.9
>  Juan A. Suarez Romero
> -Final planned release for the 17.3 series
> +Last planned 17.3.x release
>  
>  
> -18.0
> +18.0
>  2018-04-06
>  18.0.1
>  Andres Gomez
> @@ -64,6 +64,86 @@ if you'd like to nominate a patch in the next stable 
> release.
>  Andres Gomez
>  
>  
> +
> +2018-05-18
> +18.0.4
> +Andres Gomez
> +Last planned 18.0.x release
> +
> +
> +18.1
> +2018-04-20
> +18.1.0rc1
> +Dylan Baker
> +
> +
> +
> +2018-04-27
> +18.1.0rc2
> +Dylan Baker
> +
> +
> +
> +2018-05-04
> +18.1.0rc3
> +Dylan Baker
> +
> +
> +
> +2018-05-11
> +18.1.0rc4
> +Dylan Baker
> +Last planned RC/Final release
> +
> +
> +TBD
> +18.1.1
> +Emil Velikov
> +
> +
> +
> +TBD
> +18.1.2
> +Emil Velikov
> +
> +
> +
> +TBD
> +18.1.3
> +Emil Velikov
> +
> +
> +
> +TBD
> +18.1.4
> +Emil Velikov
> +Last planned RC/Final release
> +
> +
> +18.2
> +2018-07-20
> +18.2.0rc1
> +Andres Gomez
> +
> +
> +
> +2018-07-27
> +18.2.0rc2
> +Andres Gomez
> +
> +
> +
> +2018-08-03
> +18.2.0rc3
> +Andres Gomez
> +
> +
> +
> +2018-08-10
> +18.2.0rc4
> +Andres Gomez
> +Last planned RC/Final release
> +
>  
>  
>  
> -- 
> 2.16.0
> 

Looks good on my end,
Acked-by: Dylan Baker 


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


Re: [Mesa-dev] [Mesa-stable] [PATCH 1/1] i965: return the fourcc saved in __DRIimage when possible

2018-04-09 Thread Xiong, James
Hi Mark,

We need add a dmabuf export test case in piglit, unfortunately I don't have 
time to work on it at the moment, it's on my to-do list.

Thanks,
James

-Original Message-
From: Janes, Mark A 
Sent: Monday, April 9, 2018 11:17 AM
To: Xiong, James ; mesa-dev@lists.freedesktop.org
Cc: Xiong, James ; mesa-sta...@lists.freedesktop.org; 
Palli, Tapani 
Subject: Re: [Mesa-stable] [PATCH 1/1] i965: return the fourcc saved in 
__DRIimage when possible

Hi James,

Would it be possible to create a piglit test to exercise the bug referenced in 
your commit message?  If possible, we want to prevent future regressions for 
this use case.

thanks,

Mark


James Xiong  writes:

> From: "Xiong, James" 
>
> When creating a image from a texture, the image's dri_format is set to 
> the first plane's format, and used to look up for the fourcc. e.g. for 
> FOURCC_NV12 texture, the dri_format is set to __DRI_IMAGE_FORMAT_R8, 
> we end up with a wrong entry in function
> intel_lookup_fourcc():
>{ __DRI_IMAGE_FOURCC_R8, __DRI_IMAGE_COMPONENTS_R, 1,
>  { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 }, } }, instead of the 
> corret one:
>{ __DRI_IMAGE_FOURCC_NV12, __DRI_IMAGE_COMPONENTS_Y_UV, 2,
>  { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
>{ 1, 1, 1, __DRI_IMAGE_FORMAT_GR88, 2 } } }, as a result, a 
> wrong fourcc __DRI_IMAGE_FOURCC_R8 was returned.
>
> To fix this bug, the image inherits the texture's planar_format that 
> has the original fourcc; Upon querying, if planar_format is set, 
> return the saved fourcc; Otherwise fall back to the old way.
>
> v3: add a bug description and "cc mesa-stable" tag (Jason)
>   remove abandunt null pointer check (Tapani)
>   squash 2 patches into one (James)
> v2: fall back to intel_lookup_fourcc() when planar_format is NULL
>   (Dongwon & Matt Roper)
>
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Xiong, James 
> ---
>  src/mesa/drivers/dri/i965/intel_screen.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index dcb98da..29cb7ad 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -388,10 +388,16 @@ intel_image_format_lookup(int fourcc)
> return NULL;
>  }
>  
> -static boolean intel_lookup_fourcc(int dri_format, int *fourcc)
> +static boolean
> +intel_image_get_fourcc(__DRIimage *image, int *fourcc)
>  {
> +   if (image->planar_format) {
> +  *fourcc = image->planar_format->fourcc;
> +  return true;
> +   }
> +
> for (unsigned i = 0; i < ARRAY_SIZE(intel_image_formats); i++) {
> -  if (intel_image_formats[i].planes[0].dri_format == dri_format) {
> +  if (intel_image_formats[i].planes[0].dri_format == 
> + image->dri_format) {
>   *fourcc = intel_image_formats[i].fourcc;
>   return true;
>}
> @@ -578,6 +584,7 @@ intel_create_image_from_texture(__DRIcontext *context, 
> int target,
> intel_setup_image_from_mipmap_tree(brw, image, iobj->mt, level, zoffset);
> image->dri_format = driGLFormatToImageFormat(image->format);
> image->has_depthstencil = iobj->mt->stencil_mt? true : false;
> +   image->planar_format = iobj->planar_format;
> if (image->dri_format == MESA_FORMAT_NONE) {
>*error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
>free(image);
> @@ -869,7 +876,7 @@ intel_query_image(__DRIimage *image, int attrib, int 
> *value)
> case __DRI_IMAGE_ATTRIB_FD:
>return !brw_bo_gem_export_to_prime(image->bo, value);
> case __DRI_IMAGE_ATTRIB_FOURCC:
> -  return intel_lookup_fourcc(image->dri_format, value);
> +  return intel_image_get_fourcc(image, value);
> case __DRI_IMAGE_ATTRIB_NUM_PLANES:
>if (isl_drm_modifier_has_aux(image->modifier)) {
>   assert(!image->planar_format || 
> image->planar_format->nplanes == 1);
> --
> 2.7.4
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gallium: move ddebug, noop, rbug, trace to auxiliary to improve build times

2018-04-09 Thread Dylan Baker
Have you tried using the meson build if you're that concerned about build times?
The plan remains to remove the autotools build at some point, so creating a
massive amount of churn in the autotools build that may or may not break
something to get some amount of speedup when you could just change tools and get
a better speedup seems odd to me.

(meson -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=radeonsi)
for reference, with cold ccache:
ninja -C build-si -j6  703.15s user 56.77s system 383% cpu 3:17.94 total

and a hot:
ninja -C build-si -j6  54.36s user 6.72s system 340% cpu 17.929 total

compared to autotools
(./configure --without-dri-drivers --without-vulkan-drivers 
--with-gallium-drivers=radeonsi)
cold:
make -j6  827.63s user 72.89s system 339% cpu 4:25.34 total

hot:
make -j6  175.09s user 24.42s system 278% cpu 1:11.64 total

Just to be clear, meson/ninja doesn't suffer from the recursive make problem
that autotools does. There is no way you can get the same level of performance
from make without reducing the autotools build to gibberish.

Dylan

Quoting Marek Olšák (2018-04-07 12:08:36)
> From: Marek Olšák 
> 
> which also simplifies the build scripts.
> ---
>  configure.ac   |  4 ---
>  src/gallium/Makefile.am|  6 
>  src/gallium/SConscript |  2 --
>  src/gallium/auxiliary/Makefile.am  |  3 ++
>  src/gallium/auxiliary/Makefile.sources | 29 +++
>  .../driver_ddebug}/dd_context.c|  0
>  .../ddebug => auxiliary/driver_ddebug}/dd_draw.c   |  0
>  .../ddebug => auxiliary/driver_ddebug}/dd_pipe.h   |  0
>  .../ddebug => auxiliary/driver_ddebug}/dd_public.h |  0
>  .../ddebug => auxiliary/driver_ddebug}/dd_screen.c |  0
>  .../ddebug => auxiliary/driver_ddebug}/dd_util.h   |  0
>  .../noop => auxiliary/driver_noop}/noop_pipe.c |  0
>  .../noop => auxiliary/driver_noop}/noop_public.h   |  0
>  .../noop => auxiliary/driver_noop}/noop_state.c|  0
>  .../{drivers/rbug => auxiliary/driver_rbug}/README |  0
>  .../rbug => auxiliary/driver_rbug}/rbug_context.c  |  0
>  .../rbug => auxiliary/driver_rbug}/rbug_context.h  |  0
>  .../rbug => auxiliary/driver_rbug}/rbug_core.c |  0
>  .../rbug => auxiliary/driver_rbug}/rbug_objects.c  |  0
>  .../rbug => auxiliary/driver_rbug}/rbug_objects.h  |  0
>  .../rbug => auxiliary/driver_rbug}/rbug_public.h   |  0
>  .../rbug => auxiliary/driver_rbug}/rbug_screen.c   |  0
>  .../rbug => auxiliary/driver_rbug}/rbug_screen.h   |  0
>  .../trace => auxiliary/driver_trace}/README|  2 +-
>  .../trace => auxiliary/driver_trace}/tr_context.c  |  0
>  .../trace => auxiliary/driver_trace}/tr_context.h  |  0
>  .../trace => auxiliary/driver_trace}/tr_dump.c |  0
>  .../trace => auxiliary/driver_trace}/tr_dump.h |  0
>  .../driver_trace}/tr_dump_defines.h|  0
>  .../driver_trace}/tr_dump_state.c  |  0
>  .../driver_trace}/tr_dump_state.h  |  0
>  .../trace => auxiliary/driver_trace}/tr_public.h   |  0
>  .../trace => auxiliary/driver_trace}/tr_screen.c   |  0
>  .../trace => auxiliary/driver_trace}/tr_screen.h   |  0
>  .../trace => auxiliary/driver_trace}/tr_texture.c  |  0
>  .../trace => auxiliary/driver_trace}/tr_texture.h  |  0
>  .../trace => auxiliary/driver_trace}/trace.xsl |  0
>  src/gallium/auxiliary/meson.build  | 29 +++
>  src/gallium/auxiliary/rbug/README  |  2 +-
>  .../auxiliary/target-helpers/inline_debug_helper.h | 32 -
>  src/gallium/drivers/ddebug/Makefile.am | 11 
>  src/gallium/drivers/ddebug/Makefile.sources|  7 -
>  src/gallium/drivers/ddebug/meson.build | 28 --
>  src/gallium/drivers/noop/Makefile.am   | 16 ---
>  src/gallium/drivers/noop/Makefile.sources  |  4 ---
>  src/gallium/drivers/noop/SConscript| 13 -
>  src/gallium/drivers/noop/meson.build   | 27 --
>  src/gallium/drivers/radeonsi/si_debug.c|  2 +-
>  src/gallium/drivers/radeonsi/si_pipe.c |  2 +-
>  src/gallium/drivers/rbug/Makefile.am   | 33 
> --
>  src/gallium/drivers/rbug/Makefile.sources  |  9 --
>  src/gallium/drivers/rbug/SConscript| 12 
>  src/gallium/drivers/rbug/meson.build   | 28 --
>  src/gallium/drivers/trace/Makefile.am  | 15 --
>  src/gallium/drivers/trace/Makefile.sources | 13 -
>  src/gallium/drivers/trace/SConscript   | 14 -
>  src/gallium/drivers/trace/meson.build  | 29 ---
>  src/gallium/meson.build|  4 ---
>  src/gallium/state_trackers/osmesa/Makefile.am  |  3 +-
>  

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/1] i965: return the fourcc saved in __DRIimage when possible

2018-04-09 Thread Mark Janes
Hi James,

Would it be possible to create a piglit test to exercise the bug
referenced in your commit message?  If possible, we want to prevent
future regressions for this use case.

thanks,

Mark


James Xiong  writes:

> From: "Xiong, James" 
>
> When creating a image from a texture, the image's dri_format is
> set to the first plane's format, and used to look up for the
> fourcc. e.g. for FOURCC_NV12 texture, the dri_format is set to
> __DRI_IMAGE_FORMAT_R8, we end up with a wrong entry in function
> intel_lookup_fourcc():
>{ __DRI_IMAGE_FOURCC_R8, __DRI_IMAGE_COMPONENTS_R, 1,
>  { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 }, } },
> instead of the corret one:
>{ __DRI_IMAGE_FOURCC_NV12, __DRI_IMAGE_COMPONENTS_Y_UV, 2,
>  { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
>{ 1, 1, 1, __DRI_IMAGE_FORMAT_GR88, 2 } } },
> as a result, a wrong fourcc __DRI_IMAGE_FOURCC_R8 was returned.
>
> To fix this bug, the image inherits the texture's planar_format that
> has the original fourcc; Upon querying, if planar_format is set,
> return the saved fourcc; Otherwise fall back to the old way.
>
> v3: add a bug description and "cc mesa-stable" tag (Jason)
>   remove abandunt null pointer check (Tapani)
>   squash 2 patches into one (James)
> v2: fall back to intel_lookup_fourcc() when planar_format is NULL
>   (Dongwon & Matt Roper)
>
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Xiong, James 
> ---
>  src/mesa/drivers/dri/i965/intel_screen.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index dcb98da..29cb7ad 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -388,10 +388,16 @@ intel_image_format_lookup(int fourcc)
> return NULL;
>  }
>  
> -static boolean intel_lookup_fourcc(int dri_format, int *fourcc)
> +static boolean
> +intel_image_get_fourcc(__DRIimage *image, int *fourcc)
>  {
> +   if (image->planar_format) {
> +  *fourcc = image->planar_format->fourcc;
> +  return true;
> +   }
> +
> for (unsigned i = 0; i < ARRAY_SIZE(intel_image_formats); i++) {
> -  if (intel_image_formats[i].planes[0].dri_format == dri_format) {
> +  if (intel_image_formats[i].planes[0].dri_format == image->dri_format) {
>   *fourcc = intel_image_formats[i].fourcc;
>   return true;
>}
> @@ -578,6 +584,7 @@ intel_create_image_from_texture(__DRIcontext *context, 
> int target,
> intel_setup_image_from_mipmap_tree(brw, image, iobj->mt, level, zoffset);
> image->dri_format = driGLFormatToImageFormat(image->format);
> image->has_depthstencil = iobj->mt->stencil_mt? true : false;
> +   image->planar_format = iobj->planar_format;
> if (image->dri_format == MESA_FORMAT_NONE) {
>*error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
>free(image);
> @@ -869,7 +876,7 @@ intel_query_image(__DRIimage *image, int attrib, int 
> *value)
> case __DRI_IMAGE_ATTRIB_FD:
>return !brw_bo_gem_export_to_prime(image->bo, value);
> case __DRI_IMAGE_ATTRIB_FOURCC:
> -  return intel_lookup_fourcc(image->dri_format, value);
> +  return intel_image_get_fourcc(image, value);
> case __DRI_IMAGE_ATTRIB_NUM_PLANES:
>if (isl_drm_modifier_has_aux(image->modifier)) {
>   assert(!image->planar_format || image->planar_format->nplanes == 1);
> -- 
> 2.7.4
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] docs/release-calendar: update to include 18.1 and 18.2

2018-04-09 Thread Emil Velikov
From: Emil Velikov 

Dylan has kindly stepped up to help with 18.1.0, while I've taken the
liberty to nominate Andres for 18.2.0 ;-)

As always, people are welcome to swap/adjust where needed.

Cc: Dylan Baker 
Cc: Andres Gomez 
Cc: Juan A. Suarez Romero 
Signed-off-by: Emil Velikov 
---
 docs/release-calendar.html | 84 --
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/docs/release-calendar.html b/docs/release-calendar.html
index 8f588ab46c..cbaed4d5d9 100644
--- a/docs/release-calendar.html
+++ b/docs/release-calendar.html
@@ -43,10 +43,10 @@ if you'd like to nominate a patch in the next stable 
release.
 2018-04-06
 17.3.9
 Juan A. Suarez Romero
-Final planned release for the 17.3 series
+Last planned 17.3.x release
 
 
-18.0
+18.0
 2018-04-06
 18.0.1
 Andres Gomez
@@ -64,6 +64,86 @@ if you'd like to nominate a patch in the next stable release.
 Andres Gomez
 
 
+
+2018-05-18
+18.0.4
+Andres Gomez
+Last planned 18.0.x release
+
+
+18.1
+2018-04-20
+18.1.0rc1
+Dylan Baker
+
+
+
+2018-04-27
+18.1.0rc2
+Dylan Baker
+
+
+
+2018-05-04
+18.1.0rc3
+Dylan Baker
+
+
+
+2018-05-11
+18.1.0rc4
+Dylan Baker
+Last planned RC/Final release
+
+
+TBD
+18.1.1
+Emil Velikov
+
+
+
+TBD
+18.1.2
+Emil Velikov
+
+
+
+TBD
+18.1.3
+Emil Velikov
+
+
+
+TBD
+18.1.4
+Emil Velikov
+Last planned RC/Final release
+
+
+18.2
+2018-07-20
+18.2.0rc1
+Andres Gomez
+
+
+
+2018-07-27
+18.2.0rc2
+Andres Gomez
+
+
+
+2018-08-03
+18.2.0rc3
+Andres Gomez
+
+
+
+2018-08-10
+18.2.0rc4
+Andres Gomez
+Last planned RC/Final release
+
 
 
 
-- 
2.16.0

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


Re: [Mesa-dev] [PATCH] trace: allow image resource to be null

2018-04-09 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek

On Sat, Apr 7, 2018 at 10:17 PM, Ilia Mirkin  wrote:

> ping
>
> On Tue, Feb 27, 2018 at 12:19 AM, Ilia Mirkin 
> wrote:
> > Signed-off-by: Ilia Mirkin 
> > ---
> >  src/gallium/drivers/trace/tr_dump_state.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/trace/tr_dump_state.c
> b/src/gallium/drivers/trace/tr_dump_state.c
> > index e7e32237c4c..2d12720ddd9 100644
> > --- a/src/gallium/drivers/trace/tr_dump_state.c
> > +++ b/src/gallium/drivers/trace/tr_dump_state.c
> > @@ -724,7 +724,7 @@ void trace_dump_image_view(const struct
> pipe_image_view *state)
> > if (!trace_dumping_enabled_locked())
> >return;
> >
> > -   if(!state) {
> > +   if (!state || !state->resource) {
> >trace_dump_null();
> >return;
> > }
> > --
> > 2.16.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] radeonsi: correct si_vgt_param_key on big endian machines

2018-04-09 Thread Marek Olšák
On Mon, Apr 9, 2018 at 10:51 AM, Bas Vermeulen  wrote:

> I am working on a new version of this patch. I have one version which does
> away with all the bitfields, and uses
> functions to update the index.
> Another approach would be to change the union to a struct, and use a
> function to get the index.
> Yet another approach would be to keep the contents of the union and the
> index in one struct, and use a function to
> (re)calculate the index.
>
> Which would you prefer?
>

I don't mind bitfields. They make the code nice and tiny. Shifts would
decrease readability.

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


Re: [Mesa-dev] [PATCH] radeonsi: autotools: add si_build_pm4.h in dist tarball

2018-04-09 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek

On Mon, Apr 9, 2018 at 10:57 AM, Juan A. Suarez Romero 
wrote:

> Fixes: 94f726c36d ("radeonsi: move r600_cs.h contents into si_pipe.h,
> si_build_pm4.h")
> ---
>  src/gallium/drivers/radeonsi/Makefile.sources | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/radeonsi/Makefile.sources
> b/src/gallium/drivers/radeonsi/Makefile.sources
> index 6117005cbd3..b20a5497f5e 100644
> --- a/src/gallium/drivers/radeonsi/Makefile.sources
> +++ b/src/gallium/drivers/radeonsi/Makefile.sources
> @@ -7,6 +7,7 @@ C_SOURCES := \
> driinfo_radeonsi.h \
> si_blit.c \
> si_buffer.c \
> +   si_build_pm4.h \
> si_clear.c \
> si_compute.c \
> si_compute.h \
> --
> 2.15.0
>
> ___
> 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 105918] Mesa 18.0.0-2 video color issues and distorted video with system hang on restart (Apple Mac Pro 6, 1 with AMD D300 GPUs)

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105918

--- Comment #3 from Jonas Platte  ---
Sorry for the broken link, don't know how I accidentally added 'T' to the end.
Proper link: https://bugs.freedesktop.org/show_bug.cgi?id=104597

-- 
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 105918] Mesa 18.0.0-2 video color issues and distorted video with system hang on restart (Apple Mac Pro 6, 1 with AMD D300 GPUs)

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105918

--- Comment #2 from Jonas Platte  ---
Played around a bit more and found out this only happens with compton. And it
seems to have been reported a while ago already:

compton bug: https://github.com/chjj/compton/issues/477
comment with workaround (works for me):
https://github.com/chjj/compton/issues/477#issuecomment-370155748
underlying issue: https://bugs.freedesktop.org/show_bug.cgi?id=104597T

-- 
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 2/2] radeonsi: convert dispatch packet to little endian

2018-04-09 Thread Marek Olšák
I pushed both patches, thanks.

Marek

On Mon, Apr 9, 2018 at 7:06 AM, Bas Vermeulen  wrote:

> The parameters for the compute engine are wrong when using
> an E8860 on a big endian machine.
> To fix this, convert the contents of struct dispatch_packet
> to little endian.
>
> This ensures that get_global_id(0) and similar functions
> in the OpenCL code get the correct endian values, and
> makes my simple OpenCL program work correctly.
>
> Signed-off-by: Bas Vermeulen 
> ---
>  src/gallium/drivers/radeonsi/si_compute.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> index dfede47605..8ac5b262c4 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -564,18 +564,18 @@ static void si_setup_user_sgprs_co_v2(struct
> si_context *sctx,
> /* Upload dispatch ptr */
> memset(, 0, sizeof(dispatch));
>
> -   dispatch.workgroup_size_x = info->block[0];
> -   dispatch.workgroup_size_y = info->block[1];
> -   dispatch.workgroup_size_z = info->block[2];
> +   dispatch.workgroup_size_x = util_cpu_to_le16(info->block[
> 0]);
> +   dispatch.workgroup_size_y = util_cpu_to_le16(info->block[
> 1]);
> +   dispatch.workgroup_size_z = util_cpu_to_le16(info->block[
> 2]);
>
> -   dispatch.grid_size_x = info->grid[0] * info->block[0];
> -   dispatch.grid_size_y = info->grid[1] * info->block[1];
> -   dispatch.grid_size_z = info->grid[2] * info->block[2];
> +   dispatch.grid_size_x = util_cpu_to_le32(info->grid[0] *
> info->block[0]);
> +   dispatch.grid_size_y = util_cpu_to_le32(info->grid[1] *
> info->block[1]);
> +   dispatch.grid_size_z = util_cpu_to_le32(info->grid[2] *
> info->block[2]);
>
> -   dispatch.private_segment_size = program->private_size;
> -   dispatch.group_segment_size = program->local_size;
> +   dispatch.private_segment_size = util_cpu_to_le32(program->
> private_size);
> +   dispatch.group_segment_size = util_cpu_to_le32(program->
> local_size);
>
> -   dispatch.kernarg_address = kernel_args_va;
> +   dispatch.kernarg_address = util_cpu_to_le64(kernel_args_
> va);
>
> u_upload_data(sctx->b.const_uploader, 0, sizeof(dispatch),
>256, , _offset,
> @@ -652,9 +652,9 @@ static bool si_upload_compute_input(struct si_context
> *sctx,
>
> if (!code_object) {
> for (i = 0; i < 3; i++) {
> -   kernel_args[i] = info->grid[i];
> -   kernel_args[i + 3] = info->grid[i] *
> info->block[i];
> -   kernel_args[i + 6] = info->block[i];
> +   kernel_args[i] = util_cpu_to_le32(info->grid[i]);
> +   kernel_args[i + 3] =
> util_cpu_to_le32(info->grid[i] * info->block[i]);
> +   kernel_args[i + 6] = util_cpu_to_le32(info->block[
> i]);
> }
> }
>
> --
> 2.14.1
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 105918] Mesa 18.0.0-2 video color issues and distorted video with system hang on restart (Apple Mac Pro 6, 1 with AMD D300 GPUs)

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105918

Jonas Platte  changed:

   What|Removed |Added

 CC||jplatte+freedesktop@posteo.
   ||de

--- Comment #1 from Jonas Platte  ---
Created attachment 138706
  --> https://bugs.freedesktop.org/attachment.cgi?id=138706=edit
Screenshot of Konsole with mesa 18.0

I have the same issue on my desktop, using an AMD Radeon RX 460. I attached a
screenshot of what it looks like in Konsole, I have noticed two other parts of
the system are affected too though:

* Window headers in i3-wm (I only have them with tabbed views, but I would
assume the problem affects them when they are drawn in non-tabbed views too)
* Popovers in Firefox

Not sure if this helps at all, but while Konsole breaks completely,
gnome-terminal works without any issues (as do other Gtk3 programs).

I also tried to re-enable `amdgu.dc` on the kernel command line (I have it
disabled due to screen flickering when using redshift), which didn't help.

For now I have downgraded to mesa 17.3.

-- 
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 105464] Reading per-patch outputs in Tessellation Control Shader returns undefined values

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105464

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #8 from Samuel Pitoiset  ---
Should be fixed with SVN r329591.

-- 
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] spirv: autotools: add vtn_gather_types_c.py in distribution tarball

2018-04-09 Thread Emil Velikov
On 9 April 2018 at 15:58, Juan A. Suarez Romero  wrote:
> Fixes: 042ee4bea2 "(spirv: Move SPIR-V building to Makefile.spirv.am and
> spirv/meson.build")
This and the radeonsi patch are
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] etnaviv: meson: add etnaviv_query_pm.[ch] to the sources

2018-04-09 Thread Christian Gmeiner
Emil you are only minutes faster then me :) Will push this change in
some minutes.

2018-04-09 18:57 GMT+02:00 Emil Velikov :
> From: Emil Velikov 
>
> Otherwise building the driver will fail with unresolved symbols.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105960
> Fixes: 72d2043be06 ("etnaviv: add perfmon query implementation")
> Cc: Christian Gmeiner 
> Cc: Clayton Craft 
> Signed-off-by: Emil Velikov 

Reviewed-by: Christian Gmeiner 

> ---
>  src/gallium/drivers/etnaviv/meson.build | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/drivers/etnaviv/meson.build 
> b/src/gallium/drivers/etnaviv/meson.build
> index 2d091fbcbc..48e99d28c8 100644
> --- a/src/gallium/drivers/etnaviv/meson.build
> +++ b/src/gallium/drivers/etnaviv/meson.build
> @@ -54,6 +54,8 @@ files_etnaviv = files(
>'etnaviv_query_hw.h',
>'etnaviv_query_sw.c',
>'etnaviv_query_sw.h',
> +  'etnaviv_query_pm.c',
> +  'etnaviv_query_pm.h',
>'etnaviv_rasterizer.c',
>'etnaviv_rasterizer.h',
>'etnaviv_resource.c',
> --
> 2.16.0
>



-- 
greets
--
Christian Gmeiner, MSc

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


[Mesa-dev] [Bug 105960] [bisected] meson build test fails with: undefined reference to `etna_pm_create_query'

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105960

--- Comment #2 from Emil Velikov  ---
https://patchwork.freedesktop.org/patch/215989/
should fix it

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


[Mesa-dev] [PATCH] etnaviv: meson: add etnaviv_query_pm.[ch] to the sources

2018-04-09 Thread Emil Velikov
From: Emil Velikov 

Otherwise building the driver will fail with unresolved symbols.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105960
Fixes: 72d2043be06 ("etnaviv: add perfmon query implementation")
Cc: Christian Gmeiner 
Cc: Clayton Craft 
Signed-off-by: Emil Velikov 
---
 src/gallium/drivers/etnaviv/meson.build | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/meson.build 
b/src/gallium/drivers/etnaviv/meson.build
index 2d091fbcbc..48e99d28c8 100644
--- a/src/gallium/drivers/etnaviv/meson.build
+++ b/src/gallium/drivers/etnaviv/meson.build
@@ -54,6 +54,8 @@ files_etnaviv = files(
   'etnaviv_query_hw.h',
   'etnaviv_query_sw.c',
   'etnaviv_query_sw.h',
+  'etnaviv_query_pm.c',
+  'etnaviv_query_pm.h',
   'etnaviv_rasterizer.c',
   'etnaviv_rasterizer.h',
   'etnaviv_resource.c',
-- 
2.16.0

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


[Mesa-dev] [Bug 105960] [bisected] meson build test fails with: undefined reference to `etna_pm_create_query'

2018-04-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105960

Christian Gmeiner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Christian Gmeiner  ---
Issue got added with:

commit 72d2043be06c4b0135177482ae95aa321286cc17
Author: Christian Gmeiner 
Date:   Sun Mar 25 22:29:56 2018 +0200

etnaviv: add perfmon query implementation

Add needed infrastructure to use performance monitor
requests for queries.

Signed-off-by: Christian Gmeiner 
Tested-by: Chris Healy 

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


[Mesa-dev] [PATCH 18/22] st/va: add VP9 config to enable profile0

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/config.c | 2 +-
 src/gallium/state_trackers/va/va_private.h | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 7bc031a1a2..ca0183398a 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -52,7 +52,7 @@ vlVaQueryConfigProfiles(VADriverContextP ctx, VAProfile 
*profile_list, int *num_
*num_profiles = 0;
 
pscreen = VL_VA_PSCREEN(ctx);
-   for (p = PIPE_VIDEO_PROFILE_MPEG2_SIMPLE; p <= 
PIPE_VIDEO_PROFILE_JPEG_BASELINE; ++p) {
+   for (p = PIPE_VIDEO_PROFILE_MPEG2_SIMPLE; p <= 
PIPE_VIDEO_PROFILE_VP9_PROFILE0; ++p) {
   if (u_reduce_video_profile(p) == PIPE_VIDEO_FORMAT_MPEG4 && 
!debug_get_option_mpeg4())
  continue;
 
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index c82fec3d5f..b5e6cc6638 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -172,6 +172,8 @@ PipeToProfile(enum pipe_video_profile profile)
   return VAProfileHEVCMain10;
case PIPE_VIDEO_PROFILE_JPEG_BASELINE:
   return VAProfileJPEGBaseline;
+   case PIPE_VIDEO_PROFILE_VP9_PROFILE0:
+  return VAProfileVP9Profile0;
case PIPE_VIDEO_PROFILE_MPEG4_AVC_EXTENDED:
case PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH10:
case PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH422:
@@ -218,6 +220,8 @@ ProfileToPipe(VAProfile profile)
   return PIPE_VIDEO_PROFILE_HEVC_MAIN_10;
case VAProfileJPEGBaseline:
   return PIPE_VIDEO_PROFILE_JPEG_BASELINE;
+   case VAProfileVP9Profile0:
+  return PIPE_VIDEO_PROFILE_VP9_PROFILE0;
case VAProfileNone:
return PIPE_VIDEO_PROFILE_UNKNOWN;
default:
-- 
2.14.1

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


[Mesa-dev] [PATCH 21/22] radeonsi: use PIPE_FORMAT_P016 format for VP9 profile2

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeonsi/si_get.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_get.c 
b/src/gallium/drivers/radeonsi/si_get.c
index 4483ca766d..c8aacfe182 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -662,7 +662,8 @@ static int si_get_video_param(struct pipe_screen *screen,
case PIPE_VIDEO_CAP_MAX_HEIGHT:
return (sscreen->info.family < CHIP_TONGA) ? 1152 : 4096;
case PIPE_VIDEO_CAP_PREFERED_FORMAT:
-   if (profile == PIPE_VIDEO_PROFILE_HEVC_MAIN_10)
+   if (profile == PIPE_VIDEO_PROFILE_HEVC_MAIN_10 ||
+   profile == PIPE_VIDEO_PROFILE_VP9_PROFILE2)
return PIPE_FORMAT_P016;
else
return PIPE_FORMAT_NV12;
-- 
2.14.1

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


[Mesa-dev] [PATCH 12/22] radeonsi: cap VP9 support to progressive buffer

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeonsi/si_get.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_get.c 
b/src/gallium/drivers/radeonsi/si_get.c
index 761ca6f4cd..4483ca766d 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -675,6 +675,8 @@ static int si_get_video_param(struct pipe_screen *screen,
return false; //The firmware doesn't support interlaced 
HEVC.
else if (format == PIPE_VIDEO_FORMAT_JPEG)
return false;
+   else if (format == PIPE_VIDEO_FORMAT_VP9)
+   return false;
return true;
}
case PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE:
-- 
2.14.1

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


[Mesa-dev] [PATCH 14/22] st/va: add handles for VP9 buffers

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/Makefile.sources |  1 +
 src/gallium/state_trackers/va/meson.build  |  4 +--
 src/gallium/state_trackers/va/picture.c| 11 
 src/gallium/state_trackers/va/picture_vp9.c| 38 ++
 src/gallium/state_trackers/va/va_private.h |  2 ++
 5 files changed, 54 insertions(+), 2 deletions(-)
 create mode 100644 src/gallium/state_trackers/va/picture_vp9.c

diff --git a/src/gallium/state_trackers/va/Makefile.sources 
b/src/gallium/state_trackers/va/Makefile.sources
index f3a13f2081..bd43100a87 100644
--- a/src/gallium/state_trackers/va/Makefile.sources
+++ b/src/gallium/state_trackers/va/Makefile.sources
@@ -13,6 +13,7 @@ C_SOURCES := \
picture_hevc_enc.c \
picture_vc1.c \
picture_mjpeg.c \
+   picture_vp9.c \
postproc.c \
subpicture.c \
surface.c \
diff --git a/src/gallium/state_trackers/va/meson.build 
b/src/gallium/state_trackers/va/meson.build
index deb1127483..eb1491ce45 100644
--- a/src/gallium/state_trackers/va/meson.build
+++ b/src/gallium/state_trackers/va/meson.build
@@ -25,8 +25,8 @@ libva_st = static_library(
   files(
 'buffer.c', 'config.c', 'context.c', 'display.c', 'image.c', 'picture.c',
 'picture_mpeg12.c', 'picture_mpeg4.c', 'picture_h264.c', 'picture_hevc.c',
-'picture_vc1.c', 'picture_mjpeg.c', 'postproc.c', 'subpicture.c',
-'surface.c', 'picture_h264_enc.c', 'picture_hevc_enc.c',
+'picture_vc1.c', 'picture_mjpeg.c', 'picture_vp9.c','postproc.c',
+'subpicture.c', 'surface.c', 'picture_h264_enc.c', 'picture_hevc_enc.c',
   ),
   c_args : [
 c_vis_args,
diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index f2e9ba8ef6..e483ea3e21 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -134,6 +134,10 @@ handlePictureParameterBuffer(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *
   vlVaHandlePictureParameterBufferMJPEG(drv, context, buf);
   break;
 
+  case PIPE_VIDEO_FORMAT_VP9:
+  vlVaHandlePictureParameterBufferVP9(drv, context, buf);
+  break;
+
default:
   break;
}
@@ -223,6 +227,10 @@ handleSliceParameterBuffer(vlVaContext *context, 
vlVaBuffer *buf)
   vlVaHandleSliceParameterBufferMJPEG(context, buf);
   break;
 
+   case PIPE_VIDEO_FORMAT_VP9:
+  vlVaHandleSliceParameterBufferVP9(context, buf);
+  break;
+
default:
   break;
}
@@ -294,6 +302,9 @@ handleVASliceDataBufferType(vlVaContext *context, 
vlVaBuffer *buf)
   break;
case PIPE_VIDEO_FORMAT_JPEG:
   break;
+   case PIPE_VIDEO_FORMAT_VP9:
+  /* TODO */
+  break;
default:
   break;
}
diff --git a/src/gallium/state_trackers/va/picture_vp9.c 
b/src/gallium/state_trackers/va/picture_vp9.c
new file mode 100644
index 00..62350692c5
--- /dev/null
+++ b/src/gallium/state_trackers/va/picture_vp9.c
@@ -0,0 +1,38 @@
+/**
+ *
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include "va_private.h"
+
+void vlVaHandlePictureParameterBufferVP9(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf)
+{
+   /* TODO */
+}
+
+void vlVaHandleSliceParameterBufferVP9(vlVaContext *context, vlVaBuffer *buf)
+{
+   /* TODO */
+}
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 7c38747860..ef9142876c 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -429,6 +429,8 @@ void vlVaHandlePictureParameterBufferMJPEG(vlVaDriver *drv, 
vlVaContext *context
 void 

[Mesa-dev] [PATCH 22/22] st/va: add VP9 config to enable profile2

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/config.c | 2 +-
 src/gallium/state_trackers/va/va_private.h | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index ca0183398a..5becc49ce6 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -52,7 +52,7 @@ vlVaQueryConfigProfiles(VADriverContextP ctx, VAProfile 
*profile_list, int *num_
*num_profiles = 0;
 
pscreen = VL_VA_PSCREEN(ctx);
-   for (p = PIPE_VIDEO_PROFILE_MPEG2_SIMPLE; p <= 
PIPE_VIDEO_PROFILE_VP9_PROFILE0; ++p) {
+   for (p = PIPE_VIDEO_PROFILE_MPEG2_SIMPLE; p <= 
PIPE_VIDEO_PROFILE_VP9_PROFILE2; ++p) {
   if (u_reduce_video_profile(p) == PIPE_VIDEO_FORMAT_MPEG4 && 
!debug_get_option_mpeg4())
  continue;
 
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index b5e6cc6638..b19b66d2aa 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -174,6 +174,8 @@ PipeToProfile(enum pipe_video_profile profile)
   return VAProfileJPEGBaseline;
case PIPE_VIDEO_PROFILE_VP9_PROFILE0:
   return VAProfileVP9Profile0;
+   case PIPE_VIDEO_PROFILE_VP9_PROFILE2:
+  return VAProfileVP9Profile2;
case PIPE_VIDEO_PROFILE_MPEG4_AVC_EXTENDED:
case PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH10:
case PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH422:
@@ -222,6 +224,8 @@ ProfileToPipe(VAProfile profile)
   return PIPE_VIDEO_PROFILE_JPEG_BASELINE;
case VAProfileVP9Profile0:
   return PIPE_VIDEO_PROFILE_VP9_PROFILE0;
+   case VAProfileVP9Profile2:
+  return PIPE_VIDEO_PROFILE_VP9_PROFILE2;
case VAProfileNone:
return PIPE_VIDEO_PROFILE_UNKNOWN;
default:
-- 
2.14.1

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


[Mesa-dev] [PATCH 16/22] st/va: add slice parameter handling for VP9

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/picture_vp9.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_vp9.c 
b/src/gallium/state_trackers/va/picture_vp9.c
index d333a0cbcd..38684ca21e 100644
--- a/src/gallium/state_trackers/va/picture_vp9.c
+++ b/src/gallium/state_trackers/va/picture_vp9.c
@@ -84,5 +84,28 @@ void vlVaHandlePictureParameterBufferVP9(vlVaDriver *drv, 
vlVaContext *context,
 
 void vlVaHandleSliceParameterBufferVP9(vlVaContext *context, vlVaBuffer *buf)
 {
-   /* TODO */
+   VASliceParameterBufferVP9 *vp9 = buf->data;
+   int i;
+
+   assert(buf->size >= sizeof(VASliceParameterBufferVP9) && buf->num_elements 
== 1);
+
+   context->desc.vp9.slice_parameter.slice_data_size = vp9->slice_data_size;
+   context->desc.vp9.slice_parameter.slice_data_offset = 
vp9->slice_data_offset;
+   context->desc.vp9.slice_parameter.slice_data_flag = vp9->slice_data_flag;
+
+   for (i = 0; i < 8; ++i) {
+  
context->desc.vp9.slice_parameter.seg_param[i].segment_flags.segment_reference_enabled
 =
+ vp9->seg_param[i].segment_flags.fields.segment_reference_enabled;
+  
context->desc.vp9.slice_parameter.seg_param[i].segment_flags.segment_reference =
+ vp9->seg_param[i].segment_flags.fields.segment_reference;
+  
context->desc.vp9.slice_parameter.seg_param[i].segment_flags.segment_reference_skipped
 =
+ vp9->seg_param[i].segment_flags.fields.segment_reference_skipped;
+
+  memcpy(context->desc.vp9.slice_parameter.seg_param[i].filter_level, 
vp9->seg_param[i].filter_level, 4 * 2);
+
+  context->desc.vp9.slice_parameter.seg_param[i].luma_ac_quant_scale = 
vp9->seg_param[i].luma_ac_quant_scale;
+  context->desc.vp9.slice_parameter.seg_param[i].luma_dc_quant_scale = 
vp9->seg_param[i].luma_dc_quant_scale;
+  context->desc.vp9.slice_parameter.seg_param[i].chroma_ac_quant_scale = 
vp9->seg_param[i].chroma_ac_quant_scale;
+  context->desc.vp9.slice_parameter.seg_param[i].chroma_dc_quant_scale = 
vp9->seg_param[i].chroma_dc_quant_scale;
+   }
 }
-- 
2.14.1

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


[Mesa-dev] [PATCH 15/22] st/va: add picture parameter handling for VP9

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/picture_vp9.c | 52 -
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_vp9.c 
b/src/gallium/state_trackers/va/picture_vp9.c
index 62350692c5..d333a0cbcd 100644
--- a/src/gallium/state_trackers/va/picture_vp9.c
+++ b/src/gallium/state_trackers/va/picture_vp9.c
@@ -29,7 +29,57 @@
 
 void vlVaHandlePictureParameterBufferVP9(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf)
 {
-   /* TODO */
+   VADecPictureParameterBufferVP9 *vp9 = buf->data;
+   int i;
+
+   assert(buf->size >= sizeof(VADecPictureParameterBufferVP9) && 
buf->num_elements == 1);
+
+   context->desc.vp9.picture_parameter.frame_width = vp9->frame_width;
+   context->desc.vp9.picture_parameter.frame_height = vp9->frame_height;
+
+   context->desc.vp9.picture_parameter.pic_fields.subsampling_x = 
vp9->pic_fields.bits.subsampling_x;
+   context->desc.vp9.picture_parameter.pic_fields.subsampling_y = 
vp9->pic_fields.bits.subsampling_y;
+   context->desc.vp9.picture_parameter.pic_fields.frame_type = 
vp9->pic_fields.bits.frame_type;
+   context->desc.vp9.picture_parameter.pic_fields.show_frame = 
vp9->pic_fields.bits.show_frame;
+   context->desc.vp9.picture_parameter.pic_fields.error_resilient_mode = 
vp9->pic_fields.bits.error_resilient_mode;
+   context->desc.vp9.picture_parameter.pic_fields.intra_only = 
vp9->pic_fields.bits.intra_only;
+   context->desc.vp9.picture_parameter.pic_fields.allow_high_precision_mv = 
vp9->pic_fields.bits.allow_high_precision_mv;
+   context->desc.vp9.picture_parameter.pic_fields.mcomp_filter_type = 
vp9->pic_fields.bits.mcomp_filter_type;
+   context->desc.vp9.picture_parameter.pic_fields.frame_parallel_decoding_mode 
= vp9->pic_fields.bits.frame_parallel_decoding_mode;
+   context->desc.vp9.picture_parameter.pic_fields.reset_frame_context = 
vp9->pic_fields.bits.reset_frame_context;
+   context->desc.vp9.picture_parameter.pic_fields.refresh_frame_context = 
vp9->pic_fields.bits.refresh_frame_context;
+   context->desc.vp9.picture_parameter.pic_fields.frame_context_idx = 
vp9->pic_fields.bits.frame_context_idx;
+   context->desc.vp9.picture_parameter.pic_fields.segmentation_enabled = 
vp9->pic_fields.bits.segmentation_enabled;
+   context->desc.vp9.picture_parameter.pic_fields.segmentation_temporal_update 
= vp9->pic_fields.bits.segmentation_temporal_update;
+   context->desc.vp9.picture_parameter.pic_fields.segmentation_update_map = 
vp9->pic_fields.bits.segmentation_update_map;
+   context->desc.vp9.picture_parameter.pic_fields.last_ref_frame = 
vp9->pic_fields.bits.last_ref_frame;
+   context->desc.vp9.picture_parameter.pic_fields.last_ref_frame_sign_bias = 
vp9->pic_fields.bits.last_ref_frame_sign_bias;
+   context->desc.vp9.picture_parameter.pic_fields.golden_ref_frame = 
vp9->pic_fields.bits.golden_ref_frame;
+   context->desc.vp9.picture_parameter.pic_fields.golden_ref_frame_sign_bias = 
vp9->pic_fields.bits.golden_ref_frame_sign_bias;
+   context->desc.vp9.picture_parameter.pic_fields.alt_ref_frame = 
vp9->pic_fields.bits.alt_ref_frame;
+   context->desc.vp9.picture_parameter.pic_fields.alt_ref_frame_sign_bias = 
vp9->pic_fields.bits.alt_ref_frame_sign_bias;
+   context->desc.vp9.picture_parameter.pic_fields.lossless_flag = 
vp9->pic_fields.bits.lossless_flag;
+
+   context->desc.vp9.picture_parameter.filter_level = vp9->filter_level;
+   context->desc.vp9.picture_parameter.sharpness_level = vp9->sharpness_level;
+
+   context->desc.vp9.picture_parameter.log2_tile_rows = vp9->log2_tile_rows;
+   context->desc.vp9.picture_parameter.log2_tile_columns = 
vp9->log2_tile_columns;
+
+   context->desc.vp9.picture_parameter.frame_header_length_in_bytes = 
vp9->frame_header_length_in_bytes;
+   context->desc.vp9.picture_parameter.first_partition_size = 
vp9->first_partition_size;
+
+   for (i = 0; i < 7; ++i)
+  context->desc.vp9.picture_parameter.mb_segment_tree_probs[i] = 
vp9->mb_segment_tree_probs[i];
+   for (i = 0; i < 3; ++i)
+  context->desc.vp9.picture_parameter.segment_pred_probs[i] = 
vp9->segment_pred_probs[i];
+
+   context->desc.vp9.picture_parameter.profile = vp9->profile;
+
+   context->desc.vp9.picture_parameter.bit_depth = vp9->bit_depth;
+
+   for (i = 0 ; i < 8 ; i++)
+  vlVaGetReferenceFrame(drv, vp9->reference_frames[i], 
>desc.vp9.ref[i]);
 }
 
 void vlVaHandleSliceParameterBufferVP9(vlVaContext *context, vlVaBuffer *buf)
-- 
2.14.1

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


[Mesa-dev] [PATCH 19/22] vl: add VP9 profile2 support

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/auxiliary/util/u_video.h | 1 +
 src/gallium/include/pipe/p_video_enums.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/util/u_video.h 
b/src/gallium/auxiliary/util/u_video.h
index d313497a63..967ebc5748 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -80,6 +80,7 @@ u_reduce_video_profile(enum pipe_video_profile profile)
  return PIPE_VIDEO_FORMAT_JPEG;
 
   case PIPE_VIDEO_PROFILE_VP9_PROFILE0:
+  case PIPE_VIDEO_PROFILE_VP9_PROFILE2:
  return PIPE_VIDEO_FORMAT_VP9;
 
   default:
diff --git a/src/gallium/include/pipe/p_video_enums.h 
b/src/gallium/include/pipe/p_video_enums.h
index c20bc48e3d..b5b8b06228 100644
--- a/src/gallium/include/pipe/p_video_enums.h
+++ b/src/gallium/include/pipe/p_video_enums.h
@@ -69,7 +69,8 @@ enum pipe_video_profile
PIPE_VIDEO_PROFILE_HEVC_MAIN_12,
PIPE_VIDEO_PROFILE_HEVC_MAIN_444,
PIPE_VIDEO_PROFILE_JPEG_BASELINE,
-   PIPE_VIDEO_PROFILE_VP9_PROFILE0
+   PIPE_VIDEO_PROFILE_VP9_PROFILE0,
+   PIPE_VIDEO_PROFILE_VP9_PROFILE2
 };
 
 /* Video caps, can be different for each codec/profile */
-- 
2.14.1

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


[Mesa-dev] [PATCH 20/22] radeon/vcn: add VP9 profile2 support

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeon/radeon_vcn_dec.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c 
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index b4cfba1713..046b371384 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -549,6 +549,17 @@ static rvcn_dec_message_vp9_t get_vp9_msg(struct 
radeon_decoder *dec,
result.frame_refs[2] = 
result.ref_frame_map[pic->picture_parameter.pic_fields.alt_ref_frame];
result.ref_frame_sign_bias[2] = 
pic->picture_parameter.pic_fields.alt_ref_frame_sign_bias;
 
+   if (pic->base.profile == PIPE_VIDEO_PROFILE_VP9_PROFILE2) {
+   if (target->buffer_format == PIPE_FORMAT_P016) {
+   result.p010_mode = 1;
+   result.msb_mode = 1;
+   } else {
+   result.p010_mode = 0;
+   result.luma_10to8 = 1;
+   result.chroma_10to8 = 1;
+   }
+   }
+
return result;
 }
 
@@ -953,6 +964,9 @@ static struct pb_buffer *rvcn_dec_message_decode(struct 
radeon_decoder *dec,
/* SDB left tile pixel */
ctx_size += 8 * 2 * 4096;
 
+   if (dec->base.profile == 
PIPE_VIDEO_PROFILE_VP9_PROFILE2)
+   ctx_size += 8 * 2 * 4096;
+
if (!si_vid_create_buffer(dec->screen, >ctx, 
ctx_size, PIPE_USAGE_DEFAULT))
RVID_ERR("Can't allocated context buffer.\n");
si_vid_clear_buffer(dec->base.context, >ctx);
@@ -1260,6 +1274,8 @@ static unsigned calc_dpb_size(struct radeon_decoder *dec)
max_references = MAX2(max_references, 9);
 
dpb_size = (4096 * 3000 * 3 / 2) * max_references;
+   if (dec->base.profile == PIPE_VIDEO_PROFILE_VP9_PROFILE2)
+   dpb_size *= (3 / 2);
break;
 
default:
-- 
2.14.1

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


[Mesa-dev] [PATCH 17/22] st/va: parse VP9 uncompressed frame header

2018-04-09 Thread Leo Liu
To get some of UVD required parameters.

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/picture.c |   2 +-
 src/gallium/state_trackers/va/picture_vp9.c | 237 
 src/gallium/state_trackers/va/va_private.h  |   1 +
 3 files changed, 239 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index e483ea3e21..e2cdb2b40c 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -303,7 +303,7 @@ handleVASliceDataBufferType(vlVaContext *context, 
vlVaBuffer *buf)
case PIPE_VIDEO_FORMAT_JPEG:
   break;
case PIPE_VIDEO_FORMAT_VP9:
-  /* TODO */
+  vlVaDecoderVP9BitstreamHeader(context, buf);
   break;
default:
   break;
diff --git a/src/gallium/state_trackers/va/picture_vp9.c 
b/src/gallium/state_trackers/va/picture_vp9.c
index 38684ca21e..c1ca54cd00 100644
--- a/src/gallium/state_trackers/va/picture_vp9.c
+++ b/src/gallium/state_trackers/va/picture_vp9.c
@@ -25,6 +25,7 @@
  *
  **/
 
+#include "vl/vl_vlc.h"
 #include "va_private.h"
 
 void vlVaHandlePictureParameterBufferVP9(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf)
@@ -109,3 +110,239 @@ void vlVaHandleSliceParameterBufferVP9(vlVaContext 
*context, vlVaBuffer *buf)
   context->desc.vp9.slice_parameter.seg_param[i].chroma_dc_quant_scale = 
vp9->seg_param[i].chroma_dc_quant_scale;
}
 }
+
+static unsigned vp9_u(struct vl_vlc *vlc, unsigned n)
+{
+   unsigned valid = vl_vlc_valid_bits(vlc);
+
+   if (n == 0)
+  return 0;
+
+   if (valid < 32)
+  vl_vlc_fillbits(vlc);
+
+   return vl_vlc_get_uimsbf(vlc, n);
+}
+
+static signed vp9_s(struct vl_vlc *vlc, unsigned n)
+{
+   unsigned v;
+   bool s;
+
+   v = vp9_u(vlc, n);
+   s = vp9_u(vlc, 1);
+
+   return s ? -v : v;
+}
+
+static void bitdepth_colorspace_sampling(struct vl_vlc *vlc, unsigned profile)
+{
+   unsigned cs;
+
+   if (profile == 2)
+  /* bit_depth */
+  vp9_u(vlc, 1);
+
+   cs = vp9_u(vlc, 3);
+   if (cs != 7)
+  /* yuv_range_flag */
+  vp9_u(vlc, 1);
+}
+
+static void frame_size(struct vl_vlc *vlc)
+{
+  /* width_minus_one */
+  vp9_u(vlc, 16);
+  /* height_minus_one */
+  vp9_u(vlc, 16);
+
+  /* has_scaling */
+  if (vp9_u(vlc, 1)) {
+ /* render_width_minus_one */
+ vp9_u(vlc, 16);
+ /* render_height_minus_one */
+ vp9_u(vlc, 16);
+  }
+}
+
+void vlVaDecoderVP9BitstreamHeader(vlVaContext *context, vlVaBuffer *buf)
+{
+   struct vl_vlc vlc;
+   unsigned profile;
+   bool frame_type, show_frame, error_resilient_mode;
+   bool mode_ref_delta_enabled, mode_ref_delta_update = false;
+   int i;
+
+   vl_vlc_init(, 1, (const void * const*)>data,
+  (const unsigned 
*)>desc.vp9.picture_parameter.frame_header_length_in_bytes);
+
+   /* frame_marker */
+   if (vp9_u(, 2) != 0x2)
+  return;
+
+   profile = vp9_u(, 1) | vp9_u(, 1) << 1;
+
+   if (profile == 3)
+  profile += vp9_u(, 1);
+
+   if (profile != 0 && profile != 2)
+  return;
+
+   /* show_existing_frame */
+   if (vp9_u(, 1))
+  return;
+
+   frame_type = vp9_u(, 1);
+   show_frame = vp9_u(, 1);
+   error_resilient_mode = vp9_u(, 1);
+
+   if (frame_type == 0) {
+  /* sync_code */
+  if (vp9_u(, 24) != 0x498342)
+ return;
+
+  bitdepth_colorspace_sampling(, profile);
+  frame_size();
+   } else {
+  bool intra_only, size_in_refs = false;
+
+  intra_only = show_frame ? 0 : vp9_u(, 1);
+  if (!error_resilient_mode)
+ /* reset_frame_context */
+ vp9_u(, 2);
+
+  if (intra_only) {
+ /* sync_code */
+ if (vp9_u(, 24) != 0x498342)
+return;
+
+ bitdepth_colorspace_sampling(, profile);
+ /* refresh_frame_flags */
+ vp9_u(, 8);
+ frame_size();
+  } else {
+ /* refresh_frame_flags */
+ vp9_u(, 8);
+
+ for (i = 0; i < 3; ++i) {
+/* frame refs */
+vp9_u(, 3);
+vp9_u(, 1);
+ }
+
+ for (i = 0; i < 3; ++i) {
+size_in_refs = vp9_u(, 1);
+if (size_in_refs)
+   break;
+ }
+
+ if (!size_in_refs) {
+/* width/height_minus_one */
+vp9_u(, 16);
+vp9_u(, 16);
+ }
+
+ if (vp9_u(, 1)) {
+/* render_width/height_minus_one */
+vp9_u(, 16);
+vp9_u(, 16);
+ }
+
+ /* high_precision_mv */
+ vp9_u(, 1);
+ /* filter_switchable */
+ if (!vp9_u(, 1))
+/* filter_index */
+vp9_u(, 2);
+  }
+   }
+   if (!error_resilient_mode) {
+  /* refresh_frame_context */
+  vp9_u(, 1);
+  /* frame_parallel_decoding_mode */
+  vp9_u(, 1);
+   }
+   /* frame_context_index */
+   vp9_u(, 2);
+
+   

[Mesa-dev] [PATCH 13/22] st/va: add VP9 picture to context

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/context.c| 4 
 src/gallium/state_trackers/va/va_private.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 836aa77c36..14e904ee49 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -288,6 +288,10 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
  }
  break;
 
+  case PIPE_VIDEO_FORMAT_VP9:
+ context->templat.max_references = num_render_targets;
+ break;
+
   default:
  break;
   }
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 4396abb586..7c38747860 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -270,6 +270,7 @@ typedef struct {
   struct pipe_h264_picture_desc h264;
   struct pipe_h265_picture_desc h265;
   struct pipe_mjpeg_picture_desc mjpeg;
+  struct pipe_vp9_picture_desc vp9;
   struct pipe_h264_enc_picture_desc h264enc;
   struct pipe_h265_enc_picture_desc h265enc;
} desc;
-- 
2.14.1

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


[Mesa-dev] [PATCH 08/22] radeon/vcn: fill probability table to prob buffers

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeon/radeon_vcn_dec.c | 38 +
 1 file changed, 38 insertions(+)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c 
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index b29ba37b3c..bcfdd33d31 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -38,6 +38,7 @@
 #include "radeonsi/si_pipe.h"
 #include "radeon_video.h"
 #include "radeon_vcn_dec.h"
+#include "vl/vl_probs_table.h"
 
 #define FB_BUFFER_OFFSET   0x1000
 #define FB_BUFFER_SIZE 2048
@@ -360,6 +361,32 @@ static rvcn_dec_message_hevc_t get_h265_msg(struct 
radeon_decoder *dec,
return result;
 }
 
+static void fill_probs_table(void *ptr)
+{
+   rvcn_dec_vp9_probs_t *probs = (rvcn_dec_vp9_probs_t *)ptr;
+
+   memcpy(>coef_probs[0], default_coef_probs_4x4, 
sizeof(default_coef_probs_4x4));
+   memcpy(>coef_probs[1], default_coef_probs_8x8, 
sizeof(default_coef_probs_8x8));
+   memcpy(>coef_probs[2], default_coef_probs_16x16, 
sizeof(default_coef_probs_16x16));
+   memcpy(>coef_probs[3], default_coef_probs_32x32, 
sizeof(default_coef_probs_32x32));
+   memcpy(probs->y_mode_prob, default_if_y_probs, 
sizeof(default_if_y_probs));
+   memcpy(probs->uv_mode_prob, default_if_uv_probs, 
sizeof(default_if_uv_probs));
+   memcpy(probs->single_ref_prob, default_single_ref_p, 
sizeof(default_single_ref_p));
+   memcpy(probs->switchable_interp_prob, default_switchable_interp_prob, 
sizeof(default_switchable_interp_prob));
+   memcpy(probs->partition_prob, default_partition_probs, 
sizeof(default_partition_probs));
+   memcpy(probs->inter_mode_probs, default_inter_mode_probs, 
sizeof(default_inter_mode_probs));
+   memcpy(probs->mbskip_probs, default_skip_probs, 
sizeof(default_skip_probs));
+   memcpy(probs->intra_inter_prob, default_intra_inter_p, 
sizeof(default_intra_inter_p));
+   memcpy(probs->comp_inter_prob, default_comp_inter_p, 
sizeof(default_comp_inter_p));
+   memcpy(probs->comp_ref_prob, default_comp_ref_p, 
sizeof(default_comp_ref_p));
+   memcpy(probs->tx_probs_32x32, default_tx_probs_32x32, 
sizeof(default_tx_probs_32x32));
+   memcpy(probs->tx_probs_16x16, default_tx_probs_16x16, 
sizeof(default_tx_probs_16x16));
+   memcpy(probs->tx_probs_8x8, default_tx_probs_8x8, 
sizeof(default_tx_probs_8x8));
+   memcpy(probs->mv_joints, default_nmv_joints, 
sizeof(default_nmv_joints));
+   memcpy(>mv_comps[0], default_nmv_components, 
sizeof(default_nmv_components));
+   memset(>nmvc_mask, 0, sizeof(rvcn_dec_vp9_nmv_ctx_mask_t));
+}
+
 static unsigned calc_ctx_size_h265_main(struct radeon_decoder *dec)
 {
unsigned width = align(dec->base.width, VL_MACROBLOCK_WIDTH);
@@ -1306,6 +1333,17 @@ struct pipe_video_codec *radeon_create_decoder(struct 
pipe_context *context,
 
si_vid_clear_buffer(context, >msg_fb_it_probs_buffers[i]);
si_vid_clear_buffer(context, >bs_buffers[i]);
+
+   if (have_probs(dec)) {
+   struct rvid_buffer* buf;
+   void *ptr;
+
+   buf = >msg_fb_it_probs_buffers[i];
+   ptr = dec->ws->buffer_map(buf->res->buf, dec->cs, 
PIPE_TRANSFER_WRITE);
+   ptr += FB_BUFFER_OFFSET + FB_BUFFER_SIZE;
+   fill_probs_table(ptr);
+   dec->ws->buffer_unmap(buf->res->buf);
+   }
}
 
dpb_size = calc_dpb_size(dec);
-- 
2.14.1

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


[Mesa-dev] [PATCH 09/22] radeon/vcn: get VP9 msg buffer

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeon/radeon_vcn_dec.c | 176 +++-
 src/gallium/drivers/radeon/radeon_vcn_dec.h |   1 +
 2 files changed, 176 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c 
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index bcfdd33d31..170cc3fa41 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -55,6 +55,7 @@
 #define NUM_MPEG2_REFS 6
 #define NUM_H264_REFS  17
 #define NUM_VC1_REFS   5
+#define NUM_VP9_REFS   8
 
 struct radeon_decoder {
struct pipe_video_codec base;
@@ -82,6 +83,8 @@ struct radeon_decoder {
unsignedbs_size;
unsignedcur_buffer;
void*render_pic_list[16];
+   boolshow_frame;
+   unsignedref_idx;
 };
 
 static rvcn_dec_message_avc_t get_h264_msg(struct radeon_decoder *dec,
@@ -387,6 +390,168 @@ static void fill_probs_table(void *ptr)
memset(>nmvc_mask, 0, sizeof(rvcn_dec_vp9_nmv_ctx_mask_t));
 }
 
+static rvcn_dec_message_vp9_t get_vp9_msg(struct radeon_decoder *dec,
+   struct pipe_video_buffer *target,
+   struct pipe_vp9_picture_desc *pic)
+{
+   rvcn_dec_message_vp9_t result;
+   unsigned i;
+
+   memset(, 0, sizeof(result));
+
+   /* segment table */
+   rvcn_dec_vp9_probs_segment_t *prbs = (rvcn_dec_vp9_probs_segment_t 
*)(dec->probs);
+
+   if (pic->picture_parameter.pic_fields.segmentation_enabled) {
+   for (i = 0; i < 8; ++i) {
+   prbs->seg.feature_data[i] =
+   (pic->slice_parameter.seg_param[i].alt_quant & 
0x) |
+   ((pic->slice_parameter.seg_param[i].alt_lf & 
0xff) << 16) |
+   
((pic->slice_parameter.seg_param[i].segment_flags.segment_reference & 0xf) << 
24);
+   prbs->seg.feature_mask[i] =
+   
(pic->slice_parameter.seg_param[i].alt_quant_enabled << 0) |
+   
(pic->slice_parameter.seg_param[i].alt_lf_enabled << 1) |
+   
(pic->slice_parameter.seg_param[i].segment_flags.segment_reference_enabled << 
2) |
+   
(pic->slice_parameter.seg_param[i].segment_flags.segment_reference_skipped << 
3);
+   }
+
+   for (i = 0; i < 7; ++i)
+   prbs->seg.tree_probs[i] = 
pic->picture_parameter.mb_segment_tree_probs[i];
+
+   for (i = 0; i < 3; ++i)
+   prbs->seg.pred_probs[i] = 
pic->picture_parameter.segment_pred_probs[i];
+
+   prbs->seg.abs_delta = 0;
+   } else
+   memset(>seg, 0, 256);
+
+   result.frame_header_flags =
+   (pic->picture_parameter.pic_fields.frame_type <<
+RDECODE_FRAME_HDR_INFO_VP9_FRAME_TYPE_SHIFT) &
+   RDECODE_FRAME_HDR_INFO_VP9_FRAME_TYPE_MASK;
+
+   result.frame_header_flags |=
+   (pic->picture_parameter.pic_fields.error_resilient_mode <<
+RDECODE_FRAME_HDR_INFO_VP9_ERROR_RESILIENT_MODE_SHIFT) &
+   RDECODE_FRAME_HDR_INFO_VP9_ERROR_RESILIENT_MODE_MASK;
+
+   result.frame_header_flags |=
+   (pic->picture_parameter.pic_fields.intra_only <<
+RDECODE_FRAME_HDR_INFO_VP9_INTRA_ONLY_SHIFT) &
+   RDECODE_FRAME_HDR_INFO_VP9_INTRA_ONLY_MASK;
+
+   result.frame_header_flags |=
+   (pic->picture_parameter.pic_fields.allow_high_precision_mv <<
+RDECODE_FRAME_HDR_INFO_VP9_ALLOW_HIGH_PRECISION_MV_SHIFT) &
+   RDECODE_FRAME_HDR_INFO_VP9_ALLOW_HIGH_PRECISION_MV_MASK;
+
+   result.frame_header_flags |=
+   (pic->picture_parameter.pic_fields.frame_parallel_decoding_mode 
<<
+RDECODE_FRAME_HDR_INFO_VP9_FRAME_PARALLEL_DECODING_MODE_SHIFT) 
&
+   RDECODE_FRAME_HDR_INFO_VP9_FRAME_PARALLEL_DECODING_MODE_MASK;
+
+   result.frame_header_flags |=
+   (pic->picture_parameter.pic_fields.refresh_frame_context <<
+RDECODE_FRAME_HDR_INFO_VP9_REFRESH_FRAME_CONTEXT_SHIFT) &
+   RDECODE_FRAME_HDR_INFO_VP9_REFRESH_FRAME_CONTEXT_MASK;
+
+   result.frame_header_flags |=
+   (pic->picture_parameter.pic_fields.segmentation_enabled <<
+RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_ENABLED_SHIFT) &
+   RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_ENABLED_MASK;
+
+   result.frame_header_flags |=
+   (pic->picture_parameter.pic_fields.segmentation_update_map <<
+RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_UPDATE_MAP_SHIFT) 

[Mesa-dev] [PATCH 10/22] radeon/vcn: add VP9 context buffer

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeon/radeon_vcn_dec.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c 
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index 170cc3fa41..b4cfba1713 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -936,6 +936,32 @@ static struct pb_buffer *rvcn_dec_message_decode(struct 
radeon_decoder *dec,
 
memcpy(codec, (void*), sizeof(rvcn_dec_message_vp9_t));
index->message_id = RDECODE_MESSAGE_VP9;
+
+   if (dec->ctx.res == NULL) {
+   unsigned ctx_size;
+   uint8_t *ptr;
+
+   /* default probability + probability data */
+   ctx_size = 2304 * 5;
+
+   /* SRE collocated context data */
+   ctx_size += 32 * 2 * 64 * 64;
+
+   /* SMP collocated context data */
+   ctx_size += 9 * 64 * 2 * 64 * 64;
+
+   /* SDB left tile pixel */
+   ctx_size += 8 * 2 * 4096;
+
+   if (!si_vid_create_buffer(dec->screen, >ctx, 
ctx_size, PIPE_USAGE_DEFAULT))
+   RVID_ERR("Can't allocated context buffer.\n");
+   si_vid_clear_buffer(dec->base.context, >ctx);
+
+   /* ctx needs probs table */
+   ptr = dec->ws->buffer_map(dec->ctx.res->buf, dec->cs, 
PIPE_TRANSFER_WRITE);
+   fill_probs_table(ptr);
+   dec->ws->buffer_unmap(dec->ctx.res->buf);
+   }
break;
}
default:
-- 
2.14.1

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


[Mesa-dev] [PATCH 11/22] radeonsi: cap VP9 support to Raven

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeonsi/si_get.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_get.c 
b/src/gallium/drivers/radeonsi/si_get.c
index 85cfb11338..761ca6f4cd 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -648,6 +648,10 @@ static int si_get_video_param(struct pipe_screen *screen,
return false;
}
return true;
+   case PIPE_VIDEO_FORMAT_VP9:
+   if (sscreen->info.family < CHIP_RAVEN)
+   return false;
+   return true;
default:
return false;
}
-- 
2.14.1

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


[Mesa-dev] [PATCH 07/22] radeon/vcn: add VP9 message buffer interface

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeon/radeon_vcn_dec.h | 134 
 1 file changed, 134 insertions(+)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.h 
b/src/gallium/drivers/radeon/radeon_vcn_dec.h
index 0a8c343e58..3ae04a1087 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.h
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.h
@@ -109,6 +109,37 @@
 
 #define RDECODE_VP9_PROBS_DATA_SIZE2304
 
+/* VP9 Frame header flags */
+#define RDECODE_FRAME_HDR_INFO_VP9_USE_PREV_IN_FIND_MV_REFS_SHIFT  
(13)
+#define RDECODE_FRAME_HDR_INFO_VP9_MODE_REF_DELTA_UPDATE_SHIFT 
(12)
+#define RDECODE_FRAME_HDR_INFO_VP9_MODE_REF_DELTA_ENABLED_SHIFT
(11)
+#define RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_UPDATE_DATA_SHIFT  
(10)
+#define RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_TEMPORAL_UPDATE_SHIFT  
 (9)
+#define RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_UPDATE_MAP_SHIFT   
 (8)
+#define RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_ENABLED_SHIFT  
 (7)
+#define RDECODE_FRAME_HDR_INFO_VP9_FRAME_PARALLEL_DECODING_MODE_SHIFT  
 (6)
+#define RDECODE_FRAME_HDR_INFO_VP9_REFRESH_FRAME_CONTEXT_SHIFT 
 (5)
+#define RDECODE_FRAME_HDR_INFO_VP9_ALLOW_HIGH_PRECISION_MV_SHIFT   
 (4)
+#define RDECODE_FRAME_HDR_INFO_VP9_INTRA_ONLY_SHIFT
 (3)
+#define RDECODE_FRAME_HDR_INFO_VP9_ERROR_RESILIENT_MODE_SHIFT  
 (2)
+#define RDECODE_FRAME_HDR_INFO_VP9_FRAME_TYPE_SHIFT
 (1)
+#define RDECODE_FRAME_HDR_INFO_VP9_SHOW_EXISTING_FRAME_SHIFT   
 (0)
+
+#define RDECODE_FRAME_HDR_INFO_VP9_USE_PREV_IN_FIND_MV_REFS_MASK   
 (0x2000)
+#define RDECODE_FRAME_HDR_INFO_VP9_MODE_REF_DELTA_UPDATE_MASK  
 (0x1000)
+#define RDECODE_FRAME_HDR_INFO_VP9_MODE_REF_DELTA_ENABLED_MASK 
 (0x0800)
+#define RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_UPDATE_DATA_MASK   
 (0x0400)
+#define RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_TEMPORAL_UPDATE_MASK   
 (0x0200)
+#define RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_UPDATE_MAP_MASK
 (0x0100)
+#define RDECODE_FRAME_HDR_INFO_VP9_SEGMENTATION_ENABLED_MASK   
 (0x0080)
+#define RDECODE_FRAME_HDR_INFO_VP9_FRAME_PARALLEL_DECODING_MODE_MASK   
 (0x0040)
+#define RDECODE_FRAME_HDR_INFO_VP9_REFRESH_FRAME_CONTEXT_MASK  
 (0x0020)
+#define RDECODE_FRAME_HDR_INFO_VP9_ALLOW_HIGH_PRECISION_MV_MASK
 (0x0010)
+#define RDECODE_FRAME_HDR_INFO_VP9_INTRA_ONLY_MASK 
 (0x0008)
+#define RDECODE_FRAME_HDR_INFO_VP9_ERROR_RESILIENT_MODE_MASK   
 (0x0004)
+#define RDECODE_FRAME_HDR_INFO_VP9_FRAME_TYPE_MASK 
 (0x0002)
+#define RDECODE_FRAME_HDR_INFO_VP9_SHOW_EXISTING_FRAME_MASK
 (0x0001)
+
 typedef struct rvcn_dec_message_index_s {
unsigned intmessage_id;
unsigned intoffset;
@@ -447,6 +478,47 @@ typedef struct rvcn_dec_message_hevc_s {
unsigned char   direct_reflist[2][15];
 } rvcn_dec_message_hevc_t;
 
+typedef struct rvcn_dec_message_vp9_s {
+   unsigned intframe_header_flags;
+
+   unsigned char   frame_context_idx;
+   unsigned char   reset_frame_context;
+
+   unsigned char   curr_pic_idx;
+   unsigned char   interp_filter;
+
+   unsigned char   filter_level;
+   unsigned char   sharpness_level;
+   unsigned char   lf_adj_level[8][4][2];
+   unsigned char   base_qindex;
+   signed char y_dc_delta_q;
+   signed char uv_ac_delta_q;
+   signed char uv_dc_delta_q;
+
+   unsigned char   log2_tile_cols;
+   unsigned char   log2_tile_rows;
+   unsigned char   tx_mode;
+   unsigned char   reference_mode;
+   unsigned char   chroma_format;
+
+   unsigned char   ref_frame_map[8];
+
+   unsigned char   frame_refs[3];
+   unsigned char   ref_frame_sign_bias[3];
+   unsigned char   frame_to_show;
+   unsigned char   bit_depth_luma_minus8;
+   unsigned char   bit_depth_chroma_minus8;
+
+   unsigned char   p010_mode;
+   unsigned char   msb_mode;
+   unsigned char   luma_10to8;
+   unsigned char   chroma_10to8;
+
+   unsigned intvp9_frame_size;
+   unsigned intcompressed_header_size;
+   unsigned intuncompressed_header_size;
+} rvcn_dec_message_vp9_t;
+
 typedef struct rvcn_dec_feature_index_s {
unsigned intfeature_id;
unsigned intoffset;
@@ -504,6 +576,68 @@ typedef struct rvcn_dec_feedback_profiling_s {
unsigned intdmaHwCrc32Value2;
 } rvcn_dec_feedback_profiling_t;
 
+typedef struct rvcn_dec_vp9_nmv_ctx_mask_s {
+unsigned short classes_mask[2];
+unsigned short bits_mask[2];

[Mesa-dev] [PATCH 05/22] vl: add VP9 probability tables

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/auxiliary/Makefile.sources|   3 +-
 src/gallium/auxiliary/meson.build |   1 +
 src/gallium/auxiliary/vl/vl_probs_table.h | 585 ++
 3 files changed, 588 insertions(+), 1 deletion(-)
 create mode 100644 src/gallium/auxiliary/vl/vl_probs_table.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index a2dae04698..d70eb04e79 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -352,7 +352,8 @@ VL_SOURCES := \
vl/vl_video_buffer.h \
vl/vl_vlc.h \
vl/vl_zscan.c \
-   vl/vl_zscan.h
+   vl/vl_zscan.h \
+   vl/vl_probs_table.h
 
 # XXX: Nuke this as our dri targets no longer depend on VL.
 VL_WINSYS_SOURCES := \
diff --git a/src/gallium/auxiliary/meson.build 
b/src/gallium/auxiliary/meson.build
index 0108b0e756..53c85046ed 100644
--- a/src/gallium/auxiliary/meson.build
+++ b/src/gallium/auxiliary/meson.build
@@ -450,6 +450,7 @@ files_libgalliumvl = files(
   'vl/vl_vlc.h',
   'vl/vl_zscan.c',
   'vl/vl_zscan.h',
+  'vl/vl_probs_table.h',
 )
 
 vlwinsys_deps = []
diff --git a/src/gallium/auxiliary/vl/vl_probs_table.h 
b/src/gallium/auxiliary/vl/vl_probs_table.h
new file mode 100644
index 00..9e4d4ada97
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_probs_table.h
@@ -0,0 +1,585 @@
+/**
+ *
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#ifndef vl_probs_table_h
+#define vl_probs_table_h
+
+static const unsigned char default_coef_probs_4x4[2][2][6][6][3] = {
+   {  /* Y plane */
+  {  /* Intra */
+ {  /* Band 0 */
+{ 195,  29, 183 }, {  84,  49, 136 }, {   8,  42,  71 }
+ },
+ {  /* Band 1 */
+   {  31, 107, 169 }, {  35,  99, 159 }, {  17,  82, 140 },
+   {   8,  66, 114 }, {   2,  44,  76 }, {   1,  19,  32 }
+ },
+ {  /* Band 2 */
+   {  40, 132, 201 }, {  29, 114, 187 }, {  13,  91, 157 },
+   {   7,  75, 127 }, {   3,  58,  95 }, {   1,  28,  47 }
+ },
+ {  /* Band 3 */
+   {  69, 142, 221 }, {  42, 122, 201 }, {  15,  91, 159 },
+   {   6,  67, 121 }, {   1,  42,  77 }, {   1,  17,  31 }
+ },
+ {  /* Band 4 */
+   { 102, 148, 228 }, {  67, 117, 204 }, {  17,  82, 154 },
+   {   6,  59, 114 }, {   2,  39,  75 }, {   1,  15,  29 }
+ },
+ {  /* Band 5 */
+   { 156,  57, 233 }, { 119,  57, 212 }, {  58,  48, 163 },
+   {  29,  40, 124 }, {  12,  30,  81 }, {   3,  12,  31 }
+ }
+  },
+  {  /* Inter */
+ {  /* Band 0 */
+   { 191, 107, 226 }, { 124, 117, 204 }, {  25,  99, 155 }
+ },
+ {  /* Band 1 */
+   {  29, 148, 210 }, {  37, 126, 194 }, {   8,  93, 157 },
+   {   2,  68, 118 }, {   1,  39,  69 }, {   1,  17,  33 }
+ },
+ {  /* Band 2 */
+   {  41, 151, 213 }, {  27, 123, 193 }, {   3,  82, 144 },
+   {   1,  58, 105 }, {   1,  32,  60 }, {   1,  13,  26 }
+ },
+ {  /* Band 3 */
+   {  59, 159, 220 }, {  23, 126, 198 }, {   4,  88, 151 },
+   {   1,  66, 114 }, {   1,  38,  71 }, {   1,  18,  34 }
+ },
+ {  /* Band 4 */
+   { 114, 136, 232 }, {  51, 114, 207 }, {  11,  83, 155 },
+   {   3,  56, 105 }, {   1,  33,  65 }, {   1,  17,  34 }
+ },
+ {  /* Band 5 */
+   { 149,  65, 234 }, { 121,  57, 215 }, {  61,  49, 166 },
+   {  28,  36, 114 }, {  12,  25,  76 }, {   3,  16,  42 }
+ }
+  }
+   },
+   {  /* 

[Mesa-dev] [PATCH 06/22] radeon/vcn: add VP9 prob table buffer

2018-04-09 Thread Leo Liu
Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeon/radeon_vcn_dec.c | 52 +++--
 src/gallium/drivers/radeon/radeon_vcn_dec.h |  3 ++
 2 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c 
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index b7cb8a3650..b29ba37b3c 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -42,6 +42,7 @@
 #define FB_BUFFER_OFFSET   0x1000
 #define FB_BUFFER_SIZE 2048
 #define IT_SCALING_TABLE_SIZE  992
+#define VP9_PROBS_TABLE_SIZE   (RDECODE_VP9_PROBS_DATA_SIZE + 256)
 #define RDECODE_SESSION_CONTEXT_SIZE   (128 * 1024)
 
 #define RDECODE_GPCOM_VCPU_CMD 0x2070c
@@ -68,9 +69,10 @@ struct radeon_decoder {
void*msg;
uint32_t*fb;
uint8_t *it;
+   uint8_t *probs;
void*bs_ptr;
 
-   struct rvid_buffer  msg_fb_it_buffers[NUM_BUFFERS];
+   struct rvid_buffer  msg_fb_it_probs_buffers[NUM_BUFFERS];
struct rvid_buffer  bs_buffers[NUM_BUFFERS];
struct rvid_buffer  dpb;
struct rvid_buffer  ctx;
@@ -807,14 +809,20 @@ static bool have_it(struct radeon_decoder *dec)
dec->stream_type == RDECODE_CODEC_H265;
 }
 
+/* do the codec needs an probs buffer? */
+static bool have_probs(struct radeon_decoder *dec)
+{
+   return dec->stream_type == RDECODE_CODEC_VP9;
+}
+
 /* map the next available message/feedback/itscaling buffer */
-static void map_msg_fb_it_buf(struct radeon_decoder *dec)
+static void map_msg_fb_it_probs_buf(struct radeon_decoder *dec)
 {
struct rvid_buffer* buf;
uint8_t *ptr;
 
/* grab the current message/feedback buffer */
-   buf = >msg_fb_it_buffers[dec->cur_buffer];
+   buf = >msg_fb_it_probs_buffers[dec->cur_buffer];
 
/* and map it for CPU access */
ptr = dec->ws->buffer_map(buf->res->buf, dec->cs, PIPE_TRANSFER_WRITE);
@@ -825,6 +833,8 @@ static void map_msg_fb_it_buf(struct radeon_decoder *dec)
dec->fb = (uint32_t *)(ptr + FB_BUFFER_OFFSET);
if (have_it(dec))
dec->it = (uint8_t *)(ptr + FB_BUFFER_OFFSET + FB_BUFFER_SIZE);
+   else if (have_probs(dec))
+   dec->probs = (uint8_t *)(ptr + FB_BUFFER_OFFSET + 
FB_BUFFER_SIZE);
 }
 
 /* unmap and send a message command to the VCPU */
@@ -837,13 +847,14 @@ static void send_msg_buf(struct radeon_decoder *dec)
return;
 
/* grab the current message buffer */
-   buf = >msg_fb_it_buffers[dec->cur_buffer];
+   buf = >msg_fb_it_probs_buffers[dec->cur_buffer];
 
/* unmap the buffer */
dec->ws->buffer_unmap(buf->res->buf);
dec->msg = NULL;
dec->fb = NULL;
dec->it = NULL;
+   dec->probs = NULL;
 
if (dec->sessionctx.res)
send_cmd(dec, RDECODE_CMD_SESSION_CONTEXT_BUFFER,
@@ -1046,7 +1057,7 @@ static void radeon_dec_destroy(struct pipe_video_codec 
*decoder)
 
assert(decoder);
 
-   map_msg_fb_it_buf(dec);
+   map_msg_fb_it_probs_buf(dec);
rvcn_dec_message_destroy(dec);
send_msg_buf(dec);
 
@@ -1055,7 +1066,7 @@ static void radeon_dec_destroy(struct pipe_video_codec 
*decoder)
dec->ws->cs_destroy(dec->cs);
 
for (i = 0; i < NUM_BUFFERS; ++i) {
-   si_vid_destroy_buffer(>msg_fb_it_buffers[i]);
+   si_vid_destroy_buffer(>msg_fb_it_probs_buffers[i]);
si_vid_destroy_buffer(>bs_buffers[i]);
}
 
@@ -1153,20 +1164,20 @@ static void radeon_dec_end_frame(struct 
pipe_video_codec *decoder,
 {
struct radeon_decoder *dec = (struct radeon_decoder*)decoder;
struct pb_buffer *dt;
-   struct rvid_buffer *msg_fb_it_buf, *bs_buf;
+   struct rvid_buffer *msg_fb_it_probs_buf, *bs_buf;
 
assert(decoder);
 
if (!dec->bs_ptr)
return;
 
-   msg_fb_it_buf = >msg_fb_it_buffers[dec->cur_buffer];
+   msg_fb_it_probs_buf = >msg_fb_it_probs_buffers[dec->cur_buffer];
bs_buf = >bs_buffers[dec->cur_buffer];
 
memset(dec->bs_ptr, 0, align(dec->bs_size, 128) - dec->bs_size);
dec->ws->buffer_unmap(bs_buf->res->buf);
 
-   map_msg_fb_it_buf(dec);
+   map_msg_fb_it_probs_buf(dec);
dt = rvcn_dec_message_decode(dec, target, picture);
rvcn_dec_message_feedback(dec);
send_msg_buf(dec);
@@ -1180,10 +1191,13 @@ static void radeon_dec_end_frame(struct 
pipe_video_codec *decoder,
 0, RADEON_USAGE_READ, RADEON_DOMAIN_GTT);
send_cmd(dec, RDECODE_CMD_DECODING_TARGET_BUFFER, dt, 0,
 RADEON_USAGE_WRITE, RADEON_DOMAIN_VRAM);
-   send_cmd(dec, RDECODE_CMD_FEEDBACK_BUFFER, 

  1   2   >