[GS Docs] TEX1 MTBA Info

[TellowKrinkle]

The MTBA flag enables automatic generation of addresses for the mipmap levels 1, 2, and 3, placing them one after another directly after the first texture level (L0) in memory. To use this flag, your texture is supposed to be square (width == height) and have a size greater than or equal to 32.

TBW handling

You can put whatever value you want in TBW0, but MTBA addresses will be as if your TBW0 matched (1 << TW) / 64

Example: 128x128 TBW0=4

Assuming TBP0 is 0, a PSMCT32 128x128 texture with TBW0=4 would cover the following pages (one page is 64x32 pixels):

[P00 P01] P02 P03
[P04 P05] P06 P07
[P08 P09] P10 P11
[P12 P13] P14 P15

On the other hand, MTBA will treat your texture as if it had TBW0=2 for the purposes of address generation, which covers the following pages:

[P00 P01]
[P02 P03]
[P04 P05]
[P06 P07]

Based on this, the first (64x64) mipmap level would occupy pages 8 and 9 (TBP1=256, TBW1=1), overlapping the level 0 texture:

┌──────── Page 8 ─────────┐
│ L1 L1 L1 L1 L1 L1 L1 L1 │
│ L1 L1 L1 L1 L1 L1 L1 L1 │
│ L1 L1 L1 L1 L1 L1 L1 L1 │
│ L1 L1 L1 L1 L1 L1 L1 L1 │
├──────── Page 9 ─────────┤
│ L1 L1 L1 L1 L1 L1 L1 L1 │
│ L1 L1 L1 L1 L1 L1 L1 L1 │
│ L1 L1 L1 L1 L1 L1 L1 L1 │
│ L1 L1 L1 L1 L1 L1 L1 L1 │
└─────────────────────────┘

The second (32x32) and third (16x16) mipmap levels would occupy page 10, covering the following blocks (one block is 8x8 pixels):

┌──────── Page 10 ────────┐
│ L2 L2 L2 L2 L3 L3       │
│ L2 L2 L2 L2 L3 L3       │
│ L2 L2 L2 L2             │
│ L2 L2 L2 L2             │
└─────────────────────────┘

This would correspond to TBP2=320 and TBP3=336.

Non-square texture handling

Sure, you're supposed to use square textures, but do games follow that? Of course not!

If you use a non-square texture, the GS will ignore the height and assume it's a square texture for the purposes of address calculation.

Example: 128x64

Assuming TBP0 is 0, a PSMCT32 128x64 texture with TBW0=2 would cover the following pages (one page is 64x32 pixels):

[P0 P1]
[P2 P3]
 P4 P5
 P6 P7

On the other hand, MTBA will treat your texture as if it was 128x128 for the purposes of address generation, which covers the following pages:

[P0 P1]
[P2 P3]
[P4 P5]
[P6 P7]

Based on this, the first (64x32) mipmap level would occupy page 8 (TBP1=256, TBW1=1):

┌──────── Page 8 ─────────┐
│ L1 L1 L1 L1 L1 L1 L1 L1 │
│ L1 L1 L1 L1 L1 L1 L1 L1 │
│ L1 L1 L1 L1 L1 L1 L1 L1 │
│ L1 L1 L1 L1 L1 L1 L1 L1 │
└─────────────────────────┘

Nothing would be in Page 9, as this would have been the second half of the first level if it was actually 64x64 like the GS is assuming it is.

The second (32x16) and third (16x8) mipmap levels would occupy page 10, covering the following blocks (one block is 8x8 pixels):

┌──────── Page 10 ────────┐
│ L2 L2 L2 L2 L3 L3       │
│ L2 L2 L2 L2             │
│                         │
│                         │
└─────────────────────────┘

This would correspond to TBP2=320 and TBP3=336.

Example: 64x128

Assuming TBP0 is 0, a PSMCT32 64x128 texture with TBW0=1 would cover the following pages (one page is 64x32 pixels):

[P0]
[P1]
[P2]
[P3]

On the other hand, MTBA will treat your texture as if it was 64x64 for the purposes of address generation, which covers the following pages:

[P0]
[P1]
 P2
 P3

Based on this, the first (32x64), second (16x32), and third (8x16) mipmap levels would occupy pages 2 and 3, covering the following blocks and overlapping the level 0 texture (one block is 8x8 pixels):

┌──────── Page 2 ─────────┐
│ L1 L1 L1 L1 L2 L2 L3    │
│ L1 L1 L1 L1 L2 L2 L3    │
│ L1 L1 L1 L1 L2 L2       │
│ L1 L1 L1 L1 L2 L2       │
├──────── Page 3 ─────────┤
│ L1 L1 L1 L1             │
│ L1 L1 L1 L1             │
│ L1 L1 L1 L1             │
│ L1 L1 L1 L1             │
└─────────────────────────┘

This would correspond to TPB1=64, TBP2=80, and TBP3=84

[F0bes]

I went back and recompiled some of the tests. All of these are using this as the input texture and the elfs are at the bottom.

16x32

32x16

64x128 TBW 4

128x64 TBW 4

128x128 TBW 4

128x128 TBW 8

TEX0 set to 256x256 TBW 8 and 1024 blocks behind the texture
(Top half of L0 is garbage, pretend it's nothing)

sponks.zip

[refractionpcsx2]

One of the prodominant places where this is used and is sensitive to it being wrong is Cartoon Network Racing, where the menu sky is generated using unevenly sized textures, and if you generate the MTBA mips from the TBW, TH and TW, it will come out very wrong, however using the new findings where TW is used to calculate the buffer width and the texture size is made square based on the width, this seems to resolve the issue.

Please do note that as of time of writing, 1.7.2415 is the latest version and Cartoon Network Racing does look fine, but this is because we disable MTBA generation on non square rectangles currently, and this seems to avoid the issue, but is of course incorrect.

[refractionpcsx2]

Further findings relating to MTBA is how it is reloaded. The assumption was that if the Texture Buffer was cleared or TEX1 was written this would trigger a reload on the next write to TEX0 and this was causing mipmap issues with Parappa The Rapper 2. This also is not the case. MTBA updates whenever TEX0 is written to, providing it meets the minimum width requirement (need to confirm this is true, it could be that it just doesn't draw in this scenario, but the former is more likely). However one issue we did have with this was on MTBA update, we weren't flushing the current draws if the new mips were different, causing the roof in the following screenshot to become corrupted. This is because they didn't put the MIP textures in the positions that MTBA generates, explained further below.

It is interesting and I suspect that the developers of this game did not know how MTBA worked, as they turn it on, write to TEX0 to cause the reload, but then immediately write their own MIPMAP addresses afterward, since their mipmap textures weren't in the place they would be expected had MTBA generated the addresses. It should probably be noted that this was possibly due to the fact they were using non-square textures in some scenarios as described above, which causes the address calculation to not make sense, if you try to use the height in your calculation, but instead of working it out, they just brute forced it. Further to that the "fog" in the background, I do wonder if that was to hide the glitch we see in our hardware mode (which doesn't render the fog and has trouble with filtering between layers), as it seems convenient that the following glitch gets hidden behind this fog. It could be a coincidence and just a bug for us, but it seemed convenient and though it notable :D

(look on the left hand side, you will see a white poly, this is trying to use a mip level that doesn't have a texture, however this could be because our levels don't blend correctly and it should be a mix of level 2 and 3)

[refractionpcsx2]

Further tests to run:

1. 32x32 4bit texture, check TBP/addr for each level (16x16 will be less than a block so check where the 8x8 level starts)
2. 1024x1024 32/24 bit texture, does MTBA run?
3. Any Z format (lets do Z24 for ease with the source image, must be under 1024 pixels, depending on previous test) Does MTBA work?
4. MXL set to less than 3 (or 0), does MTBA run, or do all 3 levels? Also test if setting MMIN to < 2 disables the generation

Results:

1. Each level is on the block boundaries, so 0x10800 for the 32x32, 0x10880 for 16x16 (2 blocks away), 0x108c0 for 8x8 (1 block away), 0x10900 for 4x4 (1 block away, have to upload as 4x8 otherwise it's too small)
2. 1024x1024 is 4mb, so of course it's not gonna work.
3. Z formats do not trigger MTBA, however MIP Mapping still functions, the mips will need setting manually by the game.
4. MTBA doesn't care about the state of MXL, if it's on, it refreshes. Same applies with MMIN of < 2