similar to: Documentation request for MP warp error 0x10

Hi Robert, Thanks for the quick response! That goes in line with my observations which is that these things happen when using an ATOM/RED instruction. I've checked and rechecked that I'm generating 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

Hi Ilia, On Fri, Oct 02, 2015 at 06:05:21PM -0400, Ilia Mirkin wrote: > Hi Robert, > > Thanks for the quick response! That goes in line with my observations > which is that these things happen when using an ATOM/RED instruction. > I've checked and rechecked that I'm generating ops with identical bits > as what the proprietary driver does, however (and nvdisasm prints

On Fri, Oct 2, 2015 at 6:14 PM, Robert Morell <rmorell at nvidia.com> wrote: > Hi Ilia, > > On Fri, Oct 02, 2015 at 06:05:21PM -0400, Ilia Mirkin wrote: >> Hi Robert, >> >> Thanks for the quick response! That goes in line with my observations >> which is that these things happen when using an ATOM/RED instruction. >> I've checked and rechecked that

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

NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE, which apparently happens when trying to use an atomic operation on local or shared memory (instead of global memory). Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nvkm/engine/gr/gf100.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c

This patchset applies some minor fixes to renouveau.xml and then unifies the nv30 and nv40 register definitions. nv30 and nv40 are very similar and have the same offsets for the registers they share. The major differences are: 1. Texture setup is different due to full NPOT support on nv40 2. More advanced blending/render targets on nv40 3. NV30 has fixed function registers, which NV40 lacks The

Hi, This is my work in documenting EVO. I did some RE to fill missing gaps. Best regards, Maxim Levitsky

NV10TCL defines the vertex buffer registers both as arrays and as individual named registers. This causes duplicate register definitions and the individual registers are not used either by the DDX or by the Mesa driver. Francisco Jerez said to remove them all. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- renouveau.xml | 49

First some data errors I get with both nv20 exa and nv20 dri/mesa. 1. RT_FORMAT LINEAR + X8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x00000105 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x00000105 LINEAR + A8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x00000108 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x00000108 The only value I found in renouveau dump

On Mon, Oct 26, 2015 at 03:28:59PM -0400, Ilia Mirkin wrote: > On Fri, Oct 2, 2015 at 6:14 PM, Robert Morell <rmorell at nvidia.com> wrote: > > Hi Ilia, > > > > On Fri, Oct 02, 2015 at 06:05:21PM -0400, Ilia Mirkin wrote: > >> Hi Robert, > >> > >> Thanks for the quick response! That goes in line with my observations > >> which is that

On Fri, Nov 6, 2015 at 3:59 PM, Robert Morell <rmorell at nvidia.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

Hi, I'm having an issue with subregisters on my target. With a pseudo that writes to a 32 bit reg: %vreg20<def> = toHi16_low0_pseudo %vreg2; reg32:%vreg20 hi16:%vreg2 expands to %vreg2<def> = COPY %a2h; hi16:%vreg2 %vreg43<def> = mov 0, pred:0, pred:%noreg, %ac0<imp-use>, %ac1<imp-use>; lo16:%vreg43 %vreg20<def> =

--- rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++--- 1 file changed, 34 insertions(+), 3 deletions(-) diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml index 500cea9..e006dbe 100644 --- a/rnndb/memory/nvc0_pbfb.xml +++ b/rnndb/memory/nvc0_pbfb.xml @@ -49,23 +49,54 @@ Most bitfields are unknown. </doc> <bitfield high="7"

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

Chris Lattner wrote: > On Thu, 2 Dec 2004, Brent Monroe wrote: > >>I'm trying to add the xadd instruction to the X86 back end. >>xadd r/m32, r32 >>exchanges r/m32 and r32, and loads the sum into r/m32. I'm >>interested in the case where the destination operand is a >>memory location. >> >>I've added the following entry to

On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst <kherbst at redhat.com> wrote: > > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary <linux at zary.sk> wrote: > > > > Hello, > > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: > > [ 0.000000] Linux version 5.9.0-rc8+ (zary at gsql) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian)

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 + >

On Fri, Nov 06, 2015 at 04:15:29PM -0500, Ilia Mirkin wrote: > In order for ATOM.*/RED.* to work, the addresses in question must > *NOT* be inside of the 16MB local/shared windows. So if I'm getting > that error, the address must be inside. Yes, that's my understanding. > If so, this may be a reasonable explanation for what I'm seeing -- Cool, I'm happy it helps.

Thanks Steve, I will try this out. I hadn’t realised that TableGen was restricted to matching instructions with more than one output operand. I’m assuming that this is only a limitation for inferring an instruction from the patterns, because it does seem to manage schedules okay. Curiously, my memory Reg32+Reg16 pattern is very similar to yours (the 16-bit offset is sign-extended though):

Hello, I've been debugging a few different tessellation shader issues with nouveau, but let's start small. I see this issue on my GK208 with high frequency, and I *think* I've seen it once or twice on my GF108, but it's exceedingly rare, if it does happen. I don't have a GK10x to test on, unfortunately, but I assume it'll have the same issue as the GK208. The issue is