11 ms·
Zen4 has been widely rumored* to support AVX-512. Did AMD confirm or refute the rumor in this press release? Is it perhaps only available on one of the two co
by brandmeyer 5y ago
Zen4 has been widely rumored* to support AVX-512. Did AMD confirm or refute the rumor in this press release? Is it perhaps only available on one of the two core types?
* through a data leak at Gigabyte
- rbanffy 5y agoIs Intel planning to release future CPUs with AVX-512? Didn't they remove it from Adler Lake?
- opencl 5y agoIt's still there in the server chips, they just removed it from consumer parts. It's actually there in Alder Lake's performance cores and can be used on at least some motherboards if the efficiency cores are disabled.
- halz 5y agoDisabling the E-cores apparently activates AVX-512. So it was planned and engineered to be there all along, but was disabled to match the marketing talking points. [https://www.phoronix.com/vr.php?view=30664 https://www.phoronix.com/vr.php?view=30664]
- mastax 5y agoI expect it was disabled so that the P&E cores have the same ISA support and threads can be moved freely between them. A large portion of people, especially at launch, would be running on a scheduler which isn't optimized for ADL which would be a disaster. Also complicated to market and explain: "supports AVX512 but only on windows 11." This way they don't have to characterize the AVX512 units and it makes binning easier. A shame because the ADL AVX512 units are much more efficient.
- rbanffy 5y ago> P&E cores have the same ISA support and threads can be moved freely between them. Wouldn't an illegal instruction fault suffice to flag a thread running on a mismatched core and allow it to be moved to a suitable one? Or do they lose state when the fault occurs?
- mastax 5y agoPeople are going to be running existing software (Windows 10 and Linux) which do not have support for Alder Lake. These schedulers don't know to handle the SIGILL. What you'd get instead is applications randomly crashing as their threads migrate to the E-cores. I'm sure they'll get there eventually, but they probably just didn't have enough time.
- rbanffy 5y agoNo existing scheduler does that, but it wouldn't be impossible to implement one that does.
- wmf 5y agoMaybe OSes could do that but they don't today.
- rbanffy 5y agoAt the moment they also don't differentiate between fast and slow cores either. It's interesting to route processes that need to be more responsive to the faster cores and dedicate the slower ones to more lag-tolerant things, a bit how mainframes route IO tasks to specialized processors or macOS routes system threads to the efficient cores, leaving the good ones to the user.
- jdsully 5y agoThey would also need to know which specific instructions are really invalid and which just don’t exist on this specific core. X86 doesn’t make that easy.
- gpderetta 5y agoBut the OS should be able to handle it by masking out the feature bits in cpuid (and/or preventing threads using AVX512 from being migrated to the E cores). Yes, you need OS support, but then again, you need support for the ThreadDirector anyway.
- rbanffy 5y agoWouldn't this break a lot of kernel-level code? OTOH, this could allow us to have very heterogeneous processors in a single system, each with an ISA tailored to a kind of task and the OS knowing which core can run which program.
- brandmeyer 5y agoDespite years of talk about heterogeneous computing, I don't think there are any production kernels for any general-purpose operating system that are instruction-set-feature aware. Linux and Windows both have partitioned schedulers, available through per-process and per-thread affinity masks. So it doesn't seem like it should be all that hard to implement. Its "just" a matter of expressing the process's (thread's?) requirements.
- IanCutress 5y agoTo clarify here, it requires both the E-cores disabled and a specific option enabled in the BIOS. The option was removed from the Intel firmware provided to vendors, but all the motherboard vendors found what bit to flip to get it to work. MSI played safe and initial BIOSes didn't have the option, the rest put it in there from launch. MSI are now releasing BIOSes with the AVX-512 option. Beyond that, AVX-512 is not POR. It's not validated, checked for IEEE accuracy, and YMMV on whether it works at what frequency with the correct outputs. Source: AnandTech.... where I wrote about it :)
- merb 5y ago> Source: AnandTech.... where I wrote about it :) if you wrote it, it I wouldn't count it as a source /s isn't that than a bit risky to put something into the bios which might disable intels advances? and especially if not even intel tested it correctly? I mean as a consumer what would happen if I enable it and something breaks?
- mhh__ 5y agoI think they said it was gone so they could keep the software simpler i.e. switching a process from a big to little core could require a fair amount of logic if they have completely different instruction sets. It's also possible it's buggy.
- rbanffy 5y agoIf they had completely different instruction sets, this wouldn't be feasible. The OS would need to be aware of that and move tasks between cores with a compatible ISA. A possible workaround would be to use the invalid instruction fault to look for a core that implements that instruction. That, however, wouldn't work if they were completely different, as in a couple GreenArray cores and a couple x86 ones.
- phkahler 5y ago>> Zen4 has been widely rumored* to support AVX-512. I've been hoping AVX-512 goes away. Intel doesn't even seem to be embracing it very well, probably due to the huge increase in power consumption. I look forward to RISC-V Vectors, which allow scaling the hardware without changing the instruction set.
- yxhuvud 5y agoThe increased instruction set included in AVX-512 would hopefully stay though, even if the 512 wide processing unit goes away.
- phkahler 5y agoTo keep the instructions also means keeping the extra wide registers. Not sure how big a deal that is. I suspect the wider vector registers aren't such a big deal but there are also twice as many of them. The old AMD strategy of running a 4-element vector through 2 units of half size (or sequentially through one unit of half size) could work but the increased register set is still a burden to some extent.
- kimixa 5y agoMy understanding is that for general purpose registers, register renaming and other hazard-avoiding optimisations means that the register file is significantly larger than the total of (register width * number of registers). Do the SIMD units have similar register duplications? If so, reducing the duplication count would do pretty much that (Reducing the area at the cost of lower performance). Even if not, the large general purpose register duplication count likely means that the SIMD registers are actually a lower proportion of the register file on chip than the register width would imply, making it less of a saving. But generally I agree, I'm much more interested in the extra instruction vocabulary and things like masking lanes than the increased register width. I also wonder at what point the cut off of when a use case would be worth pushing to a more dedicated accelerator (like a dsp or gpu).
- ac29 5y ago