This function depends on comctrl32.dll version 6 or higher. Otherwise segmentation fault with ordinal error.

Thanks for the remark.

It isn't introduced by this patch so we should fix this upstream. Might want to discuss with developers what should happen with this code. on devtalk/blender chat.

Geometry shader should not be required.

Is this still required?
https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/vkCmdSetLogicOpEXT.html isn't supported by MoltenVK.

We select the right version through blenders manifest, we haven't seen a comctrl32 related error since this code landed, was this ordinal error actually observed or is this comment just general warning of "watch out here!" ?

I don't have version 6 of comctrl32.dll installed on my local computer, and
An ordinal error was observed by rewriting and building the ghost test cmake file.
It's not a canonical build, of course, so it's in the general sense.

Yes, ideally. But we still don't have general purpose workaround for all of them. The metal backend reimplementation of the geometry shaders is using some tricks in the backend to bind VBOs as SSBOs, which I do not want in the Vulkan Backend.

This is only the dynamic state function. The baked pipeline option is here from vulkan 1.0 https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkPipelineColorBlendStateCreateInfo.html

And yes it is used, it is wrapped by GPU_logic_op_xor_set which could be changed to not require it. But finding another way to draw and keep the same clarity might be tricky. We did change the text edit cursors which lost a bit of clarity. While it might be nice to remove, implementing it is not that difficult.

Just by toggling WITH_VULKAN_BACKEND on/off in cmake, this will trigger a complete rebuild of blender due to the use of a global define, i think we can do better here.

i don't quite understand what you mean, however with a stock build of this diff with vulkan enabled i cannot reproduce the issue you are seeing in either blender
or any of the test executables.

Will add them to the specific modules (ghost, window_manager and gpu) seems to be using it. When metal is a bit further we might want to do that also.

What I mean is simple, it's just that ordinal errors are confusing. What is our policy when it comes to loading Vulkan extensions?

For example, I wrote a test for the difference between extensions in the validation layer for debugging.
Helpers for loading extensions had to be generated at the cmake stage.

line:81
https://github.com/AgAmemnno/tmp-vulkan/blob/master/intern/ghost/CMakeLists.txt

https://github.com/AgAmemnno/tmp-vulkan

Remove void as argument in C++ files. Check other occurrences.

I wrote a pipeline test, but the submit loop causes a bug.
Shouldn't the fence work if this m_currentFrame is incremented?
Waiting for the fence immediately after submit was not a bug.
https://github.com/AgAmemnno/tmp-vulkan/blob/9afe5af6ed4fcb1882b80c23f76b8c15ca5bac90/intern/ghost/intern/GHOST_ContextVK.cpp#L907

I think it's ambiguous whether to force reset the command buffer during the loop or conditionally reset it.
Not adding VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT to flags can cause bugs.

Validation Error: [ VUID-vkBeginCommandBuffer-commandBuffer-00050 ] Object 0: handle = 0x20e874b0d10,

type = VK_OBJECT_TYPE_COMMAND_BUFFER; 
Object 1: handle = 0x2e2cd000000002b, type = VK_OBJECT_TYPE_COMMAND_POOL; | MessageID = 0xb24f00f5 | 
Call to vkBeginCommandBuffer() on VkCommandBuffer 0x20e874b0d10[] attempts to implicitly reset cmdBuffer created from VkCommandPool 0x2e2cd000000002b[] that does NOT have the VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT bit set. 
The Vulkan spec states: 
If commandBuffer was allocated from a VkCommandPool which did not have the VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT flag set, 
commandBuffer must be in the initial state (https://vulkan.lunarg.com/doc/view/1.2.189.0/windows/1.2-extensions/vkspec.html#VUID-vkBeginCommandBuffer-commandBuffer-00050)

This patch only contains some early development. Actual tests hasn't been performed yet. Would be awesome to have access to your pipeline test so we could already cover that part.
I applied the changes you mentioned.

The policy for extension loading is still in discussion. The impact for this is also unclear
I haven't checked but doing this during preprocessing might lead to more licensing issues.
We already added a ticket for this T102055: Vulkan: Validation layers potential licensing risks. Any feedback from your experience is welcome.

When using Shaderc, I ported NVPRO's auxiliary class, but it is an early development for testing.
I used Spirv-cross when generating the pipeline layout. This has been integrated as an extern library.
Implemented Immediate draw test.
However, I only see shaders for doing icon_draw_rect.
Also, since the GPU_SHADER_3D_IMAGE_COLOR input is only 2D, I modified immDrawPixelsTexSetup and set "pos" to 3D.

No problem on my computer.

$make test
Start 40: bf_draw

40/248 Test #40: bf_draw ......................................... ................... Passed 1.19 sec

Please report any errors or crashes.
Source code: https://github.com/AgAmemnno/tmp-vulkan
I didn't follow up on your task enough, so there are many places where the writing doesn't match what you are committing right now.