deleted by creator
grow a plant, hug your dog, lift heavy, eat healthy, be a nerd, play a game and help each other out
deleted by creator
I’ve been lucky enough to dumb guy my fedora install since 28, and it’s been pretty decent to me. Granted I’m not using nvidia graphics, and I feel like that could throw a big spanner in the works for regular users. It’s a big enough leap getting into the mindset of installing software from Distro repos rather than directly from the vendor.
I hope the newer nv open kernel modules don’t stay out of tree. Also hope that NVK will give users the ability to just plug and play with mesa drivers in the future.
waiting to see it ported to the HTC hd2
Must be difficult since they don’t have telemetry to work with.
Gnome implements things people ask for
I still use GNOME but with an extension to prevent the behaviour mentioned above. The discussion in that thread was pretty wild.
Yikes I wasn’t aware of the second part
I was about to ask, isn’t this guy a prolific dickhead?
the reset situation may improve in the not too distant future: https://www.phoronix.com/news/AMDGPU-Per-Ring-Resets
Correct - FSR already applies CAS. I don’t think applying another CAS pass on top of that will work out too well.
FSR already incorporates CAS towards the end of the scaling process. The Adrenalin equivalent is called RIS but applies CAS to the entire rendered frame. I believe some apps allow you to tune CAS individually (2077 comes to mind?)
You can still technically use Vega and Polaris with ROCm, the official stance is that it’s no longer validated.
With that said, the setup and development experience is pretty dire and the docs do not seem to get updated in a timely manner.
(I heard)
Anecdotes aren’t data. It’s not difficult to find comparative pricing information. I think you would generally find this is untrue, though it’s worth considering regional pricing.
no CUDA
EULA violation. This one is cut and dry. You could have made a better point about the state of ROCm (narrow product and platform support, poor documentation, library gaps in HIP).
intel has best support
Look at the state of ANV for Arc dGPU on Linux.
I see. I’m really not keen on the use of MPT since I’ve seen it fairly broadly recommended to more casual users (I’d place the blame on certain YouTubers), occasionally leading to bricked ASICs, though I’m glad you’re seeing tangible benefit from using it.
Please bear in mind that custom tuning isn’t a guarantee between different driver versions; the voltage floor can shift with power management firmware changes delivered driver packages (this doesn’t overwrite the board VBIOS, it’s loaded in at OS runtime (pmfw is also included in linux-firmware)). I’d recommend testing with vulkan memory test with each Adrenalin update, and every now and then on Fedora too.
Same config and distro as you.
I’ve not experienced the first issue, so I don’t have a great deal of input for that. Could be a display specific behaviour.
For 2, I’ve had the Steam UI hang on occasion, though this has not occurred recently. I’ll try to see if I can get this to repro again.
For 3, there’s a few things worth bearing in mind here. AMDGPU and the Windows Radeon KMD don’t really have a lot on common. I’d be interested in any perf comparisons you have between the two systems even with the default mclk on linux. I find that Fedora is more performant in somewhat surprising scenarios, like with CP2077, Halo Infinite.
For 4, I could show you how to leverage the powerplay sysfs interface and run this via systemd service at login if you’d like?
Unfortunately have no input on 5 as I use Firefox but I hope you find a solution.
I also want to see RV develop to a point where it can compete with incumbents but sinkclose isn’t a hardware vulnerability. The issue here lies with AGESA, AMD will be moving to OpenSIL hopefully around 2026.
Furthermore, RISC-V is an Open ISA but that doesn’t necessarily mean products based on this remain open.
Isn’t this specific to AGESA rather than the hardware itself?
RISC-V ISA isn’t magically exempt from vulnerabilities. You can still be hit at a microcode level.
https://www.phoronix.com/news/GhostWrite-Vulnerability-RISC-V
For AMD, I’m wondering if OpenSIL can help prevent similar, deep system firmware vulnerabilities from lingering cross numerous product generations.
On Steam, I use
-novid -anticheat_settings=SettingsDX12.json
It does and has done for quite a while now on Wayland. GNOME Presently has experimental support for it but it works well enough in my testing.
I’ve been using the nightly releases for element X android for some time.
Sliding sync means messages are fetched quite a bit quicker, though it’s not yet feature complete relative to regular element android.
I’ve not yet tested element call on EXA, however, but it’s worked very nicely for me via web.