RenderingServer.create_local_rendering_device() crashes with RenderDoc v1.26

[ctkerns]

Godot version

4.0.stable

System information

Windows 10, Vulkan API 1.2.131, Forward+, Intel UHD Graphics 26.20.100.7926

Issue description

Launching Godot from RenderDoc will crash if RenderingServer.create_local_rendering_device() is called.

The program will crash with the error:
USER ERROR: Condition "err" is true. Returning: RID() at: local_device_create (drivers/vulkan/vulkan_context.cpp:2576)

Not sure what Godot devs can do to make this work, but RenderDoc is a critical tool for developing compute shaders, I wouldn't work on them without it working.

Steps to reproduce

Open RenderDoc v1.26
Open the "Launch Application" tab. File -> Launch Application or Ctrl + N.
Under executable path, enter the path for the Godot executable.
Under working directory, enter the path for the Godot project

Minimal reproduction project

RenderDoc.zip

[Calinou]

In general, RenderDoc seems to crash for me whenever I try to run Godot 4.x using it (either using OpenGL or Vulkan). Godot 3.5.2 with GLES3 works though.

The only message I get in stdout is:

free(): invalid pointer

I'm using RenderDoc 1.26 on Linux on a GeForce RTX 4090 (NVIDIA 530.41.03).

[ctkerns]

RenderDoc will otherwise work for me as long as I'm not trying to run that code.

I have also reported the problem to RenderDoc.
Here is the RenderDoc error log: 0rY8.zip

I can't make heads or tails of it with the available time I have now.

[ctkerns]

According to the RenderDoc dev:

It looks like your application is creating multiple devices within a single instance. This is legal but something I do not support within RenderDoc and have no plans to support in future.

I am not familiar with Vulkan but it seems like the only thing Godot could do to fix this incompatibility would require a complete change in architecture, which is unreasonable. I hope I am wrong, but it seems like this is unfixable from Godot's end.

[clayjohn]

The workaround for interested users is to not create a second rendering device and instead just use the main rendering device which you can grab from RenderingServer.get_rendering_device()

[Kimau]

Doesn't this cause a big issue with console porting? Hard to discuss this behaviour in an open forum but I could see this being a real problem for some console APIs?

Or do any ported titles just need to avoid local rendering device entirerly which seems like it might be a port nightmare in some cases?

[clayjohn]

Doesn't this cause a big issue with console porting? Hard to discuss this behaviour in an open forum but I could see this being a real problem for some console APIs?

Or do any ported titles just need to avoid local rendering device entirerly which seems like it might be a port nightmare in some cases?

I'm not sure what you mean. Renderdoc choosing not to support a Vulkan feature is their own prerogative. It has nothing to do with consoles.

The workaround is just to run the shader on the main rendering device while debugging with Renderdoc.

Now, whether or not console APIs support creating the equivalent of multiple devices from a single instance is a different matter altogether. Naturally, its not a discussion we can have here.

[Kimau]

Yeah impossible and I'm no longer at Sony. First time in 17 years no devkit on my desk. I pushed so hard to have at least header level disclosure to make technical like this possible. Le sigh.

In the abstract my point was that the official docs point users to the local render device as the way to do compute shaders among other things and if they code around that model when multiple devices is a poorly supported feature it will cause a bunch of bother when porting.

[clayjohn]

In the abstract my point was that the official docs point users to the local render device as the way to do compute shaders among other things and if they code around that model when multiple devices is a poorly supported feature it will cause a bunch of bother when porting.

Fair enough. The docs should probably be clarified that using a local rendering device is a niche feature for when you want to run an compute workload async. But it should also come with a bunch of caveats as it comes with performance risks and hardware support risks (especially on mobile). The default option should definitely be to just use the main rendering device