Talk:Advanced Vector Extensions
|WikiProject Computing / Software / Hardware||(Rated C-class, Low-importance)|
- 1 AVX-512
- 2 Completely rewritten
- 3 extended precision?
- 4 why does AVX look like altivec?
- 5 FMA
- 6 Power efficient, idle power usage is insignificant
- 7 AMD reaction
- 8 Compiler support
- 9 three-operand instruction for sqrt?
- 10 Windows XP and AVX
- 11 AVX the successor to SSE?
- 12 Split off AVX-512
- 13 Knights Landing out date
- 14 AVX-128
The section on AVX-512 looks like it has been copied from a news release. Maybe it should be a separate article. It needs to point out the distinction between the unnamed instruction set of Knights Corner and the AVX-512 instruction set of Knights Landing. The former uses an MVEX prefix and the latter uses an EVEX prefix. These two prefixes differ by a single bit, even for otherwise identical instructions. Therefore the two instruction sets are not mutually compatible, but both are backwards compatible with AVX2. Does anybody have info about the fate of the Knights Corner instruction set? Is it obsolete or will both lines be continued? Afog 09:48, 2 October 2013 (UTC)
I have rewritten the whole page to fix the issues discussed below and because the article had the tag:
||This article reads like a news release, or is otherwise written in a promotional tone. (March 2009)|
AES, PCLMUL and FMA are separate instruction sets which I have put into separate articles. I have added information about AMD support, operating system support and many technical details. Afog (talk) 11:50, 4 June 2009 (UTC)
I want to clarify that AVE does 4x64 bit (double precision) and 8x32 bit (single precision) but NOT 2x128 (extended precision). The docs seem to indicate this as there is nothing mentioned about 128 bit floating point numbers. Can an expert please verify this statement as it is critical to understanding AVE.
why does AVX look like altivec?
ibm calls AltiVec VMX, and actually never believed in altivec before apple and nintendo insisted on it for the Gecko and the later G5 design upgraded on the G5 to a 256bit SIMD and a 128Bit SIMD on the Gamecube and Wii. personally i think apple might have had something to do with AVX, but that's just speculation Markthemac (talk) 01:45, 9 June 2008 (UTC)
The article states that 1) the published AVX instruction set includes FMA instructions, and 2) FMA will appear in a future extension of the instruction set. There's a contradiction here, please clarify. --184.108.40.206 (talk) 20:22, 5 December 2008 (UTC)
Power efficient, idle power usage is insignificant
This is supposedly due to the new instructions? I think a link to source material is needed here or atleast a re-write, as generally I understand the term idle to imply that the processor is doing nothing! As I understand it, power usage during idle NOP instructions is a function of the power control unit within the CPU and not due to an instruction which in an Intel cpu is a microcode op or series of microcode ops.
I would suggest that the meaning here is to imply that a future CPU implementing AVE will have enhanced power control over these new instructions, shutting off unused units during AVE instuction execution. —Preceding unsigned comment added by 220.127.116.11 (talk) 00:16, 10 January 2009 (UTC)
The phrase "idle power usage is insignificant" refers to the power usage caused by leakage current of the extra transistors added to implement the AVX logic in the processor. Transistors use power even when they are not switching. All modern x86 processors shutoff idle units by gating the clock signal into the unit. When the clock signal is turned off, power consumption of the unit will be due solely to transistor leakage current. The power consumed by the AVX unit when the AVX unit is idle is an insignificant portion of the total power consumed by the processor. Typically, this would mean below 1% of total power. Ksavage9 (talk) 20:50, 20 April 2009 (UTC)
Please incorporate in article info from http://forums.amd.com/devblog/blogpost.cfm?catid=208&threadid=112934 —Preceding unsigned comment added by 18.104.22.168 (talk) 14:11, 6 May 2009 (UTC)
three-operand instruction for sqrt?
Maybe someone can explain what sqrt with 3 operands means?
vsqrtsd xmm1, xmm2, xmm3
I'm disappointed - no fast exp(), cos() etc. Unlike CUDA. Intel really has a problem. Oh, and have to get a new operating system to use the thing. Oh, really. — Preceding unsigned comment added by 22.214.171.124 (talk) 11:51, 21 July 2012 (UTC)
Windows XP and AVX
AVX the successor to SSE?
Split off AVX-512
I plan to split AVX-512 off to a separate article. The EVEX based AVX-512 has many new details and consists of several new separate extensions, so it will be better dealt with separately. This can leave this article to deal with 128/256-bit VEX encoded AVX extensions. Any comments or objections? Carewolf (talk) 20:18, 23 February 2014 (UTC)
Knights Landing out date
"Knights Landing processor scheduled to ship in 2015"
The reference provided for this sentence doesn't talk about the shipping date. I couldn't find this date yet on the Internet. — Preceding unsigned comment added by 2A00:FE00:4103:1:0:0:0:300 (talk) 08:28, 22 August 2014 (UTC)
This article states that it's safe to use AVX-128 on OSes that support only SSE and don't support AVX.
In Intel(R) Advanced Vector Extensions Programming Reference or Intel® Architecture Instruction Set Extensions Programming Reference, section "3.2: YMM STATE MANAGEMENT" it is clearly stated that
"An OS must enable its YMM state management to support AVX and FMA extensions. Otherwise, an attempt to execute an instruction in AVX or FMA extensions (including an enhanced 128-bit SIMD instructions using VEX encoding) will cause a #UD exception."
Also, according to AMD64 Architecture Programmer’s Manual Volume 6: 128-Bit and 256-Bit XOP and FMA4 Instructions even 128-bit XOP also cause #UD exception if an OS doesn't support YMM save/restore.
So I believe that the statement that "AVX-128 instructions that do not use YMM registers are also safe to use on operating systems without AVX-support, since AVX-support in operating systems refers to handling YMM register state." is totally incorrect. — Preceding unsigned comment added by 126.96.36.199 (talk) 00:46, 25 October 2015 (UTC)
P.S. it makes sense, since AVX-128 instructions clear the upper half of a destination YMM register, so even AVX-128 touches all 256 bits of YMM reg. — Preceding unsigned comment added by 188.8.131.52 (talk) 09:22, 25 October 2015 (UTC)