A few weeks back Roy posted improved re-clocking code for NVA3 GPUs. Today his latest set of patches work on memory re-clocking improvements for DDR2/DDR3 hardware. The patches also implement wait-for-vblank to remove flickering during memory re-clocking, improvements for reducing the downtime of PFIFO pauses, etc. These patches are prep work for the actual memory re-clocking code that he says will follow later.
The open-source x264 program does support OpenCL acceleration -- when building x264 it will check for the presence of OpenCL development support and then at runtime the --opencl switch must be passed for exploiting the potential of any OpenCL hardware. The x264 test profile part of the Phoronix Test Suite is strictly intended for CPU-based testing so this weekend I added a x264-opencl test profile that uses the same revision of x264 and the same media file, but the only difference is that it forces OpenCL support. So now with the Phoronix Test Suite it's as easy as running phoronix-test-suite benchmark x264 x264-opencl to run the CPU-bound x264 and the OpenCL version for easy comparison purposes.
Since last year AMD's had the FX-9590 as the top-end Vishera CPU that can top out at 5.0GHz with its Turbo Frequency, but initially this processor was only available to OEM system builds. Over time the OEM version of the FX-9590 became available to consumers while earlier this summer AMD launched a retail version of the FX-9590 that included the eight-core CPU with a closed-loop water cooling solution. Today we're reviewing this highest-end Vishera CPU to see how it compares to other AMD and Intel processors on Ubuntu Linux.
This holiday weekend (in the US) can be a great time to test your Linux system to see how it's performing against the latest AMD and Intel processors to see if it's time for a good upgrade.
This weekend I'm working on many Linux CPU benchmarks for the upcoming Linux review of the Intel Core i7 5960X Haswell-E system (still waiting for Intel's review sample to arrive though...) and also have some other hardware in preparation for an unrelated launch that's happening next week from another vendor. I'm testing several different Intel/AMD CPUs from the latest desktop CPUs to the Extreme Edition models to some slightly older parts. Beyond the raw performance results are also the power consumption data and much more.
In recent years with more motherboard vendors enabling the updating of the BIOS/UEFI from within the setup utility itself and support loading the BIOS file off a USB thumb drive or other storage, it's generally easier for Linux users and all around a smoother process than the days of having to make a MS-DOS start-up floppy disk or similar. For most of these BIOS updates, Windows is generally not required as you can just head on over to the vendor's web-site, download a zipped up copy of the BIOS, transfer it to a USB drive, and reboot into the UEFI setup utility and flash away.
Some vendors will package their BIOS file inside an EXE that has to be executed that will then extract the file right away, but fortunately there's many programs capable of straightaway extracting the files from the EXE or the worst case scenario is generally just running the EXE under Wine. As a Linux user, with MSI motherboards their BIOS packaging takes it to an additional level of annoying and for some Linux users could be show-stopping.
Beignet is the project out of Intel's Open-Source Technology Center for exposing GPGPU/compute capabilities out of Ivy Bridge hardware and newer when using a fully open-source Linux stack. While Beignet differs greatly from Gallium3D's Clover state tracker, this Intel-specific open-source OpenCL implementation is working out quite well for Ubuntu Linux.
While I've been writing about Intel's Beignet project since early 2013, it's probably been about a year now since I tried out the code, which is developed by Intel's OTC graphics team in China. This weekend I tried out Beignet v0.9.2 as trying out the newest Intel OpenCL code has been on my TODO list for a while and it's been working out rather well in my initial tests.
Eric Anholt, formerly a lead developer on Intel's Linux graphics driver, has been quickly working away at the VC4 Gallium3D driver and related code now being a Broadcom employee tasked with making an open-source driver for the Raspberry Pi. If you're looking to try out his in-development driver or help him out in the driver creation process, he's published a brief guide to lower the barrier to entry.
Eric published a blog post on Friday that covers the steps for building a Linux kernel that has the VC4 driver, building mainline Mesa with the VC4 driver, and also building Piglit for carrying out regression tests.
A German web-site is hosting a yet to be officially released Catalyst Linux driver.
As pointed out in our forums there is a new Catalyst Linux driver version that's being hosted by Computerbase.de. This driver is marked Catalyst 14.201.1008 and was uploaded today for Linux along with Windows.
While this driver should work for any supported hardware (Radeon HD 5000 series and newer), it's labeled amd-catalyst-desktop-apu-linux-x86-x86-64-14.201.1008.zip. The driver version number is higher than the previous publicly released Catalyst Linux build available from AMD's web-site.
Hard to choose between Raspberry Pi, BeagleBone Black, and MinnowBoard Max? Now there’s another choice: the open source MIPS-based “Creator CI20″ dev board.
In a bid to harness some of the energy and enthusiasm swirling around today’s open, hackable single board computers Imagination Technologies, licensor of the MIPS ISA, has unveiled the ISA’s counter to ARM’s popular Raspberry Pi and BeagleBone Black SBCs. These days, every processor vendor simply must have a community supported dev board in order to engage with the developer communities. (Incidentally, Intel’s is the MinnowBoard Max and AMD’s is the Gizmo.)
Pantelis Antoniou originated device tree overlay support for the purpose of enabling dynamic hardware configuration under Linux on devices like BeagleBone that use device tree for hardware configuration. Device tree was introduced to Linux for the purpose of putting the description of hardware into data structures, rather than building it up programmatically, greatly reducing the amount of code required to be maintained within the Linux kernel sources. Until now, the device tree data structure was only processed at boot time and that simply can't work for devices that might change hardware configurations after boot. While many BeagleBone capes can be probed by the bootloader, a common use-case is hardware that is reconfigurable. The most obvious example is a cape with an FPGA on it.