There is (unofficial) ROCm support for Strix Halo with ROCm 6.4.1. But like Llama.cpp and such were seg faulting but ROCR-based OpenCL was working and other workloads.

ROCm GPU Compute Performance With AMD Ryzen AI MAX+ "Strix Halo": https://www.phoronix.com/review/amd-strix-halo-rocm-benchmar...

What’s AMD's strategy in not having consumer chip support for ROCm? It's puzzling. No way to get critical mass of development interest if the bar to entry is high.

You can run theoretically run ollama on it, as with the earlier APUs (I did it on an M780 by allocating 16 of the machine's 32GB to the iGPU). I am _very_ interested in getting my hands on one because I see it as a decent compromise between power, RAM capacity (with soldered-on RAM, it's got pretty good latency) and performance.

Checks out. Increase number by 1,000 every year, modulo 10,000.

We have a GPU/CPU fusion chip that is unremarkable, performant and runs well under linux out of the box. There isn't a lot of novelty in that which is, in itself, pretty remarkable.

Plus, although I can't really swear to understand how these chips work, my read is this is basically a graphics card that can be configured with 64GB of memory. If I'm not misreading that it actually sounds quite interesting; even AMDs hopeless compute drivers might potentially be useful for AI work if enough RAM gets thrown into the mix. Although my burn wounds from buying AMD haven't healed yet so I'll let someone else fund that experiment.

It appears it's using significantly more power than the Intel ones as well. I would be more interested in GPU computing performance for LLMs than graphics, as all I need is a frame buffer.

The Strix Halo GPU is roughly around RTX 4060 (laptop version) performance.

Phoronix just doesn't do much mobile dGPU testing in general to have any data to compare with there.

Agreed that for GPU oomph, you'd do better with a dGPU; there's some very good deals for dGPU laptops but even this next-tier-down 8050S is still a rather expensive new purchase by compare (for now; Strix Halo is brand new). But the power consumption will likely be much higher.

Strix Halo as an APU has two very clear advantages. First, I expect power consumption is somewhat better, due to using LPDDR5(x?) and not needing to go over PCIe.

But the real win is that you can get a 64GB or 128GB GPU (well somewhat less than that)! And there's not really anything stopping 192GB or 256GB builds from happening, now that bigger ram sizes are finally available in the world. But so far all Strix Halo offerings are soldered on ram (non user upgradeable, no camm2 offerings yet), and no one's doing more than 128GB. But that's still a huge LLM compared to what consumers could run before! Or lots of LLMs loaded and ready to go! We see similar things with the large unified memory on Mac APUs; it's why are minis are sometimes popular for LLMs.

Meanwhile Nvidia is charging $20k+ for an A100 GPU with 80GB ram. You won't have that level of performance, but you I'll be able to fit an even bigger LLM than it. For 1/10th the price.

There's also a lot of neat applications for DB's or any kind of data-intense processing. Because unified memory means the work can move between CPU and GPU, without having to move the workload. Normally to use a GPU you end up copying data out of main memory then writing it to the GPU* then reading it to do work, and you can skip 2/3rds of these read/write steps here.

There's some very awesome potential for doing query processing on GPU (ex: PG-Strom). Might also be a pretty interesting for a GPU based router, ala PacketShader (2010).

* Note that PCIe p2p-dma / device RDMA / dma-buf has been getting progressively much better, a lot of attention, across the past half deacde, such that say a nic can send network data direct to GPU memory, or a NVMe drive can send data direct to GPU or network, without bouncing through main memory. One recent example of many: https://www.phoronix.com/news/Device-Memory-TCP-TX-Linux-6.1...

Giving an APU actually fast ram has some cool use cases. I'm excited to see the lines blur in computing like this, to see

My guess is that Valve will wait at least 1 more generation, since Zen 6 will be on N2p which will be the first nanosheet generation (with promised 30% power reductions compared to the n3e that zen5 uses). Valve clearly is more interested in a console model with new releases only when there is a massive performance uplift compared to the prior generation, so I think we are at least 1 gen away. Specifically, I think their target will be 1080p/60fps on low settings (or higher settings using fsr).

Valve cares about battery life and user experience more than just raw power, and after watching multiple other handhelds deliver very insubstantial improvements over Steam Deck OLED at 3x power consumption, I tend to agree. I'm convinced that SD2 won't happen until measurable improvements at the same 15W power limit the current Deck has. There are plenty of older games and indies in Steam catalog that play perfectly fine on Deck, and chasing the latest power hungry UE5 juggernauts is a losing proposition.

One thing I wouldn't mind having on my Deck is FSR4 support, though AMD still hasn't submitted their Vulkan FP8 support proposal, requiring unofficial Mesa hacks to enable it even on desktop Linux.

Shoving a 45W+ chip into a steam deck would result in more compromises than most would like.

Chipset doesn't attach to any RAM.

Today's northbridge (aka: Memory controller) is on CPUs. GPUs need a powerful memory controller. And the most powerful memory controller between CPU and Southbridge/Chipset is the memory controller on the CPU itself.

Strix Halo is the powerful-GPU product version.

More generally there isn't really a place for low performance integrated graphis any more and southbridge style chips are made with old old cheap processes that cripped with poor memory access would probably not run any modern desktop well. A second option for the memory would be to put a small amount of local memory on the mobo along with the chipset, which again would be slow and still costly while losing the normal iGPU advantage of unified gpu & cpu memory access to th same data (UMA).

As I understand it, chiplets were introduced to address this problem while being a SoC.