GDDR5 RAM vs On-Package Cache RAM to improve IGP performance?

[Homeles]

the [HD 4000] driver will improve performance up to 10% while lowering power consumption at the same time.

What a great early birthday present!

 

[wlee15]

The only difference between those 2 cards is DDR3 vs GDDR5. And its 1800Mhz DDR3 vs 4Ghz GDDR5. Yet board TDP is 36% higher under maximum load and 10% higher under idle. Assuming the DDR3 draws 4W and the GDDR5 draws 20W under peak load.

GDDR is simply a power hog. Speed over power consumption.

Note that there are low power GDDR5 modules that run at 1.35V the same voltage as DDR3L modules. Pretty much all the GDDR5 modules in current graphics cards run at 1.5V or 1.6V. I wouldn't be surprised if GDDR5 at 800mhz was more power efficient than DDR3-1866L.

 

[mikk]

Haswell has OpenCL 1.2 support. Ivy Bridge does not.

That's just wrong. I'm using OpenCL 1.2 on my HD4000 since several months. Every 15.31 driver out there support this.

 

[Fox5]

It just doesn't make financial sense to use GDDR5 as system RAM. Look in the memory and storage forum, people are freaking out about standard DDR3 memory prices rising over their historic lows. People aren't going to pay several times current prices to put memory in a budget system.

Do you remember when the P4 required RDRAM? That didn't work out so well for Intel. If Intel can't push expensive memory, AMD certainly can't.

And how is AMD going to sell their customers? "Hey Dell, HP, Lenovo, build systems using our low price CPU. Ignore the fact that the price difference plus more is eaten up by the cost of memory. Just pass it on to your customers, they will be fine with it because it has faster graphics than Intel".

If AMD tries to go down this route they will just hasten their decline.

Most likely most systems will use DDR3. But perhaps AMD will try to score some "premium" gaming systems with high end APUs with mandatory GDDR5. (high end being >$700 - $1000, a range in which intel igps are still quite common)

 

[Ajay]

OpenCL gets translated on the fly with the driver to the hardware. Just like Java and .Net. Or DirectX, DirectCompute and so on. OpenCL is also on top of CUDA on nVidia as well.

Its certainly not closer to bare metal.

Hmm, didn't know that by a brief look at the code. Still, no VM, and I'm pretty sure you need to know the GPU arch to get the best performance; whereas in Java and .net you need to understand the JVM to get the best performance.

I'm writing CUDA code right now, it's much closer to the metal, there is a CUDA runtime and the CUDA compiler (nvcc.exe) does produce an IL code (PTX) that runs on that runtime/driver. Still, it's allot closer to the hardware than something like Java being 'compiled' by a JIT and then run on the JVM.

If if don't code for the arch I'm running on, or build the code to handle multiple uArchs, it stands a good chance of running sub-optimally on a different GPU than I'm using (Kepler 3.0). (**would love a Titan** - maybe if there will be some price cuts after Thanksgiving, and hopefully Malta rocks with the new ~June release of Catalyst).

 

[Fox5]

Hmm, didn't know that by a brief look at the code. Still, no VM, and I'm pretty sure you need to know the GPU arch to get the best performance; whereas in Java and .net you need to understand the JVM to get the best performance.

I'm writing CUDA code right now, it's much closer to the metal, there is a CUDA runtime and the CUDA compiler (nvcc.exe) does produce an IL code (PTX) that runs on that runtime/driver. Still, it's allot closer to the hardware than something like Java being 'compiled' by a JIT and then run on the JVM.

If if don't code for the arch I'm running on, or build the code to handle multiple uArchs, it stands a good chance of running sub-optimally on a different GPU than I'm using (Kepler 3.0). (**would love a Titan** - maybe if there will be some price cuts after Thanksgiving, and hopefully Malta rocks with the new ~June release of Catalyst).

JIT code is JIT code. About the only difference I'd see is that the VM on a graphics card would compile for the specific hardware (ie, how much memory is available), whereas the Java VM has to be manually tuned by the user.

 

[cytg111]

Hmm, didn't know that by a brief look at the code. Still, no VM, and I'm pretty sure you need to know the GPU arch to get the best performance; whereas in Java and .net you need to understand the JVM to get the best performance.

I'm writing CUDA code right now, it's much closer to the metal, there is a CUDA runtime and the CUDA compiler (nvcc.exe) does produce an IL code (PTX) that runs on that runtime/driver. Still, it's allot closer to the hardware than something like Java being 'compiled' by a JIT and then run on the JVM.

If if don't code for the arch I'm running on, or build the code to handle multiple uArchs, it stands a good chance of running sub-optimally on a different GPU than I'm using (Kepler 3.0). (**would love a Titan** - maybe if there will be some price cuts after Thanksgiving, and hopefully Malta rocks with the new ~June release of Catalyst).

I am coder too and must admit I dont see the big difference! Java is not being compiled by a JIT! .. JIT is a feature of the JVM that does excatly whats advertised, it compiles JustInTime. Here's the run down of how Java (and .net) behaves

-SourceCode compiles to ByteCode (bytecode can be reversed easily to the original source, its just more compact here and none of the abbreviations of the source)
-ByteCode is run in the JVM. The JVM will JIT bytecode it has not executed before, this is why with some java/.net programs you will see an inital lag upon execution, shit is getting native here.(and the big advantage of the VM, cause it has the potential to translate the bytecode into your specific architecture with whatever isa's available, avx, avx2 etc.)

When you say PTX I am thinking its analog to Bytecode. Is that right?

 

[cytg111]

JIT code is JIT code. About the only difference I'd see is that the VM on a graphics card would compile for the specific hardware (ie, how much memory is available), whereas the Java VM has to be manually tuned by the user.

It can be tuned by the user, but never really is, it is tuned by the developer(I wil instruct the JVM to run my program with these flags ....).
Unless you are running a cluster of weblogics or whatever you, as an user, will never deal with "tuning the jvm".

As far as I know, there is no such thing as JIT code, yet on interpretation it could be something I never quite understood, as in "why not"? When the JVM compiles(or JIT's) some code, why not write that binary to disc for next time? Why do the JIT compilation on the same code over and over again each time the app is executed .. It is not like we all dont see the lag !

 

[Idontcare]

It can be tuned by the user, but never really is, it is tuned by the developer(I wil instruct the JVM to run my program with these flags ....).
Unless you are running a cluster of weblogics or whatever you, as an user, will never deal with "tuning the jvm".

As far as I know, there is no such thing as JIT code, yet on interpretation it could be something I never quite understood, as in "why not"? When the JVM compiles(or JIT's) some code, why not write that binary to disc for next time? Why do the JIT compilation on the same code over and over again each time the app is executed .. It is not like we all dont see the lag !

As I remember it, been a while now, the FX!32 emulator for running x86 native apps on a DEC Alpha 21164PC computer would store the recompiled code for future runs without the translation delay/overhead.

It makes sense (what you say), why not have JIT compiled code store a local copy for future use? Web browsers can cache web pages, why not cache previously JIT compiled code?

 

[cytg111]

Indeed! Yet the counter intuitive response is that since it is such an simple and obvious idea, better suited engineering folks must have allready considered it and decided against it. I'd just like to know why?

 

[Phynaz]

Most likely most systems will use DDR3. But perhaps AMD will try to score some "premium" gaming systems with high end APUs with mandatory GDDR5. (high end being >$700 - $1000, a range in which intel igps are still quite common)

That APU system will cost more and have lower performance than using a discreet GPU.

 

[Idontcare]

That APU system will cost more and have lower performance than using a discreet GPU.

That is the downside, definitely.

On the other hand, I wonder how much of this new "GDDR5-enabled APU" direction is just recycling what is already being built for the PS4.

There may be volume behind this to drive down prices, or the repurposing of existing engineering designs to reduce design costs.

But it does have an air of rambus-ram to it too...

 

[itsmydamnation]

AMD just like NV have been doing DDR3/GDDR5 controllers for ages. lets not forget that GDDR5 is based off DDR3, their isn't a whole lot of reinventing the wheel here.

 

[Cerb]

It can be tuned by the user, but never really is, it is tuned by the developer(I wil instruct the JVM to run my program with these flags ....).
Unless you are running a cluster of weblogics or whatever you, as an user, will never deal with "tuning the jvm".

As far as I know, there is no such thing as JIT code, yet on interpretation it could be something I never quite understood, as in "why not"? When the JVM compiles(or JIT's) some code, why not write that binary to disc for next time? Why do the JIT compilation on the same code over and over again each time the app is executed .. It is not like we all dont see the lag !

1) That lag isn't important (I care, and you care, but Oracle doesn't), and 2) it's spending way more time executing it, and 3) in the case of standard Java, much of the code stays interpreted, rather than being compiled.

In the case of .NET, you do have options. For a specific program to be deployed, there are also tools to make binaries out of Java applications, such as using GCJ, but I don't know of any that work well with the standard runtime, too.

AOT, instead of JIT, allows you get rid of the JIT problems, at the cost of basically having dynamically-created static binaries. There are people that care, they just do things like HiPE (programmer-controlled AOT runtime compilation), instead of yet another JVM .

 

[NTMBK]

These high-end APUs will be ideal for form factors where a fullsize discrete GPU isn't feasible. Builds like laptops, gaming HTPCs/Steamboxes, or AIO PCs.

 

[MightyMalus]

That's just wrong. I'm using OpenCL 1.2 on my HD4000 since several months. Every 15.31 driver out there support this.

Then Intel is "just wrong". They themselves said that they are putting out OpenCL 1.2 support in about a week.

 

[Fjodor2001]

It just doesn't make financial sense to use GDDR5 as system RAM. Look in the memory and storage forum, people are freaking out about standard DDR3 memory prices rising over their historic lows. People aren't going to pay several times current prices to put memory in a budget system.

Do you remember when the P4 required RDRAM? That didn't work out so well for Intel. If Intel can't push expensive memory, AMD certainly can't.

And how is AMD going to sell their customers? "Hey Dell, HP, Lenovo, build systems using our low price CPU. Ignore the fact that the price difference plus more is eaten up by the cost of memory. Just pass it on to your customers, they will be fine with it because it has faster graphics than Intel".

If AMD tries to go down this route they will just hasten their decline.

You're not answering the question. I asked you what in the article I quoted you considered to be incorrect. The text I quoted here basically said:

* Lower speed GDDR5 RAM is cheaper than faster GDDR5 RAM
* AMD is primarily focused on using slower GDDR5 RAM for Kaveri

Which of that do you think is incorrect?

 

[Fjodor2001]

That APU system will cost more and have lower performance than using a discreet GPU.

In that case isn't is strange that Sony and MS didn't go for a discrete GPU with limited amount of GDDR5 RAM in the PS4 and XBOX720?

Instead they choose 8 GB GDDR5 RAM and an APU. Just like what a possible Kaveri based system that we are now discussing could look like.

 

[Fjodor2001]

There may be volume behind this to drive down prices, or the repurposing of existing engineering designs to reduce design costs.

Yes, if both AMD, Sony and Microsoft think it's a good idea to go with this solution to use a large amount of GDDR5 RAM together with an APU, then I guess they must have though of something.

Just looking at current price of high end GDDR5 RAM, it does seem expensive. But likely they are primarily focusing on using lower speed GDDR5 RAM which is cheaper. And maybe they are seeing something looking ahead, like GDDR5 prices falling. Just look at what has happened to the DDR3 prices. Not that long ago it was quite expensive, but now it's insanely cheap. Today some people even get 16-64 GB RAM systems "just because they can"...

Also, if they will be able to use 8 GB GDDR5 RAM for the PS4 and XBOX720, it seems like they must be able to get it at reasonable prices. After all, their budget must also include an APU, HD, Blu-ray drive, motherboard, chassis, controller, etc. And all of it should perhaps be priced at around $400. In addition, what's been said is that they don't intend to take any initial cost penalty this time, selling the units with a loss like Sony did with the PS3.

 

[ShintaiDK]

In that case isn't is strange that Sony and MS didn't go for a discrete GPU with limited amount of GDDR5 RAM in the PS4 and XBOX720?

Instead they choose 8 GB GDDR5 RAM and an APU. Just like what a possible Kaveri based system that we are now discussing could look like.

So far the Xbox720 is rumoured to go with 8GB DDR3.

 

[Arachnotronic]

Yes, if both AMD, Sony and Microsoft think it's a good idea to go with this solution to use a large amount of GDDR5 RAM together with an APU, then I guess they must have though of something.

Just looking at current price of high end GDDR5 RAM, it does seem expensive. But likely they are primarily focusing on using lower speed GDDR5 RAM which is cheaper. And maybe they are seeing something looking ahead, like GDDR5 prices falling. Just look at what has happened to the DDR3 prices. Not that long ago it was quite expensive, but now it's insanely cheap. Today some people even get 16-64 GB RAM systems "just because they can"...

Also, if they will be able to use 8 GB GDDR5 RAM for the PS4 and XBOX720, it seems like they must be able to get it at reasonable prices. After all, their budget must also include an APU, HD, Blu-ray drive, motherboard, chassis, controller, etc. And all of it should perhaps be priced at around $400. In addition, what's been said is that they don't intend to take any initial cost penalty this time, selling the units with a loss like Sony did with the PS3.

Pssst...look at DRAM prices lately?

 

[NTMBK]

So far the Xbox720 is rumoured to go with 8GB DDR3.

It's also rumoured to have some form of on-package EDRAM to help with bandwidth issues... which ties in quite nicely to the original topic!

 

[ShintaiDK]

It's also rumoured to have some form of on-package EDRAM to help with bandwidth issues... which ties in quite nicely to the original topic!

Indeed. 32MB eSRAM it seems.

 

[Fjodor2001]

So far the Xbox720 is rumoured to go with 8GB DDR3.

Yes, it seems like you are correct.

Looks like the XBOX720 will use 32 MB of embedded SRAM (ESRAM) instead to improve memory bandwidth (see this). Is that perhaps some kind of solution similar to what Intel is expected to use for Haswell (with On-Package Cache RAM for the GT3 HD5200 IGP)?

 

[Phynaz]

In that case isn't is strange that Sony and MS didn't go for a discrete GPU with limited amount of GDDR5 RAM in the PS4 and XBOX720?

Instead they choose 8 GB GDDR5 RAM and an APU. Just like what a possible Kaveri based system that we are now discussing could look like.

Consoles aren't PC's. Console are subsidized, PC's aren't. This shouldn't need explaining again.

Why are you grasping at this so hard? It seems like every thread you create is to find some way to find the thing that is going to be AMD's saving, but you don't listen to anybody as to why it won't work. Why the grasping at everything that is posted on rumor sites, instead of relying upon the facts?