Thanks ajaidev,2x128 is simpler at least. There are a lot of things around the AVX spec AMD must do (in order to get full support).Good thing is that there is plenty of time until BD core tapes out.
BTW,there are some whispers that RevD *may* have SSE4.x(or SSSE3) support.RevD should be Istanbul. But at this point it's only a rumor.
I see that Intel publicly stated that it would be 256 bite wide.Quote:
Originally Posted by informal
This is from a while ago though.
http://www.cse.scitech.ac.uk/disco/m..._BillHoran.pdf
Regards, Hans
Shintai, AMD say that intend to support AVX. You are just hoping and predicting that AMD fail on that.
Don't do that or more and more signatures get your failed predictions ;)
I would say more, and this way: AMD intends to support AVX, because it intends to introduce bulldozer in future (presumably in 2011) that would support AVX as well
:welcome:
is it not good way to be "famous"? Like Nostradamus. :rofl:Quote:
Originally Posted by v_rr
This document from spring 2008 already shows that FMA is post Sandy BridgeQuote:
Originally Posted by Hans de Vries
(see page 23 and on)
Regards, Hans
That has changed now AVX and FMA is considered different. AVX will come in SB but FMA will come in its shrink. It will be 256bit wide but using 128bit x2 route its easy to implement.Quote:
Originally Posted by Hans de Vries
Why not just get the updated info from Intel?
http://software.intel.com/en-us/avx/
Let's see, as the architecture improves, shouldn't Intel update AVX accordingly? If that causes AMD heartburn then, that means they have to work harder. Or should Intel not do improvements to help AMD? Intel has always improved SIMD's and hell, I hope they continue to.Quote:
Intel® AVX (Intel® Advanced Vector Extensions) is a 256 bit instruction set extension to SSE and is designed for applications that are floating point intensive.
http://software.intel.com/en-us/foru...s/topic/61121/
Quote:
Originally Posted by Igor
Yes, it changed alright ajaidev:yepp:Quote:
Originally Posted by Intel Engineering team:
Donnie,everything you wrote was already posted dozen of times in this very thread(in other words nothing new). 256bit registers are a *must* for AVX,there is no *if* there.What can be different is the way these are organized(ie. 2x128). This is what we do not know in AMD's approach.Quote:
Originally Posted by Donnie27
As for AVX spec. changes,the last change was the FMA change and intel went with less powerful FMA approach while AMD used the previous intel's implementation,called FMA4. This means that even though FMA will be in BD cores it won't be compatible with FMA3 in post Sandy Bridge CPU(IvyB.) The AVX is different from FMA,and if intel doesn't make some radical changes in it the BD cores will be compatible with SandyB.
Quote:
Originally Posted by v_rr
Hey thanks I will take a look at that :)
Well, whatever they implement, i hope it'll be put to a good use.
Quote:
Originally Posted by ajaidev
Quote:
Originally Posted by Donnie27
What I meant (and what Intel says here) is that AVX and FMA never were
supposed to be implemented at the same time. FMA was always targeted
for a later processor.
Regards, Hans
More on the "AVX in Bulldozer" topic,Agner's question about SSE4.1 instructions that are now missing from Volume 6(AMD developer forums):
http://forums.amd.com/devforum/messa...&enterthread=y
Response from Mr Christie:Quote:
Originally Posted by Agner
This clearly means what the SSE4.1 will be included in AVX and hence there will be no need to list it in Volume 6 which is for additional XOP extensions that AMD engineered themselves. There you go Shintai,AMD won't list ANY of the AVX included instructions in their own XOP extensions because they do not belong there at all.XOP is AMD's baby and they only posted XOP extensions manual.AVX support is there and will not be covered in Volume 6(nor will any of the SSE4.x or SSSE3)Quote:
Originally Posted by D. Christie,AMD senior fellow
The blog post response was posted by me a number of times already so there is no need to re-post it again. Christie basically said AMD will support all of the post SSE3 instruction set extensions in Bulldozer. Only FMA will be an exception ,but SandyB will not feature any support for it anyway so it's a non issue so to say. FMA3 support will come in BD shrink since AMD wants to be sure that specification is finaly stable and not prone to last minute changes.
Not really FMA was suppose to go with SB but it did not the really sad part is that even FMA4 might not work with SB that is very sad indeed.Quote:
Originally Posted by Hans de Vries
I dont much care for FMA3 because of its destructive nature.
BTW The really nice thing about these next gen processors are the operands they can handle. IMO 4 operands at a time is really the big news.
All this, why, because I asked if Intel should be responsible for AMD keeping up with improvements to their software. A simple answered yes or no instead of more PR would have been nice! Your not answering the question is nothing new from you as well LOL!Quote:
Originally Posted by informal
Thanks Hans, I know what you meant and posted what I did to back up what what was said. Why are you guys acting like I disagreed or something. See the ":yepp:"? Yepp means; Yes, damned straight, in fact, you got it, bet your @$$ and etc.. I asked why not just go straight to the source? The other question/s still goes unanswered meanwhile!Quote:
Originally Posted by Hans
Thanks Hans, love your site, was one of the first ones here to link to it BTW!
I fail to see how FMA3 is much worse than FMA4. The "destructive" nature means, that if you want to preserve the initial value, you store it somewhere before the FMA op. And retrieve it later, probably there are many ways to cope with it. The big thing is doing the FMA op in any form IMO..
ok lets see you can combo two similar FMA3 codes in a single FMA4 code.Quote:
Originally Posted by asmodean
FMA3 --> a = b+c and a = a+d
FMA4 --> a = b+c+d
b=2
c=3
d=4
FMA3 --> a = 2+3 //First
a = 5
a = 5+4 //Second
a = 9
FMA4 --> a = 2+3+4
a = 9
FMA3 is longer and takes less system utilization but takes more resources.
FMA4 is shorter as such takes more system utilization but takes less resources.
Think of it as MPEG4 Part 10 and XVID :)
Agreed, just having the FMA op in any form is better than none.Quote:
Originally Posted by asmodean
If you're implementing something like an FIR filter(yay for time-domain convolution), then the destructive nature would be followed anyways. It's a step up from the dot product op in SSE4.1 if you're dealing with more than 4(8 if extended to AVX's 256-bit) elements, as the FMA will deal with the accumulation, until the end when just one horizontal add is needed.
I'm too lazy to convert to the equivalent assembly, but the point should come across(one 256-bit FMA3 per 8 taps, one HADD, and 2 MOV instructions per 8 taps).Code://Basic FIR Filter
int taps = 8 * some_constant;
float Input[taps], System_Response[taps];
Output = 0;
for(n=0; n<taps; n++) {
Output = Input[n] * System_Response[n] + Output; }
It's all situational dependent...
No benefit from FMA4 => Worse code-density than FMA3
Benefit from FMA4 => Better code-density/performance than FMA3
Didn't happen :(.Quote:
Originally Posted by informal
Do you think they'll add it in with the Q1 2010 update?Quote:
Originally Posted by Mechromancer
Perkam
At this point ,the earliest date looks to be Bulldozer release date.
Heck, I missed the news on the Q1 2010 update. Got a link?Quote:
Originally Posted by perkam
It's Magny Cours/Sao Paolo launch..Quote:
Originally Posted by Mechromancer