Após uma saga de seis meses de desenvolvimento intenso, um desenvolvedor do Mesa conseguiu dobrar a performance do Zink em cargas de trabalho que castigam a CPU — exatamente o tipo de cenário comum em aplicações CAD. O feito veio na forma de um “movimento de pro gamer”: encarar de frente um gargalo de refcounting (contagem de referências) que explodia o número de operações atômicas por quadro. Resultado? Em viewperf, aquele benchmark implacável, o Zink simplesmente… Blammo! — dobrou os frames por segundo.
Zink é um driver do Mesa (da família Gallium) que implementa OpenGL sobre Vulkan. Em vez de falar direto com um driver OpenGL nativo, o app OpenGL chama o Zink, que traduz essas chamadas para comandos Vulkan e as envia ao driver Vulkan da sua GPU. Não é emulador: continua sendo aceleração por hardware, só muda a “língua” usada para conversar com a placa.
A batalha contra o viewperf
Para situar: Zink é a camada OpenGL-on-Vulkan do Mesa — um driver Gallium que traduz chamadas OpenGL para comandos Vulkan, permitindo rodar OpenGL onde há apenas um driver Vulkan robusto. Em outras palavras, é uma ponte moderna entre APIs, vital para manter aplicações legadas performando bem em pilhas gráficas atuais.
E por que travar essa batalha no viewperf? Porque esse benchmark reúne “viewsets” com conteúdo e padrões de uso típicos de softwares profissionais (CAD, visualização, engenharia) e, ao contrário de jogos que forçam a GPU, ele costuma estressar o lado da CPU — onde camadas de tradução sofrem mais. É o “chefão final” para medir Mesa Zink performance em cargas com dezenas de milhares de draw calls por quadro.
Nos testes iniciais, o choque: em uma estação com Threadripper 5975WX, o Zink cravava 18 fps, enquanto o driver nativo RadeonSI exibia algo próximo de 100 fps. A diferença doía — e apontava para um gargalo fora da GPU. Era hora de ligar as luzes do laboratório.
O vilão: centenas de milhares de operações atômicas
Começou a jornada épica. Perf falhava, outros profilers “circulavam” o driver inteiro como culpado e nada mudava a agulha — cenário clássico de terror para quem otimiza drivers. Até que o método “remova código até sobrar o problema” revelou o vilão: o volume absurdo de operações atômicas disparadas pelo refcounting tradicional do Gallium. Com viewperf chegando a 100 mil draw calls por quadro (cada uma com múltiplos binds de buffers), o pipeline enfileirava centenas de milhares de operações atômicas só para manter contadores de referência em dia. Sem surpresa, a CPU afundava.
Traduzindo o problema técnico: refcounting é como ter um contador perguntando o tempo todo “quantos estão usando este objeto agora?”. É seguro, facilita o gerenciamento, mas cada update do contador é uma operação atômica — barata isoladamente, caríssima quando multiplicada por 300 mil a cada quadro. O antídoto é o modelo ownership (posse): em vez de todo mundo pingar no contador, você define explicitamente quem “manda” no objeto e quando ele é descartado. Menos atomics, menos contenção, mais ar para a CPU respirar.
A vitória: performance dobrada
Claro que “apenas” mudar o modelo não é trivial em um projeto do tamanho do Mesa. Foram meses de plumbing cuidadoso para reduzir a área de impacto do refcounting até sobrar apenas nos buffers — o suficiente para viabilizar o patchset decisivo: remover o refcounting justamente dos buffers no Zink, implementando ownership e liberando-os com segurança quando saem de uso. Primeiro ganho? Um framezinho a mais (ironia do destino). Mas a outra metade do merge request entrou e… Blammo! O gargalo acabou e a performance dobrou em viewperf, abrindo espaço para melhorias adicionais. Crédito também para Marek Olšák pelo “trabalho hercúleo” de revisar esse leviatã de mudanças.
O que isso significa fora do laboratório? Que workloads típicas de CAD e visualização — onde a CPU é a rainha do tabuleiro — vão se beneficiar diretamente quando executadas via Zink. A tradução OpenGL-on-Vulkan fica mais “barata” no lado CPU, o que reduz a distância para drivers nativos e melhora a previsibilidade em cenas com milhares (ou centenas de milhares) de draws. Em termos estratégicos, é a confirmação de que atacar custos de coordenação (como o refcounting) pode render saltos de ordem de grandeza maiores do que micros tweaks na GPU — especialmente quando o objetivo é “performar como driver nativo” em cenários hostis.
No fim, a história é sobre persistência. Meses de “patches cada vez mais malucos”, ferramentas que desistiam e, ainda assim, a convicção de que havia um gargalo escondido — e que valia a pena cavar até achá-lo. Agora que o tampão foi removido, a Mesa Zink performance tem um novo platô. E, pelas palavras do próprio autor, a lacuna ainda existente “vai fechar bem rápido”. Jogo salvo. Próximo chefe.
