Could be a prod ready engineering sample. They get around more than you may think.

do you have the specific vendor model handy? Maybe it could help soemone else with the exact same model board (vendor supplied clock and voltage properties via VBIOS).

Huh, so the onboard power play was unstable? Which model GPU was this with?

they’re just little bulbasaurs charging up their solar beam

suse is neat 🥰

habibi I’m afraid I’ve not had good experiences with manjaro, I may need to defer to someone else in this thread. tumbleweed is cool as heck though.

I’d personally stick to fedora?

This may be at odds with stability somewhat being rolling release, but you may want to check out SUSE tumbleweed or EndeavourOS. You already have a solid pick based on your established requirements.

Couldn’t hurt to poke around other offerings in a VM, though

Yeah, they’re vastly different approaches, and despite my admittedly petty complaints, I’m eternally grateful for both; to me it feels as if both GNOME and KDE in some way cater to the creature comforts of MacOS and Windows respectively, and for end users hopefully moving on from both of those environments.

I find both KDE Plasma and GNOME can be made into serviceable experiences with enough time, and given the nature of FOSS and such, automating this as part of a custom deployment is a fairly trivial task in 2025 😊

I use this on specific systems but plasma’s information architecture (namely within the settings area) is bizarre to me. Yes you can search. No you shouldn’t have to resort to that.

I’m not keen on the little ‘K name everything’ in joke either, though thankfully you can rename desktop shortcuts to whatever you’d like there.

As some commentators have mentioned, that was mostly fine at the time of Ellesmere (2016ish?) where games wouldn’t so frequently shoot past that limit. In today’s environment, we find that a much higher proportion of games will want more than 8 GiB of VRAM, even at lower resolutions.

Notably, the most recent predecessor in this sort of segment (RX 7600 series) used the XT suffix to denote a different SKU to customers, though it’s worth mentioning that the XT was introduced quite a bit later in the RDNA3 product cycle.

I can appreciate that people use their systems very differently, but this is something that gnomes designers did not care to acknowledge throughout that whole exchange; input directly from their end users, and that’s bearing in mind they collect no telemetry.

I appreciate working in UX for a community driven project is no easy task, many of the people commenting in the thread linked above could be considered more advanced users with their own desktop shortcuts configured, and a one size fits all approach satisfying all is difficult to deliver. All they asked for was an option for this new behaviour.

The communication in that thread was so poor that matt miller got involved.

I gather the DE is supposed to stay out of your way, but it feels like a bandaid for another poor design decision when you frame it like that.

And in addition, no other desktop environment feels the need prompt the user to open or search for something from the get go.

On default gnome, you still have a hot corner in the upper left, and the dash along the bottom edge of the screen and I’m not sure I get that either.

Dash to panel, no overview at login, kstatus / appindicator tray icon support and gsconnect

The no overview at login story highlighted the sheer hubris of the gnome design team. Wild ride.

Phoronix is good resource on coverage for this component. The AMD CPU cppc driver (amd_pstate) is a kernel module.

Fedora would be one of the better fixed-release distros with this in mind (this is what I use personally so I may be biased). Faster still would be arch + derivs but that may incur some additional learning and care to use properly.

Think of the system firmware (SBIOS) and kernel and user spaces as different environments, the work on these components will target different aspects of your system. I would encourage keeping your BIOS up to date, particularly as these may ship critical HW and security fixes.

e: it appears there’s a sysfs interface specifically for the 3D cache:

https://www.phoronix.com/news/AMD-3DV-Cache-Optimizer-Linux

I can agree that the tweet was completely unnecessary, and the naming is extremely unfair given both variants have the exact same brand name. Even their direct predecessor does not do this.

The statement that AMD could easily sell the 16 GiB variant for 50 dollars less and that $300 gives “plenty of room” is wildly misleading, and from that I can tell they’ve not factored in BOM at all.

They blanketly state that GDDR6 is cheap and I’m not sure how they figure.

It’s an in-box driver, just not yet clear on per-distro inclusion. My tentative assumption is that you’ll want to make use of distros shipping newer packages.

I wouldn’t be surprised if something like that was the case. Could have been that the successive work was negotiated with khronos & lunarg before the final name was chosen.

I believe it’s an in-box driver, though the inclusion of this may be contingent on your distribution. I’ll try to clarify on Monday.

Yup, derived from a point in time where Vulkan was seen as a direct successor to OpenGL.

I suppose credit where due, AMD did kind of put an end to mantle, and give that over to the Khronos group to later become Vulkan. XGL as the UMD reference may predate the name Vulkan altogether.