AMD CPU speculation... and expert conjecture

[cdrkf]

An interesting interview with Rory Read:
http://www.newelectronics.co.uk/electronics-interviews/interview-with-amd-president-and-ceo-rory-read/62462/

 

[vmN]

It likely is. From an OS perspective, the i7 920 can only handle 4 threads at a time, and BF4 uses about a dozen helper threads. So what happens, if one of those helper threads need to run, is one of the two heavy threads, either the main render or main program thread, needs to be stopped to allow it to run, causing a latency spike. That's probably what you are seeing. Hence why an i3 can get good FPS numbers, buck such at gameplay. That's your latency coming into play.

The core I7 920 can handle 8 threads simultaneously.

Ok, I forgot HTT, but its worth noting that HTT has its own limitations, so certain workloads CAN'T be run on a HTT/Physical core at the same time. Also, newer (SB and later) chips have a better HTT setup, which could also be affecting performance somewhat.

What kind of workloads are you referring too?

Remember that a core is normally switching between many threads, and a core I7 should be able to handle a threadswitch, without having a greater impact on anything.

We would need more information before we can successfully pinpoint the problem.

 

[8350rocks]

He is referring to situations where you have 5+ main threads, and situations where background processes tie up resources that require more than the timeslice HTT can provide to process them. Like antivirus software, or other heavy background processes that tie up compute.

 

[juanrga]

The only times it made it difference were in extreme multiple GPU setups where the normal x16 bandwidth would of been divided up amongst several GPU's. This was a test of PCIe 2.0 8x vs PCIe 3 8x. A PCIe 2.0 16x channel has about the same bandwidth as a PCIe 3 8x channel.

Also game development is NOT being nerfed nor hindered due to PCIe, that is horribly incorrect. The very nature of how GPU's process data means that the graphics processor or the geometry source (CPU) will be the limitation. dGPU's tend to have 3~6GB of high speed memory, with PCIe 2.0 the per-lane transfer speed is 500MB's. That would allow you to transfer the entire contents of nearly any mid to upper midrange dGPU in under one second. With a 16x slot your looking at 8GB's which is the entire capacity of everything but the Titan Z in under one second. Games aren't anywhere close to needing more then 8GB's worth of new graphics data per second. They upload everything they need to the dGPU, then just go about their business rasterizing frames while slowly swapping out unneeded data for needed data.

Heck a 32-bit NT executable can't address more then 2GB of application memory, with only about 1.7~1.8GB being usable for the application. So there's no way a 32-bit application can even dream about using more then ~3GB of video memory, hell most don't use more then 512MB ~ 1GB. Which leads me to the real user of graphics memory, the GPU itself as a working area. Many graphic enhancement techniques employed at the driver level are executed inside the dGPU itself, the textures are loaded into graphics memory then rendered to larger levels inside the memory with the shaders and aliasing being done. There is next to no additional burden placed on the interconnect bandwidth, unless your rendering at a much higher internal resolution then your dGPU's memory can support and thus need to constantly swap in and out graphics resources. Of course that creates other problems which are significantly more severe then graphics bandwidth.

Anyway the technical details of how all this works leads to the result that graphics I/O interconnects are usually well ahead of what the current need is in the consumer space, usually by an entire generation.

*gasp* PCIe3 does slightly better in high-bottleneck situations at insane resolutions? I'm SHOCKED I tell you.

Again, you take an edge case and consider it a rule. There is no significant difference between the two at this point, and nowhere near enough to warrant a $200 platform upgrade.

Besides failing to interpret correctly my post, both of you show a lack of familiarity with the edge of game development.

Against the usual myth, I have provided gaming examples where PCIe3 provides a performance advantage over PCIe2. I didn't say that it was the general rule; at contrary, I wrote "here we can see some benchmarks showing that PCIe3 can provide 5%, 10%... gains over PCIe2 in some situations/configurations".

Game developers know that PCIe slots are crippling game development. I wrote before: "In fact, the big advantage of a console such as the PS4 is that avoids the PCIe bottleneck and can use the GPU for novel applications including sound processing or physics". PS4 architect confirms how the outdated PC architecture is crippling development of next gen games:

If you look at a PC, said Cerny, "if it had 8 gigabytes of memory on it, the CPU or GPU could only share about 1 percent of that memory on any given frame. That's simply a limit imposed by the speed of the PCIe. So, yes, there is substantial benefit to having a unified architecture on PS4, and it’s a very straightforward benefit that you get even on your first day of coding with the system. The growth in the system in later years will come more from having the enhanced PC GPU. And I guess that conversation gets into everything we did to enhance it."

Cerny envisions "a dozen programs running simultaneously on that GPU" -- using it to "perform physics computations, to perform collision calculations, to do ray tracing for audio."

But that vision created a major challenge: "Once we have this vision of asynchronous compute in the middle of the console lifecycle, the question then becomes, 'How do we create hardware to support it?'"

One barrier to this in a traditional PC hardware environment, he said, is communication between the CPU, GPU, and RAM. The PS4 architecture is designed to address that problem.

"A typical PC GPU has two buses," said Cerny. "There’s a bus the GPU uses to access VRAM, and there is a second bus that goes over the PCI Express that the GPU uses to access system memory. But whichever bus is used, the internal caches of the GPU become a significant barrier to CPU/GPU communication -- any time the GPU wants to read information the CPU wrote, or the GPU wants to write information so that the CPU can see it, time-consuming flushes of the GPU internal caches are required."

The three "major modifications" Sony did to the architecture to support this vision are as follows, in Cerny's words:

* "First, we added another bus to the GPU that allows it to read directly from system memory or write directly to system memory, bypassing its own L1 and L2 caches. As a result, if the data that's being passed back and forth between CPU and GPU is small, you don't have issues with synchronization between them anymore. And by small, I just mean small in next-gen terms. We can pass almost 20 gigabytes a second down that bus. That's not very small in today’s terms -- it’s larger than the PCIe on most PCs!

We already saw some early PS4 games filling 3GB for video memory[#] and using the GPU in ways that are not possible to use in a PC with a discrete card attached to a PCIe slot.


[#] Partitioned as follows,
* Non-Streaming Textures: 1321MB
* Render Targets: 800MB
* Streaming Pool (1.6GB of streaming data): 572MB
* Meshes: 315MB
* CUE Heap (49x): 32MB
* ES-GS Buffer: 16MB
* GS-VS Buffer: 16MB

to the above add a CPU/GPU shared Memory pool of 128MB

 

[juanrga]

It's really not a problem. They have all details needed to implement something similar in their own design whenever they find something good (as long as it's not covered by any patent).

There isn't a problem implementing "something similar" that doesn't violate any patent. There is a problem with reusing "blocks" from existent CPUs such as the A57. Those "blocks" are intellectual property of other companies and AMD cannot reuse them for its own CPUs.

 

[juanrga]

The fact remains, JK said that, NOT me, and NOT my source. However, considering he did actually do the cores for A7 (remember, design to tape out is about a 2 year process in most cases and A7 taped out a year after he left...), as well as many other things since leaving and returning to AMD. I have immense faith in him delivering what he says. Though as my source has pointed out, if you shoot for Mars and hit the moon, you are still on the moon. AMD has a lot of stuff coming soon, and unfortunately I cannot expound beyond that. All I can say is, leave ARM to die until it shows up in a HEDT PC, once that occurs, we will have a conversation about ARM. As for AMD catching up...we shall see. Things are very different from what they were in the 1990's, while they are also very similar to what they were as well. So, I would expect you to sit back and watch as things unfold, I can only lead you to water, whether or not you drink it is your own business.

The problems (plural) begin with you giving us two versions of what Keller supposedly said, continue with you adding the word "Intel" to a quote from him, and finish with you admitting to skatzus that you don't know what means "better than Skylake". You cannot say if it means better at efficiency, better at performance, better at performance per $ or what, still you have the arrogance of pretending that Keller is supporting your claims.

I note that you continue ignoring any technical, economic, and strategic argument given to you by several people in this thread.

Keller designed the A4 and A5 SoCs at Apple

http://www.anandtech.com/show/6129/apple-a4a5-designer-k8-lead-architect-jim-keller-returns-to-amd

The A6 design was finished at 2010 (the same year Gerard Williams was hired) and tapped-out one year latter, not two, as you pretend.

I think you accurately describe our respective orthogonal approaches: you have "immense faith"; I use data and logics to infer conclusions. This is the reason why you hyped that Steamroller was going to crush Haswell, whereas I knew this was not going to happen.

 

[juanrga]

Interestingly enough, there are games coming out with native 64bits executables (haven't seen if the libs are full 64bit though).

In the coming year (2014 -> 2015) I'm sure we'll see more games chugging more resources (I hope), since we already have some that actually do.

I gave a link to one that got my attention a while ago called "Planetary Annihilation". Also, we have "Star Citizen" and some other big games announced to be native 64bits (can't remember more though).

And iron8orn, read carefully every post in here instead of dismissing them easily (specially palladins', gamerks', 8350rocks' and juans'), since they usually contain a lot of good information to think about. That attitude only destroys good conversation and doesn't add anything meaningful to it; in other words: "if you don't have anything nice to say, then stay quiet".

Cheers!

I don't know about Windows, but Unreal is targeting exclusively 64bit for linux

https://wiki.unrealengine.com/Linux_Demos

 

[blackkstar]

Interestingly enough, there are games coming out with native 64bits executables (haven't seen if the libs are full 64bit though).

In the coming year (2014 -> 2015) I'm sure we'll see more games chugging more resources (I hope), since we already have some that actually do.

I gave a link to one that got my attention a while ago called "Planetary Annihilation". Also, we have "Star Citizen" and some other big games announced to be native 64bits (can't remember more though).

And iron8orn, read carefully every post in here instead of dismissing them easily (specially palladins', gamerks', 8350rocks' and juans'), since they usually contain a lot of good information to think about. That attitude only destroys good conversation and doesn't add anything meaningful to it; in other words: "if you don't have anything nice to say, then stay quiet".

Cheers!

I don't know about Windows, but Unreal is targeting exclusively 64bit for linux

https://wiki.unrealengine.com/Linux_Demos

Windows is always behind Linux in this sort of stuff, usually by a huge margin. You really, really have to go out of your way to use 32-bit applications in Linux and to have a fully 32-bit system.

I wouldn't be surprised to see Linux versions ship with 64-bit, SSE4 enabled executables while Windows gets 32-bit SSE1 executables.

Everyone loves to bash on GCC and then they act dumbfounded when GCC + GNU + Linux blows Windows away on the same hardware.

I used to think it was just compilers picking on AMD hardware. So I ran Blender on Gentoo and windows on my i7 920 and saw ridiculous gains as well. Blender Windows is compiled with MSVC too. There's something really wrong with the tools Blender Foundation is using to compile Blender for Windows and I wonder how many other developers are using the same tool chain and producing horrendous machine code.

When Linux gaming takes off, there's going to be a lot of people who are resilient to change spreading FUD out of fear of change.

It's going to be better for everyone. AMD wants to make changes to the Linux compiler, they just submit their changes. Nvidia, AMD, and Intel want updates to DirectX 11 and they don't show up until AMD releases Mantle. It's not difficult to see why Windows is harming consumers wallets and forcing them to upgrade hardware for artificially crippled software.

When people wake up and realize that installing Linux is a bigger upgrade to their rigs than making the jump from Nehalem to Haswell, they're gonna either switch or get really, really angry and defend the fact that they're afraid of switching OSes.

 

[8350rocks]

The fact remains, JK said that, NOT me, and NOT my source. However, considering he did actually do the cores for A7 (remember, design to tape out is about a 2 year process in most cases and A7 taped out a year after he left...), as well as many other things since leaving and returning to AMD. I have immense faith in him delivering what he says. Though as my source has pointed out, if you shoot for Mars and hit the moon, you are still on the moon. AMD has a lot of stuff coming soon, and unfortunately I cannot expound beyond that. All I can say is, leave ARM to die until it shows up in a HEDT PC, once that occurs, we will have a conversation about ARM. As for AMD catching up...we shall see. Things are very different from what they were in the 1990's, while they are also very similar to what they were as well. So, I would expect you to sit back and watch as things unfold, I can only lead you to water, whether or not you drink it is your own business.

The problems (plural) begin with you giving us two versions of what Keller supposedly said, continue with you adding the word "Intel" to a quote from him, and finish with you admitting to skatzus that you don't know what means "better than Skylake". You cannot say if it means better at efficiency, better at performance, better at performance per $ or what, still you have the arrogance of pretending that Keller is supporting your claims.

I note that you continue ignoring any technical, economic, and strategic argument given to you by several people in this thread.

Keller designed the A4 and A5 SoCs at Apple

http://www.anandtech.com/show/6129/apple-a4a5-designer-k8-lead-architect-jim-keller-returns-to-amd

The A6 design was finished at 2010 (the same year Gerard Williams was hired) and tapped-out one year latter, not two, as you pretend.

I think you accurately describe our respective orthogonal approaches: you have "immense faith"; I use data and logics to infer conclusions. This is the reason why you hyped that Steamroller was going to crush Haswell, whereas I knew this was not going to happen.

LOL!!! I actually have clarification if you want to know...

Performance per Watt is the goal they are chasing...as it bothered me as well thinking about what the reference was toward.

 

[szatkus]

Interestingly enough, there are games coming out with native 64bits executables (haven't seen if the libs are full 64bit though).

In the coming year (2014 -> 2015) I'm sure we'll see more games chugging more resources (I hope), since we already have some that actually do.

I gave a link to one that got my attention a while ago called "Planetary Annihilation". Also, we have "Star Citizen" and some other big games announced to be native 64bits (can't remember more though).

And iron8orn, read carefully every post in here instead of dismissing them easily (specially palladins', gamerks', 8350rocks' and juans'), since they usually contain a lot of good information to think about. That attitude only destroys good conversation and doesn't add anything meaningful to it; in other words: "if you don't have anything nice to say, then stay quiet".

Cheers!

I don't know about Windows, but Unreal is targeting exclusively 64bit for linux

https://wiki.unrealengine.com/Linux_Demos

Windows is always behind Linux in this sort of stuff, usually by a huge margin. You really, really have to go out of your way to use 32-bit applications in Linux and to have a fully 32-bit system.

I wouldn't be surprised to see Linux versions ship with 64-bit, SSE4 enabled executables while Windows gets 32-bit SSE1 executables.

Everyone loves to bash on GCC and then they act dumbfounded when GCC + GNU + Linux blows Windows away on the same hardware.

I used to think it was just compilers picking on AMD hardware. So I ran Blender on Gentoo and windows on my i7 920 and saw ridiculous gains as well. Blender Windows is compiled with MSVC too. There's something really wrong with the tools Blender Foundation is using to compile Blender for Windows and I wonder how many other developers are using the same tool chain and producing horrendous machine code.

When Linux gaming takes off, there's going to be a lot of people who are resilient to change spreading FUD out of fear of change.

It's going to be better for everyone. AMD wants to make changes to the Linux compiler, they just submit their changes. Nvidia, AMD, and Intel want updates to DirectX 11 and they don't show up until AMD releases Mantle. It's not difficult to see why Windows is harming consumers wallets and forcing them to upgrade hardware for artificially crippled software.

When people wake up and realize that installing Linux is a bigger upgrade to their rigs than making the jump from Nehalem to Haswell, they're gonna either switch or get really, really angry and defend the fact that they're afraid of switching OSes.

Compilers emits similar code on different OSes, just in different packages.
Usually differences in performance lies in OSes itself (how they manage resources etc.). Also porting libraries on different platforms can affect peformance (for example if programmer did crappy version of code for Windows and proper for Unix). What Blender uses for GUI? GTK?

 

[gamerk316]

Everyone loves to bash on GCC and then they act dumbfounded when GCC + GNU + Linux blows Windows away on the same hardware.

The last time I saw an in-depth performance comparison between GCC and MSVC, MSVC was found to be 12% faster on average. I'll see if I can gravedig the link.

Also note, that same comparison showed the Intel compiler was 30% faster then MSVC.

GCC, frankly, sucks. I'm glad LLVM/Clang is going to finally kill it off. Linux has needed a decent development platform in the worst possible way; how people live with GCC is beyond me.

 

[juanrga]

LOL!!! I actually have clarification if you want to know...

Performance per Watt is the goal they are chasing...as it bothered me as well thinking about what the reference was toward.

Congrats! You needed to ask and get confirmation of something that I already said here a pair of days ago: "I expect K12 to outperform Skylake efficiency"

 

[vmN]

There is a difference between expecting and have a clarification on things.

So, please try not to pick a fight.

 

[juanrga]

There is a difference between expecting and have a clarification on things.

So, please try not to pick a fight.

There is no fight. I have been ignoring the insults and provocations in last few pages, including that message from him where he changed my words and wrote I am "unqualified".

What I did above is to remind that I already knew the so-called "new information".

We (AMD included) expect K12 to outperform Skylake in efficiency, but this cannot be guaranteed because neither Skylake nor K12 are in final form and because it also depends on foundries processes: e.g. if Glofo 14nm underperforms and Intel 10nm shine then the original target of the new arch could be lost.

This is why I wrote "expect" instead "will do". It has nothing to do with clarification of anything.

I already knew that AMD was not targeting to outperform Skylake in performance. Keller never said faster than Skylake. I know a bit about new arch. I didn't need any clarification. And this is why I react to such hype claims when were said here in the forum.

AMD pretends to fight Intel using more cores: 8/12/16 core on die. The new AMD cores are efficient and small.

 

[vmN]

Skybridge*

You are both fighting. You might do it more indirectly, but you are still doing it. (However that is pretty much the standard when people argue. They will start pick on the opponent after a while).

 

[szatkus]

We (AMD included) expect Skylake to outperform Skylake in efficiency

It could be hard...

 

[Rum]

We (AMD included) expect Skylake to outperform Skylake in efficiency

It could be hard...

Yeah especially when he says Skylake will outperform itself, not sure how that is going to work out!

 

[Embra]

More Triple A titles to support mantle ?
http://www.guru3d.com/news-story/more-trippe-a-titles-to-support-mantle.html

 

[de5_Roy]

More Triple A titles to support mantle ?
http://www.guru3d.com/news-story/more-trippe-a-titles-to-support-mantle.html

didn't know r.a.g.e. had mantle support. or sleeping dogs. are we finally gonna see havok and physx support mantle? or did i mix up engine names again..

 

[8350rocks]

@juan:

PPW at similar TDP is the goal (meaning, yes, outright performance).

Also, I would like to point out, you could not possibly know anything about next gen x86, because it is unannounced as of yet, and I am not permitted to speak about it. Sure K12 is announced, however project name for next gen x86 is not skybridge and no details have yet been announced. They are playing that much closer to the chest...for a reason.

 

[gamerk316]

More Triple A titles to support mantle ?
http://www.guru3d.com/news-story/more-trippe-a-titles-to-support-mantle.html

See a lot of Cryengine 3 on there; that still going to be around if Crytek goes under? Because they are essentially bankrupt at this point.

 

[cdrkf]

More Triple A titles to support mantle ?
http://www.guru3d.com/news-story/more-trippe-a-titles-to-support-mantle.html

See a lot of Cryengine 3 on there; that still going to be around if Crytek goes under? Because they are essentially bankrupt at this point.

I wouldn't be surprised if Chris Roberts purchased Crytek given his game is built on it and they have raised *huge* amounts of cash for Star Citizen (in excess of $40,000,000), I wonder what bankrupt Crytek would go for?

 

[Rum]

More Triple A titles to support mantle ?
http://www.guru3d.com/news-story/more-trippe-a-titles-to-support-mantle.html

See a lot of Cryengine 3 on there; that still going to be around if Crytek goes under? Because they are essentially bankrupt at this point.

Rumor is Sony is looking to possibly buy Crytek.

 

[juanrga]

Skybridge*

You are both fighting. You might do it more indirectly, but you are still doing it. (However that is pretty much the standard when people argue. They will start pick on the opponent after a while).

Nope. Commenting on the content of messages posted here, including his, is not fighting. Mentioning that info that he gives to me was given before is not fighting. Avoiding provocations and insults that he makes is not fighting.

 

[juanrga]

We (AMD included) expect Skylake to outperform Skylake in efficiency

It could be hard...

We (AMD included) expect Skylake to outperform Skylake in efficiency

It could be hard...

Yeah especially when he says Skylake will outperform itself, not sure how that is going to work out!

Yes! Checking the original claim here

http://www.tomshardware.co.uk/forum/352312-28-steamroller-speculation-expert-conjecture/page-288#13680584

shows that it was a typo. My admiration by caughting it