Fix Vulkan Instance initialized twice in ProjectDialog#97006
Conversation
73db84b to
fba7f18
Compare
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ?
fba7f18 to
cc76967
Compare
|
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 |
|
That's fair. |
Not exactly. 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: This is what |
cc76967 to
bfd4c98
Compare
|
@dhoverml Should be good now |
bfd4c98 to
b8107a6
Compare
|
Thanks @Gaktan . |
b8107a6 to
a45dd84
Compare
|
@clayjohn I'll do the simple fix for now, and do the refactor in an other PR |
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 |
Sounds good! |
|
Thanks! |
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