Skip to content

Fix Vulkan Instance initialized twice in ProjectDialog#97006

Merged
akien-mga merged 1 commit into
godotengine:masterfrom
Gaktan:project_dialog_vulkan_crash
Sep 18, 2024
Merged

Fix Vulkan Instance initialized twice in ProjectDialog#97006
akien-mga merged 1 commit into
godotengine:masterfrom
Gaktan:project_dialog_vulkan_crash

Conversation

@Gaktan

@Gaktan Gaktan commented Sep 14, 2024

Copy link
Copy Markdown
Contributor

Fixes #96722

I refactored a bit to be able to share as much code as possible with other systems that create a local device,

I first wanted to replace the create_local_rendering_device(), but since it's apparently used in GDScript, I did not know if it was possible to pass pointer reference arguments.

Note: this does not fix the leak that still exists in create_local_rendering_device(): #71003

@Gaktan Gaktan requested review from a team as code owners September 14, 2024 16:27
@Gaktan Gaktan force-pushed the project_dialog_vulkan_crash branch 3 times, most recently from 73db84b to fba7f18 Compare September 14, 2024 17:13
Comment thread servers/display_server.cpp Outdated
Comment thread servers/rendering_server.cpp Outdated
Comment on lines 34 to 39

@akien-mga akien-mga Sep 14, 2024

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a pre-existing issue, so maybe not blocking, but these includes break code encapsulation. The generic / abstract servers code shouldn't need to access driver code, and instead have virtual methods that drivers can implement.

Also, nitpicking, but if those includes are needed for now, they should come after the block of core/servers includes, by convention.

@Gaktan Gaktan Sep 15, 2024

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to think of the best way to do this. Does it make sense to have this in the DisplayServer class?
Since the RenderServer doesn't have children class or API specific code.
I don't know the subtlety between the two classes. Does it even make sense for the RenderServer to have RenderingServer::create_local_rendering_device() to begin with ?

@akien-mga akien-mga added this to the 4.4 milestone Sep 14, 2024
@akien-mga akien-mga requested review from a team and clayjohn September 14, 2024 17:19
@Gaktan Gaktan force-pushed the project_dialog_vulkan_crash branch from fba7f18 to cc76967 Compare September 15, 2024 20:26
@clayjohn

Copy link
Copy Markdown
Member

I think this is too much complexity just to solve #96722.

The core issue in #96722 is that creating a RenderingDevice (not a local rendering device) crashes on certain hardware when a RenderingDevice has already been created. The solution is to add a check at the top of can_create_rendering_device() that checks if we are already using the Compatibility renderer. If we are, then it continues and attempts to create a RenderingDevice, if not, it does an early out and returns true.

@Gaktan

Gaktan commented Sep 16, 2024

Copy link
Copy Markdown
Contributor Author

That's fair.
Although what can_create_rendering_device() is doing is essentially the same steps as creating a local rendering device (literally the same code). I just took the opportunity to cleanup a bit and unify code

@clayjohn

Copy link
Copy Markdown
Member

That's fair. Although what can_create_rendering_device() is doing is essentially the same steps as creating a local rendering device (literally the same code). I just took the opportunity to cleanup a bit and unify code

Not exactly. can_create_rendering_device() doesn't create a local rendering device so the flow is very different. The new function also makes the user responsible for cleaning up the RenderingDevice and Context which is a big problem for a function like this.

Also, as a bonus, while looking at the code again, I realized that it can done very simply just by checking if the RenderingDevice singleton exists:

RenderingDevice *device = RenderingDevice::get_singleton();
if (device) {
	return true;
}

This is what create_local_rendering_device() does, which is why attempting to create one works for this PR.

@dhoverml

Copy link
Copy Markdown

@Gaktan can you please rebase?
I wanted to confirm that this fixes #96938, but I am getting a non-trivial merge conflict when I cherry pick.

@Gaktan Gaktan force-pushed the project_dialog_vulkan_crash branch from cc76967 to bfd4c98 Compare September 17, 2024 18:07
@Gaktan

Gaktan commented Sep 17, 2024

Copy link
Copy Markdown
Contributor Author

@dhoverml Should be good now

@Gaktan Gaktan force-pushed the project_dialog_vulkan_crash branch from bfd4c98 to b8107a6 Compare September 17, 2024 18:15
@dhoverml

Copy link
Copy Markdown

Thanks @Gaktan .
It looks like the crash is fixed with this PR, however, creating new windows is very slow. It takes about 1 second to create a new window (click on + Create in the Project Manager, or open any menu in the editor when Single Window Mode is false).
I don't know if that is unrelated to this PR though.

@Gaktan Gaktan force-pushed the project_dialog_vulkan_crash branch from b8107a6 to a45dd84 Compare September 17, 2024 18:36
@Gaktan

Gaktan commented Sep 17, 2024

Copy link
Copy Markdown
Contributor Author

@clayjohn I'll do the simple fix for now, and do the refactor in an other PR

@Gaktan Gaktan requested a review from akien-mga September 17, 2024 18:37

@clayjohn clayjohn left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thank you!

@clayjohn

Copy link
Copy Markdown
Member

Thanks @Gaktan . It looks like the crash is fixed with this PR, however, creating new windows is very slow. It takes about 1 second to create a new window (click on + Create in the Project Manager, or open any menu in the editor when Single Window Mode is false). I don't know if that is unrelated to this PR though.

That's unrelated to this PR.

If you are on Windows you can improve the speed of opening new windows a lot by switching to D3D12 instead of Vulkan

@clayjohn

Copy link
Copy Markdown
Member

@clayjohn I'll do the simple fix for now, and do the refactor in an other PR

Sounds good!

@akien-mga akien-mga merged commit b103381 into godotengine:master Sep 18, 2024
@akien-mga

Copy link
Copy Markdown
Member

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Crash in Project Dialog on Windows - Vulkan

4 participants