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

[DONOTMERGE] [native] Load SDL/glfw via dlopen instead of linking at build time #3736

Closed
wants to merge 4 commits into from
Closed

Conversation

flibitijibibo
Copy link
Contributor

@flibitijibibo flibitijibibo commented Dec 6, 2023

This modifies DXVK's SDL2 linkage to be dlopened rather than referenced at build time. This is an important part of #3451 which needs all WSI implementations to coexist while also not requiring hard dependencies on every possible WSI library in existence.

Notably absent from this draft is any sort of boilerplate to simplify loading SDL symbols: this does every declaration, every load, and every cast manually. Nobody in their right mind would want to maintain this, but I didn't want to start getting clever until there was a clear path forward for what DXVK's preferred style is here. Personally I like doing inline files that macro everything out (example: part 1, part 2), but that usually assumes all the API access comes from one place, which is not the case here.

Major TODO items aside from the horrendous style:

  • Does Meson define a DLL name somewhere? For testing I just hardcoded libSDL2-2.0.so.0 but it'd be great to replace that with something like SDL2_LIBRARY_NAME.
  • Because the WSI namespace is currently all static, the DLL never gets unloaded when we're all finished... I'm not sure how this might be addressed, even in the case where the WSI is selected at runtime.
  • I'm not familiar with the dependency tree for DXVK internals, so if there's a way to just have one WsiLibrary instead of the weird one-off case I have in dxvk_sdl2_exts.cpp that would probably clean things up a lot!

@flibitijibibo flibitijibibo marked this pull request as draft December 6, 2023 20:41
@flibitijibibo
Copy link
Contributor Author

Updated to depend on #3737, with that fix I was able to do the quick and simple boilerplate to simplify loading the SDL functions. Points 1 and 2 in the OP still remain!

@flibitijibibo flibitijibibo changed the title [DONOTMERGE] native: Load SDL via dlopen instead of linking to libSDL2 [DONOTMERGE] [native] Load SDL via dlopen instead of linking to libSDL2 Dec 7, 2023
@flibitijibibo flibitijibibo changed the title [DONOTMERGE] [native] Load SDL via dlopen instead of linking to libSDL2 [DONOTMERGE] [native] Load SDL/glfw via dlopen instead of linking at build time Dec 7, 2023
@flibitijibibo
Copy link
Contributor Author

Added GLFW dynamic loading, it builds but it'd be great to have a glfw user check this out.

@flibitijibibo
Copy link
Contributor Author

Threw together a way to unload the DLLs, though I'm not 100% sure if this covers all WSI cases... looking around this should be safe as long as wsi is always called by objects created by Direct3DCreate9 and CreateDXGIFactory. If this idea seems okay I'll fold this back into the patch series properly!

@flibitijibibo
Copy link
Contributor Author

#3738 rewrites this series!

@flibitijibibo flibitijibibo deleted the sdl2-dlopen branch February 10, 2024 18:35
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.

1 participant