Layers can't seem to see my maxBufferSize, which vulkaninfo shows as 1GB

[dancingmirrors]

Environment:

• OS: Linux 64-bit (Debian Trixie)
• GPU and driver version: weird hasvk fork on Ivy Bridge
• SDK or header version if building from repo: not sure, a few days ago's round of stuff (11/18/25)
• Options enabled (synchronization, best practices, etc.): VK_LOADER_LAYERS_ENABLE=VK_LAYER_KHRONOS_validation

Validation Error: [ VUID-VkBufferCreateInfo-size-06409 ] | MessageID = 0xec321b6c (Warning - This VUID has now been reported 10 times, which is the duplicate_message_limit value, this will be the last time reporting it). vkCreateBuffer(): pCreateInfo->size (247680) is larger than the maximum allowed buffer size VkPhysicalDeviceMaintenance4Properties.maxBufferSize (0).

I see two bugs. vulkaninfo shows maxBuffersize correctly, and also it's still being displayed after some rate-limit was supposed to be happening.

It should recognize maxBufferSize as 1GB which I've now hardcoded in hasvk. In some cases this could previously cause a crash that only happens with layers enabled, which I fixed by accident.

Validation Error: [ VUID-VkBufferCreateInfo-size-06409 ] | MessageID = 0xec321b6c (Warning - This VUID has now been reported 10 times, which is the duplicate_message_limit value, this will be the last time reporting it). vkCreateBuffer(): pCreateInfo->size (247680) is larger than the maximum allowed buffer size VkPhysicalDeviceMaintenance4Properties.maxBufferSize (0).

vulkaninfo | grep maxBuf maxBufferSize = 0x40000000

It's easy to see this with mpv/plplay/ffplay - --gpu-context=waylandvk, -hwaccel vulkan, etc.

Sorry, I can't reproduce the crash anymore. It said something to the effect of "no slab to serve".

[dancingmirrors]

Ah, here is the crash:

error:     #1  0x00007fdf1b1a5744 in _ZN11DebugReport10LogMessageEjSt17basic_string_viewIcSt11char_traitsIcEERK13LogObjectListRK8L
ocationRKNSt7__cxx1112basic_stringIcS2_SaIcEEE+0xa20 at /usr/local/lib/libVkLayer_khronos_validation.so+0x15a5744
error:     #2  0x00007fdf1b1a79e0 in _ZN11DebugReport16LogMessageVaListEjSt17basic_string_viewIcSt11char_traitsIcEERK13LogObjectLi
stRK8LocationPKcP13__va_list_tag+0x62 at /usr/local/lib/libVkLayer_khronos_validation.so+0x15a79e0
error:     #3  0x00007fdf19fe3589 in _ZNK6Logger8LogErrorESt17basic_string_viewIcSt11char_traitsIcEERK13LogObjectListRK8LocationPKcz+0xdb at /usr/local/lib/libVkLayer_khronos_validation.so+0x3e3589
error:     #4  0x00007fdf1ac3e15a in _ZNK9stateless6Device34manual_PreCallValidateCreateBufferEP10VkDevice_TPK18VkBufferCreateInfoPK21VkAllocationCallbacksPP10VkBuffer_TRKNS_7ContextE+0x69c at /usr/local/lib/libVkLayer_khronos_validation.so+0x103e15a
error:     #5  0x00007fdf1a7214fa in _ZNK9stateless6Device27PreCallValidateCreateBufferEP10VkDevice_TPK18VkBufferCreateInfoPK21VkAllocationCallbacksPP10VkBuffer_TRK11ErrorObject+0x45e at /usr/local/lib/libVkLayer_khronos_validation.so+0xb214fa
error:     #6  0x00007fdf19f66914 in _ZN20vulkan_layer_chassis12CreateBufferEP10VkDevice_TPK18VkBufferCreateInfoPK21VkAllocationCallbacksPP10VkBuffer_T+0x154 at /usr/local/lib/libVkLayer_khronos_validation.so+0x366914
error:     #7  0x00007fdf33eea680 in slab_alloc+0x250 at /usr/local/lib/x86_64-linux-gnu/libplacebo.so.357+0xaa680
error:     #8  0x00007fdf33eeba04 in vk_malloc_slice+0x704 at /usr/local/lib/x86_64-linux-gnu/libplacebo.so.357+0xaba04
error:     #9  0x00007fdf33ee0e7a in vk_buf_create+0x24a at /usr/local/lib/x86_64-linux-gnu/libplacebo.so.357+0xa0e7a
error:     #10 0x00007fdf33eb4291 in pl_buf_create+0x1f1 at /usr/local/lib/x86_64-linux-gnu/libplacebo.so.357+0x74291
error:     #11 0x00007fdf33eb6b6d in pl_tex_upload_pbo+0x1dd at /usr/local/lib/x86_64-linux-gnu/libplacebo.so.357+0x76b6d
error:     #12 0x00007fdf33ee37eb in vk_tex_upload+0x88b at /usr/local/lib/x86_64-linux-gnu/libplacebo.so.357+0xa37eb
error:     #13 0x00007fdf33eb3f0f in pl_tex_upload+0x6f at /usr/local/lib/x86_64-linux-gnu/libplacebo.so.357+0x73f0f
error:     #14 0x00007fdf33ee4cce in vk_tex_create+0xd5e at /usr/local/lib/x86_64-linux-gnu/libplacebo.so.357+0xa4cce
error:     #15 0x000055f3987d7ea7 in ui_create+0x227 at plplay+0x4fea7
error:     #16 0x000055f398795d3b in main+0x34b at plplay+0xdd3b
error:     #17 0x00007fdf30a46ca8 in __libc_start_call_main+0x78 at /lib/x86_64-linux-gnu/libc.so.6+0x29ca8
error:     #18 0x00007fdf30a46d65 in __libc_start_main_alias_2+0x85 at /lib/x86_64-linux-gnu/libc.so.6+0x29d65
error:     #19 0x000055f398797171 in _start+0x21 at plplay+0xf171
error: vk->CreateBuffer(vk->dev, &binfo, PL_VK_ALLOC, &slab->buffer): VK_ERROR_VALIDATION_FAILED_EXT (../src/vulkan/malloc.c:458)
error:   for malloc: ../src/gpu/utils.c:576
error: No slab to serve request for  128K bytes (with alignment 0x180) in pool 1!

[spencer-lunarg]

The logic to set maxBufferSize is the following where it first looks in VkPhysicalDeviceVulkan13Properties before setting it with VkPhysicalDeviceMaintenance4Properties

Which are you using? Are you somehow using maintenance4 without enabling VK_KHR_maintenance4 on a 1.2 or less app?

if (IsExtEnabled(extensions.vk_feature_version_1_3)) {
    instance->GetPhysicalDeviceExtProperties(physical_device, extensions.vk_feature_version_1_3, &phys_dev_props_core13);
} else {        
    /// ...

    if (IsExtEnabled(extensions.vk_khr_maintenance4)) {
        VkPhysicalDeviceMaintenance4Properties maintenance4_props = vku::InitStructHelper();
        instance->GetPhysicalDeviceExtProperties(physical_device, extensions.vk_khr_maintenance4, &maintenance4_props);
        phys_dev_props_core13.maxBufferSize = maintenance4_props.maxBufferSize;
    }
}

[spencer-lunarg]

@dancingmirrors 2 more things

1. I tried ffplay, these command options didn't work for me
2. What is the full command to run with a test.mp4 file I have?

[dancingmirrors]

I will investigate your first response. The easiest way for me to reproduce a crash is to do a recursive clone of libplacebo, which has a bunch of submodules, and then run plplay on any mp4. It enables validation layers by default if available and then crashes for me as above. ffplay -hwaccel vulkan seems to work on my end (well, not really, but it happily displays garbage due to Ivy Bridge specific issues that don't exist on Haswell). VK_LOADER_LAYERS_ENABLE=VK_LAYER_KHRONOS_validation mpv --gpu-context=waylandvk --hwdec=no test.mp4 is sufficient to trigger the maxBufferSize messages too.

[spencer-lunarg]

I ran mpv on RADV AMD

libplacebo version: v7.351.0
FFmpeg version: 7.1.1 (runtime 7.1.2)
FFmpeg library versions:
   libavcodec      61.19.101
   libavdevice     61.3.100
   libavfilter     10.4.100
   libavformat     61.7.100
   libavutil       59.39.100
   libswresample   5.3.100
   libswscale      8.3.100

and I see only

vkCmdPushDescriptorSet(): was called but the VK_KHR_push_descriptor extension nor VkPhysicalDeviceVulkan14Features::pushDescriptor feature was enabled.

Which makes me think there is likely the issue I suggested where features/extensions are not being enabled

[spencer-lunarg]

@dancingmirrors I have a fix up (https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/11125) in case we need it, but this has occured before and would like to grasp what is going on

[dancingmirrors]

Your patch fixes both the warning and the crash, but here's some of hasvk's code in case I'm doing something wrong: https://raw.githubusercontent.com/dancingmirrors/mesa/refs/heads/master/src/intel/vulkan_hasvk/anv_device.c

[dancingmirrors]

ffplay -hwaccel vulkan test.mp4 might require a bleeding edge FFmpeg build with --enable-vulkan and --enable-libplacebo.

[dancingmirrors]

It might also require --enable-libshaderc.

[dancingmirrors]

Maybe radv requires some kind of DECODE environment variable?

[dancingmirrors]

It does! Try RADV_VIDEO_DECODE=1.

[spencer-lunarg]

I have tried various things, can't figure it out, but since we are about to release an SDK, rather just get our "hack" in

[spencer-lunarg]

Your patch fixes both the warning and the crash, but here's some of hasvk's code in case I'm doing something wrong: https://raw.githubusercontent.com/dancingmirrors/mesa/refs/heads/master/src/intel/vulkan_hasvk/anv_device.c

You have

   /* Set maxBufferSize for VkPhysicalDeviceMaintenance4Properties.
    * This is also set in get_properties_1_3() for Vulkan 1.3, but we set it
    * here as well to ensure it's available when queried through the
    * Maintenance4 extension in Vulkan 1.2.
    */
   p->maxBufferSize = pdevice->isl_dev.max_buffer_size;

this is wrong, it is queried from VkPhysicalDeviceMaintenance4Properties in a Vulkan 1.2 app ... I can't figure out right now where ANV is normally doing this... but this seems like a lack in CTS coverage, not a VVL bug, so closing (not with our "fix")

[spencer-lunarg]

@dancingmirrors ok found it, its a generated file in build/src/vulkan/runtime/vk_physical_device_properties.c

I can't figure out where vk_set_physical_device_properties_struct comes from, probably some macro magic my debugger can't detect