khronosgroup / vulkan-guide

One stop shop for getting started with the Vulkan API

Vulkan^® Guide

This document is also available in the following languages:
Japanese Korean

The Vulkan Guide is designed to help developers get up and going with the world of Vulkan. It is aimed to be a light read that leads to many other useful links depending on what a developer is looking for. All information is intended to help better fill the gaps about the many nuances of Vulkan.

Note	The Vulkan Guide can be built as a single page using asciidoctor guide.adoc

1. Logistics Overview

1.1. What is Vulkan?

1.2. What you can do with Vulkan

1.3. Vulkan Spec

1.4. Platforms

1.5. Checking for Support

1.6. Versions

1.7. Vulkan Release Summary

1.8. What is SPIR-V?

1.9. Portability Initiative

1.10. Vulkan CTS

1.11. Vulkan Development Tools

1.12. Vulkan Validation Overview

1.13. Vulkan Decoder Ring (GL, GLES, DirectX, and Metal)

2. Using Vulkan

2.1. Loader

2.2. Layers

2.3. Querying Properties, Extensions, Features, Limits, and Formats

2.3.1. Enabling Vulkan Extensions

2.3.2. Enabling Vulkan Features

2.3.3. Using SPIR-V Extension

2.3.4. Formats

2.4. Queues and Queue Family

2.5. WSI

2.6. pNext and sType

2.7. Synchronization

2.7.1. Porting to VK_KHR_synchronization2

2.7.2. Synchronization Examples

2.8. Memory Allocation Strategy

2.8.1. Sparse Resources

2.8.2. Protected Memory

2.9. Pipeline Caching/Derivatives

2.10. Threading

2.11. Depth

• VK_EXT_depth_range_unrestricted, VK_EXT_depth_clip_enable, VK_EXT_depth_clip_control

2.12. Mapping Data to Shaders

2.12.1. Vertex Input Data Processing

2.12.2. Descriptor Dynamic Offset

2.12.3. Push Constants

2.13. Robustness

• VK_EXT_image_robustness, VK_EXT_robustness2, VK_EXT_pipeline_robustness

2.14. Dynamic State

• VK_EXT_extended_dynamic_state, VK_EXT_extended_dynamic_state2, VK_EXT_extended_dynamic_state3, VK_EXT_vertex_input_dynamic_state, VK_EXT_color_write_enable, VK_EXT_attachment_feedback_loop_dynamic_state

2.14.1. Dynamic State Map

2.15. Subgroups

• VK_EXT_subgroup_size_control, VK_KHR_shader_subgroup_extended_types, VK_EXT_shader_subgroup_ballot, VK_EXT_shader_subgroup_vote

2.16. Shader Memory Layout

• VK_KHR_uniform_buffer_standard_layout, VK_KHR_relaxed_block_layout, VK_EXT_scalar_block_layout

2.17. Atomics

• VK_KHR_shader_atomic_int64, VK_EXT_shader_image_atomic_int64, VK_EXT_shader_atomic_float, VK_EXT_shader_atomic_float2

2.18. Common Pitfalls

2.19. Using HLSL shaders

2.20. High Level Shader Language Comparison

3. When and Why to use Extensions

Note	These are supplemental references for the various Vulkan Extensions. Please consult the Vulkan Spec for further details on any extension

3.1. Cleanup Extensions

• VK_EXT_4444_formats, VK_KHR_bind_memory2, VK_KHR_create_renderpass2, VK_KHR_dedicated_allocation, VK_KHR_driver_properties, VK_KHR_get_memory_requirements2, VK_KHR_get_physical_device_properties2, VK_EXT_host_query_reset, VK_KHR_maintenance1, VK_KHR_maintenance2, VK_KHR_maintenance3, VK_KHR_maintenance4, VK_KHR_maintenance5, VK_KHR_maintenance6, VK_KHR_separate_depth_stencil_layouts, VK_KHR_depth_stencil_resolve, VK_EXT_separate_stencil_usage, VK_EXT_sampler_filter_minmax, VK_KHR_sampler_mirror_clamp_to_edge, VK_EXT_ycbcr_2plane_444_formats, VK_KHR_format_feature_flags2, VK_EXT_rgba10x6_formats, VK_KHR_copy_commands2

3.2. Device Groups

• VK_KHR_device_group, VK_KHR_device_group_creation

3.3. External Memory and Sychronization

• VK_KHR_external_fence, VK_KHR_external_memory, VK_KHR_external_semaphore

3.4. Ray Tracing

• VK_KHR_acceleration_structure, VK_KHR_ray_tracing_pipeline, VK_KHR_ray_query, VK_KHR_pipeline_library, VK_KHR_deferred_host_operations

3.5. Shader Features

• VK_KHR_8bit_storage, VK_KHR_16bit_storage, VK_KHR_shader_clock, VK_EXT_shader_demote_to_helper_invocation, VK_KHR_shader_draw_parameters, VK_KHR_shader_float16_int8, VK_KHR_shader_float_controls, VK_KHR_shader_non_semantic_info, VK_EXT_shader_stencil_export, VK_KHR_shader_terminate_invocation, VK_EXT_shader_viewport_index_layer, VK_KHR_spirv_1_4, VK_KHR_storage_buffer_storage_class, VK_KHR_variable_pointers, VK_KHR_vulkan_memory_model, VK_KHR_workgroup_memory_explicit_layout, VK_KHR_zero_initialize_workgroup_memory

3.6. Translation Layer Extensions

• VK_EXT_custom_border_color, VK_EXT_border_color_swizzle, VK_EXT_depth_clip_enable, VK_EXT_depth_clip_control, VK_EXT_provoking_vertex, VK_EXT_transform_feedback, VK_EXT_image_view_min_lod

3.7. VK_EXT_descriptor_indexing

3.8. VK_EXT_inline_uniform_block

3.9. VK_EXT_memory_priority

3.10. VK_KHR_descriptor_update_template

3.11. VK_KHR_draw_indirect_count

3.12. VK_KHR_image_format_list

3.13. VK_KHR_imageless_framebuffer

3.14. VK_KHR_sampler_ycbcr_conversion

3.15. VK_KHR_timeline_semaphore

3.16. VK_KHR_dynamic_rendering

3.17. VK_KHR_shader_subgroup_uniform_control_flow

4. Contributing

5. License

6. Code of conduct

vulkan-guide's Issues

Add an example implementation of `vkGetValue`

In the "pNext and sType" chapter, so that it is clear how it uses pNext and sType to set the value for b as well as for a.

For example (not sure if this is correct):

{
    a.value = 0;
    if (a.pNext != nullptr) {
        auto b = reinterpret_cast<VkB *>(a.pNext);
        if (b->sType == VK_STRUCTURE_TYPE_B) {
              b->value = 0;
        }
    }
}

Update HLSL in Vulkan chapter to match update DXC API

Due to API changes and updates in DXC, I think worth updating this chapter that it correspond to new DXC.

Points to change:

1. IDxcLibrary now has a substitution named IDxcUtils with other methods doing nearly the same.
2. In example you create IDxcCompiler3, but there is no such arguments for Compile() method anymore. They are correspond more to IDxcCompiler2
3. IDxcCompiler3 returns IDxcResult instead of IDxcOperationResult

Adding a "How to Vulkan in 20XX" chapter

During one of our documentation/tutorial related calls we talked about having a document on how to do "modern" Vulkan. A lot has changed since 2016, and with recent extensions like dynamic rendering, descriptor indexing, etc. esp. on desktop you can do a lot of things different and with less code/overhead in 20XX compared to then Vulkan launched.

And one idea that came to my mind was having a "How to Vulkan in 20XX" page that's light on content but directs e.g. desktop people into the right direction by having a list of extensions that are common or even core now which ease up things. E.g. dynamic rendering makes things a lot easier on desktop, but someone that is new to Vulkan has pretty much no chance to find out about this extension (or feature) and when to use it.

At least some of that information is already present in the Vulkan Guide to some extend, but having a "landing page" for stuff like that would be great addition imo.

P.S. : I'd be willing to start this off with a first draft ;)

Add chapter around how memory is laid out for descriptor binding

Similar to to the Vertex Input Data chapter, but around the use of buffer memory blocks in relation to each of the parameters in DescriptorBufferInfo, DescriptorSetLayoutBinding, WriteDescriptorSet and vkCmdBindDescriptorSets

Minor spelling mistake

Spelling mistake. "whe" should be "when"

https://github.com/KhronosGroup/Vulkan-Guide/blob/master/chapters/formats.adoc#packed

Add section about things to know when upgrading Vulkan minor versions

When going from 1.0 -> 1.1 or 1.1 -> 1.2 there are some slight "gotchas" that would be great to document somewhere. Most things would be around the subtle promotion changes that are not always obvious at first glance.

One thing, that prompted this idea, is the Extension Feature Aliases table in the spec and things to know about using certain new promoted extensions/features.

This would probably go into the Version chapter

Adding chapter on HLSL shader model coverage

As the question comes up here and there, would it make sense to have chapter on Vulkan's coverage of the different HLSL shader models?

Similar to this slide from this presentation:

E.g. for SM 6.6 afaik at least some features are already present in Vulkan via certain extensions.

Misleading GLSL/HLSL clamp entry

Vulkan-Guide/chapters/high_level_shader_language_comparison.adoc

Line 971 in c432ecb

| clamp | saturate

HLSL's saturate is clamp(x, 0, 1). HLSL has a clamp function that matches GLSL.

Add CI step for Antora documentation build

We should add a CI step that builds the Antora documentation for this repo to make sure we don't introduce changes that break the build for the Vulkan documentation site.

See KhronosGroup/Vulkan-Site#82

Document how to do D3D12-style command buffer management in Vulkan

There's a particular usage pattern for dynamically recorded command buffers which DX12 applications make use of DX12's ability to free-associate command buffers with command allocators, which is not how things naturally work in Vulkan.

Whilst this might not be the ideal method for managing command buffers in all cases, it works, and is natural for anyone porting D3D12 content.

After discussion in the Vulkan WG, we agreed that the following advice is the right way to achieve the same in Vulkan, with no expected perf implications vs DX12:

• Allocate command pools with VK_COMMAND_POOL_CREATE_TRANSIENT_BIT
• Treat VkCommandPool objects the same as ID3D12CommandAllocator objects
  • I.e. they are externally synchronized command allocators
• Don't pre-allocate command buffers
• Allocate command buffers when you want to begin recording, then begin them
• When the command buffer is no longer in use, free the command buffer
  • Ideally along with all others associated with the same pool

It would be useful to turn this porting advice into a section of the Vulkan-Guide, possibly alongside other porting advice.

More synchronization examples in the wiki?

I find the synchronization examples in the wiki really helpful for beginners like me, as synchronization is a difficult topic in vulkan, and there aren't so many tutorials/examples in the wild. I wonder if there's any plan to finish the remaining examples in the todo list, such as how to handle resource aliasing. Thank you.

Add section about Protected Memory

Protected memory was added in Vulkan 1.1 and should have some info about it in the Vulkan Guide

Add CI to check or build single page guide

as stated in #157 it would be nice to either

1. Add CI to check no warnings are generated when building the guide
2. host the guide.html file somewhere automatically when the guide is updated

Add a section on `LAZILY_ALLOCATED_BIT`

In the "Memory Allocation Strategy" chapter.

This is important for tiled (most mobile) GPUs since they can optimize an attachment that will only be used in a single render pass and doesn't need to be stored

We could also link to the spec and Khronos' tutorial for more info.

Thank you!

Somehow, somewhere, say something about synchronization in Ray Tracing

The way we've ended up making synchronization work for Vulkan ray tracing is not entirely obvious from the spec alone, and it's probably worth a bit of the guide to spell it out. I believe how it's intended to work is as follows:

• For trace or query calls in a shader, use VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR with the relevant shader stage(s) for the acceleration structure
• For accesses to the shader binding table in the ray tracing pipeline, use , VK_ACCESS_SHADER_READ_BIT with VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_KHR
• For builds you use VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR with access bits corresponding to which resource is being accessed:
  • Destination AS uses VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR
  • Source AS (e.g. for updates) use VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR
  • Scratch buffers need both VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR and VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR
  • Vertex/Index/Instance/Transform buffers use VK_ACCESS_SHADER_READ_BIT
• For acceleration structure copy commands you also use VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR, again with access flags dependent on sources
  • Destination AS uses VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR
  • Source AS uses VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR
  • Destination buffer uses VK_ACCESS_TRANSFER_WRITE_BIT
  • Source AS uses VK_ACCESS_TRANSFER_READ_BIT
• For indirect trace calls, the indirect buffer is VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT with VK_ACCESS_INDIRECT_COMMAND_READ_BIT
• For indirect AS builds, the indirect buffer is VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR with VK_ACCESS_INDIRECT_COMMAND_READ_BIT

Of additional note is that VK_PIPELINE_STAGE_TRANSFER_BIT does not work for acceleration structure copy commands, breaking with other copy operations.

CC @dgkoch for confirmation

vkFreeMemory() memory leaks while the VkDeviceMemory object was allocated with VkExportMemoryAllocateInfo

I am using the VK_KHR_external_memory_win32 extension to share GPU memory with OpenGL on Windows, the shared texture works fine.
The memory was allocated by vkAllocateMemory() with VkMemoryAllocateInfo that the pNext contains a VkExternalMemoryImageCreateInfo structure whose handleTypes is VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT/VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_IMAGE_BIT_NV, but the memory will not return to GPU memory heap after the related VkDeviceMemory object was freed by vkFreeMemory().
I have test Intel HD 630 / AMD RX 5700XT / Nvidia 1660 Ti graphics cards, all of them have the memory leaks issue no matter if the dedicated memory is enable or not.

Unclear when non-core formats are allowed to be used

VkPhysicalDeviceFeatures has the textureCompressionBC, textureCompressionETC2, and textureCompressionASTC_LDR feature flags, giving us information about the relevant formats and whether they are supported with optimal tiling. There's also many more extensions and Vulkan versions providing new formats.

Yet vkGetPhysicalDeviceImageFormatProperties is a physical device function, which means that it cannot know which extensions or which features we have enabled. And we seem to also be able to freely use any format that is reported as supported by the aforementioned function, even if the corresponding extension is not enabled. The spec also doesn't have any VUID which says anything about format extensions or format features to be enabled. The docs for vkGetPhysicalDeviceImageFormatProperties reports:

To query for additional properties, or if the feature is not enabled, vkGetPhysicalDeviceFormatProperties and vkGetPhysicalDeviceImageFormatProperties can be used to check for supported properties of individual formats as normal.

So, based on "or if the feature is not enabled", are the features just to quickly guarantee many formats to be usable in specific use-cases?

Reading through VkPhysicalDevice4444FormatsFeaturesEXT:

VkPhysicalDevice4444FormatsFeaturesEXT can also be used in the pNext chain of VkDeviceCreateInfo to selectively enable these features.

How else would they be enabled? Does this mean enabling format features is entirely optional?

Now, VkDeviceCreateInfo requires us to provide a VkPhysicalDeviceFeatures struct with all features we want to have enabled. So, what effect does enabling textureCompressionBC, textureCompressionETC2, or textureCompressionASTC_LDR have? What's the point of enabling e.g. VK_IMG_format_pvrtc if we can just query the format properties anyway to determine if we can use it? Are these just meta-extensions? Does the device even have to report VK_IMG_format_pvrtc` if the extensions are supported? Finally, why does this not follow the common extension/feature paradigm where we need to keep track of which features/extensions are available and were enabled, and determine our Vulkan usage based on that?

Renderpass page

Looking at the list of topics, it seems there is room for a short page on renderpasses.
Nothing extravagant, just a "heres what, why, when, and links to detailed descriptions" kind of thing.
I am willing to write it if others think its a useful/needed page.

Content Proposal:

• Purpose & rational
• Simple example/use case
• Subpasses, their limitations, and when to use them.
• Mention how mobile uses renderpasses for efficiency
• Links to external sources - Are these good links and what else is there to add?
  • Vulkan-Samples https://github.com/KhronosGroup/Vulkan-Samples/blob/master/samples/performance/render_subpasses/render_subpasses_tutorial.md
  • GPUinfo https://gpuopen.com/vulkan-renderpasses/
  • Samsung https://developer.samsung.com/game/renderpasses

Add chapter on using profiles

With profiles gaining more importance as an alternative to Vulkan versioninig, we should have a chapter for them under "Using Vulkan".

VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT description is ambiguous.

The description of VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT currently reads as follows (v1.2.189):

VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT specifies that the memory bound to this image will be allocated with the VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (see https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#memory for more detail). This bit can be set for any image that can be used to create a VkImageView suitable for use as a color, resolve, depth/stencil, or input attachment.

The usage of 'will be' here is quite ambiguous. I read it as 'must be', but others (including the validation layers) seem to interpret this as 'may be'.

Can this be clarified and updated to use the terminology specified in 2.1.2 (must/should/may etc.)?

Subgroup documentation

It would be nice to add a small page explaining the basic concepts of subgroups. There are many sources to point at, just realize there is no chapter/section for it here yet

How about add another link of helpful post of synchronization?

Hi, I'm recently studying about synchronization(legacy) and thanks for this repo, got tons of knowledge from the synchronization post. It provides us several of useful references but I got some understanding from this post as well. So why don't you add that post? I think it can give meaningful intuitives to beginners.

compare directX11 and vulkan in UE5 use NVIDIA Nsight

ue5 render VolumetricCloud call vkCmdDispatch use 0.88ms capture frame in Nsight.

but use directX11 call Dispatch use 0.40ms only.

it is a little strange.
figure of vulkan API call:

figure of dx11 API call:

Asciidoctor error on Make - MacOS

Using MacOS and compiling the guide the following error shows up:

asciidoctor --failure-level WARNING -b html5 guide.adoc
asciidoctor: WARNING: chapters/extensions/VK_KHR_sampler_ycbcr_conversion.adoc: line 19: id assigned to section already in use: formats
make: *** [guide.html] Error 1

However, the guide.html file is generated. Is it ok?

No samples containing main()

I'm trying learn via the web but every "sample" I look at makes no mention of main() and how to go about getting a thread of vulkan, specifically I want to offload some code to my gfx card to cut down the time it takes to stress test it, I basically wrote a function under MIT License to read a float string and output a float or double or long double or any other size based on what the user provides, it worked fine in when I did upto 128.128e+/-128 but my CPU is not cut out for checking every number between 0.0e+-/0 to 1024.1024e+/-1024, that's over a billion numbers to try while also using slower big int routines to cope with flexible size.

Vulkan injection issue

Hi, I'm working on a Vulkan application (that has nothing to do with OBS).. and I have strange messages and unexpected crash

[OBS] OBS_CreateDevice: texture sharing is not supported
[OBS] Failed to open pipe
[OBS] graphics-hook.dll loaded against process: coffeecupd.exe
[OBS] (half life scientist) everything.. seems to be in order

Seems like obs is injecting something in my code..how can I isolate my Vulkan application?

Add a link to Vulkan Samples

Not sure which chapter would be most relevant, maybe we could add it in the README?

Thank you!

translation_layer_extensions issues

https://docs.vulkan.org/guide/latest/extensions/translation_layer_extensions.html is missing VK_EXT_mutable_descriptor_type, VK_EXT_non_seamless_cube_map.

https://docs.vulkan.org/guide/latest/extensions/translation_layer_extensions.html#VK_EXT_transform_feedback should also be updated to point to https://www.gfxstrand.net/faith/blog/2018/10/transform-feedback-is-terrible-so-why/ and reflect the author's current name

Add section about different ways of uploading data to the GPU?

During a recent Vulkan documentation related call, we've been talking about having a single resource on the different ways for getting data uploaded to the GPU. E.g. using uniform buffers, storage buffers, push constants (for which there is already a PR), etc.

We were wondering if this would be a good fit for the Vulkan guide? It doesn't have to be too detailed, but more of a "hey, here are all the ways of getting data to the GPU and here are some things you need to consider when using this and that way".

Add section with in-depth details on Vulkan Memory Model

Assuming most people want a slight better understanding of both what the Memory model is and how it effects their applications

pnext_and_stype section should use VkBaseInStructure

To the extent this section needs to be proposing pseudocode for a driver implementation of traversing a pNext chain, it should probably be casting its way through the chain using VkBaseIn/OutStructure rather than VkA, since that's precisely the scenario they exist for.

This is a very small issue.

Rendering backticks with trailing `s` not closing monospace block

Looks like the new site renderer (as does GH's adoc renderer) has trouble with things like plural references, `VkImageView`s in the example. This works just fine in GitHub where the monospace is properly closed before s: VkImageViews - but not on the new site nor when GH renders the adoc:

https://registry.khronos.org/vulkan/site/guide/latest/extensions/VK_KHR_imageless_framebuffer.html
https://github.com/KhronosGroup/Vulkan-Guide/blob/main/chapters/extensions/VK_KHR_imageless_framebuffer.adoc

Rework or elaborate development tools chapter

The development tools chapter is a bit light on details and also kinda mixes some tools. E.g. AMD's RGP is listed as a profiler, while it an also do debugging. Vice versa nvidia's nsight is only listed as a debugger while it can also do profiling.

We should try to rework this and maybe instead of splitting between profiling/debugging tools we could just have one chapter and then write a small note on each tool. We could then also add that RenderDoc is a vendor independent debugger and kinda like the "official" debugging tool for Vulkan.

Rename default branch to 'main'

This repo slipped under the radar somehow but should do this to abide by Khronos policy. Not sure who admins the repo but I'm happy to do it if you want - as with all the other repos, it's just a matter of invoking the github renaming tool.

Add entry for VK_KHR_fragment_shading_rate

We recently noticed that there's no guide entry for this extension - however there is a Khronos blog post here: https://www.khronos.org/blog/khronos-vulkan-working-group-releases-shading-rate-extension-to-increase-rendering-performance-and-quality

Would be good if an entry could be added; much of the text in the blog post can probably be used directly?

Link to references page; is that curated also?

I noticed that what_is_vulkan.md links to https://github.com/KhronosGroup/Khronosdotorg/blob/master/api/vulkan/resources.md#libraries

to show other 3rd party libraries/tools/resources etc. Is that resources.md at Khronosdotorg actively curated as well? Is there a reason it is in Khronosdotorg instead of being in the Vulkan Guide repository?

Guide/latest - broken link

These is one malformed link in the guide:

On this page https://docs.vulkan.org/guide/latest/layers.html near the top, this link:
/data/local/debug/vulkan
Points to:
hhttps://cs.android.com/android/platform/superproject//android-9.0.0_r1:frameworks/native/vulkan/libvulkan/layers_extensions.cpp;l=454[returns%201],%20then%20the%20loader%20will%20look%20in%20link:https://cs.android.com/android/platform/superproject//android-9.0.0_r1:frameworks/native/vulkan/libvulkan/layers_extensions.cpp;l=67

The schema has an extra h (hhttps) and the URL appears to be non-existent, once the schema is corrected.

Section about compressed formats

https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#_compressed_image_formats

Would not suggest not going into the internal of the compressions at all, but instead to post links to where more information could be found.

One thing worth maybe showing is how to query/check for support such as the textureCompressionASTC_LDR feature bits and such. Then maybe just describe how using a compressed format is actually as easy as changing the VK_FORMAT used in your flow

Missing table column delimiter

Vulkan-Guide/chapters/high_level_shader_language_comparison.adoc

Line 329 in c432ecb

| POSITIONT Transformed vertex position | float4

Missing | breaks the table formatting.

Incorrect case for GLSL fine derivatives

Vulkan-Guide/chapters/high_level_shader_language_comparison.adoc

Lines 972 to 977 in c432ecb

	| dFdx | ddx
	| dFdxCoarse | ddx_coarse
	| DFdxFine | ddx_fine
	| dFdy | ddy
	| dFdyCoarse | ddy_coarse
	| DFdyFine | ddy_fine

Should be dFdxFine and dFdyFine.

Incorrect sparse texture status HLSL mapping

Vulkan-Guide/chapters/high_level_shader_language_comparison.adoc

Line 580 in c432ecb

| sparseTexelsResidentARB | SampleLevel

sparseTexelsResidentARB corresponds to HLSL's CheckAccessFullyMapped.

Missing links in layers documentation

https://docs.vulkan.org/guide/latest/layers.html#_creating_a_layer has links to github resources about the layer factory tool. These links are outdated.

I didn't find any references to layer factory in this repository, so I might be in the wrong place. Please close this issue when so and refer me to the right location.

Typo in sentence

Hello there.

I think that "T) which is only designed for emulation layers" at the end of https://github.com/KhronosGroup/Vulkan-Guide/blob/master/chapters/validation_overview.adoc is a mistake. I don't know what would be the correct version to open a corrective PR.

Add chapter with GLSL to HLSL mapping

We already have a decoder ring with terminologies compared across different apis. I think it would be good idea to have something similar for GLSL and HLSL. I often find it difficult to find HLSL terms matching GLSL terms, e.g. built-ins.

The list from here is something we could use as a base and then add in newer mappings, e.g. for ray tracing, mesh shading etc.

This document could also be used for sourcing information.