Uma breve visão geral da API Vulkan

Então, qual é o grande problema com essa nova API Vulkan, e por que devemos nos importar?

Aqui está a API Vulkan em uma centena de palavras ou menos: É uma API de baixa sobrecarga e próxima ao metal para gráficos 3D e aplicativos de computação. Vulkan é basicamente uma continuação do OpenGL. Ela foi originalmente chamada de “iniciativa OpenGL de próxima geração” e inclui algumas partes da API Mantle da AMD. O Vulkan deve fornecer inúmeras vantagens sobre outras APIs de GPU, permitindo suporte superior entre plataformas, melhor suporte para processadores multithread, menor carga de CPU e uma pitada de agnosticismo do sistema operacional. Deve também facilitar o desenvolvimento de drivers e permitir a pré-compilação de drivers, incluindo o uso de shaders escritos em várias linguagens.

São 93 palavras, então se você não estiver interessado, pode pular as próximas 3.500. Se, por outro lado, você quiser saber mais sobre a próxima API gráfica que estará conosco nos próximos anos, começarei com o básico.

Como a API Vulkan surgiu

Vulkan foi originalmente anunciado pelo Khronos Group em março de 2015, com uma data de lançamento provisória marcada para o final de 2015. Caso você não esteja familiarizado com Khronos, é um consórcio industrial sem fins lucrativos fundado há quinze anos por alguns dos maiores nomes do indústria gráfica, incluindo ATI (agora parte da AMD), Nvidia, Intel, Silicon Graphics, Discrete e Sun Microsystems. Mesmo que você não tenha ouvido falar do Khronos, provavelmente já ouviu falar de alguns de seus padrões, como: OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA e glTF.

A essa altura, você provavelmente está pensando “Ah, são esses caras”, então posso pular o resto da introdução e focar na própria API.

Ao contrário de seu antecessor, ou antecessores, o Vulkan foi projetado desde o início para rodar em diversas plataformas, desde celulares e tablets, até consoles de jogos e desktops de última geração. O design subjacente da API é em camadas, ou deveríamos dizer modular, para permitir a criação de uma arquitetura comum, mas extensível, para validação de código, depuração e criação de perfil, sem afetar o desempenho. A Krhonos afirma que a abordagem em camadas fornecerá muito mais flexibilidade, catalisará forte inovação em ferramentas de GPU de vários fornecedores e fornecerá controle de GPU mais direto exigido por mecanismos de jogo sofisticados.

Agora, eu entendo que muitos tecnófilos têm suas reservas sobre termos de marketing como “flexível”, “extensível” e “modular”, mas desta vez estamos lidando com o verdadeiro McCoy. Na verdade, essa é a ideia básica por trás do Vulkan: ele é concebido como uma API para as massas, desde crianças jogando em smartphones até seus pais projetando edifícios e jogos em estações de trabalho.

Em teoria, o Vulkan poderia ser usado em hardware de computação paralela, para controlar dezenas de bilhões de núcleos de GPU, em minúsculos wearables e drones de brinquedo, em impressoras 3D, carros, kit VR e praticamente qualquer outra coisa com uma GPU compatível dentro.

Para mais detalhes, sugiro que você dê uma olhada na visão geral oficial do Vulkan em PDF.

DNA do manto AMD

Se a abordagem próxima ao metal soa estranhamente familiar, você pode estar acompanhando os anúncios de GPU da AMD nos últimos dois anos. A AMD surpreendeu os observadores da indústria quando anunciou sua API Mantle em 2013 e os surpreendeu mais uma vez quando decidiu encerrar a API, anunciando em março de 2015 que não lançaria o Mantle 1.0 como um SDK público. Em poucas palavras, Mantle prometeu entregar melhorias significativas de desempenho e eficiência em algumas situações, especialmente na frente da CPU, pois reduziria a sobrecarga de processamento. Parecia uma boa ideia, já que os jogadores poderiam montar PCs personalizados com processadores um pouco mais lentos e investir mais dinheiro em placas gráficas de primeira qualidade. Parecia muito conveniente para a AMD também, porque a empresa não tem uma CPU de ponta competitiva há anos, embora ainda tenha bons produtos de GPU.

Enquanto os chorosos fanboys da AMD se reuniam para lamentar a morte de seu salvador, Mantle foi milagrosamente ressuscitado. A boa notícia veio na forma de uma postagem no blog, escrita pelo vice-presidente de computação visual e perceptiva da AMD, Raja Koduri. Coincidentemente, de acordo com o tema religioso, em uma ocasião Koduri realizou um sermão em um monte, durante o evento de lançamento da AMD no Havaí em 2013, mas eu discordo.

Brincadeiras à parte, a equipe de Koduri fez um bom trabalho. Embora o Mantle não tenha se tornado um novo padrão do setor, ele se tornou uma base para o Vulkan. A maior diferença é que o Vulkan não ficará restrito ao hardware AMD GCN; ele funcionará em muito mais GPUs de diferentes fornecedores. Você provavelmente pode ver onde estou indo com isso; é um pouco melhor ter uma única API gráfica de baixa sobrecarga que funcione em diferentes sistemas operacionais e plataformas de hardware do que ter APIs proprietárias para diferentes arquiteturas de GPU, sistemas operacionais e assim por diante.

A API Vulkan simplesmente pega uma boa parte da torta do Mantle e a compartilha com todos, independentemente do sistema operacional, hardware, raça ou religião.

Ah, e há mais uma coisa: Mantle eventualmente forçou a Microsoft e a Khronos a finalmente fazer algo sobre o inchaço e a ineficiência do DirectX e OpenGL. Foi um chute gentil e amigável no traseiro, ou “badonkadonk”, como um colega Toptaler gosta de dizer.

Como o Vulkan se compara ao OpenGL?

Obviamente, preciso descrever as diferenças básicas entre Vulkan e OpenGL. Khronos veio com uma ilustração simples, mostrando quanto inchaço do driver poderia ser eliminado com a nova API.

O Vulkan permite que os aplicativos se aproximem do metal, eliminando assim a necessidade de muita memória e gerenciamento de erros, além de muita fonte de linguagem de sombreamento. Os motoristas serão mais leves, mais enxutos e mais cruéis. O Vulkan contará apenas com a linguagem intermediária SPIR-V e, como possui uma API unificada para os mercados de dispositivos móveis, desktop e console, também deve receber um cuidado mais terno e amoroso dos desenvolvedores.

Mas espere, isso simplesmente não descarrega mais trabalho para os desenvolvedores de jogos? Claro, eles poderão usar o hardware com mais eficiência, mas e quanto às suas próprias horas de trabalho? É aqui que a abordagem do ecossistema em camadas entra na briga.

Os desenvolvedores poderão escolher três níveis ou camadas diferentes do ecossistema Vulkan.

• Use o Vulkan diretamente para máxima flexibilidade e controle.
• Use bibliotecas e camadas Vulkan para acelerar o desenvolvimento.
• Use o Vulkan por meio de mecanismos de jogo prontos para uso totalmente otimizados sobre a nova API.

A primeira opção claramente não será para todos, mas suspeito que daria um bom software de benchmarking. Khronos espera que a segunda opção seja uma “área rica para inovação” porque muitos utilitários e camadas estarão em código aberto e facilitarão a transição do OpenGL. Se um editor tem alguns títulos OpenGL que precisam de ajustes e atualização, é isso que eles usariam.

A última opção é, talvez, a mais tentadora porque o trabalho pesado foi feito por pesos pesados ​​da indústria como Unity, Oxide, Blizzard, Epic, EA, Valve e outros.

Aqui está uma tabela rápida de OpenGL vs. Vulkan:

Para ser honesto, não acho justo comparar os dois. Vulkan é um derivado do Mantle, enquanto o OpenGL é um mastodonte com 20 anos de bagagem. Vulkan deve abandonar um monte de coisas legadas; esse é o ponto. O Vulkan deve simplificar os testes e a implementação, tornar os drivers mais enxutos e melhorar a portabilidade do programa de sombreamento por meio da linguagem intermediária SPIR-V.

Isso nos leva à próxima pergunta. O que o Vulkan realmente significa para os desenvolvedores?

Espera-se que o SPIR-V transforme o ecossistema linguístico

Então, onde o SPIR-V entra em jogo, e o que acontece com o bom e velho GLSL?

O GSLS permanecerá vivo por enquanto e será a primeira linguagem de sombreamento suportada pelo Vulkan. Um tradutor de GLSL para SPIR-V fará o trabalho pesado e voila!, você terá o SPIR-V pronto para alimentar o faminto tempo de execução do Vulkan. Os desenvolvedores de jogos poderão usar back-ends SPIR-V e Vulkan, provavelmente contando com front-ends de compilador de código aberto. Além do GLSL, o Vulkan pode suportar kernels OpenCL C, enquanto o trabalho para adicionar suporte para C++ está progredindo. As futuras linguagens, estruturas e ferramentas específicas de domínio são outra opção. Khronos ainda menciona a possibilidade de desenvolver novas linguagens experimentais.

O que quer que os desenvolvedores decidam fazer, todos os caminhos levam ao Vulkan, via SPIR-V e, em seguida, a uma infinidade de dispositivos diferentes.

O SPIR-V deve melhorar a portabilidade de três maneiras:

• Ferramentas compartilhadas
• Conjunto de ferramentas único para um único ISV
• Simplicidade

Como não haverá necessidade de todas as plataformas de hardware apresentarem um tradutor de idiomas de alto nível, os desenvolvedores lidarão com menos deles.

Um ISV ​​individual pode gerar SPIR-V usando um único conjunto de ferramentas, eliminando assim os problemas de portabilidade da linguagem de alto nível.

O SPIR-V é mais simples do que uma linguagem típica de alto nível, facilitando a implementação e o processamento.

O desempenho será aprimorado de várias maneiras, dependendo de como o Vulkan é implementado:

• Não há mais front-end do compilador, muito processamento pode ser feito offline
• Os passes de otimização podem ser resolvidos mais rapidamente, otimizações executadas offline
• Vários sombreadores de origem são reduzidos ao mesmo fluxo de instrução de idioma intermediário

Khronos não especifica nenhum número de desempenho e observa que “a milhagem definitivamente varia”. Tudo dependerá de como o Vulkan é usado. Se você quiser conferir os detalhes, não deixe de conferir o white paper SPIR-V.

Vulkan parece promissor do ponto de vista do desenvolvedor

Descrevi vários recursos que devem tornar o Vulkan e o SPIR-V populares na comunidade de desenvolvedores, e a Khronos também deseja transmitir esse ponto. A perspectiva de usar as mesmas ferramentas e habilidades para desenvolver para várias plataformas parece intrigante, especialmente agora que a diferença de desempenho entre várias plataformas está diminuindo.

É claro que desenvolver um jogo AAA de grande orçamento para PCs continuará sendo um processo extremamente complexo e demorado, envolvendo muito dinheiro e recursos humanos, mas plataformas móveis e GPUs integradas empregadas nos mais recentes processadores Intel e AMD já oferecem muito Desempenho de GPU para o jogador casual. Além disso, desenvolvedores pequenos e independentes, ou freelancers, são mais propensos a trabalhar em jogos casuais multiplataforma do que títulos AAA produzidos por grandes editoras.

Khronos descreve as seguintes vantagens possibilitadas pelo SPIR-V:

• Os desenvolvedores podem usar o mesmo compilador front-end em várias plataformas para eliminar problemas de portabilidade entre fornecedores
• O tempo de compilação do sombreador/kernel de tempo de execução será reduzido, pois o driver só precisa processar o SPIR-V
• Os desenvolvedores não precisam distribuir o código-fonte do shader/kernel, portanto, eles desfrutam de um nível adicional de proteção de IP
• Os drivers são mais simples e confiáveis, pois não há necessidade de incluir compiladores front-end
• Os desenvolvedores têm uma visão melhor da alocação de memória e podem ajustar sua abordagem de alocação de memória de acordo

Tenho certeza que você vai concordar que isso soa bem, mas ainda há um longo caminho a percorrer.

Vulkan: Funciona, mas é um trabalho em andamento

Como eu disse, Vulkan ainda é um trabalho em andamento, e devemos ter as especificações completas até o final do ano. No entanto, pelo que vimos até agora, a nova API pode desbloquear muito desempenho mesmo com hardware de geração atual.

A melhor ilustração do Vulkan que vi até agora vem da Imagination Technologies, uma das principais equipes de GPUs móveis do mercado. O IP da GPU da Imagination Technologies é usado em todos os dispositivos iOS, juntamente com vários outros designs System-on-Chip baseados em ARM e até mesmo em alguns chips Intel x86 de baixa tensão.

Na semana passada, a Imagination publicou uma postagem no blog detalhando os ganhos de desempenho possibilitados pelo Vulkan. Sua escolha de hardware foi um tanto incomum: um Google Nexus Player, baseado em um processador Intel quad-core raramente usado com GPU PowerVR G6430. O dispositivo foi testado com o driver de API Vulkan mais recente para GPUs PowerVR, enquanto a execução de referência foi realizada no OpenGL ES 3.0. A diferença de desempenho foi nada menos que impressionante.

A cena inclui um total de 400.000 objetos, com diferentes níveis de detalhes, variando de 13.000 a 300 vértices. A tomada ampla mostra cerca de um milhão de triângulos, alguns alfa nas plantas e cerca de dez texturas diferentes para os gnomos e plantas. Cada tipo de objeto usa um sombreador diferente e os gnomos não são instanciados, cada chamada de desenho pode ser um objeto totalmente diferente, com materiais diferentes, mas o resultado final seria semelhante.

Ainda assim, há uma grande ressalva: esse não é o tipo de aumento de desempenho que você pode esperar na vida real. A equipe da Imagination Technologies usou um cenário exagerado para destacar a superioridade do Vulkan, para levá-lo ao limite, e neste cenário em particular o limite é a favor do Vulkan vs. OpenGL ES. Além disso, lembre-se de que este teste é vinculado à GPU , mas ainda é uma boa ilustração da utilização superior da CPU do Vulkan.

Como o Vulkan reduz a utilização da CPU?

Lembre-se daquela tabela OpenGL vs. Vulkan que tivemos anteriormente, ou para ser mais específico, aquele bit de renderização lado a lado? Provavelmente não, então aqui está, em poucas palavras: a Imagination usou o Vulkan para desenhar chamadas em lote em blocos e renderizar um bloco de cada vez. Dependendo de onde o bloco está no momento em que o quadro é renderizado, ele pode entrar ou sair da vista, alterar seu nível de detalhe e assim por diante. No OpenGL ES, todas as chamadas de desenho são dinâmicas, são submetidas a cada quadro, de acordo com o que está no campo de visão. Chamadas de desenho que já foram executadas não podem ser armazenadas em cache.

Como resultado, o OpenGL ES precisa de muitas chamadas no modo kernel para alterar o estado do driver e validá-lo. Vulkan não porque depende de comandos pré-gerados (buffers de comando) para reduzir a sobrecarga da CPU e eliminar a necessidade de validar ou compilar durante o loop de renderização. A equipe do Imagination descreveu a capacidade de reutilizar os buffers de comando como “útil em algumas circunstâncias” e possível de usar “em grande medida” em muitos jogos e aplicativos.

A segunda mudança de jogo é a geração de buffer paralelo , que permite que a Vulkan aproveite o poder de todos os núcleos da CPU. O OpenGL ES foi projetado antes do advento dos chips móveis multi-core, mas nos últimos três anos, a indústria passou de dois, através de quatro, para oito e dez núcleos de CPU, com os SoCs da série A da Apple e o Nvidia Tegra baseado em Denver. chips como as únicas exceções notáveis. Falei sobre as tendências do SoC móvel em um dos meus artigos anteriores do blog, abordando o próximo compilador Otimizando para Android, para que você possa conferir mais informações.

Vamos tentar uma analogia: se o Vulkan fosse um motor de combustão interna, estaria armazenando e reutilizando parte de sua energia, da mesma forma que um turbocompressor e um intercooler (buffers de comando), e seria capaz de usar quatro, seis, oito ou até dez cilindros sem perda de eficiência (geração de buffer paralelo). Comparar o Vulkan com o OpenGL ES soa um pouco como comparar um novo motor turbo de tamanho reduzido com um motor antigo de um cilindro no Troféu Triumph do seu avô.

Bem, pelo menos o vovô era um bom roqueiro, não um mod.

O resultado final é um ambiente muito mais eficiente, capaz de colocar todo o hardware disponível em bom uso, ao contrário do OpenGL ES, que é vinculado à CPU na maioria dos cenários. Isso significa que o Vulkan pode oferecer níveis semelhantes de desempenho, mantendo a CPU em clocks mais baixos, reduzindo assim o consumo de energia e o afogamento.

Potenciais desvantagens da API Vulkan (alerta de spoiler: não há muitos)

Eu não sou picuinhas; Eu sinto que também é importante listar os prós e contras da API Vulkan. Felizmente, não há muitos contras além de alguns menores e, potencialmente, um ou dois grandes. Se você acha que Vulkan é a melhor coisa desde o pão fatiado e está ansioso para experimentá-lo em seu próximo projeto, considere alguns destes pontos:

• Complexidade de código adicionada em determinados cenários
• Tempo de colocação no mercado
• Nível de suporte da indústria
• Vulkan pode não ser tão relevante ou eficaz em algumas plataformas (desktops)
• Convencer os desenvolvedores a usar o Vulkan em algumas plataformas
• Compatibilidade limitada com hardware legado

Se um desenvolvedor quiser implementar alguns dos recursos interessantes descritos neste post, isso envolverá uma boa quantidade de trabalho. Cada um terá que ser implementado em código, mas a boa notícia é que os líderes do setor facilitarão o processo com novas atualizações de drivers.

O time-to-market é outra preocupação, assim como a implementação do Vulkan em aplicativos e jogos mais antigos. Vulkan ainda é uma prévia técnica; especificações e implementações iniciais são esperadas até o final de 2015, então, realisticamente, provavelmente não veremos muitos aplicativos do mundo real antes de meados de 2016.

O apoio da indústria não deve ser um problema; Afinal, este é um padrão Khronos, mas pode demorar um pouco. Essa é uma das razões pelas quais concentrei este post no segmento móvel; O software e o hardware móveis evoluem mais rapidamente e pode levar mais alguns trimestres antes de vermos o Vulkan causando impacto nas plataformas de desktop. É assim que a indústria funciona, há muito mais coisas com que se preocupar no nicho de desktops: suporte para aplicativos profissionais, hordas de jogadores empunhando forquilhas pirando em cada quadro rasgado e assim por diante. No entanto, o fato de o Vulkan ser derivado do Mantle da AMD é encorajador.

Embora o Vulkan possa fazer maravilhas em uma configuração vinculada à CPU, especialmente com SoCs móveis de vários núcleos, esses ganhos de desempenho serão limitados em plataformas de desktop. Os desktops lidam com processadores multi-core com um maior nível de eficiência, e os aplicativos mais exigentes graficamente são vinculados à GPU.

Até que todas as peças do quebra-cabeça se encaixem, alguns desenvolvedores podem relutar em mergulhar e mexer com o Vulkan. Muitas pessoas simplesmente não têm tempo para experimentar e aprendem novas habilidades apenas quando absolutamente necessário. Queimar muito dinheiro e desperdiçar horas de trabalho para ajustar os jogos móveis existentes para usar o Vulkan neste estágio inicial não será uma opção para muitos desenvolvedores e editores.

A compatibilidade com hardware mais antigo pode ser outra fonte de preocupação. O Vulkan precisará de hardware OpenGL ES 3.1 ou OpenGL 4.1, acompanhado de novos drivers. Por exemplo, as GPUs PowerVR série 6 da Imagination Technologies podem suportá-lo, mas a série 5 não. A série Adreno 400 da Qualcomm suporta OpenGL ES 3.1, mas a série 300 não. As séries Mali T600 e T700 da ARM suportam OpenGL ES 3.1, mas falta suporte em designs mais antigos da série T400. Felizmente, quando o Vulkan se tornar relevante, a maioria dos dispositivos com GPUs não suportadas estará fora de cena. Estes incluem o iPhone 5/5C, iPad de quarta geração e dispositivos Samsung baseados em certos chips Exynos da série 5000. Os dispositivos baseados na Qualcomm podem não ter a mesma sorte, já que as GPUs Adreno série 300 são usadas em designs relativamente recentes e prolíficos, como o Snapdragon 410, Snapdragon 600, Snapdragon 800 e 801. No entanto, suspeito que a maioria deles desaparecerá com o tempo Vulkan torna-se verdadeiramente relevante.

Vida longa e renderização

Ainda é muito cedo para dizer se o Vulkan será ou não um divisor de águas, mas acho que você concordará que ele tem muito potencial. Acho que será um grande negócio, e baseio essa suposição em uma década de experiência cobrindo a indústria de GPUs. Levará tempo, no entanto, e suspeito que o Vulkan fará sua presença no celular antes de começar a mudar o cenário da área de trabalho.

Mais ou menos ao mesmo tempo, drivers, mecanismos de jogos e jogos otimizados para Vulkan, teremos um novo hardware para brincar, e não me refiro apenas a pequenos ajustes de hardware. O desenvolvimento do Mobile SoC estagnou por uma série de razões que não vou abordar agora, mas 2016 será um grande ano para a indústria, pois os nós FinFET de 14/16 nm se tornarão disponíveis para mais fabricantes e se tornarão economicamente viáveis ​​para hardware convencional em vez de chips emblemáticos.

Os desenvolvedores terão hardware muito mais poderoso e eficiente para brincar, e uma nova API gráfica de baixa sobrecarga será a cereja do bolo. Espero sinceramente que os fornecedores de hardware parem de usar a resolução de tela como um truque de marketing, já que resoluções inutilmente altas não fazem nada pela qualidade visual, mas ainda desperdiçam energia. Infelizmente, como o consumidor médio não entende isso e quer ver números maiores na caixa, suspeito que isso não aconteça tão cedo. Pretendo examinar essa questão estranha em um dos meus próximos posts, então se você está incomodado com isso, fique atento e sinta-se à vontade para desabafar na seção de comentários.