Optimizing FreeBSD for gaming?

ecd · Aug 4, 2011

Hi,

I'm still somewhat new to FreeBSD, converted from linux (ubuntu if you must know). I'm trying to play the same video game under wine in FreeBSD 8.2-RELEASE x86 as I did in Ubuntu, and it is significantly slower in terms of framerate.

I'm seeking any advice on how to improve my gaming experience. Thus far, here's what I've tried:

Ensured soft-updates are enabled on my primary filesystems (was already set by default I believe)
Disabled atime updates on my primary filesystems
Updated to use a kernel which doesn't load most of the unnecessary modules for my system
Disabled all server daemon processes (e.g., nfsd)
Reduced the number of virtual terminals I have from 8 to 3 (via /etc/ttys)

Added the following to my /etc/make.conf

Code:

CPUTYPE?=athlon64
CFLAGS= -O2 -fno-strict-aliasing -pipe
COPTFLAGS= -O2 -pipe -funroll-loops

Ensured all my ports were up-to-date and upgraded them as necessary with portupgrade
Switched to a more lightweight window manager (fluxbox)

My system is a Acer Aspire x1200-U1510A (AMD Athlon 64x2 5000+, 4GB RAM), with an added Nvidia GeForce 9400 (yes, I'm using the "nvidia" driver).

I've also recently configured my system to use dtrace and I've started to try to analyze the game process to identify bottlenecks. I've seen some odd behavior (such as calling the open system call on a directory thousands of times).

I'm starting to worry that there isn't much I can do since the bottleneck is likely in the video card drivers.

My next ideas are to do further dtrace or truss analysis and then try running the game from a tmpfs filesystem.

If anyone has any suggestions either for performance improvements or areas I should look into, please respond

vermaden · Aug 4, 2011

ecd said:
[*]Ensured soft-updates are enabled on my primary filesystems (was already set by default I believe)

Try using ZFS which may (or not) increase overall performance.

[*]Updated to use a kernel which doesn't load most of the unnecessary modules for my system

This only takes a few MB's of RAM, nothing more, it wont make it faster, well, maybe a boot process.

[*]Disabled all server daemon processes (e.g., nfsd)

Thats generally good practice to disable daemons that You do not use, no matter if You gain performance or not, but disabling devd or cron wont make Your games faster

[*]Reduced the number of virtual terminals I have from 8 to 3 (via /etc/ttys)

That also only saves RAM, but I also often drop to 4 instead of 8.

Code:
[*]Added the following to my /etc/make.conf

Code:

CPUTYPE?=athlon64 CFLAGS= -O2 -fno-strict-aliasing -pipe COPTFLAGS= -O2 -pipe -funroll-loops

These are the defaults mate (-O2 -fno-strict-aliasing -pipe) ;p

You only added CPUTYPE and -funroll-loops

[*]Ensured all my ports were up-to-date and upgraded them as necessary with portupgrade

Try portmaster, it does not need ruby, it does not create its own unneeded database and probably is better now then portupgrade.

I've also recently configured my system to use dtrace and I've started to try to analyze the game process to identify bottlenecks. I've seen some odd behavior (such as calling the open system call on a directory thousands of times).

Post this to freebsd-stable [AT] freebsd.org or freebsd-questions [AT] freebsd.org for clarification if its a BUG or not.

If anyone has any suggestions either for performance improvements or areas I should look into, please respond

You may also check various xorg.conf options of the driver.

poh-poh · Aug 4, 2011

/head branch may have some improvements in device drivers (e.g. ahci(4), ata(4)), etc. as well as there are many patches still uncommitted floating around mailing lists and GNATS, e.g. tmpfs
using IO scheduler can improve interactivity during write load, pick either gsched(8) or vfs.zfs.vdev.max_pending
allowing kernel to better manage IRQ routing by loading non-MSI drivers together with kernel from loader(8) and using MSI/MSI-X can improve performance (e.g. nvidia-driver + MSI = PR ports/156386)
compiling with clang/gcc46 + CPUTYPE?=native + -O3 unlike gcc + -funroll-loops is more likely to have noticeable difference. As some options can actually degrade performance it's better to benchmark them with time/pmcstat/ministat.

I'd also try storing entire game including its data on swap-backed tmpfs depending on how often it's evicted from VFS cache.

expl · Aug 6, 2011

File system and compiler options have little effect when it comes to gaming via wine. Get latest beta drivers from NVidia as they will have best performance code for your GPU. Try to overclock your GPU with nvidia-settings (can find some guides for linux how to load your card in overclock mode, they work on freebsd as well just know your card's limits). Second you need to tweak your wine, it helps A LOT. In some cases can expect double FPS. Check out http://wiki.winehq.org/UsefulRegistryKeys

pkubaj · Aug 6, 2011

poh-poh said:
/head branch may have some improvements in device drivers (e.g. ahci(4), ata(4)), etc. as well as there are many patches still uncommitted floating around mailing lists and GNATS, e.g. tmpfs

using IO scheduler can improve interactivity during write load, pick either gsched(8) or vfs.zfs.vdev.max_pending

allowing kernel to better manage IRQ routing by loading non-MSI drivers together with kernel from loader(8) and using MSI/MSI-X can improve performance (e.g. nvidia-driver + MSI = PR ports/156386)

compiling with clang/gcc46 + CPUTYPE?=native + -O3 unlike gcc + -funroll-loops is more likely to have noticeable difference. As some options can actually degrade performance it's better to benchmark them with time/pmcstat/ministat.

I'd also try storing entire game including its data on swap-backed tmpfs depending on how often it's evicted from VFS cache.

Is Clang really better than the bundled GCC 4.2? AFAIK Clang compiles faster, but the compiled binaries run slower. As for GCC4.6, do all the ports (or at least most of them) compile successfully and work well (without errors nonexistent in binaries compiled with GCC 4.2)?

xibo · Aug 6, 2011

Is Clang really better than the bundled GCC 4.2? AFAIK Clang compiles faster, but the compiled binaries run slower. As for GCC4.6, do all the ports (or at least most of them) compile successfully and work well (without errors nonexistent in binaries compiled with GCC 4.2)?

I cannot build kdemultimedia4 with gcc45/46, because of some dependencies of it (musicbrainz). IMO gcc is working propperly here though, some other software is just written poorly

As for clang, it compiles faster then gcc, and the binaries it creates run faster then those made by gcc. If you're looking for a compiler that compiles fast and don't care much about the speed of the built binaries you should take a look at the portable c compiler (pcc) ...

pkubaj · Aug 6, 2011

xibo said:
I cannot build kdemultimedia4 with gcc45/46, because of some dependencies of it (musicbrainz). IMO gcc is working propperly here though, some other software is just written poorly

As for clang, it compiles faster then gcc, and the binaries it creates run faster then those made by gcc. If you're looking for a compiler that compiles fast and don't care much about the speed of the built binaries you should take a look at the portable c compiler (pcc) ...

It'q quite the opposite, actually. I don't care how long a compiler takes to compile - I leave my PC on overnight anyway. I want the binaries to work as quickly as possible. What's better in that case: gcc46 (or even gcc47, provided it's stable enough for everyday use) or clang? I use 9.0-BETA1 with clang 3.0 bundled (not the stable 2.9).

rusty · Aug 7, 2011

I use an 8.2-RELEASE for games via Wine on FreeBSD. No changes bar vfs.read_max from 8 to 32 and increased vfs.ufs.dirhash_maxmem from 2MB to 8MB.
LotRO was giving me trouble on 8.2-STABLE and 9.0-CURRENT so I tried a recent Linux distro to see how things performed.
For the time it took to get running I was actually quite disapointed, especially considering this Linux has a very recent kernel, EXT4, Xorg etc. As a comparison FreeBSD 8.2-R is using Xorg 1.7.5 which was released in Feb 2010.

FreeBSD was ~5fps better at the top-end. Minimum framerates were much lower on Linux, eg entering a new area/highly populated area, fps would drop to just over double figures and took much longer to get back to normal fps, whereas on FreeBSD the fps would drop to 25-30fps but almost instantly return to 55+ resulting in much smoother gameplay.

Load times were almost 3 secs faster using UFS2 compared to EXT4, from start to login screen; 14 secs for Linux, just over 11 secs for FreeBSD.