TEKKEN 8 (1778820)

[NyaomiDEV]

Compatibility Report

• Name of the game with compatibility issues: TEKKEN 8
• Steam AppID of the game: 1778820

System Information

• GPU: Radeon RX 6900XT
• Video driver version: 23.3.3
• Kernel version: 6.6.9-artix1-1
• Link to full system information report as Gist:
• Proton version: Experimental

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

Symptoms

The game crashes when loading (in "press any button" screen.) Notice: I never started this game before, I don't have any saves.

uh, also, this

Reproduction

Start the game, go through the producer logos, skip the fmv and press a button whenever it asks you to do so.

[scandalouss]

im getting disconnects in both the regular ranked matchmaking, and trying to play in a lobby with a friend. Game always goes for a minute or two then freezes and disconnects.

Another thing to note: when I attempted to host a lobby for me and my friend to play, the game wouldn't even make it to the stage before disconnecting us. If my friend hosted however, who was playing on windows, we would get in and be able to play for about a minute or two before a disconnect. I guess hosting lobbies is not possible right now, too...

[BobrImperator]

Hmm, I've tested this back and forth with my default configuration and only Google DNS and I personally see an improvement. Wasn't able to get any matches before with certain people but now I do.

Make sure you're actually using your newly configured DNS by issuing e.g. dig www.google.com command. When configuring a network adapter, try to disconnect from it and connect again, to make sure it runs with the new config or just flush dns with some other method. The game should also be restarted to avoid any caching issues.

[Blazillion]

Also experiencing desync online using proton fix. Is there someone that can help ? I'm even willing to donate

[Gin845]

replying to https://github.com/ValveSoftware/Proton/issues/7444#issuecomment-1913831572

I tested it rather thoroughly and couldn't find a difference in behaviour between 8.8.8.8 and 1.1.1.1 or 1.0.0.1 for that matter. also it seems weird to me that DNS is supposed to have an impact. Of cause i restarted the game and re established the connection and made sure it actually uses the configured DNS Server.

[dydzio0614]

Somebody claimed on reddit that he managed to fix/workaround the online issue on steam deck by disabling "wifi power management" flip switch from steamOS... i am not on deck and wired so I am not able to test this.

Some other people point at suspiciously high ping / round trip time as potentially related to issue

[Andrew32bit]

Update : I requested refund for the game.Its better to play on ps5

Somebody claimed on reddit that he managed to fix/workaround the online issue on steam deck by disabling "wifi power management" flip switch from steamOS... i am not on deck and wired so I am not able to test this.

Some other people point at suspiciously high ping / round trip time as potentially related to issue

its not working - I tried sudo iwconfig wlan0 power off and still same issue

[halictuz]

When I changed DNS to 8.8.8.8 or 1.1.1.1 it worked a tiny bit better compared to 9.9.9.9 or my ISP dns. But still, issues are still there. 99% of online matches end in an error and disconnect/desync. On Windows 11 everything works perfectly fine tho.

[failtech]

I played again for two hours on SteamDeck via my mobiles Hotspot without any problems. all matches in ranked, quick match and private lobbies worked very well (of course, not as smooth as a wired connection). I know that this works for some other people, but doesn´t for all. After asking two other people who play on a mobile connection, the similarity seems to be that we all use Iphones and use a german cell phone contract (although, three people is still a small set of data). Maybe that info is helpful for anyone who might have a clue what could be the specific difference between landline and mobile internet connections that does the trick for us.

[Gin845]

Another thing is that Tekken crashes in the Startup screen if i dont use the hotfix version of proton. Both 8.0-5 and Experimental crash.

[Gin845]

replying to https://github.com/ValveSoftware/Proton/issues/7444#issuecomment-1915146939

I tried using tethering my mobile phone to my machine to try if this works for me. I can confirm that i can play online via my mobile connection, this is obviously not ideal but interesting. EDIT: I dont use an Iphone but a german carrier. EDIT2: It also works if I connect my Phone to my Wireless which uses the same network my PC usually uses (even though the pc usually doesnt use Wireless). But i havent found out why this works yet

[Mikeysax]

I'm also getting mid-match disconnects

GPU: AMD Radeon RX 6900 XT
CPU: AMD  Ryzen 9 5950X
Kernel: 6.7.0-204.fsync.fc39.x86_64 (64-bit)
Distro: Nobara Linux 39
Proton: GE-Proton8-28

[DelusionalLogic]

I've taken a tcpdump of a couple of examples of the issue. It think I see a pattern. The traffic flows well for a while, but at some point the kernel responds to some of the packets with a "Destination Unreachable" message. It does this for about 6-7 packets, or 30-40 milliseconds, before the game then resumes responding again. Once this initial drop has occurred, the kernel drop one packet every second on the second until the game gives up and disconnects you.

It may be some internal buffer filling up, or the kernel just not being ready for that kind of packet stream. I've attached filtered pcap file of the traffic between me and an unlucky opponent.

DC.pcap.tar.gz

[danth]

Increasing the Linux kernel buffer size doesn't help. Does Proton/Wine have its own buffers?

[dydzio0614]

BTW closed beta had same bug and if I remember correctly playing between two linux / deck users was possible back then

Since full release i had no opportunity to test how it behaves against another linux user

EDIT: tested, same disconnects against linux desktop player

[gofman]

The situation with disconnections should hopefully be much better with the just updated Proton Experimental ([bleeding-edge] branch).

[KawaiiDinosaur]

I see reports connection issues are fixed on bleeding edge. Can anyone confirm?

[temporaryroman0]

I see reports connection issues are fixed on bleeding edge. Can anyone confirm?

Just played about 5 matches in a row with proton bleeding edge and not a single disconnect!

[RiQuY]

The situation with disconnections should hopefully be much better with the just updated Proton Experimental ([bleeding-edge] branch).

Should I then change to Proton Experimental or stick with Proton Hotfix?

EDIT: nvm I didn't know there were beta for Proton Experimental https://github.com/ValveSoftware/Proton/wiki/Proton-Versions#proton-bleeding-edge

EDIT2: I tested player matches and I didn't disconnected a single time with Proton Experimental Bleeding Edge

[ravimahal]

I've taken a tcpdump of a couple of examples of the issue. It think I see a pattern. The traffic flows well for a while, but at some point the kernel responds to some of the packets with a "Destination Unreachable" message. It does this for about 6-7 packets, or 30-40 milliseconds, before the game then resumes responding again. Once this initial drop has occurred, the kernel drop one packet every second on the second until the game gives up and disconnects you.

It may be some internal buffer filling up, or the kernel just not being ready for that kind of packet stream. I've attached filtered pcap file of the traffic between me and an unlucky opponent.

DC.pcap.tar.gz

Quickly analysing your packet capture. Some interesting flow. To begin, the exchange of UDP packets is back and forth between parties, eventually we only get packets from the opponent and stop sending our own UDP packets which then results in an ICMP packet generated by us (wrapping the last received UDP packet from peer) and sent to the peer, checking connectivity.

This last UDP packet from peer may be something like "where are you? not heard from you for a while!" We put this UDP packet into an ICMP packet and send it to the peer, to check destination connectivity and get a port unreachable response. After this initial issue, we no longer send UDP packets to the peer and just receive.

Either the peer seems stops listening on its port for some reason or we are unable to send on that port ourselves Here the ports in question is, us = 52602 and peer = 64572 both need to be open on both ends for communication. It worked initially, why not now?

Also more packet captures to analyse, better yet, packet capture from @Gin845 @failtech to see what it looks like running normal Some windows user captures... what ports are used etc Maybe we can capture the UDP port traffic on linux and find out why it is becoming "unreachable" is it always the sender or receiver that stops?

I will run my own capture when i get time and report back if the symptoms are the same.

Hope this helps

[NANISOREH]

The situation with disconnections should hopefully be much better with the just updated Proton Experimental ([bleeding-edge] branch).

Should I then change to Proton Experimental or stick with Proton Hotfix?

EDIT: nvm I didn't know there were beta for Proton Experimental https://github.com/ValveSoftware/Proton/wiki/Proton-Versions#proton-bleeding-edge

EDIT2: I tested player matches and I didn't disconnected a single time with Proton Experimental Bleeding Edge

I tested Bleeding Edge as well and it looks like everything works for me too online-wise! I hope this fix gets merged soon into the stabler builds.

[MrMamba11]

Made an account just to say I was disconnecting constantly before, now I just played 3 hours of online matches with friends on the latest version of bleeding edge on proton experimental without a single disconnect. Thank you!!!

[gofman]

Thanks all for confirming! The fix is also on Proton Hotfix which should be currently selected by default on Steam Deck for the game (that is, if no compatibility tool for the game is specified in properties).

[DelusionalLogic]

@gofman Do you happen to know what fixed it? I'm looking at the bleeding-edge branch and all I see is a wine version bump.

[CNB-Kevin]

@DelusionalLogic https://gitlab.winehq.org/wine/wine/-/commit/fd2534422ba66d66cc811c75d012b2b1060d1770 https://gitlab.winehq.org/wine/wine/-/commit/bd2a2c25f54e33b5ffae1f28f5ead4b020f55456

From what I can guess, wine's http implementation was blocking when it the other side was waiting for a reply. But this code is going over a little bit over my head.

[ravimahal]

Do we still need to specify our correct locales in the launch options?

[Andrew32bit]

Thanks all for confirming! The fix is also on Proton Hotfix which should be currently selected by default on Steam Deck for the game (that is, if no compatibility tool for the game is specified in properties).

So I can set Proton Hotfix on steam deck and it will work bcs it was fix-commit, am I right?

[danth]

Do we still need to specify our correct locales in the launch options?

This was always necessary for TEKKEN 7, so I would assume yes.

[Andrew32bit]

I can confirm that it works now

[stephanhorvath]

On Steam Deck. I am still unable to connect to the servers. I don't know if it is a different issue, but when I start the game and get to start screen where it attempts to connect to the network, I get this error:

Failed to connect to the network.
Online Mode is unavailable.
[Error code: C-00001-00898-1/]

System Information

GPU: AMD Custom GPU 0405
CPU : AMD Custom APU 0405 2.8GHz
RAM: 14.45GB
OS : SteamOS Holo, ver. 3.5.7
OS build version: 20231122.1
Video driver version: 4.6 (Compatibility Profile) Mesa 23.1.3 (git-58f7632462)
Kernel version: 6.1.52-valve9-1-neptune-61
Proton version: Hotfix (have also tried Experimental)

[Andrew32bit]

Replying to https://github.com/ValveSoftware/Proton/issues/7444#issuecomment-1916466875

try to set _HOST_LC_ALL=deDE.UTF-8 %command% . Im playing from steam deck without this extra option, but using proton hotfix

[stephanhorvath]

try to set _HOST_LC_ALL=deDE.UTF-8 %command% . Im playing from steam deck without this extra option, but using proton hotfix

Thanks for the suggestion. I already had HOST_LC_ALL=en_GB.UTF-8 %command% in my launch options. I tried 'de_DE' instead, and have also tried 'da_DK.UTF-8' and 'da_utf8'. None of these have made a difference for my problem, unfortunately.

[punishedJib]

After playing for some time the game will start running at 30fps in slowmotion. If the slowdown started in training mode, when entering a match it stops, but once back in training mode it starts again. If it started mid match it will last until the end, but I usually just quit since it's unplayable, so I don't know how it will behave.

• GPU: NVIDIA 3070
• Video driver version: 545.29.06-14
• Kernel version: 6.7.1-zen1-1-zen
• Proton version: Proton GE 8-29

Launch options: HOST_LC_ALL=en_GB.UTF-8 gamemoderun %command%

[msmalik681]

GPU: GTX 1060 3GB Kernel version: 5.15.0-92-generic Video driver version: nvidia-driver-535 Proton version: Proton GE 8-29

When starting any online option like fight lounge the game locks up and crashes.

steam-1778820.log

[temporaryroman0]

Replying to https://github.com/ValveSoftware/Proton/issues/7444#issuecomment-1916681285

I have the same issue on Nvidia. Online is fixed, but now after playing for about an hour, the VRAM and GPU get maxed out and the game starts to run at 20 fps in match. I have to restart the game to make it working normal again.

GPU: Nvidia RTX 2060 Super Kernel version: 6.7.2.arch1-1 Video driver version: nvidia-545.29.06-14 Proton version: Proton Hotfix 01292024

[KawaiiDinosaur]

Replying to https://github.com/ValveSoftware/Proton/issues/7444#issuecomment-1916947249

Have you tried raising vm.max_map_count on your system? I know lower map counts can cause issues on Unreal based games.

https://wiki.archlinux.org/title/gaming#Game_compatibility

[gofman]

@gofman Do you happen to know what fixed it? I'm looking at the bleeding-edge branch and all I see is a wine version bump.

@DelusionalLogic https://gitlab.winehq.org/wine/wine/-/merge_requests/4967

[temporaryroman0]

Replying to #7444 (comment)

Have you tried raising vm.max_map_count on your system? I know lower map counts can cause issues on Unreal based games.

https://wiki.archlinux.org/title/gaming#Game_compatibility

Unfortunately it didn't help. Not only the VRAM gets maxed out, but RAM usage creeps up from 9 to 11GB and swap (uncompressed zram) from 0 to 6GB before the slowdown to 20 fps starts to happen. If it starts in training mode after loading into the match it can be normal again, but not all the time.

[NANISOREH]

Replying to https://github.com/ValveSoftware/Proton/issues/7444#issuecomment-1917990044

I noticed the same behaviour. At least it encourages me to take pauses, but I doubt it's normal. Anyway, how much VRAM do you have? UE5 games are incredibly VRAM hungry, I can basicly only play on Low setting myself because I have a 6GB 3060 and everything past that apparently requires at least 8. Weird thing is, as you noted, VRAM usage significantly increases over time.

If I play on one simpler stage, and it's using 4,5gb of VRAM, then move to a different stage with a lot more assets, the VRAM usage ramps up, but it never goes down if I go back to the previous stage, and if I didn't have slowdowns before, I start having them. Is this how VRAM allocation usually works?

[temporaryroman0]

Replying to https://github.com/ValveSoftware/Proton/issues/7444#issuecomment-1918022898

I disabled SWAP completely. I was able to play for two hours without slowdown before RAM completely maxed out starting from 9gb all the way to 16gb, then the game crashed. VRAM maxed out pretty quickly from 6gb to 8gb, however it seems like the issue is RAM and SWAP usage here.

[rbrauer]

Thanks to everyone who has been helping. I usually crash with this assert after around an hour. It has happened on various Proton versions, but this example was GE 8-29.

If other people haven't seen this one, I might not be a good example because my Steam install is a little weird. I somehow got it to work with a library on an external that I previously used with Windows and some stuff is symlinked. I haven't had issues with other games though.

GPU: GeForce GTX 1660 Driver: 4.6.0 NVIDIA 535.154.05 Kernel: 6.7.2-arch1-1 KWin / KDE 5.114.0 / Plasma 5.27.10 GE-Proton8-29

I don't actually know if any of these environment variables are actually helpful.

LD_BIND_NOW=1 PROTON_LOG=1 WINE_DISABLE_VULKAN_OPWR=1 PROTON_ENABLE_NVAPI=1 %command%

steam-1778820.log

[OllieOlafsson]

Replying to https://github.com/ValveSoftware/Proton/issues/7444#issuecomment-1918022898

System Information

GPU: NVIDIA GeForce RTX 4050 Max-Q / Mobile (6GB) CPU: 12th Gen Intel i5-12450H (12) @ 4.400GHz Video Driver: 4.6 Mesa 23.3.4-arch1.2 RAM: 16 GB Kernel Version: 6.7.2-zen1-1-zen OS: Arch Linux Proton: tests on various, similar results (Bleeding Edge Experimental, GE 28 and 29, Hotfix)

Symptoms

On my machine, most of the time, the crashes occur during loading screens. Usually I get (up to) a 40 minute period of smooth sailing before the game closes in my face and I am notified with a popup notification on GNOME "Device memory is nearly full. Steam was using a lot of memory and was forced to stop". I have monitored the VRAM usage and it skyrockets during matchup loading screens up to my maximum of 6GB. Also, lowering the graphics settings to the minimum did not prevent the crashes from my experience.

(I will note there was one isolated case as well where Firefox crashed in the same way as the game.)

[msmalik681]

I am still having a issue with not being able to load any of the online options they immediately lock up my game and after a while it will close. Please help. tested on ryzen and intel systems.

GPU: GTX 1060 3GB Kernel version: 5.15.0-92-generic Video driver version: nvidia-driver-535 Proton version: Hotfix

steam-1778820.log

[DelusionalLogic]

@DelusionalLogic https://gitlab.winehq.org/wine/wine/-/merge_requests/4967

Ahh yes, I think I see the bug happening in my log. This happens right as my games stops sending packets. Notice the WS2_sendto returncode of 0xc00000a3. which indeed translates to WSAEWOULDBLOCK.

19239.809:0144:0544:trace:winsock:inet_ntop family 2, addr 00000001A627F914, buffer 00000001A627EDB0, len 65
19239.809:0144:0544:trace:winsock:WS2_sendto socket 0x1b8, buffers 000000004E517810, buffer_count 3, flags 0, addr 00000001A627DBD0, addr_len 128, overlapped 0000000000000000, completion 0000000000000000
19239.809:0144:0544:trace:winsock:sock_ioctl handle 0x1b8, code 0x120338, in_buffer 0x1a627c7a0, in_size 32, out_buffer (nil), out_size 0
19239.809:0144:0540:trace:winsock:WS2_sendto socket 0x1b8, buffers 000000014B701B80, buffer_count 4, flags 0, addr 00000001A497F590, addr_len 128, overlapped 0000000000000000, completion 0000000000000000
19239.809:0144:0540:trace:winsock:sock_ioctl handle 0x1b8, code 0x120338, in_buffer 0x1a497ead0, in_size 32, out_buffer (nil), out_size 0
19239.809:0144:0540:trace:winsock:WS2_sendto status 0xc00000a3.
19239.809:0144:0544:trace:winsock:WS2_sendto status 0.

Thank you for the link :)

[leifliddy]

@rbrauer I'm relatively new to steam and haven't used it in years. But I had to get Tekken 8 ; )

Anyways, I kept running into that assertion failed error -- which always occurs between matches -- as it's loading the next match.

My setup is currently:

GPU: GeForce RTX 3070 (8 GB)
Driver: NVIDIA 545.29.06
Kernel:6.6.13-200.fc39.x86_64 
DE: Cinnamon 6.0.4
GE-Proton8-30 (Same behaviour with Hotfix and Experimental)

[leifliddy]

Odd.....so that error is coming from this vkCreateSwapchainKHR function

VkResult WINAPI vkCreateSwapchainKHR(VkDevice device, const VkSwapchainCreateInfoKHR *pCreateInfo,
                                     const VkAllocationCallbacks *pAllocator, VkSwapchainKHR *pSwapchain)
{
    struct vkCreateSwapchainKHR_params params;
    struct vk_swapchain *swapchain;
    NTSTATUS status;

    if (!(swapchain = malloc(sizeof(*swapchain))))
        return VK_ERROR_OUT_OF_HOST_MEMORY;
    swapchain->unix_handle = 0;

    params.device = device;
    params.pCreateInfo = pCreateInfo;
    params.pAllocator = pAllocator;
    params.pSwapchain = pSwapchain;
    params.client_ptr = swapchain;
    status = UNIX_CALL(vkCreateSwapchainKHR, &params);
    assert(!status);
    if (!swapchain->unix_handle)
        free(swapchain);
    return params.result;
}

https://github.com/ValveSoftware/wine/blob/experimental_8.0/dlls/winevulkan/loader.c#L628C1-L649C2 I'm referencing the experimental branch, because there is no hotfix branch. https://github.com/ValveSoftware/wine/branches

So, it's failing on this

    status = UNIX_CALL(vkCreateSwapchainKHR, &params);
    assert(!status);

hmmm....I'm looking at what the specification for that function https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/vkCreateSwapchainKHR.html

And I'm wondering how to get the actual error returns. Need to enable logging and see if steam has a debug mode....

[rbrauer]

I don't know what is causing the issue, but based on some of the previous comments here suggesting people are seeing continuously increasing VRAM usage while playing, I wouldn't be surprised if the assert is being triggered by that out of memory check.

[NANISOREH]

@rbrauer I confirm that I'm experiencing slightly suspect VRAM behaviour. If I play on more than low settings (1080p), even with DLSS on, VRAM usage increases with time to the point where if fills up the 6gb I have and starts lagging, then crashes on me. The only culprit of the lag in that case would be VRAM usage, because on medium settings both the GPU and the CPU are basicly chilling well under 50% while the VRAM usage is stuck at 95% of the available memory. I wasn't able to find a clear pattern to the crashing, it just hangs randomly after some minutes of high VRAM usage. If I use low settings, it still grows way more than it should according to video benchmarks of the game, but not enough to make it crash in a gameplay session's time. I don't necessarily think vkd3d is at any fault here, it might just be that the game requires more than 6gb even at 1080p and starts low on usage by trying to save up space. Or it might be some driver bug. Maybe someone that can test a similar scenario (6GB VRAM card, 1080p) on Windows too could confirm that it's generally impossible to get constant 60fps without lowering everything?

My current setup:

GPU: GeForce RTX 3060 Mobile / Max-Q (6GB VRAM)
Driver: NVIDIA 545.29.06
Kernel: 6.5.0-15-generic 
DE: Cinnamon 6.0.4
GE-Proton8-30 (Same behaviour with Hotfix and Experimental)

Update: I noticed my distro finally had 545 drivers in its repos, so I tested them out but I have the same issue. Also tested it with and without the launch option to disable resizable bar. My current launch options: HOST_LC_ALL=it_IT.UTF-8 MANGOHUD=1 PROTON_ENABLE_NVAPI=1 PROTON_LOG=1 gamemoderun %command%

[leifliddy]

@NANISOREH I think you're right, there's likely a memory leak problem. It's so odd -- it only freezes on the scenes before a match starts. The first match always plays fine -- but it'll eventually locked up on a subsequent match

In fact, it just locked up here -- right before the 2nd match started

The steam log is available here: https://leifliddy.com/.steam/steam-1778820.log

Also, I ran this command while steam was running -- up until it locked up.

[leif.liddy@black ~]$ nvidia-smi --query-gpu=timestamp,name,utilization.gpu,memory.total,memory.free,memory.used --format=csv -l 5
timestamp, name, utilization.gpu [%], memory.total [MiB], memory.free [MiB], memory.used [MiB]
.......
2024/02/02 05:21:28.268, NVIDIA GeForce RTX 3070, 9 %, 8192 MiB, 1557 MiB, 6413 MiB
2024/02/02 05:21:33.269, NVIDIA GeForce RTX 3070, 46 %, 8192 MiB, 1317 MiB, 6653 MiB
2024/02/02 05:21:38.269, NVIDIA GeForce RTX 3070, 94 %, 8192 MiB, 1266 MiB, 6704 MiB
2024/02/02 05:21:43.273, NVIDIA GeForce RTX 3070, 72 %, 8192 MiB, 396 MiB, 7574 MiB
2024/02/02 05:21:48.274, NVIDIA GeForce RTX 3070, 73 %, 8192 MiB, 363 MiB, 7607 MiB
2024/02/02 05:21:53.274, NVIDIA GeForce RTX 3070, 83 %, 8192 MiB, 185 MiB, 7785 MiB
2024/02/02 05:21:58.274, NVIDIA GeForce RTX 3070, 84 %, 8192 MiB, 97 MiB, 7873 MiB
2024/02/02 05:22:03.275, NVIDIA GeForce RTX 3070, 93 %, 8192 MiB, 96 MiB, 7874 MiB
2024/02/02 05:22:08.275, NVIDIA GeForce RTX 3070, 88 %, 8192 MiB, 149 MiB, 7821 MiB
2024/02/02 05:22:13.276, NVIDIA GeForce RTX 3070, 97 %, 8192 MiB, 157 MiB, 7813 MiB
2024/02/02 05:22:18.277, NVIDIA GeForce RTX 3070, 84 %, 8192 MiB, 150 MiB, 7820 MiB
2024/02/02 05:22:23.277, NVIDIA GeForce RTX 3070, 92 %, 8192 MiB, 151 MiB, 7819 MiB
2024/02/02 05:22:28.277, NVIDIA GeForce RTX 3070, 77 %, 8192 MiB, 91 MiB, 7879 MiB
2024/02/02 05:22:33.278, NVIDIA GeForce RTX 3070, 93 %, 8192 MiB, 143 MiB, 7827 MiB
2024/02/02 05:22:38.278, NVIDIA GeForce RTX 3070, 83 %, 8192 MiB, 139 MiB, 7831 MiB
2024/02/02 05:22:43.278, NVIDIA GeForce RTX 3070, 98 %, 8192 MiB, 269 MiB, 7701 MiB
2024/02/02 05:22:48.279, NVIDIA GeForce RTX 3070, 27 %, 8192 MiB, 156 MiB, 7814 MiB
2024/02/02 05:22:53.279, NVIDIA GeForce RTX 3070, 6 %, 8192 MiB, 155 MiB, 7815 MiB

You can see how it progressively eats more and more memory -- until there's nothing left. I'm pretty sure that's not normal, but who knows.... I hope someone's able to figure this out

You know....I just remembered that I'm power limiting my card with nvidia-smi -pl 180 upon boot up. I haven't used steam in ages so I completely forgot about it. I'll unrestricted the power limiter (to 240 watts) and see if that makes any difference.

UPDATE: Nope, same issue occurred after increasing power limit, but I made it to the 4th match this time -- where is crashed on the loading screen

[leifliddy]

I've seen issue like this where xorg was eating up all of the vram https://github.com/ValveSoftware/steam-for-linux/issues/9638

But that doesn't seem to be the case here as Polaris-Win64-Shipping.exe seems to be the main culprit

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A      2104      G   /usr/libexec/Xorg                          1080MiB |
|    0   N/A  N/A      3196      G   cinnamon                                    131MiB |
|    0   N/A  N/A      6687      G   ...,262144 --variations-seed-version=1      279MiB |
|    0   N/A  N/A     81994      G   ...local/share/Steam/ubuntu12_32/steam        3MiB |
|    0   N/A  N/A     82011      G   ...re/Steam/ubuntu12_64/steamwebhelper        4MiB |
|    0   N/A  N/A     83236    C+G   ...es\Win64\Polaris-Win64-Shipping.exe     6309MiB |
+---------------------------------------------------------------------------------------+

[NANISOREH]

@leifliddy In my case, if I always ever play in the same stage (didn't test if changing characters is the same), I don't notice a spike in VRAM usage over time. If I'm in player matches rematching the same person over and over again the VRAM usage is likely to stay the same. Whenever I start playing in different stages the memory usage goes up regardless of the stage (but heavier ones like Sanctum or Ortiz Farm are definitely worse). This makes the new ranked rules (ft2 and you're out of the set) a bit painful, because I need to restart the game for every 4-5 opponents I find.

Again, in some stages the usage is barely above 4gb when I first load them, but if I get back to those same conditions after cycling some other stages, the game now needs all the 5,8gb that it can get despite showing the very same assets it was showing before. Even when going back to the main menu after some gameplay in different stages, it shows a significantly higher VRAM usage than when I first boot the game. So it's either a quirk of UE5 games ramping up the memory requirements slowly until reaching a "stable" point or something is failing to free up memory. I'd like to test it on Windows but I don't have access to a Windows system right now.