Performance issues on Linux

[Ciordeala]

I have recently installed this on Linux Mint 20.3 and I am getting performance issues, namely the frame rate is choppy. It's still playable, but it is uncomfortable to play for too long because of the choppy visuals. I have tried lowering the graphical settings but no matter how high or low I set them I get the same result. I also have the official nvidia driver installed.

On the same machine I have a Windows 7 install and it runs perfectly smooth there, so I know it's not an issue of inadequate hardware. I know I could just boot into Windows and play it but I would have preferred if I could play it on Linux since that is my main OS on this PC.

Any ideas?

[nbohr1more]

What drivers do you have installed ?

What GPU and CPU models ?

Do you have FPS set to uncapped ( huge improvement to smoothness even when below 60 FPS )?

Is vsync set to adaptive or off ?

[Ciordeala]

Setting the FPS to uncapped seems to have done the trick. Thank you so much!

[OrbWeaver]

I seem to remember having this issue too. It's strange but the built-in FPS cap doesn't seem to work well on Linux. Perhaps there is some low-level problem determining the correct FPS from the X window system (or Wayland if you're using it).

[nbohr1more]

Something about Doom 3's FPS cap method is incompatible with modern drivers and accelerated desktop render techniques.

Capping FPS should make GPU resources available for the next frame so it should make things smoother when you are near or slightly above 60 FPS. Instead, it can steal as much as half the FPS performance even in pretty light scenes.

Setting uncapped FPS increases performance even if you use the "new" Max FPS cap that TDM uses and set it to 60.

We should probably default to uncapped FPS with max fps set to 60 and leave the old Doom 3 cap method as a developer cvar.

[cabalistic]

I think what happens is that the old method caps the framerate at just slightly below 60 fps - which means that in combination with VSync (either enabled in the game or forced by the compositor) will drop the framerate to 30 fps most of the time.

[stgatilov]

5 hours ago, OrbWeaver said:

I seem to remember having this issue too. It's strange but the built-in FPS cap doesn't seem to work well on Linux. Perhaps there is some low-level problem determining the correct FPS from the X window system (or Wayland if you're using it).

There is platform-specific piece of code which creates OS timer that wakes up every so often and bumps "tic number".
This code is completely different on Windows and Linux. Perhaps Linux code is just bad in some way.

[OrbWeaver]

Yeah, having a completely independent timer seems like a recipe for desychronisation problems.

Probably what I'd do is:

1. If the display frame rate is less than or equal to the cap value, just enable vsync and don't do any manual synchronisation — it's not adding any value beyond what vsync does naturally.
2. If the display frame rate is greater than the cap:
   1. After a frame is actually displayed (i.e. vsync is completed and the buffer swap has happened), store the current time in a variable.
   2. When the next frame is ready to be shown, compare the current time with the value stored in the previous step. If not enough time has elapsed, pause for the required number of milliseconds (or slightly less) before displaying the next frame.

Of course this assumes that there are suitable platform-specific methods to obtain the actual display frame rate. I can imagine this might be problematic on Linux given there are two different display servers and several desktop compositors in use.

Perhaps the quick and dirty solution on Linux is just to enable vsync by default, then disable the frame rate cap by default (since vsync will take care of it)?