Política de proibição da “otimização” de movimentação condicional com `mix()`+`step()` em shaders

Introdução

• Este texto busca corrigir mitos equivocados relacionados a desvios em GPUs.
• Alguns sites educacionais estão espalhando informações incorretas, e isso precisa ser corrigido.

O problema

• É apresentado um exemplo de código que usa o operador ternário para implementar execução condicional em código de GPU.
• Algumas pessoas sugerem uma “otimização” que substitui isso por operações aritméticas, mas isso parte de um entendimento incorreto.
• O operador ternário realiza uma movimentação condicional, implementada com operações simples de bits.
• Desvios reais acontecem em código de GPU, mas não são usados para pequenas movimentações de registradores.

Problemas da otimização incorreta

• A otimização proposta na verdade executa mais lentamente do que o código original.
• A função step() é implementada com um operador ternário, adicionando multiplicações e somas desnecessárias.
• No código original, o valor é movido diretamente de forma condicional.

Análise do código de máquina

• Pelo código de máquina dos compiladores da AMD e da Microsoft, é possível confirmar que a GPU não faz desvio.
• A movimentação condicional é realizada com operações de comparação e máscaras de bits.

Conclusão

• A proposta de otimização com a função step() é desinformação e precisa ser corrigida.

• Essa informação errada se espalha há mais de 20 anos e precisa ser corrigida.

• Inigo Quilez - estudando computação gráfica desde 1994.

[GN⁺]

Opiniões no Hacker News

• Embora eu esteja convencido de que a conclusão do TFA está correta, o argumento seria mais forte se fosse mostrada a geração de código de ambas as versões, não apenas da melhor

  • Mostra o código de máquina gerado para demonstrar que a versão "otimizada" na verdade roda muito mais lentamente do que a versão original, mas não prova que a versão ruim é pior

• Gostaria que houvesse uma boa forma de saber em que casos if realmente força um desvio

  • O motivo de as pessoas usarem mix/lerp mais caros é que, embora possa haver um pequeno overhead, elas têm medo de criar desvios
  • É bom que v = x > y ? a : b; realmente funcione, mas preocupa que if seja uma sintaxe que às vezes vira desvio e às vezes não

• Este artigo também é relacionado: corrigindo conselhos ruins sobre como escrever desvios em GPU

  • Antigamente, otimizações para evitar desvios funcionavam, mas agora não se deve mais fazer isso
  • Como processadores e compiladores mudam, é melhor fornecer várias variações e escolher em tempo de execução a mais rápida

• Fico me perguntando por que o compilador não reconhece que a versão "otimizada" é equivalente

  • Ele deveria entender step() e conseguir otimizar separadamente os casos em que step()=0.0 e step()==1.0

• Já fui pego por esse problema. Claude/ChatGPT também sugerem isso como otimização, mas isso causa queda de desempenho

  • Obrigado, Inigo

• Fico me perguntando como saber se uma função do OpenGL está sendo emulada em vez de chamar funcionalidades nativas da GPU

• Ao escrever código, é preciso experiência para ter confiança de que não haverá desvio condicional

  • É difícil saber quantas operações após a condicional provocam um desvio e quais operações o compilador pode eliminar
  • Fico pensando se devo usar uma suíte de testes de desempenho para verificar quedas acidentais de performance

• Explica como a variante da função mix funciona para vetores