Tag Archives: Linux benchmarking

Mesa 19.1 Adds Workaround For Epic Games Launcher With OpenGL


The latest change merged for Mesa 19.1 is a workaround so the Epic Games’ game launch correctly renders when using OpenGL.

It turns out that the Epic Games Launcher, which is Windows-only at least for now, relies upon an OpenGL 4.4 core context but uses deprecated OpenGL functionality. Technically the software shouldn’t be using a core context but rather compatibility context if it needs to use deprecated GL functionality.

But the NVIDIA Linux driver will still cooperate and presumably the Windows drivers in this invalid configuration. But the Mesa Intel i965 and RadeonSI Gallium3D drivers have instead had problems. The workaround in place for Mesa 19.1 is forcing an OpenGL compatibility context when “EpicGamesLauncher.exe” is encountered.

This change can be similarly made to the drirc configuration for existing Mesa releases should anyone be after getting a working Epic Games launcher under Wine/SteamPlay right now.

Mesa 19.1 should be released as stable around the end of May and for that to happen the feature development is being closed off next week.

Thunderbolt Is Seeing A Lot Of Improvements For Linux 5.2


Adding to the excitement of the Linux 5.2 kernel changes are a lot of Thunderbolt improvements expected to be introduced in this next kernel cycle.

Mika Westerberg of Intel has been working on a lot of Thunderbolt connectivity improvements destined for Linux 5.2 and in recent days has begun staging this work in the thunderbolt-next tree ahead of the Linux 5.2 kernel merge window opening in May.

This work includes support for full PCIe daisy chaining within the Thunderbolt software connection manager:

Currently the software connection manager (tb.c) has only supported creating a single PCIe tunnel, no PCIe device daisy chaining has been supported so far. This updates the software connection manager so that it now can create PCIe tunnels for full chain of six devices.

And there’s also the support for DisplayPort tunnels:

Display Port tunnels are somewhat more complex than PCIe tunnels as it requires 3 tunnels (AUX Rx/Tx and Video). In addition we are not supposed to create the tunnels immediately when a DP OUT is enumerated. Instead we need to wait until we get hotplug event to that adapter port or check if the port has HPD set before tunnels can be established. This adds Display Port tunneling support to the software connection manager.

Along with DMA tunnels:

In addition to PCIe and Display Port tunnels it is also possible to create tunnels that forward DMA traffic from the host interface adapter (NHI) to a NULL port that is connected to another domain through a Thunderbolt cable. These tunnels can be used to carry software messages such as networking packets.

Those are among the changes currently in the “next” branch for Thunderbolt of new material set to come with the Linux 5.2 kernel this summer.

A Set Of Obscure Drivers Out-Of-Tree Since Linux 2.x Will See Mainline For Linux 5.2


Should you have any Daktronics scoreboards, video displays, or digital billboards, mainline Linux kernel support appears to be in the works.

While shielded off by Kconfig build switches and not enabled by default, what some will surely point to the growing size of the Linux kernel and its laissez faire approach to accepting new drivers, a set of drivers that have been out-of-tree since the Linux 2.x kernel days are now on their way to the kernel’s staging area with Linux 5.2. Not only that, but the code quality is admittedly less than stellar, hence the staging route.

These are drivers around Daktronics hardware, a company specializing in high-end digital scoreboards, digital billboards, and other large displays for sporting venues, arenas, and more.

Greg Kroah-Hartman merged into staging-next the initial set of Daktronics drivers. “These drivers have been outside of the kernel tree since the 2.x days, and it’s time to bring them into the tree so they can get properly cleaned up.” He points out there is a lot of low-hanging work of areas to clean-up this code, such as for those wanting to get involved with kernel development. There’s also logic and API clean-ups and even one driver not merged yet because Greg KH couldn’t get it to build. These kernel drivers are for exposing the PCI/SPI/I2C devices and don’t appear to be a complete solution yet for driving Daktronics hardware.

These long-time out-of-tree drivers for Daktronics/Kaktronics amount to just under three thousand lines of code and will be part of the staging tree in Linux 5.2.

Panfrost DRM Driver Being Added To Linux 5.2 For Midgard / Bifrost Graphics

ARM --

Not only is the longtime Lima DRM driver for Arm Mali 400/450 graphics set to finally premiere with the Linux 5.2 kernel, but the Panfrost DRM driver is also being mainlined for the newer Mali graphics hardware.

The Panfrost DRM driver is set to be added to the Linux 5.2 kernel. Panfrost is the open-source, reverse-engineered DRM/KMS driver for Arm Mali Midgard and Bifrost graphics processors where as the Lima driver focuses on the 400/450 series.

Since earlier this year Mesa has had the Panfrost Gallium3D driver, which provides basic OpenGL functionality and can pair with this DRM/KMS kernel driver for a fully-open and functioning driver stack for Bifrost/Midgard. Though before getting too excited, at this stage Panfrost is just running some basic games and the Kodi HTPC software.

Panfrost Gallium3D is getting closer to offering OpenGL ES 3.0 support, but still more work is ahead before it can offer similar GL functionality to Arm’s proprietary driver. Also, Panfrost doesn’t yet have any OpenCL or Vulkan API support, unlike the proprietary driver.

Nevertheless, for those looking forward to open-source Midgard/Bifrost support, this new driver has been added to drm-misc-next for queuing in DRM-Next until the Linux 5.2 kernel merge window opens in May.

It’s Time To Re-Vote Following The Botched 2019 X.Org Elections

X.ORG --

While there were the recent X.Org Foundation board elections, a do-over was needed as their new custom-written voting software wasn’t properly recording votes… So here’s now your reminder to re-vote in these X.Org elections.

At least with the initial round of voting they reached a super majority and the ballot question of whether the X.Org Foundation should formally fold FreeDesktop.org into its umbrella worked and that X.Org + FreeDesktop.org hook-up passed so all is well on that front. But for the Board of Directors elections, that’s where re-voting is needed with the voting software that now correctly records the votes.

Running for the four seats on the X.Org Foundation board are Samuel Iglesias Gonsálvez, Arkadiusz Hiler, Manasi Navare, Lyude Paul, Daniel Vetter, and Trevor Woerner.

So if you are an X.Org Foundation member, now it’s time to vote.