| Summary: | Stellaris - Black/super dark planets | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Christopher W. Carpenter <mordocai> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | mesa-dev |
| Severity: | minor | ||
| Priority: | medium | CC: | alexander, jlp.bugs, kai, mboquien, nikolai.vaags, notasas |
| Version: | git | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 77449 | ||
| Attachments: |
Visual glitch of planet in stellaris
An example of the planet rendering properly snapshots New game screen with mesa master 2016-08-18 Light side of planet in game mesa master 2016-08-18 Dark side of planet in game mesa master 2016-08-18 New game screen in windows 2016-08-18 Light side of planet in game windows 2016-08-18 Dark side of planet in game windows 2016-08-18 Planets are rendered as almost black spheres in menus screenshot on r600g with mesa-git43e8808b8 Planests look good now |
||
Created attachment 123614 [details]
An example of the planet rendering properly
apitrace is too large for attachment. I have it on dropbox here: https://www.dropbox.com/s/6s7sc0ao5sxr1f1/stellaris.trace?dl=0. Please let me know if there is a better place to put this. Replaying the apitrace with LIBGL_ALWAYS_SOFTWARE=1 (forcing llvmpipe) gives the same broken rendering, so this doesn't seem to be a driver specific issue. Reassigning to Mesa core for now. I also noticed a lot of messages like these while replaying the apitrace, which might even indicate a game bug: 555820 @0 glCompileShaderARB(shaderObj = 266) 555820: warning: 0:298(55): warning: `vSinCos' used uninitialized 0:298(66): warning: `vSinCos' used uninitialized 555825 @0 glCompileShaderARB(shaderObj = 267) 555825: warning: 0:547(83): warning: `diffLight' used uninitialized 0:547(94): warning: `specLight' used uninitialized (In reply to Michel Dänzer from comment #3) > Replaying the apitrace with LIBGL_ALWAYS_SOFTWARE=1 (forcing llvmpipe) gives > the same broken rendering, so this doesn't seem to be a driver specific > issue. Reassigning to Mesa core for now. > > > I also noticed a lot of messages like these while replaying the apitrace, > which might even indicate a game bug: > > 555820 @0 glCompileShaderARB(shaderObj = 266) > 555820: warning: 0:298(55): warning: `vSinCos' used uninitialized > 0:298(66): warning: `vSinCos' used uninitialized > > 555825 @0 glCompileShaderARB(shaderObj = 267) > 555825: warning: 0:547(83): warning: `diffLight' used uninitialized > 0:547(94): warning: `specLight' used uninitialized I'm not sure if this changes anything as far as assigning it to mesa core, but my laptop running the i915 driver with mesa 11.1.3 does not exhibit the rendering issue. If there is something helpful I can do from that end (would an API trace from that laptop matter at all?) i'd be happy to do it. The trace replays fine on i965 (SKL) but incorrectly on llvmpipe, at commit 2655265 as well as on 11.2.2. BTW, those "used uninitialized warnings" are hardly always accurate. They can refer to dead code, etc. (In reply to Christopher W. Carpenter from comment #4) > I'm not sure if this changes anything as far as assigning it to mesa core, > but my laptop running the i915 driver with mesa 11.1.3 does not exhibit the > rendering issue. It doesn't change anything, we're using the Mesa core component for driver-independent Gallium issues as well. > (would an API trace from that laptop matter at all?) It would be interesting (in particular, whether replaying that trace on a Gallium driver also reproduces the problem), yes. Replaying on nvc0 also brings up the same issue. So the current status is llvmpipe: fail nvc0: fail radeonsi: fail (i assume, otherwise we wouldn't have this bug) i965/SKL: success Feels like a Gallium issue. First bad draw call in the referenced trace is 803513, I believe. That ends up with the "bad" earth - the S3TC texture of the earth doesn't appear to be making it on there. There are several draw calls involved in rendering the planet, the last one is 803895. It's not clear which of them gives the incorrect result. It would be helpful if somebody could provide snapshots of the framebuffer after each of the involved draw calls (803513, 803584, 803714, 803793, 803895) on a system that renders this _correctly_. This can be done using the --snapshot argument to glretrace, or interactively using qapitrace's "Lookup State" feature. Created attachment 124314 [details]
snapshots
glretrace --snapshot did not work for me:
803513: message: major api error 955: GL_INVALID_OPERATION in glReadPixels(multisample FBO)
warning: GL_INVALID_OPERATION while getting snapshot
but I could get them manually from qapitrace along with some messages. Taken on:
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)
OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.1.0-devel (git-1535519)
This seems to have been fixed with the latest Mesa from git. Either this, or the 1.2 upgrade to Stellaris itself did the trick. The only problem left now is the ugly cursor that uses a non-premultiplied alpha. Slight correction: the textures load correctly in-game; however the planets are still broken as before (i.e. showing only the night texture) in the "New game" screen, where the player selects who they want to play as. I'm not entirely sure, but I believe Gražvydas' snapshots are exactly from this (still broken) screen. Sorry for the spam, but I just realised that earlier game versions can be tested. Going back as far as 1.0.0, the situation is the same: textures work in-game, but are broken in the start new game screen. Unless I'm missing something important, it thus seems that whatever brought the improvement must be in Mesa. Whether intentional or not, kudos! Hopefully, the remaining problems can be fixed too. (In reply to Luchesar V. ILIEV from comment #13) > Sorry for the spam, but I just realised that earlier game versions can be > tested. Going back as far as 1.0.0, the situation is the same: textures work > in-game, but are broken in the start new game screen. Unless I'm missing > something important, it thus seems that whatever brought the improvement > must be in Mesa. Whether intentional or not, kudos! Hopefully, the remaining > problems can be fixed too. So is this fixed or not? Alright, I finally got my rig back setup with the right mesa options and everything and have new screenshots and a new API trace. Attaching these now. I'm including windows screenshots from my wife's PC as "how it should look". New Game screen definitely does not look like the windows version but it looks to me like everything looks the same in-game now (at least for Earth). The new api trace is build on the same system with radeonsi and build options: ./configure CC="gcc -m32" CXX="g++ -m32" --prefix=$HOME/install/i386/ --enable-driglx-direct --enable-gles1 --enable-gles2 --enable-glx-tls --with-dri-driverdir=$HOME/install/i386/lib/dri --with-egl-platforms='drm x11' --with-gallium-drivers=radeonsi --enable-texture-float --host=i686-pc-linux-gnu --build=x86_64-pc-linux-gnu It was run with(stellaris wouldn't listen to LD_LIBRARY_PATH): LIBGL_DRIVERS_PATH=/home/mordocai/install/i386/lib/dri/ /home/mordocai/git_repos/apitrace/build32/apitrace trace .steam/steam/steamapps/common/Stellaris/stellaris Adding attachments now. Created attachment 125898 [details]
New game screen with mesa master 2016-08-18
Created attachment 125899 [details]
Light side of planet in game mesa master 2016-08-18
Created attachment 125900 [details]
Dark side of planet in game mesa master 2016-08-18
Created attachment 125901 [details]
New game screen in windows 2016-08-18
Created attachment 125902 [details]
Light side of planet in game windows 2016-08-18
Created attachment 125903 [details]
Dark side of planet in game windows 2016-08-18
Forgot that the trace is too big to attach. You can download the new trace here: https://www.dropbox.com/s/hhtrsxq3hk1efow/stellaris_2016-08-18.trace?dl=0. I actually go in game with it and circle around the earth for a bit. Created attachment 130866 [details] Planets are rendered as almost black spheres in menus This is still an issue with an up-to-date OpenGL stack (see below for the details), in fact, I would argue that it's even worse than shown in the previously attached screenshots, see the attached screenshot. Stellaris is updated to version "1.5.1 (8818)". The graphics quality settings are all on their respective maximum settings. The full stack (Debian testing as a base) is: GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/566f2ed571 libdrm: Git:master/c9c77c3717 (tag libdrm-2.4.79) LLVM: SVN:trunk/r299977 (5.0 devel) X.Org: 2:1.19.2-1 Linux: 4.10.9 Firmware (firmware-amd-graphics): 20161130-2 libclc: 0.2.0+git20170330-1 (rebuilt for LLVM 5.0) DDX (xserver-xorg-video-amdgpu): 1.2.0-1+b1 Let me know if you need anything else (like a newer apitrace than the one from comment #22). I made a new test with Stellaris 1.6.1. With Mesa 17.1.0 on an RX480, the results are unchanged, with broken planets both in the intro screen and in-game. Seconding the previous comment, is there any way we may help? Created attachment 133972 [details]
screenshot on r600g with mesa-git43e8808b8
I've tested the trace on r600g and also in software mode on mesa git 43e8808b8
and I'd say that the planet looks quite okay (see partial screenshot) and very similar to the Windows screenshot (a bit more glossy though).
Created attachment 133974 [details] Planests look good now I can confirm, that the rendering of the planets has improved significantly with the stack detailed below (see attached screenshot), but it's still off from attachment 133972 [details]. Though the version I'm now uploading here might actually be how it is now intended to be rendered. A quick YouTube search for gameplay from this game version showed the blueish highlights on the dark side of the planet in almost all instances I've found. (See eg. <https://youtu.be/eoplpnVXnf4?t=25s> for some footage from an official channel.) Therefore I think this bug report should be closed. Game version: 1.6.2 (d7ec) The full stack used (fully updated Debian testing as a base) was: GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/39a69f0692 libdrm: 2.4.82-1 LLVM: SVN:trunk/r312520 (6.0 devel) X.Org: 2:1.19.3-2 Linux: 4.12.10 Firmware (firmware-amd-graphics): 20170823-1 libclc: Git:master/7331b0a1fa DDX (xserver-xorg-video-amdgpu): 1.3.0-1 (In reply to Kai from comment #26) > [...] > > The full stack used (fully updated Debian testing as a base) was: > GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) > Mesa: Git:master/39a69f0692 > libdrm: 2.4.82-1 > LLVM: SVN:trunk/r312520 (6.0 devel) > X.Org: 2:1.19.3-2 > Linux: 4.12.10 This line should have read "Linux: 4.13.0". Forgot I already rebooted. > Firmware (firmware-amd-graphics): 20170823-1 > libclc: Git:master/7331b0a1fa > DDX (xserver-xorg-video-amdgpu): 1.3.0-1 Since nobody spoke up after comment #25 from Gert, comment #26 by myself and I'm seeing good rendering with the stack detailed below, I'm closing this as "fixed". If somebody still sees this with a current game version and driver stack, they can reopen. The stack used (fully updated Debian testing as a base) was: Game version: Stellaris 1.6.2 (d7ec) GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/57a341b0a9 libdrm: 2.4.82-1 LLVM: SVN:trunk/r312707 (6.0 devel) X.Org: 2:1.19.3-2 Linux: 4.13.0 Firmware (firmware-amd-graphics): 20170823-1 libclc: Git:master/7331b0a1fa DDX (xserver-xorg-video-amdgpu): 1.3.0-1 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 123613 [details] Visual glitch of planet in stellaris Stellaris is 32-bit only. This was tested on debian testing x86_64 with compiled for 32-bit and installed git master radeonsi driver and libGL. I confirmed stellaris was using the correct libGL and radeonsi_dri via /proc/pid/maps. I compiled mesa with: CC="gcc -m32" CXX="g++ -m32" ./autogen.sh --with-gallium-drivers=radeonsi --with-egl-platforms=drm,x11 --enable-texture-float --enable-glx-tls --enable-shared-glapi --enable-glx --enable-driglx-direct --enable-gles1 --enable-gles2 --build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu It ouputs: prefix: /usr/local exec_prefix: ${prefix} libdir: ${exec_prefix}/lib includedir: ${prefix}/include OpenGL: yes (ES1: yes ES2: yes) OSMesa: no DRI platform: drm DRI drivers: i915 i965 nouveau r200 radeon swrast DRI driver dir: ${libdir}/dri GLX: DRI-based EGL: yes EGL platforms: drm x11 EGL drivers: builtin:egl_dri2 builtin:egl_dri3 Vulkan drivers: no llvm: yes llvm-config: /usr/bin/llvm-config llvm-version: 3.6.2 Gallium drivers: radeonsi Gallium st: mesa vdpau Shader cache: no Shared libs: yes Static libs: no Shared-glapi: yes CFLAGS: -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-math-errno -fno-trapping-math -fno-builtin-memcmp CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp Macros: -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -DUSE_SSE41 -DNDEBUG -DTEXTURE_FLOAT_ENABLED -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DHAVE_XLOCALE_H -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DHAVE_LIBUDEV -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DHAVE_ALIAS -DHAVE_DRI3 -DHAVE_MINCORE -DHAVE_ST_VDPAU -DHAVE_LLVM=0x0306 -DMESA_LLVM_VERSION_PATCH=2 LLVM_CFLAGS: -I/usr/lib/llvm-3.6/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS LLVM_CXXFLAGS: -I/usr/lib/llvm-3.6/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 LLVM_CPPFLAGS: -I/usr/lib/llvm-3.6/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS LLVM_LDFLAGS: -L/usr/lib/llvm-3.6/lib PYTHON2: python2.7 PYTHON3: python3.5 Run 'make' to build Mesa My graphics card shows up as: Advanced Micro Devices [AMD/ATI] Curacao XT [Radeon R7 370 / R9 270X/370 OEM] I have attached a picture with this description. I don't see a way to add multiple attachments so I will attach a picture of what it should look like as well as the apitrace after I submit. I'm new to all this so sorry if I missed anything! I have a vested interest in fixing this and am a programmer(though super inexperienced with graphics) so feel free to give me technical instructions.