volkLoadDeviceTable table functions unset to NULL after return

[dajofrey]

volkLoadDeviceTable

void volkLoadDeviceTable(struct VolkDeviceTable* table, VkDevice device)
{
    volkGenLoadDeviceTable(table, device, vkGetDeviceProcAddrStub);
    printf("%p // table->vkCreateFence after returning from volkGenLoadDeviceTable\n", table->vkCreateFence);
    printf("%p // table->vkAcquireNextImageKHR after returning from volkGenLoadDeviceTable\n", table->vkAcquireNextImageKHR);
}

I added some prints to the volkLoadDeviceTable function.

volkLoadDeviceTable calling code

    // vkCreateDevice etc. abstracted
    struct VolkDeviceTable *Table_p = malloc(sizeof(struct VolkDeviceTable));              
    if (Table_p == NULL) {exit(0);}                                                                                                                                                  
    volkLoadDeviceTable(Table_p, Device);                                                                                                                                
    printf("%p // table->vkCreateFence after returning from volkLoadDeviceTable\n", Table_p->vkCreateFence);
    printf("%p // table->vkAcquireNextImageKHR after returning from volkLoadDeviceTable\n", Table_p->vkAcquireNextImageKHR);                                                                                         
    exit(0);   

Output and Problem Description

0x7fcec0f10450 // table->vkCreateFence after returning from volkGenLoadDeviceTable
0x7fcec0f127c0 // table->vkAcquireNextImageKHR after returning from volkGenLoadDeviceTable
0x7fcec0f10450 // table->vkCreateFence after returning from volkLoadDeviceTable
(nil) // table->vkAcquireNextImageKHR after returning from volkLoadDeviceTable

As you notice, somehow table->vkAcquireNextImageKHR is NULL after the execution returns from volkLoadDeviceTable. But the actual loading completed successfully, otherwise vkAcquireNextImageKHR would be NULL directly after volkGenLoadDeviceTable.

The code worked fine a few days ago. All functions were being loaded correctly. I'm really not sure what is causing this.

I noticed that this at least affects functions loaded by the definition of VK_KHR_swapchain (such as vkAcquireNextImageKHR). Functions loaded when defining VK_VERSION_1_0 (such as vkCreateFence) are not affected. I think this is not really a volk issue, but I'm not sure whom else to ask for help.. Any help would be greatly appreciated!

System:

Arch Linux 5.4.69-1-lts
Vulkan Instance Version: 1.2.153
VkPhysicalDeviceDriverProperties:
---------------------------------
	driverID           = DRIVER_ID_INTEL_OPEN_SOURCE_MESA
	driverName     = Intel open-source Mesa driver
	driverInfo         = Mesa 20.2.0
	conformanceVersion = 1.2.0.0

[zeux]

I have a wild guess... Is the calling code using malloc, or is this for demonstration purposes? I ask because I think this can happen if the size of VolkDeviceTable structure is inconsistent between volk.c and your application, and the output is on the stack instead of being on the heap. Just in case you should still double-check the sizeof(VolkDeviceTable) from the caller perspective and from the volkLoadDeviceTable perspective.

The reason why they can mismatch is when the defines that control the available extensions aren't set consistently, which could happen if the configuration defines are different for volk library and the application.

[dajofrey]

Thank you so much, you're a genius! That's exactly what it was. I still have to figure which defines volk doesn't have, that the calling code has, but the problem is identified. I wish you a wonderful day!