Gráfica GPU Stuttering

muddymind

1st Folding then Sex
Embora já tenham colocado um dos artigos na thread de AMD news penso que seja tema suficiente para merecer o seu devido tópico visto afectar todas as gráficas (principalmente configurações com mais de uma gráfica).

Para quem não sabe o problema de stuttering consiste em haver frames específicos que têm um tempo de renderização muito elevado relativamente a outros próximos. Isto pode levar a que mesmo que se tenha uma boa média de fps no final, na realidade a experiência é longe do ideal pois o utilizador nota pequenas paragens ou soluços nas animações.

Isto pode dever-se a imensas coisas como operações de IO do sistema operativo, picos de utilização de CPU por outras aplicações, carregamento/libertação de muitos recursos na memória gráfica, etc. O que se veio a descobrir há cerca e um ano e meio com a ajuda do FRAPS é que na realidade havia um stutter sistemático provocado pelos drivers que afectavam com maior notoriedade as gráficas AMD. Isto era especialmente mau em casos SLI/crossfire onde existe um outro fenómeno sistemático de micro-stutter que tem períodos menores mas de menor intensidade (o efeito no utilizador é bastante subjectivo como por exemplo a questão de 75Hz vs 85Hz de refresh rate que é notado por uns e não por outros).


AMD Comments on GPU Stuttering, Offers Driver Roadmap & Perspective on Benchmarking

Neste artigo é explicado com ajuda da AMD a origem do fenómeno e o porquê de o FRAPS não ser grande ajuda para calcular com exactidão o stutter. É explicado também como este problema tem vindo a ser atacado com algum sucesso mas o trabalho está longe de terminado.


FCAT: The Evolution of Frame Interval Benchmarking, Part 1

Neste artigo é apresentada uma ferramenta da nVIDIA para cálculo preciso do stutter. Pode não ser a ferramenta mais simpática de se usar (é necessário uma placa de captura de vídeo para gravar os frames para serem processados posteriormente) mas é considerada como a solução mais exacta de calcular o tempo de renderização de frames pois é com base no que o utilizador vê.

É uma leitura interessante e dá para ver que isto é algo que ainda vai durar pois a solução não é pacífica. Principalmente no caso do micro-stutter onde tenho dúvidas que fique totalmente solucionado.
 
Última edição:
Inside the second with Nvidia's frame capture tools - Techreport

Mais uma vez o Scott Watson volta com uma análise de tempo de renderização de frames, mas agora com a ferramenta da nVidia.
Ainda não li o artigo todo, mas já vi que o FCAT da nVidia apresenta resultados bem diferentes, por analisar os frames no fnal da renderização e não no inicio, como faz o fraps.
Ou seja, o FCAT, mostra o que o jogador vê e sente, enquanto que o Fraps mostra uma estimativa. Acaba por ser a concretização do artigo que o site Anandtech fez em conjunto com a AMD.

Ou seja, apesar de o que o Fraps mostrava sobre as altas latências de renderização nos primeiros artigos, das Radeons, este não era um resultado 100% fidedigno e acabava por aumentar em muito a gravidade do problema.

skyrim-close-7970-fraps.gif


skyrim-close-7970-fcat.gif


Ao ver os testes no Skyrim, outra coisa que o FCAT mostra é que em termos de stutering, em single card, a nVidia e a AMD não estão muito diferentes.
Mas em SLI e Crossfire, a diferença é abismal e muito maior do que o Fraps mostrava. A solução Crossfire tem um resultado muito pior do que a solução SLI.
Mas mesmo considerando o bom resultado do SLI, continua a ser pior do que uma solução single card.

skyrim-close-fcat-680.gif


skyrim-close-fcat-7970.gif


skyrim-close-fcat-680sli.gif


skyrim-close-fcat-7970cf.gif
 
Última edição:
UI!

Afinal parece que o fraps não é assim tão mau como a AMD e a nVIDIA queriam fazer parecer. Se virem nesta página do artigo postado pelo Horus-Anhur afinal há uma desvantagem em analisar o frame completo. Apesar de o FCAT mostrar uma maior estabilidade na cadência dos frames relativamente ao FRAPS no final o resultado continua a ter stutter com ordem de grandeza próxima do valor do FRAPS.

Isto deve-se essencialmente à desproporção a nível do dispatch do rendering do frame (valor analisado pelo FRAPS) afectar o animation steps. Ou seja, mesmo que os frames venham para fora numa cadência relativamente constante a animação não vai ser fluída.
 
Eu não conhecia este priblema até ontem, dia em que fiz um crossfire de hd5850. Foi bastante notório quando joguei far cry 3, tinha montes de lag, algo q nao acontece com o crossfire desligado. É triste...
 
Boas noticias .. ?
Nem por isso pois esse método pode sofrer do problema do meu post anterior onde forçar artificialmente o tempo de render a nível de driver vai provocar problemas de animation steps nas aplicações. Este problema é mais cabeludo do que possa parecer à primeira vista :S
 
O buffering antes de os frames serem mandados para o ecrã acabam por corrigir muitos dos problemas de renderização, seja nas nVidia ou nas AMD. Mas não faz milagres, caso haja um período de renderização anomalamente grande no inicio do pipeline, será provável que este apareça no final do pipeline pela discrepância que esse período introduziu na cadeia toda de renderização.
 
Por ser uma tool da nVidia não deveria ser motivo para aguardar por alguma tool semelhante mas independente? Isto porque há certos benchmarks que favorecem umas marcas em detrimento de outras.
 
Leste ao menos os artigos? É que sinceramente não vejo sequer como seja possível fazer favorecimento para um lado que seja :-D
 
O pessoal ainda se acredita nestas coisas, quer dizer eu já tive tanto amd como nvidia single card equivalentes na mesma altura (gtx460 e hd5850). E para além de a diferença da amd ter por definição melhores cores, não notei qualquer stuttering em nenhuma delas.

Então a olhar para essas tabelas quer dizer que Sli de gtx680 tem menos stuttering que single gtx680, só se for para rir. :lol:
 
Se tivesses lido os artigos do Techreport, Xbixtlabs, Techspot, PCPerspective, da AMD, da nVidia e mais alguns, tinhas percebido que este problema de stutering ocorre apenas na arquitectura GCN e apenas em alguns jogos é que a questão se torna notória.

Se tivesses lido apenas os 2 artigos mais recentes da Techreport e o da Anandtech , com alguma atenção, tinhas percebido a diferença de stuterring medida no inicio e no final do pipeline de renderização.
 
Última edição:
Eu jogava MoH:AA num crt a 100hz com o vsync ligado (e há muito tempo que não vejo fluidez assim) e não sabia o que era isso do stuttering a chatice em alguns jogos era o tearing porque ligando o vsync o rato tinha lag :D


Stutterings e blurs coisas modernas que vieram com tfts e varias gráficas :P
 
Última edição:
A do Guru3D ainda usa apenas o Fraps, ou seja, não é a forma mais realista de interpretar a latência de frames. O ideal é um conjunto de Fraps e FCAT, para perceber o processos de renderização e o que o utilizador vê.
 
Pessoal ainda não percebi uma coisa. O stuttering ocorre tanto com o fraps ligado, como desligado certo? Usa-se o fraps é para testar esse mesmo stuttering correcto?
 
A do Guru3D ainda usa apenas o Fraps, ou seja, não é a forma mais realista de interpretar a latência de frames. O ideal é um conjunto de Fraps e FCAT, para perceber o processos de renderização e o que o utilizador vê.

Sim eu sei disso e tens razão, daí eles dizerem que:

I probably will stop using FRAPS with multi-GPU cards completely, there's a lot going on at AMDs side that is too hard too explain really. I included the results based on the fact that you guys want to see these. But for multi-GPU really, my advise is to ignore this. In the future we'll move towards FCAT benchmarking which will show a lot more in-depth and more reliable.

Fonte: Guru of 3D

Cumpriemntos
 
Leste ao menos os artigos? É que sinceramente não vejo sequer como seja possível fazer favorecimento para um lado que seja :-D

Li por alto, por isso é que perguntei companheiro.

Fazem bem em lançar estas tools de medição, mas acho que também podiam ser a própria nvidia e AMD a lançar alguma informação cá para fora com os testes feitos por eles - com certeza que têm ferramentas ainda mais precisas e poupavam-nos de andar a ver dezenas de reviews (muitas delas mal feitas e completamente enviesadas). Talvez isso lhe convenha, quanto mais reviewers patrocinarem melhor ;).

Mas tools já é bom.
 
Back
Topo