BTW, what actually is “Strix Halo” anyway? I’m confused about whether it’s what they’re calling all the latest-generation APUs, or just the high-end ones, or Asus co-branding, or what.
Strix Halo is the "high-end" ones (and currently the latest), in terms of gaming they are closer to previous gen discrete laptop GPU (hence they use the naming scheme Radeon 8XXX series).
There are smaller ones as well, the one that is "mid-tier" is Strix Point, which has the Radeon 800M series GPU, i.e. closer to what one had in previous generations of integrated GPUs.
In terms of gaming performance, you can compare using Notebookcheck, as an example; Kingdom Come Deliverance 2 on low preset at 1080P:
CPU
GPU
APU
Average FPS
Ryzen AI 9 HX 370
AMD Radeon 890M
Strix Point
19.9
Ryzen AI Max Pro 390
AMD Radeon 8050S
Strix Halo
76.6
Ryzen AI Max+ 395
AMD Radeon 8060S
Strix Halo
101.7
So, there's a pretty big leap going from Strix Point (mid tier) to Strix Halo (high-end)
I would assume the total area is larger for the separate CPU+GPU die when compared a single unified chip, sure.
But the cost per millimeter doesn't necessarily scale linearly either (larger chip, lower yields), so it might be cheaper to buy CPU+GPU rather than the unified chip even though the total area is larger.
Custom in this case doesn't really need to carry any weight either, it could be a simple voltage bump, clock bump, laser cutting cores etc. and they would still call it custom.
It's not a "from the ground up" custom chip.
Unified still requires a significant amount of chip area per die, especially if they want to have a relatively beefy GPU (somewhere below Radeon 8060S, but above Radeon 780M).
I would imagine this gives the best perf./buck from Valve's POV, without costing an arm and a leg
I think this is just downloading the (new) shader sets see Github issue.
I'm using an AMD GPU and never had any issues with disabling the shader cache in Steam. Note that in some games it might be a bit stuttery in the very beginning then due to the shader compiler (ACO if using Mesa drivers with AMD) running in the background.
Just saying that certain CEF/Electron apps (especially those running on older Chromium version) are what is causing certain Wayland specific issues, hence my issue is on the application side (Steam, Spotify etc.), not on Wayland's side... My bad for the badly worded post which made it seem like the classical "Wayland bad!" posts.
I haven't touched X11/Xorg in years, nor am I planning on reverting back to it anytime.
most (if not all) Wayland issues I currently have are related to Chromium, and especially CEF/Electron applications that are based on older Chromium versions. Weren't trying to say that this is an inherent Wayland issue, considering most of the applications works as expected.
Why have a consistent Wayland experience when each application can run it's own Electron version with varying degrees of enforced Wayland flags, and/or such an outdated Chromium version Wayland is just jank.
Edit:
Was trying to say that most of these CEF/Electron applications all need their own separate Wayland specific (Chromium) flags to have better Wayland support/integration. And the older Electron applications typically use an older Chromium as base, having even worse Wayland support... Was not trying to make this a "Wayland bad!" kind of post.
TL;DR: Electron applications have wildly varying level of Wayland support/integration, don't have any Wayland issues other than specific CEF/Electron apps!
Damn, they giving out electromagnetic interference for free, how nice!
You could install
linux-lts, I sometimes use that as a sanity check in case there is some kernel fuckeryDid you also update systemd at the same time? It might be worth reverting that update to see whether it's that causing the issues.
To me, this sounds more like an fstab/systemd-automount issue rather than a bootloader/initrd issue
https://github.com/ValveSoftware/steam-for-linux/issues/3671
Another classic
ArchWiki is your friend
I assume the LLM assume you are using either Proton-GE, Proton-EM or Proton-cachy, where this flag actually works 🤔
Strix Halo is the "high-end" ones (and currently the latest), in terms of gaming they are closer to previous gen discrete laptop GPU (hence they use the naming scheme Radeon 8XXX series).
There are smaller ones as well, the one that is "mid-tier" is Strix Point, which has the Radeon 800M series GPU, i.e. closer to what one had in previous generations of integrated GPUs.
In terms of gaming performance, you can compare using Notebookcheck, as an example; Kingdom Come Deliverance 2 on low preset at 1080P:
So, there's a pretty big leap going from Strix Point (mid tier) to Strix Halo (high-end)
I would assume the total area is larger for the separate CPU+GPU die when compared a single unified chip, sure. But the cost per millimeter doesn't necessarily scale linearly either (larger chip, lower yields), so it might be cheaper to buy CPU+GPU rather than the unified chip even though the total area is larger.
For reference, TechPowerUp lists:
RX 7600M: 204 mm² @ TSMC 6 nm
Strix Halo: 308 mm² @ TSMC 4 nm
Not sure what kind of area one could expect for the CPU alone (without the integrated GPU) for this kind of process
Custom in this case doesn't really need to carry any weight either, it could be a simple voltage bump, clock bump, laser cutting cores etc. and they would still call it custom.
It's not a "from the ground up" custom chip. Unified still requires a significant amount of chip area per die, especially if they want to have a relatively beefy GPU (somewhere below Radeon 8060S, but above Radeon 780M).
I would imagine this gives the best perf./buck from Valve's POV, without costing an arm and a leg
I don't think there are any 'cheap' Strix Halo chips out there, Valve probably got a massive discount (relatively) by using previous gen. laptop parts
For reference/others:
The setting is:
Settings -> Downloads -> Enable Shader Pre-cachingI think this is just downloading the (new) shader sets see Github issue.
I'm using an AMD GPU and never had any issues with disabling the shader cache in Steam. Note that in some games it might be a bit stuttery in the very beginning then due to the shader compiler (ACO if using Mesa drivers with AMD) running in the background.
I think that's what Tauri is trying to do
Overall a fair assessment! 🤝
Very much pro-Wayland in my case.
Just saying that certain CEF/Electron apps (especially those running on older Chromium version) are what is causing certain Wayland specific issues, hence my issue is on the application side (Steam, Spotify etc.), not on Wayland's side... My bad for the badly worded post which made it seem like the classical "Wayland bad!" posts.
I haven't touched X11/Xorg in years, nor am I planning on reverting back to it anytime.
Yeah, maybe it was just badly worded by me...
most (if not all) Wayland issues I currently have are related to Chromium, and especially CEF/Electron applications that are based on older Chromium versions. Weren't trying to say that this is an inherent Wayland issue, considering most of the applications works as expected.
Why have a consistent Wayland experience when each application can run it's own Electron version with varying degrees of enforced Wayland flags, and/or such an outdated Chromium version Wayland is just jank.
Edit:
Was trying to say that most of these CEF/Electron applications all need their own separate Wayland specific (Chromium) flags to have better Wayland support/integration. And the older Electron applications typically use an older Chromium as base, having even worse Wayland support... Was not trying to make this a "Wayland bad!" kind of post.
TL;DR: Electron applications have wildly varying level of Wayland support/integration, don't have any Wayland issues other than specific CEF/Electron apps!
Biggs & Wedge!
Ohh, I don't use their web based application... The compiler is open-source, so I just run it completely offline
Github repo for reference on how to install the compiler/CLI version
Big fan of Typst these days;
Markdown-like syntax, with LaTeX typesetting, great for technical documents at least