Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dxvk] Hold a reference to the DxvkAdapter's DxvkInstance #1240

Closed
wants to merge 1 commit into from

Conversation

aeikum
Copy link
Contributor

@aeikum aeikum commented Nov 7, 2019

This fixes a crash when playing Beat Saber with Wine's DXGI.

This fixes a crash when playing Beat Saber with Wine's DXGI.
@aeikum
Copy link
Contributor Author

aeikum commented Nov 7, 2019

To elaborate a bit more.

  • When using Wine's DXGI, D3D11CoreCreateDevice creates a DxvkInstance and holds a ref to it.
  • DxvkInstance::findAdapterByLuid returns a DxvkAdapter which holds a raw pointer to that DxvkInstance.
  • The DxvkAdapter is passed to D3D11DXGIDevice and persists.
  • At the end of the function, the original ref is dropped, so the DxvkInstance is destroyed.
  • The DxvkAdapter now holds an invalid pointer.

@doitsujin
Copy link
Owner

I see the problem and wonder why we haven't run into this earlier since it's a really dumb bug; unfortunately this solution creates a circular reference since DxvkAdapter is owned by DxvkInstance, so neither object will ever be destroyed.

I'll work out why there's an adapter->instance relation in the first place, it probably shouldn't exist.

@misyltoad
Copy link
Collaborator

Could solve this the d3d9 surface/texture way and make that child object inherit the refcount of its parent

@doitsujin
Copy link
Owner

doitsujin commented Nov 7, 2019

Doesn't really work that way since this isn't COM ref counting that's going wrong but the internal DXVK stuff.

Now that I think about it, I think DxvkInstance didn't own its adapters originally but created them on demand, not entirely sure why that has changed.

@aeikum
Copy link
Contributor Author

aeikum commented Nov 7, 2019

I see the problem and wonder why we haven't run into this earlier since it's a really dumb bug;

FWIW the crash I saw happens when Proton's vrclient.ivrcompositor_submit_dxvk calls IDXGIVkInteropDevice::GetVulkanHandles. It crashed in that function once, but much more often it returns a bogus VkInstance, which we then crash on later. We didn't see any other crashes when using Wine's DXGI with DXVK in all of our release testing this cycle.

@doitsujin doitsujin closed this in a0dba6b Nov 7, 2019
@doitsujin
Copy link
Owner

Beat Saber works with the above commit on my end; a proper solution will require significantly more work.

@aeikum
Copy link
Contributor Author

aeikum commented Nov 7, 2019

Thanks. I picked that commit on top of 1.4.4 and confirmed it's working here. Are you OK with releasing like that in the next Proton?

@doitsujin
Copy link
Owner

Yes; I don't know how long it'll take to rework the whole adapter thing.

doitsujin added a commit that referenced this pull request Dec 9, 2019
Hack to keep the instance alive which owns the adapters. Should
fix #1240 for now, but we should fix this properly later on.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants