AMD openSIL Will Eventually Replace AGESA, Supporting Both Client & Server CPUs

[skeevy420]

agd5f

While I can't speak for others, I use the latest active LTS kernel as a fallback for the times when Linux Stable updates faster than other software that I use. It's either that or stay on an EOL kernel for an undetermined amount of time. In my case, it isn't about having support for the latest hardware, it's having support for all the latest features of my current hardware. While reverting to LTS usually works just fine, occasionally there are pretty major updates for AMDGPU making downgrading not very ideal.

In regards to the amount of work involved with a DKMS driver, honestly, I didn't consider Frankenkernels like what Ubuntu and SUSE use. I was limiting my scope to the LTS and releas kernels listed on kernel.org since Arch uses those with minimal patching. That said, I can't help but notice that all the AMDGPU DKMS stuff in ROCm and AMDGPU-Pro are both based on those patch-laden Frankenkernels from Ubuntu, SUSE, and Red Hat. That's a Catch 22 in your argument extra work argument. Not that it isn't a valid argument (and probably damn annoying to deal with), it's just in contradiction to what AMD offers.

Also, bridgman, too,

According to the latest ROCm documentation, everything is done via installing distribution specific packages and then running the scripts afterwards. AFAICT, only certain versions of Ubuntu, SUSE, and RHEL are supported since the docs point to packages for them to install to get the scripts to build the module/install ROCm. I wanted to look more in depth into it all and give a better reply but I'm running on very little sleep dealing with some family medical issues. Perhaps in a few days I'll get to looking at it all when my time frees up.

[agd5f]

agd5f

While I can't speak for others, I use the latest active LTS kernel as a fallback for the times when Linux Stable updates faster than other software that I use. It's either that or stay on an EOL kernel for an undetermined amount of time. In my case, it isn't about having support for the latest hardware, it's having support for all the latest features of my current hardware. While reverting to LTS usually works just fine, occasionally there are pretty major updates for AMDGPU making downgrading not very ideal.

In regards to the amount of work involved with a DKMS driver, honestly, I didn't consider Frankenkernels like what Ubuntu and SUSE use. I was limiting my scope to the LTS and releas kernels listed on kernel.org since Arch uses those with minimal patching. That said, I can't help but notice that all the AMDGPU DKMS stuff in ROCm and AMDGPU-Pro are both based on those patch-laden Frankenkernels from Ubuntu, SUSE, and Red Hat. That's a Catch 22 in your argument extra work argument. Not that it isn't a valid argument (and probably damn annoying to deal with), it's just in contradiction to what AMD offers.

They are actually based on an upstream kernel new enough that it covers all of the "LTS" kernels we want to support. You can see our full DKMS source here for our last release here:

https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-5.4

It's based on an upstream kernel (currently 6.1), plus all of our latest driver code, plus what we call our KCL (Kernel Compatibility Layer). KCL uses autoconf to look at the symbols in the kernel you are building against and then sets the appropriate defines in the header so that the proper code gets enabled on the kernel you are building against.

[intelfx]

The interaction between the kernel's time stamp counter (TSC) and the firmware is not there. In some workloads, this results in the kernel not being able to decide the best power management due to lack of information.

e.g. on my parents HTPC running DRM encrypted CPU decoded HTML5 content this results in 80% C1 state with a Ryzen CPU, where as on Intel platforms it's already reaching C8 for most of the load.

If the scheduler had more information from an to-be-implemented AMD specific TSC, it'd be able to achieve C6 during certain workloads more.

What exactly is the "interaction between the kernel's TSC and the firmware"? Especially considering the fact that the TSC is a hardware feature, not kernel's feature

Anyway, even if what you say is somehow true (after correcting the terminology), the fact remains that package C6 residence time with Zen CPUs is non-zero on Linux. Thus, your original statement is wrong anyway.

[catpig]

It has worked for 40+ years.

🐟 It has? Then those memories I have of undocumented default BIOS passwords in the 90s must be false. As must the mountains of exploits. As must issues like Asus boards melting Ryzen 7000X3D CPUs. 🐟

[avis]

🐟 It has? Then those memories I have of undocumented default BIOS passwords in the 90s must be false. As must the mountains of exploits. As must issues like Asus boards melting Ryzen 7000X3D CPUs. 🐟

• Default BIOS passwords did not result in fried CPUs or motherboards.
• Melting Ryzen CPUs (and motherboards last time I checked) are a result of f*cked up AGESA and incomplete AMD guidelines which allowed motherboard vendors to enable unsafe voltages (don't remember which ones).

Both have nothing to do with the issue at hand.

Have a nice day!

[catpig]

• Default BIOS passwords did not result in fried CPUs or motherboards.
• Melting Ryzen CPUs (and motherboards last time I checked) are a result of f*cked up AGESA and incomplete AMD guidelines which allowed motherboard vendors to enable unsafe voltages (don't remember which ones).

Both have nothing to do with the issue at hand.

Have a nice day!

Might wanna take a course in "reading comprehension". Nobody said default passwords resulted in fried chips. They are, however, a security issue. But have fun trolling my friend ^^

[avis]

Might wanna take a course in "reading comprehension". Nobody said default passwords resulted in fried chips. They are, however, a security issue. But have fun trolling my friend ^^

Start with yourself, please. I said opening (as open source) this kind of firmware may result in attacks leading to physicically destroyed PC components. You replied with something utterly and completely unrelated. I tried to steer the conversation back to my original comment, now you tell me I have reading comprehension problems.

Sorry but I'll just walk away. I'm fucking tired of inane arguments here on Phoronix.

Have a nice day.

[catpig]

Start with yourself, please. I said opening (as open source) this kind of firmware may result in attacks leading to physicically destroyed PC components. You replied with something utterly and completely unrelated. I tried to steer the conversation back to my original comment, now you tell me I have reading comprehension problems.

You said security by obscurity works. I demonstrated that you're wrong, before I realised what you're here for. You reply with a preposterous straw man. And as if you are gonna walk away, you obviously enjoy trolling here ^^
Anyway: 🐟