Un presupuesto es una herramienta de decisión

1131. Identidad de la lección

Módulo

3.7 — GPU y rendimiento

Lección

Un presupuesto es una herramienta de decisión

Tipo académico

Concepto

Tipo de esquema

texto

Orden

1 del módulo

Tiempo estimado

30–40 minutos, incluida la práctica

1132. Objetivo de aprendizaje

Después de esta lección, podrás redactar un presupuesto de rendimiento medible que nombre una categoría de coste, establezca un umbral, defina el contexto de prueba y especifique la evidencia necesaria para tomar una decisión.

1133. Por qué importa

Hablar de rendimiento es demasiado impreciso cuando solo se dice que una escena debe “sentirse fluida”. Un presupuesto convierte esa intención en restricciones que pueden orientar la implementación y la revisión. También proporciona a un asistente de programación basado en IA un objetivo preciso, en lugar de una invitación a optimizar a ciegas. Una medición resulta útil cuando puede compararse con un límite explícito bajo condiciones de prueba reproducibles.

1134. Conocimientos previos

Debes poder identificar las responsabilidades principales que intervienen en la producción de un fotograma 3D y rastrear un resultado visible a través del estado de la escena, la cámara, el renderizado y la presentación, como se practicó en 3.6 L2 — Rastrear un frame 3D. No necesitas experiencia previa con herramientas de profiling. En esta lección solo tendrás que nombrar una fuente de evidencia adecuada y una regla de muestreo. La siguiente lección introduce la recogida e interpretación de esas mediciones.

1135. Concepto central

Un presupuesto de rendimiento es una regla para decidir, no una lista de deseos. Tiene cinco partes:

1. Categoría de coste: qué consume tiempo o memoria.
2. Umbral: el valor máximo aceptable o el intervalo requerido.
3. Contexto de prueba: hardware, resolución, escena, cámara y carga bajo los que se aplica el umbral.
4. Evidencia: la fuente de medición, la regla de muestreo y el resumen utilizados para evaluar el umbral.
5. Respuesta: qué decisión se toma si el resultado cumple o incumple el umbral.

Las categorías medibles habituales incluyen:

Una categoría temporal debe definirse de forma operativa. Por ejemplo, un presupuesto puede usar el intervalo entre presentaciones consecutivas indicado por una traza de presentación de la plataforma o la duración de frame en tiempo real indicada por el contador de tiempos del motor. Registra qué fuente y qué definición utilizas: dos contadores con nombres parecidos pueden abarcar tramos distintos.

El intervalo entre fotogramas o la duración de frame del motor es una medida de cadencia y rendimiento sostenido. No equivale necesariamente a la latencia completa de un fotograma lógico ni a la latencia desde la entrada del jugador hasta la presentación. Esas métricas tienen otros puntos de inicio y final, por lo que necesitan presupuestos y fuentes de evidencia propios.

La estabilidad no es una categoría de coste independiente. Es una propiedad transversal de aceptación: describe si una categoría permanece dentro de su umbral durante muestras repetidas o en las condiciones relevantes. Una afirmación de estabilidad debe nombrar la categoría evaluada y especificar un resumen, como un percentil, un máximo o una observación del peor caso. Por ejemplo, “el tiempo de GPU se mantiene en 12 ms o menos durante 120 muestras” es un presupuesto de tiempo de GPU con un requisito de estabilidad, no un sexto tipo de coste.

La categoría debe corresponderse con la decisión. Si el problema es un pase de sombras largo, el tiempo medio de carga no aporta evidencia útil. Si el problema es un tirón al entrar en una escena, un único frame estable tampoco basta.

1136. Modelo mental

Usa el modelo C-U-C-E-R:

Categoría → Umbral → Contexto → Evidencia → Respuesta

Redacta cada línea del presupuesto como una afirmación completa:

En [contexto], [categoría] debe mantenerse en [umbral], según [fuente de evidencia y regla de muestreo]. Si falla, [respuesta].

Ejemplo:

En la escena de juego objetivo, con la resolución seleccionada y desde la posición de cámara más exigente, el tiempo de GPU debe mantenerse en 12 ms o menos, medido con el profiler de GPU durante 120 frames consecutivos. Si falla, se inspeccionarán los pases de GPU más costosos antes de añadir detalle visual.

La respuesta forma parte del presupuesto porque un número sin consecuencias no orienta ninguna decisión. El umbral también queda incompleto si falta el contexto de prueba: 12 ms en una escena vacía y 12 ms durante el encuentro más exigente no son afirmaciones equivalentes.

1137. Ejemplo concreto

Supón que una pequeña escena de juego 3D tiene como objetivo presentar 60 fotogramas por segundo. El intervalo correspondiente entre presentaciones es de unos 16,67 ms. Para este presupuesto, el equipo define su métrica de frame como el intervalo entre presentaciones consecutivas indicado por una traza de presentación de la plataforma. Esta definición mide la cadencia y el rendimiento de presentación; no afirma que la latencia completa de un fotograma lógico sea exactamente de 16,67 ms ni mide la latencia desde la entrada del jugador hasta la presentación.

El equipo podría definir este presupuesto inicial:

El límite de 12 ms de GPU y el de 10 ms de CPU no deben sumarse para deducir un intervalo de 22 ms. El trabajo de CPU y GPU puede solaparse, y la sincronización o las esperas pueden afectar al intervalo de presentación observado. Además, la traza de presentación, el profiler de GPU y el profiler de CPU abarcan límites distintos. Son evidencias relacionadas, no cifras intercambiables.

Un fallo del intervalo entre presentaciones con las medianas de CPU y GPU por debajo de sus límites puede indicar una muestra de peor caso, sincronización, problemas de cadencia, comportamiento de la presentación u otra parte no medida del recorrido. A la inversa, un umbral de CPU o GPU puede incumplirse aunque la mediana del intervalo de presentación sea aceptable; esa categoría sigue requiriendo investigación porque ha superado su límite. Registra el mismo contexto de prueba y alinea las ventanas de muestreo para poder comparar la evidencia sin tratar las mediciones como si fueran sumables.

Este presupuesto no demuestra que la escena esté terminada. Crea una base para decidir. Un problema de latencia completa necesitaría un presupuesto distinto, como un umbral de entrada a presentación medido mediante un método específico para latencia.

Una versión débil diría: “Mantén la escena optimizada y evita efectos costosos”. No nombra una categoría, un umbral, un contexto, una medición ni una respuesta. Un sistema de IA podría proponer muchos cambios técnicamente plausibles a partir de esa frase, pero ninguno estaría vinculado a una restricción verificable.

1138. Error común

Un error habitual es escoger un umbral a partir de una regla general y tratarlo como si ya fuera evidencia. Declarar “60 FPS” sin indicar la escena de prueba, la resolución, el hardware, la ventana de muestras, la fuente de medición o la condición de peor caso no establece un presupuesto utilizable.

Otro error es usar la expresión “tiempo de frame” sin definir el contador. Un contador de duración de frame del motor, una traza entre presentaciones, una duración de GPU y una medición de latencia desde la entrada hasta la presentación no abarcan necesariamente los mismos límites. Nombra la herramienta o el contador e indica qué intervalo representa.

No uses solo medias cuando importe un tirón breve. Indica si la decisión usa la mediana, el máximo, un percentil u otro resumen explícito, y mantén fijo el contexto de muestreo al comparar resultados. Tampoco clasifiques la estabilidad como un coste junto al tiempo de GPU, el tiempo de CPU, la memoria o la carga; la estabilidad describe con qué constancia una categoría medida cumple su umbral.

1139. Práctica guiada

Redacta una línea de presupuesto para un riesgo de rendimiento en una escena de juego 3D:

1. Elige una categoría: intervalo entre fotogramas, tiempo de GPU, tiempo de CPU, memoria o tiempo de carga.
2. Describe la carga que debe protegerse. Incluye la escena o condición de cámara y, cuando corresponda, la resolución o la clase de hardware.
3. Establece un umbral numérico con unidades.
4. Nombra la fuente de evidencia y define qué representa su medición. Añade una regla de muestreo o un punto de control fijo.
5. Escribe la respuesta ante un fallo. Identifica el siguiente diagnóstico o decisión; no saltes directamente a una optimización sin verificar.

Usa esta plantilla:

Categoría:
Umbral:
Contexto:
Fuente de evidencia y definición de la métrica:
Regla de muestreo o punto de control:
Respuesta si falla el umbral:

Después, somete tu línea a estas tres preguntas:

• ¿Podría otro desarrollador reproducir la prueba sin preguntarte qué querías decir?
• ¿Están claros los límites de la medición para distinguir entre cadencia y latencia cuando corresponda?
• ¿El resultado provocaría una decisión clara en lugar de producir solo otro número?

Revisa la línea una vez si alguna respuesta es negativa.

1140. Validación / evidencia

1141. Puntos clave

• Un presupuesto de rendimiento convierte un objetivo de calidad en una regla de decisión medible.
• Cada línea necesita categoría, umbral, contexto, método de evidencia y respuesta.
• Define las métricas temporales mediante su fuente de medición y sus límites.
• El intervalo entre fotogramas o la duración de frame del motor no equivale automáticamente a la latencia completa ni a la latencia desde la entrada hasta la presentación.
• Los tiempos de CPU y GPU no deben sumarse sin más, porque su trabajo puede solaparse y sus contadores abarcan límites distintos.
• La estabilidad describe si una categoría medida permanece dentro de su umbral durante varias muestras; no es una categoría de coste independiente.
• Un presupuesto solo resulta útil cuando su resultado cambia lo que el equipo hará después.

1142. Siguiente lección

Continúa con 3.7 L2 — Medir antes de cambiar.

1143. Comprobación