Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?

From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
Date: Tue, 15 Dec 2015 15:15:43 +0100	[thread overview]
Message-ID: <5670208F.7070800@redhat.com> (raw)

Hi all,

As part of my compute work I'm trying to get some TGSI compute
code to work. The code from mesa/src/gallium/tests/trivial.c
works.

So now I'm trying to get a "native" tgsi kernel to run via
clover, I'm using Francisco's nbody.c example for this:

https://fedorapeople.org/~jwrdegoede/nbody.c

Which does not work, at first I thought there was an issue
with the setup of the input / output buffers, but that seems to
work fine, and moreover I finally got the smart idea to look
in dmesg, which says:

[ 9920.802435] nouveau 0000:01:00.0: gr: TRAP ch 6 [007f7fa000 nbody[31881]]
[ 9920.802449] nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000000 [] warp 10009 [INVALID_OPCODE]
[ 9920.802456] nouveau 0000:01:00.0: gr: GPC0/TPC1/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 20009 [INVALID_OPCODE]

and repeats that for every "step" in the nobody simulation, this is on a
gk107 card.

So that seems to be the real problem, since the
error says "INVALID_OPCODE", I've put the tgsi code from nbody.c
through "nouveau_compiler -a e4" and then run "nvdisasm -b SM30"
on it, but the output looks ok. There is a 8 byte sequence which does
not get decoded every 64 bytes but AFAIK that is the scheduling info,
so that should be fine.

One thing which does stand out is that this:

   0: ld u32 %r219 c0[0x0000000000000000+0x0] (0)
   1: ld u32 %r222 c0[0x4] (0)
   2: ld u64 { %r225 %r228 } c0[0x8] (0)
   3: ld u32 %r234 c0[0x10] (0)

Gets translated into (nvdisasm output) :

         /*0008*/                   LDC R4, c[0x0][0x0];                           /* 0x1400000003f11c86 */
         /*0010*/                   MOV R2, c[0x0][0x4];                           /* 0x2800400010009de4 */
         /*0018*/                   LDC.64 R0, c[0x0][0x8];                        /* 0x1400000023f01ca6 */
         /*0020*/                   MOV R3, c[0x0][0x10];                          /* 0x280040004000dde4 */

Where I would expect for LDC instructions, could that be the problem ?

If that is not the problem, then hints how to debug this further would be greatly appreciated.

Regards,

Hans
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau