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

Alan Wake Godrays broken #316

Closed
LeJimster opened this issue Sep 5, 2018 · 8 comments
Closed

Alan Wake Godrays broken #316

LeJimster opened this issue Sep 5, 2018 · 8 comments

Comments

@LeJimster
Copy link

I wasn't sure where to leave this bug, as it happens on both vanilla wine and gallium-nine.

The godrays feature is broken in this game, left is windows, right is wine:
alanwakegodray1
alanwakegodray2

Apitrace
My system info

@axeldavy
Copy link

axeldavy commented Sep 6, 2018

Are you sure gallium-nine is enabled ? Here while wine shows the issue, it works ok on nine.

@LeJimster
Copy link
Author

I just double checked it in nine and it's broken for me. For me it looks the same in nine and vanilla wine.

@axeldavy
Copy link

axeldavy commented Sep 6, 2018 via email

@LeJimster
Copy link
Author

The trace I did was from windows, I can try attempt a trace on linux with wine/nine.

I'm using a recent mesa-git
Mesa 18.3.0-devel (git-2c1f249f2b)

@axeldavy
Copy link

axeldavy commented Sep 6, 2018 via email

@LeJimster
Copy link
Author

I tried replaying the trace with nine and it runs through the scene and as expected godrays is broken. I tried the same with wine, but all I get is a black screen after the trace gets into the menus.

I have also created another trace in wine with nine enabled of the same scene if that is any help, let me know I will upload it.

@axeldavy
Copy link

axeldavy commented Sep 6, 2018

I bisected our repo and found the commit that fixes the issue is:
c172f79

The commit wasn't merged into mainline mesa because it hits slightly performance, while we hadn't found any game requiring it. I guess now we have one.

@LeJimster
Copy link
Author

Shame it hits performance slightly, but if it's a small enough impact it might be worth upstreaming. There is an Alan Wake sequel, that likely suffers the same issue (I don't have it to test).

I can try building Ixit master if you need any further testing to confirm. Although I'm a little rusty when it comes to building/installing mesa manually.

axeldavy added a commit that referenced this issue Sep 15, 2018
Tests done on several devices of all 3 vendors and
of different generations showed that there are several
ways of handling infs and NaN for d3d9.

Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours vary
with shader versions).
Doing this in nine avoids 0*inf issues for drivers
that can't generate 0*inf=0 (which is controled by
TGSI's MUL_ZERO_WINS).

For now clamp for all drivers. An ulterior optimization
would be to avoid clamping for drivers with MUL_ZERO_WINS
for the specific shader versions where NV or AMD don't
clamp.

LOG and RSQ being already clamped, this patch only
clamps RCP.

Fixes: #316

Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
axeldavy added a commit that referenced this issue Sep 23, 2018
Tests done on several devices of all 3 vendors and
of different generations showed that there are several
ways of handling infs and NaN for d3d9.

Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours vary
with shader versions).
Doing this in nine avoids 0*inf issues for drivers
that can't generate 0*inf=0 (which is controled by
TGSI's MUL_ZERO_WINS).

For now clamp for all drivers. An ulterior optimization
would be to avoid clamping for drivers with MUL_ZERO_WINS
for the specific shader versions where NV or AMD don't
clamp.

LOG and RSQ being already clamped, this patch only
clamps RCP.

Fixes: #316

Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
jasuarez pushed a commit to Igalia/release-mesa that referenced this issue Oct 2, 2018
Tests done on several devices of all 3 vendors and
of different generations showed that there are several
ways of handling infs and NaN for d3d9.

Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours vary
with shader versions).
Doing this in nine avoids 0*inf issues for drivers
that can't generate 0*inf=0 (which is controled by
TGSI's MUL_ZERO_WINS).

For now clamp for all drivers. An ulterior optimization
would be to avoid clamping for drivers with MUL_ZERO_WINS
for the specific shader versions where NV or AMD don't
clamp.

LOG and RSQ being already clamped, this patch only
clamps RCP.

Fixes: iXit/Mesa-3D#316

Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 7ee5e5e)
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

2 participants