AMD

It seems that the latest AMD Adrenaline drivers for Windows require that you agree to AMD's AI Acceptable Use Policy.

Ahead of tomorrow's availability of the AMD Ryzen 7 9800X3D processor as the first Zen 5 CPU released with 3D V-Cache, today the review embargo lifts. Here is a look at how this 8-core / 16-thread Zen 5 CPU with 64MB of 3D V-Cache is performing under Ubuntu Linux compared to a variety of other Intel Core and AMD Ryzen desktop processors.

Thanks to Valve's Linux graphics team, VK_EXT_device_generated_commands is now supported by the Radeon "RADV" Vulkan driver with the upcoming Mesa 24.3 release.

AMD has been teasing the Ryzen 9000X3D Zen 5 CPUs with 3D V-Cache and today they formally announced the specs of the Ryzen 7 9800X3D processor that will begin shipping 7 November.

This community seems to be abandoned by the moderator, but people are still keeping it alive, I would like to offer an alternative one for those people. Fair or unfair lemmy.ml has a reputation that limits its potential pool of contributors.

The AMD Ryzen 9000 series starting with the Ryzen 5 9600X and Ryzen 7 9700X launching tomorrow are some truly great desktop processors. The generational uplift is very compelling, even in single-threaded Linux workloads shooting ahead of Intel's 14th Gen Core competition, across nearly 400 benchmarks these new Zen 5 desktop CPUs impress, and these new Zen 5 desktop processors are priced competitively. I was already loving the Ryzen 7000 series performance on Linux with its AVX-512 implementation and performing so well across hundreds of different Linux workloads but now with the AMD Ryzen 9000 series, AMD is hitting it out of the ball park. That paired with the issues Intel is currently experiencing for the Intel Core 13th/14th Gen CPUs and the ~400 benchmark results makes this a home run for AMD on the desktop side with only some minor Linux caveats.

🤖 I'm a bot that provides automatic summaries for articles: Click here to see the summaryThis is the best summary I could come up with: AMD is hiring engineers to work on build and packaging of their "AMD Unified Linux Driver" to enhance the experience of deploying their packaged graphics driver stack -- including ROCm -- across different Linux distributions. AMD is hiring multiple engineers to work on build/packaging for their Linux graphics software stack. This job posting sums up that given role as: "AMD is looking for a specialized software engineer to join our Linux Build, Packaging and Install team. You will be a member of the core team of incredibly talented and highly motivated industry specialists and will work with the very latest graphics and compute hardware and software technology." There are other similar job postings as well all about Linux build and packaging of their graphics driver software. Here's to hoping that the additional hires and any other "AMD Unified Linux Driver" changes make for an easier to deploy AMD Linux graphics driver experience across distributions, especially leading-edge distributions and other non-enterprise environments, for lowering the barrier of deploying ROCm compute support. The original article contains 467 words, the summary contains 170 words. Saved 64%. I'm a bot and I'm open source!

🤖 I'm a bot that provides automatic summaries for articles: Click here to see the summaryThis is the best summary I could come up with: The Instinct MI325X, at least from what we can tell, is a lot like Nvidia's H200 in that it's a HBM3e-enhanced version of the GPU we detailed at length during AMD's Advancing AI event in December 2023. Despite hardware support for FP8 being a major selling point of the MI300X when it launched, AMD has generally focused on half-precision performance in its benchmarks. For a lot of its benchmarks, AMD is relying on vLLM – an inference library which hasn't had solid support for FP8 data types. But if your main concern is getting a model to run on as few GPUs as possible and you can not only drop to lower precision but double your floating point throughput, it's hard to see why you wouldn't. AMD isn't oblivious to the fact Nvidia's Blackwell parts hold the advantage, and to better compete the House of Zen is moving to a yearly release cadence for new Instinct accelerators. According to AMD, CDNA 4 will stick to the same 288GB of HBM3e config as MI325X, but move to a 3nm process node for the compute tiles, and add support for FP4 and FP6 data types – the latter of which Nvidia is already adopting with Blackwell The original article contains 1,113 words, the summary contains 204 words. Saved 82%. I'm a bot and I'm open source!

🤖 I'm a bot that provides automatic summaries for articles: Click here to see the summaryThis is the best summary I could come up with: While the albeit unofficial desktop GPU support has continued to improve for the ROCm compute stack, one of the areas that sadly hasn't received much attention at all has been for the integrated Radeon graphics on their APUs/SoCs. It's rare to see any code activity or mentioned improvements around ROCm / GPU compute on the AMD desktop/laptop APUs even though their popularity has increased greatly with the competitiveness of recent generations of Ryzen SoCs. Making its way into Linux 6.10 Git is an improvement to the AMDKFD "AMD Kernel Fusion Driver" for GPU compute around these small APUs. AMD engineer Lang Yu summed up the change as: "Small APUs(i.e., consumer, embedded products) usually have a small carveout device memory which can't satisfy most compute workloads memory allocation requirements. Thus acknowledging the existing issue of even basic PyTorch examples not being able to run with the compute stack on "small" Ryzen SoCs with Radeon graphics. This change was merged to Linux 6.10 Git as part of the DRM fixes submitted on Friday. The original article contains 370 words, the summary contains 171 words. Saved 54%. I'm a bot and I'm open source!

🤖 I'm a bot that provides automatic summaries for articles: Click here to see the summaryThis is the best summary I could come up with: AMD claims it is touching 33 percent in server CPU market share as it looks towards the launch of its next-gen "Turin" processors, and is promising a GPU roadmap for what comes after the MI300 product line. AMD has invested heavily in datacenter products, and Hu noted that's paid off with its recent momentum in both CPUs and GPUs for servers. In the enterprise market, Hu revealed that demand is starting to pick up – driven by the cost and power savings that AMD claims versus rival server technology (read: Intel). She cited large enterprise customers such as American Express, Shell, and STMicro that are shifting to AMD-based infrastructure, and hoped this would continue with the "Turin" Epyc chips, based on its Zen 5 cores and due later this year. Meanwhile, Arm is slowly making inroads into both PCs and datacenter servers, with Qualcomm showcasing numerous Windows-on-Arm devices at Microsoft Build this week. Sectors such as industrial and automotive have been going through what Hu called a "deep inventory correction cycle" of late, but she predicted the first half of this year will be the bottom of the market, with a gradual recovery to follow. The original article contains 920 words, the summary contains 195 words. Saved 79%. I'm a bot and I'm open source!

🤖 I'm a bot that provides automatic summaries for articles: Click here to see the summaryThis is the best summary I could come up with: The open-source Mesa driver developers employed by Valve for working on the Linux graphics stack have begun preparing the RADV Vulkan driver and the ACO compiler back-end for the upcoming "GFX12" graphics IP for next-generation RDNA4. The open-source AMD Linux graphics stack has been abuzz the past few months with GFX12 preparations for this next-gen graphics IP succeeding GFX11 used by RDNA3 class hardware. Landing this week was GFX12 assembler support within the ACO compiler back-end by Rhys Perry. Overnight Rhys opened up another merge request for GFX12 wait counters in ACO. Yesterday well known RADV developer Samuel Pitoiset of Valve opened this merge request with small preliminary changes to be done before adding the GFX12 support: "A bunch of context register moved on GFX12 and this MR contains small changes to simplify adding GFX12 support." Over on the kernel side, the new AMD IP blocks continue to be enabled within the AMDGPU and AMDKFD drivers. The original article contains 262 words, the summary contains 156 words. Saved 40%. I'm a bot and I'm open source!