Tableau de correspondance des concepts DirectX / OpenGL (Vulkan)


32

Souvent, une fonctionnalité matérielle similaire est exposée via DirectX et OpenGL en utilisant une terminologie différente.

Par exemple:
Tampon constant / Objet tampon uniforme
RWBuffer / SSBO

Je suis à la recherche d'un graphique exhaustif qui décrit quelle terminologie DirectX est utilisée pour se référer à quel concept OpenGL, et vice-versa.
Où puis-je trouver une telle ressource?


Les commentaires ne sont pas pour une discussion prolongée; cette conversation a été déplacée pour discuter .
trichoplax

Réponses:


55

Je n'ai pas pu trouver un tel graphique sur le Web, alors j'en ai créé un ici. (Tout le monde, n'hésitez pas à ajouter, à élaborer ou à corriger les erreurs. Certaines d'entre elles ne sont que des suppositions basées sur une compréhension partielle de l'API et des composants internes du matériel.)

Bases de l'API

D3D11                          OpenGL 4.x
-----                          ----------
device                         context
immediate context              (implicit; no specific name)
deferred context               (no cross-vendor equivalent, but see
                                GL_NV_command_list)
swap chain                     (implicit; no specific name)
(no cross-vendor equivalent)   extensions
debug layer; info queue        GL_KHR_debug extension

Shaders

D3D11              OpenGL 4.x
-----              ----------
pixel shader       fragment shader
hull shader        tessellation control shader
domain shader      tessellation evaluation shader
(vertex shader, geometry shader, and compute shader
 are called the same in both)

registers          binding points
semantics          interface layouts
SV_Foo semantics   gl_Foo builtin variables

class linkage      subroutines

(no equivalent)    program objects; program linking

(D3D11's normal
 behavior; no      separate shader objects
 specific name)

Géométrie et dessin

D3D11              OpenGL 4.x
-----              ----------
vertex buffer      vertex attribute array buffer; vertex buffer object
index buffer       element array buffer
input layout       vertex array object (sort of)

Draw               glDrawArrays
DrawIndexed        glDrawElements
(instancing and indirect draw are called similarly in both)
(no equivalent)    multi-draw, e.g. glMultiDrawElements​

stream-out         transform feedback
DrawAuto           glDrawTransformFeedback​

predication        conditional rendering
(no equivalent)    sync objects

Tampons et textures

D3D11                    OpenGL 4.x
-----                    ----------
constant buffer          uniform buffer object
typed buffer             texture buffer
structured buffer        (no specific name; subset of SSBO features)
UAV buffer; RWBuffer     SSBO (shader storage buffer object)
UAV texture; RWTexture   image load/store

shader resource view     texture view
sampler state            sampler object

interlocked operations   atomic operations
append/consume buffer    SSBO + atomic counter

discard buffer/texture   invalidate buffer/texture
(no equivalent)          persistent mapping
(D3D11's normal
 behavior; no            immutable storage
 specific name)
(implicitly inserted     glMemoryBarrier; glTextureBarrier
 by the API)

Cibles de rendu

D3D11                     OpenGL 4.x
-----                     ----------
(no equivalent)           framebuffer object
render target view        framebuffer color attachment
depth-stencil view        framebuffer depth-stencil attachment
multisample resolve       blit multisampled buffer to non-multisampled one

multiple render targets   multiple color attachments
render target array       layered image

(no equivalent)           renderbuffer

Requêtes

D3D11                       OpenGL 4.x
-----                       ----------
timestamp query             timer query
timestamp-disjoint query    (no equivalent)
(no equivalent)             time-elapsed query
occlusion query             samples-passed query
occlusion predicate query   any-samples-passed query
pipeline statistics query   (no equivalent in core, but see
                             GL_ARB_pipeline_statistics_query)
SO statistics query         primitives-generated/-written queries 
(no equivalent)             query buffer object

Calculer les shaders

D3D11                     OpenGL 4.x
-----                     ----------
thread                    invocation
thread group              work group
thread group size         local size
threadgroup variable      shared variable

group sync                "plain" barrier
group memory barrier      shared memory barrier
device memory barrier     atomic+buffer+image memory barriers
all memory barrier        group memory barrier

Autres ressources


3
Sensationnel. Ils embauchent probablement les esprits les plus durs du monde pour inventer les noms les plus distincts pour les mêmes choses.
narthex

Ce tableau est génial, merci d'avoir pris le temps de l'écrire!
essuyez

3
" tableau de textures - image en couches " OpenGL les appelle aussi textures de tableaux ; le terme "image en couches" est utilisé principalement autour de leurs pièces jointes dans les FBO. De plus, vous devriez probablement mentionner les objets d'échantillonneur OpenGL et leur état d'échantillonneur équivalent D3D.
Nicol Bolas

2
@ CpCd0y Oui, ils sont familièrement appelés ainsi, mais mon intention ici était de dire comment ces choses sont appelées / comment elles sont représentées dans API-ese.
Nathan Reed

1
@NathanReed: MRT n'est pas utilisé dans la spécification OpenGL, mais la "requête d'occlusion" l'est beaucoup. Le terme «échantillons passés» n'est qu'un type de requête d'occlusion; il y a aussi "tous les échantillons passés" et "conservateurs tous les échantillons passés".
Nicol Bolas

28

Voici une liste non exhaustive de Vulkan et DirectX 12. Ceci est bricolé en utilisant des critères similaires à ceux de Nathan.

Dans l'ensemble, les deux API sont étonnamment similaires. Des choses comme les étapes de shader restent inchangées par rapport à DX11 et OpenGL. Et évidemment, DirectX utilise des vues pour rendre les choses visibles aux shaders. Vulkan utilise également des vues, mais elles sont moins fréquentes.

Le comportement de visibilité du shader diffère un peu entre les deux. Vulkan utilise un masque pour déterminer si un descripteur est visible aux différentes étapes du shader. DX12 gère cela un peu différemment, la visibilité des ressources se fait sur une seule étape ou sur toutes les étapes.

J'ai cassé le jeu de descripteurs / paramètres de racine du mieux que je pouvais. La gestion des descripteurs est l'un des domaines qui varient considérablement entre les deux API. Cependant, le résultat final est assez similaire.

Bases de l'API

Vulkan                              DirectX 12
---------------                     ---------------
n/a                                 IDXGIFactory4
VkInstance                          n/a
VkPhysicalDevice                    IDXGIAdapter1
VkDevice                            ID3D12Device
VkQueue                             ID3D12CommandQueue
VkSwapchain                         IDXGISwapChain3
VkFormat                            DXGI_FORMAT
SPIR-V                              D3D12_SHADER_BYTECODE
VkFence                             fences
VkSemaphore                         n/a
VkEvent                             n/a

La couche WSI de Vulkan fournit des images pour le swapchain. DX12 nécessite des ressources de création pour représenter l'image.

Le comportement général de la file d'attente est assez similaire entre les deux. Il y a un peu d'idiosyncrasie lors de la soumission à partir de plusieurs threads.

J'essaierai de mettre à jour car je me souviens de plus de choses ...

Tampon de commande et pool

Vulkan                              DirectX 12
---------------                     ---------------
VkCommandPool                       ID3D12CommandAllocator
VkCommandBuffer                     ID3D12CommandList/ID3D12GraphicsCommandList

Le verbiage sur le pool de commandes / l'allocateur des documents Vulkan / DX12 énonce le comportement en termes très différents - mais le comportement réel est assez similaire. Les utilisateurs sont libres d'allouer de nombreux tampons / listes de commandes à partir du pool. Cependant, un seul tampon / liste de commandes du pool peut être enregistré. Les pools ne peuvent pas être partagés entre les threads. Ainsi, plusieurs threads nécessitent plusieurs pools. Vous pouvez également commencer l'enregistrement immédiatement après avoir soumis la mémoire tampon / liste de commandes sur les deux.

La liste de commandes DX12 est créée dans un état ouvert. Je trouve cela un peu ennuyeux depuis que je suis habitué à Vulkan. DX12 nécessite également une réinitialisation explicite de l'allocateur de commandes et de la liste de commandes. Il s'agit d'un comportement facultatif dans Vulkan.

Descripteurs

Vulkan                              DirectX 12
---------------                     ---------------
VkDescriptorPool                    n/a
VkDescriptorSet                     n/a
VkDescriptorSetLayout               n/a
VkDescriptorSetLayoutBinding        RootParameter**
n/a                                 ID3D12DescriptorHeap

** RootParameter - pas un équivalent exact de VkDescriptorSetLayoutBinding mais une pensée similaire dans une plus grande image.

VkDescriptorPool et ID3D12DescriptorHeaps sont en quelque sorte similaires (merci Nicolas) en ce qu'ils gèrent tous deux l'allocation des descripteurs eux-mêmes.

Il convient de noter que DX12 ne prend en charge à tout moment que deux tas de descripteurs liés à une liste de commandes. Un CBVSRVUAV et un échantillonneur. Vous pouvez avoir autant de tables de descripteurs que vous voulez référencer ces tas.

Du côté de Vulkan, il y a une limite stricte au nombre maximum d'ensembles de descripteurs que vous indiquez au pool de descripteurs. Sur les deux, vous devez faire un peu de comptabilité manuelle sur le nombre de descripteurs par type que le pool / tas peut avoir. Vulkan est également plus explicite avec le type de descripteurs. Alors que sur DX12, les descripteurs sont CBVSRVUAV ou échantillonneur.

DX12 a également une fonctionnalité où vous pouvez trier un CBV à la volée à l'aide de SetGraphicsRootConstantBufferView. Cependant, la version SRV de cela, SetGraphicsRootShaderResourceView, ne fonctionne pas sur les textures. C'est dans les documents - mais cela peut également vous prendre quelques heures pour comprendre si vous n'êtes pas un lecteur attentif.

Pipeline

Vulkan                              DirectX 12
---------------                     ---------------
VkPipelineLayout                    RootSignature***
VkPipeline                          ID3D12PipelineState
VkVertexInputAttributeDescription   D3D12_INPUT_ELEMENT_DESC
VkVertexInputBindingDescription     "

* ** RootSignature - pas un équivalent exact de VkPipelineLayout .

DX12 combine l'attribut vertex et la liaison en une seule description.

Images et tampons

Vulkan                              DirectX 12
---------------                     ---------------
VkImage                             ID3D12Resource
VkBuffer                            ID3D12Resource
uniform buffer                      constant buffer
index buffer                        index buffer
vertex buffer                       vertex buffer
VkSampler                           sampler
barriers/transitions                barriers/transitions

Les barrières sur les deux API tombent un peu différentes, mais ont un résultat net similaire.

RenderPasses / RenderTargets

Vulkan                              DirectX 12
---------------                     ---------------
VkRenderPass                        render pass
VkFramebuffer                       collection of ID3D12Resource
subpass                             n/a
n/a                                 render target

Les passes de rendu Vulkan ont une belle fonction de résolution automatique. DX12 n'a pas cet AFIAK. Les deux API fournissent des fonctions de résolution manuelle.

Il n'y a pas d'équivalence directe entre VkFramebuffer et les objets dans DX12. Une collection de ID3D12Resource qui mappent aux RTV est une similitude lâche.

VkFramebuffer agit plus ou moins comme un pool de pièces jointes que VkRenderPass référence à l'aide d'un index. Les sous-passages d'un VkRenderPass peuvent référencer n'importe quelle pièce jointe dans un VkFramebuffer en supposant que la même pièce jointe n'est pas référencée plus d'une fois par sous-passage. Le nombre maximal de pièces jointes de couleur utilisées simultanément est limité à VkPhysicalDeviceLimits.maxColorAttachments.

Les cibles de rendu de DX12 ne sont que des RTV qui sont soutenus par des objets ID3D12Resource. Le nombre maximal de pièces jointes couleur utilisées simultanément est limité à D3D12_SIMULTANEOUS_RENDER_TARGET_COUNT (8).

Les deux API nécessitent que vous spécifiez les cibles / passes de rendu lors de la création des objets de pipeline. Cependant, Vulkan vous permet d'utiliser des passes de rendu compatibles, vous n'êtes donc pas verrouillé dans celles que vous spécifiez lors de la création de la ligne de repère. Je ne l'ai pas testé sur DX12, mais je suppose que puisque c'est juste un RTV, c'est également vrai sur DX12.


Bien, c'est du bon travail!
essuyez

Je pense qu'il serait juste de dire cela VkDescriptorPoolet ID3D12DescriptorHeapsont similaires dans leur fonction (dans la mesure où ils affectent les descripteurs), mais assez différents dans la forme, en raison des différences dans la manière globale dont les descripteurs sont traités entre les API. De plus, j'imagine que l'équivalent du D3D12 VkBufferViewest des tampons typés, tout comme pour le D3D11.
Nicol Bolas

Vous avez raison sur le tas de descripteurs. Mis à jour. En ce qui concerne les vues du tampon, les deux API ont un concept de vues. Je ne pourrais pas dire si DX12 a rompu avec la convention DX1 des tampons typés ou non car je n'ai pas beaucoup d'expérience avec DX11.
codingforlove

Pourriez-vous dire que les cibles de rendu D3D12 sont l'équivalent de VkFramebuffer?
Jorge Rodriguez

2
Inspiré par ce sujet, j'ai écrit des implémentations à en-tête unique des rendus Vulkan et DX12: renderers
codingforlove
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.