A atualização Vulkan 1.4.335 chegou como mais um passo do Khronos Group para transformar a API em algo cada vez menos “interpretação” e mais “controle explícito”. O grande destaque desta Vulkan 1.4.335 update é a nova extensão VK_EXT_present_timing, que dá ao aplicativo um relógio mais confiável do que realmente acontece na etapa de apresentação e, mais importante, um jeito padronizado de pedir que um frame seja exibido em um instante específico.
Na prática, isso mira um problema que todo dev de engine conhece: a diferença entre renderizar no tempo certo e apresentar no tempo certo. É aí que nascem engasgos sutis, variação de frame pacing e parte do incômodo de latência em jogos competitivos, VR/AR e reprodução de mídia.
Controle total do tempo com VK_EXT_present_timing
Até aqui, “apresentar” um frame no swapchain era parecido com entrar numa fila: você entrega o pacote e confia que o sistema, o modo de apresentação e o VSync vão encaixar aquilo no próximo ciclo. Funciona, mas não dá uma linguagem universal para duas coisas essenciais: agendar e medir.
Com VK_EXT_present_timing, o aplicativo passa a conseguir:
- Solicitar um tempo alvo para a apresentação (em nanossegundos), dizendo ao motor de apresentação: “não deixe esse frame ficar visível antes deste instante”.
- Consultar o tempo real de apresentação depois, obtendo um histórico do que aconteceu de fato com frames anteriores.
Aqui a analogia do maestro fica ainda mais precisa: antes, era como mandar uma carta e torcer para ela chegar “no horário aproximado”. Agora o dev vira maestro, marca a entrada exata da nota e, depois do concerto, recebe a partitura anotada com o que realmente ocorreu.
Como isso entra no fluxo de uma engine
O ponto de integração é direto: o agendamento é informado no momento do vkQueuePresentKHR, encadeando a estrutura VkPresentTimingsInfoEXT no pNext do VkPresentInfoKHR, com um VkPresentTimingInfoEXT por swapchain. Para habilitar isso, o swapchain também precisa ser criado com a flag VK_SWAPCHAIN_CREATE_PRESENT_TIMING_BIT_EXT.
E existe uma sutileza que é útil para adoção gradual: targetTime = 0 permite usar a extensão apenas para coletar telemetria, sem tentar “marcar horário” para o frame. Ou seja, dá para começar medindo e só depois passar a controlar.
Feedback mensurável, não opinião
A outra metade do valor está no pós: a engine pode consultar resultados via vkGetPastPresentationTimingEXT. Como o motor de apresentação é assíncrono, esses dados podem aparecer algum tempo depois, então a ideia é tratar isso como uma fila de resultados.
Esse ponto puxa uma “pegadinha” do mundo real: se você não consumir os resultados, a fila interna pode lotar. Quando isso acontece, o present pode falhar com VK_ERROR_PRESENT_TIMING_QUEUE_FULL_EXT. Para evitar esse cenário, a extensão também oferece um controle explícito de tamanho dessa fila, permitindo que o aplicativo aloque capacidade suficiente e mantenha o consumo em dia.
FRR, VRR e a vida fora do fullscreen
A extensão também ajuda a lidar com a diferença entre telas de taxa fixa (FRR) e taxa variável (VRR), algo que afeta muito o frame pacing. O swapchain pode expor propriedades como duração do ciclo e o comportamento do intervalo de refresh, o que dá à engine base para decidir se deve alinhar o frame ao “próximo tick fixo” ou tratar a janela como VRR.
Vale notar outra particularidade: em algumas plataformas, essas propriedades podem não estar disponíveis imediatamente. Consultas podem retornar VK_NOT_READY até que ao menos um frame tenha sido apresentado, e mudanças de comportamento (por exemplo, janela comum versus fullscreen exclusivo) podem só refletir depois de uma apresentação adicional.
Refinamentos na especificação
Além da extensão nova, a 1.4.335 também é uma atualização de “limpeza de casa”, que mostra amadurecimento contínuo da Vulkan:
- Regras de Valid Usage (VU) para tessellation em shader objects foram reforçadas para limitar combinações inválidas entre estágios e reduzir espaço para comportamento indefinido.
- A geração de documentação e tabelas ligada a ray tracing recebeu ajustes para lidar melhor com dependências complexas no XML, diminuindo inconsistências em artefatos gerados.
- Comandos de debug do estilo vkCmdDebug*EXT foram melhor classificados no registro (como comandos de “estado”), o que melhora a coerência entre spec, ferramentas e validação.
Impacto no desenvolvedor
O efeito prático desta Vulkan 1.4.335 update é mais controle sobre “fluidez” com menos tentativa e erro. A VK_EXT_present_timing cria um caminho padrão para engines fecharem o ciclo: medir quando o frame aparece de verdade, ajustar pacing com base em dados e, quando fizer sentido, solicitar um alvo temporal para reduzir variação e melhorar latência. Para jogos, VR/AR e mídia, esse tipo de controle é o que separa “rodar a X fps” de “parecer consistentemente suave”.
