Re: [Mesa-dev] [PATCH 0/2] Initial Panfrost driver

[Alyssa Rosenzweig]

Hi Emil,

> As you pointed out, the CS of the driver is not included, so I wonder
> if we cannot add link to instructions in panfrost_create_screen()
> Reading the current fprintf is fairly discouraging.

The command stream portion is now included in a follow-up patch,
although for downstream kernels, that still needs an out-of-tree
overlay... so until we have an upstream kernel, maybe we should still
drop a link there.

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

[Mesa-dev] [PATCH 0/2] panfrost: Command stream driver

[Alyssa Rosenzweig]

This patch set includes the command stream driver, providing a complete
upstream driver absent some winsys bits. The first patch includes the
driver itself; the second patch includes glue for an out-of-tree overlay
for old kernels. With this patchset and a small amount of out-of-tree
glue, Panfrost is functional on upstream Mesa.

Alyssa Rosenzweig (2):
  panfrost: Check in sources for command stream
  panfrost: Include glue for out-of-tree legacy code

 src/gallium/drivers/panfrost/.gitignore   |1 +
 src/gallium/drivers/panfrost/meson.build  |   32 +-
 src/gallium/drivers/panfrost/pan_allocate.c   |  220 ++
 src/gallium/drivers/panfrost/pan_assemble.c   |  226 ++
 .../drivers/panfrost/pan_blend_shaders.c  |  178 ++
 .../drivers/panfrost/pan_blend_shaders.h  |   36 +
 src/gallium/drivers/panfrost/pan_blending.c   |  401 +++
 src/gallium/drivers/panfrost/pan_blending.h   |   34 +
 src/gallium/drivers/panfrost/pan_context.c| 2699 +
 src/gallium/drivers/panfrost/pan_context.h|3 +
 src/gallium/drivers/panfrost/pan_drm.c|   42 +
 src/gallium/drivers/panfrost/pan_drm.h|   32 +
 src/gallium/drivers/panfrost/pan_format.c |  220 ++
 src/gallium/drivers/panfrost/pan_format.h |   42 +
 .../drivers/panfrost/pan_pretty_print.c   |  224 ++
 .../drivers/panfrost/pan_pretty_print.h   |   32 +
 src/gallium/drivers/panfrost/pan_resource.c   |  432 +++
 src/gallium/drivers/panfrost/pan_screen.c |   29 +-
 src/gallium/drivers/panfrost/pan_screen.h |6 +-
 src/gallium/drivers/panfrost/pan_swizzle.c|  234 ++
 src/gallium/drivers/panfrost/pan_swizzle.h|   41 +
 src/gallium/drivers/panfrost/pan_wallpaper.c  |  275 ++
 src/gallium/drivers/panfrost/pan_wallpaper.h  |   33 +
 23 files changed, 5465 insertions(+), 7 deletions(-)
 create mode 100644 src/gallium/drivers/panfrost/.gitignore
 create mode 100644 src/gallium/drivers/panfrost/pan_allocate.c
 create mode 100644 src/gallium/drivers/panfrost/pan_assemble.c
 create mode 100644 src/gallium/drivers/panfrost/pan_blend_shaders.c
 create mode 100644 src/gallium/drivers/panfrost/pan_blend_shaders.h
 create mode 100644 src/gallium/drivers/panfrost/pan_blending.c
 create mode 100644 src/gallium/drivers/panfrost/pan_blending.h
 create mode 100644 src/gallium/drivers/panfrost/pan_context.c
 create mode 100644 src/gallium/drivers/panfrost/pan_drm.c
 create mode 100644 src/gallium/drivers/panfrost/pan_drm.h
 create mode 100644 src/gallium/drivers/panfrost/pan_format.c
 create mode 100644 src/gallium/drivers/panfrost/pan_format.h
 create mode 100644 src/gallium/drivers/panfrost/pan_pretty_print.c
 create mode 100644 src/gallium/drivers/panfrost/pan_pretty_print.h
 create mode 100644 src/gallium/drivers/panfrost/pan_resource.c
 create mode 100644 src/gallium/drivers/panfrost/pan_swizzle.c
 create mode 100644 src/gallium/drivers/panfrost/pan_swizzle.h
 create mode 100644 src/gallium/drivers/panfrost/pan_wallpaper.c
 create mode 100644 src/gallium/drivers/panfrost/pan_wallpaper.h

-- 
2.20.1

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

[Mesa-dev] [PATCH 2/2] panfrost: Include glue for out-of-tree legacy code

[Alyssa Rosenzweig]

In addition to the DRM interface in active development, for legacy
kernels Panfrost has a small, optional, out-of-tree glue repository. For
various reasons, this legacy code should not be included in Mesa proper,
but this commit allows it to coexist peacefully with upstream Panfrost.
If the nondrm repo is cloned/symlinked to the directory
`src/gallium/drivers/panfrost/nondrm`, legacy functionality will be
built. Otherwise, the driver will build normally, though a runtime error
message will be printed if a legacy kernel is detected.

This workaround is icky, but it allows a nearly-upstream Panfrost to
work on real hardware, today. Ideally, this patch will be reverted when
the Panfrost kernel module is mature and we drop legacy support.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/.gitignore|  1 +
 src/gallium/drivers/panfrost/meson.build   | 21 ++---
 src/gallium/drivers/panfrost/pan_context.c |  3 ++-
 src/gallium/drivers/panfrost/pan_screen.c  |  9 +++--
 src/gallium/drivers/panfrost/pan_screen.h  |  2 +-
 5 files changed, 29 insertions(+), 7 deletions(-)
 create mode 100644 src/gallium/drivers/panfrost/.gitignore

diff --git a/src/gallium/drivers/panfrost/.gitignore 
b/src/gallium/drivers/panfrost/.gitignore
new file mode 100644
index 000..9d2c2c18bef
--- /dev/null
+++ b/src/gallium/drivers/panfrost/.gitignore
@@ -0,0 +1 @@
+nondrm
diff --git a/src/gallium/drivers/panfrost/meson.build 
b/src/gallium/drivers/panfrost/meson.build
index 9b90035d691..5e799eae119 100644
--- a/src/gallium/drivers/panfrost/meson.build
+++ b/src/gallium/drivers/panfrost/meson.build
@@ -39,7 +39,7 @@ files_panfrost = files(
   'pan_blending.c',
   'pan_blend_shaders.c',
   'pan_wallpaper.c',
-  'pan_pretty_print.c'
+  'pan_pretty_print.c',
 )
 
 inc_panfrost = [
@@ -53,6 +53,21 @@ inc_panfrost = [
   include_directories('midgard'),
 ]
 
+compile_args_panfrost = [
+  '-DGALLIUM_PANFROST',
+  '-Wno-pointer-arith'
+]
+
+overlay = join_paths(meson.source_root(), meson.current_source_dir(), 
'nondrm/pan_nondrm.c')
+nondrm_overlay_check = run_command('ls', overlay)
+has_nondrm_overlay = nondrm_overlay_check.returncode() == 0
+
+if has_nondrm_overlay
+  files_panfrost += files('nondrm/pan_nondrm.c')
+  inc_panfrost += include_directories('nondrm/include')
+  compile_args_panfrost += '-DPAN_NONDRM_OVERLAY'
+endif
+
 midgard_nir_algebraic_c = custom_target(
   'midgard_nir_algebraic.c',
   input : 'midgard/midgard_nir_algebraic.py',
@@ -73,11 +88,11 @@ libpanfrost = static_library(
 idep_nir
   ],
   include_directories : inc_panfrost,
-  c_args : [c_vis_args, c_msvc_compat_args],
+  c_args : [c_vis_args, c_msvc_compat_args, compile_args_panfrost],
 )
 
 driver_panfrost = declare_dependency(
-  compile_args : ['-DGALLIUM_PANFROST', '-Wno-pointer-arith'],
+  compile_args : compile_args_panfrost,
   link_with : [libpanfrost, libpanfrostwinsys],
 )
 
diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 0551d553182..fb4130362e0 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1431,7 +1431,8 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool 
flush_immediate)
 
 #ifndef DRY_RUN
 
-   int fragment_id = screen->driver->submit_vs_fs_job(ctx, has_draws);
+bool is_scanout = panfrost_is_scanout(ctx);
+int fragment_id = screen->driver->submit_vs_fs_job(ctx, has_draws, 
is_scanout);
 
 /* If visual, we can stall a frame */
 
diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
b/src/gallium/drivers/panfrost/pan_screen.c
index 58f4f610fc7..defabf37f7c 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -49,7 +49,8 @@
 #include "pan_context.h"
 #include "midgard/midgard_compile.h"
 
-#include "pan_drm.h"
+struct panfrost_driver *panfrost_create_drm_driver(int fd);
+struct panfrost_driver *panfrost_create_nondrm_driver(int fd);
 
 static const char *
 panfrost_get_name(struct pipe_screen *screen)
@@ -684,8 +685,12 @@ panfrost_create_screen(int fd, struct renderonly *ro, bool 
is_drm)
 if (is_drm) {
 screen->driver = panfrost_create_drm_driver(fd);
 } else {
-fprintf(stderr, "Legacy (non-DRM) drivers are not supported in 
upstream Mesa\n");
+#ifdef PAN_NONDRM_OVERLAY
+screen->driver = panfrost_create_nondrm_driver(fd);
+#else
+fprintf(stderr, "Legacy (non-DRM) operation requires 
out-of-tree overlay\n");
 return NULL;
+#endif
 }
 
 #ifdef DUMP_PERFORMANCE_COUNTERS
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index 4c8fe8dd720..59787c8017c 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -53,7 +53,7 @@ struct panfrost_driver {
void (*unmap_bo) (struct 

[Mesa-dev] [PATCH] gallium: add PIPE_SHADER_CAP_MAX_INPUT_COMPONENTS

[Ilia Mirkin]

NVIDIA hardware is weird. The fragment shader allows 124 varying
components (i.e. 31 varyings), but a total of 128 input components if
you could e.g. gl_FragCoord. There's no way to express this currently --
specifying a max of 32 varyings will cause failures in some tests.

This separates INPUT_COMPONENTS from INPUTS, and links up
INPUT_COMPONENTS to the proper limit. For all drivers other than nvc0,
this is set to 4 * INPUTS.

Signed-off-by: Ilia Mirkin 
Cc: 19.0 
---

This is a conformance issue for nouveau, so I'd like to get it into the
next release. Should have no effect on non-nvc0 drivers.

 src/gallium/auxiliary/gallivm/lp_bld_limits.h|  2 ++
 src/gallium/auxiliary/tgsi/tgsi_exec.h   |  2 ++
 src/gallium/docs/source/screen.rst   |  4 
 src/gallium/drivers/etnaviv/etnaviv_screen.c |  4 
 src/gallium/drivers/freedreno/freedreno_screen.c |  2 ++
 src/gallium/drivers/i915/i915_screen.c   |  2 ++
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   |  4 
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   |  4 
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   |  2 ++
 src/gallium/drivers/panfrost/pan_screen.c|  3 +++
 src/gallium/drivers/r300/r300_screen.c   |  4 
 src/gallium/drivers/r600/r600_pipe.c |  2 ++
 src/gallium/drivers/radeonsi/si_get.c|  2 ++
 src/gallium/drivers/svga/svga_screen.c   | 11 +++
 src/gallium/drivers/v3d/v3d_screen.c |  5 +
 src/gallium/drivers/vc4/vc4_screen.c |  2 ++
 src/gallium/drivers/virgl/virgl_screen.c |  5 +
 src/gallium/include/pipe/p_defines.h |  1 +
 src/mesa/state_tracker/st_extensions.c   |  2 +-
 19 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_limits.h 
b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
index 7b66b758729..c27bdf8e5b8 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
@@ -99,6 +99,8 @@ gallivm_get_shader_param(enum pipe_shader_cap param)
   return LP_MAX_TGSI_NESTING;
case PIPE_SHADER_CAP_MAX_INPUTS:
   return 32;
+   case PIPE_SHADER_CAP_MAX_INPUT_COMPONENTS:
+  return 32 * 4;
case PIPE_SHADER_CAP_MAX_OUTPUTS:
   return 32;
case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE:
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h 
b/src/gallium/auxiliary/tgsi/tgsi_exec.h
index 6d4ac381421..2f483ee79d4 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
@@ -500,6 +500,8 @@ tgsi_exec_get_shader_param(enum pipe_shader_cap param)
   return TGSI_EXEC_MAX_NESTING;
case PIPE_SHADER_CAP_MAX_INPUTS:
   return TGSI_EXEC_MAX_INPUT_ATTRIBS;
+   case PIPE_SHADER_CAP_MAX_INPUT_COMPONENTS:
+  return TGSI_EXEC_MAX_INPUT_ATTRIBS * 4;
case PIPE_SHADER_CAP_MAX_OUTPUTS:
   return 32;
case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE:
diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index eaf492ce8b0..391aa82b233 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -595,6 +595,10 @@ MOV OUT[0], CONST[0][3]  # copy vector 3 of constbuf 0
 * ``PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS``: If atomic counters are
   separate, how many atomic counter buffers are available for this stage.
 * ``PIPE_SHADER_CAP_SCALAR_ISA``: Whether the ISA is a scalar one.
+* ``PIPE_SHADER_CAP_MAX_INPUT_COMPONENTS``: The maximum number of
+  input components, including any system values that require
+  slots. This value is at least 4 * ``PIPE_SHADER_CAP_MAX_INPUTS``,
+  but can be more if more components are allowed that aren't varyings.
 
 .. _pipe_compute_cap:
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index fd320232528..ffb7abe8ca2 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -440,6 +440,10 @@ etna_screen_get_shader_param(struct pipe_screen *pscreen,
* of varyings. */
   return shader == PIPE_SHADER_FRAGMENT ? screen->specs.max_varyings
 : 
screen->specs.vertex_max_elements;
+   case PIPE_SHADER_CAP_MAX_INPUT_COMPONENTS:
+  return (shader == PIPE_SHADER_FRAGMENT ?
+  screen->specs.max_varyings :
+  screen->specs.vertex_max_elements) * 4;
case PIPE_SHADER_CAP_MAX_OUTPUTS:
   return 16; /* see VIVS_VS_OUTPUT */
case PIPE_SHADER_CAP_MAX_TEMPS:
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index e596a4e8462..449dc83cd72 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -452,6 +452,8 @@ fd_screen_get_shader_param(struct pipe_screen *pscreen,
case PIPE_SHADER_CAP_MAX_INPUTS:
case 

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

[bugzilla-daemon]

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

--- Comment #5 from mikhail.v.gavri...@gmail.com ---
Which gcc versiob do you use?(In reply to Sylvain BERTRAND from comment #4)
> Tested Rise of the Tomb Raider : I get a system hang (I am going to report a
> regression because I did clear the game on 04/2018).
> No pb with dota2 vulkan, artifact (vulkan) or cs:go (opengl)
> I use a gfx stack git from sunday: linux (amd-staging-drm-next), drm, llvm,
> mesa-gl, mesa-vulkan, xserver, xf86-video-amdgpu

Which gcc version do you use?

Fedora already moved to gcc 9.0.1

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

[Mesa-dev] [PATCH] nv50, nvc0: use condition for occlusion queries when already complete

[Ilia Mirkin]

For the NO_WAIT variants, we would jump into the ALWAYS case for both
nested and inverted occlusion queries. However if the query had
previously completed, the application could reasonably expect that the
render condition would follow that result.

To resolve this, we remove the nesting distinction which unnecessarily
created an imbalance between the regular and inverted cases (since
there's no "zero" condition mode). We also use the proper comparison if
we know that the query has completed (which could happen as a result of
an earlier get_query_result call).

Fixes KHR-GL45.conditional_render_inverted.functional

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/nv50/nv50_query.c   | 10 --
 .../drivers/nouveau/nv50/nv50_query_hw.c|  8 +---
 .../drivers/nouveau/nv50/nv50_query_hw.h|  6 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_query.c   | 10 --
 .../drivers/nouveau/nvc0/nvc0_query_hw.c| 17 -
 .../drivers/nouveau/nvc0/nvc0_query_hw.h|  6 +-
 6 files changed, 27 insertions(+), 30 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query.c 
b/src/gallium/drivers/nouveau/nv50/nv50_query.c
index e30380cd84d..13088ebb5fa 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_query.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_query.c
@@ -98,12 +98,10 @@ nv50_render_condition(struct pipe_context *pipe,
   case PIPE_QUERY_OCCLUSION_COUNTER:
   case PIPE_QUERY_OCCLUSION_PREDICATE:
   case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE:
+ if (hq->state == NV50_HW_QUERY_STATE_READY)
+wait = true;
  if (likely(!condition)) {
-if (unlikely(hq->nesting))
-   cond = wait ? NV50_3D_COND_MODE_NOT_EQUAL :
- NV50_3D_COND_MODE_ALWAYS;
-else
-   cond = NV50_3D_COND_MODE_RES_NON_ZERO;
+cond = wait ? NV50_3D_COND_MODE_NOT_EQUAL : 
NV50_3D_COND_MODE_ALWAYS;
  } else {
 cond = wait ? NV50_3D_COND_MODE_EQUAL : NV50_3D_COND_MODE_ALWAYS;
  }
@@ -129,7 +127,7 @@ nv50_render_condition(struct pipe_context *pipe,
 
PUSH_SPACE(push, 9);
 
-   if (wait) {
+   if (wait && hq->state != NV50_HW_QUERY_STATE_READY) {
   BEGIN_NV04(push, SUBC_3D(NV50_GRAPH_SERIALIZE), 1);
   PUSH_DATA (push, 0);
}
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query_hw.c 
b/src/gallium/drivers/nouveau/nv50/nv50_query_hw.c
index ac3e409b2d5..4e74c462235 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_query_hw.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_query_hw.c
@@ -29,11 +29,6 @@
 #include "nv50/nv50_query_hw_sm.h"
 #include "nv_object.xml.h"
 
-#define NV50_HW_QUERY_STATE_READY   0
-#define NV50_HW_QUERY_STATE_ACTIVE  1
-#define NV50_HW_QUERY_STATE_ENDED   2
-#define NV50_HW_QUERY_STATE_FLUSHED 3
-
 /* XXX: Nested queries, and simultaneous queries on multiple gallium contexts
  * (since we use only a single GPU channel per screen) will not work properly.
  *
@@ -158,8 +153,7 @@ nv50_hw_begin_query(struct nv50_context *nv50, struct 
nv50_query *q)
case PIPE_QUERY_OCCLUSION_COUNTER:
case PIPE_QUERY_OCCLUSION_PREDICATE:
case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE:
-  hq->nesting = nv50->screen->num_occlusion_queries_active++;
-  if (hq->nesting) {
+  if (nv50->screen->num_occlusion_queries_active++) {
  nv50_hw_query_get(push, q, 0x10, 0x0100f002);
   } else {
  PUSH_SPACE(push, 4);
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query_hw.h 
b/src/gallium/drivers/nouveau/nv50/nv50_query_hw.h
index 82ec6bd2d96..a89a66cec4f 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_query_hw.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_query_hw.h
@@ -6,6 +6,11 @@
 
 #include "nv50_query.h"
 
+#define NV50_HW_QUERY_STATE_READY   0
+#define NV50_HW_QUERY_STATE_ACTIVE  1
+#define NV50_HW_QUERY_STATE_ENDED   2
+#define NV50_HW_QUERY_STATE_FLUSHED 3
+
 #define NVA0_HW_QUERY_STREAM_OUTPUT_BUFFER_OFFSET (PIPE_QUERY_TYPES + 0)
 
 struct nv50_hw_query;
@@ -29,7 +34,6 @@ struct nv50_hw_query {
uint8_t state;
bool is64bit;
uint8_t rotate;
-   int nesting; /* only used for occlusion queries */
struct nouveau_mm_allocation *mm;
struct nouveau_fence *fence;
 };
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
index 1a3e4e794c0..40af9936859 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
@@ -121,12 +121,10 @@ nvc0_render_condition(struct pipe_context *pipe,
   case PIPE_QUERY_OCCLUSION_COUNTER:
   case PIPE_QUERY_OCCLUSION_PREDICATE:
   case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE:
+ if (hq->state == NVC0_HW_QUERY_STATE_READY)
+wait = true;
  if (likely(!condition)) {
-if (unlikely(hq->nesting))
-   cond = wait ? NVC0_3D_COND_MODE_NOT_EQUAL :
-  

[Mesa-dev] [PATCH] kmsro: Move DRM entrypoints to shared block

[Alyssa Rosenzweig]

As kmsro allows an essentially mix-and-match hodgepodge of display
drivers and renderonly GPUs, it doesn't make sense to couple the display
driver entrypoint definition with the driver. Instead, we move *all*
kmsro entrypoints to a shared kmsro block at the end (avoiding clutter
and distraction since this list may snowball in the future).

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/targets/dri/target.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/src/gallium/targets/dri/target.c b/src/gallium/targets/dri/target.c
index 17484ced979..5bd34600f2e 100644
--- a/src/gallium/targets/dri/target.c
+++ b/src/gallium/targets/dri/target.c
@@ -77,21 +77,11 @@ DEFINE_LOADER_DRM_ENTRYPOINT(v3d)
 
 #if defined(GALLIUM_VC4)
 DEFINE_LOADER_DRM_ENTRYPOINT(vc4)
-#if defined(GALLIUM_KMSRO)
-DEFINE_LOADER_DRM_ENTRYPOINT(hx8357d)
-DEFINE_LOADER_DRM_ENTRYPOINT(pl111)
-#endif
 #endif
 
 #if defined(GALLIUM_PANFROST)
 DEFINE_LOADER_DRM_ENTRYPOINT(panfrost)
-#if defined(GALLIUM_KMSRO)
-DEFINE_LOADER_DRM_ENTRYPOINT(rockchip)
-DEFINE_LOADER_DRM_ENTRYPOINT(meson)
 #endif
-#endif
-
-
 
 #if defined(GALLIUM_ETNAVIV)
 DEFINE_LOADER_DRM_ENTRYPOINT(imx_drm)
@@ -101,3 +91,11 @@ DEFINE_LOADER_DRM_ENTRYPOINT(etnaviv)
 #if defined(GALLIUM_TEGRA)
 DEFINE_LOADER_DRM_ENTRYPOINT(tegra);
 #endif
+
+#if defined(GALLIUM_KMSRO)
+DEFINE_LOADER_DRM_ENTRYPOINT(hx8357d)
+DEFINE_LOADER_DRM_ENTRYPOINT(pl111)
+DEFINE_LOADER_DRM_ENTRYPOINT(rockchip)
+DEFINE_LOADER_DRM_ENTRYPOINT(meson)
+#endif
+
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] meson: Remove panfrost from default driver list

[Alyssa Rosenzweig]

> You could also add an environment variable that, when not set, will
> cause it to abort on screen setup.

Aborting on screen setup sounds like a surprise to me ;)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] panfrost: Use u_pipe_screen_get_param_defaults

[Alyssa Rosenzweig]

Switching to the defaults function cleans up pan_screen.h markedly and
futureproofs for when new PIPE_CAPs are added.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_screen.c | 157 +-
 1 file changed, 6 insertions(+), 151 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
b/src/gallium/drivers/panfrost/pan_screen.c
index 0e745583940..0fe90db0b0a 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -32,6 +32,7 @@
 #include "util/u_format.h"
 #include "util/u_format_s3tc.h"
 #include "util/u_video.h"
+#include "util/u_screen.h"
 #include "util/os_time.h"
 #include "pipe/p_defines.h"
 #include "pipe/p_screen.h"
@@ -76,14 +77,10 @@ panfrost_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
 return 1;
 
 case PIPE_CAP_SM3:
-return 1;
-
 case PIPE_CAP_POINT_SPRITE:
 return 1;
 
 case PIPE_CAP_MAX_RENDER_TARGETS:
-return PIPE_MAX_COLOR_BUFS;
-
 case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
 return 1;
 
@@ -93,14 +90,9 @@ panfrost_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
 return 1; /* TODO: Queries */
 
 case PIPE_CAP_TEXTURE_MIRROR_CLAMP:
-return 1;
-
 case PIPE_CAP_TEXTURE_SWIZZLE:
 return 1;
 
-case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
-return 0;
-
 case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
 case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
 case PIPE_CAP_MAX_TEXTURE_CUBE_LEVELS:
@@ -124,9 +116,6 @@ panfrost_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
 case PIPE_CAP_DEPTH_CLIP_DISABLE:
 return 1;
 
-case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
-return 0; /* no streamout */
-
 case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
 case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
 return 16 * 4;
@@ -138,17 +127,9 @@ panfrost_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
 case PIPE_CAP_MAX_VERTEX_STREAMS:
 return 1;
 
-case PIPE_CAP_PRIMITIVE_RESTART:
-return 0; /* We don't understand this yet */
-
 case PIPE_CAP_SHADER_STENCIL_EXPORT:
 return 1;
 
-case PIPE_CAP_TGSI_INSTANCEID:
-case PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR:
-case PIPE_CAP_START_INSTANCE:
-return 0; /* TODO: Instances */
-
 case PIPE_CAP_SEAMLESS_CUBE_MAP:
 case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
 return 1;
@@ -156,42 +137,21 @@ panfrost_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
 case PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS:
 return 256; /* for GL3 */
 
-case PIPE_CAP_MIN_TEXEL_OFFSET:
-return -8;
-
-case PIPE_CAP_MAX_TEXEL_OFFSET:
-return 7;
-
 case PIPE_CAP_CONDITIONAL_RENDER:
 return 1;
 
-case PIPE_CAP_TEXTURE_BARRIER:
-return 0;
-
 case PIPE_CAP_FRAGMENT_COLOR_CLAMPED:
-case PIPE_CAP_VERTEX_COLOR_UNCLAMPED: /* draw module */
-case PIPE_CAP_VERTEX_COLOR_CLAMPED: /* draw module */
+case PIPE_CAP_VERTEX_COLOR_UNCLAMPED:
+case PIPE_CAP_VERTEX_COLOR_CLAMPED:
 return 1;
 
-case PIPE_CAP_MIXED_COLORBUFFER_FORMATS:
-return 0;
-
 case PIPE_CAP_GLSL_FEATURE_LEVEL:
 return 330;
 
-case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
-case PIPE_CAP_TGSI_TEX_TXF_LZ:
-return 0;
-
-case PIPE_CAP_COMPUTE:
-return 0;
-
-case PIPE_CAP_USER_VERTEX_BUFFERS: /* XXX XXX */
+case PIPE_CAP_USER_VERTEX_BUFFERS: /* TODO */
 case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
 return 0;
 
-case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
-case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
 case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
 case PIPE_CAP_DOUBLES:
 case PIPE_CAP_INT64:
@@ -201,19 +161,9 @@ panfrost_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
 case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
 return 16;
 
-case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
-case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
-case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
-case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
-case PIPE_CAP_TEXTURE_MULTISAMPLE:
-return 0;
-
 case PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET:
 return 0x;
 
-case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT:
-return 64;
-
 case PIPE_CAP_QUERY_TIMESTAMP:
 case PIPE_CAP_CUBE_MAP_ARRAY:
 

Re: [Mesa-dev] [PATCH] meson: Remove panfrost from default driver list

[Jason Ekstrand]

Seems like a good idea. You could also add an environment variable that, 
when not set, will cause it to abort on screen setup.


On February 4, 2019 20:04:23 Alyssa Rosenzweig  wrote:


Until the kernel side matures and the full driver is upstreamed, to
avoid end-user surprises, Panfrost should only be built for the
adventurous.

Signed-off-by: Alyssa Rosenzweig 
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index b83cc21a328..8c24ef268f3 100644
--- a/meson.build
+++ b/meson.build
@@ -132,7 +132,7 @@ if _drivers.contains('auto')
elif ['arm', 'aarch64'].contains(host_machine.cpu_family())
  _drivers = [
'kmsro', 'v3d', 'vc4', 'freedreno', 'etnaviv', 'nouveau',
-'tegra', 'virgl', 'swrast', 'panfrost'
+'tegra', 'virgl', 'swrast'
  ]
else
  error('Unknown architecture @0@. Please pass -Dgallium-drivers to set 
  driver options. Patches gladly accepted to fix this.'.format(

--
2.20.1

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




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

[Mesa-dev] [Bug 109550] [regression][amd tahiti xt][vm fault] Rise of the Tomb Raider hangs the system

[bugzilla-daemon]

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

Sylvain BERTRAND  changed:

   What|Removed |Added

Summary|[regression][amd tahiti xt] |[regression][amd tahiti
   |Rise of the Tomb Raider |xt][vm fault] Rise of the
   |hangs the system|Tomb Raider hangs the
   ||system

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

Re: [Mesa-dev] [PATCH 1/3] glsl: XFB TSC per-vertex output varyings match as not declared as arrays

[Ilia Mirkin]

IMHO this is done at the wrong level. You're effectively keeping track
of a per-variable "this variable belongs to a tcs output that's not a
patch" bit. Doesn't seem worthy of a whole separate bit.

Also, you use ->without_array() a lot, but what you really need to do
is remove *one* layer of array-ness, since with AoA there could be
multiple.

There's already a function in link_varyings.cpp called
"get_varying_type()" I believe it does what you want.

Cheers,

  -ilia

On Thu, Dec 13, 2018 at 12:20 PM Chema Casanova  wrote:
>
> Ping.
>
> El 22/11/18 a las 0:28, Chema Casanova escribió:
> >
> >
> > On 21/11/18 20:04, Ilia Mirkin wrote:
> >> On Wed, Nov 21, 2018 at 1:45 PM Jose Maria Casanova Crespo
> >>  wrote:
> >>>
> >>> Recent change on OpenGL CTS ("Use non-arrayed varying name for TCS 
> >>> blocks")
> >>> on KHR-GL*.tessellation_shader.single.xfb_captures_data_from_correct_stage
> >>> tests changed how to name per-vertex Tessellation Control Shader output
> >>> varyings in transform feedback using interface block as 
> >>> "BLOCK_INOUT.value"
> >>> rather than "BLOCK_INOUT[0].value"
> >>>
> >>> So Tessellation control shader per-vertex output variables and blocks that
> >>> are required to be declared as arrays, with each element representing 
> >>> output
> >>> values for a single vertex of a multi-vertex primitive are expected to be
> >>> named as they were not declared as arrays.
> >>>
> >>> This patch adds a new is_xfb_per_vertex_output flag at ir_variable level 
> >>> so
> >>> we mark when an ir_variable is an per-vertex TCS output varying. So we
> >>> treat it in terms on XFB its naming as a non array variable.
> >>>
> >>> As we don't support NV_gpu_shader5, so PATCHES mode is not accepted as
> >>> primitiveMode parameter of BeginTransformFeedback the test expects a
> >>> failure as we can use the XFB results.
> >>>
> >>> This patch uncovers that we were passing the GLES version of the tests
> >>> because candidates naming didn't match, not because on GLES the 
> >>> Tessellation
> >>> Control stage varyings shouldn't be XFB candidates in any case. This
> >>> is addressed in the following patch.
> >>>
> >>> Fixes: 
> >>> KHR-GL4*.tessellation_shader.single.xfb_captures_data_from_correct_stage
> >>>
> >>> Cc: mesa-sta...@lists.freedesktop.org
> >>> ---
> >>>  src/compiler/glsl/ir.cpp| 1 +
> >>>  src/compiler/glsl/ir.h  | 6 ++
> >>>  src/compiler/glsl/link_uniforms.cpp | 6 --
> >>>  src/compiler/glsl/link_varyings.cpp | 8 +++-
> >>>  4 files changed, 18 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/src/compiler/glsl/ir.cpp b/src/compiler/glsl/ir.cpp
> >>> index 1d1a56ae9a5..582111d71f5 100644
> >>> --- a/src/compiler/glsl/ir.cpp
> >>> +++ b/src/compiler/glsl/ir.cpp
> >>> @@ -1750,6 +1750,7 @@ ir_variable::ir_variable(const struct glsl_type 
> >>> *type, const char *name,
> >>> this->data.fb_fetch_output = false;
> >>> this->data.bindless = false;
> >>> this->data.bound = false;
> >>> +   this->data.is_xfb_per_vertex_output = false;
> >>>
> >>> if (type != NULL) {
> >>>if (type->is_interface())
> >>> diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
> >>> index f478b29a6b5..e09f053b77c 100644
> >>> --- a/src/compiler/glsl/ir.h
> >>> +++ b/src/compiler/glsl/ir.h
> >>> @@ -766,6 +766,12 @@ public:
> >>> */
> >>>unsigned is_xfb_only:1;
> >>>
> >>> +  /**
> >>> +   * Is this varying a TSC per-vertex output candidate for transform
> >>
> >> TCS?
> >
> >
> > Yes. I've fixed it locally at the commit summary too.
> >
> >
> >>> +   * feedback?
> >>> +   */
> >>> +  unsigned is_xfb_per_vertex_output:1;
> >>> +
> >>>/**
> >>> * Was a transfor feedback buffer set in the shader?
> >>
> >> ugh, not your problem, but "transform" :(
> >>
> >>> */
> >>> diff --git a/src/compiler/glsl/link_uniforms.cpp 
> >>> b/src/compiler/glsl/link_uniforms.cpp
> >>> index 63e688b19a7..547da68e216 100644
> >>> --- a/src/compiler/glsl/link_uniforms.cpp
> >>> +++ b/src/compiler/glsl/link_uniforms.cpp
> >>> @@ -72,8 +72,10 @@ program_resource_visitor::process(ir_variable *var, 
> >>> bool use_std430_as_default)
> >>>   get_internal_ifc_packing(use_std430_as_default) :
> >>>var->type->get_internal_ifc_packing(use_std430_as_default);
> >>>
> >>> -   const glsl_type *t =
> >>> -  var->data.from_named_ifc_block ? var->get_interface_type() : 
> >>> var->type;
> >>> +   const glsl_type *t = var->data.from_named_ifc_block ?
> >>> +  (var->data.is_xfb_per_vertex_output ?
> >>> +   var->get_interface_type()->without_array() :
> >>> +   var->get_interface_type()) : var->type;
> >>> const glsl_type *t_without_array = t->without_array();
> >>>
> >>> /* false is always passed for the row_major parameter to the other
> >>> diff --git a/src/compiler/glsl/link_varyings.cpp 
> >>> b/src/compiler/glsl/link_varyings.cpp
> >>> index 52e493cb599..1964dcc0a22 100644
> >>> --- 

[Mesa-dev] [Bug 109550] [regression][amd tahiti xt] Rise of the Tomb Raider hangs the system

[bugzilla-daemon]

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

Sylvain BERTRAND  changed:

   What|Removed |Added

 Attachment #143295|0   |1
is obsolete||

--- Comment #3 from Sylvain BERTRAND  ---
Created attachment 143296
  --> https://bugs.freedesktop.org/attachment.cgi?id=143296=edit
dmesg with context fault

I did managed to get some logs

-- 
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] meson: Remove panfrost from default driver list

[Alyssa Rosenzweig]

Until the kernel side matures and the full driver is upstreamed, to
avoid end-user surprises, Panfrost should only be built for the
adventurous.

Signed-off-by: Alyssa Rosenzweig 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index b83cc21a328..8c24ef268f3 100644
--- a/meson.build
+++ b/meson.build
@@ -132,7 +132,7 @@ if _drivers.contains('auto')
 elif ['arm', 'aarch64'].contains(host_machine.cpu_family())
   _drivers = [
 'kmsro', 'v3d', 'vc4', 'freedreno', 'etnaviv', 'nouveau',
-'tegra', 'virgl', 'swrast', 'panfrost'
+'tegra', 'virgl', 'swrast'
   ]
 else
   error('Unknown architecture @0@. Please pass -Dgallium-drivers to set 
driver options. Patches gladly accepted to fix this.'.format(
-- 
2.20.1

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

[Mesa-dev] [Bug 109550] [regression][amd tahiti xt] Rise of the Tomb Raider hangs the system

[bugzilla-daemon]

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

--- Comment #2 from Sylvain BERTRAND  ---
Created attachment 143295
  --> https://bugs.freedesktop.org/attachment.cgi?id=143295=edit
dmesg

-- 
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 109550] [regression][amd tahiti xt] Rise of the Tomb Raider hangs the system

[bugzilla-daemon]

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

--- Comment #1 from Sylvain BERTRAND  ---
Created attachment 143294
  --> https://bugs.freedesktop.org/attachment.cgi?id=143294=edit
xorg log

-- 
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 109550] [regression][amd tahiti xt] Rise of the Tomb Raider hangs the system

[bugzilla-daemon]

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

Sylvain BERTRAND  changed:

   What|Removed |Added

Version|unspecified |git

-- 
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 109550] [regression][amd tahiti xt] Rise of the Tomb Raider hangs the system

[bugzilla-daemon]

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

Bug ID: 109550
   Summary: [regression][amd tahiti xt] Rise of the Tomb Raider
hangs the system
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: sylvain.bertr...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

I cleared the game on 04/2018. Tested the game today with a full up to date
stack, after playing hardly a few secs, I get a system hang, video settings to
lowest. All components are from git repos of last sunday:
linux (amd-staging-drm-next), drm, llvm, mesa-gl, mesa-vulkan, xserver,
xf86-video-amdgpu.
Cannot even get any logs from the hang.

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

[bugzilla-daemon]

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

--- Comment #4 from Sylvain BERTRAND  ---
Tested Rise of the Tomb Raider : I get a system hang (I am going to report a
regression because I did clear the game on 04/2018).
No pb with dota2 vulkan, artifact (vulkan) or cs:go (opengl)
I use a gfx stack git from sunday: linux (amd-staging-drm-next), drm, llvm,
mesa-gl, mesa-vulkan, xserver, xf86-video-amdgpu

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

Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver

[Jason Ekstrand]

On Mon, Feb 4, 2019 at 6:43 PM Ilia Mirkin  wrote:

> On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand 
> wrote:
> >
> > On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig 
> wrote:
> >>
> >> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
> >> > far as I understand) basically be owning the panfrost bits in mesa,
> >> > you should be able to commit to them.
> >>
> >> Oh, thank you! :)
> >>
> >> >  1. Don't break the build
> >>
> >> Acked-by: Alyssa Rosenzweig 
> >>
> >> >  2. No merge commits
> >>
> >> Just to be clear, is the idea to just make sure everything applies
> >> cleanly / is a straightforward fast-forward, and if not, to
> rebase/squash
> >> so it does?
> >
> >
> > Roughtly?  I really did mean "no merge commits" which really just means
> linear history.  Ideally, you'd have something that roughly linearly works
> but that's a Panfrost quality thing. I'm sure there will be regressions all
> over the place as you work given that it's still a bit prototypey.
>
> An important point here is "bisectable". You shouldn't have commits
> like "fix this totally broken earlier commit in the series". Breakage
> can happen -- that's a fact of life -- but you should avoid having
> "known" breaking commits, since that will mess up bisects down the
> line.
>

Right.  I just didn't want to sound too draconian because I know what the
crazy prototype world looks like.  That said, the more linearly working and
bisectable the better.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver

[Alyssa Rosenzweig]

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

Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver

[Ilia Mirkin]

On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand  wrote:
>
> On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig  wrote:
>>
>> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
>> > far as I understand) basically be owning the panfrost bits in mesa,
>> > you should be able to commit to them.
>>
>> Oh, thank you! :)
>>
>> >  1. Don't break the build
>>
>> Acked-by: Alyssa Rosenzweig 
>>
>> >  2. No merge commits
>>
>> Just to be clear, is the idea to just make sure everything applies
>> cleanly / is a straightforward fast-forward, and if not, to rebase/squash
>> so it does?
>
>
> Roughtly?  I really did mean "no merge commits" which really just means 
> linear history.  Ideally, you'd have something that roughly linearly works 
> but that's a Panfrost quality thing. I'm sure there will be regressions all 
> over the place as you work given that it's still a bit prototypey.

An important point here is "bisectable". You shouldn't have commits
like "fix this totally broken earlier commit in the series". Breakage
can happen -- that's a fact of life -- but you should avoid having
"known" breaking commits, since that will mess up bisects down the
line.

Cheers,

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

Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver

[Jason Ekstrand]

On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig 
wrote:

> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
> > far as I understand) basically be owning the panfrost bits in mesa,
> > you should be able to commit to them.
>
> Oh, thank you! :)
>
> >  1. Don't break the build
>
> Acked-by: Alyssa Rosenzweig 
>
> >  2. No merge commits
>
> Just to be clear, is the idea to just make sure everything applies
> cleanly / is a straightforward fast-forward, and if not, to rebase/squash
> so it does?
>

Roughtly?  I really did mean "no merge commits" which really just means
linear history.  Ideally, you'd have something that roughly linearly works
but that's a Panfrost quality thing. I'm sure there will be regressions all
over the place as you work given that it's still a bit prototypey.


> >  4. Don't commit code outside of Panfrost without review from someone who
> > has a decent claim to knowing what they're talking about in that area
>
> Acked-by: Alyssa Rosenzweig 
>
> >  5. Be nice and give stake-holders (who may not be in your time zone)
> > enough time to read their e-mail and review (at least 24 hours not
> > including week-ends) before pushing anything.
>
> Acked-by: Alyssa Rosenzweig 
>
> > Inside Panfrost, it's kind-of up to the Panfrost community developers
> what
> > you want to do about review.  If you've got enough people, I highly
> > recommend you do good code review.
>
> Downstream, we've been trying to enforce proper reivew. I review other
> people's code; I haggle people to review mine; you know how it is :)
>
> Thank you again!
>
> Alyssa
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] Mesa 18.3.3 release candidate

[Eric Anholt]

Carsten Haitzler  writes:

> On Fri, 1 Feb 2019 11:08:07 + Emil Velikov  
> said:
>
>> Hi Carsten,
>> 
>> On 2019/01/31, Carsten Haitzler wrote:
>> > On Wed, 30 Jan 2019 18:33:35 + Emil Velikov 
>> > said:
>> > 
>> > You might want to hold off on this. My bugfix was actually patched out by
>> > partly removing some of it. The void ptr math should never have been there
>> > and wasn't in the final patch.
>> > 
>> > I'm talking about:
>> > 
>> > +void *cpu2 = cpu + 8;
>> > 
>> > In 300d3ae8b1445b5060f92c77c0f577f4b7b2c7d6
>> > 
>> > At least with gcc8 mesa is a dud on Raspberry Pi (can't upload/downlaod
>> > textures without crashing) without the fixes. I moved the secondary ptr 
>> > math
>> > into the ASM chunk because the C compiler seemed to just mess up cpu2 ptr
>> > content/value for me on gcc8 (it also kept the parameter inputs/outputs
>> > cleaner and consistent with other ASM chunks). Keeping this as void ptr
>> > math alone is just wrong and asking for trouble and as it unfixed a fix I
>> > already had in submitted patches.
>> > 
>> > Being at FOSDEM I now no longer have access to my OS image with all of this
>> > set up to test and won't until next week. I can't dig in and verify.
>> > Without my fixes at all it's a dead man walking with gcc8, and thus Arch
>> > Linux is broken entirely on Rpi without it (and has been for a while now).

FWIW, my testing was done on gcc 8.30 on raspberry pi.

I skipped the part of moving the C expression into the asm because it
didn't make sense, and appeared in the series before the part that
actually fixed the asm clobbers bug, so it (like the .fpu neon part)
looked like random hacks.

>> Thus from stable POV, we're safe, since nothing has regressed per se. We will
>> apply the extra patches for the next release.
>> 
>> Thanks
>> Emil
>> 
>> P.S. How did you submit the patches - I cannot see them neither on mesa-dev
>> mailing list nor gitlab MR.
>
> i mailed them to eric as he was listed as the maintainer.

I suggested an MR but said I'd accept mail, since raster didn't seem to
want to use normal channels.


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

Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver

[Alyssa Rosenzweig]

> Actually, I just gave you (Alyssa) push access... Also, as you'll (as
> far as I understand) basically be owning the panfrost bits in mesa,
> you should be able to commit to them.

Oh, thank you! :)

>  1. Don't break the build

Acked-by: Alyssa Rosenzweig 

>  2. No merge commits

Just to be clear, is the idea to just make sure everything applies
cleanly / is a straightforward fast-forward, and if not, to rebase/squash
so it does?

>  4. Don't commit code outside of Panfrost without review from someone who
> has a decent claim to knowing what they're talking about in that area

Acked-by: Alyssa Rosenzweig 

>  5. Be nice and give stake-holders (who may not be in your time zone)
> enough time to read their e-mail and review (at least 24 hours not
> including week-ends) before pushing anything.

Acked-by: Alyssa Rosenzweig 

> Inside Panfrost, it's kind-of up to the Panfrost community developers what
> you want to do about review.  If you've got enough people, I highly
> recommend you do good code review.

Downstream, we've been trying to enforce proper reivew. I review other
people's code; I haggle people to review mine; you know how it is :)

Thank you again!

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

Re: [Mesa-dev] [PATCH 2/2] panfrost: Implement Midgard shader toolchain

[Alyssa Rosenzweig]

> Top of src/util/ralloc.h?

Ah-ha, thank you! Suddenly mesa makes so much more sense :)

> Counting uniforms/attributes is all a confusing mess.  I can confirm
> that what I do in v3d works, I just can't explain how without going and
> re-studying it.

Alright, I'll look there, thank you :)

> Basically the only thing I have any concern about is allowing
> end-user/distro builds of a panfrost_dri.so that doesn't actually work
> (so, some day when panfrost.ko shows up upstream, suddenly the loader
> starts trying to load this panfrost_dri.so and things break).

So, if I indefinitely remove panfrost from the ARM 'auto' list in
meson.build, this should be mitigated, yes?

Thanks,

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

Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver

[Jason Ekstrand]

On Mon, Feb 4, 2019 at 3:13 PM Rob Herring  wrote:

> On Sun, Feb 3, 2019 at 9:33 PM Alyssa Rosenzweig 
> wrote:
> >
> > > You should just land it and start doing in-tree development!
> >
> > I don't have push access, you know :P
>
> I can push it if you don't want to go the MR route. That goes for
> subsequent changes too.
>

Actually, I just gave you (Alyssa) push access.  You haven't hit the usual
2-dozen commit threshold in mesa main yet but that's because you've been
working (very actively!) out-of-tree.  I figure you'll hit that threshold
very quickly once you start working in-tree.  Also, as you'll (as far as I
understand) basically be owning the panfrost bits in mesa, you should be
able to commit to them.  Please drink responsibly, don't run with scissors
(unless they're the GL kind), and remember a few basic merging rules:

 1. Don't break the build
 2. No merge commits
 3. Write good commit messages with reasonable prefixes (such as "panfrost:
Implement clip planes for vertex shaders")
 4. Don't commit code outside of Panfrost without review from someone who
has a decent claim to knowing what they're talking about in that area
 5. Be nice and give stake-holders (who may not be in your time zone)
enough time to read their e-mail and review (at least 24 hours not
including week-ends) before pushing anything.

Inside Panfrost, it's kind-of up to the Panfrost community developers what
you want to do about review.  If you've got enough people, I highly
recommend you do good code review.  If it's really just you hacking on the
compiler, then maybe review isn't practical.

Happy hacking and welcome to the mesa tree!

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

Re: [Mesa-dev] [PATCH v3 2/3] nir: add nir_opt_vectorize_io()

[Jason Ekstrand]

On Mon, Nov 5, 2018 at 8:58 PM Timothy Arceri  wrote:

> Once linking opts are done this pass recombines varying components.
>
> This patch is loosely based on Connor's vectorize alu pass.
>
> V2: skip fragment shaders
>
> V3:
> - dont accidentally vectorise local vars
> - pass correct component to create_new_store()
> ---
>  src/compiler/Makefile.sources   |   1 +
>  src/compiler/nir/meson.build|   1 +
>  src/compiler/nir/nir.h  |   2 +
>  src/compiler/nir/nir_opt_vectorize_io.c | 527 
>  4 files changed, 531 insertions(+)
>  create mode 100644 src/compiler/nir/nir_opt_vectorize_io.c
>
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index ae170f02e82..5991df5a61c 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -290,6 +290,7 @@ NIR_FILES = \
> nir/nir_opt_shrink_load.c \
> nir/nir_opt_trivial_continues.c \
> nir/nir_opt_undef.c \
> +   nir/nir_opt_vectorize_io.c \
> nir/nir_phi_builder.c \
> nir/nir_phi_builder.h \
> nir/nir_print.c \
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index b0c3a7feb31..9555cc40e21 100644
> --- a/src/compiler/nir/meson.build
> +++ b/src/compiler/nir/meson.build
> @@ -174,6 +174,7 @@ files_libnir = files(
>'nir_opt_shrink_load.c',
>'nir_opt_trivial_continues.c',
>'nir_opt_undef.c',
> +  'nir_opt_vectorize_io.c',
>'nir_phi_builder.c',
>'nir_phi_builder.h',
>'nir_print.c',
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index a0ae9a4430e..79bbdedaf00 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -3105,6 +3105,8 @@ bool nir_opt_trivial_continues(nir_shader *shader);
>
>  bool nir_opt_undef(nir_shader *shader);
>
> +bool nir_opt_vectorize_io(nir_shader *shader, bool skip_fs_inputs);
> +
>  bool nir_opt_conditional_discard(nir_shader *shader);
>
>  void nir_sweep(nir_shader *shader);
> diff --git a/src/compiler/nir/nir_opt_vectorize_io.c
> b/src/compiler/nir/nir_opt_vectorize_io.c
> new file mode 100644
> index 000..c2ab30d307b
> --- /dev/null
> +++ b/src/compiler/nir/nir_opt_vectorize_io.c
> @@ -0,0 +1,527 @@
> +/*
> + * Copyright © 2018 Timothy Arceri
> + *
> + * 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,
> sublicense,
> + * 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 NONINFRINGEMENT.  IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS 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 "nir.h"
> +#include "nir_builder.h"
> +#include "nir_deref.h"
> +#include "util/u_dynarray.h"
> +#include "util/u_math.h"
> +
> +/** @file nir_opt_vectorize_io.c
> + *
> + * Replaces scalar nir_load_input/nir_store_output operations with
> + * vectorized instructions.
> + */
> +
> +static bool
> +is_io_load(nir_intrinsic_instr *intr)
> +{
> +   switch (intr->intrinsic) {
> +   case nir_intrinsic_interp_deref_at_centroid:
> +   case nir_intrinsic_interp_deref_at_sample:
> +   case nir_intrinsic_interp_deref_at_offset:
> +   case nir_intrinsic_load_deref:
> +  return true;
> +   default:
> +  return false;
> +   }
> +}
> +
> +static nir_deref_instr *
> +clone_deref_array(nir_builder *b, nir_deref_instr *dst_tail,
> +  const nir_deref_instr *src_head)
> +{
> +   const nir_deref_instr *parent = nir_deref_instr_parent(src_head);
> +
> +   if (!parent)
> +  return dst_tail;
> +
> +   assert(src_head->deref_type == nir_deref_type_array);
> +
> +   dst_tail = clone_deref_array(b, dst_tail, parent);
> +
> +   return nir_build_deref_array(b, dst_tail,
> +nir_ssa_for_src(b, src_head->arr.index,
> 1));
> +}
> +
> +static bool
> +instr_can_rewrite(nir_instr *instr)
> +{
> +   if (instr->type != nir_instr_type_intrinsic)
> +  return false;
> +
> +   nir_intrinsic_instr *intr = nir_instr_as_intrinsic(instr);
> +
> +   if (intr->num_components != 1)
> +  return false;
> +
> +   if (!is_io_load(intr) &&
> +  

Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver

[Rob Herring]

On Sun, Feb 3, 2019 at 9:33 PM Alyssa Rosenzweig  wrote:
>
> > You should just land it and start doing in-tree development!
>
> I don't have push access, you know :P

I can push it if you don't want to go the MR route. That goes for
subsequent changes too.

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

[Mesa-dev] [PATCH] meson: link LLVM 'native' component when LLVM is available

[Nicolai Hähnle]

From: Nicolai Hähnle 

It is required for the draw module, and makes a difference when
linking statically or against LLVM built with BUILD_SHARED_LIBS=ON.
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index bfff862c3c8..e955bdedcc6 100644
--- a/meson.build
+++ b/meson.build
@@ -1164,21 +1164,21 @@ dep_libdrm = dependency(
   'libdrm', version : '>=' + _drm_ver,
   required : with_dri2 or with_dri3
 )
 if dep_libdrm.found()
   pre_args += '-DHAVE_LIBDRM'
   if with_dri_platform == 'drm' and with_dri
 with_gallium_drisw_kms = true
   endif
 endif
 
-llvm_modules = ['bitwriter', 'engine', 'mcdisassembler', 'mcjit']
+llvm_modules = ['bitwriter', 'engine', 'mcdisassembler', 'mcjit', 'native']
 llvm_optional_modules = []
 if with_amd_vk or with_gallium_radeonsi or with_gallium_r600
   llvm_modules += ['amdgpu', 'native', 'bitreader', 'ipo']
   if with_gallium_r600
 llvm_modules += 'asmparser'
   endif
 endif
 if with_gallium_opencl
   llvm_modules += [
 'all-targets', 'linker', 'coverage', 'instrumentation', 'ipo', 'irreader',
-- 
2.19.1

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

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

[bugzilla-daemon]

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

--- Comment #3 from mikhail.v.gavri...@gmail.com ---
(In reply to Samuel Pitoiset from comment #2)
> It seems like we can't reproduce the problem. Where your mesa comes from?

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

-- 
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 v3 1/3] nir: add glsl_replace_vector_type()

[Jason Ekstrand]

On Mon, Nov 5, 2018 at 8:58 PM Timothy Arceri  wrote:

> This creates a new glsl_type with the specified number on components.
>
> We will use this in the following patch when vectorising io.
> ---
>  src/compiler/nir_types.cpp | 24 
>  src/compiler/nir_types.h   |  2 ++
>  2 files changed, 26 insertions(+)
>
> diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
> index d24f0941519..45a06e0214b 100644
> --- a/src/compiler/nir_types.cpp
> +++ b/src/compiler/nir_types.cpp
> @@ -432,6 +432,30 @@ glsl_array_type(const glsl_type *base, unsigned
> elements)
> return glsl_type::get_array_instance(base, elements);
>  }
>
> +const glsl_type *
> +glsl_replace_vector_type(const glsl_type *t, unsigned components)
>

On the one hand, this doesn't seem incredibly generic.  On the other hand,
I seem to recall having written this function before


> +{
> +   switch (glsl_get_base_type(t)) {
> +   case GLSL_TYPE_ARRAY: {
> +  const glsl_type *base = glsl_replace_vector_type(t->fields.array,
> components);
> +  return glsl_array_type(base, glsl_get_length(t));
> +   }
> +   case GLSL_TYPE_UINT:
> +   case GLSL_TYPE_INT:
> +   case GLSL_TYPE_FLOAT:
> +   case GLSL_TYPE_BOOL:
> +   case GLSL_TYPE_DOUBLE:
> +   case GLSL_TYPE_UINT64:
> +   case GLSL_TYPE_INT64:
> +   case GLSL_TYPE_FLOAT16:
> +   case GLSL_TYPE_UINT16:
> +   case GLSL_TYPE_INT16:
> +  return glsl_vector_type(glsl_get_base_type(t), components);
>

Would it be better to just do:

if (glsl_type_is_array(t)) {
   return glsl_array_type(glsl_replace_vector_type(t->fields.array),
t->length);
} else if (glsl_type_is_vector_or_scalar(t)) {
   return glsl_vector_type(t->base_type, components);
} else {
   unreachable();
}

That way we don't accidentally forget to add new scalar cases (INT8 is
coming!) and we ensure that the matrix case (currently unhandled) hits the
unreachable?

--Jason


> +   default:
> +  unreachable("Unhandled base type glsl_replace_vector_type()");
> +   }
> +}
> +
>  const glsl_type *
>  glsl_struct_type(const glsl_struct_field *fields,
>   unsigned num_fields, const char *name)
> diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
> index 77454fa9fab..deb7ead8dd2 100644
> --- a/src/compiler/nir_types.h
> +++ b/src/compiler/nir_types.h
> @@ -167,6 +167,8 @@ const struct glsl_type *glsl_bool_type(void);
>  const struct glsl_type *glsl_scalar_type(enum glsl_base_type base_type);
>  const struct glsl_type *glsl_vector_type(enum glsl_base_type base_type,
>   unsigned components);
> +const struct glsl_type * glsl_replace_vector_type(const struct glsl_type
> *t,
> +  unsigned components);
>  const struct glsl_type *glsl_matrix_type(enum glsl_base_type base_type,
>   unsigned rows, unsigned columns);
>  const struct glsl_type *glsl_array_type(const struct glsl_type *base,
> --
> 2.19.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

--- Comment #2 from Samuel Pitoiset  ---
It seems like we can't reproduce the problem. Where your mesa comes from?

-- 
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 3/6] gallium\auxiliary\vl: Add compute shader to support video compositor render

[Koenig, Christian]

Am 04.02.19 um 20:20 schrieb Zhu, James:
> On 2019-02-04 2:15 p.m., Christian König wrote:
>> Am 04.02.19 um 20:12 schrieb James Zhu:
>>> On 2019-02-04 1:47 p.m., Liu, Leo wrote:
 On 2/1/19 11:28 AM, Zhu, James wrote:
> Add compute shader to support video compositor render.
>
> Signed-off-by: James Zhu 
> ---
>      src/gallium/auxiliary/Makefile.sources  |   2 +
>      src/gallium/auxiliary/meson.build   |   2 +
>      src/gallium/auxiliary/vl/vl_compositor_cs.c | 414
> 
>      src/gallium/auxiliary/vl/vl_compositor_cs.h |  56 
>      4 files changed, 474 insertions(+)
>      create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.c
>      create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.h
>
> diff --git a/src/gallium/auxiliary/Makefile.sources
> b/src/gallium/auxiliary/Makefile.sources
> index 50e8808..df000f6 100644
> --- a/src/gallium/auxiliary/Makefile.sources
> +++ b/src/gallium/auxiliary/Makefile.sources
> @@ -348,6 +348,8 @@ VL_SOURCES := \
>      vl/vl_bicubic_filter.h \
>      vl/vl_compositor.c \
>      vl/vl_compositor.h \
> +    vl/vl_compositor_cs.c \
> +    vl/vl_compositor_cs.h \
>      vl/vl_csc.c \
>      vl/vl_csc.h \
>      vl/vl_decoder.c \
> diff --git a/src/gallium/auxiliary/meson.build
> b/src/gallium/auxiliary/meson.build
> index 57f7e69..74e4b48 100644
> --- a/src/gallium/auxiliary/meson.build
> +++ b/src/gallium/auxiliary/meson.build
> @@ -445,6 +445,8 @@ files_libgalliumvl = files(
>    'vl/vl_bicubic_filter.h',
>    'vl/vl_compositor.c',
>    'vl/vl_compositor.h',
> +  'vl/vl_compositor_cs.c',
> +  'vl/vl_compositor_cs.h',
>    'vl/vl_csc.c', (refer to MI100 frame capture feature with
> computer shader support)
>    'vl/vl_csc.h',
>    'vl/vl_decoder.c',
> diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c
> b/src/gallium/auxiliary/vl/vl_compositor_cs.c
> new file mode 100644
> index 000..3cd1a76
> --- /dev/null
> +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c
> @@ -0,0 +1,414 @@
> +/**
>
> + *
> + * Copyright 2019 Advanced Micro Devices, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person
> obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction,
> including
> + * without limitation the rights to use, copy, modify, merge,
> publish,
> + * distribute, sub license, and/or sell copies of the Software,
> and to
> + * permit persons to whom the Software is furnished to do so,
> subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice
> (including the
> + * next paragraph) shall be included in all copies or substantial
> portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> NON-INFRINGEMENT.
> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
> CONTRACT,
> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: James Zhu 
> + *
> +
> **/
> +
> +#include 
> +
> +#include "tgsi/tgsi_text.h"
> +#include "vl_compositor_cs.h"
> +
> +struct cs_viewport {
> +   float scale_x;
> +   float scale_y;
> +   int translate_x;
> +   int translate_y;
> +   struct u_rect area;
> +};
> +
> +char *compute_shader_video_buffer =
> +  "COMP\n"
> +  "PROPERTY CS_FIXED_BLOCK_WIDTH 8\n"
> +  "PROPERTY CS_FIXED_BLOCK_HEIGHT 8\n"
> +  "PROPERTY CS_FIXED_BLOCK_DEPTH 1\n"
> +
> +  "DCL SV[0], THREAD_ID\n"
> +  "DCL SV[1], BLOCK_ID\n"
> +
> +  "DCL CONST[0..5]\n"
> +  "DCL SVIEW[0..2], RECT, FLOAT\n"
> +  "DCL SAMP[0..2]\n"
> +
> +  "DCL IMAGE[0], 2D, WR\n"
> +  "DCL TEMP[0..7]\n"
> +
> +  "IMM[0] UINT32 { 8, 8, 1, 0}\n"
> +  "IMM[1] FLT32 { 1.0, 2.0, 0.0, 0.0}\n"
> +
> +  "UMAD TEMP[0], SV[1], IMM[0], SV[0]\n"
> +
> +  /* Drawn area check */
> +  "USGE TEMP[1].xy, TEMP[0].xyxy, CONST[4].xyxy\n"
> +  "USLT TEMP[1].zw, TEMP[0].xyxy, 

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

[James Zhu]

On 2019-02-04 2:15 p.m., Christian König wrote:
> Am 04.02.19 um 20:12 schrieb James Zhu:
>> On 2019-02-04 1:47 p.m., Liu, Leo wrote:
>>> On 2/1/19 11:28 AM, Zhu, James wrote:
 Add compute shader to support video compositor render.

 Signed-off-by: James Zhu 
 ---
     src/gallium/auxiliary/Makefile.sources  |   2 +
     src/gallium/auxiliary/meson.build   |   2 +
     src/gallium/auxiliary/vl/vl_compositor_cs.c | 414 
 
     src/gallium/auxiliary/vl/vl_compositor_cs.h |  56 
     4 files changed, 474 insertions(+)
     create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.c
     create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.h

 diff --git a/src/gallium/auxiliary/Makefile.sources 
 b/src/gallium/auxiliary/Makefile.sources
 index 50e8808..df000f6 100644
 --- a/src/gallium/auxiliary/Makefile.sources
 +++ b/src/gallium/auxiliary/Makefile.sources
 @@ -348,6 +348,8 @@ VL_SOURCES := \
     vl/vl_bicubic_filter.h \
     vl/vl_compositor.c \
     vl/vl_compositor.h \
 +    vl/vl_compositor_cs.c \
 +    vl/vl_compositor_cs.h \
     vl/vl_csc.c \
     vl/vl_csc.h \
     vl/vl_decoder.c \
 diff --git a/src/gallium/auxiliary/meson.build 
 b/src/gallium/auxiliary/meson.build
 index 57f7e69..74e4b48 100644
 --- a/src/gallium/auxiliary/meson.build
 +++ b/src/gallium/auxiliary/meson.build
 @@ -445,6 +445,8 @@ files_libgalliumvl = files(
   'vl/vl_bicubic_filter.h',
   'vl/vl_compositor.c',
   'vl/vl_compositor.h',
 +  'vl/vl_compositor_cs.c',
 +  'vl/vl_compositor_cs.h',
   'vl/vl_csc.c', (refer to MI100 frame capture feature with 
 computer shader support)
   'vl/vl_csc.h',
   'vl/vl_decoder.c',
 diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c 
 b/src/gallium/auxiliary/vl/vl_compositor_cs.c
 new file mode 100644
 index 000..3cd1a76
 --- /dev/null
 +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c
 @@ -0,0 +1,414 @@
 +/**
  

 + *
 + * Copyright 2019 Advanced Micro Devices, Inc.
 + * All Rights Reserved.
 + *
 + * Permission is hereby granted, free of charge, to any person 
 obtaining a
 + * copy of this software and associated documentation files (the
 + * "Software"), to deal in the Software without restriction, 
 including
 + * without limitation the rights to use, copy, modify, merge, 
 publish,
 + * distribute, sub license, and/or sell copies of the Software, 
 and to
 + * permit persons to whom the Software is furnished to do so, 
 subject to
 + * the following conditions:
 + *
 + * The above copyright notice and this permission notice 
 (including the
 + * next paragraph) shall be included in all copies or substantial 
 portions
 + * of the Software.
 + *
 + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
 EXPRESS
 + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
 NON-INFRINGEMENT.
 + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
 + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF 
 CONTRACT,
 + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 + *
 + * Authors: James Zhu 
 + *
 + 
 **/
 +
 +#include 
 +
 +#include "tgsi/tgsi_text.h"
 +#include "vl_compositor_cs.h"
 +
 +struct cs_viewport {
 +   float scale_x;
 +   float scale_y;
 +   int translate_x;
 +   int translate_y;
 +   struct u_rect area;
 +};
 +
 +char *compute_shader_video_buffer =
 +  "COMP\n"
 +  "PROPERTY CS_FIXED_BLOCK_WIDTH 8\n"
 +  "PROPERTY CS_FIXED_BLOCK_HEIGHT 8\n"
 +  "PROPERTY CS_FIXED_BLOCK_DEPTH 1\n"
 +
 +  "DCL SV[0], THREAD_ID\n"
 +  "DCL SV[1], BLOCK_ID\n"
 +
 +  "DCL CONST[0..5]\n"
 +  "DCL SVIEW[0..2], RECT, FLOAT\n"
 +  "DCL SAMP[0..2]\n"
 +
 +  "DCL IMAGE[0], 2D, WR\n"
 +  "DCL TEMP[0..7]\n"
 +
 +  "IMM[0] UINT32 { 8, 8, 1, 0}\n"
 +  "IMM[1] FLT32 { 1.0, 2.0, 0.0, 0.0}\n"
 +
 +  "UMAD TEMP[0], SV[1], IMM[0], SV[0]\n"
 +
 +  /* Drawn area check */
 +  "USGE TEMP[1].xy, TEMP[0].xyxy, CONST[4].xyxy\n"
 +  "USLT TEMP[1].zw, TEMP[0].xyxy, CONST[4].zwzw\n"
 +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
 +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
 +  "AND TEMP[1].x, 

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

[Christian König]

Am 04.02.19 um 20:12 schrieb James Zhu:

On 2019-02-04 1:47 p.m., Liu, Leo wrote:

On 2/1/19 11:28 AM, Zhu, James wrote:

Add compute shader to support video compositor render.

Signed-off-by: James Zhu 
---
src/gallium/auxiliary/Makefile.sources  |   2 +
src/gallium/auxiliary/meson.build   |   2 +
src/gallium/auxiliary/vl/vl_compositor_cs.c | 414 

src/gallium/auxiliary/vl/vl_compositor_cs.h |  56 
4 files changed, 474 insertions(+)
create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.c
create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.h

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

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

[James Zhu]

On 2019-02-04 1:47 p.m., Liu, Leo wrote:
> On 2/1/19 11:28 AM, Zhu, James wrote:
>> Add compute shader to support video compositor render.
>>
>> Signed-off-by: James Zhu 
>> ---
>>src/gallium/auxiliary/Makefile.sources  |   2 +
>>src/gallium/auxiliary/meson.build   |   2 +
>>src/gallium/auxiliary/vl/vl_compositor_cs.c | 414 
>> 
>>src/gallium/auxiliary/vl/vl_compositor_cs.h |  56 
>>4 files changed, 474 insertions(+)
>>create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.c
>>create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.h
>>
>> diff --git a/src/gallium/auxiliary/Makefile.sources 
>> b/src/gallium/auxiliary/Makefile.sources
>> index 50e8808..df000f6 100644
>> --- a/src/gallium/auxiliary/Makefile.sources
>> +++ b/src/gallium/auxiliary/Makefile.sources
>> @@ -348,6 +348,8 @@ VL_SOURCES := \
>>  vl/vl_bicubic_filter.h \
>>  vl/vl_compositor.c \
>>  vl/vl_compositor.h \
>> +vl/vl_compositor_cs.c \
>> +vl/vl_compositor_cs.h \
>>  vl/vl_csc.c \
>>  vl/vl_csc.h \
>>  vl/vl_decoder.c \
>> diff --git a/src/gallium/auxiliary/meson.build 
>> b/src/gallium/auxiliary/meson.build
>> index 57f7e69..74e4b48 100644
>> --- a/src/gallium/auxiliary/meson.build
>> +++ b/src/gallium/auxiliary/meson.build
>> @@ -445,6 +445,8 @@ files_libgalliumvl = files(
>>  'vl/vl_bicubic_filter.h',
>>  'vl/vl_compositor.c',
>>  'vl/vl_compositor.h',
>> +  'vl/vl_compositor_cs.c',
>> +  'vl/vl_compositor_cs.h',
>>  'vl/vl_csc.c',
>>  'vl/vl_csc.h',
>>  'vl/vl_decoder.c',
>> diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c 
>> b/src/gallium/auxiliary/vl/vl_compositor_cs.c
>> new file mode 100644
>> index 000..3cd1a76
>> --- /dev/null
>> +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c
>> @@ -0,0 +1,414 @@
>> +/**
>> + *
>> + * Copyright 2019 Advanced Micro Devices, Inc.
>> + * All Rights Reserved.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the
>> + * "Software"), to deal in the Software without restriction, including
>> + * without limitation the rights to use, copy, modify, merge, publish,
>> + * distribute, sub license, and/or sell copies of the Software, and to
>> + * permit persons to whom the Software is furnished to do so, subject to
>> + * the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the
>> + * next paragraph) shall be included in all copies or substantial portions
>> + * of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
>> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
>> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
>> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
>> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
>> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>> + *
>> + * Authors: James Zhu 
>> + *
>> + **/
>> +
>> +#include 
>> +
>> +#include "tgsi/tgsi_text.h"
>> +#include "vl_compositor_cs.h"
>> +
>> +struct cs_viewport {
>> +   float scale_x;
>> +   float scale_y;
>> +   int translate_x;
>> +   int translate_y;
>> +   struct u_rect area;
>> +};
>> +
>> +char *compute_shader_video_buffer =
>> +  "COMP\n"
>> +  "PROPERTY CS_FIXED_BLOCK_WIDTH 8\n"
>> +  "PROPERTY CS_FIXED_BLOCK_HEIGHT 8\n"
>> +  "PROPERTY CS_FIXED_BLOCK_DEPTH 1\n"
>> +
>> +  "DCL SV[0], THREAD_ID\n"
>> +  "DCL SV[1], BLOCK_ID\n"
>> +
>> +  "DCL CONST[0..5]\n"
>> +  "DCL SVIEW[0..2], RECT, FLOAT\n"
>> +  "DCL SAMP[0..2]\n"
>> +
>> +  "DCL IMAGE[0], 2D, WR\n"
>> +  "DCL TEMP[0..7]\n"
>> +
>> +  "IMM[0] UINT32 { 8, 8, 1, 0}\n"
>> +  "IMM[1] FLT32 { 1.0, 2.0, 0.0, 0.0}\n"
>> +
>> +  "UMAD TEMP[0], SV[1], IMM[0], SV[0]\n"
>> +
>> +  /* Drawn area check */
>> +  "USGE TEMP[1].xy, TEMP[0].xyxy, CONST[4].xyxy\n"
>> +  "USLT TEMP[1].zw, TEMP[0].xyxy, CONST[4].zwzw\n"
>> +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
>> +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
>> +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
>> +
>> +  "UIF TEMP[1]\n"
>> + /* Translate */
>> + "UADD TEMP[2].xy, TEMP[0], -CONST[5].xyxy\n"
>> + "U2F TEMP[2], TEMP[2]\n"
>> + "DIV TEMP[3], TEMP[2], IMM[1].\n"
>> +
>> + /* Scale */
>> + "DIV TEMP[2], TEMP[2], CONST[3].zwzw\n"
>> + "DIV TEMP[3], TEMP[3], CONST[3].zwzw\n"
>> +
>> + /* Fetch texels */
>> + "TEX_LZ TEMP[4].x, TEMP[2], SAMP[0], RECT\n"
>> + "TEX_LZ TEMP[4].y, TEMP[3], SAMP[1], 

Re: [Mesa-dev] [PATCH] intel/compiler: update validator to account for half-float exec type promotion

[Francisco Jerez]

Iago Toral  writes:

> On Mon, 2019-02-04 at 08:50 +0100, Iago Toral wrote:
>> On Fri, 2019-02-01 at 11:23 -0800, Francisco Jerez wrote:
>> > Iago Toral  writes:
>> > 
>> > > On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote:
>> > > > Iago Toral  writes:
>> > > > 
>> > > > > On Thu, 2019-01-24 at 11:45 -0800, Francisco Jerez wrote:
>> > > > > > Iago Toral  writes:
>> > > > > > 
>> > > > > > > On Wed, 2019-01-23 at 06:03 -0800, Francisco Jerez wrote:
>> > > > > > > > Iago Toral Quiroga  writes:
>> > > > > > > > 
>> > > > > > > > > Commit c84ec70b3a72 implemented execution type
>> > > > > > > > > promotion to
>> > > > > > > > > 32-
>> > > > > > > > > bit
>> > > > > > > > > for
>> > > > > > > > > conversions involving half-float registers, which
>> > > > > > > > > empirical
>> > > > > > > > > testing
>> > > > > > > > > suggested
>> > > > > > > > > was required, but it did not incorporate this change
>> > > > > > > > > into
>> > > > > > > > > the
>> > > > > > > > > assembly validator
>> > > > > > > > > logic. This commits adds that, preventing validation
>> > > > > > > > > errors
>> > > > > > > > > like
>> > > > > > > > > this:
>> > > > > > > > > 
>> > > > > > > > 
>> > > > > > > > I don't think we should be validating empirical
>> > > > > > > > assumptions
>> > > > > > > > in
>> > > > > > > > the EU
>> > > > > > > > validator.
>> > > > > > > 
>> > > > > > > I am not sure I get your point, isn't c84ec70b3a72 also
>> > > > > > > based
>> > > > > > > on
>> > > > > > > empirical testing after all?
>> > > > > > > 
>> > > > > > 
>> > > > > > To some extent, but it doesn't attempt to enforce ISA
>> > > > > > restrictions
>> > > > > > based
>> > > > > > on information obtained empirically.
>> > > > > > 
>> > > > > > > 
>> > > > > > > > > mov(16)  g9<4>B   g3<16,8,2>HF { align1 1H };
>> > > > > > > > > ERROR: Destination stride must be equal to the ratio
>> > > > > > > > > of
>> > > > > > > > > the
>> > > > > > > > > sizes
>> > > > > > > > > of the
>> > > > > > > > >execution data type to the destination type
>> > > > > > > > > 
>> > > > > > > > > Fixes: c84ec70b3a72 "intel/fs: Promote execution type
>> > > > > > > > > to
>> > > > > > > > > 32-bit
>> > > > > > > > > when any half-float conversion is needed."
>> > > > > > > > 
>> > > > > > > > I don't think this "fixes" anything that ever worked.
>> > > > > > > 
>> > > > > > > It is true that the code in that trace above is not
>> > > > > > > something
>> > > > > > > we
>> > > > > > > can
>> > > > > > > produce right now, because it is a conversion from HF to
>> > > > > > > B
>> > > > > > > and
>> > > > > > > that
>> > > > > > > should only happen within the context of
>> > > > > > > VK_KHR_shader_float16_int8,
>> > > > > > > however, this is a consequence of the fact that since
>> > > > > > > c84ec70b3a72
>> > > > > > > there is an inconsistency between what we do at the IR
>> > > > > > > level
>> > > > > > > regarding
>> > > > > > > execution size of HF conversions and what the EU
>> > > > > > > validator
>> > > > > > > is
>> > > > > > > doing,
>> > > > > > > and from that perspective this is really fixing an
>> > > > > > > inconsistency
>> > > > > > > that
>> > > > > > > didn't exist before, and I thought we would want to
>> > > > > > > address
>> > > > > > > that
>> > > > > > > sooner
>> > > > > > > rather than later and track it down to the original
>> > > > > > > change
>> > > > > > > that
>> > > > > > > introduced that inconsistency so we know where this is
>> > > > > > > coming
>> > > > > > > from.
>> > > > > > > 
>> > > > > > 
>> > > > > > The "inconsistency" between the IR's get_exec_type() and
>> > > > > > the
>> > > > > > EU
>> > > > > > validator's execution_type() has existed ever since
>> > > > > > a05b6f25bf4bfad7
>> > > > > > removed the HF assert from get_exec_type() without actually
>> > > > > > implementing
>> > > > > > the code required to handle HF operands (which is what my
>> > > > > > commit
>> > > > > > c84ec70b3a72 did).
>> > > > > 
>> > > > > I agree with the fact that since a05b6f25bf4bfad7 the
>> > > > > validator
>> > > > > could
>> > > > > reject valid code and that had nothing to do with your patch,
>> > > > 
>> > > > The validator rejected the same valid HF code since it was
>> > > > written,
>> > > > that
>> > > > had nothing to do with neither a05b6f25bf4bfad7 nor with my
>> > > > patch,
>> > > > and
>> > > > it is the real problem this patch was working around.
>> > > > 
>> > > > > but the inconsistency I am talking about here, that this
>> > > > > patch
>> > > > > fixes,
>> > > > > is the one about get_exec_type() in the IR and
>> > > > > execution_type()
>> > > > > in
>> > > > > the
>> > > > > validator doing different things for HF instructions, which
>> > > > > only
>> > > > > exists since your patch and which you discuss below.
>> > > > > 
>> > > > 
>> > > > The "inconsistency" exists ever since get_exec_type() was
>> > > > introduced
>> > > > without correct handling of HF types (even though
>> > > > 

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

[Liu, Leo]

On 2/1/19 11:38 AM, Christian König wrote:
> Am 01.02.19 um 17:28 schrieb Zhu, James:
>> Add video compute shader render. export CS_COMPOSITOR_RENDER=true
>> to enable video compute shader render.
>
> Ok that actually makes more sense, but I would either put everything 
> into one file or cleanly separate between gfx and compute implementation.

Agreed.

Leo


>
> Christian.
>
>>
>> Signed-off-by: James Zhu 
>> ---
>>   src/gallium/auxiliary/vl/vl_compositor.c | 19 +--
>>   1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
>> b/src/gallium/auxiliary/vl/vl_compositor.c
>> index 7ee8402..66a8fc9 100644
>> --- a/src/gallium/auxiliary/vl/vl_compositor.c
>> +++ b/src/gallium/auxiliary/vl/vl_compositor.c
>> @@ -1376,8 +1376,8 @@ vl_compositor_convert_rgb_to_yuv(struct 
>> vl_compositor_state *s,
>>  s->pipe->flush(s->pipe, NULL, 0);
>>   }
>>   -void
>> -vl_compositor_render(struct vl_compositor_state *s,
>> +static void
>> +vl_compositor_gfx_render(struct vl_compositor_state *s,
>>    struct vl_compositor   *c,
>>    struct pipe_surface    *dst_surface,
>>    struct u_rect  *dirty_area,
>> @@ -1419,6 +1419,21 @@ vl_compositor_render(struct 
>> vl_compositor_state *s,
>>  draw_layers(c, s, dirty_area);
>>   }
>>   +void
>> +vl_compositor_render(struct vl_compositor_state *s,
>> + struct vl_compositor   *c,
>> + struct pipe_surface    *dst_surface,
>> + struct u_rect  *dirty_area,
>> + bool    clear_dirty)
>> +{
>> +   assert(s);
>> +
>> +   if (cs_compositor_render_enable && s->layers->cs)
>> +  vl_compositor_cs_render(s, c, dst_surface, dirty_area, 
>> clear_dirty);
>> +   else
>> +  vl_compositor_gfx_render(s, c, dst_surface, dirty_area, 
>> clear_dirty);
>> +}
>> +
>>   bool
>>   vl_compositor_init(struct vl_compositor *c, struct pipe_context *pipe)
>>   {
>
> ___
> 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 3/6] gallium\auxiliary\vl: Add compute shader to support video compositor render

[Liu, Leo]

On 2/1/19 11:28 AM, Zhu, James wrote:
> Add compute shader to support video compositor render.
>
> Signed-off-by: James Zhu 
> ---
>   src/gallium/auxiliary/Makefile.sources  |   2 +
>   src/gallium/auxiliary/meson.build   |   2 +
>   src/gallium/auxiliary/vl/vl_compositor_cs.c | 414 
> 
>   src/gallium/auxiliary/vl/vl_compositor_cs.h |  56 
>   4 files changed, 474 insertions(+)
>   create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.c
>   create mode 100644 src/gallium/auxiliary/vl/vl_compositor_cs.h
>
> diff --git a/src/gallium/auxiliary/Makefile.sources 
> b/src/gallium/auxiliary/Makefile.sources
> index 50e8808..df000f6 100644
> --- a/src/gallium/auxiliary/Makefile.sources
> +++ b/src/gallium/auxiliary/Makefile.sources
> @@ -348,6 +348,8 @@ VL_SOURCES := \
>   vl/vl_bicubic_filter.h \
>   vl/vl_compositor.c \
>   vl/vl_compositor.h \
> + vl/vl_compositor_cs.c \
> + vl/vl_compositor_cs.h \
>   vl/vl_csc.c \
>   vl/vl_csc.h \
>   vl/vl_decoder.c \
> diff --git a/src/gallium/auxiliary/meson.build 
> b/src/gallium/auxiliary/meson.build
> index 57f7e69..74e4b48 100644
> --- a/src/gallium/auxiliary/meson.build
> +++ b/src/gallium/auxiliary/meson.build
> @@ -445,6 +445,8 @@ files_libgalliumvl = files(
> 'vl/vl_bicubic_filter.h',
> 'vl/vl_compositor.c',
> 'vl/vl_compositor.h',
> +  'vl/vl_compositor_cs.c',
> +  'vl/vl_compositor_cs.h',
> 'vl/vl_csc.c',
> 'vl/vl_csc.h',
> 'vl/vl_decoder.c',
> diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c 
> b/src/gallium/auxiliary/vl/vl_compositor_cs.c
> new file mode 100644
> index 000..3cd1a76
> --- /dev/null
> +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c
> @@ -0,0 +1,414 @@
> +/**
> + *
> + * Copyright 2019 Advanced Micro Devices, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: James Zhu 
> + *
> + **/
> +
> +#include 
> +
> +#include "tgsi/tgsi_text.h"
> +#include "vl_compositor_cs.h"
> +
> +struct cs_viewport {
> +   float scale_x;
> +   float scale_y;
> +   int translate_x;
> +   int translate_y;
> +   struct u_rect area;
> +};
> +
> +char *compute_shader_video_buffer =
> +  "COMP\n"
> +  "PROPERTY CS_FIXED_BLOCK_WIDTH 8\n"
> +  "PROPERTY CS_FIXED_BLOCK_HEIGHT 8\n"
> +  "PROPERTY CS_FIXED_BLOCK_DEPTH 1\n"
> +
> +  "DCL SV[0], THREAD_ID\n"
> +  "DCL SV[1], BLOCK_ID\n"
> +
> +  "DCL CONST[0..5]\n"
> +  "DCL SVIEW[0..2], RECT, FLOAT\n"
> +  "DCL SAMP[0..2]\n"
> +
> +  "DCL IMAGE[0], 2D, WR\n"
> +  "DCL TEMP[0..7]\n"
> +
> +  "IMM[0] UINT32 { 8, 8, 1, 0}\n"
> +  "IMM[1] FLT32 { 1.0, 2.0, 0.0, 0.0}\n"
> +
> +  "UMAD TEMP[0], SV[1], IMM[0], SV[0]\n"
> +
> +  /* Drawn area check */
> +  "USGE TEMP[1].xy, TEMP[0].xyxy, CONST[4].xyxy\n"
> +  "USLT TEMP[1].zw, TEMP[0].xyxy, CONST[4].zwzw\n"
> +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
> +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
> +  "AND TEMP[1].x, TEMP[1]., TEMP[1].\n"
> +
> +  "UIF TEMP[1]\n"
> + /* Translate */
> + "UADD TEMP[2].xy, TEMP[0], -CONST[5].xyxy\n"
> + "U2F TEMP[2], TEMP[2]\n"
> + "DIV TEMP[3], TEMP[2], IMM[1].\n"
> +
> + /* Scale */
> + "DIV TEMP[2], TEMP[2], CONST[3].zwzw\n"
> + "DIV TEMP[3], TEMP[3], CONST[3].zwzw\n"
> +
> + /* Fetch texels */
> + "TEX_LZ TEMP[4].x, TEMP[2], SAMP[0], RECT\n"
> + "TEX_LZ TEMP[4].y, TEMP[3], SAMP[1], RECT\n"
> + "TEX_LZ TEMP[4].z, TEMP[3], SAMP[2], RECT\n"
> +
> + "MOV TEMP[4].w, IMM[1].\n"
> +
> + /* Color Space Conversion */
> + "DP4 

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

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Blocks||109535


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109535
[Bug 109535] [Tracker] Mesa 19.0 release tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Depends on||109543


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109543
[Bug 109543] After upgrade mesa to 19.0.0~rc1 all vulkan based application stop
working ["vulkan-cube" received SIGSEGV in radv_pipeline_init_blend_state at
../src/amd/vulkan/radv_pipeline.c:699]
-- 
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] panfrost: Implement Midgard shader toolchain

[Eric Anholt]

Alyssa Rosenzweig  writes:

>> Looks like you leak the constants?  You could pass ctx->ssa_constants
>> instead of NULL and the allocation would be automatically freed.
>
> Hm, alright. Is there documentation anywhere on how memctx works in
> general?

Top of src/util/ralloc.h?

>> > +nir_foreach_variable(var, >uniforms) {
>> > +if (glsl_get_base_type(var->type) == GLSL_TYPE_SAMPLER) 
>> > continue;
>> > +
>> > +unsigned length = glsl_get_aoa_size(var->type);
>> > +
>> > +if (!length) {
>> > +length = glsl_get_length(var->type);
>> > +}
>> > +
>> > +if (!length) {
>> > +length = glsl_get_matrix_columns(var->type);
>> > +}
>> 
>> This seems suspicious -- I don't have anything like this for my uniforms.
>
> Suspicious indeed... what is the correct way to map, then, without
> allocating a uniform for samplers and other not-real-uniform-uniforms?
> The hardware just wants a vec4 index; NIR mirrors the GLSL; poof?
>
> I think I had troubles there, but I can't recall exactly.

Counting uniforms/attributes is all a confusing mess.  I can confirm
that what I do in v3d works, I just can't explain how without going and
re-studying it.

>> All of this is suggestions for future work.  I'm mostly glad to see the
>> driver coming into the tree at last.  Both patches are:
>> 
>> Acked-by: Eric Anholt 
>
> Thank you! As I mentioned in the other email (to Rob), is there anything
> particular blocking a push into master?

Basically the only thing I have any concern about is allowing
end-user/distro builds of a panfrost_dri.so that doesn't actually work
(so, some day when panfrost.ko shows up upstream, suddenly the loader
starts trying to load this panfrost_dri.so and things break).  For V3D I
had the build disabled on ARM until I had the kernel ABI settled (since
I was doing dev on x86 using a simulator), but I don't have a good
solution if you're doing all your work on ARMs.  Maybe keep it out of
the list of drivers available in meson for now, since you're clearly
carrying out-of-tree code anyway?


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

Re: [Mesa-dev] [PATCH libdrm] intel: sync i915_pciids.h with kernel

[Lionel Landwerlin]

On 02/02/2019 08:07, Rodrigo Vivi wrote:

Straight copy from the kernel file.

Add more PCI Device IDs for Coffee Lake, Ice Lake,
and Amber Lake. It also include a reorg on Whiskey Lake IDs.

Align with kernel commits:

5e0f5a58b167 ("drm/i915/cfl: Adding another PCI Device ID.")
03ca3cf8e9aa ("drm/i915/icl: Adding few more device IDs for Ice Lake")
c0c46ca461f1 ("drm/i915/aml: Add new Amber Lake PCI ID")
c1c8f6fa731b ("drm/i915: Redefine some Whiskey Lake SKUs")

Cc: José Roberto de Souza 
Signed-off-by: Rodrigo Vivi 



Acked-by: Lionel Landwerlin 




---
  intel/i915_pciids.h | 29 +
  1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
index fd965ffb..d2fad7b0 100644
--- a/intel/i915_pciids.h
+++ b/intel/i915_pciids.h
@@ -365,16 +365,20 @@
INTEL_VGA_DEVICE(0x593B, info) /* Halo GT4 */
  
  /* AML/KBL Y GT2 */

-#define INTEL_AML_GT2_IDS(info) \
+#define INTEL_AML_KBL_GT2_IDS(info) \
INTEL_VGA_DEVICE(0x591C, info),  /* ULX GT2 */ \
INTEL_VGA_DEVICE(0x87C0, info) /* ULX GT2 */
  
+/* AML/CFL Y GT2 */

+#define INTEL_AML_CFL_GT2_IDS(info) \
+   INTEL_VGA_DEVICE(0x87CA, info)
+
  #define INTEL_KBL_IDS(info) \
INTEL_KBL_GT1_IDS(info), \
INTEL_KBL_GT2_IDS(info), \
INTEL_KBL_GT3_IDS(info), \
INTEL_KBL_GT4_IDS(info), \
-   INTEL_AML_GT2_IDS(info)
+   INTEL_AML_KBL_GT2_IDS(info)
  
  /* CFL S */

  #define INTEL_CFL_S_GT1_IDS(info) \
@@ -390,6 +394,9 @@
INTEL_VGA_DEVICE(0x3E9A, info)  /* SRV GT2 */
  
  /* CFL H */

+#define INTEL_CFL_H_GT1_IDS(info) \
+   INTEL_VGA_DEVICE(0x3E9C, info)
+
  #define INTEL_CFL_H_GT2_IDS(info) \
INTEL_VGA_DEVICE(0x3E9B, info), /* Halo GT2 */ \
INTEL_VGA_DEVICE(0x3E94, info)  /* Halo GT2 */
@@ -407,27 +414,29 @@
  
  /* WHL/CFL U GT1 */

  #define INTEL_WHL_U_GT1_IDS(info) \
-   INTEL_VGA_DEVICE(0x3EA1, info)
+   INTEL_VGA_DEVICE(0x3EA1, info), \
+   INTEL_VGA_DEVICE(0x3EA4, info)
  
  /* WHL/CFL U GT2 */

  #define INTEL_WHL_U_GT2_IDS(info) \
-   INTEL_VGA_DEVICE(0x3EA0, info)
+   INTEL_VGA_DEVICE(0x3EA0, info), \
+   INTEL_VGA_DEVICE(0x3EA3, info)
  
  /* WHL/CFL U GT3 */

  #define INTEL_WHL_U_GT3_IDS(info) \
-   INTEL_VGA_DEVICE(0x3EA2, info), \
-   INTEL_VGA_DEVICE(0x3EA3, info), \
-   INTEL_VGA_DEVICE(0x3EA4, info)
+   INTEL_VGA_DEVICE(0x3EA2, info)
  
  #define INTEL_CFL_IDS(info)	   \

INTEL_CFL_S_GT1_IDS(info), \
INTEL_CFL_S_GT2_IDS(info), \
+   INTEL_CFL_H_GT1_IDS(info), \
INTEL_CFL_H_GT2_IDS(info), \
INTEL_CFL_U_GT2_IDS(info), \
INTEL_CFL_U_GT3_IDS(info), \
INTEL_WHL_U_GT1_IDS(info), \
INTEL_WHL_U_GT2_IDS(info), \
-   INTEL_WHL_U_GT3_IDS(info)
+   INTEL_WHL_U_GT3_IDS(info), \
+   INTEL_AML_CFL_GT2_IDS(info)
  
  /* CNL */

  #define INTEL_CNL_IDS(info) \
@@ -452,9 +461,13 @@
INTEL_VGA_DEVICE(0x8A51, info), \
INTEL_VGA_DEVICE(0x8A5C, info), \
INTEL_VGA_DEVICE(0x8A5D, info), \
+   INTEL_VGA_DEVICE(0x8A59, info), \
+   INTEL_VGA_DEVICE(0x8A58, info), \
INTEL_VGA_DEVICE(0x8A52, info), \
INTEL_VGA_DEVICE(0x8A5A, info), \
INTEL_VGA_DEVICE(0x8A5B, info), \
+   INTEL_VGA_DEVICE(0x8A57, info), \
+   INTEL_VGA_DEVICE(0x8A56, info), \
INTEL_VGA_DEVICE(0x8A71, info), \
INTEL_VGA_DEVICE(0x8A70, info)
  



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

Re: [Mesa-dev] [PATCH 1/2] swr/rast: don't create wrapper for every Create LLVM call

[Hota, Alok]

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Emil Velikov
> Sent: Monday, February 4, 2019 3:21 AM
> To: mesa-dev@lists.freedesktop.org
> Cc: mesa-sta...@lists.freedesktop.org; emil.l.veli...@gmail.com; Hota, Alok
> 
> Subject: [Mesa-dev] [PATCH 1/2] swr/rast: don't create wrapper for every
> Create LLVM call
> 
> We user only a fraction (approximatelly 1/4) of the API - generate only those.
> 
> This way, we spend less time processing and generate smaller file. This also
> removes the need for hacks needed for compiling files bootstrapped with
> another LLVM version.

Thanks for the patch!
I had to add one function, CreateNeg, to used_functions for it to compile for 
me.

> 
> Cc: Alok Hota 
> Cc: Bruce Cherniak 
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Emil Velikov 
> ---
>  .../rasterizer/codegen/gen_llvm_ir_macros.py  | 226 +++---
>  1 file changed, 136 insertions(+), 90 deletions(-)
> 
> diff --git
> a/src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py
> b/src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py
> index 485403ae1ec..16872411408 100644
> --- a/src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py
> +++ b/src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py
> @@ -41,6 +41,72 @@ inst_aliases = {
>  'BIN_OP': 'BINOP',
>  }
> 
> +used_functions = [
> +'CreateAdd',
> +'CreateAlloca',
> +'CreateAnd',
> +'CreateAShr',
> +'CreateBitCast',
> +'CreateBr',
> +'CreateCall',
> +'CreateCast',
> +'CreateCondBr',
> +'CreateExtractElement',
> +'CreateFAdd',
> +'CreateFCmpOEQ',
> +'CreateFCmpOGE',
> +'CreateFCmpOGT',
> +'CreateFCmpOLE',
> +'CreateFCmpOLT',
> +'CreateFCmpONE',
> +'CreateFDiv',
> +'CreateFMul',
> +'CreateFPExt',
> +'CreateFPToSI',
> +'CreateFPToUI',
> +'CreateFPTrunc',
> +'CreateFSub',
> +'CreateICmpEQ',
> +'CreateICmpNE',
> +'CreateICmpSGT',
> +'CreateICmpSLE',
> +'CreateICmpSLT',
> +'CreateICmpUGE',
> +'CreateICmpUGT',
> +'CreateICmpULE',
> +'CreateICmpULT',
> +'CreateInBoundsGEP',
> +'CreateInsertElement',
> +'CreateInsertElement',
> +'CreateIntToPtr',
> +'CreateLShr',
> +'CreateMaskedGather',
> +'CreateMaskedStore',
> +'CreateMemSet',
> +'CreateMul',
> +'CreateNot',
> +'CreateOr',
> +'CreatePHI',
> +'CreatePointerCast',
> +'CreatePtrToInt',
> +'CreateRetVoid',
> +'CreateSDiv',
> +'CreateSelect',
> +'CreateSExt',
> +'CreateShl',
> +'CreateShuffleVector',
> +'CreateSIToFP',
> +'CreateStore',
> +'CreateSub',
> +'CreateTrunc',
> +'CreateUDiv',
> +'CreateUIToFP',
> +'CreateURem',
> +'CreateVectorSplat',
> +'CreateXor',
> +'CreateZExt',
> +]
> +
>  intrinsics = [
>  ['VGATHERPD',   ['src', 'pBase', 'indices', 'mask', 'scale'], 'src'],
>  ['VGATHERPS',   ['src', 'pBase', 'indices', 'mask', 'scale'], 'src'],
> @@ -100,97 +166,77 @@ def parse_ir_builder(input_file):
>  line = lines[idx].rstrip()
>  idx += 1
> 
> -#match = re.search(r'\*Create', line)
>  match = re.search(r'[\*\s]Create(\w*)\(', line)
> -if match is not None:
> -#print('Line: %s' % match.group(1))
> -
> -if re.search(r'^\s*Create', line) is not None:
> -func_sig = lines[idx-2].rstrip() + line
> -else:
> -func_sig = line
> -
> -end_of_args = False
> -while not end_of_args:
> -end_paren = re.search(r'\)', line)
> -if end_paren is not None:
> -end_of_args = True
> -else:
> -line = lines[idx].rstrip()
> -func_sig += line
> -idx += 1
> -
> -delfunc = re.search(r'LLVM_DELETED_FUNCTION|= delete;', func_sig)
> -
> -if not delfunc:
> -func = re.search(r'(.*?)\*[\n\s]*(Create\w*)\((.*?)\)', 
> func_sig)
> -if func is not None:
> -
> -return_type = func.group(1).strip() + '*'
> -func_name = func.group(2)
> -arguments = func.group(3)
> -
> -func_args = []
> -arg_names = []
> -args = arguments.split(',')
> -for arg in args:
> -arg = arg.strip()
> -if arg:
> -func_args.append(arg)
> -
> -split_args = arg.split('=')
> -arg_name = split_args[0].rsplit(None, 1)[-1]
> -
> -reg_arg = re.search(r'[\&\*]*(\w*)', arg_name)
> -if reg_arg:
> -arg_names += [reg_arg.group(1)]
> -
> -  

[Mesa-dev] [Bug 109532] ir_variable has maximum access out of bounds -- but it's not out of bounds

[bugzilla-daemon]

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

--- Comment #6 from asimiklit  ---
Created attachment 143288
  --> https://bugs.freedesktop.org/attachment.cgi?id=143288=edit
this simple program helps me to reproduce this issue.

just share my simple reproducer)

Run it in this way:

   simple_reproducer shader.comp

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

Re: [Mesa-dev] [PATCH] anv/cmd_buffer: check for NULL framebuffer

[Jason Ekstrand]

On Mon, Feb 4, 2019 at 3:02 AM Juan A. Suarez Romero 
wrote:

> On Fri, 2019-02-01 at 15:33 -0600, Jason Ekstrand wrote:
> > On Fri, Feb 1, 2019 at 10:14 AM Juan A. Suarez Romero <
> jasua...@igalia.com> wrote:
> > > This can happen when we record a VkCmdDraw in a secondary buffer that
> > > was created inheriting from the primary buffer, but with the
> framebuffer
> > > set to NULL in the VkCommandBufferInheritanceInfo.
> > >
> > > CC: Jason Ekstrand 
> > > ---
> > >  src/intel/vulkan/gen7_cmd_buffer.c | 13 +++--
> > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/src/intel/vulkan/gen7_cmd_buffer.c
> b/src/intel/vulkan/gen7_cmd_buffer.c
> > > index 352892aee33..fe1a47f6ce6 100644
> > > --- a/src/intel/vulkan/gen7_cmd_buffer.c
> > > +++ b/src/intel/vulkan/gen7_cmd_buffer.c
> > > @@ -70,12 +70,21 @@ gen7_cmd_buffer_emit_scissor(struct anv_cmd_buffer
> *cmd_buffer)
> > >};
> > >
> > >const int max = 0x;
> > > +
> > > +  uint32_t height = 0;
> > > +  uint32_t width = 0;
> > > +
> > > +  if (fb) {
> > > +height = fb->height;
> > > +width = fb->width;
> > > +  }
> > > +
> > >struct GEN7_SCISSOR_RECT scissor = {
> > >   /* Do this math using int64_t so overflow gets clamped
> correctly. */
> > >   .ScissorRectangleYMin = clamp_int64(s->offset.y, 0, max),
> > >   .ScissorRectangleXMin = clamp_int64(s->offset.x, 0, max),
> > > - .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y +
> s->extent.height - 1, 0, fb->height - 1),
> > > - .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x +
> s->extent.width - 1, 0, fb->width - 1)
> > > + .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y +
> s->extent.height - 1, 0, height - 1),
> > > + .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x +
> s->extent.width - 1, 0, width - 1)
> >
> > If fb == NULL, won't width/height be 0 and this be -1 and we end up
> clamping to -1?  I think we want to rather make the clamp conditional on
> having the framebuffer.
> >
>
> Right. And as ScissorRectangle(X/Y)Max is an uint value, its value would be
> MAX_UINT.
>

Which is fine if they specified a scissor that is >= the framebuffer size.
However, if they are actually trying to scissor something, this makes their
scissor disappear.  That's bad. :-)

--Jason


> I think as we do not know the framebuffer size (which will be know later,
> IIUC),
> we are emitting the scissor for the full rectangle.
>
>
>
>
> > --Jason
> >
> > >};
> > >
> > >if (s->extent.width <= 0 || s->extent.height <= 0) {
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] amdgpu: The CS has been cancelled because the context is lost.

[Michel Dänzer]

On 2019-02-03 2:15 a.m., Stuart Young wrote:
> Jean has logged 3 versions of the same bug in Debian, as he wasn't sure
> which package was causing the issues.
> 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921114
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921145
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921004
> 
> None of the bug logs currently contain dmesg or xorg logs.
> 
> Jean: Can you reply when you've added the logs to one of the Debian bug
> reports? I suspect the one against libglx-mesa0 is probably a good choice
> for the moment ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921145 ).

Rather #921114; this is an issue between the firmware and the amdgpu
kernel driver, Mesa is just the messenger bringing the bad news that
something went wrong. xf86-video-amdgpu has even less to do with it.


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

[Mesa-dev] [Bug 109532] ir_variable has maximum access out of bounds -- but it's not out of bounds

[bugzilla-daemon]

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

--- Comment #5 from asimiklit  ---
Hi,

I managed to reproduce this issue using provided shader under KBL with latest
mesa from git.
This happens with 'BlockB' field:
ir->data.max_array_access is 1
and
ir->type->length is 1 too

I am going to continue my investigation.

Thanks,
Andrii.

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

Re: [Mesa-dev] [PATCH] intel: Add more PCI Device IDs for Coffee Lake and Ice Lake.

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 02/02/2019 08:07, Rodrigo Vivi wrote:

Align with kernel commits:

5e0f5a58b167 ("drm/i915/cfl: Adding another PCI Device ID.")
03ca3cf8e9aa ("drm/i915/icl: Adding few more device IDs for Ice Lake")

Cc: José Roberto de Souza 
Cc: Kenneth Graunke 
Cc: Anuj Phogat 
Signed-off-by: Rodrigo Vivi 
---
  include/pci_ids/i965_pci_ids.h | 5 +
  1 file changed, 5 insertions(+)

diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 7201562d82..b91abd7a3f 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
@@ -171,6 +171,7 @@ CHIPSET(0x3185, glk_2x6, "Intel(R) UHD Graphics 600 (Geminilake 
2x6)")
  CHIPSET(0x3E90, cfl_gt1, "Intel(R) UHD Graphics 610 (Coffeelake 2x6 GT1)")
  CHIPSET(0x3E93, cfl_gt1, "Intel(R) UHD Graphics 610 (Coffeelake 2x6 GT1)")
  CHIPSET(0x3E99, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
+CHIPSET(0x3E9C, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
  CHIPSET(0x3E91, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
  CHIPSET(0x3E92, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
  CHIPSET(0x3E96, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
@@ -203,6 +204,10 @@ CHIPSET(0x5A54, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 
GT2)")
  CHIPSET(0x8A50, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
  CHIPSET(0x8A51, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
  CHIPSET(0x8A52, icl_8x8, "Intel(R) HD Graphics (Ice Lake 8x8 GT2)")
+CHIPSET(0x8A56, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
+CHIPSET(0x8A57, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
+CHIPSET(0x8A58, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
+CHIPSET(0x8A59, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
  CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
  CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
  CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")



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

Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver

[Jason Ekstrand]

On February 3, 2019 21:33:39 Alyssa Rosenzweig  wrote:


You should just land it and start doing in-tree development!


I don't have push access, you know :P


Make a MR with all the acks on it and I'll click the button. I say MR 
because the full patch would be huge.


--Jason



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

Re: [Mesa-dev] [PATCH 5/6] glsl/linker: simplify xfb_offset vs xfb_stride overflow check

[Ilia Mirkin]

On Mon, Feb 4, 2019 at 7:43 AM Andres Gomez  wrote:
>
> On Fri, 2019-02-01 at 13:17 -0500, Ilia Mirkin wrote:
> > On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez  wrote:
> > > Current implementation uses a complicated calculation which relies in
> > > an implicit conversion to check the integral part of 2 division
> > > results.
> > >
> > > However, the calculation actually checks that the xfb_offset is
> > > smaller or a multiplier of the xfb_stride. For example, while this is
> > > expected to fail, it actually succeeds:
> > >
> > >   "
> > >
> > > ...
> > >
> > > layout(xfb_buffer = 2, xfb_stride = 12) out block3 {
> > >   layout(xfb_offset = 0) vec3 c;
> > >   layout(xfb_offset = 12) vec3 d; // ERROR, requires stride of 24
> > > };
> > >
> > > ...
> > >
> > >   "
> > >
> > > Fixes: 2fab85aaea5 ("glsl: add xfb_stride link time validation")
> > > Cc: Timothy Arceri 
> > > Signed-off-by: Andres Gomez 
> > > ---
> > >  src/compiler/glsl/link_varyings.cpp | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/src/compiler/glsl/link_varyings.cpp 
> > > b/src/compiler/glsl/link_varyings.cpp
> > > index 6cebc5b3c5a..ab66ceb0d00 100644
> > > --- a/src/compiler/glsl/link_varyings.cpp
> > > +++ b/src/compiler/glsl/link_varyings.cpp
> > > @@ -1213,8 +1213,7 @@ tfeedback_decl::store(struct gl_context *ctx, 
> > > struct gl_shader_program *prog,
> > >   return false;
> > >}
> > >
> > > -  if ((this->offset / 4) / info->Buffers[buffer].Stride !=
> > > -  (xfb_offset - 1) / info->Buffers[buffer].Stride) {
> > > +  if (xfb_offset > info->Buffers[buffer].Stride) {
> >  >= ?
>
> I believe it is correct as it is.

Right. At this point in the code, xfb_offset is where the *next*
variable would go. But since there's no next variable, it's fine for
them to be equal.

Cheers,

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

Re: [Mesa-dev] [PATCH 5/6] glsl/linker: simplify xfb_offset vs xfb_stride overflow check

[Andres Gomez]

On Fri, 2019-02-01 at 13:17 -0500, Ilia Mirkin wrote:
> On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez  wrote:
> > Current implementation uses a complicated calculation which relies in
> > an implicit conversion to check the integral part of 2 division
> > results.
> > 
> > However, the calculation actually checks that the xfb_offset is
> > smaller or a multiplier of the xfb_stride. For example, while this is
> > expected to fail, it actually succeeds:
> > 
> >   "
> > 
> > ...
> > 
> > layout(xfb_buffer = 2, xfb_stride = 12) out block3 {
> >   layout(xfb_offset = 0) vec3 c;
> >   layout(xfb_offset = 12) vec3 d; // ERROR, requires stride of 24
> > };
> > 
> > ...
> > 
> >   "
> > 
> > Fixes: 2fab85aaea5 ("glsl: add xfb_stride link time validation")
> > Cc: Timothy Arceri 
> > Signed-off-by: Andres Gomez 
> > ---
> >  src/compiler/glsl/link_varyings.cpp | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/src/compiler/glsl/link_varyings.cpp 
> > b/src/compiler/glsl/link_varyings.cpp
> > index 6cebc5b3c5a..ab66ceb0d00 100644
> > --- a/src/compiler/glsl/link_varyings.cpp
> > +++ b/src/compiler/glsl/link_varyings.cpp
> > @@ -1213,8 +1213,7 @@ tfeedback_decl::store(struct gl_context *ctx, struct 
> > gl_shader_program *prog,
> >   return false;
> >}
> > 
> > -  if ((this->offset / 4) / info->Buffers[buffer].Stride !=
> > -  (xfb_offset - 1) / info->Buffers[buffer].Stride) {
> > +  if (xfb_offset > info->Buffers[buffer].Stride) {
>  >= ?

I believe it is correct as it is.

> >   linker_error(prog, "xfb_offset (%d) overflows xfb_stride (%d) for 
> > "
> >"buffer (%d)", xfb_offset * 4,
> >info->Buffers[buffer].Stride * 4, buffer);
> > --
> > 2.20.1
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-- 
Br,

Andres

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

Re: [Mesa-dev] [ANNOUNCE] mesa 19.0.0-rc1

[Eero Tamminen]

Hi,

On 2.2.2019 3.20, Mark Janes wrote:

Eero Tamminen  writes:

On 31.1.2019 1.37, Dylan Baker wrote:

This email announces the mesa 19.0 release candidate 1. I'll keep this email
fairly brief since I'm already running a little late on getting this done :)
I've just had to resolve quite a few autotools issues to get the dist built.

Notable in the 19.0-rc1 branch is SWR is set to require LLVM 7 instead of LLVM
6. It is impossible to bootstrap SWR with LLVM 6 and compile with  LLVM 7 due to
LLVM API changes. Since RadeonSI and Radv both require LLVM 7 I've taken the
liberty of bumping SWR so that we could get a tarball built.

We've had an exciting release cycle, plenty of GL and Vulkan extensions, ~1600
commits since the 18.3 branchpoint with substantial work across all areas of
mesa.


Are all the recent (i965) perf regressions included to it:
* https://bugs.freedesktop.org/show_bug.cgi?id=109517 (spilling)
* https://bugs.freedesktop.org/show_bug.cgi?id=109505 (Unigine)
* https://bugs.freedesktop.org/show_bug.cgi?id=109216 (Vulkan)


These regressions all need to be added to the release tracker.  Thank
you for reporting them.


If that should track all the things regressed since previous
18.3 version was branched:
---
tag 18.3-branchpoint
Tagger: Emil Velikov 
Date:   Thu Nov 1 18:47:06 2018 +
---

Then there are a couple of other (i965) regressions I've reported:
* https://bugs.freedesktop.org/show_bug.cgi?id=109055 (Vulkan / CPU)
* https://bugs.freedesktop.org/show_bug.cgi?id=108820 (compute hangs)
* https://bugs.freedesktop.org/show_bug.cgi?id=108787 (BSW CarChase aborts)

(First two seem at least partially resolved.)



PS. There's also much older:
* https://bugs.freedesktop.org/show_bug.cgi?id=107510

Which was already fixed, but then regressed again, and regressing commit
wasn't anymore reverted.  I'm mentioning it because Timothy had a patch
series in October that fixed the tess/geom shader regressions (which
were largest), but for some reason it's not yet in upstream.


That one regressed after 18.2-branchpoint:
---
Tagger: Andres Gomez 
Date:   Thu Aug 2 17:57:41 2018 +0300
---

And it wasn't listed in 18.2.x release tracker bug.

Neither were its duplicates:
* https://bugs.freedesktop.org/show_bug.cgi?id=107706
* https://bugs.freedesktop.org/show_bug.cgi?id=107743


If there's a release check list for Mesa, it could have items for:
* having the release tracker meta bug
* going through bugzilla bugs that have been created after previous
  release branch point was tagged and, adding the relevant ones
  to the release tracker bug


- Eero


Expect rc2 about this time next week, see you then.

Dylan

git tag: mesa-19.0.0-rc1

https://mesa.freedesktop.org/archive/mesa-19.0.0-rc1.tar.gz
MD5:  b3a610b204d0cb3431823353a8cbe8e6  mesa-19.0.0-rc1.tar.gz
SHA1: d1f0d0bc49ec7e02d0cd7d141127fd2fefc72e35  mesa-19.0.0-rc1.tar.gz
SHA256: 0a14bb059f6cead4e50923df9c24d3c5025d9310803ca5189e019f07e539639e  
mesa-19.0.0-rc1.tar.gz
SHA512: 
5bedc917afecef6a0dd11c56688a3e3fdbbaeaceca33062d6825b5525c6e78663e873bdecc96b98b0448d988ad81a7a8617c523e2d312384369c6a333b790b86
  mesa-19.0.0-rc1.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.0.0-rc1.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-19.0.0-rc1.tar.xz
MD5:  727abb6469e518ff1a2e1bde33543503  mesa-19.0.0-rc1.tar.xz
SHA1: 577642259cd269c883007df7c2772c8c636fabfb  mesa-19.0.0-rc1.tar.xz
SHA256: 8efb32956c428d23f78364f9eace5491bda9feaafd767128133672a5f79659e8  
mesa-19.0.0-rc1.tar.xz
SHA512: 
23d21d6c4f03a1d9073ecb1f43dc251d581cdeb6b7cc24a19c299571070b4184ad4f22b0ca170ca42e58c62bb46eca0dadc334a952bbb7e0379961a30a6ca856
  mesa-19.0.0-rc1.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.0.0-rc1.tar.xz.sig

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

Re: [Mesa-dev] [PATCH 23/25] radeonsi: factor si_query_buffer logic out of si_query_hw

[Nicolai Hähnle]

On 01.02.19 05:25, Timothy Arceri wrote:

On 26/1/19 11:56 am, Marek Olšák wrote:

Timothy, can you please test the attached fix?


I'm having trouble compiling 32bit mesa on my machine at the moment so 
haven't been able to test Batman. But this commit also causes No Mans 
Sky to lock up my machine and the attached patch does not fix it.


Is there a trace or something else to easily reproduce it?

Cheers,
Nicolai







Thanks,
Marek

On Wed, Jan 2, 2019 at 10:58 PM Timothy Arceri > wrote:


    This commit seems to cause bad stuttering in the Batman Arkham City
    benchmark.

    On 7/12/18 1:00 am, Nicolai Hähnle wrote:
 > From: Nicolai Hähnle mailto:nicolai.haeh...@amd.com>>
 >
 > This is a move towards using composition instead of inheritance 
for

 > different query types.
 >
 > This change weakens out-of-memory error reporting somewhat,
    though this
 > should be acceptable since we didn't consistently report such
    errors in
 > the first place.
 > ---
 >   src/gallium/drivers/radeonsi/si_perfcounter.c |   8 +-
 >   src/gallium/drivers/radeonsi/si_query.c       | 177
    +-
 >   src/gallium/drivers/radeonsi/si_query.h       |  17 +-
 >   src/gallium/drivers/radeonsi/si_texture.c     |   7 +-
 >   4 files changed, 99 insertions(+), 110 deletions(-)
 >
 > diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c
    b/src/gallium/drivers/radeonsi/si_perfcounter.c
 > index 0b3d8f89273..f0d10c054c4 100644
 > --- a/src/gallium/drivers/radeonsi/si_perfcounter.c
 > +++ b/src/gallium/drivers/radeonsi/si_perfcounter.c
 > @@ -761,23 +761,22 @@ static void si_pc_query_destroy(struct
    si_screen *sscreen,
 >               struct si_query_group *group = query->groups;
 >               query->groups = group->next;
 >               FREE(group);
 >       }
 >
 >       FREE(query->counters);
 >
 >       si_query_hw_destroy(sscreen, rquery);
 >   }
 >
 > -static bool si_pc_query_prepare_buffer(struct si_screen *screen,
 > -                                    struct si_query_hw *hwquery,
 > -                                    struct r600_resource *buffer)
 > +static bool si_pc_query_prepare_buffer(struct si_context *ctx,
 > +                                    struct si_query_buffer *qbuf)
 >   {
 >       /* no-op */
 >       return true;
 >   }
 >
 >   static void si_pc_query_emit_start(struct si_context *sctx,
 >                                  struct si_query_hw *hwquery,
 >                                  struct r600_resource *buffer,
    uint64_t va)
 >   {
 >       struct si_query_pc *query = (struct si_query_pc *)hwquery;
 > @@ -1055,23 +1054,20 @@ struct pipe_query
    *si_create_batch_query(struct pipe_context *ctx,
 >               counter->base = group->result_base + j;
 >               counter->stride = group->num_counters;
 >
 >               counter->qwords = 1;
 >               if ((block->b->b->flags & SI_PC_BLOCK_SE) &&
    group->se < 0)
 >                       counter->qwords = screen->info.max_se;
 >               if (group->instance < 0)
 >                       counter->qwords *= block->num_instances;
 >       }
 >
 > -     if (!si_query_hw_init(screen, >b))
 > -             goto error;
 > -
 >       return (struct pipe_query *)query;
 >
 >   error:
 >       si_pc_query_destroy(screen, >b.b);
 >       return NULL;
 >   }
 >
 >   static bool si_init_block_names(struct si_screen *screen,
 >                               struct si_pc_block *block)
 >   {
 > diff --git a/src/gallium/drivers/radeonsi/si_query.c
    b/src/gallium/drivers/radeonsi/si_query.c
 > index 479a1bbf2c4..5b0fba0ed92 100644
 > --- a/src/gallium/drivers/radeonsi/si_query.c
 > +++ b/src/gallium/drivers/radeonsi/si_query.c
 > @@ -514,86 +514,129 @@ static struct pipe_query
    *si_query_sw_create(unsigned query_type)
 >       query = CALLOC_STRUCT(si_query_sw);
 >       if (!query)
 >               return NULL;
 >
 >       query->b.type = query_type;
 >       query->b.ops = _query_ops;
 >
 >       return (struct pipe_query *)query;
 >   }
 >
 > -void si_query_hw_destroy(struct si_screen *sscreen,
 > -                      struct si_query *rquery)
 > +void si_query_buffer_destroy(struct si_screen *sscreen, struct
    si_query_buffer *buffer)
 >   {
 > -     struct si_query_hw *query = (struct si_query_hw *)rquery;
 > -     struct si_query_buffer *prev = query->buffer.previous;
 > +     struct si_query_buffer *prev = buffer->previous;
 >
 >       /* Release all query buffers. */
 >       while (prev) {
 >               struct si_query_buffer *qbuf = prev;
 >               prev = prev->previous;
   

Re: [Mesa-dev] [PATCH 23/25] radeonsi: factor si_query_buffer logic out of si_query_hw

[Nicolai Hähnle]

Patch looks good to me, for what it's worth.

si_query_buffer_alloc could be restructured to be slightly cleaner by 
unifying the two calls to prepare_buffer, but it's not a huge deal.


Cheers,
Nicolai

On 26.01.19 01:56, Marek Olšák wrote:

Timothy, can you please test the attached fix?

Thanks,
Marek

On Wed, Jan 2, 2019 at 10:58 PM Timothy Arceri > wrote:


This commit seems to cause bad stuttering in the Batman Arkham City
benchmark.

On 7/12/18 1:00 am, Nicolai Hähnle wrote:
 > From: Nicolai Hähnle mailto:nicolai.haeh...@amd.com>>
 >
 > This is a move towards using composition instead of inheritance for
 > different query types.
 >
 > This change weakens out-of-memory error reporting somewhat,
though this
 > should be acceptable since we didn't consistently report such
errors in
 > the first place.
 > ---
 >   src/gallium/drivers/radeonsi/si_perfcounter.c |   8 +-
 >   src/gallium/drivers/radeonsi/si_query.c       | 177
+-
 >   src/gallium/drivers/radeonsi/si_query.h       |  17 +-
 >   src/gallium/drivers/radeonsi/si_texture.c     |   7 +-
 >   4 files changed, 99 insertions(+), 110 deletions(-)
 >
 > diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c
b/src/gallium/drivers/radeonsi/si_perfcounter.c
 > index 0b3d8f89273..f0d10c054c4 100644
 > --- a/src/gallium/drivers/radeonsi/si_perfcounter.c
 > +++ b/src/gallium/drivers/radeonsi/si_perfcounter.c
 > @@ -761,23 +761,22 @@ static void si_pc_query_destroy(struct
si_screen *sscreen,
 >               struct si_query_group *group = query->groups;
 >               query->groups = group->next;
 >               FREE(group);
 >       }
 >
 >       FREE(query->counters);
 >
 >       si_query_hw_destroy(sscreen, rquery);
 >   }
 >
 > -static bool si_pc_query_prepare_buffer(struct si_screen *screen,
 > -                                    struct si_query_hw *hwquery,
 > -                                    struct r600_resource *buffer)
 > +static bool si_pc_query_prepare_buffer(struct si_context *ctx,
 > +                                    struct si_query_buffer *qbuf)
 >   {
 >       /* no-op */
 >       return true;
 >   }
 >
 >   static void si_pc_query_emit_start(struct si_context *sctx,
 >                                  struct si_query_hw *hwquery,
 >                                  struct r600_resource *buffer,
uint64_t va)
 >   {
 >       struct si_query_pc *query = (struct si_query_pc *)hwquery;
 > @@ -1055,23 +1054,20 @@ struct pipe_query
*si_create_batch_query(struct pipe_context *ctx,
 >               counter->base = group->result_base + j;
 >               counter->stride = group->num_counters;
 >
 >               counter->qwords = 1;
 >               if ((block->b->b->flags & SI_PC_BLOCK_SE) &&
group->se < 0)
 >                       counter->qwords = screen->info.max_se;
 >               if (group->instance < 0)
 >                       counter->qwords *= block->num_instances;
 >       }
 >
 > -     if (!si_query_hw_init(screen, >b))
 > -             goto error;
 > -
 >       return (struct pipe_query *)query;
 >
 >   error:
 >       si_pc_query_destroy(screen, >b.b);
 >       return NULL;
 >   }
 >
 >   static bool si_init_block_names(struct si_screen *screen,
 >                               struct si_pc_block *block)
 >   {
 > diff --git a/src/gallium/drivers/radeonsi/si_query.c
b/src/gallium/drivers/radeonsi/si_query.c
 > index 479a1bbf2c4..5b0fba0ed92 100644
 > --- a/src/gallium/drivers/radeonsi/si_query.c
 > +++ b/src/gallium/drivers/radeonsi/si_query.c
 > @@ -514,86 +514,129 @@ static struct pipe_query
*si_query_sw_create(unsigned query_type)
 >       query = CALLOC_STRUCT(si_query_sw);
 >       if (!query)
 >               return NULL;
 >
 >       query->b.type = query_type;
 >       query->b.ops = _query_ops;
 >
 >       return (struct pipe_query *)query;
 >   }
 >
 > -void si_query_hw_destroy(struct si_screen *sscreen,
 > -                      struct si_query *rquery)
 > +void si_query_buffer_destroy(struct si_screen *sscreen, struct
si_query_buffer *buffer)
 >   {
 > -     struct si_query_hw *query = (struct si_query_hw *)rquery;
 > -     struct si_query_buffer *prev = query->buffer.previous;
 > +     struct si_query_buffer *prev = buffer->previous;
 >
 >       /* Release all query buffers. */
 >       while (prev) {
 >               struct si_query_buffer *qbuf = prev;
 >               prev = prev->previous;
 >               r600_resource_reference(>buf, NULL);
 >               FREE(qbuf);
 >       }
 >
 > -     

Re: [Mesa-dev] [PATCH] meson: drop the xcb-xrandr version requirement

[Mike Lothian]

I'm a bit confused by this patch

It's in a section called xlib_lease, for leases to work I think the
newer version is required, but I think the underlying code was changed
to build without the newer headers

Do leases work with the old code, or should this section be renamed?

On Sun, 3 Feb 2019 at 11:52, Erik Faye-Lund
 wrote:
>
> On Sat, 2019-02-02 at 12:58 -0500, Marek Olšák wrote:
> >
> >
> > On Sat, Feb 2, 2019, 12:41 PM Eric Engestrom <
> > eric.engest...@intel.com wrote:
> > > On Saturday, 2019-02-02 10:32:15 -0500, Marek Olšák wrote:
> > > > On Sat, Feb 2, 2019, 7:17 AM Eric Engestrom <
> > > eric.engest...@intel.com wrote:
> > > >
> > > > > On Friday, 2019-02-01 15:42:17 -0500, Marek Olšák wrote:
> > > > > > If there is no feedback soon, I'll push this.
> > > > >
> > > > > Have you tested that xcb-randr < 1.12 works?
> > > > > Probably shouldn't remove a restriction unless you're sure it
> > > isn't
> > > > > needed :)
> > > > >
> > > >
> > > > Is this a joke? I'm just mirroring autotools. Supporting the same
> > > linux
> > > > distributions as autotools is a requirement for meson's general
> > > acceptance.
> > >
> > > No, I'm being serious: just because a restriction didn't exist on
> > > autotools doesn't mean that code path was exercised by people
> > > running
> > > an old xcb-randr, hence the need to test it :)
> > >
> > > I didn't mean to offend you, I was just asking the question to make
> > > sure
> > > this was tested before we claim to support xcb-randr < 1.12, as it
> > > might
> > > be that autotools was simply missing the version check.
> >
> > Ok. I use old xcb-xrandr on some of my systems, one of them used to
> > be my main system. Not being able to use meson on those systems
> > without this patch is a big deal for me.
>
> This sounds like you have indeed tested on xcb-randr < 1.12, so I
> suppose the answer to the question is "yes"? If so, I think it's all
> good, no?
>
> Anyway, I think this seems like the right move, and since Keith has't
> responded, feel free to add:
>
> Reviewed-by: Erik Faye-Lund 
>
> ___
> 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 109543] After upgrade mesa to 19.0.0~rc1 all vulkan based application stop working ["vulkan-cube" received SIGSEGV in radv_pipeline_init_blend_state at ../src/amd/vulkan/radv_pipeline.

[bugzilla-daemon]

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

--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 143285
  --> https://bugs.freedesktop.org/attachment.cgi?id=143285=edit
vulkan-cube backtrace

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

[bugzilla-daemon]

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

Bug ID: 109543
   Summary: After upgrade mesa to 19.0.0~rc1 all vulkan based
application stop working ["vulkan-cube" received
SIGSEGV in radv_pipeline_init_blend_state at
../src/amd/vulkan/radv_pipeline.c:699]
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: mikhail.v.gavri...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 143284
  --> https://bugs.freedesktop.org/attachment.cgi?id=143284=edit
rise_of_tomb_rider backtrace

Yesterday I tried update mesa to 19.0.0~rc1 version, but after update all
vulkan based application stop working.

List of tested application:
- Rise of the Tomb Raider (backtrace is attached)
- F1 2017
- Any game launched via steam play DXVK
- vulkan-cube (backtrace is attached)

Last working mesa version:
18.3.2-1

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

[Mesa-dev] [PATCH 1/2] swr/rast: don't create wrapper for every Create LLVM call

[Emil Velikov]

We user only a fraction (approximatelly 1/4) of the API - generate only
those.

This way, we spend less time processing and generate smaller file. This
also removes the need for hacks needed for compiling files bootstrapped
with another LLVM version.

Cc: Alok Hota 
Cc: Bruce Cherniak 
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Emil Velikov 
---
 .../rasterizer/codegen/gen_llvm_ir_macros.py  | 226 +++---
 1 file changed, 136 insertions(+), 90 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py 
b/src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py
index 485403ae1ec..16872411408 100644
--- a/src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py
+++ b/src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py
@@ -41,6 +41,72 @@ inst_aliases = {
 'BIN_OP': 'BINOP',
 }
 
+used_functions = [
+'CreateAdd',
+'CreateAlloca',
+'CreateAnd',
+'CreateAShr',
+'CreateBitCast',
+'CreateBr',
+'CreateCall',
+'CreateCast',
+'CreateCondBr',
+'CreateExtractElement',
+'CreateFAdd',
+'CreateFCmpOEQ',
+'CreateFCmpOGE',
+'CreateFCmpOGT',
+'CreateFCmpOLE',
+'CreateFCmpOLT',
+'CreateFCmpONE',
+'CreateFDiv',
+'CreateFMul',
+'CreateFPExt',
+'CreateFPToSI',
+'CreateFPToUI',
+'CreateFPTrunc',
+'CreateFSub',
+'CreateICmpEQ',
+'CreateICmpNE',
+'CreateICmpSGT',
+'CreateICmpSLE',
+'CreateICmpSLT',
+'CreateICmpUGE',
+'CreateICmpUGT',
+'CreateICmpULE',
+'CreateICmpULT',
+'CreateInBoundsGEP',
+'CreateInsertElement',
+'CreateInsertElement',
+'CreateIntToPtr',
+'CreateLShr',
+'CreateMaskedGather',
+'CreateMaskedStore',
+'CreateMemSet',
+'CreateMul',
+'CreateNot',
+'CreateOr',
+'CreatePHI',
+'CreatePointerCast',
+'CreatePtrToInt',
+'CreateRetVoid',
+'CreateSDiv',
+'CreateSelect',
+'CreateSExt',
+'CreateShl',
+'CreateShuffleVector',
+'CreateSIToFP',
+'CreateStore',
+'CreateSub',
+'CreateTrunc',
+'CreateUDiv',
+'CreateUIToFP',
+'CreateURem',
+'CreateVectorSplat',
+'CreateXor',
+'CreateZExt',
+]
+
 intrinsics = [
 ['VGATHERPD',   ['src', 'pBase', 'indices', 'mask', 'scale'], 'src'],
 ['VGATHERPS',   ['src', 'pBase', 'indices', 'mask', 'scale'], 'src'],
@@ -100,97 +166,77 @@ def parse_ir_builder(input_file):
 line = lines[idx].rstrip()
 idx += 1
 
-#match = re.search(r'\*Create', line)
 match = re.search(r'[\*\s]Create(\w*)\(', line)
-if match is not None:
-#print('Line: %s' % match.group(1))
-
-if re.search(r'^\s*Create', line) is not None:
-func_sig = lines[idx-2].rstrip() + line
-else:
-func_sig = line
-
-end_of_args = False
-while not end_of_args:
-end_paren = re.search(r'\)', line)
-if end_paren is not None:
-end_of_args = True
-else:
-line = lines[idx].rstrip()
-func_sig += line
-idx += 1
-
-delfunc = re.search(r'LLVM_DELETED_FUNCTION|= delete;', func_sig)
-
-if not delfunc:
-func = re.search(r'(.*?)\*[\n\s]*(Create\w*)\((.*?)\)', 
func_sig)
-if func is not None:
-
-return_type = func.group(1).strip() + '*'
-func_name = func.group(2)
-arguments = func.group(3)
-
-func_args = []
-arg_names = []
-args = arguments.split(',')
-for arg in args:
-arg = arg.strip()
-if arg:
-func_args.append(arg)
-
-split_args = arg.split('=')
-arg_name = split_args[0].rsplit(None, 1)[-1]
-
-reg_arg = re.search(r'[\&\*]*(\w*)', arg_name)
-if reg_arg:
-arg_names += [reg_arg.group(1)]
-
-ignore = False
-
-# The following functions need to be ignored in openswr.
-# API change in llvm-5.0 breaks baked autogen files
-if (
-(func_name == 'CreateFence' or
- func_name == 'CreateAtomicCmpXchg' or
- func_name == 'CreateAtomicRMW')):
-ignore = True
-
-# The following functions need to be ignored.
-if (func_name == 'CreateInsertNUWNSWBinOp' or
-func_name == 'CreateMaskedIntrinsic' or
-func_name == 'CreateAlignmentAssumptionHelper' or
-func_name == 'CreateGEP' or
- 

[Mesa-dev] [PATCH 2/2] configure.ac: drop SWR_INVALID_LLVM_VERSION workaround

[Emil Velikov]

Previously one of the SWR python generators would create wrappers for
LLVM functions. Every Create* API would have one, even though we only
needed about a quarter of them.

Additionally this meant  that we could not create create the file with
one LLVM version and compile with another.

Cc: Dylan Baker 
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Emil Velikov 
---
 configure.ac|  4 
 src/gallium/drivers/swr/Makefile.am | 10 --
 2 files changed, 14 deletions(-)

diff --git a/configure.ac b/configure.ac
index c7bf5cf3591..c57a6960148 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2823,10 +2823,6 @@ if test -n "$with_gallium_drivers"; then
 done
 fi
 
-# XXX: Keep in sync with LLVM_REQUIRED_SWR
-AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != x6.0.0 -a \
-  "x$LLVM_VERSION" != x6.0.1)
-
 if test "x$enable_llvm" = "xyes" -a "$with_gallium_drivers"; then
 llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
 llvm_add_default_components "gallium"
diff --git a/src/gallium/drivers/swr/Makefile.am 
b/src/gallium/drivers/swr/Makefile.am
index 3390ef6b096..3137f4a3cdd 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -370,16 +370,6 @@ endif
 
 include $(top_srcdir)/install-gallium-links.mk
 
-# Generated gen_builder.hpp is not backwards compatible. So ship only one
-# created with the oldest supported version of LLVM.
-dist-hook:
-if SWR_INVALID_LLVM_VERSION
-   @echo "*"
-   @echo "LLVM 6.0.x required to create the tarball"
-   @echo "*"
-   @test
-endif
-
 EXTRA_DIST = \
SConscript \
meson.build \
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] anv/cmd_buffer: check for NULL framebuffer

[Juan A. Suarez Romero]

On Fri, 2019-02-01 at 15:33 -0600, Jason Ekstrand wrote:
> On Fri, Feb 1, 2019 at 10:14 AM Juan A. Suarez Romero  
> wrote:
> > This can happen when we record a VkCmdDraw in a secondary buffer that
> > was created inheriting from the primary buffer, but with the framebuffer
> > set to NULL in the VkCommandBufferInheritanceInfo.
> > 
> > CC: Jason Ekstrand 
> > ---
> >  src/intel/vulkan/gen7_cmd_buffer.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
> > b/src/intel/vulkan/gen7_cmd_buffer.c
> > index 352892aee33..fe1a47f6ce6 100644
> > --- a/src/intel/vulkan/gen7_cmd_buffer.c
> > +++ b/src/intel/vulkan/gen7_cmd_buffer.c
> > @@ -70,12 +70,21 @@ gen7_cmd_buffer_emit_scissor(struct anv_cmd_buffer 
> > *cmd_buffer)
> >};
> > 
> >const int max = 0x;
> > +
> > +  uint32_t height = 0;
> > +  uint32_t width = 0;
> > +
> > +  if (fb) {
> > +height = fb->height;
> > +width = fb->width;
> > +  }
> > +
> >struct GEN7_SCISSOR_RECT scissor = {
> >   /* Do this math using int64_t so overflow gets clamped correctly. 
> > */
> >   .ScissorRectangleYMin = clamp_int64(s->offset.y, 0, max),
> >   .ScissorRectangleXMin = clamp_int64(s->offset.x, 0, max),
> > - .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
> > s->extent.height - 1, 0, fb->height - 1),
> > - .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
> > s->extent.width - 1, 0, fb->width - 1)
> > + .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
> > s->extent.height - 1, 0, height - 1),
> > + .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
> > s->extent.width - 1, 0, width - 1)
> 
> If fb == NULL, won't width/height be 0 and this be -1 and we end up clamping 
> to -1?  I think we want to rather make the clamp conditional on having the 
> framebuffer.
> 

Right. And as ScissorRectangle(X/Y)Max is an uint value, its value would be
MAX_UINT.

I think as we do not know the framebuffer size (which will be know later, IIUC),
we are emitting the scissor for the full rectangle.




> --Jason
>  
> >};
> > 
> >if (s->extent.width <= 0 || s->extent.height <= 0) {

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

Re: [Mesa-dev] [PATCH] intel/compiler: update validator to account for half-float exec type promotion

[Iago Toral]

On Mon, 2019-02-04 at 08:50 +0100, Iago Toral wrote:
> On Fri, 2019-02-01 at 11:23 -0800, Francisco Jerez wrote:
> > Iago Toral  writes:
> > 
> > > On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote:
> > > > Iago Toral  writes:
> > > > 
> > > > > On Thu, 2019-01-24 at 11:45 -0800, Francisco Jerez wrote:
> > > > > > Iago Toral  writes:
> > > > > > 
> > > > > > > On Wed, 2019-01-23 at 06:03 -0800, Francisco Jerez wrote:
> > > > > > > > Iago Toral Quiroga  writes:
> > > > > > > > 
> > > > > > > > > Commit c84ec70b3a72 implemented execution type
> > > > > > > > > promotion to
> > > > > > > > > 32-
> > > > > > > > > bit
> > > > > > > > > for
> > > > > > > > > conversions involving half-float registers, which
> > > > > > > > > empirical
> > > > > > > > > testing
> > > > > > > > > suggested
> > > > > > > > > was required, but it did not incorporate this change
> > > > > > > > > into
> > > > > > > > > the
> > > > > > > > > assembly validator
> > > > > > > > > logic. This commits adds that, preventing validation
> > > > > > > > > errors
> > > > > > > > > like
> > > > > > > > > this:
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I don't think we should be validating empirical
> > > > > > > > assumptions
> > > > > > > > in
> > > > > > > > the EU
> > > > > > > > validator.
> > > > > > > 
> > > > > > > I am not sure I get your point, isn't c84ec70b3a72 also
> > > > > > > based
> > > > > > > on
> > > > > > > empirical testing after all?
> > > > > > > 
> > > > > > 
> > > > > > To some extent, but it doesn't attempt to enforce ISA
> > > > > > restrictions
> > > > > > based
> > > > > > on information obtained empirically.
> > > > > > 
> > > > > > > 
> > > > > > > > > mov(16)  g9<4>B   g3<16,8,2>HF { align1 1H };
> > > > > > > > > ERROR: Destination stride must be equal to the ratio
> > > > > > > > > of
> > > > > > > > > the
> > > > > > > > > sizes
> > > > > > > > > of the
> > > > > > > > >execution data type to the destination type
> > > > > > > > > 
> > > > > > > > > Fixes: c84ec70b3a72 "intel/fs: Promote execution type
> > > > > > > > > to
> > > > > > > > > 32-bit
> > > > > > > > > when any half-float conversion is needed."
> > > > > > > > 
> > > > > > > > I don't think this "fixes" anything that ever worked.
> > > > > > > 
> > > > > > > It is true that the code in that trace above is not
> > > > > > > something
> > > > > > > we
> > > > > > > can
> > > > > > > produce right now, because it is a conversion from HF to
> > > > > > > B
> > > > > > > and
> > > > > > > that
> > > > > > > should only happen within the context of
> > > > > > > VK_KHR_shader_float16_int8,
> > > > > > > however, this is a consequence of the fact that since
> > > > > > > c84ec70b3a72
> > > > > > > there is an inconsistency between what we do at the IR
> > > > > > > level
> > > > > > > regarding
> > > > > > > execution size of HF conversions and what the EU
> > > > > > > validator
> > > > > > > is
> > > > > > > doing,
> > > > > > > and from that perspective this is really fixing an
> > > > > > > inconsistency
> > > > > > > that
> > > > > > > didn't exist before, and I thought we would want to
> > > > > > > address
> > > > > > > that
> > > > > > > sooner
> > > > > > > rather than later and track it down to the original
> > > > > > > change
> > > > > > > that
> > > > > > > introduced that inconsistency so we know where this is
> > > > > > > coming
> > > > > > > from.
> > > > > > > 
> > > > > > 
> > > > > > The "inconsistency" between the IR's get_exec_type() and
> > > > > > the
> > > > > > EU
> > > > > > validator's execution_type() has existed ever since
> > > > > > a05b6f25bf4bfad7
> > > > > > removed the HF assert from get_exec_type() without actually
> > > > > > implementing
> > > > > > the code required to handle HF operands (which is what my
> > > > > > commit
> > > > > > c84ec70b3a72 did).
> > > > > 
> > > > > I agree with the fact that since a05b6f25bf4bfad7 the
> > > > > validator
> > > > > could
> > > > > reject valid code and that had nothing to do with your patch,
> > > > 
> > > > The validator rejected the same valid HF code since it was
> > > > written,
> > > > that
> > > > had nothing to do with neither a05b6f25bf4bfad7 nor with my
> > > > patch,
> > > > and
> > > > it is the real problem this patch was working around.
> > > > 
> > > > > but the inconsistency I am talking about here, that this
> > > > > patch
> > > > > fixes,
> > > > > is the one about get_exec_type() in the IR and
> > > > > execution_type()
> > > > > in
> > > > > the
> > > > > validator doing different things for HF instructions, which
> > > > > only
> > > > > exists since your patch and which you discuss below.
> > > > > 
> > > > 
> > > > The "inconsistency" exists ever since get_exec_type() was
> > > > introduced
> > > > without correct handling of HF types (even though
> > > > execution_type()
> > > > already attempted to handle it).  And I disagree that it's a
> > > > real
> > > > inconsistency except due to the fact that the validator is
> 

Re: [Mesa-dev] [ANNOUNCE] Mesa 18.3.3 release candidate

[Carsten Haitzler]

On Fri, 1 Feb 2019 11:08:07 + Emil Velikov  said:

> Hi Carsten,
> 
> On 2019/01/31, Carsten Haitzler wrote:
> > On Wed, 30 Jan 2019 18:33:35 + Emil Velikov 
> > said:
> > 
> > You might want to hold off on this. My bugfix was actually patched out by
> > partly removing some of it. The void ptr math should never have been there
> > and wasn't in the final patch.
> > 
> > I'm talking about:
> > 
> > +void *cpu2 = cpu + 8;
> > 
> > In 300d3ae8b1445b5060f92c77c0f577f4b7b2c7d6
> > 
> > At least with gcc8 mesa is a dud on Raspberry Pi (can't upload/downlaod
> > textures without crashing) without the fixes. I moved the secondary ptr math
> > into the ASM chunk because the C compiler seemed to just mess up cpu2 ptr
> > content/value for me on gcc8 (it also kept the parameter inputs/outputs
> > cleaner and consistent with other ASM chunks). Keeping this as void ptr
> > math alone is just wrong and asking for trouble and as it unfixed a fix I
> > already had in submitted patches.
> > 
> > Being at FOSDEM I now no longer have access to my OS image with all of this
> > set up to test and won't until next week. I can't dig in and verify.
> > Without my fixes at all it's a dead man walking with gcc8, and thus Arch
> > Linux is broken entirely on Rpi without it (and has been for a while now).
> > 
> If I understand this correctly, during the rework (by Eric I assume) some of
> your fixes got invalidated. Yet the current code and binaries produced are
> not worse off then before the patches.

they would still crash which means the problem isn't fixed given what i saw
(the void *cpu2 = cpu + 8 being there). this would mean yu have a new release
of mesa with no fixes for anyone with a new gcc8 (like arch linux) and a vc4
gpu (all rpi's)

> Thus from stable POV, we're safe, since nothing has regressed per se. We will
> apply the extra patches for the next release.
> 
> Thanks
> Emil
> 
> P.S. How did you submit the patches - I cannot see them neither on mesa-dev
> mailing list nor gitlab MR.

i mailed them to eric as he was listed as the maintainer.

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

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

Re: [Mesa-dev] [Bug 109107] gallium/st/va: change va max_profiles when using Radeon VCN Hardware

[Mihai]

Hi,

I am not sure if this is related with regards to what is causing hardware
accelerated decoding on my Raven laptop not to work.

Fedora repos:
che-mesa, rpmfusion, fedora-rawhide-kernel-nodebug
Mesa-git installed is build from: sha 9279a28

chromium-vaapi package from rpmfusion repo, started with the following
command:
chromium-vaapi --enable-plugins --enable-extensions --enable-user-scripts
--enable-printing --enable-accelerated-video
--enable-native-gpu-memory-buffers --enable-accelerated-mjpeg-decode
-nable-gpu-rasterization --disable-gpu-driver-bug-workarounds --enable-sync
--flag-switches-begin --enable-accelerated-mjpeg-decode
--enable-accelerated-video --enable-zero-copy --ignore-gpu-blacklist
--enable-features=VizDisplayCompositor --flag-switches-end


chrome://gpu/

Native GpuMemoryBuffers: Hardware accelerated
Hardware Protected Video Decode: Hardware accelerated
Video Decode: Hardware accelerated
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
-

chrome://media-internals/

video_codec_name vp9
video_dds false
video_decoder VpxVideoDecoder

so, as the VpxVideoDecoder, it means the gpu hardware acceleration is not
working.

Log:
[18642:18642:0201/223152.683850:ERROR:vaapi_wrapper.cc(568)] :
vaQueryConfigProfiles returned: 14
[18642:18642:0201/223152.683943:ERROR:vaapi_wrapper.cc(568)] :
vaQueryConfigProfiles returned: 14
[18642:18642:0201/223152.771320:ERROR:sandbox_linux.cc(364)] :
InitializeSandbox() called with multiple threads in process gpu-process.
[18642:18642:0201/224233.934476:ERROR:buffer_manager.cc(491)] :
[GroupMarkerNotSet(crbug.com/242999)!:C0B874BB3939]GL ERROR
:GL_INVALID_OPERATION : glBufferData: <- error from previous GL command

Specs:
I am using HP 15-cp0001na laptop with Ryzen 2700u:

inxi -G
Graphics:  Device-1: AMD Raven Ridge [Radeon Vega Series / Radeon Vega
Mobile Series] driver: amdgpu v: kernel
Display: x11 server: Fedora Project X.org 1.20.3 driver: amdgpu tty: N/A
OpenGL: renderer: AMD RAVEN (DRM 3.27.0 5.0.0-0.rc4.git0.1.fc30.x86_64 LLVM
9.0.0) v: 4.5 Mesa 19.1.0-devel
--
dmesg
[3.119158] amdgpu :04:00.0: ring vcn_dec uses VM inv eng 1 on hub 1
[3.119166] amdgpu :04:00.0: ring vcn_enc0 uses VM inv eng 4 on hub 1
[3.119170] amdgpu :04:00.0: ring vcn_enc1 uses VM inv eng 5 on hub 1
[3.119173] amdgpu :04:00.0: ring vcn_jpeg uses VM inv eng 6 on hub 1

vainfo

libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_3
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.3 (libva 2.3.0)
vainfo: Driver version: Mesa Gallium driver 19.1.0-devel for AMD RAVEN (DRM
3.27.0, 5.0.0-0.rc4.git0.1.fc30.x86_64, LLVM 9.0.0)
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointEncSlice
  VAProfileHEVCMain10 : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileVP9Profile0: VAEntrypointVLD
  VAProfileVP9Profile2: VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc

Possibly related:
https://sea-region.github.com/saiarcot895/chromium-ubuntu-build/issues/39

Thanks in advance!



On Fri, Dec 21, 2018 at 3:19 AM  wrote:

> *Comment # 1  on
> bug 109107  from
> zhoulei  *
>
> More details:
>
> In function 
> VASupportedProfiles::GetSupportedVAProfiles,https://github.com/chromium/chromium/blob/master/media/gpu/vaapi/vaapi_wrapper.cc#L571
>
> const int max_profiles = vaMaxNumProfiles(va_display_);
> vaMaxNumProfiles will return (PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH -
> PIPE_VIDEO_PROFILE_UNKNOWN) in mesa.
>
>  int num_supported_profiles;
>   VAStatus va_res = vaQueryConfigProfiles(va_display_, _profiles[0],
>   _supported_profiles);
>   VA_SUCCESS_OR_RETURN(va_res, "vaQueryConfigProfiles failed", false);
>   if (num_supported_profiles < 0 || num_supported_profiles > max_profiles) {
> LOG(ERROR) << "vaQueryConfigProfiles returned: " << 
> num_supported_profiles;
> return false;
>