[Guru3D] An introduction to FCAT benchmarking

[reiszink]

Uma leitura interessante de como as análises às placas gráficas vão passar a ser feitas. Medir apenas os fps debitados, cada vez vai ser mais secundário nas reviews.

Já existiam alguns sites especializados que mediam as latências do frames, mas agora todos os maiores sites do ramo estão-se a preparar para fornecer aos leitores os chamados frametimes.

Ou seja, o debitar x ou y frames cada vez vai ter menos importância, porque isso por vezes depois na prática não se traduz em fluidez de jogo. É aconselhável o pessoal ficar a par destes novos métodos, para depois nas reviews não estranharem ao verem uma gráfica a debitar mais fps, mas ser apontada como inferior a uma outra que debita menos.

There's a problem that started floating at the surface for a while now, FPS does not say much as to what you see and experience on screen thus on your monitor, in certain conditions you can get a little stuttering every now and then. E.g. FPS will not say a thing about graphics anomalies. Up-to a while ago nobody really cared that, and some of you perhaps think that is the best way to approach this. Do you really care of you see a small stutter every now and then for a fraction of a second maybe split-second? The answer to that is two fold. Some of you, the more enthusiast end users, do while other's don't. And as such lately we have seen websites posting frame-capture and frame time results.

An introduction to FCAT benchmarking

[MAXLD]

Yap, tenho acompanhado atentamente este assunto e isto abriu a caixa de pandora. Os mal amados tearing, stuttering e micro-stuttering estão na linha de fogo e estes sistemas de análise demonstram o que se passa em todo processo desde o motor do jogo até à saída DVI (ao que nós vemos realmente no monitor). E os dados até agora dão razão aqueles que sempre se queixaram desses problemas atrás referidos, particularmente os gamers com dual GPU (em especial Crossfire).

Aconselho a mega investigação do Ryan Shrout da PC Perspective:

• 3/27: Frame Rating Dissected: Full Details on Capture-based Graphics Performance Testing
• 3/27: Radeon HD 7970 GHz Edition vs GeForce GTX 680 (Single and Dual GPU)
• 3/30: AMD Radeon HD 7990 vs GeForce GTX 690 vs GeForce GTX Titan
• 4/2: Radeon HD 7950 vs GeForce GTX 660 Ti (Single and Dual GPU)
• 4/5: Radeon HD 7870 GHz Edition vs GeForce GTX 660 (Single and Dual GPU)
  
  • PLUS Radeon HD 7850 vs Radeon HD 7790 vs GeForce GTX 650 Ti vs GeForce GTX 650 Ti BOOST

Tudo isto permitiu chegar a conclusões deste tipo:








Basicamente o que isto quer dizer é: o Fraps indica-nos as frames do motor do jogo que devíamos ver no fim no nosso monitor, o segundo gráfico mostra o que se passa pelo meio quando a API, drivers, GPU e afins pegam nelas e as processam, e no fim temos as frames que realmente chegamos a ver, sem as frames perdidas ou cortadas / reduzidas a uma minuscula barra horizontal.

No caso do multi-gpu (SLi / Crossfire), cada gráfica processa uma frame alternadamente (uma frame vai para o gpu1 e a próxima vai para o gpu2), e isto quer dizer que das duas uma:
- ou as gráficas se orientam minimamente para dar uma sequência mais natural, consoante as frames são processadas e depois enviados para a DVI pelo gpu1 (podendo introduzir um certo lag) (Caso nVidia / SLi)
- ou então as frames são enviadas a torto e a direito para saída DVI o mais rápido possível assim que acabam de ser processadas por qualquer um dos gpu, sem qualquer tipo de controlo. (Caso da AMD / Crossfire)

O problema é que certas frames demoram mais tempo a ser processadas que outras, e se um gpu despacha uma frame mais lentamente, o outro gpu não espera e pode enviar outra(s) frame(s) a seguir... resultado: quando acontece o refresh do monitor aparecem-nos não uma mais várias frames ao mesmo tempo, ou seja, vemos a imagem partida aos bocados e deslocados entre si (tearing), ou então não temos sequer frames para serem mostradas, resultando em stutter (quebras). Acelere-se o processo e temos um autêntico "clusterfuck" de frames e quebras de movimento, conforme os jogos exigem mais ou menos processamento em cada frame.

A nVidia tem controlado isso usando um sistema de métrica que acerta o passo dos gpu e reduz em muito essas situações (dantes era por software, as actuais por hardware) , mas a AMD não tem qualquer sistema desses e os resultados são esses que se vêm nos gráficos. Já disseram que andam a trabalhar numa solução e que para o Verão teremos uma opção nas CCC para activar um processo para reduzir esses bugs (embora podendo introduzir algum lag), daí que vão meter como opcional para o gamer poder escolher).

Vamos ver o que acontece, mas uma coisa é certa, estes métodos de frame rating vieram revolucionar as análises de gráficas... por enquanto o método é caro e nem todos os sites vão poder ter isto (só a placa de captura custa 2000$), mas o que vamos ter é análises detalhadas daquilo que realmente vemos no monitor e não o que o Fraps/motor do jogo dizem que teoricamente vamos ver.


Atenção que isto tudo é sem usar V-Sync. Usando V-Sync, como há um limite máximo (60Hz, por exemplo), o que vamos ter é mais constante, e geralmente resolve alguns desses problemas em vários casos, mas como todos sabem o V-Sync geralmente introduz mais lag e outros eventuais problemas. Daí que tudo isto é um assunto em constante estudo, e os próximos artigos do Ryan Shrout serão focados em uso de tools como o RadeonPro e outras soluções que foram sugeridas entretanto pelo pessoal... tools que controlam / impoem limite de FPS e introduzem métodos que se assemelham ao Dynamic V-Sync usado pelas nVidia.

Sem dúvida algo a acompanhar nas próximas semanas.