Divergencia: por qué un if puede costar el doble

La divergencia es el concepto de este nivel con más consecuencias prácticas y el peor explicado en la mayoría del material. No es que los condicionales sean caros: es que el coste de un condicional depende de los datos que lo evalúan, cosa que ningún otro lenguaje que hayas usado hace. El mismo shader, con la misma entrada de tamaño idéntico, puede tardar el doble solo porque los valores están ordenados de otra forma.

El mecanismo: máscaras, no saltos

Un subgrupo tiene un contador de programa y no puede tener dos. Cuando el código llega a un if y las 32 invocaciones no coinciden en el resultado de la condición, el hardware no puede saltar, así que hace otra cosa: ejecuta las dos ramas, una detrás de otra, y usa una máscara de ejecución —un bit por invocación— para decidir qué invocaciones escriben resultados en cada una.

// Si en un subgrupo hay invocaciones con x > 0 y otras con x <= 0:
if (x > 0.0) {
  a = caro1();     // se ejecuta con las de x <= 0 enmascaradas
} else {
  a = caro2();     // se ejecuta con las de x > 0 enmascaradas
}
// tiempo total = coste(caro1) + coste(caro2)

Las invocaciones enmascaradas no desaparecen: siguen avanzando por el código, ciclo a ciclo, con sus escrituras desactivadas. Ocupan la máquina y no producen nada. Esa es toda la divergencia.

La generalización tiene tres casos que hay que saber distinguir de un vistazo.

Condicional uniforme. Todas las invocaciones del subgrupo evalúan la condición igual. El hardware detecta que la máscara es completa o vacía y salta de verdad, ejecutando solo una rama. Coste: el de esa rama, más una comparación. Es prácticamente gratis.

Condicional divergente con dos ramas. Coste: la suma de las dos ramas. Es el caso del ejemplo.

Condicionales anidados o un switch con muchos casos. El coste se acumula. Un switch de ocho casos donde el subgrupo se reparte entre los ocho cuesta la suma de los ocho cuerpos.

Un bucle divergente es la peor variante y la que más gente pilla por sorpresa:

// n vale 2 para 31 invocaciones y 400 para una.
var acc = 0.0;
for (var i = 0u; i < n; i = i + 1u) {
  acc = acc + trabajo(i);
}
// El subgrupo entero itera 400 veces.

El subgrupo no puede salir del bucle hasta que la última invocación termine. Las 31 que acabaron en la segunda iteración siguen dando vueltas, enmascaradas, 398 veces. El coste de un bucle divergente es el del peor caso del subgrupo, no el promedio. Por eso un trazador de rayos donde algunos rayos rebotan veinte veces y la mayoría una es tan difícil de optimizar, y por eso las implementaciones serias reagrupan los rayos entre rebotes.

Lo que no es divergencia

Tres confusiones frecuentes conviene despejarlas antes de empezar a optimizar cosas que no lo necesitan.

Un if sobre un uniforme no diverge. Si la condición depende de un valor que es igual para todas las invocaciones —un flag en un búfer uniforme, una constante de especialización— todas toman la misma rama y no hay coste. La divergencia requiere que la condición dependa de datos que varían por invocación.

Un return temprano en la guarda del dispatch apenas diverge. El if (i >= arrayLength(&datos)) { return; } del principio de cada kernel solo divide un subgrupo: el último del último workgroup. Todos los demás lo evalúan uniformemente.

Un condicional barato no importa aunque diverja. Sumar el coste de dos ramas que hacen una multiplicación cada una es sumar dos multiplicaciones. Si el shader está limitado por memoria, ni siquiera se nota.

La pregunta correcta no es «hay un if» sino cuánto cuesta la rama menos tomada. Un if divergente que protege una lectura de textura y quince operaciones es un problema; uno que protege una asignación no lo es.

Las tres técnicas que funcionan

Uno: ordenar los datos para que la coherencia sea espacial. Es la más eficaz con diferencia y la que menos afecta al código del shader. Si procesas partículas de tres tipos y cada una toma una rama distinta, ordenarlas por tipo hace que la inmensa mayoría de los subgrupos contenga un solo tipo, y el condicional pasa de divergente a uniforme en casi todos. Lo mismo con rayos por dirección, con fragmentos por material, con celdas de una rejilla por estado. El coste de ordenar se amortiza si el shader es caro y los datos duran varios fotogramas.

Dos: convertir la selección en aritmética cuando las dos ramas son baratas. Si ambas ramas son cortas, calcular las dos y elegir sin ramificar cuesta menos que el mecanismo de máscara:

// Con rama: el compilador probablemente ya lo convierte, pero no siempre.
var color: vec3f;
if (t > 0.5) { color = a; } else { color = b; }

// Sin rama, explicito:
let color = select(b, a, t > 0.5);

select(falso, verdadero, condicion) es la función de WGSL para esto, y ojo al orden de los argumentos, que es el contrario del que casi todo el mundo espera: el primero es el valor cuando la condición es falsa. Conviene no abusar: si una de las ramas es cara o tiene efectos —una lectura de textura, un bucle—, calcular las dos siempre es peor que ramificar.

Tres: separar en varios lanzamientos. Si un kernel tiene dos caminos muy distintos y muy caros, a veces la respuesta es no tener un kernel sino dos, cada uno con su propia lista de elementos. Se paga una pasada de clasificación y se gana que ningún subgrupo diverja. Es lo que hacen los motores de partículas con muchos comportamientos y los trazadores de rayos por wavefront.

Un ejemplo con números

Un shader de sombreado con dos materiales, uno barato y otro caro:

if (material == 0u) {
  color = difuso_simple();        // 20 operaciones
} else {
  color = pbr_completo();         // 200 operaciones y 4 lecturas de textura
}

Con los objetos mezclados al azar, la probabilidad de que un subgrupo de 32 invocaciones contenga solo un material, si están al 50%, es de dos entre dos elevado a 32: cero en la práctica. Casi todos los subgrupos ejecutan las dos ramas: 220 operaciones y 4 lecturas por invocación.

Con los objetos ordenados por material, solo los subgrupos que caen en la frontera entre grupos divergen. Si hay diez materiales y diez mil objetos, hay del orden de diez subgrupos frontera de un total de varios cientos. El coste medio baja a poco más de 110 operaciones, la media ponderada real, que es la mitad.

El mismo shader, los mismos datos, el mismo número de píxeles. Solo cambia el orden.

La divergencia explica por qué se pierde tiempo ejecutando trabajo inútil. La otra mitad del rendimiento se explica por dónde están los datos: la jerarquía de memoria.