Com a chegada de APIs de baixo nível aos PC, os ganhos serão grandes existirão. Brad Wardell fala mesmo em ganhos de 500 e 600%. Mas será que serão esses os ganhos que teremos? E em que medida este DirectX 12 poderá ajudar a Xbox One? E a PS4 como fica?
O DirectX 12 é o primeiro API de baixo nível a ser lançado para o mercado PC. Em que consiste um API de baixo nível?
Para percebermos isso temos de perceber primeiro alguns conceitos. São essas situações que um API de baixo nível elimina, melhorando assim a eficiência do sistema.
Abstraction Layer – Um dos motivos pelos quais os APIs de alto nível possuem fraco rendimento prende-se com a existência daquilo a que se chama de as abstraction layers no software.
O termo pode ser traduzido como camada de abstracção, e como o nome indica, abstrair-se de algo é basicamente não o ter em consideração, ou desconsiderar.
Ora o acesso ao hardware normalmente está coberto por um grande número de camadas de abstracção implementadas no sistema operativo e que correm entre o hardware físico e o software que estamos a executar.
Para que servem? Muito simplesmente para esconder as diferenças existentes entre os diversos hardwares. É uma forma encontrada de se permitir que o Kernel não necessite de ser alterado para correr em sistemas com hardwares diferentes. Basicamente podemos considerar estas camadas como uma espécie de driver que faz a comunicação entre o software e o hardware, mas que se torna indispensável para o sistema uma vez que o software não contacta directamente o hardware, ficando a questão da compatibilidade com o mesmo desconsiderada (abstracção).
É esta situação que permite a um sistema operativo e respectivo software correr num grande número de plataformas diferentes com grande variedade de hardware. O programador não tem de se preocupar com o hardware que lá existe e o seu funcionamento, bastando dar o comando que pretende e as camadas de abstracção tratam do resto.
Este é o motivo pelo qual os APIs de baixo nível sempre estiveram limitados a sistemas específicos e a hardware único onde essas layers não necessitam de existir. É possível alargar os acessos de baixo nível a um leque maior de hardware, mas sempre com compromissos pois terão de existir sempre camadas de abstracção adicionais para esse suporte.
O DirectX 12 é o primeiro API que trará acessos de baixo nível para os PCs e o seu hardware bastante genérico. No entanto o DX 12 não vai eliminar todas as camadas de abstracção, e nunca chegará ao nível de um API de baixo nível criado para um hardware dedicado (totalmente ao metal). Mas valendo-se de compatibilidades entre as arquitecturas mais recentes dos principais fabricantes, limitando o suporte a hardware e arquitecturas mais recentes, o DirectX 12 conseguirá superar tremendamente o número de camadas de abstração atravessadas face ao existente no DirectX 11. E futuramente todo o hardware terá de possuir as compatibilidades que a norma for definindo, para continuar a ser suportado, acrescentando inclusive hardware que possa ajudar nesta situação.
Deste ecossistema o GPU é o elemento fundamental devido à maior disparidade e diferença de arquitecturas existentes no mercado. E esse é o motivo pelo qual nem todo o hardware gráfico actualmente no mercado será suportado pelo API. Um sacrifício que mesmo o Mantle teve de fazer, mas apenas no que toca às placas AMD. E naturalmente, sendo o Mantle um API ainda mais restrito, a sua capacidade para expor mais características de baixo nível ao permitir superar mais camadas de abstracção é maior que a do DirectX 12.
Mas onde se verificam os ganhos apresentados por estes APIs?
Basicamente um API de baixo nível ao eliminar este tipo de camadas de abstracção, permite libertar o CPU. Todo o processamento realizado pelo CPU para a transição do código entre as diversas camadas é tremendamente reduzido, o que permite libertar bastante o mesmo. Mais ainda estes APIs implementam novidades como as Pipeline State Object, Command Lists, Bundles, and Heaps, que entre outras situações (Bundles) fazem o agrupamento de comandos semelhantes que são enviados todos de uma só vez não se repetindo assim o processo de conversão de comandos vezes e vezes sem conta, só acontecendo essa situação nas camadas que não podem ser suprimidas devido às questões de suporte ao diverso hardware. Mais importante ainda, os actuais APIs de baixo nível realizam aquilo que se chama o Multi-Thread que é basicamente uma distribuição por igual das tarefas em processamento por todos os núcleos de CPU.
As optimizações de um API de baixo nível – a redução de “gargalos”
Basicamente num sistema informático o GPU executa as ordens do CPU. E aqui podem acontecer quatro situações:
1- O número de chamadas de desenho enviadas pelo CPU não o saturam, mas são complexas o suficiente para saturar o GPU;
2- O número de chamadas de desenho enviadas pelo CPU saturam-no, e saturam igualmente o GPU;
3 – O número de chamadas de desenho enviadas pelo CPU não o saturam, mas também não saturam o GPU;
4 – O número de chamadas de desenho enviadas pelo CPU saturam-no, mas não saturam o GPU;
O caso 1 é o mais particular de todos, pelo que vamos deixa-lo para o final!
Comecemos então pelo segundo caso!
Caso 2 – O número de chamadas de desenho enviadas pelo CPU saturam-no, e saturam igualmente o GPU;
Apesar de algumas das considerações do caso 1 serem igualmente aplicadas aqui, podemos desde já ver que com a aplicação de um API de baixo nível, mesmo que não se consiga alterar o limite do GPU, a utilização do CPU vai descer.
Isso quer dizer que, no mínimo (e há depois que encaixar aqui o caso 1), vamos ter mais CPU livre. E só esse simples facto permitirá melhorar os jogos. Mesmo que o número de fotogramas não aumente por o GPU estar saturado, poderemos ter melhor física, audio, detecção de colisões, etc.
Caso 3 – O número de chamadas de desenho enviadas pelo CPU não o saturam, mas também não saturam o GPU;
Neste caso o sistema não está saturado. Estamos perante um caso de um jogo que não explora convenientemente o hardware. E como tal aqui poderemos ter melhores prestações mesmo sem qualquer API de baixo nível.
Mas isso não quer dizer que ele não permita reduzir ainda mais as ocupações do sistema. E isso porque se for aplicado aqui, falo-à certamente.
Caso 4 – O número de chamadas de desenho enviadas pelo CPU saturam-no, mas não saturam o GPU;
Este é o caso onde um API de baixo mais ganhos aporta. O limite neste caso é o CPU, e devido a ele o GPU não pode ser mais explorado. Ao reduzirmos a ocupação do CPU, o GPU vai poder libertar a sua capacidade que estava por usar devido a um limite imposto pelo CPU. E é neste caso onde poderemos ver ganhos maiores. Dependendo da complexidade dos cálculos e da libertação conseguida no CPU os ganhos que já vimos acontecer poderão chegar a 500 ou mesmo 600%. Neste último caso os limites do CPU estavam a ser de tal forma que o GPU só estava a conseguir usar 16,6% da sua potencialidade normal.
Convém aqui perceber que em caso nenhum o API de baixo nível eleva a capacidade de um sistema, seja ele CPU ou GPU para cima das suas potencialidades teóricas. Uma placa de 2 TFlops será sempre uma placa de 2 Tflops, e nunca se comparará com uma de 3 Tflops com um API igual. No entanto como é fácil de perceber, se com um API de Alto nível, um CPU limita uma placa de 2 Tflops a 20% da sua capacidade, perante o mesmo API e CPU a de 3 Tflops fica igualmente limitada e para valores mais ou menos idênticos ao da placa inferior. Ou seja, ambas as placas, apesar das diferentes capacidades, irão debitar basicamente o mesmo pois a percentagem de aproveitamento do GPU, ao estar limitado pelo CPU, acaba por ser inferior na placa mais potente! O factor limitador de ambas as placas é externo, e como tal a sua potência é basicamente irrelevante!
Num exemplo teórico, ainda com o mesmo CPU em ambas as placas, se a placa de 2 Tflops se conseguisse libertar totalmente com um API de baixo nível, ela facilmente seria 5 vezes mais rápida (100%/20%=5) que a mais potente caso esta se mantivesse com o API original.
Mas claro, falamos de situações pontuais. Situações destas apenas acontecem pontualmente em jogos genéricos! Digamos que em média, se um programa pensado de raiz para o uso de um API de baixo nível conseguir, pela remoção de gargalos, uma performance dupla da de um API de alto nível, estaremos numa situação de óptimo ganho deste tipo de optimização do software. Mas isso nem sempre acontece e por vezes os ganhos até são bem menores. A Microsoft oficialmente, e para o seu DirectX 12 resguarda-se numa média conservativa de ganhos de 50%! Isto claro, nos PCs que até hoje sempre trabalham com APIs de Alto Nível.
Daí que as frases que recentemente temos lido e vindas de Brad Wardell necessitam de ser fortemente contextualizadas. De forma alguma podemos esperar como normal um jogo ganhar 500 ou 600%.
Wardell analisa as situação perante os resultados obtidos pela sua demo, o Star Swarm, e onde mesmo nela esses ganhos variam de cena para cena, mas a sua demo é uma situação extremamente peculiar de um software pensado exactamente para criar gargalos no sistema nos seus pontos mais fracos e verificar os ganhos que um API de baixo-nivel pode aportar. É um Stress Test criado com a intenção de esganar o CPU ao máximo com pequenos pedidos de desenho ao GPU.
Diga-se que a procura insistente pelo protagonismo deste senhor, com um produto que basicamente já existe à anos no mercado, mas que ele só agora viu ao aparecer para PC (Wardell nunca desenvolveu para consolas e como tal desconhece a sua realidade) levam a que este senhor preste um péssimo serviço à informação real sobre o que são os ganhos efectivos aportados pelo uso deste tipo de APIs.
Naturalmente um jogo com as características da demo de Wardell ganhará muito (muito mesmo). Mas não estamos a falar exactamente de um jogo tipo e standard, e muito menos de algo AAA. Dado que nem o CPU nem o GPU ficarão mais rápidos com um API de baixo nível, que apenas lhes remove gargalos que por vezes aparecem e podiam ser evitados, a sua performance máxima continua idêntica. Isso quer dizer que para termos um ganho de 600% estaríamos perante um raríssimo caso de um GPU sub-aproveitado a cerca de 16% ou menos, algo que a acontecer será sempre pontual, pelo que os valores verificados por Wardell em Star Swarm são, acima de tudo um caso de estudo teórico!
Daí Star Swarm ser um Benchmark e não um jogo real! Ali o que temos são milhares de naves, milhares de tiros laser, misseis, e explosões, tudo gerido pelo CPU.
O caso 1 – O número de chamadas de desenho enviadas pelo CPU não o saturam, mas são complexas o suficiente para saturar o GPU;
Este é o caso mais complexo, e que, pelos dados até agora divulgados, desconheço que tipo de optimizações terá o DX 12.
Aqui é o GPU está saturado! E à partida nada se poderá fazer! Mas isso não é bem verdade!
A optimização do GPU são situações bem comuns em APIs baixo nível de consolas (hardware único), mas muito mais difíceis em hardware genérico. O Mantle, e recorde-se que ele e bem menos genérico que o DX 12, suporta algumas situações para optimizar igualmente o uso dos GPUs GCN. E eles são:
- Dedução da submissão de buffers de comandos
- Controlo explicito de recursos de compressão, expansão e sinconização
- Filas DMA assíncronas para uploads de dados independentes do motor gráfico
- Filas assíncronas de computação para sobreposição de trabalhos gráficos e de computação genérica
- Optimizações nos diversos formatos de dados pelo uso de um acesso flexivel ao buffer/imagem
- Características avançadas de Anti-Aliasing para optimização de soluções MSAA/EQAA
- Suporte a multi-GPU
O DirectX 12 terá igualmente suporte para algumas destas optimização. Os dados exactos são ainda desconhecidos, mas mesmo que sejam todas suportadas, a optimização máxima teórica será sempre inferior à do Mantle pela diversidade de arquitecturas suportadas e pelas diferenças de processamento existentes entre elas. Poderá contudo acontecer determinadas marcas de placas serem melhor suportadas pelo API, o que parece acontecer com as placas AMD que de acordo com os testes do Anandtech mostraram ganhos máximos com o DX 12 de 400% ao passo que as Nvidia apenas se mantiveram pelos 150%.
Mas o DirectX 12 trará igualmente o Multi-Threading, ou a capacidade não só de dividir correctamente o trabalho pelos diversos núcleos do CPU de forma automatizada, mas igualmente de cada um dos núcleos poder comunicar com a placa gráfica de forma independente. Algo que actualmente nos PCs apenas o Mantle suporta!!
Mas e a Xbox One, o que ganhará com o DX 12?
Bem, sem falarmos das alterações ao seu Hardware que como já referimos permitirão optimizar de forma adicional um pouco mais o uso do CPU, a Xbox One vai ganhar de outras formas.
Não só o DirectX 12 melhora rotinas já existentes no DirectX 11 para serem mais eficientes, nomeadamente no que toca ao suporte hardware de certas características introduzidas com o DirectX 11.2 e 11.3 mas que face às limitações do DirectX 11 se revelam de muito pouca eficiência, mas acima de tudo a introdução do Multi-Thread, permitirá explorar o CPU da consola ao máximo.
Note-se que desconhecemos se o actual API, com as suas extensões de baixo nível já permitem utilizar o multi-thread na consola, mas tal a acontecer estará limitado aos jogos exclusivos. Os jogos multi-plataforma, ao serem programados em PC, e consequentemente em DirectX 11 não se crê que tirem partido de absolutamente nenhuma das novidades do DirectX 12, e como tal o que temos são jogos alterados, ajustados e optimizados dentro do possível para o API de baixo nível a consola. Mas no entanto nada que tire o máximo partido da mesma, limitando-se a optimização a diminuir alguma da sobrecarga do CPU para permitir puxar um pouco mais por este.
Seja como for, os ganhos na Xbox One serão, comparativamente ao PC, marginais, e isto porque o baixo “overhead” no CPU e a criação de “bundles”, as duas principais vantagem de um API de baixo nível, já estão implementadas na consola desde sempre, como o comprova o slide da Microsoft relativo à apresentação de Forza 5, o primeiro jogo a ser convertido para o Direct3D 12 (o Direct3D é a componente 3D do DirectX 12), e ainda em 2013 (Note-se que a driver com estas características só foi cedida a terceiros em meados de 2014).
Os Pipeline State Objects e Resource Binding não estavam na altura implementados na consola. E aqui desconhece-se se foram disponibilizados entretanto ou se esta optimização ficará para o DirectX 12. Mas, mais uma vez, acredita-se que estes recursos, a estarem disponíveis se-lo-ão apenas às equipas internas da Microsoft.
Convém não esquecer, como referido atrás, que poucos ou nenhuns programadores tiraram até hoje total partido do existente quer na Xbox quer na PS4, devido à programação actual ocorrer em PCs usando o DX 11.
Naturalmente o DX 12 para a Xbox One deverá igualmente ter optimizações específicas para o hardware da consola, eliminado as camadas de abstracção existentes na versão PC, a dúvida é se com a quase totalidade do API compatível com o PC, por questões de facilitismo, elas serão usadas por terceiros. Há quem defenda que isso não deverá acontecer, reservando-se as optimizações únicas da Xbox para os exclusivos!
E a Playstation 4? Como fica no meio disto tudo?
Bem, na realidade… nada mal! Para começar a programação em baixo nível efectuada nos jogos multi-plataforma beneficiará ambas as consolas. Somente com programação baixo nível poderemos ter acessos baixo nível. Isso quer dizer que a PS4 está actualmente com exactamente as mesmas limitações que a Xbox One no que toca à sua utilização. E como tal, no que toca a jogos de terceiros, basicamente nenhuma das características avançadas dos APIs de baixo nível está igualmente usada nesta consola!
Mas e como se compara o API da PS4, o GNM, com o Mantle e com o DirectX 12?
Na realidade, muito bem!
Aras Pranckevičius, um dos engenheiros responsáveis pelo motor gráfico Unity, teve no seu blog a 31/05/2014 alguns comentários ao estado actual do Open GL face ao DirectX 12. Termina referindo que está contente que o Mantle e o DirectX 12 tenham causado tanta agitação, colocando a seguinte frase (que traduzimos), entre parenteasses:
Para ser justo, o libGCM da PS3, foi provavelmente o primeiro API “moderno e ao metal”, mas todos que sabem disso não podem dizer
O libGCM era o API da PS3 que foi entretanto ajustado, adaptado, melhorado e actualizado e é actualmente é o GNM, o API da Playstation 4. E dado ambos estarem fechados por um forte NDA (Non Disclosure Agreement, ou Acordo de Não Revelação), pouco ou nada se sabe sobre eles!
Esta afirmação permite confirmar algo que se sabia à muito tempo. A Sony a nível de APIs de baixo nível sempre andou à frente da Microsoft, suportando-os desde o tempo da Playstation 2 (Sim, PS2! Na altura não era o libGCN, mas era igualmente de baixo nível). No entanto, tal não nos responde à questão: O que vale comparativamente?
Para respondermos a isso teremos de ver outras afirmações. A DICE, criadores do Mantle, referiu em tempos o seguinte sobre o GNM:
O API gráfico da PS4 tambem é bom, não precisamos do Mantle na PS4
Essa realidade foi revelado num slide de apresentação do Mantle, e onde foi igualmente dado a conhecer que a Sony e a Dice estão a colaborar na partilha de conceitos, métodos e estratégias de optimização. O que leva a perceber que tudo o que o Mantle actualmente suporta, o API da PS4 também suporta.
As semelhanças do API da PS4 com o Mantle foram vincadas recentemente numa entrevista à AMD realizada pela Gaming Bolt.
Actualmente a PS4 utiliza 2 APIs, o GNM e o GNMX. Existe ainda um Wrapper baseado para a conversão directa de jogos DirectX.
Actualmente muitos jogos são convertidos do DirectX 11 para GNMX, uma versão mais simplificada do GNM, mas que não é tão baixo nível, usando o Wrapper. A ideia da Sony foi criar uma plataforma intermédia de habituação ao GNM que pode ser acedida manualmente ou de forma automatizada. No entanto a nível de optimização CPU este API está longe dos resultados do GNM, e se for automatizado, muito menos.
O GNM é o API ao metal da PS4, e o que mais optimizações oferece. Com excepção de exclusivos, não há conhecimento directo de qualquer jogo de terceiros programado usando o mesmo (O GNMX é o normalmente preferido)!
Fontes: Entre outras, o artigo Direct3D* 12 – Console API Efficiency & Performance on PCs existente na secção de “developers” do website da Intel.