Porque motivos os benchmarks que existem para o Vulkan não medem a sua performance.

Com o lançamento do Vulkan apareceram benchmarks vindo de um jogo: The Talos Principle. A questão é que esses benchmarks, nem de perto, nem de longe, representam as performances do Vulkan.

O Vulkan é um novo API de baixo nível, baseado no Mantle, e que será competidor do DirectX 12, mas no entanto muito mais versátil e suportando a quase totalidade dos sistemas operativos e hardware atualmente à venda no mercado.

Disponibilizado à apenas alguns dias na sua versão protótipo, o Mantle definiu as bases para o seu funcionamento e algumas demos (nos dipositivos móveis) e benchmarks começam a aparecer demonstrando as suas potêncialidades.

Mas os benchmarks que tem vindo a aparecer e baseados no jogo The Talos Principle demonstram performances muito fracas. Inferiores até que o DirectX 11, um API de alto nível. É isto que vale o Vulkan?

Na realidade Neste momento é impossível ter-se uma verdadeira noção do que são as performances do Vulkan, pois neste momento não há ainda nada no mercado que permita fazer benchmarks à sua performance real.

E devido a tal, os benchmarks e demos atualmente existentes não representam de forma alguma a performance do Vulkan. Vamos tentar explicar o porque:

Até à bem pouco tempo atrás o mercado era dominado por dois grandes APIs, o DirectX 11 e o Open GL. O directX 11 era o API da Microsoft exclusivo ao sistema operativo Windows, ao passo que o Open GL era mais aberto e compatível com vários sistemas operativos.

Se até ao DirectX 7 a Microsoft nunca fez mais do que copiar as capacidades do Open GL, com o DirectX 8 a Microsoft ultrapassou o API concorrente ao trazer suporte a novas caracteristicas.

E a situação inverteu-se com o Open GL a ser quem corria atrás do DirectX.

Infelizmente o Open GL tinha uma desvantagem. Se o DirectX funcionava totalmente dependente das capacidades do Hardware, o Open GL estava desenhado para poder ser emulado por software.

Esta diferença obrigava a forma diferentes de implementação. E se ambos os APIs possuíam as mesmas funcionalidades, as performances eram muitas vezes diferentes.

Daí que quando se falou que o DirectX 11 iria sofrer uma atualização para um API mais moderno, o DirectX 12, adequado ao hardware mais recente, e que tirava total partido das novas tecnologias presentes nos CPUs e GPUs, com uma menor sobrecarga no CPU e melhor utilização das performances disponíveis, ao permitir o acesso directo ao hardware, o Open GL viu-se limitado na base..

Infelizmente o legado do Open GL era demasiadamente pesado. Alterar o API para algo do género do DirectX 12 era uma tarefa que obrigava a criar um novo API de raiz. O Open GL pagava o preço por escolhas do passado.

Infelizmente a  criação de um novo API era tarefa para vários anos, daí que quando a  AMD apareceu a fornecer uma base sólida e pronta de trabalho, o seu API Mantle, o mundo agradeceu.

E é partindo desse API que surge o Vulkan (aliás há uma ligação muito clara entre os nomes de ambos), o novo API que virá substituir o antigo Open GL.

Ora o Vulkan foi lançado na sua versão 1.0 à alguns dias. Mas não com o intuito de ser já aplicado em jogos. Na realidade esta versão cria a primeira base do API para a criação de drivers e de ferramentas para o seu uso, bem como para a adaptação a motores gráficos, a criação de drivers e tudo o mais. Trata-se apenas de uma primeira base funcional de trabalho que define as especificações ao API, mas tal não define o API como pronto para o mercado, ou com as melhores performances possíveis.

Ora isso significa igualmente uma outra coisa. Se o Mantle apenas agora foi lançado com as especificações finais, como é que o The Talos Principle lançado em Dezembro do ano passado o suporta?

A resposta é! Não suporta!

Mas a realidade é que há Benchmarks Vulkan ao The Talos Prince, e assim sendo então o que é que o jogo suporta?

Na realidade este é apenas um jogo que suporta o Open GL, um API com o o qual o Vulkan vai manter compatibilidade.
Diga-se aliás que as performances do jogo em Open GL nem sequer são as melhores. Dado que as principais plataformas são a PS4 e o Windows, sendo que ambas podem usar o DirectX 11 (já lá vamos), o Open GL é apenas uma aposta para se cobrir mercados menores como o Linux e o Mac.

Daí que os programadores de The Talos Principle resolveram experimentar uma situação. Criaram aquilo que se chama um Wrapper, um software que converte os comandos Open GL para alguns comandos equivalentes em Vulkan, o que permite que o jogo corra usando chamadas de Vulkan.

O resultado é uma situação algo estranha. Basicamente um jogo a correr o limitado Open GL, com a estrutura de programação pensada para o Open GL, os limites do Open GL, mas a sofrer algumas acelerações pelo Vulkan. Ou seja, o que temos é as performances do Open GL com alguma aceleração adicional criada pelo Vulkan, mas não, de forma alguma, o Vulkan puro.

Há atualmente um caso bem semelhante no mercado e que pode ajudar a compreender isto:

Apesar de boas performances e limitações, o DirectX 11 é um API de alto nível, e que cria uma elevada sobrecarga no CPU com as suas chamadas de desenho. E é, ainda hoje, um dos APIs mais usados no mundo, e uma referência, o que o torna uma ferramenta bastante conhecida e familiar dos programadores!

Daí que a Microsoft o tenha incluído na sua Xbox One, alterando-o e acrescentando-lhe extensões que acabaram por dar origem ao atual DirectX 12, para performances extras.

Ora a Sony sempre pretendeu que os criadores tivessem fácil acesso à sua consola, e nesse sentido o DirectX 11 era essencial. Daí, dado que tinha o seu API de baixo nível, o GNM, muito superior ao DirectX 11, mas algo novo e desconhecido dos programadores, a intenção foi que a consola pudesse correr igualmente os jogos DirectX 11.

Infelizmente o DX 11 é propriedade da Microsoft e executar o mesmo de forma nativa obrigaria à concordância da Microsoft, bem como ao pagamento de royalties, daí que a Sony optou pelo uso de um Wrapper, tal como o The Talos Principle faz.


Assim, os comandos DirectX 11 são convertidos para comandos GNM, criando-se performances mistas. Basicamente o que temos são as performances base do DirectX 11, aceleradas numa determinada percentagem pelo GNM, mas não as performances nativas do GNM.

Este wrapper teve o nome de GNMX!

Este tipo de situações, fornece realmente acelerações adicionais face ao API base, mas a passagem de um API de alto nível para um API de baixo nível é muito mais complexa do que isso. E só com essa passagem total podemos medir as performances desse API.

No entanto convêm referir-se que o GNMX foi alvo do trabalho de vários anos, ainda hoje sendo atualizado, e por parte de toda uma equipa especializada em APIs, ao passo que este wrapper é o trabalho de uma semana de parte da equipa da Croteam.

O motor de The Talos Principle demorou alguns anos a ser criado, e foi optimizado ao longo de todo o seu desenvolvimento para o DirectX. Aliás a equipa confessa que quando criou o jogo as performances do próprio DirectX 11 não passavam as do DirectX 9, e que foi preciso optimizar posteriormente. Mas ao menos aqui a base do DirectX estava criada. – Fonte

A verdade é que sendo o Vulkan um API diferente e acima de tudo, ao contrário de tudo o que o motor suporta, de baixo nível, há que se aplicar muito mais do que um mero Wrapper. E os programadores de The Talos Principle reconhecem isso e resolveram explicar a situação para que esta seja clara.


Eis as explicações dadas pelos programadores e que demonstram os três grandes passos que são necessários para se tirar pleno partido de um API.

O desenho de um motor para o Vulkan basicamente consiste-se de três fases:

1) Converter o jogo. Fazê-lo funcionar, o mais rápido possível, colocando o “wrapper” no design atual do motor a funcionar ligado ao Vulkan. Temos de evitar todos os problemas e estrangulamentos que surgem. Isto é o que foi feito até agora e lançado como patch para o nosso jogo Talos.

2) Usar o Vulkan para processamento multi-threaded (vários trabalhos distribuídos pelos vários núcleos). O nosso motor é projetado muito bem para render tarefas multi-threaded, mas temos apenas a nossa wrapper para ele – e desta forma as chamadas para o novo API de gráficos (o Vulkan) não são multi-threaded. Ainda! Dito isto, este é o próximo passo que vamos fazer. E, provavelmente, liberar isso também como patch para Talos.

3) Redesenhar o motor para Vulkan. Este é o maior passo e pode ser dividido em dois:

3a) Fazer primeiramente um Precache de todos os estados de renderização (que são maioritariamente os materiais do jogo). Isso fará com que as chamadas de desenho se tornem mais simples e mais rápidas. Assim, em vez de decidir na altura do processamento o que é necessário para um material ser processado através de Vulkan, fazemos isso durante a carga do jogo e, em seguida, quando o material precisa ser processado limitamos a fornece-lo ao Vulkan, através de uma ou duas simples chamadas de função.

3b) Fazer igualmente o Precache de toda a geometria, materiais, texturas, e tudo o que é necessário para para um objecto ser processado antecipadamente. Isso basicamente cria um buffer de comandos prontos para o Vulkan, e nada precisa de  ser definido ou criado na altura de renderizar.

A terceira parte 3ª parte da conversão do jogo é, obviamente, a mais complexa,irá demorar muito tempo para mudar passa a passo o projeto do motor para o Vulkan.

Como vemos o que temos aplicado até agora é apenas o primeiro de três passos, sendo que o principal é o terceiro. E a acrescentar a isso temos o jogo a correr com drivers Beta, sendo que maior parte delas nem sequer são ainda certificadas.

Resumidamente, estes resultados não são nem de perto nem de longe o que o Vulkan pode atingir. E tal como os resultados do GNMX não são os do GNM, isto são resultados do Open GL acelerado pelo Vulkan e não resultados do Vulkan.

Outros dados relevantes fornecidos pela equipa num post de perguntas e respostas colocadas nos fóruns da comunidade Steam  é que atualmente, apesar dos ganhos o seu Wrapper até chaga a causar abrandamentos de 20 a 30% de performance nas zonas onde havia gargalos do GPU. Daí que a intenção é deixar claro que resultados finais superarão em muito os obtidos pelo DirectX 11, mas que nesta fase é ainda muito cedo para que tal aconteça.

O objectivo deste artigo é acima de tudo realçar que não há ainda nada com suporte ao Vulkan e que não há ainda sequer jogos anunciados com o seu suporte. Assim sendo nesta fase falar avaliar as performances do API baseando-nos no único teste existente, que não passa de um Wrapper criado com a primeira versão das especificações e a funcionar sobre drivers Beta e é claramente e apenas um trabalho preliminar que não suporta o API na totalidade, é algo que não deve acontecer!

 

Publicidade

Posts Relacionados

Readers Comments (2)

  1. A Realidade é que mesmo o vulkan sendo uma beta ja é superior ao OPENGL e isso ja é muito bom, estou ansioso que melhorem isso e muito, quero voltar ao meu windows 7 e não ter que ser obrigado a ter o completamente ridiculo windows 10 a nivel de privacidade e outros factores, so o facto de impletementarem o DX12 somente no windows 10 só prova o quanto a microsoft anda na droga a coisa de uns 4 ou 5 anos. Antes disso nunca tive queixa deles…

    • Olha, eu instalei o Lubuntu num netbook Toshiba NB100 que vinha com o XP, e Wow. Parece outra máquina. Agora até filmes em HD ele reproduz sem problemas, a Net é perfeitamente normal e não um mar de engasganços, etc. Apesar de no meu caso a gráfica não ser suportada pelo Vulkan, outros casos existirão onde máquinas melhores do que esta, mas igualmente obsoletas poderão ganhar vida nova com um OS destes e o Vulkan.

Os comentarios estao fechados.