AMD CPU speculation... and expert conjecture

[juanrga]

Above 3Ghz isn't too comforting. Above 4Ghz would be. So we likely have to go back to the older charts where SR is 10-15% faster than Piledriver. Clock speed reduction but higher "IPC". On the plus side they should be cheaper to make and use less power. Good for the mainstream user but FX-6350/8350 will remain top end for desktop.

I consider a 20% and a slight reduction in clock freq. compared to Richland.

 

[juanrga]

Again though, look at what HSA allows AMD to do: They can offer a CPU+APU combo (HSA) and do something that looks like:

CPU for generic tasks
APU for OpenCL/CUDA/HSA
Discrete GPU for rendering

This would allow, for instance, fully hardware accelerated effects without a hit to FPS, as neither the CPU or GPU would have to do any additional processing. That's the big advantage HSA allows to happen. Using this schema, you wouldn't need a powerful CPU for gaming, as you could potentially offload a LOT more processing without a noticeable performance hit, making FX a dead-end arch. Coincidentally, this is the way I think things are going to head for the desktop going forward

The possibility AMD could release APUs as base gaming systems that can be upgraded with a dGPU, in whose case, the iGPU could work exclusively for compute was already considered and discussed before in this thread.

In fact, I will add more data supporting this speculation. We know that AMD is moving all the heavy compute tasks from the CPU to the GPU. E.g. the PS4 will use the GPU for complex processes which are traditionally handled by the CPU such as physics simulation, collision detection, raycasting for audio, decompression...

Therefore, we have for kaveri:

i) The CPU alone has about the same performance of an i5/FX-6

ii) Heavy computations are moved to the iGPU, which implies that the CPU will perform better for the remaining tasks.

iii) The iGPU has more performance than a hypothetical dual socket FX-9590s OC at 6GHz.

iv) FX-series R.I.P.

 

[juanrga]

I think you have not answered my main points: bulk vs SOI? Carrizo 20nm? Q42013 vs H12014?

you mean this rumor? http://news.softpedia.com/news/AMD-and-GlobalFoundries-Interested-in-FD-SOI-for-the-20-nm-Process-267519.shtml
or http://www.xbitlabs.com/news/other/display/20120428083057_AMD_Globalfoundries_Others_Set_to_Use_Fully_Depleted_SOI_with_14nm_20nm_Chips.html

or some other rumor made up on another forum claiming "bulk"?

No. I did mean what I wrote.

so .. Kaveri is going to improve trinty by going from 4.2 ghz base clock to intel's standard 3.5? If thats the case, then I don't see kaveri getting close to the 6300 @ stock. Kaveri needs ~4.5 ghz for that. If kaveri is bulk, my hopes of seeing a decent cpu out of it are even lower.

There is no way that Kaveri will be 4.5 GHz. I am convinced that will be clocked slower than Richland.

- AMD is replacing 8-core Opterons by 4-core Berlin.
- Warsaw will use Piledriver => there is no 6/8-core Steamroller modules.
- Kaveri comes as 2/4-core.

Does it make sense for you that AMD will release 6/8-core FX steamroller or similar chip exclusively for the desktop? Not for me.

SR FX are not exclusive to DT. those are the 2p-4p server chips. If warsaw is a PD refresh, then we should see some in the AM3+ DT socket as well. When/if SR moves to 2p-4P we will see SR-FX or whatever they decide to call it in 2015.

The existence of Warsaw doesn't mean the elimination of all other 2p-4p cpus. If kaveri/sr FX are both 28nm (SOI or not), AMD wants to make the best profit possible, and with GF being limited on production, that leaves Kaveri being the most viable option until stocks are full, then we may see SR 28nm (SOI) 2P-4P cpus.

There is no SR FX for the 2p-4p and it looks more reasonable to me that Warsaw CPUs will be substituted by an Excavator APU/CPU in 2015, just like Opterons are being replaced by Berlin in 2014. I also hope Excavator to come in 2/4 cores configs.

I see no reason for PD refresh in AM3+. For me, the FX-9000 series is the last desktop line.

Oh, I didn't see this blog post... I just got it from the AMD Dev mailing list:

http://blog.documentfoundation.org/2013/07/03/amd-joins-the-document-foundation-advisory-board-to-accelerate-libreoffice/

Looks like they joined LibreOffice to work with them developing stuff to use the GPU (or APU thinking HSA). I'd love to see OpenSheet using the GPU for lookups, haha.

Cheers!

Yes, I gave this link a pair of days ago in this thread.

 

[noob2222]

I think you have not answered my main points: bulk vs SOI? Carrizo 20nm? Q42013 vs H12014?

you mean this rumor? http://news.softpedia.com/news/AMD-and-GlobalFoundries-Interested-in-FD-SOI-for-the-20-nm-Process-267519.shtml
or http://www.xbitlabs.com/news/other/display/20120428083057_AMD_Globalfoundries_Others_Set_to_Use_Fully_Depleted_SOI_with_14nm_20nm_Chips.html

or some other rumor made up on another forum claiming "bulk"?

No. I did mean what I wrote.

got any sources of all your " facts from AMD" or do you just start rumors.

you never seem to provide any sources at all.

 

[juanrga]

Geeze... this is SteamRoller people, not Half Life 3. We haven't heard anything about AMD "delaying" anything. These are just rumors. Lol, think about it...

Rumor: Kaveri being delayed...

Truth: Kaveri not being delayed.

Rumor: FX series CPUs being canceled.

Truth: No one ever said anything about AM3+ line up being discontinued.

It was more like VR-ZONE launched the rumours that kaveri is delayed and the FX-line is cancelled and AMD replied to VR-ZONE denying only the rumour about kaveri...

Of course, this does not imply that AMD confirmed the other rumour, but the asymmetry in their treatment of both rumours is curious.

HUMA allows to avoid copying memory between CPU and GPU contexts. This copying increases latency by a significant degree, which in turn affects performance. To get around this limitation, you typically see, for instance, smaller textures used that are repeated over and over again, allowing for a smaller data transfer. By giving the GPU access to main memory, you avoid needing to copy textures to the GPU's memory context, allowing, theoretically, much larger and more detailed textures to be used without a performance penalty.

There are other two advantages of hUMA. The first is the the system does not need to maintain a copy of VRAM on RAM, freeing up memory. This means that a HUMA APU with 8 GB has more available memory than an traditional CPU+GPU with 8+2GB.

The second advantage is that hUMA allows that both CPU and GPU can use the same pieces of data at the same time. During GDC 2012, AMD already mentioned how the possibility of utilizing both processors at the same time allows them to perform certain complex tasks that couldn't be performed with the traditional PC architecture.

 

[hcl123]

ESRAM management is not fun; ask PS3 developers how hard it was to keep the CPU going to know what I'm talking about.

HUMA allows to avoid copying memory between CPU and GPU contexts. This copying increases latency by a significant degree, which in turn affects performance. To get around this limitation, you typically see, for instance, smaller textures used that are repeated over and over again, allowing for a smaller data transfer. By giving the GPU access to main memory, you avoid needing to copy textures to the GPU's memory context, allowing, theoretically, much larger and more detailed textures to be used without a performance penalty.

ummm... Cell of the PS3 used DMA (direct memory access) to talk to the ESP... plenty of copies... XBone CPU can talk directly with the ESRAM without copies, at least that is how i understand it. No.. its not the same thing since its only 32MB, but will alleviate those copies a great deal.

And bonus is that "from" the ESRAM will reduce latencies a great deal. The rest XBone GPU will have the same scheme of Llano/Trinity, it will have its own partitioned DRAM space.

 

[palladin9479]

There are other two advantages of hUMA. The first is the the system does not need to maintain a copy of VRAM on RAM, freeing up memory.

...

...

You know that doesn't happen right. It's actually impossible due to the non-kernel memory address range on Windows x86 being 31 bits large (2GB max) and the kernel range being another 2GB max. There was a time back when cards had MUCH smaller memory sized (think 32~64MB) that his happened, AGP era basically. That has long since passed and now the contents of VRAM are left there or paged out in a 32-bit application. 64-bit Windows is a bit saner, it'll try to keep it there but can copy it out if you task switch to another application. What is kept in memory is a copy of the current scene, that tends to be MUCH smaller then the size of the VRAM and allows the program to start rendering again though it'll have to reload resources.

Anywho HUMA isn't anything new, just a new word for a concept that's been around since before the 8087 coprocessor. HSA is just a set of language protocols and standards that allow non-uniform processors to talk to each other and cohabitate in the same system without requiring different memory subsytems.

 

[hcl123]

Again though, look at what HSA allows AMD to do: They can offer a CPU+APU combo (HSA) and do something that looks like:

CPU for generic tasks
APU for OpenCL/CUDA/HSA
Discrete GPU for rendering

This would allow, for instance, fully hardware accelerated effects without a hit to FPS, as neither the CPU or GPU would have to do any additional processing. That's the big advantage HSA allows to happen. Using this schema, you wouldn't need a powerful CPU for gaming, as you could potentially offload a LOT more processing without a noticeable performance hit, making FX a dead-end arch. Coincidentally, this is the way I think things are going to head for the desktop going forward

The possibility AMD could release APUs as base gaming systems that can be upgraded with a dGPU, in whose case, the iGPU could work exclusively for compute was already considered and discussed before in this thread.

In fact, I will add more data supporting this speculation. We know that AMD is moving all the heavy compute tasks from the CPU to the GPU. E.g. the PS4 will use the GPU for complex processes which are traditionally handled by the CPU such as physics simulation, collision detection, raycasting for audio, decompression...

Therefore, we have for kaveri:

i) The CPU alone has about the same performance of an i5/FX-6

ii) Heavy computations are moved to the iGPU, which implies that the CPU will perform better for the remaining tasks.

iii) The iGPU has more performance than a hypothetical dual socket FX-9590s OC at 6GHz.

iv) FX-series R.I.P.

No... Just because the AM3+ might very well be EOL, doesn't mean FX is R.I.P. Steamroller FX might very well need another socket, one notable difference is that it might have PCIe support along with support for HTX slots on board.

PCIe everybody understands it could be similar to intel, HTX ppl would also understand if they knew AMD "server" boards. The catch is that hUMA "needs" cache coherency, and with HTX is not only APUs that can have hUMA but also the traditional configs with discrete graph cards.

Combo "PCIe+HTX" slots i even presented the AMD patents here... put a PCIe board in there and it will be like today, put the same but with a HTX ready board (which probably will be AMD only for a long time, doubt nvidia will have it any time soon if ever) and that discrete GPGPU will be hUMA.

No wonder Intel freaked out, and is making almost all Broadwell line BGA... makes something smell like rotten for the sides of Nvidia, like something is dead lol...

 

[hcl123]

Anywho HUMA isn't anything new, just a new word for a concept that's been around since before the 8087 coprocessor. HSA is just a set of language protocols and standards that allow non-uniform processors to talk to each other and cohabitate in the same system without requiring different memory subsytems.

There is one notable difference, x87 used the same MMU/TLB of the CPU, it was a closed coupled co-processor that later jumped inside the CPU.

With hUMA each "heterogeneous processor" uses its own MMU/TLB, in the lines of IOMMU of AMD, which v2.5 is now an official HSA standard.

That is what makes it different... hUMA its cache coherency + IOMMU (kind of). And is like this because i think the intention is make it real flexible, its not only for close coupled "processors", it could function with different processors GPU, DSP even FPGAs, on interconnects soldered into a board or in another slot or socket.

Matter of fact what makes it similar to the original x87 is the FlexFPU in those modules, we can say the FlexFPU is a hUMA closed coupled (same MMU/TLB) co-processor.

 

[hcl123]

Another advantage of HSA that nobody talks about is "task queues".

Those "task queues" in hardware will look like another small buffer, but there is a catch... with advanced enough interconnects it could make the "heterogeneous" processor a bus master element, that is, the CPU can be put to idle while the heterogeneous is crunching, kind of makes the heterogeneous part "independent" of the CPU, since those "queues" will be visible from "userpase" (for applications) without the CPU having to schedule those tasks.

For a GPU is like an evolution of the nvidia Fermi scheduling scheme (better with that), which Kepler represented a step back (1.5B lol).

For one thing it means you don't need the absolute top performance CPU to have the absolute top performance out of the GPU... dedicated task queues scheduling, hUMA, bus mastering/ "lightweight notification"( which didn't went for PCIe v3... thanks intel... but HTX can have it http://www.eetimes.com/document.asp?doc_id=1171458 ) the GPU(s) can be at 120%(lol) even with a xfire config( thanks LwN), while the CPU reports periods of idling lol

 

[gamerk316]

There are other two advantages of hUMA. The first is the the system does not need to maintain a copy of VRAM on RAM, freeing up memory.

...

...

You know that doesn't happen right. It's actually impossible due to the non-kernel memory address range on Windows x86 being 31 bits large (2GB max) and the kernel range being another 2GB max. There was a time back when cards had MUCH smaller memory sized (think 32~64MB) that his happened, AGP era basically. That has long since passed and now the contents of VRAM are left there or paged out in a 32-bit application. 64-bit Windows is a bit saner, it'll try to keep it there but can copy it out if you task switch to another application. What is kept in memory is a copy of the current scene, that tends to be MUCH smaller then the size of the VRAM and allows the program to start rendering again though it'll have to reload resources.

Anywho HUMA isn't anything new, just a new word for a concept that's been around since before the 8087 coprocessor. HSA is just a set of language protocols and standards that allow non-uniform processors to talk to each other and cohabitate in the same system without requiring different memory subsytems.

I think the default is 256/512MB or so reserved by the system for this purpose, but still, even if the working set of data is small, you still have to copy it to the GPUs VRAM. That's the step thats being removed by HUMA.

And I'd argue that old 32-bit 2GB barrier is still a major limiting factor on PC gaming. We still get the occasional game that isn't compiled as Large Address Aware (*coughSkyrimcough*), which enables full 4GB worth of Addressing on Win64 (and 3GB on Win32 if the /3GB switch is set) [And I'm going to totally disregard the existence of PAE/AWE for this discussion]. Obviously, native 64-bit binaries would be best, since you could theoretically support a 16EB Address Space, pending Software/Hardware support.

 

[palladin9479]

There are other two advantages of hUMA. The first is the the system does not need to maintain a copy of VRAM on RAM, freeing up memory.

...

...

You know that doesn't happen right. It's actually impossible due to the non-kernel memory address range on Windows x86 being 31 bits large (2GB max) and the kernel range being another 2GB max. There was a time back when cards had MUCH smaller memory sized (think 32~64MB) that his happened, AGP era basically. That has long since passed and now the contents of VRAM are left there or paged out in a 32-bit application. 64-bit Windows is a bit saner, it'll try to keep it there but can copy it out if you task switch to another application. What is kept in memory is a copy of the current scene, that tends to be MUCH smaller then the size of the VRAM and allows the program to start rendering again though it'll have to reload resources.

Anywho HUMA isn't anything new, just a new word for a concept that's been around since before the 8087 coprocessor. HSA is just a set of language protocols and standards that allow non-uniform processors to talk to each other and cohabitate in the same system without requiring different memory subsytems.

I think the default is 256/512MB or so reserved by the system for this purpose, but still, even if the working set of data is small, you still have to copy it to the GPUs VRAM. That's the step thats being removed by HUMA.

And I'd argue that old 32-bit 2GB barrier is still a major limiting factor on PC gaming. We still get the occasional game that isn't compiled as Large Address Aware (*coughSkyrimcough*), which enables full 4GB worth of Addressing on Win64 (and 3GB on Win32 if the /3GB switch is set) [And I'm going to totally disregard the existence of PAE/AWE for this discussion]. Obviously, native 64-bit binaries would be best, since you could theoretically support a 16EB Address Space, pending Software/Hardware support.

Your thinking address space being reserved, he was speaking about actual memory being used. As in 2GB of system memory being used to keep a copy of the 2GB of data in the VRAM. Basic knowledge of Window's memory model renders that laughably absurd.

Having both GPU and CPU using the same memory space has huge advantages when it comes to binary languages. Currently if someone wants to write code to run on the GPU (GPGPU / OpenCL / ect..) its a completely different code set then what you send to the CPU. With HSA / HUMA you can compile a single binary that contains both sets of code as a single stream. It's basically SSE on steroids.

My point is that the existence of a large powerful vector co-processor does not reduce the usefulness of multiple scalar processors. They each specialize in different work loads and do not replace each other. What that large vector co-processor allows is physics / AI and other array math heavy applications to run better then before, provided you have a dGPU. This is why I speculated that AMD will release a 6 ~ 8 core version with a cut down iGPU that only does HSA procesing and acts like a co-processor instead of rendering graphics.

 

[griptwister]

@palladin9479, Out of all the rumors and theories here, that would make sense if AMD canceled the FX series and the AM3+ or AM4 line up. If we had something a little more concrete though... Those gigabyte MoBos are pretty looking. I'm thinking about getting a FM2+ Processor just to say I have a sense of hUMA.

 

[de5_Roy]

^^ the brand(fx) or a powerful(in amd terms) flagship 'cpu' won't be going away any time soon. amd will keep making those for publicity alone.
the next fx could easily be an 'apu'.

 

[mayankleoboy1]

The second advantage is that hUMA allows that both CPU and GPU can use the same pieces of data at the same time. During GDC 2012, AMD already mentioned how the possibility of utilizing both processors at the same time allows them to perform certain complex tasks that couldn't be performed with the traditional PC architecture.

i don think this will be happening in kaveri. i think amd needs a die shrink+excavator arch to do this

 

[juanrga]

There are other two advantages of hUMA. The first is the the system does not need to maintain a copy of VRAM on RAM, freeing up memory.

...
...

You know that doesn't happen right. It's actually impossible due to the non-kernel memory address range on Windows x86 being 31 bits large (2GB max) and the kernel range being another 2GB max. There was a time back when cards had MUCH smaller memory sized (think 32~64MB) that his happened, AGP era basically. That has long since passed and now the contents of VRAM are left there or paged out in a 32-bit application. 64-bit Windows is a bit saner, it'll try to keep it there but can copy it out if you task switch to another application. What is kept in memory is a copy of the current scene, that tends to be MUCH smaller then the size of the VRAM and allows the program to start rendering again though it'll have to reload resources.

I was discussing a PC with 8 GB RAM. I was assuming 64-bit all. I didn't mention Windows...

In an ordinary PC architecture, all the textures/shaders/vertices have to be uploaded to the VRAM from the system RAM. This means that your graphics data will temporarily be in both system RAM and VRAM. It does not matter if once the upload is done you may choose to get rid of the copy in system RAM. At some instant data is duplicated.

The question about how many RAM is used at a given instant is complex. E.g. it depends if textures are stored uncompressed or compressed on RAM. If I recall correctly, the unreal engine use 4:1 and 8:1 compression ratios for textures. It also depends of the file format. Some formats can contain more than one copy of the same texture, each copy compressed with a different algorithm for use on a specific GPU.

My point holds: an APU hUMA 8GB PC has more available memory than a traditional PC with 8 GB RAM + 2GB VRAM. Some game developers recommend 12GB RAM for PCs to try to replicate the 8GB of the PS4 by this motive. Epic uses 16GB in the PCs.

Again though, look at what HSA allows AMD to do: They can offer a CPU+APU combo (HSA) and do something that looks like:

CPU for generic tasks
APU for OpenCL/CUDA/HSA
Discrete GPU for rendering

This would allow, for instance, fully hardware accelerated effects without a hit to FPS, as neither the CPU or GPU would have to do any additional processing. That's the big advantage HSA allows to happen. Using this schema, you wouldn't need a powerful CPU for gaming, as you could potentially offload a LOT more processing without a noticeable performance hit, making FX a dead-end arch. Coincidentally, this is the way I think things are going to head for the desktop going forward

The possibility AMD could release APUs as base gaming systems that can be upgraded with a dGPU, in whose case, the iGPU could work exclusively for compute was already considered and discussed before in this thread.

In fact, I will add more data supporting this speculation. We know that AMD is moving all the heavy compute tasks from the CPU to the GPU. E.g. the PS4 will use the GPU for complex processes which are traditionally handled by the CPU such as physics simulation, collision detection, raycasting for audio, decompression...

Therefore, we have for kaveri:

i) The CPU alone has about the same performance of an i5/FX-6

ii) Heavy computations are moved to the iGPU, which implies that the CPU will perform better for the remaining tasks.

iii) The iGPU has more performance than a hypothetical dual socket FX-9590s OC at 6GHz.

iv) FX-series R.I.P.

No... Just because the AM3+ might very well be EOL, doesn't mean FX is R.I.P. Steamroller FX might very well need another socket, one notable difference is that it might have PCIe support along with support for HTX slots on board.

PCIe everybody understands it could be similar to intel, HTX ppl would also understand if they knew AMD "server" boards. The catch is that hUMA "needs" cache coherency, and with HTX is not only APUs that can have hUMA but also the traditional configs with discrete graph cards.

Combo "PCIe+HTX" slots i even presented the AMD patents here... put a PCIe board in there and it will be like today, put the same but with a HTX ready board (which probably will be AMD only for a long time, doubt nvidia will have it any time soon if ever) and that discrete GPGPU will be hUMA.

No wonder Intel freaked out, and is making almost all Broadwell line BGA... makes something smell like rotten for the sides of Nvidia, like something is dead lol...

Well, AMD claims that the center of its universe are APUs. Both server and desktop roadmaps show no Steamroller FXs are coming. AMD want to unify sockets. There are strong rumours that the FX line disappear...

 

[juanrga]

The second advantage is that hUMA allows that both CPU and GPU can use the same pieces of data at the same time. During GDC 2012, AMD already mentioned how the possibility of utilizing both processors at the same time allows them to perform certain complex tasks that couldn't be performed with the traditional PC architecture.

i don think this will be happening in kaveri. i think amd needs a die shrink+excavator arch to do this

This is already available to jaguar cores with hUMA support. From AMD:

PS4 will have hUMA wich means that you no longer need a distinction between CPU partition and GPU partition. Both processors can use the same pieces of data at the same time. You don't need to copy stuff and this allows for completely new algorithms that utilize CPU and GPU at the same time. This is interesting since a GPU is very strong, but extremely dumb. A CPU is extremely smart, but very weak. Since you can utilize both processors at the same time for a single task you have a system that is extremely smart and extremely strong at the same time.

 

[juanrga]

Your thinking address space being reserved, he was speaking about actual memory being used. As in 2GB of system memory being used to keep a copy of the 2GB of data in the VRAM. Basic knowledge of Window's memory model renders that laughably absurd.

Then you will laugh at this quotation:

Sharing isn't a problem for an architecture like this. It's an advantage. It's not the same thing with PS2/XBox era RAM sharing, where CPU and GPU got access to a fraction of memory. These 8GB are completely accessible by both processors. That means that everything that requires traffic between RAM and VRAM on PC and duplicates of various resources no longer needs any of that on PS4.

For example, consider streaming a texture on PC. First, the VRAM memory is "unlocked", which means a duplicate storage space is created in RAM. Then the texture data is read from HDD and copied over to RAM. Then the texture is "locked," which involves copying contents of texture in RAM over to VRAM via the PCIe bus. This is the biggest bottleneck on PC. On PS4 it is completely eliminated. Data is streamed from HDD or disk directly into shared memory.

Or say you want destructible environment in a PC game. You can either run physics on CPU, which isn't terribly fast, and then you have to update geometry buffers in graphics memory. Or you can run all of the physics in GPU, altering geometry directly there, but then you have to pull it out into RAM so that your path finding and AI can use it. Either way, you end up managing geometry both in VRAM and in RAM. Updating both copies constantly via the same PCIe bus. Again, a major bottleneck.

On PS4, you have just one copy of geometry sitting in lightning fast GDDR5 memory and both GPU and CPU have access to it. So either processor can be running physics, depending on which is more convenient, with GPU running graphics and CPU running AI all from the same geometry.

Still, the main point here is that CPU really doesn't have to be all that great. PS4′s CPU is just there to run logic. AMD's architecture isn't the best even for that, but it's definitely good enough. The entire edge of PS4 comes from the fact that both chips are sitting on the same die and are sharing memory. And whatever else you might say about AMD, they have most experience with this sort of design.

 

[gamerk316]

^^ The point Palladin was making though, is that whole 2GB of VRAM won't be used in one shot (which is correct). More VRAM is just like more RAM in a system: You avoid having to constantly move data in/out of it to make room for the dataset you are currently working on.

So when you eliminate VRAM and let the GPU access main memory directly, guess what? That VRAM bottleneck GOES AWAY. So, for instance, if you took a 512MB, 1GB, and 2GB version of the same exact card on a PC, benchmark it, you will see the 512MB version of the card does the worst, especially on high settings. Why? Because the GPU is waiting on data to get to the VRAM, which often means something has to move OUT of VRAM to make room. Meanwhile, the GPU is sitting around doing nothing. The 2GB version of the card, by contrast, can just keep loading more and more data into VRAM, so you don't have the performance loss due to VRAM being filled. Thats the type of bottleneck HUMA does away with.

 

[Ags1]

Why would AMd kill FX? They have a modular arch so it should not take much investment to scale up to four modules even if two modules are the focus. FX may cater to a niche but it is a much bigger niche than, say, the Nvidia Titan niche. If Intel push up their prices it opens the market to AMD.

 

[blackkstar]

^^ the brand(fx) or a powerful(in amd terms) flagship 'cpu' won't be going away any time soon. amd will keep making those for publicity alone.
the next fx could easily be an 'apu'.

A $200 APU using HSA benchmarks compared to a $999 Intel EE using CPU only would result in the Intel EE getting slaughtered.

I'm imagining something along the lines of comparing perhaps:

AMD CPU + iGPU for OpenCL physics/other GPGPU tasks + dGPU for rendering vs Intel CPU + dGPU for rendering.

Both of which are running the same exact code, but the Intel CPU has to do the work of the iGPU for the AMD rig.

Perhaps imagine a situation we can see now when we can compare AMD CPU + Nvidia GPU for PhysX + GPU for rendering vs CPU + GPU for rendering with the same PhysX settings but the CPU + GPU combination has PhysX running on the CPU.

AMD has a huge chance with these console wins to get a massive software advantage over Intel in benchmarks, which would be the biggest win AMD could achieve. AMD didn't even have that when they had better CPUs.

 

[Cazalan]

Why would AMd kill FX? They have a modular arch so it should not take much investment to scale up to four modules even if two modules are the focus. FX may cater to a niche but it is a much bigger niche than, say, the Nvidia Titan niche. If Intel push up their prices it opens the market to AMD.

Perhaps because it's getting close to 2014 and with AMD talking about hUMA all the time the FX without any graphics at all starts to look like a relic. Marketing wise that's a challenge, combined with the initial bad press for Bulldozer FX.

They can always revive it later when it makes sense to do so. With the mobile/low power push today the big chips are being released on a slower cadence. That's even true for Intel.

 

[griptwister]

Hmmm... there must be something big going on... AMD is really clearing house. Also, I noticed Newegg doesn't have the ASUS 990FX R 2.0 Gen 3 listed anymore... I'm starting to buy this, "AMD is moving the FX to the FM2 Platform."

 

[iafro1989]

Hmmm... there must be something big going on... AMD is really clearing house. Also, I noticed Newegg doesn't have the ASUS 990FX R 2.0 Gen 3 listed anymore... I'm starting to buy this, "AMD is moving the FX to the FM2 Platform."

That mobo is just out of stock.

 

[juanrga]

^^ The point Palladin was making though, is that whole 2GB of VRAM won't be used in one shot (which is correct).

And mapping VRAM <--> RAM does not need to be one MB to one MB. I already mentioned one example of how a texture can occupy more RAM than VRAM.

His explicit mention of the "Window's memory model" makes me believe that he misunderstood completely what I tried to say, because what I was saying is completely independent of the operative system used.

My point was that a traditional PC architecture always has redundant data stored on both RAM and VRAM for applications such as games. How many of that total data is redundant and how many RAM occupies depends on lot of factors: from game settings to the game-engine internals.

The new hUMA architecture eliminates those redundancies and free up system memory. That is one of reasons why some game developer recommends 12GB RAM for PCs:

Next-gen consoles adopt 8GB of unified memory as a baseline. In contrast, PC operates two distinct pools - system memory (DDR3) and video RAM (typically, GDDR5). Our advice for graphics is to get a card with as much GDDR5 as you can, but system memory also has to be factored in.

Linus Blomberg of Avalanche recommends 8GB of DDR3, while another of our sources believes that 12GB is a safer bet for future-proofing your PC, bearing in mind the overhead required by Windows combined with the fact that graphics data needs to spool from system RAM into the GPU's onboard memory.

This, from an AMD seminar, is also interesting:

Game developers and other 3D rendering programs have wanted to use extremely large textures for a number of years and they’ve had to go through a lot of tricks to pack pieces of textures into smaller textures, or split the textures into smaller textures, because of problems with the legacy memory model… Today, a whole texture has to be locked down in physical memory before the GPU is allowed to touch any part of it. If the GPU is only going to touch a small part of it, you’d like to only bring those pages into physical memory and therefore be able to accommodate other large textures.

With a hUMA approach to 3D rendering, applications will be able to code much more naturally with large textures and yet not run out of physical memory, because only the real working set will be brought into physical memory.