Artigos, VGAs

3DMark Port Royal – E eis um benchmark usando Ray Tracing em tempo real!

Fala pessoal, beleza?

Muito se fala de Ray Tracing desde o lançamento das GeForce RTX mas na realidade, esse conceito é um tanto mais antigo, tendo surgido no final da década de 60 com os primeiras implementações sendo realizadas na década de 80, desde então, o hardware obviamente evoluiu muito, porém, processar Ray Tracing em tempo real até algum tempo atrás era algo para poucos devido ao enorme custo computacional necessário para realizar esse trabalho.

Imagem produzida em 1980 usando o algoritmo de Ray Tracing desenvolvido por Turner Whitted

Entretanto as coisas evoluíram e agora temos no mercado uma primeira geração de GPUs com hardware dedicado para a aceleração do Ray Tracing e de quebra, também temos a primeira ferramenta de benchmark adequada para uso competitivo que faz uso dessa tecnologia! 😀

O 3dmark Port Royal é a primeira ferramenta benchmark para medir o desempenho do sistema usando DirectX Ray Tracing (DXRT) como API. Diferente dos outros benchmarks integrados a essa suíte, o Port Royal inclui apenas um graphic test (GT) e o demo, sendo que esse ultimo é opcional e não entra no calculo do resultado.

O primeiro (óbvio) requisito é a necessidade do hardware compatível com DXRT, algo que até o presente momento se resume as GPUs nVidia Turing/Volta e ainda que em tese seja possível rodar DXRT em GPUs de geração anteriores, o desempenho dessas deve deixar a desejar por conta de alguns detalhes da arquitetura que mudaram para melhor nas Turing/Volta e pela falta de hardware dedicado a aceleração de algumas etapas do processo de Ray Tracing, como mostrarei adiante com mais detalhes. Ainda sobre essa questão do hardware compatível, a Lisa Su anunciou em uma conferencia na CES 2019 que a AMD está trabalhando em uma solução de hardware/software para aceleração de RT.

O segundo requisito é a versão do SO, sendo necessário atualizar o Windows 10 no mínimo para a build 1809 para utilizar o DXRT.

Sobre o benchmark, apesar do mesmo não integrar um CPU Test, o mesmo ainda se beneficia de um CPU com várias threads para a construção da lista de comandos a ser passada para o GPU executar e o também com outras tarefas relacionadas ao processo de renderização. A ideia aqui é tentar fazer com que o benchmark continue sendo “GPU Bound” (em outras palavras, limitado pelo desempenho do GPU) e portanto relevante na hora de testar as futuras gerações de GPUs compatíveis com DirectX Ray Tracing, dando um exemplo mais prático, a UL não quer que o Port Royal vire um 3DMark05, onde um CPU moderno com n! cores operando a um gazilhão de gigahertz e um GPU em stock costuma dar um resultado melhor do que com esse mesmo CPU em stock com o GPU fortemente overclockado.

Da parte do GPU, esse benchmark é aquilo que podemos chamar de “compute heavy”, fazendo uso extensivo de compute shaders e até mesmo shaders assíncronos, conforme o diagrama abaixo onde consta as tarefas executadas pelo GPU nas filas relacionadas a execução de tarefas gráficas e computacionais.

Antes de prosseguirmos, deixe-me tentar deixar as coisas um pouco mais claras para quem não é familiarizado com o assunto explicando alguns termos que aparecerão logo abaixo:

Um shader é um “pequeno programa” que roda no GPU e tradicionalmente realiza alguma tarefa a nível de pixels ou vértices, por exemplo, aplicar um efeito de iluminação, mudar a cor de um pixel e até mesmo suavizar bordas nas imagens em alguns tipos de anti-aliasing.

Rasterização é o processo de transformar uma imagem 3D (que matematicamente podem ser descritas por vetores) em pontos (pixel) visando obter melhor desempenho, afinal de contas, computacionalmente é muito menos custoso trabalhar com matrizes do que com vetores!

Retornando, muitos devem associar como “compute” a algo como o GPUPI, que é uma aplicação que usa o GPU e uma API especifica para esse fim (CUDA ou OpenCL) para fazer uma série de cálculos matemáticos e no final retornar um valor, que no caso do GPUPI é o tempo de processamento, entretanto, muitos desenvolvedores vem adotando o uso de compute shaders nas engines dos jogos com as mais diversas motivações, que vão desde simulações de dinâmica de fluidos realistas, efeitos de post-processing (FXAA por exemplo), iluminação e sombreamento que seriam mais custosos de se fazer de maneira tradicional. Se bem implementada, essa abordagem permite usar o hardware de maneira mais eficiente pois a maior parte dos GPUs modernos permitem a execução de workloads gráficos/computacionais simultaneamente e também podem economizar recursos de execução no pipeline gráfico, poupando ROPs e acessos a memória.

Quem quiser ir mais a fundo nos detalhes técnicos desses benchmarks da UL, sugiro a leitura desse guia técnico do 3DMark. 🙂

Do ponto de vista do hardware disponível, os GPUs das famílias Volta e Turing trouxeram diversos incrementos na arquitetura visando não somente melhorar o desempenho com Ray Tracing mas também em aplicações computacionais (HPC) e Deep Learning. Uma dessas melhorias foi o retrabalho na SM que deu ao GPU a capacidade de executar instruções INT32 e FP32 simultaneamente, sendo que isso pode trazer ganhos de desempenho consideráveis caso a engine seja programada para tirar proveito disso.

Outra adição desses GPUs são os Tensor Cores, que são unidades especializadas em realizar operações de multiplicação/soma de matrizes e convolução, sendo esses cálculos extensamente utilizados em Deep Learning. Abaixo um exemplo do tipo de operação que esse hardware acelera.

Tudo muito bonito, mas qual a utilidade disso no nosso contexto? Bem, como mostrei logo na introdução desse artigo, o processo de Ray Tracing consiste no processo inverso ao da nossa visão e ao invés dos raios de luz serem emitidos pela fonte luminosa, eles são emitidos pelos “olhos” (câmera) e evidentemente que quanto maior o número de raios de luz, melhor será a qualidade da imagem, entretanto, o custo computacional também será maior o que infelizmente acaba por inviabilizar a brincadeira. Felizmente foi possível chegar a uma a solução para esse problema, que basicamente consiste em usar menos raios e adotar filtros para minimizar o problema do ruído na imagem e é ai que entram os Tensor Cores com filtros denoising baseados no uso de inteligência artificial sendo que o vídeo abaixo ilustra o funcionamento dessa tecnologia.

Apenas um adendo, os jogos apresentados até o momento ainda não utilizam denoiser baseados em IA, algo que pode ou não mudar no futuro… De todo modo, essa é mais uma alternativa e também representa uma forma de uso “civil” para esse hardware! 🙂

Também outro feature que faz uso dos Tensor Cores é o DLSS, acrônimo para “Deep Learning Super Sampling” que trata-se de um novo recurso que pode ser usado como filtro AA e funciona com base em uma rede neural para analisar cada cena e tomando como base vários frames ela é capaz de reconstruir a imagem com qualidade comparável ou mesmo superior a outra usando um filtro como TAA. O DLSS também trás ganhos de desempenho porque ao contrário do TAA, ele renderiza as imagens com uma resolução menor do que a utilizada e a partir dessas imagens, a rede neural consegue “inferir” o resultado com resolução maior, isso sem contar que boa parte desse trabalho é realizado pelos Tensor Cores em detrimento dos SMs.

O unico “senão” é que essa rede neural precisa ser treinada individualmente para cada aplicação, algo que é feito em um supercomputador da nVidia conforme sugerido no slide abaixo e é por esse motivo que você simplesmente não tem a opção de ativar o DLSS em qualquer jogo. Nesse link você pode encontrar uma lista de jogos que em breve irão suportar essa tecnologia. No momento, o 3DMark Port Royal ainda não oferece suporte a DLSS, entretanto, é esperado para os próximos meses uma atualização oferecendo suporte a essa tecnologia.

E por fim, chegamos aos RT Cores, que são uma adição exclusiva dos GPUs pertencentes a arquitetura Turing e que como o nome já diz, servem para acelerar o processo de Ray Tracing. Para entender melhor o que essas unidades fazem é necessário ter uma ideia, ainda que muito superficial, do funcionamento do algoritmo de um Ray Tracer cuja função é basicamente emitir os raios a partir da câmera conforme a imagem abaixo, testar cada um desses raios individualmente para verificar os que interceptam os objetos e caso afirmativo, a distância do raio até essa primitiva (que seria um triangulo) e com as informações da cor/material desse objeto em mãos, o algoritmo consegue determinar a cor daquele pixel, se ele reflete naquela superfície e como isso afeta as demais.

Então nesse processo todo, a parte que cabe aos RT Cores é a de realizar todos esses testes de intersecção dos raios com os objetos! Nos GPUs anteriores, toda essa parte dos testes de intersecção dos raios era feita computacionalmente pelos Cuda Cores (ou CUs, se for um GPU AMD), o que tomava um tempo imenso do GPU fazendo esse trabalho, adicionando latência na execução das demais tarefas e resultando em taxas de frames impraticáveis ao se usar Ray Tracing, enquanto que nas Turing, os RT Cores fazem esse serviço e o resto do GPU pode ir trabalhando em outras coisas, o que naturalmente implica em melhor desempenho usando RT.

Entretanto, ainda existe um problema nisso tudo: A maioria esmagadora dos raios não interceptam nada! Isso implicaria que preciosos ciclos de trabalho estariam sendo desperdiçados e que supostamente os RT Cores estariam fazendo muito trabalho “inútil”… Mas e se de alguma forma conseguirmos “filtrar” esses raios que não interceptam nada e com isso diminuir o número desses testes? É ai que entra o BVH!

O BVH (Bounding Volume Hiearchy) trata-se de uma estrutura de dados que nesse contexto tem como propósito separar os objetos em caixas e sub-caixas menores conforme a proximidade, com o intuito de montar uma estrutura de dados em forma de árvore conforme ilustrado nas figuras abaixo. A ideia disso é diminuir drasticamente o número dos testes, afinal de contas, as sub-caixas que estão vazias não precisam ser testadas pois já se sabe que não tem nada ali! Para isso funcionar, o BVH é atualizado por comando do driver frame a frame devido as possíveis mudanças nos objetos em questão (exemplo: Uma parede que cai e perde um pedaço, algum sistema de partículas que sofreu alguma mudança e etc) e isso é feito por um compute shader que atualiza a árvore e “passa” a mesma para os RT Cores trabalharem nos testes, conforme mostrado nos slides acima.

Por fim, tenham em mente que a solução adotada pela nVidia para uso do Ray Tracing é um híbrido entre renderização e rasterização, onde o antigo método continuará sendo usado onde ele é mais eficiente enquanto que efeitos de sombra/iluminação/reflexos serão feitos por Ray Tracing sendo que a ideia ai é justamente economizar recursos de execução enquanto que melhorando a IQ onde não seria possível faze-lo usando apenas rasterização. Caso alguém tenha interesse em aprender mais sobre o assunto, recomendo muito a leitura do Scratchapixel, que explica como todas essas coisas discutidas aqui funcionam e inclusive fornece exemplos de código para quem quiser ir mais a fundo.

Encerradas as explicações, vamos aos testes e resultados!

Configuração utilizada:

CPU: Ryzen 7 2700X (obrigado AMD!)

MOBO: ASUS ROG Crosshair VII HERO

RAM: 2x8GB G.Skill Flare X 3200 CL14 (Samsung B-Die)

VGA: NVIDIA GeForce RTX 2080 (obrigado NVIDIA – agradecimentos especiais ao Alexandre Ziebert pelo suporte!)

STORAGE: SSD HyperX 3K 120GB

SO: Windows 10 x64 1809

Objetivo dos testes: Testar o 3DMark Port Royal e verificar alguns aspectos como dependência do CPU, impacto do overclock na pontuação e como o mesmo roda em uma RTX2080. Considero isso válido pois esse trata-se do primeiro benchmark a usar DXRT e que logo o mesmo deve se tornar relevante no cenário competitivo, alias, uma competição de overclock extremo patrocinada pela Galax que ocorreu final de 2018 já foi baseada em uma versão pre-release do Port Royal! 🙂

Outro ponto que considero importante destacar é que usei a RTX2080 com um WC Custom ao invés do sistema de refrigeração padrão e foi feito assim porque os testes dessa VGA já foram realizados a algum tempo e o WC simplesmente ainda estava instalado nessa VGA. De todo modo, em breve devo publicar também o review dessa VGA com os resultados e as demais impressões sobre essa placa.

Sobre o Port Royal em si, capturei usando o GeForce Experience uma run do benchmark em suas configurações padrões e outra com Ray Tracing desabilitado conforme explicado no guia técnico que linkei anteriormente. A ideia aqui é mostrar as diferenças na IQ e dar uma noção do impacto do RT no desempenho. Ambas as rodadas foram realizadas com o 2700X @ 4.2GHz, RAM @ 3533 14-14-14-30 1T, RTX2080 @ 2055/1938 (+110/+700) e tenham em mente que o GFE gravando o vídeo subtrai uns 100 pontos do score final do benchmark.

Port Royal RT ON:

Port Royal RT OFF:

Resultados:

Para mensurar se o Port Royal apresenta alguma diferença na pontuação final ao variar a core count, mantive o CPU nos 4.2GHz, RAM @ 3533 14-14-14-30 1T, o GPU agora em stock e fui apenas desabilitando cores/SMT e anotando os resultados, algo que deu origem ao gráfico abaixo…

… Onde é possível verificar que não houve diferença no resultado além da variação entre uma run e outra, ficando entre 6020 e 6048 marks, uma variação de pouco menos de 0.5% do pior resultado para o melhor sendo que em uma das rodadas com 4C/8T houve uma diferença de apenas 1 ponto para o melhor resultado, que foi obtido com 8C/16T, ou seja, ao menos usando apenas uma RTX2080, o seu todo poderoso i9 7980XE não irá fazer qualquer diferença aqui! 🙂

Visando obter melhor resultado, tasquei o CPU @ 4250MHz e VGA @ 2055/1931 e obtive o score de 6466 pontos, um acréscimo de pouco menos de 6.5% em relação a melhor pontuação que obtive com a VGA completamente em stock. Irei discutir isso com mais detalhes no review da placa, mas tenham em mente que por conta da refrigeração a água, consegui manter a temperatura do GPU no máximo em 50ºC, o que significa que o mesmo foi capaz de manter os 2055MHz constantes ao longo de todo o teste e que no aspecto do overclock/frequência máxima em benchmarks, a geração Turing 12nm apresenta praticamente os mesmos limites das Pascal 16nm.

https://www.3dmark.com/3dm/32219451?

E por fim, para quem não tiver condições de ver os vídeos, segue uma galeria de screenshots do Port Royal. 🙂

Conclusão:

A UL fez um bom trabalho, lançando uma ferramenta benchmark que deve se manter fiel ao objetivo na qual ela foi inicialmente concebida, que no caso, é ser um software para testar GPUs compatíveis com Ray Tracing. Falo dessa forma pois pelos testes aqui realizados, da para perceber que ela realmente é muito pouco dependente do CPU sendo completamente GPU Bound, algo muito bom no longo prazo especialmente se a ideia for evitar o “efeito 3dmark05” que mencionei anteriormente.

Do ponto de vista do hardware suportado, por enquanto temos apenas as GPUs Turing/Volta, algo que só deve mudar quando a AMD (ou mesmo a Intel) colocar no mercado algum GPU com aceleração para RT, no entanto, existe a possibilidade de soltarem drivers que tragam compatibilidade com DXRT usando DirectCompute nos GPUs antigos e ainda que o desempenho dessa solução deixa a desejar, pelo menos ela deve permitir que mais pessoas possam também brincar de Port Royal em um ranking como o HWBOT. 🙂

Por enquanto é isso pessoal! Até a próxima.

4 comentários em “3DMark Port Royal – E eis um benchmark usando Ray Tracing em tempo real!”

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s