Thoughts on "8 Core" Bulldozer and "4 Core Sandy Bridge"

[xd_1771]

The thing about AMD's GPU "cores" is that they work & are counted completely differently from nVidia's GPU "cores". Even if they were the same thing, AMD would provide the same performance for the same TDP. The same is the case for SB vs BD, because AMD redefined CPU "cores" with BD by using chip-multi-threading and shared resources.

 

[Nemesis 1]

From IDC link another link to AMDs fma4.

AMD has changed the encoding from the original SSE5 specification in order to improve compatibility with Intel's AVX instruction set and the new VEX coding scheme.

All SSE5 instructions that were equivalent or similar to instructions in the AVX and FMA4 instruction sets announced by Intel have been changed to use the coding proposed by Intel. Integer instructions without equivalents in AVX were classified as the XOP extension.[3] The XOP instructions have an Opcode byte 8F (hexadecimal), but otherwise almost identical coding scheme as AVX with the 3-byte VEX prefix.

Commentators[4] have seen this as evidence that Intel has not allowed AMD to use any part of the large VEX coding space. AMD has been forced to use different codes in order to avoid using any code combination that Intel might possibly be using in their development pipeline for something else. The XOP coding scheme is as close to the VEX scheme as technically possible without risking that the AMD codes overlap with any future Intel codes. It must be noted that this inference is speculative, since no public information is available about negotiations between the two companies on this issue.

The use of the 8F byte requires that the m-bits (see VEX coding scheme) have a value bigger than or equal to 8 in order to avoid overlap with existing instructions. The C4 byte used in the VEX scheme has no such restriction. This may prevent the use of the m-bits for other purposes in the future in the XOP scheme, but not in the VEX scheme. Another possible problem is that the pp bits have the value 00 in the XOP scheme, while they have the value 01 in the VEX scheme for instructions that have no legacy equivalent. This may complicate the use of the pp bits for other purposes in the future.

A similar compatibility issue is the difference between the FMA3 and FMA4 instruction sets. INTEL initially proposed FMA4 in AVX/FMA specification version 3 to supersede the 3-operand FMA proposed by AMD in SSE5. After AMD adopted FMA4, however, Intel canceled FMA4 support and reverted back to FMA3 in the AVX/FMA specification version 5

 

[Nemesis 1]

I was/am under the impression that AMD's proposed FMA4 solution is superior to that of Intel's FMA3.

http://en.wikipedia.org/wiki/FMA_instruction_set

No were does it say superior Only alittle more flexable but intel covered that with VEC


How you got superior out of this I don't know.

The 4-operand form (FMA4) allows a, b, c and d to be four different registers, while the 3-operand form (FMA3) requires that d is the same register as either a, b or c. The 3-operand form makes the code shorter and the hardware implementation slightly simpler while the 4-operand form provides more programming flexibility.

 

[Mopetar]

No were does it say superior Only alittle more flexable but intel covered that with VEC


How you got superior out of this I don't know.

The 4-operand form (FMA4) allows a, b, c and d to be four different registers, while the 3-operand form (FMA3) requires that d is the same register as either a, b or c. The 3-operand form makes the code shorter and the hardware implementation slightly simpler while the 4-operand form provides more programming flexibility.

Honestly, depending on your point of view, you could easily claim either method is superior. FMA3 has a simpler hardware implementation which can result in a more elegant CPU design. FMA4 allows developers to be more flexible with their program code, making things easier for them.

 

[Nemesis 1]

Yes I understand that But from some reason and I believe its in an article here before SB was released that Intel if the use FMA 3 it would have a spare register the same with FMA4 it will have 5 registers . What these extra registers were for wasn't talked about as I recall.

Again I will repaste this part . again so you can more clearly see AMDs problem with FMA 4


AMD has changed the encoding from the original SSE5 specification in order to improve compatibility with Intel's AVX instruction set and the new VEX coding scheme.

All SSE5 instructions that were equivalent or similar to instructions in the AVX and FMA4 instruction sets announced by Intel have been changed to use the coding proposed by Intel. Integer instructions without equivalents in AVX were classified as the XOP extension.[3] The XOP instructions have an Opcode byte 8F (hexadecimal), but otherwise almost identical coding scheme as AVX with the 3-byte VEX prefix.

Commentators[4] have seen this as evidence that Intel has not allowed AMD to use any part of the large VEX coding space. AMD has been forced to use different codes in order to avoid using any code combination that Intel might possibly be using in their development pipeline for something else. The XOP coding scheme is as close to the VEX scheme as technically possible without risking that the AMD codes overlap with any future Intel codes. It must be noted that this inference is speculative, since no public information is available about negotiations between the two companies on this issue.

The use of the 8F byte requires that the m-bits (see VEX coding scheme) have a value bigger than or equal to 8 in order to avoid overlap with existing instructions. The C4 byte used in the VEX scheme has no such restriction. This may prevent the use of the m-bits for other purposes in the future in the XOP scheme, but not in the VEX scheme. Another possible problem is that the pp bits have the value 00 in the XOP scheme, while they have the value 01 in the VEX scheme for instructions that have no legacy equivalent. This may complicate the use of the pp bits for other purposes in the future.

A similar compatibility issue is the difference between the FMA3 and FMA4 instruction sets. INTEL initially proposed FMA4 in AVX/FMA specification version 3 to supersede the 3-operand FMA proposed by AMD in SSE5. After AMD adopted FMA4, however, Intel canceled FMA4 support and reverted back to FMA3 in the AVX/FMA specification version 5

Intel in its white paper on AVx stated that Vec prefix is an intel exclusive they won't let AMD use it Until such a time they want to let AMD use . Its not even on the board for discussion or negotiations
Intels approach with cpu first for AVX/CL is along these lines and I agree. Another repaste

If you think that's radical, please realise that the rules for writing high performance software have already changed dramatically when we went multi-core. So you might as well finish what you started and add scatter/gather support or the CPU will keep losing terrain to the GPU. You're nearing the point where people just buy the cheapest CPU available and rather invest in a more powerful GPU to do the 'real work'. The competition (both AMD and NVIDIA) are in rather sweet spots to take the biggest pieces of the pie in this scenario. So you'd better give people good reasons to keep buying the latest CPUs, by adding instructions to support algorithms that would otherwise run more optimally outside of the CPU. The only reason I care is because I believe it's better for the end user


__________________

 

[LOL_Wut_Axel]

So you are saying that an 8 core, 8 thread BD CPU will beat a 6 core, 12 thread SB-E CPU in multithreaded apps...while you claim the SB will be faster in single threaded apps? I do not follow your logic there.

I also do not agree with your assessment of BD floating point performance. I think this is where BD will shine. Especially when apps are compiled to take advantage of the new instructions like FMA. I have been considering getting a BD for my number crunching server (until Haswell of course).

Whether it beats it or not is irrelevant. Bulldozer does not compete with Sandy Bridge-E, but rather Sandy Bridge. Bulldozer is a Performance CPU and platform, just like Sandy Bridge. Sandy Bridge-E is an Enthusiast CPU and platform.

People seriously need to bring up Sandy Bridge-E in these discussions. It will be much more expensive overall.

 

[Nemesis 1]

If it offers the performance who cares . Your tieing everthing to price LOL. Ya lets not bring SB-E into this subject because its an enthusiast cpu platiform . Actually its a server platform that has enthusiast M/Bs But it is SB none the less It has no IGP just as BD a server chip has no APU . Nobody on this forum is stopping anyone from buying whatever they want . But telling people the SB-E is out of the discussion is childish.

 

[LOL_Wut_Axel]

If it offers the performance who cares . Your tieing everthing to price LOL. Ya lets not bring SB-E into this subject because its an enthusiast cpu platiform . Actually its a server platform that has enthusiast M/Bs But it is SB none the less It has no IGP just as BD a server chip has no APU . Nobody on this forum is stopping anyone from buying whatever they want . But telling people the SB-E is out of the discussion is childish.

Why would you compare things that don't compete with each other? How is it childish to say that it's not realistic to compare a $100+ motherboard platform to a $200+ motherboard platform and a $300 CPU to a $500 CPU?

 

[Nemesis 1]

You win I can't argue with your logic, Even tho the 4 core SB-e is priced in the $300 dollar range on a superior M/B

 

[LOL_Wut_Axel]

The thing about AMD's GPU "cores" is that they work & are counted completely differently from nVidia's GPU "cores". Even if they were the same thing, AMD would provide the same performance for the same TDP. The same is the case for SB vs BD, because AMD redefined CPU "cores" with BD by using chip-multi-threading and shared resources.

I didn't realize you were a member here. I got banned from OCN, LMAO.

Anyway, you're definitely right regarding the cores being different in the GPUs. AMD's and NVIDIA's architectures are very different. AMD typically does better on extremely parallel applications.

 

[Cerb]

Honestly, depending on your point of view, you could easily claim either method is superior. FMA3 has a simpler hardware implementation which can result in a more elegant CPU design. FMA4 allows developers to be more flexible with their program code, making things easier for them.

If overwriting is not an option:
4: Fma (A,B,C) -> D
3: Copy D -> C; fma (A,B,C) -> A, B, or C

Meh. Intel being able to have a generation or two of CPUs with an extension that AMD can't yet support, is a meaningful issue, both in terms of performance, market power, and the unbelievable absurdity of our IP laws and regulations.

 

[DeathReborn]

Yes I understand that But from some reason and I believe its in an article here before SB was released that Intel if the use FMA 3 it would have a spare register the same with FMA4 it will have 5 registers . What these extra registers were for wasn't talked about as I recall.

Again I will repaste this part . again so you can more clearly see AMDs problem with FMA 4


AMD has changed the encoding from the original SSE5 specification in order to improve compatibility with Intel's AVX instruction set and the new VEX coding scheme.

All SSE5 instructions that were equivalent or similar to instructions in the AVX and FMA4 instruction sets announced by Intel have been changed to use the coding proposed by Intel. Integer instructions without equivalents in AVX were classified as the XOP extension.[3] The XOP instructions have an Opcode byte 8F (hexadecimal), but otherwise almost identical coding scheme as AVX with the 3-byte VEX prefix.

Commentators[4] have seen this as evidence that Intel has not allowed AMD to use any part of the large VEX coding space. AMD has been forced to use different codes in order to avoid using any code combination that Intel might possibly be using in their development pipeline for something else. The XOP coding scheme is as close to the VEX scheme as technically possible without risking that the AMD codes overlap with any future Intel codes. It must be noted that this inference is speculative, since no public information is available about negotiations between the two companies on this issue.

The use of the 8F byte requires that the m-bits (see VEX coding scheme) have a value bigger than or equal to 8 in order to avoid overlap with existing instructions. The C4 byte used in the VEX scheme has no such restriction. This may prevent the use of the m-bits for other purposes in the future in the XOP scheme, but not in the VEX scheme. Another possible problem is that the pp bits have the value 00 in the XOP scheme, while they have the value 01 in the VEX scheme for instructions that have no legacy equivalent. This may complicate the use of the pp bits for other purposes in the future.

A similar compatibility issue is the difference between the FMA3 and FMA4 instruction sets. INTEL initially proposed FMA4 in AVX/FMA specification version 3 to supersede the 3-operand FMA proposed by AMD in SSE5. After AMD adopted FMA4, however, Intel canceled FMA4 support and reverted back to FMA3 in the AVX/FMA specification version 5

Intel in its white paper on AVx stated that Vec prefix is an intel exclusive they won't let AMD use it Until such a time they want to let AMD use . Its not even on the board for discussion or negotiations
Intels approach with cpu first for AVX/CL is along these lines and I agree. Another repaste

If you think that's radical, please realise that the rules for writing high performance software have already changed dramatically when we went multi-core. So you might as well finish what you started and add scatter/gather support or the CPU will keep losing terrain to the GPU. You're nearing the point where people just buy the cheapest CPU available and rather invest in a more powerful GPU to do the 'real work'. The competition (both AMD and NVIDIA) are in rather sweet spots to take the biggest pieces of the pie in this scenario. So you'd better give people good reasons to keep buying the latest CPUs, by adding instructions to support algorithms that would otherwise run more optimally outside of the CPU. The only reason I care is because I believe it's better for the end user


__________________

It all reminds me of a merry-go-round with Intel spinning it & fooling AMD into thinking they can get off, only to knock them off their feet again.

In reference to the bolded part:

I know it's unlikely but anyone know if this is a breach of the recent "agreement" and "fine" over anti-competitive behaviour?

 

[Nemesis 1]

Well the problem with your question is what constitutes an X86 processor . With the 256 bit AVX were not talking about x86 instructions, What were talking about conversion of say all SSE instructions threw a compiler. Take the vec prefix . all sse 3 instructions are auto recompiled with the simple addition of vex prefix at the start of the code . Now this maybe SSE2 I can't recall which and I not going to go look.

Even thou intell has to let AMD use AVX . They do not have to give AMD their Jit compilers or the other compilers. This is compiler work . The Jit compiler will handle the vex prefix along with CL on the fly recompiles using c++ . The C99 is what open CL uses and intel simply uses their C++ compiler to run on their Arch. Some can be done I the fly but I haven't got much info on this as of yet . But the final result is not X86 based . Its vector were dealing with . What software layer intel is running on . I don't know as intel hasn't said . So no intel has broken no X86 agreement. Thing about it . Should Intel be allowed to reverse engineer LLANO . NO they shouldn't yet llano is X86 based cpu(APU) .So this is a fight AMD wouldn't want to start. You think intel should do the work and spend the money and just give it to AMD . FMA really isn't x86 either. Intel used it in its IA64 processor which used EPIC(VLIW) Its used in GPUs also and most if not all use VLIW.

 

[podspi]

I would be very surprised if AMD doesn't at some point support AVX. It just seems improbable that their recent agreement would allow instruction-extensions (which have been done continually) to be exempt from their extensive sharing agreements.

 

[Arachnotronic]

...Bulldozer supports AVX....http://www.hardwaresecrets.com/article/Inside-the-AMD-Bulldozer-Architecture/1078/2

 

[Nemesis 1]

heres a little info on vex from a source outside intels white paper/ If you read down you will see that depending on wjat FMA 3/4 is used there is room for 5 registers . I really haven't found yet what this 4/5register is for but I sure will know soon enough .

[edit] FeaturesThe proposed VEX coding scheme extends the existing x86 instruction set architecture to allow the definition of new instructions and the extension or modification of previously existing instruction codes. This serves the following purposes:

The opcode map is extended to make space for future instructions.
It allows instruction codes to have up to five operands, where the original scheme allows only two operands (in rare cases three operands).
It allows the size of SIMD vector registers to be extended from the 128-bits XMM registers to 256-bits registers named YMM. There is room for further extensions of the register size in the future.
It allows existing two-operand instructions to be modified into non-destructive three-operand forms where the destination register is different from both source registers. For example c:=a+b instead of a:=a+b (where register a is changed by the instruction).
[edit] Technical descriptionThe proposed VEX coding scheme uses a code prefix consisting of 2 or 3 bytes which is added to existing or new instruction codes[1].

The VEX prefix replaces the most commonly used instruction prefix bytes and escape codes. In many cases, the number of prefix bytes and escape bytes that are replaced is the same as the number of bytes in the VEX prefix, so that the total length of the VEX-encoded instruction is the same as the length of the legacy instruction code. In other cases, the VEX-encoded version is longer or shorter than the legacy code.

The 3-bytes VEX prefix contains the following components:

The four bits R,X,B,W contained in the REX prefix used in the x86-64 instruction set extension.
Two bits named pp to replace operand size prefixes and operand type prefixes (66, F2, F3).
A bit named L specifying 256 bit vector length.
Four bits named vvvv specifying an second source register operand.
Five bits named m-mmmm. Two of the m bits are used for replacing existing escape codes and for specifying the length of the instruction. The remaining three m bits are reserved for future use, such as specifying vector lengths > 256 bits, specifying different instruction lengths, or extending the opcode space.
The 2-bytes VEX prefix contains a subset of these components and can be used in cases where not all components are needed.

The encoding is as follows:

First byte Second byte Third byte
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
3-byte VEX 1 1 0 0 0 1 0 1 R̅ X̅ B̅ m m m m m W v v v v L p p
2-byte VEX 1 1 0 0 0 1 0 1 R̅ v v v v L p p

The R̅, X̅ and B̅ bits are equivalent to the REX prefix's R, X and B bits, providing a fourth register number bit for each of the three registers referenced by a standard x86 instruction: the register operand, and the index and base registers for the memory operand. The v̅ bits specify an additional source register, or are set to all-ones if not used. All of these bits are complemented in the instruction stream, so they are encoded as 1 bits in 32-bit mode.

The VEX opcode bytes are the same as that used by the LDS and LES instructions. These instructions are not supported in 64-bit mode, while in 32-bit mode, the following "mod R/M" byte can not be of the form "11xxxxxx" (which would specify a register operand). The bit inversion ensures that the second byte of a VEX prefix is always of this form in 32-bit mode.

The W bit is equivalent to the REX prefix's W bit, and specifies a 64-bit operand. For non-integer instructions, it is a general opcode extension bit.

The 5 m bits replace leading opcode bytes. The values 1, 2 and 3 are equivalent to opcodes 0F, 0F 38 and 0F 3A; all other values are currently reserved. (The 2-byte VEX prefix always corresponds to a 0F prefix.)

The L bit indicates the vector length. It is 0 for 128-bit SSE (xmm) registers, and 1 for 256-bit AVX (ymm) registers.

The p bits encode additional prefix bytes. The 4 possible values are none, 66, F3, and F2. These encode the operand type for SSE instructions: packed single, packed double, scalar single and scalar double, respectively.

Instructions that need more than three operands have an extra suffix byte specifying one or two additional register operands. Instructions coded with the VEX prefix can have up to five operands. At most one of the operands can be a memory operand; and at most one of the operands can be an immediate constant of 4 or 8 bits. The remaining operands are registers.

The AVX instruction set is the first instruction set extension to use the VEX coding scheme. The AVX instructions have up to four operands. The AVX instruction set allows the VEX prefix to be applied only to instructions using the SIMD XMM registers. However, the VEX coding scheme has space for applying the VEX prefix to other instructions as well in future instruction sets.

Legacy instructions with a VEX prefix added are equivalent to the same instructions without VEX prefix with the following differences:

The VEX-encoded instruction can have one more operand, making it non-destructive.
A 128-bit XMM instruction without VEX prefix leaves the upper half of the full 256-bit YMM register unchanged, while the VEX-encoded version sets the upper half to zero.
Instructions that use the whole 256-bit YMM register should not be mixed with non-VEX instructions that leave the upper half of the register unchanged, for reasons of efficiency.

 

[Nemesis 1]

I would be very surprised if AMD doesn't at some point support AVX. It just seems improbable that their recent agreement would allow instruction-extensions (which have been done continually) to be exempt from their extensive sharing agreements.

AMD can use AVX all they want . They can feast on it . BUT the prefix of vec is and always will be an intel exclusive until intel says differantly. So you think Intel should be allowed to reverse engineer LLANO. Which is an x86 CPU(apu)I don't. I really don't think AMD is dumb enough to push the prefix of vec as an intel exclusive. Or intel could push back and go after AMds x86 APU. Ya can't have it all AMDS way. Think of vex as being cuda. Its an nv exclusive . as vec is an intel exclusive it is coding after all

Instructions that need more than three operands have an extra suffix byte specifying one or two additional register operands. Instructions coded with the VEX prefix can have up to five operands. At most one of the operands can be a memory operand; and at most one of the operands can be an immediate constant of 4 or 8 bits. The remaining operands are registers.

Vex prefix allows up to 5 operands Thats why with FMA3 intel carries a spare register with fma 4 intel can extend to 5 registers. I don't get this as yet but soon enough it will come together
a)At most one of the operands can be a memory operand(note the word can)
b)at most one of the operands can be an immediate constant of 4 or 8 bits (note the word can )
The AVX instruction set is the first instruction set extension to use the VEX coding scheme. The AVX instructions have up to four operands. The AVX instruction set allows the VEX prefix to be applied only to instructions using the SIMD XMM registers. However, the VEX coding scheme has space for applying the VEX prefix to other instructions as well in future instruction sets. Such as open CL for instance. Thats why the prefix of vex is so important to intel . scatter gather operations . Intel played this hand well

AVX has up to 4 operands. SEE THE DIFFERANCE

 

[jones377]

Anyone looking to get some real actual information on the VEX encoding scheme I recommend reading this page instead of the drivel above:

http://en.wikipedia.org/wiki/VEX_prefix

 

[Nemesis 1]

Almost all the drivel above was pasted from your link . and links inside that link . If you want the lowdown on AVX read the Intel white paper on the subject as I have already sugjested several times . Post 91 above is from the link you gave . So drivel me this riddler

 

[podspi]

AMD can use AVX all they want . They can feast on it .

:biggrin::awe::twisted:

BUT the prefix of vec is and always will be an intel exclusive until intel says differantly. So you think Intel should be allowed to reverse engineer LLANO. Which is an x86 CPU(apu)I don't.

You've said this a few times in this thread... What are you talking about? Intel will have, by AMD's own definition, an APU with IB, with full support of DX11 and OpenCL.

I really don't think AMD is dumb enough to push the prefix of vec as an intel exclusive. Or intel could push back and go after AMds x86 APU. Ya can't have it all AMDS way. Think of vex as being cuda. Its an nv exclusive . as vec is an intel exclusive it is coding after all

Intel ALREADY is going after the APU. And with the entire industry behind OpenCL...

SEE THE DIFFERANCE

Not going to claim I fully understand everything being discussed, but the sharing of IP/instruction sets seems pretty self-explanatory to me. Who owns x86-64 again? Oh that's right, AMD. If AMD somehow lost their right to implement all of the new Intel instructions, they've made a grave negotiating error.

 

[Nemesis 1]

So you have the orginal agreement between Intel /AMD great . But these parts your discussing were not made available to the public. Amd 64 and Intel 64 are not the same. Intel owns 64 bit as much as AMD does unless you can show me otherwise in said agreement. Its like licensing other people tech . If you improve the IP still belongs to the orginal owner even if you developed it. It still reverts back to the orginal license of X86. That the problem with agreements one party expresses the desire to keep parts of contract sealed. Intel has already challenged Amd to make the orginal agreement full public knowledge AMD ran off like a dog with tail between legs,

 

[Edrick]

Whether it beats it or not is irrelevant. Bulldozer does not compete with Sandy Bridge-E, but rather Sandy Bridge. Bulldozer is a Performance CPU and platform, just like Sandy Bridge. Sandy Bridge-E is an Enthusiast CPU and platform.

People seriously need to bring up Sandy Bridge-E in these discussions. It will be much more expensive overall.

Since you seem to know the prices of both of these unreleased products, please share.

 

[grimpr]

Intel ALREADY is going after the APU. And with the entire industry behind OpenCL...

http://www.lanl.gov/orgs/hpc/salishan/salishan2011/3moore.pdf

 

[Topweasel]

So you have the orginal agreement between Intel /AMD great . But these parts your discussing were not made available to the public. Amd 64 and Intel 64 are not the same. Intel owns 64 bit as much as AMD does unless you can show me otherwise in said agreement. Its like licensing other people tech . If you improve the IP still belongs to the orginal owner even if you developed it. It still reverts back to the orginal license of X86. That the problem with agreements one party expresses the desire to keep parts of contract sealed. Intel has already challenged Amd to make the orginal agreement full public knowledge AMD ran off like a dog with tail between legs,

Lot of circular talking there. They have a cross license agreement on X86 and with the government and Intel not wanting to get broken up, will have one for a long time. In that agreement it allows for full sharing of technology as it pertains to x86. They have made some concessions here and there on both sides. AMD agreed to stop using the same platform (in their best interests anyways as its hard to stay competitive if they have to keep designing chips for a platform only after its been released. Intel recently in the last extension agreed to have AMD pay them less in royalties because of the amount of AMD IP used in the 6-10 years in Intel processors (and to lower the lump sum that they paid AMD to get the government off their backs). Technologies like EMT64, On-die memory controllers, QPI, SSE, are built around technologies AMD Pioneered, or ones AMD had built up on Intel IP.

If AMD no longer had a cross licensing agreement, about the only thing Intel could sell right now would be Itaniums.

 

[Nemesis 1]

You are way out there man . Ya ever here of of a company called DEC . You should actually do some research . point to point has been around way befor AMD used it . AMD licensed X86 . In the hardware industry If you licensed someones IP if you make improvements on said IP the orginal owner In most cases still owns the IP you developed off there license . Thats the way it is . As for AMD paying intel for each cpu they prodice thats over AMD pays intel nothing . Yes it does allow for full sharing . AMD can use AVX , But They can't use prefix of Vex. Its in intel white paper. I can't believe that you think AMD invented point to point . or AMD HT Everthing you said is basicly wrong Amd pioneered 64 bit thats true but it was developed on intels IP which means intel owns it and Amd can use it . MS and AMD conspired on 64 bit hammer. SSE is an intel invention . AMD was first to use ondie memory controller on x86. But everyone that talked the talk befor c2D couldn't walk the walk after its release so that ondie memory comtroller was befor its time on desktop . but not so much on server. qpi is intels point to point not amds amds is ht and amd didn't invent it . amd did only 64 bit hammerand that was done on intels ip

AMD cann't license X86 to anyone . YA know why . Its INTELS.