Some people have reported that installing the 32-bit version of mesa libva drivers makes it work for them? Might be worth a shot.
Some people have reported that installing the 32-bit version of mesa libva drivers makes it work for them? Might be worth a shot.
Yeah, in a Reddit comment, Hector Martin himself said that the memory bandwidth on the Apple SIlicon GPU is so big that any potential performance problems due to TBDR vs IMR are basically insignificant.
…which is a funny fact because I had another Reddit user swear up and down that TBDR was a big problem and that’s why Apple decided not to support Vulkan and instead is forcing everyone to go Metal.
I’ve heard something about Apple Silicon GPUs being tile-based and not immediate mode, which means the Vulkan API is different compared to regular PCs. How has this been addressed in the Vulkan driver?
Huge fucking deal, especially for Nvidia users, but it is great for the entire ecosystem. Other OSes have had explicit sync for ages, so it is great for Linux to finally catch up in this regard.
You’re correct. While the stable version of KDE Wayland is usable right now with the new driver with no flickering issues, etc., it technically does not have the necessary patches needed for explicit sync. Nvidia has put some workarounds in the 555 driver code to prevent flickering without explicit sync, but they’re slower code paths.
The AUR has a package called kwin-explicit-sync, which is just the latest stable kwin with the explicit sync patches applied. This combined with the 555 drivers makes explicit sync work, finally solving the flickering issues in a fast performant way.
I’ve tested with both kwin and kwin-explicit-sync and the latter has dramatically improved input latency. I am basically daily driving Wayland now and it is awesome.
I truly believe the answer to this question is going to be yes around the May - June timeframe when Nvidia releases their explicit sync enabled drivers. All aboard the Wayland hype train babyyyy!
BUT they can’t implement it on MacOS because Apple won’t allow it
Yeah, but Apple isn’t allowing it (at least according to the comment you replied to), so if Riot continues to allow their games to run on Mac without kernel anti-cheat, then their whole argument against Linux support is moot.
But if the Mac client doesn’t have anti-cheat, doesn’t it totally defeat their whole argument?
They’re at different layers of the audio stack though so not really replacing.
Well…have you filed bugs for your issues?
Most people have had a very smooth transition over to Pipewire. I have 4 Arch machines and Pipewire has been flawless. I am even using one machine for pro-audio usecases (REAPER, Ardour).
I’ve been using it for years and now I basically can’t live without it. I consider OpenWrt compatibility in all of my router purchases. Currently using a Netgear R7800 and a Belkin RT3200, both are going strong.
It isn’t as widely used because it can be finicky to flash sometimes, and that’s if it’s even compatible in the first place. Even if it works, you may experience a drop in performance unless OpenWrt supports using the routers hardware acceleration features. If there’s no support, OpenWrt basically uses the onboard CPU to do routing and they’re usually not all that powerful.
It’s a native app on Windows and Mac?
I am so happy power-profiles-daemon now sets the CPU driver instead of only setting the platform_driver when it is present. It was a big pain point of mine.
Seriously. I really hope this allows Ken to get some additional developers onboard. Dude sounds like he’s shouldering a ton of responsibility at the moment.
Your issues stem from going rootless. Podman Compose creates rootless containers and that may or may not be what you want. A lot more configuration needs to be done to get rootless containers working well for persistent services that use low ports, like enabling linger for specific users or enabling low ports for non-root users.
If you want the traditional Docker experience (which is rootful) and figure out the migration towards rootless later, I’d recommend the following:
podman-docker
. This provides a seamless Docker compatibility layer for podman, allowing you to even use regular docker commands that get translated behind the scenes into Podman.docker-compose
. This will work via podman-docker
and gives you the native docker compose experience.podman.socket
and podman-restart.service
. First one socket-activates the central Podman daemon, second one restarts any podman containers with a restart-policy
of always
on boot.sudo
, so sudo docker-compose up -d
etc. You can run this with sudo podman compose
as well if you’re allergic to hyphenation. Podman allows both rootful and rootless containers and the way you choose is by running the commands with sudo
or not.This gets you to a very Docker-like experience and is what I am currently using to host my services. I do plan on getting familiar with rootless and systemd services and Kubernetes files, but I honestly haven’t had the time to figure all that out yet.
Performance parity? Heck no, not until this bug with the GSP firmware is solved: https://github.com/NVIDIA/open-gpu-kernel-modules/issues/538