Tu GPU no está cansada: 20.000 draw calls la tienen harta

Tu GPU no está cansada, está harta de que la interrumpas: el día que RenderDoc me destapó la sobrecarga de draw calls en Vulkan

23 de septiembre de 2026

¿Cuántas veces has culpado a la tarjeta gráfica de ese tirón que arruina tu juego a 144 FPS? Confiesa. Yo también lo he hecho. "Es la GPU", dices, mientras miras el ventilador girar como si te debiera dinero. Y casi nunca es la GPU. Casi siempre es tu motor de juego hablándole demasiado.

Bienvenido al club de los que descubren, con la boca abierta, que el verdadero cuello de botella no era el hardware, sino veinte mil draw calls por frame que tu código lanzaba como si fueran confeti en un concierto.

Hoy te cuento cómo pasé de "mi GPU es una patata" a "mi arquitectura de renderizado es una máquina de hacer ruido". Y de paso, por qué Vulkan es maravillosamente honesto cuando lo perfilas bien, y por qué RenderDoc es esa amiga sin filtros que te dice lo que nadie más se atreve.

Primero, ¿qué demonios es una draw call?

Imagina que eres el chef de un restaurante con un solo ayudante. Cada vez que necesitas un ingrediente, tienes que gritarle al ayudante: "¡Tráeme un tomate!". Luego: "¡Tráeme una cebolla!". Luego: "¡Tráeme sal!". El ayudante corre, va, vuelve, corre, va, vuelve. La cocina funciona, pero es un caos. Eso, amigo mío, es una draw call: una orden que la CPU le lanza a la GPU para que dibuje algo.

En Vulkan, a diferencia de APIs más antiguas, tú controlas el flujo. Tú decides cuándo grabas los comandos, cómo los agrupas y cuándo los envías. Es potente. Es brutal. Y es también un campo minado donde un novato puede dispararse en el pie sin darse cuenta.

Porque aquí viene la trampa: Vulkan no te salva de ti mismo. Si tu motor genera una draw call por cada cubo, hierba, partícula o tornillo del escenario, la CPU se convierte en ese ayudante exhausto, y la GPU se queda mirando al techo, aburrida, esperando órdenes que llegan a cuentagotas.

La escena del crimen: 60 FPS que parecían 12

Te pongo en situación. Un motor propio, escena con unos cuantos miles de objetos, iluminación dinámica, sombras. En mi cabeza, "esto vuela". En la pantalla, tirones que hacen llorar al gato.

Lo primero que hice, como buen novato, fue bajar la resolución. Nada. Luego desactivé las sombras. Nada. Luego pensé en comprarme una GPU nueva. Casi lo hago. Menos mal que no.

Porque el problema no estaba en la GPU. Estaba antes. En la CPU. En el momento en que mi motor decidía cómo enviar el trabajo. Y ahí es donde entra RenderDoc.

RenderDoc: el polígrafo de tu renderizado

Si no lo has usado nunca, te lo resumo: RenderDoc captura un frame de tu aplicación y te lo abre en canal. Literalmente. Ves cada draw call, cada pipeline, cada barrera de sincronización, cada copia de buffer. Todo. Es como ponerle un micrófono a tu motor y escuchar cada suspiro.

Lo abrí. Capturé un frame. Y ahí estaba, en la timeline, la verdad incómoda: más de 18.000 draw calls en un solo frame. Dieciocho mil. Para una escena que, bien organizada, debería resolverse con unas pocas docenas.

La GPU no estaba cansada. Estaba esperando. La CPU estaba saturada emitiendo órdenes. Y yo, mientras tanto, culpando al hardware.

Por qué Vulkan amplifica el problema (y también lo resuelve)

Aquí viene la parte que me flipa de Vulkan. En APIs más antiguas, el driver hacía magia negra por ti: agrupaba, optimizaba, mentía un poco para que todo pareciera fluido. En Vulkan, no hay red. Si haces el tonto, se nota. Y se nota muchísimo.

Vulkan te da herramientas como command buffers secundarios, render passes, descriptors reutilizables y push constants. Todo está pensado para que agrupes trabajo y reduzcas el número de operaciones. Pero si no las usas, Vulkan no va a venir a salvarte. Te va a dejar solo con tu caos.

El famoso "error de sobrecarga de draw calls" no es un bug de Vulkan. Es un bug tuyo. Mío. De todos. Es la consecuencia natural de tratar una API de bajo nivel como si fuera una API de alto nivel. Y RenderDoc te lo pone delante de la cara sin anestesia.

Cómo lo arreglé (y qué aprendí por el camino)

No te voy a vender humo. No hay una sola línea mágica. Hay disciplina.

1. Uno: dejé de dibujar objeto por objeto. Empecé a agrupar por material, por pipeline y por proximidad espacial. Menos cambios de estado, menos draw calls.
2. Dos: metí instancing hasta en la sopa. Si tengo 500 árboles iguales, ¿por qué narices los dibujo 500 veces por separado? Una draw call, 500 instancias. La GPU lo agradece. La CPU, más.
3. Tres: usé command buffers secundarios para partes estáticas de la escena. Se graban una vez, se reutilizan mil. Como preparar la mise en place antes del servicio.
4. Cuatro: revisé el frustum culling. Tenía objetos fuera de cámara enviándose igualmente. Un clásico. Un pecado capital.
5. Cinco: volví a capturar con RenderDoc. Y ahí estaba la recompensa: de 18.000 draw calls a poco más de 200. Los FPS no solo subieron, se estabilizaron. Los tirones desaparecieron. Y yo dejé de mirar con rencor a mi GPU.

Lo que RenderDoc te enseña y ningún tutorial te cuenta

RenderDoc no es solo una herramienta de perfilado. Es una herramienta de humildad. Te enseña que el rendimiento no se arregla adivinando. Se arregla midiendo.

Y aquí va mi opinión sin filtros: demasiados desarrolladores optimizan a ciegas. Bajan texturas, reducen polígonos, apagan efectos. Y no entienden que el problema estaba en cómo organizan el trabajo, no en cuánto trabajo hacen.

Vulkan te da el volante. RenderDoc te da el retrovisor. Si no miras por él, vas a chocar. Y vas a culpar al coche.

Por qué esto importa más allá del gaming

Puede que estés pensando: "Violetta, yo no hago motores de juego, esto no me toca". Error. Esto te toca.

Los principios que aprendí perfilando draw calls en Vulkan se aplican a cualquier sistema que hable con hardware:

• Agrupa operaciones
• Reduce cambios de contexto
• Mide antes de optimizar
• No confundas el síntoma con la causa

Esa mentalidad te sirve para renderizado, para procesamiento de datos, para backend, para lo que sea. Porque al final, optimizar es entender dónde duele de verdad, no donde crees que duele.

El cierre, que no es un cierre

Así que la próxima vez que tu juego vaya a tirones y tu primer instinto sea culpar a la GPU, respira. Abre RenderDoc. Captura un frame. Mira la timeline con calma. Y pregúntate: ¿estoy dibujando demasiado, o estoy hablando demasiado?

Porque a veces el problema no es lo que haces. Es cuántas veces se lo dices a la GPU.

Y tú, ¿ya has perfilado tu motor con RenderDoc, o sigues culpando al hardware mientras tu CPU se desgañita pidiendo un respiro? Cuéntame. Que las verdades incómodas se comparten mejor.