Released yesterday was AMD's first OpenCL 2.0 Catalyst driver but we also learned privately about what's coming next in the pipeline with the fglrx 14.50 update. There's Linux support for the Heterogeneous System Architecture coming in this driver along with VCE video encoding support for GCN GPUs -- to match the open-source RadeonSI Gallium3D driver in its video encoding capabilities.
AMD's Alex Deucher sent in another Radeon drm-next patch series this week with some more last-minute tweaks for the Linux kernel's next merge window.
While all the major Linux 3.18 DRM graphics features are already queued for this next merge window, a few more Radeon DRM changes were submitted this week. Topping off the AMD Radeon features for Linux 3.18 on top of R600 UVD video decoding support, Userptr support, and concurrent buffer read support is some Radeon Dynamic Power Management (DPM) tweaking.
Within this article from an updated Fedora 21 stack, I ran some Linux gaming tests under its stock X.Org Server 1.16 environment and then rebooted and logged into the GNOME on Wayland session. From there the Phoronix Test Suite ran and I used the variety of graphics tests at my disposal to push the limits of XWayland.
A Radeon HD 6870 graphics card with the mature R600 Gallium3D driver was used for testing with Linux 3.17-rc6 + Mesa 10.3-rc3. While modern versions of Mesa support OpenGL 3.3 for Radeon Gallium3D, when running the tests under the Wayland session only OpenGL 3.0 was being exposed off the same Mesa build.
A new AMD Catalyst Linux graphics driver has been released today that finally delivers OpenCL 2.0 to Catalyst.
Released today was AMD's OpenCL 2.0 Catalyst driver for both Windows and Linux. The Linux distributions AMD is officially supporting for this driver are Red Hat Enterprise Linux 6.5 and Ubuntu 14.04 LTS, but of course the other usual distributions should work too.
With the Linux 3.17 kernel due out soon, here's our routine file-system benchmarks we do each kernel cycle to see how the popular Linux file-systems have evolved between kernel releases.
Earlier this month I did a 9-way file-system comparison on Linux 3.17 while in this article are the four most common Linux file-systems as we see how the performance evolved compared to Linux 3.16 stable. With Linux 3.17 there were notable changes to XFS and new F2FS features while the Btrfs changes were largely rejected.
Long story short, in the case mentioned above, the SiS driver works much better than the generic xf86-video-vesa and xf86-video-fbdev generic drivers and now this user running their aging system on the latest Fedora Linux development code is left without the dedicated DDX. In that case, the user discovered that Mageia's SiS DDX driver that's packaged happens to be ABI compatible with the Fedora X Server (at least temporarily), so he's back to using his preferred driver without burdening the Fedora developers in supporting an out-of-date, open-source GPU driver.
While Linux is commonly referred to as being able to run on almost anything, especially aging PCs, more Linux developers are realizing the burden in trying to maintain support and compatibility for older hardware; in some cases there's just regressions while in other instances the latest code can be completely broken for months until a user notices. What's your views on Linux maintaining support for old hardware? Let us know in the forums.
Several hours ago Valve finally released to the public the Linux port of Counter-Strike: Global Offensive! This has been one of the most sought after titles to come to Steam on Linux by gamers and now it's finally out there. Of course, soon as it was made public, we added support for the game to our benchmarking software. After a very busy night, here's the first widely available benchmarks of Counter-Strike: Global Offensive running natively on Linux. Up for this first round of testing are an assortment of AMD Radeon and NVIDIA GeForce graphics cards with the proprietary graphics drivers.
A significant patch-set was published on Saturday night that implements the driver-independent bits of OpenGL 4's ARB_tessellation_shader extension inside Mesa.
The tessellation support has been one of the big pieces missing from Mesa's OpenGL 4 implementation and fortunately it's getting close to mainline. Chris Forbes of Intel published fifty-six patches this weekend that implement the driver-independent portions of the extension inside Mesa. Of course, the driver portions still need to follow for it to be useful.