[gentoo-user] Build for Athlon and Ryzen architectures

[gentoo-user] Build for Athlon and Ryzen architectures

[ralfconn]

Hello,

my 8-year old gentoo HTPC is giving clear signals that the motherboard 
is about to die so I ordered new components.

The dying box is an AMD FX-6530 built with -march=native. The new box 
will be Ryzen 7 5800X.

I'd like to rebuild the dying boxwith some more generic -march option so 
that I'll be able to boot into the new box and then rebuild it with more 
optimized -march.

If I understand well the GCC man page the safest option for the dying 
system rebuild would be -march=x86_64 (and maybe -mtune=generic?). Is 
this right?

thanks,

raffaele

Re: [gentoo-user] Build for Athlon and Ryzen architectures

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1123 bytes --]

On 8/20/24 1:23 PM, ralfconn wrote:
> Hello,
> 
> my 8-year old gentoo HTPC is giving clear signals that the motherboard
> is about to die so I ordered new components.
> 
> The dying box is an AMD FX-6530 built with -march=native. The new box
> will be Ryzen 7 5800X.
> 
> I'd like to rebuild the dying boxwith some more generic -march option so
> that I'll be able to boot into the new box and then rebuild it with more
> optimized -march.
> 
> If I understand well the GCC man page the safest option for the dying
> system rebuild would be -march=x86_64 (and maybe -mtune=generic?). Is
> this right?


The other safe option is to run `ld.so --help` and check for this:

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)



Your new CPU should support -march=x86-64-v3 but perhaps the old one
doesn't.

If you plan to recompile all packages with -march=native immediately
after you swap anyway, then it doesn't really matter, just use "x86-64"
for maximum compatibility.


-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Build for Athlon and Ryzen architectures

[byte.size226]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]


On 20/08/2024 18:38, Eli Schwartz wrote:
> Your new CPU should support -march=x86-64-v3 but perhaps the old one
> doesn't.
> 
> If you plan to recompile all packages with -march=native immediately
> after you swap anyway, then it doesn't really matter, just use "x86-64"
> for maximum compatibility.

Agreed with this recommendation. Last year I migrated from a dying Intel 
6th gen to a Ryzen 7000 series and went with, IIRC, the most generic 
-march=x86-64 without -mtune.

To save some compile time and electricity I only recompiled @system. 
After migrating the drive to the new system I updated -march accordingly 
and recompiled @system again (just in case, perhaps unnecessarily) 
before ultimately running a full "--emptytree @world" recompile with 
some exceptions from @system. If recompile time and/or energy is not a 
factor, it's probably safer to go with @world in both cases and not bother.

Somebody also suggested then to install "gentoo-kernel-bin" before the 

migration in case there's any compatibility changes and your current 
kernel doesn't boot on the new system.

Ironically, in my case I did have issues with a black screen with my 
kernel, but the gentoo-kernel-bin panic'd straight away. Turns out my 
issue was graphics related and adding "nomodeset" got the screen going 
and I resolved the problem shortly after. So YMMV, but probably doesn't 
hurt to have it as a back up.

Good luck!

- Victor

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [gentoo-user] Build for Athlon and Ryzen architectures

[Dale]

ralfconn wrote:
> Hello,
>
> my 8-year old gentoo HTPC is giving clear signals that the motherboard
> is about to die so I ordered new components.
>
> The dying box is an AMD FX-6530 built with -march=native. The new box
> will be Ryzen 7 5800X.
>
> I'd like to rebuild the dying boxwith some more generic -march option
> so that I'll be able to boot into the new box and then rebuild it with
> more optimized -march.
>
> If I understand well the GCC man page the safest option for the dying
> system rebuild would be -march=x86_64 (and maybe -mtune=generic?). Is
> this right?
>
> thanks,
>
> raffaele
>
>
> .
>


If you are in no hurry for the new system to be available once built,
I'd consider this way.  Leave current system as is.  If you start
compiling, it could die while compiling depending on what the problem
is.  I'd assemble the new system, test from some boot media, make sure
memory, CPU and all that works.  In other words, not dead out of the
box.  Then install the hard drive OS from the old system.  Boot the boot
media, mount and chroot into the old install.  Make the needed changes
in make.conf, don't forget CPU flags if set, and start a emerge -e
world.  One advantage of compiling on newer rig, it is faster than the
old rig.  Another advantage, you only need to do it once. 

While you are doing the emerge world, you can be in another console
working on any needed kernel config changes, compiling, installing and
configuring boot loader.  Don't forget lspci -k from the boot media. 

There is a number of good ways to go about this.  There's nothing wrong
with what others mentioned either.  This is just yet one other option. 
If your old rig for example is having CPU, memory or heat issues, saving
the compile for the new rig is also safer. 

Oh, compiling on the new rig will also give the CPU thermal paste time
to set in good.  Lots of short heat and cool cycles with some longer
cycles as well.  That's important if you assemble it yourself.  My new
rig is finally settling in.  My temps max out at 190F.  Compared to your
old CPU temp, that is about 110F.  Yep, these new things run hotter.  I
don't see any way to get that 190 down to even 160F.  Yet. 

Hope that gives you another option to consider.  Depending on the reason
for old system having problems, may be really helpful. 

Dale

:-)  :-)

Re: [gentoo-user] Build for Athlon and Ryzen architectures

[ralfconn]

Il 20/08/24 19:38, Eli Schwartz ha scritto:
 > On 8/20/24 1:23 PM, ralfconn wrote:
 >> my 8-year old gentoo HTPC is giving clear signals that the motherboard
 >> is about to die so I ordered new components.
 >>
 >> The dying box is an AMD FX-6530 built with -march=native. The new box
 >> will be Ryzen 7 5800X.
 > The other safe option is to run `ld.so --help` and check for this:
 >
 > Subdirectories of glibc-hwcaps directories, in priority order:
 >    x86-64-v4
 >    x86-64-v3 (supported, searched)
 >    x86-64-v2 (supported, searched)
 >
 >
 > Your new CPU should support -march=x86-64-v3 but perhaps the old one
 > doesn't.
 >
 > If you plan to recompile all packages with -march=native immediately
 > after you swap anyway, then it doesn't really matter, just use "x86-64"
 > for maximum compatibility.

The command on the old rig outputs:

   x86-64-v4
   x86-64-v3
   x86-64-v2 (supported, searched)

while on another box with a Ryzen 9 5900x it output the same as your 
example (-v3 and -v2 supported).

I did not know about this 'Microarchitecture level' definition [1], 
thanks. I'd expect the -v3 to be a superset of the -v2, instead when in 
the past I tried to boot a Ryzen 9 from a system built with 
-march=native for an FX 8530 it did not work (I don't remember if it was 
a kernel panic or if it stopped already at GRUB, I think the latter), so 
I had to reinstall from stage 3.

raffaele

[1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

Re: [gentoo-user] Build for Athlon and Ryzen architectures

[ralfconn]

Il 20/08/24 22:42, Dale ha scritto:
> If you are in no hurry for the new system to be available once built,
> I'd consider this way.  Leave current system as is.  If you start
> compiling, it could die while compiling depending on what the problem
> is.  I'd assemble the new system, test from some boot media, make sure
> memory, CPU and all that works.  In other words, not dead out of the
> box.  Then install the hard drive OS from the old system.  Boot the boot
> media, mount and chroot into the old install.  Make the needed changes
As mentioned in another post I tried a similar route in the past (not 
chroot but directly boot from the old install) and it did not work. At 
the time I assumed the instruction sets were different between the 
Athlon and the Ryzen and gave up, reinstalling the new rig from stage 3. 
I'm not so convinced that was the problem, but this subject is far too 
complex given the time I can invest on it.
> in make.conf, don't forget CPU flags if set, and start a emerge -e
> world.  One advantage of compiling on newer rig, it is faster than the
> old rig.  Another advantage, you only need to do it once.
>

Re: [gentoo-user] Build for Athlon and Ryzen architectures

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1257 bytes --]

On 8/21/24 12:34 AM, ralfconn wrote:
> I did not know about this 'Microarchitecture level' definition [1],
> thanks. I'd expect the -v3 to be a superset of the -v2, instead when in
> the past I tried to boot a Ryzen 9 from a system built with
> -march=native for an FX 8530 it did not work (I don't remember if it was
> a kernel panic or if it stopped already at GRUB, I think the latter), so
> I had to reinstall from stage 3.
> 
> raffaele
> 
> [1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels


Yup, that is the great advantage of these microarchitecture "common
levels". Unlike -march=native which just toggles every single tiny
option your current CPU supports, these are strictly defined supersets
designed to work with, basically, "any CPU produced after a certain
date". It makes it much easier to deliver common optimizations to a mere
3 distinct configurations. Also it makes it much easier to rapidly tell
which group your current CPU supports.



Gentoo's official binhost uses these too. Well, the binhost provides a
regular generic -march=x86-64 set of binary packages, plus a set that
targets the -march=x86-64-v3 seriesdsfe. No "v2" or "v4" packages there,
I'm afraid. :)


-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]