

I mean, if you can get a 50 series card at MSRP then do, the scalping sucks but otherwise it’s still a slight perf/€ win over 40 series.
I mean, if you can get a 50 series card at MSRP then do, the scalping sucks but otherwise it’s still a slight perf/€ win over 40 series.
It’s not the same, but it provides similar performance. The performance gains are being compared to stock wine, not to Proton with esync or fsync.
NTsync won’t change much for performance compared to Nobara with Proton. Proton has used esync and fsync for many years now which provide similar performance, but with flaws that prevent them from being upstreamable to Wine. NTSync will allow upstream wine to match fsync performance and hopefully fix some bugs.
A big problem with Android is ARM vendors don’t upstream anything in so you need to run very specific kernel and bootloaders just to boot the OS. SteamOS on x86 won’t have that problem, regardless of who makes the end device.
This looks nice, especially cool that it supports multiple vendors.
This is frame generation. That’s a second option on top of the older DLSS super resolution (upscaling) that doubles framerates at the cost of some latency. It only works on 4000 series cards.
That DLSS frame generation works in Proton
Yes, and ChromeOS is built from Gentoo. That doesn’t mean much, the end user experience is worlds different.
Mostly that it doesn’t work on Steam Deck. Hits memory limits IIRC.
It would allow them to do HDMI FRL also, which is probably what you mean when you say HDMI 2.1. AMD cards also do HDMI FRL I thought. FRL is what allows things like 4k120Hz (higher bandwidth modes). The VRR that the Dock does is the VRR standardized with 2.1, which is why it works on TVs and devices that do not support freesync (see: LG TVs).
Anyway, the Dock doesn’t have a fast enough HDMI converter to do that. It’s not a licensing issue. Next gen Deck/Dock will probably do it.
Actually it works fine on Steam Deck. It uses VRR over DP to the dock, which then translates it to HDMI with VRR. The dock has proprietary firmware to do this.
Intel and Nvidia hardware with open source kernel drivers also do a similar trick where the HDMI part is in a firmware blob. Only AMD does not work with HDMI VRR.
Exactly. That’s why it’s a trash motherboard as soon as root access is gained. It can never again be trusted.
How do you trust that the flash was done properly if you did it from the compromised system? This would only work if you flashed it externally somehow without the system running.
Yes it is. It’s not in mainline wine, it’s been in kernel for a long time now.
It’s annoying all the articles are focusing on performance versus stock wine here when basically everyone uses Proton or a fork of it anyway, which has had fsync for years now that does similar performance uplift.
The story here should be that we’re getting fsync level performance with fewer bug and it can be upstreamed to wine. There is no relevant performance uplift for Proton users, but I guess performance gets clicks so that’s the story all the press are going with.
It’s not merged, but the benchmarks are against upstream wine. Proton has hacks (fsync) that have almost identical performance uplift but were not suited to upstreaming.
So basically this will improve “correctness” versus current Proton, not performance. Should fix some bugs and improve compatibility.
Versus stock wine, it’s a huge perf uplift though.
555.58 works great for me in Wayland. 3090 on Arch with Gnome
Knowing Mozilla it’s probably done client side (meaning it sends weather data for all major regions or something and the client filters what is needed)
Technically AMD also offers an open Vulkan driver (AMDVLK), it’s just dog shit, and an open compute driver (Rocm), its just also bad, and an open OpenGL driver (Radeonsi), which is solid.
Those three are all primarily developed by AMD engineers and are fully open. Nvidia has no such open equivalents.
It’s not known either way yet, but unless they offloaded it to a separate firmware like Nvidia or Intel, it’s not possible for them to do in Linux due to HDMI patents. The way the other vendors avoided this is to use a separate component that does everything internally, so none of the code is in the drivers. AMD doesn’t do that historically, and thus can only support such features with closed source drivers/OS.