Re: [Mesa-dev] [PATCH 2/3] iris: Create a composite context for both compute and render pipelines
On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote: > iris currently uses two distinct GEM contexts to have distinct logical > HW contexts for the compute and render pipelines. However, using two > distinct GEM contexts implies that they are distinct timelines, yet as > they are a single GL context that implies they belong to a single > timeline from the client perspective. Currently, fences are occasionally > inserted to order the two timelines. Using 2 GEM contexts, also implies > that we keep 2 ppGTT for identical buffer state. If we can create a > single GEM context, with the right capabilities, we can have a single > VM, a single timeline, but 2 logical HW contexts for the 2 pipelines. > > This is allowed through the new context interface that allows VM to be > shared, timelines to be specified, and for the logical contexts to be > constructed as the user desires. > > Cc: Joonas Lahtinen > Cc: Kenneth Graunke > --- > src/gallium/drivers/iris/iris_batch.c | 16 ++- > src/gallium/drivers/iris/iris_batch.h | 5 +-- > src/gallium/drivers/iris/iris_context.c | 56 - > 3 files changed, 60 insertions(+), 17 deletions(-) Hi Chris, I don't think that I want the single timeline option. It seems like we've been moving away from implicit sync for a long time, and the explicit sync code we have is pretty straightforward and seems to do the trick. Jason and I also chatted briefly, and we don't necessarily want to a strict submission-order between render/compute. Separating the VMA from the context state image seems like absolutely the right thing to do - as you said, they're separate in hardware, and no real reason to tie it together. I would be in favor of new uABI for that. I don't think there will be much overhead reduction from sharing the VMA here though. It's very plausible that the compositor might want to run between render and compute batches, at which point we end up doing page directory loads anyway. I have also heard rumors about bit 47 becoming magical at some point which may prohibit us from sharing... Context cloning seems OK, but I'm always pretty hesitant to add new uABI unless it's strictly necessary. In this case, we can do the same thing with a little bit of userspace code, so I'm not sure it's worth adding that... I would love to see an iris patch to use the new I915_CONTEXT_PARAM_RECOVERABLE option without the other dependencies. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] panfrost/midgard: Add ult/ule ops
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 2 ++
src/gallium/drivers/panfrost/midgard/midgard.h | 4
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 1 +
3 files changed, 7 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src/gallium/drivers/panfrost/midgard/helpers.h
index 01c88ed0fcf..0d553d87917 100644
--- a/src/gallium/drivers/panfrost/midgard/helpers.h
+++ b/src/gallium/drivers/panfrost/midgard/helpers.h
@@ -223,6 +223,8 @@ static unsigned alu_opcode_props[256] = {
[midgard_alu_op_ine]= UNITS_MOST,
[midgard_alu_op_ilt]= UNITS_MOST,
[midgard_alu_op_ile]= UNITS_MOST,
+[midgard_alu_op_ule]= UNITS_MOST,
+[midgard_alu_op_ult]= UNITS_MOST,
[midgard_alu_op_icsel] = UNITS_ADD,
[midgard_alu_op_fcsel_i]= UNITS_ADD,
diff --git a/src/gallium/drivers/panfrost/midgard/midgard.h
b/src/gallium/drivers/panfrost/midgard/midgard.h
index c40c94bc378..eab7cb5eec0 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard.h
+++ b/src/gallium/drivers/panfrost/midgard/midgard.h
@@ -103,6 +103,8 @@ typedef enum {
midgard_alu_op_ieq= 0xA0,
midgard_alu_op_ine= 0xA1,
+midgard_alu_op_ult= 0xA2,
+midgard_alu_op_ule= 0xA3,
midgard_alu_op_ilt= 0xA4,
midgard_alu_op_ile= 0xA5,
midgard_alu_op_iball_eq = 0xA8,
@@ -470,6 +472,8 @@ static char *alu_opcode_names[256] = {
[midgard_alu_op_f2u8] = "f2u8",
[midgard_alu_op_ieq]= "ieq",
[midgard_alu_op_ine]= "ine",
+[midgard_alu_op_ult]= "ult",
+[midgard_alu_op_ule]= "ule",
[midgard_alu_op_ilt]= "ilt",
[midgard_alu_op_ile]= "ile",
[midgard_alu_op_iball_eq] = "iball_eq",
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index dac5eeb2c1b..0c7bc28f00a 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -991,6 +991,7 @@ emit_alu(compiler_context *ctx, nir_alu_instr *instr)
ALU_CASE(ieq32, ieq);
ALU_CASE(ine32, ine);
ALU_CASE(ilt32, ilt);
+ALU_CASE(ult32, ult);
/* We don't have a native b2f32 instruction. Instead, like many
* GPUs, we exploit booleans as 0/~0 for false/true, and
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] panfrost/midgard: Handle i2b constant
Fixes
dEQP-GLES2.functional.shaders.conversions.scalar_to_scalar.int_to_bool_fragment
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index d6ed0008596..3dd21d0390d 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1174,7 +1174,7 @@ emit_alu(compiler_context *ctx, nir_alu_instr *instr)
}
ins.alu.src2 = vector_alu_srco_unsigned(blank_alu_src_);
-} else if (instr->op == nir_op_f2b32) {
+} else if (instr->op == nir_op_f2b32 || instr->op == nir_op_i2b32) {
ins.ssa_args.inline_constant = false;
ins.ssa_args.src1 = SSA_FIXED_REGISTER(REGISTER_CONSTANT);
ins.has_constants = true;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] panfrost/midgard: Expand fge lowering to more types
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 1 +
.../drivers/panfrost/midgard/midgard_compile.c | 14 +++---
.../panfrost/midgard/midgard_nir_algebraic.py | 3 ---
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src/gallium/drivers/panfrost/midgard/helpers.h
index 0d553d87917..84db2de84d1 100644
--- a/src/gallium/drivers/panfrost/midgard/helpers.h
+++ b/src/gallium/drivers/panfrost/midgard/helpers.h
@@ -218,6 +218,7 @@ static unsigned alu_opcode_props[256] = {
/* For vector comparisons, use ball etc */
[midgard_alu_op_feq]= UNITS_MOST,
[midgard_alu_op_fne]= UNITS_MOST,
+[midgard_alu_op_fle]= UNITS_MOST,
[midgard_alu_op_flt]= UNITS_MOST,
[midgard_alu_op_ieq]= UNITS_MOST,
[midgard_alu_op_ine]= UNITS_MOST,
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 0c7bc28f00a..d6ed0008596 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1052,11 +1052,19 @@ emit_alu(compiler_context *ctx, nir_alu_instr *instr)
ALU_CASE(b32any_inequal3, ibany_neq);
ALU_CASE(b32any_inequal4, ibany_neq);
-/* For greater-or-equal, we use less-or-equal and flip the
+/* For greater-or-equal, we lower to less-or-equal and flip the
* arguments */
-case nir_op_ige32: {
-op = midgard_alu_op_ile;
+case nir_op_fge:
+case nir_op_fge32:
+case nir_op_ige32:
+case nir_op_uge32: {
+op =
+instr->op == nir_op_fge ? midgard_alu_op_fle :
+instr->op == nir_op_fge32 ? midgard_alu_op_fle :
+instr->op == nir_op_ige32 ? midgard_alu_op_ile :
+instr->op == nir_op_uge32 ? midgard_alu_op_ule :
+0;
/* Swap via temporary */
nir_alu_src temp = instr->src[1];
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py
b/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py
index e5af36539d6..8aad4b128c4 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py
+++ b/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py
@@ -30,9 +30,6 @@ a = 'a'
b = 'b'
algebraic = [
-# TODO: Should really be a fle, maybe not lowered in algebraic?
-(('fge', a, b), ('flt', b, a)),
-
# XXX: We have hw ops for this, just unknown atm..
#(('fsign@32', a), ('i2f32@32', ('isign', ('f2i32@32', ('fmul', a,
0x4380)
#(('fsign', a), ('fcsel', ('fge', a, 0), 1.0, ('fcsel', ('flt', a, 0.0),
-1.0, 0.0)))
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] panfrost/midgard: fpow is a two-part operation
In fact, the native "fpow" instruction only does half of it; more work
is needed for the actual instruction. For now, just lower.
Fixes: 1ea42894c ("panfrost/midgard: Implement fpow")
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 2 +-
src/gallium/drivers/panfrost/midgard/midgard.h | 4 ++--
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 1 -
src/gallium/drivers/panfrost/midgard/midgard_compile.h | 1 +
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src/gallium/drivers/panfrost/midgard/helpers.h
index 84db2de84d1..456c3fb5f1e 100644
--- a/src/gallium/drivers/panfrost/midgard/helpers.h
+++ b/src/gallium/drivers/panfrost/midgard/helpers.h
@@ -234,7 +234,7 @@ static unsigned alu_opcode_props[256] = {
[midgard_alu_op_frcp] = UNIT_VLUT,
[midgard_alu_op_frsqrt] = UNIT_VLUT,
[midgard_alu_op_fsqrt] = UNIT_VLUT,
-[midgard_alu_op_fpow] = UNIT_VLUT,
+[midgard_alu_op_fpow_pt1] = UNIT_VLUT,
[midgard_alu_op_fexp2] = UNIT_VLUT,
[midgard_alu_op_flog2] = UNIT_VLUT,
diff --git a/src/gallium/drivers/panfrost/midgard/midgard.h
b/src/gallium/drivers/panfrost/midgard/midgard.h
index eab7cb5eec0..59957c1b566 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard.h
+++ b/src/gallium/drivers/panfrost/midgard/midgard.h
@@ -126,7 +126,7 @@ typedef enum {
midgard_alu_op_fcsel = 0xC5,
midgard_alu_op_fround = 0xC6,
midgard_alu_op_fatan_pt2 = 0xE8,
-midgard_alu_op_fpow = 0xEC,
+midgard_alu_op_fpow_pt1 = 0xEC,
midgard_alu_op_frcp = 0xF0,
midgard_alu_op_frsqrt = 0xF2,
midgard_alu_op_fsqrt = 0xF3,
@@ -498,7 +498,7 @@ static char *alu_opcode_names[256] = {
[midgard_alu_op_frcp] = "frcp",
[midgard_alu_op_frsqrt] = "frsqrt",
[midgard_alu_op_fsqrt] = "fsqrt",
-[midgard_alu_op_fpow] = "fpow",
+[midgard_alu_op_fpow_pt1] = "fpow_pt1",
[midgard_alu_op_fexp2] = "fexp2",
[midgard_alu_op_flog2] = "flog2",
[midgard_alu_op_fsin] = "fsin",
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 3dd21d0390d..4640d921b7b 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1016,7 +1016,6 @@ emit_alu(compiler_context *ctx, nir_alu_instr *instr)
ALU_CASE(frcp, frcp);
ALU_CASE(frsq, frsqrt);
ALU_CASE(fsqrt, fsqrt);
-ALU_CASE(fpow, fpow);
ALU_CASE(fexp2, fexp2);
ALU_CASE(flog2, flog2);
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.h
b/src/gallium/drivers/panfrost/midgard/midgard_compile.h
index a6520091a21..a4dfb25648d 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.h
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.h
@@ -73,6 +73,7 @@ static const nir_shader_compiler_options midgard_nir_options
= {
.lower_fdiv = true,
.lower_idiv = true,
.lower_isign = true,
+.lower_fpow = true,
.vertex_id_zero_based = true,
.lower_extract_byte = true,
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] [rfc] draw/vs: partly fix basevertex/vertex id
On 03/25/2019 06:47 PM, Dave Airlie wrote:
From: Dave Airlie
This gets the basevertex from the draw depending on whether
it's an indexed or non-indexed draw.
We still fail a transform feedback test for vertex id, as
the vertex id actually an index id, and isn't getting translated
properly to a vertex id, suggestions on how/where to fix that welcome.
---
src/gallium/auxiliary/draw/draw_vs_exec.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_vs_exec.c
b/src/gallium/auxiliary/draw/draw_vs_exec.c
index 4f11ac7506c..dbd7aa551eb 100644
--- a/src/gallium/auxiliary/draw/draw_vs_exec.c
+++ b/src/gallium/auxiliary/draw/draw_vs_exec.c
@@ -128,18 +128,17 @@ vs_exec_run_linear(struct draw_vertex_shader *shader,
input[slot][3]);
}
#endif
+int basevertex = shader->draw->pt.user.eltSize ?
shader->draw->pt.user.eltBias : shader->draw->start_index;
if (shader->info.uses_vertexid) {
unsigned vid =
machine->SysSemanticToIndex[TGSI_SEMANTIC_VERTEXID];
assert(vid < ARRAY_SIZE(machine->SystemValue));
-machine->SystemValue[vid].xyzw[0].i[j] = i + j;
-/* XXX this should include base vertex. Where to get it??? */
+machine->SystemValue[vid].xyzw[0].i[j] = i + j + basevertex;
}
if (shader->info.uses_basevertex) {
unsigned vid =
machine->SysSemanticToIndex[TGSI_SEMANTIC_BASEVERTEX];
assert(vid < ARRAY_SIZE(machine->SystemValue));
-machine->SystemValue[vid].xyzw[0].i[j] = 0;
-/* XXX Where to get it??? */
+machine->SystemValue[vid].xyzw[0].i[j] = basevertex;
}
if (shader->info.uses_vertexid_nobase) {
unsigned vid =
machine->SysSemanticToIndex[TGSI_SEMANTIC_VERTEXID_NOBASE];
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 6/8] gallium: add lima driver
> + [PPIR_INSTR_SLOT_ALU_VEC_MUL] = ppir_codegen_encode_vec_mul,
> + [PPIR_INSTR_SLOT_ALU_SCL_MUL] = ppir_codegen_encode_scl_mul,
> + [PPIR_INSTR_SLOT_ALU_VEC_ADD] = ppir_codegen_encode_vec_add,
> + [PPIR_INSTR_SLOT_ALU_SCL_ADD] = ppir_codegen_encode_scl_add,
vmul/smul/vadd/sadd are the (official?) names for this on Midgard, fwiw.
> +static const int ppir_codegen_field_size[] = {
> + 34, 62, 41, 43, 30, 44, 31, 30, 41, 73
> +};
What is this?
> +static inline int align_to_word(int size)
> +{
> + return ((size + 0x1f) >> 5);
> +}
Maybe use the align() macro (it's in mesa/src/util/) for clarity?
> + ppir_codegen_combine_scalar_op_atan = 8, /* Arc Tangent Part 1 */
> + ppir_codegen_combine_scalar_op_atan2 = 9, /* Arc Tangent 2 Part 1 */
Any plan to use these ops? Midgard has them too, but inverse trig gets
lowered away anyway...
> +if (node->op == ppir_op_neg)
> + src->negate = !src->negate;
> +else if (node->op == ppir_op_abs)
> + src->absolute = true;
I'm confused. NIR has neg/abs modifiers natively. You can get all
fneg/fabs instructions lowered in NIR to these modifiers via
the lower_source_mods pass. If you don't want them, you'll never have
neg/abs ops at all; they'll all be modifiers. Why duplicate this in
ppir?
> + uint32_t va;
I don't know the Utgard MMU, but will this work on 64-bit?
> + uint32_t dubya;
???
> + uint32_t mrt_bits;
> + uint32_t mrt_pitch;
Utgard supports MRT?!
> + uint32_t width = fui(fb->width);
> + uint32_t height = fui(fb->height);
> + uint32_t reload_gl_pos[] = {
> + width, 0x, 0x, 0x3f80, /* 0x */
> + 0x, 0x, 0x, 0x3f80, /* 0x0010 */
> + 0x, height, 0x, 0x3f80, /* 0x0020 */
> + };
> + memcpy(cpu + lima_reload_gl_pos_offset, reload_gl_pos,
> + sizeof(reload_gl_pos));
> +
> + uint32_t reload_varying[] = {
> + width, 0x, 0x, 0x, /* 0x */
> + 0x, height, 0x, 0x, /* 0x0010 */
> + };
> + memcpy(cpu + lima_reload_varying_offset, reload_varying,
> + sizeof(reload_varying));
> +
Why not actual float arrays?
> + uint32_t clear_shader[] = {
> + 0x00021025, 0x000c,
> + (ctx->clear.color_16pc << 12) | 0x07cf,
> + ctx->clear.color_16pc >> 12,
> + ctx->clear.color_16pc >> 44,
> + };
Please don't include shader blobs. This should maybe be generated
from NIR, but at minimum, please include the corresponding annotated
assembly.
> + clear->color_16pc =
> + ((uint64_t)float_to_ushort(color->f[3]) << 48) |
> + ((uint64_t)float_to_ushort(color->f[2]) << 32) |
> + ((uint64_t)float_to_ushort(color->f[1]) << 16) |
> + float_to_ubyte(color->f[0]);
Should that last line be float_to_ushort?
> +enum lima_attrib_type {
> + LIMA_ATTRIB_FLOAT = 0x000,
> + /* todo: find out what lives here. */
LIMA_ATTRIB_FP16 maybe.
LIMA_ATTRIB_I32/LIMA_ATTRIB_U32?.
> +static bool
> +is_modifier_ok(const uint64_t *modifiers, int count, uint64_t mod)
drm_find_modifier in util/u_drm.h
> + /* fs program for clear buffer? */
> + static const uint32_t pp_clear_program[] = {
> + 0x00020425, 0x000c, 0x01e007cf, 0xb000, /* 0x */
> + 0x05f5, 0x, 0x, 0x, /* 0x0010 */
> + };
> + memcpy(lima_bo_map(screen->pp_buffer) + pp_clear_program_offset,
> + pp_clear_program, sizeof(pp_clear_program));
> +
> + /* copy texture to framebuffer, used to reload gpu tile buffer */
> + static const uint32_t pp_reload_program[] = {
> + 0x05e6, 0xf1003c20, 0x, 0x39001000, /* 0x */
> + 0x0e4e, 0x07cf, 0x, 0x, /* 0x0010 */
> + };
> + memcpy(lima_bo_map(screen->pp_buffer) + pp_reload_program_offset,
> + pp_reload_program, sizeof(pp_reload_program));
> +
> + /* 0/1/2 vertex index for reload/clear draw */
> + static const uint32_t pp_shared_index[] = {
> + 0x00020100, 0x, 0x, 0x, /* 0x */
> + };
> + memcpy(lima_bo_map(screen->pp_buffer) + pp_shared_index_offset,
> + pp_shared_index, sizeof(pp_shared_index));
> +
> + /* 4096x4096 gl pos used for partial clear */
> + static const uint32_t pp_clear_gl_pos[] = {
> + 0x4580, 0x, 0x3f80, 0x3f80, /* 0x */
> + 0x, 0x, 0x3f80, 0x3f80, /* 0x0010 */
> + 0x, 0x4580, 0x3f80, 0x3f80, /* 0x0020 */
> + };
> + memcpy(lima_bo_map(screen->pp_buffer) + pp_clear_gl_pos_offset,
> + pp_clear_gl_pos, sizeof(pp_clear_gl_pos));
Again, please no shader blobs.
> +
> + /* reverse calculate the parameter of glViewport */
> + ctx->viewport.x = viewport->translate[0] - viewport->scale[0];
> + ctx->viewport.y = fabsf(viewport->translate[1]
Re: [Mesa-dev] [PATCH v2 6/8] gallium: add lima driver
> Seems Panfrost implementation does not take depth uniforms? That's a /* to-do */ for me; it should definitely be implemented before adding to common code. > we both use the viewport scale/transform vector as the uniform > in this lower pass. I think that's reasonable. I don't like wasting a half-uniform (2vec3 = 1.5vec4), but that can't be helped I guess. > But due to lima pad special uniforms instead of prefix like > panfrost, we need to add a uniform location parameter to the API function. What do you mean by "pad vs prefix"? A location parameter is a good idea regardless. Better yet, we could use an intrinsic system value load (I forget the exact) name to handle this, which I think is the most generic way for common NIR routines. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 6/8] gallium: add lima driver
On Fri, Mar 22, 2019 at 11:25 PM Alyssa Rosenzweig wrote:
>
> > +
> > +static bool gpir_lower_viewport_transform(gpir_compiler *comp)
> > +{
> > + gpir_node *rcpw = NULL;
> > +
> > + /* rcpw = 1 / w */
> > + list_for_each_entry(gpir_block, block, >block_list, list) {
> > + list_for_each_entry(gpir_node, node, >node_list, list) {
> > + if (node->op == gpir_op_store_varying) {
> > +gpir_store_node *store = gpir_node_to_store(node);
> > +if (store->index == 0 && store->component == 3) {
> > + gpir_node *w = store->child;
> > +
> > + rcpw = gpir_node_create(block, gpir_op_rcp);
> > + if (!rcpw)
> > + return false;
> > + list_addtail(>list, >list);
> > +
> > + gpir_alu_node *alu = gpir_node_to_alu(rcpw);
> > + alu->children[0] = w;
> > + alu->num_child = 1;
> > + store->child = rcpw;
> > +
> > + gpir_node_insert_child(node, w, rcpw);
> > + goto found;
> > +}
> > + }
> > + }
> > + }
> > +
> > +found:
> > + assert(rcpw);
> > +
> > + /* xyz = xyz * rcpw * scale + transition */
> > + list_for_each_entry(gpir_block, block, >block_list, list) {
> > + list_for_each_entry(gpir_node, node, >node_list, list) {
> > + if (node->op == gpir_op_store_varying) {
> > +gpir_store_node *store = gpir_node_to_store(node);
> > +if (store->index == 0 && store->component < 3) {
> > + gpir_node *xyz = store->child;
> > +
> > + gpir_node *mul1 =
> > + gpir_lower_create_insert_node(node, xyz, rcpw,
> > gpir_op_mul);
> > + if (!mul1)
> > + return false;
> > +
> > + gpir_load_node *scale = gpir_node_create(block,
> > gpir_op_load_uniform);
> > + if (!scale)
> > + return false;
> > + scale->index = comp->constant_base;
> > + scale->component = store->component;
> > + list_addtail(>node.list, >list);
> > +
> > + gpir_node *mul2 =
> > + gpir_lower_create_insert_node(node, mul1, >node,
> > gpir_op_mul);
> > + if (!mul2)
> > + return false;
> > +
> > + gpir_load_node *translate = gpir_node_create(block,
> > gpir_op_load_uniform);
> > + if (!translate)
> > + return false;
> > + translate->index = comp->constant_base + 1;
> > + translate->component = store->component;
> > + list_addtail(>node.list, >list);
> > +
> > + gpir_node *add =
> > + gpir_lower_create_insert_node(node, mul2,
> > >node, gpir_op_add);
> > + if (!add)
> > + return false;
> > +
> > + store->child = add;
> > +}
> > + }
> > + }
> > + }
> > +
> > + comp->constant_base += 2;
> > + return true;
> > +}
>
> I have this routine implemented in Panfrost at the NIR level, rather
> than the ISA level. Do we want to move this to common NIR code?
>
Seems Panfrost implementation does not take depth uniforms? I think we can
move it to nir if we both use the viewport scale/transform vector as the uniform
in this lower pass. But due to lima pad special uniforms instead of prefix like
panfrost, we need to add a uniform location parameter to the API function.
> > +static int gpir_get_max_start(gpir_node *node)
>
> Read until here (note to self, gotta go, will read more later).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] [rfc] draw/vs: partly fix basevertex/vertex id
From: Dave Airlie
This gets the basevertex from the draw depending on whether
it's an indexed or non-indexed draw.
We still fail a transform feedback test for vertex id, as
the vertex id actually an index id, and isn't getting translated
properly to a vertex id, suggestions on how/where to fix that welcome.
---
src/gallium/auxiliary/draw/draw_vs_exec.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_vs_exec.c
b/src/gallium/auxiliary/draw/draw_vs_exec.c
index 4f11ac7506c..dbd7aa551eb 100644
--- a/src/gallium/auxiliary/draw/draw_vs_exec.c
+++ b/src/gallium/auxiliary/draw/draw_vs_exec.c
@@ -128,18 +128,17 @@ vs_exec_run_linear(struct draw_vertex_shader *shader,
input[slot][3]);
}
#endif
+int basevertex = shader->draw->pt.user.eltSize ?
shader->draw->pt.user.eltBias : shader->draw->start_index;
if (shader->info.uses_vertexid) {
unsigned vid = machine->SysSemanticToIndex[TGSI_SEMANTIC_VERTEXID];
assert(vid < ARRAY_SIZE(machine->SystemValue));
-machine->SystemValue[vid].xyzw[0].i[j] = i + j;
-/* XXX this should include base vertex. Where to get it??? */
+machine->SystemValue[vid].xyzw[0].i[j] = i + j + basevertex;
}
if (shader->info.uses_basevertex) {
unsigned vid =
machine->SysSemanticToIndex[TGSI_SEMANTIC_BASEVERTEX];
assert(vid < ARRAY_SIZE(machine->SystemValue));
-machine->SystemValue[vid].xyzw[0].i[j] = 0;
-/* XXX Where to get it??? */
+machine->SystemValue[vid].xyzw[0].i[j] = basevertex;
}
if (shader->info.uses_vertexid_nobase) {
unsigned vid =
machine->SysSemanticToIndex[TGSI_SEMANTIC_VERTEXID_NOBASE];
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 --- Comment #2 from james.dut...@gmail.com --- the git checkout and cherry-pick are from the mesa git. My graphics card is a AMD Vega 56. -- 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 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 james.dut...@gmail.com changed: What|Removed |Added CC||james.dut...@gmail.com --- Comment #1 from james.dut...@gmail.com --- Comment on attachment 143777 --> https://bugs.freedesktop.org/attachment.cgi?id=143777 Log of wine output from "wine ACOdyssey.exe" The following combination is good: git checkout 5f5ac19f138125b04d8ddedd6334b996f8925a4a git cherry-pick db07f0554a83bef534525c47d2dd3a2c3fcbf8b9 git cherry-pick 427a6fee439b2df96edc813c56572169385772a6 -- 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] panfrost: Cache index buffer bounds
> Can you reuse u_vbuf_get_minmax_index()? From a preliminary read, it didn't look like that did caching? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110240] Assassins Creed Odyssey crashes with nir errors
https://bugs.freedesktop.org/show_bug.cgi?id=110240 Bug ID: 110240 Summary: Assassins Creed Odyssey crashes with nir errors Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: james.dut...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Created attachment 143777 --> https://bugs.freedesktop.org/attachment.cgi?id=143777=edit Log of wine output from "wine ACOdyssey.exe" Summary: error: instr->type == glsl_get_array_element(parent->type) (../src/compiler/nir/nir_validate.c:466) Please see attachment for full log. git checkout master at point git checkout 39da1deb497af55496308c0867b5ce5a0e9df56e -- 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] panfrost: Cache index buffer bounds
Alyssa Rosenzweig writes: > This code is probably a wholesale duplication of the corresponding code > in mesa/src/vbo/vbo_minmax_indices.c; we should investigate reusing > that. Can you reuse u_vbuf_get_minmax_index()? signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/glsl_to_nir: fix incorrect arrary access
On 26/3/19 3:43 am, Emil Velikov wrote: Hi Timothy, On Fri, 1 Mar 2019 at 10:36, Timothy Arceri wrote: This fixes a segfault when we try to access the array using a -1 when the array wasn't allocated in the first place. Before 7536af670b75 we would just access a pre-allocated array that was also load/stored to/from the shader cache. But now the cache will no longer allocate these arrays if they are empty. The change resulted in tests such as the following segfaulting when run with a warm shader cache. I was going through some extra checks for 18.3 and noticed this commit. Admittedly it does not fix 7536af670b75 although it does address a preexisting issue exposed by it. That said I suspect we'd want this for stable? This fixes an issue that is not part of the default path of any drivers so I'm happy to skip back porting to stable. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #10540 completed
Build mesa 10540 completed Commit 8ed583fe52 by Jason Ekstrand on 2/27/2019 9:59 PM: spirv: Handle the NonUniformEXT decoration Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 --- Comment #22 from Dylan Baker --- There is a meson bug here, I've proposed a patch here: https://github.com/mesonbuild/meson/pull/5143 -- 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] [AppVeyor] mesa master #10538 failed
Build mesa 10538 failed Commit 3bd5457641 by Jason Ekstrand on 2/27/2019 8:36 PM: nir: Add a lowering pass for non-uniform resource access\n\nReviewed-by: Bas Nieuwenhuizen Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 --- Comment #21 from mikhail.v.gavri...@gmail.com --- Thanks, Alex. I tested new mesa Fedora build (mesa-19.0.0-2.fc31) I noted that "-Db_ndebug=true" also helps another games rinning by DXVK (steam play): - Dishonored series becomes playeble, yes shutters accidently may occurs but without "-Db_ndebug=true" shutters occurs every time then protogonist change angle of view, with "-Db_ndebug=true" they occurs much rarely. - Homefront: The Revolution without "-Db_ndebug=true" just stucking in main menu. Start game button not woking not on keyboard neither on gamepad. About Rise of the Tomb Raider I can say that the game started after 3 minutes. I suppose there is some more space for optimizations here. -- 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] Fixes assertion fail on startup in `glXCreateContextAttribsARB`.
On Monday, March 25, 2019 4:46 AM, Felix Schwarz wrote: > Am 25.03.19 um 00:06 schrieb zegen...@protonmail.com: > > > To quote Uli Schlacher, who understands this stuff more than I do: > > "Schlachter" Appears I can't spell if my life depended on it. Fixed. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fixes assertion fail on startup in `glXCreateContextAttribsARB`.
From 05468bf625317e76adb43aa8ef20375cc179dd12 Mon Sep 17 00:00:00 2001 From: Hal Gentz Date: Sun, 24 Mar 2019 16:52:39 -0600 Subject: [PATCH] Fixes assertion fail on startup in `glXCreateContextAttribsARB`. To quote Uli Schlachter, who understands this stuff more than I do: > The function __glXSendError() in mesa's src/glx/glx_error.c invents an X11 > protocol error out of thin air. For the sequence number it uses dpy->request. > This is the sequence number of the last request that was sent. _XError() will > then update dpy->last_request_read based on the sequence number of the error > that just "came in". > > If now another something comes in with a sequence number less than > dpy->last_request_read, since sequence numbers are monotonically increasing, > widen() will incorrectly add 1<<32 to the sequence number and things might go > downhill afterwards. `__glXSendErrorForXcb` was also patched, as that's the function that `glXCreateContextAttribsARB` actually uses. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99781 Signed-off-by: Hal Gentz --- src/glx/glx_error.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/glx/glx_error.c b/src/glx/glx_error.c index 653cbeb2d2a..712ecf8213d 100644 --- a/src/glx/glx_error.c +++ b/src/glx/glx_error.c @@ -54,7 +54,7 @@ __glXSendError(Display * dpy, int_fast8_t errorCode, uint_fast32_t resourceID, error.errorCode = glx_dpy->codes->first_error + errorCode; } - error.sequenceNumber = dpy->request; + error.sequenceNumber = dpy->last_request_read; error.resourceID = resourceID; error.minorCode = minorCode; error.majorCode = glx_dpy->majorOpcode; @@ -73,7 +73,7 @@ __glXSendErrorForXcb(Display * dpy, const xcb_generic_error_t *err) error.type = X_Error; error.errorCode = err->error_code; - error.sequenceNumber = err->sequence; + error.sequenceNumber = dpy->last_request_read; error.resourceID = err->resource_id; error.minorCode = err->minor_code; error.majorCode = err->major_code; -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac: allow to use vec3 for typed/untyped buffer stores/loads with LLVM 9+
Just figured that's broken for older LLVM, I will fix.
On 3/25/19 6:17 PM, Samuel Pitoiset wrote:
27670 shaders in 14347 tests
Totals:
SGPRS: 1231173 -> 1236757 (0.45 %)
VGPRS: 866056 -> 867488 (0.17 %)
Spilled SGPRs: 24201 -> 24169 (-0.13 %)
Code Size: 46134836 -> 46115944 (-0.04 %) bytes
Max Waves: 232287 -> 232070 (-0.09 %)
Totals from affected shaders:
SGPRS: 247624 -> 253208 (2.26 %)
VGPRS: 214952 -> 216384 (0.67 %)
Spilled SGPRs: 63 -> 31 (-50.79 %)
Code Size: 7633772 -> 7614880 (-0.25 %) bytes
Max Waves: 62065 -> 61848 (-0.35 %)
This changes requires LLVM r356755.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 21 +++--
src/amd/common/ac_llvm_build.h | 1 +
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 1123dce2cc8..cd963bc008c 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -83,6 +83,7 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
ctx->v2i32 = LLVMVectorType(ctx->i32, 2);
ctx->v3i32 = LLVMVectorType(ctx->i32, 3);
ctx->v4i32 = LLVMVectorType(ctx->i32, 4);
+ ctx->v3f32 = LLVMVectorType(ctx->f32, 3);
ctx->v2f32 = LLVMVectorType(ctx->f32, 2);
ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
ctx->v8i32 = LLVMVectorType(ctx->i32, 8);
@@ -1150,9 +1151,9 @@ ac_build_llvm8_buffer_store_common(struct ac_llvm_context
*ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, HAVE_LLVM >= 0x900 ? 4 : 3) - 1;
- const char *type_names[] = {"f32", "v2f32", "v4f32"};
+ const char *type_names[] = {"f32", "v2f32", "v3f32", "v4f32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
@@ -1334,10 +1335,10 @@ ac_build_llvm8_buffer_load_common(struct ac_llvm_context *ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, HAVE_LLVM >= 0x900 ? 4 : 3) - 1;
- LLVMTypeRef types[] = {ctx->f32, ctx->v2f32, ctx->v4f32};
- const char *type_names[] = {"f32", "v2f32", "v4f32"};
+ LLVMTypeRef types[] = {ctx->f32, ctx->v2f32, ctx->v3f32, ctx->v4f32};
+ const char *type_names[] = {"f32", "v2f32", "v3f32", "v4f32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
@@ -1490,10 +1491,10 @@ ac_build_llvm8_tbuffer_load(struct ac_llvm_context *ctx,
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, dfmt | (nfmt << 4), 0);
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, HAVE_LLVM >= 0x900 ? 4 : 3) - 1;
- LLVMTypeRef types[] = {ctx->i32, ctx->v2i32, ctx->v4i32};
- const char *type_names[] = {"i32", "v2i32", "v4i32"};
+ LLVMTypeRef types[] = {ctx->i32, ctx->v2i32, ctx->v3i32, ctx->v4i32};
+ const char *type_names[] = {"i32", "v2i32", "v3i32", "v4i32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
@@ -1651,9 +1652,9 @@ ac_build_llvm8_tbuffer_store(struct ac_llvm_context *ctx,
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, dfmt | (nfmt << 4), 0);
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, HAVE_LLVM >= 0x900 ? 4 : 3) - 1;
- const char *type_names[] = {"i32", "v2i32", "v4i32"};
+ const char *type_names[] = {"i32", "v2i32", "v3i32", "v4i32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 9151c743bed..d2f8cd5e08b 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -71,6 +71,7 @@ struct ac_llvm_context {
LLVMTypeRef v3i32;
LLVMTypeRef v4i32;
LLVMTypeRef v2f32;
+ LLVMTypeRef v3f32;
LLVMTypeRef v4f32;
LLVMTypeRef v8i32;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ac: allow to use vec3 for typed/untyped buffer stores/loads with LLVM 9+
27670 shaders in 14347 tests
Totals:
SGPRS: 1231173 -> 1236757 (0.45 %)
VGPRS: 866056 -> 867488 (0.17 %)
Spilled SGPRs: 24201 -> 24169 (-0.13 %)
Code Size: 46134836 -> 46115944 (-0.04 %) bytes
Max Waves: 232287 -> 232070 (-0.09 %)
Totals from affected shaders:
SGPRS: 247624 -> 253208 (2.26 %)
VGPRS: 214952 -> 216384 (0.67 %)
Spilled SGPRs: 63 -> 31 (-50.79 %)
Code Size: 7633772 -> 7614880 (-0.25 %) bytes
Max Waves: 62065 -> 61848 (-0.35 %)
This changes requires LLVM r356755.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 21 +++--
src/amd/common/ac_llvm_build.h | 1 +
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 1123dce2cc8..cd963bc008c 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -83,6 +83,7 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
ctx->v2i32 = LLVMVectorType(ctx->i32, 2);
ctx->v3i32 = LLVMVectorType(ctx->i32, 3);
ctx->v4i32 = LLVMVectorType(ctx->i32, 4);
+ ctx->v3f32 = LLVMVectorType(ctx->f32, 3);
ctx->v2f32 = LLVMVectorType(ctx->f32, 2);
ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
ctx->v8i32 = LLVMVectorType(ctx->i32, 8);
@@ -1150,9 +1151,9 @@ ac_build_llvm8_buffer_store_common(struct ac_llvm_context
*ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, HAVE_LLVM >= 0x900 ? 4 : 3) - 1;
- const char *type_names[] = {"f32", "v2f32", "v4f32"};
+ const char *type_names[] = {"f32", "v2f32", "v3f32", "v4f32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
@@ -1334,10 +1335,10 @@ ac_build_llvm8_buffer_load_common(struct
ac_llvm_context *ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, HAVE_LLVM >= 0x900 ? 4 : 3) - 1;
- LLVMTypeRef types[] = {ctx->f32, ctx->v2f32, ctx->v4f32};
- const char *type_names[] = {"f32", "v2f32", "v4f32"};
+ LLVMTypeRef types[] = {ctx->f32, ctx->v2f32, ctx->v3f32, ctx->v4f32};
+ const char *type_names[] = {"f32", "v2f32", "v3f32", "v4f32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
@@ -1490,10 +1491,10 @@ ac_build_llvm8_tbuffer_load(struct ac_llvm_context *ctx,
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, dfmt | (nfmt << 4), 0);
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, HAVE_LLVM >= 0x900 ? 4 : 3) - 1;
- LLVMTypeRef types[] = {ctx->i32, ctx->v2i32, ctx->v4i32};
- const char *type_names[] = {"i32", "v2i32", "v4i32"};
+ LLVMTypeRef types[] = {ctx->i32, ctx->v2i32, ctx->v3i32, ctx->v4i32};
+ const char *type_names[] = {"i32", "v2i32", "v3i32", "v4i32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
@@ -1651,9 +1652,9 @@ ac_build_llvm8_tbuffer_store(struct ac_llvm_context *ctx,
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, dfmt | (nfmt << 4), 0);
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
- unsigned func = CLAMP(num_channels, 1, 3) - 1;
+ unsigned func = CLAMP(num_channels, 1, HAVE_LLVM >= 0x900 ? 4 : 3) - 1;
- const char *type_names[] = {"i32", "v2i32", "v4i32"};
+ const char *type_names[] = {"i32", "v2i32", "v3i32", "v4i32"};
const char *indexing_kind = structurized ? "struct" : "raw";
char name[256];
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 9151c743bed..d2f8cd5e08b 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -71,6 +71,7 @@ struct ac_llvm_context {
LLVMTypeRef v3i32;
LLVMTypeRef v4i32;
LLVMTypeRef v2f32;
+ LLVMTypeRef v3f32;
LLVMTypeRef v4f32;
LLVMTypeRef v8i32;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/glsl_to_nir: fix incorrect arrary access
Hi Timothy, On Fri, 1 Mar 2019 at 10:36, Timothy Arceri wrote: > > This fixes a segfault when we try to access the array using a > -1 when the array wasn't allocated in the first place. > > Before 7536af670b75 we would just access a pre-allocated array > that was also load/stored to/from the shader cache. But now the > cache will no longer allocate these arrays if they are empty. > The change resulted in tests such as the following segfaulting > when run with a warm shader cache. > I was going through some extra checks for 18.3 and noticed this commit. Admittedly it does not fix 7536af670b75 although it does address a preexisting issue exposed by it. That said I suspect we'd want this for stable? Aside: The patch does look spot on IMHO, but I cannot see any formal review - be that on the ML or in gitlab. Thanks -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 00/40] intel: VK_KHR_shader_float16_int8 implementation
On Fri, 2019-03-22 at 17:53 +0100, Iago Toral wrote: > Yes, I think those should be fine to land now, they are very few > actually. Jason, any objections? > Pushed: - [PATCH v4 10/40] compiler/nir: add lowering option for 16-bit fmod - [PATCH v4 11/40] compiler/nir: add lowering for 16-bit flrp - [PATCH v4 12/40] compiler/nir: add lowering for 16-bit ldexp J.A. > Iago > > On Fri, 2019-03-22 at 17:26 +0100, Samuel Pitoiset wrote: > > Can you eventually merge all NIR patches now? We should be able to > > hook > > up that extension for RADV quite soon. > > > > On 2/12/19 12:55 PM, Iago Toral Quiroga wrote: > > > The changes in this version address review feedback to v3. The most > > > significant > > > changes include: > > > > > > 1. A more generic constant combining pass that can handle more > > > constant types (not just F and HF) requested by Jason. > > > > > > 2. The addition of assembly validation for half-float restrictions, > > > and also > > > for mixed float mode, requested by Curro. It should be noted that > > > this > > > implementation of VK_KHR_shader_float16_int8 does not emit any > > > mixed mode float > > > instructions at this moment so I have not empirically validated the > > > restictions > > > implemented here. > > > > > > As always, a branch with these patches is available for testing in > > > the > > > itoral/VK_KHR_shader_float16_int8 branch of the Igalia Mesa > > > repository at > > > https://github.com/Igalia/mesa. > > > > > > Iago Toral Quiroga (40): > > >compiler/nir: add an is_conversion field to nir_op_info > > >intel/compiler: add a NIR pass to lower conversions > > >intel/compiler: split float to 64-bit opcodes from int to 64-bit > > >intel/compiler: handle b2i/b2f with other integer conversion > > > opcodes > > >intel/compiler: assert restrictions on conversions to half-float > > >intel/compiler: lower some 16-bit float operations to 32-bit > > >intel/compiler: handle extended math restrictions for half-float > > >intel/compiler: implement 16-bit fsign > > >intel/compiler: drop unnecessary temporary from 32-bit fsign > > > implementation > > >compiler/nir: add lowering option for 16-bit fmod > > >compiler/nir: add lowering for 16-bit flrp > > >compiler/nir: add lowering for 16-bit ldexp > > >intel/compiler: add instruction setters for Src1Type and > > > Src2Type. > > >intel/compiler: add new half-float register type for 3-src > > > instructions > > >intel/compiler: don't compact 3-src instructions with Src1Type > > > or > > > Src2Type bits > > >intel/compiler: allow half-float on 3-source instructions since > > > gen8 > > >intel/compiler: set correct precision fields for 3-source float > > > instructions > > >intel/compiler: fix ddx and ddy for 16-bit float > > >intel/compiler: fix ddy for half-float in Broadwell > > >intel/compiler: workaround for SIMD8 half-float MAD in gen8 > > >intel/compiler: split is_partial_write() into two variants > > >intel/compiler: activate 16-bit bit-size lowerings also for 8- > > > bit > > >intel/compiler: rework conversion opcodes > > >intel/compiler: implement isign for int8 > > >intel/compiler: ask for an integer type if requesting an 8-bit > > > type > > >intel/eu: force stride of 2 on NULL register for Byte > > > instructions > > >intel/compiler: generalize the combine constants pass > > >intel/compiler: implement is_zero, is_one, is_negative_one for > > > 8-bit/16-bit > > >intel/compiler: add a brw_reg_type_is_integer helper > > >intel/compiler: fix cmod propagation for non 32-bit types > > >intel/compiler: remove inexact algebraic optimizations from the > > > backend > > >intel/compiler: skip MAD algebraic optimization for half-float > > > or > > > mixed mode > > >intel/compiler: also set F execution type for mixed float mode > > > in BDW > > >intel/compiler: validate region restrictions for half-float > > > conversions > > >intel/compiler: validate conversions between 64-bit and 8-bit > > > types > > >intel/compiler: skip validating restrictions on operand types > > > for > > > mixed float > > >intel/compiler: validate region restrictions for mixed float > > > mode > > >compiler/spirv: move the check for Int8 capability > > >anv/pipeline: support Float16 and Int8 SPIR-V capabilities in > > > gen8+ > > >anv/device: expose VK_KHR_shader_float16_int8 in gen8+ > > > > > > src/compiler/nir/nir.h| 5 + > > > src/compiler/nir/nir_opcodes.py | 73 +- > > > src/compiler/nir/nir_opcodes_c.py | 1 + > > > src/compiler/nir/nir_opt_algebraic.py | 11 +- > > > src/compiler/shader_info.h| 1 + > > > src/compiler/spirv/spirv_to_nir.c | 11 +- > > > src/intel/Makefile.sources| 1 + > > >
[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 --- Comment #20 from Mike Lothian --- Seems to be setting it with CFLAGS, though I guess that might need to change -- 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 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 --- Comment #19 from Alex Smith --- You have -Db_ndebug=true which I think is what Fedora is missing - their build definitely does not have that as I see code in the binaries that is only compiled when NDEBUG is not set. However you don't get any optimization flag set, unless Gentoo is setting it with CFLAGS? -- 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 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 --- Comment #18 from Mike Lothian --- Will --buildtype=plane cause any issues? It's the default here on Gentoo meson --buildtype plain --libdir lib64 --localstatedir /var/lib --prefix /usr --sysconfdir /etc --wrap-mode nodownload -Dplatforms=x11,surfaceless,wayland,drm -Dllvm=true -Dlmsensors=true -Dlibunwind=false -Dgallium-nine=true -Dgallium-va=true -Dva-libs-path=/usr/lib64/va/drivers -Dgallium-vdpau=true -Dgallium-xa=false -Dgallium-xvmc=false -Dgallium-opencl=disabled -Dosmesa=none -Dbuild-tests=false -Dglx=dri -Dshared-glapi=true -Ddri3=true -Degl=true -Dgbm=true -Dgles1=false -Dgles2=true -Dglvnd=false -Dselinux=false -Dvalgrind=false -Ddri-drivers=i965 -Dgallium-drivers=radeonsi,swrast -Dvulkan-drivers=amd,intel -Dvulkan-overlay-layer=true --buildtype plain -Db_ndebug=true /var/tmp/portage/media-libs/mesa-/work/mesa- /var/tmp/portage/media-libs/mesa-/work/mesa--abi_x86_64.amd64 -- 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 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 --- Comment #17 from Alex Smith --- Reported: https://bugzilla.redhat.com/show_bug.cgi?id=1692426 -- 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 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03
https://bugs.freedesktop.org/show_bug.cgi?id=110141 --- Comment #1 from Parker Reed --- wlroots from sway is also affected. -- 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] st/mesa: fix texture deletion context mix-up issues (v2)
On 03/23/2019 10:49 AM, Jose Fonseca wrote:
Looks good to me.
Reviewed-by: Jose Fonseca
Though I wonder if this could happen also when not destroying the
current context. (Ie, if we need zoombie textures too?)
If we're not destroying the thread's current context, this patch
temporarily binds the context as the current one. If the contexts
textures are not shared, they'll be deleted. If they are shared, they
won't be deleted. I think that part is fairly straight-forward.
-Brian
Jose
*From:* Brian Paul
*Sent:* Friday, March 22, 2019 19:51
*To:* mesa-dev@lists.freedesktop.org
*Cc:* Jose Fonseca; Neha Bhende
*Subject:* [PATCH] st/mesa: fix texture deletion context mix-up issues (v2)
When we destroy a context, we need to temporarily make that context
the current one for the thread.
That's because during context tear-down we make many calls to
_mesa_reference_texobj(, NULL). Note there's no context
parameter. If the texture's refcount goes to zero and we need to
delete it, we use the thread's current context. But if that context
isn't the context we're tearing down, we get into trouble when
deallocating sampler views. See patch 593e36f956 ("st/mesa:
implement "zombie" sampler views (v2)") for background information.
Also, we need to release any sampler views attached to the fallback
textures.
Fixes a crash on exit with a glretrace of the Nobel Clinician
application.
v2: at end of st_destroy_context(), check if save_ctx == ctx and
unbind the context if so.
---
src/mesa/state_tracker/st_context.c | 51
-
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
index f037384..09d467a 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -917,15 +917,39 @@ st_destroy_context(struct st_context *st)
{
struct gl_context *ctx = st->ctx;
struct st_framebuffer *stfb, *next;
+ struct gl_framebuffer *save_drawbuffer;
+ struct gl_framebuffer *save_readbuffer;
+
+ /* Save the current context and draw/read buffers*/
+ GET_CURRENT_CONTEXT(save_ctx);
+ if (save_ctx) {
+ save_drawbuffer = save_ctx->WinSysDrawBuffer;
+ save_readbuffer = save_ctx->WinSysReadBuffer;
+ } else {
+ save_drawbuffer = save_readbuffer = NULL;
+ }
- GET_CURRENT_CONTEXT(curctx);
+ /*
+ * We need to bind the context we're deleting so that
+ * _mesa_reference_texobj_() uses this context when deleting textures.
+ * Similarly for framebuffer objects, etc.
+ */
+ _mesa_make_current(ctx, NULL, NULL);
- if (curctx == NULL) {
- /* No current context, but we need one to release
- * renderbuffer surface when we release framebuffer.
- * So temporarily bind the context.
- */
- _mesa_make_current(ctx, NULL, NULL);
+ /* This must be called first so that glthread has a chance to finish */
+ _mesa_glthread_destroy(ctx);
+
+ _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st);
+
+ /* For the fallback textures, free any sampler views belonging to this
+ * context.
+ */
+ for (unsigned i = 0; i < NUM_TEXTURE_TARGETS; i++) {
+ struct st_texture_object *stObj =
+ st_texture_object(ctx->Shared->FallbackTex[i]);
+ if (stObj) {
+ st_texture_release_context_sampler_view(st, stObj);
+ }
}
st_context_free_zombie_objects(st);
@@ -933,11 +957,6 @@ st_destroy_context(struct st_context *st)
mtx_destroy(>zombie_sampler_views.mutex);
mtx_destroy(>zombie_shaders.mutex);
- /* This must be called first so that glthread has a chance to finish */
- _mesa_glthread_destroy(ctx);
-
- _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st);
-
st_reference_fragprog(st, >fp, NULL);
st_reference_prog(st, >gp, NULL);
st_reference_vertprog(st, >vp, NULL);
@@ -965,4 +984,12 @@ st_destroy_context(struct st_context *st)
st = NULL;
free(ctx);
+
+ if (save_ctx == ctx) {
+ /* unbind the context we just deleted */
+ _mesa_make_current(NULL, NULL, NULL);
+ } else {
+ /* Restore the current context and draw/read buffers (may be NULL) */
+ _mesa_make_current(save_ctx, save_drawbuffer, save_readbuffer);
+ }
}
--
1.8.5.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] nir: aplit nir_shader_compiler_options::lower_ffma into 16/32/64 bits
RADV doesn't have to lower 16-bits FMA.
Original patch from Rhys Perry.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 4 +++-
src/broadcom/compiler/nir_to_vir.c | 4 +++-
src/compiler/nir/nir.h | 4 +++-
src/compiler/nir/nir_opt_algebraic.py | 4 +++-
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 4 +++-
src/gallium/drivers/panfrost/midgard/midgard_compile.h | 3 ++-
src/gallium/drivers/radeonsi/si_get.c | 4 +++-
src/gallium/drivers/vc4/vc4_program.c | 4 +++-
8 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 7c5447c5b56..63d4147460c 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -70,7 +70,9 @@ static const struct nir_shader_compiler_options nir_options =
{
.lower_unpack_unorm_4x8 = true,
.lower_extract_byte = true,
.lower_extract_word = true,
- .lower_ffma = true,
+ .lower_ffma16 = true,
+ .lower_ffma32 = true,
+ .lower_ffma64 = true,
.lower_fpow = true,
.lower_mul_2x32_64 = true,
.max_unroll_iterations = 32
diff --git a/src/broadcom/compiler/nir_to_vir.c
b/src/broadcom/compiler/nir_to_vir.c
index 2c411b86ed1..c516bd4eb74 100644
--- a/src/broadcom/compiler/nir_to_vir.c
+++ b/src/broadcom/compiler/nir_to_vir.c
@@ -2330,7 +2330,9 @@ const nir_shader_compiler_options v3d_nir_options = {
.lower_unpack_half_2x16 = true,
.lower_fdiv = true,
.lower_find_lsb = true,
-.lower_ffma = true,
+.lower_ffma16 = true,
+.lower_ffma32 = true,
+.lower_ffma64 = true,
.lower_flrp32 = true,
.lower_fpow = true,
.lower_fsat = true,
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index ca9d5e6ffc8..84f7f0ec23b 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2161,7 +2161,9 @@ typedef enum {
typedef struct nir_shader_compiler_options {
bool lower_fdiv;
- bool lower_ffma;
+ bool lower_ffma16;
+ bool lower_ffma32;
+ bool lower_ffma64;
bool fuse_ffma;
bool lower_flrp16;
bool lower_flrp32;
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
index 2e5e43d801e..b1559133281 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -141,7 +141,9 @@ optimizations = [
(('~fadd', a, ('fmul', ('b2f', 'c@1'), ('fadd', b, ('fneg', a,
('bcsel', c, b, a), 'options->lower_flrp32'),
(('~fadd@32', a, ('fmul', c , ('fadd', b, ('fneg', a, ('flrp',
a, b, c), '!options->lower_flrp32'),
(('~fadd@64', a, ('fmul', c , ('fadd', b, ('fneg', a, ('flrp',
a, b, c), '!options->lower_flrp64'),
- (('ffma', a, b, c), ('fadd', ('fmul', a, b), c), 'options->lower_ffma'),
+ (('ffma@16', a, b, c), ('fadd', ('fmul', a, b), c),
'options->lower_ffma16'),
+ (('ffma@32', a, b, c), ('fadd', ('fmul', a, b), c),
'options->lower_ffma32'),
+ (('ffma@64', a, b, c), ('fadd', ('fmul', a, b), c),
'options->lower_ffma64'),
(('~fadd', ('fmul', a, b), c), ('ffma', a, b, c), 'options->fuse_ffma'),
(('fdot4', ('vec4', a, b, c, 1.0), d), ('fdph', ('vec3', a, b, c), d)),
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index afad48b5920..957ed5904cd 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -896,7 +896,9 @@ nvc0_screen_bind_cb_3d(struct nvc0_screen *screen, bool
*can_serialize,
static const nir_shader_compiler_options nir_options = {
.lower_fdiv = false,
- .lower_ffma = false,
+ .lower_ffma16 = false,
+ .lower_ffma32 = false,
+ .lower_ffma64 = false,
.fuse_ffma = false, /* nir doesn't track mad vs fma */
.lower_flrp32 = true,
.lower_flrp64 = true,
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.h
b/src/gallium/drivers/panfrost/midgard/midgard_compile.h
index b3308c866f6..d609cbf0ae7 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.h
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.h
@@ -62,8 +62,9 @@ midgard_compile_shader_nir(nir_shader *nir, midgard_program
*program, bool is_bl
* solution. */
static const nir_shader_compiler_options midgard_nir_options = {
-.lower_ffma = true,
.lower_ffma16 = true,
+.lower_ffma32 = true,
+.lower_ffma64 = true,
.lower_sub = true,
.lower_scmp = true,
.lower_flrp32 = true,
diff --git a/src/gallium/drivers/radeonsi/si_get.c
b/src/gallium/drivers/radeonsi/si_get.c
index 6fa67087c7d..de0213995cb 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -490,7 +490,9 @@ static const struct nir_shader_compiler_options
[Mesa-dev] [PATCH 2/2] radv: do not lower 16-bit FMA
The lowering needs to be disabled for sufficient precision to pass
deqp-vk's 16-bit fma test on radv.
Original patch from Rhys.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 63d4147460c..05041b2eae6 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -70,7 +70,6 @@ static const struct nir_shader_compiler_options nir_options =
{
.lower_unpack_unorm_4x8 = true,
.lower_extract_byte = true,
.lower_extract_word = true,
- .lower_ffma16 = true,
.lower_ffma32 = true,
.lower_ffma64 = true,
.lower_fpow = true,
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vl/dri3: remove the wait before getting back buffer
On 2019-03-21 8:10 p.m., Liu, Leo wrote:
> On 2019-03-20 1:56 p.m., Michel Dänzer wrote:
>> On 2019-03-20 4:42 p.m., Liu, Leo wrote:
>>> The wait here is unnecessary since we got a pool of back buffers,
>>> and the wait for swap buffer will happen before the present pixmap,
>>> at the same time the previous back buffer will be put back to pool
>>> for reuse after the check for PresentIdleNotify event
>>>
>>> Signed-off-by: Leo Liu
>>>
>>> [...]
>>>
>>> @@ -626,13 +621,6 @@ vl_dri3_screen_texture_from_drawable(struct vl_screen
>>> *vscreen, void *drawable)
>>> if (!dri3_set_drawable(scrn, (Drawable)drawable))
>>> return NULL;
>>>
>>> - if (scrn->flushed) {
>>> - while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
>>> - if (!dri3_wait_present_events(scrn))
>>> -return NULL;
>>> - }
>>> - scrn->flushed = false;
>>> -
>>> buffer = (scrn->is_pixmap) ?
>>> dri3_get_front_buffer(scrn) :
>>> dri3_get_back_buffer(scrn);
>>>
>> Hmm. Is the wait here not necessary before getting a pixmap's front
>> buffer either though? Maybe wait only here for a pixmap, and only in
>> vl_dri3_flush_frontbuffer for a window?
>>
>> Sorry I didn't realize this earlier.
>>
> The pixmap case is used by Totem player, or previous GLX case for MPV
> player, and the front buffer of the pixmap is a temporary buffer, and
> later as source for GL to present.
>
> For pixmap case, there is no need to wait, and the dri3 present wait
> before dri3_get_front_buffer() is not get called, because scrn->flushed
> will never be true, since our presentation flush code is not used by
> this case.
Makes sense, thanks.
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix texture deletion context mix-up issues (v2)
On 25/03/2019 14:26, Brian Paul wrote: > On 03/23/2019 10:49 AM, Jose Fonseca wrote: >> Looks good to me. >> >> Reviewed-by: Jose Fonseca >> >> Though I wonder if this could happen also when not destroying the >> current context. (Ie, if we need zoombie textures too?) > > If we're not destroying the thread's current context, this patch > temporarily binds the context as the current one. If the contexts > textures are not shared, they'll be deleted. If they are shared, they > won't be deleted. I think that part is fairly straight-forward. OK. Thinking more about it, we only need zombies for the sample views, not the textures themselves. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 --- Comment #16 from Alex Smith --- I think I have an idea what's happening here. Pipeline compilation will be a lot slower using debug builds of Mesa. Mikhail, it looks from your backtraces like you're using a debug build you've done yourself? If so could you use a release build instead (pass -Dbuildtype=release to meson, the default is debugoptimized). Timur, are you by any chance using Fedora's packages? It appears that they are currently shipping a debug build in there, and I can reproduce this when using those :( I will file a bug with Fedora. -- 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] draw/gs: fix point size outputs from geometry shader.
On 03/24/2019 11:14 PM, Dave Airlie wrote:
From: Dave Airlie
If the geom shader emits a point size we failed to find it here,
use the correct API to look it up.
Fixes:
tests/spec/glsl-1.50/execution/geometry/point-size-out.shader_test
---
src/gallium/auxiliary/draw/draw_pipe_wide_point.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_wide_point.c
b/src/gallium/auxiliary/draw/draw_pipe_wide_point.c
index 1329ab4e7c0..e9bbb67a958 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_wide_point.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_wide_point.c
@@ -266,14 +266,7 @@ widepoint_first_point(struct draw_stage *stage,
wide->psize_slot = -1;
if (rast->point_size_per_vertex) {
/* find PSIZ vertex output */
- const struct draw_vertex_shader *vs = draw->vs.vertex_shader;
- uint i;
- for (i = 0; i < vs->info.num_outputs; i++) {
- if (vs->info.output_semantic_name[i] == TGSI_SEMANTIC_PSIZE) {
-wide->psize_slot = i;
-break;
- }
- }
+ wide->psize_slot = draw_find_shader_output(draw, TGSI_SEMANTIC_PSIZE, 0);
}
stage->point( stage, header );
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] 2019 X.Org Foundation Election Opening in 35 hours
To all X.Org Foundation Members: We've had some problems with the previous ballot (i.e. I didn't create it properly) that opened last Thursday. Apologies to the two people that already voted. We've re-created the ballot (v2). It will open on March 27 at 2am UTC and close on April 11 at 2am UTC. Updated Schedule: Nomination period Start: Jan 31 00:00 UTC Nomination period End: Feb 28 23:59 UTC Deadline of X.Org membership application or renewal: Mar 07 23:59 UTC Publication of Candidates & start of Candidate QA: Mar 11 Election Start: Mar 21 00:00 UTC - Delayed to March 21, again delayed to March 27 at 02:00 UTC Election End: Apr 4 23:59 UTC - Extended to April 11, 02:00 UTC I will send a reminder the day the polls open. I apologize for the many delays. Please take some time to familiarize yourself with the proposed bylaw changes and the candidates. Details are at https://www.x.org/wiki/BoardOfDirectors/Elections/2019/ Harry, on behalf of the X.Org elections committee ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: bail instead of assert on instance count (v2)
On 03/24/2019 09:41 PM, Dave Airlie wrote: From: Dave Airlie With indirect rendering it's fine to set the instance count parameter to 0, and expect the rendering to be ignored. Fixes assert in KHR-GLES31.core.compute_shader.pipeline-gen-draw-commands on softpipe v2: return earlier before changing fpstate --- src/gallium/auxiliary/draw/draw_pt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/draw/draw_pt.c b/src/gallium/auxiliary/draw/draw_pt.c index be76a30f97c..50286149cd4 100644 --- a/src/gallium/auxiliary/draw/draw_pt.c +++ b/src/gallium/auxiliary/draw/draw_pt.c @@ -464,6 +464,9 @@ draw_vbo(struct draw_context *draw, unsigned fpstate = util_fpstate_get(); struct pipe_draw_info resolved_info; + if (info->instance_count == 0) + return; + /* Make sure that denorms are treated like zeros. This is * the behavior required by D3D10. OpenGL doesn't care. */ @@ -472,7 +475,6 @@ draw_vbo(struct draw_context *draw, resolve_draw_info(info, _info, &(draw->pt.vertex_buffer[0])); info = _info; - assert(info->instance_count > 0); if (info->index_size) assert(draw->pt.user.elts); Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110230] "Read the documentation here" link on https://www.mesa3d.org/sourcedocs.html is a 404 error
https://bugs.freedesktop.org/show_bug.cgi?id=110230 --- Comment #8 from Laurent --- Ok but there isn't any source documentation generated in the mesa folder when I run doxygen command is it normal ? It seems it only point to links for reading the documentation. -- 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] ac: use llvm.amdgcn.fmed3 intrinsic for nir_op_fmed3
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 27 +++
src/amd/common/ac_llvm_build.h | 4
src/amd/common/ac_nir_to_llvm.c | 13 +
3 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 1123dce2cc8..04d4b377fd1 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -2430,6 +2430,33 @@ void ac_build_waitcnt(struct ac_llvm_context *ctx,
unsigned simm16)
ctx->voidt, args, 1, 0);
}
+LLVMValueRef ac_build_fmed3(struct ac_llvm_context *ctx, LLVMValueRef src0,
+ LLVMValueRef src1, LLVMValueRef src2,
+ unsigned bitsize)
+{
+ LLVMTypeRef type;
+ char *intr;
+
+ if (bitsize == 16) {
+ intr = "llvm.amdgcn.fmed3.f16";
+ type = ctx->f16;
+ } else if (bitsize == 32) {
+ intr = "llvm.amdgcn.fmed3.f32";
+ type = ctx->f32;
+ } else {
+ intr = "llvm.amdgcn.fmed3.f64";
+ type = ctx->f64;
+ }
+
+ LLVMValueRef params[] = {
+ src0,
+ src1,
+ src2,
+ };
+ return ac_build_intrinsic(ctx, intr, type, params, 3,
+ AC_FUNC_ATTR_READNONE);
+}
+
LLVMValueRef ac_build_fract(struct ac_llvm_context *ctx, LLVMValueRef src0,
unsigned bitsize)
{
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 9151c743bed..14c1c56522b 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -549,6 +549,10 @@ void ac_build_waitcnt(struct ac_llvm_context *ctx,
unsigned simm16);
LLVMValueRef ac_build_fract(struct ac_llvm_context *ctx, LLVMValueRef src0,
unsigned bitsize);
+LLVMValueRef ac_build_fmed3(struct ac_llvm_context *ctx, LLVMValueRef src0,
+ LLVMValueRef src1, LLVMValueRef src2,
+ unsigned bitsize);
+
LLVMValueRef ac_build_isign(struct ac_llvm_context *ctx, LLVMValueRef src0,
unsigned bitsize);
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 675623cbfeb..7fd6437049a 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -,14 +,11 @@ static void visit_alu(struct ac_nir_context *ctx, const
nir_alu_instr *instr)
result = emit_minmax_int(>ac, LLVMIntSGT, result, src[2]);
break;
case nir_op_fmed3: {
- LLVMValueRef tmp1 = emit_intrin_2f_param(>ac,
"llvm.minnum",
- ac_to_float_type(>ac,
def_type), src[0], src[1]);
- LLVMValueRef tmp2 = emit_intrin_2f_param(>ac,
"llvm.maxnum",
- ac_to_float_type(>ac,
def_type), src[0], src[1]);
- tmp2 = emit_intrin_2f_param(>ac, "llvm.minnum",
- ac_to_float_type(>ac,
def_type), tmp2, src[2]);
- result = emit_intrin_2f_param(>ac, "llvm.maxnum",
- ac_to_float_type(>ac,
def_type), tmp1, tmp2);
+ src[0] = ac_to_float(>ac, src[0]);
+ src[1] = ac_to_float(>ac, src[1]);
+ src[2] = ac_to_float(>ac, src[2]);
+ result = ac_build_fmed3(>ac, src[0], src[1], src[2],
+ instr->dest.dest.ssa.bit_size);
break;
}
case nir_op_imed3: {
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fixes assertion fail on startup in `glXCreateContextAttribsARB`.
Am 25.03.19 um 00:06 schrieb zegen...@protonmail.com: > To quote Uli Schlacher, who understands this stuff more than I do: "Schlachter" > https://bugs.freedesktop.org/show_bug.cgi?id=99781 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99781 Felix ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] iris: Handle GPU recovery
We want to opt out of the automatic GPU recovery and replay performed by
the kernel of a guilty context after a GPU reset as our incremental
batch construction very often implies that subsequent batches are a GPU
reset are incomplete and will trigger fresh GPU hangs. As we are aware
of how we need to reset the context state, but the kernel isn't, tell
the kernel to cancel the inflight rendering and immediately report the
GPU hang, where upon we reconstruct a fresh context for the next batch.
---
src/gallium/drivers/iris/iris_batch.c | 92 ++---
src/gallium/drivers/iris/iris_batch.h | 13
src/gallium/drivers/iris/iris_bufmgr.c | 25 +++
src/gallium/drivers/iris/iris_context.c | 24 +--
src/gallium/drivers/iris/iris_context.h | 12 ++--
5 files changed, 125 insertions(+), 41 deletions(-)
diff --git a/src/gallium/drivers/iris/iris_batch.c
b/src/gallium/drivers/iris/iris_batch.c
index 40bcd939795..2edca3d558f 100644
--- a/src/gallium/drivers/iris/iris_batch.c
+++ b/src/gallium/drivers/iris/iris_batch.c
@@ -163,6 +163,7 @@ iris_init_batch(struct iris_batch *batch,
struct iris_screen *screen,
struct iris_vtable *vtbl,
struct pipe_debug_callback *dbg,
+iris_init_context_fn init_context,
struct iris_batch *all_batches,
uint32_t hw_id,
enum iris_batch_name name)
@@ -171,6 +172,7 @@ iris_init_batch(struct iris_batch *batch,
batch->vtbl = vtbl;
batch->dbg = dbg;
batch->name = name;
+ batch->init_context = init_context;
batch->hw_ctx_id = hw_id;
batch->engine = name;
@@ -212,6 +214,8 @@ iris_init_batch(struct iris_batch *batch,
}
iris_batch_reset(batch);
+
+ batch->init_context(batch->screen, batch, batch->vtbl, batch->dbg);
}
static struct drm_i915_gem_exec_object2 *
@@ -443,6 +447,44 @@ iris_finish_batch(struct iris_batch *batch)
batch->primary_batch_size = iris_batch_bytes_used(batch);
}
+static int
+iris_recreate_context(struct iris_batch *batch)
+{
+ struct drm_i915_gem_context_create_ext_clone clone = {
+ .base = { .name = I915_CONTEXT_CREATE_EXT_CLONE },
+ .clone_id = batch->hw_ctx_id,
+ .flags = ~I915_CONTEXT_CLONE_UNKNOWN,
+ };
+ struct drm_i915_gem_context_create_ext arg = {
+ .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
+ .extensions = (uintptr_t),
+ };
+ if (drm_ioctl(batch->screen->fd,
+ DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT,
+ ))
+ return -EIO;
+
+ uint32_t old_ctx_id = batch->hw_ctx_id;
+
+ batch->hw_ctx_id = arg.ctx_id;
+ batch->init_context(batch->screen, batch, batch->vtbl, batch->dbg);
+
+ for (int b = 0; b < ARRAY_SIZE(batch->other_batches); b++) {
+ struct iris_batch *other = batch->other_batches[b];
+ if (other->hw_ctx_id != old_ctx_id)
+ continue;
+
+ other->hw_ctx_id = arg.ctx_id;
+ other->init_context(other->screen, other, other->vtbl, other->dbg);
+ }
+
+ drm_ioctl(batch->screen->fd,
+ DRM_IOCTL_I915_GEM_CONTEXT_DESTROY,
+ _ctx_id);
+
+ return 0;
+}
+
/**
* Submit the batch to the GPU via execbuffer2.
*/
@@ -483,17 +525,11 @@ submit_batch(struct iris_batch *batch)
(uintptr_t)util_dynarray_begin(>exec_fences);
}
- int ret = drm_ioctl(batch->screen->fd,
- DRM_IOCTL_I915_GEM_EXECBUFFER2,
- );
- if (ret != 0) {
+ int ret = 0;
+ if (drm_ioctl(batch->screen->fd,
+ DRM_IOCTL_I915_GEM_EXECBUFFER2,
+ ))
ret = -errno;
- DBG("execbuf FAILED: errno = %d\n", -ret);
- fprintf(stderr, "execbuf FAILED: errno = %d\n", -ret);
- abort();
- } else {
- DBG("execbuf succeeded\n");
- }
for (int i = 0; i < batch->exec_count; i++) {
struct iris_bo *bo = batch->exec_bos[i];
@@ -561,6 +597,25 @@ _iris_batch_flush(struct iris_batch *batch, const char
*file, int line)
int ret = submit_batch(batch);
+ batch->exec_count = 0;
+ batch->aperture_space = 0;
+
+ struct iris_syncpt *syncpt =
+ ((struct iris_syncpt **) util_dynarray_begin(>syncpts))[0];
+ iris_syncpt_reference(screen, >last_syncpt, syncpt);
+
+ util_dynarray_foreach(>syncpts, struct iris_syncpt *, s)
+ iris_syncpt_reference(screen, s, NULL);
+ util_dynarray_clear(>syncpts);
+
+ util_dynarray_clear(>exec_fences);
+
+ /* Start a new batch buffer. */
+ iris_batch_reset(batch);
+
+ if (ret == -EIO)
+ ret = iris_recreate_context(batch);
+
if (ret >= 0) {
//if (iris->ctx.Const.ResetStrategy == GL_LOSE_CONTEXT_ON_RESET_ARB)
//iris_check_for_reset(ice);
@@ -574,25 +629,10 @@ _iris_batch_flush(struct iris_batch *batch, const char
*file, int line)
const bool color = INTEL_DEBUG & DEBUG_COLOR;
fprintf(stderr, "%siris: Failed to submit batchbuffer: %-80s%s\n",
color ? "\e[1;41m" : "",
[Mesa-dev] [PATCH 1/3] drm-uapi: Pull i915_drm.h changes for context cloning
For use in GPU recovery and pipeline construction.
---
include/drm-uapi/i915_drm.h | 389 +---
1 file changed, 317 insertions(+), 72 deletions(-)
diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index d2792ab3640..59baacd265d 100644
--- a/include/drm-uapi/i915_drm.h
+++ b/include/drm-uapi/i915_drm.h
@@ -62,6 +62,28 @@ extern "C" {
#define I915_ERROR_UEVENT "ERROR"
#define I915_RESET_UEVENT "RESET"
+/*
+ * i915_user_extension: Base class for defining a chain of extensions
+ *
+ * Many interfaces need to grow over time. In most cases we can simply
+ * extend the struct and have userspace pass in more data. Another option,
+ * as demonstrated by Vulkan's approach to providing extensions for forward
+ * and backward compatibility, is to use a list of optional structs to
+ * provide those extra details.
+ *
+ * The key advantage to using an extension chain is that it allows us to
+ * redefine the interface more easily than an ever growing struct of
+ * increasing complexity, and for large parts of that interface to be
+ * entirely optional. The downside is more pointer chasing; chasing across
+ * the boundary with pointers encapsulated inside u64.
+ */
+struct i915_user_extension {
+ __u64 next_extension;
+ __u32 name;
+ __u32 flags; /* All undefined bits must be zero. */
+ __u32 rsvd[4]; /* Reserved for future use; must be zero. */
+};
+
/*
* MOCS indexes used for GPU surfaces, defining the cacheability of the
* surface data and the coherency for this data wrt. CPU vs. GPU accesses.
@@ -99,9 +121,14 @@ enum drm_i915_gem_engine_class {
I915_ENGINE_CLASS_VIDEO = 2,
I915_ENGINE_CLASS_VIDEO_ENHANCE = 3,
+ /* should be kept compact */
+
I915_ENGINE_CLASS_INVALID = -1
};
+#define I915_ENGINE_CLASS_INVALID_NONE -1
+#define I915_ENGINE_CLASS_INVALID_VIRTUAL 0
+
/**
* DOC: perf_events exposed by i915 through /sys/bus/event_sources/drivers/i915
*
@@ -319,6 +346,9 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_PERF_ADD_CONFIG 0x37
#define DRM_I915_PERF_REMOVE_CONFIG0x38
#define DRM_I915_QUERY 0x39
+#define DRM_I915_GEM_VM_CREATE 0x3a
+#define DRM_I915_GEM_VM_DESTROY0x3b
+/* Must be kept compact -- no holes */
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -367,6 +397,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
#define DRM_IOCTL_I915_GEM_WAITDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
+#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create_ext)
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READDRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
@@ -377,6 +408,8 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_PERF_REMOVE_CONFIG, __u64)
#define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_QUERY, struct drm_i915_query)
+#define DRM_IOCTL_I915_GEM_VM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_CREATE, struct drm_i915_gem_vm_control)
+#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -476,6 +509,7 @@ typedef struct drm_i915_irq_wait {
#define I915_SCHEDULER_CAP_ENABLED (1ul << 0)
#define I915_SCHEDULER_CAP_PRIORITY (1ul << 1)
#define I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
+#define I915_SCHEDULER_CAP_SEMAPHORES(1ul << 3)
#define I915_PARAM_HUC_STATUS 42
@@ -559,6 +593,14 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_MMAP_GTT_COHERENT 52
+/*
+ * Query whether DRM_I915_GEM_EXECBUFFER2 supports coordination of parallel
+ * execution through use of explicit fence support.
+ * See I915_EXEC_FENCE_OUT and I915_EXEC_FENCE_SUBMIT.
+ */
+#define
[Mesa-dev] [PATCH 2/3] iris: Create a composite context for both compute and render pipelines
iris currently uses two distinct GEM contexts to have distinct logical
HW contexts for the compute and render pipelines. However, using two
distinct GEM contexts implies that they are distinct timelines, yet as
they are a single GL context that implies they belong to a single
timeline from the client perspective. Currently, fences are occasionally
inserted to order the two timelines. Using 2 GEM contexts, also implies
that we keep 2 ppGTT for identical buffer state. If we can create a
single GEM context, with the right capabilities, we can have a single
VM, a single timeline, but 2 logical HW contexts for the 2 pipelines.
This is allowed through the new context interface that allows VM to be
shared, timelines to be specified, and for the logical contexts to be
constructed as the user desires.
Cc: Joonas Lahtinen
Cc: Kenneth Graunke
---
src/gallium/drivers/iris/iris_batch.c | 16 ++-
src/gallium/drivers/iris/iris_batch.h | 5 +--
src/gallium/drivers/iris/iris_context.c | 56 -
3 files changed, 60 insertions(+), 17 deletions(-)
diff --git a/src/gallium/drivers/iris/iris_batch.c
b/src/gallium/drivers/iris/iris_batch.c
index 556422c38bc..40bcd939795 100644
--- a/src/gallium/drivers/iris/iris_batch.c
+++ b/src/gallium/drivers/iris/iris_batch.c
@@ -164,24 +164,16 @@ iris_init_batch(struct iris_batch *batch,
struct iris_vtable *vtbl,
struct pipe_debug_callback *dbg,
struct iris_batch *all_batches,
-enum iris_batch_name name,
-uint8_t engine,
-int priority)
+uint32_t hw_id,
+enum iris_batch_name name)
{
batch->screen = screen;
batch->vtbl = vtbl;
batch->dbg = dbg;
batch->name = name;
- /* engine should be one of I915_EXEC_RENDER, I915_EXEC_BLT, etc. */
- assert((engine & ~I915_EXEC_RING_MASK) == 0);
- assert(util_bitcount(engine) == 1);
- batch->engine = engine;
-
- batch->hw_ctx_id = iris_create_hw_context(screen->bufmgr);
- assert(batch->hw_ctx_id);
-
- iris_hw_context_set_priority(screen->bufmgr, batch->hw_ctx_id, priority);
+ batch->hw_ctx_id = hw_id;
+ batch->engine = name;
util_dynarray_init(>exec_fences, ralloc_context(NULL));
util_dynarray_init(>syncpts, ralloc_context(NULL));
diff --git a/src/gallium/drivers/iris/iris_batch.h
b/src/gallium/drivers/iris/iris_batch.h
index 2a68103c379..db1a4cbbe11 100644
--- a/src/gallium/drivers/iris/iris_batch.h
+++ b/src/gallium/drivers/iris/iris_batch.h
@@ -131,9 +131,8 @@ void iris_init_batch(struct iris_batch *batch,
struct iris_vtable *vtbl,
struct pipe_debug_callback *dbg,
struct iris_batch *all_batches,
- enum iris_batch_name name,
- uint8_t ring,
- int priority);
+ uint32_t hw_id,
+ enum iris_batch_name name);
void iris_chain_to_new_batch(struct iris_batch *batch);
void iris_batch_free(struct iris_batch *batch);
void iris_batch_maybe_flush(struct iris_batch *batch, unsigned estimate);
diff --git a/src/gallium/drivers/iris/iris_context.c
b/src/gallium/drivers/iris/iris_context.c
index a1d11755a24..aeb608c70bd 100644
--- a/src/gallium/drivers/iris/iris_context.c
+++ b/src/gallium/drivers/iris/iris_context.c
@@ -143,6 +143,57 @@ iris_destroy_context(struct pipe_context *ctx)
unreachable("Unknown hardware generation"); \
}
+static void create_hw_contexts(struct iris_screen *screen,
+ uint32_t *hw_id,
+ int priority)
+{
+#define RCS0 {0, 0}
+ I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 2) = {
+ .class_instance = { RCS0, RCS0 }
+ };
+ struct drm_i915_gem_context_create_ext_setparam p_engines = {
+ .base = {
+ .name = I915_CONTEXT_CREATE_EXT_SETPARAM,
+.next_extension = 0, /* end of chain */
+ },
+ .param = {
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = (uintptr_t),
+ .size = sizeof(engines),
+ },
+ };
+ struct drm_i915_gem_context_create_ext_setparam p_prio = {
+ .base = {
+ .name =I915_CONTEXT_CREATE_EXT_SETPARAM,
+ .next_extension = (uintptr_t)_engines,
+ },
+ .param = {
+ .param = I915_CONTEXT_PARAM_PRIORITY,
+ .value = priority,
+ },
+ };
+ struct drm_i915_gem_context_create_ext arg = {
+ .flags = I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE |
+ I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
+ .extensions = (uintptr_t)_prio,
+ };
+
+ if (drm_ioctl(screen->fd,
+ DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT,
+ ) == 0) {
+ for (int i = 0; i < IRIS_BATCH_COUNT; i++)
+ hw_id[i] = arg.ctx_id;
+ return;
+ }
+
+ /* No fancy new features; create two contexts instead */
+ for (int i = 0; i < IRIS_BATCH_COUNT; i++) {
+
[Mesa-dev] [Bug 110230] "Read the documentation here" link on https://www.mesa3d.org/sourcedocs.html is a 404 error
https://bugs.freedesktop.org/show_bug.cgi?id=110230 Eric Engestrom changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #7 from Eric Engestrom --- The sentence starts with "If you're reading this page from your local copy of Mesa, [...]", which is evidently not true when not reading it from your local copy but from the website instead. -- 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] [PATCH] intel/compiler: Print quad value in hex format
From: Sagar Ghuge Print quad value same as unsigned quad so that we can distinguish in between quater control disassembled values for e.g 1/2/3[Q] and immediate quad value for e.g 1Q. This allows round-tripping through the assembler/disassembler. Signed-off-by: Sagar Ghuge --- src/intel/compiler/brw_disasm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intel/compiler/brw_disasm.c b/src/intel/compiler/brw_disasm.c index efca3e2ce7d..04efa965cef 100644 --- a/src/intel/compiler/brw_disasm.c +++ b/src/intel/compiler/brw_disasm.c @@ -1309,7 +1309,7 @@ imm(FILE *file, const struct gen_device_info *devinfo, enum brw_reg_type type, format(file, "0x%016"PRIx64"UQ", brw_inst_imm_uq(devinfo, inst)); break; case BRW_REGISTER_TYPE_Q: - format(file, "%"PRId64"Q", brw_inst_imm_uq(devinfo, inst)); + format(file, "0x%016"PRIx64"Q", brw_inst_imm_uq(devinfo, inst)); break; case BRW_REGISTER_TYPE_UD: format(file, "0x%08xUD", brw_inst_imm_ud(devinfo, inst)); -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider)
https://bugs.freedesktop.org/show_bug.cgi?id=106151 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #34 from Samuel Pitoiset --- Very nice, thanks for checking! Feel free to re-open if the problem happens again. -- 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 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Bug 77449 depends on bug 106151, which changed state. Bug 106151 Summary: [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider) https://bugs.freedesktop.org/show_bug.cgi?id=106151 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: fix alphaToCoverage when there is no color attachment
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?
It is the latter.
> 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.
>
OK, thanks for the suggestion!
Sam
>
> 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;
> > > const int max_rt = FRAG_RESULT_DATA7 - FRAG_RESULT_DATA0 + 1;
> > > @@ -843,12 +845,28 @@ anv_pipeline_link_fs(const struct
> > brw_compiler
> > > *compiler,
> > >const unsigned rt = var->data.location -
> > FRAG_RESULT_DATA0;
> > >if (rt >= MAX_RTS ||
> > >!(stage->key.wm.color_outputs_valid & (1 << rt))) {
> > > - /* Unused or out-of-bounds, throw it away */
> > > - deleted_output = true;
> > > - var->data.mode = nir_var_function_temp;
> > > - exec_node_remove(>node);
> > > - exec_list_push_tail(>locals, >node);
> > > - continue;
> > > + if (rt == 0 && ms_info && ms_info-
> > >alphaToCoverageEnable &&
> > > + subpass->depth_stencil_attachment &&
> > rt_to_bindings[rt]
> > > == -1) {
> > > +/* Don't throw away the unused output, because we
> > needed
> > > it for
> > > + * calculate correctly the alpha to coverage samples
> > > when there
> > > + * is no color buffer attached at location 0.
> > > + */
> > > +rt_to_bindings[rt] = num_rts;
> > > +/* We need a null render target */
> > > +rt_bindings[rt_to_bindings[rt]] = (struct
> > > anv_pipeline_binding) {
> > > + .set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
> > > + .binding = 0,
> > > + .index = UINT32_MAX,
> > > +};
> > > +num_rts++;
> > > + } else {
> > > +/* Unused or out-of-bounds, throw it away */
> > > +deleted_output = true;
> > > +var->data.mode = nir_var_function_temp;
> > > +exec_node_remove(>node);
> > > +exec_list_push_tail(>locals, >node);
Re: [Mesa-dev] [PATCH 2/2] radv: write availability status vkGetQueryPoolResults() when the data is not available
On Fri, 2019-03-22 at 17:21 +0100, Samuel Pitoiset wrote:
> Does this fix anything known?
>
I am writing CTS tests for VK_EXT_host_query_reset extension and I
found this bug while testing them on RADV.
> Does that rule also apply for CmdCopyQueryPoolResults()? If so, we
> might
> need to fix it (I haven't looked yet).
>
The rule is slightly different on CmdCopyQueryPoolResults():
"Similarly, if VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set and
VK_QUERY_RESULT_WAIT_BIT is not set, the availability is guaranteed to
reflect the most recent use of the query on the same queue, assuming
that the query is not being simultaneously used by other queues. As
with vkGetQueryPoolResults, implementations must guarantee that if they
return a non-zero availability value, then the numerical results are
valid."
So if VK_QUERY_RESULT_WITH_AVAILABILITY_BIT we need to still set the
availability state.
I skimmed the implementation of this function on RADV, it seems it is
missing setting the availability value for all the queries except for
VK_QUERY_TYPE_TIMESTAMP.
Could you take care of this?
> With the comment on patch 1, series is:
>
> Reviewed-by: Samuel Pitoiset
>
OK, thanks! It seems I did a wrong squash of patches on patch 1. I will
fix it and push both patches to master.
Sam
> On 3/22/19 1:03 PM, Samuel Iglesias Gonsálvez wrote:
> > If VK_QUERY_RESULT_WITH_AVAILABILY_BIT is set and
> > VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are both
> > not
> > set, we need return to VK_NOT_READY only and set the availability
> > status field for each query.
> >
> > From Vulkan spec:
> >
> > "If VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are
> > both
> > not set then no result values are written to pData for queries that
> > are
> > in the unavailable state at the time of the call, and
> > vkGetQueryPoolResults returns VK_NOT_READY. However, availability
> > state
> > is still written to pData for those queries if
> > VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set."
> >
> > Signed-off-by: Samuel Iglesias Gonsálvez
> > ---
> > src/amd/vulkan/radv_query.c | 15 +++
> > 1 file changed, 3 insertions(+), 12 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_query.c
> > b/src/amd/vulkan/radv_query.c
> > index 8578680f09d..63a2ab773a8 100644
> > --- a/src/amd/vulkan/radv_query.c
> > +++ b/src/amd/vulkan/radv_query.c
> > @@ -1141,11 +1141,8 @@ VkResult radv_GetQueryPoolResults(
> > available = *(uint64_t *)src !=
> > TIMESTAMP_NOT_READY;
> > }
> >
> > - if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT)) {
> > + if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT))
> > result = VK_NOT_READY;
> > - break;
> > -
> > - }
> >
> > if (flags & VK_QUERY_RESULT_64_BIT) {
> > if (available || (flags &
> > VK_QUERY_RESULT_PARTIAL_BIT))
> > @@ -1178,11 +1175,8 @@ VkResult radv_GetQueryPoolResults(
> > }
> > }
> >
> > - if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT)) {
> > + if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT))
> > result = VK_NOT_READY;
> > - break;
> > -
> > - }
> >
> > if (flags & VK_QUERY_RESULT_64_BIT) {
> > if (available || (flags &
> > VK_QUERY_RESULT_PARTIAL_BIT))
> > @@ -1196,11 +1190,8 @@ VkResult radv_GetQueryPoolResults(
> > break;
> > }
> > case VK_QUERY_TYPE_PIPELINE_STATISTICS: {
> > - if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT)) {
> > + if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT))
> > result = VK_NOT_READY;
> > - break;
> > -
> > - }
> >
> > const uint64_t *start = (uint64_t*)src;
> > const uint64_t *stop = (uint64_t*)(src +
> > pipelinestat_block_size);
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
