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.
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.
No, AMDVLK is also a user space driver. You’re confusing it with AMDGPU, which is a kernel module.
I don’t think AMDVLK is even installed by default with Fedora. It can definitely be installed, but there’s not much reason to as it’s a really bad Vulkan driver.
The default driver used by Fedora is RADV. Steam/Proton does not choose your Vulkan driver. That’s why your games run well - you aren’t using the one made by AMD.
You’re missing my point. AMD’s official Linux drivers are ALSO garbage. Try it. Go install AMDVLK and check how well games work. You’re almost certainly using RADV, which was not developed by AMD.
What does that have to do with AMD’s driver support? AMD’s Linux Vulkan driver (AMDVLK) was so late and bad that Red Hat and Valve had to make their own (RADV), which is the default in Fedora and SteamOS. AMD’s first party drivers are still garbage.
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.
32GB is news. It confirms either a 512 or (more likely) 256 bit bus, which would be a significant drop from the 384 bit on the 4090.
I’m sure the increased perf of G7 would fully offset that, but this means without some larger caches it will be difficult for this to be a massive performance jump from last gen.
Unless they’re going 512 bit, in which case ignore all that and wow is this a monster.
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.
Sounds like you should be in the market for an electric boiler and induction cooktop.
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
I’m fairly confident “rustls” should be “rust language server” if it stands for anything…
Ideal would be them not reversing a decade of energy savings in the name of AI, but yeah, if they’re going to do that anyway then Nuclear is one of the better options.
I don’t think there’s a good guy. Both parties suck here.
We are now at the point where lobbying looks like a moral option compared to this shit