Re: [Mesa-dev] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware
On Wed, 1 May 2019 at 12:34, Ilia Mirkin wrote: > > On Tue, Apr 30, 2019 at 10:42 AM Ilia Mirkin wrote: > > > > On Tue, Apr 30, 2019 at 2:48 AM Dave Airlie wrote: > > > > > > On Tue, 30 Apr 2019 at 08:47, Dave Airlie wrote: > > > > > > > > On Tue, 30 Apr 2019 at 08:42, Ilia Mirkin wrote: > > > > > > > > > > Thing is, I think that would not be enough - with the "recent" (like > > > > > past 2 years) CSO/state change detection changes, I think that you can > > > > > end up with no sampler set for a buffer view. Perhaps someone with the > > > > > hw can investigate what goes wrong? > > > > > > > > I'm trying to get a live r600/700 machine, I plugged in my rv635 and > > > > rv740 gpus, and they both seemed toast, I've got an rv635 laptop I'll > > > > try and get up to date. > > > > > > I've found a working rv770 and reproduced it here. This isn't an > > > indication I'll get to fix it soon, but I will try. > > > > When I was debugging this issue on nouveau (and trying to nail down > > specifically what didn't work and what was required to make it work), > > I found that using a gallium test to debug this made the issues at > > hand quite obvious, and I didn't have to worry about how to force the > > st to assign mappings here or there for views or samplers. I'm not > > sure if I still have those left over, but I'll have a look tonight. > > They're also not terribly difficult to write. > > In case it's helpful: > https://people.freedesktop.org/~imirkin/tbo-tex.c which fits together > with the other gallium/tests/trivial ones. > > I think there were associated Makefile.am changes, but with the > removal of autoconf, I probably lost the local changes. > > In its current form, it doesn't create a sampler, but you can see how > trivial/quad-tex.c does it if you want to play around with having > samplers around. You might also have to use PIPE_FORMAT_R8G8B8A8_UNORM > instead of the BGRA variant for the view's format (iirc r600 has some > limitations around swizzling and buffer textures). > Thanks for test, but I ended up installing firefox and watching the pain, then found it by accident. https://patchwork.freedesktop.org/patch/302675/ For Viktor to test. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600: reset tex array override even when no view bound
From: Dave Airlie
If no view is bound we still should reset the override to 0
and array mode.
This should fix misrendering in firefox WebRender since
the pbo sampler was removed.
Fixes: 1250383e36 (st/mesa: remove sampler associated with buffer texture in
pbo logic)
---
src/gallium/drivers/r600/r600_state.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index f86764f5220..86c1ca96e0f 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -1839,16 +1839,16 @@ static void r600_emit_sampler_states(struct
r600_context *rctx,
* filtering between layers.
* Don't update TEX_ARRAY_OVERRIDE if we don't have the sampler
view.
*/
- if (rview) {
- enum pipe_texture_target target =
rview->base.texture->target;
- if (target == PIPE_TEXTURE_1D_ARRAY ||
- target == PIPE_TEXTURE_2D_ARRAY) {
- rstate->tex_sampler_words[0] |=
S_03C000_TEX_ARRAY_OVERRIDE(1);
- texinfo->is_array_sampler[i] = true;
- } else {
- rstate->tex_sampler_words[0] &=
C_03C000_TEX_ARRAY_OVERRIDE;
- texinfo->is_array_sampler[i] = false;
- }
+ enum pipe_texture_target target = PIPE_BUFFER;
+ if (rview)
+ target = rview->base.texture->target;
+ if (target == PIPE_TEXTURE_1D_ARRAY ||
+ target == PIPE_TEXTURE_2D_ARRAY) {
+ rstate->tex_sampler_words[0] |=
S_03C000_TEX_ARRAY_OVERRIDE(1);
+ texinfo->is_array_sampler[i] = true;
+ } else {
+ rstate->tex_sampler_words[0] &=
C_03C000_TEX_ARRAY_OVERRIDE;
+ texinfo->is_array_sampler[i] = false;
}
radeon_emit(cs, PKT3(PKT3_SET_SAMPLER, 3, 0));
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] panfrost/decode: Hit MRT blend shader enable bits
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/include/panfrost-job.h | 6 --
src/gallium/drivers/panfrost/pandecode/decode.c | 15 ++-
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index 97fcb0380dd..c2d922678b8 100644
--- a/src/gallium/drivers/panfrost/include/panfrost-job.h
+++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
@@ -424,8 +424,10 @@ struct mali_blend_meta {
u64 unk1;
-/* For programmable blending, these turn into the blend_shader address
*/
-struct mali_blend_equation blend_equation_1;
+union {
+struct mali_blend_equation blend_equation_1;
+mali_ptr blend_shader;
+};
u64 zero2;
struct mali_blend_equation blend_equation_2;
diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c
b/src/gallium/drivers/panfrost/pandecode/decode.c
index bb6f4b19711..9936249e524 100644
--- a/src/gallium/drivers/panfrost/pandecode/decode.c
+++ b/src/gallium/drivers/panfrost/pandecode/decode.c
@@ -1278,7 +1278,20 @@ pandecode_replay_vertex_tiler_postfix_pre(const struct
mali_vertex_tiler_postfix
#ifndef BIFROST
pandecode_prop("unk1 = 0x%" PRIx64, b->unk1);
-
pandecode_replay_blend_equation(>blend_equation_1, "_1");
+
+/* Depending on unk1, we determine if there's a
+ * blend shader */
+
+if ((b->unk1 & 0xF) >= 0x2) {
+blend_shader = true;
+
pandecode_replay_shader_address("blend_shader", b->blend_shader);
+} else {
+
pandecode_replay_blend_equation(>blend_equation_1, "_1");
+}
+
+/* This is always an equation, I think. If
+ * there's a shader, it just defaults to
+ * REPLACE (0x122) */
pandecode_replay_blend_equation(>blend_equation_2, "_2");
if (b->zero2) {
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] panfrost: Remove shader dump
Redundant via the midgard shader dump.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_blend_shaders.c | 4
src/gallium/drivers/panfrost/pan_screen.c| 1 -
src/gallium/drivers/panfrost/pan_util.h | 1 -
src/gallium/drivers/panfrost/pan_wallpaper.c | 3 ---
4 files changed, 9 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_blend_shaders.c
b/src/gallium/drivers/panfrost/pan_blend_shaders.c
index fadcdecb044..5367b7ccf5e 100644
--- a/src/gallium/drivers/panfrost/pan_blend_shaders.c
+++ b/src/gallium/drivers/panfrost/pan_blend_shaders.c
@@ -131,15 +131,11 @@ panfrost_make_blend_shader(struct panfrost_context *ctx,
struct panfrost_blend_s
/* Build a trivial blend shader */
nir_store_var(b, c_out, nir_blending_f(blend, b, s_src, s_dst, s_con),
0xFF);
- if (pan_debug & PAN_DBG_SHADERS)
- nir_print_shader(shader, stdout);
-
/* Compile the built shader */
midgard_program program;
midgard_compile_shader_nir(shader, , true);
-
/* Upload the shader */
int size = program.compiled.size;
diff --git a/src/gallium/drivers/panfrost/pan_screen.c
b/src/gallium/drivers/panfrost/pan_screen.c
index 5dddb801578..4f23dd5cdf0 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -54,7 +54,6 @@
static const struct debug_named_value debug_options[] = {
{"msgs", PAN_DBG_MSGS, "Print debug messages"},
- {"shaders", PAN_DBG_SHADERS, "Dump shaders in NIR"},
DEBUG_NAMED_VALUE_END
};
diff --git a/src/gallium/drivers/panfrost/pan_util.h
b/src/gallium/drivers/panfrost/pan_util.h
index 35d95d887c0..c467a35176f 100644
--- a/src/gallium/drivers/panfrost/pan_util.h
+++ b/src/gallium/drivers/panfrost/pan_util.h
@@ -29,7 +29,6 @@
#define PAN_UTIL_H
#define PAN_DBG_MSGS 0x0001
-#define PAN_DBG_SHADERS0x0002
extern int pan_debug;
diff --git a/src/gallium/drivers/panfrost/pan_wallpaper.c
b/src/gallium/drivers/panfrost/pan_wallpaper.c
index b402519a767..ac77ad089bc 100644
--- a/src/gallium/drivers/panfrost/pan_wallpaper.c
+++ b/src/gallium/drivers/panfrost/pan_wallpaper.c
@@ -79,9 +79,6 @@ panfrost_build_wallpaper_program()
nir_store_var(b, c_out, texel, 0xFF);
- if (pan_debug & PAN_DBG_SHADERS)
- nir_print_shader(shader, stdout);
-
return shader;
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/10] panfrost/midgard: Fix crash on unknown op
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src/gallium/drivers/panfrost/midgard/helpers.h
index 6d35f4de025..d2855cd89cd 100644
--- a/src/gallium/drivers/panfrost/midgard/helpers.h
+++ b/src/gallium/drivers/panfrost/midgard/helpers.h
@@ -264,6 +264,10 @@ static struct {
static bool
midgard_is_integer_op(int op)
{
-char prefix = alu_opcode_props[op].name[0];
-return (prefix == 'i') || (prefix == 'u');
+const char *name = alu_opcode_props[op].name;
+
+if (!name)
+return false;
+
+return (name[0] == 'i') || (name[0] == 'u');
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/10] panfrost/midgard/disasm: Fill in .int mod
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 0938486c883..4583e9e1584 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -107,7 +107,7 @@ print_reg(unsigned reg, unsigned bits)
static char *outmod_names[4] = {
"",
".pos",
-"",
+".int",
".sat"
};
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] panfrost: Fix blend shader upload
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/pan_blend_shaders.c | 3 +--
src/gallium/drivers/panfrost/pan_context.c | 18 +-
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_blend_shaders.c
b/src/gallium/drivers/panfrost/pan_blend_shaders.c
index 5367b7ccf5e..f716e85e3f5 100644
--- a/src/gallium/drivers/panfrost/pan_blend_shaders.c
+++ b/src/gallium/drivers/panfrost/pan_blend_shaders.c
@@ -96,7 +96,6 @@ void
panfrost_make_blend_shader(struct panfrost_context *ctx, struct
panfrost_blend_state *cso, const struct pipe_blend_color *blend_color)
{
const struct pipe_rt_blend_state *blend = >base.rt[0];
-mali_ptr *out = >blend_shader;
/* Build the shader */
@@ -150,7 +149,7 @@ panfrost_make_blend_shader(struct panfrost_context *ctx,
struct panfrost_blend_s
hot_color[c] = blend_color->color[c];
}
-*out = panfrost_upload(>shaders, dst, size, true) |
program.first_tag;
+cso->blend_shader = panfrost_upload(>shaders, dst, size, true) |
program.first_tag;
/* We need to switch to shader mode */
cso->has_blend_shader = true;
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 42db8317d37..c50c546a399 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -960,15 +960,22 @@ panfrost_emit_for_draw(struct panfrost_context *ctx, bool
with_vertex_data)
(ctx->blend->equation.alpha_mode == 0x122) &&
(ctx->blend->equation.color_mask == 0xf);
+/* Even on MFBD, the shader descriptor gets blend shaders. It's
+ * *also* copied to the blend_meta appended (by convention),
+ * but this is the field actually read by the hardware. (Or
+ * maybe both are read...?) */
+
+if (ctx->blend->has_blend_shader) {
+ctx->fragment_shader_core.blend_shader =
ctx->blend->blend_shader;
+}
+
if (ctx->require_sfbd) {
/* When only a single render target platform is used,
the blend
* information is inside the shader meta itself. We
* additionally need to signal CAN_DISCARD for
nontrivial blend
* modes (so we're able to read back the destination
buffer) */
-if (ctx->blend->has_blend_shader) {
-ctx->fragment_shader_core.blend_shader =
ctx->blend->blend_shader;
-} else {
+if (!ctx->blend->has_blend_shader) {
memcpy(>fragment_shader_core.blend_equation, >blend->equation,
sizeof(ctx->blend->equation));
}
@@ -1018,8 +1025,9 @@ panfrost_emit_for_draw(struct panfrost_context *ctx, bool
with_vertex_data)
},
};
-if (ctx->blend->has_blend_shader)
-memcpy(_meta[0].blend_equation_1,
>blend->blend_shader, sizeof(ctx->blend->blend_shader));
+if (ctx->blend->has_blend_shader) {
+blend_meta[0].blend_shader =
ctx->blend->blend_shader;
+}
memcpy(transfer.cpu + sizeof(struct mali_shader_meta),
blend_meta, sizeof(blend_meta));
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/10] panfrost/midgard: reg_mode_full -> reg_mode_32, etc
In preparation for 8-bit and 64-bit operands, let's not reinforce the
32-bit-centric biases in the ISA.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c | 6 +++---
src/gallium/drivers/panfrost/midgard/midgard.h | 8
.../drivers/panfrost/midgard/midgard_compile.c | 18 +-
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 719f5780863..ba1ab2bca5b 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -229,8 +229,8 @@ print_vector_field(const char *name, uint16_t *words,
uint16_t reg_word,
midgard_reg_info *reg_info = (midgard_reg_info *)_word;
midgard_vector_alu *alu_field = (midgard_vector_alu *) words;
-if (alu_field->reg_mode != midgard_reg_mode_half &&
-alu_field->reg_mode != midgard_reg_mode_full) {
+if (alu_field->reg_mode != midgard_reg_mode_16 &&
+alu_field->reg_mode != midgard_reg_mode_32) {
printf("unknown reg mode %u\n", alu_field->reg_mode);
}
@@ -245,7 +245,7 @@ print_vector_field(const char *name, uint16_t *words,
uint16_t reg_word,
bool half, out_half, out_high = false;
unsigned mask;
-half = (alu_field->reg_mode == midgard_reg_mode_half);
+half = (alu_field->reg_mode == midgard_reg_mode_16);
if (half) {
if (alu_field->mask & 0xF) {
diff --git a/src/gallium/drivers/panfrost/midgard/midgard.h
b/src/gallium/drivers/panfrost/midgard/midgard.h
index cd4882dad1f..e86f517442d 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard.h
+++ b/src/gallium/drivers/panfrost/midgard/midgard.h
@@ -164,10 +164,10 @@ typedef enum {
} midgard_outmod;
typedef enum {
-midgard_reg_mode_quarter = 0,
-midgard_reg_mode_half = 1,
-midgard_reg_mode_full = 2,
-midgard_reg_mode_double = 3 /* TODO: verify */
+midgard_reg_mode_8 = 0,
+midgard_reg_mode_16 = 1,
+midgard_reg_mode_32 = 2,
+midgard_reg_mode_64 = 3 /* TODO: verify */
} midgard_reg_mode;
typedef enum {
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 348ec861404..361c7364f00 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -316,7 +316,7 @@ v_fmov(unsigned src, midgard_vector_alu_src mod, unsigned
dest)
},
.alu = {
.op = midgard_alu_op_fmov,
-.reg_mode = midgard_reg_mode_full,
+.reg_mode = midgard_reg_mode_32,
.dest_override = midgard_dest_override_none,
.mask = 0xFF,
.src1 = vector_alu_srco_unsigned(zero_alu_src),
@@ -1038,7 +1038,7 @@ emit_condition(compiler_context *ctx, nir_src *src, bool
for_branch, unsigned co
},
.alu = {
.op = midgard_alu_op_iand,
-.reg_mode = midgard_reg_mode_full,
+.reg_mode = midgard_reg_mode_32,
.dest_override = midgard_dest_override_none,
.mask = (0x3 << 6), /* w */
.src1 = vector_alu_srco_unsigned(alu_src),
@@ -1066,7 +1066,7 @@ emit_indirect_offset(compiler_context *ctx, nir_src *src)
},
.alu = {
.op = midgard_alu_op_imov,
-.reg_mode = midgard_reg_mode_full,
+.reg_mode = midgard_reg_mode_32,
.dest_override = midgard_dest_override_none,
.mask = (0x3 << 6), /* w */
.src1 = vector_alu_srco_unsigned(zero_alu_src),
@@ -1328,7 +1328,7 @@ emit_alu(compiler_context *ctx, nir_alu_instr *instr)
midgard_vector_alu alu = {
.op = op,
-.reg_mode = midgard_reg_mode_full,
+.reg_mode = midgard_reg_mode_32,
.dest_override = midgard_dest_override_none,
.outmod = outmod,
@@ -1576,7 +1576,7 @@ emit_intrinsic(compiler_context *ctx, nir_intrinsic_instr
*instr)
},
.alu = {
.op = midgard_alu_op_u2f,
-.reg_mode =
midgard_reg_mode_half,
+.reg_mode =
midgard_reg_mode_16,
.dest_override =
midgard_dest_override_none,
.mask = 0xF,
[Mesa-dev] [PATCH 02/10] panfrost/midgard/disasm: Catch mask errors
We silently ignored certain bits of the mask, which causes issues when
disassembly 8/64-bit ops.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/disassemble.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index ba1ab2bca5b..7b71a9937ff 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -260,10 +260,21 @@ print_vector_field(const char *name, uint16_t *words,
uint16_t reg_word,
mask = alu_field->mask >> 4;
}
} else {
+/* For full 32-bit, every other bit is duplicated, so we only
+ * pick every other to find the effective mask */
+
mask = alu_field->mask & 1;
mask |= (alu_field->mask & 4) >> 1;
mask |= (alu_field->mask & 16) >> 2;
mask |= (alu_field->mask & 64) >> 3;
+
+/* ... but verify! */
+
+unsigned checked = alu_field->mask & 0x55;
+unsigned opposite = alu_field->mask & 0xAA;
+
+if ((checked << 1) != opposite)
+printf("/* %X */ ", alu_field->mask);
}
out_half = half;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/10] panfrost/midgard/disasm: Support 8-bit destination
Meanwhile, we're forced to disable dest_override, since it's not yet
clear how this interacts with other bitnesses (it'll likely need to be
overhauled in any case).
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 39 ++-
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 4583e9e1584..71f5c489528 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -298,27 +298,30 @@ print_vector_field(const char *name, uint16_t *words,
uint16_t reg_word,
out_half = half;
-if (alu_field->dest_override != midgard_dest_override_none) {
-if (out_half)
-printf("/* half */ ");
+/* First, print the destination */
+{
+int out_reg = reg_info->out_reg;
+unsigned bits = 32;
-out_half = true;
+if (alu_field->dest_override != midgard_dest_override_none) {
+printf("/* do%d */ ", alu_field->dest_override);
+}
-if (alu_field->dest_override == midgard_dest_override_lower)
-out_high = false;
-else if (alu_field->dest_override ==
midgard_dest_override_upper)
-out_high = true;
-else
-assert(0);
-}
+if (alu_field->reg_mode == midgard_reg_mode_16) {
+bits = 16;
+out_reg *= 2;
+out_reg += out_high;
+} else if (alu_field->reg_mode == midgard_reg_mode_8) {
+bits = 8;
+out_reg *= 4;
+out_reg += out_high;
+} else if (alu_field->reg_mode == midgard_reg_mode_64) {
+bits = 64;
+/* TODO */
+}
-if (out_half) {
-if (out_high)
-print_reg(2 * reg_info->out_reg + 1, 16);
-else
-print_reg(2 * reg_info->out_reg, 16);
-} else
-print_reg(reg_info->out_reg, 32);
+print_reg(out_reg, bits);
+}
if (mask != 0xF) {
unsigned i;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/10] panfrost/midgard/disasm: Handle dest_override generalized
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 90 ++-
1 file changed, 68 insertions(+), 22 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 8466a90b8d6..c893bc89a6c 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -274,6 +274,70 @@ print_immediate(uint16_t imm)
printf("#%g", _mesa_half_to_float(imm));
}
+static int
+bits_for_mode(midgard_reg_mode mode)
+{
+switch (mode) {
+case midgard_reg_mode_8:
+return 8;
+case midgard_reg_mode_16:
+return 16;
+case midgard_reg_mode_32:
+return 32;
+case midgard_reg_mode_64:
+return 64;
+default:
+return 0;
+}
+}
+
+static void
+print_dest(unsigned reg, midgard_reg_mode mode, midgard_dest_override
override, bool out_high)
+{
+bool overriden = override != midgard_dest_override_none;
+bool overriden_up = override == midgard_dest_override_upper;
+
+/* Depending on the mode and override, we determine the type of
+ * destination addressed. Absent an override, we address just the
+ * type of the operation itself, directly at the out_reg register
+ * (scaled if necessary to disambiguate, raised if necessary) */
+
+unsigned bits = bits_for_mode(mode);
+
+if (overriden)
+bits /= 2;
+
+/* Sanity check the override */
+
+if (overriden) {
+bool modeable = (mode == midgard_reg_mode_32) || (mode ==
midgard_reg_mode_16);
+bool known = override != 0x3; /* Unused value */
+bool uppable = !overriden_up || (mode == midgard_reg_mode_32);
+
+if (!(modeable && known && uppable))
+printf("/* do%d */ ", override);
+}
+
+switch (mode) {
+case midgard_reg_mode_8:
+case midgard_reg_mode_16:
+reg = reg * 2 + out_high;
+break;
+
+case midgard_reg_mode_32:
+if (overriden) {
+reg = (reg * 2) + overriden_up;
+}
+
+break;
+
+default:
+break;
+}
+
+print_reg(reg, bits);
+}
+
static void
print_vector_field(const char *name, uint16_t *words, uint16_t reg_word,
unsigned tabs)
@@ -329,29 +393,11 @@ print_vector_field(const char *name, uint16_t *words,
uint16_t reg_word,
}
/* First, print the destination */
-{
-int out_reg = reg_info->out_reg;
-unsigned bits = 32;
-
-if (alu_field->dest_override != midgard_dest_override_none) {
-printf("/* do%d */ ", alu_field->dest_override);
-}
-
-if (mode == midgard_reg_mode_16) {
-bits = 16;
-out_reg *= 2;
-out_reg += out_high;
-} else if (mode == midgard_reg_mode_8) {
-bits = 8;
-out_reg *= 2;
-out_reg += out_high;
-} else if (mode == midgard_reg_mode_64) {
-bits = 64;
-/* TODO */
-}
+print_dest(reg_info->out_reg, mode, alu_field->dest_override,
out_high);
-print_reg(out_reg, bits);
-}
+/* The semantics here are not totally grokked yet */
+if (alu_field->dest_override == midgard_dest_override_upper)
+out_high = true;
if (mask != 0xF) {
unsigned i;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/10] panfrost/midgard/disasm: Stub out 64-bit
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 20 ++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 9469cac6e75..8466a90b8d6 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -75,6 +75,8 @@ prefix_for_bits(unsigned bits)
return 'q';
case 16:
return 'h';
+case 64:
+return 'd';
default:
return 0;
}
@@ -219,7 +221,19 @@ print_vector_src(unsigned src_binary, bool out_high,
print_reg(reg, 32);
}
} else if (mode == midgard_reg_mode_64) {
-/* TODO */
+if (src->rep_high)
+printf(" /* rep_high */ ");
+
+if (src->rep_low)
+printf(" /* rep_low */ ");
+
+if (src->half)
+printf(" /* half */ ");
+
+if (out_high)
+printf(" /* out_high */ ");
+
+print_reg(reg, 64);
}
//swizzle
@@ -268,10 +282,6 @@ print_vector_field(const char *name, uint16_t *words,
uint16_t reg_word,
midgard_vector_alu *alu_field = (midgard_vector_alu *) words;
midgard_reg_mode mode = alu_field->reg_mode;
-if (mode == midgard_reg_mode_64) {
-printf("unknown reg mode %u\n", alu_field->reg_mode);
-}
-
/* For now, prefix instruction names with their unit, until we
* understand how this works on a deeper level */
printf("%s.", name);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] panfrost/midgard/disasm: Extend print_reg to 8-bit
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 49 +--
1 file changed, 34 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 7b71a9937ff..0938486c883 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -67,20 +67,39 @@ print_ld_st_opcode(midgard_load_store_op op)
static bool is_embedded_constant_half = false;
static bool is_embedded_constant_int = false;
+static char
+prefix_for_bits(unsigned bits)
+{
+switch (bits) {
+case 8:
+return 'q';
+case 16:
+return 'h';
+default:
+return 0;
+}
+}
+
static void
-print_reg(unsigned reg, bool half)
+print_reg(unsigned reg, unsigned bits)
{
/* Perform basic static analysis for expanding constants correctly */
-if (half && (reg >> 1) == 26) {
+if ((bits == 16) && (reg >> 1) == 26) {
is_embedded_constant_half = true;
is_embedded_constant_int = is_instruction_int;
-} else if (!half && reg == 26) {
+} else if ((bits == 32) && reg == 26) {
is_embedded_constant_int = is_instruction_int;
+} else if (bits == 8) {
+/* TODO */
+} else if (bits == 64) {
+/* TODO */
}
-if (half)
-printf("h");
+char prefix = prefix_for_bits(bits);
+
+if (prefix)
+putchar(prefix);
printf("r%u", reg);
}
@@ -169,18 +188,18 @@ print_vector_src(unsigned src_binary, bool out_high,
printf(" /* rep_low */ ");
}
-print_reg(half_reg, true);
+print_reg(half_reg, 16);
} else {
if (src->rep_high)
printf(" /* rep_high */ ");
if (src->half)
-print_reg(reg * 2 + src->rep_low, true);
+print_reg(reg * 2 + src->rep_low, 16);
else {
if (src->rep_low)
printf(" /* rep_low */ ");
-print_reg(reg, false);
+print_reg(reg, 32);
}
}
@@ -295,11 +314,11 @@ print_vector_field(const char *name, uint16_t *words,
uint16_t reg_word,
if (out_half) {
if (out_high)
-print_reg(2 * reg_info->out_reg + 1, true);
+print_reg(2 * reg_info->out_reg + 1, 16);
else
-print_reg(2 * reg_info->out_reg, true);
+print_reg(2 * reg_info->out_reg, 16);
} else
-print_reg(reg_info->out_reg, false);
+print_reg(reg_info->out_reg, 32);
if (mask != 0xF) {
unsigned i;
@@ -342,9 +361,9 @@ print_scalar_src(unsigned src_binary, unsigned reg)
printf("abs(");
if (src->full)
-print_reg(reg, false);
+print_reg(reg, 32);
else
-print_reg(reg * 2 + (src->component >> 2), true);
+print_reg(reg * 2 + (src->component >> 2), 16);
static const char c[4] = "xyzw";
\
@@ -383,10 +402,10 @@ print_scalar_field(const char *name, uint16_t *words,
uint16_t reg_word,
printf(" ");
if (alu_field->output_full)
-print_reg(reg_info->out_reg, false);
+print_reg(reg_info->out_reg, 32);
else
print_reg(reg_info->out_reg * 2 + (alu_field->output_component
>> 2),
- true);
+ 16);
static const char c[4] = "xyzw";
printf(".%c, ",
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/10] 8-bit arithemtic
This change set implements support for disassembly 8-bit arithmetic in Midgard, as exposed via the (u)char OpenCL types. This is far from complete, but it does a decent job for some more basic 8-bit-using shaders. This is a prerequisite to a decent implementation of programmatic blending, since the blend pipeline is required to pack the pixel format itself. For RGBA8, this means some 8-bit arithmetic in the blend shader. Alyssa Rosenzweig (10): panfrost/midgard: reg_mode_full -> reg_mode_32, etc panfrost/midgard/disasm: Catch mask errors panfrost/midgard/disasm: Extend print_reg to 8-bit panfrost/midgard/disasm: Fill in .int mod panfrost/midgard: Fix crash on unknown op panfrost/midgard: Rename ilzcnt8 -> iclz panfrost/midgard/disasm: Support 8-bit destination panfrost/midgard/disasm: Print 8-bit sources panfrost/midgard/disasm: Stub out 64-bit panfrost/midgard/disasm: Handle dest_override generalized .../drivers/panfrost/midgard/disassemble.c| 215 +- .../drivers/panfrost/midgard/helpers.h| 10 +- .../drivers/panfrost/midgard/midgard.h| 10 +- .../panfrost/midgard/midgard_compile.c| 18 +- 4 files changed, 183 insertions(+), 70 deletions(-) -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] Blend shader preparation
Midgard has only limited fixed-function blending support. For more complex use cases, including many within ES2, a programmatic "blend shader" is used instead, autogenerated by the driver and used as a dedicated post-fragment shader stage. This patch set does some preliminary work towards enabling blend shaders on Panfrost (again). Alyssa Rosenzweig (3): panfrost: Remove shader dump panfrost/decode: Hit MRT blend shader enable bits panfrost: Fix blend shader upload .../drivers/panfrost/include/panfrost-job.h| 6 -- .../drivers/panfrost/pan_blend_shaders.c | 7 +-- src/gallium/drivers/panfrost/pan_context.c | 18 +- src/gallium/drivers/panfrost/pan_screen.c | 1 - src/gallium/drivers/panfrost/pan_util.h| 1 - src/gallium/drivers/panfrost/pan_wallpaper.c | 3 --- .../drivers/panfrost/pandecode/decode.c| 15 ++- 7 files changed, 32 insertions(+), 19 deletions(-) -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] panfrost/midgard: Rename ilzcnt8 -> iclz
Per OpenCL.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 2 +-
src/gallium/drivers/panfrost/midgard/midgard.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src/gallium/drivers/panfrost/midgard/helpers.h
index d2855cd89cd..2be192a363b 100644
--- a/src/gallium/drivers/panfrost/midgard/helpers.h
+++ b/src/gallium/drivers/panfrost/midgard/helpers.h
@@ -224,7 +224,7 @@ static struct {
[midgard_alu_op_inor] = {"inor", UNITS_MOST | OP_COMMUTES},
[midgard_alu_op_ixor] = {"ixor", UNITS_MOST | OP_COMMUTES},
[midgard_alu_op_inxor] = {"inxor", UNITS_MOST | OP_COMMUTES},
-[midgard_alu_op_ilzcnt] = {"ilzcnt", UNITS_ADD},
+[midgard_alu_op_iclz] = {"iclz", UNITS_ADD},
[midgard_alu_op_ibitcount8] = {"ibitcount8", UNITS_ADD},
[midgard_alu_op_inand] = {"inand", UNITS_MOST},
[midgard_alu_op_ishl] = {"ishl", UNITS_ADD},
diff --git a/src/gallium/drivers/panfrost/midgard/midgard.h
b/src/gallium/drivers/panfrost/midgard/midgard.h
index e86f517442d..c2808937b43 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard.h
+++ b/src/gallium/drivers/panfrost/midgard/midgard.h
@@ -94,7 +94,7 @@ typedef enum {
midgard_alu_op_iornot = 0x75, /* (a | ~b) */
midgard_alu_op_ixor = 0x76,
midgard_alu_op_inxor = 0x77, /* ~(a & b) */
-midgard_alu_op_ilzcnt = 0x78, /* Number of zeroes on left. 31 -
ilzcnt(x) = findMSB(x) */
+midgard_alu_op_iclz = 0x78, /* Number of zeroes on left */
midgard_alu_op_ibitcount8 = 0x7A, /* Counts bits in 8-bit increments */
midgard_alu_op_imov = 0x7B,
midgard_alu_op_iabs = 0x7C,
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/10] panfrost/midgard/disasm: Print 8-bit sources
This handles the usual case. 8-bit register access parallels 16-bit
access, but with one major caveat: in 8-bit mode, only half of the
register file is actually (directly) accessible as sources. In
particular, for each 16-bit integer register (hrN), we can only index a
*single* 8-bit integer (qrN), corresponding to the lower 8-bits. To get
the upper 8-bits, it is required to do an explicit shift. For example,
to add the bytes of a 16-bit integer hr0.x and get the result as an
8-bit qr0, you'd need to do something like:
ilsr hr1.x, hr0.x, #8
iadd qr0.x, qr0.x, qr1.x
This scheme diverges from 32-bit registers, in that both the upper and
lower halves of a 32-bit register are individually accessible as a pair
of half registers. For contrast, to add the lower and upper 16-bits of a
32-bit integer r0.x, you can just:
iadd hr0.x, hr0.x, hr1.x
Since hr1.x = upper 16-bit of r0.x.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 66 ---
1 file changed, 43 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 71f5c489528..9469cac6e75 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -130,7 +130,7 @@ print_quad_word(uint32_t *words, unsigned tabs)
static void
print_vector_src(unsigned src_binary, bool out_high,
- bool out_half, unsigned reg,
+ midgard_reg_mode mode, unsigned reg,
bool is_int)
{
midgard_vector_alu_src *src = (midgard_vector_alu_src *)_binary;
@@ -164,32 +164,49 @@ print_vector_src(unsigned src_binary, bool out_high,
//register
-if (out_half) {
+if (mode == midgard_reg_mode_8) {
if (src->half)
printf(" /* half */ ");
-unsigned half_reg;
+unsigned quarter_reg = reg * 2;
if (out_high) {
+if (!src->rep_low)
+quarter_reg++;
+
+if (src->rep_high)
+printf(" /* rep_high */ ");
+} else {
+if (src->rep_high)
+quarter_reg++;
+
if (src->rep_low)
-half_reg = reg * 2;
-else
-half_reg = reg * 2 + 1;
+printf(" /* rep_low */ ");
+}
+
+print_reg(quarter_reg, 8);
+} else if (mode == midgard_reg_mode_16) {
+if (src->half)
+printf(" /* half */ ");
+
+unsigned half_reg = reg * 2;
+
+if (out_high) {
+if (!src->rep_low)
+half_reg++;
if (src->rep_high)
printf(" /* rep_high */ ");
} else {
if (src->rep_high)
-half_reg = reg * 2 + 1;
-else
-half_reg = reg * 2;
+half_reg++;
if (src->rep_low)
printf(" /* rep_low */ ");
}
print_reg(half_reg, 16);
-} else {
+} else if (mode == midgard_reg_mode_32) {
if (src->rep_high)
printf(" /* rep_high */ ");
@@ -201,6 +218,8 @@ print_vector_src(unsigned src_binary, bool out_high,
print_reg(reg, 32);
}
+} else if (mode == midgard_reg_mode_64) {
+/* TODO */
}
//swizzle
@@ -247,9 +266,9 @@ print_vector_field(const char *name, uint16_t *words,
uint16_t reg_word,
{
midgard_reg_info *reg_info = (midgard_reg_info *)_word;
midgard_vector_alu *alu_field = (midgard_vector_alu *) words;
+midgard_reg_mode mode = alu_field->reg_mode;
-if (alu_field->reg_mode != midgard_reg_mode_16 &&
-alu_field->reg_mode != midgard_reg_mode_32) {
+if (mode == midgard_reg_mode_64) {
printf("unknown reg mode %u\n", alu_field->reg_mode);
}
@@ -261,12 +280,15 @@ print_vector_field(const char *name, uint16_t *words,
uint16_t reg_word,
print_outmod(alu_field->outmod);
printf(" ");
-bool half, out_half, out_high = false;
+bool out_high = false;
unsigned mask;
-half = (alu_field->reg_mode == midgard_reg_mode_16);
+if (mode == midgard_reg_mode_16
+|| mode == midgard_reg_mode_8) {
+
+/* For partial views, the mask denotes which adjacent register
+ * is used as
Re: [Mesa-dev] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware
On Tue, Apr 30, 2019 at 10:42 AM Ilia Mirkin wrote: > > On Tue, Apr 30, 2019 at 2:48 AM Dave Airlie wrote: > > > > On Tue, 30 Apr 2019 at 08:47, Dave Airlie wrote: > > > > > > On Tue, 30 Apr 2019 at 08:42, Ilia Mirkin wrote: > > > > > > > > Thing is, I think that would not be enough - with the "recent" (like > > > > past 2 years) CSO/state change detection changes, I think that you can > > > > end up with no sampler set for a buffer view. Perhaps someone with the > > > > hw can investigate what goes wrong? > > > > > > I'm trying to get a live r600/700 machine, I plugged in my rv635 and > > > rv740 gpus, and they both seemed toast, I've got an rv635 laptop I'll > > > try and get up to date. > > > > I've found a working rv770 and reproduced it here. This isn't an > > indication I'll get to fix it soon, but I will try. > > When I was debugging this issue on nouveau (and trying to nail down > specifically what didn't work and what was required to make it work), > I found that using a gallium test to debug this made the issues at > hand quite obvious, and I didn't have to worry about how to force the > st to assign mappings here or there for views or samplers. I'm not > sure if I still have those left over, but I'll have a look tonight. > They're also not terribly difficult to write. In case it's helpful: https://people.freedesktop.org/~imirkin/tbo-tex.c which fits together with the other gallium/tests/trivial ones. I think there were associated Makefile.am changes, but with the removal of autoconf, I probably lost the local changes. In its current form, it doesn't create a sampler, but you can see how trivial/quad-tex.c does it if you want to play around with having samplers around. You might also have to use PIPE_FORMAT_R8G8B8A8_UNORM instead of the BGRA variant for the view's format (iirc r600 has some limitations around swizzling and buffer textures). -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: fix alphaToCoverage when there is no color attachment
On Tue, Apr 30, 2019 at 4:36 AM Iago Toral wrote:
> Hi Jason,
>
> it seems that this was never addressed so I'll try to take it from here. A
> couple of comments regarding your feedback:
>
> We always setup a null render target if we don't have any, so I think that
> part of the patch is not necessary. I checked that simply making sure that
> we don't remove the output when we are in this situation is enough to make
> the tests pass.
>
> However, you make another suggestion below about only writing the Alpha
> channel in that case. I understand that you meant this as an optimization
> for this particular scenario since it is not really a functional
> requirement for this to work, since we are using a null render target in
> this case. Anyway, I have been looking into it and I believe that
> implementing this would be slightly trickier since we'd also need to make
> sure that we compile a different version of the shader when it is used with
> a valid color attachment (since in that case we do need to emit the RGB
> writes). Therefore, it would require that we include a bit for this
> sceneario in brw_wm_prog_key. We could do that very easily at the same
> moment we make the decision that we need a null render target
> in anv_pipeline_link_fs() (where we are already editing nr_color_regions
> and color_outputs_valid in the key). If we do it like this, then we can
> implement the optimization trivially when we handle implement
> nir_intrinsic_store_output in brw_fs_nir.cpp by simply skipping the MOVs
> for the RGB components when this key flag is set. Does this sound good to
> you?
>
Yeah, it may not be worth it. It was just a thought. Let's focus on
plugging the current hole. The optimization can come later.
I'm not sure that we would actually need a bit. This would be an implicit
combination of the color_outputs_valid and dual-src blending which is
already part of the shader. That might need a big fat comment though. :)
--Jason
>
> Iago
>
> On Fri, 2019-03-22 at 10:06 -0500, Jason Ekstrand wrote:
>
> I'm confused. Don't we always have a NULL render target at location 0?
> Is the problem really that we need the NULL render target or is it that we
> can't throw away the alpha component of the RT write in the shader? If
> it's that we can't throw away the alpha component of the RT write, then I'd
> suggest a slightly different workaround which does just that. We can
> rewrite the store_output intrinsic (or store_var; not sure which it is at
> that point) so that it writes vec4(undef, undef, undef, alpha) to help with
> linking but then keep the one output var so it we still get the write in
> the shader.
>
>
> On Mon, Mar 4, 2019 at 4:56 AM Samuel Iglesias Gonsálvez <
> sigles...@igalia.com> wrote:
>
> Still unreviewed.
>
> Sam
>
> On Thu, 2019-02-21 at 12:08 +0100, Samuel Iglesias Gonsálvez wrote:
> > CL#3532 added a test for alpha to coverage without a color
> > attachment.
> > First the test draws a primitive with alpha 0 and a subpass with only
> > a depth buffer. No writes to a depth buffer are expected. Then a
> > second draw with a color buffer and the same depth buffer is done to
> > verify the depth buffer still has the original clear values.
> >
> > This behavior is not explicitly forbidden by the Vulkan spec, so
> > it seems it is allowed.
> >
> > When there is no color attachment for a given output, we discard it
> > so at the end we have an FS assembly like:
> >
> > Native code for unnamed fragment shader (null)
> > SIMD16 shader: 1 instructions. 0 loops. 4 cycles. 0:0 spills:fills.
> > Promoted 0 constants. Compacted 16 to 16 bytes (0%)
> >START B0 (4 cycles)
> > sendc(16) null<1>UW g120<0,1,0>F0x90031000
> >
> > render MsgDesc: RT write SIMD16 LastRT Surface = 0 mlen 8 rlen 0 {
> > align1 1H EOT };
> >
> > As g120 is not initialized, we see random writes to the depth buffer
> > due to the alphaToCoverage enablement. This commit fixes that by
> > keeping the output and creating a null render target for it.
> >
> > Fixes tests:
> >
> > dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
> >
> > Signed-off-by: Samuel Iglesias Gonsálvez
> > ---
> > src/intel/vulkan/anv_pipeline.c | 35 +
> >
> > 1 file changed, 27 insertions(+), 8 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_pipeline.c
> > b/src/intel/vulkan/anv_pipeline.c
> > index e2024212bd9..70a958bf3a8 100644
> > --- a/src/intel/vulkan/anv_pipeline.c
> > +++ b/src/intel/vulkan/anv_pipeline.c
> > @@ -792,7 +792,9 @@ anv_pipeline_compile_gs(const struct brw_compiler
> > *compiler,
> >
> > static void
> > anv_pipeline_link_fs(const struct brw_compiler *compiler,
> > - struct anv_pipeline_stage *stage)
> > + struct anv_pipeline_stage *stage,
> > + const struct anv_subpass *subpass,
> > + const VkPipelineMultisampleStateCreateInfo
> > *ms_info)
> > {
> > unsigned
Re: [Mesa-dev] [PATCH 0/3] radeonsi: handle unaligned vertex buffers in hardware
Why can we not use tbuffer loads? Marek On Thu, Apr 25, 2019 at 7:18 AM Nicolai Hähnle wrote: > Hi all, > > the following patches contain code to implement all vertex fetches > using plain, non-format loads plus explicit shader arithmetic for > format conversion. > > This allows us to remove the software workaround for unaligned vertex > buffers on SI, because we can just load individual bytes on the GPU. > CI+ will still use short/dword loads even in the unaligned case. > > The format conversion code was tested by running with > radeonsi_vs_fetch_always_opencode=true on both Verde and Vega. > > Please review! > > Thanks, > Nicolai > -- > src/amd/common/ac_llvm_build.c | 313 + > src/amd/common/ac_llvm_build.h | 30 ++ > .../drivers/radeonsi/si_debug_options.h | 1 + > src/gallium/drivers/radeonsi/si_get.c| 2 +- > src/gallium/drivers/radeonsi/si_pipe.h | 1 + > src/gallium/drivers/radeonsi/si_shader.c | 249 + > src/gallium/drivers/radeonsi/si_shader.h | 46 +-- > src/gallium/drivers/radeonsi/si_state.c | 233 +++- > src/gallium/drivers/radeonsi/si_state.h | 19 + > .../drivers/radeonsi/si_state_shaders.c | 37 +- > 10 files changed, 645 insertions(+), 286 deletions(-) > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radeonsi/nir: call radeonsi nir opts before the scan pass
Rb for the series. (I can't type my surname on the phone) Marek On Thu, Apr 25, 2019, 3:03 AM Timothy Arceri wrote: > Some of the opts are not called in the general optimastion loop > in the state trackers glsl -> nir conversion. We need to call > the radeonsi specific optimisation once before scanning over > the nir otherwise we can end up gathering info on code that > is later removed. > > Fixes an assert in the piglit test: > > ./bin/varying-struct-centroid_gles3 > --- > src/gallium/drivers/radeonsi/si_compute.c | 1 + > src/gallium/drivers/radeonsi/si_state_shaders.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/src/gallium/drivers/radeonsi/si_compute.c > b/src/gallium/drivers/radeonsi/si_compute.c > index 541d7e6f118..f1a433b72df 100644 > --- a/src/gallium/drivers/radeonsi/si_compute.c > +++ b/src/gallium/drivers/radeonsi/si_compute.c > @@ -106,6 +106,7 @@ static void si_create_compute_state_async(void *job, > int thread_index) > assert(program->ir_type == PIPE_SHADER_IR_NIR); > sel.nir = program->ir.nir; > > + si_nir_opts(sel.nir); > si_nir_scan_shader(sel.nir, ); > si_lower_nir(); > } > diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c > b/src/gallium/drivers/radeonsi/si_state_shaders.c > index 5bdfd4f6ac1..7250b40c5db 100644 > --- a/src/gallium/drivers/radeonsi/si_state_shaders.c > +++ b/src/gallium/drivers/radeonsi/si_state_shaders.c > @@ -2240,6 +2240,7 @@ static void *si_create_shader_selector(struct > pipe_context *ctx, > > sel->nir = state->ir.nir; > > + si_nir_opts(sel->nir); > si_nir_scan_shader(sel->nir, >info); > si_nir_scan_tess_ctrl(sel->nir, >tcs_info); > } > -- > 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
Re: [Mesa-dev] [PATCH] gallium: Query uvd handles info
It would be better to add a pipe cap for this. I don't think you need
uint64_t here.
Marek
On Tue, Apr 30, 2019, 6:45 AM Sahu, Satyajit wrote:
> Query the uvd handles info. If the used uvd handles are equals to
> max possible handles then return error.
>
> Signed-off-by: Satyajit Sahu
> ---
> src/gallium/drivers/radeon/radeon_winsys.h| 1 +
> src/gallium/drivers/radeonsi/si_get.c | 8
> src/gallium/include/pipe/p_screen.h | 1 +
> src/gallium/state_trackers/va/context.c | 2 ++
> src/gallium/state_trackers/va/picture.c | 11 ++-
> src/gallium/state_trackers/va/va_private.h| 1 +
> src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 11 +++
> 7 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_winsys.h
> b/src/gallium/drivers/radeon/radeon_winsys.h
> index 0c71b59ae04..b4f3a3ad09f 100644
> --- a/src/gallium/drivers/radeon/radeon_winsys.h
> +++ b/src/gallium/drivers/radeon/radeon_winsys.h
> @@ -125,6 +125,7 @@ enum radeon_value_id {
> RADEON_CURRENT_MCLK,
> RADEON_GPU_RESET_COUNTER, /* DRM 2.43.0 */
> RADEON_CS_THREAD_TIME,
> +RADEON_UVD_HANDLES,
> };
>
> enum radeon_bo_priority {
> diff --git a/src/gallium/drivers/radeonsi/si_get.c
> b/src/gallium/drivers/radeonsi/si_get.c
> index 4e23d283ab7..6e27b0162e0 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -887,6 +887,13 @@ static uint64_t si_get_timestamp(struct pipe_screen
> *screen)
> sscreen->info.clock_crystal_freq;
> }
>
> +//ADD function for querying uvd handles info
> +static uint64_t si_get_handles_info(struct pipe_screen *screen)
> +{
> + struct si_screen *sscreen = (struct si_screen*)screen;
> +
> + return sscreen->ws->query_value(sscreen->ws, RADEON_UVD_HANDLES);
> +}
> static void si_query_memory_info(struct pipe_screen *screen,
> struct pipe_memory_info *info)
> {
> @@ -975,6 +982,7 @@ void si_init_screen_get_functions(struct si_screen
> *sscreen)
> sscreen->b.get_device_uuid = si_get_device_uuid;
> sscreen->b.get_driver_uuid = si_get_driver_uuid;
> sscreen->b.query_memory_info = si_query_memory_info;
> + sscreen->b.query_handles_info = si_get_handles_info;
> sscreen->b.get_disk_shader_cache = si_get_disk_shader_cache;
>
> if (sscreen->info.has_hw_decode) {
> diff --git a/src/gallium/include/pipe/p_screen.h
> b/src/gallium/include/pipe/p_screen.h
> index d4e2d9f63ac..c41af7b842f 100644
> --- a/src/gallium/include/pipe/p_screen.h
> +++ b/src/gallium/include/pipe/p_screen.h
> @@ -148,6 +148,7 @@ struct pipe_screen {
> * wait for rendering to complete (which cannot be achieved with
> queries).
> */
> uint64_t (*get_timestamp)(struct pipe_screen *);
> + uint64_t (*query_handles_info)(struct pipe_screen *);
>
> /**
> * Create a context.
> diff --git a/src/gallium/state_trackers/va/context.c
> b/src/gallium/state_trackers/va/context.c
> index 9176b7e8c5d..01dc618291f 100644
> --- a/src/gallium/state_trackers/va/context.c
> +++ b/src/gallium/state_trackers/va/context.c
> @@ -237,8 +237,10 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID
> config_id, int picture_width,
> if (!context)
>return VA_STATUS_ERROR_ALLOCATION_FAILED;
>
> + context->is_vpp =false;
> if (is_vpp) {
>context->decoder = NULL;
> + context->is_vpp =true;
> } else {
>context->templat.profile = config->profile;
>context->templat.entrypoint = config->entrypoint;
> diff --git a/src/gallium/state_trackers/va/picture.c
> b/src/gallium/state_trackers/va/picture.c
> index 04d2da0afeb..43ed53f8e82 100644
> --- a/src/gallium/state_trackers/va/picture.c
> +++ b/src/gallium/state_trackers/va/picture.c
> @@ -42,6 +42,8 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID
> context_id, VASurfaceID rende
> vlVaDriver *drv;
> vlVaContext *context;
> vlVaSurface *surf;
> + struct pipe_screen *pscreen;
> + int available_uvd_handles;
>
> if (!ctx)
>return VA_STATUS_ERROR_INVALID_CONTEXT;
> @@ -50,6 +52,8 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID
> context_id, VASurfaceID rende
> if (!drv)
>return VA_STATUS_ERROR_INVALID_CONTEXT;
>
> + pscreen = VL_VA_PSCREEN(ctx);
> +
> mtx_lock(>mutex);
> context = handle_table_get(drv->htab, context_id);
> if (!context) {
> @@ -73,7 +77,12 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID
> context_id, VASurfaceID rende
> context->mjpeg.sampling_factor = 0;
>
> if (!context->decoder) {
> -
> + if (!context->is_vpp) {
> + //Query available uvd handles. If uvd handles not available
> fallback to software.
> + available_uvd_handles = pscreen->query_handles_info(pscreen);
> + if (available_uvd_handles <= 0)
> +return VA_STATUS_ERROR_ALLOCATION_FAILED;
> + }
>
Re: [Mesa-dev] [PATCH 2/3] mesa: fix pbuffers because internally they are front buffers
I have never understood why Mesa has gl_context::Visual and gl_framebuffer::Visual. The Mesa code also allows a non-matching doublebuffer setting between the two. libEGL also always uses a singlebuffered config for pixmaps and pbuffers even if the context config is doublebuffered. Marek On Tue, Apr 30, 2019, 1:25 PM Adam Jackson wrote: > On Mon, 2019-04-29 at 20:35 -0400, Marek Olšák wrote: > > > Yeah that's possible. The thing is that a GL context can have a > > doublebuffered config and begin with GL_BACK as the draw buffer, but > > MakeCurrent can set a pbuffer with a singlebuffered config and then > > nothing is rendered with Mesa because there is no back buffer. This > > case appears to work on NVIDIA. > > Okay, that makes sense. Thanks for the explanation. > > I think this is only true because of EGL_KHR_no_config_context? If the > context has a config, then you shouldn't be able to make a single- > buffered pbuffer current to a double-buffered context. EGL section > 2.2's definition of compatibility includes having "color and ancillary > buffers of the same depth"; if you don't have a back buffer, then you > have zero bits of back buffer, and you would not be compatible with > non-zero bits of back buffer. I would think, anyway. > > Now if you bind a single-buffered pbuffer to a no-config context, > obviously rendering should go to GL_FRONT. > > - ajax > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110439] [TRACKER] Mesa 19.1 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=110439 Juan A. Suarez changed: What|Removed |Added Depends on|110501 | Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110501 [Bug 110501] Land VK_KHR_shader_float_controls -- 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 2/3] mesa: fix pbuffers because internally they are front buffers
On Mon, 2019-04-29 at 20:35 -0400, Marek Olšák wrote: > Yeah that's possible. The thing is that a GL context can have a > doublebuffered config and begin with GL_BACK as the draw buffer, but > MakeCurrent can set a pbuffer with a singlebuffered config and then > nothing is rendered with Mesa because there is no back buffer. This > case appears to work on NVIDIA. Okay, that makes sense. Thanks for the explanation. I think this is only true because of EGL_KHR_no_config_context? If the context has a config, then you shouldn't be able to make a single- buffered pbuffer current to a double-buffered context. EGL section 2.2's definition of compatibility includes having "color and ancillary buffers of the same depth"; if you don't have a back buffer, then you have zero bits of back buffer, and you would not be compatible with non-zero bits of back buffer. I would think, anyway. Now if you bind a single-buffered pbuffer to a no-config context, obviously rendering should go to GL_FRONT. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110565] scons-3 breaks libgl-xlib build
https://bugs.freedesktop.org/show_bug.cgi?id=110565 --- Comment #3 from Brian Paul --- OK, the problem on my end was just a few missing package dependencies for X. I also installed SCons 3.0.4 and that seemed to work too. I have python3 version 3.7.3. I wonder if that's the difference. Can you try upgrading your python? -- 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 110552] Land Gallium nine fixes for 19.1
https://bugs.freedesktop.org/show_bug.cgi?id=110552 Axel Davy changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Axel Davy --- Pushed. -- 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 110439] [TRACKER] Mesa 19.1 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=110439 Bug 110439 depends on bug 110552, which changed state. Bug 110552 Summary: Land Gallium nine fixes for 19.1 https://bugs.freedesktop.org/show_bug.cgi?id=110552 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv/query: ensure visibility of reset before copying query results
Let me check the new tests and see if where the problem is.
Thanks for letting us know!
-Lionel
On 30/04/2019 13:43, Iago Toral Quiroga wrote:
Specifically, vkCmdCopyQueryPoolResults is required to see the effect
of a previous vkCmdResetQueryPool. This may not work currently when
query execution is still on going, as some of the queries may become
available asynchronously after the reset.
Fixes new CTS tests:
dEQP-VK.query_pool.statistics_query.reset_before_copy.*
---
Jason, do you have any better ideas?
src/intel/vulkan/genX_query.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/intel/vulkan/genX_query.c b/src/intel/vulkan/genX_query.c
index 146435c3f8f..08b013f6351 100644
--- a/src/intel/vulkan/genX_query.c
+++ b/src/intel/vulkan/genX_query.c
@@ -383,6 +383,19 @@ void genX(CmdResetQueryPool)(
ANV_FROM_HANDLE(anv_cmd_buffer, cmd_buffer, commandBuffer);
ANV_FROM_HANDLE(anv_query_pool, pool, queryPool);
+ /* From the Vulkan spec:
+*
+*"vkCmdCopyQueryPoolResults is guaranteed to see the effect of
+* previous uses of vkCmdResetQueryPool in the same queue, without
+* any additional synchronization. Thus, the results will always
+* reflect the most recent use of the query."
+*
+* So we need to make sure that any on-going queries are finished by
+* the time we emit the reset.
+*/
+ cmd_buffer->state.pending_pipe_bits |= ANV_PIPE_CS_STALL_BIT;
+ genX(cmd_buffer_apply_pipe_flushes)(cmd_buffer);
+
for (uint32_t i = 0; i < queryCount; i++) {
anv_batch_emit(_buffer->batch, GENX(MI_STORE_DATA_IMM), sdm) {
sdm.Address = anv_query_address(pool, firstQuery + i);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110552] Land Gallium nine fixes for 19.1
https://bugs.freedesktop.org/show_bug.cgi?id=110552 --- Comment #2 from Axel Davy --- I think we can merge it asap. The question on the GPU vendor name hasn't been resolved. I can remove that patch of the serie and push in half an hour from now. -- 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 110552] Land Gallium nine fixes for 19.1
https://bugs.freedesktop.org/show_bug.cgi?id=110552 --- Comment #1 from Juan A. Suarez --- This is blocking 19.1 release. Any chance to merge it asap? -- 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 110565] scons-3 breaks libgl-xlib build
https://bugs.freedesktop.org/show_bug.cgi?id=110565 --- Comment #2 from Volker Wegert --- If you need any more info to help diagnose/reproduce the issue, please let me know. # python --version Python 3.6.5 -- 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/3] mesa: fix pbuffers because internally they are front buffers
On Tue, Apr 30, 2019 at 5:59 AM Mathias Fröhlich wrote: > > Adam, Marek, > > On Monday, 29 April 2019 18:28:21 CEST Adam Jackson wrote: > > On Fri, 2019-04-26 at 23:31 -0400, Marek Olšák wrote: > > > > I don't claim to know what this series is trying to fix, but: > > > > > +* 2) Pbuffers are back buffers from the application point of view, > > > +*but they are front buffers from the Mesa point of view, > > > +*because they are always single buffered. > > > +*/ > > > > The EGL spec (back to 1.0!) says: > > > > "The resulting pbuffer will contain color buffers and ancillary buffers > > as specified by config." > > > > This appears to be copied from GLX, which has something more elaborate: > > > > "The resulting pbuffer will contain color buffers and ancillary buffers > > as specified by config. It is possible to create a pbuffer with back > > buffers and to swap the front and back buffers by calling > > glXSwapBuffers. Note that pbuffers use framebuffer resources so > > applications should consider deallocating them when they are not in > > use." > > > > So I'm not convinced that pbuffers are "always single-buffered". The > > back buffer is definitely a color buffer, and at least under GLX it > > seems like it should be possible to draw red to back, swap, draw blue > > to back, glReadBuffer(GL_FRONT), and expect glReadPixels to return red. > > Hmm, probably Marek's escape could be 2.2.2 Rendering Models form the > eglspec: > [...] > Pbuffer surfaces have a back buffer but no associated > window, so the back buffer need not be copied. > [...] > > Not sure myself what that means in its total consequence, but can't we > read that as > there is only undefined behavior associated with the pbuffer front buffer? > > Why, do I get to that? > IIRC somewhere in EGL there is a note that there is basically no front > buffer rendering > in EGL. And the above tells that the implementation may behave as if there > is no way > to swap the back buffers content into the front buffer. > > Is there some path left using egl images or egl copy buffers? > Or what else do I miss? > Well, EGL pbuffers have been broken in Mesa for a decade or so. We are finally getting to the point of making them work. Mesa makes EGL pbuffers always single-buffered just like EGL pixmaps. I like that because we don't waste memory for a front buffer that we might not need. We also don't support front buffer rendering with egl/x11, which makes the rabbit hole a lot deeper. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110439] [TRACKER] Mesa 19.1 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=110439 Bug 110439 depends on bug 110562, which changed state. Bug 110562 Summary: Land VK_EXT_memory_budget https://bugs.freedesktop.org/show_bug.cgi?id=110562 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] radv: implement a workaround for VK_EXT_conditional_rendering
Per the Vulkan spec 1.1.107, the predicate is a 32-bit value. Though
the AMD hardware treats it as a 64-bit value which means it might
fail to discard.
I don't know why this extension has been drafted like that but this
definitely not fit with AMD. The hardware doesn't seem to support
a 32-bit value for the predicate, so we need to implement a workaround.
This fixes an issue when DXVK enables conditional rendering with RADV,
this also fixes the Sasha conditionalrender demo.
v2: - wait for confirmation to avoid random failures on Polaris10
- update commit description
Fixes: e45ba51ea45 ("radv: add support for VK_EXT_conditional_rendering")
Reported-by: Philip Rebohle
Signed-off-by: Samuel Pitoiset
Reviewed-by: Bas Nieuwenhuizen (v1)
---
src/amd/vulkan/radv_cmd_buffer.c | 47 ++--
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 2fa55e6ab00..963118215fa 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4933,8 +4933,11 @@ void radv_CmdBeginConditionalRenderingEXT(
{
RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
RADV_FROM_HANDLE(radv_buffer, buffer,
pConditionalRenderingBegin->buffer);
+ struct radeon_cmdbuf *cs = cmd_buffer->cs;
bool draw_visible = true;
- uint64_t va;
+ uint64_t pred_value = 0;
+ uint64_t va, new_va;
+ unsigned pred_offset;
va = radv_buffer_get_va(buffer->bo) +
pConditionalRenderingBegin->offset;
@@ -4950,13 +4953,51 @@ void radv_CmdBeginConditionalRenderingEXT(
si_emit_cache_flush(cmd_buffer);
+ /* From the Vulkan spec 1.1.107:
+*
+* "If the 32-bit value at offset in buffer memory is zero, then the
+* rendering commands are discarded, otherwise they are executed as
+* normal. If the value of the predicate in buffer memory changes while
+* conditional rendering is active, the rendering commands may be
+* discarded in an implementation-dependent way. Some implementations
+* may latch the value of the predicate upon beginning conditional
+* rendering while others may read it before every rendering command."
+*
+* But, the AMD hardware treats the predicate as a 64-bit value which
+* means we need a workaround in the driver. Luckily, it's not required
+* to support if the value changes when predication is active.
+*
+* The workaround is as follows:
+* 1) allocate a 64-value in the upload BO and initialize it to 0
+* 2) copy the 32-bit predicate value to the upload BO
+* 3) use the new allocated VA address for predication
+*
+* Based on the conditionalrender demo, it's faster to do the COPY_DATA
+* in ME (+ sync PFP) instead of PFP.
+*/
+ radv_cmd_buffer_upload_data(cmd_buffer, 8, 16, _value,
_offset);
+
+ new_va = radv_buffer_get_va(cmd_buffer->upload.upload_bo) + pred_offset;
+
+ radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
+ radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_SRC_MEM) |
+ COPY_DATA_DST_SEL(COPY_DATA_DST_MEM) |
+ COPY_DATA_WR_CONFIRM);
+ radeon_emit(cs, va);
+ radeon_emit(cs, va >> 32);
+ radeon_emit(cs, new_va);
+ radeon_emit(cs, new_va >> 32);
+
+ radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
+ radeon_emit(cs, 0);
+
/* Enable predication for this command buffer. */
- si_emit_set_predication_state(cmd_buffer, draw_visible, va);
+ si_emit_set_predication_state(cmd_buffer, draw_visible, new_va);
cmd_buffer->state.predicating = true;
/* Store conditional rendering user info. */
cmd_buffer->state.predication_type = draw_visible;
- cmd_buffer->state.predication_va = va;
+ cmd_buffer->state.predication_va = new_va;
}
void radv_CmdEndConditionalRenderingEXT(
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware
On Tue, Apr 30, 2019 at 2:48 AM Dave Airlie wrote: > > On Tue, 30 Apr 2019 at 08:47, Dave Airlie wrote: > > > > On Tue, 30 Apr 2019 at 08:42, Ilia Mirkin wrote: > > > > > > Thing is, I think that would not be enough - with the "recent" (like > > > past 2 years) CSO/state change detection changes, I think that you can > > > end up with no sampler set for a buffer view. Perhaps someone with the > > > hw can investigate what goes wrong? > > > > I'm trying to get a live r600/700 machine, I plugged in my rv635 and > > rv740 gpus, and they both seemed toast, I've got an rv635 laptop I'll > > try and get up to date. > > I've found a working rv770 and reproduced it here. This isn't an > indication I'll get to fix it soon, but I will try. When I was debugging this issue on nouveau (and trying to nail down specifically what didn't work and what was required to make it work), I found that using a gallium test to debug this made the issues at hand quite obvious, and I didn't have to worry about how to force the st to assign mappings here or there for views or samplers. I'm not sure if I still have those left over, but I'll have a look tonight. They're also not terribly difficult to write. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110565] scons-3 breaks libgl-xlib build
https://bugs.freedesktop.org/show_bug.cgi?id=110565 --- Comment #1 from Brian Paul --- >From the Gentoo bug it looks like your command line was simply "scons libgl-xlib". I'm testing with Scons 3.0.1 from Ubuntu 19.04. I get something different: $ scons libgl-xlib scons: Reading SConscript files ... Checking for GCC ... yes Checking for Clang ... no Checking for C header file xlocale.h... (cached) no Checking for C header file endian.h... (cached) yes Checking for C function strtod_l()... (cached) yes Checking for C function strtof_l()... (cached) yes Checking for C function timespec_get()... (cached) yes Checking for X11 (x11 xext xdamage >= 1.1 xfixes glproto >= 1.4.13 dri2proto >= 2.8)... no Checking for XCB (x11-xcb xcb-glx >= 1.8.1 xcb-dri2 >= 1.8)... no Checking for XF86VIDMODE (xxf86vm)... no Checking for DRM (libdrm >= 2.4.75)... no Checking for Python Mako module (>= 0.8.0)... yes warning: LLVM disabled: not building llvmpipe scons: done reading SConscript files. scons: Building targets ... scons: *** Do not know how to make File target `libgl-xlib' (/home/brian/projects/mesa/libgl-xlib). Stop. scons: building terminated because of errors. But, "scons -D" (build default targets) seems to proceed, but no libGL.so is produced at the end. I'll try to dig into this as time permits. -- 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] egl: add EGL_platform_device support
On Mon, 29 Apr 2019 at 22:50, Marek Olšák wrote: > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen wrote: >> >> On Sat, 27 Apr 2019 09:38:27 -0400 >> Marek Olšák wrote: >> >> > Those are all valid reasons, but I don't wanna expose swrast for AMD's >> > customers. >> >> Hi Marek, >> >> is you objection that you will never want to see any software renderer >> in the list, or that you don't want to see a software renderer only as >> long as it doesn't actually work? >> >> Why do you not "wanna expose swrast for AMD's customers"? >> >> Are you talking about swrast specifically or all the software renderers >> in Mesa? >> >> I'm not an AMD customer if you mean someone paying for support rather >> than just buying their hardware, so I cannot speak for them. However, I >> would be very happy to have a software renderer available to be picked >> the same way as any other hardware renderer, so that I can use it in >> graphical test suites (a point from Anholt) testing also the EGL glue >> in addition to the pixels produced. >> >> The thing will be run on boxes with AMD GPUs, and in those cases there >> must be a way to *not* use the AMD GPU, and use the software renderer >> instead when wanted. Not by environment variables or anything hacky >> like that, but by deliberately choosing the software renderer in the >> program. It will need an EGLSurface too. >> >> How would this be made to work in the future? > > > A software renderer could be exposed by adding a new EGL function on top of > EGL_EXT_device_base, for example: > > // EGL_MESA_device_software > > EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice); > > > You would get the swrast device from that function instead of > eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps > everything else the same. > IMHO the current EGL_MESA_device_software approach is perfectly valid. The Query API provides the devices and one can query their capabilities/device extensions. As far as I can see you have valid concerns: - HW devices should be the first/default - the SW device should work, if exposed - one may want to omit the SW one all together At the same time: - the device_base extension is explicit that at least one device must be present - manipulating the EGL client extension string, before we determine the driver is a PITA How about: - whip a quick (admittedly gross) hack that makes SW work - flip the order so SW is always the last one in the list - add a hack that disables SW all-together? The first two should be OK to upstream, although I'd suggest keeping the last one in AMDGPU-PRO. Reason being is that the pro packaging can enforce that radeonsi is always present. While we cannot do that for distributions :-\ /me starts working on the patches -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv/query: ensure visibility of reset before copying query results
Specifically, vkCmdCopyQueryPoolResults is required to see the effect
of a previous vkCmdResetQueryPool. This may not work currently when
query execution is still on going, as some of the queries may become
available asynchronously after the reset.
Fixes new CTS tests:
dEQP-VK.query_pool.statistics_query.reset_before_copy.*
---
Jason, do you have any better ideas?
src/intel/vulkan/genX_query.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/intel/vulkan/genX_query.c b/src/intel/vulkan/genX_query.c
index 146435c3f8f..08b013f6351 100644
--- a/src/intel/vulkan/genX_query.c
+++ b/src/intel/vulkan/genX_query.c
@@ -383,6 +383,19 @@ void genX(CmdResetQueryPool)(
ANV_FROM_HANDLE(anv_cmd_buffer, cmd_buffer, commandBuffer);
ANV_FROM_HANDLE(anv_query_pool, pool, queryPool);
+ /* From the Vulkan spec:
+*
+*"vkCmdCopyQueryPoolResults is guaranteed to see the effect of
+* previous uses of vkCmdResetQueryPool in the same queue, without
+* any additional synchronization. Thus, the results will always
+* reflect the most recent use of the query."
+*
+* So we need to make sure that any on-going queries are finished by
+* the time we emit the reset.
+*/
+ cmd_buffer->state.pending_pipe_bits |= ANV_PIPE_CS_STALL_BIT;
+ genX(cmd_buffer_apply_pipe_flushes)(cmd_buffer);
+
for (uint32_t i = 0; i < queryCount; i++) {
anv_batch_emit(_buffer->batch, GENX(MI_STORE_DATA_IMM), sdm) {
sdm.Address = anv_query_address(pool, firstQuery + i);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] winsys/svga: Add an environment variable to force host-backed operation
The series looks good to me.
Reviewed-by: Brian Paul
On 04/30/2019 05:04 AM, Thomas Hellstrom wrote:
The vmwgfx kernel module has a compatibility mode for user-space that is
not guest-backed resource aware. Add an environment variable to facilitate
testing of this mode on guest-backed aware kernels: if the environment
variable SVGA_FORCE_HOST_BACKED is defined, the driver will use host-backed
operation.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Deepak Rawat
---
src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index 0ec8c1abe11..cdfe284c4c8 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -967,6 +967,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
drmVersionPtr version;
boolean drm_gb_capable;
boolean have_drm_2_5;
+ const char *getenv_val;
VMW_FUNC;
@@ -1006,17 +1007,21 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
goto out_no_3d;
}
vws->ioctl.hwversion = gp_arg.value;
-
- memset(_arg, 0, sizeof(gp_arg));
- gp_arg.param = DRM_VMW_PARAM_HW_CAPS;
- ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_GET_PARAM,
- _arg, sizeof(gp_arg));
+ getenv_val = getenv("SVGA_FORCE_HOST_BACKED");
+ if (!getenv_val || strcmp(getenv_val, "0") == 0) {
+ memset(_arg, 0, sizeof(gp_arg));
+ gp_arg.param = DRM_VMW_PARAM_HW_CAPS;
+ ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_GET_PARAM,
+_arg, sizeof(gp_arg));
+ } else {
+ ret = -EINVAL;
+ }
if (ret)
vws->base.have_gb_objects = FALSE;
else
vws->base.have_gb_objects =
!!(gp_arg.value & (uint64_t) SVGA_CAP_GBOBJECTS);
-
+
if (vws->base.have_gb_objects && !drm_gb_capable)
goto out_no_3d;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110565] scons-3 breaks libgl-xlib build
https://bugs.freedesktop.org/show_bug.cgi?id=110565
Bug ID: 110565
Summary: scons-3 breaks libgl-xlib build
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Other
Assignee: mesa-dev@lists.freedesktop.org
Reporter: freedesk...@volker-wegert.de
QA Contact: mesa-dev@lists.freedesktop.org
Scons has been upgraded from 2.1.5 to 3.0.4 on my Gentoo system. After that,
building libgl-xlib no longer worked; errors were
scons: Reading SConscript files ...
TypeError: a bytes-like object is required, not 'str':
File "/var/tmp/portage/media-libs/mesa-18.3.6/work/mesa-18.3.6/SConstruct",
line 47:
ENV = os.environ,
File "/usr/lib64/python3.6/site-packages/SCons/Environment.py", line 982:
apply_tools(self, tools, toolpath)
File "/usr/lib64/python3.6/site-packages/SCons/Environment.py", line 107:
env.Tool(tool)
File "/usr/lib64/python3.6/site-packages/SCons/Environment.py", line 1789:
tool(self)
File "/usr/lib64/python3.6/site-packages/SCons/Tool/__init__.py", line 296:
self.generate(env, *args, **kw)
File
"/var/tmp/portage/media-libs/mesa-18.3.6/work/mesa-18.3.6/scons/gallium.py",
line 219:
env['gcc_compat'] = check_cc(env, 'GCC', 'defined(__GNUC__)')
File
"/var/tmp/portage/media-libs/mesa-18.3.6/work/mesa-18.3.6/scons/gallium.py",
line 135:
source.write('#if !(%s)\n#error\n#endif\n' % expr)
File "/usr/lib64/python3.6/tempfile.py", line 483:
return func(*args, **kwargs)
Checking for GCC ...
I've been told to report this upstream since apparently this is an issue with
the scons files.
For reference, the Gentoo bug is https://bugs.gentoo.org/684790
--
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] vulkan/wsi: document libdrm version introducing drmIsMaster()
On 2019-04-30 at 12:04, Emil Velikov wrote: > From: Emil Velikov > > To avoid pulling the latest libdrm we copy the helper locally. Document > when it was introduced, making it easier to purge in the future. > > Cc: Eric Engestrom > Suggested-by: Eric Engestrom > Signed-off-by: Emil Velikov > --- > Thanks for the suggestion Eric. Thanks! Reviewed-by: Eric Engestrom > --- > src/vulkan/wsi/wsi_common_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/vulkan/wsi/wsi_common_display.c > b/src/vulkan/wsi/wsi_common_display.c > index 7df1e1fd384..803e7f7e9dd 100644 > --- a/src/vulkan/wsi/wsi_common_display.c > +++ b/src/vulkan/wsi/wsi_common_display.c > @@ -1815,7 +1815,7 @@ fail_attr_init: > > /* > * Local version fo the libdrm helper. Added to avoid depending on bleeding > - * edge version of the library. > + * edge version of the library - libdrm v2.4.98, released 19 Apr 2019. > */ > static int > local_drmIsMaster(int fd) > -- > 2.21.0 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] svga: Avoid bouncing buffer data in malloced buffers
Some constant- and texture upload buffer data may bounce in malloced
buffers before being transferred to hardware buffers. In the case of
texture upload buffers this seems to be an oversight. In the case of
constant buffers, code comments indicate that we want to avoid mapping
hardware buffers for reading when copying out of buffers that need
modification before being passed to hardware. In this case we avoid
data bouncing for upload manager buffers but make sure buffers that
we read out from stay in malloced memory.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
src/gallium/drivers/svga/svga_context.c | 3 +-
.../drivers/svga/svga_resource_buffer.c | 44 ++-
.../drivers/svga/svga_resource_texture.c | 2 +-
3 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_context.c
b/src/gallium/drivers/svga/svga_context.c
index 7b3e9e81f4c..57c0dc49957 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -230,7 +230,8 @@ svga_context_create(struct pipe_screen *screen, void *priv,
unsigned flags)
svga->const0_upload = u_upload_create(>pipe,
CONST0_UPLOAD_DEFAULT_SIZE,
- PIPE_BIND_CONSTANT_BUFFER,
+ PIPE_BIND_CONSTANT_BUFFER |
+ PIPE_BIND_CUSTOM,
PIPE_USAGE_STREAM, 0);
if (!svga->const0_upload)
goto cleanup;
diff --git a/src/gallium/drivers/svga/svga_resource_buffer.c
b/src/gallium/drivers/svga/svga_resource_buffer.c
index a3e11adfac6..3f37ef692fa 100644
--- a/src/gallium/drivers/svga/svga_resource_buffer.c
+++ b/src/gallium/drivers/svga/svga_resource_buffer.c
@@ -42,16 +42,37 @@
/**
- * Vertex and index buffers need hardware backing. Constant buffers
- * do not. No other types of buffers currently supported.
+ * Determine what buffers eventually need hardware backing.
+ *
+ * Vertex- and index buffers need hardware backing. Constant buffers
+ * do on vgpu10. Staging texture-upload buffers do when they are
+ * supported.
*/
static inline boolean
-svga_buffer_needs_hw_storage(unsigned usage)
+svga_buffer_needs_hw_storage(const struct svga_screen *ss,
+ const struct pipe_resource *template)
{
- return (usage & (PIPE_BIND_VERTEX_BUFFER | PIPE_BIND_INDEX_BUFFER |
-PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_STREAM_OUTPUT)) != 0;
-}
+ unsigned bind_mask = (PIPE_BIND_VERTEX_BUFFER | PIPE_BIND_INDEX_BUFFER |
+ PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_STREAM_OUTPUT);
+ if (ss->sws->have_vgpu10) {
+ /*
+ * Driver-created upload const0- and staging texture upload buffers
+ * tagged with PIPE_BIND_CUSTOM
+ */
+ bind_mask |= PIPE_BIND_CUSTOM;
+ /* Uniform buffer objects.
+ * Make sure we don't create hardware storage for state-tracker
+ * const0 buffers, because we frequently map them for reading.
+ * They are distinguished by having PIPE_USAGE_STREAM, but not
+ * PIPE_BIND_CUSTOM.
+ */
+ if (template->usage != PIPE_USAGE_STREAM)
+ bind_mask |= PIPE_BIND_CONSTANT_BUFFER;
+ }
+
+ return !!(template->bind & bind_mask);
+}
/**
* Create a buffer transfer.
@@ -411,7 +432,7 @@ svga_buffer_create(struct pipe_screen *screen,
sbuf->b.vtbl = _buffer_vtbl;
pipe_reference_init(>b.b.reference, 1);
sbuf->b.b.screen = screen;
- bind_flags = template->bind;
+ bind_flags = template->bind & ~PIPE_BIND_CUSTOM;
LIST_INITHEAD(>surfaces);
@@ -430,7 +451,7 @@ svga_buffer_create(struct pipe_screen *screen,
*/
sbuf->b.b.width0 = align(sbuf->b.b.width0, 16);
- if (svga_buffer_needs_hw_storage(bind_flags)) {
+ if (svga_buffer_needs_hw_storage(ss, template)) {
/* If the buffer is not used for constant buffer, set
* the vertex/index bind flags as well so that the buffer will be
@@ -442,9 +463,10 @@ svga_buffer_create(struct pipe_screen *screen,
* bind flag since streamout buffer is an output buffer and
* might have performance implication.
*/
- if (!(template->bind & PIPE_BIND_CONSTANT_BUFFER)) {
- /* Not a constant buffer. The buffer may be used for vertex data
- * or indexes.
+ if (!(template->bind & PIPE_BIND_CONSTANT_BUFFER) &&
+ !(template->bind & PIPE_BIND_CUSTOM)) {
+ /* Not a constant- or staging buffer.
+ * The buffer may be used for vertex data or indexes.
*/
bind_flags |= (PIPE_BIND_VERTEX_BUFFER |
PIPE_BIND_INDEX_BUFFER);
diff --git a/src/gallium/drivers/svga/svga_resource_texture.c
b/src/gallium/drivers/svga/svga_resource_texture.c
index c716b66e89f..e9449e8a1ff 100644
--- a/src/gallium/drivers/svga/svga_resource_texture.c
+++
[Mesa-dev] [PATCH 4/5] winsys/svga: Update the drm interface file
The file vmwgfx_drm.h was a bit outdated. Update to a recent version,
including defines supporting coherent memory.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
.../winsys/svga/drm/vmw_screen_ioctl.c| 4 +-
src/gallium/winsys/svga/drm/vmwgfx_drm.h | 358 +-
2 files changed, 188 insertions(+), 174 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index cdfe284c4c8..ab60265bdd2 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -107,7 +107,7 @@ vmw_ioctl_extended_context_create(struct vmw_winsys_screen
*vws,
VMW_FUNC;
memset(_arg, 0, sizeof(c_arg));
- c_arg.req = (vgpu10 ? drm_vmw_context_vgpu10 : drm_vmw_context_legacy);
+ c_arg.req = (vgpu10 ? drm_vmw_context_dx : drm_vmw_context_legacy);
ret = drmCommandWriteRead(vws->ioctl.drm_fd,
DRM_VMW_CREATE_EXTENDED_CONTEXT,
_arg, sizeof(c_arg));
@@ -1057,7 +1057,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
if (vws->ioctl.have_drm_2_9) {
memset(_arg, 0, sizeof(gp_arg));
- gp_arg.param = DRM_VMW_PARAM_VGPU10;
+ gp_arg.param = DRM_VMW_PARAM_DX;
ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_GET_PARAM,
_arg, sizeof(gp_arg));
if (ret == 0 && gp_arg.value != 0) {
diff --git a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
index 0b1e031292e..02cab33f2f2 100644
--- a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
+++ b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
@@ -28,8 +28,10 @@
#ifndef __VMWGFX_DRM_H__
#define __VMWGFX_DRM_H__
-#ifndef __KERNEL__
-#include "drm-uapi/drm.h"
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
#endif
#define DRM_VMW_MAX_SURFACE_FACES 6
@@ -38,7 +40,9 @@
#define DRM_VMW_GET_PARAM0
#define DRM_VMW_ALLOC_DMABUF 1
+#define DRM_VMW_ALLOC_BO 1
#define DRM_VMW_UNREF_DMABUF 2
+#define DRM_VMW_HANDLE_CLOSE 2
#define DRM_VMW_CURSOR_BYPASS3
/* guarded by DRM_VMW_PARAM_NUM_STREAMS != 0*/
#define DRM_VMW_CONTROL_STREAM 4
@@ -95,7 +99,7 @@
#define DRM_VMW_PARAM_MAX_MOB_MEMORY 9
#define DRM_VMW_PARAM_MAX_MOB_SIZE 10
#define DRM_VMW_PARAM_SCREEN_TARGET11
-#define DRM_VMW_PARAM_VGPU10 12
+#define DRM_VMW_PARAM_DX 12
#define DRM_VMW_PARAM_HW_CAPS2 13
#define DRM_VMW_PARAM_SM4_114
@@ -118,9 +122,9 @@ enum drm_vmw_handle_type {
*/
struct drm_vmw_getparam_arg {
- uint64_t value;
- uint32_t param;
- uint32_t pad64;
+ __u64 value;
+ __u32 param;
+ __u32 pad64;
};
/*/
@@ -141,8 +145,8 @@ struct drm_vmw_getparam_arg {
*/
struct drm_vmw_context_arg {
- int32_t cid;
- uint32_t pad64;
+ __s32 cid;
+ __u32 pad64;
};
/*/
@@ -172,7 +176,7 @@ struct drm_vmw_context_arg {
* @mip_levels: Number of mip levels for each face.
* An unused face should have 0 encoded.
* @size_addr: Address of a user-space array of sruct drm_vmw_size
- * cast to an uint64_t for 32-64 bit compatibility.
+ * cast to an __u64 for 32-64 bit compatibility.
* The size of the array should equal the total number of mipmap levels.
* @shareable: Boolean whether other clients (as identified by file
descriptors)
* may reference this surface.
@@ -184,12 +188,12 @@ struct drm_vmw_context_arg {
*/
struct drm_vmw_surface_create_req {
- uint32_t flags;
- uint32_t format;
- uint32_t mip_levels[DRM_VMW_MAX_SURFACE_FACES];
- uint64_t size_addr;
- int32_t shareable;
- int32_t scanout;
+ __u32 flags;
+ __u32 format;
+ __u32 mip_levels[DRM_VMW_MAX_SURFACE_FACES];
+ __u64 size_addr;
+ __s32 shareable;
+ __s32 scanout;
};
/**
@@ -204,7 +208,7 @@ struct drm_vmw_surface_create_req {
*/
struct drm_vmw_surface_arg {
- int32_t sid;
+ __s32 sid;
enum drm_vmw_handle_type handle_type;
};
@@ -220,10 +224,10 @@ struct drm_vmw_surface_arg {
*/
struct drm_vmw_size {
- uint32_t width;
- uint32_t height;
- uint32_t depth;
- uint32_t pad64;
+ __u32 width;
+ __u32 height;
+ __u32 depth;
+ __u32 pad64;
};
/**
@@ -291,13 +295,13 @@ union drm_vmw_surface_reference_arg {
/**
* struct drm_vmw_execbuf_arg
*
- * @commands: User-space address of a command buffer cast to an uint64_t.
+ * @commands: User-space address of a command buffer cast to an __u64.
* @command-size: Size in bytes of the command buffer.
* @throttle-us: Sleep until software is less than @throttle_us
* microseconds ahead of hardware.
[Mesa-dev] [PATCH 2/5] winsys/svga: Enable the transfer_from_buffer GPU command for vgpu10
We didn't have the path using this command enabled as typically we take an alternate path using DMA uploads. Emable it so that we can exercise that code-path by turning off the DMA path. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul --- src/gallium/winsys/svga/drm/vmw_screen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/winsys/svga/drm/vmw_screen.c b/src/gallium/winsys/svga/drm/vmw_screen.c index e122e0c9902..56294fec60e 100644 --- a/src/gallium/winsys/svga/drm/vmw_screen.c +++ b/src/gallium/winsys/svga/drm/vmw_screen.c @@ -96,6 +96,7 @@ vmw_winsys_create( int fd ) if (!vmw_ioctl_init(vws)) goto out_no_ioctl; + vws->base.have_transfer_from_buffer_cmd = vws->base.have_vgpu10; vws->fence_ops = vmw_fence_ops_create(vws); if (!vws->fence_ops) goto out_no_fence_ops; -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] winsys/svga: Add an environment variable to force host-backed operation
The vmwgfx kernel module has a compatibility mode for user-space that is
not guest-backed resource aware. Add an environment variable to facilitate
testing of this mode on guest-backed aware kernels: if the environment
variable SVGA_FORCE_HOST_BACKED is defined, the driver will use host-backed
operation.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Deepak Rawat
---
src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index 0ec8c1abe11..cdfe284c4c8 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -967,6 +967,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
drmVersionPtr version;
boolean drm_gb_capable;
boolean have_drm_2_5;
+ const char *getenv_val;
VMW_FUNC;
@@ -1006,17 +1007,21 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
goto out_no_3d;
}
vws->ioctl.hwversion = gp_arg.value;
-
- memset(_arg, 0, sizeof(gp_arg));
- gp_arg.param = DRM_VMW_PARAM_HW_CAPS;
- ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_GET_PARAM,
- _arg, sizeof(gp_arg));
+ getenv_val = getenv("SVGA_FORCE_HOST_BACKED");
+ if (!getenv_val || strcmp(getenv_val, "0") == 0) {
+ memset(_arg, 0, sizeof(gp_arg));
+ gp_arg.param = DRM_VMW_PARAM_HW_CAPS;
+ ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_GET_PARAM,
+_arg, sizeof(gp_arg));
+ } else {
+ ret = -EINVAL;
+ }
if (ret)
vws->base.have_gb_objects = FALSE;
else
vws->base.have_gb_objects =
!!(gp_arg.value & (uint64_t) SVGA_CAP_GBOBJECTS);
-
+
if (vws->base.have_gb_objects && !drm_gb_capable)
goto out_no_3d;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vulkan/wsi: document libdrm version introducing drmIsMaster()
From: Emil Velikov To avoid pulling the latest libdrm we copy the helper locally. Document when it was introduced, making it easier to purge in the future. Cc: Eric Engestrom Suggested-by: Eric Engestrom Signed-off-by: Emil Velikov --- Thanks for the suggestion Eric. --- src/vulkan/wsi/wsi_common_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vulkan/wsi/wsi_common_display.c b/src/vulkan/wsi/wsi_common_display.c index 7df1e1fd384..803e7f7e9dd 100644 --- a/src/vulkan/wsi/wsi_common_display.c +++ b/src/vulkan/wsi/wsi_common_display.c @@ -1815,7 +1815,7 @@ fail_attr_init: /* * Local version fo the libdrm helper. Added to avoid depending on bleeding - * edge version of the library. + * edge version of the library - libdrm v2.4.98, released 19 Apr 2019. */ static int local_drmIsMaster(int fd) -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] winsys/svga: Don't abort on EBUSY errors from execbuffer
This error code typically indicated that a buffer object that was referenced
by the command stream was being used for CPU access by another client.
The correct action here is to retry after a while. Use usleep() until we
have proper kernel support for this wait.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index ab60265bdd2..3b14f1d3513 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -564,7 +564,9 @@ vmw_ioctl_command(struct vmw_winsys_screen *vws, int32_t
cid,
offsetof(struct drm_vmw_execbuf_arg, context_handle);
do {
ret = drmCommandWrite(vws->ioctl.drm_fd, DRM_VMW_EXECBUF, ,
argsize);
- } while(ret == -ERESTART);
+ if (ret == -EBUSY)
+ usleep(1000);
+ } while(ret == -ERESTART || ret == -EBUSY);
if (ret) {
vmw_error("%s error %s.\n", __FUNCTION__, strerror(-ret));
abort();
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] amdgpu: Query uvd handles info
Kindly Ignore this. Sent to wrong mailing list. Sent another email to
correct mailing list.
Regards,
Satyajit
On 4/30/2019 4:15 PM, Sahu, Satyajit wrote:
> [CAUTION: External Email]
>
> Query the max uvd handles and used uvd handles.
>
> Signed-off-by: Satyajit Sahu
> ---
> amdgpu/amdgpu.h | 14 ++
> amdgpu/amdgpu_gpu_info.c | 15 +++
> 2 files changed, 29 insertions(+)
>
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> index c44a495a..407b5fae 100644
> --- a/amdgpu/amdgpu.h
> +++ b/amdgpu/amdgpu.h
> @@ -1174,6 +1174,20 @@ int amdgpu_query_gpu_info(amdgpu_device_handle dev,
> int amdgpu_query_info(amdgpu_device_handle dev, unsigned info_id,
>unsigned size, void *value);
>
> +/**
> + * Query uvd handles info.
> + *
> + *
> + * \param dev - \c [in] Device handle. See #amdgpu_device_initialize()
> + * \param size- \c [in] Size of the returned value.
> + * \param value - \c [out] Pointer to the return value.
> + *
> + * \return 0 on success\n
> + * <0 - Negative POSIX error code
> + *
> +*/
> +int amdgpu_query_uvd_handles(amdgpu_device_handle dev,
> + unsigned size, void *value);
> /**
>* Query hardware or driver information.
>*
> diff --git a/amdgpu/amdgpu_gpu_info.c b/amdgpu/amdgpu_gpu_info.c
> index 777087f2..253c4da7 100644
> --- a/amdgpu/amdgpu_gpu_info.c
> +++ b/amdgpu/amdgpu_gpu_info.c
> @@ -44,6 +44,21 @@ drm_public int amdgpu_query_info(amdgpu_device_handle dev,
> unsigned info_id,
> sizeof(struct drm_amdgpu_info));
> }
>
> +drm_public int amdgpu_query_uvd_handles(amdgpu_device_handle dev,
> +unsigned size, void *value)
> +{
> + struct drm_amdgpu_info request;
> +
> + memset(, 0, sizeof(request));
> + request.return_pointer = (uintptr_t)value;
> + request.return_size = size;
> + request.query = AMDGPU_INFO_NUM_HANDLES;
> + request.query_hw_ip.type = AMDGPU_HW_IP_UVD;
> +
> + return drmCommandWrite(dev->fd, DRM_AMDGPU_INFO, ,
> + sizeof(struct drm_amdgpu_info));
> +}
> +
> drm_public int amdgpu_query_crtc_from_id(amdgpu_device_handle dev, unsigned
> id,
> int32_t *result)
> {
> --
> 2.19.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] amdgpu: Query uvd handles info
Query the max uvd handles and used uvd handles.
Signed-off-by: Satyajit Sahu
---
amdgpu/amdgpu.h | 14 ++
amdgpu/amdgpu_gpu_info.c | 15 +++
2 files changed, 29 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index c44a495a..407b5fae 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1174,6 +1174,20 @@ int amdgpu_query_gpu_info(amdgpu_device_handle dev,
int amdgpu_query_info(amdgpu_device_handle dev, unsigned info_id,
unsigned size, void *value);
+/**
+ * Query uvd handles info.
+ *
+ *
+ * \param dev - \c [in] Device handle. See #amdgpu_device_initialize()
+ * \param size- \c [in] Size of the returned value.
+ * \param value - \c [out] Pointer to the return value.
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX error code
+ *
+*/
+int amdgpu_query_uvd_handles(amdgpu_device_handle dev,
+ unsigned size, void *value);
/**
* Query hardware or driver information.
*
diff --git a/amdgpu/amdgpu_gpu_info.c b/amdgpu/amdgpu_gpu_info.c
index 777087f2..253c4da7 100644
--- a/amdgpu/amdgpu_gpu_info.c
+++ b/amdgpu/amdgpu_gpu_info.c
@@ -44,6 +44,21 @@ drm_public int amdgpu_query_info(amdgpu_device_handle dev,
unsigned info_id,
sizeof(struct drm_amdgpu_info));
}
+drm_public int amdgpu_query_uvd_handles(amdgpu_device_handle dev,
+unsigned size, void *value)
+{
+ struct drm_amdgpu_info request;
+
+ memset(, 0, sizeof(request));
+ request.return_pointer = (uintptr_t)value;
+ request.return_size = size;
+ request.query = AMDGPU_INFO_NUM_HANDLES;
+ request.query_hw_ip.type = AMDGPU_HW_IP_UVD;
+
+ return drmCommandWrite(dev->fd, DRM_AMDGPU_INFO, ,
+ sizeof(struct drm_amdgpu_info));
+}
+
drm_public int amdgpu_query_crtc_from_id(amdgpu_device_handle dev, unsigned id,
int32_t *result)
{
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: Query uvd handles info
Query the uvd handles info. If the used uvd handles are equals to
max possible handles then return error.
Signed-off-by: Satyajit Sahu
---
src/gallium/drivers/radeon/radeon_winsys.h| 1 +
src/gallium/drivers/radeonsi/si_get.c | 8
src/gallium/include/pipe/p_screen.h | 1 +
src/gallium/state_trackers/va/context.c | 2 ++
src/gallium/state_trackers/va/picture.c | 11 ++-
src/gallium/state_trackers/va/va_private.h| 1 +
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 11 +++
7 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_winsys.h
b/src/gallium/drivers/radeon/radeon_winsys.h
index 0c71b59ae04..b4f3a3ad09f 100644
--- a/src/gallium/drivers/radeon/radeon_winsys.h
+++ b/src/gallium/drivers/radeon/radeon_winsys.h
@@ -125,6 +125,7 @@ enum radeon_value_id {
RADEON_CURRENT_MCLK,
RADEON_GPU_RESET_COUNTER, /* DRM 2.43.0 */
RADEON_CS_THREAD_TIME,
+RADEON_UVD_HANDLES,
};
enum radeon_bo_priority {
diff --git a/src/gallium/drivers/radeonsi/si_get.c
b/src/gallium/drivers/radeonsi/si_get.c
index 4e23d283ab7..6e27b0162e0 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -887,6 +887,13 @@ static uint64_t si_get_timestamp(struct pipe_screen
*screen)
sscreen->info.clock_crystal_freq;
}
+//ADD function for querying uvd handles info
+static uint64_t si_get_handles_info(struct pipe_screen *screen)
+{
+ struct si_screen *sscreen = (struct si_screen*)screen;
+
+ return sscreen->ws->query_value(sscreen->ws, RADEON_UVD_HANDLES);
+}
static void si_query_memory_info(struct pipe_screen *screen,
struct pipe_memory_info *info)
{
@@ -975,6 +982,7 @@ void si_init_screen_get_functions(struct si_screen *sscreen)
sscreen->b.get_device_uuid = si_get_device_uuid;
sscreen->b.get_driver_uuid = si_get_driver_uuid;
sscreen->b.query_memory_info = si_query_memory_info;
+ sscreen->b.query_handles_info = si_get_handles_info;
sscreen->b.get_disk_shader_cache = si_get_disk_shader_cache;
if (sscreen->info.has_hw_decode) {
diff --git a/src/gallium/include/pipe/p_screen.h
b/src/gallium/include/pipe/p_screen.h
index d4e2d9f63ac..c41af7b842f 100644
--- a/src/gallium/include/pipe/p_screen.h
+++ b/src/gallium/include/pipe/p_screen.h
@@ -148,6 +148,7 @@ struct pipe_screen {
* wait for rendering to complete (which cannot be achieved with queries).
*/
uint64_t (*get_timestamp)(struct pipe_screen *);
+ uint64_t (*query_handles_info)(struct pipe_screen *);
/**
* Create a context.
diff --git a/src/gallium/state_trackers/va/context.c
b/src/gallium/state_trackers/va/context.c
index 9176b7e8c5d..01dc618291f 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -237,8 +237,10 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID
config_id, int picture_width,
if (!context)
return VA_STATUS_ERROR_ALLOCATION_FAILED;
+ context->is_vpp =false;
if (is_vpp) {
context->decoder = NULL;
+ context->is_vpp =true;
} else {
context->templat.profile = config->profile;
context->templat.entrypoint = config->entrypoint;
diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index 04d2da0afeb..43ed53f8e82 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -42,6 +42,8 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID
context_id, VASurfaceID rende
vlVaDriver *drv;
vlVaContext *context;
vlVaSurface *surf;
+ struct pipe_screen *pscreen;
+ int available_uvd_handles;
if (!ctx)
return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -50,6 +52,8 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID
context_id, VASurfaceID rende
if (!drv)
return VA_STATUS_ERROR_INVALID_CONTEXT;
+ pscreen = VL_VA_PSCREEN(ctx);
+
mtx_lock(>mutex);
context = handle_table_get(drv->htab, context_id);
if (!context) {
@@ -73,7 +77,12 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID
context_id, VASurfaceID rende
context->mjpeg.sampling_factor = 0;
if (!context->decoder) {
-
+ if (!context->is_vpp) {
+ //Query available uvd handles. If uvd handles not available fallback
to software.
+ available_uvd_handles = pscreen->query_handles_info(pscreen);
+ if (available_uvd_handles <= 0)
+return VA_STATUS_ERROR_ALLOCATION_FAILED;
+ }
/* VPP */
if (context->templat.profile == PIPE_VIDEO_PROFILE_UNKNOWN &&
context->target->buffer_format != PIPE_FORMAT_B8G8R8A8_UNORM &&
diff --git a/src/gallium/state_trackers/va/va_private.h
b/src/gallium/state_trackers/va/va_private.h
index b2b997d4799..a34cd6785ce 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++
[Mesa-dev] [Bug 110439] [TRACKER] Mesa 19.1 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=110439 Juan A. Suarez changed: What|Removed |Added Depends on||110562 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110562 [Bug 110562] Land VK_EXT_memory_budget -- 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 109323] [TRACKER] mesa: Remove autotools
https://bugs.freedesktop.org/show_bug.cgi?id=109323 Eric Engestrom changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Eric Engestrom --- Autotools is gone now :) commit 95aefc94a941701616fda0776a3bd15710c8c151 Author: Dylan Baker Date: Mon Apr 8 12:44:17 2019 -0700 Delete autotools Acked-by: Kenneth Graunke Reviewed-by: Eric Anholt Reviewed-by: Eric Engestrom Acked-by: Marek Olšák Acked-by: Jason Ekstrand Acked-by: Bas Nieuwenhuizen Acked-by: Matt Turner -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] mesa: fix pbuffers because internally they are front buffers
Adam, Marek, On Monday, 29 April 2019 18:28:21 CEST Adam Jackson wrote: > On Fri, 2019-04-26 at 23:31 -0400, Marek Olšák wrote: > > I don't claim to know what this series is trying to fix, but: > > > +* 2) Pbuffers are back buffers from the application point of view, > > +*but they are front buffers from the Mesa point of view, > > +*because they are always single buffered. > > +*/ > > The EGL spec (back to 1.0!) says: > > "The resulting pbuffer will contain color buffers and ancillary buffers > as specified by config." > > This appears to be copied from GLX, which has something more elaborate: > > "The resulting pbuffer will contain color buffers and ancillary buffers > as specified by config. It is possible to create a pbuffer with back > buffers and to swap the front and back buffers by calling > glXSwapBuffers. Note that pbuffers use framebuffer resources so > applications should consider deallocating them when they are not in > use." > > So I'm not convinced that pbuffers are "always single-buffered". The > back buffer is definitely a color buffer, and at least under GLX it > seems like it should be possible to draw red to back, swap, draw blue > to back, glReadBuffer(GL_FRONT), and expect glReadPixels to return red. Hmm, probably Marek's escape could be 2.2.2 Rendering Models form the eglspec: [...] Pbuffer surfaces have a back buffer but no associated window, so the back buffer need not be copied. [...] Not sure myself what that means in its total consequence, but can't we read that as there is only undefined behavior associated with the pbuffer front buffer? Why, do I get to that? IIRC somewhere in EGL there is a note that there is basically no front buffer rendering in EGL. And the above tells that the implementation may behave as if there is no way to swap the back buffers content into the front buffer. Is there some path left using egl images or egl copy buffers? Or what else do I miss? best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: fix alphaToCoverage when there is no color attachment
Hi Jason,
it seems that this was never addressed so I'll try to take it from
here. A couple of comments regarding your feedback:
We always setup a null render target if we don't have any, so I think
that part of the patch is not necessary. I checked that simply making
sure that we don't remove the output when we are in this situation is
enough to make the tests pass.
However, you make another suggestion below about only writing the
Alpha channel in that case. I understand that you meant this as an
optimization for this particular scenario since it is not really a
functional requirement for this to work, since we are using a null
render target in this case. Anyway, I have been looking into it and I
believe that implementing this would be slightly trickier since we'd
also need to make sure that we compile a different version of the
shader when it is used with a valid color attachment (since in that
case we do need to emit the RGB writes). Therefore, it would require
that we include a bit for this sceneario in brw_wm_prog_key. We could
do that very easily at the same moment we make the decision that we
need a null render target in anv_pipeline_link_fs() (where we are
already editing nr_color_regions and color_outputs_valid in the key).
If we do it like this, then we can implement the optimization trivially
when we handle implement nir_intrinsic_store_output in brw_fs_nir.cpp
by simply skipping the MOVs for the RGB components when this key flag
is set. Does this sound good to you?
Iago
On Fri, 2019-03-22 at 10:06 -0500, Jason Ekstrand wrote:
> I'm confused. Don't we always have a NULL render target at location
> 0? Is the problem really that we need the NULL render target or is
> it that we can't throw away the alpha component of the RT write in
> the shader? If it's that we can't throw away the alpha component of
> the RT write, then I'd suggest a slightly different workaround which
> does just that. We can rewrite the store_output intrinsic (or
> store_var; not sure which it is at that point) so that it writes
> vec4(undef, undef, undef, alpha) to help with linking but then keep
> the one output var so it we still get the write in the shader.
>
>
>
> On Mon, Mar 4, 2019 at 4:56 AM Samuel Iglesias Gonsálvez <
> sigles...@igalia.com> wrote:
> > Still unreviewed.
> >
> >
> >
> > Sam
> >
> >
> >
> > On Thu, 2019-02-21 at 12:08 +0100, Samuel Iglesias Gonsálvez wrote:
> >
> > > CL#3532 added a test for alpha to coverage without a color
> >
> > > attachment.
> >
> > > First the test draws a primitive with alpha 0 and a subpass with
> > only
> >
> > > a depth buffer. No writes to a depth buffer are expected. Then a
> >
> > > second draw with a color buffer and the same depth buffer is done
> > to
> >
> > > verify the depth buffer still has the original clear values.
> >
> > >
> >
> > > This behavior is not explicitly forbidden by the Vulkan spec, so
> >
> > > it seems it is allowed.
> >
> > >
> >
> > > When there is no color attachment for a given output, we discard
> > it
> >
> > > so at the end we have an FS assembly like:
> >
> > >
> >
> > > Native code for unnamed fragment shader (null)
> >
> > > SIMD16 shader: 1 instructions. 0 loops. 4 cycles. 0:0
> > spills:fills.
> >
> > > Promoted 0 constants. Compacted 16 to 16 bytes (0%)
> >
> > >START B0 (4 cycles)
> >
> > > sendc(16) null<1>UW g120<0,1,0>F0x90031000
> >
> > >
> >
> > > render MsgDesc: RT write SIMD16 LastRT Surface = 0 mlen 8 rlen 0
> > {
> >
> > > align1 1H EOT };
> >
> > >
> >
> > > As g120 is not initialized, we see random writes to the depth
> > buffer
> >
> > > due to the alphaToCoverage enablement. This commit fixes that by
> >
> > > keeping the output and creating a null render target for it.
> >
> > >
> >
> > > Fixes tests:
> >
> > >
> >
> > > dEQP-
> > VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
> >
> > >
> >
> > > Signed-off-by: Samuel Iglesias Gonsálvez
> >
> > > ---
> >
> > > src/intel/vulkan/anv_pipeline.c | 35 +
> >
> >
> > >
> >
> > > 1 file changed, 27 insertions(+), 8 deletions(-)
> >
> > >
> >
> > > diff --git a/src/intel/vulkan/anv_pipeline.c
> >
> > > b/src/intel/vulkan/anv_pipeline.c
> >
> > > index e2024212bd9..70a958bf3a8 100644
> >
> > > --- a/src/intel/vulkan/anv_pipeline.c
> >
> > > +++ b/src/intel/vulkan/anv_pipeline.c
> >
> > > @@ -792,7 +792,9 @@ anv_pipeline_compile_gs(const struct
> > brw_compiler
> >
> > > *compiler,
> >
> > >
> >
> > > static void
> >
> > > anv_pipeline_link_fs(const struct brw_compiler *compiler,
> >
> > > - struct anv_pipeline_stage *stage)
> >
> > > + struct anv_pipeline_stage *stage,
> >
> > > + const struct anv_subpass *subpass,
> >
> > > + const VkPipelineMultisampleStateCreateInfo
> >
> > > *ms_info)
> >
> > > {
> >
> > > unsigned num_rts = 0;
> >
> > >
[Mesa-dev] [Bug 110439] [TRACKER] Mesa 19.1 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=110439 Bug 110439 depends on bug 110551, which changed state. Bug 110551 Summary: Land patches for re-enabling fast color clears for GEN11 https://bugs.freedesktop.org/show_bug.cgi?id=110551 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 99781] Some Unity games fail assertion on startup in glXCreateContextAttribsARB
https://bugs.freedesktop.org/show_bug.cgi?id=99781 Michel Dänzer changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #18 from Michel Dänzer --- Thanks for the report, fixed in Mesa Git master: https://gitlab.freedesktop.org/mesa/mesa/commit/e91ee763c378d03883eb88cf0eadd8aa916f7878 -- 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] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware
On Tue, 30 Apr 2019 at 08:47, Dave Airlie wrote: > > On Tue, 30 Apr 2019 at 08:42, Ilia Mirkin wrote: > > > > Thing is, I think that would not be enough - with the "recent" (like > > past 2 years) CSO/state change detection changes, I think that you can > > end up with no sampler set for a buffer view. Perhaps someone with the > > hw can investigate what goes wrong? > > I'm trying to get a live r600/700 machine, I plugged in my rv635 and > rv740 gpus, and they both seemed toast, I've got an rv635 laptop I'll > try and get up to date. I've found a working rv770 and reproduced it here. This isn't an indication I'll get to fix it soon, but I will try. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
