Jump to content

Mr. Doomguy

Member
  • Content Count

    22
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by Mr. Doomguy

  1. 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.

  2. First things first, apologies for the delay of making this monthly news since i've had some life stuff to do. With that behind, let's get started to talk about what happened in January 2020 regarding the Linux gaming.

     

    Mesa 20.0 has reached the freeze state and more goodies added

    Right off the bat, Mesa, an open source GPU driver library has reached the freezing state and started releasing RC versions, at this point no new features will be added besides bug fixes, luckily at the last week before entering that state it received more features:

    * OpenGL 4.6 and NIR support enabled for AMD GPUs that use RadeonSI, one of AMD's Gallium3D driver primarily supported by GCN and newer architecture.

    * Intel's new Gallium3D driver for Broadwell „Gen8” gpus and newer has been enabled by default, which allows you to take advantage of Gallium3D features such as the HUD and perhaps even Gallium Nine which is primarily used for Windows games that use Direct3D 9, allowing for a native performance without translating it to OpenGL (Requires Wine Nine Config installed)

    * Vulkan 1.2 support for both ANV and RadV drivers, former for Intel and latter for AMD.

    * NGG geometry support being re-enabled for RX 5700 series (and perhaps for any Navi GPUs), was previously disabled for the sake of taking care of bugs that were difficult to fix.

    * Valve's ACO for AMD has received a support for GCN 1.0 GPUs, according to Phoronix article it provides slightly better framerate, besides just lowering the shader compiling time dramatically. All that is left is for ACO to support tesselation shaders and OpenGL, after that it'll be most likely a bye-bye to LLVM.

    Mesa 20.0 will receive a stable release in late February or perhaps even in early March, depending on how many bugs it needs to be fixed before the release.

    NVIDIA ends 340 driver support, 390 will be next in line

    The time has reached for 340 legacy driver support to end, which according to NVIDIA it's last supported XOrg is 1.20 and the 5.4 Linux kernel, albeit it can be patched to use newer kernels instead. Fermi GPUs that use 390 legacy driver will have their support end in 2022

    Wine 5.0 has been released + a surprise

    Wine 5.0 has left the freezing state for the sake of bug fixes and received a stable release. Despite mentioning a few major features such as:
    * Multi monitor support
    * Vulkan 1.1 support

    * XAudio 2 reimplementation

    *Builtin modules in PE format

    There is more where that comes from, one such thing being support for S3TC texture compression, fleshed out support for Windows Media Foundation, MSI installer support, for more see the changelog list

    Besides that, we've gotten a new surprise from Codeweavers which they are coming back to work on Vulkan implementation of WineD3D, which last year didn't go anywhere. Looks like DXVK will have a competition here.

    Valve works on a new compositor called Gamescope, aimed to replace Steam Compositor

    It seems that Valve has began on reworking their compositor for desktop environment that was primarily used for SteamOS called, Steam Compositor. This time they decide to aim higher by making it not only to use Wayland only, but combine that with Vulkan instead. Here is a more detailed information from it's readme file:

    Quote

    In an embedded session usecase, gamescope does the same thing as steamcompmgr, but with less extra copies and latency:

    • It's getting game frames through Wayland by way of Xwayland, so there's no copy within X itself before it gets the frame.
    • It can use DRM/KMS to directly flip game frames to the screen, even when stretching or when notifications are up, removing another copy.
    • When it does need to composite with the GPU, it does so with async Vulkan compute, meaning you get to see your frame quick even if the game already has the GPU busy with the next frame.

    It also runs on top of a regular desktop, the 'nested' usecase steamcompmgr didn't support.

    • Because the game is running in its own personal Xwayland sandbox desktop, it can't interfere with your desktop and your desktop can't interfere with it.
    • You can spoof a virtual screen with a desired resolution and refresh rate as the only thing the game sees, and control/resize the output as needed. This can be useful in exotic display configurations like ultrawide or multi-monitor setups that involve rotation.

    This is rather an interesting project overall, sadly NVIDIA users will not be able to use it mostly due to the company not having much interest in improving Wayland and XWayland support. Last time i remember using GTX 970 on Wayland, it couldn't do Vulkan as it was missing an extension for it in their proprietary driver. So for now AMD and probably even Intel users will be able to use it.

    The git repo of this project can be found here.

    VKBasalt 0.3 has been released, supports shaders from ReShade now

    For all of you folks who like to play around with shaders from ReShade, but miss using it on Linux have a chance to use it now. VKBasalt dev along with the creator of ReShade worked together to provide support for it in this 0.3 release. VKBasalt 1st started off as a new way of adding sharpening filter similar to AMD's Image Sharpening feature in Windows but works only for native Linux games that use Vulkan or Windows games through projects like DXVK on Wine/Proton. More about this can be found in it's project page

    Besides all these major news here is what was going on around on Linux gaming overall:

    * DXVK last release in that month was 1.5.3

    * Proton 4.11-12 was released

    * Steam survey from December 2019 used to show 0.63% of active Linux users, however there was an issue similar to the last year which over-counted Windows 7 users from China. The real value was 0.83%. Right now the market share as of January 2020 is now 0.90% and keeps raising.

    * Linux kernel 5.5 has received a stable release (overview here), work on 5.6 has begun and currently reached the release candidate.

    Previous Monthly Linux Gaming News

    ================================

    November 2019

    December 2019

  3. 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

  4.  

    16 hours ago, Andytizer said:

    Thank you for posting this, didn't realise how much Linux PC gaming news I was missing out on! Some thoughts from a non-Linux gamer:

    - Is Steam Linux Runtime the long-term solution for when distros lose 32-bit support?

    - What was the point of dropping support for 32-bit for Ubuntu? Is it related to MacOS Catalina dropping 32-bit support? Will Windows ever drop 32-bit support like it did for 16-bit support?

    - Reminds me that we should do some PR work with Feral!

    - Vulkan performance is seriously impressive, hopefully more games will add support.

    - Looking forward to next month's edition.

    - Considering that one way or another we may lose support in the future it most likely will. Besides that another reason for making this is perhaps due to the unofficial Flatpak version of Steam which runs it in sandbox mode with it's own libraries. A good idea, but it may be behind in terms of new library releases.

    -No one knows what made Cannonical to do that, perhaps Apple's decision may have influenced them to do that. Luckily the huge backlash made them rethink their decision and decided to only include 32 bit libraries that are needed (and while at it, Pop!_OS gained more traction)

    - Agreed. It'd be also nice to have their store pages added into PCGW articles as well, specially when the games they have ported will give you a Steam key once you buy their ports from their store.

  5. Hello and welcome into a Monthly Tux Gaming News which I mention what was going on in this month around the Linux gaming community which you won't find in any mainstream gaming news.

     

    Mesa 19.3 stable release delayed, further improvements en-route.

    Mesa, an open source GPU driver library maintained by the community has it's 19.3 stable version delayed to early December as there are more bugs to fill in. This will be the 1st release which will contain Valve's own shader compiler that is meant to replace LLVM, which is commonly used for this stuff specially when they are complex, with ACO which is specifically made for AMD graphics cards only . The major difference between these two is that ACO takes much less time to compile the shaders and as a bonus provides a frame rate boost, however it currently only works under Vulkan and you must be using Radeon RX 300 series or newer from dedicated GPU whereas in case of APUs it's Bristol Ridge, Raven Ridge or newer. You can learn more information about this feature from their blog post, they have plans to provide support for HD 7000 series and OpenGL along with other shading stages according to this roadmap

    But that is not just it, Valve is revising their Secure Compile feature for Mesa's AMD Vulkan driver called RadV which will result in lower resource usage and avoid slower shader compile times reducing the stuttering even more and best of all, this gets backported into 19.3, so by combining that with ACO things will get even more interesting. However, ACO will not be enabled by default as it requires you to run the game with

    RADV_PERFTEST=aco

    on Steam you need to use this in launch parameter right at the beginning

    RADV_PERFTEST=aco %command%

     

    Next major release of Mesa will happen in February 2020 which will hit 20.0 and the work has already started.

     

    New AAA game Linux port from Feral Interactive + a major update for one of their older Linux ports

    Feral Interactive was busy this year with porting Shadow Of The Tomb Raider into Linux and Mac. The Linux version uses Vulkan by default and it's based on the DIrect3D 12 version of the game instead of D3D 11, what is the result you ask and how does it compare to Windows? First of all, there's no ray tracing support which can be a bummer, but when it comes to performance compared to Windows version, according to this following benchmark video the difference between them is that the native Linux version is......about 2% slower. That is seriously impressive, however there has been some words that on AMD GPUs in conjunction with ACO the game actually runs faster than NVIDIA but so far no benchmark has been found to confirm this.

    But this is not the only main thing that has been going on around from Feral, they've also updated their Linux port of Shadow of Modor by providing Vulkan support which currently is in beta and can be opted-in any time by choosing  linux_vulkan_beta from Betas tab. As their older port uses OpenGL and was released in 2015 it had a worse performance compared to Windows as they were still new to porting games into Linux, after all, the company was primarily doing Mac ports since 1998 and started with Linux porting in 2014 with X-Com: Enemy Unknown. So, has this helped improving the performance? Considering how since 2016 where they've started playing around with Vulkan by choosing Mad Max i dare to say....

    It's jawdropping!

    The most interesting thing here is that this is not the only thing that got added, Feral also added an option to choose the Vulkan driver of your choice and change the FOV through their launcher.

    Since Tomb Raider 2013 on Mac got a Metal support, perhaps that game will also receive the Vulkan treatment......or Deux Ex Mankind Divided? Actually, DX:MD seriously needs one.

     

    Valve still being busy and awesome with Linux support as usual

    Besides Mesa stuff, Valve has also been busy with their own stuff. They have activated VKD3D in their Proton 4.11-8 release which is Wine's own Direct3D 12 to Vulkan wrapper allowing you to play games which utilize D3D12, however be aware that this wrapper is still being worked on and speaking of Proton, the recent version that got hit at the end of this month is 4.11-9 which are just mostly bug fixes.

     

    One thing thou that received a major change from Valve for Steam is the option to use Steam Linux Runtime as a Compatibility Tool. What does it do? Well basically it forces the game to use the libraries which were included with Steam, including 32 bit ones. This is a very useful option as there is a chance that a native Linux game will not work be it missing a library or 32 bit games not working (Gee, wonder what made them to do it in a 1st place), game developers can also take the advantage of it as well when providing a help for the user that uses a distro not supported by Steam which is Ubuntu LTS or anything based on it or even use it for testing purposes.

     

    What else is there? Hmmmm....Oh, streaming option has been enabled on Steam for Linux, wonder what took em so long to do it.

     

    What's next in the future?

    Well after the release of Linux kernel 5.4, the next major version is still in the works and may end up in a freezing state soon, as mentioned previously Mesa 20.0 work has begun and finally perhaps things will get interesting once Ubuntu 20.04 hits in April 2020 which will be a Long Term Support one.

    "What about Nouveau, the open source NVIDIA driver by the community?" you ask. Still in a poor shape from 900 series and no Vulkan driver of it's own. Hope NVIDIA actually does something about this.

  6. Following last weekend's WineConf 2017 and its announcement, Wine project founder Alexandre Julliard has sent out a detailed action item list as a result of the developers' meeting in Poland.

     

    Perhaps most exciting is that they will be developing VKD3D in its own Git repository. The VKD3D code-base is to be a Direct3D 12 to Vulkan library for eventually allowing D3D12 Windows games to run on Linux via translations to Vulkan, similar to the project's work on converting Direct3D calls to OpenGL.

     

    Separately there has also been the VK9 effort for running Direct3D 9 over Vulkan, but this Wine VKD3D project is just about Direct3D 12 with that matching more nicely to the semantics of Vulkan. Besides, Wine's Direct3D 10/11 support backed by OpenGL is already getting into good shape.

     

    But don't expect vkd3d to become usable overnight as it will likely be quite some months involved before it will be helping out for running Windows D3D12 games under Wine. It will also be interesting to see once full-featured if any game studios/porters will be using it to assist in porting games to Linux, assuming the overhead isn't too high of this yet-to-be-developed library.

     

    At WineConf 2017, developers also agreed to begin producing more detailed Git commit messages, consolidating some of their mailing lists, and to begin building binary Wine packages for Android.

     

    Their current plan is also to do the code freeze for Wine 3.0 around the end of November, meaning the release should be out on schedule in December or January.

     

    The list of action items can be found on Wine-devel.

     

    https://www.phoronix.com/scan.php?page=news_item&px=Wine-Vkd3d-And-More

     

    But that is not all, the community also aims to make a good use of the Vulkan API for other DirectX versions.

     

    DXVK is currently in development which translates Direct3D 11 calls into Vulkan and can be used for Wine.

     

    VK9 is similar to the mentioned DXVK, but for Direct3D 9 calls.

     

    Why is this important?

     

    Currently Wine uses OpenGL to translate the calls from DirectX and compared to Vulkan, the latter is a lower-level API which offers parallel tasking which can result in a major performance difference. For Linux users this is a good news, but sadly, MacOS users are out of luck since Apple refuses to implement Vulkan into their system as they want to push their own graphics API called Metal. A third party Vulkan implementation does exists, but it uses Metal API to translate the calls.

     

    At the same time it may cause Linux to be more future proof while (most likely) providing backwards compatibility with older games on Windows.

  7. I've been thinking about adding a list of packages that are required for the game to work on Linux in a dropdown table which is divided into popular distributions besides Ubuntu. So if someone who runs under Manjaro for example, could take a look on what package they should install in case if the speficic *.so file is missing. Can be very useful for those who own either an older Linux port or decide to run the game with native library instead of those that are included (Such as those from Steam. Since by default it still uses the ones from Ubuntu 12.04)

     

    For example:

     

    1st row: openal:i386, sdl2:i386 - Ubuntu, Debian

    2nd row: lib32-openal, lib32-sdl2 - ArchLinux/Antergos/Manjaro

    3rd row: openal:i686, sdl2:i686 - Fedora

     

    As there's the ldd command which lists the SO library files, it may confuse the newcomers as they won't know which package has it. Some libraries are even in the other one you won't expect. However, most package managers have an option to locate which package has the specific file required to run.

     

    EDIT: Would placing the dropdown table fit under the System Requirements for Linux? I can't help but feel that it's a good place to put it.

  8. As you may know (or not), Steam to this day uses the libraries from Ubuntu 12.04, released in 2012 and are not even updated at all, which causes a large difference in terms of performance. Forcing you to manualy create your own executable with STEAM_RUNTIME=0 to force Steam to use libraries from your system. Some Linux distributions such as ArchLinux has a package specifically made for this situation, but not all distros have that, especially when you require a 32 bit library to run Steam in Native mode in a 1st place.

     

    Then Solus came in and made a decision to use snaps to provide Steam for every single Linux distribution with the option to use it's own native library, even on distros that don't support multilib!

     

     

     

    Why You Do This??

    It's time to relieve the pressure on distributions for supporting gaming, by doing so through a single point of entry. A snapped LSI will ensure that the Steam/LSI combo would work identically on every distribution, *even if they don't support multilib*. It also ensures we can provide a "perfect" runtime, but ensure its up to date, optimised, and configured explicitly to support LSI & Steam.

     

    [...]

     

    TLDR: Single Steam/LSI image that takes all of the Solus gaming/Steam work, and provides it for everyone, on any distro.

     

    Source

     

    Think of it as Steam runtime (default)....but on steroids!

     

    EDIT: Oh great, the forum removes the + from the beginning at Solus in the url resulting in a page error.

  9.  

     

    Student developer Jente Hidskes' work this summer on improving the Piper GTK3 user-interface for configuring gaming mice on Linux via libratbag is now the latest example of a very successful Google Summer of Code (GSoC) project.

    Jente was able to provide some much needed improvements to this GTK3 user-interface for configuring Linux mice via the libratbag daemon. Among the work he accomplished this summer were support for mouse profiles, resolution configuration, LED configuration, button mappings, welcome and error screens, and more.

    Marking the end of GSoC 2017, he's written a lengthy blog post highlighting some of the work carried out over the summer. Below is a WebM video showing off his results to Piper:

     

    https://hjdskes.github.io/img/blog/gsoc-part-15/overview.webm

     

    The work was successfully merged to Piper on GitHub.

     

    http://www.phoronix.com/scan.php?page=news_item&px=Piper-GSoC-2017-Success

     

    For those who are wondering which mouse does it support, here's a current list of it.

  10. Dustin Land of id Software has been working on the "vkNeo" project in his spare/personal time as a Vulkan renderer for Doom 3 BFG / idTech4, which was open-sourced a few years back. This is along the same lines as the vkQuake open-source port of the original Quake to running on Vulkan.

     

    [...]

     

    How much code did it take to write for a Vulkan renderer for Doom 3? The commit diff adding the Vulkan code comes in at 602,265 lines, including blank/comment lines and that also includes some shaders/SPIR-V and plenty of header files.

     

    The Doom 3 Vulkan code was open-sourced over night via vkDOOM3 on GitHub for those interested. Land commented, " It was written as an example of how to use Vulkan for writing something more sizable than simple recipes. It covers topics such as General Setup, Proper Memory & Resource Allocation, Synchronization, Pipelines, etc."

     

     

    http://www.phoronix.com/scan.php?page=news_item&px=Vulkan-Doom3-Available

     

    This is going to be interesting.

  11. The main reason for listing a GUI library used by a game into a infobox is to quickly establish if the game uses SDL or any other library such as GLFW. This can be very helpful for Linux users as they would be able to use specific commands for the likes of SDL2 to provide some changes such as using ALSA instead of Pulseaudio, use Wayland mode instead of Xorg (Saving the performance) etc.

     

    Besides that it would also help recognize which library the Linux user needs to install in order to either get the game to work or compile the the binary file in case if the games source code is available (Such as Aquaria).

×
×
  • Create New...