There's a fix for it but I don't believe its available right now. Should appear in mesa-dev soon.

https://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-GL-4.5-Compat-Patches

Works flawlessly with an nvdia card though

This game actually has a issue with nvidia cards, it can't allocate vram correctly so you end up with texture and terrain mesh pop in that is quite bad.

If you switch between windows and linux and just pan/walk around you can see this effect quite obviously. Do 180deg turn and the textures slowly load in along with tessellation mesh etc...

this is probably a result of the game unable to detect correct amount of vram for the videocard for some reason and auto assigning quite a low amount instead of utilizing the GPU's full amount.

The warning can be turned off in NMS config but it doesn't fix the issue, no amount of setting fixes it.

Hello,
today it seems now NMS is finally working, in some case...
The white screen is gone and the game is playable. But the ground textures are glitching around.
I use this ppa to get the newest mesa build: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers
They have merged the workarounds that i mentioned before and where discussed in this mesa bug report: https://bugs.freedesktop.org/show_bug.cgi?id=107581
I hope somebody can report back if he have the same issues with the ground textures.

No Man's Sky (App ID:275850) black screen on resolution higher than 1920*1080

Issue transferred from https://github.com/ValveSoftware/Proton/issues/1034.
@Liodinis posted on 2018-08-30T22:52:04:

Ubuntu 18.04.1 LTS
I7 6700K @ 4.00Ghz
Nvidia GTX 1070
Nvidia driver 396.54
Proton 3.7-3
RAM 16Go
SSHD 1To Toshiba H200
Display Acer Predator 24" 2560X1440

"No Man's Sky" doesn't work on resolution higher than 1920*1080.

Launch the game is displaying a black screen, but the game seems to be working, because sounds can be hear in background.
If you put your screen resolution at 1920*1080 or edit the config file TKGRAPHICSSETTINGS.MXML with the native resolution of your screen at the place below :

/home/username/.local/share/Steam/steamapps/common/No Man's Sky/Binaries/SETTINGS

restart the game, and it will become playable.

Hardware Configuration.txt

No Man's Sky config file.zip

No Man's Sky [App ID:275850] Crash on nvidia

Issue transferred from https://github.com/ValveSoftware/Proton/issues/1072.
@hitchhiker54 posted on 2018-08-31T13:42:44:

The game plays flawlessly so far except for scanning when an npc base is in view. Tested on Minor Settlement and Observatory type, if the base is in view the game instantly crashes to desktop when in visor view. Player bases, ships, exocraft all seem to be fine. Using gtx980ti, i76700k on Ubuntu 18.04, Nvidia drivers 396.54

[edits additional]
Game version 1.58, issue also reported to Hello Games

sudo lshw results :
https://www.dropbox.com/s/xxu34qjfnjp7f01/specs.txt?dl=0

Ubuntu 16.04, NVIDIA GTX 970, Proton 3.7-5 Beta:

Steam System Information

Test | Result
-- | --
Singleplayer | Working as expected
Local Co-op | _N/A_
Online Multiplayer | Working as expected

Configuration | ...
-- | --
Input | Steam Controller
Display | 1920x1080
Fullscreen | Yes
Preset | Medium^
VSync | Off^^
API | OpenGL

^ Default graphics preset is High
^^ Default VSync setting is On

Tried with Proton 3.7-3.

The game worked flawlessly. With my setup. Attached pastebin shows the specs of my machine and versions of all relevant drivers/software.

My specs: https://pastebin.com/9hQP94N1

Yes it works technically better then on windows for me because on windows I can't remove screen tearing without vsync enable which seems to cost fps. But under linux with vsync off there is no tearing.

I did find the game caches textures a bit slow on NTFS, you can speed it up a bit by using big_writes in the disk drive mount options. Or move it to BTRFS or EXT4 drive.

No Man's Sky seems to actually run smoother on my aging graphics card in Linux! Seems to be working out of the box.

Fedora 28
Core i7-4770
Nvidia GTX 760
Proton 3.7-3

I had the same black screen issues as comment: https://github.com/ValveSoftware/Proton/issues/438#issuecomment-417493922

In the same TKGRAPHICSSETTINGS.MXML file, setting "Borderless" to True will also allow the game to run properly, even if the desktop resolution is higher than the game's resolution. I want to run games at 1920x1080 for any recording/streaming, but my desktop is set to 1920x1200, setting the borderless option allows me to do so.

In Windows have no problem just setting my monitor to 1920x1080 when needed, but in Linux I am having an issue which I suspect is with my DVI cable, that's not letting the system recognize any 16:9 resolutions for this monitor, and I've been unable to add them with xrandr (keep getting a BadMatch error when trying to add it to DVI-I-1.) I've got a DisplayPort cable on order that I'm hoping will open up the full range of resolutions my monitor is capable of. My second monitor connected via HDMI has all of it's modes properly recognized, my main monitor doesn't have an HDMI port or I would have tested it to be sure it's the DVI cable.

Update: It was the DVI cable. DP cable came in last week and all display modes/resolutions are available now.

[ISSUE] No Man`s Sky no sound ( 275850)

Issue transferred from https://github.com/ValveSoftware/Proton/issues/1459.
@Rainakins posted on 2018-09-15T09:23:49:

Compatibility Report

• Name of the game with compatibility issues: No Man`s Sky
• Steam AppID of the game: 275850

System Information

• GPU: GTX 1050ti
• Driver/LLVM version: Nvidia 396.54
• Kernel version: 4.15
• Link to full system information report as Gist:

Computer Information:
Manufacturer: Unknown
Model: Unknown
Form Factor: Desktop
No Touch Input Detected

Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD Ryzen 5 2600 Six-Core Processor
CPU Family: 0x17
CPU Model: 0x8
CPU Stepping: 0x2
CPU Type: 0x0
Speed: 3400 Mhz
12 logical processors
6 physical processors
HyperThreading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported

Operating System Version:
Ubuntu 18.04.1 LTS (64 bit)
Kernel Name: Linux
Kernel Version: 4.15.0-34-generic
X Server Vendor: The X.Org Foundation
X Server Release: 11906000
X Window Manager: GNOME Shell
Steam Runtime Version: steam-runtime-beta-release_2018-06-14

Video Card:
Driver: NVIDIA Corporation GeForce GTX 1050 Ti/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 396.54
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 60 Hz
VendorID: 0x10de
DeviceID: 0x1c82
Revision Not Detected
Number of Monitors: 1
Number of Logical Video Cards: 1
Primary Display Resolution: 1920 x 1080
Desktop Resolution: 1920 x 1080
Primary Display Size: 20.08" x 11.30" (23.03" diag)
51.0cm x 28.7cm (58.5cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 4096 MB
Supported MSAA Modes: 2x 4x 8x 16x

Sound card:
Audio device: Nvidia GPU 80 HDMI/DP

Memory:
RAM: 16052 Mb

Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Total Hard Disk Space Available: 194192 Mb
Largest Free Hard Disk Block: 107787 Mb
VR Headset: None detected

Recent Failure Reports:

• Proton version: 3.7-6

I confirm:

• [ x ] that I haven't found an existing compatibility report for this game.
• [ x ] that I have checked whether there are updates for my system available.

steam-275850.log

Symptoms

The sound was working initially for about a week and for some reason yesterday the sound completely stopped working everything else still runs fine and performance is great but the sound simply does not work any longer

Reproduction

for me its easily done by launching the game

For me the game freezes after difficulty selection. I just get a black screen, and GNOME becomes completely unresponsive. The sound for the game continues, however, I am unable to interact with the computer further, and a hard reset is required. I have tried manually changing the game to borderless and windowed modes to no effect.

I'm using an R9 Fury, Mesa 18.3, LLVM 8 from Padoka unstable as recommended by Proton, and kernel 4.18.8.

What does ulimit -aH tell you? could be a limited open files issue which is often associated with load freezes.

output of ulimit -aH

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63415
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63415
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Hello @viggy96, give https://github.com/zfigura/wine/blob/esync/README.esync a read and increase the max open files limit on your system.

@kisak-valve I thought I did it properly before, but apparently not, LOL. However, regardless, No Man's Sky still fails in the same way for me.
output of ulimit -aH

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63415
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1048576
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63415
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

I still can't seem to get past the black screen on this game. Not sure what could be causing this. I've increased the max open files limit, as above, but still no dice.

Nvidia 396.54.09, Geforce GTX 1050ti, Proton 3.16-1 Beta, Slackware 14.2 multilib. After this morning's update to Proton 3.16-1, I'm getting an error saying No Man's Sky needs at least 1.5 GB of VRAM and that the adapter (blank) is reporting 0. The game loads and plays just fine, if you click through, though. Bug? Or something I need to change?

@viggy96 Are you still having trouble?

Sorry, meant to update. My issues were fixed with 3.16-3.

@SwooshyCueb Yes, I am. I still can't get past the black screen. I've tried editing the game settings file to use borderless mode, as some other have suggested, but still No Man's Sky doesn't work for me.

I'm using an R9 Fury, Mesa 18.3, LLVM 8 from Padoka unstable as recommended by Proton, and kernel 4.18.8.

Only thing I can suggest is don't use experimental drivers and LLVM8, go back to release mesa version 18.2.x and try LLVM 7.0

I know Ubuntu repos are terrible for getting latest stable version drivers sometimes, I use antergos personally.

@viggy96 If you're feeling adventurous, you could give https://launchpad.net/~kisak/+archive/ubuntu/steamvr a try (kernel and xorg-server should not be needed for this), otherwise https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/pkppa is a relatively safe bet.

@kisak-valve Unfortunately, the stable Padoka PPA does not solve the issue for me. I also tried disabling the Steam overlay, but to no avail. Also, to update, I'm using kernel 4.19 currently. Its a very strange issue, as even the GNOME desktop locks up, and I am forced to hard reset my computer.

Might be a Fury R9 and AMDGPU driver issue perhaps? not many people have the Fury cards anymore.

I have a 1080Ti because 4k and AMD has yet to support 4k gaming at 60fps, once they do then I'll move back to AMD GPU's and be able to experience all the AMD related steamplay bugs people get.

ATM the major issue with NVIDIA cards is the libraries some games attempt to use are incompatible with Wine/Proton, which is why they introduced the spoofing trick recently.

I have an issue with rendering all 3d content in game (all black in loading, white in game). All menus works well.

Changing settings has no effect.
Tested on Ubuntu 18.04 LTS and Solus 3.99 - same result. (On ubuntu also try the latest amdgpu drivers from amd website)

specs:
Radeon RX 580 Series (POLARIS10, DRM 3.26.0, 4.18.16-97.current, LLVM 7.0.0)
AMD® Ryzen 5 1600x six-core processor × 12
7,8 Gb RAM

The drivers off AMD's website are amdgpu-pro

The ones you will want to try are oibaf package on launchpad which should be compatible with any ubuntu based distro (not sure if solus is).

@jarrard solus is ubuntu-based, but it have it's own package system.
I returned to ubuntu 18.04 and tried oibaf repo and it works well now, thanks a lot.

Works on my system (Ubuntu 18.04 with Mesa 19 Git R9 290)

OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon R9 200 Series (HAWAII, DRM 3.26.0, 4.18.19-041819-generic, LLVM 7.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.0-devel (git-fbf95ce 2018-11-29 bionic-oibaf-ppa)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.0.0-devel (git-fbf95ce 2018-11-29 bionic-oibaf-ppa)
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.0.0-devel (git-fbf95ce 2018-11-29 bionic-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

It has some visual glitches, some trees display white artifacts on the border of the leaves and branches.

Bush-like plants and grass appear and re-appear in front of you as if they disolve due to distance, but they're in front of you.

Other than that 100+ hours playing on Linux!

@AntoChu

@jarrard solus is ubuntu-based, but it have it's own package system.

Solus is not Ubuntu based. It started out that way, but cut ties and started over from scratch, now is it's own thing.

Gentoo w/Mesa 18.3.1 on 4.19.9 kernel, runs like a dream. On my Vega64 it outperforms the Windows OpenGL driver.

Those guys at Mesa kick ASS at OpenGL, and they're making huge Vulkan improvements. These are good times.

Working for me too since mesa 18.3.1 on ArchLinux.

However, I first got some weird glitches, fixed by specifying these launch options for No Man's Sky:

MESA_GL_VERSION_OVERRIDE=4.5COMPAT force_glsl_extensions_warn=true %command%

Everything is running great then on Vega64, just the Tesselation that really impacts performances, even on low, so turning it off really helps.

With proton 3.16-6, if I have STEAM_PREFER_HOST_LIBRARIES set to 0, NMS won't connect to the servers. If I have it set to 1, it will. This a result of the gnutls change? (Slackware 14.2 does ship with 3.6.5.) This worked fine without using host_libraries in 3.15 and below.

I have the same issue as @viggy96 .

Running on Kernel 4.19-4.21 rc, from Mesa 18.3 release to Mesa-GIT, LLVM7 and LLVM8-svn, the game produces a black screen.

Kernel 4.18 and GIT version of mesa based on 18.3 with LLVM-SVN, I had no issues. Pulled 123 hours into the game.

Using a Vega 56. Tried all fixes mentioned. Even gone as far as emptying all my cache, to no avail.

I'm having problems on my Wayland based Fedora 29 system with an ATI Vega64 card. I'm getting a white screen with odd lines that show up as systems are initialized when I first start the game, after I pick a difficulty.

I've verified that yes, indeed, I have 2^20 open files as both a hard and soft limit. I've verified that the steam process is set up that way too.

It was actually quite vexing as the steam installer on my system sets a soft limit of 1024 and a hard limit of 2^18 with a comment about Proton. It took me awhile to track all that through dracut and all kinds of other things.

Update: I tried @Anthony25 's solution and that improved things. But, the ground still isn't visible. Nor is most of the HUD. Also, I get weird artifacts in the background when I switch to the screen that lets you mess with your multitool or make stuff.

It works fine on my laptop with a really anemic Quadro M1200 Mobile. :-/

Steam using Wine standard, so I wonder if there is fixes for this game in staging because that's what I use. Also this game is OpenGL (native) so not directx involved, which is double odd you'd get graphic issues given that its native API.,

Maybe fedora has a bad mesa version?

Here's my version of everything mesa related. :-)

$ rpm -qa '*mesa*' mesa-vulkan-drivers-18.2.8-1.fc29.x86_64 mesa-libglapi-18.2.8-1.fc29.i686 mesa-libEGL-18.2.8-1.fc29.x86_64 mesa-libGL-devel-18.2.8-1.fc29.x86_64 mesa-vulkan-drivers-18.2.8-1.fc29.i686 mesa-libGLU-9.0.0-16.fc29.x86_64 mesa-libGL-18.2.8-1.fc29.i686 mesa-libgbm-18.2.8-1.fc29.x86_64 mesa-filesystem-18.2.8-1.fc29.i686 mesa-libOpenCL-18.2.8-1.fc29.x86_64 mesa-vdpau-drivers-18.2.8-1.fc29.x86_64 mesa-libxatracker-18.2.8-1.fc29.x86_64 mesa-libGL-18.2.8-1.fc29.x86_64 mesa-libEGL-devel-18.2.8-1.fc29.x86_64 mesa-libglapi-18.2.8-1.fc29.x86_64 mesa-dri-drivers-18.2.8-1.fc29.x86_64 mesa-filesystem-18.2.8-1.fc29.x86_64 mesa-dri-drivers-18.2.8-1.fc29.i686 mesa-khr-devel-18.2.8-1.fc29.x86_64

That may, or may not tell you what you need to know.

I want to report that No Man's Sky does not work (will not open at all) on my Ubuntu 18.04 system with an AMD GPU (RX 550)

using the free driver amdgpu, provided by AMD. I've reinstall steam and the game to confirm this.

steam-275850.log

Yeah I dunno, seems I can't get the GOG version to run through Steam either on my nvidia gpu. Odd issue.

Lutris works fine.

I discovered that the game requires a vulkan driver to be installed, which is not included in Ubuntu 18.04. I installed the packages mesa-vulkan-drivers & mesa-vulkan-drivers:i386 from Padoka Stable PPA

https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/pkppa

I am also not experiencing any of the OS issues I experienced when I tried the amdgpu-pro-18.50-708488-ubuntu-18.04 driver. This was recently updated to a new build (725072), and may have fixed issues with the amdgpu-pro driver set (which includes a vulkan driver). But I wasn't going to risk it, since I had major issues.

Fix - use Padoka PPA packages.

Has the game moved to vulkan now? thought it was opengl...

Hmm, I've been using the Padoka PPA for forever, and No Man's Sky has yet to work on my machine. I still get a GNOME desktop lockup, and am forced to hard reset the machine, after selecting a difficulty in the game.

https://www.nomanssky.com/2019/04/vulkan-update/ Apparently there's an engine change to Vulkan. Has anyone tried the experimental branch yet?

Nms now has an experimental vulkan renderer, it may help amd on some of the 3 vulkan drivers (radv, amdvlk,-pro)

No Man's Sky - Vulkan branch (experimental)

Issue transferred from https://github.com/ValveSoftware/Proton/issues/2546.
@Rodhin posted on 2019-04-16T16:35:46:

Compatibility Report

• Name of the game with compatibility issues: No Man's Sky
• Steam AppID of the game: 275850

System Information

• GPU: GTX 980Ti
• Driver/LLVM version: nvidia 418.56
• Kernel version: 4.18
• Link to full system information report as Gist: https://gist.github.com/Rodhin/98698055599b676e3e8c868604cc75cf
• Proton version: 4.2-2

I confirm:

• [x] that I haven't found an existing compatibility report for this game.
• [x] that I have checked whether there are updates for my system available.

steam-275850.log

Symptoms

Today the game received an experimental branch, they will switch from OpenGL to Vulkan. The OpenGL version runs like a dream, but the Vulkan version barely runs with 2-5 FPS. When the next big update is released for the game they will drop the OpenGL renderer completely.

More info about the Vulkan release and access to the experimental branch:
https://www.nomanssky.com/2019/04/vulkan-update/

Reproduction

Switch to the experimental branch and launch the game.

Moving my response to the correct thread, sorry!

GPU: GTX 1050ti
Driver/LLVM version: nvidia 418.49.04
Kernel version: 4.4.172
Link to full system information report as Gist: https://gist.github.com/garpu/20a8d8928b67f691d56b355c39b4ac28
Proton version: 4.2-2

Same issue, here. Bad fps, and it seems like no settings affect performance. (I reset graphics options to default, around medium, where I was able to play on all high on the OpenGL renderer.)

Log: https://gist.github.com/garpu/bd9d23b1821bbb5f4a6b5f95a9947d02

Also confirming the Vulkan update to No Man's Sky has dropped the performance, it's unplayable now.

System info: https://gist.github.com/LiamDawe/2db6810dfec6b26a81a72580d15a509a

Proton Log file: https://gist.github.com/LiamDawe/9497165b31f4ea96f640b3db109db4ad

I've tried the experimental Vulkan patch with not only Proton 4.2 but the 3.16 beta and an unofficial TKG wine build (although not latest which I will try next) and same result. I've also confirmed performance is not the same as Windows (where there's only a 5 fps drop from OGL).

It appears to be using only one CPU thread (or not using the others well).

Tested the game's experimental vulkan renderer with my amd rx470 and with RADV it crashes my computer in a spectacular way turning everything purple and spamming the tty with "[drm:amdgpu_cs_ioctl [amdgpu]] ERROR Failed to initialize parser 125!", tested it also with AMDGPU-PRO vulkan driver and it worked with a beautiful 60fps near a crashed freighter (haven't tested it further). I don't how well AMDVLK will work, but it will probably work the same way as -pro but with a longer loading screen and stuttering.

I think the vulkan update to Talos Principle was slower then OpenGL when it first came out also, obviously there are further issues for wine compatibility but hopefully the developer and progress it along over time.

I updated video card drivers to the 418.52.03 drivers for Nvidia, and no change.

tried the vulkan renderer again but with latest mesa stable release (19.0.2) and it didn't crash my system but it had very very bad performance at first (5 fps max), but I fixed it by selecting default settings on the graphics menu and fps went to max 60fps

tried the vulkan renderer again but with latest mesa stable release (19.0.2) and it didn't crash my system but it had very very bad performance at first (5 fps max), but I fixed it by selecting default settings on the graphics menu and fps went to max 60fps

Going by reports elsewhere it seems the Nvidia driver has an issue.

Edit: I've made a post here on the Nvidia devtalk forums, if more people with Nvidia cards share your experiences hopefully the issue might get looked at.

That could well be true. Someone here said switching away from the beta Vulkan drivers (on windows) fixed the issue: https://www.reddit.com/r/NoMansSkyTheGame/comments/bdxlls/177_vulkan_performance_thread/

Has anyone tried 418.56?

Looks like there's a thread started on the Nvidia forums, as well: https://devtalk.nvidia.com/default/topic/1050274/linux/no-mans-sky-proton-vulkan-patch-performance-issues-with-nvidia/

That could well be true. Someone here said switching away from the beta Vulkan drivers (on windows) fixed the issue: https://www.reddit.com/r/NoMansSkyTheGame/comments/bdxlls/177_vulkan_performance_thread/

Has anyone tried 418.56?

Looks like there's a thread started on the Nvidia forums, as well: https://devtalk.nvidia.com/default/topic/1050274/linux/no-mans-sky-proton-vulkan-patch-performance-issues-with-nvidia/

I've tried the Vulkan beta drivers on windows, no issues with them. I've also tried 418.56 in Linux which have the same problem as the dev drivers in Linux.

Complete lockup for me, exactly the same way as when the AMDGPU drivers didn’t support OpenGL 4.5. White screen and then complete system hang.
Ubuntu 18.10 with Kernel 5.0.2 generic, Padoka PPA unstable Mesa 19.1 git, LLVM 9

No change with the April 18 update. Allegedly we're supposed to get a message if our drivers aren't supported? I haven't received a message starting it. Assuming it's checking for vulkan extensions? What is implemented in the AMD driver that works that isn't in the Nvidia one? If we can figure that out, we might be able to provide something to the nvidia driver people. (Assuming, also that this isn't an engine bug, which it could be--people on the latest drivers on Windows are having the same issue.)

Someone on the protondb said they got it working decently with amdvlk drivers with a couple of tricks.

• GPU: GTX 970
• Driver/LLVM version: 418.56
• Kernel version: 5.0.7
• Link to full system information report as Gist: https://gist.github.com/RockyTV/76d1c9f5be0ce138cdd3594de56eb5da#file-sysinfo-txt
• Proton version: 4.2-3
• Proton log: https://gist.github.com/RockyTV/76d1c9f5be0ce138cdd3594de56eb5da#file-steam-275850-log

I've tried running it disabling wined3d but it looks like it didn't fallback to DXVK. Any runtime settings doesn't seem to affect the performance - went from a playable 60 FPS state (normal branch) to 10-12 FPS with the experimental branch.

I've tried running it disabling wined3d but it looks like it didn't fallback to DXVK. Any runtime settings doesn't seem to affect the performance - went from a playable 60 FPS state (normal branch) to 10-12 FPS with the experimental branch.

Game doesn't use Direct X btw so WineD3D or DXVK are not used at all. It's straight up Vulkan (or OpenGL for current live) so using any D3D related launch commands is pointless.

Edit: New Nvidia driver 418.52.05 released no change.

Small update tried 430.09 same issue.

One thing I keep noticing is this error appearing in the logs:

4306.386:002a:002b:fixme:vulkan:wine_vkCreateCommandPool Support for allocation callbacks not implemented yet

Doesn't load at all with the April 29 update. I'm getting a popup with "Unable to initialize Vulkan (vkEnumerateInstanceExtensionProperties failed.) You may not have a Vulkan driver installed, or an old driver on your machine may be corrupted."
ETA: I've got 418.52.05 installed. No problems with dxvk applications.

I have to confirm. Running the game after April 29 experimental update results in the error dialog (vkEnumerateInstanceExtensionProperties), followed by a black screen (have to kill NMS.exe with SIGKILL to get rid of that black screen). NVidia driver 418.56

vkEnumerateInstanceExtensionProperties here also.

Can anyone confirm whether this happens on AMD?

@fls2018 @volca02 Same 'vkEnumerateInstanceExtensionProperties' issue on AMD, with a Radeon VII, Mesa 19.0.1 stable from Padoka. Kernel 5.0.10.

Has anyone tried with stock WINE or wine-staging? NMS bug or WINE/proton bug?

Vulkan is broken for all 3 amd vulkan drivers (RADV, AMDVLK and -PRO)

EDIT: tried with a custon proton-tkg 4.5 build

The Vulkan loader shipped with the game doesn't work in Wine. You can use WINEDLLOVERRIDES='vulkan-1=b' to workaround the vkEnumerateInstanceExtensionProperties error.

Now it's back to where it was before the April 29 patch. Does sound like Nvidia users on Windows are still having FPS problems, however.

Now it's back to where it was before the April 29 patch. Does sound like Nvidia users on Windows are still having FPS problems, however.

That's down in Nvidia to take a look at, I did make a thread on the devtalk forums but it sunk with no responses.

I've just tried the new update myself with the override, it seems performance has improved somewhat... still half what it should be but in my experience 25-30 fps more at 1440p than I had before the last update.

This is using Nvidia's latest 430 branch driver (non developer one). I was going to switch back to the 418 dev branch to see if it improved also.

Update:

418.52.05 driver + new update = 5 fps

430.09 driver + new update = 40-50 fps on low at 1080p on a GTX 1070.

Now that I switched to the 430.09 driver, everything's as smooth as silk. Some glitches, but they're the same glitches I've seen elsewhere--for instance with planet rings and atmospheres bleeding through into space stations and the Anomaly. I haven't done any formal benchmarks, but it's about on par with OpenGL for me.

I heard the vulkan renderer was considerably slower then opengl atm, can we get actual compare numbers?

Overriding the game's Vulkan loader makes the game show a copy of the framebuffer and then it hangs. System is responsive though. Using amdgpu

Now that I switched to the 430.09 driver, everything's as smooth as silk. Some glitches, but they're the same glitches I've seen elsewhere--for instance with planet rings and atmospheres bleeding through into space stations and the Anomaly. I haven't done any formal benchmarks, but it's about on par with OpenGL for me.

Can you give more detail i.e. system specs, resolution, settings etc?

Reason being while 430.09 is better I'm still only getting half the performance of OGL or Vulkan on Windows. It's definitely not smooth as silk for me, borderline playable perhaps.

If I have terrain tessellation on, it crashes, though, and I was able to use that with OpenGL. I always turn blur off because of motion sickness.

Nvidia 1050ti, i7-2700K, Slackware 14.2 mulitlib.

So using Mesa this latest experimental branch seems to not work.
Enabling AMDVLK for this does work though.

I can reproduce the crash when enabling tesselation.
EDIT: Crash for me seems to be when vsync is on, not tesselation.

If I have terrain tessellation on, it crashes, though, and I was able to use that with OpenGL. I always turn blur off because of motion sickness.

Nvidia 1050ti, i7-2700K, Slackware 14.2 mulitlib.

Can you do nvidia-smi in terminal while playing? I'm noticing NMS.exe is only using 800 mb of VRAM, maybe there's a weird bottleneck in memory allocation.

Pretty solidly at 1712MB. No more, no less, which is odd. I'd expect that number to move one way or the other while playing. 142MB when not playing anything in use, so 1570MB for NMS.

Pretty solidly at 1712MB. No more, no less, which is odd. I'd expect that number to move one way or the other while playing. 142MB when not playing anything in use, so 1570MB for NMS.

This can't be right surely?

The game is using more system memory than GPU memory on my end, on windows at 1440p it uses quite a few GB on GPU memory.

Confirming, NMS.exe only takes about 1022MiB of GPU memory on my nvidia system (GTX 1080, 430.09) when loading in space station and about 1048MiB when on planet.

And with OpenGL?

Keep in mind allocated memory is not the same as actual used memory. Vulkan may just be getting a significantly lower allocation due to specific vulkan api optimisations (only allocates what it needs). OGL is likely to allocation ALLOT more memory.

And with OpenGL?

Keep in mind allocated memory is not the same as actual used memory. Vulkan may just be getting a significantly lower allocation due to specific vulkan api optimisations (only allocates what it needs). OGL is likely to allocation ALLOT more memory.

On Windows in the same Vulkan experimental it's using 4.2 GB, on Linux it caps at 1.2 GB as above there's only 800 MB for NMS.exe. There's definitely some severe bottleneck somewhere, whether memory allocation is the problem or just the symptom there's definitely an issue.

It also might not be quite Linux specific, I read a post on the NMS Steam discussion forums that a windows user had poor performance until they switched their GPU to a different PCI-e slot (I can't test that because of water cooling). I've also seen people having issues with SLI which triggers the 5 fps issue.

Hello everyone. I had recently switched over to Linux Mint 19.1 at the beginning of the year. My rig is equipped with a Phenom II X6 1090T CPU, 16GB DDR3 RAM, a single Red Devil Vega 64 graphics card, and am dual booting Linux Mint and Windows 10. Linux Mint is using the 4.18 kernel.

On the Linux side, I have installed the latest padoka MESA unstable drivers (unstable was chosen due to its support of Vega cards) along with the latest Vulkan drivers. I had recently tried to launch the experimental build of No Man's Sky in order to take advantage of the Vulkan API, but I have received the same "Unable to initialize Vulkan (vkEnumerateInstanceExtensionProperties failed.) You may not have a Vulkan driver installed, or an old driver on your machine may be corrupted." as @garpu @fls2018 and @volca02 received. I attempted to use the override command shown on this thread to bypass NMS's own Vulkan launcher, but it gave me the same exact error message. I had no choice to revert back to the stable build of NMS in Linux. Are there any other solutions available? Or is this an issue that must be patched in newer updates of the experimental branch of NMS?

On Windows 10, I updated the AMD drivers to Adrenalin 19.4.3, and launched the experimental build of NMS. It launched successfully, and noticed a substantial increase in performance and FPS. There is still stuttering around, but that may be due to my CPU bottle necking. At first, I didn't see any performance increase until I went into the graphics options and increased the default FPS limit 30 up to 90, and disabled V-sync.

Any information would greatly be appreciated.

well atm the opengl build should work better then vulkan anyway. There is a memory cap being applied to the vulkan under Linux and until we figure that out, it will probably have performance issues over ogl option.

Latest 430.14 driver no change.

With the May 14th update, tessellation still crashes (Nvidia drivers 430.14). AFAIK, tessellation is still having issues for Windows users, too.

Proton 4.2-4 states "-Improve Vulkan support for the new No Man's Sky Vulkan build."

What this means is no longer need to use wine overrides to set vulkan to builtin.

I see no difference in performance.

If you're on NVIDIA, be on the 430 series, it's much closer to OpenGL levels now in the Vulkan beta and actually playable again.

I seem to be getting a GPU hang in Vulkan on my RX 580 w/ Mesa 19.1.0-rc2 / LLVM 8.0, as soon as the game is finished loading. Can anybody else confirm?

I haven't tried without Esync but I don't think that will make a difference, as the game works fine on OpenGL.

With the new Proton update, the game started to work fine for me again on RADV. (Mesa 19.0.4 / LLVM 8.0.0) on a Radeon VII

Hello @jerbear64, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report. Also, please add PROTON_LOG=1 %command% to the game's launch options and drag and drop the generated $HOME/steam-$APPID.log into the comment box.

https://gist.github.com/jerbear64/ce4c393c02d467790dbb65e9f115a780

I captured a Proton log last night. This goes up to the GPU hang, so the game was abruptly closed as a result.
steam-275850.log

@jerbear64, if it's not too much hassle, you could try a workaround at https://bugs.freedesktop.org/show_bug.cgi?id=110471#c1.

Not a problem, I already maintain my own Mesa COPR on Fedora. I can apply the workaround tonight and report back.

-------- Original Message --------
On May 15, 2019, 8:56 AM, kisak-valve wrote:

@jerbear64, if it's not too much hassle, you could try a workaround at https://bugs.freedesktop.org/show_bug.cgi?id=110471#c1.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Hello everyone!

The most recent experimental branch update of No man's sky actually allowed nms to launch using Vulkan on Linux Mint 19.1 without using the special command workaround. The game managed to load and I was able to move around... For a short time.

However, the game froze the graphics on both my primary screen and my secondary screen (secondary monitor had my web browser up) after looking around the area where I last saved, even though the sound was still coming from the game. I was unable to get any response from the game nor the pc, and thus had to do a hard reset of my rig.

A step in the right direction for sure, but I froze after a short while of looking around. I switched back to the stable build once more.

Workaround had no effect. Still hangs right after the loading screen.

@TarsusEndri Sounds like a GPU hang, and similar to my symptoms. What's your GPU / driver?

@jerbear64

My gpu is a Powercolor Red Devil RX Vega 64 using the latest MESA-Padoka Unstable drivers (according to the Padoka page, Unstable drivers are needed for use with Vega series cards). Latest Vulkan drivers were also installed.

And that new shader precaching crap that just got added to steam just reduced performance even more...

I won't be trying out vulkan for this game until its out of beta and is final version. Also try deleting your cache files for dxvk and proton

Just for the record, nvidia driver 418.52.07 does not seem to include the fix for the low FPS, it's single-digit FPS on this version of the driver (only 430.* seem to include the improvement).

Just for the record, nvidia driver 418.52.07 does not seem to include the fix for the low FPS, it's single-digit FPS on this version of the driver (only 430.* seem to include the improvement).

I suspected as much, the new Vulkan dev driver is nothing more than the same old branch with a couple of extra extensions. Also as mentioned even 430 while better still needs improvements as there's a memory issue with it.

@jerbear64 My GPU also crashes with Mesa 19.1rc4 (LLVM8) and 19.2-git (LLVM9) on the Vulkan experimental branch, while mesa 19.0.x (LLVM8) works fine. AMDGPU / 290X / Arch Linux rolling.

I can generally replicate the crash though. For me it seems to be when I try to jetpack in to my biodome full of plants. However, confusingly, if I go outside and jetpack on to the outside of the biodome and look in, it doesn't crash. So possibly when inside the glass cuboid that leads to the biodome a shadow or light shader(?) is doing something odd.

I have no DXVK logs or anything. I was only trying mesa 19.1 and 19.2 because VirtualBox has visual corruption on mesa 19.0.5 so thought I'd rather try going newer than older... I'm just throwing my "me too" in to the ring.

Maybe a similar vulkan bug? https://github.com/doitsujin/dxvk/issues/1056

There are no DXVK logs because it's not a DX game. At least it isn't just me, though.

-------- Original Message --------
On Jun 1, 2019, 12:24 PM, HanFox wrote:

@jerbear64 My GPU also crashes with Mesa 19.1rc4 (LLVM8) and 19.2-git (LLVM9) on the Vulkan experimental branch, while mesa 19.0.x (LLVM8) works fine. AMDGPU / 290X / Arch Linux rolling.

I can generally replicate the crash though. For me it seems to be when I try to jetpack in to my biodome full of plants. However, confusingly, if I go outside and jetpack on to the outside of the biodome and look in, it doesn't crash. So possibly when inside the glass cuboid that leads to the biodome a shadow or light shader(?) is doing something odd.

I have no DXVK logs or anything. I was only trying mesa 19.1 and 19.2 because VirtualBox has visual corruption on mesa 19.0.5 so thought I'd rather try going newer than older... I'm just throwing my "me too" in to the ring.

Maybe related? doitsujin/dxvk#1056

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Also having the crashing on load problem with the Vulkan version. 980Ti crashing during the loading scene with:
wine_vkCreateCommandPool Support for allocation callbacks not implemented yet, which I believe is the error code.

Running 418.52.10 driver on 5.1.12-arch1-1-ARCH

steam-275850.log

My RX 480 gets a similar colorful screen then hang and "failed to initialize parser -125" error in dmesg on the experimental branch. OpenGL is slow but works. I am using AMDGPU (Mesa?) 19.1.1 with LLVM 8.0.0.

Interestingly, if you create a brand new save -- not loading an old one -- the game won't crash until the little cutscene intro is over.

My RX 480 gets a similar colorful screen then hang and "failed to initialize parser -125" error in dmesg on the experimental branch. OpenGL is slow but works. I am using AMDGPU (Mesa?) 19.1.1 with LLVM 8.0.0.

Interestingly, if you create a brand new save -- not loading an old one -- the game won't crash until the little cutscene intro is over.

Could you generate a PROTON_LOG=1 with a new save & vulkan?

Cheers

NOTE: First attempt to load did ctd after the starfield travel intro, but loading up second time worked fine, possible hickup in shader cache generation.

Here is my steamplay log on manjaro xfce 1080TI, seems to work but there may be serious performance issues. Gotta test settings more.

steam-275850.log

How do you switch back to opengl? or does that require a redownload to other non exp version? seems odd if so.

### OK TESTING DONE

Vulkan FPS: ~15-30 fps
OpenGL FPS: ~50-60+ fps

Yep Vulkan borked in this game, this is quite extraordinary since other games that use vulkan often get 1:1 or above parity under Linux and Steamplay (doom/wolf....). No idea whats going on, quite puzzling!

@jarrard be sure to try driver 430.x if you haven't already. 430.34 seems to fix my problems with vulkan performance, more or less (there still are sometimes lower framerate situations on planet surface, though).

I'm using 430.26 atm, will look into getting newer ones sometime.

Can anyone manage to get the game to launch with Proton 4.11? I'm finding it crashes/hangs immediately, 4.2-9 still works. Tried fsync off to see if that was the culprit made on difference.

steam-275850.log

I'm able to launch the game with 4.11, using the opengl client however since vulkan has a few issues.

Here's my log. Wish I had VR to play with this game.

steam-275850.log

I found the problem, I had the 418 dev driver installed which usually does launch (but with the 5fps bug) but with 4.11 it hangs.

430 works with 4.11 providing fsync is not used.

Also another thing everyone should note is the Vulkan renderer becomes the main one in a little under two weeks, I'm guessing OpenGL will most likely be binned unless they keep it to support older systems which I doubt.

That's why it's important issues with it get resolved rather than be content with the OGL renderer.

If it's becoming the main renderer you can expect a hell of a lot of updates/fixes for it. Hopefully that'll make it run a little smoother, as I could never get the Vulkan branch to load.

For me the game doesnt even launch on 4.11 but does work totally ok on 4.2-9

@Haxk20 are you using the fsync kernel? if so, try disabling fsync or esync before launching the game.

Will try to do so. Yes compiled 5.3-rc2 with fsycn

Sadly enough disabled fsync and esync but still fails to launch.

And this happens on both openGL and Vulkan.

IDK what just happened but i was trying to kill NMS.exe process since steam was telling me its running but nothing showed up for minutes and i clicked kill the process killed explorer.exe and it just showed up with NMS.exe still running
EDIT: This was just 4.2-9 launching after i changed it. It just took longer to regenrate. 4.11 is still broken.

Seems like 4.11-2 broke it -1 working when using custom build

Just a heads up:

Vulkan build is going live at any time, looking at the patch notes as suspected OpenGL HAS BEEN REMOVED ENTIRELY.

So there is literally no avoiding vulkan now, just hoping they've done some optimizations to their engine so that it works better with the linux drivers although chances are it performs much the same as the experimental.

For anyone on AMD that GPU hangs on the Vulkan branch, if you install ACO the game will function, although it doesn't render 100% accurately. I'll fill out a bug report once Beyond is out as that might change this.

-------- Original Message --------
On Aug 14, 2019, 6:58 AM, fls2018 wrote:

Just a heads up:

Vulkan build is going live at any time, looking at the patch notes as suspected OpenGL HAS BEEN REMOVED ENTIRELY.

So there is literally no avoiding vulkan now, just hoping they've done some optimizations to their engine so that it works better with the linux drivers although chances are it performs much the same as the experimental.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I'm in Australia so we don't get the patch until very last. Last time I tried that vulkan branch, it had major performance issues with nvidia 1080TI.

Nvidia 430 Driver seems to crash as well.
Pop!_OS 19.04
GTX 1070.

Beyond either crashes before loading the menus, or after selecting a save. It seems like Vulkan is the only renderer available.

Right I've managed to get into game, there were a few hangs/crashes at first loading but everything is still the same at least on Nvidia 435.17... low fps still.

Graphics settings have changed somewhat so hard to directly compare but VRAM usage is still low, just about playable on standard settings (lowest) on a 1070.

Think someone from nvidia need to be pinged to take a look at this now it's out.

Loads fine for me, no issues there.

However, the performance is absolutely terrible on my 980ti with Proton 4.9 and 4.11 both tested.

I'll test on my 580, with and without ACO, when I get home from work. Would be interesting to see if the FPS drop is Nvidia specific. I remember some people with Nvidia were saying they had poor performance on the old experimental Vulkan branch as well.
-------- Original Message --------
On Aug 14, 2019, 2:43 PM, Liam Dawe wrote:

Loads fine for me, no issues there.

However, the performance is absolutely terrible on my 980ti with Proton 4.9 and 4.11 both tested.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Running pretty decently for me on a 1050ti with 435.17. It doesn't connect to the online servers, but I've got mulitplayer disabled.

Crash before load menu on Kubuntu 19.04 , 1070 with 430.40 and proton 4.11-2
On Lutris say "vkEnumerateInstanceExtensionProperties failed"
steam-275850.log

Crashes after around 15 seconds of loading a new game for me. Proton 4.11-2.
Steam System Info
steam-275850.log

Crashes right after loading a new or an existing game. Proton 4.11-2, RX 480 with latest stable Mesa.
steam-275850.log

Those on Nvidia, I created an issue on Nvidia's devtalk forums about the performance months ago but it hasn't had any responses. It would be great if others can report the issue there to try and keep this on their radar at least:

https://devtalk.nvidia.com/default/topic/1050274/linux/no-mans-sky-proton-vulkan-patch-performance-issues-with-nvidia/

As for the crashing, keep in mind every platform (including consoles) is experiencing crashes especially at the nexus. It might be hard to isolate what crashes are down to proton/linux drivers or game bugs.

@fls2018 perhaps you should update the original submisison to show that you no longer have to manually select the vulkan branch? And the title while you're at it, this is just a performance issue with the regular game now.

430.34-54 performance is terrible with Beyond update - on GTX 1080 at ultrawide resolution 2560x1080 I have 20-30 FPS while in inventory or on foot.

418.52.20 I can't even get No Man's Sky to load past the 'Preparing to launch' window. It appears as if the prefix isn't even being updated. With Proton 4.11-2 & Proton-tkg 4.13.r7.gca09e891

This is everything that is in the PROTON_LOG (steam-275850.log)
======================
Proton: 1565123138 proton-4.11-2
SteamGameId: 275850
Command: ["/home/telans/.local/share/Steam/steamapps/common/No Man's Sky/Binaries/NMS.exe"]
Options: set()
======================

418.52.20 I can't even get No Man's Sky to load past the 'Preparing to launch' window. It appears as if the prefix isn't even being updated. With Proton 4.11-2 & Proton-tkg 4.13.r7.gca09e891

For some reason the 418 dev branch doesn't launch NMS anymore with Proton 4.11, you can launch proton 4.2 with them but you'd only get 5 fps.

430 & later are absolutely required for any game play.

I've recently installed this game, after I create a new game it shows the intro, and goes "into the galaxy" for 10-20 seconds and then crash.
steam-275850.log

Has anybody tried the VR mode? I just tried it on my Index but it instantly crashes. I do see a black screen on my monitor for a little bit, but that goes away after a split second.

Yeah it works on 430.34 Nvidia Drivers for me with my 1080TI at 4k, but the FPS is significantly worse then when it was running OpenGL where on the type of semi barren planet I'm on I'd easily get over 60fps, but with Vulkan I'm getting dips down to what must be 10-20fps and rarely see 60fps unless I'm looking directly down/up.

Bit disappointing, must be something real wrong going on for Vulkan to perform this badly!

NOTE for those getting quit to desktop at menu, don't hover over the menu options, holding down to get rid of update message will also click background menu selections (if you hover on them) and cause a problem.

I can also report very poor performance with the new "Beyond" update. In the past, I was able to play very well with the OpenGL renderer, but now that's been removed in favor of Vulkan, the FPS are too low to play.

Proton: 4.12-2
Nvidia Driver: 430.34
GPU: Nvidia RTX 2070

If I were to guess, the poor performance nearly everyone sees could be due to the seemingly abstract 1GB video memory limit that happens with NMS

Could you test this @rstrube with nvidia-smi?

VRAM usage for me is as following,yes it does seem low considering Im on high settings at 4k.

C+G ...ps\common\No Man's Sky\Binaries\NMS.exe 1375-1408MiB

Then again, planet is nothing spectacular, and I have no opengl reference. (OGL probably handles memory and caching differently, so it may not be apples to apples comparison).

Here's the nvidia-smi output.

nvidia-smi
Wed Aug 14 18:32:47 2019       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 430.34       Driver Version: 430.34       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce RTX 2070    Off  | 00000000:06:00.0  On |                  N/A |
| 41%   50C    P0    73W / 185W |   1494MiB /  7982MiB |     93%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      1407      G   /usr/lib/xorg/Xorg                            39MiB |
|    0      1965      G   /usr/lib/xorg/Xorg                           200MiB |
|    0      2112      G   /usr/bin/gnome-shell                         252MiB |
|    0     27233      G   ...m/debian-installation/ubuntu12_32/steam    31MiB |
|    0     27257      G   ./steamwebhelper                               3MiB |
|    0     29820    C+G   ...ps\common\No Man's Sky\Binaries\NMS.exe   906MiB |
+-----------------------------------------------------------------------------+

Here's a video showing memory usage with open-gl/vulkan on Windows: https://youtu.be/XEC1mEsZ2lU?t=30

Especially since that's only 1080p, 1.3GB for 4k seems extremely low. Peraps the low performance is due to the game swapping out textures very often when VRAM is low?

I dunno, the low performance is persistent not something that happens only when moving.

Can anybody else confirm that the 435.17 beta driver solves the poor Vulkan performance problem?

is there a ubuntu ppa with that driver somewhere? only way I would test it. Its in none of my package managers. (one of the things I miss about ARCH AUR)

Oh found them.

https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa

Cool, I was about to post that exact link. It's nice that the PPA already has the latest beta drivers in place.

Unfortunately the 435 driver is not showing in my package list, seems it can't see it on the PPA.. unknown why.

Unfortunately the 435 driver is not showing in my package list, seems it can't see it on the PPA.. unknown why.

Interesting, you should just be able to do a sudo apt install nvidia-driver-435. Do you see that the PPA is checked if you do a sudo apt update?

I'm not seeing Nvidia-435 either, the latest available is Nvidia-430

Strange, it's definitely in the PPA, perhaps it's behind some sort of testing flag?

See here:
https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+packages?field.name_filter=435&field.status_filter=published&field.series_filter=

Edit: Oh shit, it's for 19.10 (Eoan) my bad...

Somebody on the nvidia developer forums posted that 435.17 didn't fix the performance problems. I had high hopes that the latest beta driver would improve things...

https://devtalk.nvidia.com/default/topic/1050274/linux/no-mans-sky-proton-vulkan-patch-performance-issues-with-nvidia/post/5373548/#5373548

I think the main issue is that the game won't even start under most circumstances. It's an issue with Proton AFAIK.

I just installed 435.17 on Arch, and I can get into the game now (couldn't with 418) but no matter if I disable f-sync (always breaks) or e-sync (makes no difference) it crashes before a world generates. Tested creating a new save/loading an old one.

Just to note this is the exact same issue I was having a month or two ago with the 430 drivers and the vulkan-experimental branch.

I think the main issue is that the game won't even start under most circumstances. It's an issue with Proton AFAIK.

Mine will start every time, but performance is unplayable.

it crashes before a world generates.

Be sure to delete your old SHADERCACHE files just to be sure. And make sure it isn't loading mods.

Clean install, with & without prebuilt shadercache, same result. Not sure how it can even be played at all now that open-gl is gone.

steam-275850.log

Not sure how I can even play at all now that open-gl is gone

Well you can't, but to be honest none of us are going to be playing at 10-20fps, unless you like that sort of thing (laptop users).

What I would suggest is just post your proton log for the time being.

Actually on the topic of being able to revert to Open-GL, it might be possible to manually download the old No Man's Sky binaries & etc through Steam Console.

Here are the manifest lists for NMS: https://steamdb.info/depot/275851/manifests/

I'll give it a try and see how it goes.

I seem to be able to get into the game by running with Proton 4.2-9, on Nvidia 430.40
It crashed when I tried to enter another planet's atmosphere, though I haven't yet retested.
Don't have a log for it, sorry. Forgot to enable it. I'll update this comment if I get the crash on 4.2-9 again.

I'll give it a try and see how it goes.

My guess is that you will need to revert to previous game version and content. IE. No Beyond.

I kinda only wanted to play due the beyond update.

That's what I was getting at, but yeah it's a shame Beyond does not appear to work.

A Week 1 patch might help, as windows users are experiencing in-game crashes, which might be related.

another nvidia user with the 1.5gb usage bug. i know the opengl version used almost all my video memory. was crashing at ultra settings which i was able to run before the update. dropping down the high stopped the immediate crashing but frames are definitely way down.

After the latest micro update (30.7 MB) a few minutes ago, the game appears to run great. It was showing a black screen while the music played before this latest update. I'm getting 60 fps.

Also I forgot, using Proton's Vulkan loader.

System:
Ryzen 5 1600
RX 580 8 Gb

Ubuntu Budgie 19.04
RADV/ACO/LLVM 8
Proton 4.11-2
Vulkan 1.1.101.0-2

What's your vram usage? However, I don't see an update

I received the beyond update almost 24hrs after other people got it. There is a delay system with steams update process, probably related to region. I'm Australian, 3rd rate steam citizen :(

What's your vram usage? However, I don't see an update

I have 4587 MB free VRAM, so 3605 MB used

AMD cards don't seem to have the low VRAM usage issue.

I am also using the experimental beta (Current Content BuildID: 4107029)

Still crashes loading a world with the experimental/30mb update

Running into a fun issue with RADV/ACO on my Radeon VII: the game loads in fine, if glacially slow.. then all terrain is completely missing. Game works fine, plays fine, rocks, plants, ships and buildings are visible. I did verify the game files. Lowering tesselation did not help. Older Proton versions don't start at all.

Nevermind! Same issue on Windows..... :man_shrugging:

edit: Though I do get the same issue as the user below me!

I'm able to run this game with the Beyond update perfectly with Proton 4.2 as well as 4.11.1.
What does not work however is if I try to get it running in VR. It just launches a black window and "loads" eternally. "loads" because IO is exactly zero and the process is a zombie...
If I disable esync then the process doesn't go zombie but instead has about 2-3% CPU load, and does nothing with IO either, and again just a black screen. Trying to use PROTON_LOG=1 doesn't do anything, there does not appear to be any log generated.
Trying VR to start with Proton 4.2 just starts the desktop version, probably because it still has with the old openvr lib.
Edit: should probably mention I'm on Mesa 19.2 ACO

Not working well for me on Radeon Vega 56 + Proton 4.11-2 + RADV/Mesa 19.1.4. Crashes to desktop as soon as the world loads.

I get a little more progress on Mesa 19.2 ACO. The world loads and I get fairly decent performance, but if I open a menu my graphics card hard locks.

Ok it now did generate a log for VR. It got like 60MiB big after not even two minutes... I have uploaded "only" a hundred thousand lines of that so github won't cancel the upload due to it taking too long: https://gist.github.com/Zamundaaa/c4bcc723bcb85f41daf178e1cfdedcf8
Edit: here's a log from a normal (2D) launch: steam-275850.log

with the 30mb update on experimental the 1.5gb memory limit might have gone away. running graphics on medium causes it to go up to 1.9gb video memory usage rougly. running on high loads into the world but the crashes immediately. running graphics on ultra causes crash on loading start system screen.

with the 30mb update on experimental the 1.5gb memory limit might have gone away. running graphics on experimental causes it to go up to 1.9gb video memory usage rougly. running on high loads into the world but the crashes immediately. running graphics on ultra causes crash on loading start system screen.

I managed to load the game with medium settings as well but my VRAM usage was still only around 600mb on a 1080ti.

Games run on mix of enchanced and high settings on 45fps on RX560X which is impressive but the UI renders at 7fps and makes the game basically unplayable.

Games run on mix of enchanced and high settings on 45fps on RX560X which is impressive but the UI renders at 7fps and makes the game basically unplayable.

same. and getting about 35fps on a gtx 1060 6gb. it seems terrain tessellation on anything higher than enchanced caused the game to crash when entering a planet. so far no random crashes but ive only played 45 minutes with these settings. hopfully a new release of proton/nms brings performace back to where it was with opengl.

Seems my game is running ok for me now on my 430.17 drivers / 1080TI, at 4k I get somewhere around 45-50fps which is similar to what opengl gave me. Just matter of enabling 1800p edid now to see if I can tweak things.

I believe it might have been the recent experimental patch that resolved something? not sure exactly. I did switch to Proton 4.2 ran it, noticed it was ok, then switched back to normal 4.11-2

Hmm come to think of it, flying and such is still pretty poor performance, I guess this will probably take several more patches before its decent framerates.

Is your GPU memory usage any better while having the better performance?

Seems my game is running ok for me now on my 430.17 drivers / 1080TI, at 4k I get somewhere around 45-50fps which is similar to what opengl gave me. Just matter of enabling 1800p edid now to see if I can tweak things.

I believe it might have been the recent experimental patch that resolved something? not sure exactly. I did switch to Proton 4.2 ran it, noticed it was ok, then switched back to normal 4.11-2

Hmm come to think of it, flying and such is still pretty poor performance, I guess this will probably take several more patches before its decent framerates.

I'm using 435.17 and already tried the experimental patch and still seeing the same low fps.

Is your GPU memory usage any better while having the better performance?

I'll check sometime later. But honestly it was only better on ground then before, as soon as I took off in my ship I got the 20-30fps issue happening, even in space a bit also. So it still needs some work.

I had 70 FPS in nexus just now, only to have 30 as soon as I hopped in the ship and launched. That is with the current 2.06b patch. Memory usage was still around 900 Mb, so it seems the nexus fit well enough in that limited memory to render fast.

On experimental it now crashes if started for VR. A black window appears shortly and then closes again. The log is short this time. I am sure that that's indeed a Proton issue, and not a problem with NMS, as noone on Windows seems to have this problem. Can't check on my own Windows install though because it's broken...
The log is a lot shorter this time.
steam-275850.log

On experimental it now crashes if started for VR. A black window appears shortly and then closes again.

Also experiencing the same issue as @Zamundaaa using the public branch (tested with Valve Index Headset):

steam-275850.log

System Information

• GPU: RTX 2060
• Driver/LLVM version: NVIDIA 430.40
• Kernel version: 5.0.0-25-generic
• Link to full system information report as Gist
• Proton version: 4.11-2
• SteamVR version: 1.7.5

Game runs flawlessly on 435.17 (1060 6GB) on arch with KDE and Kwin-lowlatency. Slight stuttering issue when loading (which isn't present on windows) but other than that works great. I don't have the 30fps issue when in space.

Game is using 2.1GB of VRam. Kernel is 5.2.8.arch-1-1. I'm using GE-Proton-4.11-1, if that changes anything on that end. I'm on high settings for everything but textures which sets itself to standard if I go higher than enhanced. Experimental branch.

THIS IS A PROTON BUG, NOT AN NVIDIA BUG
I can confirm the issue is with Proton specifically, as Glorious Eggroll's patch fixes the issue, while the game runs terrible on stock proton. Using GE's proton fork fixes it.

I'll give this a test now.

UPDATE:
Nope still VRAM doesn't budge past 1247MB usage for NMS, this is at 4k and with highish settings.
Moving around on planet is probably somewhere between 30-40fps while flying is easily below 30fps, the performance problem still exists. At least for 1080TI cards on 430.34 driver, It may well be a complexed multitude of issues combining together.

Maybe vulkan performance is just crap for this game, I'm going to need to boot into windows10 to test!

PS. I have yet to experience any of the crashes others are facing, that could be mostly a AMD issue, (running Ryzen3600 with clearcpuid=514 here)

THIS IS A PROTON BUG, NOT AN NVIDIA BUG
I can confirm the issue is with Proton specifically, as Glorious Eggroll's patch fixes the issue, while the game runs terrible on stock proton. Using GE's proton fork fixes it.

This is system specific I believe, not Proton related.

I am using the following:
Kernel: 5.2.8-20-tkg-pds
Nvidia: 435.17; 980Ti
Proton-tkg: 4.14 (all GE patches + more)
Resolution: 1080p

To get the game to load a world where it wouldn't before, I had to delete .steam/steam/steamapps/common/No Man's Sky/Binaries/SETTINGS/TKGRAPHICSSETTINGS.MXML

I have now set all graphics options to high/ultra except for tesselation which remains on Enhanced.
This is my VRAM usage: C+G ...ps\common\No Man's Sky\Binaries\NMS.exe 1191MiB.

No matter where I went in the world/space, it never climbed over 1260MiB. This is odd, because when all graphics options are set to Low (after restart), changing all the options to Ultra (before needed restart to apply texture settings) I saw my VRAM usage go up to ~1600MiB.

It appears applying graphics settings mid-game uses more VRAM than a clean start with my current settings (Ultra textures).

My performance is worse than Open-GL, 35-40fps constant no matter what settings I use.

Perhaps someone else could test this? Apply Low settings, restart, check VRAM, then apply Ultra and see if the VRAM climbs.

1080ti 430.34 Pop_OS Plasma5
Win10 4k High settings
Land: 85 Space: 100+

Linux 4k High settings (Proton-GE)
Land: 25-33 Space: 33

Yeah real sad days for NMS under Linux.
We should be seeing 1:1 or better performance then compared to windows because nvidia's vulkan driver is meant to be the same or better (more updates and fixes), this is why games like Doom and Wolf run great under Linux.

Hmm, strange. TKG said it worked for him as well, and changing it to proton 4.11-2 did the same thing everyone here is describing.

If your running at 1080p it does perform best, but that doesn't mean it's a fix.
Also I deleted my compatdata before testing with proton-GE, just to be sure. (I did not build my own Proton-GE, just used the bin release)

Unfortunately I'm still having the same performance issues with Proton-GE. I've tried completely deleting and rebuilding my prefix as well. Currently running Nvidia 430.34 drivers, so perhaps the 435.17 beta drivers fix the issue in conjunction with Proton-GE?

Unfortunately I'm still having the same performance issues with Proton-GE. I've tried completely deleting and rebuilding my prefix as well. Currently running Nvidia 430.34 drivers, so perhaps the 435.17 beta drivers fix the issue in conjunction with Proton-GE?

Nope, tried GE as well as TKG protons with 435.17 and it's the same.

One difference I did notice with third party protons though is a lot more texture popping & trees weren't rendering leaves even on higher settings... although performance was still the same.

The VRAM issue seems to be specific to Valve's vanilla Proton builds (I tried 4.11-2 and 4.2-9), as Wine-staging (tested using 4.13) and GE patched Proton (according to comments here) work fine in that regard.

The overall performance otherwise is spotty and is probably more system- or driver-specific. But the VRAM issue specifically appears to be vanilla Proton at fault.

The VRAM issue seems to be specific to Valve's vanilla Proton builds (I tried 4.11-2 and 4.2-9), as Wine-staging (tested using 4.13) and GE patched Proton (according to comments here) work fine in that regard.

The overall performance otherwise is spotty and is probably more system- or driver-specific. But the VRAM issue specifically appears to be vanilla Proton at fault.

As shown by multiple people in this thread, including me, this is false. Vanilla Proton is not the cause.

The VRAM issue seems to be specific to Valve's vanilla Proton builds (I tried 4.11-2 and 4.2-9), as Wine-staging (tested using 4.13) and GE patched Proton (according to comments here) work fine in that regard.

I'm not seeing that with third party builds, on Ultra settings at 1440p this game should be eating beyond 4GB like it does in windows. The most I've been able to get it to is around 1.5GB and that's after changing location a number of times.

For anyone on arch, try doing a full system update and check if the game runs properly.
Also, make sure you're on experimental branch

For me the game runs just OK for few days now. On arch Linux using GE
proton and RX560X. Enchanced-High on 40 fps on planet.

On Sat, Aug 17, 2019, 3:27 PM william341 notifications@github.com wrote:

For anyone on arch, try doing a full system update and check if the game
runs properly.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/438?email_source=notifications&email_token=AD7WP7RDZETIXNNIAVRQY4TQE74C7A5CNFSM4FRPXRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QLDTQ#issuecomment-522236366,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD7WP7S373XLFB5F2DWY5RTQE74C7ANCNFSM4FRPXRRA
.

Yes there is a crash bug with AMD cards where if tessellation is set above low it will crash on load up or something. (protondb).

AMD users compare to how it runs under Windows? is 40fps that same as windows?

Haven't tried windows for obvious reasons and I'm not planing on trying it.
When somebody has Acer nitro 5 with RX560X and windows they can try to see
what FPS they get but I think they get slightly more fps maybe.

On Sat, Aug 17, 2019, 3:50 PM jarrard notifications@github.com wrote:

Yes there is a crash bug with AMD cards where if tessellation is set above
low it will crash on load up or something. (protondb).

AMD users compare to how it runs under Windows? is 40fps that same as
windows?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/438?email_source=notifications&email_token=AD7WP7UB3GPWL7Y3XTJKTCTQE76ZFA5CNFSM4FRPXRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QLWBY#issuecomment-522238727,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD7WP7T77ZBGIEOQYE6OKXDQE76ZFANCNFSM4FRPXRRA
.

And the tessellation but is impossible for me to reproduce. I can have
tessellation on enchanced and it loads OK but will check again when I come
home.

On Sat, Aug 17, 2019, 3:58 PM No Name asasin7229@gmail.com wrote:

Haven't tried windows for obvious reasons and I'm not planing on trying
it. When somebody has Acer nitro 5 with RX560X and windows they can try to
see what FPS they get but I think they get slightly more fps maybe.

On Sat, Aug 17, 2019, 3:50 PM jarrard notifications@github.com wrote:

Yes there is a crash bug with AMD cards where if tessellation is set
above low it will crash on load up or something. (protondb).

AMD users compare to how it runs under Windows? is 40fps that same as
windows?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/438?email_source=notifications&email_token=AD7WP7UB3GPWL7Y3XTJKTCTQE76ZFA5CNFSM4FRPXRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QLWBY#issuecomment-522238727,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD7WP7T77ZBGIEOQYE6OKXDQE76ZFANCNFSM4FRPXRRA
.

Someone said above that 560 performance is expected to be 40fps.

Well this is laptop and settings are surely different so if somebody can
try it on RX560 that would be great. I will post SC of graphics settings
when I get home.

On Sat, Aug 17, 2019, 4:07 PM william341 notifications@github.com wrote:

Someone said above is that 560 performence is expected to be 40fps.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/438?email_source=notifications&email_token=AD7WP7W5J4CSUFPLFLHVZHTQFAA33A5CNFSM4FRPXRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QMDQA#issuecomment-522240448,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD7WP7SJBVYKH2SJQWKVKLDQFAA33ANCNFSM4FRPXRRA
.

After latest game update I'm experiencing heavy FPS drop in all game menus. It is like ~5fps when opening inventory, in dialogs or even game setting menu. Does anyone have this issue or solution?

Yes I did. Use GE build of proton. That fixed it for me

On Sat, Aug 17, 2019, 5:14 PM alsh notifications@github.com wrote:

After latest game update I'm experiencing heavy FPS drop in all game
menus. It is like ~5fps when opening inventory, in dialogs or even game
setting menu. Does anyone have this issue or solution?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/438?email_source=notifications&email_token=AD7WP7QG2WKGZCJKSROBUC3QFAIU5A5CNFSM4FRPXRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QNO4Y#issuecomment-522246003,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD7WP7S7A7JBS2ZNRRN5PKTQFAIU5ANCNFSM4FRPXRRA
.

Tried that but GE build didn't help me either.

Yes I did. Use GE build of proton. That fixed it for me
…
On Sat, Aug 17, 2019, 5:14 PM alsh @.*> wrote: After latest game update I'm experiencing heavy FPS drop in all game menus. It is like ~5fps when opening inventory, in dialogs or even game setting menu. Does anyone have this issue or solution? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#438?email_source=notifications&email_token=AD7WP7QG2WKGZCJKSROBUC3QFAIU5A5CNFSM4FRPXRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QNO4Y#issuecomment-522246003>, or mute the thread https://github.com/notifications/unsubscribe-auth/AD7WP7S7A7JBS2ZNRRN5PKTQFAIU5ANCNFSM4FRPXRRA .

@jarrard I don't have that bug with my rx 580. It was all on High by default, terrain tesselation, too, and it works without a problem. The only thing I have noticed now is that it has hung for a few seconds twice in an hour of playing, but that's probably just one of the few bugs NMS still has right now.

In order to be able to start the game after the Beyond-Update, the value in the game settings for "TerrainTesselation" must be set to "Low". Maybe the solution only works for AMD GPUs.

The setting must be made in the file _TKGRAPHICSSETTINGS.MXML_. This is located in the folder _~/steam/steamapps/common/No Man's Sky/Binaries/SETTINGS/._

If you open the file with an editor you will find the following line:
_Property name="TerrainTessellation" value="TkGraphicsDetailTypes.xml"_

The next line after that is:
_Property name="GraphicDetail" value="High" /_

In this line replace the "High" with a "Low". After that I could at least load my existing save games again. Before I had a crash to desktop after loading the game in the moment where the game starts.

My system:
'AMD Ryzen 5 1600X
AMD Radeon rx580 8GB
16 GB DDR4
Linux MInt 19.2 (Tina) Cinnamon
Padoka Stable PPA (Mesa)
Kernel 5.2.7
Proton 4.11-2

It seems like on my setup that I can only hit 2GB vram.

I get a little more progress on Mesa 19.2 ACO. The world loads and I get fairly decent performance, but if I open a menu my graphics card hard locks.

For issues regarding the radv/ACO driver, please report here https://github.com/daniel-schuermann/mesa/issues/112

Instead of set the Tesselation-Details to "Low" in the local settings i purged the Padoka PPA and installed the ACO-Mesa-Driver from Valve. With this the game runs like a charme. With "High" even in Tesselation. https://steamcommunity.com/app/221410/discussions/0/1640915206474070669/

I can't seem to set the Tesselation-Details vlaue to low. Any manual changes I make to TKGraphicsSettings.xml is replaced with the following;

<Property name="GraphicsDetail" value="TkGraphicsDetailPreset.xml">
        <Property name="TextureQuality" value="TkGraphicsDetailTypes.xml" />
        <Property name="AnimationQuality" value="TkGraphicsDetailTypes.xml" />
        <Property name="ShadowQuality" value="TkGraphicsDetailTypes.xml" />
        <Property name="PostProcessingEffects" value="TkGraphicsDetailTypes.xml" />
        <Property name="VolumetricsQuality" value="TkGraphicsDetailTypes.xml" />
        <Property name="TerrainTessellation" value="TkGraphicsDetailTypes.xml" />
        <Property name="PlanetQuality" value="TkGraphicsDetailTypes.xml" />
        <Property name="BaseQuality" value="TkGraphicsDetailTypes.xml" />
        <Property name="AmbientOcclusion" value="HBAO_Low" />
        <Property name="AnisotropyLevel" value="2" />
        <Property name="AntiAliasing" value="TAA_LOW" />
    </Property>

With any proton and mesa (amdgpu on rx570) I get a crash to desktop 5 seconds after loading into a world or starting a new game.

I can't seem to set the Tesselation-Details vlaue to low. Any manual changes I make to TKGraphicsSettings.xml is replaced with the following;

<Property name="GraphicsDetail" value="TkGraphicsDetailPreset.xml"> <Property name="TextureQuality" value="TkGraphicsDetailTypes.xml" /> <Property name="AnimationQuality" value="TkGraphicsDetailTypes.xml" /> <Property name="ShadowQuality" value="TkGraphicsDetailTypes.xml" /> <Property name="PostProcessingEffects" value="TkGraphicsDetailTypes.xml" /> <Property name="VolumetricsQuality" value="TkGraphicsDetailTypes.xml" /> <Property name="TerrainTessellation" value="TkGraphicsDetailTypes.xml" /> <Property name="PlanetQuality" value="TkGraphicsDetailTypes.xml" /> <Property name="BaseQuality" value="TkGraphicsDetailTypes.xml" /> <Property name="AmbientOcclusion" value="HBAO_Low" /> <Property name="AnisotropyLevel" value="2" /> <Property name="AntiAliasing" value="TAA_LOW" /> </Property>

With any proton and mesa (amdgpu on rx570) I get a crash to desktop 5 seconds after loading into a world or starting a new game.

Looks a little weird. Here my corresponding part. In your file some lines are missing:

>
But i would emphasis to use the ACO Driver from Valve. With this I was able to play without setting Tesselation to Low.

The problem is my file is freshly created and the game doesn't let you get into the options to set (and create) the missing entries until you're in a world. There's no options in the main menu.

@mongrol: you can add these properties to your config file, the game should use it.

Edit: my bad, after a backlog I see that your config file is replaced when you init a new game. Maybe you can take a save, like this one: http://gtrainers.com/load/categories/savegames/no_man_39_s_sky_savegame_galactic_center_codex/30-1-0-1441
Then change the graphics from there, and start a new game.

Managed to get some renderdoc captures: https://drive.google.com/file/d/1Q0RUQaWi4L9ZKzZBgjrm3Nx6hAVVnmEW/view

Not working well for me on Radeon Vega 56 + Proton 4.11-2 + RADV/Mesa 19.1.4. Crashes to desktop as soon as the world loads.

I get a little more progress on Mesa 19.2 ACO. The world loads and I get fairly decent performance, but if I open a menu my graphics card hard locks.

I get the exact same problem on mesa-aco with Vega VII, pressing anything that opens the menu hard locks, however I am able to drop to tty and wineserver -k. Adding bug report to mesa-aco repo now. Judging from the log this seems to be gpu specific:

from log:

amdgpu: The CS has been rejected, see dmesg for more information.
vk: error: failed to submit CS 0


$ dmesg
[27979.489949] [drm] recover vram bo from shadow start
[27979.495247] [drm] recover vram bo from shadow done
[27979.495249] [drm] Skip scheduling IBs!
[27979.495249] [drm] Skip scheduling IBs!
[27979.495285] amdgpu 0000:43:00.0: GPU reset(8) succeeded!
[27979.495315] [drm] Skip scheduling IBs!
[27979.495444] [drm] Skip scheduling IBs!
[27979.495447] [drm] Skip scheduling IBs!
[27979.495448] [drm] Skip scheduling IBs!
[27979.495453] [drm] Skip scheduling IBs!
[27979.495611] [drm] Skip scheduling IBs!
[27979.495614] [drm] Skip scheduling IBs!
[27979.495619] [drm] Skip scheduling IBs!
[27979.522575] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!

steam-275850.log

The problem is my file is freshly created and the game doesn't let you get into the options to set (and create) the missing entries until you're in a world. There's no options in the main menu.

Try this:
Just edit the config file and place my line with text _Property name="GraphicDetail" value="Low"_ under the line with text _Property name="TerrainTessellation" value="TkGraphicsDetailTypes.xml"_ and save the config file.

Then change the permissions of the file. Linux Mint right-clicking on the file offers me an option to change the permissons. Set them all to "Read" (only). There should be somethin similiar to this in your distro's file manager.

Then try to start NMS.

I'm not making any promises that it'll work. But maybe this will prevent a new initial version from being created immediately. At least it's worth a try.

The problem is my file is freshly created and the game doesn't let you get into the options to set (and create) the missing entries until you're in a world. There's no options in the main menu.

Try this:
Just edit the config file and place my line with text _Property name="GraphicDetail" value="Low"_ under the line with text _Property name="TerrainTessellation" value="TkGraphicsDetailTypes.xml"_ and save the config file.

Then change the permissions of the file. Linux Mint right-clicking on the file offers me an option to change the permissons. Set them all to "Read" (only). There should be somethin similiar to this in your distro's file manager.

Then try to start NMS.

I'm not making any promises that it'll work. But maybe this will prevent a new initial version from being created immediately. At least it's worth a try.

Or do a chattr +i on this file.

chattr +i

Sounds like another good option (not knewn untill now to me).
https://wiki.ubuntuusers.de/chattr/

But even more I would like to recommend to try out the ACO drivers as it has been said here several times. This should at least allow the game to run for a while so that a first configuration file can be created without crashing.

Anyone else getting unacceptably low frame rates as soon as the depth of field effect is used? Happening for me on both ACO and normal Mesa on a 580. GPU immediately goes to 100%.

Yes well NVIDIA users get low FPS when you enter the menus which if I remember correctly enables the DOF effect. But we nvidia users are experiencing different issues, and I'm not 100% sure its all related to low vram usage, certainly that is a factor but I doubt its the whole gist of the issue.

Yeah all the menus enable the DoF effect as well as most of the character conversations.

With my (odd) 2GB max VRAM I have no FPS problems with the menus

menus destroy the fps with radv or radv/aco and causes some artifacts to appear randomly. amdgpu-pro and amdvlk crash when using default settings,

Confirmed. Tesselation set to Low, mesa-avo on amdgpu. Menu's are atrocious and make it unplayable. It seems a bit random though as they were slow but tolerable earlier but now drop everything to about 2fps.

Also there are huge artifacts when you use menu and you are long enough in it.

I'm experiencing weird graphical (shader?) glitches.
Distro: Manjaro Linux
Kernel: 5.2.9-1-MANJARO
GPU: AMD RX580
CPU: AMD FX8350
Vulkan version seems to be 1.1.73
Also running gamemode from feral, though it doesn't seem to change anything

It happens with both llvm and aco, though aco seems to be much more extreme. Short example videos (Gfycat) here (ignore the performance, struggling with recording):

LLVM (00:06.0 - 00:14.0, different glitch at 00:55.0 in the background)
ACO (right from the start, similar (the same?) glitch from above at 00:37.0)

If more information is needed, feel free to ask

It's working fine for me with ACO and I'm on kernel 5.1.21-1 (Manjaro, too). So maybe try that, too? With the same GPU and so on it should probably work the same. Probably.

Alright, tested it quickly with the same kernel version of yours, didn't fix it

What settings are you playing on? I have everything on High. And are you on the experimental branch? I didn't notice anything on the stable branch but I didn't use it for too long.
If there's no difference then that's really mindboggingly weird.

The example videos are all with ultra settings (anti-aliasing down one because TAA causes massive blur) though I've tampered with the settings a lot and nothing changed no matter what combination of settings I chose. Branches the same, no matter if stable or experimental the issue stays.

ok, on Arch, switching back to normal mesa (not even -git from AUR) and resetting settings, still with tesselation low fixes the slow menu. Everything running very fast now.

I'm experiencing weird graphical (shader?) glitches.

Although I suspect it to be the same issue as daniel-schuermann/mesa#112, I'd be glad about a renderdoc capture.

Well it seems like TAA is the culprit somehow. Until now I only had FXAA enabled, once I switched to TAA the same glitches appeared for me. Switching back did _not_ seem to fix it though.

I'm experiencing weird graphical (shader?) glitches.

Although I suspect it to be the same issue as daniel-schuermann/mesa#112, I'd be glad about a renderdoc capture.

Alright.. sorry. Took me a long time to make it all work but here it is:
Done with ACO https://mega.nz/#!Ab513A7B!P4-gcFK1cJ0KrISx1dNeKZAzEA6CRpJV0cdOd_75oPM

Btw I'm using Proton 4.11-2.. forgot to mention that

Well the issue persists now for me. It wasn't there before I turned on TAA. I think before the update I had already set it to FXAA and there was no glitches or anything, now since I had TAA enabled once the glitches won't go away. It may be a coincidence but I think not.

Ok it now did generate a log for VR. It got like 60MiB big after not even two minutes... I have uploaded "only" a hundred thousand lines of that so github won't cancel the upload due to it taking too long: https://gist.github.com/Zamundaaa/c4bcc723bcb85f41daf178e1cfdedcf8
Edit: here's a log from a normal (2D) launch: steam-275850.log

Well I had a look at the log and the most important thing is of course in the end that can't be seen in what I uploaded. The log always is more or less the same size, always very near to 63MB. I've split up the log into multiple files now (probably just maybe the first and the last file is meaningful, the crash comes from a stack overflow):
steam-275850-partaa.txt
steam-275850-partab.txt
steam-275850-partac.txt
steam-275850-partad.txt
steam-275850-partae.txt
steam-275850-partaf.txt
steam-275850-partag.txt

I created a quick mod that replaces most of the DoF fragment shaders with stubs that return nothing but a transparent color. I haven't tested it extensively, but it appears to do the job.

https://www.nexusmods.com/nomanssky/mods/1126

In the game's folder, go to GAMEDATA -> PCBANKS, delete DISABLEMODS.TXT, and create a MODS folder. Download and unzip this mod and put nodof.pak inside there. You should see a notice on startup about the game being modded if done correctly.

It's very possible this will slightly mess up some other graphical effects- again, I didn't do a whole lot of testing, just enough to ensure that the menu and conversations no longer create the depth of field effect.

Alright, tested the mod. Doesn't seem to fix my issue.

That issue is different and unrelated. I have it as well.

-------- Original Message --------
On Aug 19, 2019, 12:40 AM, Furby On Steroid wrote:

Alright, tested the mod. Doesn't seem to fix my issue.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Based on a research of one guy on DXVK discord it would seem the low VRAM usage on NVidia is most probably an application bug - changing vendorid to AMD via vulkan layer fixed the problem for him.

Did that also fix performance or much the same?

It did fix the performance on his system.

Something to try out sometime, like in a few months because my 1080ti is dead, gotta RMA it, and who knows how well that will go.

@volca02 would you mind providing some instructions on how to change the vendorid? I won't be home for the next week to try it myself (have a destkop with manjaro and a gtx 1080 at home) but I suspect Hello Games will not be fixing the application bug unless it affects windows (seems like it does not though).

Since the game is native vulkan and not dx11 the card cannot be spoofed by dxvk like it does for other games.

I'd also like to learn how to change the vendor ID. I double cheked the *.json files in /usr/share/vulkan/icd.d but it doesn't appear to be present in any of the files.

I can now confirm spoofing vendorid will indeed fix the low GPU memory usage on nvidia. I've tried to create a repository with the layer, not sure if it will work for anyone else but it's worth trying: https://github.com/volca02/spoof_vendorid

I can now confirm spoofing vendorid will indeed fix the low GPU memory usage on nvidia. I've tried to create a repository with the layer, not sure if it will work for anyone else but it's worth trying: https://github.com/volca02/spoof_vendorid

Thanks for this. Will try it on my system when I get home. Did this only fix the low GPU memory usage or did it also improve the FPS issues?

it fixed both - the bad FPS problem was caused by the game using normal memory instead of GPU's memory.

With the spoof it crashes instead - is it expecting a specific amount of free VRAM? I have a 1060 3GB

UPDATE: I dropped all the setting to low in the config file, and it loaded as far as the screen going white. Then it crashed completely, and I have [19940.058332] NVRM: Xid (PCI:0000:01:00): 31, Ch 0000007b, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_PE_4 faulted @ 0x1_88551000. Fault is of type FAULT_PDE ACCESS_TYPE_READ in dmesg

The spoof has fixed performance issues for me from limited testing. On medium settings I went from 35-45 FPS to around 100-120 FPS and was also able to start the game with high settings. Using high settings, nvidia-smi returns a memory usage of around 4GB. This is all using a 1080ti with driver 430.40.

Thanks for the fix!

Can you not just use vendorid change with DXVK configuration system?

https://github.com/doitsujin/dxvk/blob/master/dxvk.conf

Oh wait, doesn't use DXVK does it, hmmm.. no wine way of doing this instead of hacking vulkan code?

No, because No Man's Sky is a native Vulkan title, so DXVK isn't used.

-------- Original Message --------
On Aug 19, 2019, 8:28 PM, jarrard wrote:

Can you not just use vendorid change with DXVK configuration system?

https://github.com/doitsujin/dxvk/blob/master/dxvk.conf

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Thanks for the fix @volca02 & to zerofault too, got it working and it's utilizing VRAM properly.

Edit: For those struggling to build etc follow rstrube's instructions a few posts below, they are better explained than mine were.

I'm wondering whether Valve can implement something like this layer in the Steam Runtime to load on a per game basis? Might be easier than waiting for wine to add extra vulkan bits or bobs or for Nvidia to come up with something and might be very useful with other windows only vulkan titles.

So is this a Wine issue or Nvidia driver issue in the end?

So is this a Wine issue or Nvidia driver issue in the end?

It's a game developer issue and I doubt they'd change their entire memory allocation strategy when it works fine on Windows, question is who works around it?

NVIDIA under windows is not affected, so I dunno about that.

I can now confirm spoofing vendorid will indeed fix the low GPU memory usage on nvidia. I've tried to create a repository with the layer, not sure if it will work for anyone else but it's worth trying: https://github.com/volca02/spoof_vendorid

This doesn't appear to work with 435.17, or I'm doing something wrong. @fls2018

C+G ...ps\common\No Man's Sky\Binaries\NMS.exe 1097MiB
With high/ultra. Still stuck at ~40fps. 980Ti

git clone https://github.com/volca02/spoof_vendorid
cd spoof_vendorid
cmake .
make
cp libVkLayer_vendorid_layer.so /usr/lib
cp VkLayer_vendorid_layer.json /etc/vulkan/explicit_layer.d/

VK_LAYER_PATH="/etc/vulkan/explicit_layer.d" VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_vendorid_layer %COMMAND%

I can now confirm spoofing vendorid will indeed fix the low GPU memory usage on nvidia. I've tried to create a repository with the layer, not sure if it will work for anyone else but it's worth trying: https://github.com/volca02/spoof_vendorid

This doesn't appear to work with 435.17, or I'm doing something wrong. @fls2018

C+G ...ps\common\No Man's Sky\Binaries\NMS.exe 1097MiB
With high/ultra. Still stuck at ~40fps. 980Ti

git clone https://github.com/volca02/spoof_vendorid
cd spoof_vendorid
cmake .
make
cp libVkLayer_vendorid_layer.so /usr/lib
cp VkLayer_vendorid_layer.json /etc/vulkan/explicit_layer.d/

VK_LAYER_PATH="/etc/vulkan/explicit_layer.d" VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_vendorid_layer %COMMAND%

I placed both libVkLayer_vendorid_layer.so and VkLayer_vendorid_layer.json in the same directory and then changed VK_LAYER_PATH=/some/path/ to the directory path.

Yeah cheers that works, perhaps you should change that fls2018?

EDIT: Going from ~35-40fps with High/Ultra capped at ~1100MiB of VRAM, now with the workaround to ~70fps average with ~3800MiB VRAM usage.

Yeah cheers that works, perhaps you should change that fls2018?

EDIT: Going from ~35-40fps with High/Ultra capped at ~1100MiB of VRAM, now with the workaround to ~70fps average with ~3800MiB VRAM usage.

I installed mine to the system and my nvidia drivers are not distro ones, maybe the issue when you tried my way is the fact some distro drivers install nvidia json files in /usr/share/vulkan rather than etc/vulkan.

Probably best not to install to the system though as I did.

For others that are struggling to build the Vulkan Layer, here are the steps that I used:

First install the neccessary development packages:

sudo apt install cmake cmake-curses-gui libxrandr-dev libxcb1-dev libx11-dev

Configure and build (I disabled wayland and mir support)

git clone https://github.com/volca02/spoof_vendorid
cd spoof_vendorid
ccmake ./ #I disabled wayland and mir support
cmake ./
make

Copy the generated files

mkdir $HOME/vulkan
cp libVkLayer_vendorid_layer.so $HOME/vulkan/
cp VkLayer_vendorid_layer.json $HOME/vulkan/

Then edit your launch options for NMS in Steam, mine look like:

VK_LAYER_PATH=/home/robert/vulkan/ VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_vendorid_layer %COMMAND%

Replace the VK_LAYER_PATH with your own local path.

I forgot the mention that this completely solves my performance problems. Amazing! Thank you so much for sharing this with us.

Hardware: GTX 2070 as eGPU over Thunderbolt 3

I've discovered another issue, while the vulkan layer fixes low memory it doesn't flush it so you eventually run out of memory after about an hour or so if you're travelling between planets & such.

Edit: Clearing NMS settings/prefix/nv shader cache seemed to have fixed it, although VRAM usage is insanely high at 1440p Ultra and it only seems to flush 100MB every now & then.

Performance though despite the odd stutter is excellent, around 5-7 fps difference to windows.

I can now confirm spoofing vendorid will indeed fix the low GPU memory usage on nvidia. I've tried to create a repository with the layer, not sure if it will work for anyone else but it's worth trying: https://github.com/volca02/spoof_vendorid

Excellent find by ZeroFault! This helped my issues with the game crashing at the boot screen to playing it for over 10 hours without a single crash or issue with FPS! Thank you for sharing this!

Info
Proton: 4.11-2
Distro: Fedora
Kernel: 5.2.8-200.fc30.x86_64
RAM: 8GB

GPU Driver: NVIDIA 430.40
GPU: NVIDIA GeForce GTX 970
CPU: Intel Core i7-4790K @ 4.00GHz

Without the patch, NMS uses ~1G vram and runs horribly. After around 10 mins, it will crash with Xid 31 (meaning GPU page fault). I've ran cuda-memtest for 15 mins on stress mode with no problems, basemark gpu vulkan bench runs fine and so do all other GL games that I have. The card is also not overclocked, so I don't think it's a hardware issue.

With the vendorid patch, the game loads normally up until the white screen when the game is fully loaded. The screen then goes completely black apart from 2 UI elements being rendered, the red mission marker and centre white aim dot, and an xid 31 appears in dmesg. Any ideas on what could be causing these xid issues, it doesn't seem like anyone else here has them. I looked through the nvidia forums as well, where people with this error code blamed it on a driver bug, and some DXVK users also get xid 31 with some games. I have no clue at this point.

Info:
Proton 4.11-2
Kubuntu 18.04
Kernel 5.0.0-25-generic
i5 4670k @ 4.3G (tested to be stable)
16GB DDR3 (tested with memtest86)
GTX 1060 3GB (tested with cuda_memtest + other benchmarks)

EDIT: GPU memory graph with patch

Just found something very interesting in the experimental patch notes from yesterday:

Update to Experimental Branch 20/08

Fixed a crash affecting AMD GPUs when creating the pipe state on a framebuffer that has not been created yet.
Fixed a number of threading-related multiplayer matchmaking issues.
Fixed an audio crash when quitting from the initial screen.
Fixed a crash when quitting the game during audio initialisation.
**Fixed Steam VR in Linux.**
Fixed a rare issue where joining a full lobby causes an incorrect player ID.
Fixed an issue where players joining a group can be taken to the wrong system.
Fixed an issue that caused some network games not to appear in the Join game screen.
Fixed an issue that caused the Exocraft Technician to have an incorrect interaction.
Fixed a crash caused by an invalid base index.

Any VR players tested that yet?

Yeah, it still crashes for me.

-------- Original Message --------
On Aug 21, 2019, 9:43 AM, fls2018 wrote:

Just found something very interesting in the experimental patch notes from yesterday:

Update to Experimental Branch 20/08

Fixed a crash affecting AMD GPUs when creating the pipe state on a framebuffer that has not been created yet.
Fixed a number of threading-related multiplayer matchmaking issues.
Fixed an audio crash when quitting from the initial screen.
Fixed a crash when quitting the game during audio initialisation.
Fixed Steam VR in Linux.
Fixed a rare issue where joining a full lobby causes an incorrect player ID.
Fixed an issue where players joining a group can be taken to the wrong system.
Fixed an issue that caused some network games not to appear in the Join game screen.
Fixed an issue that caused the Exocraft Technician to have an incorrect interaction.
Fixed a crash caused by an invalid base index.

Any VR players testing that?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

It does _technically_ not crash for me now, but it doesn't really start either. So the behaviour I had in the beginning... Black window and nothing else happening. The log seems to be a little shorter but still ends with the same stack overflow exception. Still, very nice to see someone cares :smile:
Here's the log from now:
steam-275850-part#aa.txt
steam-275850-part#ab.txt
steam-275850-part#ac.txt
steam-275850-part#ad.txt
steam-275850-part#ae.txt
steam-275850-part#af.txt
steam-275850-part#ag.txt

Has anyone verified that patch 2.06E fixes the memory issue on Nvidia cards?

Has anyone verified that patch 2.06E fixes the memory issue on Nvidia cards?

Doesn't fix anything on my end. The only way I can get it to use my VRAM efficiently is to use that vulkan workaround

Have anybody found a fix for the loading screen crash yet? (I have tried loading the game with proton 4.11 and 4.2 but no luck..)

GPU Driver: NVIDIA 430.40
GPU: NVIDIA GeForce GTX 960
CPU: Intel Core i5-4460 @ 3.20GHz

Edit:
steam-275850.log

Have anybody found a fix for the loading screen crash yet? (I have tried loading the game with proton 4.11 and 4.2 but no luck..)

Try delete ~/.steam/steam/steamapps/common/No Man's Sky/Binaries/SETTINGS/TKGRAPHICSSETTINGS.MXML

Then reapply the settings in-game. I believe setting tesselation above Enhanced is causing some crashes too

Have anybody found a fix for the loading screen crash yet? (I have tried loading the game with proton 4.11 and 4.2 but no luck..)

Try delete ~/.steam/steam/steamapps/common/No Man's Sky/Binaries/SETTINGS/TKGRAPHICSSETTINGS.MXML

Then reapply the settings in-game. I believe setting tesselation above Enhanced is causing some crashes too

I tried that, but no luck. :(

I have an AMD Radeon rx580 (Linux Mint 19.2; Kernel 5.2.9; Proton 4.11-2) and could only start the game after I replaced the Padoka stable PPA with the experimental ACO driver PPA from Valve. Before that I always had a crash to desktop when the loading screen ended and the game should have started.

After Hello Games released some fixes I wanted to know if I could play with the stable Padoka drivers again. With the experimental ACO driver the screen was frozen 2x times without any input possibilities left. I cannot blame the ACO driver 100%. But I didn't have such a bug before.

As I said, I wanted to return to the stable Padoka-PPA. I uninstalled the ACO driver with PURGE and reinstalled the Padoka-PPA. However, the game crashed again at the same place directly after the loading screen. That's why I changed back to the ACO driver.

This only as info if someone has something similar in mind. Currently the attempt can be saved.

I tried the latest patch and VR finally works! This is awesome!
Horrible performance (to be expected on my 580) and SteamVRs bug with async reprojection doesn't help there - but that's fine. The coming rx 5700XT will probably handle that.
Flying into space however made the game crash. Looked like the exact moment I was "in space", when I could see the asteroids. The window on the desktop froze, it didn't push any more frames to VR and audio kind of sounded like it was repeating the last 5 seconds or so.
steam-275850.log
So I'm gonna have to restrict myself to the planet for now, but even that's still very much amazing.

@Zamundaaa How did you get it to work? Mine still freezes just opening NMS in VR.

EDIT: And it just started working on experimental....
EDIT2: Performance seems totally crap though, and this is on a Radeon VII...

try disabling async reprojection. And go into the video settings, disable the 60fps cap, VSync, reduce the mirror window resolution etc. It's kind of OK for me with lowest settings, but without async reprojection it kind of stutters back and forth when moving the head. And with async reprojection it completely craps out (https://github.com/ValveSoftware/SteamVR-for-Linux/issues/226)

Ah! I shall try all that, thanks!

So, no official patch for nvidia vram allocation ?

On the VKx discord, an nvidia dev said they are trying to get in contact with Hello Games to issue a fix, since it was confirmed to be game's issue.

The issue with the rocks being weird seems to be fixed. From the patchnotes:

Fixed a number of LODding issues on specific plants

And it actually is fixed for me at least.

Hey guys... those on nvidia might want to check WITHOUT the spoof on latest experimental update?

It appears to be working, think HG have officially fixed it.

Just tried the latest, unfortunately no progress for me. I tried launching with texture quality set to enhanced (1st launch in graph) and at ultra (2nd), made no difference. Still at 20-30 fps no matter what.

Hey guys... those on nvidia might want to check WITHOUT the spoof on latest experimental update?

It appears to be working, think HG have officially fixed it.

Works great now for me, without the workaround.

C+G ...ps\common\No Man's Sky\Binaries\NMS.exe 3972MiB

However, on the first launch I did crash and stutter heaps, but the second launch went fine. I think it was probably caching something.

It fixed it for me too. Again, first launch crashes.

However, on the first launch I did crash and stutter heaps, but the second launch went fine. I think it was probably caching something.

This is mostly a sign that the Vulkan Shader Cache is being built.

The latest experimental build also fixed my performance issues. I can now play the game without the spoof! This is fantastic!

Have anybody found a fix for the loading screen crash yet? (I have tried loading the game with proton 4.11 and 4.2 but no luck..)

NMS was crashing right after the starfield loader. Upgrading to mesa 19.2.0~rc1 on Debian fixed the problem.

Performances have improved significantly since last time I tried this game, but the menus are unusable, impossibly slow.

I made a mod to fix that, see https://github.com/ValveSoftware/Proton/issues/438#issuecomment-522352356

seems unfortunate that dof does that. surely there is a reason.

The issue with the rocks being weird seems to be fixed. From the patchnotes:

Fixed a number of LODding issues on specific plants

And it actually is fixed for me at least.

Not fixed for me unfortunately
https://imgur.com/a/Kpm4Dbt
Both with the normal and experimental NMS build

I'm using a polaris GPU and the game crashed in the start or loading screen.
Set <Property name="VsyncEx" value="Triple" /> to <Property name="VsyncEx" value="Off" /> fixed the problem for me.

@FurbyonSteroid I started NMS again to double check and now it was there again for me. It was better than before, but still / again there. Weird.

The game crashes after loading screen with ACO and Tessellation Low on my Picasso 3500U. Loading or creating new save file doesn't work.
steam-275850-newsave.log
steam-275850.log

EDIT: Corrected CPU generation

I tried the latest patch and VR finally works! This is awesome!

@Zamundaaa Confirmed, the experimental branch now appears to work as expected (tested with Valve Index Headset). General performance is still an issue though this is also true on Windows.

System Information

• GPU: RTX 2060
• Driver/LLVM version: NVIDIA 430.40
• Kernel version: 5.0.0-25-generic
• Link to full system information report as Gist
• Proton version: 4.11-2
• SteamVR version: 1.7.9

The game worked great for me (GTX 1080) with the nvidia to amd spoof. After today's update, I removed the spoof and the game still works great.

However I just tried with my HTC Vive and unfortunately the performance is so bad it's unplayable. I tried other tweaks suggested by the windows community but it still does not work. Looking at the VR frame graph, it seems the VR compositor is taking a long time doing something for some reason which makes the game lag.

Other Proton VR Games such as Gorn works fine with expected performance (90 FPS locked with no reprojection).

Other users on windows are reporting 90 FPS performance on no man's sky with setups like mine and VR. I am getting like 30

Anyone else tried VR?

Yes, performance is still bad in VR, when you move your head around. That's on a Radeon VII, where all other games run just fine.

@beniwtv you're probably experiencing https://github.com/ValveSoftware/SteamVR-for-Linux/issues/226, too.
You can disable async reprojection in the browser at http://localhost:8998/dashboard/debugcommands.html
That makes it somewhat playable for me (at lowest settings, but my GPU is crap compared to the RVII). If that works then it would probably be good to add your system report to issue 226. Valve's either hit a wall or they're not putting in much effort to fix it.
@fazo96 it may either be some more issues with NMS+ NVidia or it might be the same bug. Is Async Reprojection now working on Linux at all?

@Zamundaaa I don't think async reprojection is working at all for me on Linux according to the SteamVR settings screen. Only regular reprojection works (and is always triggered in NMS).

Motion smoothing doesn't work either as it's not supported, amusingly it says it's not supported on "older versions of Windows" :smile:

I tried disabling reprojection and confirmed on the SteamVR Settings screen that it was not reprojecting, but the framerate was still so low it was nausea inducing. The game runs at 80-120 FPS in 1440p with max settings when not in VR, with drops to 20-50 for a split second when landing on planets or in other cases.

Unfortunately in VR it performs much much worse even with the lowest settings. Changing settings had effects on visual quality but none on performance.

@Zamundaaa I did try turning it off, and it showed me it's off but that makes absolutely no difference. Turning down all details, VR resolution, etc also don't help.

No matter what settings, this issue persists.

I tried with the SteamVR 1.7 beta today since in the Changelog they mentioned improved performance on Linux.

Performance is MUCH better for me with this version. However, most of the time it still does not run well enough to get out of Reprojection so it is not yet playable for me (I get sick due to the low framerate) but at least it will be for some people.

This is on my HTC Vive with a GTX 1080 with minimum settings and 1.0 supersampling, so the results are still much worse than what is expected on Windows, even though they are a big improvement over SteamVR pre-1.7

I'm getting a crash while playing the game. Reproducible in about 10 minutes of playing.

steam-275850.log

dmesg output for crash

[97860.884543] NVRM: Xid (PCI:0000:01:00): 13, pid=19181, Graphics Exception: EXTRA_MACRO_DATA
[97860.884546] NVRM: Xid (PCI:0000:01:00): 13, pid=19181, Graphics Exception: ESR 0x404490=0x80000002
[97860.884725] NVRM: Xid (PCI:0000:01:00): 13, pid=19181, Graphics Exception: ChID 003b, Class 0000c197, Offset 00000fb4, Data 00000000

The strange thing was, last week on 4.11-4, I played the game for hours straight without issue. This just popped up today after I updated to 4.11-5. Going back to 4.2-9 will also reproduce this problem.

The crash hard hangs my computer with audio from the game still playing. I usually regain control of the system within a minute or so and I get the above screenshot.

System Information

• GPU: GTX 1080
• Driver/LLVM version: nvidia-drivers-435.21
• Kernel version: 4.19.72-gentoo

I'm also getting a reproducible crash after 10 min of playing.

No "xid" messages in dmesg or popups, however. The game freezes but the audio keeps playing. I have to manually kill NMS.exe. The process usually sits at about 4.2GB at this point.

Tested with the recent Proton versions and GloriousEggroll.

steam-275850.log

System Information

• RAM: 16 GB
• GPU: RTX 2070 8GB
• Driver/LLVM version: 435.19.03 (tested with 435.21 - same issue)
• Kernel version: 5.2.15-zen (zen-kernel)
• Proton version: 4.15-GE-2-7-g57d3fe8
• Branch: Experimental Branch 12/09 (Patch Notes)

I lucked out on this title. I just played a solid hour or more with no major issues.

Minor things I did notice were slight graphic artifacts. If I had to describe this artifact, it would be like an occasional snow like effect on panels. Other than that I haven't noticed anything else to document.

I didn't collect FPS stats, but It was smooth and seemed to be synced up with my freesync monitor.

System Information

• RAM: 32 GB
• GPU: Radeon RX Vega 64 8GB
• Driver: amdgpu
• Kernel version: 5.2.11-manjaro
• Proton version: 4.11-6

I have artifacts and they are not minor. Almost every 3D model has artifacts: either a blueish or whiteish square or noise. Also trees in the distance have a white outline.
Here are a couple of screenshots:

System Information

• RAM: 16 GB
• GPU: Radeon RX 580 8GB
• Driver: amdgpu (ACO) DRM 3.27.0, LLVM 8.0.0 Mesa 19.3.0-devel
• Kernel version: 5.0.0-29-generic
• Proton version: 4.11-6

@lavadrop Ah, finally some pictures where these artifacts are really visible. Would you be able to provide a renderdoc capture of such situation and link it over here https://github.com/daniel-schuermann/mesa/issues/112 ?

@lavadrop Now that you mention it, I also did have that white outline on the trees from a distance that I forgot to mention. I think I only saw that when I was flying. It seems as they were loading they would start out with that white outline and then turn normal the closer I got to them.
I'll have to look more closer to see if I'm getting that blueish shadow like artifact on the near by models.

@lavadrop Ah, finally some pictures where these artifacts are really visible. Would you be able to provide a renderdoc capture of such situation and link it over here daniel-schuermann/mesa#112 ?

Yeah, sure

I'm getting a crash while playing the game. Reproducible in about 10 minutes of playing.

steam-275850.log

dmesg output for crash

[97860.884543] NVRM: Xid (PCI:0000:01:00): 13, pid=19181, Graphics Exception: EXTRA_MACRO_DATA
[97860.884546] NVRM: Xid (PCI:0000:01:00): 13, pid=19181, Graphics Exception: ESR 0x404490=0x80000002
[97860.884725] NVRM: Xid (PCI:0000:01:00): 13, pid=19181, Graphics Exception: ChID 003b, Class 0000c197, Offset 00000fb4, Data 00000000

The strange thing was, last week on 4.11-4, I played the game for hours straight without issue. This just popped up today after I updated to 4.11-5. Going back to 4.2-9 will also reproduce this problem.

The crash hard hangs my computer with audio from the game still playing. I usually regain control of the system within a minute or so and I get the above screenshot.

System Information

• GPU: GTX 1080
• Driver/LLVM version: nvidia-drivers-435.21
• Kernel version: 4.19.72-gentoo

I have the same crash 8 times out of 10, any news?

I'm getting a crash while playing the game. Reproducible in about 10 minutes of playing.
steam-275850.log

dmesg output for crash

[97860.884543] NVRM: Xid (PCI:0000:01:00): 13, pid=19181, Graphics Exception: EXTRA_MACRO_DATA
[97860.884546] NVRM: Xid (PCI:0000:01:00): 13, pid=19181, Graphics Exception: ESR 0x404490=0x80000002
[97860.884725] NVRM: Xid (PCI:0000:01:00): 13, pid=19181, Graphics Exception: ChID 003b, Class 0000c197, Offset 00000fb4, Data 00000000

The strange thing was, last week on 4.11-4, I played the game for hours straight without issue. This just popped up today after I updated to 4.11-5. Going back to 4.2-9 will also reproduce this problem.
The crash hard hangs my computer with audio from the game still playing. I usually regain control of the system within a minute or so and I get the above screenshot.

System Information

• GPU: GTX 1080
• Driver/LLVM version: nvidia-drivers-435.21
• Kernel version: 4.19.72-gentoo

I have the same crash 8 times out of 10, any news?

I don't get crashes here, that said I did have crashes on the first load of a new update a couple of weeks back due to having the nvidia fps overlay still enabled. I've also experienced a little instability with V-sync.

I have artifacts and they are not minor. Almost every 3D model has artifacts: either a blueish or whiteish square or noise. Also trees in the distance have a white outline.
Here are a couple of screenshots:

System Information

* RAM: 16 GB

* GPU: Radeon RX 580 8GB

* Driver: amdgpu (ACO) DRM 3.27.0, LLVM 8.0.0 Mesa 19.3.0-devel

* Kernel version: 5.0.0-29-generic

* Proton version: 4.11-6

I can confirm those graphical glitches. I have tried the game with and without ACO enabled. So this problem seems not to be related to the compilerbackend. I know that the problem doesn't exist when an nvidiagpu is used. So my guess is that it has something to do with the RADV driver. No man's sky uses vulkan as its native API so dxvk is not causing those glitches.

Systemspecs:

RAM 16GB
GPU: Radeon RX 590
Driver: amdgpu (ACO) DRM 3.27.0, LLVM 8.0.0 Mesa 19.3.0-devel
Kernel: 5.3.5
Proton version: 4.11-6

I struggled with xid 13s for a long time; I tried different drivers, even changing distro to no avail. I did manage to finally fix it by doing the following:

• Backing up my savefiles
• Removing EVERYTHING to do with no mans sky (the proton dir, the shader cache etc)
• Reinstall from steam
• Copying in my savefiles

Hopefully this helps, the issue seems quite touch and go but good luck

I have artifacts and they are not minor. Almost every 3D model has artifacts: either a blueish or whiteish square or noise. Also trees in the distance have a white outline.
Here are a couple of screenshots:

System Information

* RAM: 16 GB

* GPU: Radeon RX 580 8GB

* Driver: amdgpu (ACO) DRM 3.27.0, LLVM 8.0.0 Mesa 19.3.0-devel

* Kernel version: 5.0.0-29-generic

* Proton version: 4.11-6

I can also confirm that this issue exists while running on Arch Linux with Proton 4.11-9. I am using a Vega 56.

I can also confirm that this issue exists while running on Arch Linux with Proton 4.11-9. I am using a Vega 56.

Unfortunately, this is a game bug and would require us to disable some (valid) optimization to work around this issue. It doesn't seem that the developers are spending attention on that anytime soon..

Anyone notice the terrain tessellation is quite slow in this game, You can turn around and watch it slowly grow the tessellation cells on the ground in front of you. Is there any hack us linux users can do to speed it up? (its also a tad slow under Windows I believe)

Anyone notice the terrain tessellation is quite slow in this game, You can turn around and watch it slowly grow the tessellation cells on the ground in front of you. Is there any hack us linux users can do to speed it up? (its also a tad slow under Windows I believe)

Some info about your hardware would be helpful.

When using an AMD GPU I would emhpasize to use Mesa 19.3 and activate the new built-in ACO-Support. When using an Ubuntu or derivate of it (I am using Linux Mint 19.2) the kisak-PPA would be a good choice:
-> https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa

I just having the latest nvidia drivers with a 1080TI

I cannot get the game to boot at all with any version of Proton, even GE. What steps should I take to diagnose this?

You can generally let Proton generate a log with "PROTON_LOG=1 %command%"

I can also confirm that this issue exists while running on Arch Linux with Proton 4.11-9. I am using a Vega 56.

Unfortunately, this is a game bug and would require us to disable some (valid) optimization to work around this issue. It doesn't seem that the developers are spending attention on that anytime soon..

Could you elaborate on this? I plan on testing NMS in windows on the same hardware soon.

You can generally let Proton generate a log with "PROTON_LOG=1 %command%"

It's not storing any logs in my home dir, when launching with normal Wine it says VK_ERROR_INITIALIZATION_FAILED

You can generally let Proton generate a log with "PROTON_LOG=1 %command%"

It's not storing any logs in my home dir, when launching with normal Wine it says VK_ERROR_INITIALIZATION_FAILED

That error means your system is not properly configured to use Vulkan

You can generally let Proton generate a log with "PROTON_LOG=1 %command%"

It's not storing any logs in my home dir, when launching with normal Wine it says VK_ERROR_INITIALIZATION_FAILED

That error means your system is not properly configured to use Vulkan

Have a look at this for the Proton requirements and how to setup Vulkan:
-> https://github.com/ValveSoftware/Proton/wiki/Requirements

You can generally let Proton generate a log with "PROTON_LOG=1 %command%"

It's not storing any logs in my home dir, when launching with normal Wine it says VK_ERROR_INITIALIZATION_FAILED

That error means your system is not properly configured to use Vulkan

Have a look at this for the Proton requirements and how to setup Vulkan:
-> https://github.com/ValveSoftware/Proton/wiki/Requirements

I've already done those steps and I have the latest drivers. I'm on a 1060 6gb.
Also DOTA2 works with Vulkan perfect.

A few weeks ago I had d problem to start NMS, too. But instead of a research for the reason for it I simply deleted teh installation and all steam-directories of the game and completely reinstalled the game. From this point ist runs without problems (no pain for me; reinstalled in less then 40 minutes (250 mbit internet connection)).

As said, I don´t know the exact reason. Maybe you`ll give it a try.

This is certainly not a very factual or professional tip. But since your VK installation is correct according to your information, I am not left with a factual or technical tip in case of your error message.

A few weeks ago I had d problem to start NMS, too. But instead of a research for the reason for it I simply deleted teh installation and all steam-directories of the game and completely reinstalled the game. From this point ist runs without problems (no pain for me; reinstalled in less then 40 minutes (250 mbit internet connection)).

As said, I don´t know the exact reason. Maybe you`ll give it a try.

This is certainly not a very factual or professional tip. But since your VK installation is correct according to your information, I am not left with a factual or technical tip in case of your error message.

Where exactly are these error logs stored? I'm on Ubuntu 19.10. The game just launches and closes with no black screen on Steam, and when trying the Wine Lutris install it gives me that Vulkan error.

Where exactly are these error logs stored? I'm on Ubuntu 19.10. The game just launches and closes with no black screen on Steam, and when trying the Wine Lutris install it gives me that Vulkan error.

I have not only deleted the log files. I deleted the entire game.

Finally got the log to work. I uninstalled everything including steam and all my games.
steam-275850.log

Hello @pattmax00, err:file:init_redirects /media/max/OS/SteamLibrary/steamapps/compatdata/275850/pfx/dosdevices/c:/windows: No such file or directory from the log looks like where things start to go wrong. What filesystem are you using with /media/max/OS?

Hello @pattmax00, err:file:init_redirects /media/max/OS/SteamLibrary/steamapps/compatdata/275850/pfx/dosdevices/c:/windows: No such file or directory from the log looks like where things start to go wrong. What filesystem are you using with /media/max/OS?

NTFS, shameful I know, it's a long story.

Proton + NTFS is known to be temperamental and needs to be mounted carefully for Proton to work with it. In particular, we know it needs to be mounted with ntfs-3g as the current user, and without the windows_names mount option. There may be other restrictions involved and you can search for ntfs on this issue tracker to find what others have tried.

Proton + NTFS is known to be temperamental and needs to be mounted carefully for Proton to work with it. In particular, we know it needs to be mounted with ntfs-3g as the current user, and without the windows_names mount option. There may be other restrictions involved and you can search for ntfs on this issue tracker to find what others have tried.

Thank you for this information, I'm going to just not use NTFS from now on, I don't have anything that uses Windows anymore.

The game is working now!

I use proton with my NTFS drives all the time without issues. I do have several flags set for the partitions tho. Some of what I have below is probably not needed and does nothing great.

x-gvfs-show,noatime,async,big_writes,inherit,windows_names,uid=1000,gid=1004,rw,user,exec,umask=000 0 0

Also the compatdata folder needs to be symlinked back to the users .steam path, compatdata should never be on ntfs drives.

Has the latest update broken the game for anyone else? The game used to work perfectly for me without any changes, but recently the game just freezes up my desktop. It seems to be using my Intel HD Graphics as well (the window says 'No Mans Sky (Intel HD Graphics)). All my other games are working as normal so I'm confident nothing has gone wrong with my drivers. Also reinstalling didn't work

Specs is an i7-9750H and GTX 1660Ti running on Ubuntu 18.04 (Elementary OS).

Hello @Cybiko, that sounds similar to #3215. Can you check if that's what you encountered?

@kisak-valve It doesn't seem to be, none of the launch commands on there have any effect on my game whatsoever.

It's the Steam Overlay.
ERROR: ld.so: object '~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

Unfortunately, this is a game bug and would require us to disable some (valid) optimization to work around this issue. It doesn't seem that the developers are spending attention on that anytime soon..

I wrote a workaround for RADV which seems to resolve the issue no matter which backend (LLVM or ACO) is used: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4047
It will probably be merged today or tomorrow and hopefully removes the small artifacts you encounter in the game. (I haven't tested in-game as I don't own the game, so would be glad if anyone could report back.) We won't backport this workaround to mesa stable as it's a bit too invasive, sorry for that.

I wrote a workaround for RADV which seems to resolve the issue no matter which backend (LLVM or ACO) is used: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4047
It will probably be merged today or tomorrow and hopefully removes the small artifacts you encounter in the game. (I haven't tested in-game as I don't own the game, so would be glad if anyone could report back.) We won't backport this workaround to mesa stable as it's a bit too invasive, sorry for that.

It seems that the artifacts are still present sadly, tested the patch with TKG's PKGBUILD with both LLVM and ACO

@BlazeKl thx for testing. If you are sure, you added the patches (it's 6 patches) correctly, could you check on the reported application name if it's reporting "No Mans Sky"? Because I'm pretty sure I got the artifacts removed in a renderdoc capture, but maybe the workaround doesn't get enabled for some reason.

@daniel-schuermann the application name is "No Man's Sky", tested it again with the correct name and it works great, thanks

When will we get the patch? I am using the oibaf ppa right now. But the artifacts are still visible.

When will we get the patch? I am using the oibaf ppa right now. But the artifacts are still visible.

I merged the series today, so should come in with the next update.

Some users reported issues on the Proton 5.0 series. It may have only affected users that never ran it on older versions of Proton. In any case, we included a fix for No Man's Sky in 5.0-4, so if you had trouble with the game on Proton 5.0, it may be worth retrying now.

Issues as in crashing every 2 hours of play or so?

Is anybody else having problems with NMS + Steam VR. With the latest release, when I start NMS via Steam VR, my VR headset remains black, I can hear music coming from the headset's headphones, and I can see the main menu only on my monitor. It's almost as if the game is being forced into Desktop mode? I can use the mouse and keyboard to navigate the menus, but my VR controllers are not active.

Yeah, I can't get NMS to start in VR mode either

Looks like there is an issue with Proton 5.0-4 initializing OpenVR for certain games. Please see this issue: https://github.com/ValveSoftware/Proton/issues/3652

Proton 5.0-5 fixes the issue with NMS + VR. Yay!

Can confirm, works again :)

Hey there. I recently purchased No Man's Sky and I have not been able to get it to run. When I click the Play button in the Steam Library's interface, the screen goes black for only a second, then the screen returns to the Library UI and the Play button is visible again.
From the logs, it throws the following error when the game exits:

ERROR: ld.so: object '/home/trent/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/trent/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
GameAction [AppID 275850, ActionID 2] : LaunchApp changed task to Completed with ""

I searched for this error in several places to see if any users were having the same issue and, while I did find it for some other games, I did not find any information concerning NMS. Any help would be appreciated. Thank you.

Here are the full logs:
https://gist.github.com/trentchilders/5aa2fa1aa8aad586ce6feff0defaa4c2

CPU: AMD Ryzen 5 1600 Six-Core Processor
GPU: Radeon RX 570 Series

the "ERROR: ld.so:..." stuff can safely be ignored. The actual line of importance is:

Z:\home\trent.local\shareSteam\steamapps\common\No Man's Sky\Binaries\NMS.exe: symbol lookup error: /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so: undefined symbol: amdgpu_bo_list_create_raw

It looks like your Vulkan drivers are at fault. What's your distro, is your system up to date and what's the output of "vulkaninfo"?

@Zamundaaa Thanks for your reply! Distro and version:

Distributor ID: Ubuntu
Description:    Ubuntu 18.04.4 LTS
Release:    18.04
Codename:   bionic

And this is the out but from vulkaninfo:

https://gist.github.com/trentchilders/1eb9d1f3f54ccdd0fe7689122e0301b5

I ran sudo apt-get dist-upgrade to ensure I was up to date, and I got the same "undefined symbol: amdgpu_bo_list_create_raw" error as before.

I would suggest using a newer OS, or at least upgrade your vulkan driver/loader libraries

@trentchilders
what telans said. An upgrade to a newer Ubuntu, Ubuntu 20.04 once it's out or of course straight up another distro would probably do it. Alternatively there's the easier option of some ppas like the padoka ones (stable or unstable, take your pick) that will update your drivers.
Can you run other vulkan applications like vkcube?

@trentchilders
Regarding what @Zamundaaa said I would recommend the PPA of @kisak-valve . I used to use the Padoka PPA as well ... but the PPA is not (anymore) updated as regularly and promptly. Therefore I switched to the kisak-PPA.

The kisak PPA updates the Mesa drivers to the latest version (currently 20.0.3). At the same time you have integrated the ACO support propagated by Valve, if desired (can be turned on or off individually):
-> https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa

Additionally you should install or update the Vulcan drivers:
sudo apt install mesa-vulkan-drivers mesa-vulkan-drivers:i386

But you can find all this here as well:
https://github.com/ValveSoftware/Proton/wiki/Requirements

@KuJo-Ger Thanks for your post. I added the Kisak PPA and ran the install command you reference and I got this:

mesa-vulkan-drivers is already the newest version (20.1~git2004220730.f1a12d~oibaf~b).
mesa-vulkan-drivers:i386 is already the newest version (20.1~git2004220730.f1a12d~oibaf~b).

And yet still the game won't run. I get the same errors. So, this might lead me down the path that @telans and @Zamundaaa suggested: a new linux distro. Which one do you like to use?

@Zamundaaa I'm not familiar with pkcube. I'll have to look into it and get back to you.

not pkcube, "vkcube". Just run it in the terminal, it should already be installed.
I personally am using Manjaro KDE and NMS is working perfectly like always. For gaming it's usually best to pick a rather up to date distro, the best options would be Arch, Manjaro, Fedora, Solus but the latest Ubuntu should also be enough as long as you don't want to use new hardware like GPUs soon after launch.

Hello @trentchilders, please do not use multiple mesa PPAs at the same time, this is completely untested and may have strange side effects. If you want to test with my PPA, please ppa-purge oibaf's PPA before adding mine, and vice versa if you want to switch back.

@trentchilders
You installed the PPA from oibaf. This is based on the unstable and not yet released Mesa version 20.1 (20.1 ~ git2004220730.f1a12d ~ oibaf ~ b). Currently version 20.0.x is released and stable. This may also be the reason that NMS is not running.

It is always recommended to choose a stable version. Like the one from @kisak-valve .

But as kisak has already explained you have to uninstall other PPAs before you can install its PPA. This is e.g. described on the PPA page of oibaf (see the section under "=== Revert to original drivers ==="):
-> https://launchpad.net/~oibaf/+archives/ubuntu/graphics-drivers

Then follow the steps as described on the Proton page (see section "AMD/Intel"):
-> https://github.com/ValveSoftware/Proton/wiki/Requirements

BTW - I use Linux MInt 19.3 with the kisak PPA. AMD Ryzen 5 3600, AMD Radeon RX 5700 XT.

@KuJo-Ger Got it. Thank you so much. I'm at work right now but can try this when I get home. Yes. I had multiple PPAs for mesa drivers, which was dumb, but I'm still learning about all of this.

@Zamundaaa @telans @kisak-valve Thanks to all of you for replying. I really appreciate it.

No Man's Sky runs very well besides a few stutters during cut scenes. The only problem I'm getting is random crashes during gameplay. I'll try capturing the error log but the mouse disappears in the crash window. I saw something mentioning OpenVR and I don't have a VR headset so it might be trying to find one.

The game has now crashed multiple times on entering space. But besides that, it runs well on my Arch Linux system with a Ryzen 5 3600, 16GB of RAM, and RTX 2060.

I was able to capture the error log

I was able to capture the error log

It's more helpful to use the log provided with the PROTON_LOG=1 %command%

Alright, here's Proton's log.

I found an odd thing with No Man's Sky where the game won't open after like a few minutes. The solution to this is opening a task manager (ex: htop, top, GNOME Task Manager, etc.) and kill the explorer.exe processes and within a few seconds the game will open.

The game doesn't even open with proton 5.0-7. Since the game doesn't open it doesn't even create a log file when using PROTON_LOG=1 %command%

System Info

Bug] No Man's Sky LOD fade-in effect corruption

Issue transferred from https://github.com/ValveSoftware/Proton/issues/3902.
@FuzzyQuills posted on 2020-05-23T10:02:34:

Compatibility Report

• Name of the game with compatibility issues: No Man's Sky
• Steam AppID of the game: 275850

System Information

• GPU: RX 570
• Driver/LLVM version: Mesa 19.3.3/LLVM 9.0.1 (using ACO, same issue appears on LLVM, but isn't present on Windows AMD Vulkan driver)
• Kernel version: currently 4.19, kernels 5.3-3.6 tested as well
• Link to full system information report as Gist: https://gist.github.com/FuzzyQuills/294fdb78855e9c9b389194b8cfc1fcc6
• Proton version: 5.0-7

I confirm:

• [ x ] that I haven't found an existing compatibility report for this game.
• [ x ] that I have checked whether there are updates for my system available.

<Log omitted, please see #3902>

Symptoms

While walking around on planets, the LOD fade-in effect is corrupted; parts of trees flash slowly on and off as you approach them, billboarded objects flash a noisy box when transitioning to the actual model, base parts flash orange noise on approach, etc.

Given this happens on both AMDVLK, RADV/LLVM and RADV/ACO but not on Windows, I suspect this could be a shader compiler glitch, but who knows... Haven't seen this reported anywhere at all, with only one reddit comment with a gif showing the artifact as well on a different AMD GPU.

(screenshot showing one instance of the billboard corruption in particular: https://imgur.com/a/zbStQ4T)

Reproduction

Simply launch the game on the above system configuration. (Or for that matter any GPU using the amdgpu driver)

Additional note: I am also not sure where else to report this, so apologies in advance if this is in the wrong place.

Hello @FuzzyQuills, mesa 20.1 has some commits which might help with what you're seeing, specifically https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4047. If you're able, please test the game with mesa 20.1.0-rc4 or git master.

Hello @FuzzyQuills, mesa 20.1 has some commits which might help with what you're seeing, specifically https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4047. If you're able, please test the game with mesa 20.1.0-rc4 or git master.

I swear that was a fix for something else from a long time ago, but duly noted. Looks like I'll have to work out how to build mesa on Debian...

Edit: actually never mind, looks like it was submitted to experimental two days ago, will try it soon.

Alright, so the fix is definitely working! Some base parts still flicker (namely the corridor ones, the floor has flickering triangles) but it's a _lot_ better. No more orange flashing.

Will test more after I've slept. Appears 20.1 is required for a glitch-free No Man's Sky.

Now that Mesa 20.1 has been released and contains a fix for No Man's Sky, can you confirm that it works fine? Thanks a lot!

I've never seen issues graphically with No Man's Sky, it may be just with the hardware I've got in my desktop or it has to do with using Arch Linux. But as I've commented before, there's gaemplay issues.

Now that Mesa 20.1 has been released and contains a fix for No Man's Sky, can you confirm that it works fine? Thanks a lot!

Currently my No Man's Sky seems fine. The LOD bug definitely is gone.

Since the crossplay patch however some planets are rendering invisible when you're far enough away from them. Since this didn't happen before the patch, this could be the game to blame

I've never seen issues graphically with No Man's Sky, it may be just with the hardware I've got in my desktop or it has to do with using Arch Linux. But as I've commented before, there's gaemplay issues.

What gameplay issues are you getting specifically? (Other than crashes)

The game crashes when leaving a planet.

I sometimes get a momentary freeze when first leaving a planet upon loading my save, but that happens on Windows as well so it's on the game there.

What version of Proton? I'm using 5.0-9 (latest)

I'm using Proton-5.6-GE-1

I'm using Proton-5.6-GE-1

I'm assuming you're launching through Steam? Try forcing specifically 5.0-9 and see if it helps fix it.
I can also give a GE build a go on my end and see if it crashes.

Yes, through Steam. I don't have access to my desktop right now which has the problem.

I played it on my laptop without issues and this seems to possibly be an issue with either having 2 NVidia GPUs (RTX 2060 and GTX 1050ti) or having a Ryzen 5 3600 which both my desktop has.

The game plays well for me, but there is one new issue as a result of their recent update: TLS 1.1 and 1.2 are required:

See 4th bullet at the bottom of the patch notes: https://www.nomanssky.com/2020/06/crossplay-patch-2-53/?cli_action=1592800239.205

It links to this site: https://support.microsoft.com/en-gb/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

Is there a way to enable these in Proton so that we can keep playing online?

TLS 1.1 has been end of life for two years now and enabling it would not be the smartest idea security wise

The game plays well for me, but there is one new issue as a result of their recent update: TLS 1.1 and 1.2 are required:

See 4th bullet at the bottom of the patch notes: https://www.nomanssky.com/2020/06/crossplay-patch-2-53/?cli_action=1592800239.205

It links to this site: https://support.microsoft.com/en-gb/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

Is there a way to enable these in Proton so that we can keep playing online?

Pretty sure Proton already uses 1.2 as I had Multiplayer working day one.
Update: deleting the proton prefix and letting it regenerate seems to have fixed multiplayer for me

TLS 1.1 has been end of life for two years now and enabling it would not be the smartest idea security wise

If Proton is using Windows 7 as the base OS version, it's likely it could be using TLS 1.0 instead, but given the crossplay update worked for me when it was launched, I don't think that's the case here.

I could be wrong, as I've done little investigation into the matter (not sure where to start really), but I can say that multiplayer is currently broken for people running Windows 7 and apparently for people running the game via Steam Play. The only way to play online is to play via Windows 10 (for now), I guess.

I could be wrong, as I've done little investigation into the matter (not sure where to start really), but I can say that multiplayer is currently broken for people running Windows 7 and apparently for people running the game via Steam Play. The only way to play online is to play via Windows 10 (for now), I guess.

That's what's strange; it only seemed to break for me after a friend tried adding my friend code; online discovery services and uploading bases seem to work, but matchmaking fails. I have a feeling given what I saw on a Steam Community Forum post that in my case adding his friend code should fix mine.

Will report back if that does work, as it was working two days ago for me. Running latest proton 5.0-9

edit: please see my latest comment

I could be wrong, as I've done little investigation into the matter (not sure where to start really), but I can say that multiplayer is currently broken for people running Windows 7 and apparently for people running the game via Steam Play. The only way to play online is to play via Windows 10 (for now), I guess.

That's what's strange; it only broke for me after a friend tried adding my friend code; online discovery services and uploading bases seem to work, but matchmaking fails. I have a feeling given what I saw on a Steam Community Forum post that in my case adding _his_ friend code should fix mine.

Will report back if that does work, as it was working two days ago for me. Running latest proton 5.0-9

Im not sure this is a Proton issue as much as a NMS issue, when the crossplay update first came out Navi GPU would crash landing on a planet and while its working ok atm its still a known issue regards to Navi. Crossplay is also very wonky atm with bugs to be worked out.

I could be wrong, as I've done little investigation into the matter (not sure where to start really), but I can say that multiplayer is currently broken for people running Windows 7 and apparently for people running the game via Steam Play. The only way to play online is to play via Windows 10 (for now), I guess.

That's what's strange; it only broke for me after a friend tried adding my friend code; online discovery services and uploading bases seem to work, but matchmaking fails. I have a feeling given what I saw on a Steam Community Forum post that in my case adding _his_ friend code should fix mine.
Will report back if that does work, as it was working two days ago for me. Running latest proton 5.0-9

Im not sure this is a Proton issue as much as a NMS issue, when the crossplay update first came out Navi GPU would crash landing on a planet and while its working ok atm its still a known issue regards to Navi. Crossplay is also very wonky atm with bugs to be worked out.

I've looked in the proton log and it actually looks like HTTPS in general is completely broken in Proton for some reason; No Man's Sky spams a bunch of "unsupported" messages from the winsock library, and in-game it's saying the matchmaking connection couldn't be made.

New update; finally decided to try downgrading proton, which forced my game's Proton pfx folder to get rebuilt. Soon as I did that multiplayer started working again, which points to an issue with the latest proton and certain prefix setups.

Can someone having issues with multiplayer try deleting the pfx folder for No Man's Sky so it's forced to rebuild it? If that doesn't work, try downloading version 4.11 then force No Man's Sky to use that version. That's what I did to get it to work, and after doing that, switching back to 5.0-9 also started working.

tl;dr: seems forcing a rebuild of the pfx folder fixes multiplayer, but I need to check if it's version-agnostic.

Update: just tested deleting and rebuilding with 5.0-9 and sure enough a fresh prefix from 5.0-9 breaks multiplayer. using 4.11 to build it then switching to 5.0-9 still works. (Tested by saving in the space anomaly and just reloading save after altering my Proton install)
This points to a regression in 5.0-9, maybe the EA Origin fix is related?

I may try comparing .reg files from the two versions, as I also noticed that the winhttp registry entries were missing

Have you tried the latest Proton-GE build, its unofficial but if it fixes issues for anyone then it might be worth looking into which specific patches resolved said issues.

Have you tried the latest Proton-GE build, its unofficial but if it fixes issues for anyone then it might be worth looking into which specific patches resolved said issues.

If there is a way to add it to Steam as a valid Proton install to use, I can try it, I don't have experience using GE builds otherwise

https://github.com/GloriousEggroll/proton-ge-custom/releases archive under Assets, extract it under ~/.steam/root/compatibilitytools.d/ folder (it should be in its own folder). Restart steam, look under NMS proton list.

It's generally good practice to wipe the game pfx folder between changing major proton versions. (from stock steam proton to custom protons like GE)

https://github.com/GloriousEggroll/proton-ge-custom/releases archive under Assets, extract it under ~/.steam/root/compatibilitytools.d/ folder (it should be in its own folder). Restart steam, look under NMS proton list.

It's generally good practice to wipe the game pfx folder between changing major proton versions. (from stock steam proton to custom protons like GE)

what's funny is that the pfx folder was never written over, it was only used by 5.0-9. Then out of the blue a No Man's Sky patch addressing crossplay bugs broke it on Linux on that version of proton.

Currently decompressing Proton-GE, will test now

Ok, so Proton-GE fails as well but if the prefix is generated at ALL by 4.11-13, it works fine with any proton version above it if the prefix is upgraded. I wonder what's messed it up

Edit: aaaand that nuked my saves somehow...
edit2: crisis averted, I had a backup lol

Fixed for me, thanks @FuzzyQuills.

Here are the steps for anyone reading along:

1. cd ~/.steam/steam/steamapps/common
2. rm -r "Proton 5.0"
3. In Steam, go to the Proton 5.0 entry. Right click it and click Properties. Go to the Local Files tab and press "Verify integrity of tool files".
4. Let Proton 5.0 redownload, and then open NMS and test.

Profit.

Fixed for me, thanks @FuzzyQuills.

Here are the steps for anyone reading along:

1. `cd ~/.steam/steam/steamapps/common`

2. `rm -r "Proton 5.0"`

3. In Steam, go to the Proton 5.0 entry. Right click it and click Properties. Go to the Local Files tab and press "Verify integrity of tool files".

4. Let Proton 5.0 redownload, and then open NMS and test.

Profit.

Going to try this with mine as well, must be a corrupted Proton dist file causing the bug.
Just a heads up; make sure to find your NMS save inside the prefix and back it up, as deleting the prefix may cause Steam Cloud to wipe your save. Wasn't aware of this until I nearly lost my 3 month old save. (I had a backup from my Windows partition)

Again, seems something is messed up in version 5.0-9, but I'll try this first since it worked for you

Yeah, I noticed the save was in the pfx directory so wanted to avoid deleting it. Reinstalling proton did fix it for me. Let me know your results.

Hello @FuzzyQuills, Proton 5.0 has changed the wineprefix from Windows 7 to Windows 10. What you've described is that the game changes its behavior in a win10 environment. When you run the game with Proton 4.11 to setup the wine prefix, it is set to win7 and it is expected to stay on that setting when you switch to Proton 5.0 for the second run.

Hello @FuzzyQuills, Proton 5.0 has changed the wineprefix from Windows 7 to Windows 10. What you've described is that the game changes its behavior in a win10 environment. When you run the game with Proton 4.11 to setup the wine prefix, it is set to win7 and it is expected to stay on that setting when you switch to Proton 5.0 for the second run.

Well then, so it isn't a proton bug as such, just weird behaviour.

Given some Windows 10 installs for other people were also failing, my guess is that this is actually a bug in No Man's Sky that also triggers on Proton 5. (maybe it incorrectly uses a code path meant for the gamepass version? wouldn't surprise me honestly)

I assume single player works? because NMS works for me but I haven't attempted to try Multiplayer yet.

@jarrard Yes single player is flawless for me. Was just having issues with multiplayer.

Yeah I'll test MP later tonight, however I don't know anyone to test with so hopefully it just lets you connect to any server.

Yeah I'll test MP later tonight, however I don't know anyone to test with so hopefully it just lets you connect to any server.

I think No Man's Sky is actually peer to peer based, so no servers can be picked.
If anyone on your friend's list (Steam or NMS, doesn't matter) plays it, either host a session yourself or get a friend to do so.

If you need a host, soon as my PC is working again (motherboard upgrade mishap nuked my OS drive) I'll volunteer my PC as tribute.

Yeah I'll test MP later tonight, however I don't know anyone to test with so hopefully it just lets you connect to any server.

Just fly into the Anomaly. If you see other people, it works. If you don't see anyone else, it's not.

For RADV users: This game should work perfectly fine with Mesa 20.1.2/ACO and latest game version 2.55. Can you confirm so that we can remove the "RADV" tag?

For RADV users: This game should work perfectly fine with Mesa 20.1.2/ACO and latest game version 2.55. Can you confirm so that we can remove the "RADV" tag?

I'm on 20.1.1/ACO via Debian Experimental, and my game's practically perfect barring some Z-fighting on certain base parts. (Only seems to affect one of my bases as well, others are fine)

What fixed multiplayer for me was just switching to Proton 4 from my existing 5 prefix, then back to 5. Everything worked perfectly at that point. I think Steam also reinstalled the dependencies during this process, which may have something to do with this bug.

What fixed multiplayer for me was just switching to Proton 4 from my existing 5 prefix, then back to 5. Everything worked perfectly at that point. I think Steam also reinstalled the dependencies during this process, which may have something to do with this bug.

That's what I initially did when I encountered the bug, then I tried wiping the wineprefix on both versions to see what they did. (Almost lost my save doing that... lol)

Hadn't played in about 3 months or so and decided to give it another try. Using a fresh install of archlinux, proton, and NMS I kept getting an error message most of the time before I could finish the loading screen. I managed to fix it by installing vulkan-radeon and uninstalling amdvlk. Now the game works perfectly. When either just amdvlk is installed or both amdvlk and vulkan-radeon are installed the above error appears. I have posted a screenshot of the error. I hope that this might help other people using AMD GPUs.

RADV is the most reliable vulkan driver for AMD cards atm, amdvlk (from amd) as you've found out has some issues.

Hadn't played in about 3 months or so and decided to give it another try. Using a fresh install of archlinux, proton, and NMS I kept getting an error message most of the time before I could finish the loading screen. I managed to fix it by installing vulkan-radeon and uninstalling amdvlk. Now the game works perfectly. When either just amdvlk is installed or both amdvlk and vulkan-radeon are installed the above error appears. I have posted a screenshot of the error. I hope that this might help other people using AMD GPUs.

The reason AMDVLK didn't work is actually due to an oversight in the AMDVLK packages; pretty much all of them fail to install the proper vulkan ICDs, you have to install them yourself. (Finding them on the internet isn't difficult thankfully)

With that said Mesa/ACO is way better for No Man's Sky, both performance and graphical artifacts wise. (A bug with LOD fade was fixed in Mesa 20.1, which also includes ACO)

Hadn't played in about 3 months or so and decided to give it another try. Using a fresh install of archlinux, proton, and NMS I kept getting an error message most of the time before I could finish the loading screen. I managed to fix it by installing vulkan-radeon and uninstalling amdvlk. Now the game works perfectly. When either just amdvlk is installed or both amdvlk and vulkan-radeon are installed the above error appears. I have posted a screenshot of the error. I hope that this might help other people using AMD GPUs.

The reason AMDVLK didn't work is actually due to an oversight in the AMDVLK packages; pretty much all of them fail to install the proper vulkan ICDs, you have to install them yourself. (Finding them on the internet isn't difficult thankfully)

With that said Mesa/ACO is way better for No Man's Sky, both performance and graphical artifacts wise. (A bug with LOD fade was fixed in Mesa 20.1, which also includes ACO)

I had the amdvlk IDCs installed so I know that wasn't the problem. Must have been a problem with the driver itself. Also I noticed that there is a new version of amdvlk just released so I'm going to test that and see if it fixes the problem. I will report back.

Edit: the new amdvlk works now without crashing. However it seems to have lower FPS than vulkan-radeon provided by mesa.

Yea, soon as RADV had the LOD issue fixed I stopped using AMDVLK altogether due to it performing much worse VS RADV/ACO. (Even LLVM was better than AMDVLK somehow)

No Man's Sky "No connection to matchmaking services" with Proton 5.0-9, works with 4.11-13

Issue transferred from https://github.com/ValveSoftware/Proton/issues/4082.
@JPLeBreton posted on 2020-07-18T16:22:36:

Compatibility Report

• Name of the game with compatibility issues: No Man's Sky
• Steam AppID of the game: 275850

System Information

• GPU:
• Driver/LLVM version: nvidia 440.82
• Kernel version: 5.4.44-1-MANJARO
• Link to full system information report as Gist: https://gist.github.com/JPLeBreton/27ee957c57ea36298312ca3a09eadd70
• Proton version: 5.0-9

I confirm:

• [X] that I haven't found an existing compatibility report for this game.
• [x] that I have checked whether there are updates for my system available.

steam-275850.log

Symptoms

Can't play multiplayer since the game's Cross Play Update last month. The older release version of Proton, 4.11-13, doesn't seem to have this issue.
Note that I can still connect to the game's "discovery services", ie the server that lets players log and see each other's discovered planets, bases, etc, just fine. I believe that's a whole separate kind of network access.

Reproduction

1. Launch the latest version of the game (2.60) with Proton 5.0-9.
2. Load a savegame.
3. Enter the options menu, and select the "network" section.
4. Observe: a box pops up that says "No connection to matchmaking services".
5. Quit the game and set it to run using Proton 4.11-13 instead.
6. Relaunch the game, load a save and enter the same options menu.
7. Observe: networking error doesn't occur as before.

Expected behavior: Multiplayer works with all versions of Proton.

I can confirm the network issue. good thing works like a charm on 4.11-13

@osdamv Did you try my comment? https://github.com/ValveSoftware/Proton/issues/438#issuecomment-648177961

Also guys if you happen to dualboot (I do for games that don't run reliably on proton yet) -- check system clock, if it's skewed even a little bit multiplayer won't work.

Yeah you can set windows clock to UTC which should prevent the time-flip each time you OS jump.

Yeah you can set windows clock to UTC which should prevent the time-flip each time you OS jump.

Or probably the easier method... Set Linux to use local time. timedatectl set-local-rtc 1

@simpleauthority Thanks is working now !

Hello all.
Thanx for amazing job, Proton team.

I have an issue with No man's sky for now. Few days ago i'm tried NMS, got periodically long time hangs. I've updated my system to latest kernel and issues is gone completely.
But today i have the same issue again. Game periodically (every 1-2 min) hangs completely - only sound play. This is true for proton4 and 5 - no any difference. Steam and game reinstall don't help.

My system specs and application logs:
sysinfo.log
steam-275850.log

When game hangs this strings appears:

3447.428:00bc:0138:fixme:winsock:convert_aiflag_w2u Unhandled windows AI_xxx flags 0x100
3448.420:00bc:0138:fixme:winsock:convert_aiflag_w2u Unhandled windows AI_xxx flags 0x100
3449.424:00bc:0138:fixme:winsock:convert_aiflag_w2u Unhandled windows AI_xxx flags 0x100
3450.425:00bc:0138:fixme:winsock:convert_aiflag_w2u Unhandled windows AI_xxx flags 0x100
3450.862:00bc:00c0:err:ntdll:RtlpWaitForCriticalSection section 0xd7f930 "?" wait timed out in thread 00c0, blocked by 0138, retrying (60 sec)
3451.428:00bc:0138:fixme:winsock:convert_aiflag_w2u Unhandled windows AI_xxx flags 0x100
3452.607:00bc:0138:fixme:winsock:convert_aiflag_w2u Unhandled windows AI_xxx flags 0x100
3453.416:00bc:0138:fixme:winsock:convert_aiflag_w2u Unhandled windows AI_xxx flags 0x100
3454.419:00bc:0138:fixme:winsock:convert_aiflag_w2u Unhandled windows AI_xxx flags 0x100
3455.604:00bc:0138:fixme:winsock:convert_aiflag_w2u Unhandled windows AI_xxx flags 0x100

havent been able to start NMS with any version of proton
i used to be able to play..... though it was several months ago

nvidia 1070
nvidia 440.100
linuxmint 19.3 (ubuntu 18.04 LTS)

this window pops up and thats it.

THE GAME HAS ENCOUNTERED AN ERROR AND WILL NOW SHUTDOWN

Token:
62637_0x7DCDDF_76561198095643958

protonlog is 140kb large

343342.359:0070:007c:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\wineusb": c0000142
343342.360:0030:0034:fixme:service:scmdatabase_autostart_services Auto-start service L"wineusb" failed to start: 1114

343342.729:0098:009c:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\user32.dll" at 0x7efddd520000: builtin
Setting breakpad minidump AppID = 275850
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198095643958 [API loaded no]
343342.765:0020:0024:err:steam:setup_vrpaths got error parsing vrpaths file
343342.884:0098:009c:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\ole32.dll" at 0x65000000: PE builtin

i think this is where it crashes, but im not for sure

343343.841:00bc:00c0:warn:debugstr:OutputDebugStringA "[S_API] SteamAPI_Init(): Loaded 'C:\\Program Files (x86)\\Steam\\steamclient64.dll' OK.\n"
343343.841:00bc:00c0:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b00fc3e ip=7b00fc3e tid=00c0
343343.841:00bc:00c0:trace:seh:raise_exception  info[0]=0000000000000056
343343.841:00bc:00c0:trace:seh:raise_exception  info[1]=000000000021c8d0
343343.841:00bc:00c0:trace:seh:raise_exception  rax=000000000021c450 rbx=00007fffffd9c000 rcx=000000000021c430 rdx=0000000000000000
343343.841:00bc:00c0:trace:seh:raise_exception  rsi=000000000021c530 rdi=000000000021c460 rbp=000000000021c870 rsp=000000000021c410
343343.841:00bc:00c0:trace:seh:raise_exception   r8=0000000000000002  r9=000000000021c520 r10=0000000000000000 r11=0000000000000246
343343.841:00bc:00c0:trace:seh:raise_exception  r12=0000000000d397f0 r13=0000000000000000 r14=000000000021d158 r15=0000000000000001
343343.841:00bc:00c0:trace:seh:RtlVirtualUnwind type 1 rip 7b00fc3e rsp 21c410
343343.841:00bc:00c0:trace:seh:dump_unwind_info **** func fbf0-fc77
343343.841:00bc:00c0:trace:seh:dump_unwind_info unwind info at 0x7b09a340 flags 0 prolog 0x11 bytes function 0x7b00fbf0-0x7b00fc77
343343.841:00bc:00c0:trace:seh:dump_unwind_info     0x11: subq $0xc8,%rsp
343343.841:00bc:00c0:trace:seh:dump_unwind_info     0xa: pushq %rsi
343343.841:00bc:00c0:trace:seh:dump_unwind_info     0x9: pushq %rdi
343343.841:00bc:00c0:trace:seh:dwarf_virtual_unwind function 7b439bb1 base 0x7b439968 cie 0x7b496a90 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip

ive tried .Net version 4.8
im just not sure what i need to install with protontricks to get this to work...

It shouldn't require anything extra to make it work. Try proton-GE, and perhaps GE-5.0 as sometimes when wine updates, things break.

Those who're crashing, have you tried a newer nvidia binary? Seems like 440.100 is crashing for a lot of people. I played using 450.57, and no problems this past week.

It shouldn't require anything extra to make it work. Try proton-GE, and perhaps GE-5.0 as sometimes when wine updates, things break.

negative, i use 4-11, 5.0 and proton-ge-5.9

Those who're crashing, have you tried a newer nvidia binary? Seems like 440.100 is crashing for a lot of people. I played using 450.57, and no problems this past week.

since nvidia 440.x is longterm i was hesitant to update to the new latest 450.x branch
no problems with the update, however it doesnt fix the NMS issue.
every other proton/linux/wine/vulkan WHATEVER game runs perfectly fine
so, its something to do with NMS specifically and whatever custom libraries i have

same error

62637_0x7DCDDF_userid#

SOLVED.
Completely UNINSTALL and wipe everything
reinstall through steam
ACCEPT EULA
for some reason the EULA was causing me a huge problem, although i played this game previously

I was trying this out the other week under Linux on my 1080TI at 4k and I had a few issues, first was vkbasalt or mangohud were causing crashing after 10s or so, mangohud was unable to report the GPU vram or clock setting/usage.

The other issue was I had major performance issues where the frame would keep dropping down to 10-20fps continuously like a wave depending on where I was looking.. was unplayable. Went back to windows, no issues.

Playing this on a 2080 Ti. Uncapped I was getting (an extremely variable) ~100 fps, but with VSync on it was failing to achieve a 60 fps lock, being very stuttery and hovering in the 50s. Dropping the texture resolution right down helped somewhat, but not that much.

Applying the spoofing fix fixed it right up. Stable framerates and much better performance, with everything set as high as it will go. Something about the game's Nvidia-specific code path for texture streaming still just doesn't seem to be working right.

In both cases the game's only using 3-4 GB of VRAM of the 11 GB I have available.

Just installed proton-ge-custom-bin from AUR today and I'm having a graphical issue with the latest drivers. Any fixes?

Not sure if it is a regression but now No Man's Sky is not working in VR here. Sent my Valve Index to RMA, it returned, works with all games (88 VR games) except for No Man's Sky, and it worked perfectly before. Tried with and without the NVIDIA AMD spoofing trick, tried completely uninstalling and purging 275850 compatdata directory and then reinstalling, tried verifying files, trying different NVIDIA drivers, tried different proton versions besides 5.0-9 default, tried both running from the steam client and selecting "Run game in HMD" and from inside SteamVR Home, to no avail. What happens: I call the game, the thumbnail of the game loading in the headset screen appears for a few seconds, but then the game starts in the monitor and of course does not respond to the Index controls. It's like it can't initialize/access VR, but since I completely uninstalled and reinstalled and even verified the files it should be able to use openvr_api.dll or whatever it uses, doesn't make sense.

gist of my configuration: https://gist.github.com/Patola/acbcb1b52ab975f9b02f8e888b325de8 (I have a newer NVIDIA driver now though). Same thing both in Arch and Ubuntu 20.04.1.

Got a post in gamingonlinux mentioning it: https://www.gamingonlinux.com/forum/topic/4619/post_id=

steam-275850.log

Hello @Patola, err:vrclient:create_win_interface Don't recognize interface name: IVRSystem_022 looks like the line of interest from the log.

Thank you very much @kisak-valve , I will try and search what does that mean and try to come up with solutions to the problem. If I fix it, I will tell here.

So... It is a version of IVR System that SteamVR Linux still doesn't support, is it? It supports IVRSystem up to 021?

@Patola Thanks for reporting. I'll have this fixed in an upcoming Proton release.

Thanks. I tried to fiddle with the vrclient_x64 directory of proton to try and add IVRSystem_022 based on the older ones, it didn't work. Lame attempt, but it was worth the try. I'll wait for the upcoming Proton release.

Ok, it seems Proton 5.13-1 just broke No Man's Sky completely (VR or otherwise)? The PROTON_LOG is attached.
steam-275850.log

@Patola I am able to get in-game and move around on the first planet, so it's at least not completely broken :) Are other games working for you in 5.13, or are all games broken?

VR mode is indeed not fixed. I'm still working on that.

I've only ran a couple games and they worked under 5.13, I will try at least 20 other games today to see if it affects them too.

@aeikum I am terribly sorry. I do not know what changed but after I've tested a dozen games successfully under Proton 5.13-1, I ran No Man's Sky again (non-VR mode) and it ran successfully. It now took a while to compile shaders first, but it ran ok. I do not know why it hasn't run that time. Please disregard my latest steam-275850.log. I even tried the VR version again (didn't work but fell back to the pancake mode) and then ran it back in pancake mode and it worked.

Great! I'm very happy to hear it :)

Did you have a python update? I did, and was having similar issues to you. I relogged, and proton worked again.

Indeed. Yesterday when I had this problem, python-xlib was updated.

I can also confirm that the game runs fine in "pancake" mode on 5.13-1. I'm unfortunately also experiencing problems with running the game in VR mode on my Index.

Please note stuff like Mangohud can cause crashing in certain games such as NMS where once you leave first planet, mangohud (if it even shows on screen) will CTD the game.

I'm getting the same error that @Patola was showing in their log file. I'm on Manjaro with a GeForce GTX 1080 and all software is up to date. I haven't had it working yet before, just tried to install NMS today.

Grateful for any suggestions!

Sorry, I realized I didn't attach my own log file...
steam-275850.log

For RADV users: Do you still have rendering issues with that game and Mesa 20.2.x ? I think we fixed all known issues, so the RADV label could be removed but asking for a confirmation first.

For RADV users: Do you still have rendering issues with that game and Mesa 20.2.x ? I think we fixed all known issues, so the RADV label could be removed but asking for a confirmation first.

Radeon RX 5700 XT; AMDGPU with kisak-mesa fresh ppa (20.2.1 atm) ; Linux Mint 19.3; Kernel 5.8.16
I have no rendering errors. But I'm not sure if I had any because I haven't played for a while. I only play it again with the last DLC.

Maybe others who have reported the mentioned errors can add something.

RX 5700, mesa 20.3-git-2b977a. Resolution scaling causes strange blocky lighting artifacts (ACO and LLVM, this issue has existed for me since resolution scaling was added to NMS), and high resolution textures take a long time to load in (ACO only, I seem to remember seeing a bug report open somewhere about this but I can't find it...). Haven't spotted any other issues, I think they're all fixed.

Image of lighting artifacts:

No Man's Sky

Issue transferred from https://github.com/ValveSoftware/Proton/issues/4342.
@taldarus posted on 2020-11-02T18:17:07:

Compatibility Report

• Name of the game with compatibility issues: No man's sky
• Steam AppID of the game: 275850

`System Information

• GPU: GeForce GTX 970
• Driver/LLVM version: nvidia v: 390.138
• Kernel version: 5.4.0-52-generic x86_64
• Proton version: 3.16, 3.7 are both installed, but I thought I was using 5.13/up to date

I confirm:

• [X] that I haven't found an existing compatibility report for this game.
• [X] that I have checked whether there are updates for my system available.

Log:
Did this got nothing, see the problem.

Symptoms

Run the game and I am getting still getting "SteamAPI_Init failed. No license or steam isn't running."

I wasn't up to date when the error started, I have rebooted and restarted everything multiple times.

Sorry if this is the wrong place. I mostly want to return game atm, but it's for my kids. I searched multiple times and turned up nothing. It feels like a missing file, not a compatibility issue, but steam support drone referred me to here.

Reproduction

It's easy to reproduce :)

I just hit play and it doesn't work. Sorry I can't give you a fancy log, as steamAPI is the problem, so asking it for a log doesn't work.

Hello @taldarus, the nVidia 390 driver series is older than the support cutoff for Proton, please update to a newer driver series. Also, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

Starting with Proton 5.13, Proton now runs on top of Steam Linux Runtime - Soldier which is a container environment setup by Pressure Vessel. Since PROTON_LOG=1 isn't generating a log with Proton 5.13, that hints that you might have encountered an issue with Pressure Vessel. Please completely close Steam, then run Steam from a terminal and check if there are any hints in the terminal spew when trying to run the game. If you're using the Debian modified Steam package, then it might intercept any hints and put it in ~/.steam/error.log.

System Info Real Fast: https://gist.github.com/taldarus/d91b4d730a9d11eb0c186aa0a270f124
Terminal Spew: https://gist.github.com/taldarus/274fad28c4c728c90177bed96c8ec91d

That is a bit confusing, because that looks like I should run in elevated privileges, which I understand to be a traditional no-no. So I will go ahead and do it and see if I get more data.

Post Nvidia Terminal Spew: https://gist.github.com/taldarus/5d8b01c5266c8a2d0f567bc1934609f2

And steam is doing something strange, I saw it try to update itself. So that looks promising. I will tinker for a moment.

Final Edit (Probably):
At this point I have got the problem (it appears that mint 19.3 -> 20 went through a 64bit change that was significant). Starting with Nvidia, I quickly hit all sorts of little bugs, and it eventually led me to updating to 20.x. I have not confirmed it will fix the problem, but the update process has been running for almost two hours now. (2000 packages needed updating O.o)

I remember it wanting to update to 20.0, and I told it to wait. At least I thought it was wait, because it flat out refused to tell me about this update again. If it doesn't fix the problem I will post again. Hopefully the game will work in a bit.

Thanks for the assistance Kisak

Hi @aeikum, I've noticed a new release of Proton-5.0 (5.0-10) and updated Proton and tried running No Man's Sky in VR with this particular version. Crashed at start with a generic dialog window asking me to contact support, even tried completely uninstalling, removing the 275850 compatdata (I don't know why steam does not remove these after uninstall), and then installing it again straight from Proton 5.0. Works perfectly in pancake mode, but crashes with the same generic message.

Was this Proton release supposed to solve the problem with No Man's Sky VR? I say that because having updated openvr compatibility, I thought it would.

In any case, I am attaching the steam log if you guys need it
steam-275850.log
.

Unfortunately no. The game is hitting some new bug, which I have looked into, but was unable to solve. I've filed a bug for it in our internal tracker, but I don't have any estimate on when it will be fixed. (It's passing what is apparently an invalid VkPhysicalDevice handle in to an OpenVR function, which causes the crash. I don't know why it is doing that.)

@aeikum Does the new Proton 5.13-2 RC have any fixes for No Man's Sky in VR mode?

@rstrube No.

Updated to Mesa 20.2.2 from Kisak's PPA mesa-fresh and No Man Sky doesn't render any in game graphics anymore

Initial menus and star field animation render correctly.

However on the game screen everything is black as in no graphics are being rendered other than labels.

The in-game menus also work 100%

I'm using a RX480 8GiB card on Ubuntu 18.04.5

Any other game I have been able to test works fine.

This started happening right after the update to 20.2.2 on the previous version ran 100% fine on my computer.

Updated to Mesa 20.2.2 from Kisak's PPA mesa-fresh and No Man Sky doesn't render any in game graphics anymore

Initial menus and star field animation render correctly.

However on the game screen everything is black as in no graphics are being rendered other than labels.

The in-game menus also work 100%

I'm using a RX480 8GiB card on Ubuntu 18.04.5

Any other game I have been able to test works fine.

This started happening right after the update to 20.2.2 on the previous version ran 100% fine on my computer.

I can confirm this. After updating to Kisak mesa-fresh 20.2.2 from previous 20.2.1 I have the same problems. IOnly a black screen is displayed ingame. The textures are not rendered. Only the screen icons that mark special places or waymarks are still displayed. Also the ingame menus and the star screen in the loading sequence work the same way.

So I removed the PPA and now use the Mesa 20.0.8 which comes with Linux Mint 20 (based on Ubuntu 20.04 LTS) as default and so it works fine again. The only thing I have now is the texture errors that were known in the past.

Specs:
Linux Mint 20
Kernel 5.8.16
AMDGPU
AMD Ryzen 3600
AMD RX 5700 XT

Thanks for bringing the driver snafu to my attention @nentibusarchitectura, and @KuJo-Ger. As of right now the issue is in my set of early backports for mesa, and not currently an upstream mesa issue. I'll see what I can find for the 20.2.3 build.

Update: The offending patch has been identified and will be backed out in the next PPA build.

As of right now, there's no hints that mesa 20.2.3 is going to roll out on schedule, so I've pushed mesa 20.2.2~kisak2 to the build farm which should fix the PPA specific regression. Thanks again for finding the issue.

As of right now, there's no hints that mesa 20.2.3 is going to roll out on schedule, so I've pushed mesa 20.2.2~kisak2 to the build farm which should fix the PPA specific regression. Thanks again for finding the issue.

I have reinstalled your PPA - and the game runs fine again. The textures are rendered correctly again.

@kisak-valve:
You thank us for finding the issue. But we have much more to thank you for providing us with this great PPA!

Hi Kisak,

Can confirm that the newer version on your Mesa-Fresh PPA fixes the issue for me too.

Many thanks for your hard work, it is much appreciated.

Unfortunately no. The game is hitting some new bug, which I have looked into, but was unable to solve. I've filed a bug for it in our internal tracker

@aeikum Also experiencing the same issue as @Patola and @rstrube, perhaps it's worth reaching out to the developers as they seem supportive of Proton given their previous fixes?

https://hellogames.org/contact