VCC not compiling for graphics pipelines

[Trynera]

btw it's probably not me having corrupted anything with a git clone or anything, I cloned it with the recursive flag and I tried it again after pulling just to be sure! This is the errors I got in my Vulkan code, keep in mind that when I wrote it in GLSL it worked just fine.
Most notible is the part mentioning Operand 3 requiring Kernel and GroupNonUniform capabilities which are generally known for not being available in Graphics Pipelines (afaik)

Validation layer: Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08737 ] | MessageID = 0xa5625282 | vkCreateShaderModule(): pCreateInfo->pCode (spirv-val produced an error):
Operand 3 of Decorate requires one of these capabilities: Kernel GroupNonUniform
OpDecorate %subgroup_id BuiltIn SubgroupId
. The Vulkan spec states: If pCode is a pointer to SPIR-V code, pCode must adhere to the validation rules described by the Validation Rules within a Module section of the SPIR-V Environment appendix (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-08737)
Validation layer: Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08737 ] | MessageID = 0xa5625282 | vkCreateShaderModule(): pCreateInfo->pCode (spirv-val produced an error):
Operand 3 of Decorate requires one of these capabilities: Kernel GroupNonUniform
OpDecorate %subgroup_id BuiltIn SubgroupId
. The Vulkan spec states: If pCode is a pointer to SPIR-V code, pCode must adhere to the validation rules described by the Validation Rules within a Module section of the SPIR-V Environment appendix (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-08737)
Validation layer: Validation Error: [ VUID-VkGraphicsPipelineCreateInfo-layout-07988 ] Object 0: handle = 0xee647e0000000009, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0xec4bec000000000b, type = VK_OBJECT_TYPE_PIPELINE_LAYOUT; | MessageID = 0x215f02cd | vkCreateGraphicsPipelines(): pCreateInfos[0].pStages[0] SPIR-V (VK_SHADER_STAGE_VERTEX_BIT) uses descriptor slot [Set 0 Binding 0] (type VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC) but was not declared in the pipeline layout. The Vulkan spec states: If a resource variables is declared in a shader, a descriptor slot in layout must match the shader stage (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-VkGraphicsPipelineCreateInfo-layout-07988)

Here is the Vertex Shader (shader.vert.c):

#include <shady.h>

location(0) output vec3 fragColor;

vec2 positions[3] =
{
    (vec2){0.0f, -0.5f},
    (vec2){0.5f, 0.5f},
    (vec2){-0.5f, 0.5f}
};

vec3 colors[3] =
{
    (vec3){1.0f, 0.0f, 0.0f},
    (vec3){0.0f, 1.0f, 0.0f},
    (vec3){0.0f, 0.0f, 1.0f}
};

vertex_shader void main()
{
    gl_Position = (vec4){positions[gl_VertexIndex].x, positions[gl_VertexIndex].y, 0.0f, 1.0f};
    fragColor = colors[gl_VertexIndex];
}

Here is the Fragment Shader (shader.frag.c):

#include <shady.h>

location(0) input vec3 fragColor;

location(0) output vec4 outColor;

fragment_shader void main()
{
    outColor = (vec4){fragColor.x, fragColor.y, fragColor.z, 1.0f};
}

probably the most relevent section in the C++ part where I just get every feature from every version of the api (fyi my hardware is not the problem or atleast I don't think it is, also most of it is not my code so don't judge me I'm an idiot):

void createLogicalDevice()
{
	QueueFamilyIndices indices = findQueueFamilies(m_PhysicalDevice, m_Surface);

	std::vector<VkDeviceQueueCreateInfo> queueCreateInfos;
	std::set<uint32_t> uniqueQueueFamilies =
	{
		indices.graphicsFamily.value(),
		indices.presentFamily.value()
	};

	float queuePriority = 1.0f;
	for (uint32_t queueFamily : uniqueQueueFamilies)
	{
		VkDeviceQueueCreateInfo queueCreateInfo{};
		queueCreateInfo.sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO;
		queueCreateInfo.queueFamilyIndex = queueFamily;
		queueCreateInfo.queueCount = 1;
		queueCreateInfo.pQueuePriorities = &queuePriority;
		queueCreateInfos.push_back(queueCreateInfo);
	}

	VkPhysicalDeviceFeatures deviceFeatures{};
	vkGetPhysicalDeviceFeatures(m_PhysicalDevice, &deviceFeatures);

	if (deviceFeatures.shaderInt16 == VK_FALSE || deviceFeatures.shaderInt64 == VK_FALSE)
		throw std::runtime_error("Your device doesn't support the required features");

	VkPhysicalDeviceVulkan11Features vk11Features{};
	vk11Features.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_1_FEATURES;

	VkPhysicalDeviceVulkan12Features vk12Features{};
	vk12Features.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_2_FEATURES;
	vk12Features.pNext = &vk11Features;

	VkPhysicalDeviceVulkan13Features vk13Features{};
	vk13Features.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_1_3_FEATURES;
	vk13Features.pNext = &vk12Features;

	VkPhysicalDeviceFeatures2 deviceFeatures2{};
	deviceFeatures2.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2;
	deviceFeatures2.pNext = &vk13Features;
	deviceFeatures2.features = deviceFeatures;

	vkGetPhysicalDeviceFeatures2(m_PhysicalDevice, &deviceFeatures2);

	VkDeviceCreateInfo createInfo{};
	createInfo.sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO; 
	createInfo.pNext = &deviceFeatures2;

	createInfo.queueCreateInfoCount = static_cast<uint32_t>(queueCreateInfos.size());
	createInfo.pQueueCreateInfos = queueCreateInfos.data();

	createInfo.enabledExtensionCount = static_cast<uint32_t>(m_DeviceExtensions.size());
	createInfo.ppEnabledExtensionNames = m_DeviceExtensions.data();

	if (enableValidationLayers)
	{
		createInfo.enabledLayerCount = static_cast<uint32_t>(m_ValidationLayers.size());
		createInfo.ppEnabledLayerNames = m_ValidationLayers.data();
	}
	else
		createInfo.enabledLayerCount = 0;

	if (vkCreateDevice(m_PhysicalDevice, &createInfo, nullptr, &m_Device) != VK_SUCCESS)
		throw std::runtime_error("Failed to create logical device!");

	vkGetDeviceQueue(m_Device, indices.graphicsFamily.value(), 0, &m_GraphicsQueue);
	vkGetDeviceQueue(m_Device, indices.presentFamily.value(), 0, &m_PresentQueue);
}

Sorry if I'm making your life harder through bad bug reports or just horrible code.

[Trynera]

I compiled Shady and VCC using Visual Studio 2022 if that's important

[Trynera]

So after a bit of investigation I saw that the Shady IR output doesn't have any signs of a SubGroupID or smth like that, but when I look within the LLVM IR, it has mentions of a SubGroupID! So it's probably a problem with the Shady Compiler

[Hugobros3]

The compiler defaults to hiding some internal/generated code from module dumps to make them more readable. You can enable such through --print-generated and --print-internal.

Shady does not use the Kernel capability at all, the first validation error seems to be related to a bad handling of the capabilities at that time. I think the current main branch should not exhibit this issue.

See also the related issue opened today