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?
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.
Interesting solution! Thanks for the info. Seems like Nginx Proxy Manager doesn’t support Proxy Protocol. Lmao, the world seems to be constantly pushing me towards Traefik all the time 🤣
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!
I think there was some bad vibes when they got bought by a less than reputable company a while back. I know a lot of people, myself included switched to Mullvad. I am on Proton now though for the port forwarding.
I see. And the rest of your services are all exposed on localhost? Hmm, darn, it really looks like there’s no way to use user-defined networks.
I am guessing you’re not running Caddy itself in a container? Otherwise you’ll run into the same real IP issue.
I see! So I am assuming you had to configure Nginx specifically to support this? Problem is I love using Nginx Proxy Manager and I am not sure how to change that to use socket activation. Thanks for the info though!
Man, I often wonder whether I should ditch docker-compose. Problem is there’s just so many compose files out there and its super convenient to use those instead of converting them into systemd unit files every time.
Yeah, I thought about exposing ports on localhost for all my services just to get around this issue as well, but I lose the network separation, which I find incredibly useful. Thanks for chiming in though!
Pasta is the default, so I am already using it. It seems like for bridge networks, rootlesskit is always used alongside pasta and that’s the source of the problem.
All of this is still irrelevant. If given the same hardware, one OS performs better than another, then one OS is obviously more optimized…
You’re saying a lot of words but it all just boils down to “throw more hardware at the problem”.
How is this relevant? If an OS performs better on old hardware, it’s still an indication that it is more optimized.
They’re at different layers of the audio stack though so not really replacing.
If anything, it’s Epic that will succumb to capitalism because they’ve been failing to innovate on their platform since the beginning. EGS is still a glorified game launcher without any platform features. Where’s the equivalent to Steam Input, Remote Play and Remote Play Together, Family Sharing, Chat, Discussion Boards, Proton, Steam Deck, etc.?
Maybe spend some of that Fortnite money on your platform instead of buying up exclusives…
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).
Man, I have GOT to try Truenas Scale one of these days. I see it recommended so often, but I was just too used to a standard Linux ecosystem to bother learning something new. I am assuming it gets you closer to the feel of a pre-built NAS during administration tasks compared to Cockpit and a SSH session lmao.
I think I am just always afraid of being locked into a specific way of doing things by a vendor. I feel like I would get annoyed if something that I could do easily on standard Linux was harder to do on Truenas Scale.
I have zero trust in QNAP. QNAP knowingly sold several NASes with a known clock-drift defect in their Intel J1900 CPUs and then refused to provide any support. A bunch of community members had to figure out how to solder a resistor to temporarily revive their bricked NASes in order to retrieve their data. https://forum.qnap.com/viewtopic.php?t=135089
I had a TS-453 Pro and my friend had a TS-451. Both mine and his exhibited this issue and refused to boot. After this debacle and the extreme apathy from their support, I vowed to never buy a pre-built NAS.
That’s not where Valve makes their money from though. Their money primarily comes from store purchases, so anything to expand Steam’s reach is better for them. Plus, keeping Steam as relevant and ubiquitous as possible will in turn promote sales of the Steam Deck. The Xbox and Steam Deck cater to fundamentally different use cases anyways.
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.