Claro. Voy a dejarlo como **checkpoint canónico de esta sesión**, pensado para que podamos copiarlo a otra conversación y retomar sin reconstruir todo desde cero.

# Checkpoint — GT6 v1.22 Spec II / MLAA Patch / RPCS3 / Vertex Explosion

## 1. Contexto general

Estamos trabajando con:

* **Gran Turismo 6 v1.22**

* **Spec II Mod**

* **RPCS3**

Pruebas realizadas principalmente en *Time Trial → Mount Panorama / Bathurst**

Conducción automatizada mediante la opción interna CHANGE_DRIVER_DBG**

Importante: *no es B-Spec**

* Se eligió para mantener la conducción lo más repetible/controlada posible.

En *todas las pruebas de esta conversación**, EMAIN está **completamente intacto**.

* No se ha modificado ni parcheado directamente EMAIN.

Por decisión nuestra, *en este workflow no estamos haciendo ingeniería inversa ni modificaciones directas al ejecutable**.

La posibilidad de editar/parchear EMAIN queda reservada para un *workflow futuro separado**.

---

# 2. Parche MLAA que estamos probando

El parche actual consta de una única escritura:

```yaml

- [ be32, 0x00ED2E88, 0x39E00001 ]

```

Este parche:

* elimina MLAA;

* corrige/evita una parte importante del flickering original;

proporciona una *ganancia enorme de rendimiento**;

pero bajo determinadas condiciones, principalmente con *PPU LLVM**, produce **vertex explosions**.

Encontramos además un comentario externo que describe aparentemente **exactamente este mismo problema**:

> un parche puede arreglar flickering y eliminar MLAA, pero tiene efectos secundarios como grandes vertex explosions; no existe fix oficial porque todavía se desconoce si la causa está en el parche o en una interacción con alguna configuración de RPCS3.

Por lo tanto:

**nuestro vertex explosion no parece ser un problema exclusivo de nuestra instalación.**

Es un comportamiento ya observado anteriormente con esta clase de parche.

---

# 3. Resultado original antes de las pruebas controladas

### Parche original + configuración intended

Resultados aproximados:

GPU: *20–30%**

CPU: *30–45%**

FPS: *~60**

Frametime: *estable**

Audio: *completamente roto/basura**

MLAA: *OFF**

* Visuales: glitches presentes

Importante: esta configuración incluía **otros ajustes específicos recomendados junto con el parche**, por lo que esos 60 FPS no podían atribuirse únicamente a la instrucción de MLAA.

---

### Sin ningún parche

Resultados aproximados:

GPU: *5–20%**

CPU: *~40%**

FPS: *~38**

* Frametime: decente

* Audio: mejor

Race/prerace: *negro**

Buffer de elementos 2D: *no se limpia / acumulación**

Esto ya indicaba que quitar el parche no era un benchmark visualmente válido debido a la ruta de framebuffer rota.

---

# 4. Tests controlados

## Test A

Configuración principal:

```text

PPU: LLVM

Patch MLAA: OFF

WCB: ON

RCB: OFF

Force CPU Blit: OFF

```

Resultados:

* Prerace: parpadeante

Acumulación 2D: *MUY agresiva**

GPU: *21–30%**, spike observado de ~47%

* CPU: ~40%

FPS: *~35**

* Frametime: OK

* Audio: mejor

Race: *totalmente negra salvo elementos 2D**

### Conclusión

WCB ON / RCB OFF no reconstruye correctamente la escena de GT6 1.22.

---

# 5. Test B

Igual a A pero:

```text

Force CPU Blit: ON

```

Resultados:

* Prerace: parpadeante

* Acumulación 2D: muy agresiva

GPU: *20–35%**

* CPU: ~40%

FPS: *~30**

* Frametime: OK

* Race: igual que A

### Conclusión

Force CPU Blit:

* empeora el rendimiento;

* no arregla esta combinación;

* no es solución para WCB ON / RCB OFF.

---

# 6. Test C — baseline visual válido sin parche

Configuración:

```text

PPU: LLVM

Patch MLAA: OFF

WCB: ON

RCB: ON

```

Resultados:

* Prerace: OK

GPU: *10–50%+**

* CPU: ~40%

FPS: *~35**

Frametime: *MUY bueno**

* Race: aparentemente correcta

* Audio: roto

* Artefacto importante:

* pequeños destellos/brillos constantes en follaje y árboles

* aspecto parecido a reflejos o pequeñas gotas brillando al sol

### Importante

Estos destellos:

**desaparecen al pausar el juego** en algunas configuraciones sin parche.

### Conclusión

Este se convirtió en nuestro **baseline visual válido sin parche**:

> **LLVM + WCB + RCB + patch OFF ≈ 35 FPS**

---

# 7. Test E

Configuración:

```text

PPU: Interpreter (Static)

Patch MLAA: ON

WCB: OFF

RCB: OFF

```

Importante:

Se omitió deliberadamente el resto de la configuración “intended” del parche para minimizar variables.

Resultados:

* Prerace: negro

* Sin acumulación 2D

* Solamente se veía el automóvil; pista ausente

GPU: *25–30%**

* CPU: ~40%

FPS: *~48**

* Frametime: decente

* Audio: mejor

* Al iniciar carrera:

* juego aparentemente normal

### Conclusión importante

El parche permite que la **carrera funcione sin WCB/RCB**, algo que sin parche no ocurre correctamente.

Esto sugirió que el parche modifica una parte importante de la ruta de postprocesado/framebuffer, no simplemente la apariencia del AA.

---

# 8. Test F

Configuración:

```text

PPU: LLVM

Patch: OFF

WCB: OFF

RCB: ON

Force CPU Blit: OFF

```

Resultados:

* Prerace: pista visible pero “se quiebra”

* Acumulación 2D agresiva, especialmente al pausar

GPU: *20–38%**

* CPU: ~40%

FPS: *~38**

* Frametime: variable

* Audio: roto

* Race:

* relativamente normal

* mismos destellos constantes en follaje/árboles

### Conclusión

Ganó aproximadamente 3 FPS frente a C, pero la ruta gráfica/2D queda dañada.

No es sustituto viable del parche MLAA.

---

# 9. Test F2

Igual a F pero:

```text

Force CPU Blit: ON

```

Resultados:

* Prerace: negro

* Acumulación 2D fuerte

GPU: *13–21%**

* CPU: ~40%

FPS: *~41**

* Frametime: consistente

* Audio: sorprendentemente bueno

* Race:

* **totalmente negra**

* acumulación 2D

### Conclusión

Aunque marca más FPS, el resultado no es válido porque la escena 3D desaparece.

También demostró algo útil:

**el audio roto no se correlaciona perfectamente con Accurate XFloat o FPS.**

---

# 10. Test G

Configuración:

```text

PPU: Interpreter (Static)

Patch: OFF

WCB: ON

RCB: ON

```

Resultados:

* Prerace: funciona

GPU: *35%+**

* CPU: ~40%

FPS: *25–35**

* Frametime: variable

* Audio: roto

* Race:

* destellos en follaje/árboles

* ocasionalmente tearing severo

Dato muy importante:

> los destellos **cesan al pausar**.

### Conclusión

Static sin parche es considerablemente más lento que LLVM.

---

# 11. Test H — uno de los resultados más importantes

Configuración:

```text

PPU: Interpreter (Static)

Patch MLAA: ON

WCB: ON

RCB: ON

```

Resultados:

* Prerace: roto

* Sin acumulación 2D

GPU: *~40%**

* CPU: ~40%

FPS: *45–55**

* Frametime: variable

* Audio: algo mejor

* Carrera:

* aparentemente normal

* **MLAA OFF**

* los destellos de follaje desaparecen

* algunas transparencias están rotas

* problema suficientemente sutil para no ser muy molesto

### Comparación clave G → H

Misma configuración básica, mismo PPU Static, mismos WCB/RCB.

Cambio principal:

```text

Patch OFF → Patch ON

```

Resultado:

```text

~25–35 FPS

↓

~45–55 FPS

```

Es decir, aproximadamente:

**+15 a +25 FPS atribuibles al parche/ruta que elimina.**

Esto fue la evidencia más fuerte de que el parche elimina una cantidad **realmente grande** de trabajo y que la ganancia no proviene simplemente de quitar WCB/RCB.

---

# 12. Test I — resultado crítico

Configuración:

```text

PPU: LLVM

Patch MLAA: ON

WCB: ON

RCB: ON

```

Resultados:

* Prerace: negro

* Sin acumulación 2D

GPU: *~50%**

FPS: *60 clavados**

Frametime: *16.66 ms exactos**

Audio: *bien**

* Carrera:

* funciona

* MLAA OFF

* **vertex explosions / geometría rota**

* cielo y árboles parpadean

problema persiste *incluso estando pausado**

### Conclusión enorme

El parche **NO “rompe LLVM” en términos generales**.

LLVM:

* ejecuta el juego;

* llega a carrera;

* logra perfectamente 60 FPS;

* mantiene 16.66 ms;

* produce buen audio.

El problema verdadero es:

> **corrupción gráfica / vertex explosion al combinar el parche MLAA con PPU LLVM.**

---

# 13. Test J

Configuración:

```text

PPU: LLVM

Patch MLAA: ON

WCB: OFF

RCB: OFF

```

Resultados:

* Prerace: roto

FPS: *60**

Frametime: *16.66 ms**

GPU: *30–35%**

* Vertex explosions/glitches:

* **siguen presentes**

### Conclusión muy importante

WCB y RCB **NO son la causa principal del vertex explosion**.

Tenemos:

```text

LLVM + patch + WCB/RCB ON

→ vertex explosion

LLVM + patch + WCB/RCB OFF

→ vertex explosion

```

Por tanto, quitar la ruta de color buffers no soluciona el problema.

---

# 14. Disable Vertex Cache — Test L conceptual

Partiendo esencialmente de J:

```text

PPU LLVM

Patch ON

Disable Vertex Cache: ON

```

Resultado superficial:

> para alguien viendo dos videos, DVC ON y DVC OFF parecerían casi idénticos.

Pero después de 5–6 días observando el problema, se detectó claramente que con **DVC ON es peor**.

Cambios observados:

* vertex explosions más frecuentes;

* empeoran conforme se acerca la cámara a una “zona de explosión”;

las explosiones de colores a veces son reemplazadas por *texturas aleatorias**;

en ocasiones una *cara completa de un edificio distante** aparece:

* delante de la cámara;

* gigantesca;

* aplastada verticalmente;

* la corrupción visual parece más caótica.

### Capturas compartidas

Las imágenes muestran:

* grandes triángulos/polígonos cubriendo partes enteras del cielo;

* abanicos de geometría de colores;

* texturas reales del juego estiradas a tamaños absurdos;

* superficies que parecen provenir de meshes normales pero con posiciones/transformaciones incorrectas.

### Conclusión DVC

**Disable Vertex Cache NO corrige el problema.**

De hecho:

> parece empeorarlo.

Hipótesis actual:

La vertex cache probablemente **no genera el error**. Puede estar reutilizando datos suficientemente estables como para ocultar/amortiguar ligeramente la corrupción.

Al desactivarla, RPCS3 vuelve a procesar datos corruptos con mayor frecuencia y el síntoma se vuelve más agresivo.

Esto es una **hipótesis**, no una demostración.

---

# 15. Naturaleza visual del problema

Después de ver las capturas, ya no tratamos esto como:

* MLAA visualmente incorrecto;

* postprocesado roto;

* simple fallo de framebuffer.

Lo tratamos específicamente como:

## **Vertex explosion / corrupción de geometría**

Manifestaciones:

* polígonos gigantes;

* triángulos proyectados por todo el cielo;

* caras de objetos desplazadas;

* geometría estirada;

* texturas válidas aplicadas a polígonos completamente deformados;

* objetos distantes que parecen aparecer delante de la cámara;

* superficies aplastadas en un eje.

Puede involucrar:

* vertex positions;

* vertex attributes;

* index data;

* transforms/matrices;

* UV coordinates;

* o datos relacionados con un draw call.

Aún no sabemos cuál.

---

# 16. Vertex explosion durante pausa

Hay dos clases de glitches que observamos y es importante NO confundirlos.

### Tipo A — destellos de follaje sin parche

En C/F/G:

* pequeños destellos/brillos;

* principalmente árboles/follaje;

en G *desaparecen al pausar**.

### Tipo B — vertex explosion con LLVM + parche

En I/J:

* cielo/árboles/geometría masivamente deformados;

* **continúa incluso estando pausado**.

Esto sugiere que los dos fenómenos pueden ser independientes.

---

# 17. NaN poisoning

Durante la investigación se encontró un thread sobre **NaN poisoning** en GT6/RPCS3.

Inicialmente parecía posible relacionarlo con nuestro problema.

Sin embargo, posteriormente encontramos el comentario que habla específicamente del:

> MLAA patch → big vertex explosions

Por eso actualmente:

**NO asumimos que nuestro vertex explosion sea causado por NaN.**

El problema de NaN del thread puede ser:

* otro bug distinto;

* relacionado;

* o simplemente coexistir con nuestro problema.

No hay suficiente evidencia para conectar ambos.

---

# 18. Opciones Accurate PPU bajo LLVM

Estas opciones se han probado anteriormente con LLVM:

```text

Accurate PPU Vector NaN Handling

Accurate PPU Non-Java Mode

Accurate PPU Float Condition Control

Accurate PPU/SPU Double-Precision FMA

```

RPCS3 reporta cosas como:

```text

Setting X is ENABLED, IGNORING

```

Es decir:

**LLVM las ignora.**

Pero detalle crucial:

> Durante TODOS los tests controlados A–J de esta conversación, estas opciones estaban DESACTIVADAS.

Antes de empezar esta investigación se creó una copia de las configuraciones estables y se inició un preset nuevo desde defaults.

Por lo tanto:

* H no se beneficiaba secretamente de esas opciones;

* I/J no diferían de H porque LLVM las estuviera ignorando;

* el experimento H vs I sigue siendo válido respecto a estas opciones.

Los tests K/L/M propuestos para alternarlas fueron descartados.

---

# 19. Accurate XFloat / audio

Durante buena parte de los tests se dejó **Accurate XFloat** activado deliberadamente para evitar contaminar resultados.

Se sabe que provoca/provocaba problemas importantes de audio en algunas configuraciones.

Sin embargo:

* algunos tests con Accurate XFloat tuvieron audio roto;

* otros, como I, tuvieron audio bueno;

* F2 también tuvo audio sorprendentemente correcto.

Por lo tanto:

> el audio no debe utilizarse como indicador único de XFloat ni como diagnóstico directo del parche.

Probablemente también intervienen scheduling/carga de SPU y otras rutas.

---

# 20. Uso de CPU

Se decidió dejar de registrar CPU UTIL.

Motivo:

Prácticamente siempre rondaba ~40%, incluso cuando el juego estaba en:

* 25 FPS;

* 35 FPS;

* 48 FPS;

* 60 FPS.

Por tanto, el porcentaje global de CPU no representa adecuadamente el hilo/cuello de botella crítico.

Métricas más útiles:

* FPS

* frametime

* GPU usage

* comportamiento gráfico

* prerace

* carrera

* pausa

* audio

---

# 21. Mount Panorama / Bathurst fue accidentalmente un stress test extremo

Esto es muy importante para interpretar todos los resultados.

El vertex explosion ocurre **en prácticamente toda la pista**, pero es especialmente visible:

* al inicio;

* después de tomar la primera izquierda tras meta;

* durante los primeros sectores.

Luego parece disminuir bastante después de la recta/curva hacia la derecha al inicio de la subida.

Hipótesis del usuario:

> probablemente no disminuye realmente; simplemente durante la subida hay menos cielo visible y, por lo tanto, menos superficie donde notar los polígonos gigantes.

Esto es plausible.

---

# 22. Mount Panorama ya tiene problemas incluso en la configuración “estable”

Existe un backup previo de configuración considerada mucho más estable, que incluye aproximadamente:

* PPU Static;

* Strict Rendering;

* optimizaciones asociadas al parche;

* configuración recomendada/intended.

Incluso así:

> **Mount Panorama todavía presenta pequeñas roturas visuales.**

Son:

* muchísimo más sutiles;

* no agresivas;

* pero detectables después de observar el juego durante varios días.

### Conclusión

Mount Panorama es probablemente:

> **la peor pista posible para usar como único test de compatibilidad.**

Pero a la vez es:

> **excelente como stress test para detectar vertex explosions.**

En el futuro conviene usar:

* Bathurst → stress test;

* otra pista más ligera/estable → control.

---

# 23. Conclusiones técnicas principales hasta ahora

### Confirmado

```text

Patch OFF + LLVM + WCB/RCB

≈ 35 FPS

```

frente a:

```text

Patch ON + LLVM

= 60 FPS / 16.66 ms

```

Por tanto:

> **LLVM tiene potencia suficiente para entregar exactamente el rendimiento que buscamos.**

El problema ya no es rendimiento.

---

### Confirmado

```text

Patch ON + Static

→ visualmente mucho más estable

→ ~45–55 FPS

```

mientras:

```text

Patch ON + LLVM

→ 60 FPS

→ vertex explosions

```

Así que la interacción problemática se reduce aproximadamente a:

> **MLAA patch × PPU LLVM**

---

### Confirmado

WCB/RCB no son la causa principal.

---

### Confirmado

Disable Vertex Cache no arregla el problema y aparentemente **lo empeora**.

---

### Muy probable

No estamos ante un simple problema de postprocesado.

Existe corrupción de geometría/vertex data real.

---

### No confirmado

Todavía NO sabemos si la causa es:

```text

A) el parche en sí

B) cómo LLVM recompila el código alrededor del parche

C) una interacción parche + algún comportamiento de RPCS3

D) una corrupción posterior desencadenada por el nuevo control flow

E) otro bug de GT6/RPCS3 que el parche deja expuesto

```

El propio thread externo mantiene prácticamente estas mismas posibilidades abiertas.

---

# 24. Workflows que debemos mantener separados

## Workflow A — esta conversación

Permitido:

* configuración RPCS3;

* parche existente;

* PPU Static/LLVM;

* SPU;

* WCB/RCB;

* RSX;

* comparación de comportamiento;

* tests controlados.

Condición:

> **EMAIN permanece intacto.**

No entrar aquí en ingeniería inversa.

---

## Workflow B — conversación futura

Tema potencial:

* editar EMAIN;

* aplicar un parche directamente al ejecutable;

* analizar el punto 0x00ED2E88;

* buscar una forma más limpia de desactivar MLAA;

* analizar por qué 0x39E00001 produce el comportamiento observado;

* encontrar un punto anterior/posterior más seguro;

* investigar compatibilidad específica con LLVM.

Este workflow permanece **completamente separado** por ahora.

---

# 25. Estado actual del proyecto

Nuestra meta inicial era:

> conseguir aproximadamente el rendimiento del Disable MLAA patch usando LLVM, sin sus problemas.

Ahora sabemos algo mucho mejor:

## Ya conseguimos el rendimiento.

```text

60 FPS

16.66 ms

Audio bueno

PPU LLVM

MLAA OFF

```

Así que el objetivo actual ya no es “conseguir 60 FPS”.

Es:

> **mantener esos 60 FPS eliminando el vertex explosion.**

Y el parche:

```yaml

- [ be32, 0x00ED2E88, 0x39E00001 ]

```

es el eje central del problema.

---