1. fpsVR: una herramienta para investigar qué está limitando a nuestro equipo

Cuando jugamos iRacing en realidad virtual, conseguir un promedio cercano a 90 FPS no garantiza necesariamente una experiencia fluida. Podemos tener un contador que indique 90 FPS y, sin embargo, experimentar pequeños tirones al comenzar una carrera, al circular entre muchos vehículos o al pasar por determinadas zonas del circuito.

Para entender qué está ocurriendo necesitamos observar la evolución temporal del procesamiento y determinar qué componente o etapa del sistema está llegando primero a su límite.

fpsVR, disponible en Steam, permite registrar y analizar diferentes métricas relacionadas con la experiencia de realidad virtual: FPS, frametime de CPU y GPU, utilización de CPU y GPU, memoria, temperaturas (cuando la monitorización está habilitada), reproyección y fotogramas descartados. Su History Viewer permite examinar las curvas registradas durante una sesión.

Entre sus métricas resulta especialmente interesante Busiest Core, que muestra la utilización del núcleo lógico más ocupado. Esta información complementa el uso global de CPU y ayuda a detectar una distribución desigual de la carga: un hilo puede estar muy exigido mientras el porcentaje total del procesador parece moderado. La denominación se incorporó para describir con mayor claridad la carga del núcleo más ocupado en el historial de fpsVR. Ver las novedades oficiales de fpsVR.

Esto es relevante para investigar posibles límites del renderizador o de otros trabajos críticos de iRacing. Sin embargo, Busiest Core no identifica por nombre el hilo principal de iRacing ni demuestra por sí solo que exista un cuello de botella. Los hilos pueden migrar entre núcleos lógicos y la métrica indica cuál presenta la mayor carga, no la identidad del hilo que ejecuta el trabajo.

2. La referencia fundamental: 90 FPS equivalen a 11,11 ms por fotograma

Para interpretar correctamente las curvas, primero debemos conocer el tiempo disponible para procesar cada imagen. En un visor configurado a 90 Hz, el sistema dispone de aproximadamente 11,11 milisegundos para cada ciclo de presentación.

Una curva de frametime que permanece en 7 u 8 ms ofrece un margen considerable. En cambio, una que se mantiene alrededor de 11 ms trabaja muy cerca del límite, incluso si todavía consigue entregar los fotogramas a tiempo. Cuando la curva supera repetidamente los 11,11 ms, pueden aparecer condiciones que impidan mantener la frecuencia objetivo.

El frametime funciona al revés que los FPS: cuanto más alto es el valor en milisegundos, más lento es el procesamiento. El promedio y la mediana describen el comportamiento habitual, pero pueden esconder eventos breves. Para detectarlos también debemos examinar percentiles elevados —como P99 y P99,9— y observar los fotogramas descartados.

Un P99,9 de 14 ms indica que existe una pequeña proporción de tiempos de procesamiento muy elevados, aunque la mayor parte de la sesión haya funcionado correctamente. Por eso, un promedio cercano a 90 FPS no demuestra por sí mismo que la experiencia haya sido estable durante toda la sesión.

3. Cómo distinguir la carga de CPU y GPU

La primera etapa del diagnóstico consiste en comparar las curvas de frametime de CPU y GPU. Si la curva de GPU permanece por encima de la de CPU, la medición de GPU está registrando tiempos mayores; si sucede lo contrario, la medición de CPU es la más elevada.

Estos tiempos no representan necesariamente dos etapas consecutivas que deban sumarse. Además, el CPU Frametime de fpsVR no debe tratarse como una medida directa del tiempo del hilo principal de iRacing: según la explicación del desarrollador, esa métrica refleja trabajo del compositor y la escena 3D, pero no captura necesariamente todo el trabajo paralelo de la aplicación, por ejemplo el que ejecuta su hilo principal. Ver la explicación técnica del desarrollador de fpsVR.

Por eso, para completar el diagnóstico necesitamos observar también los medidores del simulador.

Los indicadores R, G, T, C y S de iRacing

• R: tiempo que tarda el renderizador en procesar un fotograma.
• G: tiempo que tarda la tarjeta gráfica en dibujar un fotograma.
• T: tiempo total desde que comienza el renderizado hasta que la GPU termina de dibujar. No equivale exactamente a R + G, porque CPU y GPU pueden trabajar en paralelo y acumular fotogramas en la cola.
• C: tiempo dedicado al hilo de físicas. iRacing indica que este hilo necesita ejecutarse 60 veces por segundo.
• S: retraso acumulado o skew del sistema de físicas. Si aumenta continuamente, indica que la simulación está quedándose atrás.

Estos medidores no son idénticos a los tiempos de CPU y GPU de fpsVR: observan etapas diferentes del proceso. R y G ayudan a identificar las etapas de renderizado; C y S aportan información sobre la simulación de físicas. Consultar la documentación oficial de iRacing.

4. Situación A: limitación sostenida de GPU

La curva de GPU se mantiene elevada durante una parte importante de la sesión y se aproxima o supera repetidamente la línea de 11,11 ms. La curva de CPU permanece por debajo, con un margen claramente superior.

El diagnóstico gana solidez cuando coinciden tres señales: la curva de GPU de fpsVR aumenta y permanece elevada; el medidor G de iRacing se acerca o supera el presupuesto de tiempo; y el medidor R conserva un margen claramente mayor que G. Si estas señales coinciden con las caídas de FPS, tenemos evidencia consistente de una limitación gráfica.

Un porcentaje elevado de utilización de GPU, por sí solo, no demuestra que exista un cuello de botella. Debe contrastarse con el frametime y con la pérdida efectiva de margen respecto de la frecuencia objetivo.

5. Situación B: el procesamiento de CPU limita el rendimiento

En este escenario puede aparecer una situación aparentemente contradictoria: el uso global de CPU permanece moderado, pero Busiest Core registra una utilización muy elevada. Si al mismo tiempo aumenta R o el frametime de CPU y G conserva margen, tenemos una señal de posible limitación asociada al procesamiento del renderizador o a uno o pocos hilos críticos.

Es importante no confundir R con CPU Frametime de fpsVR. Para investigar una posible limitación del hilo principal hay que buscar correlación entre la utilización del núcleo más ocupado, el tiempo R, el comportamiento de G y los momentos en que caen los FPS.

Si R aumenta mientras G conserva margen y la utilización del núcleo más ocupado se aproxima al 100 %, hay indicios sólidos de una limitación de procesamiento de CPU. No significa necesariamente que un único hilo sea responsable de todo el problema, pero sí que el renderizador está consumiendo el tiempo disponible.

6. Situación C: picos de procesamiento al comenzar una carrera

Una situación frecuente es que el rendimiento sea excelente durante una práctica en solitario, pero aparezcan tirones al comenzar una carrera o al llegar a la primera curva. En el historial podemos observar curvas que permanecen bajas durante la mayor parte de la sesión y presentan picos pronunciados durante la salida.

La interpretación depende de qué métrica presenta el aumento más importante: si suben principalmente R y Busiest Core, el procesamiento asociado al renderizador merece atención; si aumenta principalmente G, la escena está imponiendo mayor demanda gráfica; si ambas curvas aumentan significativamente, la limitación puede ser mixta.

La diferencia respecto de una limitación sostenida es que el problema se concentra en un momento específico y las curvas regresan después a sus niveles habituales.

7. Situación D: picos localizados en boxes o zonas visualmente complejas

Otra situación es encontrar un rendimiento estable durante la mayor parte del circuito, pero observar un aumento importante de frametime al circular por boxes o al mirar hacia una zona con numerosas estructuras, tribunas, objetos o elementos de iluminación.

Si el pico se repite en el mismo punto, la coincidencia espacial es una pista útil. Si afecta principalmente a G, la GPU está consumiendo el margen disponible; si aumenta R, el procesamiento del renderizador también puede estar involucrado. El diagnóstico gana fiabilidad cuando el mismo patrón se reproduce en vueltas comparables.

8. Situación E: picos aislados y esporádicos

Este patrón puede ser engañoso. Las curvas de CPU y GPU permanecen normalmente por debajo del presupuesto de 90 Hz, pero aparecen aumentos estrechos de frametime que pueden coincidir con tirones perceptibles.

Cuando aparecen estas anomalías, conviene observar si coinciden con aumentos de utilización del núcleo más ocupado, uso elevado de memoria, reproyección, fotogramas descartados o cambios de contexto durante la sesión. Si no existe una correlación clara con CPU o GPU, no hay evidencia suficiente para atribuir el problema a un cuello de botella gráfico o de procesamiento sostenido.

9. Situación F: CPU y GPU tienen margen, pero la experiencia VR no es fluida

Puede ocurrir que las curvas de CPU y GPU permanezcan claramente por debajo del presupuesto de 11,11 ms, pero que el usuario siga percibiendo saltos o una imagen irregular. En esta situación, el análisis debe examinar también los indicadores de presentación de realidad virtual.

La reproyección puede ayudar a sostener la presentación cuando no se genera un nuevo fotograma a tiempo, pero no equivale a renderizar cada imagen al ritmo objetivo. También conviene observar los fotogramas descartados y verificar que la frecuencia y configuración del visor sean las esperadas.

Si los FPS permanecen estables pero los vehículos rivales presentan saltos de posición o comportamiento irregular, hay que distinguir un problema de red de uno de renderizado. Los indicadores L y Q de iRacing informan sobre latencia y calidad de conexión, no sobre el frametime gráfico.

10. Cómo reconocer una configuración realmente estable a 90 FPS

Después de analizar los patrones anteriores, podemos establecer una referencia visual de una sesión que mantiene la frecuencia objetivo.

Para considerar que una configuración está preparada para mantener 90 FPS con una experiencia fluida, debemos encontrar varias condiciones simultáneas:

• Margen en el procesamiento: las curvas habituales de CPU y GPU permanecen claramente por debajo de 11,11 ms.
• Ausencia de picos recurrentes: los percentiles elevados y el historial no muestran episodios repetidos en los que el procesamiento supere el presupuesto.
• Sin saturación crítica sostenida: Busiest Core no muestra una saturación prolongada coincidente con aumentos de R.
• Sin acumulación de fotogramas descartados: el contador de Dropped Frames permanece estable.
• Reproyección controlada: la frecuencia objetivo no depende habitualmente de generar fotogramas reproyectados.

Ninguno de estos indicadores, considerado aisladamente, demuestra que la experiencia sea perfecta. La coincidencia de todos ellos proporciona una evidencia mucho más sólida.

11. Qué nos enseñan nuestras siete pruebas de Sebring

Para poner en contexto la interpretación de las curvas, utilizamos los resultados de siete sesiones realizadas en iRacing, con el Porsche Cup en Sebring, un Ryzen 7 5800X3D, una Radeon RX 7700 XT de 12 GB, 32 GB de RAM y un HP Reverb G2 a 90 Hz.

SteamVR se mantuvo al 100 %, con 2576 × 2520 por ojo reportados por SteamVR; la resolución del juego fue 100 %, AMD FSR 1 Quality y MSAA 2x. El objetivo era validar una configuración cercana a 90 FPS e incorporar progresivamente elementos gráficos del circuito.

Los resultados permiten destacar tres observaciones:

1. La GPU registró medianas superiores a las de CPU en las siete pruebas. Esto muestra que la medición de GPU fue la más exigente en régimen habitual, aunque no demuestra que fuera el único límite posible.
2. Los percentiles elevados muestran anomalías que las medianas no revelan. En la prueba 3, el GPU P99,9 alcanzó 13,2 ms; en la prueba 4, el CPU P99,9 llegó a 16,7 ms. Estos resultados justifican revisar los intervalos correspondientes del historial para entender qué ocurrió.
3. La configuración se mantuvo muy cerca de 90 FPS, pero eso no demuestra una ejecución absolutamente libre de caídas. La proporción de tiempos bajo el presupuesto fue muy alta, aunque algunos percentiles superaron los 11,11 ms.

Las siete sesiones se realizaron entre el 27 y el 29 de septiembre de 2026. Las primeras cinco incluyeron sesiones con IA y las dos últimas fueron prácticas online. La secuencia sirve para validar una configuración y observar patrones, pero no constituye un experimento causal perfectamente aislado entre cada cambio.

12. Un indicador adicional: el procesamiento de físicas de iRacing

Para un diagnóstico completo también es necesario observar el procesamiento de físicas del simulador. iRacing dispone del indicador C, que mide el tiempo dedicado al hilo de físicas. Este hilo necesita ejecutarse 60 veces por segundo, por lo que su referencia temporal es aproximadamente 16,67 ms, diferente del presupuesto gráfico de 11,11 ms para 90 Hz.

El indicador S representa el retraso acumulado o skew del sistema de físicas. Si presenta picos ocasionales puede deberse a una carga momentánea; si aumenta continuamente, indica que el sistema no está manteniendo el ritmo necesario.

Así podemos diferenciar dos problemas que pueden coincidir, pero no son idénticos:

• Renderizado: determina si el equipo puede producir y presentar las imágenes a 90 Hz.
• Simulación: determina si el procesador puede completar el trabajo de físicas con la frecuencia que necesita iRacing.

La documentación oficial también describe P (fallos de página), L (latencia de red) y Q (calidad de conexión). Estos indicadores ayudan a distinguir problemas que no necesariamente proceden del procesamiento gráfico. Consultar los medidores del sistema de iRacing.

Conclusión: identificar el límite es más importante que perseguir un promedio de FPS

Mantener 90 FPS en realidad virtual exige que todas las etapas críticas del procesamiento trabajen dentro del tiempo disponible y que no aparezcan picos recurrentes que interrumpan la presentación.

fpsVR proporciona una visión muy útil de este comportamiento, especialmente cuando se combinan sus curvas de frametime con la utilización del núcleo más ocupado, la reproyección y los fotogramas descartados. Su mayor utilidad aparece al contrastar esa información con los medidores de iRacing: R y G ayudan a identificar las etapas de renderizado; T permite observar el tiempo total del proceso gráfico; C y S aportan información sobre el procesamiento de físicas.

La interpretación conjunta permite distinguir entre una GPU que no alcanza a dibujar los fotogramas, un renderizador limitado por CPU, un hilo lógico que concentra demasiada carga, picos transitorios provocados por escenas exigentes, problemas de presentación VR o limitaciones del procesamiento de físicas independientes del objetivo de 90 FPS.

La verdadera optimización comienza cuando dejamos de preguntarnos cuántos FPS entrega nuestro equipo y empezamos a preguntarnos cuánto tiempo consume cada etapa del procesamiento, cuándo lo consume y cuál de ellas está llegando primero a su límite.

Fuentes y referencias

• fpsVR – página oficial en Steam.
• fpsVR – novedades del History Viewer y la métrica Busiest Core.
• fpsVR – explicación técnica del desarrollador sobre las métricas.
• iRacing – Meter Box y explicación de R, G, T, C, S, P, L y Q.
• iRacing – recomendaciones para utilizar realidad virtual.

Nota editorial: la figura 9 está reconstruida a partir de los datos reales de las siete pruebas de Sebring. Las figuras 1 a 8 son esquemas didácticos de patrones de comportamiento, no capturas originales de fpsVR ni registros medidos. Se utilizan para enseñar a reconocer las distintas situaciones en el historial.