Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

detect AVX-512 FMA count #125

Merged
merged 12 commits into from
Sep 22, 2020
Merged

detect AVX-512 FMA count #125

merged 12 commits into from
Sep 22, 2020

Conversation

jeffhammond
Copy link
Contributor

This change adds support for a virtual CPUID bit called "secondFMA", which indicates whether an Intel Xeon processor has a second FMA unit. This detection is based upon the processor name, which is the best known method. It should be correct for all documented SKUs as well as most other instances, although it is impossible for me to verify on all of them, although we have a bit of experience testing SKUs already in the BLIS project.

jeffhammond and others added 8 commits June 25, 2020 17:38
The information contained in this commit was obtained from
"Intel® Architecture Instruction Set Extensions and Future Features Programming Reference" document 319433-040 from
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Signed-off-by: Jeff Hammond <jeff.r.hammond@intel.com>
Signed-off-by: Hammond, Jeff R <jeff.r.hammond@intel.com>
Signed-off-by: Hammond, Jeff R <jeff.r.hammond@intel.com>
Signed-off-by: Jeff Hammond <jeff.r.hammond@intel.com>
Signed-off-by: Hammond, Jeff R <jeff.r.hammond@intel.com>
1) remove debug stuff
2) remove ICX - will add details when available

Signed-off-by: Hammond, Jeff R <jeff.r.hammond@intel.com>
Signed-off-by: Hammond, Jeff R <jeff.r.hammond@intel.com>
@gchatelet
Copy link
Collaborator

@jeffhammond Can I ask you to resolve the conflicts?

@jeffhammond
Copy link
Contributor Author

Yeah, they should be resolved now. Git struggles with the diamond dependency...

Copy link
Collaborator

@gchatelet gchatelet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thx a lot @jeffhammond for the PRs. I really appreciate it.

src/cpuinfo_x86.c Show resolved Hide resolved
src/cpuinfo_x86.c Outdated Show resolved Hide resolved
src/cpuinfo_x86.c Outdated Show resolved Hide resolved
char proc_name[49] = {0};
FillX86BrandString(proc_name);
// detect Xeon
if (proc_name[9]=='X') {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is testing individual character the official way? It feels like upcoming names could match and trigger false positives.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of this code is within the model==0x55 conditional so it is not vulnerable to future branding changes unless they were based on the Skylake Server microarchitecture, which seems exceedingly unlikely.

In C++ implementations of this code, I do substring matching but in the C versions I just test single characters since I believe I have complete knowledge of the relevant processor names (including off-roadmap ones), in which case it should be sufficient.

Would you prefer I test multiple characters directly (test for 'X', 'e', 'o', 'n' not just 'X'), use strncmp, or use strstr? I generally avoid the latter since it doesn't have an n version.

Hammond, Jeff R added 3 commits September 21, 2020 10:47
Signed-off-by: Hammond, Jeff R <jeff.r.hammond@intel.com>
Signed-off-by: Hammond, Jeff R <jeff.r.hammond@intel.com>
Signed-off-by: Hammond, Jeff R <jeff.r.hammond@intel.com>
Copy link
Collaborator

@gchatelet gchatelet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah sorry about the "larger scale change", I'll try to add a check so people can only submit well formatted patches in the future.
Thank you for bearing with me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants