On Tue, Jul 26, 2016 at 6:53 PM, Samuel Pitoiset <[email protected]> wrote: > The number of outputs patch (limited to 255) has moved in the TCP > header, but blob seems to also set the old position. Also, the high > 8-bits are now located inbetween the min/max parallel output read > address at position 20. > > Signed-off-by: Samuel Pitoiset <[email protected]> > --- > src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c > b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c > index 5fc2753..8ed3e10 100644 > --- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c > +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c > @@ -346,6 +346,15 @@ nvc0_tcp_gen_header(struct nvc0_program *tcp, struct > nv50_ir_prog_info *info) > > nvc0_vtgp_gen_header(tcp, info); > > + if (info->target >= NVISA_GM107_CHIPSET) { > + /* On GM107+, the number of output patch components has moved in the > TCP > + * header, but it seems like blob still also uses the old position. > + * Also, the high 8-bits are located inbetween the min/max parallel > + * field and has to be set after updating the outputs. */ > + tcp->hdr[3] = opcs << 28;
Semantically identical, but I think it'll help out the poor casual reader: tcp->hdr[3] = (opcs & 0x0f) << 28; Otherwise this is Acked-by: Ilia Mirkin <[email protected]> [to reflect the fact that I've done absolutely no verification of your claims about how the hw works] > + tcp->hdr[4] |= (opcs & 0xf0) << 16; > + } > + > nvc0_tp_get_tess_mode(tcp, info); > > return 0; > -- > 2.9.0 > > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
