Considérations relatives à Direct3D 9 à Direct3D 10 (Direct3D 10)

La page suivante présente les principales différences entre Direct3D 9 et Direct3D 10. Le plan ci-dessous fournit des informations sur l’aide aux développeurs avec l’expérience Direct3D 9 pour explorer et se rapporter à Direct3D 10.

Bien que les informations de cette rubrique compareNt Direct3D 9 à Direct3D 10, car Direct3D 11 s’appuie sur les améliorations apportées dans Direct3D 10 et 10.1, vous avez également besoin de ces informations pour migrer de Direct3D 9 vers Direct3D 11. Pour plus d’informations sur le déplacement au-delà de Direct3D 10 vers Direct3D 11, consultez Migration vers Direct3D 11.

• Vue d’ensemble des principales modifications structurelles dans Direct3D 10
  • Suppression de la fonction fixe
  • Validation du temps de création d’objet de l’appareil
• Abstractions du moteur / Séparation
  • Suppression directe des dépendances Direct3D 9
• Astuces pour résoudre rapidement les problèmes de build d’application
  • Substitution de types Direct3D 9
  • Résolution des problèmes de lien
  • Simulation des adresses DEP de l’appareil
• Conduite de l’API Direct3D 10
  • Création de ressources
  • Vues
  • Accès aux ressources statiques et dynamiques
  • Effets Direct3D 10
  • HLSL sans effets
  • Compilation du nuanceur
  • Création de ressources de nuanceur
  • Interface de couche de réflexion du nuanceur
  • Dispositions de l’assembleur d’entrée - Nuanceur de vertex / Liaison de flux d’entrée
  • Impact de la suppression du code mort du nuanceur
  • Exemple de structure d’entrée du nuanceur de vertex
  • Création d’objets State
• Portage des textures
  • Formats de fichier pris en charge
  • Formats de texture de mappage
• Portage des nuanceurs
  • Les nuanceurs Direct3D 10 sont créés dans HLSL
  • Signatures et liaison du nuanceur
  • Liaisons de l’étape du nuanceur HLSL
  • Mémoires tampons constantes
  • Plans de clip utilisateur dans HLSL au niveau de la fonctionnalité 9 et versions ultérieures
• Autres différences direct3D 10 à surveiller
  • Entiers en tant qu’entrée
  • Curseurs de souris
  • Mappage de Texels à pixels dans Direct3D 10
  • Modifications du comportement de comptage de référence
  • Niveau de coopération de test
  • StretchRect
• Différences supplémentaires direct3D 10.1
• Rubriques connexes

Vue d’ensemble des principales modifications structurelles dans Direct3D 10

• Suppression de la fonction fixe
• Validation du temps de création d’objet de l’appareil

Le processus de rendu à l’aide de l’appareil Direct3D 10 est structurellement similaire à Direct3D 9.

• Définir une source de flux de vertex
• Définir la disposition d’entrée dans Direct3D 10 (définir la déclaration de flux de vertex dans Direct3D 9)
• Déclarer la topologie primitive
• Définir des textures
• Définir des objets d’état
• Définir des nuanceurs
• Draw

L’appel Draw lie les opérations ensemble ; l’ordre des appels avant l’appel Draw est arbitraire. Les principales différences dans la conception de l’API Direct3D 10 sont les suivantes :

• Suppression de la fonction fixe
• Suppression des bits CAPS - Le jeu de fonctionnalités de base de Direct3D 10 est garanti
• Gestion plus stricte de : accès aux ressources, état de l’appareil, constantes de nuanceur, liaison de nuanceur (entrées et sorties aux nuanceurs) entre les étapes
• Les modifications apportées au nom du point d’entrée de l’API reflètent l’utilisation de la mémoire GPU virtuelle (Map() au lieu de Lock()).
• Une couche de débogage peut être ajoutée à l’appareil au moment de la création
• La topologie primitive est désormais un état explicite (séparé de l’appel Draw )
• Les constantes de nuanceur explicites sont désormais stockées dans des mémoires tampons constantes
• La création de nuanceur est entièrement effectuée dans HLSL. Le compilateur HLSL réside désormais dans la DLL Direct3D 10 principale.
• Nouvelle étape programmable - nuanceur geometry
• Suppression de BeginScene()/EndScene()
• Fonctionnalités courantes de gestion des adaptateurs, focus et 2D implémentées dans un nouveau composant : DXGI

Suppression de la fonction fixe

Il est parfois surprenant que même dans un moteur Direct3D 9 qui exploite entièrement le pipeline programmable, il reste un certain nombre de zones qui dépendent du pipeline de fonction fixe (FF). Les zones les plus courantes sont généralement liées au rendu aligné sur l’espace d’écran pour l’interface utilisateur. C’est pour cette raison que vous devrez probablement créer un nuanceur d’émulation FF ou un ensemble de nuanceurs qui fournissent les comportements de remplacement nécessaires.

Cette documentation contient un livre blanc contenant des sources de nuanceur de remplacement pour les comportements FF les plus courants (voir l’exemple UEM de fonction fixe). Certains comportements de pixels de fonction fixe, y compris le test alpha, ont été déplacés dans des nuanceurs.

Validation du temps de création d’objet de l’appareil

Le pipeline Direct3D 10 a été repensé à partir du terrain dans le matériel et les logiciels avec l’intention principale de réduire la surcharge du processeur (au moment du dessin). Pour réduire les coûts, tous les types de données d’appareil ont été affectés à un objet avec des méthodes de création explicites fournies par l’appareil lui-même. Cela permet une validation stricte des données au moment de la création de l’objet au lieu de l’appel Draw comme il le fait souvent avec Direct3D 9.

Abstractions du moteur / Séparation

Les applications, y compris les jeux, qui souhaitent prendre en charge Direct3D 9 et Direct3D 10 doivent avoir les couches de rendu abstraites du reste de la base de code. Il existe de nombreuses façons d’y parvenir, mais la clé de tous est la conception de la couche d’abstraction pour l’appareil Direct3D de niveau inférieur. Tous les systèmes doivent communiquer avec le matériel via la couche commune qui est conçue pour fournir une ressource GPU et une gestion de type de bas niveau.

Suppression directe des dépendances Direct3D 9

Lors du portage de bases de code volumineuses, précédemment testées, il est important de réduire la quantité de modifications de code qui sont absolument nécessaires pour conserver les comportements précédemment testés dans le code. Les meilleures pratiques incluent clairement la documentation où les éléments changent à l’aide de commentaires. Il est souvent utile d’avoir une norme de commentaire pour ce travail qui permet une navigation rapide via la base de code.

Voici un exemple de liste de commentaires de bloc monoligne/début standard qui peuvent être utilisés pour ce travail.

Pour plusieurs lignes de source, vous devez utiliser le style C /* */ commentaires également, mais ajouter les commentaires de début/fin pertinents autour de ces zones.

Astuces pour résoudre rapidement les problèmes de build d’application

• Substitution de types Direct3D 9
• Résolution des problèmes de lien
• Simulation des adresses DEP de l’appareil

Substitution de types Direct3D 9

Il peut être utile d’insérer un fichier d’en-tête de haut niveau contenant des définitions de type/ remplacements pour les types de base Direct3D 9 qui ne sont plus pris en charge par les en-têtes Direct3D 10. Cela vous aidera à réduire la quantité de modifications dans le code et les interfaces où il existe un mappage direct d’un type Direct3D 9 au type Direct3D 10 nouvellement défini. Cette approche est également utile pour conserver les comportements de code ensemble dans un fichier source. Dans ce cas, il est judicieux de définir des types neutres / généralement nommés de version qui décrivent les constructions courantes utilisées pour le rendu, mais couvrent les API Direct3D 9 et Direct3D 10. Par exemple :

#if defined(D3D9)
typedef IDirect3DIndexBuffer9   IDirect3DIndexBuffer;
typedef IDirect3DVertexBuffer9  IDirect3DVertexBuffer;
#else //D3D10
typedef ID3D10Buffer            IDirect3DIndexBuffer;
typedef ID3D10Buffer            IDirect3DVertexBuffer
#endif

Voici d’autres exemples spécifiques de Direct3D 10 :

typedef ID3D10TextureCube   IDirect3DCubeTexture;
typedef ID3D10Texture3D     IDirect3DVolumeTexture;
typedef D3D10_VIEWPORT      D3DVIEWPORT;
typedef ID3D10VertexShader  IDirect3DVertexShader;
typedef ID3D10PixelShader   IDirect3DPixelShader;

Résolution des problèmes de lien

Il est conseillé de développer des applications Direct3D 10 et Windows Vista à l’aide de la dernière version de Microsoft Visual Studio. Toutefois, il est possible de créer une application Windows Vista qui dépend de Direct3D 10 à l’aide de la version 2003 antérieure de Visual Studio. Direct3D 10 est un composant de plateforme Windows Vista qui a des dépendances (comme avec le Kit de développement logiciel (SDK) de plateforme Server 2003 SP1 sur la bibliothèque suivante : BufferOverflowU.lib est nécessaire pour résoudre les problèmes de l’éditeur de liens buffer_security de vérification.

Simulation des adresses DEP de l’appareil

De nombreuses applications contiennent des zones de code qui dépendent des données CAPS de l’appareil disponibles. Contourner ce problème en remplaçant l’énumération de l’appareil et en forçant l’appareil CAPS à des valeurs sensibles. Prévoyez de visiter à nouveau les zones où il y a des dépendances sur CAPS ultérieurement pour la suppression complète de CAPS dans la mesure du possible.

Conduite de l’API Direct3D 10

Cette section se concentre sur les modifications de comportement provoquées par l’API Direct3D 10.

• Création de ressources
• Vues
• Accès aux ressources statiques et dynamiques
• Effets Direct3D 10
• HLSL sans effets
• Compilation du nuanceur
• Création de ressources de nuanceur
• Interface de couche de réflexion du nuanceur
• Dispositions de l’assembleur d’entrée - Nuanceur de vertex / Liaison de flux d’entrée
• Impact de la suppression du code mort du nuanceur
• Exemple de structure d’entrée du nuanceur de vertex
• Création d’objets State

Création de ressources

L’API Direct3D 10 a conçu des ressources en tant que types de mémoires tampons génériques qui ont des indicateurs de liaison spécifiques en fonction de l’utilisation planifiée. Ce point de conception a été choisi pour faciliter l’accès quasi omniprésent des ressources dans le pipeline pour des scénarios tels que le rendu dans une mémoire tampon de vertex, puis dessine instantanément les résultats sans interrompre l’UC. L’exemple suivant illustre l’allocation des mémoires tampons de vertex et de la mémoire tampon d’index où vous pouvez voir que la description de la ressource diffère uniquement par les indicateurs de liaison de ressources GPU.

L’API Direct3D 10 a fourni des méthodes d’assistance de texture pour créer explicitement des ressources de type de texture, mais comme vous pouvez l’imaginer, il s’agit vraiment de fonctions d’assistance.

• CreateTexture2D()
• CreateTextureCube()
• CreateTexture3D()

Lorsque vous ciblez Direct3D 10, il est probable que vous souhaitiez allouer plus d’éléments pendant la création des ressources que vous utilisez avec Direct3D 9. Cela devient le plus apparent avec la création de mémoires tampons et de textures de cible de rendu où vous devez également créer une vue pour accéder à la mémoire tampon et définir la ressource sur l’appareil.

Tutoriel 1 : Notions de base de Direct3D 10

Vues

Une vue est une interface spécifiquement typée pour les données stockées dans une mémoire tampon de pixels. Une ressource peut avoir plusieurs vues allouées sur celle-ci à la fois et cette fonctionnalité est mise en surbrillance dans l’exemple De rendu à cubemap contenu dans ce Kit de développement logiciel (SDK).

Page Guide du programmeur sur l’accès aux ressources

Exemple CubeMap

Accès aux ressources statiques et dynamiques

Pour des performances optimales, les applications doivent partitionner leur utilisation des données en termes de nature statique et dynamique des données. Direct3D 10 a été conçu pour tirer parti de cette approche et, par conséquent, les règles d’accès pour les ressources ont été considérablement renforcées par rapport à Direct3D 9. Pour les ressources statiques, vous devez idéalement remplir la ressource avec ses données pendant la création. Si votre moteur a été conçu autour du point de conception Create, Lock, Fill, Unlock de Direct3D 9, vous pouvez différer la population de Create time à l’aide d’une ressource intermédiaire et de la méthode UpdateSubResource sur l’interface de ressource.

Effets Direct3D 10

L’utilisation du système Direct3D 10 Effects est en dehors de l’étendue de cet article. Le système a été écrit pour tirer pleinement parti des avantages architecturaux offerts par Direct3D 10. Pour plus d’informations sur son utilisation, consultez la section Effets (Direct3D 10 ).

HLSL sans effets

Le pipeline De nuanceur Direct3D 10 peut être piloté sans utiliser le système d’effets Direct3D 10. Notez que dans cette instance, toutes les liaisons de mémoire tampon, de nuanceur, d’échantillonneur et de texture doivent être gérées par l’application elle-même. Pour plus d’informations, consultez l’exemple de lien et les sections suivantes de ce document :

HLSL sans exemple d’effets

Compilation du nuanceur

Le compilateur HLSL Direct3D 10 apporte des améliorations à la définition du langage HLSL et peut donc fonctionner en 2 modes. Pour une prise en charge complète des fonctions intrinsèques de style Direct3D 9 et de la sémantique, la compilation doit être appelée à l’aide de l’indicateur MODE DE COMPATIBILITÉ qui peut être spécifié sur une base de compilation.

La sémantique du langage HLSL spécifique au modèle de nuanceur 4.0 et les fonctions intrinsèques pour Direct3D 10 se trouvent dans HLSL. Les modifications majeures de la syntaxe de Direct3D 9 HLSL pour prendre le plus d’avis sont dans la zone d’accès de texture. La nouvelle syntaxe est le seul formulaire pris en charge par le compilateur en dehors du mode de compatibilité.

Création de ressources de nuanceur

La création d’instances de nuanceur compilées en dehors du système d’effets Direct3D 10 est effectuée de manière très similaire à Direct3D 9. Toutefois, dans Direct3D 10, il est important de conserver la signature d’entrée du nuanceur pour une utilisation ultérieure. La signature est retournée par défaut dans le cadre de l’objet blob du nuanceur, mais peut être extraite pour réduire les besoins en mémoire si nécessaire. Pour plus d’informations, consultez Utilisation des nuanceurs dans Direct3D 10.

Interface de couche de réflexion du nuanceur

La couche de réflexion du nuanceur est l’interface par laquelle des informations sur les exigences du nuanceur peuvent être obtenues. Cela est particulièrement utile lors de la création de liaisons d’assembly d’entrée (voir ci-dessous) où vous devrez peut-être parcourir les exigences d’entrée du nuanceur pour vous assurer que vous fournissez la structure d’entrée correcte au nuanceur. Vous pouvez créer une instance de l’interface de couche de réflexion en même temps que la création d’une instance d’un nuanceur compilé.

La couche de réflexion du nuanceur remplace les méthodes D3DX9 qui fournissent des fonctionnalités similaires. Par exemple, IsParameterUsed est remplacé par la méthode GetDesc.

Dispositions de l’assembleur d’entrée - Nuanceur de vertex / Liaison de flux d’entrée

L’assembleur d’entrée (IA) remplace la déclaration de flux de vertex de style Direct3D 9 et sa structure de description est très similaire sous forme. La principale différence que l’IA apporte est que l’objet de disposition IA créé doit directement mapper à un format spécifique de signature d’entrée du nuanceur. L’objet de mappage créé pour lier le flux d’entrée au nuanceur peut être utilisé sur n’importe quel nombre de nuanceurs où la signature d’entrée du nuanceur correspond à celle du nuanceur utilisé pour créer la disposition d’entrée.

Pour mieux piloter le pipeline avec des données statiques, vous devez prendre en compte les permutations du format de flux d’entrée vers les signatures d’entrée de nuanceur possibles et créer les instances d’objet de disposition IA dès que possible et les réutiliser le cas échéant.

Impact de la suppression du code mort du nuanceur

La section suivante détaille une différence significative entre Direct3D 9 et Direct3D 10 qui nécessite probablement une gestion minutieuse dans votre code moteur. Les nuanceurs qui contiennent des expressions conditionnelles ont souvent certains chemins de code supprimés dans le cadre du processus de compilation. Dans Direct3D 9, deux types d’entrées peuvent être supprimés (marqués pour suppression) lorsqu’elles ne sont pas utilisées : entrées de signature (comme l’exemple ci-dessous) et entrées constantes. Si la fin de la mémoire tampon constante contient des entrées inutilisées, la déclaration de taille dans le nuanceur reflète la taille de la mémoire tampon constante sans les entrées inutilisées à la fin. Ces deux types d’entrées restent dans des signatures ou des mémoires tampons constantes Direct3D 10 avec une exception spéciale dans le cas d’entrées constantes inutilisées à la fin d’une mémoire tampon constante. Cela peut avoir un impact sur le moteur lors de la gestion des nuanceurs volumineux et de la création de dispositions d’entrée. Les éléments qui sont supprimés par des optimisations de code mort dans le compilateur doivent toujours être déclarés dans la structure d’entrée. Cela est illustré par l’exemple suivant :

Exemple de structure d’entrée du nuanceur de vertex

struct VS_INPUT
{
float4 pos: SV_Position;
float2 uv1 : Texcoord1;
float2 uv2 : Texcoord2; *
};

* La suppression de code mort Direct3D 9 supprimerait la déclaration dans le nuanceur en raison de la suppression conditionnelle du code mort

float4x4  g_WorldViewProjMtx;
static const bool g_bLightMapped = false; // define a compile time constant

VS_INPUT main(VS_INPUT i) 
{
    VS_INPUT o;
    o.pos = mul( i.pos, g_WorldViewProjMtx);
    o.uv1 = i.uv1;
    if ( g_bLightMapped )
    {
        o.uv2 = i.uv2;
    }
    return o;
}

Ou bien, vous pouvez rendre encore plus évident que la constante est une constante de temps de compilation avec la déclaration suivante :

#define LIGHT_MAPPED false

Dans l’exemple ci-dessus, sous Direct3D 9, l’élément uv2 est supprimé en raison d’optimisations de code mortes dans le compilateur. Sous Direct3D 10, le code mort sera toujours supprimé, mais la disposition de l’assembleur d’entrée du nuanceur nécessite la définition des données d’entrée à exister. La couche de réflexion du nuanceur fournit les moyens de gérer cette situation de manière générique, par laquelle vous pouvez parcourir les exigences d’entrée du nuanceur et vous assurer que vous fournissez une description complète du flux d’entrée pour le mappage de signature du nuanceur.

Voici un exemple de fonction pour détecter l’existence d’un nom/d’index sémantique dans une signature de fonction :

// Returns true if the SemanticName / SemanticIndex is used in the input signature.
// pReflector is a previously acquired shader reflection interface.
bool IsSignatureElementExpected(ID3D10ShaderReflection *pReflector, const LPCSTR SemanticName, UINT SemanticIndex)
{
    D3D10_SHADER_DESC               shaderDesc;
    D3D10_SIGNATURE_PARAMETER_DESC  paramDesc;

    Assert(pReflector);
    Assert(SemanticName);

    pReflector->GetDesc(&shaderDesc);

    for (UINT k=0; k<shaderDesc.InputParameters; k++)
    {
        pReflector->GetInputParameterDesc( k, &paramDesc);
        if (wcscmp( SemanticName, paramDesc.SemanticName)==0 && paramDesc.SemanticIndex == SemanticIndex) 
            return true;
    }

    return false;
}

Création d’objets State

Lors du portage du code du moteur, il peut être utile d’utiliser initialement un ensemble d’objets d’état par défaut et de désactiver tous les paramètres d’état de rendu de l’appareil Direct3D 9/texture. Cela entraîne le rendu des artefacts, mais est le moyen le plus rapide d’obtenir les choses en cours d’exécution. Vous pouvez ensuite construire un système de gestion des objets d’état qui peut utiliser une clé composée pour permettre la réutilisation maximale du nombre d’objets d’état utilisés.

Portage des textures

Formats de fichier pris en charge

Les fonctions D3DXxxCreateXXX et D3DXxxSaveXXX qui créent ou enregistrent une texture à partir d’un fichier graphique (par exemple, D3DX10CreateTextureFromFile) prennent en charge un ensemble différent de formats de fichier dans Direct3D 10 que dans Direct3D 9 :

Pour plus d’informations, comparez les énumérations direct3D 9 D3DXIMAGE_FILEFORMAT aux énumérations D3DX10_IMAGE_FILE_FORMAT pour Direct3D 10.

Formats de texture de mappage

Le tableau suivant montre le mappage des formats de texture de Direct3D 9 à Direct3D 10. Tout contenu dans les formats non disponibles dans DXGI doit être converti par routines utilitaires.

¹DXGI 1.1, inclus dans le runtime Direct3D 11, inclut des formats BGRA. Toutefois, la prise en charge de ces formats est facultative pour les appareils Direct3D 10 et 10.1 avec des pilotes implémentés dans le modèle de pilote d’affichage Windows (WDDM) pour Windows Vista (WDDM 1.0). Envisagez plutôt d’utiliser DXGI_FORMAT_R8G8B8A8_UNORM. Vous pouvez également créer votre appareil avec D3D10_CREATE_DEVICE_BGRA_SUPPORT pour vous assurer que vous prenez uniquement en charge les ordinateurs avec le runtime Direct3D 11.0 et un pilote WDDM 1.1 ou version ultérieure installé.

²DXGI 1.0 défini 5:6:5 et 5:5:5:1 formats, mais ils n’ont pas été pris en charge par le runtime Direct3D 10.x ou Direct3D 11.0. Ces formats sont éventuellement pris en charge avec DXGI 1.2 dans le runtime DirectX 11.1, ce qui est requis pour les adaptateurs vidéo de niveau de fonctionnalité 11.1 et WDDM 1.2 (modèle de pilote d’affichage commençant par Windows 8) et déjà pris en charge sur les niveaux de fonctionnalités 10level9.

³DXGI 1.2 a introduit le format 4:4:4:4. Ce format est éventuellement pris en charge dans le runtime DirectX 11.1, qui est requis pour les adaptateurs vidéo de niveau de fonctionnalité 11.1 et les pilotes WDDM 1.2 et déjà pris en charge sur les niveaux de fonctionnalité 10level9.

Pour les formats non compressés, DXGI a limité la prise en charge des modèles de format de pixels arbitraires ; tous les formats non compressés doivent être de type RVBA. Cela peut nécessiter un basculement des formats de pixels de ressources existants, que nous vous recommandons de calculer en tant que passe de pré-processus hors connexion, le cas échéant.

Portage des nuanceurs

Les nuanceurs Direct3D 10 sont créés dans HLSL

Direct3D 10 limite l’utilisation du langage d’assembly à celle du débogage uniquement, par conséquent, les nuanceurs d’assembly écrits manuellement utilisés dans Direct3D 9 doivent être convertis en HLSL.

Signatures et liaison du nuanceur

Nous avons abordé les conditions requises pour la liaison d’assembly d’entrée à des signatures d’entrée de nuanceur de vertex plus haut dans ce document (voir ci-dessus). Notez que le runtime Direct3D 10 a également renforcé les exigences en matière de liaison intermédiaire entre les nuanceurs. Cette modification affecte les sources de nuanceur où la liaison entre les étapes n’a peut-être pas été entièrement décrite sous Direct3D 9. Par exemple :

VS_OUTPUT                       PS_INPUT
float4   pos : SV_POSITION;     float4 pos : SV_POSITION;
float4   uv1 : TEXCOORD1;       float4 uv1 : TEXCOORD1;
float4x3 tangentSp : TEXCOORD2; float4 tangent : TEXCOORD2; *
float4   Color : TEXCOORD6;     float4 color : TEXCOORD6;

* Vs cassé - Liaison PS - même si le nuanceur de pixels peut ne pas être intéressé par la matrice complète, la liaison doit spécifier le float4x3 complet.

Notez que la sémantique de liaison entre les phases doit correspondre exactement, mais les entrées des étapes cibles peuvent être un préfixe des valeurs en cours de sortie. Dans l’exemple ci-dessus, le nuanceur de pixels peut avoir une position et un texcoord1 comme seules entrées, mais il n’a pas pu avoir la position et le texcoord2 comme seules entrées en raison des contraintes de classement.

Liaisons de l’étape du nuanceur HLSL

La liaison entre les nuanceurs peut se produire à l’un des points suivants dans le pipeline :

• Assembleur d’entrée au nuanceur de vertex
• Nuanceur de vertex en nuanceur de pixels
• Nuanceur de vertex en nuanceur geometry
• Nuanceur de vertex pour diffuser en continu la sortie
• Nuanceur de géométrie en nuanceur de pixels
• Nuanceur geometry pour diffuser en continu

Mémoires tampons constantes

Pour faciliter le portage du contenu à partir de Direct3D 9, une approche initiale de la gestion constante en dehors du système Effets peut impliquer la création d’une mémoire tampon constante unique contenant toutes les constantes requises. Il est important que les performances commandent des constantes en mémoires tampons par la fréquence de mise à jour attendue. Cette organisation réduit au minimum la quantité de jeux de constantes redondantes.

Plans de clip utilisateur dans HLSL au niveau de la fonctionnalité 9 et versions ultérieures

À compter de Windows 8, vous pouvez utiliser l’attribut de fonction clipplanes dans une déclaration de fonction HLSL plutôt que SV_ClipDistance pour que votre nuanceur fonctionne au niveau des fonctionnalités 9_x ainsi que le niveau de fonctionnalité 10 et supérieur. Pour plus d’informations, consultez Plans de découpage utilisateur sur le matériel de niveau de fonctionnalité 9.

Autres différences direct3D 10 à surveiller

Entiers en tant qu’entrée

Dans Direct3D 9, il n’y avait aucune prise en charge matérielle réelle pour les types de données entiers, mais le matériel Direct3D 10 prend en charge les types entiers explicites. Si vous avez des données à virgule flottante dans votre mémoire tampon de vertex, vous devez disposer d’une entrée float. Sinon, un type entier est la représentation de modèle de bits de la valeur à virgule flottante. Un type entier n’est pas autorisé pour une entrée de nuanceur de pixels, sauf si la valeur est marquée pour aucune interpolation (voir Modificateurs d’interpolation).

Curseurs de souris

Sur les versions précédentes de Windows, les routines de curseur de souris GDI standard ne fonctionnent pas correctement sur tous les appareils exclusifs plein écran. Les API SetCursorProperties, ShowCursor et SetCursorPosition ont été ajoutées pour gérer ces cas. Étant donné que la version de Windows Vista de GDI comprend entièrement les surfaces DXGI , il n’est pas nécessaire que cette API de curseur de souris spécialisée ne soit pas équivalente à Direct3D 10. Les applications Direct3D 10 doivent utiliser plutôt les routines de curseur de souris GDI standard pour les curseurs de souris.

Mappage de Texels à pixels dans Direct3D 10

Dans Direct3D 9, les centres de texel et les centres de pixels étaient séparés d’une demi-unité (voir Mappage direct des Texels aux pixels (Direct3D 9)). Dans Direct3D 10, les centres texels sont déjà à moitié unités, il n’est donc pas nécessaire de déplacer les coordonnées de vertex du tout.

Le rendu des quads plein écran est plus direct avec Direct3D 10. Les quads plein écran doivent être définis dans le clipspace (-1,1) et simplement passés par le nuanceur de vertex sans aucune modification. De cette façon, il n’est pas nécessaire de recharger votre mémoire tampon de vertex chaque fois que la résolution de l’écran change, et il n’y a pas de travail supplémentaire dans le nuanceur de pixels pour manipuler les coordonnées de texture.

Modifications du comportement de comptage de référence

Contrairement aux versions précédentes de Direct3D, les différentes fonctions Set ne contiennent pas de référence aux objets d’appareils. Cela signifie que l’application doit s’assurer qu’elle contient une référence sur l’objet tant qu’elle souhaite que cet objet soit lié au pipeline. Lorsque le nombre de références de l’objet passe à zéro, l’objet est indépendant du pipeline tel qu’il est détruit. Ce style de conservation de référence est également appelé conservation de référence faible. Par conséquent, chaque emplacement de liaison sur l’objet Device contient une référence faible à l’interface/objet. Sauf indication explicite, ce comportement doit être supposé pour toutes les méthodes Set. Chaque fois que la destruction d’un objet entraîne la définition d’un point de liaison sur NULL , la couche de débogage émet un avertissement. Notez que les appels à des méthodes Get d’appareil telles que OMGetRenderTargets augmenteront le nombre de références d’objets retournés .

Niveau de coopération de test

La fonctionnalité de l’API Direct3D 9 TestCooperativeLevel est analogue à la définition de l’DXGI_PRESENT_TEST lors de l’appel de Present.

StretchRect

Une fonction similaire à la méthode Direct3D 9 IDirect3DDevice9 ::StretchRect n’est pas disponible dans Direct3D 10 et 10.1. Pour copier des surfaces de ressources, utilisez ID3D10Device ::CopySubresourceRegion. Pour les opérations de redimensionnement, effectuez un rendu sur une texture à l’aide du filtrage de texture. Pour convertir des surfaces MSAA en surfaces non MSAA, utilisez ID3D10Device ::ResolveSubresource.

Différences supplémentaires direct3D 10.1

Windows Vista avec Service Pack 1 (SP1) inclut une mise à jour mineure vers Direct3D 10 et Direct3D 10.1, qui expose les fonctionnalités matérielles supplémentaires suivantes :

• Nuanceurs MSAA par exemple
• Lecture de profondeur MSAA
• Modes de fusion indépendants par cible de rendu
• Tableaux de cartes de cube
• Rendu aux formats compressés par bloc (BC)

La mise à jour Direct3D 10.1 a ajouté la prise en charge des nouvelles interfaces suivantes, dérivées des interfaces existantes :

• ID3D10Device1
• ID3D10BlendState1
• ID3D10ShaderResourceView1

La mise à jour direct3D 10.1 inclut également les structures supplémentaires suivantes :

• D3D10_RENDER_TARGET_BLEND_DESC1
• D3D10_BLEND_DESC1
• D3D10_SHADER_RESOURCE_VIEW_DESC1

L’API Direct3D 10.1 inclut un nouveau concept nommé de niveau de fonctionnalité. Ce concept signifie que vous pouvez utiliser l’API Direct3D 10.1 pour piloter le matériel Direct3D 10.0 (D3D10_FEATURE_LEVEL_10_0) ou Direct3D 10.1 (D3D10_FEATURE_LEVEL_10_1). Étant donné que l’API Direct3D 10.1 est dérivée des interfaces Direct3D 10, les applications peuvent créer un appareil Direct3D 10.1, puis l’utiliser en tant qu’appareil Direct3D 10.0, sauf si de nouvelles fonctionnalités spécifiques à 10.1 sont nécessaires (à condition que le niveau des fonctionnalités D3D10_FEATURE_LEVEL_10_1 soit présent et prend en charge ces fonctionnalités).

Windows 7 contenait une mise à jour mineure de l’API Direct3D 10.1 incluse dans le runtime Direct3D 11. Cette mise à jour ajoute la prise en charge des niveaux de fonctionnalités suivants :

• D3D10_FEATURE_LEVEL_9_1
• D3D10_FEATURE_LEVEL_9_2
• D3D10_FEATURE_LEVEL_9_3

Windows 7 a également ajouté la prise en charge de Direct3D 10.1 pour windows Advanced Rasterization Platform (WARP). Vous pouvez spécifier un pilote WARP à l’aide de D3D10_DRIVER_TYPE_WARP.

Pour plus d’informations sur Direct3D 10.1, consultez Fonctionnalités direct3D 10.1 et énumération D3D10_FEATURE_LEVEL1.

Rubriques connexes

Guide de programmation pour Direct3D 10