Answers:
我无法在网上找到这样的图表,因此我在这里做了一个。(每个人都可以随意添加,阐述或纠正任何错误。其中一些只是基于对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
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)
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
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)
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
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
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
这是Vulkan和DirectX 12的非详尽列表。使用类似于Nathan的标准将其拼凑在一起。
总体而言,这两个API惊人地相似。着色器阶段之类的东西在DX11和OpenGL中保持不变。显然,DirectX使用视图使着色器可见。Vulkan还使用视图,但是视图的频率较低。
两者之间的着色器可见性行为有所不同。Vulkan使用遮罩确定描述符在各个着色器阶段是否可见。DX12的处理方式略有不同,资源可见性可以在单个阶段完成,也可以在所有阶段完成。
我尽最大可能破坏了描述符集/根参数。描述符处理是两个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
Vulkan的WSI层为交换链提供图像。DX12需要创建资源来表示图像。
两者之间的一般队列行为非常相似。从多个线程提交时有一些特质。
当我记得更多的东西时,将尝试更新...
Vulkan DirectX 12
--------------- ---------------
VkCommandPool ID3D12CommandAllocator
VkCommandBuffer ID3D12CommandList/ID3D12GraphicsCommandList
Vulkan / DX12文档中有关命令池/分配器的说法用不同的词表述了该行为-但实际行为非常相似。用户可以自由地从池中分配许多命令缓冲区/列表。但是,池中只能记录一个命令缓冲区/列表。池不能在线程之间共享。因此,多个线程需要多个池。您还可以在同时提交两个命令的缓冲区/列表后立即开始记录。
DX12命令列表在打开状态下创建。我觉得这很烦人,因为我习惯了Vulkan。DX12还要求并明确重置命令分配器和命令列表。这是Vulkan中的可选行为。
Vulkan DirectX 12
--------------- ---------------
VkDescriptorPool n/a
VkDescriptorSet n/a
VkDescriptorSetLayout n/a
VkDescriptorSetLayoutBinding RootParameter**
n/a ID3D12DescriptorHeap
** RootParameter-不完全等同于VkDescriptorSetLayoutBinding,但在更大范围内具有相似的想法。
VkDescriptorPool和ID3D12DescriptorHeaps有点相似(感谢Nicolas),因为它们都管理描述符本身的分配。
应该注意的是,DX12在任何给定时间最多仅支持两个绑定到命令列表的描述符堆。一台CBVSRVUAV和一台采样器。您可以具有要引用这些堆的任意多个描述符表。
在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之间处理描述符的总体方式不同。而且,我想像VkBufferView
D3D11一样,等效于D3D12 是类型化缓冲区。