I am not a vulkan programmer even I'm barely learning opengl but individually you guys are worth like 15 web devs or 6 game devs each do you guys have any tips on how you understood the graphics pipeline so well beyond just "practice and repetition makes perfect"

I am a little confused on what is broken. I thought slang compilation was supposed to "handle the bindings." so here I would of expected that ubo would of been included in only the vertex spirv, and texSampler would only be included in the fragment spirv. I am sure that there is probably something I need to do explicitly here, but I was sold on slang auto-magically handing these types of things. I am new to graphics programming and initially followed the old tutorial to completion then wanted to try porting over to slang. Any help is appreciated, as i have been digging through the slang and vulkan documentation for a while and its been hard to figure out how it all comes together without a real example.

slang file :

struct MatrixParameters{
float4x4 model;
float4x4 view;
float4x4 proj;
}
struct Vertex{
float3 position;
float3 color;
float2 uv;
}
struct VOut
{
float4 position : SV_POSITION;
float3 fragColor;
float2 fragTexCoord;
}
ConstantBuffer<MatrixParameters> ubo;
[shader("vertex")]
VOut main(Vertex input)
{
VOut output;
output.position = mul(ubo.proj, mul(ubo.view, mul(ubo.model, float4(input.position, 1.0))));
output.fragColor = input.color;
output.fragTexCoord = input.uv;
return output;
}
uniform DescriptorHandle<Sampler2D> texSampler;
[shader("fragment")]
float4 main(VOut input) : SV_TARGET
{
float4 outColor = float4(input.fragColor * texSampler.Sample(input.fragTexCoord).rgb, 1.0);
return outColor;
}

c++ program file :

// CREATING DESCRIPTOR SET LAYOUT
VkDescriptorSetLayoutBinding uboLayoutBinding{};
uboLayoutBinding.binding = 0;
uboLayoutBinding.descriptorType = VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER;
uboLayoutBinding.descriptorCount = 1;
uboLayoutBinding.stageFlags = VK_SHADER_STAGE_VERTEX_BIT;
uboLayoutBinding.pImmutableSamplers = nullptr;

VkDescriptorSetLayoutBinding samplerLayoutBinding{};
samplerLayoutBinding.binding = 1;
samplerLayoutBinding.descriptorType = VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER;
samplerLayoutBinding.descriptorCount = 1;
samplerLayoutBinding.pImmutableSamplers = nullptr;
samplerLayoutBinding.stageFlags = VK_SHADER_STAGE_FRAGMENT_BIT;

std::array<VkDescriptorSetLayoutBinding, 2> bindings = { uboLayoutBinding, samplerLayoutBinding };

VkDescriptorSetLayoutCreateInfo layoutInfo{};
layoutInfo.sType = VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO;
layoutInfo.bindingCount = static_cast<uint32_t>(bindings.size());
layoutInfo.pBindings = bindings.data();

vkCreateDescriptorSetLayout(device, &layoutInfo, nullptr, &outDescriptorSetLayout)
...
slangModule->getDefinedEntryPoint(0, vertexEntryPoint.writeRef());
slangModule->getDefinedEntryPoint(1, fragmentEntryPoint.writeRef());

slangResources.mpSessionInstance->createCompositeComponentType(
componentTypes.data(), // {slangModule, vertexEntryPoint, fragmentEntryPoint }
componentTypes.size(),
composedProgram.writeRef(),
diagnosticBlob.writeRef());

composedProgram->getEntryPointCode(
0,
0,
spirvCode,
diagnosticBlob.writeRef()
);
VkShaderModuleCreateInfo shaderModuleCreateInfo{};
shaderModuleCreateInfo.sType = VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO;
shaderModuleCreateInfo.codeSize = spirvCode->getBufferSize();
shaderModuleCreateInfo.pCode = reinterpret_cast<const uint32_t *>(spirvCode->getBufferPointer());
VkShaderModule vertexModule;
vkCreateShaderModule(device, &shaderModuleCreateInfo, nullptr, &comboModule);



composedProgram->getEntryPointCode(
1,
0,
spirvCode2,
diagnosticBlob.writeRef()
);
VkShaderModuleCreateInfo shaderModuleCreateInfoFr{};
shaderModuleCreateInfoFr.sType = VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO;
shaderModuleCreateInfoFr.codeSize = spirvCode2->getBufferSize();
shaderModuleCreateInfoFr.pCode = reinterpret_cast<const uint32_t *>(spirvCode2->getBufferPointer());
VkShaderModule fragmentModule;
vkCreateShaderModule(device, &shaderModuleCreateInfoFr, nullptr, &fragmentModule;

ERROR output :

validation layer: vkCreateGraphicsPipelines(): pCreateInfos[0].pStages[0] shader [VK_SHADER_STAGE_VERTEX_BIT] uses descriptor [Set 0, Binding 1, variable "ubo"] (VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER) but the VkDescriptorSetLayoutBinding::stageFlags was VK_SHADER_STAGE_FRAGMENT_BIT.
(VkDescriptorSetLayout from VkPipelineLayoutCreateInfo::pSetLayouts[0]).
The Vulkan spec states: If a resource variable is declared in a shader and layout is not VK_NULL_HANDLE, the corresponding descriptor set in layout must match the shader stage (https://docs.vulkan.org/spec/latest/chapters/pipelines.html#VUID-VkGraphicsPipelineCreateInfo-layout-07988)
validation layer: vkCreateGraphicsPipelines(): pCreateInfos[0].pStages[1] shader [VK_SHADER_STAGE_FRAGMENT_BIT] uses descriptor [Set 0, Binding 0, variable "globalParams"] (VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER) but the VkDescriptorSetLayoutBinding::stageFlags was VK_SHADER_STAGE_VERTEX_BIT.

Database link: VulkanScope Database

EFIShell0/VulkanScope: Vulkan capabilities and GPU information viewer for Android

I'll also be making OpenGL ES versions and Windows and Linux ARM64/x86_64 versions of VulkanScope soon.

Hey everyone, I've just finished the 2nd video, and followup to my "Modern Vulkan in 2 Hrs" video. Thanks for the awesome feedback on the first one! This 2nd video tackles a ton of stuff:

glTF Model Parsing, Loading, Rendering

Camera, Basic Lighting, Multi-Draw Indirect, Vertex Pulling, Buffer Device Address, etc.

Hope you guys like it!

Resource handling consists of two different parts: managing a CPU-side version like a VkBuffer, VkImage, etc., and managing a GPU-side version like a combination of set, binding, and array indices. From what I've read, it looks to me like a GPU-side handle is created when a CPU-side resource is created. And it makes sense to create them together, since there should be only one reference to such a resource Thus, a resource would look like this:

struct Resource {
    union {
        VkBuffer buffer;
        VkImage image;
        // ...
    };

    struct {
        int set;
        int binding;
        int index;
    } reference;
};

However, such a design would tightly couple resource management with descriptor set handling, because a resource manager would need to know where and how to bind a resource, and this doesn't look too good to me.

Considering all of the above, I have a few questions I can't answer myself:

1. Does the resource manager need to know how to handle descriptors? If not, should the API user handle them himself, given that they should know where to bind the requested resources?
2. If it is the resource manager's job to handle descriptors, doesn't that impose some predefined descriptor layout so that the manager knows where to bind them?
3. If it does enforce some descriptor layout, how do you write shaders that need different input data?

Why doesnt Apple support Vulkan? (I know KosmicKrisp exists)

Is vendor lockin that important? Does that strategy work for them - are there many developers that use metal and not support other platforms? Seems like the result is not really lockin, but just forcing more work for developers?

Kind of feels like a poor architecture decision that helps no one, except maybe giving slightly more control to Apple at the expense of their developers as well as the complexity of maintaining another api.

Hopefully, there are no differences left between CapsViewer and VulkanScope except for the database feature. What are your thoughts? Also, if anyone is experiencing problems, please let me know. Releases · EFIShell0/VulkanScope

I was reading this tutorial https://vkguide.dev/docs/extra-chapter/multithreading/ and it claims that you can compile shaders on a background thread and avoid hitching. Is this true? Are there any drawbacks to this approach?

"For compiling pipelines, vkCreateShaderModule and vkCreateGraphicsPipeline are both allowed to be called from multiple threads at once. A common approach for multithreaded shader compilation is to have a background thread dedicated to it, with it constantly looking into a parallel queue to receive compilation requests, and putting the compiled pipelines into another queue that then the main renderthread will connect to the simulation. This is very important to do if you want to have an engine that doesn’t have a lot of hitching. Compiling shader pipelines can take a very long time, so if you have to compile pipelines at runtime outside of a load screen, then you need to implement such a multithreaded async compile scheme for your game to work well."