| Bug ID | 107581 |
|---|---|
| Summary | Graphics Not Rendered Due to Missing 4.5 COMPAT Profile |
| Product | Mesa |
| Version | git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | ben@xnode.org |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 141109=
[details]
Lack of rendered image
Slightly obtuse issue as it's a game inside Wine.
No Man's Sky used to work if you faked a compatibility profile. This no-lon=
ger
works as, since the last game update, it seems they are actually using some=
of
the COMPAT mode features. The result of this is that the game menu renders
fine, but any of the "3D" graphics in the game are either missing=
or just
render completely white.
e.g. the starfield during loading should be various pinkish colours, but
instead you just see a black screen. Once in-game, you should see the game
world, but instead just have a (what seems to be non-refreshing) white scre=
en.
The game seems to be fine on Nvidia cards using their proprietary driver.
Attached is an image of the issue to see specific what I'm referring to and=
a
trace, from launch of the game, to a few minutes in game, to exiting the ga=
me.
Generated with APITrace (I'll attach the trace in the next comment).
Created attachment 141110 [detai=
ls]
APITrace
~900MB uncompressed.
when replaying the trace I see some compilation issues: 227035: message: major shader compiler error 2: 0:25(25): error: no matching function for call to `texture2DLod(sampler2D, vec2, float)'; candidates are: 227035: message: major shader compiler error 3: 0:25(17): error: operands to arithmetic operators must be numeric
and there are some 0:1294(3): preprocessor error: Unterminated= #if I think this is mostly due to uncompiled shaders, maybe there is more to it, but we should concentrate on those issues first.
Created attachment 141122<=
/a> [details]
APITrace Playback Log
As it may contain something useful.
I haven't tried force_glsl_extensions_warn, but MESA_GL_VERSION_OVERRIDE=3D4.5COMPAT doesn't help. It worked on older versi= ons of the game, but has no positive effect with the current version of the game (= aka No Man's Sky NEXT).
| What | Removed | Added |
|---|---|---|
| Status | NEW | NEEDINFO |
(In reply to Benjamin Hodgetts from comment #1) > Created attachment 141110= [details] > APITrace >=20 > ~900MB uncompressed. Please don't attach large traces to the bug itself instead please upload to= an external site such as google drive. It seems you have captured the trace without using overrides. You must use MESA_GL_VERSION_OVERRIDE=3D4.5COMPAT for NMS to work correctly. Also there = is a drirc option that is needed for the game to work correctly (you can also se= t it from the command line for testing) force_glsl_extensions_warn=3Dtrue. Do these two environment vars fix the issues for you?
(In reply to Benjamin Hodgetts from comment #6) > I haven't tried force_glsl_extensions_warn, but > MESA_GL_VERSION_OVERRIDE=3D4.5COMPAT doesn't help. It worked on older = versions > of the game, but has no positive effect with the current version of th= e game > (aka No Man's Sky NEXT). The override used to be broken and actually caused you to get an OpenGL core like profile. Since this is now fixed things will have changed, this is not= a regression. Please try using force_glsl_extensions_warn=3Dtrue it works around some game bugs.
| What | Removed | Added |
|---|---|---|
| CC | t_arceri@yahoo.com.au |
Created attachment 141209 [details] [review]
hack around preprocessor stringification
Ok I've taken a closer look and there is indeed new issues with this game
besides the existing ones.
Shaders include preprocessor stringification which is legal in C by not
specified in the GLSL spec e.g.
#define DOMAIN_PARAMS(dmn) ROOT_SIG(DS) [domain(#dmn)]
I've hacked around that with the following patch but then hit further shade=
rs
that fail to compile "unexpected LAYOUT_TOK"
>Please try using force_glsl_extensio=
ns_warn=3Dtrue it works around some game bugs.
That generated the two new messages in the terminal...
ATTENTION: default value of option force_glsl_extensions_warn overridden by
environment.
ATTENTION: option value of option force_glsl_extensions_warn ignored.
... so I assume it was picked up properly, but rendering behaviour didn't
change. The nebula clouds were still missing on the loading screen (so spac=
e is
just black) and in-game looked the same as the screenshot I originally post=
ed
(screen is just white except for the menu). All in all, no change.
I'll try with your hack patch and see if that changes behaviour.
BTW, the attachment limit on bugs is 4GB and my attachment was= 286MB. If people shouldn't post large attachments then it's probably worth lowering that lim= it, otherwise people have no way of knowing that they aren't supposed to attach large files.
Applied the patch in attachment 141209 [detai= ls] [review] and rebuilt, but the game looks the same. Something of note is that it's supposed to build the shaders on the f= irst load of the game, but the SHADERCACHE folder of the game is remaining empty= (I assume as the shaders are failing to build).
(In reply to Benjamin Hodgetts from comment #11) > Applied the patch in attachment 141209 [details] [review] [review] and rebuilt, but > the game looks the same. Something of note is that it's supposed to bu= ild > the shaders on the first load of the game, but the SHADERCACHE folder = of the > game is remaining empty (I assume as the shaders are failing to build)= . The hack should make the planets/stars render correctly on the shader loadi= ng screen. It also helps the sky render in-game, everything else is missing but I'm sure it's because of the remaining failing shaders. All in all this gam= e is extremely buggy. Do you know if it actually renders correctly on the AMD windows drivers?
AFAIK it works fine on Windows. The only people that had issue= s were people with old cards (e.g. 6000 series and below, due to lack of support). Just to clarify, you're using the latest version of the game, labeled "= ;NEXT"?
I've just rebuilt Mesa again with your patch, no CCache or any= thing this time, just in case. I'm still getting no clouds on the loading screen (you can see the stars as white dot and the names, but there's no colour, everything is = just black and white) and then when it gets "in game" the menu is ther= e, but the screen is still just white. I wonder if the card is specific here: OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.26.0, 4.18.3-1-clear, LLVM 8.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.0-devel (git-9e5e3a8ead)
Created attachment= 141230 [details] [review] hack around layout qualifiers The next shader compilation problem is that they are applying layout qualif= iers to function params. e.g void WriteTextureCacheFeedback( vec2 lCacheCoords, ivec2 lResolution, float lfDesiredMip, layout( r32i ) iimage2D lFeedbackMap, < -------- uint liFeedbackIndex ) layout( r32i ) can only be applied to uniforms. I've attached another hack that together with the other hack makes the game playable for me.
Looks like I lost MESA_GL_VERSION_OVERRIDE=3D4.5COMPAT somewhe= re along the line which is why I couldn't see anything. That, plus force_glsl_extensions_warn=3Dtrue and your two patches does indeed work. The starfield renders now but it's still missing the coloured cloud nebulae (this - https://cdn.cnn.com/cnnnext/da= m/assets/150617071718-game-faces-no-mans-sky-ns-natpkg-00014710-large-169.j= pg). So it seems your patches (and the overrides) get us most of the way there.<= /pre>
| What | Removed | Added |
|---|---|---|
| CC | nethershaw@gmail.com |
I've been following this issue since it was reported and I wou= ld like to contribute if I can. Since the bug status is currently "NEEDINFO"= I will endeavor to provide corroborating details and offer my platform for investigation and testing. I can begin by validating everything discussed in the comments so far. The issue presents itself on my platform exactly as Benjamin documented. My platform only differs slightly: OpenGL renderer string: Radeon RX Vega (VEGA10, DRM 3.26.0, 4.18.4-gentoo, = LLVM 6.0.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.0-rc4 The patches Timothy provided apply and build perfectly, and with the sugges= ted environment variables set while running NMS I can also exactly reproduce Benjamin's result. World assets render correctly; the game is playable; the galaxy map "clouds" are not visible; there appear to be significa= nt artifacts in the semi-transparent background textures of most UI elements (conversati= on dialogs and the tab menu). My first attempt at reproducing the problem and using the proposed patches = was done on Mesa 18.2.0-rc4 built from source, but I have no problem in princip= le with testing further against the current 18.3.0 development branch. I am happy to test additional patches and gather any additional information upon request. Thank you for starting the work.
| What | Removed | Added |
|---|---|---|
| Status | NEEDINFO | ASSIGNED |
(In reply to Matthew Vaughn from comment #17) > The patches Timothy provided apply and build per= fectly, and with the > suggested environment variables set while running NMS I can also exact= ly > reproduce Benjamin's result. World assets render correctly; the game is > playable; the galaxy map "clouds" are not visible; there app= ear to be > significant artifacts in the semi-transparent background textures of m= ost UI > elements (conversation dialogs and the tab menu). > The artifacts should be fixed by the zerovram part of this patch series [1] which you can already do with the following environment var R600_DEBUG=3Dze= rovram I've reported the shaders bugs from this bug report to the No Mans Sky devs= and also created some CTS tests to expose them on the Nvidia driver so hopefully they will get fixed in the game. As for the missing nebulae I'm not sure what the problem is there. All I kn= ow is it was working before the last game update and I suspect there may have = been another bug introduced somewhere. I'll have another look tomorrow but I'm probably not going to spend too much time on that issue since the game is otherwise now playable. [1] https://pat= chwork.freedesktop.org/series/48664/
Thanks for all the work so far Timothy.
| What | Removed | Added |
|---|---|---|
| Status | ASSIGNED | RESOLVED |
| Resolution | --- | FIXED |
(In reply to Benjamin Hodgetts from comment #19) > Thanks for all the work so far Timothy. No problem. Thanks for reporting the issues. I've now pushed patches to enable OpenGL 4.5 compat for radeonsi. I've fixe= d a bug in the lexer that was causing some shaders to fail to compile, and I've added a workaround to another shader bug in the game that they don't curren= tly want to work around as the Nvidia driver depends on the buggy shaders. So a= s of git master a couple of minutes ago No Mans Sky should run out of the box no manual environment vars required. As for the missing nebulae there is a shader failing to compile as they are missing an #endif to go with an #ifdef. This is my guess as to why its fail= ing to display, and I've let the NMS devs know about it. If I'm correct this is= sue should be present even on Nvidia drivers currently. So with that I think we can now close this bug.
| What | Removed | Added |
|---|---|---|
| CC | jonathanilevi@gmail.com |
*** Bug 107778 has been marked as a du= plicate of this bug. ***