Rendering issues on Linux

[r-gr]

I'm getting some rendering issues with the code in this repo. I lack the vocabulary to describe it properly so I've attached some screenshots and a video recording (see below).

I've done a lot of debugging but haven't been able to find a cause (unless it's a driver bug, which seems unlikely but not impossible). As a beginner with Vulkan, I don't know where else to go with my investigations. I'm hoping someone here with more experience will recognise the issue.

Everything shown below is running on the main branch of this repo, with no changes aside from to CMakeLists.txt to allow compilation on my system.

---

System info

• OS: Arch Linux (kernel version: 6.17.9)
• Package/driver versions:
  • mesa 1:26.0.3-1
  • vulkan-radeon 1:26.0.3-1
  • volk 1.4.304
  • GLM 1.0.3
  • VMA 3.3.0
  • SDL 3.4.2
  • Slang 2026.5.1
  • cmake 4.3.0
  • gcc 15.2.1
  • clang 22.1.1
• Selected device: AMD Radeon RX 6800 XT (RADV NAVI21)
• Vulkan Instance Version: 1.4.341 (from vulkaninfo)

---

The issue

screenrecording-2026-03-30_21-08-47.mp4

• The issue appears to be deterministic -- every run of the programs shows the same pattern of glitchy fragments with the wrong colour.
• The pattern of glitchy fragments changes with zoom, rotation and window size.
• The glitchy fragments are generally stable frame-to-frame, but by rotating the models and resizing the window I can find ones that flicker (appear/disappear rapidly).
• The incorrect colour appears to come from elsewhere in the image -- the colour is either black (from the background), or blue/green/brown (from the Suzanne models).
• The issue is present when running as a native Wayland window or under X11 compatibility (Xwayland).
• Compiling with GCC and clang gives the same result.

---

Investigations

• Vulkan validation layers reported no issues, including when GPU Assisted Validation was enabled.
• Tried various RADV_DEBUG environment variable flags (nodcc, nodisplaydcc, nofastclears, nohiz, llvm) but none had any effect on the issue.
• Enabled back-face culling (set .cullMode = VK_CULL_MODE_BACK_BIT, .frontFace = VK_FRONT_FACE_COUNTER_CLOCKWISE on rasterizationState). No effect.
• Captured frames in RenderDoc and inspected the pixels with the wrong colour in the Texture Viewer, which showed that:
  1. the correct colour for the fragments were computed by the fragment shader (shown as 'Shader Out' in RenderDoc);
  2. if there was more than one fragment per pixel, the correct fragment passed the depth test;
  3. the wrong colour was written to the final pixel, and it appears to come from a fragment that fails the depth test (although when back-face culling is enabled, there's only one fragment per pixel and the wrong colour appears to come from nowhere).

Example 1 -- pixels in the white part of the Suzanne model's eye are incorrectly coloured black:

Example 2 -- blue fragments appear on top of the brown Suzanne model. The fragment shader's output colour is correct (brown) but the colour written to the texture is blue. (Although the blue fragment fails the depth test, there shouldn't be any blue fragments at that position because there's zero overlap with the blue Suzanne model on the left. Interestingly, the blue model on the left has some incorrect brown pixels on it, like the colours from each model have swapped places.)

Example 3 -- same as example 2 but with back-face culling enabled, showing that the fragment shader outputs the correct colour for the single fragment at that pixel, but the final colour written to the texture is wrong and appears from nowhere:

This bizarre behaviour seems to point towards a driver bug or a hardware issue, but with the major caveat that no other applications or games on my system have any issues, including complex games running under dxvk/Proton. I've also considered issues like the depth texture or swapchain images having the wrong sizes, but everything looks correct in the code.

I'll try to get this code running on Windows on the same machine to confirm if the behaviour is the same. Edit: runs on Windows on the same hardware without issues (Vulkan 1.4.315, compiled with Visual Studio).

I'm happy to provide more details on request.

[SaschaWillems]

These artefacts are typical for non-uniform shader access. But I do enable that feature, and wrap the texture sampling call in the fragment shader inside a NonUniformResourceIndex. So that shouldn't happen. Are you running a modified version of the code/shader?

[r-gr]

Thank you for the diagnosis, much appreciated. I was intentionally not running a modified version of the code when testing this, however I have run modified versions of the code and shaders at other times. I don't think compiled shaders should be cached anywhere but I'll do some further tests to rule that out.

[r-gr]

I cloned a fresh copy of the repo to a different location and can confirm the issue still happens. Given that the shaders are compiled at run-time, I don't think there's any possibility of it running an incorrect cached version of the shader.

I can see in RenderDoc's shader debugger that the value of InstanceIndex is correct and the colour computed for that fragment is correct, but then the final image has the wrong colour...

Narrowing it down, looking for workarounds

1. Changing the vkCmdDrawIndexed call in the render loop to draw each instance separately resolves the issue (but defeats the purpose of instanced drawing):

		for (auto i = 0u; i < textures.size(); i++) {
			vkCmdDrawIndexed(cb, static_cast<uint32_t>(indexCount), 1, 0, 0, i);
		}

2. Disabling the runtimeDescriptorArray feature and hardcoding the size of the textures array in the shader does not fix the issue, so this feature doesn't seem to be the problem.

Sampler2D textures[3];

3. Disabling the shaderSampledImageArrayNonUniformIndexing feature and loading all three textures into a single image with layerCount = 3, then accessing that in the shader as a single Sampler2DArray does fix the issue, so that feature seems to be the problem. I guess this approach only works because all three textures have the same dimensions, pixel format, mip levels, etc. so it's less flexible than the original approach. To give a rough summary of the changes:

Sampler2DArray textureArray;

[shader("fragment")]
float4 main(VSOutput input) {
    // ...
    float3 color = textureArray.Sample(float3(input.UV, input.InstanceIndex)).rgb * input.Factor;
    return float4(diffuse * color.rgb + specular, 1.0);
}

struct Texture {
	VmaAllocation allocation = nullptr;
	VkImage image = VK_NULL_HANDLE;
	VkImageView view = VK_NULL_HANDLE;
	VkSampler sampler = VK_NULL_HANDLE;
} textureArray{};
constexpr uint32_t textureCount = 3;

int main(int argc, char* argv[])
{
	// ...

	ktxTexture* ktxTexture = nullptr;
	std::string filename = "assets/suzanne0.ktx";
	ktxTexture_CreateFromNamedFile(filename.c_str(), 0, &ktxTexture);
	VkImageCreateInfo texImgCI{ ..., .mipLevels = ktxTexture->numLevels, .arrayLayers = textureCount, ... };
	// ...
	VkImageViewCreateInfo texVewCI{ ..., .subresourceRange = { ..., .levelCount = ktxTexture->numLevels, .layerCount = textureCount } };

	// Upload to intermediate buffer ...
	VkBufferCreateInfo imgSrcBufferCI{..., .size = ktxTexture->dataSize * textureCount, ... };
	// ...

	for (auto i = 0u; i < textureCount; i++) {
		std::string filename = "assets/suzanne" + std::to_string(i) + ".ktx";
		ktxTexture_CreateFromNamedFile(filename.c_str(), KTX_TEXTURE_CREATE_LOAD_IMAGE_DATA_BIT, &ktxTexture);
		char* dest = static_cast<char*>(imgSrcAllocInfo.pMappedData) + ktxTexture->dataSize * i;
		memcpy(dest, ktxTexture->pData, ktxTexture->dataSize);
	}

	// Convert to GPU optimal tiled image ...
	VkImageMemoryBarrier2 barrierTexImage{ ..., .subresourceRange = { ..., .levelCount = ktxTexture->numLevels, .layerCount = textureCount } };
	// ...
	for (auto i = 0u; i < textureCount; i++) {
		for (auto j = 0u; j < ktxTexture->numLevels; j++) {
			ktx_size_t mipOffset = 0;
			KTX_error_code _ = ktxTexture_GetImageOffset(ktxTexture, j, 0, 0, &mipOffset);
			copyRegions.push_back({
				.bufferOffset = mipOffset + ktxTexture->dataSize * i, // <- changed
				.imageSubresource = {
					.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT,
					.mipLevel = static_cast<uint32_t>(j),
					.baseArrayLayer = i, // <- new
					.layerCount = 1
				},
				.imageExtent = { .width = ktxTexture->baseWidth >> j, .height = ktxTexture->baseHeight >> j, .depth = 1 }
			});
		}
	}
	// ...
	VkImageMemoryBarrier2 barrierTexImage{ ..., .subresourceRange = { ..., .levelCount = ktxTexture->numLevels, .layerCount = textureCount } };
	// ...

	// changes to descriptor sets because there's now only 1 descriptor ...
}

---

Do you think this is most likely a bug in the drivers on Linux? I'm surprised I don't see this issue in any other applications, but maybe they aren't using the problematic feature 🤷

[SaschaWillems]

I would be surprised if this is a driver bug, as descriptor indexing has been around for quite some time. Maybe Slang isn't outputting the required non-uniform access op codes. I'll have to check.

[fredrikfoss]

I also have this or a similar looking issue, but I think I only started getting it after updating either dependencies or the system and recompiling at some point. I did modify the source and also the assets quite a bit, but I'm fairly sure the rendering issues only started after an update. Alpine Linux.

[fredrikfoss]

Update: it disappeared after moving to multi-draw indirect with one indirect record per object (vkCmdDrawIndirect). Replacing one instanced draw with three one-instance draws using different firstInstance values also worked (but this is all in my C rewrite):

for (uint32_t i = 0; i < 3; i++) {
	vkCmdDrawIndexed(cb, indexCount, 1, 0, 0, i);
}