Experimental support for injection

[JayFoxRox]

Can be ran using reset && clear && XBOX=192.168.177.3 ./nv2a-trace.py clear.json and should give something like:

TODO:

• Recover pgraph state
• Cleanup
• Wait for trace enhancements so this is useful
• Add support for injecting RAM data (such as vertice or texture pixels)

[JayFoxRox]

Doesn't work right now, because code won't run until we step through (so debug.html would not contain any results). We could set dma_put_addr to the original v_dma_get_addr to run this quickly and address this.

[JayFoxRox]

Separate change (more code follows)

[JayFoxRox]

Separate change. Not too happy about this tbh.

[JayFoxRox]

Should be able to use int(..., base=0) (or provide it implicitly)

[JayFoxRox]

  {
    "method": "CLEAR_BUFFERS", 
    "data": [{
      "COLOR_A": true,
      "COLOR_R": true,
      "COLOR_G": true,
      "COLOR_B": true
    }]
  }

[JayFoxRox]

  {
    "method": "CLEAR_BUFFERS", 
    "data": [0]
  }

[JayFoxRox]

  {
    "method": "CLEAR_VALUE",
    "data": ["0x00FF00FF"]
  }

[JayFoxRox]

For the record:

[fox@x230 rnn]$ RNN_PATH=`pwd`/../rnndb:`pwd`/../rnndb-generated/ ./lookup.py -d SUBCHAN -v obj-class NV20_3D 0x1d94 0xF0 2>/dev/null
CLEAR_BUFFERS => { COLOR_A | COLOR_B | COLOR_G | COLOR_R }

In https://github.com/envytools/envytools/tree/master/rnn

---

Integrating rnn looks kind of painful.

• Distribution is not solved and I had trouble getting it to work properly as there's also a lack of documentation
• For tracing it apppears mostly fine but it doesn't handle arrays well (which is odd).
• For injecting I'd probably need to put in a lot of work. It doesn't seem to handle value parsing on its own.

I'll probably reach out to the envytools folks to improve distribution of rnn / rnndb (why no setuptools?); also the quality of rnndb for NV2A (and NV20_3D - NV25_3D) is not where it should be. Something I'd also attempt to address in hopes we adopt envytool names for all Xbox tools later.

[JayFoxRox]

@file
@file+offset
@file+offset(count*size:stride)

Could be a useful format for binary data?

However, with interleaved vertex attributes, this would cause like 16x memory usage which will be a problem.
We"d need a clever mechanism to find all "good" overlap then.

For testing it might be safer to assume that all data is rather tightly packed (meaning we don"t need a full 64MB RAM dump).

We could also go more invasive and re-structure resources on a draw call. However, I"d like to avoid that if possible.

---

This must be handled kind of special:

{
  "load": {

    "file data": {
      "size": 16, # Implicit len(data); only really matters when stride isn't 0?
      "stride": 100, # Implicit 0

      # Load from file
      "data": "vertex_attrib_0.bin"
    },

    "direct data": {
      # Direct data
      "data": [
        ["0x00000000", 1.0, 2.0, 3.0],
        ["0x00000000", 4.0, 5.0, 6.0],
      ]
    }

  }
},
{
  "unload": [ "unique identifier" ]
}

[JayFoxRox]

We also have to solve the problem where the injection might start or stop in a bad state which might affect much more than pgraph.

Say stopping between BEGIN and END: we can detect this probably, but we probably can't change the state without injecting additional comments because the GPU probably has a lot of internal state.