It’s good to be back to this forum and I’m quite happy about this. I recently upgraded from my X99 Intel/Nvidia platform to AMD/AMD and thought about getting back to EnOS.
You see, when I was using my old Intel/Nvidia bond, whenever I tried gaming, 3D Modeling or Programming it lacked performance as on Windows. So I was forced to use Windows for like half a year or so.
After some time I finally saved some money and managed to do a full upgrade and switch to AMD Ryzen 7 5700X3D along with AMD Radeon RX 7600XT.
And finally after 6 months or so I’m getting back to using EnOS as my daily drive so I would be grateful if you could answer some of my questions before I switch. So down below is a small list of questions that need to be asked
Is LACT good alternative to AMD Adrenalin?
Can I use external FSF/FSR to game? (like not in-game FSR 2)
Which software I can use to control ARGB (I have ARGB Fans, MSI Motherboard and GIGABYTE GPU)
Yes. But i can’t really tell if it offers all the options AMD Adrenaline has to offer. But you can definitely do some overclocking / undervolting and specify automatic profile switching in case gamemode is activated (e.g. gamemoderun %command% as launch option in steam or lutris.
Yes, afaik. But haven’t tried that yet, I just use in-game settings. Via lutris you can configure lots of options.
Check OpenRGB and supported devices in their database.
I don’t think so - I’m only aware of solaar as device manager for logitech input devices. And G Hub seems to be very specific.
While 64GB seem to be plenty, and the likelihood that files needs to be transferred into swap is rather low, it’s still recommended to have a swap partition. In short, avoiding issues by having one comes only with a penalty of a partition in equal size to your ram capacity. This may suck on a 128 GB SSD as a boot drive. But as nowadays NVMe are mostly 1 TB in size, that is negligible I think.
Excellent. Just check Steamdeck compabilities. Some complains due to popular online titles requiring anticheat programs… and not all of those solutions seem to be accessible on linux. But there is at least a Proton Battleye runtime available and valve made it pretty easy for external developers to activate Battleye support for their titles, which is more or less only a formality which has to be requested by the game devs. For some titles they hesitate or even refuse to do so though (the game devs, not valve).
About 3rd question they have bunch or Mystic Light entries, so I guess it might work for ARGB on MoBo and fans. But for GPU they only have 7800 XT. I may open a pull request for RX 7600 XT support, because I think RGB control unit is the same on both GPUs.
About 2nd question do even FSR 2 differs from FSR 3?
About 4th question as far as Solaar can change DPI and RGB its pretty good choice ig
Well, for 3 and 4 and RGB in general… I do eliminate each rgb light source where it’s not strictly required or functional, even desoldering those which annoy me. Therefore I can’t really help you in that regard.
FSR 2 is doesn’t include frame generation and latency reduction (Anti-Lag), is mostly an upscaler.
FSR 3 introduced those features.
In terms of frame generation, there are differences. As you’ve got a RX7600XT, which is a RDNA 3 chip,
AMD Fluid Motion Frames (AFMF) is a driver-level frame gen technique, which requires RDNA 2 or later GPUs.
Generally, FSR 2, 3 as well as Intel’s XeSS aren’t vendor locked unlike nVidias DLSS, which restricted to nVidia cards.
So if I get it right, AFMF and FSR 3 could appear in some games? By default or after some tweaks. Like for example on Windows in Squad I had to use AMD Adrenalin with its FSR 3, because the game only have FSR 2 built-in
I’d like to add that you might want to look at swappiness if you decide to use swap. With that, you can tell the system how often it should use swap or if it should try to avoid that. I feel like, with a large RAM, you can get away with using swap less. From my personal experience, the system tends to move files into swap sooner than I’d like. But might be different for you, I just wanted to make you aware of that option
In short, as Proton is more or less a translation layer for Vulkan to run Direct3D stuff, it is technically feasible to activate FSR 3 even if a game doesn’t support FSR at all, if I’m not mistaken. I just haven’t bothered to look into that stuff.
Just check https://www.protondb.com/ for general game compability, there you’ll find workarounds or even advanced options to configure a game to get the most out of it. Similiar info is shared via lutris as well. I just avoided potential rabbit holes and most of the time I don’t really bother to tweak settings to get the most out of it.
Thanks I’ll figure out about games compatibility after I fully switch. So about FSR, do I even need it? Like I guess it does make some games run better, but not all of them
Well, in terms of pure upscaling of the display resolution, it’s quite handy.
Frame generation on the other hand is a different topic which is also associated an option with FSR or XeSS. Some prefer XeSS over FSR as an upscaler. Both can be used in combination with an AMD GPU.
In short, as every graphics settings, it’s up to you as the end user.
Older titles which are running with more than 100 fps easily won’t really need any upscaling or frame generation.
Seems zram was the most popular conclusion/suggestion over there as well.
The user is already talking about LACT etc .. I dont think choice of SWAP is something too scary.
It should also be less important with the specs given - already high RAM and zram is more impressive when compared to something like spinning hard disk swap.
I tend to suggest it not only because its what I use, and because I think its the most efficient in most cases, but also because its ultimately simpler - does not require something like a partition, so does not require extra disk considerations, or fooling with deleting or expanding them given some future decision.
Which doesn’t include the very common use case that hibernation will require at least a swap file and zram won’t allow for hibernation that easily, it is quite an involved process to set up, if I’m not mistaken.
ZRAM was specifically developed for systems with limited physical memory, EndeavourOS doesn’t ship with it by default. SWAP (and zswap) is the default configuration EnOS is shipping with.
And we truely can continue this over in the dedicated topic.
Not that involved, but you are right about the hibernation not working ootb with zram.
Is that true? At some point the amount of zram possible will be dictated by the size of the ram .. and especially given ratios of compression algorithms, as well as the size of physical memory available back when compcache was created .. this would not be my guess. *
My suggestion is still zram unless you need hibernation.
But as mentioned above - given your specs it will likely matter little outside of secondary considerations like whether you use hibernation or if disk space is somehow at a premium.
EDIT
* - Found some things. https://lkml.org/lkml/2008/4/8/69 https://wiki.ubuntu.com/Compcache
It would seem that small memory - especially in cases like live environments where its possible no swap exists - was at least one consideration. But performance (compared to traditional swap) seems to be mentioned as a driving force even in the earliest mails.
Thanks for helping me learn some more today.
Involved in the term of : hibernation support with zram would need several swap spaces.
Which isn’t required if zswap is being used. As documented in the Arch Wik here.
Zram is a suitable solution for optimizing swap performance and reducing disk usage on systems with limited RAM or a focus on disk longevity. However, the potential for increased CPU overhead and limited scalability by available RAM should be considered during implementation.
