This is a major change in the SoC detection methodology.
Previous to this commit, the SoC (model, vendor and manufacturing
process) would only appear if the exact model was found in the LUT.
In other words, every supported SoC must be added manually to the LUT.
This would allow to show the precise SoC model and the manufacturing
process, which can only be hardcoded (i.e., it cannot be dynamically
determined).
This commit introduces guess_raw_soc_from_devtree, a new way of
inferring the SoC. This simply reads from the compatible file in the
device tree and tries to find a matching vendor to that string. If
there is a match, then we simply copy the model also from the
compatible string and show it directly.
This new implementation will show a less "precise" SoC name and
no manufacturing process because there would be no hardcoded value for
that SoC. However, it improves the scalability of the SoC detection
significantly because there is no longer a need to hardcode every
single SoC.
Lastly, there are some SoC vendors intentionally left outside the
scope of this function: For now I prefer to keep updating manually
the LUT for those to ensure the highest quality detection (e.g.,
showing precise SoC name and manufacturing process).
Overview of changes:
- Adds field max_pp in frequency struct to hold the max freq for peak-performance estimation.
- Instead of getting the max frequency in get_peak_performance, we get it in get_cpu_info (more natural).
- Adds fill_frequency_info_pp which fills the max_pp of the passed cpu by calling measure_frequency.
The approach is to call measure_frequency with a vector where the max frequencies are stored. Then,
the first time measure_frequency is called, the frequency is measured while running all the cores,
and the max frequency is computed per module (e.g., in the case of 2 modules, we would compute
the freq for the first and for the second module), and saved into this vector. Subsequent calls to
measure_frequency will just read the corresponding value for the vector. In other words, the frequency
is only measured once for the whole CPU.
There are cases where measure_frequency is called after binding the
process to a specific core via bind_to_cpu (e.g., when iterating over
modules in hybrid architectures). Thus, in measure_frequency we must
set the affinity of the newly created threads, ensuring they are
binded to the right core.
* Add Intel and AMD 486, Intel Pentium Pro, and AMD K5 chips
* Update infer_cpu_name_from_uarch to support added CPU uarches
* Add sources for more of the legacy chip data
* Add the more specific codename for Intel Pentium MMX Mobile chips
* Document source of AMD 486/K5 variants
* Add link to documentation for Intel 486
---------
Co-authored-by: Timothy Warren <[email protected]>
Dr-Noob