Pela aparência, agora cada glSet deve incluir glBind (algo) dentro dele
Não exatamente. É o contrário, como descrito em vários parágrafos abaixo.
Mesmo se isso fosse verdade, lembre-se de que os comandos GL do aplicativo cliente para o servidor GL (também conhecido como driver) têm muita sobrecarga de despacho em comparação com uma chamada de função regular. Mesmo se assumirmos que as funções DSA são apenas invólucros em torno das funções existentes, eles são invólucros que vivem dentro do servidor GL e, portanto, podem ter (um pouco) menos sobrecarga.
se o OpenGL ainda é uma máquina de estado, não pode tirar proveito das alterações transmitidas aplicadas a um único item.
GPUs não são máquinas de estado. A interface da máquina de estado GL é uma emulação que envolve os drivers do tipo DSA, e não o contrário.
A remoção de uma camada de quebra automática - uma camada que requer um número excessivo de chamadas no servidor GL - é claramente uma vitória, mesmo que pequena.
A abordagem da máquina de estado também não faz muito sentido ao lidar com vários threads; A GL ainda é péssima nesse caso de uso, mas os drivers costumam usar threads nos bastidores, e uma máquina de estado exige muita sincronização de threads ou algoritmos / construções paralelos realmente sofisticados para fazer as coisas funcionarem de maneira confiável.
A extensão DSA continua expressando sua operação em termos de alterações de estado porque, afinal, é uma extensão de um documento baseado em estado existente e não uma API totalmente nova, portanto, precisava estar pronto para se conectar à especificação GL existente linguagem e terminologia do documento. Mesmo que essa linguagem existente seja bastante adequada ao seu trabalho como uma API de hardware gráfico moderna.
Por favor, explique o raciocínio e as vantagens do novo DSA.
O maior raciocínio é que a maneira antiga era uma dor. Tornou muito difícil compor bibliotecas em conjunto que pudessem modificar ou confiar no estado GL. Isso dificultou o empacotamento eficiente da API GL em um estilo orientado a objeto ou funcional devido às suas raízes profundas de gerenciamento de estado processual, o que dificultou o empacotamento da API em várias linguagens não C e também o fornecimento de empacotadores de dispositivos gráficos eficientes esse OpenGL abstrato do Direct3D.
O segundo foi a sobrecarga da API de máquina de estado processual, conforme descrito anteriormente.
Terceiro, as funções do DSA alteraram a semântica, quando apropriado, das APIs antigas que permitiam maior eficiência. Coisas que antes eram mutáveis se tornaram imutáveis, por exemplo, o que remove muitos códigos de contabilidade do servidor GL. As chamadas do aplicativo podem ser enviadas para o hardware ou validadas mais cedo (ou em modas mais paralelas) quando o servidor GL não precisar lidar com objetos mutáveis.
-
Justificativa e explicação adicionais são fornecidas na especificação de extensão EXT_direct_state_access .
-
As alterações de hardware relevantes para o design da API são bastante numerosas.
Lembre-se de que o OpenGL remonta a 1991. O hardware alvo não eram placas gráficas de nível consumidor (elas não existiam), mas grandes estações de trabalho CAD e similares. O hardware daquela época tinha envelopes de desempenho muito diferentes dos atuais; o multi-threading era mais raro, os barramentos de memória e as CPUs tinham menos brechas de velocidade e a GPU fazia pouco mais do que a renderização de triângulo de função fixa.
Mais e mais recursos de função fixa foram adicionados. Vários modelos de iluminação, modos de textura etc. foram todos adicionados, cada um precisando de seu próprio estado. A abordagem simples baseada em estado funcionou quando você tinha vários estados. À medida que mais e mais estados foram adicionados, a API começou a explodir nas costuras. A API tornou-se mais complicada, mas não divergiu muito dos modos de hardware, pois eram realmente baseadas em muitas opções de estado.
Então, veio o hardware programável. O hardware tornou-se cada vez mais programável, a ponto de agora, o hardware suportar um pouco de estado, alguns programas fornecidos pelo usuário e muitos buffers. Todo esse estado da época anterior tinha que ser emulado, assim como todos os recursos de função fixa daquela época estavam sendo emulados pelos motoristas.
O hardware também mudou para ficar cada vez mais paralelo. Isso exigiu outras reformulações de hardware que tornaram as alterações de estado dos gráficos muito caras. O hardware funciona em grandes blocos de estado imutável. Devido a essas alterações, o driver não pôde simplesmente aplicar cada pedacinho do estado que o usuário definiu imediatamente, mas teve que agrupar as alterações automaticamente e aplicá-las quando necessário implicitamente.
O hardware moderno opera ainda mais do modelo clássico OpenGL. O DSA é uma pequena mudança necessária há mais de 10 anos (foi originalmente prometida como parte do OpenGL 3.0), semelhante ao que o D3D10 fez. Muitas das alterações de hardware acima precisam muito mais do que apenas o DSA para manter o OpenGL relevante, e é por isso que ainda estão disponíveis grandes extensões que alteram drasticamente o modelo OpenGL . Depois, há toda a nova API GLnext, além de D3D12, Mantle, Metal, etc. nenhuma delas mantém a abstração obsoleta da máquina de estado.