Direct3D 10 : un conjunto de funciones API para interactuar con una tarjeta de video; compatible con NV GeForce 8x00, ATI Radeon 2x00 y tarjetas de video superiores. Direct3D 10 (D3D10) es un componente de interfaz de programación de aplicaciones (API) de DirectX 10, la décima versión de Direct3D, el sucesor de Direct3D 9. Direct3D 10 proporciona funciones para el sistema operativo y la interacción de aplicaciones con controladores de tarjetas de video. Estas características son específicas del sistema operativo en la línea de Windows y están disponibles en Windows Vista y Windows 7 . Parcialmente D3D10 funciona en tarjetas de video del nivel Direct3D 9.
La versión final oficial se lanzó el 10 de noviembre de 2006 como parte de Windows Vista .
Las siguientes son características clave y diferencias con Direct3D versión 9.
En Windows Vista , un modelo de controlador completamente nuevo, WDDM ( Modelo de controlador de pantalla de Windows , anteriormente LDDM - Modelo de controlador de pantalla Longhorn), es un cambio importante en el modelo de controlador de video desde la llegada de la aceleración de hardware. En XDDM ( modelo de controlador de pantalla de Windows XP ), cada llamada de DirectX agregaba un puntero de comando (token) al búfer de comando en un formato independiente de la tarjeta de video. Cuando DX Runtime decidió que el búfer estaba lo suficientemente lleno, se llamó a una función de controlador (en modo kernel ) para obtener ese búfer. Después de eso, el controlador analizó este búfer y transfirió los datos a la tarjeta de video. Es decir, no había funciones de controlador en modo usuario . El desarrollo de las tarjetas de video y, como resultado, la complicación del búfer de comando llevó al hecho de que el controlador se volvió increíblemente grande y, en caso de error, provocó BSOD . Además, en XDDM, el sistema operativo no tiene forma de establecer prioridades, administrar la memoria de video, programar llamadas DX, lo que dificulta compartir una tarjeta de video entre varios procesos, la causa de la "pérdida del dispositivo".
En el nuevo modelo de controlador, se realiza una separación entre la parte del usuario y la parte del controlador en modo kernel. Todas las llamadas DX van directamente al controlador de usuario, que inmediatamente prepara un búfer con contenido específico del hardware. Este búfer transfiere datos al kernel del sistema operativo, desde donde van a la tarjeta de video. Por lo tanto, todo el trabajo duro se realiza en la parte del usuario y en el kernel, solo la transferencia del búfer recopilado a la tarjeta de video. Como resultado, si un controlador personalizado falla, no sucederá nada malo: se cerrará una aplicación específica, pero no se producirá ningún BSOD . Además, el controlador ahora decide cuándo y cuántas llamadas a funciones del kernel hacer. Además, DX Runtime se vuelve muy delgado: no hay búferes de comando, las funciones del controlador se llaman directamente. Además, hay un programador de tareas entre las partes del usuario y del núcleo, que selecciona qué búfer recopilados se envían a la tarjeta de video ( división de la GPU en muchos procesos).
Ahora, si no hay suficiente memoria de video, los recursos se transfieren al sistema (desde donde se pueden intercambiar ). Debido a que Windows Vista controla la asignación de memoria de video (anteriormente, el controlador), es posible asignarla de manera más eficiente que POOL_MANAGED en XDDM. En esta etapa, esto funciona a nivel de software: el programador de GPU, antes de transferir el paquete DMA a la tarjeta, carga todas las texturas necesarias en la memoria de video (puede cargarlas por adelantado mientras la GPU está ocupada con otra y el bus está libre). Si la aplicación es de pantalla completa, todo lo extra de la memoria de video se transferirá a la memoria del sistema según sea necesario; si está en modo ventana, la memoria se comparte entre los procesos actuales. Si desea garantizar el 100% de disponibilidad de un recurso en la memoria de video, debe usar el modo de pantalla completa y controlar el tamaño de las asignaciones.
En versiones anteriores, por varias razones, podía ocurrir Device Lost, después de lo cual era necesario recargar todos los recursos en la memoria de video y restaurar objetos. Con el nuevo modelo de controlador, este problema ya no existe. Es posible que se produzca una situación de dispositivo eliminado, lo que significa que la tarjeta de video se ha eliminado físicamente del sistema o que el controlador de video se ha actualizado. La situación es muy rara.
Toda la funcionalidad está garantizada en DX10, es decir, si una tarjeta admite DX10, entonces debe admitir la última versión de shaders en su totalidad, admitir todos los formatos de textura, todos los modos de filtrado posibles, plantilla (stencil) y todo lo demás. Además, para DX10 escribieron una especificación de reglas de rasterización, es decir, ahora la imagen en diferentes tarjetas de video que usan el mismo código siempre debe ser la misma y coincidir con el rasterizador de software de referencia. Si este no es el caso, entonces se trata de un error del fabricante de la tarjeta de video. En el futuro, se ampliará la funcionalidad (paquete DX10.1, DX11, etc.).
Tiempo de llamada reducido para funciones (incluido DIP) en la CPU. Según presentaciones de Microsoft , se puede observar una reducción de tiempo de 10x. Esto es significativo ya que un juego pesado puede pasar alrededor de 10+ milisegundos en llamadas DX. La mayor parte del tiempo de llamada se dedicaba anteriormente a Runtime y Driver, pero ahora el modelo de controlador en realidad no hace nada, sino que proporciona ejecución inmediata al controlador.
Aparecieron State Objects: objetos que se pueden ensamblar previamente durante la creación y luego instalarlos rápidamente en la tarjeta de video. Se agregaron búferes constantes, lo que permite una configuración más eficiente de las constantes de sombreado.
Todos los Set*States han sido reemplazados por State Objects. Los estados se dividen en varios grupos:
Los estados de cada grupo se establecen como un todo, y no cada uno por separado, como en D3D9. Para cada grupo, puede crear un objeto de estado que, cuando se crea, especifica el conjunto completo de estados del grupo y solo puede "establecerlo". La creación de un objeto de estado es una operación costosa y lenta y debe llamarse rara vez. La motivación de esta innovación es que una API de este tipo permite que el controlador genere un conjunto de comandos para la tarjeta de video por adelantado (al crear el objeto de estado) y no generarlo cada vez durante el procesamiento al llamar a Set*State.
Para los principales tipos de datos (vértices, índices, constantes), se ha introducido un solo búfer, ID3D10Buffer, un conjunto de bytes en la memoria. El tipo seguro se proporciona especificando al crear el contenido del búfer. Para los recursos, se han introducido objetos separados para vincular a la canalización: vistas de recursos. Es decir, primero creamos una textura como un objeto en la memoria y luego su vista de recursos como entrada para el sombreador o como destino de renderización, y con esta vista llamamos PSSetShaderResources (en lugar de SetTexture) y OMSetRenderTargets (en lugar de SetRenderTarget). Vale la pena señalar que un recurso puede tener varias vistas de recursos.
Este principio te permite trabajar de forma generalizada. Hay recursos "sin tipo" (sin tipo), es decir, recursos que no tienen un tipo específico (no especificado durante la creación), por ejemplo, DXGI_FORMAT_R32G32B32_TYPELESS. El tipo de dichos recursos se selecciona durante la creación de la vista (por ejemplo, DXGI_FORMAT_R32G32B32_UINT o DXGI_FORMAT_R32G32B32_FLOAT) y la selección de elementos/ cortes desde la matriz de texturas/textura volumétrica.
Set*ShaderConstant se reemplaza por Búferes constantes: grupos de constantes (un búfer para n constantes) que se configuran a la vez. El grupo se puede bloquear y grabar como un búfer normal. La vinculación al sombreador se realiza a partir de una determinada ranura.
Así, el uso de constantes se reduce a dividirlas en varios grupos por frecuencia de actualización (por objeto, por material, por pase, por escena) y crear un Búfer de constantes para cada grupo. Además del rendimiento adicional, este enfoque le brinda al conductor una imagen de alto nivel: más oportunidades de optimización.
VertexDeclaration se reemplazó con Diseño de entrada. Requiere al crear una firma de entrada de sombreador, es decir, una lista de parámetros de entrada (entrada) del sombreador. El objeto creado se puede usar como declaración de vértice con cualquier sombreador que tenga la misma lista de parámetros de entrada. En D3D9, la declaración de vértices se configuró independientemente del sombreador al renderizar y, por lo tanto, los controladores tuvieron que modificar seriamente la configuración al cambiar vdecl. Ahora vdecl está conectado a la entrada del sombreador, lo que permite que el controlador calcule todo por adelantado.
Los sombreadores ya no se pueden escribir en ensamblador; debe usar HLSL. Aunque hay un ensamblador para el modelo de sombreador 4.x y puede ver el resultado de compilar sombreadores en él, ya no es posible obtener el código binario del sombreador del texto del ensamblador (lo que hizo psa.exe / vsa.exe ), pero puede usar el método de ingeniería inversa para esto .
Para facilitar la portabilidad del código de sombreador, el compilador puede compilar versiones anteriores de sombreadores HLSL (SM2.0, SM 3.0) en SM4.0. En el nuevo HLSL, agregamos atributos para sugerencias al compilador: desenredar bucles y elegir ramificaciones dinámicas frente a estáticas para saltos condicionales.
En Shader Model 4, se agregaron instrucciones de números enteros y operaciones de bits (puede contar en un punto fijo justo y pasar banderas booleanas), se eliminó la restricción en la cantidad de instrucciones (pero un shader muy largo puede convertirse en uno de 10 segundos). límite de tiempo de ejecución del paquete en la GPU)
Sombreador geométrico: un sombreador adicional entre el vértice (Vertex Shader) y el píxel (Pixel Shader), que puede generar primitivas. En la entrada, se le da una primitiva con información sobre los vecinos, en la salida, puede generar varios (no un número fijo).
Esta es la capacidad de escribir el resultado de Vertex Shader / Geometry Shader en la memoria. Por ejemplo, para almacenar en caché el procesamiento de la geometría o, en general, la geometría creada por GS. Puedes pensar en efectos iterativos como Tela/Agua. Es decir, ahora puede transformar y escribir geometría directamente en la GPU, y no solo dibujar píxeles en Render Target. También es posible leer en el sombreador desde el búfer en la memoria por índice, es decir, tener una memoria compartida de solo lectura bastante grande. NV, por ejemplo, sugiere almacenar constantes de animación allí para instanciar.
Aparecieron los arreglos de texturas, es decir, un contenedor de texturas del mismo tamaño y formato, desde el cual el sombreador puede seleccionar por índice (en DX10.1, los arreglos de mapas de cubos también son posibles). Este es el mismo atlas hecho correctamente: antes, cuando se almacenaban varias texturas diferentes en una textura, tenía que preocuparse por los niveles de mip, dejar un espacio entre las texturas, etc. Ahora no es necesario. Una identificación de instancia/primitiva llega al sombreador, según la identificación de la instancia, puede usar un conjunto diferente de texturas/coordenadas/cualquier dato. Se espera que la rama dinámica en el sombreador sea rápida (mejor que en el hardware DX9), por lo que puede pasar una ID de material y seleccionar un material en el sombreador. Es decir, en teoría, es posible generar una gran cantidad de geometría con diferentes parámetros, texturas y materiales en una sola llamada. En la práctica, la rama dinámica tiene un costo de tiempo bastante grande y una serie de otros problemas (cálculo de gradientes de coordenadas de textura).
Una de las innovaciones más útiles por la que muchos se han pasado a DX10. Ahora, en el sombreador, puede leer cada muestra de MSAA por separado, es decir, escribir su propio filtro AA, muestrear durante el procesamiento sin ningún problema e incluso usar MSAA RT como textura. Además, AlphaToCoverage ahora está oficialmente presente. En D3D10.1, las texturas de profundidad también tienen estas características.
Ahora el búfer de profundidad se puede usar como textura. Podemos decir que al muestrear, comparar con el valor y filtrar a los vecinos, puede obtener un valor de profundidad limpio y un valor de plantilla.
El sistema operativo Windows XP no es compatible con DX10. La razón es que no es posible portar un nuevo modelo de controlador: se requieren demasiados cambios en el kernel del sistema operativo. Sin embargo, si solo se transfiere un conjunto de funciones nuevas de DX10, también surgen problemas: la virtualización y la programación no se pueden realizar en el modelo de controlador anterior, la transferencia de funciones de hardware es demasiado trabajo para Microsoft e IHV .