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

Consider adapting wine-d3d9 patches to make use of Gallium Nine #9

Open
boombatower opened this issue Aug 25, 2018 · 1 comment
Open

Comments

@boombatower
Copy link

Parent issue (ValveSoftware/Proton#66), but likely needs to be a discussion specific to wine maintainers (perhaps the same group). See ValveSoftware/Proton#66 (comment) for a summary of the suggestion, but given the state of d3d9 over vulkan and the performance gains for those able to make use of Gallium Nine it seems worth consideration. Obviously, may have other priorities and this would require maintaining the changes to some degree which is why the topic should be discussed before much effort is given.

@boombatower
Copy link
Author

boombatower commented Aug 25, 2018

The first patch (d3d9-helper.patch) applies cleanly, but (wine-d3d9.patch) has relatively trivial issues applying, but given maintaining a fork of wine it likely does not make sense to try patching it during proton build regardless. The helper patch makes the primary changes of consideration since they are to the primary wine files while the second patch is all d3d9 ddl specific additions. For rough idea the changes to consider:

 dlls/ntdll/loader.c          | 205 ++++++++++++++++++++----
 dlls/ntdll/loadorder.c       | 298 ++++++++++++++++++++++++++---------
 dlls/ntdll/ntdll_misc.h      |   1 +
 programs/winecfg/Makefile.in |   1 +
 programs/winecfg/main.c      |  12 +-
 programs/winecfg/resource.h  |   5 +
 programs/winecfg/staging.c   |  93 +++++++++++
 programs/winecfg/winecfg.h   |   1 +
 programs/winecfg/winecfg.rc  |  10 ++
 9 files changed, 522 insertions(+), 104 deletions(-)

With some work to modify it to toggle when appropriate. This is mostly a question of direction from Valve perspective.

kakra referenced this issue in kakra/wine-proton Dec 12, 2018
By manually notifying the server every time we enter and exit a message wait.

The hung queue logic keeps breaking. In the case of bug #9 it was breaking
because we were waiting for more than 5 seconds on our queue and then someone
sent us a message with SMTO_ABORTIFHUNG. Just stop fighting against the
server and try to coöperate with it instead. It takes two extra server calls,
but ideally the GUI thread isn't going to be in the same sort of performance-
critical code that this patchset was written for.
kakra referenced this issue in kakra/wine-proton Dec 14, 2018
By manually notifying the server every time we enter and exit a message wait.

The hung queue logic keeps breaking. In the case of bug #9 it was breaking
because we were waiting for more than 5 seconds on our queue and then someone
sent us a message with SMTO_ABORTIFHUNG. Just stop fighting against the
server and try to coöperate with it instead. It takes two extra server calls,
but ideally the GUI thread isn't going to be in the same sort of performance-
critical code that this patchset was written for.
kakra referenced this issue in kakra/wine-proton Dec 15, 2018
By manually notifying the server every time we enter and exit a message wait.

The hung queue logic keeps breaking. In the case of bug #9 it was breaking
because we were waiting for more than 5 seconds on our queue and then someone
sent us a message with SMTO_ABORTIFHUNG. Just stop fighting against the
server and try to coöperate with it instead. It takes two extra server calls,
but ideally the GUI thread isn't going to be in the same sort of performance-
critical code that this patchset was written for.
aeikum pushed a commit that referenced this issue Dec 21, 2018
By manually notifying the server every time we enter and exit a message wait.

The hung queue logic keeps breaking. In the case of bug #9 it was breaking
because we were waiting for more than 5 seconds on our queue and then someone
sent us a message with SMTO_ABORTIFHUNG. Just stop fighting against the
server and try to coöperate with it instead. It takes two extra server calls,
but ideally the GUI thread isn't going to be in the same sort of performance-
critical code that this patchset was written for.
kakra referenced this issue in kakra/wine-proton Dec 22, 2018
By manually notifying the server every time we enter and exit a message wait.

The hung queue logic keeps breaking. In the case of bug #9 it was breaking
because we were waiting for more than 5 seconds on our queue and then someone
sent us a message with SMTO_ABORTIFHUNG. Just stop fighting against the
server and try to coöperate with it instead. It takes two extra server calls,
but ideally the GUI thread isn't going to be in the same sort of performance-
critical code that this patchset was written for.
kakra referenced this issue in kakra/wine-proton Jan 2, 2019
By manually notifying the server every time we enter and exit a message wait.

The hung queue logic keeps breaking. In the case of bug #9 it was breaking
because we were waiting for more than 5 seconds on our queue and then someone
sent us a message with SMTO_ABORTIFHUNG. Just stop fighting against the
server and try to coöperate with it instead. It takes two extra server calls,
but ideally the GUI thread isn't going to be in the same sort of performance-
critical code that this patchset was written for.
kakra referenced this issue in kakra/wine-proton Jan 5, 2019
By manually notifying the server every time we enter and exit a message wait.

The hung queue logic keeps breaking. In the case of bug #9 it was breaking
because we were waiting for more than 5 seconds on our queue and then someone
sent us a message with SMTO_ABORTIFHUNG. Just stop fighting against the
server and try to coöperate with it instead. It takes two extra server calls,
but ideally the GUI thread isn't going to be in the same sort of performance-
critical code that this patchset was written for.
AlexeyProkhin pushed a commit to AlexeyProkhin/wine that referenced this issue Aug 27, 2019
By manually notifying the server every time we enter and exit a message wait.

The hung queue logic keeps breaking. In the case of bug ValveSoftware#9 it was breaking
because we were waiting for more than 5 seconds on our queue and then someone
sent us a message with SMTO_ABORTIFHUNG. Just stop fighting against the
server and try to coöperate with it instead. It takes two extra server calls,
but ideally the GUI thread isn't going to be in the same sort of performance-
critical code that this patchset was written for.
rbernon pushed a commit to rbernon/wine-proton that referenced this issue Oct 22, 2019
By manually notifying the server every time we enter and exit a message wait.

The hung queue logic keeps breaking. In the case of bug ValveSoftware#9 it was breaking
because we were waiting for more than 5 seconds on our queue and then someone
sent us a message with SMTO_ABORTIFHUNG. Just stop fighting against the
server and try to coöperate with it instead. It takes two extra server calls,
but ideally the GUI thread isn't going to be in the same sort of performance-
critical code that this patchset was written for.
rbernon pushed a commit to rbernon/wine-proton that referenced this issue Dec 17, 2019
By manually notifying the server every time we enter and exit a message wait.

The hung queue logic keeps breaking. In the case of bug ValveSoftware#9 it was breaking
because we were waiting for more than 5 seconds on our queue and then someone
sent us a message with SMTO_ABORTIFHUNG. Just stop fighting against the
server and try to coöperate with it instead. It takes two extra server calls,
but ideally the GUI thread isn't going to be in the same sort of performance-
critical code that this patchset was written for.
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

No branches or pull requests

1 participant