Texture cache: stop the churn, the per-frame image leak and garbage textures

- Unmapped GPU addresses get a stand-in CPU address fixed by the GPU
  address. A fresh one per lookup meant FindImage never found an image
  there again: title 1's bloom chain at 0xf0000-0x15b600 was re-created
  on every use (~5,400 images per 600 frames), filling VRAM.
- ASTC whose blocks carry no alpha (exact endpoint-mode scan reusing the
  decoder's block parsing) is re-compressed to BC1 instead of BC3, half
  the size; about 70% of title 1's ASTC qualifies. Copies between BC1
  and BC3 hosts are skipped (their guest data is uploaded instead).
  EDEN_NX2_ASTC_BC1=0 turns it off.
- Deleting an image cancels every decode still queued for it. An image
  re-decoded mid-decode has two; the first to finish cleared IsDecoding,
  the second was not cancelled and was uploaded into the next image to
  take the slot: garbage textures (the title logo, road patches) and a
  staging overrun when that image was smaller.
- Diagnostics: images created and deleted per 600 frames by shape,
  collector deletions, async decodes, BC1/BC3 split; collector
  thresholds overridable (EDEN_NX2_TC_EXPECTED_MIB/CRITICAL_MIB); GPU
  ASTC decode wait timing (EDEN_NX2_ASTC_FLUSH=1 submits without it).

Title 1 attract loop: device memory 4.8-5.1 GB instead of 5.9-6.1 GB, no
decoded textures evicted, ~17 -> 22-23 fps.

0 files changed, 0 insertions, 0 deletions