-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Fix D3D Forced Anisotropy #3672
Conversation
Considering that this is a fix to an enhancement and brings it to parity with OpenGL, this should be considered for 5.0. As long as anisotropic filtering off stays the same, I don't see any issue with at least giving this a good, hard look. |
Sounds fine, but please do the same for OGL, also if this change has no effect. |
ff9df8e
to
23c855d
Compare
This should fix Broken Sunrays in ZTP when using anisotropic filter. https://wiki.dolphin-emu.org/images/7/72/TwilightPrincessGC_Sunrays_Broken.jpg |
Did we ask fifoci for its opinion yet? @dolphin-emu-bot rebuild |
FifoCI doesn't run with anisotropic filtering enabled. |
@Mullin I've taken a look at those and I don't think I can do anything about it. The way the game implements them is just not compatible with Anisotropic filtering; you'd need an Action Replay code to modify its implementation. The game sets [The idea of this PR is to bring D3D to parity with OpenGL. If OpenGL w/ Anisotropic filtering was drawing correctly then this fixes it so D3D will also draw it correctly now. If OpenGL was drawing it wrong then nothing has changed either way.] @BhaaLseN The non-anisotropic code paths are unchanged from master, FifoCI results should be identical. |
@EmptyChaos Okay, so sad :( |
// Only use anisotropic filtering if one or both of the filters are set to Linear. | ||
// If both filters are set to Point then using anisotropy is equivalent | ||
// to "forced filtering" which will cause visual glitches. | ||
if (state.max_anisotropy > 1 && (state.min_filter & 4 || state.mag_filter)) |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
6e29742
to
f22981f
Compare
Review status: 0 of 7 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed. Source/Core/VideoBackends/D3D/D3DState.cpp, line 265 [r1] (raw file): Comments from the review on Reviewable.io |
Would this fix the text in Mario Party 4-7 with AF enabled? |
f22981f
to
83d3055
Compare
@straightflushin Possibly? Does it display correctly in OpenGL w/ Anisotropy (on an nVidia GPU, I don't know about AMD/Intel)? I don't have any Mario Partys to test, but I can take a look at a FIFO Log if you want to upload one. |
Sorry, it looks like that bug only happens now with Force Texture Filtering enabled (on both backends). |
// Letting the game set other combinations will have varying arbitrary results; | ||
// possibly being interpreted as equal to bilinear/trilinear, implicitly | ||
// disabling anisotropy, or changing the anisotropic algorithm employed. | ||
min_filter = (tm0.min_filter & 3) == TexMode0::TEXF_NONE ? GL_LINEAR : GL_LINEAR_MIPMAP_LINEAR; |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
83d3055
to
5fd7db1
Compare
@dolphin-emu-bot rebuild |
I don't think I have any further changes to make. This is ready to be reviewed for merging. |
LGTM in terms of what it fixes. |
Can this PR be rebased to latest master? |
5fd7db1
to
cb07e30
Compare
Rebased on master. |
cb07e30
to
f474dac
Compare
Anything left holding this PR up? |
Reviewed 1 of 4 files at r1, 2 of 6 files at r2, 4 of 8 files at r4, 4 of 4 files at r5. Source/Core/VideoBackends/OGL/SamplerCache.cpp, line 63 [r5] (raw file): Comments from the review on Reviewable.io |
The D3D backend was always forcing Anisotropic filtering when that is enabled regardless of how the game chose to configure the texture filtering registers; this causes the same issues as "Force Filtering" without Anisotropy, such as causing game UI elements to no longer line up adjacent correctly. Historically, OpenGL's Anisotropy support has always worked "better" than D3D's due to seeming to not have this problem; unfortunately, OpenGL's Anisotropy specification only gives GL_LINEAR based filtering modes defined behavior, with only the mipmap setting being required to be considered. Some OpenGL implementations were implicitly disabling Anisotropy when the min/mag filters were set to GL_NEAREST, but this behavior is not required by the spec so cannot be relied on.
f474dac
to
0b9a72a
Compare
Review status: 2 of 11 files reviewed at latest revision, 1 unresolved discussion. Source/Core/VideoBackends/OGL/SamplerCache.cpp, line 63 [r5] (raw file): Comments from the review on Reviewable.io |
@EmptyChaos any progress? |
@delroth I've already made the change. I screwed up the Reviewable by not clicking Publish. |
So neobrain and/or MaJoRoesch wasn't correct about this, I reported this issue long time ago : https://bugs.dolphin-emu.org/issues/7724 Thanks EmptyChaos. |
neobrain is correct, this is in some sense a hack to disable anisotropy in On Sat, Mar 26, 2016 at 11:57 PM Robert Krawczyk notifications@github.com
|
@delroth Not really. The screenshot I posted at the top actually also occurs with Anisotropic Filtering set to 1x (off) and Forced Texture Filtering set to On. The problem is specifically caused by forcing texture filtering when it is meant to be disabled, it isn't directly related to anisotropic filtering itself. You can cause similar issues in some commercial PC games by forcing Anisotropic Filtering from the Nvidia/Catalyst control panel. Also, I think "fundamental difference between the APIs" may be overstating things a little.
"Implementations are also permitted to ignore ..." means this has always been broken in OpenGL as well. |
The D3D backend is known to force anisotropic filtering on all textures when enabled which results in glitches that don't occur in the OpenGL backend under the same anisotropy level. I tried to trace the difference between the 2 implementations to find what was causing this and it seems to actually be an implementation-defined interaction between the anisotropy level and the texture min/mag filter setting in OpenGL. The Anisotropy specification says that the min/mag filters have an implementation-defined effect on the anisotropic filter; only the combination of
GL_LINEAR
+GL_LINEAR_MIPMAP_LINEAR
has a clearly defined behavior as being "best effort". I guessed that nVidia's OpenGL drivers were implicitly disabling anisotropy when usingGL_NEAREST
as the filter so I patched D3D with that assumption to see what would happen and got this:(Left is master; right is with this patch applied. Both are 16x Anisotropic in D3D11. The right image matches OpenGL)
I don't know anything about Flipper so this is just a proof of concept.