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.
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!
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
Surely they’ll make a native Linux client then, right, right?!
(Meanwhile; shoutout to Heroic)
Any particular reason you’re not on/tested the v590-branch? Of course it might be borked compared to 570, but might be worth a shot?
Why not just grab the previous PKGBUILD version that worked?
Not sure if you have the same problem or not, but I had intermittent jitter spikes (and/or complete package drops) every 60 seconds on my Realtek chipset, ran:
sudo iw dev wlan0 set power_save off
And it’s been stable since (just had to make a udev rule to make it persistent across boot)
Have you enabled Southern Islands support as a kernel parameter? Your generation of GPU was originally supported on radeon, so you need to explicitly enable SI (Southern Islands) support to use amdgpu.
See ArchWiki for more information
There is a patch-series that is now merged into 6.15-rc1 that exposes more i2c/RGB controllers on the GPU side for AMD cards, so that kernel + OpenRGB (as others have mentioned) might be a solution down the line
Patch series for reference: https://lists.freedesktop.org/archives/amd-gfx/2025-January/118399.html
In general it sounds like you want ‘tiling’. There are multiple window managers that does this, e.g. AwesomeWM, i3, Sway, River etc.
Additionally you typically have ‘tiling scripts’ that work on top of Gnome and Kwin (Plasma), however unsure what the capabilities are there.
I can atleast speak for Sway:
Here you can can move/select the current focused window relative to whatever key strokes you prefer, the defaults are using Vim-bindings, but arrow keys are also pretty common.
For grabbing a specific window (like in an ordered manner) is probably something that you would need to extend through scripting if the ‘basic’ movement isn’t enough.
Note: A tiling window manager is quite different (in usage) from a stacking one (which is what one is mostly used to) tiling capabilities/scripts
Der8auer’s video is worth a watch, he got one of the Redditor’s card:
Yes, so R&D and finalizing the model weight is done on NVIDIA GPUs (I guess you need an excessive amount of VRAM).
Inference is probably gonna be offloaded to consumers in the end where the NPU is taking care of the inference cost (See Apple, Qualcomm etc)
Not the best on AI/LLM terms, but I assume that training the models was done on Nvidia, while inference (using the model/getting the data from the model) is done on Huawei chips
To add: Training the model is a huge single-cost expense, while inference is a continuous expense.
For reference/others:
The setting is:
Settings -> Downloads -> Enable Shader Pre-caching