Resolution/solution edit:
The majority of my problems were solved w/ the known-good replacement chip sent by Kizune.
Two issues remained:
Original Post:
This is a continuation of this discussion from the Intel ES discussion thread: https://forums.servethehome.com/index.php?threads/es-xeon-discussion.5031/post-394775
Summary of findings so far:
AMX (Specifically AMX-Base and AMX-TMUL), VMX, SMX, SGX, and TME instructions should be available on SPR chips. There seems to be a divergence in these supposedly supported instructions between 3 users with similar chips and platforms
Using the same model of SPR stepping E3 EVQS chips sold by Kizune, sam55todd and Kizune were able to get the instruction showing up in hwinfo64, but I was unable to do so on my chip (It also did not show up under /proc/cpuinfo flags in linux). All of us were using supermicro boards, although sam55todd's X13DEI board was running older microcode. My X13SEM board ran with both older and newer microcode, neither of which enabled the missing instructions on my chip.
(Annotated image compilation from sam55todd)
Despite missing the flag for the AMX instructions, my chip did have the AMX-TMUL clocks fused, and they were fused identically to the ones on the chips that both sam55todd and Kizune have.
I was eventually able to get one of the 5 instructions to show up, but unlike sam55todd who had AMX showing up, I was able to get SGX enabled through the bios (which also indicated that HWINFO64 has a bug where it should display 'supported but disabled' instructions in red, but it seems to just be displaying them as greyed out (unsupported) instead). Despite also enabling TME and SMX in my bios on the latest firmware through their respective options, they still showed as unsupported. There were no visible options in my bios to enable either VMX or AMX.
Things I have tried:
* Rebooting
* Updating the bios from 1.1 to 1.4 (current latest)
* Resetting the bios settings (on both versions 1.1 and 1.4)
* Installing the chipset drivers
* Updating the OSes (Ubuntu 22.04 LTS and Windows 10 22H2)
* Enabling options in the bios (This got SGX working, but not VMX (no option enabled by default but not working), SMX (enabled but not working), TME (enabled but not working) or AMX (no option))
Things I am trying/will be trying over the next few days:
* known-working CPU from Kizune (to validate that this is not a board problem)
* making sure that the CPU is evenly mounted in the socket
* Windows 11 (If I can get it to install. For some reason during the 'preparing files for installation' step it bugs out and drops all the nvme and sata drives off of their busses. This doesn't cause the system to reboot or crash, but its impossible to continue the installation from that point. The windows 10 installer did not have this problem, and I had not observed it in normal use in either linux or windows. I haven't really had a chance to debug this prior to now since I've been busy today w/ work and other things)
The majority of my problems were solved w/ the known-good replacement chip sent by Kizune.
Two issues remained:
- The intel AMX-TMUL sample code appears to need initialization on windows 10, but there is no documentation on how to do this for windows 10 - presumably this can be reverse-engineered from the ONNX codebase which supports AMX, but exploring that was outside of the scope of merely trying to resolve the issues I was encountering. The sample code only has initialization for linux (requires kernel version 5.16 or later), and on windows 11 it just works (after removing the linux-specific initialization code) without any problems.
- Officially according to Intel, AMX is disabled in VMs. Theoretically (at least according to VMWare) using specific hypervisors (ex, ESXI 8.0u1, apparently) it is possible to get it working on guest OSes, but this doesnt seem to be officially supported by Intel.
Original Post:
This is a continuation of this discussion from the Intel ES discussion thread: https://forums.servethehome.com/index.php?threads/es-xeon-discussion.5031/post-394775
Summary of findings so far:
AMX (Specifically AMX-Base and AMX-TMUL), VMX, SMX, SGX, and TME instructions should be available on SPR chips. There seems to be a divergence in these supposedly supported instructions between 3 users with similar chips and platforms
Using the same model of SPR stepping E3 EVQS chips sold by Kizune, sam55todd and Kizune were able to get the instruction showing up in hwinfo64, but I was unable to do so on my chip (It also did not show up under /proc/cpuinfo flags in linux). All of us were using supermicro boards, although sam55todd's X13DEI board was running older microcode. My X13SEM board ran with both older and newer microcode, neither of which enabled the missing instructions on my chip.
(Annotated image compilation from sam55todd)
Despite missing the flag for the AMX instructions, my chip did have the AMX-TMUL clocks fused, and they were fused identically to the ones on the chips that both sam55todd and Kizune have.
I was eventually able to get one of the 5 instructions to show up, but unlike sam55todd who had AMX showing up, I was able to get SGX enabled through the bios (which also indicated that HWINFO64 has a bug where it should display 'supported but disabled' instructions in red, but it seems to just be displaying them as greyed out (unsupported) instead). Despite also enabling TME and SMX in my bios on the latest firmware through their respective options, they still showed as unsupported. There were no visible options in my bios to enable either VMX or AMX.
Things I have tried:
* Rebooting
* Updating the bios from 1.1 to 1.4 (current latest)
* Resetting the bios settings (on both versions 1.1 and 1.4)
* Installing the chipset drivers
* Updating the OSes (Ubuntu 22.04 LTS and Windows 10 22H2)
* Enabling options in the bios (This got SGX working, but not VMX (
Things I am trying/will be trying over the next few days:
* known-working CPU from Kizune (to validate that this is not a board problem)
* making sure that the CPU is evenly mounted in the socket
* Windows 11 (If I can get it to install. For some reason during the 'preparing files for installation' step it bugs out and drops all the nvme and sata drives off of their busses. This doesn't cause the system to reboot or crash, but its impossible to continue the installation from that point. The windows 10 installer did not have this problem, and I had not observed it in normal use in either linux or windows. I haven't really had a chance to debug this prior to now since I've been busy today w/ work and other things)
Last edited: