Como otimizar o desempenho de um programa quando nenhuma ferramenta de criação de perfil está disponível?


8

Atualmente, estou trabalhando em um programa OpenGl cujo desempenho eu gostaria de melhorar. O desempenho é bom, mas não é ideal em GPUs dedicadas poderosas, mas é péssimo em gráficos integrados (<10 fps). Em um programa normal (baseado na CPU, sem OpenGl ou outra API de GPU), eu executava um criador de perfil (talvez o incorporado ao CLion) no programa, veria onde a maior parte do tempo é gasto e depois trabalharia em um algoritmo melhor para essas áreas ou encontre uma maneira de reduzir a quantidade que essa área é chamada.

O uso dessa técnica no meu programa OpenGl mostra que a grande maioria do tempo do programa (~ 86%) em seu thread principal (o que eu quero otimizar) é gasto no arquivo .so do driver OpenGl. Além disso, o uso da CPU do programa durante a execução é muito baixo, mas o uso da GPU fica entre 95% e 100%. Juntas, essas informações me dizem que o gargalo está na GPU, e é aí que devo otimizar.

É aqui que ocorre um problema. Porém, minha técnica normal de usar um criador de perfil para orientar minhas otimizações não funcionará sem o criador de perfil de GPU específico. Como tal, fiz algumas pesquisas para encontrar um criador de perfil que me diga onde está sendo gasto o tempo de processamento da GPU. Não consegui encontrar nada que seja remotamente utilizável. Tudo era apenas para Windows (eu executo exclusivamente Linux, e meu programa ainda não foi portado para Windows - nem será até muito tempo depois), não é mais atualizado e / ou custa muito mais do que o orçamento para esse projeto é

Como tal, pergunto: como otimizar o desempenho do meu programa quando o criador de perfil relevante não existe? Tentei adivinhar onde estão os problemas e otimizar a partir disso, no entanto, não fez nenhuma diferença, embora eu tenha conseguido verificar que minhas otimizações (seleção de frustum) resultaram em menos trabalho para a GPU pela metade. Uma boa resposta fornecerá alguma técnica de criação de perfil aplicável ao Opengl no Linux ou uma técnica que funcione sem um criador de perfil.


a maneira antiquada de comentar coisas até que você encontre a parte mais lenta?
Ewan

@ wan o renderizador é bastante mínimo. Comentar anyrhing out faria com que não funcionasse.
9139 John Jund

Quanto à parte "comentando coisas", você pode dividir o código em seções e comentar tudo, exceto a primeira seção. Essas seções devem ter alguma saída para verificar se funciona conforme o esperado. Depois disso, você pode percorrer as seções para ver se essa peça é o gargalo em potencial. Com essa abordagem, você conclui o estilo básico de tentativa e erro.
eparham7861 9/06/19

Se você tiver acesso a um pino de hardware na GPU, poderá alterná-lo na entrada e sair para as funções. Um osciloscópio indicará o tempo gasto nessa função e com que frequência é chamado etc.
Ant

Respostas:


7

como otimizar o desempenho do meu programa quando o criador de perfil relevante não existe?

Ao traçar seu próprio código. Encontrar gargalos na GPU não é particularmente difícil.

Supondo que você tenha uma versão inferior do OpenGL ( consultas com timer não estão disponíveis), faça o que as pessoas vêm fazendo há anos: mude as coisas e veja como elas funcionam.

Existem três locais básicos para gargalos na renderização: CPU (ou seja: envio de dados ineficientemente), T&L de vértices e processamento por fragmento. Determinar qual é o gargalo é apenas uma questão de ver o impacto no desempenho quando você altera alguma coisa.

Por exemplo, se você quiser ver se o processamento por fragmento é um gargalo, reduza o número de fragmentos gerados (por exemplo: a resolução da tela). Se o desempenho melhorar a uma taxa linear em relação ao número de pixels na resolução da tela, esse foi o seu gargalo.

Se você quiser saber se o processamento do vértice é o gargalo, renderize o mesmo objeto várias vezes (uma após a outra). Supondo que você tenha um teste de profundidade ativo e não esteja misturando, os fragmentos das renderizações subsequentes devem ser descartados antes de chamar o shader de fragmento. Portanto, se o desempenho diminuir linearmente ao renderizar repetidamente todos os objetos, você terá um gargalo no processamento do vértice.

E se nenhum desses for o gargalo, então pelo processo de eliminação, a CPU é o problema.

Se você tiver acesso a consultas de timer, poderá programar diretamente as operações da GPU. Você não pode cronometrar estágios específicos, mas pode determinar o tempo necessário para a conclusão dos comandos da GPU. Você também pode encontrar a latência entre a conclusão do comando GPU e quando o thread da CPU terminou de enviar esses comandos. No geral, eles devem ajudá-lo a dizer quanto tempo leva para a GPU processar as coisas em comparação com a CPU que a envia.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.