CPU VS GPU – Encontrando o Gargalo — Pt 2


Neste post irei discutir um pouco sobre algumas maneiras que temos para perceber se um jogo esta limitado pela CPU ou pela GPU . Irei também falar brevemente sobre como remover gargalos no caso da aplicacão esta limitada pela GPU. (Link para parte 1)

Inicialmente recomendo que o pessoal tenha lido o primeiro tutorial da série.

Em jogos, normalmente encontramos os seguintes tipos de gargalos  :

  1. CPU bound (o processador é o fator limitante no seu jogo)
  2. GPU bound (a placa de vídeo é o fator limitante no seu jogo)
  3. Equilíbrio (CPU e GPU estão sob a mesma carga,praticamente impossível de alcançar em uma execução completa de um jogo)

Nao existe uma maneira simples de detectar se estamos CPU e GPU bounded.

O blog do Shawn Hargreaves contem uma serie de passos que podemos seguir para tentar descobrir em qual caso acima estamos. Irei me basear um pouco no post dele neste artigo, porem sem focar exclusivamente no XNA.

O primeiro e básico passo nesta procura é:

  • Desabilitar qualquer espécie de sistema que controle o frame rate da aplicação. Alguns jogos/engines usam um sistema interno de clock que forcam o FPS a um determinado numero fixo.
  • Desabilitar o V-Sync (vertical synchronization)

Em seguida começamos os testes:

O primeiro é feito para detectar se voce esta CPU Bounding usando um profiler de CPU.

A idéia é ver se o tempo gasto em seu aplicativo percentualmente esta mais concentrado nos métodos que realizam tarefas exclusivamente de CPU (como a maioria dos sistemas de inteligência artificial por exemplo). Se voce encontrar numeros alarmantes nos métodos CPU, voce provavelmente estara CPU BOUNDED. Se voce perceber que uma grande parcela do tempo esta sendo gasta em metodos que realizam operacoes graficas, voce nao poderá concluir que sua aplicacão está GPU BOUNDED (lembre do ultimo post, a tarefa de desenhar uma primitiva é um conjunto de operacões executadas tanto pela CPU quanto pela GPU).

Caso o seu aplicativo esteja gastando muito tempo na funcao chamada Present do DirectX (responsavel por traduzir as chamadas gráficas para o driver de vídeo executa-las (o opengl deve ter uma semelhante), conforme discutido no post anterior), isto pode significar que voce esta GPU Bound (o Present pode estar esperando a GPU terminar de desenhar o frame anterior e por isto estar demorando mais que o normal), porém em alguns casos pode significar que a CPU esta gastando muito tempo para converter as chamadas gráficas em instrucoes para a GPU. Para descobrir em qual caso voce está, a melhor maneira é (infelizmente) alterar o codigo que roda exclusivamente na CPU e verificar o que acontece com o frame rate. Tomar cuidado para não alterar algo que tenha a ver com desenho de primitivas (desenhar depende da GPU e CPU, se voce fizer isto,  nao podera concluir nada com a resposta obtida, deve-se alterar apenas trechos que dependam exclusivamente da CPU ou da GPU)

Um exemplo de alteração possivel é desabilitar uma parte do calculo da IA, se o frame rate nao mudar, voce esta GPU BOUND, se ele mudar sensivelmente voce esta CPU BOUND.

Uma vez que descobrimos que estamos GPU bound, precisamo saber em que estagio da pipeline da GPU esta o nosso gargalo. É interessante utilizar um profiler de GPU como o PerfHud neste caso. Devemos olhar para os graficos que mostram a carga de operacão nas unidades Vertex e Pixel shader (DirectX 9c), além de verificar acesso a texturas e memória utilizada. Esta tarefa é bastante: “experiência, conhecimento da técnica usada e tentativa e erro”, não existe uma receita pronta.

Situação comuns de GPU Bound (e solucões possíveis )são:

  • Ter um Pixel Shader muito complexo. (Não há solucão simples, tente simplificar o algoritmo, usar texturas com valores pré-calculados, prefira se possível passar os cálculas para o Vertex Shader e utilizar os valores interpolados pelo rasterizador)
  • Ter um Vertex Shader muito complexo. (Não há solucão simples, tente simplificar o algoritmo, usar texturas com valores pré-calculados)
  • Efetuar muitas leituras de texturas no Pixel Shader (Não há solucão simples, tente simplificar o algoritmo, usar filtros mais simples como Point ou Linear)
  • Desenhar muitas primitivas diferentes usando shaders diferentes (Efetue na CPU uma ordenação dos objetos a serem desenhados a fim de minimizar a troca de estados da GPU)
  • Desenhar muitas primitivas (considere o uso de instancing para o caso de objetos iguais, tente usar estruturas cache friendly ao armazenar os vértices, considere o uso de estruturas de particão espacial (como uma Octree) para ajudar fazendo Culling na CPU)

A seguir listei os parametros que mais afetam cada um dos estágios da pipeline da GPU, :

Input Assembler

  • Número de vértices enviados
  • Tamanho de cada vértices (quantidade de dados enviado por vértices)
  • O quão ordenado estão os vértices (coerência de cache).

Vertex shader

  • Número de vértices enviados
  • Complexidade do código rodado nesta unidade
  • Quanto ordenados estão os vértices do triângulos para coerência de cache.

Rasterizer

  • Número de pixel renderizado (Resolução da tela)
  • Número de valores a serem interpolados passados do Vertex para o Pixel Shader

Pixel shader

  • Número de pixels renderizados
  • Complexidade do Pixel Shader (funções utilizadas, tamanho, fluxo de dados, complexidade dos algoritmos utilizados)

Texture fetch (leitura de texels)

  • Número de Pixels renderizados
  • Quantidade de leituras de textura por pixel
  • Quantidade de dados de textura lidos da memória
  • Texturas com Mipmap normalmente tem maior coerência de cache
  • Compressão de textura utilizada
  • Tipo de filtros aplicados
  • Anisotrópico é o mais caro
  • Trilinear é a segunda mais lenta
  • Bilinear e Point são as que possuem os menores custos

Depth/stencil testes

  • Número de pixels renderizados
  • Uso de MultiSampling (Antialiasing)
  • Configuração do Depth/Stencil (modo read/write vs. read-only )

FrameBuffer

  • Número de pixel renderizado
  • Uso de MultiSampling
  • Tamanho de cada pixel em termo de bytes (including MRT)
  • Modo read/write (alpha blending) vs. write-only (opaco)

As informacoes acimas foram retiradas de blogs especializados, livros e da minha experiência no assunto.

Uma última dica importante que ouvimos todos os dias, mas ninguém segue. Otimizacão  é feita depois que as coisas já estão funcionando. Otimizacão deve ser feita de maneira inteligente, não adianta absolutamente nada criar o método de busca mais rápido do universo se ele é usado uma única vez pelo seu jogo ( e ainda durante o loading =P). Encontre os gargalos antes !!!!

Até a próxima pessoal =P

 

, , , , ,

  1. #1 by corewmg on 23 de julho de 2017 - 2:00 pm

    ただの妄想だとか、統合失調症のキチガイとか思っている人ばかりです。 熱海パーソナルコンピュータ教室は、静岡県熱海市にある小さなパソコン教室です。 [url=http://softpcjpjp.com/?mode=grp&gid=1342009]produkey office 2010[/url]
    (可逆圧縮コーデックとかも使える)●リーラー・アヴァターラヒンドゥー教において救済の神ヴィシュヌの物質世界への化身バーガヴァタ・プラーナの第1編でヴィシュヌの25のアヴァターラがある第3の化身リシ(賢者・仙人・聖賢)としての【神々しい者】=ナーラダです。 これらが実際にはどういうものになるのか、内容は明らかになっていないが、興味深い。
    [url=http://softpcjpjp.com/?mode=cate&cbid=2087964&csid=0]Adobe Acrobat[/url] )通常でもそんな状態なのに、裏で WindowsUpdateやストアのアプリの更新が勝手に動きだすと、表の作業は全く使えない状態になってしまうから、更新を手動に出来ないWindows10をF-07C で使うのはちょっと無理があるように思えます。 日時がずれる、で思い出すのが…過去にPCのセットアップ作業などをしていたとき、何度トライしてもWindowsアップデートができない状況に遭遇しました。
    [url=http://www.officehb.com/category/Microsoft%20%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%BD%E3%83%95%E3%83%88/Office%20Professional%20Plus%202013]office personal 2013 ダウンロード 版[/url]
    小泉ブームの影響を受け、自民党だけで改選64議席、与党で78議席の大勝。 Security という名前に変更し、ENTER キーを押します。 [url=http://www.office2016jpjp.net/officeprofessionalplus2016-c-2_15.html]office2016 personal 価格[/url]
    わたしたちは、本来の意味での『死の尊厳』を守るためにこれを阻止しなければならないと考えております」。 GanttProject GanttProject はJAVAにより作られたオープンソース+無料なアプリケーションです。
    [url=http://www.ofisu2013.com/]office2016 の プロダクト キー[/url] よってZIPファイルを解凍してファイル作成後上書きしかない。 そのメールには、私のフルネームと正確な固定電話番号が記載されており、金銭を請求しているようです。
    [url=http://softpcjpjp.com/]produkey office 2016[/url]

  2. #2 by Agen judi on 23 de julho de 2017 - 2:09 pm

    Awesome write-up. I am a regular visitor of your web site and appreciate you taking the time to maintain the nice site. I will be a regular visitor for a long time.

  3. #3 by game rts offline terbaru paling seru on 23 de julho de 2017 - 2:58 pm

    Hiya, I am really glad I have found this information. Today bloggers publish just about gossip and web stuff and this is actually annoying. A good web site with exciting content, this is what I need. Thanks for making this site, and I will be visiting again. Do you do newsletters by email?

  4. #4 by Biloxi apartments on 23 de julho de 2017 - 4:53 pm

    The information and facts mentioned within the post are several of the very best accessible

  5. #5 by Biloxi rentals on 23 de julho de 2017 - 5:20 pm

    although web sites we backlink to beneath are considerably not connected to ours, we really feel they may be in fact worth a go via, so have a look

  6. #6 by auto owners insurance Paw Paw MI on 23 de julho de 2017 - 5:29 pm

    I cannot tell a lie, that really helped.

  7. #7 by Car Alarm Miami on 23 de julho de 2017 - 5:34 pm

    WONDERFUL Post.thanks for share..more wait .. 😉 ?

  8. #8 by Car Alarm Miami on 23 de julho de 2017 - 5:41 pm

    Spot on with this write-up, I truly think this website needs much more consideration. I?ll probably be again to read much more, thanks for that info.

  9. #9 by auto owners insurance Longview WA on 23 de julho de 2017 - 6:44 pm

    Well macadamia nuts, how about that.

  10. #10 by http://www.hexpilot.com/help_cartier.aspx on 23 de julho de 2017 - 6:45 pm

    Our system ended up being with that great rates I by no means believed ones quality is so that excellent. It is awesome. This particular mom is going to adore it upon Christmas morning when she opens present and it appears like I spent significantly more, still rates had been just great!!

  11. #11 by temporary carpet protection on 23 de julho de 2017 - 7:30 pm

    here are some links to sites that we link to due to the fact we assume they’re worth visiting

1 684 685 686
(não será publicado)