Uma ´ unica m´ aquina remota

Esta se¸c˜ao apresenta os primeiros resultados obtidos com o driver OpenGL modificado, sendo as suas fun¸c˜oes transferidas pela rede Ethernet. Neste caso de uso, foram utilizados dois computadores iguais: um deles para a aplica¸c˜ao e o outro somente para a exibi¸c˜ao do conte´udo.

Os tempos m´edios de renderiza¸c˜ao est˜ao representados na figura 25, e seus valores na tabela 5. Apesar desta infraestrutura n˜ao representar um sistema imersivo real, os valores obtidos nos permitem analisar o overhead do driver OpenGL e de sua respectiva abstra¸c˜ao da rede. Esta compara¸c˜ao pode ser realizada, pois a imagem obtida nesta configura¸c˜ao ´e exatamente igual `a obtida com um ´unico computador local. Em ambos os casos, a imagem ´e exibida em dois projetores DepthQ, na mesma resolu¸c˜ao e com o mesmo frustum de visualiza¸c˜ao.

Sendo assim, ´e poss´ıvel observar o impacto da distribui¸c˜ao no desempenho das al- ternativas mais convencionais de renderiza¸c˜ao. No caso do modo ubosub cpucull com 64 modelos, por exemplo, o desempenho piorou, em m´edia, mais de 600%, reduzindo consid- eravelmente o n´umero de quadros renderizados por segundo, quando comparado com um computador local.

´

E importante notar que embora exista uma comunica¸c˜ao atrav´es da rede, a maioria das informa¸c˜oes n˜ao s˜ao de fato enviadas, uma vez que o driver utiliza uma codifica¸c˜ao

Tabela 5: Tempo m´edio de renderiza¸c˜ao com 1 m´aquina remota (milissegundos). Qtd. de modelos Modos de renderiza¸c˜ao 1 27 64 125 ubosub 5.02 124.74 297.47 579.60 ubosub cpucull 5.59 74.21 188.83 329.32 uborange 5.09 87.71 209.81 410.92 uborange cpucull 2.89 25.05 68.16 113.16 indexedmdi 3.16 25.00 55.85 108.42 indexedmdi gpucull 2.94 16.11 35.57 67.57 indexedmdi unified 3.16 23.64 51.74 98.21 indexedmdi unified gpucull 2.93 14.55 30.90 56.51

em delta, onde apenas as informa¸c˜oes diferentes do quadro anterior s˜ao transferidas. No entanto, grande parte da perda de desempenho ´e causada pelo processo de verifica¸c˜ao, onde todas as informa¸c˜oes do quadro corrente precisam ser comparadas com as do quadro anterior.

Apesar de existir um overhead estabelecido pela comunica¸c˜ao e pelo sincronismo, este overhead pode ser dilu´ıdo ao utilizar um conjunto maior de objetos, juntamente com as t´ecnicas mais modernas de renderiza¸c˜ao discutidas neste trabalho. Este fato pode ser observado, por exemplo, no modo indexedmdi, onde para um ´unico modelo o desempenho piorou em 18%, por´em para 125 modelos, o impacto foi de apenas 7%.

Outro fato interessante pode ser observado nos modos indexedmdi gpucull e indexed- mdi unified gpucull, onde a renderiza¸c˜ao indireta ´e utilizada junto com o culling na GPU. No benchmark com uma m´aquina local, estes modos apresentaram desempenho inferior aos modos tradicionais, em fun¸c˜ao algoritmo do culling. No entanto, ao introduzir a rede como elemento intermedi´ario de comunica¸c˜ao, o desempenho das t´ecnicas modernas apresentam resultados extremamente vantajosos.

Al´em disto, especificamente no modo indexedmdi unified gpucull, a aplica¸c˜ao apresen- tou melhora de desempenho no caso distribu´ıdo, quando comparado com uma m´aquina local. Apesar de n˜ao ter sido antecipado, este comportamento pode ser explicado atrav´es de um grau reduzido de paralelismo, obtido atrav´es da execu¸c˜ao de tarefas distintas nas duas m´aquinas do teste.

No caso espec´ıfico da cena com 125 modelos, o tempo de renderiza¸c˜ao reduziu quase 8%. Entre os motivos identificados para este grau de paralelismo, podemos mencionar por exemplo, o fato de que quando o algoritmo de culling na GPU est´a habilitado, o mesmo faz uso de uma barreira de mem´oria. Esta barreira na GPU existe para garantir que a

Figura 26: Taxa de transferˆencia na rede. 1 27 64 125 0 0.5 1 ·104 Modelos 3D K B/s

ubosub ubosub cpucull

uborange uborange cpucull

indexedmdi indexedmdi gpucull

indexedmdi unified indexedmdi unified gpucull

solicita¸c˜ao de renderiza¸c˜ao seja executada apenas ap´os a conclus˜ao do algoritmo de culling. No entanto, ao executar a aplica¸c˜ao em um sistema distribu´ıdo, a barreira introduzida pelo algoritmo afeta apenas a m´aquina respons´avel pela exibi¸c˜ao, garantindo que a m´aquina da aplica¸c˜ao seja liberada para executar outras instru¸c˜oes. Este fato promove certo grau de paralelismo, criando oportunidade para um ganho marginal de desempenho.

Novamente, as vantagens das t´ecnicas mais modernas de renderiza¸c˜ao s˜ao evidenci- adas em cenas mais complexas. Considerando o caso com 64 modelos, por exemplo, um modo como o ubosub cpucull funciona com uma taxa inferior a 6 quadros/segundo. O modo uborange cpucull proporciona uma melhora consider´avel, operando `a 14 quadros/se- gundo. No entanto, ambos com o desempenho aqu´em do considerado satisfat´orio. O modo indexedmdi unified gpucull, por sua vez, proporciona um desempenho bem melhor, a 32 quadros/segundo.

A figura 26 apresenta a taxa de transferˆencia utilizada na rede por cada modo de renderiza¸c˜ao. Em fun¸c˜ao das otimiza¸c˜oes aplicadas pelo driver, principalmente devido `a codifica¸c˜ao em delta, pouca informa¸c˜ao ´e de fato transferida.

Conforme pode ser observado na figura, apenas os modos de renderiza¸c˜ao ubosub - cpucull e uborange cpucull apresentam taxa de transferˆencia com valores significativos. Isto ocorre pois estes s˜ao os ´unicos modos que utilizam culling na CPU. Ao utilizar este algoritmo de culling, as chamadas do OpenGL, enviadas atrav´es da rede, sofrem mu- dan¸cas constantes em fun¸c˜ao de altera¸c˜oes na posi¸c˜ao da cˆamera e, consequentemente, no conjunto de objetos vis´ıveis. Estas altera¸c˜oes prejudicam o recurso de codifica¸c˜ao em

delta praticado pelo driver, o que aumenta consideravelmente as informa¸c˜oes enviadas na rede. Mesmo assim, a taxa de transferˆencia ´e relativamente pequena, sempre inferior a 10 MB/s.

Os modos que n˜ao possuem frustum culling habilitado sempre renderizam todos os objetos da cena, independente da posi¸c˜ao da cˆamera. Embora esta abordagem deteriore o desempenho gr´afico da aplica¸c˜ao, a mesma garante certa uniformidade nas chamadas de fun¸c˜ao OpenGL entre quadros consecutivos, o que facilita o recurso de codifica¸c˜ao em delta e, consequentemente, reduz a taxa de transferˆencia nestes modos. Nas outras alternativas, que utilizam culling na GPU, a justificativa ´e semelhante - o algoritmo de culling n˜ao altera de forma significativa as chamadas OpenGL efetuadas pela aplica¸c˜ao, uma vez que o algoritmo ´e executado diretamente na GPU. Sendo assim, esta ´ultima abordagem tamb´em facilita o recurso de codifica¸c˜ao em delta.

Para melhor investigar a influˆencia da latˆencia da rede sobre o desempenho da apli- ca¸c˜ao, selecionou-se a alternativa com maior taxa de transferˆencia m´edia: o modo ubosub - cpucull com 27 modelos na cena. Nesta situa¸c˜ao, a aplica¸c˜ao possui taxa de transferˆencia inferior a 8 MB/s. Para aferir a latˆencia, o comando ping foi utilizado para realizar me- didas de RTT (round-trip time) na mesma infraestrutura onde s˜ao executados os testes gr´aficos. Este comando foi utilizado transferindo pacotes de 64 KB em intervalos de 8 ms. Estes parˆametros aproximam o perfil de uso da rede efetuado pela aplica¸c˜ao. Neste cen´ario, o valor m´edio obtido para o RTT foi de 2 ms e desvio padr˜ao de 0.4 ms.

Sendo assim, pode-se concluir que grande parte do overhead da aplica¸c˜ao ocorre na intercepta¸c˜ao e no processamento das chamadas OpenGL, dentro do driver adaptado. Ao reduzir o n´umero destas chamadas utilizando um mecanismo moderno de renderiza¸c˜ao, por exemplo, o impacto no desempenho da aplica¸c˜ao ´e reduzido de forma significativa, podendo at´e promover um ganho de desempenho, como observado na alternativa indexed- mdi unified gpucull.