Directx 10

Directx?
Microsoft DirectX é uma coleção de APIs que tratam de tarefas relacionadas a programação de jogos para o sistema operacional Microsoft Windows, aumentando principalmente no desempenho grafico do jogo. O DirectX foi inicialmente distribuido pelos criadores de jogos junto com seus produtos, mas depois foi incluido no Windows.
Inciar>Executar. Depois digite "Dxdiag" (sem aspas). Nas "Informações do sistema", na última linha haverá a "Versão do DirectX", onde mostra que versão você está utilizando.

* DirectX 1.0: 4.02.0095
* DirectX 2.0: 2.0a 4.03.00.1096
* DirectX 3.0: 3.0a 4.04.0068
* DirectX 5.0: 4.05.01.1721 (lançado no Windows 98)
* DirectX 6.0: 4.06.02.0436 (lançado no Windows 98 SE)
* DirectX 7.0: 4.07.00.0700 (lançado no Windows 2000 e Windows ME)
* DirectX 8.0: 4.08.00.0400
* DirectX 8.1: 4.08.01.0811 (lançado no Windows XP e Windows Server 2003)
* DirectX 9.0: 4.09.0000.0900
* DirectX 9.0a: 4.09.0000.0901
* DirectX 9.0b: 4.09.0000.0902
* DirectX 9.0c: 4.09.0000.0904 (última versão)
* DirectX 9.0l: (L para legacy, implementação do DX9 para windows Vista)
* DirectX 10.0

* Não há uma versão 4.


a questão eh que o directx 10 é uma versão diferente de todas, as placas foram criadas e programas para suportar o mesmo..."Geforce NX8800GTs e o direct 3D criada pela base da OpenGL, sendo assim beneficia as ferramentas da SGI (Silicon Graphics).

Assim: A nova API entra em contradição com a compatibilidade aos recursos mais avançados e um jogo Direct3D 10 só poderá rodar com uma placa gráfica Direct3D 10.
OU: os desenvolvedores terão que oferecer um executável diferente para atualizar as bibliotecas do DirectX 9.



Windows Vista trouxe o DirectX 10 e o lançamento do Service Pack 1 trará o DirectX 10.1.

Para a Microsoft, a ocasião para fornecer especificações detalhadas sobre o antialiasing e dar maior controle aos desenvolvedores nesse nível, o que não foi incorporado no DirectX 10 para não atrasar sua disponibilidade. É possível que os chips G80 da NVIDIA e o R600 da ATI/AMD suportem uma gestão avançada dos recursos de antialiasing.
No directx 9 quase não percebe-se o "antialiasing", o DirecTX 10.1 O.o
Direct3D 10.1 representará a uma evolução das unidades fixas restantes das GPUs, antes de torná-las completamente programáveis numa futura versão.

Para compreender melhor a interação dessa arquitetura, vamos a um exemplo concreto: sob o Windows XP, quando um comando é executado, este ao ser enviado à GPU, passa pelo runtime Direct3D, este fornecido pela Microsoft e sem nenhum conhecimento da GPU. Assim, cria-se um buffer DMA abstrato que passa seguidamente ao driver que tem as informações do “hardware” e deste modo, ele aborta a interpretação do buffer recebido e recodifica em um formato específico à GPU.



Uma pergunta óbvia: por que não enviar cada comando direto ao driver? É porque esse driver encontra-se no espaço do núcleo, ao contrário da aplicação que se está no espaço usuário. Essa mudança carrega muito a CPU. A API procura eliminar esse problema preenchendo os buffers de comando com várias execuções antes de enviá-los ao driver. Em resumo, entre as duas opções, os engenheiros escolheram a menos grave. Apesar desta fase de encodificação/decodificação intermediária, tem um custo e é isto o que o novo modelo de driver procura eliminar.



Assim quando a aplicação executa um comando Direct3D, esta passou pelo runtime, mas ao invés de encodificá-lo em formato abstrato, evoca o driver situado no espaço usuário que compila diretamente um buffer DMA interpretável pelo “hardware”. Outra vantagem desta arquitetura é que a maior parte do trabalho é efetuada pelo driver que reside em espaço usuário. O driver núcleo não precisa se ocupar de tarefas de baixo nível (a programação efetiva da GPU) e assim o sistema permanece mais estável, pois a quantidade de códigos executados no espaço de núcleo encontra-se reduzida.

O único e grande incoveniente deste novo modelo de driver é que no final, proíbe o suporte do DirectX 10 para o Windows XP. Então, pode-se maldizer a Microsoft e afirmar que tudo não passa de uma conspiração para obrigar os jogadores a migrarem para o Vista. Pode-se também analisar as coisas de modo técnico e o enorme trabalho que causaria para adaptar este novo modelo de drivers sob o XP. Além do Direct3D, o novo modelo de driver também afeta o funcionamento do GDI (norma do Windows para exibição de objetos gráficos na tela e que se baseia na interface do sistema operacional Microsoft), que teria de ser alterado.

Um novo tipo de shader: Geometry Shader

As novidades mais interessantes da nova API se refere a um novo tipo de pipeline 3D.


Sua parte essencial permanece a mesma em relação ao pipeline do DirectX 9, entretanto, um novo estágio é introduzido: o Geometry Shader (GS) e os outros tiveram algumas modificações. Vamos ao estudo detalhado:

O GS constitui a grande novidade do DirectX 10 e este novo nível de pipeline opera não apenas em um único vértice (Vertex Shader) como nas unidades de shader atuais mas em todos os elementos primitivos (ponto, segmento, triângulo). Tem-se acesso a todos os nós do primitivo e dos adjacentes se for o caso.


Os Geometry Shaders são capazes de gerar vários nós que formam novos primitivos ou simplesmente eliminam os primitivos correntes. O limite dos Geometry Shaders é a geração de 1.024 valores 32 bits, respeitável ainda que seja um limite meramente teórico. Recorda-se principalmente das milhares de instruções geridas pelo Pixel Shader 2.0a dos NV3x... Esse limite alia-se ao resultado de um compromisso entre uma aplicação eficaz de “hardware” e os desejos dos desenvolvedores. Do ponto de vista de programador, os primitivos devem ser tratados na ordem em que são enviados à GPU. Na prática, este não é o caso (do mesmo modo que as instruções de um programa são tratados desordenadamente pela CPU para maximizar o desempenho), mas deve ser transparente ao programador: o “hardware” deverá se comportar exatamente como as ordens dos dados. Do mesmo modo, os primitivos gerados pelo Geometry Shader devem conservar essa ordem, o que pode ser problemático quanto à implantação em unidades paralelas. Para resolver esse problema, o resultado dos Geometry Shaders é armazenado em buffers que são tratados seguidamente por ordem de chegada.

As possibilidades oferecidas por esses novos “shaders” são múltiplas: como é capaz de gerir mais primitivos que ele recebe, um Geometry Shader pode efetuar a amplificação da geometria. Também pode gerar menos primitivos e permitir implementar um sistema de níveis de detalhes (LoD) sobre a GPU.

Note que a amplificação maciça da geometria se continua possível, não fazia parte dos objetivos do design do Geometry Shader. Para essa tarefa, os engenheiros da Microsoft previram outro estágio do pipeline: o Tessellator, presente nas primeiras versões do pipeline, na época em que o DirectX 10 era conhecido como WGF 2:



Finalmente a complexidade introduzida por este novo estágio foi julgada como extremamente grande em relação às possibilidades trazidas e decidiram retirá-lo.

Geometry Shader (continuação)

A amplificação da geometria permitiu a aparição do Displacement Mapping. Ele já foi apresentado em 2002 pela Matrox no lançamento do Parhelia, entretanto essa função não era programável na época. As esperanças dos programadores residiam em uma aplicação baseada nos “shaders”.



Se por um lado os Vertex Shaders 3.0 introduziram a amostragem de texturas, vários outros elementos impediram a expansão dessa técnica. Em primeiro lugar, os desempenhos dos vertex texture fetch nas primeiras arquiteturas que aplicaram o Shader Model 3.0 não eram satisfatórios. Segundo ponto: a falha nas especificações do DirectX 9 que permitiu à ATI oferecer o suporte dos vertex texture fetch sem nenhum formato de textura suportado! E por último, principalmente a ausência de uma técnica de amplificação de geometria: sem isso, o Displacement Mapping não tem quase nenhum interesse.

A Matrox baseou sua aplicação nos N-Patch, hoje desaparecidos graças a falta de interação para os desenvolvedores, mas os Geometry Shaders podem substituí-lo e de modo programável. Associado aos vertex texture fetch e eficiente em arquiteturas unificadas, não há mais nada que se oponha ao desenvolvimento do Displacement Mapping. O desempenho dos Geometry Shaders nas primeiras GPUs DirectX 10 será difícil de avaliar inicialmente. Será necessário também observar as novas técnicas desenvolvidas como o Parallax Oclusion Mapping (escolhido para STALKER) que oferece resultados excelentes.



Os Geometry Shaders também são adaptados por algoritmos já existentes como as sombras, por exemplo. A técnica permite substituir a CPU para a geração dessas sombras (detecção de silhueta por extrusão).



As sombras não estão a cargo dos desenvolvedores através dos shadow maps? Isso não é problema, pois os Geometry Shaders podem também prestar serviços oferecendo a renderização através de um cube map (mapeamento em cubo) em uma passagem que pode permitir a aceleração da geração de shadow maps para luzes omnidirecionais.



Entre outros possíveis efeitos pode-se citar a gestão do fur shading (pele) inteiramente pela GPU.



Os Geometry Shaders permitem fazer coisas mais abstratas como aplicar um sistema de materiais inteiramente através da GPU, deixando um Geometry Shader alterar as propriedades de cada material por primitivos.

Nota-se que os Geometry Shaders são também utilizados para emular o funcionamento de point sprites que desaparecem.

Stream Output

O papel do Stream Output é permitir o armazenamento de dados dos primitivos na memória. Esta técnica é chamada render-to-vertex-array. Esta técnica não é nova, mas necessitava de um certo amadurecimento neste tipo de pipeline 3D. Nota-se que a utilização do Stream Output não interrompe o tratamento dos primitivos: podem ser armazenados ao mesmo tempo na memória e continua o seu tratamento ao estágio Rasterizer.



Uma vez armazenadas na memória, os dados dos primitivos podem ser enviados no pipeline para serem tratados mais uma vez, autorizando assim a passagem dos algoritmos sem a intervenção ou leitura da CPU.

Um exemplo das possibilidades oferecidas pelo Stream Output seria efetuar um cálculo complexo em um vertex shader, como por exemplo, o skinning de um personagem, e salvar o resultado para passagens posteriores. Assim o cálculo trabalhoso é realizado apenas uma vez. Esta técnica permite, em uma arquitetura unificada, utilizar mais unidades de cálculo para o tratamento dos elementos na primeira fase que maximizam os desempenhos.

Nota-se que as gravações efetuas na atual fase do pipeline são meramente seqüenciais, o Stream Output não autoriza gravações aleatórias na proteção de saída (o famoso scatter da ATI, apreciado pelos programadores GPGPU, não é possível).

***Shaders Unificados***

Desde a introdução dos “shaders”, a Microsoft sempre definiu duas máquinas virtuais distintas: uma para os vertex shaders e outra para os pixel shaders. O Shader Model 3.0 marcou um primeiro passo para a unificação trazendo o suporte das texturas nos vertex shader e abolindo vários limites arbritrários dos pixel shaders, mas as diferenças ainda permaneciam.

Com o Direct3D 10, isso acabou: existe apenas uma única técnica que a Microsoft chama de Common Shader Core.

Evidentemente certos níveis conservam alguns recursos que não têm nenhum sentido em outros locais do pipeline. Assim, só um pixel shader pode calcular as derivadas δ/δx δ/δy tendo em conta que só um pixel shader tem a noção de espaço-tela (sistema de coordenadas físicas da tela), o que não tem utilidade. Da mesma maneira, considerando que um Geometry Shader pode emitir um número arbritrário de primitivos, não pode utilizar o mesmo modelo de vertex e pixel shaders que colocam os seus resultados em registros pré-definidos quando o programa termina. Para isso, os Geometry Shaders dispõem de uma instrução emit dedicada.

O Common Shader Core é definido por um conjunto de funcionalidades básicas:

* conjunto de instruções
* número de registros
* número de slots de instruções
* número de pontos de laço de recursos (texturas, samples, constantes)



As novidades em relação ao Shader Model 3.0 são numerosas. Embora o tipo principal de dados permaneça em um vetor de 4 pontos flutuantes de simples precisão, o Shader Model 4 introduz a gestão de valores inteiros (integer) de 32 bits. A aparição de valores inteiros acompanha a introdução de operações booleanas (bit-a-bit) clássicas da linguagem C (E lógico, OU lógico, OU exclusivo, NÃO, etc...). A gestão dos cálculos deve ser compatível com a norma IEEE.

Os recursos vêm seus limites aumentarem de maneira substancial, assim o número de registros temporários passa de 32 para 4.096, número de constantes, de 256 para 65.536 (16 × 4.096) e o número de texturas (cujas dimensões máximas passaram de 4.096 × 4.096 para 8.192 × 8.192) passou de 16 para 128.

***Shaders Unificados*** (continuação)

Para permitir essa atualização, a Microsoft utilizou vários artifícios. No que diz respeito ao número de registros temporários, é evidente que nem todos serão aplicados por “hardware”. Relembra a aplicação DirectX 9 da NVIDIA que oferece no máximo 4 registros temporários e se este número for ultrapassado, reduz a capacidade de “quads” em seu lote, limitando assim a capacidade de mascarar a latência dos acessos às memórias. A Microsoft explica que uma aplicação do “hardware” deve apresentar uma diminuição de desempenho relativamente linear quando os recursos utilizados aumentam e não desmoronar de uma só vez quando o limite arbitrário do “hardware” é ultrapassado.

A gestão das constantes foi totalmente reconsiderado. Enquanto sob o Direct3D 9 as constantes eram armazenadas em um conjunto de registros limitado (ainda que a aplicação do “hardware” possa variar, certas fabricantes armazenavam as constantes diretamente no código, no caso dos pixel shaders), no DirectX 10, as constantes estão situadas com os buffers na memória exatamente como os outros recursos. Essas constantes podem ser alteradas de modo claramente mais eficaz: enquanto uma chamada da API era efetuada para alterar o valor de uma constante, na nova API a aplicação cria constant buffers (as constantes são agrupadas de acordo com a utilização e a freqüência de suas atualizações) cujo número não é limitado e pode-se vinculá-las em uma só chamada de função. Até 16 constant buffers podem ser vinculadas por shader.



A Microsoft introduziu também sérias modificações quanto a gestão de texturas desvinculando os samples dos dados. Com este artifício, foi possível um maciço aumento de texturas simultaneamente utilizáveis (de 16 para 128) embora o número de samplers continua a ser, por sua vez, limitado a 16. Recorda-se que os samplers reúnem todas as informações necessárias para acessar e interpretar os dados lidos desde uma textura principalmente o modo de filtragem, o modo de endereçamento das coordenadas de textura...

Ainda a propósito das texturas, nota-se o aparecimento de uma instrução Load que permite recuperar os dados de uma textura a um endereço dado não normalizado e sem nenhuma filtragem, ao contrário da instrução Sample. Essas duas funções aceitam parâmetro de deslocamento opcional que permite especificar um valor em número de texels (entre mais ou menos 8 texels) às coordenadas de texturas especificadas. Essa adição permite simplesmente realizar filtros específicos, sem ter a necessidade de passar a dimensão da textura como parâmetro ao shader.

Gestão de recursos

Com o DirectX 10, a Microsoft reestruturou completamente a gestão de recursos. Enquanto os recursos eram fortemente tipificados com o DirectX 9, os do DirectX 10 não têm mais essa característica: são as zonas de memória brutas. Existem dois tipos: as texturas e os buffers dos quais todos os recursos derivam. Para serem interpretadas, essas zonas de memórias devem ser vinculadas a uma via que define os formatos dos dados de um recurso.

Assim permite uma forma, limitada mas útil, de interface de dados. Por exemplo no DirectX 9 era impossível dispôr de um buffer interpretado como vertex buffer em um vertex shader ou textura em um pixel shader. Com o DirectX 10 isso é possível. O único porém deste mecanismo é que se um tipo de dado alterar, sua dimensão continuará a mesma (um elemento composto por um vetor de dois flutuantes de 16 bits não pode ser interpretado como um escalar flutuante de 32 bits).



Uma outra novidade é o aparecimento das tabelas de recursos, principalmente a de texturas que permitem armazenar até 512 tipos com os mesmos formato e dimensão. Essa tabela de texturas podem ser indexada diretamente nos shaders e permite principalmente a técnica de compactar várias texturas e deixar apenas uma de maior dimensão. O Direct3D também permite efetuar a renderização através de uma tabela de “render targets”.

ONE MORE TIME

O Direct3D 10 também traz outras novidades, menos radicais que as citadas anteriormente, mas que também merecem ser assinaladas.

Conforme indicado na introdução, o novo runtime foi inteiramente reescrito com a preocupação de chegar o mais perto possíveis das GPUs recentes. Desembaraçando todos os recursos que podem ser reproduzidos pelos shaders, esse novo runtime foi aprimorado consideravelmente e deve oferecer um impacto benéfico quanto à utilização da CPU. O novo runtime introduz a validação de recursos na criação, ao contrário do DirectX 9, cujo processo era repetido a cada utilização dos recursos. Isso reduz a utilização da CPU pela API. O papel da validação confere a integridade dos dados e pacotes enviadas à API.

Ainda como foco a máxima redução possível de trabalho à CPU pela API, o Direct3D 10 introduz o método state objects: objetos encapsulados com vários estados são alterados freqüentemente. Anteriormente, era necessário uma chamada à API para alterar cada estado. Não foi detalhado como consiste essas mudanças de estado, mas parece ser transformar vetores em bitmaps (3D para 2D), misturar cores, alterar formas, ou seja, qualquer operação que envolva a mudança de estado de um objeto.

No DirectX 10, foram criados 5 estruturas novas de estado a nível de pipeline: InputLayout, Sampler, Rasterizer, DepthStencil, e Blend. Estes são classes / objetos que por sua vez tem seus métodos e atributos. A função desses objetos é transformar de maneira rápida e direta (integralmente) toda informação de estado, sem realizar múltiplas chamadas e causar um overhead.

Uma nova funcionalidade também interessante é a renderização condicional. O Direct3D 10 permite controlar a renderização de um objeto em função de um valor de um atributo. Por exemplo, é possível utilizar o resultado de um pedido de oclusão de uma caixa que engloba um objeto e, se esta for mascarada totalmente por outras, evita que esta seja renderizado com uma geometria complexa. Os pedidos de oclusão já eram possíveis no DirectX 9, mas o resultado era lido pela CPU que, em seguida, encarregava-se de controlar a renderização em função desse resultado. Agora o resultado de tal pedido é inserido diretamente na pipeline da GPU e pode ser utilizado sem a intervenção da CPU. Se o resultado do pedido não estiver disponível, a GPU supõe que o objeto é visível para evitar a interrupção do pipeline devido à espera desse resultado.



O instancing também sofreu atualização considerável na nova API. Enquanto a versão anterior permitia apenas girar a mesma geometria a diferentes posições, gerando assim um exército de clones, é agora possível utilizar os textures arrays para efetuar diferentes texturas a cada posição de uma geometria.



Nota-se também o aparecimento de um recurso presente a muito tempo no OpenGL: o alpha-to-coverage, focado ao problema de antialiasing em multisampling de texturas alpha. Maiores informações sobre essa técnica pode ser consultadas no “preview” da Presence PC sobre o GeForce 7.

E para terminar essa longa lista de novidades, o Direct3D 10 traz o suporte oficial de filtragem de shadow maps. Um outro artigo que trata do funcionamento dessa técnica pode-se ver consultado neste atalho.



DO THE EVOLUTION BABY

Conclusão

Com o DirectX 10, a Microsoft fez a lição de casa e abandonou o ciclo anual que era colocado para as novas versões essenciais do DirectX. Hoje pode-se dizer que a empresa de Redmond utilizou todo o seu tempo disponível para reestruturar completamente a sua API. Os engenheiros não exitaram em tomar decisões corajosas porque ainda que tecnicamente justificáveis, impunham mudanças radicais: fim da retrocompatibilidade, suporte obrigatório dos recursos... As opções não eram fáceis e inaugura novos rumos para a programação de jogos. Desta vez, as razões tecnológicas foram mais fortes que o marketing, oferecendo uma base splida sobre a qual representa a evolução do 3D em tempo real. As primeiras placas a utilizarem este benefício são as GeForce 8800 GTX e GTS da NVIDIA.