search for: sm35

GK20A is mostly compatible with GK104, but uses the SM35 ISA. Use the GK110 path when this chip is detected. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 + src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 2 +- src/gallium/drivers/nouveau/codegen/nv50...

GK20A is mostly compatible with GK104, but uses the SM35 ISA. Use the GK110 path when this chip is detected. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 2 +- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 2 +- .../drivers/nouveau/codegen/nv50_ir_target_...

On Tue, May 27, 2014 at 12:59 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: > GK20A is mostly compatible with GK104, but uses the SM35 ISA. Use > the GK110 path when this chip is detected. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 + > src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 2 +- > src/ga...

...ing ops with identical bits as what the proprietary 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...

...happen whenever I try to access global memory on kepler (potentially only atomics, not sure at this point). Knowing precisely what causes the error to get triggered (and esp what we need to do in order not to trigger it) would be most useful. For reference, my shader looks something like this (for SM35): /*0018*/ LDC.64 R0, c[0xf][0x1c0]; /* 0x7ca80780e01ffc02 */ /*0020*/ ATOM.E.ADD R2, [R0], R2; /* 0x68080000011c000a */ /*0028*/ LD.E.CG R0, [R0]; /* 0xcc800000001c0000 */ I know that the proprietary drivers are...

The following 2 patches make it possible to run Mesa programs on GK20A (Tegra K1). GK20A is very similar to GK104, but uses a new (backward-compatible) 3D class as well as the same ISA as GK110 (SM35). Taking these differences into account is sufficient to successfully render simple off-screen buffers. Alexandre Courbot (2): nvc0: add GK20A 3D class nvc0: use SM35 ISA with GK20A src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 + src/gallium/drivers/nouveau/codegen/nv50_i...

...al bits > as what the proprietary 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. 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 >...

...as what the proprietary 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. > > 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 th...

On Fri, Oct 02, 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...

...evaluation shaders (decoded with nvdisasm which you're hopefully more familiar with), along with the shader headers that we generate. FTR, this is how I feed the raw shader opcode bytes into nvdisasm: perl -ane 'foreach (@F) { print pack "I", hex($_) }' > tt; nvdisasm -b SM35 tt (for some reason it doesn't want to read from a pipe or even a fd). http://people.freedesktop.org/~imirkin/tess_shaders_quads.txt My suspicion is that we're doing something wrong with the sched codes. We have an elaborate calculator, but... perhaps not elaborate enough? You can see it...

...which you're hopefully more familiar with), along with >> the shader headers that we generate. >> >> FTR, this is how I feed the raw shader opcode bytes into nvdisasm: >> >> perl -ane 'foreach (@F) { print pack "I", hex($_) }' > tt; nvdisasm -b SM35 tt >> >> (for some reason it doesn't want to read from a pipe or even a fd). >> >> http://people.freedesktop.org/~imirkin/tess_shaders_quads.txt >> >> My suspicion is that we're doing something wrong with the sched codes. >> We have an elaborate cal...

...ns the following (nvc0) code: 1: mov u32 $r2 0x00000000 (8) 2: mov u32 $r3 0x3fe00000 (8) 3: add f64 $r0d $r0d $r2d (8) Into: 1: add f64 $r0d $r0d 0.500000 (8) This has been tested with the 2 double shader tests which I just send to the piglet list. On a gk208 (gk110 / SM35) card, and by checking the output of nouveau_compiler with both nvdisasm and envydis on gf100 / gk104 / gm107. Regards, Hans

...oprietary 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. > > > > 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 f...

...1: mov u32 $r2 0x00000000 (8) > 2: mov u32 $r3 0x3fe00000 (8) > 3: add f64 $r0d $r0d $r2d (8) > > Into: > 1: add f64 $r0d $r0d 0.500000 (8) > > This has been tested with the 2 double shader tests which I just send to > the piglet list. On a gk208 (gk110 / SM35) card, and by checking the output > of nouveau_compiler with both nvdisasm and envydis on gf100 / gk104 / gm107. > > Regards, > > Hans

...idia.com> wrote: > On Fri, Oct 02, 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. > > &gt...

...y testing the problem was introduced by commit abd326e81b06f58797be94bd655ee06b17a34f0c Author: Ilia Mirkin <imirkin at alum.mit.edu> Date: Fri Dec 4 15:21:11 2015 -0500 nv50/ir: propagate indirect loads into instructions This way $r1 = $r0 + 4; c1[$r1] becomes c1[$r0+4]. On SM35: total instructions in shared programs : 6206257 -> 6185058 (-0.34%) total gprs used in shared programs : 911045 -> 910722 (-0.04%) total local used in shared programs : 39072 -> 39072 (0.00%) local gpr inst bytes helped...

On Tue, May 27, 2014 at 12:59 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: > GK20A is mostly compatible with GK104, but features a new 3D > class. Add it to the relevant header and use it when GK20A is > detected. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > src/gallium/drivers/nouveau/nv_object.xml.h | 1 + >