Many lights on screen renders editor and runtime unresponsive until restart [4.3 dev]

[MarioBossReal]

Tested versions

• Reproducible in 4.3 dev snapshots (tested with 4.3 dev 3 and 4.3 dev 4 mono versions)

System information

Godot v4.3.dev4.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1080 (NVIDIA; 31.0.15.5176) - Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz (8 Threads)

Issue description

Having many lights on screen causes the editor to freeze up and effectively become permanently stuck, requiring it to be closed. I'm not sure of the exact cause for this, as I tried making a different setup with many more omni lights (only omni lights) but it did not cause the crash. The MRP has a single directional light, with a mix of many omni and spot light nodes with a variety of different properties and transforms.

Edit: The (presumably) exact same issue occurs at runtime too, tested with a simple WASD mouselook camera.

Running the editor with the console shows this error being spammed continuously upon production of the bug:

ERROR: Condition "err != VK_SUCCESS" is true. Returning: FAILED at: command_queue_execute_and_present (drivers/vulkan/rendering_device_driver_vulkan.cpp:2214) ERROR: Unable to acquire framebuffer. at: (servers/rendering/rendering_device.cpp:3199)

This happens in the forward+ and mobile renders, but not the compatibility renderer.
This issue does not happen in latest stable build (4.2.1)

Steps to reproduce

Steps to reproduce is outlined in the MRP provided.

Minimal reproduction project (MRP)

https://github.com/MarioBossReal/Light-Crash-Issue-MRP

[MarioBossReal]

The same issue occuring at runtime, using a simple mouselook camera.

[DarioSamo]

I can confirm the project fails with a Vulkan validation error.

drivers\vulkan\rendering_context_driver_vulkan.cpp:304 - VALIDATION - Message Id Number: 466895974 | Message Id Name: VUID-VkRenderPassBeginInfo-pNext-02853
	Validation Error: [ VUID-VkRenderPassBeginInfo-pNext-02853 ] Object 0: handle = 0xfac9830000004d2c, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0xfc84a20000004d2d, type = VK_OBJECT_TYPE_FRAMEBUFFER; | MessageID = 0x1bd44466 | vkCmdBeginRenderPass(): pRenderPassBegin->renderArea offset.y (4096) + extent.height (256) is greater than framebuffer height (4096). 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.275.0/windows/1.3-extensions/vkspec.html#VUID-VkRenderPassBeginInfo-pNext-02853)
	Objects - 2
		Object[0] - VK_OBJECT_TYPE_RENDER_PASS, Handle -375625057885467348
		Object[1] - VK_OBJECT_TYPE_FRAMEBUFFER, Handle -250897558342185683

It'll likely require more investigation to find out the real cause, but as I suspected the error you're seeing is just the driver failing to work once a series of errors happens before.

[DarioSamo]

The crash seems to mostly originate from the fact that it tries to render the shadowmaps for the omni lights outside of the size of the atlas texture. I'm not very familiar with how Forward+ handles this yet, but I can confirm at least it's not a regression from how RenderingDevice handles this: draw lists with regions out of bounds are being issued and the renderer is considering it an error.

It does seem like the issue correlates at least to a lot of omni lights with shadowmaps being rendered (not exactly recommended but a use case nonetheless). Maybe @clayjohn has a better idea of why the render list for the shadow pass could be assigning a region outside of the bounds of the atlas texture?

Having many lights on screen causes the editor to freeze up and effectively become permanently stuck, requiring it to be closed. I'm not sure of the exact cause for this, as I tried making a different setup with many more omni lights (only omni lights) but it did not cause the crash.

Perhaps the differentiating factor was whether those lights were enabled for shadow casting or not?

[MarioBossReal]

Perhaps the differentiating factor was whether those lights were enabled for shadow casting or not?

This may be right, I think I forgot to enable shadow casting when I tested.

[clayjohn]

Another interesting data point is that this doesn't crash on my intel iGPU! I'll look into it deeper with a dedicated GPU

Not reproducible in dev1, reproducible in dev2. Therefore it's most likely an ARG regression

[speakk]

I hit this bug on 4.3dev6, on linux. Regular build, not the mono one.
Laptop with an Nvidia card: GA104GLM [RTX A3000 Mobile]

My system is an up to date arch linux setup.

[clayjohn]

There are two parts to this bug:

1. For some reason OmniLight3D shadows are trying to draw outside of the atlas. That should be fixed.
2. For some reason our RenderingDevice validation isn't validating properly when something tries to draw outside of a framebuffer.

I have tracked the validation problem down to this line (try and spot the bug):

if (!(regioni.position.x >= viewport.position.x) && (regioni.position.y >= viewport.position.y) &&
		((regioni.position.x + regioni.size.x) <= (viewport.position.x + viewport.size.x)) &&
		((regioni.position.y + regioni.size.y) <= (viewport.position.y + viewport.size.y))) {
	ERR_FAIL_V_MSG(INVALID_ID, "When supplying a custom region, it must be contained within the framebuffer rectangle");
}

I will fix this and the shadow atlas issue in the same PR, hopefully soon

The shadow issue is specifically coming from SpotLights when the shadow atlas is full