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 native support? #53

Open
Mis012 opened this issue Dec 11, 2023 · 7 comments
Open

dxvk native support? #53

Mis012 opened this issue Dec 11, 2023 · 7 comments
Labels
enhancement New feature or request

Comments

@Mis012
Copy link

Mis012 commented Dec 11, 2023

Games like Portal use DXVK Native in their latest Linux versions. DXVK Native was fully upstreamed into main DXVK. Would it be possible to support native builds with dxvk-remix? I'm not sure if DXVK native support exists in your fork, so it may need to be rebased.

@Mis012
Copy link
Author

Mis012 commented Jan 31, 2024

I guess even building on Linux for use with Wine would be a good start, stuff like not having incorrect case in e.g include statements that Windows happily ignores, using / for paths (it works on Windows just fine) or having linux versions of host tools (some of them seem to be closed source, so can't even build them manually), not having a hard dependency on visual studio...

@anon-apple
Copy link
Collaborator

The project is currently developed on Windows with Visual Studio so yeah we haven't really been paying attention to how it compiles on Linux sadly (and indeed broke that), mostly because I think it works on Linux just fine regardless when using Wine/Proton (last I checked at least, but we also don't have good coverage for testing that).

Also like you mention Remix currently uses a somewhat outdated DXVK version as well (1.9.3 if I am not mistaken) so we'd have to update to a more recent DXVK most likely if the native support is there, and that is easier said than done as well (though may be done at some point as we have pulled from DXVK in the past, it is just a lot of work and has the risk of introducing many bugs).

@Mis012
Copy link
Author

Mis012 commented Mar 11, 2024

It would probably be preferable in general to use / for paths and especially fix the rAnDOMcAsE includes as a matter of code style (I believe wine might have some tools to check for such issues as part of winebuild, would be weird if they don't work on windows; I would expect Visual Studio to lint wrong case includes honestly but never used it so I have no idea). I also believe meson automatically converts -option to /option so that might be another thing that doesn't need compile testing to fix. Of course this doesn't fix all the issues, but might as well take the low hanging fruit.

@anon-apple
Copy link
Collaborator

Visual Studio doesn't do linting as far as I know (other than maybe this which only checks for like a handful of things). Fixing those problems would require being able to compile it on Linux probably, but we've never tried to do that I don't think.

@Mis012
Copy link
Author

Mis012 commented Mar 11, 2024

hm, it seems Windows supports enabling case sensitivity for a path (https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity), not sure if they added that for WSL reasons or if it already existed... there is probably no such easy way to catch the other issues though.

@anon-apple
Copy link
Collaborator

I fixed a number of the obvious case sensitivity and Windows path issues here if you're curious: d3a6711
I have been working on seeing if it can be made to build natively in the meantime, no guarantees though as it may be difficult due to some of our library dependencies (and this isn't a high priority or anything since the majority of users don't need to be using a Linux cross compilation like this).

@Mis012
Copy link
Author

Mis012 commented Mar 17, 2024

thanks for looking into it, I guess most users wouldn't be compiling from source at all but it's always nice to have the option

@anon-apple anon-apple added the enhancement New feature or request label Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants