回答:
ウェブ上でこのようなチャートを見つけることができなかったので、ここで作成しました。（誰でも、どんな間違いでも自由に追加、詳細化、修正できます。これらのいくつかは、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 extensionD3D11 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)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 objectsD3D11 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)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) renderbufferD3D11 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 objectD3D11 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以下は、VulkanとDirectX 12の完全なリストです。これは、Nathanの基準と同様の基準を使用してまとめられています。
全体的に、両方のAPIは驚くほど似ています。シェーダーステージなどは、DX11およびOpenGLから変更されていません。そして明らかに、DirectXはビューを使用して、シェーダーから見えるようにします。Vulkanもビューを使用しますが、ビューはそれほど頻繁ではありません。
シェーダーの可視性の動作は、両者の間で少し異なります。Vulkanは、マスクを使用して、記述子がさまざまなシェーダーステージから見えるかどうかを判断します。DX12はこれを少し異なる方法で処理し、リソースの可視性は単一のステージまたはすべてのステージで実行されます。
記述子セット/ルートパラメータを可能な限り破壊しました。記述子の処理は、2つのAPIの間で大きく異なる領域の1つです。ただし、最終結果はかなり似ています。
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
VulkanのWSIレイヤーは、スワップチェーンの画像を提供します。DX12では、イメージを表す作成リソースが必要です。
一般的なキューの動作は、両者の間で非常に似ています。複数のスレッドから送信する場合、少し特異性があります。
私はより多くのものを覚えているように更新しようとします...
Vulkan DirectX 12
--------------- ---------------
VkCommandPool ID3D12CommandAllocator
VkCommandBuffer ID3D12CommandList/ID3D12GraphicsCommandList
Vulkan / DX12 docsのコマンドプール/アロケーターについての詳細は、動作を非常に異なる言葉で述べていますが、実際の動作はかなり似ています。ユーザーはプールから多数のコマンドバッファ/リストを自由に割り当てることができます。ただし、プールからコマンドバッファ/リストを1つだけ記録できます。プールはスレッド間で共有できません。したがって、複数のスレッドには複数のプールが必要です。また、両方でコマンドバッファ/リストを送信した直後に記録を開始することもできます。
DX12コマンドリストは、開いた状態で作成されます。私はバルカンに慣れているので、これは少し面倒です。DX12では、コマンドアロケーターとコマンドリストの明示的なリセットも必要です。これはVulkanのオプションの動作です。
Vulkan DirectX 12
--------------- ---------------
VkDescriptorPool n/a
VkDescriptorSet n/a
VkDescriptorSetLayout n/a
VkDescriptorSetLayoutBinding RootParameter**
n/a ID3D12DescriptorHeap
** RootParameter -ないと完全に同等VkDescriptorSetLayoutBindingが、大きな画像で同様の考え方。
VkDescriptorPoolとID3D12DescriptorHeapsは、どちらも記述子自体の割り当てを管理するという点で似ています（ニコラスに感謝します）。
DX12は、常にコマンドリストにバインドされた記述子ヒープを最大2つしかサポートしないことに注意してください。1つのCBVSRVUAVと1つのサンプラー。これらのヒープを参照する記述子テーブルはいくつでも持つことができます。
Vulkan側では、記述子プールに通知する記述子セットの最大数にハード制限があります。両方で、プール/ヒープが持つことができるタイプごとの記述子の数について、少しの手動アカウンティングを行う必要があります。また、Vulkanは記述子のタイプにより明示的です。一方、DX12記述子はCBVSRVUAVまたはサンプラーです。
DX12には、SetGraphicsRootConstantBufferViewを使用して、オンザフライでCBVをバインドできる機能もあります。ただし、これのSRVバージョンであるSetGraphicsRootShaderResourceViewは、テクスチャでは機能しません。それはドキュメントにあります-しかし、あなたが慎重な読者でないなら、これを理解するのに数時間かかるかもしれません。
Vulkan DirectX 12
--------------- ---------------
VkPipelineLayout RootSignature***
VkPipeline ID3D12PipelineState
VkVertexInputAttributeDescription D3D12_INPUT_ELEMENT_DESC
VkVertexInputBindingDescription "
* ** RootSignature -ないと完全に同等VkPipelineLayout。
DX12は、頂点属性とバインディングを単一の記述に結合します。
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
両方のAPIの障壁は少し異なりますが、最終的な結果は似ています。
Vulkan DirectX 12
--------------- ---------------
VkRenderPass render pass
VkFramebuffer collection of ID3D12Resource
subpass n/a
n/a render target
Vulkanレンダーパスには優れた自動解決機能があります。DX12にはこのAFIAKはありません。両方のAPIは、手動解決のための機能を提供します。
VkFramebufferとDX12のオブジェクトとの間には直接的な同等性はありません。RTVにマップするID3D12Resourceのコレクションは、緩やかな類似性です。
VkFramebufferは、VkRenderPassがインデックスを使用して参照する添付ファイルプールとほぼ同じように機能します。VkRenderPass内のサブパスは、同じ添付ファイルがサブパスごとに複数回参照されていないと仮定して、VkFramebuffer内の任意の添付ファイルを参照できます。一度に使用される色の添付ファイルの最大数はVkPhysicalDeviceLimits.maxColorAttachmentsに制限されています。
DX12のレンダーターゲットは、ID3D12Resourceオブジェクトによってバッキングされる単なるRTVです。一度に使用されるカラー添付ファイルの最大数は、D3D12_SIMULTANEOUS_RENDER_TARGET_COUNT（8）に制限されています。
両方のAPIでは、パイプラインオブジェクトの作成時にレンダーターゲット/パスを指定する必要があります。ただし、Vulkanでは互換性のあるレンダーパスを使用できるため、ピップラインの作成中に指定したパスにロックされません。DX12ではテストしていませんが、RTVであるため、DX12でも同様です。
VkDescriptorPoolし、ID3D12DescriptorHeapディスクリプタがAPIの間で処理される全体的な方法の違いによる、機能に類似している（彼らはあなたが記述子を割り当てる方法があるという点で）が、フォームで全く異なります。また、D3D11と同様に、D3D12に相当するのVkBufferViewは型付きバッファだと思います。