Hi!

I am using noesisgui in a vulkan project.
The UI works fine so far, but since I added a TextBox element I encounter an error randomly within seconds of interacting with the TextBox (see validation layer errors below).
I could not observe the issue so far on capped framerates (<=120), but the point of the project is to put as much load as possible on the small engine and then optimize. Therefore I need the framerate to be unlocked in the end.
I am not sure if this is an error on my side or simply a bug. I found the VK_NAME macro in VkRenderDevice.cpp.

Is there a way to disable profiling or fix the issue by other means?


Thanks for your time, kind regards

Validation Error: [ VUID-vkSetDebugUtilsObjectNameEXT-pNameInfo-02588 ] Object 0: handle = 0x2898b7dbb50, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x30f70d65 | vkSetDebugUtilsObjectNameEXT() pNameInfo->objectHandle cannot be VK_NULL_HANDLE. The Vulkan spec states: pNameInfo->objectHandle must not be VK_NULL_HANDLE (https://vulkan.lunarg.com/doc/view/1.3. ... Info-02588)

Validation Error: [ VUID-VkDebugUtilsObjectNameInfoEXT-objectType-02590 ] Object 0: handle = 0x2898ac57b70, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x9b4c6071 | Invalid VkDeviceMemory Object 0x0. The Vulkan spec states: If objectType is not VK_OBJECT_TYPE_UNKNOWN, objectHandle must be VK_NULL_HANDLE or a valid Vulkan handle of the type associated with objectType as defined in the VkObjectType and Vulkan Handle Relationship table (https://vulkan.lunarg.com/doc/view/1.3. ... Type-02590)

If you compile the renderer in Release configuration mode, the VK_NAME is converted to no_op and you shouldn't get any validation error.

Could you please attach here call stack information about where you are getting those messages? Thank you

Since it also crashes in Release mode I assume it is somewhat linked. Maybe in Debug it just crashes earlier due to profiling?
I provoke the error usually by interacting rapidly with the TextBox (selecting text, inserting, deleting, ..). If the UI is not shown, I have yet to see a crash to occur.

Release Callstack:
nvoglv64.dll!00007ffed66622bb() (Unknown Source:0)
nvoglv64.dll!00007ffed65a7f56() (Unknown Source:0)
NoesisApp.dll!NoesisApp::VKRenderDevice::AllocatePage(NoesisApp::VKRenderDevice::DynamicBuffer & buffer) Line 1234 (d:\uni\DIRE\repo\ext\noesis\Src\Packages\Render\VKRenderDevice\Src\VKRenderDevice.cpp:1234)
NoesisApp.dll!NoesisApp::VKRenderDevice::MapBuffer(NoesisApp::VKRenderDevice::DynamicBuffer & buffer, unsigned int size) Line 1348 (d:\uni\DIRE\repo\ext\noesis\Src\Packages\Render\VKRenderDevice\Src\VKRenderDevice.cpp:1348)
NoesisApp.dll!NoesisApp::VKRenderDevice::MapIndices(unsigned int bytes) Line 1006 (d:\uni\DIRE\repo\ext\noesis\Src\Packages\Render\VKRenderDevice\Src\VKRenderDevice.cpp:1006)
Noesis.dll!00007ffed9d726e9() (Unknown Source:0)
Noesis.dll!00007ffed9d678ad() (Unknown Source:0)
Noesis.dll!00007ffed9bf0bc6() (Unknown Source:0)
Noesis.dll!00007ffed9bee207() (Unknown Source:0)
Noesis.dll!00007ffed9bead6d() (Unknown Source:0)
Noesis.dll!00007ffed9beb4fb() (Unknown Source:0)
DireVk.exe!00007ff6d1576402() (Unknown Source:0)
DireVk.exe!00007ff6d157098e() (Unknown Source:0)
DireVk.exe!00007ff6d1561c2b() (Unknown Source:0)
DireVk.exe!00007ff6d15cce7a() (Unknown Source:0)
kernel32.dll!00007fff505a7614() (Unknown Source:0)
ntdll.dll!00007fff514a26b1() (Unknown Source:0)

Debug Callstack:
nvoglv64.dll!00007ffed617615a() (Unknown Source:0)
nvoglv64.dll!00007ffed617610a() (Unknown Source:0)
vulkan-1.dll!00007fff15f7d954() (Unknown Source:0)
[Inline Frame] VkLayer_khronos_validation.dll!DispatchSetDebugUtilsObjectNameEXT(VkDevice_T *) Line 1264 (c:\j\msdk\build\Vulkan-ValidationLayers\repo\layers\generated\layer_chassis_dispatch.cpp:1264)
VkLayer_khronos_validation.dll!vulkan_layer_chassis::SetDebugUtilsObjectNameEXT(VkDevice_T * device, const VkDebugUtilsObjectNameInfoEXT * pNameInfo) Line 10025 (c:\j\msdk\build\Vulkan-ValidationLayers\repo\layers\generated\chassis.cpp:10025)
vulkan-1.dll!00007fff15f5c7dc() (Unknown Source:0)
NoesisApp.dll!NoesisApp::VKRenderDevice::AllocatePage(NoesisApp::VKRenderDevice::DynamicBuffer & buffer) Line 1231 (d:\uni\DIRE\repo\ext\noesis\Src\Packages\Render\VKRenderDevice\Src\VKRenderDevice.cpp:1231)
NoesisApp.dll!NoesisApp::VKRenderDevice::MapBuffer(NoesisApp::VKRenderDevice::DynamicBuffer & buffer, unsigned int size) Line 1348 (d:\uni\DIRE\repo\ext\noesis\Src\Packages\Render\VKRenderDevice\Src\VKRenderDevice.cpp:1348)
NoesisApp.dll!NoesisApp::VKRenderDevice::MapVertices(unsigned int bytes) Line 995 (d:\uni\DIRE\repo\ext\noesis\Src\Packages\Render\VKRenderDevice\Src\VKRenderDevice.cpp:995)
Noesis.dll!00007ffed9d726ce() (Unknown Source:0)
Noesis.dll!00007ffed9d678ad() (Unknown Source:0)
Noesis.dll!00007ffed9bf0bc6() (Unknown Source:0)
Noesis.dll!00007ffed9bee207() (Unknown Source:0)
Noesis.dll!00007ffed9bead6d() (Unknown Source:0)
Noesis.dll!00007ffed9beb4fb() (Unknown Source:0)
DireVk.exe!Gui::draw() Line 89 (d:\uni\DIRE\repo\src\gui\gui.cpp:89)
DireVk.exe!`App::draw'::`2'::<lambda_1>::operator()(VkCommandBuffer_T * commandbuffer, int frame_index) Line 150 (d:\uni\DIRE\repo\src\app\app.cpp:150)
DireVk.exe!std::invoke<`App::draw'::`2'::<lambda_1> &,VkCommandBuffer_T *,int>(App::draw::__l2::<lambda_1> & _Obj, VkCommandBuffer_T * && _Arg1, int && <_Args2_0>) Line 1573 (c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\type_traits:1573)
DireVk.exe!std::_Invoker_ret<void>::_Call<`App::draw'::`2'::<lambda_1> &,VkCommandBuffer_T *,int>(App::draw::__l2::<lambda_1> & _Func, VkCommandBuffer_T * && <_Vals_0>, int && <_Vals_1>) Line 672 (c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\functional:672)
DireVk.exe!std::_Func_impl_no_alloc<`App::draw'::`2'::<lambda_1>,void,VkCommandBuffer_T *,int>::_Do_call(VkCommandBuffer_T * && <_Args_0>, int && <_Args_1>) Line 832 (c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\functional:832)

This seems to be an out of memory scenario, requesting a dynamic buffer for geometry, this could happen if many frames are enqueued without rendering them.

Are you correctly using the frameNumber and safeFrameNumber members of the RecordingInfo struct passed to VKRenderDevice::SetCommandBuffer ?

This was actually the issue, thank you very much!

I misinterpreted safeFrameNumber as frame in flight index, which I wrap around, because it is used to address the current frame in flight to be drawn.
After reviewing the example implementation I see that this is just counted up, indicating these are the prior frames safe to use. Makes sense now that I see it ..

Glad to have helped!