I can confirm that I have the exact same issue.
Hardware: Ryzen 5 2600, Radeon VII, 32GB RAM, Kernel 5.2.0-2, Debian Unstable, latest Mesa from Oibaf Eoan PPA.
Other people on ProtonDB reported the same issue as well. I tried different Proton versions, including 4.11-5, 4.11-6 and GEs 4.15. I tried the environment variables listed in the readme file here on github, but nothing helped, sadly. It becomes worse the more I explore or move around. Settings ingame don't help much, I only get slightly better performance when I drop the render distance to around 10% (maybe 5-10 more fps, which is still just ~50 out of way over 120 when I don't do anything at all for a few minutes).

Forgot to add that it also happens in multiplayer when I am not the host.

Getting the same issue over here. My frame rate varies from up to 200 FPS when standing still for a while, all the way down single digits when moving around a lot. The number of actors nearby doesn't seem to matter.

During these lag spikes, my CPU usages jumps up to 100% on all cores from about 50%. ~The lag spikes seem to come with a regular period as well, when standing still.~ (EDIT: was probably caused by something else running in the background, the periodic spikes are gone now)

Specs

• Kernel 5.3.0.1-MANJARO
• CPU: Intel i5-4690K @ 3.5 GHz
• GPU: AMD RX Vega 56 (Mesa 19.3.0)
• Memory: 8 GB DDR3

To back up the above post by @Jvanrhijn it looks like it's a CPU issue causing the frame drops. I lowered my resolution down to 640x480 and I still got drops down to 30fps when moving around. I know the Alpha version relied heavily on SQLite and it seems the Beta uses it as well judging by the name of the save files. Not sure if that's relevant or not.

Same problem. Running Manjaro with an i7 4790k and GTX 1080

Game just officially released 2 hours ago, I have the same problem previously talked about in this thread. running solus my system info is here https://hasteb.in/mokikufe.sql

Did a really quick test with ACO and fsync and performance seemed okay with the default settings. If you haven't tried with fsync yet, give it a try and see if that improves anything. If you have it installed, try running perf record -g -p PID_OF_CUBEWORLD.EXE and upload a zip of it here. It's likely that one or two things will light up in perf report -g.

Cube World calls select at regular intervals with no file descriptor and ~16 ms timeout.

select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15912}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15968}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15514}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15979}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15976}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15969}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15986}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15966}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15961}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15938}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=15990}) = 0 (Timeout)

This leads me to the NtDelayExecution function in Wine. Maybe it's some sort of CPU usage limiter gone wrong? (I get a constant 144 fps on Windows)

Proton 4.11-6
perf.zip

@HannesMann If that were the case you'd expect CPU usage to go down during the lag. Also, are those timeouts on the main game thread?

@Guy1524

If that were the case you'd expect CPU usage to go down during the lag.

It's still doing more work than when it's completely idle I guess? It's being limited for a reason.

Also, are those timeouts on the main game thread?

I have no idea but seeing as it's not a problem on Windows it's likely a "world loading" thread being limited from loading chunks too often (CW spawns at least 8 additional threads, two of which deal with world loading/generation).

My theory is that NtDelayExecution is implemented wrong in Wine and is limiting all threads instead of just the calling thread. Either that or it's rendering on one of these other threads and getting slowed down by DXVK (is DXVK multi-threaded?). GPU usage hovers around 10% at 1920x1080 so it's definitively not a problem on the GPU side. I'll get Proton built and see if changing the function makes any difference.

For what it's worth, I disabled DXVK and the problem persisted.

On Fri, 4 Oct 2019 at 17:41, Hannes Mann [email protected] wrote:

@Guy1524 https://github.com/Guy1524

If that were the case you'd expect CPU usage to go down during the lag.

It's still doing more work than when it's completely idle I guess? It's
being limited for a reason.

Also, are those timeouts on the main game thread?

I have no idea but seeing as it's not a problem on Windows it's likely a
"world loading" thread being limited from loading chunks too often (CW
spawns at least 8 additional threads, two of which deal with world
loading/generation).

My theory is that NtDelayExecution is implemented wrong in Wine and is
limiting all threads instead of just the calling thread. Either that or
it's rendering on one of these other threads and getting slowed down by
DXVK (is DXVK multi-threaded?). GPU usage hovers around 10% at 1920x1080 so
it's definitively not a problem on the GPU side. I'll get Proton built and
see if changing the function makes any difference.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3079?email_source=notifications&email_token=AM5XENIK2WB2MT2XLWKHPX3QM62ABA5CNFSM4IZVOB62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAM6T6Q#issuecomment-538569210,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AM5XENKZFZXO7SIAGRLOXKDQM62ABANCNFSM4IZVOB6Q
.

Removing NtDelayExecution completely makes the game run at single-digit FPS. Increasing the delay to 1 sec makes the game smooth but makes it stutter for long periods of time (and the world never loads). The problem definitively seems to be in the "world generation thread", it's probably generating geometry on the GPU on that thread while the game is running on the main thread.

@cain05
I don't think wined3d fares any better at multi-threading than DXVK :)

Yeah, I figured it wouldn't magically fix the issue, but I thought I would test it after your previous post just to rule it out.

I have the exact same issue (was also present in the Alpha version).

AMD Ryzen Threadripper 1950X 16-Core Processor
64268 Mb RAM
NVIDIA GeForce GTX 1080 (435.21)
Gentoo Linux kernel 5.3.5
XFCE 4.14
Proton 4.11-7

I can provide more debug info if needed.
perf.zip

Thank you!

Well, it was a Threadripper issue for me!

I had to lock the process to the first 4 'node 0 cpus' using this launcher option:
taskset -c 0-3 %command%

My NUMA config was loooking like this:

numactl -H
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 0 size: 64269 MB
node 0 free: 49081 MB
node distances:
node   0 
  0:  10

I get steady 120fps now at 100% distance view