-
Notifications
You must be signed in to change notification settings - Fork 244
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
Comments
The first patch (
With some work to modify it to toggle when appropriate. This is mostly a question of direction from Valve perspective. |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: