PCGamingWiki will soon migrate to a Single Sign On (SSO) system to bridge Wiki and Forum accounts, please read our FAQ.
Nvidia SLI and AMD Crossfire settings
By
WAVEFORM, in Development (concluded)
-
-
Similar Content
-
By Mr. Doomguy
A lot of interesting stuff has happened in February starting with the most important one.
NVIDIA contributes to Nouveau once more
Despite the status update report being published which mentions not only some new features which Nouveau received, it also appears that less and less people work on it but then, out of nowhere NVIDIA has stepped in and provided the following contributions to this project
NVIDIA Format Modifiers - Provide better performance in compressed layers. Will be available in the upcoming Linux kernel 5.7 Signed firmwares for GeForce 16 series (1600 and 1650 series) While this is surprising nice approach it still lacks a specific firmware to deal with poor performance from GTX 900 series to newer and we have yet to receive an open source Vulkan driver which Nouveau still lacks.
Mesa 20.0 has been released + 20.1 work has begun
As stated in the title, Mesa 20.0 has been released which provides the following new features:
Owners of Intel's Broadwell line of CPUs or newer will use the new Gallium3D driver codenamed Iris by default, providing better performance and take advantage of Gallium3D features such as the GalliumHUD or even Gallium3D Nine for use with Wine for a native DIrect3D 9 support (Requires Wine Nine Config) compared to the old i965 driver which is still used for older Intel iGPUs. Additionally Mesa 20.0 now supports Intel's Jasper Lake line of CPUs as well. Owners of AMD graphics card based on GCN 1.0/1.1 architecture can take advantage of Valve's shader compiler made specifically for AMD called ACO, reducing the shader compiling time (which in turn minimizes stuttering) and provide more FPS as a bonus. Speaking of ACO, it supports even more shaders and some improvements leaving only Tesselation shaders and OpenGL support for last. AMD's Gallium3D driver, RadeonSI, now supports OpenGL 4.6 due to the NIR being enabled and used by default and now uses the "live shader cache" to reduce the stuttering when compiling shaders in OpenGL games. The recently added Next-Gen Geometry added by AMD for Navi GPUs has been re-enabled. Previously was disabled due to the issues popping up that were difficult to fix. As of this release, the work on 20.1 version has begun and it's expected to receive a stable release in May 2020. So far these are the new features that has been presented:
Shader Disk Cache support for Nouveau, to improve loading times in games when using NVIDIA GPUs with the open source driver NIR support + OpenGL 4.6 support for R600 Gallium3D driver used by AMD HD 2000 series to HD 6000 series. Disabling (and perhaps removal) of SISched support, as Valve's ACO already beaten it. Used as a shader compiler for OpenGL and Vulkan games. Performance improvements by Valve for GCN 1.0/1.1 based graphics cards. AMD's GPU Profiler and SQ Thread Trace support for RadV (Open source Vulkan driver for AMDGPU) made possible by Valve. Normally these features were used by AMD in their own drivers, especially in their own open source Vulkan driver codenamed AMDVLK. Smaller size for RadeonSI, but even more performance improvements in combination with two compiling options which are LTO and PGO, as mentioned here. Speculation: OpenGL 3.0 support in Zink, an OpenGL To Vulkan driver. Some oopsies have happenned
It seems that Windows games that ran through Proton started to count as Windows sale instead of the Linux one for some time until a game developer noticed this, luckily this has been reported to Valve and turns out that despite the system of it works, the filtering did not.
But now time to mention some major issue that is going on. As of the release of Linux kernel 5.5, it turns out that it missed some of the critical patches for Intel Graphics Driver which led to system freezes and other serious issues. Hopefully the point releases included them.
Other news:
- Besides the release of Godot Engine 4.0 happening in mid 2020, the developers announced that it will include Wayland support along with EGL support, which for latter's case will greatly help for Raspberry Pi devices.
- Wine has reached 5.3 release
- Proton reached 5.0 release
- DXVK received 1.5.5 release which only includes bugfixes. New major release will happen once all the regressions have been fixed.
-
By capofantasma97
Hi,
I've noticed that in a few articles there are bad commands/arguments for Launch Options and Console commands. These have been copypasted all over the internet since the dawn of Source engine tinkering, with many people improvising experts without any knowledge whatsoever.
Here's a list of commands that should NEVER be used and even removed if present in articles. As the all-knowing wiki for PC gaming, this place should be error free, especially considering the main reason people come here is because of the will to tinker with this kind of stuff.
-high it is not merely a matter of not being compatible with some stuff like the Origin updater, but detrimental to the overall performance. It is usually pasted because people think that setting an higher priority for the game, it will run better. In truth, High is a priority mode in Windows that is useful only for short, critical events, and processes that are not short and critical like games will cause an unbalance in resource usage with a decrease in performance. In addition, there's no visible benefit in running it, any anecdotal improvement is placebo.
-threads the Source engine automatically detects the amount of threads it has to run, and automatically caps the threads accordingly in case it would be detrimental for performance. Furthermore, a Valve developer once replied on Reddit saying such launch option should be removed.
- dxlevel is often wrongly used and recommended. For the best quality and optimal performance it shouldn't be used, and anyway if one wants to enforce it, the compatible and recommended values are 60, 70, 80, 81, 90, 91, 95 and 100 (some games do not support all of these). 98 should never be used as it is a value for Xbox 360 only, as also explained in the official documentation.
-preload / sv_forcepreload / cl_forcepreload should NEVER BE USED. Mocked by a Valve developer as "cl_massive_hitches_at_surprising_times 1", it commonly causes stuttering and lag spikes, and has been removed in many games.
-heapsize does not exist in Source since 2009. Heapsize related commands are not to be used as not only they should be disabled basically in every Source game, but if it happens to work somewhere, it may cause long Garbage Collection pauses in the software, with clear problematic performance issues and glitches.
Launch options and commands that affect window/fullscreen modes and resolutions like -noborder -fullscreen -w -h -full -sw are to be avoided if possible because they may cause "confusion" in the engine and create performance issues. Plus it will conflict with any changes applied in the game settings. For this kind of settings, video options in the game's settings should be the only way to interact with them. Almost all games have a selectable borderless windowed mode.
-nocrashdialog removes some windows crash messages. It has no effect on performance and makes crashes harder to troubleshoot.
There's also a series of bad network related values and commands. These should not be touched if you are not an expert. Only modern and updated config bundles like mastercomfig for Team Fortress 2 should be used to automatically apply these settings with the right values, if the game is well known to support them. For these and more settings, refer to Mastercomfig's well-researched documentation.
rate 60000 is a bad value. The default in many Source games is 80000, so applying it will lower the rate which obviously cripples network performance even for bad connections.
cl_interp 0.0152 causes bad interp with server, cl_interp 0.033 is a typo of the commonly used cl_interp 0.0303
cl_updaterate 60 and cl_cmdrate 60 are typos of cl_updaterate 66 and cl_cmdrate 66 which are the default values for most Source games as the usual tickrate for servers is 66. Some games like Apex Legends have a tickrate of 20, and these values are useless to try to enforce. Maximum tickrate is dictated by the server and doesn't give a damn of what you set.
Since I'm here, I may as well give some helpful launch options:
-novid disables the game developer/publisher startup logos/animations. It doesn't always work (like in Apex Legends).
-nojoy and -nosteamcontroller disable the joystick system and Steam controller system respectively. If the player is certain that they will not use joysticks/controllers of any kind, these launch options are useful to reduce memory usage and improve startup times as there's 2 less modules for the game to load, as well as potentially preventing input conflicts if a controller is connected.
-freq x , -refresh x and -refreshrate x are all the same thing but with alternative syntax names and only one should be used if need be. They enforce the refresh rate put in place of "x", which is useful for alternative refresh rates like 120, 144 and 240Hz, as the Source engine may not correctly detect the refresh rate of the monitor. Example: -freq 144
fps_max x is a command to input in a config file but could be used as launch option as +fps_max x. It sets the maximum framerate. It can be used to prevent excessive spikes which could result in inconsistent input lag or to give more resource space to other programs in the background. Generally is recommended to not set it or set it as +fps_max 0 in order to have uncapped framerate and benefit from the lowest input lag possible, or alternatively to set it a bit above your monitor's refresh rate, like +fps_max 160 for 144Hz, in order to not waste resources and value stability more.
m_rawinput 1 useful command if raw input can't be found or is difficult to find in the game's settings. It enables mouse raw input, meaning that the game picks the mouse sensitivity directly from the sensor of the mouse itself instead of passing through Windows's sensitivity settings, meaning that it will always give a true 1:1 consistent sensitivity and lower input lag.
Please add in Source games a section explaining both good and bad launch options and updating the wrong ones.
-
By Mr. Doomguy
Ho! Ho! Ho!
We have approached the end of 2019 and this month has left some interesting things going on around the Linux Gaming community.
Mesa 19.3 release and new features in the upcoming 20.0 version
As predicted, Mesa 19.3 has been released in early December which marks the 1st stable release to include Valve's shader compiler for AMD called ACO, however it is not enabled by default and users are required to run with RADV_PERFTEST=aco to take advantage of it, of course on Steam ya need to put RADV_PERFTEST=aco %command% into Launch options. As a reminder, this is meant for AMD only running on GCN architecture or newer which halves the compiling time making the game less suspectible to stuttering and increase the frame rate as a bonus. Besides that it provides a support for Navi 14 based GPUs (Such as RX 5500 XT), Intel Tiger Lake support, Zink driver (OpenGL To Vulkan driver, currently supports OpenGL 2.1) which is currently in experimental state and new Vulkan extensions for both Radeon RadV and Intel ANV.
New features have been announced to appear in the upcoming Mesa 20.0 which will be released in February:
- Intel GPUs under Mesa will use Iris by default, a Gallium3D driver made by Intel themselves. Allowing you to take advantage of Gallium3D features such as the HUD and perhaps even Gallium3D Nine to run Direct3D 9 games under Wine without any translation to OpenGL, causing a boost to the frame rate.
- OpenGL 4.6 support for RadeonSI (Open source OpenGL driver for AMD) and replacing TGS route with NIR, which results in some slight frame rate boost.
- OpenGL Tesselation Support in Gallium3D's Software Rasterizer
- AMD R600 GPUs will receive NIR support
Linux 5.5 performance regression and AMDGPU's experimental GCN 1.0 support may be dropped
Currently we are receiving Release Candidates for the upcoming stable 5.5 Linux kernel and it seems that some performance regression has been found, according to the Phoronix article this is cause by the usage of AppArmor feature presented in the kernel and a second unknown issue. If you are using Debian or Ubuntu (including even flavours such as Xubuntu, Kubuntu etc.) then it must be disabled by adding apparmor=0 into the kernel parameter. Luckily other distros such as Fedora and perhaps even ArchLinux have their kernels compiled to not use it by default.
Now here's the bad news for any owner of AMD's graphics card that uses GCN 1.0 architecture, AMD might drop the experimental support for it under AMDGPU kernel driver due to the UVD video driver not being included and some occasional bugs due to lack of testing and any output from AMD themselves. Enabling the usage of AMDGPU kernel driver for GCN 1.0 required a manual change in the kernel parameter with radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 (Not required for GCN 3 and newer, as it's enabled by default) but it provided not only a frame rate boost but also a Vulkan support for GPUs which uses this architecture, the worst part is that they are unlikely to release a firmware which provides UVD video driver, but may also drop SI support from AMDGPU entirely. Valve may not like that as in their Future Work list for ACO, GFX6 lists Radeon HD 7000 series along with Radeon 200 series (Specifically 240 and 250) to have it's support added.
Proton 4.11-11 release, D9VK merged with DXVK, Wine 5.0 reached into freeze mode
Speaking of Valve, they have recently released a 10th and 11th revision of Proton 4.11 which not only includes some fixes but also:
- Halo: Master Chief Collection is supported from the single player side, multiplayer mode uses Easy AntiCheat which Wine and Proton has yet to provide support for it (Unless EAC hasn't been updated).
- Adds a Interger Scaling Mode which can be toggled by running the game with WINE_FULLSCREEN_INTEGER_SCALING=1
- Updated FAudio to 19.12 and DXVK to 1.5
Now the DXVK 1.5 is special one here, as D9VK which is a fork of DXVK that translated Direct3D 9 games to Vulkan has been merged with it, so by default DXVK currently supports D3D9, D3D10 and D3D11.
From the Wine side, the Wine 5.0 development has reached into the freezing state, so for now we are getting release candidates (RC3 being the last release in this year!) which only includes bug fixes in order to be prepared for the stable release of it which may happen in February or March. This is rather important as Wine is used by Valve to create Proton, so once 5.0 gets a full stable release, then perhaps we will get Proton 5.0?
Life Is Strange 2 Linux release, some NVIDIA updates, leading Vulkan dev at Feral Interactive leaves
Folks at Feral Interactive has been busy this month and released the Linux port of Life Is Strange 2 which uses Vulkan by default, now for the bad news, their leading Vulkan dev Alex Smith has left the studio after 3 years and currently works at Sony with the PlayStation, luckily he mentioned that Feral still has some capable Vulkan devs ready to take over. Wonder if PlayStation 5 will use Vulkan?
Now time for some NVIDIA news, they have released a new update for their legacy 340 driver series in order to make them work on recent distros for the upcoming 2020 and currently GNOME (one of the big desktop environments) will provide a much easier GPU switch in the 3.36 release, whereas KDE Plasma is soon to follow.
The 2010s was a decade which showed some activity in terms of Linux gaming, starting from Valve providing Steam support for it in 2012 with other stores such as GOG, followed by a release of SteamOS and Steam Machine and later on this caused some companies who made only Mac ports to join in such as Feral Interactive, Aspyr Media, Virtual Programming etc. some of them made a huge progress and some of em didn't, but despite the failure of Steam Machines Valve still continues to this day to spend their time and money to make Linux more viable for gaming and even decided to use most of the open source middlewares such as SDL2, OpenAL, libavcodec, Vulkan and OpenGL in their newer games which most likely even reduced to cost of developing the game for specific platforms such as Windows, Mac, Linux, Android, iOS.
Other contributions which Valve made for Linux are as follows:
- Contributes their codes to SDL2, Vulkan, Mesa, Linux kernel
- Working together with Codeweavers on Proton and upstream the codes to Wine
- Open sourcing some of their projects such as OpenVR, GameNetworkingSockets, Proton, Fossilize
- Giving contracts to specific developers such as DXVK, Feral GameMode etc. to continue their work
Now let us remember that Linux Gaming wasn't born with Valve, but with Loki Software in late 90s and early 2000 which were responsible for using SDL and OpenAL which are still being used to this day, even in source ports of your favourite games.
The biggest question here is, what will await in 2020?
Previous Monthly Linux Gaming News
November 2019
-
By SirYodaJedi
This file is password protected due to possibility of false positives. Use the password pcgw to extract.
Source: https://mega.nz/#!PIdT1aIK!mQu-qdOCBnGrOu9-hfnLhoGxIMWg040eF8OSwlK9DQo
NOTE: This mod is not compatible with the highly recommended unofficial patches.
-
By SirYodaJedi
This file is password protected due to possibility of false positives. Use the password pcgw to extract.
Source: https://web.archive.org/web/20071218061808/http://www.giantswd.org/?file=2
-
-
Who's Online 5 Members, 0 Anonymous, 452 Guests (See full list)
-
Recently Browsing 0 members
No registered users viewing this page.
-
Forum Statistics
1,319
Total Topics7,189
Total Posts
