Re: [Mesa-dev] [PATCH] radv: put back VGT_FLUSH at ring init on gfx10
Reviewed-by: Samuel Pitoiset
On 7/18/19 8:14 AM, Dave Airlie wrote:
From: Dave Airlie
I can find no evidence that removing this is a good idea.
Fixes: 9b116173b6a ("radv: do not emit VGT_FLUSH on GFX10")
---
src/amd/vulkan/radv_device.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index b397a9a8aa0..8dd24cb8192 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -2753,10 +2753,8 @@ radv_get_preamble_cs(struct radv_queue *queue,
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cs, EVENT_TYPE(V_028A90_VS_PARTIAL_FLUSH) |
EVENT_INDEX(4));
- if (queue->device->physical_device->rad_info.chip_class < GFX10) {
- radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
- radeon_emit(cs, EVENT_TYPE(V_028A90_VGT_FLUSH)
| EVENT_INDEX(0));
- }
+ radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
+ radeon_emit(cs, EVENT_TYPE(V_028A90_VGT_FLUSH) |
EVENT_INDEX(0));
}
radv_emit_gs_ring_sizes(queue, cs, esgs_ring_bo, esgs_ring_size,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: put back VGT_FLUSH at ring init on gfx10
From: Dave Airlie
I can find no evidence that removing this is a good idea.
Fixes: 9b116173b6a ("radv: do not emit VGT_FLUSH on GFX10")
---
src/amd/vulkan/radv_device.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index b397a9a8aa0..8dd24cb8192 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -2753,10 +2753,8 @@ radv_get_preamble_cs(struct radv_queue *queue,
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cs, EVENT_TYPE(V_028A90_VS_PARTIAL_FLUSH) |
EVENT_INDEX(4));
- if (queue->device->physical_device->rad_info.chip_class
< GFX10) {
- radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
- radeon_emit(cs, EVENT_TYPE(V_028A90_VGT_FLUSH)
| EVENT_INDEX(0));
- }
+ radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
+ radeon_emit(cs, EVENT_TYPE(V_028A90_VGT_FLUSH) |
EVENT_INDEX(0));
}
radv_emit_gs_ring_sizes(queue, cs, esgs_ring_bo, esgs_ring_size,
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: reset the window scissor with no clear state.
From: Dave Airlie
IF we don't have clear state (which gfx10 doesn't currently)
we will fix to reset the scissor. AMDVLK will leave it set
to something else.
Marek also has this fix for radeonsi pending.
---
src/amd/vulkan/si_cmd_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 6fe447ef2e9..0efa169d674 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -202,7 +202,7 @@ si_emit_graphics(struct radv_physical_device
*physical_device,
/* CLEAR_STATE doesn't clear these correctly on certain generations.
* I don't know why. Deduced by trial and error.
*/
- if (physical_device->rad_info.chip_class <= GFX7) {
+ if (physical_device->rad_info.chip_class <= GFX7 ||
!physical_device->has_clear_state) {
radeon_set_context_reg(cs,
R_028B28_VGT_STRMOUT_DRAW_OPAQUE_OFFSET, 0);
radeon_set_context_reg(cs, R_028204_PA_SC_WINDOW_SCISSOR_TL,
S_028204_WINDOW_OFFSET_DISABLE(1));
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: fix crash in shader tracing.
From: Dave Airlie
Enabling tracing, and then having a vmfault, can leads to a segfault
before we print out the traces, as if a meta shader is executing
and we don't have the NIR for it.
Just pass the stage and give back a default.
Fixes: 9b9ccee4d64 ("radv: take LDS into account for compute shader occupancy
stats")
---
src/amd/vulkan/radv_nir_to_llvm.c | 8 ++--
src/amd/vulkan/radv_private.h | 1 +
src/amd/vulkan/radv_shader.c | 2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index 3e18303879e..c08789a4361 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -4244,9 +4244,10 @@ ac_setup_rings(struct radv_shader_context *ctx)
unsigned
radv_nir_get_max_workgroup_size(enum chip_class chip_class,
+ gl_shader_stage stage,
const struct nir_shader *nir)
{
- switch (nir->info.stage) {
+ switch (stage) {
case MESA_SHADER_TESS_CTRL:
return chip_class >= GFX7 ? 128 : 64;
case MESA_SHADER_GEOMETRY:
@@ -4257,6 +4258,8 @@ radv_nir_get_max_workgroup_size(enum chip_class
chip_class,
return 0;
}
+ if (!nir)
+ return chip_class >= GFX9 ? 128 : 64;
unsigned max_workgroup_size = nir->info.cs.local_size[0] *
nir->info.cs.local_size[1] *
nir->info.cs.local_size[2];
@@ -4340,7 +4343,8 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
ac_llvm_compiler *ac_llvm,
for (int i = 0; i < shader_count; ++i) {
ctx.max_workgroup_size = MAX2(ctx.max_workgroup_size,
radv_nir_get_max_workgroup_size(ctx.options->chip_class,
-
shaders[i]));
+
shaders[i]->info.stage,
+
shaders[i]));
}
if (ctx.ac.chip_class >= GFX10) {
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 931d4039397..f1f30887e01 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -2138,6 +2138,7 @@ void radv_compile_nir_shader(struct ac_llvm_compiler
*ac_llvm,
const struct radv_nir_compiler_options *options);
unsigned radv_nir_get_max_workgroup_size(enum chip_class chip_class,
+gl_shader_stage stage,
const struct nir_shader *nir);
/* radv_shader_info.h */
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index bcc050a86cc..8f24a6d72b0 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -1232,7 +1232,7 @@ generate_shader_stats(struct radv_device *device,
lds_increment);
} else if (stage == MESA_SHADER_COMPUTE) {
unsigned max_workgroup_size =
- radv_nir_get_max_workgroup_size(chip_class,
variant->nir);
+ radv_nir_get_max_workgroup_size(chip_class, stage,
variant->nir);
lds_per_wave = (conf->lds_size * lds_increment) /
DIV_ROUND_UP(max_workgroup_size, 64);
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111107] 726a31df705b causes pipeline creation to use up to 5x more memory (which is not freed on pipeline destruction)
https://bugs.freedesktop.org/show_bug.cgi?id=07
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Timothy Arceri ---
Should be fixed by:
commit a20a9d0c5e7e9d4468cfcf58fc5a4e9ad8f90610
Author: Timothy Arceri
Date: Wed Jul 17 14:20:55 2019 +1000
radv: dont store disasm string unless keep_shader_info flag set
This fixes the memory use regression from bug 07.
Fixes: 726a31df705 ("radv: Add the concept of radv shader binaries.")
Reviewed-by: Bas Nieuwenhuizen
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=07
--
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 4/4] radv/gfx10: do not always execute a barrier before the second shader
On Wed, Jul 17, 2019 at 3:44 PM Samuel Pitoiset
wrote:
>
> With NGG, empty waves may still be required to export data.
>
> This fixes dEQP-VK.ycbcr.format.*_unorm.geometry_*.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_nir_to_llvm.c | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index 3e18303879e..7e623414adc 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -4448,8 +4448,37 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
> ac_llvm_compiler *ac_llvm,
> declare_esgs_ring(&ctx);
> }
>
> - if (i)
> + bool nested_barrier = false;
> +
> + if (i) {
> + if (shaders[i]->info.stage == MESA_SHADER_GEOMETRY &&
> + ctx.options->key.vs_common_out.as_ngg) {
> + nested_barrier = false;
> + } else {
> + nested_barrier = true;
> + }
> + }
We can simplify this to
nested_barrier = i && (shaders[i]->info.stage != MESA_SHADER_GEOMETRY
|| !ctx.options->key.vs_common_out.as_ngg);
Otherwise r-b, I'm just surprised an s_barrier is okay.
> +
> + if (nested_barrier) {
> + /* Execute a barrier before the second shader in
> +* a merged shader.
> +*
> +* Execute the barrier inside the conditional block,
> +* so that empty waves can jump directly to s_endpgm,
> +* which will also signal the barrier.
> +*
> +* This is possible in gfx9, because an empty wave
> +* for the second shader does not participate in
> +* the epilogue. With NGG, empty waves may still
> +* be required to export data (e.g. GS output
> vertices),
> +* so we cannot let them exit early.
> +*
> +* If the shader is TCS and the TCS epilog is present
> +* and contains a barrier, it will wait there and then
> +* reach s_endpgm.
> + */
> ac_emit_barrier(&ctx.ac, ctx.stage);
> + }
>
> nir_foreach_variable(variable, &shaders[i]->outputs)
> scan_shader_output_decl(&ctx, variable, shaders[i],
> shaders[i]->info.stage);
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] radv/gfx10: set BREAK_WAVE_AT_EOI if TES or GS enable the primitive ID
On Wed, Jul 17, 2019 at 3:44 PM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index de933937f03..8b6e62a75f5 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -3452,6 +3452,14 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf
> *ctx_cs,
> bool break_wave_at_eoi = false;
> unsigned nparams;
>
> + if (es_type == MESA_SHADER_TESS_EVAL) {
> + struct radv_shader_variant *gs =
> + pipeline->shaders[MESA_SHADER_GEOMETRY];
> +
> + if (es_enable_prim_id || (gs && gs->info.info.uses_prim_id))
> + break_wave_at_eoi = true;
> + }
> +
r-b
> nparams = MAX2(outinfo->param_exports, 1);
> radeon_set_context_reg(ctx_cs, R_0286C4_SPI_VS_OUT_CONFIG,
>S_0286C4_VS_EXPORT_COUNT(nparams - 1) |
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radv: move emitting VGT_GS_MODE into the HW VS path
On Thu, Jul 18, 2019 at 2:05 AM Bas Nieuwenhuizen
wrote:
>
> On Wed, Jul 17, 2019 at 3:44 PM Samuel Pitoiset
> wrote:
> >
> > It's useless for NGG anyways.
> >
> > Signed-off-by: Samuel Pitoiset
> > ---
> > src/amd/vulkan/radv_pipeline.c | 43 ++
> > 1 file changed, 33 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> > index fdeb31c453e..686fd371f0f 100644
> > --- a/src/amd/vulkan/radv_pipeline.c
> > +++ b/src/amd/vulkan/radv_pipeline.c
> > @@ -3272,27 +3272,18 @@ radv_pipeline_generate_vgt_gs_mode(struct
> > radeon_cmdbuf *ctx_cs,
>
> Can you rename the function?
Actually now that I see your later patches, how about we keep this
function, return immediately if ngg, and then move the primitive id
stuff for ngg to ngg?
>
>
> > pipeline->shaders[MESA_SHADER_TESS_EVAL] :
> > pipeline->shaders[MESA_SHADER_VERTEX];
> > unsigned vgt_primitiveid_en = 0;
> > - uint32_t vgt_gs_mode = 0;
> >
> > - if (radv_pipeline_has_gs(pipeline)) {
> > - const struct radv_shader_variant *gs =
> > - pipeline->shaders[MESA_SHADER_GEOMETRY];
> > -
> > - vgt_gs_mode = ac_vgt_gs_mode(gs->info.gs.vertices_out,
> > -
> > pipeline->device->physical_device->rad_info.chip_class);
> > - } else if (radv_pipeline_has_ngg(pipeline)) {
> > + if (radv_pipeline_has_ngg(pipeline)) {
> > bool enable_prim_id =
> > outinfo->export_prim_id ||
> > vs->info.info.uses_prim_id;
> >
> > vgt_primitiveid_en |=
> > S_028A84_PRIMITIVEID_EN(enable_prim_id) |
> >
> > S_028A84_NGG_DISABLE_PROVOK_REUSE(enable_prim_id);
> > } else if (outinfo->export_prim_id || vs->info.info.uses_prim_id) {
> > - vgt_gs_mode = S_028A40_MODE(V_028A40_GS_SCENARIO_A);
> > vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(1);
> > }
> >
> > radeon_set_context_reg(ctx_cs, R_028A84_VGT_PRIMITIVEID_EN,
> > vgt_primitiveid_en);
> > - radeon_set_context_reg(ctx_cs, R_028A40_VGT_GS_MODE, vgt_gs_mode);
> > }
> >
> > static void
> > @@ -3370,6 +3361,38 @@ radv_pipeline_generate_hw_vs(struct radeon_cmdbuf
> > *ctx_cs,
> >cull_dist_mask << 8 |
> >clip_dist_mask);
> >
> > + /* We always write VGT_GS_MODE in the VS state, because every switch
> > +* between different shader pipelines involving a different GS or
> > no GS
> > +* at all involves a switch of the VS (different GS use different
> > copy
> > +* shaders). On the other hand, when the API switches from a GS to
> > no
> > +* GS and then back to the same GS used originally, the GS state is
> > not
> > +* sent again.
> > +*/
> > + unsigned vgt_gs_mode;
> > + if (!radv_pipeline_has_gs(pipeline)) {
> > + const struct radv_vs_output_info *outinfo =
> > + get_vs_output_info(pipeline);
> > + const struct radv_shader_variant *vs =
> > + pipeline->shaders[MESA_SHADER_TESS_EVAL] ?
> > + pipeline->shaders[MESA_SHADER_TESS_EVAL] :
> > + pipeline->shaders[MESA_SHADER_VERTEX];
> > + unsigned mode = V_028A40_GS_OFF;
> > +
> > + /* PrimID needs GS scenario A. */
> > + if (outinfo->export_prim_id || vs->info.info.uses_prim_id)
> > + mode = V_028A40_GS_SCENARIO_A;
> > +
> > + vgt_gs_mode = S_028A40_MODE(mode);
> > + } else {
> > + const struct radv_shader_variant *gs =
> > + pipeline->shaders[MESA_SHADER_GEOMETRY];
> > +
> > + vgt_gs_mode = ac_vgt_gs_mode(gs->info.gs.vertices_out,
> > +
> > pipeline->device->physical_device->rad_info.chip_class);
> > + }
> > +
> > + radeon_set_context_reg(ctx_cs, R_028A40_VGT_GS_MODE, vgt_gs_mode);
> > +
>
> Can you keep this in a separate function (possibly with the name
> radv_pipeline_generate_vgt_gs_mode)?
> > if (pipeline->device->physical_device->rad_info.chip_class <= GFX8)
> > radeon_set_context_reg(ctx_cs, R_028AB4_VGT_REUSE_OFF,
> >outinfo->writes_viewport_index);
> > --
> > 2.22.0
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] radv: move emitting VGT_GS_MODE into the HW VS path
On Wed, Jul 17, 2019 at 3:44 PM Samuel Pitoiset
wrote:
>
> It's useless for NGG anyways.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 43 ++
> 1 file changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index fdeb31c453e..686fd371f0f 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -3272,27 +3272,18 @@ radv_pipeline_generate_vgt_gs_mode(struct
> radeon_cmdbuf *ctx_cs,
Can you rename the function?
> pipeline->shaders[MESA_SHADER_TESS_EVAL] :
> pipeline->shaders[MESA_SHADER_VERTEX];
> unsigned vgt_primitiveid_en = 0;
> - uint32_t vgt_gs_mode = 0;
>
> - if (radv_pipeline_has_gs(pipeline)) {
> - const struct radv_shader_variant *gs =
> - pipeline->shaders[MESA_SHADER_GEOMETRY];
> -
> - vgt_gs_mode = ac_vgt_gs_mode(gs->info.gs.vertices_out,
> -
> pipeline->device->physical_device->rad_info.chip_class);
> - } else if (radv_pipeline_has_ngg(pipeline)) {
> + if (radv_pipeline_has_ngg(pipeline)) {
> bool enable_prim_id =
> outinfo->export_prim_id || vs->info.info.uses_prim_id;
>
> vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(enable_prim_id)
> |
>
> S_028A84_NGG_DISABLE_PROVOK_REUSE(enable_prim_id);
> } else if (outinfo->export_prim_id || vs->info.info.uses_prim_id) {
> - vgt_gs_mode = S_028A40_MODE(V_028A40_GS_SCENARIO_A);
> vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(1);
> }
>
> radeon_set_context_reg(ctx_cs, R_028A84_VGT_PRIMITIVEID_EN,
> vgt_primitiveid_en);
> - radeon_set_context_reg(ctx_cs, R_028A40_VGT_GS_MODE, vgt_gs_mode);
> }
>
> static void
> @@ -3370,6 +3361,38 @@ radv_pipeline_generate_hw_vs(struct radeon_cmdbuf
> *ctx_cs,
>cull_dist_mask << 8 |
>clip_dist_mask);
>
> + /* We always write VGT_GS_MODE in the VS state, because every switch
> +* between different shader pipelines involving a different GS or no
> GS
> +* at all involves a switch of the VS (different GS use different copy
> +* shaders). On the other hand, when the API switches from a GS to no
> +* GS and then back to the same GS used originally, the GS state is
> not
> +* sent again.
> +*/
> + unsigned vgt_gs_mode;
> + if (!radv_pipeline_has_gs(pipeline)) {
> + const struct radv_vs_output_info *outinfo =
> + get_vs_output_info(pipeline);
> + const struct radv_shader_variant *vs =
> + pipeline->shaders[MESA_SHADER_TESS_EVAL] ?
> + pipeline->shaders[MESA_SHADER_TESS_EVAL] :
> + pipeline->shaders[MESA_SHADER_VERTEX];
> + unsigned mode = V_028A40_GS_OFF;
> +
> + /* PrimID needs GS scenario A. */
> + if (outinfo->export_prim_id || vs->info.info.uses_prim_id)
> + mode = V_028A40_GS_SCENARIO_A;
> +
> + vgt_gs_mode = S_028A40_MODE(mode);
> + } else {
> + const struct radv_shader_variant *gs =
> + pipeline->shaders[MESA_SHADER_GEOMETRY];
> +
> + vgt_gs_mode = ac_vgt_gs_mode(gs->info.gs.vertices_out,
> +
> pipeline->device->physical_device->rad_info.chip_class);
> + }
> +
> + radeon_set_context_reg(ctx_cs, R_028A40_VGT_GS_MODE, vgt_gs_mode);
> +
Can you keep this in a separate function (possibly with the name
radv_pipeline_generate_vgt_gs_mode)?
> if (pipeline->device->physical_device->rad_info.chip_class <= GFX8)
> radeon_set_context_reg(ctx_cs, R_028AB4_VGT_REUSE_OFF,
>outinfo->writes_viewport_index);
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: fix VGT_GS_MODE if VS uses the primitive ID
r-b
On Wed, Jul 17, 2019 at 10:54 AM Samuel Pitoiset
wrote:
>
> Found by inspection.
>
> Cc:
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index a3323ae8135..f6cb3611c9d 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -3264,6 +3264,10 @@ radv_pipeline_generate_vgt_gs_mode(struct
> radeon_cmdbuf *ctx_cs,
> struct radv_pipeline *pipeline)
> {
> const struct radv_vs_output_info *outinfo =
> get_vs_output_info(pipeline);
> + const struct radv_shader_variant *vs =
> + pipeline->shaders[MESA_SHADER_TESS_EVAL] ?
> + pipeline->shaders[MESA_SHADER_TESS_EVAL] :
> + pipeline->shaders[MESA_SHADER_VERTEX];
> unsigned vgt_primitiveid_en = 0;
> uint32_t vgt_gs_mode = 0;
>
> @@ -3274,16 +3278,12 @@ radv_pipeline_generate_vgt_gs_mode(struct
> radeon_cmdbuf *ctx_cs,
> vgt_gs_mode = ac_vgt_gs_mode(gs->info.gs.vertices_out,
>
> pipeline->device->physical_device->rad_info.chip_class);
> } else if (radv_pipeline_has_ngg(pipeline)) {
> - const struct radv_shader_variant *vs =
> - pipeline->shaders[MESA_SHADER_TESS_EVAL] ?
> - pipeline->shaders[MESA_SHADER_TESS_EVAL] :
> - pipeline->shaders[MESA_SHADER_VERTEX];
> bool enable_prim_id =
> outinfo->export_prim_id || vs->info.info.uses_prim_id;
>
> vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(enable_prim_id)
> |
>
> S_028A84_NGG_DISABLE_PROVOK_REUSE(enable_prim_id);
> - } else if (outinfo->export_prim_id) {
> + } else if (outinfo->export_prim_id || vs->info.info.uses_prim_id) {
> vgt_gs_mode = S_028A40_MODE(V_028A40_GS_SCENARIO_A);
> vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(1);
> }
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #11927 failed
Build mesa 11927 failed Commit 9689407c54 by Eric Anholt on 7/17/2019 7:56 PM: freedreno/a6xx: Drop the WFI in the program update stateobj.\n\nRob Clark thinks this was likely a workaround for our const buffer\nupdate bugs, and now that it's passing tests, we should be able to\ndrop it.\n\nrenderdoc-traces results:\n\ntraces/android/clashofclans.rdc: +6.1% +/- 1.1%\ntraces/android/candycrush.rdc:+5.2% +/- 1.6%\n\nReviewed-by: Rob Clark Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Set meta data for textures from handle.
On Wed, Jul 17, 2019 at 3:59 PM Lepton Wu wrote:
>
> OK, actually struct winsys_handle is an obscure structure for virgl
> driver so we can't access whandle->stride here...
> So maybe just leave this CL as it is?
That is fair. R-b'ed and pushed.
>
> On Wed, Jul 17, 2019 at 1:12 PM Chia-I Wu wrote:
> >
> > On Wed, Jul 17, 2019 at 12:45 PM Lepton Wu wrote:
> > > metadata->stride[0] is calculated from
> > > util_format_get_stride(pt->format, pt->width0);
> > > So basically you are asking to check if
> > > util_format_get_stride(pt->format, pt->width0) == whandle->stride
> > > Should this be something done by framework?
> > The framework does not know that is how virgl decides the stride for a
> > resource. That is also not the case for most drivers.
> >
> > The framework asks virgl to import a buffer with the specified stride.
> > virgl should either accept it, or reject it if virgl does not want to
> > handle the unexpected stride. Not that I believe that is going to
> > happen, but still...
> >
> > >
> > > On Wed, Jul 17, 2019 at 12:25 PM Chia-I Wu wrote:
> > > >
> > > > On Wed, Jul 17, 2019 at 11:44 AM Lepton Wu wrote:
> > > > >
> > > > > On Wed, Jul 17, 2019 at 11:26 AM Chia-I Wu wrote:
> > > > > >
> > > > > > On Wed, Jul 17, 2019 at 10:14 AM Erik Faye-Lund
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, 2019-07-17 at 10:02 -0700, Lepton Wu wrote:
> > > > > > > > The set of meta data was removed by commit 8083464. It broke
> > > > > > > > lots of
> > > > > > > > dEQP tests when running with pbuffer surface type.
> > > > > > > >
> > > > > > > > Fixes: 80834640137 ("virgl: remove dead code")
> > > > > > > > Signed-off-by: Lepton Wu
> > > > > > > > ---
> > > > > > > > src/gallium/drivers/virgl/virgl_resource.c | 1 +
> > > > > > > > 1 file changed, 1 insertion(+)
> > > > > > > >
> > > > > > > > diff --git a/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > > > b/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > > > index c22a78a4731..909deb774c7 100644
> > > > > > > > --- a/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > > > +++ b/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > > > @@ -515,6 +515,7 @@ static struct pipe_resource
> > > > > > > > *virgl_resource_from_handle(struct pipe_screen *scre
> > > > > > > > res->u.b = *templ;
> > > > > > > > res->u.b.screen = &vs->base;
> > > > > > > > pipe_reference_init(&res->u.b.reference, 1);
> > > > > > > > + virgl_resource_layout(&res->u.b, &res->metadata);
> > > > > > There was a similar MR for this
> > > > > >
> > > > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/965
> > > > > >
> > > > > > Can you add a check to make sure the stride is compatible?
> > > > > I think this kind of check should be in "framework" side instead of
> > > > > inside virgl driver.
> > > > > The check what you are said is basically to check if stride info n
> > > > > whandle is comptabile
> > > > > with value in pipe_resource, I think if we need this check, we should
> > > > > put it in dri2_allocate_textures
> > > > > and dri2_create_image_from_winsys? and that should be another CL?
> > > > The framework does not know the stride of a pipe resource.
> > > >
> > > > > >
> > > > > > if (res->metadata->stride[0] != whandle->stride) reject the
> > > > > > whandle;
> > > > > >
> > > > > > > >
> > > > > > > > res->hw_res = vs->vws->resource_create_from_handle(vs->vws,
> > > > > > > > whandle);
> > > > > > > > if (!res->hw_res) {
> > > > > > >
> > > > > > > Whoops! Good catch, sorry for the mess!
> > > > > > >
> > > > > > > Reviewed-by: Erik Faye-Lund
> > > > > > >
> > > > > > > ___
> > > > > > > mesa-dev mailing list
> > > > > > > mesa-dev@lists.freedesktop.org
> > > > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #11925 failed
Build mesa 11925 failed Commit f1a8967344 by Bas Nieuwenhuizen on 7/17/2019 12:58 AM: radv: Only save the descriptor set if we have one.\n\nAfter reset, if valid does not contain the relevant bit the descriptor\ncan be != NULL but still not be valid.\n\nCC: \nReviewed-by: Dave Airlie Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Set meta data for textures from handle.
OK, actually struct winsys_handle is an obscure structure for virgl
driver so we can't access whandle->stride here...
So maybe just leave this CL as it is?
On Wed, Jul 17, 2019 at 1:12 PM Chia-I Wu wrote:
>
> On Wed, Jul 17, 2019 at 12:45 PM Lepton Wu wrote:
> > metadata->stride[0] is calculated from
> > util_format_get_stride(pt->format, pt->width0);
> > So basically you are asking to check if
> > util_format_get_stride(pt->format, pt->width0) == whandle->stride
> > Should this be something done by framework?
> The framework does not know that is how virgl decides the stride for a
> resource. That is also not the case for most drivers.
>
> The framework asks virgl to import a buffer with the specified stride.
> virgl should either accept it, or reject it if virgl does not want to
> handle the unexpected stride. Not that I believe that is going to
> happen, but still...
>
> >
> > On Wed, Jul 17, 2019 at 12:25 PM Chia-I Wu wrote:
> > >
> > > On Wed, Jul 17, 2019 at 11:44 AM Lepton Wu wrote:
> > > >
> > > > On Wed, Jul 17, 2019 at 11:26 AM Chia-I Wu wrote:
> > > > >
> > > > > On Wed, Jul 17, 2019 at 10:14 AM Erik Faye-Lund
> > > > > wrote:
> > > > > >
> > > > > > On Wed, 2019-07-17 at 10:02 -0700, Lepton Wu wrote:
> > > > > > > The set of meta data was removed by commit 8083464. It broke lots
> > > > > > > of
> > > > > > > dEQP tests when running with pbuffer surface type.
> > > > > > >
> > > > > > > Fixes: 80834640137 ("virgl: remove dead code")
> > > > > > > Signed-off-by: Lepton Wu
> > > > > > > ---
> > > > > > > src/gallium/drivers/virgl/virgl_resource.c | 1 +
> > > > > > > 1 file changed, 1 insertion(+)
> > > > > > >
> > > > > > > diff --git a/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > > b/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > > index c22a78a4731..909deb774c7 100644
> > > > > > > --- a/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > > +++ b/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > > @@ -515,6 +515,7 @@ static struct pipe_resource
> > > > > > > *virgl_resource_from_handle(struct pipe_screen *scre
> > > > > > > res->u.b = *templ;
> > > > > > > res->u.b.screen = &vs->base;
> > > > > > > pipe_reference_init(&res->u.b.reference, 1);
> > > > > > > + virgl_resource_layout(&res->u.b, &res->metadata);
> > > > > There was a similar MR for this
> > > > >
> > > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/965
> > > > >
> > > > > Can you add a check to make sure the stride is compatible?
> > > > I think this kind of check should be in "framework" side instead of
> > > > inside virgl driver.
> > > > The check what you are said is basically to check if stride info n
> > > > whandle is comptabile
> > > > with value in pipe_resource, I think if we need this check, we should
> > > > put it in dri2_allocate_textures
> > > > and dri2_create_image_from_winsys? and that should be another CL?
> > > The framework does not know the stride of a pipe resource.
> > >
> > > > >
> > > > > if (res->metadata->stride[0] != whandle->stride) reject the whandle;
> > > > >
> > > > > > >
> > > > > > > res->hw_res = vs->vws->resource_create_from_handle(vs->vws,
> > > > > > > whandle);
> > > > > > > if (!res->hw_res) {
> > > > > >
> > > > > > Whoops! Good catch, sorry for the mess!
> > > > > >
> > > > > > Reviewed-by: Erik Faye-Lund
> > > > > >
> > > > > > ___
> > > > > > mesa-dev mailing list
> > > > > > mesa-dev@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv/gfx10: set the pgm rsrc3/4 regs using index sh reg set
r-b
On Tue, Jul 16, 2019 at 7:28 AM Dave Airlie wrote:
>
> From: Dave Airlie
>
> This is ported from AMDVLK, it's probably not requires unless
> we want to use "real time queues", but it might be nice to just have
> in place.
> ---
> src/amd/common/sid.h | 1 +
> src/amd/vulkan/radv_cs.h | 18 +++
> src/amd/vulkan/si_cmd_buffer.c | 42 +++---
> 3 files changed, 42 insertions(+), 19 deletions(-)
>
> diff --git a/src/amd/common/sid.h b/src/amd/common/sid.h
> index d464b6a110e..0b996e54884 100644
> --- a/src/amd/common/sid.h
> +++ b/src/amd/common/sid.h
> @@ -196,6 +196,7 @@
> #define PKT3_INCREMENT_CE_COUNTER 0x84
> #define PKT3_INCREMENT_DE_COUNTER 0x85
> #define PKT3_WAIT_ON_CE_COUNTER0x86
> +#define PKT3_SET_SH_REG_INDEX 0x9B
> #define PKT3_LOAD_CONTEXT_REG 0x9F /* new for VI */
>
> #define PKT_TYPE_S(x) (((unsigned)(x) & 0x3) << 30)
> diff --git a/src/amd/vulkan/radv_cs.h b/src/amd/vulkan/radv_cs.h
> index eb1aedb0327..d21acba7e8e 100644
> --- a/src/amd/vulkan/radv_cs.h
> +++ b/src/amd/vulkan/radv_cs.h
> @@ -97,6 +97,24 @@ static inline void radeon_set_sh_reg(struct radeon_cmdbuf
> *cs, unsigned reg, uns
> radeon_emit(cs, value);
> }
>
> +static inline void radeon_set_sh_reg_idx(const struct radv_physical_device
> *pdevice,
> +struct radeon_cmdbuf *cs,
> +unsigned reg, unsigned idx,
> +unsigned value)
> +{
> + assert(reg >= SI_SH_REG_OFFSET && reg < SI_SH_REG_END);
> + assert(cs->cdw + 3 <= cs->max_dw);
> + assert(idx);
> +
> + unsigned opcode = PKT3_SET_SH_REG_INDEX;
> + if (pdevice->rad_info.chip_class < GFX10)
> + opcode = PKT3_SET_SH_REG;
> +
> + radeon_emit(cs, PKT3(opcode, 1, 0));
> + radeon_emit(cs, (reg - SI_SH_REG_OFFSET) >> 2 | (idx << 28));
> + radeon_emit(cs, value);
> +}
> +
> static inline void radeon_set_uconfig_reg_seq(struct radeon_cmdbuf *cs,
> unsigned reg, unsigned num)
> {
> assert(reg >= CIK_UCONFIG_REG_OFFSET && reg < CIK_UCONFIG_REG_END);
> diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
> index a832dbd89eb..f789cdd1ce6 100644
> --- a/src/amd/vulkan/si_cmd_buffer.c
> +++ b/src/amd/vulkan/si_cmd_buffer.c
> @@ -262,20 +262,24 @@ si_emit_graphics(struct radv_physical_device
> *physical_device,
> if (physical_device->rad_info.chip_class >= GFX7) {
> if (physical_device->rad_info.chip_class >= GFX10) {
> /* Logical CUs 16 - 31 */
> - radeon_set_sh_reg(cs,
> R_00B404_SPI_SHADER_PGM_RSRC4_HS,
> - S_00B404_CU_EN(0x));
> - radeon_set_sh_reg(cs,
> R_00B204_SPI_SHADER_PGM_RSRC4_GS,
> - S_00B204_CU_EN(0x) |
> -
> S_00B204_SPI_SHADER_LATE_ALLOC_GS_GFX10(0));
> - radeon_set_sh_reg(cs,
> R_00B104_SPI_SHADER_PGM_RSRC4_VS,
> - S_00B104_CU_EN(0x));
> - radeon_set_sh_reg(cs,
> R_00B004_SPI_SHADER_PGM_RSRC4_PS,
> - S_00B004_CU_EN(0x));
> + radeon_set_sh_reg_idx(physical_device,
> + cs,
> R_00B404_SPI_SHADER_PGM_RSRC4_HS,
> + 3, S_00B404_CU_EN(0x));
> + radeon_set_sh_reg_idx(physical_device,
> + cs,
> R_00B204_SPI_SHADER_PGM_RSRC4_GS,
> + 3, S_00B204_CU_EN(0x) |
> +
> S_00B204_SPI_SHADER_LATE_ALLOC_GS_GFX10(0));
> + radeon_set_sh_reg_idx(physical_device,
> + cs,
> R_00B104_SPI_SHADER_PGM_RSRC4_VS,
> + 3, S_00B104_CU_EN(0x));
> + radeon_set_sh_reg_idx(physical_device,
> + cs,
> R_00B004_SPI_SHADER_PGM_RSRC4_PS,
> + 3, S_00B004_CU_EN(0x));
> }
>
> if (physical_device->rad_info.chip_class >= GFX9) {
> - radeon_set_sh_reg(cs,
> R_00B41C_SPI_SHADER_PGM_RSRC3_HS,
> - S_00B41C_CU_EN(0x) |
> S_00B41C_WAVE_LIMIT(0x3F));
> + radeon_set_sh_reg_idx(physical_device, cs,
> R_00B41C_SPI_SHADER_PGM_RSRC3_HS,
> + 3, S_00B41C_CU_EN(0x) |
> S_00B41C_WAVE_LIMIT(0x3F));
> } else {
>
[Mesa-dev] [Bug 111150] [BRW] WRC 5 asserts with gallium nine and iris.
https://bugs.freedesktop.org/show_bug.cgi?id=50 --- Comment #4 from Nanley Chery --- (In reply to Illia Iorin from comment #2) > Yes, tilling is X-tiled. I created a merge request for this issue here: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1371 Please let me know if it fixes the issue. > This flush fixes the assertion failure but it didn't fix the game being > stuck. I’ll try to make a trace. I think we should file another bug for the game being stuck. It's not clear that the two are related. -- 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 111150] [BRW] WRC 5 asserts with gallium nine and iris.
https://bugs.freedesktop.org/show_bug.cgi?id=50 Nanley Chery changed: What|Removed |Added CC||matias.nicolas...@gmail.com --- Comment #3 from Nanley Chery --- *** Bug 62 has been marked as a duplicate of this bug. *** -- 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] virgl: Set meta data for textures from handle.
On Wed, Jul 17, 2019 at 12:45 PM Lepton Wu wrote:
> metadata->stride[0] is calculated from
> util_format_get_stride(pt->format, pt->width0);
> So basically you are asking to check if
> util_format_get_stride(pt->format, pt->width0) == whandle->stride
> Should this be something done by framework?
The framework does not know that is how virgl decides the stride for a
resource. That is also not the case for most drivers.
The framework asks virgl to import a buffer with the specified stride.
virgl should either accept it, or reject it if virgl does not want to
handle the unexpected stride. Not that I believe that is going to
happen, but still...
>
> On Wed, Jul 17, 2019 at 12:25 PM Chia-I Wu wrote:
> >
> > On Wed, Jul 17, 2019 at 11:44 AM Lepton Wu wrote:
> > >
> > > On Wed, Jul 17, 2019 at 11:26 AM Chia-I Wu wrote:
> > > >
> > > > On Wed, Jul 17, 2019 at 10:14 AM Erik Faye-Lund
> > > > wrote:
> > > > >
> > > > > On Wed, 2019-07-17 at 10:02 -0700, Lepton Wu wrote:
> > > > > > The set of meta data was removed by commit 8083464. It broke lots of
> > > > > > dEQP tests when running with pbuffer surface type.
> > > > > >
> > > > > > Fixes: 80834640137 ("virgl: remove dead code")
> > > > > > Signed-off-by: Lepton Wu
> > > > > > ---
> > > > > > src/gallium/drivers/virgl/virgl_resource.c | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > b/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > index c22a78a4731..909deb774c7 100644
> > > > > > --- a/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > +++ b/src/gallium/drivers/virgl/virgl_resource.c
> > > > > > @@ -515,6 +515,7 @@ static struct pipe_resource
> > > > > > *virgl_resource_from_handle(struct pipe_screen *scre
> > > > > > res->u.b = *templ;
> > > > > > res->u.b.screen = &vs->base;
> > > > > > pipe_reference_init(&res->u.b.reference, 1);
> > > > > > + virgl_resource_layout(&res->u.b, &res->metadata);
> > > > There was a similar MR for this
> > > >
> > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/965
> > > >
> > > > Can you add a check to make sure the stride is compatible?
> > > I think this kind of check should be in "framework" side instead of
> > > inside virgl driver.
> > > The check what you are said is basically to check if stride info n
> > > whandle is comptabile
> > > with value in pipe_resource, I think if we need this check, we should
> > > put it in dri2_allocate_textures
> > > and dri2_create_image_from_winsys? and that should be another CL?
> > The framework does not know the stride of a pipe resource.
> >
> > > >
> > > > if (res->metadata->stride[0] != whandle->stride) reject the whandle;
> > > >
> > > > > >
> > > > > > res->hw_res = vs->vws->resource_create_from_handle(vs->vws,
> > > > > > whandle);
> > > > > > if (!res->hw_res) {
> > > > >
> > > > > Whoops! Good catch, sorry for the mess!
> > > > >
> > > > > Reviewed-by: Erik Faye-Lund
> > > > >
> > > > > ___
> > > > > mesa-dev mailing list
> > > > > mesa-dev@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #11921 failed
Build mesa 11921 failed Commit f92290a8d9 by Andreas Bergmeier on 7/14/2019 8:23 PM: broadcom: Move v3d_get_device_info to common\n\nIn common we can use implementation for Vulkan. Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Set meta data for textures from handle.
metadata->stride[0] is calculated from
util_format_get_stride(pt->format, pt->width0);
So basically you are asking to check if
util_format_get_stride(pt->format, pt->width0) == whandle->stride
Should this be something done by framework?
On Wed, Jul 17, 2019 at 12:25 PM Chia-I Wu wrote:
>
> On Wed, Jul 17, 2019 at 11:44 AM Lepton Wu wrote:
> >
> > On Wed, Jul 17, 2019 at 11:26 AM Chia-I Wu wrote:
> > >
> > > On Wed, Jul 17, 2019 at 10:14 AM Erik Faye-Lund
> > > wrote:
> > > >
> > > > On Wed, 2019-07-17 at 10:02 -0700, Lepton Wu wrote:
> > > > > The set of meta data was removed by commit 8083464. It broke lots of
> > > > > dEQP tests when running with pbuffer surface type.
> > > > >
> > > > > Fixes: 80834640137 ("virgl: remove dead code")
> > > > > Signed-off-by: Lepton Wu
> > > > > ---
> > > > > src/gallium/drivers/virgl/virgl_resource.c | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/src/gallium/drivers/virgl/virgl_resource.c
> > > > > b/src/gallium/drivers/virgl/virgl_resource.c
> > > > > index c22a78a4731..909deb774c7 100644
> > > > > --- a/src/gallium/drivers/virgl/virgl_resource.c
> > > > > +++ b/src/gallium/drivers/virgl/virgl_resource.c
> > > > > @@ -515,6 +515,7 @@ static struct pipe_resource
> > > > > *virgl_resource_from_handle(struct pipe_screen *scre
> > > > > res->u.b = *templ;
> > > > > res->u.b.screen = &vs->base;
> > > > > pipe_reference_init(&res->u.b.reference, 1);
> > > > > + virgl_resource_layout(&res->u.b, &res->metadata);
> > > There was a similar MR for this
> > >
> > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/965
> > >
> > > Can you add a check to make sure the stride is compatible?
> > I think this kind of check should be in "framework" side instead of
> > inside virgl driver.
> > The check what you are said is basically to check if stride info n
> > whandle is comptabile
> > with value in pipe_resource, I think if we need this check, we should
> > put it in dri2_allocate_textures
> > and dri2_create_image_from_winsys? and that should be another CL?
> The framework does not know the stride of a pipe resource.
>
> > >
> > > if (res->metadata->stride[0] != whandle->stride) reject the whandle;
> > >
> > > > >
> > > > > res->hw_res = vs->vws->resource_create_from_handle(vs->vws,
> > > > > whandle);
> > > > > if (!res->hw_res) {
> > > >
> > > > Whoops! Good catch, sorry for the mess!
> > > >
> > > > Reviewed-by: Erik Faye-Lund
> > > >
> > > > ___
> > > > mesa-dev mailing list
> > > > mesa-dev@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Set meta data for textures from handle.
On Wed, Jul 17, 2019 at 11:44 AM Lepton Wu wrote:
>
> On Wed, Jul 17, 2019 at 11:26 AM Chia-I Wu wrote:
> >
> > On Wed, Jul 17, 2019 at 10:14 AM Erik Faye-Lund
> > wrote:
> > >
> > > On Wed, 2019-07-17 at 10:02 -0700, Lepton Wu wrote:
> > > > The set of meta data was removed by commit 8083464. It broke lots of
> > > > dEQP tests when running with pbuffer surface type.
> > > >
> > > > Fixes: 80834640137 ("virgl: remove dead code")
> > > > Signed-off-by: Lepton Wu
> > > > ---
> > > > src/gallium/drivers/virgl/virgl_resource.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/src/gallium/drivers/virgl/virgl_resource.c
> > > > b/src/gallium/drivers/virgl/virgl_resource.c
> > > > index c22a78a4731..909deb774c7 100644
> > > > --- a/src/gallium/drivers/virgl/virgl_resource.c
> > > > +++ b/src/gallium/drivers/virgl/virgl_resource.c
> > > > @@ -515,6 +515,7 @@ static struct pipe_resource
> > > > *virgl_resource_from_handle(struct pipe_screen *scre
> > > > res->u.b = *templ;
> > > > res->u.b.screen = &vs->base;
> > > > pipe_reference_init(&res->u.b.reference, 1);
> > > > + virgl_resource_layout(&res->u.b, &res->metadata);
> > There was a similar MR for this
> >
> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/965
> >
> > Can you add a check to make sure the stride is compatible?
> I think this kind of check should be in "framework" side instead of
> inside virgl driver.
> The check what you are said is basically to check if stride info n
> whandle is comptabile
> with value in pipe_resource, I think if we need this check, we should
> put it in dri2_allocate_textures
> and dri2_create_image_from_winsys? and that should be another CL?
The framework does not know the stride of a pipe resource.
> >
> > if (res->metadata->stride[0] != whandle->stride) reject the whandle;
> >
> > > >
> > > > res->hw_res = vs->vws->resource_create_from_handle(vs->vws,
> > > > whandle);
> > > > if (!res->hw_res) {
> > >
> > > Whoops! Good catch, sorry for the mess!
> > >
> > > Reviewed-by: Erik Faye-Lund
> > >
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111020] [RADV][DXVK] GPU lockup on Risk of Rain 2
https://bugs.freedesktop.org/show_bug.cgi?id=111020 MayeulC changed: What|Removed |Added Version|unspecified |19.1 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Set meta data for textures from handle.
On Wed, Jul 17, 2019 at 11:26 AM Chia-I Wu wrote:
>
> On Wed, Jul 17, 2019 at 10:14 AM Erik Faye-Lund
> wrote:
> >
> > On Wed, 2019-07-17 at 10:02 -0700, Lepton Wu wrote:
> > > The set of meta data was removed by commit 8083464. It broke lots of
> > > dEQP tests when running with pbuffer surface type.
> > >
> > > Fixes: 80834640137 ("virgl: remove dead code")
> > > Signed-off-by: Lepton Wu
> > > ---
> > > src/gallium/drivers/virgl/virgl_resource.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/src/gallium/drivers/virgl/virgl_resource.c
> > > b/src/gallium/drivers/virgl/virgl_resource.c
> > > index c22a78a4731..909deb774c7 100644
> > > --- a/src/gallium/drivers/virgl/virgl_resource.c
> > > +++ b/src/gallium/drivers/virgl/virgl_resource.c
> > > @@ -515,6 +515,7 @@ static struct pipe_resource
> > > *virgl_resource_from_handle(struct pipe_screen *scre
> > > res->u.b = *templ;
> > > res->u.b.screen = &vs->base;
> > > pipe_reference_init(&res->u.b.reference, 1);
> > > + virgl_resource_layout(&res->u.b, &res->metadata);
> There was a similar MR for this
>
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/965
>
> Can you add a check to make sure the stride is compatible?
I think this kind of check should be in "framework" side instead of
inside virgl driver.
The check what you are said is basically to check if stride info n
whandle is comptabile
with value in pipe_resource, I think if we need this check, we should
put it in dri2_allocate_textures
and dri2_create_image_from_winsys? and that should be another CL?
>
> if (res->metadata->stride[0] != whandle->stride) reject the whandle;
>
> > >
> > > res->hw_res = vs->vws->resource_create_from_handle(vs->vws,
> > > whandle);
> > > if (!res->hw_res) {
> >
> > Whoops! Good catch, sorry for the mess!
> >
> > Reviewed-by: Erik Faye-Lund
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radv/gfx10: always build the GS copy shader but uses it on-demand
I think Vulkan doesn't need to use legacy GS, because gs_invocations
doesn't multiply the max_out_vertices limit in Vulkan, but it does multiply
it in GL.
Marek
On Tue, Jul 16, 2019 at 10:39 AM Samuel Pitoiset
wrote:
> It should be possible to build it on-demand too but it requires
> more work. On GFX10, the GS copy shader is required when tess
> is enabled with extreme geometry.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 8
> src/amd/vulkan/radv_pipeline.c | 21 ++---
> src/amd/vulkan/radv_private.h| 2 ++
> 3 files changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 6a0db2b67e9..a6d4e0d0e21 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -929,7 +929,7 @@ radv_emit_prefetch_L2(struct radv_cmd_buffer
> *cmd_buffer,
> if (mask & RADV_PREFETCH_GS) {
> radv_emit_shader_prefetch(cmd_buffer,
>
> pipeline->shaders[MESA_SHADER_GEOMETRY]);
> - if (pipeline->gs_copy_shader)
> + if (radv_pipeline_has_gs_copy_shader(pipeline))
> radv_emit_shader_prefetch(cmd_buffer,
> pipeline->gs_copy_shader);
> }
>
> @@ -1124,7 +1124,7 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer
> *cmd_buffer)
>pipeline->shaders[i]->bo);
> }
>
> - if (radv_pipeline_has_gs(pipeline) && pipeline->gs_copy_shader)
> + if (radv_pipeline_has_gs_copy_shader(pipeline))
> radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs,
>pipeline->gs_copy_shader->bo);
>
> @@ -2362,7 +2362,7 @@ radv_emit_streamout_buffers(struct radv_cmd_buffer
> *cmd_buffer, uint64_t va)
> base_reg + loc->sgpr_idx * 4, va,
> false);
> }
>
> - if (pipeline->gs_copy_shader) {
> + if (radv_pipeline_has_gs_copy_shader(pipeline)) {
> loc =
> &pipeline->gs_copy_shader->info.user_sgprs_locs.shader_data[AC_UD_STREAMOUT_BUFFERS];
> if (loc->sgpr_idx != -1) {
> base_reg = R_00B130_SPI_SHADER_USER_DATA_VS_0;
> @@ -4071,7 +4071,7 @@ static void radv_emit_view_index(struct
> radv_cmd_buffer *cmd_buffer, unsigned in
> radeon_set_sh_reg(cmd_buffer->cs, base_reg + loc->sgpr_idx
> * 4, index);
>
> }
> - if (pipeline->gs_copy_shader) {
> + if (radv_pipeline_has_gs_copy_shader(pipeline)) {
> struct radv_userdata_info *loc =
> &pipeline->gs_copy_shader->info.user_sgprs_locs.shader_data[AC_UD_VIEW_INDEX];
> if (loc->sgpr_idx != -1) {
> uint32_t base_reg =
> R_00B130_SPI_SHADER_USER_DATA_VS_0;
> diff --git a/src/amd/vulkan/radv_pipeline.c
> b/src/amd/vulkan/radv_pipeline.c
> index 31495ec078d..d1eede172dc 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -120,6 +120,22 @@ bool radv_pipeline_has_ngg(const struct radv_pipeline
> *pipeline)
> return variant->info.is_ngg;
> }
>
> +bool radv_pipeline_has_gs_copy_shader(const struct radv_pipeline
> *pipeline)
> +{
> + if (!radv_pipeline_has_gs(pipeline))
> + return false;
> +
> + /* The GS copy shader is required if the pipeline has GS on
> GFX6-GFX9.
> +* On GFX10, it might be required in rare cases if it's not
> possible to
> +* enable NGG.
> +*/
> + if (radv_pipeline_has_ngg(pipeline))
> + return false;
> +
> + assert(pipeline->gs_copy_shader);
> + return true;
> +}
> +
> static void
> radv_pipeline_destroy(struct radv_device *device,
>struct radv_pipeline *pipeline,
> @@ -2395,7 +2411,6 @@ void radv_create_shaders(struct radv_pipeline
> *pipeline,
> struct radv_shader_binary *binaries[MESA_SHADER_STAGES] = {NULL};
> struct radv_shader_variant_key keys[MESA_SHADER_STAGES] =
> {0};
> unsigned char hash[20], gs_copy_hash[20];
> - bool use_ngg = device->physical_device->rad_info.chip_class >=
> GFX10;
>
> radv_start_feedback(pipeline_feedback);
>
> @@ -2416,7 +2431,7 @@ void radv_create_shaders(struct radv_pipeline
> *pipeline,
> gs_copy_hash[0] ^= 1;
>
> bool found_in_application_cache = true;
> - if (modules[MESA_SHADER_GEOMETRY] && !use_ngg) {
> + if (modules[MESA_SHADER_GEOMETRY]) {
> struct radv_shader_variant *variants[MESA_SHADER_STAGES] =
> {0};
> radv_create_shader_variants_from_pipeline_cache(device,
> cache, gs_copy_hash, variants,
>
> &found_in_application_cache);
> @@ -2567,7 +2582,7 @@ void radv_create_shaders(struct radv_pipeline
> *pipeline,
> }
> }
>
> - if(modules[MESA_SHADER_GEOMETRY] && !use_ngg) {
> + if(modules[MESA_SHADER_GEOMETRY]) {
>
Re: [Mesa-dev] [PATCH] virgl: Set meta data for textures from handle.
On Wed, Jul 17, 2019 at 10:14 AM Erik Faye-Lund
wrote:
>
> On Wed, 2019-07-17 at 10:02 -0700, Lepton Wu wrote:
> > The set of meta data was removed by commit 8083464. It broke lots of
> > dEQP tests when running with pbuffer surface type.
> >
> > Fixes: 80834640137 ("virgl: remove dead code")
> > Signed-off-by: Lepton Wu
> > ---
> > src/gallium/drivers/virgl/virgl_resource.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_resource.c
> > b/src/gallium/drivers/virgl/virgl_resource.c
> > index c22a78a4731..909deb774c7 100644
> > --- a/src/gallium/drivers/virgl/virgl_resource.c
> > +++ b/src/gallium/drivers/virgl/virgl_resource.c
> > @@ -515,6 +515,7 @@ static struct pipe_resource
> > *virgl_resource_from_handle(struct pipe_screen *scre
> > res->u.b = *templ;
> > res->u.b.screen = &vs->base;
> > pipe_reference_init(&res->u.b.reference, 1);
> > + virgl_resource_layout(&res->u.b, &res->metadata);
There was a similar MR for this
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/965
Can you add a check to make sure the stride is compatible?
if (res->metadata->stride[0] != whandle->stride) reject the whandle;
> >
> > res->hw_res = vs->vws->resource_create_from_handle(vs->vws,
> > whandle);
> > if (!res->hw_res) {
>
> Whoops! Good catch, sorry for the mess!
>
> Reviewed-by: Erik Faye-Lund
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Set meta data for textures from handle.
On Wed, 2019-07-17 at 10:02 -0700, Lepton Wu wrote:
> The set of meta data was removed by commit 8083464. It broke lots of
> dEQP tests when running with pbuffer surface type.
>
> Fixes: 80834640137 ("virgl: remove dead code")
> Signed-off-by: Lepton Wu
> ---
> src/gallium/drivers/virgl/virgl_resource.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/virgl/virgl_resource.c
> b/src/gallium/drivers/virgl/virgl_resource.c
> index c22a78a4731..909deb774c7 100644
> --- a/src/gallium/drivers/virgl/virgl_resource.c
> +++ b/src/gallium/drivers/virgl/virgl_resource.c
> @@ -515,6 +515,7 @@ static struct pipe_resource
> *virgl_resource_from_handle(struct pipe_screen *scre
> res->u.b = *templ;
> res->u.b.screen = &vs->base;
> pipe_reference_init(&res->u.b.reference, 1);
> + virgl_resource_layout(&res->u.b, &res->metadata);
>
> res->hw_res = vs->vws->resource_create_from_handle(vs->vws,
> whandle);
> if (!res->hw_res) {
Whoops! Good catch, sorry for the mess!
Reviewed-by: Erik Faye-Lund
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] virgl: Set meta data for textures from handle.
The set of meta data was removed by commit 8083464. It broke lots of
dEQP tests when running with pbuffer surface type.
Fixes: 80834640137 ("virgl: remove dead code")
Signed-off-by: Lepton Wu
---
src/gallium/drivers/virgl/virgl_resource.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/virgl/virgl_resource.c
b/src/gallium/drivers/virgl/virgl_resource.c
index c22a78a4731..909deb774c7 100644
--- a/src/gallium/drivers/virgl/virgl_resource.c
+++ b/src/gallium/drivers/virgl/virgl_resource.c
@@ -515,6 +515,7 @@ static struct pipe_resource
*virgl_resource_from_handle(struct pipe_screen *scre
res->u.b = *templ;
res->u.b.screen = &vs->base;
pipe_reference_init(&res->u.b.reference, 1);
+ virgl_resource_layout(&res->u.b, &res->metadata);
res->hw_res = vs->vws->resource_create_from_handle(vs->vws, whandle);
if (!res->hw_res) {
--
2.22.0.510.g264f2c817a-goog
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #11917 failed
Build mesa 11917 failed Commit a301250ece by Alyssa Rosenzweig on 7/16/2019 6:36 PM: panfrost: Merge varyings_mem into transient buffers\n\nTheoretically we would like these split since varyings can have\nspecially optimized flags (no map, coherent local). For now, since\nneither of these flags is particularly meaningful right now, merge them\ntogether instead of special casing varyings_mem.\n\nSaves upwards of 64MB of RAM per context.\n\nSigned-off-by: Alyssa Rosenzweig Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111141] [REGRESSION] [BISECTED] [DXVK] 1-bit booleans and Elite Dangerous shader mis-optimization
https://bugs.freedesktop.org/show_bug.cgi?id=41 --- Comment #7 from Denis --- Created attachment 144810 --> https://bugs.freedesktop.org/attachment.cgi?id=144810&action=edit intel_hd620_picture hi, looks like this issue is not actual for intel gpu. Tested on HD 620 (KBL). Picture attached (my settings in game are "low") -- 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 4/4] radv/gfx10: do not always execute a barrier before the second shader
With NGG, empty waves may still be required to export data.
This fixes dEQP-VK.ycbcr.format.*_unorm.geometry_*.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_nir_to_llvm.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index 3e18303879e..7e623414adc 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -4448,8 +4448,37 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct
ac_llvm_compiler *ac_llvm,
declare_esgs_ring(&ctx);
}
- if (i)
+ bool nested_barrier = false;
+
+ if (i) {
+ if (shaders[i]->info.stage == MESA_SHADER_GEOMETRY &&
+ ctx.options->key.vs_common_out.as_ngg) {
+ nested_barrier = false;
+ } else {
+ nested_barrier = true;
+ }
+ }
+
+ if (nested_barrier) {
+ /* Execute a barrier before the second shader in
+* a merged shader.
+*
+* Execute the barrier inside the conditional block,
+* so that empty waves can jump directly to s_endpgm,
+* which will also signal the barrier.
+*
+* This is possible in gfx9, because an empty wave
+* for the second shader does not participate in
+* the epilogue. With NGG, empty waves may still
+* be required to export data (e.g. GS output vertices),
+* so we cannot let them exit early.
+*
+* If the shader is TCS and the TCS epilog is present
+* and contains a barrier, it will wait there and then
+* reach s_endpgm.
+ */
ac_emit_barrier(&ctx.ac, ctx.stage);
+ }
nir_foreach_variable(variable, &shaders[i]->outputs)
scan_shader_output_decl(&ctx, variable, shaders[i],
shaders[i]->info.stage);
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] radv: move emitting VGT_GS_MODE into the HW VS path
It's useless for NGG anyways.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 43 ++
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index fdeb31c453e..686fd371f0f 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -3272,27 +3272,18 @@ radv_pipeline_generate_vgt_gs_mode(struct radeon_cmdbuf
*ctx_cs,
pipeline->shaders[MESA_SHADER_TESS_EVAL] :
pipeline->shaders[MESA_SHADER_VERTEX];
unsigned vgt_primitiveid_en = 0;
- uint32_t vgt_gs_mode = 0;
- if (radv_pipeline_has_gs(pipeline)) {
- const struct radv_shader_variant *gs =
- pipeline->shaders[MESA_SHADER_GEOMETRY];
-
- vgt_gs_mode = ac_vgt_gs_mode(gs->info.gs.vertices_out,
-
pipeline->device->physical_device->rad_info.chip_class);
- } else if (radv_pipeline_has_ngg(pipeline)) {
+ if (radv_pipeline_has_ngg(pipeline)) {
bool enable_prim_id =
outinfo->export_prim_id || vs->info.info.uses_prim_id;
vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(enable_prim_id) |
S_028A84_NGG_DISABLE_PROVOK_REUSE(enable_prim_id);
} else if (outinfo->export_prim_id || vs->info.info.uses_prim_id) {
- vgt_gs_mode = S_028A40_MODE(V_028A40_GS_SCENARIO_A);
vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(1);
}
radeon_set_context_reg(ctx_cs, R_028A84_VGT_PRIMITIVEID_EN,
vgt_primitiveid_en);
- radeon_set_context_reg(ctx_cs, R_028A40_VGT_GS_MODE, vgt_gs_mode);
}
static void
@@ -3370,6 +3361,38 @@ radv_pipeline_generate_hw_vs(struct radeon_cmdbuf
*ctx_cs,
cull_dist_mask << 8 |
clip_dist_mask);
+ /* We always write VGT_GS_MODE in the VS state, because every switch
+* between different shader pipelines involving a different GS or no GS
+* at all involves a switch of the VS (different GS use different copy
+* shaders). On the other hand, when the API switches from a GS to no
+* GS and then back to the same GS used originally, the GS state is not
+* sent again.
+*/
+ unsigned vgt_gs_mode;
+ if (!radv_pipeline_has_gs(pipeline)) {
+ const struct radv_vs_output_info *outinfo =
+ get_vs_output_info(pipeline);
+ const struct radv_shader_variant *vs =
+ pipeline->shaders[MESA_SHADER_TESS_EVAL] ?
+ pipeline->shaders[MESA_SHADER_TESS_EVAL] :
+ pipeline->shaders[MESA_SHADER_VERTEX];
+ unsigned mode = V_028A40_GS_OFF;
+
+ /* PrimID needs GS scenario A. */
+ if (outinfo->export_prim_id || vs->info.info.uses_prim_id)
+ mode = V_028A40_GS_SCENARIO_A;
+
+ vgt_gs_mode = S_028A40_MODE(mode);
+ } else {
+ const struct radv_shader_variant *gs =
+ pipeline->shaders[MESA_SHADER_GEOMETRY];
+
+ vgt_gs_mode = ac_vgt_gs_mode(gs->info.gs.vertices_out,
+
pipeline->device->physical_device->rad_info.chip_class);
+ }
+
+ radeon_set_context_reg(ctx_cs, R_028A40_VGT_GS_MODE, vgt_gs_mode);
+
if (pipeline->device->physical_device->rad_info.chip_class <= GFX8)
radeon_set_context_reg(ctx_cs, R_028AB4_VGT_REUSE_OFF,
outinfo->writes_viewport_index);
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] radv/gfx10: set BREAK_WAVE_AT_EOI if TES or GS enable the primitive ID
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index de933937f03..8b6e62a75f5 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -3452,6 +3452,14 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf
*ctx_cs,
bool break_wave_at_eoi = false;
unsigned nparams;
+ if (es_type == MESA_SHADER_TESS_EVAL) {
+ struct radv_shader_variant *gs =
+ pipeline->shaders[MESA_SHADER_GEOMETRY];
+
+ if (es_enable_prim_id || (gs && gs->info.info.uses_prim_id))
+ break_wave_at_eoi = true;
+ }
+
nparams = MAX2(outinfo->param_exports, 1);
radeon_set_context_reg(ctx_cs, R_0286C4_SPI_VS_OUT_CONFIG,
S_0286C4_VS_EXPORT_COUNT(nparams - 1) |
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] radv: move emitting VGT_PRIMITIVEID_EN into the HW VS and NGG paths
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 42 --
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 686fd371f0f..de933937f03 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -3262,30 +3262,6 @@ radv_pipeline_generate_multisample_state(struct
radeon_cmdbuf *ctx_cs,
S_02882C_YMAX_BOTTOM_EXCLUSION(exclusion));
}
-static void
-radv_pipeline_generate_vgt_gs_mode(struct radeon_cmdbuf *ctx_cs,
- struct radv_pipeline *pipeline)
-{
- const struct radv_vs_output_info *outinfo =
get_vs_output_info(pipeline);
- const struct radv_shader_variant *vs =
- pipeline->shaders[MESA_SHADER_TESS_EVAL] ?
- pipeline->shaders[MESA_SHADER_TESS_EVAL] :
- pipeline->shaders[MESA_SHADER_VERTEX];
- unsigned vgt_primitiveid_en = 0;
-
- if (radv_pipeline_has_ngg(pipeline)) {
- bool enable_prim_id =
- outinfo->export_prim_id || vs->info.info.uses_prim_id;
-
- vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(enable_prim_id) |
-
S_028A84_NGG_DISABLE_PROVOK_REUSE(enable_prim_id);
- } else if (outinfo->export_prim_id || vs->info.info.uses_prim_id) {
- vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(1);
- }
-
- radeon_set_context_reg(ctx_cs, R_028A84_VGT_PRIMITIVEID_EN,
vgt_primitiveid_en);
-}
-
static void
gfx10_set_ge_pc_alloc(struct radeon_cmdbuf *ctx_cs,
struct radv_pipeline *pipeline,
@@ -3368,7 +3344,7 @@ radv_pipeline_generate_hw_vs(struct radeon_cmdbuf *ctx_cs,
* GS and then back to the same GS used originally, the GS state is not
* sent again.
*/
- unsigned vgt_gs_mode;
+ unsigned vgt_primitiveid_en, vgt_gs_mode;
if (!radv_pipeline_has_gs(pipeline)) {
const struct radv_vs_output_info *outinfo =
get_vs_output_info(pipeline);
@@ -3376,22 +3352,27 @@ radv_pipeline_generate_hw_vs(struct radeon_cmdbuf
*ctx_cs,
pipeline->shaders[MESA_SHADER_TESS_EVAL] ?
pipeline->shaders[MESA_SHADER_TESS_EVAL] :
pipeline->shaders[MESA_SHADER_VERTEX];
+ bool enable_prim_id = outinfo->export_prim_id ||
+ vs->info.info.uses_prim_id;
unsigned mode = V_028A40_GS_OFF;
/* PrimID needs GS scenario A. */
- if (outinfo->export_prim_id || vs->info.info.uses_prim_id)
+ if (enable_prim_id)
mode = V_028A40_GS_SCENARIO_A;
vgt_gs_mode = S_028A40_MODE(mode);
+ vgt_primitiveid_en = enable_prim_id;
} else {
const struct radv_shader_variant *gs =
pipeline->shaders[MESA_SHADER_GEOMETRY];
vgt_gs_mode = ac_vgt_gs_mode(gs->info.gs.vertices_out,
pipeline->device->physical_device->rad_info.chip_class);
+ vgt_primitiveid_en = 0;
}
radeon_set_context_reg(ctx_cs, R_028A40_VGT_GS_MODE, vgt_gs_mode);
+ radeon_set_context_reg(ctx_cs, R_028A84_VGT_PRIMITIVEID_EN,
vgt_primitiveid_en);
if (pipeline->device->physical_device->rad_info.chip_class <= GFX8)
radeon_set_context_reg(ctx_cs, R_028AB4_VGT_REUSE_OFF,
@@ -3448,6 +3429,8 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf
*ctx_cs,
uint64_t va = radv_buffer_get_va(shader->bo) + shader->bo_offset;
gl_shader_stage es_type =
radv_pipeline_has_tess(pipeline) ? MESA_SHADER_TESS_EVAL :
MESA_SHADER_VERTEX;
+ struct radv_shader_variant *es =
+ es_type == MESA_SHADER_TESS_EVAL ?
pipeline->shaders[MESA_SHADER_TESS_EVAL] :
pipeline->shaders[MESA_SHADER_VERTEX];
radeon_set_sh_reg_seq(cs, R_00B320_SPI_SHADER_PGM_LO_ES, 2);
radeon_emit(cs, va >> 8);
@@ -3464,6 +3447,8 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf
*ctx_cs,
bool misc_vec_ena = outinfo->writes_pointsize ||
outinfo->writes_layer ||
outinfo->writes_viewport_index;
+ bool es_enable_prim_id = outinfo->export_prim_id ||
+(es && es->info.info.uses_prim_id);
bool break_wave_at_eoi = false;
unsigned nparams;
@@ -3502,6 +3487,10 @@ radv_pipeline_generate_hw_ngg(struct radeon_cmdbuf
*ctx_cs,
cull_dist_mask << 8 |
clip_dist_mask);
+ radeon_set_context_reg(ctx_cs, R_028A84_VGT_PRIMITIVEID_EN,
+ S_028A84_PRIMITIVEID_EN(es_enable_prim_id) |
+
S_028A84_NGG_DIS
[Mesa-dev] [Bug 111150] [BRW] WRC 5 asserts with gallium nine and iris.
https://bugs.freedesktop.org/show_bug.cgi?id=50 --- Comment #2 from Illia Iorin --- Yes, tilling is X-tiled. This flush fixes the assertion failure but it didn't fix the game being stuck. I’ll try to make a trace. -- 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] radv: fix VGT_GS_MODE if VS uses the primitive ID
Found by inspection.
Cc:
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index a3323ae8135..f6cb3611c9d 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -3264,6 +3264,10 @@ radv_pipeline_generate_vgt_gs_mode(struct radeon_cmdbuf
*ctx_cs,
struct radv_pipeline *pipeline)
{
const struct radv_vs_output_info *outinfo =
get_vs_output_info(pipeline);
+ const struct radv_shader_variant *vs =
+ pipeline->shaders[MESA_SHADER_TESS_EVAL] ?
+ pipeline->shaders[MESA_SHADER_TESS_EVAL] :
+ pipeline->shaders[MESA_SHADER_VERTEX];
unsigned vgt_primitiveid_en = 0;
uint32_t vgt_gs_mode = 0;
@@ -3274,16 +3278,12 @@ radv_pipeline_generate_vgt_gs_mode(struct radeon_cmdbuf
*ctx_cs,
vgt_gs_mode = ac_vgt_gs_mode(gs->info.gs.vertices_out,
pipeline->device->physical_device->rad_info.chip_class);
} else if (radv_pipeline_has_ngg(pipeline)) {
- const struct radv_shader_variant *vs =
- pipeline->shaders[MESA_SHADER_TESS_EVAL] ?
- pipeline->shaders[MESA_SHADER_TESS_EVAL] :
- pipeline->shaders[MESA_SHADER_VERTEX];
bool enable_prim_id =
outinfo->export_prim_id || vs->info.info.uses_prim_id;
vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(enable_prim_id) |
S_028A84_NGG_DISABLE_PROVOK_REUSE(enable_prim_id);
- } else if (outinfo->export_prim_id) {
+ } else if (outinfo->export_prim_id || vs->info.info.uses_prim_id) {
vgt_gs_mode = S_028A40_MODE(V_028A40_GS_SCENARIO_A);
vgt_primitiveid_en |= S_028A84_PRIMITIVEID_EN(1);
}
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: fix gathering clip/cull distance masks for GS
On 7/17/19 10:25 AM, Juan A. Suarez Romero wrote:
On Tue, 2019-07-16 at 08:37 +0200, Samuel Pitoiset wrote:
For NGG, the driver relies on the VS outinfo struct.
This fixes
dEQP-VK.clipping.user_defined.clip_*_vert_tess_geom_*
Should this be included in 19.1 stable branch?
No, it's GFX10 specific.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_nir_to_llvm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index 76d784b3374..b890ce56f16 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -2407,6 +2407,11 @@ scan_shader_output_decl(struct radv_shader_context *ctx,
ctx->shader_info->tes.outinfo.cull_dist_mask = (1
<< shader->info.cull_distance_array_size) - 1;
ctx->shader_info->tes.outinfo.cull_dist_mask <<=
shader->info.clip_distance_array_size;
}
+ if (stage == MESA_SHADER_GEOMETRY) {
+ ctx->shader_info->vs.outinfo.clip_dist_mask = (1
<< shader->info.clip_distance_array_size) - 1;
+ ctx->shader_info->vs.outinfo.cull_dist_mask = (1
<< shader->info.cull_distance_array_size) - 1;
+ ctx->shader_info->vs.outinfo.cull_dist_mask <<=
shader->info.clip_distance_array_size;
+ }
}
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: fix gathering clip/cull distance masks for GS
On Tue, 2019-07-16 at 08:37 +0200, Samuel Pitoiset wrote:
> For NGG, the driver relies on the VS outinfo struct.
>
> This fixes
> dEQP-VK.clipping.user_defined.clip_*_vert_tess_geom_*
>
Should this be included in 19.1 stable branch?
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_nir_to_llvm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index 76d784b3374..b890ce56f16 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -2407,6 +2407,11 @@ scan_shader_output_decl(struct radv_shader_context
> *ctx,
> ctx->shader_info->tes.outinfo.cull_dist_mask =
> (1 << shader->info.cull_distance_array_size) - 1;
> ctx->shader_info->tes.outinfo.cull_dist_mask
> <<= shader->info.clip_distance_array_size;
> }
> + if (stage == MESA_SHADER_GEOMETRY) {
> + ctx->shader_info->vs.outinfo.clip_dist_mask =
> (1 << shader->info.clip_distance_array_size) - 1;
> + ctx->shader_info->vs.outinfo.cull_dist_mask =
> (1 << shader->info.cull_distance_array_size) - 1;
> + ctx->shader_info->vs.outinfo.cull_dist_mask <<=
> shader->info.clip_distance_array_size;
> + }
> }
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111151] vkGetRandROutputDisplayEXT returns VK_SUCCESS on failure
https://bugs.freedesktop.org/show_bug.cgi?id=51 Lionel Landwerlin changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #1 from Lionel Landwerlin --- There is an MR opened about this : https://gitlab.freedesktop.org/mesa/mesa/merge_requests/385 Unfortunately we need a spec update first as there is no error code defined for this function to fail. There is an issue opened about this on the khronos group gitlab. I think the behavior of the driver follows the spec, so I will close. When the spec is updated we'll update the driver. -- 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
