[Mesa-dev] [Bug 109443] Build failure with MSVC 2017 when using Scons >= 3.0.2

2019-02-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109443

Alex Granni  changed:

   What|Removed |Added

Summary|Build failure with MSVC |Build failure with MSVC
   |2017 when using Scons >=|2017 when using Scons >=
   |3.0.3   |3.0.2

-- 
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 1/3] egl/sl: split out swrast probe into separate function

2019-02-17 Thread Mathias Fröhlich
Emil,

indeed this is easier to read.

For patch #1 and #2 you get 

Reviewed-by: Mathias Fröhlich 

For patch #3, I don't know vgem good enough to judge the big picture.
The change within mesa itself looks technically correct.

best

Mathias


On Tuesday, 5 February 2019 16:31:06 CET Emil Velikov wrote:
> From: Emil Velikov 
> 
> Make the code a bit easier to read.
> 
> As a bonus point this makes it obvious that we forgot to call
> _eglAddDevice() for the device - do so.
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/egl/drivers/dri2/platform_surfaceless.c | 46 -
>  1 file changed, 27 insertions(+), 19 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
> b/src/egl/drivers/dri2/platform_surfaceless.c
> index f9809561611..d6e48ba11b2 100644
> --- a/src/egl/drivers/dri2/platform_surfaceless.c
> +++ b/src/egl/drivers/dri2/platform_surfaceless.c
> @@ -322,25 +322,27 @@ surfaceless_probe_device(_EGLDisplay *dpy, bool swrast)
>dri2_dpy->loader_extensions = NULL;
> }
>  
> -   /* No DRM device, so attempt to fall back to software path w/o DRM. */
> -   if (swrast) {
> -  _eglLog(_EGL_DEBUG, "Falling back to surfaceless swrast without DRM.");
> -  dri2_dpy->fd = -1;
> -  dri2_dpy->driver_name = strdup("swrast");
> -  if (!dri2_dpy->driver_name) {
> - return false;
> -  }
> +   return false;
> +}
>  
> -  if (dri2_load_driver_swrast(dpy)) {
> - dri2_dpy->loader_extensions = swrast_loader_extensions;
> - return true;
> -  }
> +static bool
> +surfaceless_probe_device_sw(_EGLDisplay *dpy)
> +{
> +   struct dri2_egl_display *dri2_dpy = dpy->DriverData;
>  
> -  free(dri2_dpy->driver_name);
> -  dri2_dpy->driver_name = NULL;
> -   }
> +   dri2_dpy->fd = -1;
> +   dpy->Device = _eglAddDevice(dri2_dpy->fd, true);
> +   assert(dpy->Device);
>  
> -   return false;
> +   dri2_dpy->driver_name = strdup("swrast");
> +   if (!dri2_dpy->driver_name)
> +  return false;
> +
> +   if (!dri2_load_driver_swrast(dpy))
> +  return false;
> +
> +   dri2_dpy->loader_extensions = swrast_loader_extensions;
> +   return true;
>  }
>  
>  EGLBoolean
> @@ -364,9 +366,15 @@ dri2_initialize_surfaceless(_EGLDriver *drv, _EGLDisplay 
> *disp)
>   "No hardware driver found, falling back to software 
> rendering");
> }
>  
> -   if (!driver_loaded && !surfaceless_probe_device(disp, true)) {
> -  err = "DRI2: failed to load driver";
> -  goto cleanup;
> +   if (!driver_loaded)
> +  driver_loaded = surfaceless_probe_device(disp, true);
> +
> +   if (!driver_loaded) {
> +  _eglLog(_EGL_DEBUG, "Falling back to surfaceless swrast without DRM.");
> +  if (!surfaceless_probe_device_sw(disp)) {
> + err = "DRI2: failed to load driver";
> + goto cleanup;
> +  }
> }
>  
> if (!dri2_create_screen(disp)) {
> 




___
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.

2019-02-17 Thread Jonathan Gray
Compared to linux and libdrm Mesa is missing a VLV and ICL id.

0x0f30
ff049b6ce21d2814451afd4a116d001712e0116b
drm/i915: bind driver to ValleyView chipsets

0x8A70
d55cb4fa2cf0105bfb16b60a2846737b91fdc173
drm/i915/icl: Add the ICL PCI IDs

The Intel Media SDK describes these as

/* VLV */
{ 0x0f30, MFX_HW_VLV, MFX_GT1 },   /* VLV mobile */

/* ICL LP */
{ 0x8A70, MFX_HW_ICL_LP, MFX_GT1 }

and libdrm's intel_chipset.h describes the VLV id as

#define PCI_CHIP_VALLEYVIEW_PO  0x0f30 /* VLV PO board */

It isn't clear what the ICL configuration should be from public
information.

diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index b91abd7a3f9..3568007b1ef 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
@@ -86,6 +86,7 @@ CHIPSET(0x0D2B, hsw_gt3, "Intel(R) Haswell")
 CHIPSET(0x0D0E, hsw_gt1, "Intel(R) Haswell")
 CHIPSET(0x0D1E, hsw_gt2, "Intel(R) Haswell")
 CHIPSET(0x0D2E, hsw_gt3, "Intel(R) Haswell")
+CHIPSET(0x0F30, byt, "Intel(R) Bay Trail")
 CHIPSET(0x0F31, byt, "Intel(R) Bay Trail")
 CHIPSET(0x0F32, byt, "Intel(R) Bay Trail")
 CHIPSET(0x0F33, byt, "Intel(R) Bay Trail")
@@ -212,4 +213,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)")
 CHIPSET(0x8A5D, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
+CHIPSET(0x8A70, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
 CHIPSET(0x8A71, icl_1x8, "Intel(R) HD Graphics (Ice Lake 1x8 GT0.5)")
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] panfrost: Stub out separate stencil functions

2019-02-17 Thread Alyssa Rosenzweig
This is not yet functional, but it resolves a crash in various apps and
provides a framework for further work.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_resource.c | 27 ++---
 src/gallium/drivers/panfrost/pan_resource.h |  2 ++
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index a38ab5e9928..0a00033780e 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -536,15 +536,34 @@ panfrost_invalidate_resource(struct pipe_context *pctx, 
struct pipe_resource *pr
 //fprintf(stderr, "TODO %s\n", __func__);
 }
 
+static enum pipe_format
+panfrost_resource_get_internal_format(struct pipe_resource *prsrc)
+{
+return prsrc->format;
+}
+
+static void
+panfrost_resource_set_stencil(struct pipe_resource *prsrc,
+  struct pipe_resource *stencil)
+{
+pan_resource(prsrc)->separate_stencil = pan_resource(stencil);
+}
+
+static struct pipe_resource *
+panfrost_resource_get_stencil(struct pipe_resource *prsrc)
+{
+return &pan_resource(prsrc)->separate_stencil->base;
+}
+
 static const struct u_transfer_vtbl transfer_vtbl = {
 .resource_create  = panfrost_resource_create,
 .resource_destroy = panfrost_resource_destroy,
 .transfer_map = panfrost_transfer_map,
 .transfer_unmap   = panfrost_transfer_unmap,
 .transfer_flush_region= u_default_transfer_flush_region,
-//.get_internal_format  = panfrost_resource_get_internal_format,
-//.set_stencil  = panfrost_resource_set_stencil,
-//.get_stencil  = panfrost_resource_get_stencil,
+.get_internal_format  = panfrost_resource_get_internal_format,
+.set_stencil  = panfrost_resource_set_stencil,
+.get_stencil  = panfrost_resource_get_stencil,
 };
 
 void
@@ -557,7 +576,7 @@ panfrost_resource_screen_init(struct panfrost_screen 
*pscreen)
 pscreen->base.resource_from_handle = panfrost_resource_from_handle;
 pscreen->base.resource_get_handle = panfrost_resource_get_handle;
 pscreen->base.transfer_helper = 
u_transfer_helper_create(&transfer_vtbl,
-true, true,
+true, false,
 true, true);
 
 pb_slabs_init(&pscreen->slabs,
diff --git a/src/gallium/drivers/panfrost/pan_resource.h 
b/src/gallium/drivers/panfrost/pan_resource.h
index af92fa48ec9..8ebff16fac4 100644
--- a/src/gallium/drivers/panfrost/pan_resource.h
+++ b/src/gallium/drivers/panfrost/pan_resource.h
@@ -70,6 +70,8 @@ struct panfrost_resource {
 
 struct panfrost_bo *bo;
 struct renderonly_scanout *scanout;
+
+struct panfrost_resource *separate_stencil;
 };
 
 static inline struct panfrost_resource *
-- 
2.20.1

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

[Mesa-dev] [PATCH 4/7] panfrost: Update extended branch disassembly

2019-02-17 Thread Alyssa Rosenzweig
Partial support was previously included in the disassembler, but based
on a buggy form of the ISA. This corrects the disassembly. Additionally,
we now prefix extended branches with "brx", to visually differentiate
from compact branches prefixed with "br".

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/midgard/disassemble.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c 
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index afde3fdbbcd..7e5c5803f75 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -373,6 +373,10 @@ static void
 print_branch_op(int op)
 {
 switch (op) {
+case midgard_jmp_writeout_op_branch_uncond:
+printf("uncond.");
+break;
+
 case midgard_jmp_writeout_op_branch_cond:
 printf("cond.");
 break;
@@ -412,6 +416,7 @@ print_branch_cond(int cond)
 break;
 
 default:
+printf("unk%X", cond);
 break;
 }
 }
@@ -470,17 +475,13 @@ print_extended_branch_writeout_field(uint8_t *words)
 midgard_branch_extended br;
 memcpy((char *) &br, (char *) words, sizeof(br));
 
-printf("br.");
+printf("brx.");
 
 print_branch_op(br.op);
 print_branch_cond(br.cond);
 
-/* XXX: This can't be right */
 if (br.unknown)
-printf(".unknown%d\n", br.unknown);
-
-if (br.zero)
-printf(".zero%d\n", br.zero);
+printf(".unknown%d", br.unknown);
 
 printf(" ");
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 3/7] panfrost: Rectify doubleplusungood extended branch

2019-02-17 Thread Alyssa Rosenzweig
Midgard features "compact branches" and "extended branches", i.e.
corresponds to short jumps and far jumps. The form of the extended
branch was previously incorrect in the ISA headers; this patch corrects
it.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/midgard/midgard.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard.h 
b/src/gallium/drivers/panfrost/midgard/midgard.h
index b6cd38a5cd0..04e195a635d 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard.h
+++ b/src/gallium/drivers/panfrost/midgard/midgard.h
@@ -231,8 +231,7 @@ __attribute__((__packed__))
 midgard_jmp_writeout_op op : 3; /* == branch_cond */
 unsigned dest_tag : 4; /* tag of branch destination */
 unsigned unknown : 2;
-signed offset : 7;
-unsigned zero : 16;
+signed offset : 23;
 unsigned cond : 16;
 }
 midgard_branch_extended;
-- 
2.20.1

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

[Mesa-dev] [PATCH 7/7] panfrost: Verify and print brx condition in disasm

2019-02-17 Thread Alyssa Rosenzweig
The condition code in extended branches is repeated 8 times for unclear
reasons; accordingly, the code would be disassembled as "unknown",
"unknown", etc. This patch correctly masks off the lower two bits to
find the true code to print, verifying that the code is repeated as
believed to be necessary (providing some assurance for compiler quality
and an assert trip in case we encounter a shader in the wild that breaks
the convention).

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/midgard/disassemble.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c 
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 7e5c5803f75..66d32d942c4 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -478,7 +478,16 @@ print_extended_branch_writeout_field(uint8_t *words)
 printf("brx.");
 
 print_branch_op(br.op);
-print_branch_cond(br.cond);
+
+/* Condition repeated 8 times in all known cases. Check this. */
+
+unsigned cond = br.cond & 0x3;
+
+for (unsigned i = 0; i < 16; i += 2) {
+assert(((br.cond >> i) & 0x3) == cond);
+}
+
+print_branch_cond(cond);
 
 if (br.unknown)
 printf(".unknown%d", br.unknown);
-- 
2.20.1

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

[Mesa-dev] [PATCH 6/7] panfrost: Dynamically set discard branch targets

2019-02-17 Thread Alyssa Rosenzweig
discard and discard_if are both implemented with the branching pipeline
on Midgard; essentially, we branch to the end of the fragment shader in
a special "discard" mode, setting the condition as necessary.
Previously, we hardcoded the form of this instruction, which worked for
very simple shaders but was incorrect for anything remotely interesting.
This patch instead emits logical branches in the IR, which are flattened
to real discard ops the same way other branches are, allowing targets to
be computed correctly.

Signed-off-by: Alyssa Rosenzweig 
---
 .../panfrost/midgard/midgard_compile.c| 66 +--
 1 file changed, 46 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 7b990fe709a..a7da54c00f9 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -64,11 +64,13 @@ typedef struct {
 struct midgard_block;
 
 /* Target types. Defaults to TARGET_GOTO (the type corresponding directly to
- * the hardware), hence why that must be zero */
+ * the hardware), hence why that must be zero. TARGET_DISCARD signals this
+ * instruction is actually a discard op. */
 
 #define TARGET_GOTO 0
 #define TARGET_BREAK 1
 #define TARGET_CONTINUE 2
+#define TARGET_DISCARD 3
 
 typedef struct midgard_branch {
 /* If conditional, the condition is specified in r31.w */
@@ -323,7 +325,7 @@ midgard_create_branch_extended( midgard_condition cond,
 (cond << 0);
 
 midgard_branch_extended branch = {
-.op = midgard_jmp_writeout_op_branch_cond,
+.op = op,
 .dest_tag = dest_tag,
 .offset = quadword_offset,
 .cond = duplicated_cond
@@ -1151,10 +1153,11 @@ emit_intrinsic(compiler_context *ctx, 
nir_intrinsic_instr *instr)
 /* fallthrough */
 
 case nir_intrinsic_discard: {
-midgard_condition cond = instr->intrinsic == 
nir_intrinsic_discard_if ?
- midgard_condition_true : 
midgard_condition_always;
+bool conditional = instr->intrinsic == 
nir_intrinsic_discard_if;
+struct midgard_instruction discard = v_branch(conditional, 
false);
+discard.branch.target_type = TARGET_DISCARD;
+emit_mir_instruction(ctx, discard);
 
-EMIT(alu_br_compact_cond, midgard_jmp_writeout_op_discard, 0, 
2, cond);
 ctx->can_discard = true;
 break;
 }
@@ -3522,19 +3525,40 @@ midgard_compile_shader_nir(nir_shader *nir, 
midgard_program *program, bool is_bl
 
 if (ins->prepacked_branch) continue;
 
+/* Parse some basic branch info */
+bool is_compact = ins->unit == 
ALU_ENAB_BR_COMPACT;
+bool is_conditional = ins->branch.conditional;
+bool is_inverted = 
ins->branch.invert_conditional;
+bool is_discard = ins->branch.target_type == 
TARGET_DISCARD;
+
 /* Determine the block we're jumping to */
 int target_number = ins->branch.target_block;
 
-midgard_block *target = mir_get_block(ctx, 
target_number);
-assert(target);
-
-/* Report the destination tag. */
-int dest_tag = 
midgard_get_first_tag_from_block(ctx, target_number);
+/* Report the destination tag. Discards don't 
need this */
+int dest_tag = is_discard ? 0 : 
midgard_get_first_tag_from_block(ctx, target_number);
 
 /* Count up the number of quadwords we're 
jumping over. That is, the number of quadwords in each of the blocks between 
(br_block_idx, target_number) */
 int quadword_offset = 0;
 
-if (target_number > br_block_idx) {
+if (is_discard) {
+/* Jump to the end of the shader. We
+ * need to include not only the
+ * following blocks, but also the
+ * contents of our current block (since
+ * discard can come in the middle of
+ * the block) */
+
+midgard_block *blk = 
mir_get_block(ctx, br_block_idx + 1);
+
+for (midgard_bundle *bun = bundle + 1; 
bun < (midgard_bundle *)((char*) block->bundles.data + block->bundles.size); 
+

[Mesa-dev] [PATCH 5/7] panfrost/midgard: Emit extended branches

2019-02-17 Thread Alyssa Rosenzweig
Previously, we only emitted compact branches; however, the offset range
of these branches is too small for many real world shaders. This patch
implements support for emitting extended branches and switches to always
using them for control flow. This incurs a code size and possibly
performance penalty, but expands the range of working shaders and
provides opportunity for further optimization.

Support for emitting compact branches is retained but this code path is
presently unused. In the future, we'll want to heuristically determine
which type of branch should be emitted for optimal codegen.

Signed-off-by: Alyssa Rosenzweig 
---
 .../drivers/panfrost/midgard/helpers.h|  7 ++
 .../panfrost/midgard/midgard_compile.c| 94 +++
 2 files changed, 84 insertions(+), 17 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h 
b/src/gallium/drivers/panfrost/midgard/helpers.h
index b8ccea8bcd8..6940f27b4ab 100644
--- a/src/gallium/drivers/panfrost/midgard/helpers.h
+++ b/src/gallium/drivers/panfrost/midgard/helpers.h
@@ -158,6 +158,13 @@ midgard_is_integer_op(int op)
 }
 }
 
+/* Is this unit a branch? */
+static bool
+midgard_is_branch_unit(unsigned unit)
+{
+return (unit == ALU_ENAB_BRANCH) || (unit == ALU_ENAB_BR_COMPACT);
+}
+
 /* There are five ALU units: VMUL, VADD, SMUL, SADD, LUT. A given opcode is
  * implemented on some subset of these units (or occassionally all of them).
  * This table encodes a bit mask of valid units for each opcode, so the
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index bcd6bf151c1..7b990fe709a 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -126,6 +126,7 @@ typedef struct midgard_instruction {
 midgard_load_store_word load_store;
 midgard_vector_alu alu;
 midgard_texture_word texture;
+midgard_branch_extended branch_extended;
 uint16_t br_compact;
 
 /* General branch, rather than packed br_compact. Higher level
@@ -293,7 +294,7 @@ v_branch(bool conditional, bool invert)
 {
 midgard_instruction ins = {
 .type = TAG_ALU_4,
-.unit = ALU_ENAB_BR_COMPACT,
+.unit = ALU_ENAB_BRANCH,
 .compact_branch = true,
 .branch = {
 .conditional = conditional,
@@ -304,6 +305,33 @@ v_branch(bool conditional, bool invert)
 return ins;
 }
 
+static midgard_branch_extended
+midgard_create_branch_extended( midgard_condition cond,
+midgard_jmp_writeout_op op,
+unsigned dest_tag,
+signed quadword_offset)
+{
+/* For unclear reasons, the condition code is repeated 8 times */
+uint16_t duplicated_cond =
+(cond << 14) |
+(cond << 12) |
+(cond << 10) |
+(cond << 8) |
+(cond << 6) |
+(cond << 4) |
+(cond << 2) |
+(cond << 0);
+
+midgard_branch_extended branch = {
+.op = midgard_jmp_writeout_op_branch_cond,
+.dest_tag = dest_tag,
+.offset = quadword_offset,
+.cond = duplicated_cond
+};
+
+return branch;
+}
+
 typedef struct midgard_bundle {
 /* Tag for the overall bundle */
 int tag;
@@ -2267,9 +2295,15 @@ schedule_bundle(compiler_context *ctx, midgard_block 
*block, midgard_instruction
 }
 }
 
-bundle.body_size[bundle.body_words_count] = 
sizeof(ains->br_compact);
-
memcpy(&bundle.body_words[bundle.body_words_count++], &ains->br_compact, 
sizeof(ains->br_compact));
-bytes_emitted += sizeof(ains->br_compact);
+if (ains->unit == ALU_ENAB_BRANCH) {
+
bundle.body_size[bundle.body_words_count] = sizeof(midgard_branch_extended);
+
memcpy(&bundle.body_words[bundle.body_words_count++], &ains->branch_extended, 
sizeof(midgard_branch_extended));
+bytes_emitted += 
sizeof(midgard_branch_extended);
+} else {
+
bundle.body_size[bundle.body_words_count] = sizeof(ains->br_compact);
+
memcpy(&bundle.body_words[bundle.body_words_count++], &ains->br_compact, 
sizeof(ains->br_compact));
+bytes_emitted += 
sizeof(ains->br_compact);
+}
 } e

[Mesa-dev] [PATCH 0/7] panfrost: Improve branching in Midgard compiler

2019-02-17 Thread Alyssa Rosenzweig
This patch series generally improves the state of branching in the
Midgard compiler. Notably, in addition to resolving a number of bugs
breaking branching in real apps, it implements support for extended
branches (far jumps). In total, the series enables much more
sophisticated branching, fixing a nontrivial shader in a target app.
Performance is wanting at the moment, but Midgard is believed to use
small warp sizes, so this should be fixable in the future.

Alyssa Rosenzweig (7):
  panfrost/midgard: Refactor tag lookahead code
  panfrost/midgard: Fix nested/chained if-else
  panfrost: Rectify doubleplusungood extended branch
  panfrost: Update extended branch disassembly
  panfrost/midgard: Emit extended branches
  panfrost: Dynamically set discard branch targets
  panfrost: Verify and print brx condition in disasm

 .../drivers/panfrost/midgard/disassemble.c|  24 ++-
 .../drivers/panfrost/midgard/helpers.h|   7 +
 .../drivers/panfrost/midgard/midgard.h|   3 +-
 .../panfrost/midgard/midgard_compile.c| 202 +-
 4 files changed, 171 insertions(+), 65 deletions(-)

-- 
2.20.1

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

[Mesa-dev] [PATCH 2/7] panfrost/midgard: Fix nested/chained if-else

2019-02-17 Thread Alyssa Rosenzweig
An if-else statement is compiled to a conditional branch (from the start
to the second block) and an unconditional branch (from the end of the
first block to the end of the else). We previously incorrectly computed
the block index of the unconditional branch to be exactly one after that
of the conditional branch, valid for a single if-else statement but
nothing fancier. This patch correctly computes the unconditional branch
target, fixing more complex if-else chains.

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

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index de9420685f5..bcd6bf151c1 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -3182,20 +3182,20 @@ emit_if(struct compiler_context *ctx, nir_if *nif)
 int else_idx = ctx->block_count;
 int count_in = ctx->instruction_count;
 midgard_block *else_block = emit_cf_list(ctx, &nif->else_list);
+int after_else_idx = ctx->block_count;
 
 /* Now that we have the subblocks emitted, fix up the branches */
 
 assert(then_block);
 assert(else_block);
 
-
 if (ctx->instruction_count == count_in) {
 /* The else block is empty, so don't emit an exit jump */
 mir_remove_instruction(then_exit);
-then_branch->branch.target_block = else_idx + 1;
+then_branch->branch.target_block = after_else_idx;
 } else {
 then_branch->branch.target_block = else_idx;
-then_exit->branch.target_block = else_idx + 1;
+then_exit->branch.target_block = after_else_idx;
 }
 }
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 1/7] panfrost/midgard: Refactor tag lookahead code

2019-02-17 Thread Alyssa Rosenzweig
Each Midgard instruction is scheduled to a particular instruction type
("tag"). Presumably the hardware prefetches memory based on tag, so it
is required to report out the first tag to the command stream and the
next tag of a branch target. This procedure was implemented in two
separate parts of the compiler (one time with a slight bug relating to
empty blocks); this patch refactors to unite the two routines and solve
the bug when branching to empty blocks.

Signed-off-by: Alyssa Rosenzweig 
---
 .../panfrost/midgard/midgard_compile.c| 58 ++-
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index cd8412c2dff..de9420685f5 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -3283,6 +3283,33 @@ emit_cf_list(struct compiler_context *ctx, struct 
exec_list *list)
 return start_block;
 }
 
+/* Due to lookahead, we need to report the first tag executed in the command
+ * stream and in branch targets. An initial block might be empty, so iterate
+ * until we find one that 'works' */
+
+static unsigned
+midgard_get_first_tag_from_block(compiler_context *ctx, unsigned block_idx)
+{
+midgard_block *initial_block = mir_get_block(ctx, block_idx);
+
+unsigned first_tag = 0;
+
+do {
+midgard_bundle *initial_bundle = 
util_dynarray_element(&initial_block->bundles, midgard_bundle, 0);
+
+if (initial_bundle) {
+first_tag = initial_bundle->tag;
+break;
+}
+
+/* Initial block is empty, try the next block */
+initial_block = list_first_entry(&(initial_block->link), 
midgard_block, link);
+} while(initial_block != NULL);
+
+assert(first_tag);
+return first_tag;
+}
+
 int
 midgard_compile_shader_nir(nir_shader *nir, midgard_program *program, bool 
is_blend)
 {
@@ -3465,11 +3492,8 @@ midgard_compile_shader_nir(nir_shader *nir, 
midgard_program *program, bool is_bl
 midgard_block *target = mir_get_block(ctx, 
target_number);
 assert(target);
 
-/* Determine the destination tag */
-midgard_bundle *first = 
util_dynarray_element(&target->bundles, midgard_bundle, 0);
-assert(first);
-
-int dest_tag = first->tag;
+/* Report the destination tag. */
+int dest_tag = 
midgard_get_first_tag_from_block(ctx, target_number);
 
 /* Count up the number of quadwords we're 
jumping over. That is, the number of quadwords in each of the blocks between 
(br_block_idx, target_number) */
 int quadword_offset = 0;
@@ -3568,28 +3592,8 @@ midgard_compile_shader_nir(nir_shader *nir, 
midgard_program *program, bool is_bl
 
 free(source_order_bundles);
 
-/* Due to lookahead, we need to report in the command stream the first
- * tag executed. An initial block might be empty, so iterate until we
- * find one that 'works' */
-
-midgard_block *initial_block = list_first_entry(&ctx->blocks, 
midgard_block, link);
-
-program->first_tag = 0;
-
-do {
-midgard_bundle *initial_bundle = 
util_dynarray_element(&initial_block->bundles, midgard_bundle, 0);
-
-if (initial_bundle) {
-program->first_tag = initial_bundle->tag;
-break;
-}
-
-/* Initial block is empty, try the next block */
-initial_block = list_first_entry(&(initial_block->link), 
midgard_block, link);
-} while(initial_block != NULL);
-
-/* Make sure we actually set the tag */
-assert(program->first_tag);
+/* Report the very first tag executed */
+program->first_tag = midgard_get_first_tag_from_block(ctx, 0);
 
 /* Deal with off-by-one related to the fencepost problem */
 program->work_register_count = ctx->work_registers + 1;
-- 
2.20.1

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

[Mesa-dev] [Bug 99553] Tracker bug for runnning OpenCL applications on Clover

2019-02-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 108572, which changed state.

Bug 108572 Summary: Could not start gimp (probably due to opencl)
https://bugs.freedesktop.org/show_bug.cgi?id=108572

   What|Removed |Added

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

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

[Mesa-dev] [Bug 99553] Tracker bug for runnning OpenCL applications on Clover

2019-02-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=99553

Timothy Arceri  changed:

   What|Removed |Added

 Depends on||108572


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=108572
[Bug 108572] Could not start gimp (probably due to opencl)
-- 
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] i965: Be resilient in the face of GPU hangs

2019-02-17 Thread Kenneth Graunke
On Saturday, February 16, 2019 4:46:27 AM PST Chris Wilson wrote:
> If we hang the GPU and end up banning our context, we will no longer be
> able to submit and abort with an error (exit(1) no less). As we submit
> minimal incremental batches that rely on the logical context state of
> previous batches, we can not rely on the kernel's recovery mechanism
> which tries to restore the context back to a "golden" renderstate (the
> default HW setup) and replay the batches in flight. Instead, we must
> create a new context and set it up, including all the lost register
> settings that we only apply once during setup, before allow the user to
> continue rendering. The batches already submitted are lost
> (unrecoverable) so there will be a momentarily glitch and lost rendering
> across frames, but the application should be able to recover and
> continue on fairly oblivious.
> 
> To make wedging even more likely, we use a new "no recovery" context
> parameter that tells the kernel to not even attempt to replay any
> batches in flight against the default context image, as experience shows
> the HW is not always robust enough to cope with the conflicting state.
> 
> v2: Export brw_reset_state() to improve the amount of state we clobber
> on return to a starting context. (Kenneth)
> 
> Cc: Kenneth Graunke 
> ---
> The intent was to refactor the existing brw_reset_state() out of
> brw_init_state() so that we could reuse, so reuse it!
> ---
>  src/mesa/drivers/dri/i965/brw_bufmgr.c| 25 +++
>  src/mesa/drivers/dri/i965/brw_bufmgr.h|  2 ++
>  src/mesa/drivers/dri/i965/brw_context.h   |  3 +++
>  src/mesa/drivers/dri/i965/brw_state_upload.c  | 22 
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 20 +++
>  5 files changed, 67 insertions(+), 5 deletions(-)

Even better, thanks!

Reviewed-by: Kenneth Graunke 


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

Re: [Mesa-dev] [PATCH v2 2/3] i965: Add INTEL_DEBUG=hang

2019-02-17 Thread Kenneth Graunke
On Saturday, February 16, 2019 4:41:30 AM PST Chris Wilson wrote:
> Introduce a new debug option to wilfully cause the GPU to hang and for
> the kernel to accuse of being neglectful.
> ---
>  src/intel/Makefile.sources|   2 +
>  src/intel/common/gen_debug.c  |   1 +
>  src/intel/common/gen_debug.h  |   1 +
>  src/intel/common/gen_hang.c   | 176 ++
>  src/intel/common/gen_hang.h   |  51 +
>  src/intel/common/meson.build  |   2 +
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c |  14 ++
>  7 files changed, 247 insertions(+)
>  create mode 100644 src/intel/common/gen_hang.c
>  create mode 100644 src/intel/common/gen_hang.h

This seems useful for testing recovery, but I am unsure whether we want
to ship it as an INTEL_DEBUG option available at runtime in all builds.

Perhaps others have an opinion...


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