O muro da Fury X — Um desafio para a RX Vega?

“(…) Tanto em AMD quanto em NVIDIA, o gargalo acontece. Mas em taxas de frames ou tempo de frames diferentes(…)”

Nos últimos dias, nos dedicamos a entender inteiramente o funcionamento da nova versão do game Prey, lançada há pouco tempo, ainda em 2017. E, na busca por essas informações a serem entregues à vocês, percebemos um “estranho” comportamento nas R9 Fury X da AMD que já vinha nos incomodando, mas nesta oportunidade, não deixamos passar.

O termo “estranho” ganhou aspas porque, para nós, essa questão não é nenhuma novidade, mas para a comunidade pode ser algo completamente revelador e inusitado. A GPU Fiji, em determinados momentos, perde para uma GTX 1060 em 1080p Baixo e médio e para uma GTX 1070 por uma boa quantidade de FPS em todos os presets e resoluções (com exceção a 1440p Muito Alto). Isso acontece basicamente por duas razões: overhead de driver e falta de memória de vídeo.

Por favor, não diga o “porquê” mas “como”

“(…) Mas quando um desses processos acima listados demanda mais tempo de um CPU do que o tempo que a GPU leva para entregar o frame anterior, então temos um gargalo(...)”

Você reparou que as GPUs AMD não conseguem superar a casa dos 200 FPS?! Reparou também que as NVIDIA conseguem em contrapartida chegar em 240FPS?! Mesmo em GPUs sabidamente inferiores à FURY X, como a GTX 1060?! Esse problema chato pode ser relacionado ao overhead do driver. O problema em si não é o muro por si só (ele existe em ambas as marcas) mas o fato de ele obliterar a performance da sua GPU AMD muito antes que uma NVIDIA.

Overhead é o temo usado para o excesso de carga que o driver põe na CPU. Entenda! Um código de um jogo qualquer tem uma linguagem de programação (para facilitar o entendimento, exemplificamos essa linguagem como sendo “inglês”). O sistema operacional não entende essa linguagem, tal de “inglês”, precisando portanto de um “tradutor” — A API (DirectX 11, OpenGL, Vulkan) — para falar com o CPU que, por sua vez, entende apenas em “alemão”. Esse processo de tradução (API) roda no próprio processador.

Então, o CPU precisa se comunicar com a GPU, mas essa maldita GPU não entende nem “inglês” nem “alemão”, o papo dela é “francês” (que confusão)! Daí precisamos de MAIS um tradutor — o driver! O processo de tradução ocorre (desta vez, o driver) no processador.

Então, no fim das contas, o CPU tem que rodar o código do jogo, os cálculos inerentes a ele (tipo IA, física, I/O), a API, o driver, o sistema operacional, e depois disso tudo, enviar instruções para a GPU fazer o que há de mais importante em um jogo: o frame. (Não confunda: o CPU não gera frames, gera apenas as instruções, coordenadas, abstrações para que a GPU gere-o).

Mas quando um desses processos acima listados demanda mais tempo de um CPU do que o tempo que a GPU leva para entregar o frame anterior, então temos um gargalo.

Imagina aí: o CPU leva 5 milissegundos para fazer seu trabalho e preparar as coordenadas do frame 1. Aí manda as instruções do frame 1 para a GPU. Enquanto a GPU está fazendo seus cálculos tambem — na verdade entregando o referido frame pro monitor em forma de pixels — o CPU já estará trabalhando nas instruções do Frame 2 para a GPU. Se a GPU termina seu trabalho em um tempo mais rápido que o tempo do CPU (4 milissegundos, por exemplo) você terá uma GPU esperando 1 ms pelo CPU. Esse tempo de espera derruba o uso de GPU. Esse é o mais puro e técnico gargalo.

Tanto em AMD quanto em NVIDIA, o gargalo acontece. Mas em taxas de frames ou tempo de frames diferentes. 200 FPS em AMD (5ms) e 250 FPS em NVIDIA (4ms). Essa adversidade em particular acontece porque o driver da AMD trabalha com apenas um núcleo de qualquer CPU, enquanto que o da NVIDIA trabalha apropriadamente com múltiplos núcleos (ou threads)

DETALHE: não é uma implementação magnífica e perfeita por parte da NVIDIA, mas dá uma sobrevida às suas GPUs em casos em que o core do CPU poderia estar sendo um fator limitante. Para quem quiser conhecer mais sobre esse recurso, pesquise sobre NVIDIA Hyper Q.

Análise de Threads em cada caso

Uma GTX 1080Ti em 1440p Muito Alto pode ter 11 threads com mais de 10% de uso do core. A Fury X, em contrapartida, não consegue usar mais que 8. De fato, nós podemos ver apenas 3 threads acima dos 20% em AMD contra 8 threads acima dos 20% em NVIDIA.

Perceba que mesmo com um framerate mais baixo, as primeiras duas threads tem mais de 80% de uso em AMD, uma demanda que nenhuma placa gráfica da NVIDIA exigiu do nosso processador.

Em 1080p Baixo, onde há menor exigência de CPU vindo do código do jogo, o comportamento ainda permanece o mesmo no quesito de gerenciamento de threads. Apenas 8 threads usados.

E tem mais!

Ao passo que temos problemas com settings mais baixas e resoluções mais baixas causadas pelo overhead do driver em AMD (ocorre em NVIDIA tambem mas não tão precocemente), em resoluções mais alto como 4K, temos outro problema: falta de VRAM — memória de vídeo.

Os 4GB da Fury X a fazem funcionar como se estivesse com freio de mão puxado. Em Prey, especificamente, não vemos acontecer problemas em 4K com os FPS médios (graças às otimizações do time Radeon) mas as Quedas e Quedas bruscas não mentem. Temos maior instabilidade nas R9 Fury X que em GTX 1070 que, diga-se de passagem não são tão potentes quanto à verdadeira concorrente da Fury X, as GTX 980Ti. Nos jogos mais recentes, tem se tornado regra, demandas de mais de 4GB para se jogar em 4K.

E as RX Vega?

Se você considerar os rumores das RX Vega sendo lançadas em 30 de julho e que o melhor dos SKUs dessa família virá com 8GB HBM V2, podemos tranquilamente assumir que SKUs menores virão com 4GB (como indicam os rumores). Isso é algo para se preocupar.

Não apenas pelo fato de a Fury X já ter demonstrado suas barreiras em altas demandas como 4K e baixas demandas como 1080p, mas porque parece que não há uma boa folga de tempo para resolver isso.

Se a Fury X é limitada por VRAM e overhead de driver, uma GPU mais forte que ela será tão capada quanto e isso é algo para a comunidade ter em mente.

Se tivesse que advinhar, diria que o principal desafio que a equipe da AMD RTG tem é justamente resolver esse par de problemas antes do lançamento das RX Vega.

Ainda há esperança (leia com uma pitada de sal)

A arquitetura Vega tem dois recursos chamados de High Bandwidth Cache (HBC) e HBC Controller. A principal função destes recursos é manter dentro da memória de vídeo o que a placa VERDADEIRAMENTE precisa para que o código do game rode de maneira apropriada. Isso deve, em teoria, reduzir a necessidade de placas com quantidades massivas de memória dedicada. É uma questão de VRAM alocada contra VRAM requirida. Segundo o próprio Raja Koduri, a maior parte dos jogos aloca o dobro de memória dentro da GPU do que ele realmente utiliza.

O Infinity Fabric seria tambem uma solução que, pareado com CPUs Ryzen, poderiam de fato entregar melhor comunicação entre CPU e GPU e reduzir o problema de overhead. I não consigo ainda entender como isso vai funcionar na prática (devo acrescentar) mas é algo que a AMD está engendrando esforços. Este esforço não deve ser por nada (Assim espero)

Por fim, considerando a evolução dos últimos anos da Polaris e dos Drivers Crimson e a corrida por otimizações para Ryzen, podemos ficar confiantes de que alguns aprimoramentos devem vir pós — lançamento .

Este artigo não é para colocar um alerta contra a Vega, mas para debater com a comunidade sobre algo que todos deveriam estar plenamente cientes.

Sinceramente, torço para que a AMD quebre o paradigma atual de mercado de GPUs com suas placas com a nova GCN, mas sempre seremos críticos e direcionados pela ciência, matemática e coerência, nunca pela paixão. be driven by science, never by passion.

Vejo vocês no porradal por vir,

Marcus Sarmanho

CEO

PC Facts