All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
Cc: "nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
Date: Wed, 16 Dec 2015 18:06:52 +0100	[thread overview]
Message-ID: <56719A2C.4000501@redhat.com> (raw)
In-Reply-To: <CAKb7Uvh0Cj6rrn_Y1X2sTnODxvxuzp=+s5tVs0+xAjZuk3b6CQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi,

On 15-12-15 20:04, Ilia Mirkin wrote:
> Also, where's the exit op? Perhaps what's happening is that you don't
> have an exit and it just goes off executing into the ether?

Sorry I only included a small bit of the program in my original mail
because I found the use of "MOV" instructions to load constants
suspicious, is that normal ?

I've put a log with NV50_PROG_DEBUG=1 output here:

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

nvdisasm -b SM30 for the generated binary code is here:

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

There are already .tgsi, .hex and .bin files there if
you find those easier to use then the
NV50_PROG_DEBUG=1 output.


>
> On Tue, Dec 15, 2015 at 12:00 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>> A few things that stand out:
>>
>>    0: ld u32 %r219 c0[0x0000000000000000+0x0] (0)
>>
>> wtf is that 0x0000000000000 thing doing there? Was it a %rX which got
>> constant-folded into 0? That indirectness should have then been
>> removed... that said, the final encoding looks fine.

I don't know, maybe there is a hint in the log file?

Regards,

Hans


>>
>> I believe that kepler has this launch descriptor thing too... is that
>> being set correctly? Please generate a mmt trace, and we can see if
>> anything stands out compared to a blob trace that also does compute.
>>
>> Cheers,
>>
>>    -ilia
>>
>> On Tue, Dec 15, 2015 at 9:15 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> 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
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

  parent reply	other threads:[~2015-12-16 17:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-15 14:15 Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ? Hans de Goede
     [not found] ` <5670208F.7070800-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-12-15 17:00   ` Ilia Mirkin
     [not found]     ` <CAKb7Uvg-Gs1WtbucN2Qx4YENf8zNQ_OA4KhCarTu_4b6PE_N0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-15 19:04       ` Ilia Mirkin
     [not found]         ` <CAKb7Uvh0Cj6rrn_Y1X2sTnODxvxuzp=+s5tVs0+xAjZuk3b6CQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-16 17:06           ` Hans de Goede [this message]
     [not found]             ` <56719A2C.4000501-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-12-16 17:24               ` Ilia Mirkin
     [not found]                 ` <CAKb7UvhQRs6QrCEi1uEP9JhMbE91g=n4xwq-ufW-NMgy=7pMgw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-16 17:34                   ` Ilia Mirkin
     [not found]                     ` <CAKb7UvhsFDN8vnnYr3KGx4hRpDaiWXBfTXgJbOJZyWcdoMuYcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-18 12:57                       ` Hans de Goede
2015-12-18 12:55                   ` Hans de Goede
     [not found]                     ` <56740253.5030900-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-12-18 20:46                       ` Ilia Mirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56719A2C.4000501@redhat.com \
    --to=hdegoede-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.