[d3d9] Optimize StretchRect stretching resolves #5023
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
doitsujin
requested changes
Jun 17, 2025
Owner
doitsujin
left a comment
doitsujin
left a comment
There was a problem hiding this comment.
comment, haven't looked at the d3d9 side yet.
|
Thank you for your work. I am happy to have helped. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Improves #4895 when using MSAA in Source.
HL2 frequently resolves a 2048x1536 screenshot into a 1024x1024 image which is then used for refraction when rendering glass.
The game does these resolves (using StretchRect) quite frequently and unfortunately a lot of them are redundant.
Current DXVK master would first resolve the original texture to a temporary image and then blit that to the actual target texture.
While that's actually what the D3D9 docs suggest happens behind the scenes, it's a bit slow:
This PR changes it so the blit and resolve are done in one step rather than in two. It improves performance in the HL2 main menu at 4k Max settings with 8x MSAA from 240 fps to 265 fps.
Besides that, the PR also forbids creating a lockable texture with more than 1 sample. This matches what I've seen in tests done on Windows.
In the future I'd like to get rid of the resolve step in
LockImagebut for now we still need it because of the GDI-based presentation fallback.