Difference between revisions of "Smooth Quake in Linux"

From QWiki
Line 165: Line 165:
 
To set your refresh in an xorg configuration file, please see the Arch wiki on the subject: https://wiki.archlinux.org/index.php/Xorg#Using_.conf_files
 
To set your refresh in an xorg configuration file, please see the Arch wiki on the subject: https://wiki.archlinux.org/index.php/Xorg#Using_.conf_files
  
−
==Sound==
+
===CPU Affinity===
  
 +
Normally the individual threads spawned by ezquake will be managed by the kernel and will be moved from one core to another as various conditions are met. While for most workloads this is fine, there is some inherent latency with this method, so we prefer to bind each thread to a physical core instead. You can see this default behavior by running ezquake and then running ps in a terminal:
  
−
'''ezQuake 2.1 new soundcode:'''<br>
+
<pre>
−
ezQuake 2.1 has new soundcode for ALSA/OSS/Pulseaudio ported from FodQuake. This will allow you to have other sound sources
+
watch -n .5 'ps -L -o pid,tid,%cpu,comm,psr -p `pgrep ezquake`'
−
than only ezQuake. <br>
+
</pre>
−
*Choose sound driver with '''''s_driver alsa/oss/pulse'''''<br>
 
−
*If you are running on a system without pulseaudio and got problems with new ALSA code, you can first try setting ''s_alsa_noworkaround 1'' and do ''s_restart''.<br>
 
−
*If that doesn't help, you can switch to the old drivers (called legacy) with ''cl_uselegacydrivers 1'' for ALSA/OSS (still chosen by s_driver).<br>
 
−
*Pulseaudio will need to be set in config files before starting client in order to work. (Pulseaudio code is treated as experimental)<br>
 
  
 +
The output should look something like the following:
 +
<pre>
 +
  PID  TID %CPU COMMAND        PSR
 +
15461 15461 40.0 ezquake-linux-x  3
 +
15461 15462  0.0 PulseHotplug      3
 +
15461 15463  0.4 SDLAudioP2        0
 +
</pre>
  
−
'''Information below is for the old soundcode ONLY:'''
+
In this example the first row represents the main ezquake thread while the following rows indicate other threads it has spawned. The last column shows you which core each thread is running on. By running this command with watch as we have, we can see the threads being moved around.
−
* Got software mixing and problems with sound in ezquake? SOLUTION: add +set s_device dmix to command line and don't use local .asoundrc <br>
 
−
* if you don't get sound at all with those settings try doing these things:<br>
 
−
- add yourself to group 'audio' ($ addgroup username audio) ; then disconnect/reconnect (login)<br>
 
−
- $ echo 'ezquake-gl.glx 0 0 direct' > /proc/asound/card0/pcm0p/oss (might need to chmod it first)<br>
 
−
* If sound doesn't work try oss -noalsa -snddev /dev/dsp (1517) or +set s_noalsa 1 +set s_device /dev/dsp in 1754.
 
−
* Very good guide to fix soundproblems  http://ubuntuforums.org/showthread.php?t=205449&highlight=onboard+sound $$$ link
 
  
 +
If we want to bind each thread to a core, we can use the following bash script to do so once ezquake has been up and running for a few seconds:
 +
 +
<pre>
 +
#run quake and background
 +
/path/to/quake/ezquake-linux-arch &
 +
qpid=$(pgrep -f ezquake-linux-arch)
 +
 +
#allow threads to spawn
 +
sleep 5
 +
 +
#set thread affinity - sorted based on cpu usage so our primary threads will definitely get their own cores
 +
qthreads=$(ps --no-headers -L -o pcpu:1,tid:1 -p ${qpid}|sort -nr|cut -d" " -f2)
 +
 +
#set affinity, if we run out of physical cores to pin threads to, let the system decide where they go
 +
core=0
 +
for thread in $qthreads;do
 +
taskset -p -c $core $thread >/dev/null 2>&1
 +
let core=core+1
 +
done
 +
 +
wait $qpid
 +
</pre>
 +
 +
A maintained and fully featured version of this script is kept at https://github.com/ciscon/random/blob/master/quake.sh
  
 
==Other Common problems==
 
==Other Common problems==

Revision as of 19:20, 22 April 2019

General

WARNING: Page recently updated and not fully vetted, please consider talking to client developers before doing advanced changes to your system !!!

This page contains solutions and tips for various tearing, lagging, jerky and sucky Quake configurations, on Linux.

  • If you have low fps, try installing proprietary video drivers and disabling compositing (see compositing section below).
  • For minimal tearing set your framerate cap (cl_maxfps) above 1000, and for absolute minimum tearing set to a multiple of your refresh rate (e.g. 1001).
  • Some clients run much better than others under linux. Make sure you try ezQuake, fodQuake and FTE.

Mouse

Change mouse hz to 500/1000

Note: The usb polling rate will automatically be as high as possible on most modern usb controllers (ehci/xhci/etc) in recent linux kernels. It is still worth checking that it is actually running at the desired polling rate as some bios settings can prohibit the polling rate from going above a certain level and may need to be changed.

First and foremost check what your current rate is, it may very well already be at 500/1000 (depending on your mouse and usb controller limits):

Download and compile evhz: 

git clone https://gitlab.com/iankelling/evhz.git
cd evhz
gcc evhz.c -o evhz

Run evhz and move mouse around, see that polling rate reaches desired/expected rate: 

sudo ./evhz

Example output (500Hz mouse): 

...
A..... G3: Latest   500Hz, Average   488Hz
...

If your mouse is not polling as fast as it should be, try forcing a polling rate in the usbhid module. To check current polling rate setting in usbhid, type in console: 

cat /sys/module/usbhid/parameters/mousepoll

Using console, open /etc/modules in editor with admin rights: 

sudo gedit /etc/modules

Add this two lines at the end: 

-r usbhid
usbhid mousepoll=x

value "x" can be:

1 = 1000Hz 2 = 500Hz 4 = 250Hz 8 = 125Hz 10 = 100Hz (Default)

for example, to change polling rate to 500Hz, end lines in /etc/modules schould be: 

-r usbhid
usbhid mousepoll=2

To test immediately without rebooting, type the following as a single command (otherwise you'll lose input on any usb devices you might have): 

sudo rmmod usbhid;sudo modprobe usbhid mousepoll=2

Now run evhz again, if you are still not seeing the polling rate you're expecting it very well may be a bios setting. If you have any usb legacy or compatibility modes in your bios, disable them, this should fix the issue. Warning: disabling usb legacy/compatibility support in your bios may render your usb keyboard/mouse non-functional in grub, do not be alarmed if you cannot navigate the grub menu in this mode. It will still be usable before grub (eg bios) and after the linux kernel has loaded.

Warning: Higher polling rates will increase CPU usage.

Mouse related tools

Screen

Disable compositing:

Xorg has a built-in compositing extension which is enabled by default. Most window managers/desktop environments will provide a composite manager, most of which will automatically redirect fullscreen applications away from the compositor. This is not always the case however, and even when compositing is fully disabled in a composite manager, this redirect can fail. It is recommended that compositing be disabled in your composite manager (see your specific window manager/desktop environment's documentation, it should be a simple checkbox). If quake fails to be redirected properly, you will lose fps and things can appear jerky.

If you would like to completely disable the compositing extension in xorg just to be sure, just add the following file to your xorg.conf.d directory and restart x. Warning: if your window manager/desktop environment requires compositing, it may fail to start or may start a compatibility mode (eg KDE/Gnome): 

sudo mkdir -p  sudo mkdir -p /etc/X11/xorg.conf.d
sudo vi /etc/X11/xorg.conf.d/01-compositor.conf

Contents: 

Section "Extensions"
    Option "COMPOSITE" "Disable"
EndSection


Run quake in a separate X Server:

Note: this will no longer work with systemd which most modern linux distributions unfortunately use.

Users have reported that running a second x server can give a more responsive quake (https://web.archive.org/web/20171112041921/http://www.besmella-quake.com/forum/viewtopic.php?t=338)

Excerpt/Conclusion from the above link:

  • To run your engine in a second X server (which might help on various occasions) on virtual terminal 12 (you could switch between regular X and 2nd one by pressing ctl+alt+f7 and ctr+alt+f12):
xinit /path/to/your/executable_or_script -- :1 vt12
  • If you want you can also create a new xorg.conf for this new X server and specify it via attaching "-config xorg_qw.conf" in the command line.
xinit /path/to/your/executable_or_script -- :1 -config xorg_qw.conf

You can also simply type xinit -- :1 to get an console where you then start the game.


Refresh Rate If you are using a proprietary driver such as the nvidia driver or amdgpu-pro, you are most likely using the supplied control panel to configure your GPU settings and can set the appropriate refresh rate there. If not, you may need to do it manually. You can do this by setting it in an xorg configuration file, or do it on the fly using xrandr. Here we'll look at doing this via xrandr as it's more flexible and we can test changes immediately.

Run xrandr: 

xrandr

You should see output similar to: 

Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm
   1920x1080     60.00 + 144.00*  119.98    99.93  
   1440x900     119.85  
   1280x1024    119.96    75.02    60.02  
   1024x768     119.99    75.03    60.00  
   800x600      119.97    75.00    60.32    56.25  
   640x480      120.01    75.00    59.94

This example output/monitor supports 144Hz and 1920x1080, and you can see that it is set to 1920x1080@144Hz as the asterisk (*) is next to 144 on the 1920x1080 line. You can change this by simply specifying whichever resolution/refresh rate you would like on any particular output: 

xrandr --output DVI-I-1 --mode 1920x1080 --rate 120

This would change the refresh rate to ~120, example output of running xrandr with no options again would show that we have successfully changed our refresh rate: 

xrandr 
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm
   1920x1080     60.00 + 144.00   119.98*   99.93  
   1440x900     119.85  
   1280x1024    119.96    75.02    60.02  
   1024x768     119.99    75.03    60.00  
   800x600      119.97    75.00    60.32    56.25  
   640x480      120.01    75.00    59.94

You can always have this program run on start-up/login by using whichever method your window manager/desktop environment uses to autorun programs.

To set your refresh in an xorg configuration file, please see the Arch wiki on the subject: https://wiki.archlinux.org/index.php/Xorg#Using_.conf_files

CPU Affinity

Normally the individual threads spawned by ezquake will be managed by the kernel and will be moved from one core to another as various conditions are met. While for most workloads this is fine, there is some inherent latency with this method, so we prefer to bind each thread to a physical core instead. You can see this default behavior by running ezquake and then running ps in a terminal: 

watch -n .5 'ps -L -o pid,tid,%cpu,comm,psr -p `pgrep ezquake`'

The output should look something like the following: 

  PID   TID %CPU COMMAND         PSR
15461 15461 40.0 ezquake-linux-x   3
15461 15462  0.0 PulseHotplug      3
15461 15463  0.4 SDLAudioP2        0

In this example the first row represents the main ezquake thread while the following rows indicate other threads it has spawned. The last column shows you which core each thread is running on. By running this command with watch as we have, we can see the threads being moved around.

If we want to bind each thread to a core, we can use the following bash script to do so once ezquake has been up and running for a few seconds: 

#run quake and background
/path/to/quake/ezquake-linux-arch &
qpid=$(pgrep -f ezquake-linux-arch)

#allow threads to spawn
sleep 5

	#set thread affinity - sorted based on cpu usage so our primary threads will definitely get their own cores
	qthreads=$(ps --no-headers -L -o pcpu:1,tid:1 -p ${qpid}|sort -nr|cut -d" " -f2)
	
	#set affinity, if we run out of physical cores to pin threads to, let the system decide where they go
	core=0
	for thread in $qthreads;do
		taskset -p -c $core $thread >/dev/null 2>&1
		let core=core+1 
	done
	
wait $qpid

A maintained and fully featured version of this script is kept at https://github.com/ciscon/random/blob/master/quake.sh

Other Common problems

Missing files error Unlike Windows, Linux is case-sensitive, which means "PaK0.pAk" and "pak0.pak" are different files. If you just copied the Quake directory from your Windows machine, it's possible that there are some files in upper case. Fortunately, that's easy to fix.

  • change to your main quake directory

e.g. 'cd /home/joe/quakeworld'

  • convert every file in your Quake directory (including all subdirectories) to lowercase, run this little script (by faustov@ryba):
#! /bin/bash
#

Cdir ()
{
for elem in * ; do
        if [[ -d "$elem" ]] ; then 
                mv "$elem" "$(echo $elem | sed -e 's/./\L&/g')" 2> /dev/null
                elem=$(echo $elem | sed -e 's/./\L&/g');
                cd "$elem";
                Cdir;
                cd ..;
        else 
                mv "$elem" "$(echo $elem | sed -e 's/./\L&/g')" 2> /dev/null
        fi;
done;
}

Cdir;


Keyboard issues If you get laggy/skippy input from the keyboard when using high refresh rate mouse polling, you could try switching keyboard drivers if you want to keep the mouse the way it is. My keyboard frequently ignored my commands when using 1000hz evdev+ evdev keyboard, so I switched them to mouse/kbd X11 drivers and things seem okay now.

Launch ezQuake by clicking on qw:// links in your browser

KDE (untested):

[Protocol]
exec=/path/to/qw/ezquake-gl.glx +qwurl '%u'
protocol=qw
input=none
output=none
helper=true
listing=false
reading=false
writing=false
makedir=false
deleting=false
icon=package
Description=qw
  • Save this code in ${KDEHOME}/share/services/qw.protocol

Adapted from http://ubuntuforums.org/showpost.php?&p=2618481

Gnome (untested):

gconftool-2 -t string -s /desktop/gnome/url-handlers/qw/command exec /path/to/qw/ezquake-gl.glx +qwurl "%s"
gconftool-2 -t bool -s /desktop/gnome/url-handlers/qw/enabled true
gconftool-2 -t bool -s /desktop/gnome/url-handlers/qw/needs_terminal false

Adapted from http://ubuntuforums.org/showpost.php?&p=2618481

Firefox:

Create a new file containing this: 

#!/bin/sh
#
# ezquake launcher script for qw:// links
#
exec /path/to/qw/ezquake-gl.glx +qwurl "$@"
  • Save it as qwconnect.sh and chmod +x it. Place it in your qw folder.
  • In Firefox go to about:config.
  • Rightclick, "new" -> "string": "network.protocol-handler.app.qw" "/path/to/qwconnect.sh"
  • Rightclick, "new" -> "boolean": "network.protocol-handler.external.qw" "true"
  • Rightclick, "new" -> "boolean": "network.protocol-handler.warn-external.qw" "false" (unless you want that "are you sure" box)

Compile ezQuake yourself

You can use GIT to get the latest development sources and compile ezQuake yourself.

Prerequisites

  • A working Internet connection
  • Installed software
    • git (package git)
    • gcc, make... and a sane buildsystem (mainly build-essential)
    • libraries, see below

Procedure

  • change to your home directory
cd ~
  • checkout the code from git to folder ezquake
git clone git://github.com/ezQuake/ezquake-source ezquake
  • install necessary libraries (for Ubuntu)
sudo apt-get install libgl1-mesa-dev libglu1-mesa-dev libasound2-dev x11proto-xf86dga-dev x11proto-xf86vidmode-dev libxxf86dga-dev libxxf86vm-dev libxext-dev libsvga1-dev libxpm-dev
  • for OpenSUSE
sudo zypper install freeglut-devel alsa-devel
  • change to libs directory
cd ezquake/libs/linux-x86/ (or linux-x86_64 for 64bit)
  • invoke a script downloading precompiled versions
 ./download.sh 

cd ../../
  • compile the OpenGL binary
make glx
  • (optional) Software version SVGA (32bit only)
make svga
  • (optional) Software version X11
make x11

If everything went smoothly, your freshly compiled binary can be found in release-x86/ezquake-gl.glx (or release-x86_64/ dir for 64bit)

Links

Other OS

Windows

See Smooth Quake

Macintosh

If ezQuake doesn't work for you, feel free to try Fodquake http://www.fodquake.net

Retrieved from "https://www.quakeworld.nu/w/index.php?title=Smooth_Quake_in_Linux&oldid=39095"