<p>Here's a non-exhaustive list of Vulkan and DirectX 12. This is cobbled together using criteria similar to that of Nathan's.</p>

<p>Overall both APIs are surprisingly similar. Things like shader stages remain unchanged from DX11 and OpenGL. And obviously, DirectX uses views to make things visible to shaders. Vulkan also uses views, but they are less frequent.</p>

<p>Shader visibility behavior differs a bit between the two. Vulkan uses a mask to determine if a descriptor is visible to the various shader stages. DX12 handles this a little differently, resource visibility is either done on single stage or all stages.</p>

<p>I broke the descriptor set / root parameter stuff down best I could. Descriptor handling is one of the areas that vary greatly between the two APIs. However, the end result is fairly similar.</p>

<h2><strong>API Basics</strong></h2>

<pre><code>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
</code></pre>

<p>Vulkan's WSI layer supplies images for the swapchain. DX12 requires creation resources to represent the image. </p>

<p>General queue behavior is pretty similar between both. There's a bit of idiosyncrasy when submitting from multiple threads. </p>

<p>Will try to update as I remember more stuff...</p>

<h2><strong>Command Buffer and Pool</strong></h2>

<pre><code>Vulkan                              DirectX 12
---------------                     ---------------
VkCommandPool                       ID3D12CommandAllocator
VkCommandBuffer                     ID3D12CommandList/ID3D12GraphicsCommandList
</code></pre>

<p>Verbiage about command pool/allocator from Vulkan/DX12 docs state the behavior in very different words - but the actual behavior is pretty similar. Users are free to allocate many command buffers/lists from the pool. However, only one command buffer/list from the pool can be recording. Pools cannot be shared between threads. So multiple threads require multiple pools. You can also begin recording immediately after submitting the command buffer/list on both.</p>

<p>DX12 command list are created in an open state. I find this a bit annoying since I'm used to Vulkan. DX12 also requires and explicit reset of the command allocator and command list. This is an optional behavior in Vulkan.</p>

<h2><strong>Descriptors</strong></h2>

<pre><code>Vulkan                              DirectX 12
---------------                     ---------------
VkDescriptorPool                    n/a
VkDescriptorSet                     n/a
VkDescriptorSetLayout               n/a
VkDescriptorSetLayoutBinding        RootParameter**
n/a                                 ID3D12DescriptorHeap
</code></pre>

<p>** <strong>RootParameter</strong> - not an exact equivalent to <strong>VkDescriptorSetLayoutBinding</strong> but similar thinking in the bigger picture.</p>

<p>VkDescriptorPool and ID3D12DescriptorHeaps are sort of similar (thanks Nicolas) in that they both manage allocation of the descriptors themselves. </p>

<p>It should be noted that DX12 only supports at most two descriptor heaps bound to a command list at any given time. One CBVSRVUAV and one sampler. You can have as many descriptor tables as you want referencing these heaps. </p>

<p>On the Vulkan side, there is a hard limit to the max number of descriptor sets that you tell the descriptor pool. On both you have to do a bit of manual accounting on the number of descriptors per type the pool/heap can have. Vulkan is also more explicit with the type of descriptors. Whereas on DX12 descriptors are either CBVSRVUAV or sampler. </p>

<p>DX12 also has a feature where you can sort of bind a CBV on the fly using SetGraphicsRootConstantBufferView. However, the SRV version of this, SetGraphicsRootShaderResourceView, does not work on textures. It's in the docs - but may also take you a couple of hours to figure this out if you're not a careful reader.</p>

<h2><strong>Pipeline</strong></h2>

<pre><code>Vulkan                              DirectX 12
---------------                     ---------------
VkPipelineLayout                    RootSignature***
VkPipeline                          ID3D12PipelineState
VkVertexInputAttributeDescription   D3D12_INPUT_ELEMENT_DESC
VkVertexInputBindingDescription     "
</code></pre>

<p><strong>* **RootSignature</strong> - not an exact equivalent to <strong>VkPipelineLayout</strong>.</p>

<p>DX12 combines the vertex attribute and binding into a single description. </p>

<h2><strong>Images and Buffers</strong></h2>

<pre><code>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
</code></pre>

<p>Barriers on both APIs break down a bit different, but have similar net result.</p>

<h2><strong>RenderPasses / RenderTargets</strong></h2>

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

<p>Vulkan render passes have a nice auto-resolve feature. DX12 doesn't have this AFIAK. Both APIs provide functions for manual resolve. </p>

<p>There's not a direct equivalence between VkFramebuffer and any objects in DX12. A collection of ID3D12Resource that map to RTVs is a loose similarity.</p>

<p>VkFramebuffer acts more or less like an attachment pool that VkRenderPass references using an index. Subpasses within a VkRenderPass can reference any of the attachments in a VkFramebuffer assuming the same attachment isn't referenced more than once per subpass. Max number of color attachments used at once is limited to VkPhysicalDeviceLimits.maxColorAttachments.</p>

<p>DX12's render targets are just RTVs that are backed by an ID3D12Resource objects. Max number of color attachments used at once is limited to D3D12_SIMULTANEOUS_RENDER_TARGET_COUNT (8).</p>

<p>Both APIs require you to specify the render targets/passes at the creation of the pipeline objects. However, Vulkan allows you to use compatible render passes, so you're not locked into the ones you specify during the pipline creation. I haven't tested it on DX12, but I would guess since it's just an RTV, this is also true on DX12.</p>

CC BY-SA 3.0
2016-12-29T11:06:17.883Z
Nice, this is great work!
wip
CC BY-SA 3.0
2016-12-29T16:24:42.290Z
I think it would be fair to say that `VkDescriptorPool` and `ID3D12DescriptorHeap` are similar in function (in that they are how you allocate descriptors), but quite different in form, due to the differences in the overall way descriptors are handled between the APIs. Also, I imagine that the D3D12 equivalent to `VkBufferView` is typed buffers, just as for D3D11.
Nicol Bolas
CC BY-SA 3.0
2016-12-29T16:37:50.477Z
You're right on the descriptor heap. Updated. Regarding the buffer views, both API have a concept of views. I couldn't tell if DX12 has broken away from the DX1 convention of typed buffers or not since I don't have much experience with DX11.
Hai Nguyen
CC BY-SA 3.0
2016-12-30T06:03:19.123Z
Could you say that D3D12 render targets are the equivalent of VkFramebuffer?
Jorge Rodriguez
CC BY-SA 3.0
2016-12-30T08:48:56.470Z
@JorgeRodriguez - I updated response to address your question.
Hai Nguyen
CC BY-SA 3.0
2017-01-09T11:23:24.617Z
Inspired by this topic, I wrote single header implementations of both Vulkan and DX12 renderers:

renderers:https://github.com/chaoticbob/tinyrenderers
Hai Nguyen
CC BY-SA 4.0
2016-12-29T10:12:42.363Z
2019-03-16T20:09:59.560Z
2019-03-16T20:09:59.560Z
Hai Nguyen
<p>I haven't been able to find such a chart on the web, so I made one here. (Everyone, feel free to add, elaborate, or correct any mistakes. Some of these are just best guesses based on a partial understanding of the API and hardware internals.)</p>

<h2>API Basics</h2>



<pre class="lang-none prettyprint-override"><code>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
</code></pre>

<h2>Shaders</h2>

<pre class="lang-none prettyprint-override"><code>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)
</code></pre>

<h2>Geometry and Drawing</h2>

<pre class="lang-none prettyprint-override"><code>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
</code></pre>

<h2>Buffers and Textures</h2>

<pre class="lang-none prettyprint-override"><code>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)
</code></pre>

<h2>Render Targets</h2>

<pre class="lang-none prettyprint-override"><code>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
</code></pre>

<h2>Queries</h2>

<pre class="lang-none prettyprint-override"><code>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
</code></pre>

<h2>Compute Shaders</h2>

<pre class="lang-none prettyprint-override"><code>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
</code></pre>

<h2>Other Resources</h2>

<ul>
<li><a href="https://anteru.net/blog/2013/10/13/2188/" rel="noreferrer">Porting from DirectX11 to OpenGL 4.2</a> – not exhaustive, but a quick discussion of common porting issues</li>
<li><a href="https://msdn.microsoft.com/en-us/windows/uwp/gaming/glsl-to-hlsl-reference" rel="noreferrer">MSDN: GLSL-to-HLSL porting guide</a> – lists correspondences and differences between GLSL and HLSL shading languages</li>
</ul>

CC BY-SA 3.0
2016-12-28T21:10:42.407Z
Wow. They probably hire toughest minds in the world to make up most distinct names for same things.
mdkdy
CC BY-SA 3.0
2016-12-28T21:45:46.330Z
That chart is great, thanks for having taken the time to write it down!
wip
CC BY-SA 3.0
2016-12-28T23:21:42.820Z
"*texture array - layered image*" OpenGL also calls them Array Textures; the term "layered image" is used primarily around their attachments in FBOs. Also, you should probably mention OpenGL sampler objects and their D3D equivalent, sampler state.
Nicol Bolas
CC BY-SA 3.0
2016-12-29T04:14:50.003Z
@NicolBolas Thanks. I've edited and hopefully clarified that.
Nathan Reed
CC BY-SA 3.0
2016-12-30T09:32:58.847Z
Nice chart, but usually I find that `Multiple Render Targets` and `Occlusion Query` are also called the same in OpenGL, in general.
CpCd0y
CC BY-SA 3.0
2016-12-30T22:02:14.560Z
@CpCd0y Yeah, they're colloquially called that, but my intent here was to say what those things are called / how they're represented in API-ese.
Nathan Reed
CC BY-SA 3.0
2016-12-31T03:26:10.050Z
@NathanReed: MRT is not used in the OpenGL specification, but "occlusion query" very much is. The term "samples passed" is merely one kind of occlusion query; there are also "any samples passed" and "conservative any samples passed".
Nicol Bolas
CC BY-SA 4.0
2018-10-25T15:35:49.980Z
Disjoint timer queries in GL: https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_disjoint_timer_query.txt
Shahbaz
CC BY-SA 3.0
2016-12-28T20:29:30.783Z
2016-12-29T04:11:37.157Z
2016-12-29T04:11:37.157Z
Nathan Reed
<p>Often a similar hardware feature is exposed via DirectX and OpenGL using different terminology. </p>

<p>For example:<br>
<a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ff476898(v=vs.85).aspx#Shader_Constant_Buffer" rel="noreferrer">Constant Buffer</a> / <a href="https://www.khronos.org/opengl/wiki/Uniform_Buffer_Object" rel="noreferrer">Uniform Buffer Object</a><br>
<a href="https://msdn.microsoft.com/en-us/library/windows/desktop/ff471472(v=vs.85).aspx" rel="noreferrer">RWBuffer</a> / <a href="https://www.khronos.org/opengl/wiki/Shader_Storage_Buffer_Object" rel="noreferrer">SSBO</a></p>

<p>I am looking for an exhaustive chart that describes which DirectX terminology is used to refer to which OpenGL concept, and vice-versa.<br>
Where can I find such a resource?  </p>

CC BY-SA 3.0
2016-12-29T11:34:17.840Z
Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/50883/discussion-on-question-by-wil-directx-openglvulkan-concepts-mapping-chart).
trichoplax is on Codidact now
<api>
DirectX / OpenGL(Vulkan) concepts mapping chart
wip
# DirectX / OpenGL(Vulkan) concepts mapping chart

(Asked by: username_0 on 2016-12-27)

Often a similar hardware feature is exposed via DirectX and OpenGL using different terminology.

For example:  
[Constant Buffer](https://msdn.microsoft.com/en-us/library/windows/desktop/ff476898(v=vs.85).aspx#Shader_Constant_Buffer) / [Uniform Buffer Object](https://www.khronos.org/opengl/wiki/Uniform_Buffer_Object)  
[RWBuffer](https://msdn.microsoft.com/en-us/library/windows/desktop/ff471472(v=vs.85).aspx) / [SSBO](https://www.khronos.org/opengl/wiki/Shader_Storage_Buffer_Object)

I am looking for an exhaustive chart that describes which DirectX terminology is used to refer to which OpenGL concept, and vice-versa.  
Where can I find such a resource?

**Tags:** api

> **Comments:**
> **username_1**: Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/50883/discussion-on-question-by-wil-directx-openglvulkan-concepts-mapping-chart).  

---

## 2 answers

### Answer by username_5 on 2016-12-28. Score: 62 | Accepted answer

I haven't been able to find such a chart on the web, so I made one here. (Everyone, feel free to add, elaborate, or correct any mistakes. Some of these are just best guesses based on a partial understanding of the API and hardware internals.)

## API Basics

```none
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

```none
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)

```

## Geometry and Drawing

```none
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

```

## Buffers and Textures

```none
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)

```

## Render Targets

```none
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

```

## Queries

```none
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

```

## Compute Shaders

```none
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

```

## Other Resources

* [Porting from DirectX11 to OpenGL 4.2](https://anteru.net/blog/2013/10/13/2188/) – not exhaustive, but a quick discussion of common porting issues
* [MSDN: GLSL-to-HLSL porting guide](https://msdn.microsoft.com/en-us/windows/uwp/gaming/glsl-to-hlsl-reference) – lists correspondences and differences between GLSL and HLSL shading languages

> **Comments:**
> **username_6**: Wow. They probably hire toughest minds in the world to make up most distinct names for same things.  
> **username_0**: That chart is great, thanks for having taken the time to write it down!  
> **username_3**: "*texture array - layered image*" OpenGL also calls them Array Textures; the term "layered image" is used primarily around their attachments in FBOs. Also, you should probably mention OpenGL sampler objects and their D3D equivalent, sampler state.  
> **username_5**: @username_3 Thanks. I've edited and hopefully clarified that.  
> **username_7**: Nice chart, but usually I find that `Multiple Render Targets` and `Occlusion Query` are also called the same in OpenGL, in general.  
> **username_5**: @username_7 Yeah, they're colloquially called that, but my intent here was to say what those things are called / how they're represented in API-ese.  
> **username_3**: @username_5: MRT is not used in the OpenGL specification, but "occlusion query" very much is. The term "samples passed" is merely one kind of occlusion query; there are also "any samples passed" and "conservative any samples passed".  
> **username_8**: Disjoint timer queries in GL: https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_disjoint_timer_query.txt  

---

### Answer by username_2 on 2016-12-29. Score: 37

Here's a non-exhaustive list of Vulkan and DirectX 12. This is cobbled together using criteria similar to that of username_5's.

Overall both APIs are surprisingly similar. Things like shader stages remain unchanged from DX11 and OpenGL. And obviously, DirectX uses views to make things visible to shaders. Vulkan also uses views, but they are less frequent.

Shader visibility behavior differs a bit between the two. Vulkan uses a mask to determine if a descriptor is visible to the various shader stages. DX12 handles this a little differently, resource visibility is either done on single stage or all stages.

I broke the descriptor set / root parameter stuff down best I could. Descriptor handling is one of the areas that vary greatly between the two APIs. However, the end result is fairly similar.

## **API Basics**

```
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's WSI layer supplies images for the swapchain. DX12 requires creation resources to represent the image.

General queue behavior is pretty similar between both. There's a bit of idiosyncrasy when submitting from multiple threads.

Will try to update as I remember more stuff...

## **Command Buffer and Pool**

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

```

Verbiage about command pool/allocator from Vulkan/DX12 docs state the behavior in very different words - but the actual behavior is pretty similar. Users are free to allocate many command buffers/lists from the pool. However, only one command buffer/list from the pool can be recording. Pools cannot be shared between threads. So multiple threads require multiple pools. You can also begin recording immediately after submitting the command buffer/list on both.

DX12 command list are created in an open state. I find this a bit annoying since I'm used to Vulkan. DX12 also requires and explicit reset of the command allocator and command list. This is an optional behavior in Vulkan.

## **Descriptors**

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

```

\*\* **RootParameter** - not an exact equivalent to **VkDescriptorSetLayoutBinding** but similar thinking in the bigger picture.

VkDescriptorPool and ID3D12DescriptorHeaps are sort of similar (thanks Nicolas) in that they both manage allocation of the descriptors themselves.

It should be noted that DX12 only supports at most two descriptor heaps bound to a command list at any given time. One CBVSRVUAV and one sampler. You can have as many descriptor tables as you want referencing these heaps.

On the Vulkan side, there is a hard limit to the max number of descriptor sets that you tell the descriptor pool. On both you have to do a bit of manual accounting on the number of descriptors per type the pool/heap can have. Vulkan is also more explicit with the type of descriptors. Whereas on DX12 descriptors are either CBVSRVUAV or sampler.

DX12 also has a feature where you can sort of bind a CBV on the fly using SetGraphicsRootConstantBufferView. However, the SRV version of this, SetGraphicsRootShaderResourceView, does not work on textures. It's in the docs - but may also take you a couple of hours to figure this out if you're not a careful reader.

## **Pipeline**

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

```

**\* \*\*RootSignature** - not an exact equivalent to **VkPipelineLayout**.

DX12 combines the vertex attribute and binding into a single description.

## **Images and Buffers**

```
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

```

Barriers on both APIs break down a bit different, but have similar net result.

## **RenderPasses / RenderTargets**

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

```

Vulkan render passes have a nice auto-resolve feature. DX12 doesn't have this AFIAK. Both APIs provide functions for manual resolve.

There's not a direct equivalence between VkFramebuffer and any objects in DX12. A collection of ID3D12Resource that map to RTVs is a loose similarity.

VkFramebuffer acts more or less like an attachment pool that VkRenderPass references using an index. Subpasses within a VkRenderPass can reference any of the attachments in a VkFramebuffer assuming the same attachment isn't referenced more than once per subpass. Max number of color attachments used at once is limited to VkPhysicalDeviceLimits.maxColorAttachments.

DX12's render targets are just RTVs that are backed by an ID3D12Resource objects. Max number of color attachments used at once is limited to D3D12\_SIMULTANEOUS\_RENDER\_TARGET\_COUNT (8).

Both APIs require you to specify the render targets/passes at the creation of the pipeline objects. However, Vulkan allows you to use compatible render passes, so you're not locked into the ones you specify during the pipline creation. I haven't tested it on DX12, but I would guess since it's just an RTV, this is also true on DX12.

> **Comments:**
> **username_0**: Nice, this is great work!  
> **username_3**: I think it would be fair to say that `VkDescriptorPool` and `ID3D12DescriptorHeap` are similar in function (in that they are how you allocate descriptors), but quite different in form, due to the differences in the overall way descriptors are handled between the APIs. Also, I imagine that the D3D12 equivalent to `VkBufferView` is typed buffers, just as for D3D11.  
> **username_2**: You're right on the descriptor heap. Updated. Regarding the buffer views, both API have a concept of views. I couldn't tell if DX12 has broken away from the DX1 convention of typed buffers or not since I don't have much experience with DX11.  
> **username_4**: Could you say that D3D12 render targets are the equivalent of VkFramebuffer?  
> **username_2**: @username_4 - I updated response to address your question.  
> **username_2**: Inspired by this topic, I wrote single header implementations of both Vulkan and DX12 renderers:  renderers:https://github.com/chaoticbob/tinyrenderers  

---

