search for: sm30

...tary driver does, however (and nvdisasm prints identical output). Could you advise what the proper way of indicating that the memory is "global" to the op? I'm sure I'm just missing something simple. If you show me what to look for in SM35 I can probably find it on my own for SM20/SM30/SM50. In case you're interested in looking at the mesa code, It's available on my atomic2 branch at: https://github.com/imirkin/mesa/commits/atomic2 . However I hardly expect you to debug my buggy code :) The SUREDP stuff is about surface RED ops, the existing code uses it but I'm goin...

...t; 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[...

...all 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,...

...asm prints >> identical output). Could you advise what the proper way of indicating >> that the memory is "global" to the op? I'm sure I'm just missing >> something simple. If you show me what to look for in SM35 I can >> probably find it on my own for SM20/SM30/SM50. > > Unfortunately this isn't something I know a lot about, so I'm going to > have do some research and get back to you, hopefully within a few days. Hi Robert, Were you able to find any further information out about this? Happy to provide with any traces or additional detai...

Hello, I've recently come across an error reported by the GPU and would like to know what it means and especially what causes it to be triggered. Any information would be very useful: I'm seeing MP warp error 0x10 (appears in MP register 0x48). This is what we currently have in nouveau: <reg32 offset="0x048" name="TRAP_WARP_ERROR"> <!-- ctx-switched -->

...] 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)...

...wever (and nvdisasm prints > identical output). Could you advise what the proper way of indicating > that the memory is "global" to the op? I'm sure I'm just missing > something simple. If you show me what to look for in SM35 I can > probably find it on my own for SM20/SM30/SM50. Unfortunately this isn't something I know a lot about, so I'm going to have do some research and get back to you, hopefully within a few days. > In case you're interested in looking at the mesa code, It's available > on my atomic2 branch at: > https://github.com/imi...

...he 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 at alum.mit.edu>...

...ginal 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. >> >> >>> >&gt...

...2015 at 06:05:21PM -0400, Ilia Mirkin wrote: > Could you advise what the proper way of indicating > that the memory is "global" to the op? I'm sure I'm just missing > something simple. If you show me what to look for in SM35 I can > probably find it on my own for SM20/SM30/SM50. Sorry again for the delay. Here's what I've been able to find out about the generic thread address space (used by the SMs) and what types of memory it contains. Hopefully this clears things up. Local memory is a per-thread space. Shared memory is a per-CTA space (compute shaders...

...ginal 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. >> >> >>> >&gt...

...0 c07e0074 10009de4 28004000 > 00105c00 30044000 01201c84 14060000 04001c02 10408102 05205c84 14060000 > 720042e7 22e20042 04105c02 10040404 04011c83 68000000 0000dde2 18fe0000 > 00001de2 18000000 0c005de4 28000000 00009de2 18000000 00001de7 80000000 > > which, with "nvdisas -b SM30 -raw" decodes to > > /*0008*/ IPA.PASS R0, a[0x70], RZ; > /*0010*/ IPA.PASS R1, a[0x74], RZ; > /*0018*/ MOV R2, c[0x0][0x4]; > /*0020*/ FFMA R1, R1, c[0x0][0x0], R2; > /*0028*...

...> identical output). Could you advise what the proper way of indicating > >> that the memory is "global" to the op? I'm sure I'm just missing > >> something simple. If you show me what to look for in SM35 I can > >> probably find it on my own for SM20/SM30/SM50. > > > > Unfortunately this isn't something I know a lot about, so I'm going to > > have do some research and get back to you, hopefully within a few days. > > Hi Robert, > > Were you able to find any further information out about this? Happy to > pro...

...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)...

...1PM -0400, Ilia Mirkin wrote: >> Could you advise what the proper way of indicating >> that the memory is "global" to the op? I'm sure I'm just missing >> something simple. If you show me what to look for in SM35 I can >> probably find it on my own for SM20/SM30/SM50. > > Sorry again for the delay. Here's what I've been able to find out about > the generic thread address space (used by the SMs) and what types of > memory it contains. Hopefully this clears things up. > > > Local memory is a per-thread space. > Shared memory...

Hello, I've been trying to add ARB_sample_shading support to nouveau, and am being defeated by the gl_SampleMask tests. Everything else works fine. (And naturally the tests pass with the proprietary driver.) I'm trying to do this for both GT21x, as well as GF100+. In the GT21x case, it seems like the low bit of method 0x1928 needs to be set (as well as the second-to-lowest bit), for

...fff01c00 c07e0070 fff05c00 c07e0074 10009de4 28004000 00105c00 30044000 01201c84 14060000 04001c02 10408102 05205c84 14060000 720042e7 22e20042 04105c02 10040404 04011c83 68000000 0000dde2 18fe0000 00001de2 18000000 0c005de4 28000000 00009de2 18000000 00001de7 80000000 which, with "nvdisas -b SM30 -raw" decodes to /*0008*/ IPA.PASS R0, a[0x70], RZ; /*0010*/ IPA.PASS R1, a[0x74], RZ; /*0018*/ MOV R2, c[0x0][0x4]; /*0020*/ FFMA R1, R1, c[0x0][0x0], R2; /*0028*/ F2I.S32.F32.T...

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- .../drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp index f010767..4a9e48f 100644 ---

...28004000 >> 00105c00 30044000 01201c84 14060000 04001c02 10408102 05205c84 14060000 >> 720042e7 22e20042 04105c02 10040404 04011c83 68000000 0000dde2 18fe0000 >> 00001de2 18000000 0c005de4 28000000 00009de2 18000000 00001de7 80000000 >> >> which, with "nvdisas -b SM30 -raw" decodes to >> >> /*0008*/ IPA.PASS R0, a[0x70], RZ; >> /*0010*/ IPA.PASS R1, a[0x74], RZ; >> /*0018*/ MOV R2, c[0x0][0x4]; >> /*0020*/ FFMA R1, R1, c[0x0][0x0], R2; &...