vsgoffscreenshot viewport problems and freezeup

[dov]

I tried vsgoffscreenshot the latest VSG and vsgExamples and it behaves better than before, however the offscreen image still doesn't allways follow the display image as expected.

The following images show a window of vsgoffscreenshot on the left and an image viewer on the right, which also shows the current image size. Between each of these images I pressed "e" followed by "s".

The command I used was vsgoffscreenshot -d -f benchy.png 3DBenchy.stl.

1. Initial offscreenshot works well:

2. After resizing the vsgoffscreenwindow, the offscreenshot has a different view port, and the model has a very low resolution. It is like the change of resolution was applied twice:

3. After another "small" resizing of the vsgoffscreenwindow, the offscreenimage becomes all black. At this stage there were lots of vulkan validation errors. See below.

4. However, this black image does not always occur. Repeating the same steps yielded a correct view port after doing a "small" resizing of the vsgoffscreenwindow:

The black screenshot is accompanied by the following vulkan warnings:

info: offscreen render resized to: 606x431
VUID-VkRenderPassBeginInfo-pNext-02852(ERROR / SPEC): msgNum: -617851033 - Validation Error: [ VUID-VkRenderPassBeginInfo-pNext-02852 ] Object 0: handle = 0xd68cbb0000000091, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0x8168780000000092, type = VK_OBJECT_TYPE_FRAMEBUFFER; | MessageID = 0xdb2c5767 | vkCmdBeginRenderPass(): pRenderPassBegin->renderArea offset.x (0) + extent.width (665) is greater than framebuffer width (606). The Vulkan spec states: If the pNext chain does not contain VkDeviceGroupRenderPassBeginInfo or its deviceRenderAreaCount member is equal to 0, renderArea.offset.x + renderArea.extent.width must be less than or equal to VkFramebufferCreateInfo::width the framebuffer was created with (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-VkRenderPassBeginInfo-pNext-02852)
    Objects: 2
        [0] 0xd68cbb0000000091, type: 18, name: NULL
        [1] 0x8168780000000092, type: 24, name: NULL
VUID-VkRenderPassBeginInfo-pNext-02853(ERROR / SPEC): msgNum: 466895974 - Validation Error: [ VUID-VkRenderPassBeginInfo-pNext-02853 ] Object 0: handle = 0xd68cbb0000000091, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0x8168780000000092, type = VK_OBJECT_TYPE_FRAMEBUFFER; | MessageID = 0x1bd44466 | vkCmdBeginRenderPass(): pRenderPassBegin->renderArea offset.y (0) + extent.height (468) is greater than framebuffer height (431). The Vulkan spec states: If the pNext chain does not contain VkDeviceGroupRenderPassBeginInfo or its deviceRenderAreaCount member is equal to 0, renderArea.offset.y + renderArea.extent.height must be less than or equal to VkFramebufferCreateInfo::height the framebuffer was created with (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-VkRenderPassBeginInfo-pNext-02853)
    Objects: 2
        [0] 0xd68cbb0000000091, type: 18, name: NULL
        [1] 0x8168780000000092, type: 24, name: NULL
info: writing image to file: benchy.png
info: image saved.
VUID-vkQueuePresentKHR-pWaitSemaphores-03268(ERROR / SPEC): msgNum: 622825338 - Validation Error: [ VUID-vkQueuePresentKHR-pWaitSemaphores-03268 ] Object 0: handle = 0xcad092000000000d, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x220247c0, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0x251f8f7a | vkQueuePresentKHR(): pPresentInfo->pWaitSemaphores[0] queue (VkQueue 0x220247c0[]) is waiting on semaphore (VkSemaphore 0xcad092000000000d[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of pPresentInfo must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueuePresentKHR-pWaitSemaphores-03268)
    Objects: 2
        [0] 0xcad092000000000d, type: 5, name: NULL
        [1] 0x220247c0, type: 4, name: NULL
UNASSIGNED-VkPresentInfoKHR-pImageIndices-MissingAcquireWait(ERROR / SPEC): msgNum: 460037874 - Validation Error: [ UNASSIGNED-VkPresentInfoKHR-pImageIndices-MissingAcquireWait ] Object 0: handle = 0xa182620000000079, type = VK_OBJECT_TYPE_IMAGE; Object 1: handle = 0xf3eaa0000000081, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x1b6b9ef2 | vkQueuePresentKHR(): pPresentInfo->pImageIndices[0] was acquired with a semaphore VkSemaphore 0xf3eaa0000000081[] that has not since been waited on
    Objects: 2
        [0] 0xa182620000000079, type: 10, name: NULL
        [1] 0xf3eaa0000000081, type: 5, name: NULL
VUID-vkQueuePresentKHR-pWaitSemaphores-03268(ERROR / SPEC): msgNum: 622825338 - Validation Error: [ VUID-vkQueuePresentKHR-pWaitSemaphores-03268 ] Object 0: handle = 0xcad092000000000d, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x220247c0, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0x251f8f7a | vkQueuePresentKHR(): pPresentInfo->pWaitSemaphores[0] queue (VkQueue 0x220247c0[]) is waiting on semaphore (VkSemaphore 0xcad092000000000d[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of pPresentInfo must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.283.0/linux/1.3-extensions/vkspec.html#VUID-vkQueuePresentKHR-pWaitSemaphores-03268)
    Objects: 2
        [0] 0xcad092000000000d, type: 5, name: NULL
        [1] 0x220247c0, type: 4, name: NULL

My system details:

• Vulkan 1.3.283.0
• GPU: NVidia GTX 1070
• NVidia Driver Version: 565.77
• Linux version: Linux grozy 6.12.11-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jan 24 04:59:58 UTC 2025 x86_64 GNU/Linux

[SherSpidey]

Hi, I ran into the same issue recently and want to share what worked for me.

I noticed the renderArea.offset didn't have a default value. On Windows this resulted in an all-black output. Explicitly setting it to {0, 0} or initializing renderArea with {} fixes this.

auto offscreenRenderGraph = vsg::RenderGraph::create();
offscreenRenderGraph->framebuffer = createOffscreenFramebuffer(device, transferImageView, samples);
offscreenRenderGraph->renderArea = {};
offscreenRenderGraph->renderArea.extent = offscreenRenderGraph->framebuffer->extent2D();

And after resizing the window, things got weird — shrinking kind of works, but enlarging just breaks offscreen rendering completely. Digging through the vsg codebase, I noticed RenderGraph::record() has a built-in resize mechanism tied to its previous_extent. Manually updating it before record helped prevent unintended double-scaling.

auto prevCaptureCommands = captureCommands;

offscreenExtent = displayExtent;
offscreenRenderGraph->renderArea = displayCamera->getRenderArea();
offscreenRenderGraph->previous_extent = displayExtent; // avoid double-scaling