Pilha de matriz do OpenGL vs multiplicação manual

8

O que é mais eficiente usando a pilha de transformação do OpenGL ou aplicando as transformações manualmente.

Ouvi muitas vezes que você deve minimizar o número de transições de estado no seu pipeline de gráficos. Pressionar e exibir matrizes de tradução parece uma grande mudança. No entanto, gostaria de saber se a placa de vídeo pode mais do que compensar o soluço do pipeline usando seu hardware de execução paralela para multiplicar em massa os vértices.

Meu caso específico. Eu tenho fonte renderizada em uma folha de sprite. As coordenadas de cada caractere ou sequência são calculadas e adicionadas a um buffer de vértice. Agora eu preciso mover essa corda. Seria melhor percorrer o buffer de vértice e ajustar cada um dos vértices manualmente ou enviar temporariamente uma nova matriz de conversão?

opengl optimization opengl-es fonts deft_code
fonte
Depende da versão contábil que você está alvejando. Eles estão obsoletos no 3.xe em diante.
O pato comunista

Respostas:

7

Entendo que nas versões mais recentes das especificações (3.3 e 4.x) as pilhas de matriz se foram e você precisa acompanhar suas matrizes de transformação manualmente. Acredito que isso possa ser verdade também para as especificações para dispositivos móveis (ES).

Se você está procurando uma maneira consistente de lidar com suas matrizes manualmente, pode estar interessado no GLM . É uma biblioteca matemática bastante elegante (que inclui transformações de matriz) modelada após a especificação GLSL, portanto, você só precisa manter um conjunto de rotinas matemáticas em mente ao lidar com o código OpenGL.

Bob Somers
fonte
alguém pode confirmar isso? Aprendi programação gráfica com o OpenGL 1.5 e achei que era avançado porque estava experimentando alguns dos recursos do 2.0. Você pode dizer que estou um pouco fora do circuito. A retirada do suporte para matrizes de tradução parece ser uma enorme desvantagem.
Deft_code
11
Apenas verificado. Sim, as pilhas da matriz foram descontinuadas em 3.0 - 3.2 e removidas em 3.3 e 4.x. A idéia é que, como todo o pipeline se tornou programável, você apenas passa sua matriz final para o shader e parte daí. Não há nada para impedir que você continue com o OpenGL 2.0. Toda a funcionalidade da pilha de matrizes a que você está acostumado ainda estará lá.
Bob Somers
Observe que isso não significa que "o suporte para matrizes de conversão" foi descartado, @deft_code. Uma matriz de conversão é apenas um conjunto específico de valores de ponto flutuante, afinal, você pode criar um trivialmente. É mais na área da "álgebra linear" do que no acesso ao pipeline gráfico - observe que o D3D também não tem funções análogas (eles estão em uma biblioteca de utilitários separada, o D3DX).
11
Além disso: GLES 1.x é o análogo de funcionalidade fixa do OpenGL 1.5 (ish) e inclui as pilhas de textura, visualização de modelo e projeção. O GLES 2.x é o OpenGL incorporado totalmente programável e não inclui as operações da matriz, nem todo o restante do pipeline de funcionalidade fixa. Portanto, no GLSL também não há gl_Vertex / Normal / Color / etc. A decisão de como você passa as informações para um programa de sombreador é inteiramente sua.
Tommy
3

A pilha é a opção menos ideal aqui - não porque empurrar e estourá-la era cara, pois nunca deveria induzir uma alteração complexa no estado do driver (a matriz não deve ser enviada para o cartão até que um comando de renderização seja emitido , portanto, é tudo manipulação da CPU na API, geralmente).

O problema com a pilha é que ela tem um limite de quão longe você pode empurrá-la - é um dos parâmetros que você pode obter via glGet *, eu acho. Não há grande vantagem em usar a pilha, a menos que você não tenha ou seja incapaz / não queira escrever matemática matricial. Eu recomendaria fazer você mesmo.

Não sei qual é o estado das funções da pilha no GL moderno. Acredito que eles tenham sido descontinuados / removidos também, mas não preciso usar o GL há algum tempo, por isso não me mantenho atualizado.


fonte
3

Como outros observaram, a pilha de matrizes está saindo, o que é um bom motivo para investigar alternativas.

Em um dos meus projetos, usei as operações de matriz do OpenGL para calcular minhas matrizes, mas acabei tendo que usar as funções glGet para buscar a matriz de volta, para que eu pudesse fazer algumas operações na matriz que as próprias funções do OpenGL não suportavam. O desempenho foi péssimo, e eu tracei a perda para a função glGet única. É possível que as operações da matriz sejam realmente executadas na GPU de alguma forma e o uso do glGet tenha causado a descarga do pipeline, ou algo assim.

Qualquer que seja o motivo, substituí as operações da matriz pela CML , a biblioteca matemática configurável e o desempenho melhorou drasticamente. Além de não estar mais vinculado às métricas de desempenho das operações da matriz OpenGL, a CML também incluiu toneladas de operações que o OpenGL não suporta.

E implementar uma pilha de matrizes é muito fácil usando o vetor STL ou algo assim.

Jari Komppa
fonte
2

Não tenho certeza do seu nível de experiência, mas recomendo fazê-lo manualmente. Pode ser necessário mais esforço para aprender como fazer isso, mas é imensamente benéfico saber o que suas matrizes estão fazendo e poder manipulá-las você mesmo. Também o tornará mais ciente dos problemas que podem surgir ao aplicar matrizes em diferentes ordens (por exemplo, dimensionamento e rotação). Eu sei que passei muitas horas tentando descobrir "erros" estranhos de renderização antes de decidir que meu tempo seria melhor gasto estudando minuciosamente o que cada operação estava fazendo. Vale a pena o investimento.

Resolvendo um problema específico, aplicar uma transformação aos vértices parece a maneira mais fácil, basta estar ciente da ordem das operações das matrizes.

kaunartist
fonte
1

O principal problema que vejo é que você precisa acessar os resultados para outras tarefas do jogo e acessá-los pode ser complicado e lento.

É por isso que eu prefiro fazer essas operações de matriz.

bcsanches
fonte