C++ Girl
  1. C++ Girl
  3. DirectX 9 HLSL et DirectX 10 HLSL: la syntaxe est-elle la même?
Intereting Posts
Déballer les parameters variés via Lambdas Algorithme permettant d’imprimer sur les chemins d’écran dans un labyrinthe de textes Valeur par défaut du pointeur statique dans c / c ++ Vérifier si l’élément trouvé dans le tableau c ++ Puis-je détacher un std :: vector des données qu’il contient? Comment effectuer une conversion RVB-> YUV en C / C ++? Filtre de carte de déplacement dans OpenCV Android NDK dans le type Eclipse size_t n’a pas pu être résolu Quaternion à EulerXYZ, comment différencier le quaternion négatif et positif passer des tableaux de caractères de c ++ à fortran Devrais-je supprimer les grandes collections d’arbres en C ++ à la fin du programme ou laisser cela à OS? Spécialisation des parameters de template de template Pourquoi mon constructeur C ++ surchargé n’est-il pas appelé? Projet VC ++ 2008 toujours “obsolète” C ++: Passage d’objects par valeur à une fonction membre de la même classe

DirectX 9 HLSL et DirectX 10 HLSL: la syntaxe est-elle la même?

Depuis un mois à peu près, je me suis efforcé d’apprendre DirectX. Je mélange donc entre DirectX 9 et 10. L’un des principaux changements que j’ai constatés dans les deux cas concerne la manière de traiter les vecteurs dans la carte graphique.

L’un des changements radicaux que j’ai remarqué est la manière dont vous faites en sorte que le GPU reconnaisse vos structures. Dans DirectX 9, vous définissez les formats de sumt flexible.

Votre configuration typique ressemblerait à ceci: 

#define CUSTOMFVF (D3DFVF_XYZRHW | D3DFVF_DIFFUSE)

Dans DirectX 10, je pense que l’équivalent est la description du sumt d’entrée: 

 D3D10_INPUT_ELEMENT_DESC layout[] = { {"POSITION",0,DXGI_FORMAT_R32G32B32_FLOAT, 0 , 0, D3D10_INPUT_PER_VERTEX_DATA, 0}, {"COLOR",0,DXGI_FORMAT_R32G32B32A32_FLOAT, 0 , 12, D3D10_INPUT_PER_VERTEX_DATA, 0} };

Je remarque dans DirectX 10 que c’est plus descriptif. Outre cela, quels sont les changements radicaux apportés, et la syntaxe HLSL est-elle la même pour les deux?

Je dirais qu’il n’y a pas de changement radical dans la syntaxe HLSL elle-même entre DX9 et DX10 (et par extension DX11).

Comme l’indique Codeka, les modifications consistent davantage à nettoyer l’API et à générer une généralisation (dans l’intérêt du GPGPU). Mais il y a bien des différences notables:

Différences notables:

  • Pour passer constant aux shaders, vous devez maintenant passer par les tampons constants.

  • Un kernel de shader commun: tous les types de shader ont access au même ensemble de fonctions insortingnsèques (à quelques exceptions près, comme pour l’étape GS). Les opérations entières et binarys sont maintenant entièrement compatibles IEEE (et non émulées via une virgule flottante). Vous avez maintenant access aux conversions binarys pour interpréter un int comme un float, un float comme un uint, etc.

  • Textures et Samplers ont été dissociés. Vous utilisez maintenant la syntaxe g_myTexture.Sample( g_mySampler, texCoord ) au lieu de tex2D( g_mySampledTexture, texCoord )

  • Tampons: nouveau type de ressource pour accéder à des données ne nécessitant aucun filtrage de manière aléatoire, à l’aide de la nouvelle fonction Object.Load .

  • Sémantique système-valeur: une généralisation et des extensions de la sémantique POSITION , DEPTH , COLOR , qui sont maintenant SV_Position , SV_Depth , SV_Target et ajout de nouvelles sémantiques par étape, telles que SV_InstanceID , SV_VertexId , etc.

C’est tout ce que je vois pour le moment. Si quelque chose de nouveau me vient à l’esprit, je mettrai à jour ma réponse.

Le changement le plus important que j’ai constaté entre DX9 et DX10 est le fait que sous DX10, vous devez définir un bloc de rendu entier dans lequel vous pouvez modifier des états individuels dans DX9. Cela a quelque peu brisé mon architecture parce que je comptais plutôt pouvoir faire un petit changement et laisser les autres états identiques (Cela ne devient vraiment un problème que lorsque vous définissez des états à partir d’un shader).

L’autre grand changement est le fait que sous DX10, les déclarations de vertex sont liées à un shader compilé (dans CreateInputLayout). Sous DX9, ce n’était pas le cas. Vous venez de définir une déclaration et de définir un shader. Sous DX10, vous devez créer un shader, puis créer une présentation d’entrée associée à un shader donné.

Comme codeka le souligne, D3DVERTEXELEMENT9 est le moyen recommandé de créer des signatures de shader depuis l’introduction de DX9. Les FVF étaient déjà amortis et vous ne parvenez pas, par exemple, à définir une base tangente. Les layouts de vertex sont beaucoup plus puissants et ne vous obligent pas à vous en tenir à un layout. Vous pouvez placer les éléments de sumt où vous voulez.

Si vous voulez en savoir plus sur les dispositions d’entrée DX9, je vous suggère de commencer par MSDN .

Les FVF étaient (en quelque sorte) obsolètes en faveur de D3DVERTEXELEMENT9 (alias Vertex Declarations ) – qui est remarquablement similaire à D3D10_INPUT_ELEMENT_DESC – de toute façon. En fait, la plupart des éléments de DirectX 10 sont remarquablement similaires à ceux de DirectX 9, à l’ exception du pipeline à fonction fixe .

Le plus gros changement entre DirectX9 et DirectX10 a été le nettoyage de l’API (en termes de séparation des préoccupations, ce qui a pour effet de préciser beaucoup plus clairement la nature de l’étape du pipeline, etc.).