I have been working on a complex shader, and all of a sudden it began to crash my editor with the error below.
“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)”
It completely freezes the editor, and I can’t re-open the project until I do something to beak the scenes relying on the shader (ie. change the shader filename).
The shader shows no errors in the shader editor, but as soon as attached to a material Godot crashes again. I am guessing this is perhaps when a shader is compiled, and this is when the crash happens?
There is a lot going on in the shader, and frankly it’s a complete mess so I’d rather not share until I can find a minimal case that causes the crash, just wondering if anyone can point me i the right direction! Just before the crash started I had been in the process of switching the shader to data read from INSTANCE_CUSTOM, but removing this code didn’t stop it from crashing.
Apologies for this poorly described crash. I will try to reproduce a minimal case, but if anyone has any pointers where to look that would be greatly appreciated!
The shader is several hundred lines long and a bit all over the place. I’m trying to prune it back to minimum case that causes the crash but haven’t managed it yet. Sorry this isn’t very helpful, I was hoping the error message might give somebody an idea where I’m best looking.
I found the issue - Too many varyings!
Having over (roughly, I haven’t found a consistent limit) 32 components (ie. floats, such that a vec2 is two components etc) set as varying will cause the editor to crash without a meaningful error, and repeatedly crash whenever opening a project dependent on said shader.
Thankfuly (for me) most of those varyings were redundent/bloat as I was just testing out distributing the work between vertex and fragment shaders.
While I accept I was probably mistreating Vulkan and asking for this, it would be nice if the user could be given a heads up! Should I add a github issue for this issue?
[ edit - just to add that the specific change I made to cause the crash seems to have been changing varyings to ‘flat’. I’m assuming that this somehow duplicates the workload somehow? ]
Thanks, that’s definitely my problem! It seems like quite a complex issue (including factors such as whether the variable is uppercase or not!) so I might wait till I can do a bit more systematic research on where the limit is before I add bad data to the github account. I’m glad to see there is an open issue though.