AMD CPU speculation... and expert conjecture

[de5_Roy]

and the prime example as I stated before, can't at all be anything Intel did when they assisted in programming the game itself. It must be somthing with AMD, anything that Intel could have done is just a conspiracy.

imo, right now, it doesn't make much sense for intel to push amd down like they did before with their anti-competitive practices.
i checked the sub-$200 gaming cpu round up and in that, the phenom cpus outperformed the fx ones and there was a clear difference of avg fps between cpus with and without l3 cache e.g. phenom vs llano. in another comparo, i found that phenom and lynnfield i5 perform similarly (with i5 leading by a bit).
http://www.anandtech.com/bench/Product/362?vs=191
considering bd was supposed to be 45nm and it has lower ipc and worse cache latency compared to 32nm sandy bridge and later, i assume starcraft 2 woulda played better on intel anyway. in this bench,
http://www.anandtech.com/bench/Product/434?vs=191
fx leads lynnfield in starcraft 2. the test systems are different though.
otoh, i've seen some gaming benchmarks with amd cpus beating intel cpus. some benchmarks from ocaholic come to mind.
that's why, to me at least, the conspiracy theory doesn't hold much value, unless there is clear evidence that intel indeed programmed to have amd cpus underperform, unlike placing optimizations for intel's own cpus (or gpus) because intel, amd and nvidia all do the latter.

Intel has no reason to force AMD cpus for example to not use SSE instructions.

i won't say intel has 'no reason'.... for example, they worked around by locking amd out of using earlier sse instructions (iirc this is how the compiler switch worked). if there was such an issue again, i bet they'll find yet another workaround... but. right now that doesn't seem to be intel's focus.

 

[gamerk316]

However you can use just about any hexeditor or search program that will allow you to search for the string "GenuineIntel".

Be VARY careful; a lot of people use that string as a cheap way to differentiate Intel/AMD products, especially during periods where AMD is lacking some specific Intel feature. (Yes, CPUID *should* be used instead). Simply seeing that string in HEX isn't enough to gurantee that Intel's compiler was responsible for the compilation.

 

[gamerk316]

WHAT THE F .... 0.2% on the game that is claimed to be soley IPC and clock speed? There is a reason AMD can't compete in SC2, and its not just IPC and clock speed. 0.2% gain from BD to PD, there is something else holding AMD back. SC2 is the only game where overclocking an AMD cpu doesn't even speed the game up.

Considering SC2 was designed BEFORE the court order to Intel, and Intel plastered the game all over their website, what could possibly be the problem? Is SC2 performance all AMD's fault?

According to my profile tools, Intel's compiler was NOT used to compile SC2. That being said, they can't identify the compiler either...

Could also be a number of other things: Could be memory intensive (favors Intel), sensitive to cache latencies (favors Intel), very branch intensive code (favors Intel), or very FP heavy code (favors Intel). Really can't tell without looking at the source.

 

[keithlm]

Be VARY careful; a lot of people use that string as a cheap way to differentiate Intel/AMD products, especially during periods where AMD is lacking some specific Intel feature. (Yes, CPUID *should* be used instead). Simply seeing that string in HEX isn't enough to gurantee that Intel's compiler was responsible for the compilation.

Seeing that string in HEX almost always indicates the Intel ICC compiler. So I'm going to have to ignore your "advice".

 

[gamerk316]

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-New-Graphics-Performance-Metric

Some interesting points brought up. Especially in the case where the second of three frames is barely drawn to the screen at all.

(Seriously, AMD, news please?)

 

[-Fran-]

Techreports method is really gaining momentum it seems. Hope we hear something from Toms as well.

And this is besides the point of AMD in need to improve the drivers, off course. I wonder how the APUs fare with the new metric at hand.

Cheers!

 

[blackkstar]

It's just CPU bound. Considering it's almost 50 FPS, that's pretty good for AMD. But the fact that there is almost no improvement, that's bad. I've heard it's the socket in general and the Pin count. Which I don't know why Pin number would make a difference.

This is the dumbest logic I have ever heard.

AMD is CPU bottlenecked but increasing CPU performance via overclocking yields no performance gains. In other news, my graphics card is a bottle neck but overclocking it doesn't help my FPS or frame time at all.

 

[gamerk316]

Seeing that string in HEX almost always indicates the Intel ICC compiler. So I'm going to have to ignore your "advice".

"Almost always" != "Always". I guess you would never see code in the form of:

if CpuIdName = "GeniuneIntel" then // Intel CPU's
...
else CpuIdName = "AuthenticAMD" then // AMD CPU's
...
else // Cyrix, Via, etc
...
end if

You might do this if, for whatever reason, you use a significant amount of Intel/AMD only extensions (such as the Intel/AMD varients of SSE3/4). And yes, looking directly at the extensions via CPUID makes the most sense. And yes, I've seen this in source code before.

In any case, I'll do some checking over the weekend and make a quick list for the games I currently have installed. Should give a pretty good sample size of what compilers are typically used.

 

[noob2222]

But according to Noob222, frame latency is just another term for "minimum FPS measure in 1 frame intervals".
So WTF is AMD actually improving ? I see a conspiracy by AMD here..

"minimum FPS measure in 1 frame intervals". is like saying "minimum kilomtres per hour measured in 1 meter intervals". Which means absolutely nothing.

But rather than average those out by each second of time, what if you looked at each frame individually?
http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-New-Graphics-Performance-Metric

quite a bit more interesting read than techspot. kinda looks like they discovered a 2nd anomaly, too small of a frame latency is what causes screen tear, not too long. Looks like there are two sides of this latency coin.

high latency, low fps is obvious, but varies from person to person how fast they can see (some claim they can see 120+ fps)

low latency, high fps causes screen tear ( would explain why other individuals feel 60hz monitors isn't fast enough)

one thing I miss is toms writeups on screen ghosting with monitor reviews. how much of that is still going on in todays monitors? Is the monitor itself the bigger factor in examining frame latency?

 

[gamerk316]

Ghosting still exists to some extent; you still see LCD's with Response Times in the 16ms range (and those are always best case numbers).

The low latency, high FPS case is where Vsync comes into play. This ensures only one complete frame is rendered per display cycle, but in most implementations, the game engine comes to a halt in the time period between a frame being finished and the primary buffer being read by the GPU. If it takes longer then 16.7ms on average to create a frame, this results in FPS getting cut in half.

The reason FPS gets halved is because of the face the primary display driver ALWAYS holds the most complete frame, so if it takes, say, 18ms to create a frame, you get as follows:

Begin
Frame 1 Begins Processing
Display requests new frame (16ms)
No Frame Ready [FPS = 0]
Frame 1 created (18ms)
Display requests new frame (32ms)
Frame 1 Displayed [FPS = 30]
Frame 2 Begins Processing
Display requests new frame (48 ms)
No Frame Ready [FPS = 15]
Frame 2 Finishes Processing (50 ms)
Display requests new frame (64 ms)
Frame 2 Displayed [FPS = 30]

Note how processing of the next frame doesn't start until the previous one is displayed? Thats the problem with most Vsync implementations (though this is starting to change). So you kill FPS, and introduce a lot of input lag.

Ideally, the next frame would be processed as soon as the previous one finishes, and would be moved into the primary buffer either when complete [if the primary buffer currently isn't being read], or after the next read is complete. In that case, an average frame time of 18ms would still equate to 55 FPS being displayed. Big difference.

 

[JAYDEEJOHN]

Thruput TO the screen, not displayed is what we are seeing with these measurements.
That doesnt mean ghosting isnt occuring, it just compounds the many potential possibilities of what causes these.
At any portion of any game , one HW solution can look bad in latencies, as well as game to game.

 

[-Fran-]

And that's not even including the internal latency some monitors/TVs add to the image when applying filters 8(

But at least, I can attest to 120Hz monitors (in particular, Samsung 2233rz). I have a friend with one and the games DO look more fluid with no v-sync on, since you don't reach the 120FPS easily. It's really nice actually. Now, the 120Hz magic is thanks to the circuitry in charge of processing the image itself. Problem is, you never get to know what it what in that arena, just trademarked names, like the good "BRAVIA Engine" from Sony. Well, at least I can say Plasma TVs are great for gaming. They usually have low image processing that can't be turned off and the refresh rate is amazing; around 600Hz equivalent.

Cheers!

 

[noob2222]

Ghosting still exists to some extent; you still see LCD's with Response Times in the 16ms range (and those are always best case numbers).

The low latency, high FPS case is where Vsync comes into play. This ensures only one complete frame is rendered per display cycle, but in most implementations, the game engine comes to a halt in the time period between a frame being finished and the primary buffer being read by the GPU. If it takes longer then 16.7ms on average to create a frame, this results in FPS getting cut in half.

The reason FPS gets halved is because of the face the primary display driver ALWAYS holds the most complete frame, so if it takes, say, 18ms to create a frame, you get as follows:

Begin
Frame 1 Begins Processing
Display requests new frame (16ms)
No Frame Ready [FPS = 0]
Frame 1 created (18ms)
Display requests new frame (32ms)
Frame 1 Displayed [FPS = 30]
Frame 2 Begins Processing
Display requests new frame (48 ms)
No Frame Ready [FPS = 15]
Frame 2 Finishes Processing (50 ms)
Display requests new frame (64 ms)
Frame 2 Displayed [FPS = 30]

Note how processing of the next frame doesn't start until the previous one is displayed? Thats the problem with most Vsync implementations (though this is starting to change). So you kill FPS, and introduce a lot of input lag.

Ideally, the next frame would be processed as soon as the previous one finishes, and would be moved into the primary buffer either when complete [if the primary buffer currently isn't being read], or after the next read is complete. In that case, an average frame time of 18ms would still equate to 55 FPS being displayed. Big difference.

The only problem is your missing the frame buffer. LCD normally are fed through a double buffer, IE when the primary is ready to be displayed, the next frame is being rendered in the back buffer. once its displayed, the buffer moves up, and begins loading the next frame. In order to get a no frame ready, you have to drop below the refresh rate for 2 frames.

This is where triple buffering really comes in handy. you have to drop below the threshold for 3 frames.

Here is another problem with only discussing latency. You have to do all this latency testing with v-sync off. Your video card just feeds the data as soon as it gets it, 0 buffering. Seems the whole latency issue is more of an issue of non-syncronizing with the monitor because v-sync is off. Could this be more of an issue of wether or not you should be running v-sync with a 60hz monitor?

of course there is the downfall with v-sync and tri-buffering, each frame is sent to the monitor later than its ready. For tri-buffering, when frame 3 is ready, frame 2 was sent to front buffer 16 ms ago, and frame 1 sent to monitor 32ms ago. for just v-sync, frame 2 ready, frame 1 sent to the monitor 16ms ago. V-sync disabled, 0 ms wait time.

BTW, your corrected math would be

display 16ms
Frame 1 ready 18ms
frame 2 started
display frame 1 32ms
frame 2 moved up
Frame 2 finished 36ms
frame 3 started
Display frame 2 48ms
frame 3 moved up
frame 3 finished 54ms.
frame 4 started
display frame 3 64ms


you won't get an actual dropped frame till frame 30. the video card doesn't wait for the ok to start the next frame, it just waits for the ok to send or change the information.

one interesting thing is lcd can still be subject to tearing with v-sync off. Monitor is reading data out-of-sync, reads half of the frame, video card changes the frame, monitor continues reading and displays 2 -1/2 frame images.

http://www.tweakguides.com/Graphics_9.html

 

[de5_Roy]

AMD Launches a Pair of E-Series APUs
http://www.techpowerup.com/178303/AMD-Launches-a-Pair-of-E-Series-APUs.html

 

[esrever]

AMD Launches a Pair of E-Series APUs
http://www.techpowerup.com/178303/AMD-Launches-a-Pair-of-E-Series-APUs.html

why release these now?

 

[noob2222]

why release these now?

Various new devices launched at the 2013 International CES are based around the two.

your answer was in the article

 

[gamerk316]

And that's not even including the internal latency some monitors/TVs add to the image when applying filters 8(

But at least, I can attest to 120Hz monitors (in particular, Samsung 2233rz). I have a friend with one and the games DO look more fluid with no v-sync on, since you don't reach the 120FPS easily. It's really nice actually. Now, the 120Hz magic is thanks to the circuitry in charge of processing the image itself. Problem is, you never get to know what it what in that arena, just trademarked names, like the good "BRAVIA Engine" from Sony. Well, at least I can say Plasma TVs are great for gaming. They usually have low image processing that can't be turned off and the refresh rate is amazing; around 600Hz equivalent.

Cheers!

Remember, the TV is still receiving 60Hz, and "filling in" the other 60 frames by taking the difference between frames 1 and 2. In short: there's an automatic 16ms latency + time to create the filler image when using the 120Hz mode.

Good for TV viewing, not so much for games.

 

[gamerk316]

The only problem is your missing the frame buffer. LCD normally are fed through a double buffer, IE when the primary is ready to be displayed, the next frame is being rendered in the back buffer. once its displayed, the buffer moves up, and begins loading the next frame. In order to get a no frame ready, you have to drop below the refresh rate for 2 frames.

This is where triple buffering really comes in handy. you have to drop below the threshold for 3 frames.

Here is another problem with only discussing latency. You have to do all this latency testing with v-sync off. Your video card just feeds the data as soon as it gets it, 0 buffering. Seems the whole latency issue is more of an issue of non-syncronizing with the monitor because v-sync is off. Could this be more of an issue of wether or not you should be running v-sync with a 60hz monitor?

of course there is the downfall with v-sync and tri-buffering, each frame is sent to the monitor later than its ready. For tri-buffering, when frame 3 is ready, frame 2 was sent to front buffer 16 ms ago, and frame 1 sent to monitor 32ms ago. for just v-sync, frame 2 ready, frame 1 sent to the monitor 16ms ago. V-sync disabled, 0 ms wait time.

BTW, your corrected math would be

display 16ms
Frame 1 ready 18ms
frame 2 started
display frame 1 32ms
frame 2 moved up
Frame 2 finished 36ms
frame 3 started
Display frame 2 48ms
frame 3 moved up
frame 3 finished 54ms.
frame 4 started
display frame 3 64ms


you won't get an actual dropped frame till frame 30. the video card doesn't wait for the ok to start the next frame, it just waits for the ok to send or change the information.

one interesting thing is lcd can still be subject to tearing with v-sync off. Monitor is reading data out-of-sync, reads half of the frame, video card changes the frame, monitor continues reading and displays 2 -1/2 frame images.

http://www.tweakguides.com/Graphics_9.html

I will agree on most of this; most games these days are clearly using a second buffer, as I'm not seeing the same frame drops with Vsync enabled. So thats a plus right there.

The main problem when discussing FPS is there are three key components: The game engine, the GPU, and the display. Example: The GPU may be capable of having a secondary/tertiary buffer, but those are useless if the game engine physically stops while a frame is being displayed. Or the fact that theres no easy way to count the number of unique frames actually sent to the display. And so on. Hence why I've always disliked FPS, since its nothing more then a measure of GPU work. Techreport and PC Perspective at least are finally looking at the rest of the chain, and trying to determine how many of those created frames actually end up on the display.

 

[esrever]

Various new devices launched at the 2013 International CES are based around the two.

your answer was in the article

I was expecting kabini to be released at CES or something.

 

[mayankleoboy1]

Kabini, or Temash or even Hondo.

 

[sarinaide]

Merry Xmas and New years to everyone, belatedly. Hope 2013 for all is a prosperous one and hope 2013 is a good one for technology.

 

[anxiousinfusion]

8000 series rebrand is announced. http://www.amd.com/us/products/desktop/graphics/oem-solutions/Pages/desktop.aspx#2

Kaveri will be running a version of this graphics arch?

 

[mayankleoboy1]

the rebrand from 7xxx to 8xxx is for OEM parts only.
No real 8xxx GCN2.0 parts have been announced.

 

[esrever]

Could AMD hold off the OEMs for just a couple of months with 7XXX and not have to rebrand the cards? This is just stupid. top to bottom OEM rebrands. Now the performance is going to be all out of wrack when the real 8XXXs launch.

Also something about kaveri for H2 2013

http://www.techpowerup.com/178389/AMD-Unveils-Innovative-New-APUs-and-SoCs.html

AMD also introduced the new APU codenamed "Richland" which is currently shipping to OEMs and delivers visual performance increases ranging from more than 20 percent to up to 40 percent over the previous generation of AMD A-Series APUs1. "Richland" is expected to come bundled with new software for consumers such as gesture- and facial-recognition to dramatically expand and enhance consumers' user experiences. The follow-on to "Richland" will be the 28nm APU codenamed "Kaveri" with revolutionary heterogeneous system architecture (HSA) features which is expected to begin shipping to customers in the second half of 2013.

 

[de5_Roy]

AMD shares latest mobile, desktop roadmap
http://techreport.com/news/24164/amd-shares-latest-mobile-desktop-roadmap
this looks so funny, squeezing yet another 32nm apu. now amd will have FIVE major lineups (llano, bd, trinity, pd and richland) made off 32nm node. seems like the earlier rumor of richland being 28nm may be wrong. amd says richland apus will ship with 'amd optimized games' among other things, hopefully the usual conspiracy theory of intel messing up every game for amd cpus can be put to rest...(probably until/if intel beats richland in a gaming cpu bench).
the weird part is that the article says kaveri will ship by the end of the year. wtf? if that happens, won't it be a repeat of llano and trinity fighting for the same market segment, not to mention trinity will be barely a year old when richland will launch and richland will be Months old when/if kaveri launches. i wonder how amd will tackle this.
meanwhile, kabini and temash look far more promising than the possible mess amd is trying to create.

AMD CES 2013 Press Event Live Blog
http://www.anandtech.com/show/6567/amd-ces-2013-press-event-live-blog
kaveri will be out in h2 2013. sigh...

8000 series rebrand is announced. http://www.amd.com/us/products/desktop/graphics/oem-solutions/Pages/desktop.aspx#2

Kaveri will be running a version of this graphics arch?

guys, there is actually a radeon 8000 thread (free of fanboy bickering so far. )
http://www.tomshardware.com/forum/forum2.php?config=tomshardwareus.inc&cat=33&post=346081&page=1&p=1&sondage=0&owntopic=1&trash=0&trash_post=0&print=0&numreponse=0&quote_only=0&new=0&nojs=0