What Happens When Running Out of VRAM

Years ago, I made the decision to cheap out on my graphics card. I knew I wanted to get an NVIDIA GTX 1060, but that model had two main configurations: 3GB of video memory, and 6GB. Naturally, being the cheap person I am, I opted for a 3GB card. While I do not regret this purchase, this has lead me to need to upgrade likely sooner than I expected.

ALL Controller: Initial Impressions from a Linux User

A few years ago, I backed a project on Kickstarter for the ALL Controller. This is meant to be a “universal” gamepad, compatible with Windows/Mac/Linux on the PC side, Android and IOS on mobile, as well as consoles like Xbox One, PlayStation 4 and the Nintendo Switch. Beyond this, it is programmable, and has upgradable firmware, meaning that it can have support for new platforms added as time goes on. Personally I was particularly interested in the Linux support (no surprise there), but more so its programmability. Having now had it for a couple months, I can say it is certainly delivering on its promise.

PRIME Render Offloading: The Official Bumblebee Replacement

I’ve written several times in the past about bumblebee, which to this day remains as my preferred method to handle the NVidia Optimus problem on Linux. Despite there being various community projects to in some capacity improve the experience of hybrid graphics laptops, there are always compromises and limitations. Enter PRIME render offloading, which is the officially supported method straight from NVidia. It’s easy, clean, but is not yet ready for prime time.

Fixing VSync with Mixed Refresh Rates on Linux

Having recently acquired a high refresh rate monitor, I decided to add it to my current screen, running at the standard 60Hz. While running games, I quickly realized a problem: VSync was limiting to 60 FPS. The primary monitor itself was running faster, and with FreeSync to boot, however it was synchronizing using the refresh rate of the other screen.  Initially, I discovered a setting in the NVidia control panel, allowing to specify “Sync to this display”. Unfortunately, this did not appear to work. Eventually, I found myself on the Arch Wiki, where instructions on how to resolve this issue were plainly found. Simply put, when in TwinView (a.k.a. a multiple monitor setup), syncing can be enforced to a specific display by setting certain environment variables on startup (typically in /etc/profile):

export __GL_SYNC_TO_VBLANK=1
export __GL_SYNC_DISPLAY_DEVICE=DFP-0
export VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-0

The device listed as DFP-0 is replaced with the desired display, as listed in the NVidia settings menus.

High FPS Gaming: Surprisingly Easy to Get Into

For some time now, I’ve been contemplating acquiring a high refresh rate computer monitor. I have always marvelled at how much a jump from even 30 to 60 FPS could make on content. My main concern however was whether I would actually get sufficient use out of this. Many companies market these towards fast-paced first-person shooter games and the like, which do not much align with my interests. Equally so, players are expected to have the latest and fastest GPUs paired with this for the optimal result (or so we are told). All of this felt discouraging; it suggested I needed to doll out big bucks (I’m quite cheap), just for the sake of better enjoying games I don’t like. This lead me to wonder if there were even that many games, let alone other content, that actually support this market. As it turns out, there’s a lot more out there than I expected.

Wayland: Getting Better, but I’m Still Not Using it

I’ve written in the past about my thoughts on Wayland, both in terms of my excitement, and my hesitations. While the noise has died down on the subject, my remaining gripes on using it remain. Lately however, I’ve stumbled across some new developments which may finally address some of my biggest complaints. Sadly though, it will probably be quite some time before I can ultimately use it.

Diablo on Linux: The Day Has Finally Come

While I’ve been experimenting using Wine for gaming over the years, with varying degrees of success, one game in particular has become a sore spot for myself (and undoubtedly others), this being the original Diablo for PC (1996). For quite some time, there have been outstanding bugs that needed to be addressed in order to run the game without facing black screens overtop of the menus. While there has been some progress made to work around the issue, there are still several challenges. Thankfully, an alternative has surfaced: DevilutionX.

Steam Play: Not Just for Windows Games

Steam Play has taken the Linux gaming community by storm. While users have been able to run Windows games through Wine, and some managing this with tools like Play On Linux and Lutris, the ability to natively use these tools within the Steam client is a plus. No longer is it necessary to manage different Wine environments, or even run a separate client to launch the applications. What’s better is that developers are actively contributing to the Proton project, improving the compatibility list for existing games. What’s interesting however is that this launcher isn’t restricted to certain Windows games. In fact, Steam now allows users to launch any application through the compatibility layer, with just a few clicks. While this will not always work, some of the results are quite surprising (and pleasing).

Why Multi-GPU on Linux Still Sucks (and How it’s Getting Better)

While the desktop Linux experience has been improving by leaps and bounds, there are still some edge cases that need to be worked out, including systems with multiple graphics cards. While there exists support for technologies like Nvidia SLI and AMD/ATI Crossfire, these required identical GPUs and hardware bridges between them. The more tricky case is when the GPUs are not the same (and may even differ by chipset or brand). Though this is not as commonly found, any Linux desktop user with such a setup will tell you the struggles of utilizing all of their hardware, and how the desktop experience is less than ideal. Despite this “common knowledge”, it can be difficult to find cohesive information on the topic, so I’ve decided to put together a more comprehensive overview of the experience, and what we should expect to come in the future.

Installing RetroPie from Linux

Seeing as how difficult (and expensive) it is these days to get one’s hands on an NES Classic, an arguably better alternative is to turn a Raspberry Pi into an emulation box. The setup for this is surprisingly easy. Along with the Pi, a micro SD card (8GB as a recommended minimum), a micro USB power adapter (be sure to chose one with the correct voltage), a USB or Bluetooth controller, and a case are what’s needed. The setup also requires a keyboard, and the device needs to be connected to a display through an HDMI output. Audio can either be passed through the HDMI connection, or through the 3.5mm audio jack.

As a convenience, a Linux distribution called RetroPie is designed specifically with emulation in mind. Download it from the official website, and install it to the SD card with the following command:

dd if=/path/to/retropie.img of=/dev/sdX bs=1M conv=fsync

Be sure that the SD card is not mounted when executing the command.

After it is complete, connect all the peripherals to the Pi (SD card, USB devices, HDMI), then plug in the power adapter. The device should automatically boot up, and resize the partition to accommodate the available space. The controller will then be configured via user input. It is recommended at this point to perform updates to the device through the configuration menu. Once completed and rebooted, ROMs can be loaded onto the device following this guide. Files can be added automatically via a USB drive, through SFTP, or even a Samba share. If ever terminal access is required directly on the device, pressing F4 will pull it up.