Talk:Ryzen

CFLAGS
As of now using -march=znver1 doesn't seem like the best choice: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80313


 * I will look into it. Thank you. --Maffblaster (talk) 19:08, 13 April 2017 (UTC)


 * After collaborating with another Gentoo developer, it looks like  was causing him segfaults. I changed it to the previously supported -march value. --Maffblaster (talk) 23:58, 9 May 2017 (UTC)


 * According to this forum discussion  should be either ,   or.
 * Using  is not a good option as pointed out in this Phoronix article, simply because Bulldozer's instruction set extension FMA4/XOP is no longer available on the Zen architecture.
 * Code built for  through   might or might not work on Zen, depending on the actual instructions included during compilation. This is automatic and no one can say for sure what the compiler descides to use and not to use.
 * My recommendation is to use a lower subset of instructions to build GCC 6 (I used  without issues, Ryzen 7 1800X) and then use   with GCC 6 set as the system GCC version (I removed GCC 5.4 completely). The caveat is that some packages need the   ACCEPT_KEYWORDS flag set, because not all stable   ebuilds include a GCC6 patch (yet).
 * Anyway, I just put that information into Safe CFLAGS, which now shows contradictory information to this article. One should be changed to equalize the information and remove the contradiction.
 * Luttztfz (talk) 23:05, 15 May 2017 (UTC)


 * , Thanks for putting this discussion point together. I have been discussion with other Gentoo developers, but haven't received back much information from them (yet). I have been using  on my system with GCC and have experienced no issues whatsoever. I would actually be okay with transcluding the information from the Safe CFLAGS article to this article. I'll check into that. Thanks again for your efforts! Feel free to edit more around the wiki; my workload is high right now and it's hard for me to keep up. :) --Maffblaster (talk) 00:37, 16 May 2017 (UTC)


 * Might also be worth adding a note that Ryzen users really should be using at least gcc 6.3? Or maybe if using  users should then add further switches that disable FMA4/XOP. Is this possible? --Zucca (talk) 09:27, 16 May 2017 (UTC)


 * Yes,  and   will disable the use of these specific instruction set extensions. According to GCC x86 options one more difference between   and   is the LWP extension. Thus   may also be a good idea.
 * I hope that these  options will cancel the standard options of.
 * The result would be:  for Zen on GCC 5.4. As I currently use GCC 6, I cannot test this right away, but I plan to do so in a couple of days. Luttztfz (talk) 20:17, 16 May 2017 (UTC)


 * I also found this PDF that states (on PDF page 12) that Zen lacks not only the FMA4 and XOP, but also the TBM instruction extension. In the Wikipedia article XOP instruction set (section History, last paragraph) it states exactly the same, that Zen lacks Piledrivers FMA4, TBM, XOP and LWP.
 * I changed the recommended CFLAGS in Safe CFLAGS and this article accordingly. Luttztfz (talk) 17:15, 17 May 2017 (UTC)



Yup, this can be shown via GCC echo | gcc -### -E - -march=native | grep -i lwp Using built-in specs.

COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/7.1.0/gcc Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.1.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.1.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.1.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.1.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include/g++-v7 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.1.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 7.1.0-r1 p1.1' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --disable-default-pie --enable-default-ssp Thread model: posix gcc version 7.1.0 (Gentoo 7.1.0-r1 p1.1) COLLECT_GCC_OPTIONS='-E' '-march=native'

/usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1 -E -quiet - "-march=znver1" -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mmwaitx -mclzero -mno-pku -mno-rdpid --param "l1-cache-size=32" --param "l1-cache-line-size=64" --param "l2-cache-size=512" "-mtune=znver1" COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/bin/

LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-E' '-march=native'

--Naib (talk) 18:29, 17 May 2017 (UTC)

CPUFreq schedutil
Looks like from at least kernel 5.18.3 it's not possible to set 'ondemand' by default. Seems recommendation should be 'schedutil'. If somebody else can confirm this.. --Jms (talk) 16:53, 11 June 2022 (UTC)


 * Yes. I also use schedutil and that works best for the AMD P-State or the ACPI driver, in my opinion. --Maffblaster (talk) 06:00, 9 July 2022 (UTC)

AMD Processor P-State driver
seems to be a new (at least from 5.18) option in kernelː AMD Processor P-State driver (X86_AMD_PSTATE) --Jms (talk) 16:58, 11 June 2022 (UTC)


 * I looked at my .config files and found it in 5.17 too, but not in earlier verions. Luttztfz (talk) 05:54, 9 July 2022 (UTC)

The AMD P-State driver is now mentioned with this change: Special:Diff/1072124/1076468. Hope it helps! --Maffblaster (talk) 06:16, 9 July 2022 (UTC)

lm_sensors
Variable from motherboard to motherboard. I didn't edit the page for that but in my case:

As of Linux 5.18, several options for Asus Mobo seems available, maybe the section has to be revised.

--Admnd (talk) 11:18, 04 July 2022 (UTC)


 * Please update the article (add a new sensors section if necessary) if you find information that is missing or out of date. No need to discuss this kind of a change here as it is useful information to anyone wanting sensors support for their motherboard. Thank you! --Maffblaster (talk) 21:53, 2 August 2022 (UTC)

Old GCC versions
GCC 8.x and 9.x are now hardmasked and all older GCC releases have been removed from the main portage tree a long time ago as of 2022-11-08. I would remove those outdated GCC sections and add something for GCC 11 & 12 (or even 13 which starts to support Zen 4) or would it make sense to keep it for a reason or another? (e.g. historical purposes). --Admnd (talk) 23:20, 8 November 2022 (UTC)


 * I personally cannot think of any reason, because a "historical" Gentoo doesn't exist anyhow. The only thing that IMHO might be of interest would a table showing the earliest GCC versions that introduced znver1, znver2, znver3... Luttztfz (talk) 17:56, 11 November 2022 (UTC)

I would agree. At minimum, support for when each compiler optimization flag was added to GCC is useful for our community reference. I'd also be OK with merging this information into a table or something. Thanks! --Maffblaster (talk) 00:04, 26 November 2022 (UTC)