As part of the GPUOpen initiative that AMD launched last month is an introduction to the Heterogeneous Compute Compiler (HCC) for writing code to take advantage of AMD's new LLVM-based compiler for offloading the work to the GPU.
Not only does RadeonSI Gallium3D work with XCOM 2 on Linux for AMD graphics processors, but it looks like the Catalyst (or now known as Radeon Software, officially) too works with this brand new, highly anticipated strategy game seeing a same-day release across OS X / Linux / Windows.
The AMDGPU DRM driver support for Iceland (Topaz) graphics processors is now considered stable with the experimental flag set to be removed.
Landing last month in the LLVM SVN/Git code-base was the SI machine scheduler for the AMDGPU LLVM back-end. This scheduler has the potential to improve the performance for some hardware/workloads, but not by the wide margins originally reported by some early testers.
Following this morning's article about Russian Super-Computing Users Get Tired Of Catalyst, Start Looking At Open-Source AMD, I decided to run some fresh Radeon open-source OpenCL benchmarks on my own using the Gallium3D Clover state tracker with the HPC researchers also being curious how this very latest open-source AMD graphics stack is performing. Here are some initial results with Mesa 11.2-devel Git built against LLVM 3.9 SVN (thanks Padoka!) and using the Linux 4.5 Git kernel.
AMD this morning updated its Kaveri APU line-up and also released a new Athlon X4 processor.
Super-computing researchers part of the Institute of System Research for the Russian Academy of Sciences recently presented on using the open-source Radeon driver for OpenCL.
Last week AMD launched GPUOpen and began shipping their new and open code. Today the company has published a guide for taking advantage of the Boltzmann stack with their Radeon Open Compute Kernel and Runtime.
While the Linux 4.5 kernel's merge window ended more than one week ago, it looks like the AMDGPU driver may get a late feature arrival: ACP support.
Since yesterday's release of Linux 4.5-rc2 there was at least one report of AMDGPU performance improvements with Linux 4.5-rc2 for an R9 Fury "Fiji" graphics card.
With Linux 4.5-rc2 that was released last night, the new AMDGPU DRM driver is supposedly much faster compared to last week's 4.5-rc1 kernel.
Whew, tons of Linux graphics benchmarks this weekend, in large part for getting more eyes looking at the new OpenBenchmarking.org web interface that's now in beta so feedback can be received and get it all tuned up for the official release in February. The latest of these benchmarks this weekend is comparing the out-of-the-box Ubuntu 15.10 performance against the speed when upgrading the Linux kernel and Mesa for the AMD R600g and RadeonSI Gallium3D drivers.
A few days back I showed the Radeon vs. AMDGPU vs. Catalyst kernel driver potential when testing on the R9 290 "Hawaii" graphics card that has experimental and disabled-by-default support for the new AMDGPU kernel driver primarily designed for AMD GCN 1.2 GPUs and newer. Those results were interesting and showed some areas where AMDGPU came out faster than Radeon, so I decided to run experimental tests on another GCN 1.1 Sea Islands GPU that can be made to work with this kernel driver.
The latest batch of open-source Linux benchmarks to share this weekend are doing some P-State and CPUFreq scaling driver benchmarks and also trying each driver's different CPU scaling governor options when using the AMD Radeon R9 285 graphics card on the AMDGPU kernel driver of Linux 4.5.
When it comes to OpenGL 4 support on the AMD R600 Gallium3D driver for pre-GCN graphics cards, currently the only R600g-supported cards advertising OpenGL 4.1 right now are the Radeon HD 5800 "Cypress" and Radeon HD 6900 "Cayman" series. Here are some tests done with OpenGL 4.1 on a Radeon HD 5830 compared to Cayman and various GPUs with the RadeonSI Gallium3D driver.
This week I've already delivered a number of AMDGPU/Radeon benchmarks from the in-development Linux 4.5 kernel now that there's AMDGPU PowerPlay and other improvements. With the week not being over, here are some more AMD Radeon graphics card benchmarks from Linux 4.5 while also using Mesa 11.2-devel Git with LLVM SVN.
With yesterday's Linux 4.5 AMDGPU/Radeon vs. Catalyst OpenGL Performance testing, the loser was the R9 Fury "Fiji" graphics card on the AMDGPU open-source driver with the performance still being miserable. Even with PowerPlay enabled on Linux 4.5, the performance was still poor. But if forcing to a high performance state via sysfs, is the performance any better?
While the AMDGPU DRM driver doesn't enable the necessary Kconfig option by default, it's supposed to be possible to use this new DRM driver with the AMD GCN "Sea Islands" (CIK) graphics cards rather than just Tonga and Fiji when it comes to the currently shipping discrete GPUs.
Fresh off this morning's launch of GPUOpen, Radeon Technologies Group has announced the Radeon Open Compute initial release.
Today's the day that AMD opens up GPUOpen.
A number of AMDGPU LLVM back-end changes have been hitting the mainline LLVM SVN/Git code-base in recent days.
Here's a fresh kernel spin of the brand new Linux 4.5-rc1 kernel with the latest AMDGPU PowerPlay bits enabled.
AMD's upcoming "Stoney" APUs has support for ETC2 texture compression.
The user-space side of semaphore support is getting taken care of for the new AMDGPU driver.
Since last month Intel has offered compute shader support via their open-source Linux graphics driver. The ARB_compute_shader support is needed for OpenGL 4.3 but so far Intel is the only Mesa/Gallium3D driver having support for this important extension.
The AMD Heterogeneous System Architecture (HSA) code has been mainlined within the GCC compiler!
The other follow-up question I received an answer to on Friday from AMD's media liaison was whether the company is looking at supporting the OpenGL Vendor Neutral Dispatch Library (GLVND) to make it easier to install and maintain their user-space GL driver on Linux systems.
Earlier today I wrote about how AMD will only be supporting Vulkan with the AMDGPU DRM kernel driver and not the more common Radeon DRM kernel driver. Here's a few more points to clarify the situation.
I've just received confirmation from AMD that their forthcoming Vulkan driver will only work with the AMDGPU DRM kernel driver. This means that unless this AMDGPU kernel driver is extended to support pre-VI hardware, only the very latest AMD GPUs on Linux will work with Khronos' next-generation API.
While the Radeon DRM driver has had support for doing GPU resets in case of hangs, the AMDGPU DRM driver for newer graphics processors haven't had this feature.
1108 AMD news articles published on Phoronix.