Dúvidas: Java para jogos e mineração?

Assuntos Gerais
#21

É só ver o impacto que uma placa de vídeo tem sobre a qualidade do jogo, e facilmente vc comprova essa afirmação. Lógico, no caso de MMOs ou outros jogos de rede, a própria conexão de rede será um dos principais gargalos.

Mas, a menos que seu jogo tenha perfil de um que exija muito processamento de IA (como um RTS), dificilmente sua CPU e a linguagem será um problema.

Quanto a BI, deixo a questão para outros especialistas.[/quote]

Vini, o problema não é a gpu, mas sim o overhead que um framework causa em cima de outro(java ogre em cima de opengl). A perda de performance é grande. Eu testei o java ogre aqui e não vi muita diferença para sua versão em c++. Mas um teste assim não pode ser comparado com um jogo de mercado ao nível de starcraft2 ou um mmo age of conan.

#22

Não existe perda de performance do ogre em cima de opengl. Pelo contrário, existe ganho.

Primeiro de tudo. Vamos lembrar que, no fundo, existem 2 processadores. A GPU e a CPU. Ambos se comunicam através de memória compartilhada e de um barramento. Essa forma de comunicação é muito lenta, e faze-la de maneira ingênua realmente causa gargalos gigantescos numa aplicação gráfica. E isso sim, é perda de performance.

Também vamos lembrar que a etapa de desenho é muito lenta. A mais lenta que existe num jogo. São milhares de polígonos na tela, transformados, texturizados, iluminados.

Dito tudo isso, é prudente imaginar que o uso de uma GPU também pode ser muito otimizado, já que ela tem caches. Desenhar centenas de vezes o mesmo objeto em sequencia é milhares de vezes mais rápido do que carregar objetos diferentes: mesmo que no final a cena seja a mesma.

Existe também limitações quanto a quantidade de luzes que podem ser ligadas ao mesmo tempo. É mais eficiente desenhar os objetos da frente da cena do que os do fundo primeiro (já que, a placa de vídeo pode evitar totalmente o desenho de objetos eclipsados).

Enquanto um processador está ocupado, o outro pode estar trabalhando. Entretanto, há certas fases que um terá que esperar, pois o trabalho nem sempre pode correr em paralelo. Na maior parte dos jogos, a CPU é o processador que espera. Faz-se todo o desenho, empilha-se os comandos da GPU e espera que tudo seja desenhado.

Para a CPU, todos os comandos de desenho parecem instantaneos. Ele simplesmente os empilha na GPU, que “trava” somente no momento que o comando final de pintura for dado. Como a GPU tem memória, muitas vezes ela empilha 2 ou 3 quadros antes realmente solicitar a CPU que pare.

Enfim… se a CPU está ociosa, podemos dizer que trocar a linguagem lá por uma mais lenta, ou mesmo por uma API inteira, não é um problema. Existe tempo livre lá, e o processador está parado, enquanto o vídeo trabalho. E se usassemos esse tempo para, ao invés de ficarmos parados, implementar toda a otimização que descrevi ali em cima? É o que uma API gráfica, como a Ogre, JMonkeyEngine, a da IDEngine, CryTek fazem. Gasta-se mais CPU, mas poupa-se com isso GPU.

Através de uma classe chamada Scene Manager, essas APIs são capazes de dizer o que vai ser desenhado, quando e como. E tentam organizar para que isso seja feito da melhor forma possível. Ganha-se com GPU, reduz-se a ociosidade da CPU. Seria muitíssimo difícil (embora certamente possível) obter uma performance melhor usando OpenGL diretamente.

Veja que o overhead que você está falando, seja da linguagem ou da biblioteca, está num processador que estaria parado, esperando pelo vídeo. É o que acontece quando otimizamos o lugar errado. Aumentar a velocidade da linguagem, nesse caso, só faria com que a CPU esperasse o desenho por mais tempo. Numa aplicação, seja ela qual for, temos que atacar o maior gargalo, não coisas que parecem menos eficientes, mas não são o problema.

Cabe aqui uma analogia. Imagine que vc tem 1 pedreiro e um auxiliar. O pedreiro (A GPU) está construindo uma parede. O auxiliar (a CPU) está levando o material para o primeiro. A GPU é lenta, empilha devagar os tijolos. O outro, busca os sacos de cimento e os tijolos e os dispõe numa área comum, entre ambos. Como ele é muito mais rápido, frequentemente essa área comum enche e ele é obrigado a esperar que mais tijolos sejam empilhados. Nessa hora ele senta, toma um café e fica completamente parado.

Se você trocar o um auxiliar por um que corre até o saco de cimento duas vezes mais rápido, só que vai ter é esse sujeito parado por mais tempo. Afinal, a montagem da parede não se acelerará por causa disso e é ali que está nosso problema.

Agora, imagine que você troque por um auxiliar mais inteligente. Ele não traz os sacos mais rapidamente, de fato, ele é até um pouco mais lento. Porém, ele usa seu tempo livre para dispor o material de modo que fique muito mais fácil para o pedreiro que constrói a parede. Ele já deixa os materiais para fazer a massa lado-a-lado, mantém o material de trabalho do pedreiro próximo as mãos dele e evita ao máximo que esse pedreiro perca tempo desnecessário. Por exemplo, ele poderia trazer primeiro todos os tijolos, e só depois todos os azulejos, evitando que o pedreiro tenha que alternar entre as construções de ambos desnecessariamente.

Consequentemente, o sujeito construindo a parede ganha 30% até 40% de rendimento. As pausas para o café do auxiliar ainda existem, mas como o pedreiro é mais rápido, elas agora são muito menos freqüêntes. Entretanto, não só ambos se mantém ocupados, como o trabalho final sai mais rápido e mais bem-feito.

#23

Não quis dizer o ogre nativo. Disse o java ogre. O nativo usa a opengl diretamente. O java usa o framework ogre através de jni, que por sua vez usa opengl. Ae que eu queria saber se vai realmente dar uma grande diferença, prq pequena, já dá.

Mas enfim, vi o quake2 portado para java, e ficou realmente muito bom.

#24

[quote=ViniGodoy]
Não existe perda de performance do ogre em cima de opengl. Pelo contrário, existe ganho.

Primeiro de tudo. Vamos lembrar que, no fundo, existem 2 processadores. A GPU e a CPU. Ambos se comunicam através de memória compartilhada e de um barramento. Essa forma de comunicação é muito lenta, e faze-la de maneira ingênua realmente causa gargalos gigantescos numa aplicação gráfica. E isso sim, é perda de performance.

Também vamos lembrar que a etapa de desenho é muito lenta. A mais lenta que existe num jogo. São milhares de polígonos na tela, transformados, texturizados, iluminados.

Dito tudo isso, é prudente imaginar que o uso de uma GPU também pode ser muito otimizado, já que ela tem caches. Desenhar centenas de vezes o mesmo objeto em sequencia é milhares de vezes mais rápido do que carregar objetos diferentes: mesmo que no final a cena seja a mesma.

Existe também limitações quanto a quantidade de luzes que podem ser ligadas ao mesmo tempo. É mais eficiente desenhar os objetos da frente da cena do que os do fundo primeiro (já que, a placa de vídeo pode evitar totalmente o desenho de objetos eclipsados).

Enquanto um processador está ocupado, o outro pode estar trabalhando. Entretanto, há certas fases que um terá que esperar, pois o trabalho nem sempre pode correr em paralelo. Na maior parte dos jogos, a CPU é o processador que espera. Faz-se todo o desenho, empilha-se os comandos da GPU e espera que tudo seja desenhado.

Para a CPU, todos os comandos de desenho parecem instantaneos. Ele simplesmente os empilha na GPU, que “trava” somente no momento que o comando final de pintura for dado. Como a GPU tem memória, muitas vezes ela empilha 2 ou 3 quadros antes realmente solicitar a CPU que pare.

Enfim… se a CPU está ociosa, podemos dizer que trocar a linguagem lá por uma mais lenta, ou mesmo por uma API inteira, não é um problema. Existe tempo livre lá, e o processador está parado, enquanto o vídeo trabalho. E se usassemos esse tempo para, ao invés de ficarmos parados, implementar toda a otimização que descrevi ali em cima? É o que uma API gráfica, como a Ogre, JMonkeyEngine, a da IDEngine, CryTek fazem. Gasta-se mais CPU, mas poupa-se com isso GPU.

Através de uma classe chamada Scene Manager, essas APIs são capazes de dizer o que vai ser desenhado, quando e como. E tentam organizar para que isso seja feito da melhor forma possível. Ganha-se com GPU, reduz-se a ociosidade da CPU. Seria muitíssimo difícil (embora certamente possível) obter uma performance melhor usando OpenGL diretamente.

Veja que o overhead que você está falando, seja da linguagem ou da biblioteca, está num processador que estaria parado, esperando pelo vídeo. É o que acontece quando otimizamos o lugar errado. Aumentar a velocidade da linguagem, nesse caso, só faria com que a CPU esperasse o desenho por mais tempo. Numa aplicação, seja ela qual for, temos que atacar o maior gargalo, não coisas que parecem menos eficientes, mas não são o problema.

Cabe aqui uma analogia. Imagine que vc tem 1 pedreiro e um auxiliar. O pedreiro (A GPU) está construindo uma parede. O auxiliar (a CPU) está levando o material para o primeiro. A GPU é lenta, empilha devagar os tijolos. O outro, busca os sacos de cimento e os tijolos e os dispõe numa área comum, entre ambos. Como ele é muito mais rápido, frequentemente essa área comum enche e ele é obrigado a esperar que mais tijolos sejam empilhados. Nessa hora ele senta, toma um café e fica completamente parado.

Se você trocar o um auxiliar por um que corre até o saco de cimento duas vezes mais rápido, só que vai ter é esse sujeito parado por mais tempo. Afinal, a montagem da parede não se acelerará por causa disso e é ali que está nosso problema.

Agora, imagine que você troque por um auxiliar mais inteligente. Ele não traz os sacos mais rapidamente, de fato, ele é até um pouco mais lento. Porém, ele usa seu tempo livre para dispor o material de modo que fique muito mais fácil para o pedreiro que constrói a parede. Ele já deixa os materiais para fazer a massa lado-a-lado, mantém o material de trabalho do pedreiro próximo as mãos dele e evita ao máximo que esse pedreiro perca tempo desnecessário. Por exemplo, ele poderia trazer primeiro todos os tijolos, e só depois todos os azulejos, evitando que o pedreiro tenha que alternar entre as construções de ambos desnecessariamente.

Consequentemente, o sujeito construindo a parede ganha 30% até 40% de rendimento. As pausas para o café do auxiliar ainda existem, mas como o pedreiro é mais rápido, elas agora são muito menos freqüêntes. Entretanto, não só ambos se mantém ocupados, como o trabalho final sai mais rápido e mais bem-feito.[/quote]

clap clap clap :shock:

#25