[Mesa-dev] [PATCH] r600: shader CF_OP_VTX also doesn't use the EOP bit.
Gert Wollny
gw.fossdev at gmail.com
Thu Nov 16 22:00:35 UTC 2017
Am Mittwoch, den 15.11.2017, 11:28 +1000 schrieb Dave Airlie:
> On 15 November 2017 at 04:50, Gert Wollny <gw.fossdev at gmail.com>
> wrote:
> > Although the EOP bit is documented for the vertex fetch clause, it
> > is not
> > properly interpreted. As a result the piglit
> > spec/arb_tessellation_shader/execution/trivial-tess-gs_no-gs-
> > inputs creates a TESS_EVAL shader that does not have an EOP clause,
> > which might result in a GPU lockup.
> >
> > This patch forces an additional CF_OP_NOP group like it is already
> > done for other final CF_OP groups.
>
> Although I think this is probably a good safety thing to add, I've
> sent a patch that should make it unneeded, it would be good if you
> could test it.
Regardless o this, I wonder why with do CF_OP_VTK and CF_OP_TEX not
emit the EOP bit on evergreen? The documentation says it is supported,
and when I apply below path (changed white spaces to fit the mail
size), then I don't see any lock-ups, the sb disassembler reports the
EOP flag, I don't get valgrind errors in sb, and no piglit regressions.
best,
Gert
--- a/src/gallium/drivers/r600/eg_asm.c
+++ b/src/gallium/drivers/r600/eg_asm.c
@@ -71,10 +69,13 @@ int eg_bytecode_cf_build(struct r600_bytecode *bc,
struct r600_bytecode_cf *cf)
} else if (cfop->flags & CF_CLAUSE) {
/* CF_TEX/VTX (CF_ALU already handled above) */
bc->bytecode[id++] = S_SQ_CF_WORD0_ADDR(cf->addr >> 1);
- bc->bytecode[id++] = S_SQ_CF_WORD1_CF_INST(opcode) |
+ bc->bytecode[id] = S_SQ_CF_WORD1_CF_INST(opcode) |
S_SQ_CF_WORD1_BARRIER(1) |
S_SQ_CF_WORD1_VALID_PIXEL_MODE(cf->vpm) |
S_SQ_CF_WORD1_COUNT((cf->ndw / 4) - 1);
+ if (bc->chip_class == EVERGREEN) /* no EOP on cayman */
+ bc->bytecode[id] |=
S_SQ_CF_ALLOC_EXPORT_WORD1_END_OF_PROGRAM(cf->end_of_program);
+ id++;
} else if (cfop->flags & CF_EXP) {
/* EXPORT instructions */
bc->bytecode[id++] =
S_SQ_CF_ALLOC_EXPORT_WORD0_RW_GPR(cf->output.gpr) |
More information about the mesa-dev
mailing list