Hello @Spacefish, this is is a continuation of the video driver regression being tracked at [#836](https://github.com/ValveSoftware/SteamVR-for-Linux/issues/836) affecting X based user sessions.

Thanks for the fast reply.

I use Wayland and have this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38987 in my mesa build (which i ran into before).

For me it looks more like a newly supported filter type for some texture / plane whatever in vulkan which might lead to the assertion? Maybe there is a bug in mesa where it exposes filter types of an extension which was not requested during vulkan device creation or SteamVR accidently requests the extension but does not handle the type?

SteamVR seems to talk / lease the drm device / connector from wayland as well:

Sun Dec 28 2025 03:52:22.062003 [Info] - CHmdWindowSDL: Using Wayland
Sun Dec 28 2025 03:52:22.095797 [Info] - WaylandHMDState: Got interface: wp_drm_lease_device_v1
Sun Dec 28 2025 03:52:22.097397 [Info] - WaylandHMDLeaseDevice::LeaseDevice_DrmFD: /dev/dri/card1
Sun Dec 28 2025 03:52:22.107173 [Info] - WaylandHMDLeaseConnector::LeaseConnector_Done
Sun Dec 28 2025 03:52:22.107210 [Info] - WaylandHMDLeaseDevice::LeaseDevice_Done

Ok, after a restart of my PC SteamVR seems to suddendly work again, but only for like 10-20 seconds, i can even start a game in that time, then it crashes with the same assertion and show "-203" as the error.

It´s somehow random, either it starts into the black screen with backlight on and the assertion, or it starts into the Loader and then stops working 10-20 seconds later going completly black and showing "-203"..

The error i see in the log now some times:
Mon Dec 29 2025 00:03:40.804867 [Error] - CHmdWindowSDL::AcquireNextImage - Failed to acquire swapchain image for: HMD (-1000000000)

I enabled vulkan validation layers just to see if there is anything obvious, there is one that VK_KHR_timeline_semaphore is not requested but still a semaphore is requested via vkCreateSemaphore()

VUID-VkSemaphoreCreateInfo-pNext-pNext(ERROR / SPEC): msgNum: -1880859272 - Validation Error: [ VUID-VkSemaphoreCreateInfo-pNext-pNext ] Object 0: handle = 0x5cf52d1764f0, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x8fe45d78 | vkCreateSemaphore(): pCreateInfo->pNext includes a pointer to a VkStructureType (VK_STRUCTURE_TYPE_SEMAPHORE_TYPE_CREATE_INFO), but its parent extension VK_KHR_timeline_semaphore has not been enabled. The Vulkan spec states: Each pNext member of any structure (including this one) in the pNext chain must be either NULL or a pointer to a valid instance of VkExportMetalObjectCreateInfoEXT, VkExportSemaphoreCreateInfo, VkExportSemaphoreWin32HandleInfoKHR, VkImportMetalSharedEventInfoEXT, VkQueryLowLatencySupportNV, or VkSemaphoreTypeCreateInfo (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkSemaphoreCreateInfo-pNext-pNext)
    Objects: 1
        [0] 0x5cf52d1764f0, type: 1, name: NULL

and the other one that an image is marked as VK_IMAGE_LAYOUT_UNDEFINED but should be VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL

Maybe there is a missing barrier? Or maybe this is from the chromium engine and not from the VR compositor at all..
Looks like some kind of synchronization issue to me, where the image i created and then read from before anything is written to it.

UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x5cf52deb1da0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x30000000003, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x5cf52deb1da0[] expects VkImage 0x30000000003[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
    Objects: 2
        [0] 0x5cf52deb1da0, type: 6, name: NULL
        [1] 0x30000000003, type: 10, name: NULL

And there is one, which is probably a non-issue, that an image is VK_IMAGE_LAYOUT_GENERAL but should be VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL:

UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x5aeb861c61e0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xc500000000c5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x5aeb861c61e0[] expects VkImage 0xc500000000c5[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_GENERAL.
    Objects: 2
        [0] 0x5aeb861c61e0, type: 6, name: NULL
        [1] 0xc500000000c5, type: 10, name: NULL
OnAboutToShowDevicesMenu
OnAboutToShowWorkshopMenu
CQVRSystemReportWindow(0x5bb93d620060)  does not have a property named  "list_column_width"

Never mind the vrcopositor does it correctly regarding the semaphores:

VK_KHR_timeline_semaphore is passed in vkCreateDevice and the VkPhysicalDeviceTimelineSemaphoreFeatures is passed as well with timelineSemaphore = 1:

        ppEnabledExtensionNames:        const char* const* = 0x5619b8fcf970
            ppEnabledExtensionNames[0]:     const char* = "VK_EXT_custom_border_color"
            ppEnabledExtensionNames[1]:     const char* = "VK_EXT_extended_dynamic_state"
            ppEnabledExtensionNames[2]:     const char* = "VK_EXT_host_query_reset"
            ppEnabledExtensionNames[3]:     const char* = "VK_KHR_create_renderpass2"
            ppEnabledExtensionNames[4]:     const char* = "VK_KHR_dedicated_allocation"
            ppEnabledExtensionNames[5]:     const char* = "VK_KHR_external_memory"
            ppEnabledExtensionNames[6]:     const char* = "VK_KHR_external_memory_fd"
            ppEnabledExtensionNames[7]:     const char* = "VK_KHR_external_semaphore"
            ppEnabledExtensionNames[8]:     const char* = "VK_KHR_external_semaphore_fd"
            ppEnabledExtensionNames[9]:     const char* = "VK_KHR_get_memory_requirements2"
            ppEnabledExtensionNames[10]:    const char* = "VK_KHR_image_format_list"
            ppEnabledExtensionNames[11]:    const char* = "VK_KHR_maintenance1"
            ppEnabledExtensionNames[12]:    const char* = "VK_KHR_sampler_ycbcr_conversion"
            ppEnabledExtensionNames[13]:    const char* = "VK_KHR_swapchain"
            ppEnabledExtensionNames[14]:    const char* = "VK_KHR_swapchain_mutable_format"
            ppEnabledExtensionNames[15]:    const char* = "VK_KHR_timeline_semaphore"
            ppEnabledExtensionNames[16]:    const char* = "VK_EXT_display_control"
            ppEnabledExtensionNames[17]:    const char* = "VK_KHR_external_memory_fd"
            ppEnabledExtensionNames[18]:    const char* = "VK_KHR_external_semaphore_fd"
            ppEnabledExtensionNames[19]:    const char* = "VK_EXT_global_priority"
            ppEnabledExtensionNames[20]:    const char* = "VK_EXT_extended_dynamic_state3"
            ppEnabledExtensionNames[21]:    const char* = "VK_EXT_sample_locations"

 pNext:                          VkPhysicalDeviceTimelineSemaphoreFeatures = 0x7ffeb2d0d750:
            sType:                          VkStructureType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_FEATURES (1000207000)
            pNext:                          void* = VkPhysicalDeviceHostQueryResetFeatures
            timelineSemaphore:              VkBool32 = 1

I believe this error is probably just a mistake internally in steamvr. CVulkanVRRenderer::CreateSampler handles sampler type 0~3, but is passed sampler type 4. SteamVR seems to continue on after this error.

I believe this error is probably just a mistake internally in steamvr. CVulkanVRRenderer::CreateSampler handles sampler type 0~3, but is passed sampler type 4. SteamVR seems to continue on after this error.

Yes that´s what i observed as well (continues) but assertions typically end a process / hint at unexpected conditions which are not handled, so it should be looked into wether it is an issue or they can just change the assertion to accept 0-4.

So if i understand this correctly, the old behaviour of mesa was to always call:
radv_initialise_color_surface(device, &color_att[i].cb, iview);

But now it does it conditionally only if VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT is set on the view:

if (iview->vk.usage & VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT)
      radv_initialise_color_surface(device, &iview->color_desc, iview);

So if this is read from the command buffer, the descriptor is probably unintialized / contains garbage data, leading to the crashes..

SteamVR does not seem to do that, this is even reported by the vulkan validation layers, see my earlier bug report here: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/862 which probably is caused by the same underlying issue.

Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01208 ] | MessageID = 0xf855a75b
vkCmdPipelineBarrier(): pImageMemoryBarriers[0].newLayout (VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL) is not compatible with VkImage 0x80000000008[SwapChainImage] usage flags VK_IMAGE_USAGE_TRANSFER_DST_BIT|VK_IMAGE_USAGE_STORAGE_BIT.
The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, and oldLayout or newLayout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL then image must have been created with the VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT usage flag set (https://vulkan.lunarg.com/doc/view/1.4.335.0/linux/antora/spec/latest/chapters/synchronization.html#VUID-VkImageMemoryBarrier-oldLayout-01208)
Objects: 1
    [0] VkImage 0x80000000008[SwapChainImage]

and

Validation Error: [ VUID-vkCmdBeginRenderPass-initialLayout-00895 ] | MessageID = 0x34f84ef4
(Warning - This VUID has now been reported 10 times, which is the duplicate_message_limit value, this will be the last time reporting it).
vkCmdBeginRenderPass(): pRenderPassBegin->renderPass (VkRenderPass 0x3e300000003e3) was created with pCreateInfo->pAttachments[0].initialLayout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, but VkFramebuffer 0x3e400000003e4 pAttachments[0] (VkImageView 0xb000000000b[SwapChainImageView]) usage is VK_IMAGE_USAGE_TRANSFER_DST_BIT|VK_IMAGE_USAGE_STORAGE_BIT.
The Vulkan spec states: If any of the initialLayout or finalLayout member of the VkAttachmentDescription structures or the layout member of the VkAttachmentReference structures specified when creating the render pass specified in the renderPass member of pRenderPassBegin is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL then the corresponding attachment image view of the framebuffer specified in the framebuffer member of pRenderPassBegin must have been created with the VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT usage flag set (https://vulkan.lunarg.com/doc/view/1.4.335.0/linux/antora/spec/latest/chapters/renderpass.html#VUID-vkCmdBeginRenderPass-initialLayout-00895)
Objects: 4
    [0] VkImage 0x80000000008[SwapChainImage]
    [1] VkRenderPass 0x3e300000003e3
    [2] VkFramebuffer 0x3e400000003e4
    [3] VkImageView 0xb000000000b[SwapChainImageView]

I Vibe-Coded a Vulkan Layer which intercepts the vkCreateImage and vkCreateSwapchainKHR and adds the VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT to all 2D images which are >= 1024 and <= 4096 as well as all swapchains.

This fixes the issue for me and i can run SteamVR without issue with Mesa 26.1 Git.
See attached files:

CMakeLists.txt
VK_LAYER_ForceColorAttachment.json
VkLayer_ForceColorAttachment.cpp

Usage: Compile with CMake + make
Replace the path to the .so in VK_LAYER_ForceColorAttachment.json and then load the layer via:

export VK_LAYER_PATH=~/.local/share/vulkan/implicit_layer.d
export VK_INSTANCE_LAYERS="VK_LAYER_ForceColorAttachment"

Should show stuff like

[ForceColorLayer] GetInstanceProcAddr: vkCreateInstance
....
[ForceColorLayer] +++ Added COLOR_ATTACHMENT_BIT to 1024x1024 image (orig 0x7)

B.t.w. i get zero Vulkan Validation Errors now, if i load the LunarG Vulkan Validation layers :)

No crashes since then, SteamVR works wonderfully. Time to VRChat

Yes, it's an application bug. Missing VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT when creating images, this should be caught by VVL too.

Yes, it's an application bug. Missing VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT when creating images, this should be caught by VVL too.

It is caught by VVL!

Heya, I wanted to weigh in since Mesa 26.0.1 is now stable released in Arch Linux. Unfortunately, the short term time to avoid this bug has expired, as my stable system dumps the same assert and experiences the same issues as stated on the bug report.

Describe the bug
On vrcompositor start, ASSERT: "Unhandled sampler filter type!" at /data/src/common/vrcommon/vrrenderer/vulkanrenderer.cpp:2278 is returned. This results in a black screen on my HMD (Index, backlight is ON). SteamVR GUI does not report any errors. Note again that I found this assert in my dmp files, created by vrcompositor. See assert_20260226212909_4-ghedit.txt line 1550.

I use mesa 26.0.1 and vulkan-radeon 26.0.1 from the official Arch repositories. I did not experience this issue before upgrading.

I believe this issue really hinders Vulkan SteamVR use among stable users, softly speaking. I don't see any workarounds right now other than locally patching in the above vibe code by Spacefish. I have nothing else to contribute other than a request to prioritize this issue, because I think it will affect more users in some time notice.

2 hours of jank later: I grabbed the Vulkan SDK, configured Vulkan_INCLUDE_DIR path in the CMakeCache.txt (by default unset) to the SDK's include/ directory and followed these instructions:

Usage: Compile with CMake + make Replace the path to the .so in VK_LAYER_ForceColorAttachment.json

This makes a .so file that I leave in the build directory, then replace the path in the .json file. After that the last instructions:

and then load the layer via:

export VK_LAYER_PATH=~/.local/share/vulkan/implicit_layer.d
export VK_INSTANCE_LAYERS="VK_LAYER_ForceColorAttachment"

I solved this in a harsh way by adding a .sh in /etc/profile.d/ to set these vars on boot.

vrcompositor now works again! So this bandaid also works on Mesa 26.0.1 stable release. I was able to complete a 30 minute VTOL VR mission w/o a hitch. Thanks @Spacefish!

Valve plz fix 🥺
It´s just one bit you have to set on two places.. Should be a "two-liner"

Fixed in 2.16.1

2.16.2 the error is now:
[Error] - ASSERT: "IsDepthFormat(eVkFormat)" at /data/src/common/vrcommon/vrrenderer/vulkanrenderer.cpp:762

I'm also still getting the black screen on my Index when Async is enabled on 2.16.3 with Mesa 26.0.1

@DKesserich - To double-check, you aren't seeing the specific assert in the top-level post though, yes?

@halsafar - That's an assert in a different chunk of the renderer; could you make a different bug for it? Otherwise I'll try to remember to make one a little later and link it here. (The assert you report should definitely be fixed, I just don't want this to turn into a close-and-reopen 'generic any-assert-in-the-code bug' for the sake of my sanity, given that it's titled with a very specific assert, file, and line.)

I'm seeing two different asserts in the startup:

ASSERT: "Unhandled sampler filter type!" at /data/src/common/vrcommon/vrrenderer/vulkanrenderer.cpp:2288. (possibly the exact same assert as OP if ten lines of code have been added above it)

ASSERT: "IsDepthFormat(eVkFormat)" at /data/src/common/vrcommon/vrrenderer/vulkanrenderer.cpp:762.

Though I just double-checked and I also get those when enableLinuxVulkanAsync is false, which seems weird.