Proton: Ashes of the Singularity: Escalation (507490)

[ananace]

Compatibility Report

• Name of the game with compatibility issues: Ashes of the Singularity: Escalation
• Steam AppID of the game: 507490

System Information

• GPU: RX580 8GB
• Driver/LLVM version: Mesa 18.1.8, LLVM 6.0.1
• Kernel version: 4.18.6
• Link to full system information report as Gist: https://gist.github.com/ananace/fec7a290582e7d7070af19b675ac074d
• Proton version: 3.7-6 Beta

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-507490.log

Symptoms

The launcher fails to load, crashing with an error about not being able to load gamedata.dat.
Replacing the StardockLauncher.exe binary with AshesEscalation.exe to bypass the launcher lets the game launch, until it finishes loading assets and then freezes.

Reproduction

Replace StardockLauncher.exe with AshesEscalation.exe, launch the game.

Using regular WineD3D11 shows no difference, except for taking longer to finish loading the assets.

Where it freezes;

[andrebadaia]

Confirmed. I had the same issue.

Distro: Linux Mint 19 Tara
Processor: AMD Ryzen 7 1700
GPU: GTX 1070, Nvidia proprietary driver 396.54
RAM: 32GB
Kernel (custom) - 4.17.14 (optimized for Ryzen)
Resolution: 1920x1080
Proton 3.7-6

[logan001]

not working for me
error.log shows a weird message

Game update: AppID 507490 "", ProcID 5277, IP 0.0.0.0:0
ERROR: ld.so: object '/home/dan/.steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
>>> Adding process 5294 for game ID 507490
ERROR: ld.so: object '/home/dan/.steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 5297 for game ID 507490
AL lib: (WW) GetSymbol: Failed to load jack_error_callback: /usr/lib/x86_64-linux-gnu/libjack.so.0: undefined symbol: jack_error_callback
AL lib: (WW) jack_msg_handler: Cannot connect to server socket err = No such file or directory
AL lib: (WW) jack_msg_handler: Cannot connect to server request channel
AL lib: (WW) jack_msg_handler: jack server is not running or cannot be started
AL lib: (WW) jack_msg_handler: JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
AL lib: (WW) jack_msg_handler: JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
AL lib: (WW) ALCjackBackendFactory_init: jack_client_open() failed, 0x11
AL lib: (WW) alc_initconfig: Failed to initialize backend "jack"
AL lib: (EE) SetChannelMap: Failed to match front-center channel (2) in channel map
Installing breakpad exception handler for appid(gameoverlayui)/version(20180908192109)
Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)
Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)
Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)

I have a creative x-fi fatality pro which has 7.1 sound. i have no clue why i'm getting that message about jack server. i've never used jack server
weird
game freeze with turinium optimized

[ananace]

not working for me
error.log shows a weird message

...

I have a creative x-fi fatality pro which has 7.1 sound. i have no clue why i'm getting that message about jack server. i've never used jack server
weird
game freeze with turinium optimized

Those messages are probably related to using the Wine XAudio DLLs, you could get rid of them using winetricks/protontricks and installing xact, though it won't solve the game issues as they're not audio related.

[logan001]

is there any way to find out what is the problem with the game in proton?
i've seen a lot of people saying that they can play the game.
Here are my system infos
ive tried also arch linux with 4.18 kernel.
no luck there also
the only think in common is cinnamon DM

[logan001]

btw
another strange thing is that launcher can't find setting file when you try to edit it.
it even offer you the option to save it in a "strange" path.
it seems like launcher and wine are not working well togheter

[HonkingGoose]

@flibitijibibo This seems somewhat related to XAudio2 too?

From original post Proton log:

394966.649:0025:0026:trace:module:load_dll looking for L"C:\windows\system32\xaudio2_7.dll" in L"C:\windows\system32;C:\Program Files (x86)\Steam;C:\windows\system32;C:\windows\system;C:\windows;.;C:\windows\system32;C:\windows;C:\windows\system32\wbem"

But it seems that the game not loading issue stems from something other than Xaudio, according to user ananace:

Those messages are probably related to using the Wine XAudio DLLs, you could get rid of them using winetricks/protontricks and installing xact, though it won't solve the game issues as they're not audio related.

[flibitijibibo]

In addition to checking for xaudio2_x, it's also a good idea to check for x3daudio1_*, as some games might only use XAudio2 as a basic output stream, and the current builtin should handle that without any trouble. This seems to fall into the X3DAudio category so it probably is actively used, but you're right in that there's probably something bigger going on with this one...

[7oxicshadow]

I have found 2 problems with Proton and Ashes so far:

In game settings not saved across restart

Proton 3.16 beta now uses a Compatdata folder for the pfx folder. In the pfx/drive_c/users/steamuser folder there is no symlink to "My Documents" folder. Creating a symlink to Documents in your home folder fixes this and allows the game to save settings in the settings.ini.
_(Note: The "edit settings file" from the launcher still does not open properly. Ignore this, the settings from ingame will be saved with the above fix.)_

Multiplayer is disabled:

Multiplayer is disabled and if we look at the run log it shows:

ChecksumManager: Checksum_GameCore_Summary does NOT match!

Reading on the internet suggests that some windows users have suffered from this problem and it appears to be caused by installing Ashes on a drive that is not C:/. This is a problem for Proton as it maps any linux location to Z:/ (this is confirmed in the Ashes runlog.txt).
Executable Path: Z:\mnt\ssd_games\native_steam\steamapps\common\Ashes of the Singularity Escalation\AshesEscalation_DX11.exe

Hopefully a Proton dev will be able to chip in on this one to see if there is any workarounds for the Z:/ mapping issue

[7oxicshadow]

Also this game will not launch for me unless I set the following launch options to the following in steam:

PROTON_NO_ESYNC=1 %command%

[douglasg14b]

When you say

Replace StardockLauncher.exe with AshesEscalation.exe, launch the game.

What does that entail exactly? There are many different actions that could match that.

---

If I cop and rename AshesEscalation.exe to StardockLauncher.exe overwriting the initial one the same issue persists where the game just immediately closes when launching.

It seem it might be a pathing issue? As the game can't find it's settings.ini, even though it clearly exists.

[ananace]

In my case, I just copy the game executable on top of the launcher,
overwriting it.

On Fri, 11 Jan 2019, 08:03 Douglas Gaskell <[email protected] wrote:

When you say

Replace StardockLauncher.exe with AshesEscalation.exe, launch the game.

What does that entail exactly? There are many different actions that could
match that.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1479#issuecomment-453400872,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAgnvKCoSiNQGxab8Y7C0yljJU27jKRgks5vCDdTgaJpZM4WqyZX
.

[douglasg14b]

@ananace So renaming the executable to StardockLauncher.exe overwriting it?

[7oxicshadow]

rename StardockLauncher.exe to StardockLauncher.exe.bak
rename AshesEscalation.exe to StardockLauncher.exe

Be aware you might need the NO_ESYNC option. This is required by some but not by others. Not sure why. If I do not set the NO_ESYNC option the game will instantly close

Also this game will not launch for me unless I set the following launch options to the following in steam:

PROTON_NO_ESYNC=1 %command%

[douglasg14b]

@7oxicshadow Thanks! This confirms what I have been trying.

Unfortunately, in my case, the game still instantly closes after opening. Do you know where I might be able to find a log that says why? Unfortunately the system log doens't have anything, and there is no error log in the ashes folder.

[7oxicshadow]

try renaming AshesEscalation_DX11.exe to StardockLauncher.exe instead

[douglasg14b]

Tried the dx11 and vulkan ones too (and dx12 for good measure, tho never expected that to work) since I read other people having success in dx11 or vulkan mode.

Looking to find out what I can do to diagnose or find error logs at this point.

[7oxicshadow]

i assume you are using either the nvidia or amd binary drivers?

[douglasg14b]

Basic System info:

Proton:3.16-6
Distro:Ubuntu 18.10
Kernel:4.18.0-12-generic
RAM:32 GB
GPU Driver:4.4 Mesa 18.2.2
GPU:Radeon RX 580
CPU:AMD Ryzen 7 2700X Eight-Core

[7oxicshadow]

Hopefully someone with an AMD setup will be able to tell you if that is the best driver or not. I think the Mesa driver is still missing support for some DXVK functions/Extensions.

All I can recommend is to check that you are using proton 3.16-6 and that "use this tool instead of game-specific selections from steam" is also ticked on the steam play settings page.

[ananace]

In my case;

CPU: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
GPU: Radeon RX 580 Series (POLARIS10, DRM 3.26.0, 4.18.0-sabayon, LLVM 7.0.0)
Driver: 4.5 (Compatibility Profile) Mesa 18.3.1

I've been playing some skirmishes on Ashes with the Mesa radv driver, so it certainly implements enough features to run this game.

My suggestion on debugging is to run Steam in a terminal so you can see any output in there, and possibly also adding PROTON_LOG=1 to the launch, it'll produce a full Wine log in your home directory which might help on if it's a Wine issue that causes the issue for you at @douglasg14b .

[douglasg14b]

Thanks!

Was able to see some error in the wine log, not sure how helpful it is though:

wine: Unhandled page fault on read access to 0x00000000 at address 0x1403fab5b (thread 0025), starting debugger...
696114.801:0024:0025:trace:seh:start_debugger Starting debugger "winedbg --auto 36 148"
696115.492:0024:0025:trace:seh:call_teb_handler handler at 0x7b4a0c30 returned 1
696115.492:0024:0025:warn:seh:call_stack_handlers exception data not found in L"AshesEscalation_DX11.exe"

See the same error for the vulkan one as well. Hm.

[iicurtis]

Regarding the failed validation. If you re-verify the steam files, 1 file gets fixed. These are the files that are modified while steam verifies and fixes the files:

/SteamLibrary/steamapps/downloading/507490/gamedata.dat
/SteamLibrary/steamapps/downloading/state_507490_580374.patch
/SteamLibrary/steamapps/compatdata/507490/version
/SteamLibrary/steamapps/compatdata/507490/pfx.lock

The steam steamclient.dll and steamclient64.dll get modified as well. So does openvr_api_dxvk.dll and vrclient.dll.

When the game is run the following files are modified:

/SteamLibrary/steamapps/compatdata/507490/pfx/reg41950000.tmp
/SteamLibrary/steamapps/compatdata/507490/pfx/drive_c/users/steamuser/Local Settings/Temporary Internet Files/Content.IE5/2J1WR8SC/gamedata.337[0]
/SteamLibrary/steamapps/compatdata/507490/pfx/drive_c/users/steamuser/Temp/gamedata.dat
/SteamLibrary/steamapps/common/Ashes of the Singularity Escalation/gamedata.dat
/SteamLibrary/steamapps/compatdata/507490/pfx/drive_c/users/steamuser/My Documents/My Games/Ashes of the Singularity - Escalation/RunLog.txt

I think the safe bet is that gamedata.dat is getting modified. I just don't understand why that is happening.

[tatsujb]

Glad some people are taking a look at this, I'm going to try it out too,

btw guys this is supposed to have a native port to linux sometime this year (2019). It was always Stardock's plan to eventually support linux for this game, so don't sweat it too hard :P

this guide allowed me to run it on my first try! thanks! :

rename StardockLauncher.exe to StardockLauncher.exe.bak
rename AshesEscalation.exe to StardockLauncher.exe

Be aware you might need the NO_ESYNC option. This is required by some but not by others. Not sure why. If I do not set the NO_ESYNC option the game will instantly close

Also this game will not launch for me unless I set the following launch options to the following in steam:
PROTON_NO_ESYNC=1 %command%

runs acceptably for me, haven't tried multi but I don't see the point given how laggy this is.

I'd used this same rig under windows and was getting night-and-day performance from this. I never tried wine or proton on it because I didn't think it'd run well and now I've confirmed it.

Here's hoping Stardock hurry up. they had already promised the linux port for Q4 2018, it keeps getting pushed back.

[douglasg14b]

A linux port will be great! Also funny seeing you here as well @tatsujb :smile_cat:

[tatsujb]

well.... RTS-ers are nothing if not devoted to the genre ;)

[logan001]

i can't start the game with vulkan api. do i need to do anything?
the game starts but i get only the mouse and an empty window - as in whatever was in the background before the game starts will be in the game windows like a screenshot

[7oxicshadow]

It sounds like you are getting the launcher without graphics. This used to be an issue for me but was fixed with the latest proton builds.

If you look at the attached screenshot and estimate where the play button is and click it the game should launch.

This game runs great with proton now. Multiplayer works and everything with proton 4.2-2

[douglasg14b]

@7oxicshadow How did you get proton 4.2-2? I don't see that option in my steam install.

[7oxicshadow]

I have seen that happen before. Force steam to check for updates (Steam > Check for steam client updates). It should find it.

[douglasg14b]

Got it.

Unfortunately Ashes still just crashes as soon as I hit play in the launcher 0n 4.2-2 :/

[7oxicshadow]

@douglasg14b I am assuming you have tried with and without PROTON_NO_ESYNC?

The only other place that will yield some possible information is the AshesEscalation_DX11_d3d11.log and the AshesEscalation_DX11_dxgi.log.

These are created by DXVK when launching the game. They are located in the same directory as the AshesEscalation executables. If you are having vulkan issues it will tell you the most likely cause in there.

[douglasg14b]

@7oxicshadow I'm running with PROTON_NO_ESYNC=1 yeah.

Here is what I see under `StardockLauncher_dxgi.log:

info:  Game: StardockLauncher.exe
info:  DXVK: v0.94-18-g3b3ccc8
warn:  OpenVR: Failed to initialize OpenVR
info:  Required Vulkan extension VK_KHR_get_physical_device_properties2 not supported
info:  Required Vulkan extension VK_KHR_surface not supported
info:  Required Vulkan extension VK_KHR_win32_surface not supported
err:   DxvkInstance: Failed to create instance

[kisak-valve]

Hello @douglasg14b, please verify you have vulkan drivers installed for your video card with something like apt policy mesa-vulkan-drivers mesa-vulkan-drivers:i386 and install them if they are not.

Also, looks like you've encountered https://github.com/ValveSoftware/steam-for-linux/issues/6093. Please opt into Steam's beta client and/or go to Steam -> Library dropdown -> Tools and install Proton 3.16 beta on the list.

[douglasg14b]

@kisak-valve

I didn't made mesa drivers installed, somehow. Installed them and it starts up! Doesn't look like Vulkan works though, only DX11.

Thanks!

[tatsujb]

@kisak-valve @douglasg14b @7oxicshadow stardock promissed a linux port of AOTS. trying to make it run on proton may be a waste of time :)

[ananace]

I was able to play a few hours with a Windows-using friend, so I think
there's not actually all that much left to "make it run" so to speak.

And I can't imagine that work spent improving Ashes won't be useful for
other applications, so I'm certainly all for it.

On Fri, 19 Apr 2019, 12:51 tatsujb, [e-mail] wrote:

@kisak-valve https://github.com/kisak-valve @douglasg14b
https://github.com/douglasg14b @7oxicshadow
https://github.com/7oxicshadow stardock promissed a linux port of AOTS.
trying to make it run on proton may be a waste of time :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1479#issuecomment-484849974,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAECPPHDL5PE3SL6JRHKVL3PRGPZ5ANCNFSM4FVLEZLQ
.

[tatsujb]

@ananace @d10sfan as you guys can see here : https://github.com/ValveSoftware/Proton/issues/1479#issuecomment-458227447 I ran it without much effort. it's just the performance is crap and I don't want the devs to get the impression that their port is "not needed"

[7oxicshadow]

@tatsujb If I run the benchmark on "crazy" I get 45 FPS as the average score which is really good under DX11. (That is with 6700k @ 4.5 with GTX 1070). It is pretty much perfect under Proton for me.

As for not wanting to put the devs off making a Linux port, you don't have to worry. They are not making the port for the home user, they are making it for Google stadia compatibility. On the steam discussion the devs mentioned that there was renewed interest in making a linux port but could not go into details, then Stadia was announced and the devs followed up with a statement effectively saying "now you can see why".

[7oxicshadow]

Just to clarify my statement above. Linux users will get support on home PC's because of Stadia. Not the other way round.

[tatsujb]

well to me it's worrysome stadia needs to be the reason why they're doing it rather than that they promised to in the first place.

I guess the positive attitude way of looking at it is at least now we have some sort of guarantee.

that being said if I understood correctly stadia is meant to use some form of proton/wine for non-ported games, is that correct?

[aufkrawall]

The game just works here in Proton 4.11-6 (also with fsync) and doesn't seem to show any issues with DXVK.
However, when selecting the game's native Vulkan renderer, it complains about the driver not being compatible (refuses to start because of some silly driver version check?). This is the case with RX 570 8GB on radv, amdvlk-open and amdvlk-proprietary.

[Leopard1907]

Game regressed on Proton 4.11. It just doesn't work with 4.11. Tries to load the game then just hangs i think.

4.2 still works and even native vlk works but with a caveat. At least for once you have to use PROTON_USE_WINED3D=1 if you want to select native vlk from options and to be greeted with it. Without use wined3d option, it will always keep working on dx11.

rename StardockLauncher.exe to StardockLauncher.exe.bak
rename AshesEscalation.exe to StardockLauncher.exe

Also have to be applied as noted on other messages. There are sound issues with the game as well ( workarounds exists on ProtonDB) but i just wanted to see if it does work with native vlk or not.

My launch options were like this after changing to native vlk and to be sure that is ( wined3d) needed for once:

PROTON_NO_ESYNC=1 PROTON_NO_FSYNC=1 DXVK_HUD=version VK_INSTANCE_LAYERS=VK_LAYER_MESA_overlay

For changing native vlk at first you need this:

PROTON_NO_ESYNC=1 PROTON_NO_FSYNC=1 DXVK_HUD=version VK_INSTANCE_LAYERS=VK_LAYER_MESA_overlay PROTON_USE_WINED3D=1

Once you have changed to native vlk , you won't need wined3d launch option anymore.

DXVK hud options are there because i just wanted to make sure i'm not on dxvk by any weird random nuisance caused by game.

Here are some logs:

steam-507490-tryingtochangevlk.log
steam-507490-wined3d11.log

steam-507490-workswithnativevlk.log.tar.gz

My system info:

https://gist.github.com/Leopard1907/36697cb0a2e68465e648a9725c0a38a0

Screenshot of it when it does actually worked with native vlk , might not be possible on radv:

[kisak-valve]

Hello @Leopard1907, can you check if Proton 4.11-8 and the DirectX 11 backend behaves with WINEDLLOVERRIDES="dxgi=n" %command% in the game's launch options? If not, then re-add the no-esync/fsync options.

[Leopard1907]

Hi @kisak-valve , that is not a wine/dxvk dxgi regression. Simply game regressed on 4.11.

But i did what you've suggested anyway , game just silently dies.

Here are the logs:

steam-507490-dxvkdxgi.log
steam-507490-nosync.log
steam-507490-winedxgi.log

[roemhildtg]

I'm running into similar issues I think. Here's my system info and logs:

https://pastebin.com/YiRUKCLb

Operating System: Manjaro Linux
KDE Plasma Version: 5.17.3
KDE Frameworks Version: 5.64.0
Qt Version: 5.13.2
Kernel Version: 5.3.11-1-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-4690K CPU @ 3.50GHz
Memory: 15.5 GiB of RAM

Nvidia Graphics/GTX 970

[gregg@gregg-pc ~]$ inxi -Fx
System:    Host: gregg-pc Kernel: 5.3.11-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.2.0 Desktop: KDE Plasma 5.17.3 
           Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: Gigabyte model: Z97MX-Gaming 5 v: x.x serial: <root required> UEFI: American Megatrends v: F6 
           date: 09/18/2015 
CPU:       Topology: Quad Core model: Intel Core i5-4690K bits: 64 type: MCP arch: Haswell rev: 3 L2 cache: 6144 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 28009 
           Speed: 1304 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 2939 2: 2586 3: 3069 4: 2836 
Graphics:  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics vendor: Gigabyte driver: i915 v: kernel 
           bus ID: 00:02.0 
           Device-2: NVIDIA GM204 [GeForce GTX 970] vendor: Micro-Star MSI driver: nvidia v: 440.31 bus ID: 02:00.0 
           Display: x11 server: X.Org 1.20.5 driver: nvidia resolution: 2560x1080~60Hz 
           OpenGL: renderer: GeForce GTX 970/PCIe/SSE2 v: 4.6.0 NVIDIA 440.31 direct render: Yes 
Audio:     Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio driver: snd_hda_intel v: kernel bus ID: 00:03.0 
           Device-2: Intel 9 Series Family HD Audio vendor: Gigabyte driver: snd_hda_intel v: kernel bus ID: 00:1b.0 
           Device-3: NVIDIA GM204 High Definition Audio vendor: Micro-Star MSI driver: snd_hda_intel v: kernel bus ID: 02:00.1 
           Device-4: Logitech Webcam C270 type: USB driver: snd-usb-audio,uvcvideo bus ID: 1-6:3 
           Sound Server: ALSA v: k5.3.11-1-MANJARO 
Network:   Device-1: Qualcomm Atheros Killer E220x Gigabit Ethernet vendor: Gigabyte driver: alx v: kernel port: d000 
           bus ID: 04:00.0 
           IF: enp4s0 state: down mac: fc:aa:14:96:7a:ea 
           Device-2: Intel Wireless-AC 9260 driver: iwlwifi v: kernel port: d000 bus ID: 05:00.0 
           IF: wlp5s0 state: up mac: a4:c3:f0:85:c7:8a 
Drives:    Local Storage: total: 2.15 TiB used: 1.74 TiB (81.1%) 
           ID-1: /dev/sda vendor: OCZ model: ARC100 size: 223.57 GiB 
           ID-2: /dev/sdb vendor: Western Digital model: WD20EZRZ-00Z5HB0 size: 1.82 TiB 
           ID-3: /dev/sdc vendor: Kingston model: SV300S37A120G size: 111.79 GiB 
Partition: ID-1: / size: 100.58 GiB used: 79.52 GiB (79.1%) fs: ext4 dev: /dev/sdc2 
           ID-2: swap-1 size: 8.80 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sdc3 
Sensors:   System Temperatures: cpu: 45.0 C mobo: 29.8 C gpu: nvidia temp: 53 C 
           Fan Speeds (RPM): N/A gpu: nvidia fan: 0% 
Info:      Processes: 211 Uptime: 1m Memory: 15.51 GiB used: 1.27 GiB (8.2%) Init: systemd Compilers: gcc: 9.2.0 Shell: bash 
           v: 5.0.11 inxi: 3.0.36 

Steam log

>>> Adding process 2545 for game ID 507490
ERROR: ld.so: object '/home/gregg/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
>>> Adding process 2547 for game ID 507490
Game update: AppID 507490 "", ProcID 2545, IP 0.0.0.0:0
RecordSteamInterfaceCreation (PID 2545): SteamUser016 / User
RecordSteamInterfaceCreation (PID 2545): SteamFriends013 / Friends
RecordSteamInterfaceCreation (PID 2545): SteamUtils005 / Utils
RecordSteamInterfaceCreation (PID 2545): SteamMatchMaking009 / Matchmaking
RecordSteamInterfaceCreation (PID 2545): SteamMatchMakingServers002 / MatchmakingServers
RecordSteamInterfaceCreation (PID 2545): STEAMUSERSTATS_INTERFACE_VERSION011 / UserStats
RecordSteamInterfaceCreation (PID 2545): STEAMAPPS_INTERFACE_VERSION005 / Apps
RecordSteamInterfaceCreation (PID 2545): SteamNetworking005 / Networking
RecordSteamInterfaceCreation (PID 2545): STEAMREMOTESTORAGE_INTERFACE_VERSION010 / RemoteStorage
RecordSteamInterfaceCreation (PID 2545): STEAMSCREENSHOTS_INTERFACE_VERSION001 / Screenshots
RecordSteamInterfaceCreation (PID 2545): STEAMHTTP_INTERFACE_VERSION002 / HTTP
ERROR: ld.so: object '/home/gregg/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 2552 for game ID 507490
RecordSteamInterfaceCreation (PID 2545): SteamUtils005 / Utils
ERROR: ld.so: object '/home/gregg/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
>>> Adding process 2572 for game ID 507490
ERROR: ld.so: object '/home/gregg/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 2573 for game ID 507490
ERROR: ld.so: object '/home/gregg/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 2594 for game ID 507490
Setting breakpad minidump AppID = 507490
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198080150525 [API loaded no]
ERROR: ld.so: object '/home/gregg/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 2597 for game ID 507490
Game update: AppID 507490 "", ProcID 2597, IP 0.0.0.0:0
RecordSteamInterfaceCreation (PID 2597): SteamUtils007 / Utils
RecordSteamInterfaceCreation (PID 2597): SteamUser017 / User
RecordSteamInterfaceCreation (PID 2597): STEAMAPPTICKET_INTERFACE_VERSION001 / 
INTEL-MESA: warning: Haswell Vulkan support is incomplete
wine: Unhandled page fault on read access to 00007F04E3527CB8 at address 00007F04E34D0000 (thread 005d), starting debugger...
ERROR: ld.so: object '/home/gregg/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 2606 for game ID 507490
pid 2504 != 2503, skipping destruction (fork without exec?)
Game removed: AppID 507490 "", ProcID 2597 
Game 507490 created interface STEAMAPPTICKET_INTERFACE_VERSION001 / 
Game 507490 created interface SteamUser017 / User
Game 507490 created interface SteamUtils007 / Utils
Game 507490 method call count for IClientUser::GetAppOwnershipTicketExtendedData : 1
Game 507490 method call count for IClientUser::GetSteamID : 1
Game 507490 method call count for IClientUtils::GetAppID : 4
Game 507490 method call count for IClientUtils::GetConnectedUniverse : 1
Game 507490 method call count for IClientUtils::RecordSteamInterfaceCreation : 3
Uploaded AppInterfaceStats to Steam
Exiting app 507490
No cached sticky mapping in ActivateActionSet.Installing breakpad exception handler for appid(steam)/version(1573780595)
Installing breakpad exception handler for appid(steam)/version(1573780595)
Installing breakpad exception handler for appid(steam)/version(1573780595)

[mfp20]

I'm having similar issues on "Code Vein" and "Ashes of the singularity":

• system information
• steam log

Any idea?

EDIT: it works, using Proton 4.2-9. No need of any extra env var, lib, parameter.

[iicurtis]

As with everyone else, my logs are similar and the game silently crashes on newer proton versions.

After looking into this, Proton 4.11-6 is the last working version. Specifically commit 46f1a6c is good while 526279b does not launch. This indicates either an update to wine mono 4.9.3 is the issue or there is a regression in wine between commit c2511e5a1a5b7f0937e60c879a5ef791c962f21b and commit 41c7d676d89d3aa3a4add4bedb1ec89c8a4d89f8.

I'm going to start bisecting those wine commits to see if I can pinpoint the regression.

Edit:
Verified to be commit 526279b causing the problems. I'll have to start looking into what wine commit caused the regression.

2nd Edit:
Compiling the latest Proton 5.0-2 with Wine at commit c2511e5a1a5 allows the game to run fine.
Wine commit 93d2d86 crashes. The issue is somewhere between c2511e5a1a5 - 93d2d86.

Broken wine commit is somewhere between 1d72700 - 7510969.

[iicurtis]

The guilty commit is wine/242e003.

advapi32: Move registry functions to kernelbase.

Signed-off-by: Alexandre Julliard <[email protected]>
(cherry picked from commit c7548d6)

[7oxicshadow]

Nice. Now all you need to do is start bisecting down to the actual line that broke it :) (joke)

I was kind hoping that all of the functions that were moved from dlls/advapi32/registry.c to dlls/kernelbase/registry.c would all line up so that a diff tool would spot any obvious differences. This is not the case.

It looks like there is considerable changes between both implementations.

It might be possible to make an assumption that the problem lies with reading registry keys as if the keys were created using an old (working prefix) and then no longer work when moving to a newer prefix i am guessing that it is probably doing read processes during start-up.

[7oxicshadow]

For fun I had a go at launching the game with WINEDEBUG=+all turned on.

The game actually gets to the full screen image showing the ashes picture where it says "initialising assets" or whatever at the bottom of the screen. In the end I had to alt+f4 because the logfile was 17GB and i was rapidly running out of space!

The interesting thing is that the image doesn't show without WINEDEBUG. This either means that the crash happens that quick that the image doesn't have time to show normally or there is a genuine timing problem.

[alasky17]

@iicurtis Nice work finding the commit to blame! This regression slid under the radar for far too long :)

[iicurtis]

I'm slowly working through the >3000 adds/dels in commit 242e003.

It might help to follow along with these notes if you diff the kernelbase and advapi32 registry.c with:

git diff 86d13f5b01:dlls/advapi32/registry.c 242e003:dlls/kernelbase/registry.c

Things I've tried on commit 242e003

• Replace kernelbase/main.c call to RegOpenKeyExW with the old RegOpenKeyW
  call with extra checks.
  
  
  
  • Did not work. I'm not sure why the old checks were deemed unnecessary.
  
  
• Put old stub functions back in place. RemapPredefinedHandleInternal() and
  DisablePredefinedHandleTableInternal().
  
  
  
  • Did not work.
  
  
• Move RegCopyTree functions back to advapi32.
  
  
  
  • Did not work.
  
  

Things changed between 86d13f5 and 242e003

• major: RegDisablePredefinedCache() changed to stub that calls
  DisablePredefinedHandleTableInternal(). Reworked.
• major: RegOpenCurrentUser() Reworked.
• load_mui_string() string initialization changed to *string = NULL.
  load_string() replaced with LoadStringW(). Strange typecast of string. Now
  checks if string exists.
• RegCopyTreeW() now returns type LSTATUS but the function did not change?
  Is LONG ret compatible with LSTATUS?
• bool hkcu_cache_diabled is now combined with root_key_names
• is_wow6432node() switched from strncmpiW() to wcsnicmp()
• create_key() switched from strncmpiW() to wcsnicmp()
• create_special_root_hkey() now checks cache_disabled[idx]
• RegOverridePredefKey() renamed to RemapPredefinedHandleInternal() and now
  returns NTSTATUS instead of LSTATUS.
• RegSaveKeyW() renamed to RegSaveKeyExW()
• RegSaveKeyExW() now uses swprintf() instead of snprintfW()
• RegSaveKeyA() renamed to RegSaveKeyExA()
• RegUnLoadKeyW() now skips RegOpenKeyW() checks and goes to
  RegOpenKeyExW()
• kernelbase/main.c now skips RegOpenKeyW() checks and goes to
  RegOpenKeyExW()
• load_string() function REMOVED
• reg_mui_cache_get() switched from strcmpiW() to wcsicmp()
• reg_mui_cache_put() switched from strlenW() to lstrlenW(). Also switched
  from strcpyW() to lstrcpyW()
• RegLoadMUIStringW() switched from strrchrW() to wcsrchr(). Also switched
  from atoiW() to wcstol(). Also switched from strlenW() to lstrlenW().
  Also switched from strcpyW() to lstrcpyW(). Also switched from strcatW()
  to lstrcatW()
• superficial: RegDeleteKeyExA() now uses RegEnumKeyExA() instead of RegEnumKeyA()
• superficial: RegSetKeyValueW() now uses RegCreateKeyExW() instead of
  RegCreateKeyW()
• superficial: RegSetKeyValueA() now uses RegCreateKeyExA() instead of
  RegCreateKeyA()
• superficial: ADVAPI_ApplyRestrictions() renamed to apply_restrictions()
• superficial: RegDeleteTreeW() replaced RegDeleteKeyW() with RegDeleteKeyExW()
• superficial: EnumDynamicTimeZoneInformation() now uses RegEnumKeyExW() instead of
  RegEnumKeyW()
• superficial: SHRegWriteUSValueW() now uses RegCreateKeyExW() instead of
  RegCreateKeyW()

Things left in advapi32 that may have changed

• nochange: RegCreateKeyW()
• nochange: RegCreateKeyA()
• nochange: RegCreateKeyTransactedW()
• nochange: RegCreateKeyTransactedA()
• RegOpenKeyW()
• RegOpenKeyA()
• RegEnumKeyW()
• RegEnumKeyA()
• RegQueryMultipleValuesA()
• RegQueryMultipleValuesW()
• RegQueryReflectionKey()
• RegDeleteKeyW()
• RegDeleteKeyA()
• RegSetValueW()
• RegSetValueA()
• RegQueryValueW()
• RegQueryValueA()
• nochange: RegReplaceKeyW()
• nochange: RegReplaceKeyA()
• nochange: RegConnectRegistryW()
• nochange: RegConnectRegistryA()
• nochange: RegCopyTreeA()
• nochange: RegDisableReflectionKey()

[douglasg14b]

This is a good example for the argument of enforcing granular commits.

In my stuff a commit should contain as many changes that can be semantically described in the message in <150chars. It makes for a lot of commits, but they are all small, semantic, and easy to track down.

Kudos on doing the hard work of sifting through that @iicurtis

[iicurtis]

I've tried going in both directions, from the non-working commit backwards and from the working commit incrementally applying what I can. From what I can see, either the issue is something with the movement of the functions or it has to do with the new strcmp and strlen functions. I haven't been able to reproduce/fix the issue working from either direction yet. Unfortunately, my debug logs haven't given me any hints where the crash is.

If anyone sees anything obvious in the logs, it might be a good time to point it out.

[random2324]

Still crashes at start with Proton 5.0-4. Also no change with custom Proton with Wine Staging 5.4.

[iicurtis]

The fix hasn't been found yet. The commit with the regression has been found, but not the exact cause within that commit.

This could probably be corrected faster by submitting a bug report to the upstream wine developers.

[iicurtis]

@7oxicshadow I was not able to reproduce the PROTON_LOG=1 WINEDEBUG+=all working. However, I did get it to launch with PROTON_LOG=1 WINEDEBUG+=relay %command%... where it created a 2.2GB log file, and launched to the splash screen where it was loading the assets normally. I killed ashes before the log file got too out of control.
There is something very odd here.

[7oxicshadow]

@iicurtis I am almost convinced that it is some sort of timing issue which if correct would be a nightmare to debug. Out of curiosity, did you ever try adding debug to all of the functions that were changed in the commit.

Like a printf on entry and a printf on exit of a function so you could possibly narrow it down further? Are there a lot of functions that have changed?

[iicurtis]

Outside of the changes/renames listed above (which I've mostly reversed and tested already), these are the functions that have changed:

• strncmpiW -> wcsnicmp (unlikely)
• swprintf -> snprintfW
• strcmpiW -> wcsicmp (unlikely)
• strlenW -> lstrlenW (unlikely)
• strcpyW -> lstrcpy (unlikely)
• strchrW -> wcsrchr (unlikely)
• atoiW -> wcstol
• strcatW -> lstrcatW (unlikely)

I don't really think it's likely to be any of these, but they are the largest source of change here. Particularly wcstol. Running a grep on the log file I see this when it crashes with PROTON_LOG=1 WINEDEBUG+=all:

❯ rg msvcrt.wcstol steam-507490.log
1157246:25604.475:0016:0019:Call msvcrt.wcstol(00cfd530 L"12",00939668,0000000a) ret=6a729fdc
1157250:25604.475:0016:0019:Ret  msvcrt.wcstol() retval=0000000c ret=6a729fdc
1157393:25604.478:0016:0019:Call msvcrt.wcstol(00c62820 L"12",00939668,0000000a) ret=6a729fdc
1157397:25604.478:0016:0019:Ret  msvcrt.wcstol() retval=0000000c ret=6a729fdc
1157454:25604.479:0016:0019:Call msvcrt.wcstol(00cdbb20 L"12",00939668,0000000a) ret=6a729fdc
1157458:25604.480:0016:0019:Ret  msvcrt.wcstol() retval=0000000c ret=6a729fdc
1249170:25606.125:0016:002c:Call msvcrt.wcstol(00cdd300 L"12",0118a248,0000000a) ret=6a729fdc
1249178:25606.125:0016:002c:Ret  msvcrt.wcstol() retval=0000000c ret=6a729fdc
1249261:25606.127:0016:002c:Call msvcrt.wcstol(00cfc6b0 L"12",0118a248,0000000a) ret=6a729fdc
1249265:25606.127:0016:002c:Ret  msvcrt.wcstol() retval=0000000c ret=6a729fdc
1249326:25606.128:0016:002c:Call msvcrt.wcstol(00cf9080 L"12",0118a248,0000000a) ret=6a729fdc
1249330:25606.128:0016:002c:Ret  msvcrt.wcstol() retval=0000000c ret=6a729fdc
1310737:25607.290:0016:002c:Call msvcrt.wcstol(00c0a0b0 L"12",0118a248,0000000a) ret=6a729fdc
1310741:25607.290:0016:002c:Ret  msvcrt.wcstol() retval=0000000c ret=6a729fdc
1310786:25607.292:0016:002c:Call msvcrt.wcstol(00d0b450 L"12",0118a248,0000000a) ret=6a729fdc
1310790:25607.292:0016:002c:Ret  msvcrt.wcstol() retval=0000000c ret=6a729fdc
1310843:25607.293:0016:002c:Call msvcrt.wcstol(00be6230 L"12",0118a248,0000000a) ret=6a729fdc
1310847:25607.293:0016:002c:Ret  msvcrt.wcstol() retval=0000000c ret=6a729fdc

But when I run with PROTON_LOG=1 WINEDEBUG+=relay and the game launches:

❯ rg msvcrt.wcstol ashes-507490.log
21318760:0063:Call msvcrt.wcstol(00bb1380 L"200",00000000,0000000a) ret=645495db
21318771:0063:Ret  msvcrt.wcstol() retval=000000c8 ret=645495db
21319026:0063:Call msvcrt.wcstol(01c84c08 L"178",00000000,0000000a) ret=645495db
21319035:0063:Ret  msvcrt.wcstol() retval=000000b2 ret=645495db
21363671:0065:Call msvcrt.wcstol(00b85b90 L"200",00000000,0000000a) ret=645495db
21363682:0065:Ret  msvcrt.wcstol() retval=000000c8 ret=645495db
21364020:0065:Call msvcrt.wcstol(01cb58e0 L"22",00000000,0000000a) ret=645495db
21364030:0065:Ret  msvcrt.wcstol() retval=00000016 ret=645495db
21375611:0060:Call msvcrt.wcstol(00bc4900 L"200",00000000,0000000a) ret=645495db
21375622:0060:Ret  msvcrt.wcstol() retval=000000c8 ret=645495db
21378420:004e:Call msvcrt.wcstol(00b86c28 L"200",00000000,0000000a) ret=645495db
21378434:004e:Ret  msvcrt.wcstol() retval=000000c8 ret=645495db
22777557:0065:Call msvcrt.wcstol(01ccb2e0 L"200",00000000,0000000a) ret=645495db
22777568:0065:Ret  msvcrt.wcstol() retval=000000c8 ret=645495db
22777961:0065:Call msvcrt.wcstol(01c45580 L"22",00000000,0000000a) ret=645495db
22777973:0065:Ret  msvcrt.wcstol() retval=00000016 ret=645495db
22785118:004e:Call msvcrt.wcstol(01c455c0 L"200",00000000,0000000a) ret=645495db
22785132:004e:Ret  msvcrt.wcstol() retval=000000c8 ret=645495db
22785573:004e:Call msvcrt.wcstol(00b8bac0 L"8156",00000000,0000000a) ret=645495db
22785584:004e:Ret  msvcrt.wcstol() retval=00001fdc ret=645495db
22944317:0060:Call msvcrt.wcstol(01c414d0 L"200",00000000,0000000a) ret=645495db
22944319:0060:Ret  msvcrt.wcstol() retval=000000c8 ret=645495db
22944565:0060:Call msvcrt.wcstol(01cb27a8 L"254",00000000,0000000a) ret=645495db
22944575:0060:Ret  msvcrt.wcstol() retval=000000fe ret=645495db

I don't know if it even matters, but for some reason the only string it tries to grab a number from is "12" on the bad launch. Also, notice that the crashed launch has a valid end pointer, while the launching one does not (it's always 0).

---

I think I'm chasing ghosts here. The function calls to wcstol on the crashed version can't be from our new kernelbase functions, because they specify the endpointer (second argument to wcstol) to be NULL. So maybe it has errors before it gets to that particular function (RegLoadMUIStringW).

[random2324]

@iicurtis
Is there any chance you can reproduce this with a vanilla wine version and open a bug report over at winehq.com? Im not sure if the devs are already aware of this regression.

[Leopard1907]

@random2324 I think they are aware because one of the commentors here (Alasky17) is one of the QA people from CodeWeavers.

[random2324]

Just checked with custom proton wine 5.7 staging, nothing has changed. I think its a little bit strange, that a bisect regression stays for so long unresolved.

@kisak-valve
Anything needs to be done here from user side? Or is someone already working on a fix?

[thunder1410]

I got this game free on the humble bundle store and got it working with vulkan and this launch option using proton 4.2-9:

PROTON_NO_ESYNC=1 PROTON_NO_FSYNC=1 PROTON_LOG=1 %command% /nolauncher

But when I put the texture quality on high it starts crashing the moment I run the built-in benchmark.
System specs:
Ubuntu 18.04.4 LTS
i5-4460
GTX 980
Driver Version: 4.6.0 NVIDIA 435.21
System information: https://gist.github.com/thunder1410/76897c9bd211c74b30968baa4037ce96

The log file of a crash is zipped below (>50MB):
steam-507490-log.zip

[DeathTBO]

Fedora 32 - Kernel 5.6.12
Ryzen 2700
5700xt - Mesa 20.0.7
Proton 4.2.9

Launcher seems to work just fine. I'm also using PROTON_NO_ESYNC=1. The game wont start with DX11 unless I have PROTON_USE_WINED3D=1. It doesn't seem to like DXVK. Performance is awful in this mode even at all low graphics. There are also tons of graphical issues.

Switching the game to Vulkan gives me an error saying "Vulkan requires the very latest drivers." I'm not sure what Vulkan extension I need for this, but I've tried both ACO and LLVM... Neither work.

[doitsujin]

Vulkan is known not to work on AMD cards because the version check only works on Windows. Even the proprietary Vulkan driver does not work, and neither does replacing the amdags library with one that fakes the driver version.

It's unfortunate that the game doesn't even allow you to start it in Vulkan mode if the version check fails, but there's not much we can do about that as of right now.

I don't know why DXVK wouldn't work for you, it's running fine here without any obvious issues.

[DeathTBO]

It's strange but I remember having issues with DXVK and Ashes last year as well. At the time Mesa was version ~18 and I had a 580x, but it was the same story.

Edit: MangoHUD was causing issues not DXVK. I apologize @doitsujin - Performance is reasonable on max settings

[7oxicshadow]

Looks like there is some good news on the horizon. Proton GE has released a build (5.11-GE2) with a fix for Ashes and I can confirm that it works for me using DX11.

I am not sure what the fix was but for anyone wanting to try it, it is here:
https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.11-GE-2-MF

Instructions for use are here:
https://github.com/GloriousEggroll/proton-ge-custom

For those who do not wish to try custom proton versions I suspect that it won't be too long before it makes its way into the official Proton version.

[random2324]

Can confirm this. Using Proton 5.11-r11 TKG game is starting now.

[tatsujb]

what's the performance like though?

[7oxicshadow]

For those interested in technical details. The bug report below provides the required info.

https://bugs.winehq.org/show_bug.cgi?id=48938

From what I can grasp, the bisected comit discovered by @iicurtis was indirectly causing the problem via a much older bug and appears to be fixed by the following:

https://source.winehq.org/patches/data/187866

[mozo78]

Unfortunately it now hangs on "Turinium Optimized"...

[7oxicshadow]

Unfortunately it now hangs on "Turinium Optimized"...

Didn't notice any problems on my machine? Benchmark worked well. Does the game work for you on older versions of proton?

[mozo78]

Nope. It's the GOG version though.

[kisak-valve]

Ashes of the Singularity: Escalation native Vulkan support

Issue transferred from https://github.com/ValveSoftware/Proton/issues/4151.
@outsidefactor posted on 2020-08-26T04:41:48:

Compatibility Report

• Name of the game with compatibility issues: Ashes of the Singularity: Escalation
• Steam AppID of the game: 507490

System Information

• GPU: Radeon RX Vega (VEGA10, DRM 3.38.0, 5.8.1-3-MANJARO, LLVM 10.0.1)
• Driver/LLVM version: 20.1.5
• Kernel version: 5.8.1-3
• Link to full system information report as Gist: https://gist.github.com/outsidefactor/b51e4e409653f2a074a75a644fdd6e52
• Proton version: 5.0.9

I confirm:

• [ ] that I haven't found an existing compatibility report for this game. - this is not relevant to my report. existing reports are for DX11/Proton-4.2

• [X] that I have checked whether there are updates for my system available.

steam-507490.log

Symptoms Cannot launch the native Vulkan version of the game.

Reproduction

1 - Launch game as per current compat report (Proton 4.2)
2 - Set game to use Vulkan instead of DX11 - game will say you need to restart
3 - Exit game
4 - Set Steam to Launch game with Proton 5.0.9
5 - Start game. Reaches launcher, but main game fails to launch.

[kisak-valve]

Hello @outsidefactor, I suspect that amdvlk is contributing to the crash you're seeing. It might be interesting to see if mesa/RADV shows better behavior or if it still hits the previously mentioned version check.

[outsidefactor]

Hello @outsidefactor, I suspect that amdvlk is contributing to the crash you're seeing. It might be interesting to see if mesa/RADV shows better behavior or if it still hits the previously mentioned version check.

Sorry, I thought I had changed the default load order in .profile. I guess I have to do it for each game in Steam, unless there's a way to set Proton to default to default to RADV. I really only have AMDVLK for two specific games, and their both Linux native.

Here's the log with RADV set with VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json PROTON_LOG=1 %command%

steam-507490.log

[random2324]

Driver doesnt matter: https://github.com/ValveSoftware/Proton/issues/1479#issuecomment-630257309

Vulkan is known not to work on AMD cards because the version check only works on Windows. Even the proprietary Vulkan driver does not work, and neither does replacing the amdags library with one that fakes the driver version.

[outsidefactor]

Driver doesnt matter: #1479 (comment)

Vulkan is known not to work on AMD cards because the version check only works on Windows. Even the proprietary Vulkan driver does not work, and neither does replacing the amdags library with one that fakes the driver version.

I can't really tell from that comment if they mean (a) there is no fix right now, or (b) a fix is impossible

And does this mean that _no_ Windows games with Vulkan drivers work with any Radeon card?

[Compizfox]

Ashes' Vulkan renderer also doesn't work with RADV.

And does this mean that _no_ Windows games with Vulkan drivers work with any Radeon card?

On Linux (using Wine/Proton), you mean? No, there are definitely games with Vulkan renderers that work fine using Wine on Linux with AMD GPUs. Doom (2016) comes to mind, but there are dozens. I think that quote by @doitsujin should be read in the context of Ashes specifically.

[outsidefactor]

Ashes' Vulkan renderer also doesn't work with RADV.

And does this mean that _no_ Windows games with Vulkan drivers work with any Radeon card?

On Linux (using Wine/Proton), you mean? No, there are definitely games with Vulkan renderers that work fine using Wine on Linux with AMD GPUs. Doom (2016) comes to mind, but there are dozens. I think that quote by @doitsujin should be read in the context of Ashes specifically.

I though something like that. I tried Paths of Exile's beta Vulkan and it worked fine.

So I have to wonder, Is this something that's easier fixed from WINE's side or AotS? Stardock are really quite reasonable, and they even discussed a Linux native version of AotS during the dev cycle. If there is something they can easily do to make it compatible and they had some help from the community with understanding the problem and testing fixes this might get sorted.

I assume that mapping from Windows Vulkan via WINE to the Linux native Vulkan is more efficient than DXVK... or is this entirely pointless?

[7oxicshadow]

Be aware that the vulkan back end for Ashes is inferior to any DX back end regardless of OS. The developers could never get the efficiency to be anything like dx11/12. There is a dev response on the steam forums if iirc to back this up. I seem to remember it was in response to a question regarding Linux support.

Personally I would stick with DXVK as it gives the best FPS for me (using NVIDIA)

[outsidefactor]

Be aware that the vulkan back end for Ashes is inferior to any DX back end regardless of OS. The developers could never get the efficiency to be anything like dx11/12. There is a dev response on the steam forums if iirc to back this up. I seem to remember it was in response to a question regarding Linux support.

Personally I would stick with DXVK as it gives the best FPS for me (using NVIDIA)

Yeah, ok...
Here's the problem with that:
1) One of the Benchmark modes is only available in Vulkan - not a huge issue and I guess I can live with this
2) I am not on nVidia, and am not going to be on nVidia any time soon
3) I am trying to address a specific short fall - lighting seems particularly inefficient via DXVK, at least on my Vega. When I played on Windows (exact same hardware) the lighting problem wasn't anywhere near as bad, and was much smoother than under WINE. I honestly can't remember if that was under DX12... in fact I can't seem to find a DX12 option in AotS, only DX11... is there something I need to enable to allow AotS to present a DX12 option? It would make sense that this explains the issue because DX12/Vulkan's shader model is exactly what allows Radeon to be so much more efficient, as I understand it.

On the upside, the GE editions of Proton support AotS from Proton-5.11-GE-2-MF onward, it seems. Maybe at some point the lighting inefficiency might get addressed.

Or RDNA2/Big Navi will arrive and not be too expensive (crosses fingers) and the extra grunt will render my specific problem moot, assuming I don't get tripped up by DX11's ageing shader model.

I am no expert. Maybe someone can set me straight?

[outsidefactor]

As I understand it, VKD3D is in Proton from 5 onward, but I might need to do something to enable it per game?

OK, so I tried to set PROTON_USE_VKD3D=1 in the Luanch Options for AotS and it started but failed to present DX12 as an option in-game.

Is that all I need to do, or is there VKD3D configuration that needs to be done beyond just enabling it?

I am using Proton-5.11-GE-3-MF now, as well.

EDIT:
For reference here's my entire launch option:
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json PROTON_USE_VKD3D=1 PROTON_LOG=1 %command%

EDIT2:
I have also tried it with AMDVLK. The game ran, still only presented DX11 and Vulkan as options. Benchmark visually stuttered more (even with Freesync/VRR operational) but the numerical results were higher.

EDIT3
OK, so I found the discussion about a native Linux version on Steam (sorry, I can't figure out how to link to it).

Here is a quote:

"Update: 9/29/2019:
Ok we have it ported now. So good news and bad news. We have it running Debian and we presume it'll work on others. But the bad news is that the performance is just not acceptable. This is mainly due to the game being developed prior to Vulkan. It's all doable to fix but we don't have the budget to make those kinds of changes for one platform.

The difference based on the video card set up is pretty drastic too (not blaming any video card drivers here but the variance is pretty huge and would result in some unhappy people).

The good news is that Ashes II (and our other new titles) should, in theory, ship with Linux support off the bat thanks to this effort.

Those of you who are familiar with Stardock know we came from the OS/2 world back in the day so we are very much motivated to make our games work on Linux too. Just a matter of having enough resources to do it.

Thank you for your support on this. The sign up sheet helped us push through getting budget to do the initial port which should have benefits long-term for all our games not being so tied to Windows in the future."

It clearly indicates that Vulkan was an afterthought. This seems to pretty clearly indicate that if I want extra free FPS from a modern shader model (and threaded DX, etc) my only path is DX12/VKD3D.

[outsidefactor]

OK, given that Vulkan seems to be not a solution, DX12/VKD3D seems like my best path to those tasty extra frames Radeon gets with a modern API (from the modern shader model, superior threading etc).

VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json PROTON_USE_VKD3D=1 PROTON_LOG=1 %command%

The game loads this way with both Proton-5.9-GE-5-ST and Proton-5.11-GE-3-MF. It also loads with RADV or AMDVLK as the system Vulkan driver (yes I know I need to change the Launch Options)! But I don't see a DX12 option presented in-game.

Any Radeon users out there interested in this? Or should I just give up and wait for Ashes 2, seeing as it will be native? At this point I am not even sure what to try next to get the game to see DX12 as an option to present. VKD3D seems to work really well for certain games, but I don't know if that's a function of the work GloriousEggroll does.

Any suggestions for a next step?

[random2324]

PROTON_USE_WINE_DXGI=1 and make sure win10 is set.
Already successfully tested dx12 mode and it seems to be faster than dxvk. Although extreme preset crashes for me.

[Compizfox]

I assume that mapping from Windows Vulkan via WINE to the Linux native Vulkan is more efficient than DXVK... or is this entirely pointless?

No, you're right. In fact, it's even better than that because there isn't really such as a thing as "Windows Vulkan" that has to be translated. It's just native Vulkan, which does not need a translation layer because your GPU drivers understand that directly. You still need Wine to run the Windows game of course, but you don't need something like DXVK or VKD3D.

OK, given that Vulkan seems to be not a solution, DX12/VKD3D seems like my best path to those tasty extra frames Radeon gets with a modern API (from the modern shader model, superior threading etc).

I'm not sure. IIRC VKD3D's performance is not nearly as good as DXVK's, which I think offsets any potential gains you got by using DX12 over DX11.

[outsidefactor]

PROTON_USE_WINE_DXGI=1 and make sure win10 is set.
Already successfully tested dx12 mode and it seems to be faster than dxvk. Although extreme preset crashes for me.

What Proton build are you using? 5.0-9, 5.0-10 or 5.9-GE-5-ST or 5.11-GE-3-ST?

OK, so my Launch Options now look like:
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json PROTON_USE_VKD3D=1 PROTON_USE_WINE_DXGI=1 PROTON_LOG=1 %command%

And then use protontricks to set the Windows edition to 10?

I assume that mapping from Windows Vulkan via WINE to the Linux native Vulkan is more efficient than DXVK... or is this entirely pointless?

No, you're right. In fact, it's even better than that because there isn't really such as a thing as "Windows Vulkan" that has to be translated. It's just native Vulkan, which does not need a translation layer because your GPU drivers understand that directly. You still need Wine to run the Windows game of course, but you don't need something like DXVK or VKD3D.

OK, given that Vulkan seems to be not a solution, DX12/VKD3D seems like my best path to those tasty extra frames Radeon gets with a modern API (from the modern shader model, superior threading etc).

I'm not sure. IIRC VKD3D's performance is not nearly as good as DXVK's, which I think offsets any potential gains you got by using DX12 over DX11.

But the issue is that I can't get the Vulkan version to launch. Have you had any success in getting Vulkan to work for AotS?

[outsidefactor]

OMG, @random2324 you are my Heathen God and I want to have your babies.

This WORKS with 5.9-GE-5-ST. To confirm that this was the only step I deleted the old compatdata folder for AotS and started again.

I didn't even need to protontricks it to Windows 10 because I think that Proton-5.9-GE actually takes care of that already.

Even better than it working it also gave me a TONNE of extra FPS, as I had hoped. Each benchmark scene gave me 10+ extra FPS in DX12 over DX11, plus the quality of the lighting is far superior.

[random2324]

I build Proton myself using TKG. You also dont need the Proton Log option set everytime. Except thats intentional.

You wont get the Vulkan version to launch. Its not possible in the moment. The game seems to check for specific (Windows) driver versions. Faking those seems to be no trivial task.

Also it's not like just because the vulkan renderer of the game runs now on Linux it maps its calls directly to the driver. There is still something necessary called winevulkan which mimicks Windows behavior. Anyway I wouldn't expect much of an improvement for this. Vkd3d and DXVK are already pretty good sometimes even outperform Windows.

[outsidefactor]

I build Proton myself using TKG. You also dont need the Proton Log option set everytime. Except thats intentional.

You wont get the Vulkan version to launch. Its not possible in the moment. The game seems to check for specific (Windows) driver versions. Faking those seems to be no trivial task.

Also it's not like just because the vulkan renderer of the game runs now on Linux it maps its calls directly to the driver. There is still something necessary called winevulkan which mimicks Windows behavior. Anyway I wouldn't expect much of an improvement for this. Vkd3d and DXVK are already pretty good sometimes even outperform Windows.

Hey, look, Vulkan or DX12 it's all good: anything with a modern shader model is going to be 10-20% faster on Vega. Stardock seem to indicate that the Vulkan support in AotS is very much an afterthought and no efficient anyway. VKD3D is working well and that's giving me better performance AND visuals. Can't ask for much more than that.

I had a look into TKG and it's not quite as simple as GE. I am sure it's superior, but GE 'just works' with no more effort than downloading a tar.gz and expanding it into a folder. Yeah, yeah, lazy user...

But... now I know what works to get DX12 going for AotS there are other DX12 games I can consider.

[BabylonAS]

I’ve downloaded Proton-GE and tried to use vkd3d but the game only lists DirectX 11 and Vulkan APIs in the settings, even though my video card (GTX 1650) does support DX12.

[outsidefactor]

I’ve downloaded Proton-GE and tried to use vkd3d but the game only lists DirectX 11 and Vulkan APIs in the settings, even though my video card (GTX 1650) does support DX12.

Try using protontricks to set the OS to Windows 10 for AotS, @BabylonAS . I had assumed GE set it for me, but evidently I had changed it to Windows 10 at some point while I was tinkering.

The invocation I am using is also for RADV Vulkan. If you didn't already, you will need to remove the VK_ICD_FILENAMES part of the launch options, or set it to the appropriate nVidia one.

PROTON_USE_VKD3D=1 PROTON_USE_WINE_DXGI=1 %command% should work for most nVidia users, as far as I understand it. I don't have any nVidia machines to test with.

[BabylonAS]

No, it doesn't work for me — the game hangs on the loading assets screen.

[BabylonAS]

PROTON_NO_ESYNC=1 doesn’t seem to make a difference. Looks like we’re back to where this whole issue begins...

[outsidefactor]

No, it doesn't work for me — the game hangs on the loading assets screen.

Bummer. I just tried another machine I have with an RX 580 in it and it worked fine on that, was even easier because I don't have both RADV and AMDVLK on that machine at the same time. I just don't have any nVidia cards to try it with.

You're on what Linux distro? Proton-5.9-GE-5-ST? FSYNC capable Kernel? Shader pre-caching enabled? I have tried to keep much of my main system as close to the shipped versions from Manjaro to make it easier to help some friends that have made the move too, so I am not really running anything that out of the ordinary.

[BabylonAS]

Arch Linux, with 5.8.3-arch1-1 kernel. No idea about fsync or pre-caching.

[outsidefactor]

Kernel 5.8 has FSYNC patched-in by default. You'll want FSYNC and ESYNC enabled for the best performance (not much point in getting DX12 going if it does't run better).

Shader pre-caching can be turned on in Steam:
Steam menu -> Settings -> Shader Pre-caching
And you can tick "Enable Shader Pre-Caching" and "Allow Background processing of Vulkan Shaders". You can then restart Steam to force it to start processing if it doesn't start on its own.

If you have a lot of games installed that can take a while to run. It will stop the background processing if you start a game in Steam, but you'll want to shut down Steam if you want to play a Lutris game and the background stuff hasn't settled down.

Your best bet might be best to set it and then go to bed or do something else for a while and let it run. How long it takes is a function of your CPU performance and the number of games you have installed.

Even if you can't get DX12 going, you're still better off on the GE Proton build. 5.0-9 doesn't run AotS at all, so at least with GE Proton and ESYNC and FSYNC your performance will be better than with the current recommendation on ProtonDB, Proton-4.2-9.

[plasticbomb1986]

Just a note:

CPU AMD R7 3800XT (watercooled)
RX Vega64 (2x)(watercooled)
32GB DDR4 3200MHz
Game and os is on separate SSD, swap partition is on an NVMe SSD
ArchLinux, Kernel 5.8.11-zen
Mesa 20.1.8
TK-Glithc Proton 5.18.r3

steam launch parameters: VKD3D_VULKAN_DEVICE=1 PROTON_LOG=1 mangohud RADV_PERFTEST=aco %command%
(Im happy to see, VKD3D actually have a working GPU selection method, DXVK never was able to choose between two identical card, and zen kernel have fsync enabled, and it earned a few fps for me (5-10 percent) )

ive tested with /nolauncher and without it, the game starts in both instance.
The game crashes every time either i alt+tabed (or just used windows key) out of it, or it opened a separate window like for benchmark results to check outside of the game.

Game runs reasonably well on VKD3D (DX12), but about 20 percent less fps on Linux.

win10benchmar output:
Output_20_09_29_1350.txt
Linux
Output_20_09_29_1134.txt

Saw some fixme:err in proton log
steam-507490.log

SIde note: i did checked the vulkan render too on win: about 20-25% less fps in gpu focused, but 1-2 fps more in cpu focused benchmark.