AMD CPU speculation... and expert conjecture

[esrever]

Eventually all high end APUs will likely come with on chip memory, ddr4 will only provide so much bandwidth. To get to even 7770 performance, you'd need to invest in other way to increase bandwidth on the APU. Microsoft just jumpped the gun in their design while sony went with the traditional memory set up. MS is generally more forward looking in both the 360 and the ONE in regards to the silicon. Unified memory and unified shaders in the 360 and on die esram + memory accelerators for the ONE. I really doubt future APUs will ship with GDDR5 for main memory simply because it will be hard to AMD to push system makers to do something like that, they have a hard enough time to get their chips into designs as it is without completely redoing the motherboard designs for both DDR4 and GDDR laptops. My guess is stacked ram on chip is a much more likely solution to the bandwidth problem, be it ESRAM or EDRAM, having memory like this will help in the overall performance of the APU without much increase for thermals and provide the bandwidth.

It seems like both consoles will support some form of uniform coherent memory system. This is pretty good for AMD to push huma and their HSA plans. There is still wonder of if MS is on board for the while HSA movement AMD is pulling. Wonder if MS is or will be on the HSA foundation. Their support could mean HSA can gain much more support in the software space. BOLT is cool and all but MS can put so much more support for it out there by promoting it with MSVS.

 

[juanrga]

Charlei is incorrect.

its not the "The blue arrows above are for coherent memory accesses, yellow for non-coherent traffic"... if he had payed attention and not eager to sell more fish out of the same basket, if he had included the slide "GPU and GPU MMU clients"(http://cdn2.wccftech.com/wp-content/uploads/2013/08/Xbox-One-GPU-Architecture-635x481.png )(edt) as seen here http://wccftech.com/microsoft-xbox-one-architecture-detailed-hot-chip-2013-features-5-billion-transistors/, the second yellow/(green) line from the top for the "Host Guest GPU MMU", totally exposed in the "SoC Components" slide he analyses, but without the *comments*, says: "DRAM Access Non-CPU-Cache-Coherent 68GB/sec peak (incl coherent BW)", and that link goes exclusively to the DRAM controller that has 68GB/s peak, meaning all DRAM (system DRAM) is coherent to the GPU caches at max bandwidth possible, its the CPU block the one restricted to 30GB/sec (~half)... so Durango is hUMA...

And Durango is not 1+ year old design, matter of fact compared with PS4 design that uses Garlic and Onions as seen here http://www.vgleaks.com/playstation-4-architecture-evolution-over-time/ seems more advanced than Orbis( not very fond of M$ like Charlei, but skip the phobia)... thought Orbis will perform better at games( but probably not that much)...

Matter of fact the design is pretty identical to "onion + onion+" of Orbis, most included that remarkable piece of Northbridge in the slide "Soc components" (CPU-Cache-Coherent Memory Access)(edt) that Charlei analyses saying: "Microsoft probably had to beef up the L2 to NB links to almost match that of the L1 to L2 links".. it was most most probably AMD NOT MSFT (perhaps for praising AMD, Charlei tung just sticks lol) since exactly the same thing is highly to suspect on the "Liverpool" SoC , just compare to http://www.vgleaks.com/world-exclusive-orbis-unveiled-2/ with http://www.vgleaks.com/world-exclusive-durango-unveiled-2/ (very identical *unified* Northbridge)... which *may* lead to conclude according the particularities, both SoCs will operate ~2Ghz for the CPU...

Also on that slide "SoC Components", the line from the bottom ESRAM to the CPU block, means that the 32MB ESRAM is visible from the CPU, probably as VGleaks suggested is I/O coherent, meaning the CPU can read it, but cannot write it in a coherent way (for this there is another link directly to GPU caches).

So Durango has a kind of large dedicated cache for the GPU (ESRAM), that is visible from the CPU, and is hUMA at total possible DRAM bandwidth... and is more advanced in some ways than Orbis, and could be a good preview for Kaveri.

There is no way that AMD (or Nvidia or ARM or Intel) can implement an Uniform Memory Access with discrete.

Perhaps you should get a job at AMD... they and their HSA friends, supposedly experts from top companies are to embark in an impossibility LOL

http://t1.gstatic.com/images?q=tbn:ANd9GcRvGiOpiosFpbI_dQ0Fhf-2w6RanklsgXec8ZHRWDd0vWt-JvHlSQ

The last thing that is supposed to finish the total specification, foreseen for middle next year (mid 2014 http://www.theregister.co.uk/2013/08/25/heterogeneous_system_architecture_deep_dive/?page=3 ) is exactly "Extend to discrete GPU" for this last push of "system integration" ... just see that image link, damn it lol ... (gee! could it be... HSA dumb juanrga smart!? LOL)

UPDATE :
And according to some analyses ( yes for one thing i would also like more details) http://mygaming.co.za/news/hardware/53750-amds-plan-for-the-future-huma-fully-detailed.html ... its not only for future, but hUMA of sorts already works with Discrete adapters of the HD7000 family

For bonus points, this works with discrete AMD graphics cards from the HD7000 family as well, although there will be some latency issues when accessing GDDR5 memory. Its possible to have the CPU, integrated GPU and the discrete GPU all working on the same thing.

Though it could be, even with PCIe (cc emulated), i think none of the drivers versions so far really supports this.

As I already said, the HSA specification doesn't mention hUMA in any part. In fact, I have just checked the specification again and there is no mention to uniform. The HSA memory model is described as a "unified memory model". Whereas the memory model in both Kaveri APUs and HSA dGPUs will be unified, it will be only uniform in the case of APUs.

unified != uniform

It seems some people (including at AMD) is confounding both concepts.

In fact, the confusion that AMD has introduced about hUMA is incredibly funny. What does hUMA mean? Has PS4 hUMA? Has XboxOne hUMA? Sometimes they have sometimes they don't, depending of the day and who replies emails at AMD.

One day AMD claims that PS4 is better than XboxOne because the PS4 has hUMA

http://www.fudzilla.com/home/item/32310-ps4-is-better-because-it-has-a-sense-of-huma-says-amd

Another day AMD claims that is "inaccurate". Then a supposed dev. who never did heard of hUMA before claims that XboxOne has hUMA or "something" as that

http://www.videogamer.com/news/xbox_one_has_implementation_of_huma_memory_system_just_like_ps4_say_dev.html

Pay attention to his exact words, because he confounds unified with uniform. Has XboxOne a unified memory model? Yes. Has a uniform memory model (UMA)? No.

But it can be funniest. When asked about the PS4/XboxOne controversy, AMD claims that both the PS4 and Xbox One processors are based on Kabini and that Kabini "doesn't support hUMA"

http://www.pcper.com/news/General-Tech/Sony-PlayStation-4-PS4-will-NOT-utilize-AMD-hUMA-Kabini-based-SoC

So [...] there is no support for a true heterogeneous unified memory architecture in either upcoming console platform.

Note that this uses again "unified" instead "uniform". Is this confusing enough? No?

AMD contacted me again to make another comment. Essentially, they said that the correction statement to the original statement claiming hUMA was part PS4 was "inaccurate" but that this correction does NOT mean the opposite claim is true. Even when pressed for a more specific and debate-ending comment, AMD wouldn't give us any more information.

And then more people try to make sense of this pseudo-quantum logic...

http://www.neoseeker.com/news/23716-making-sense-of-who-has-a-sense-of-huma-between-ps4-xbox-one/

by adding more confusion: The XboxOne may not have "AMD's hUMA per se", but does indeed implement a "comparable memory sharing feature".

It seems evident AMD is using two different meaning for hUMA and confounding everyone on Earth about that:

If hUMA is a uniform memory model for heterogeneous processors, then both Kaveri and PS4 have hUMA, whereas XboxOne and HSA dGPU don't.

If hUMA is a unified memory model for heterogeneous processors, then Kaveri, PS4, XboxOne, and HSA dGPU all them have hUMA.

I suspect AMD is using the last meaning, but UMA stands for uniform memory model. No strange all the confusion they are generating...

 

[de5_Roy]

Seems to me Itanic (the Itanium IA64 'Titanic' CPU of intel)... worst, one that is already leaking before leaving harbor lol

ahh. itanium+titanic... good one.

 

[griptwister]

This could possibly explain AM3+ Steamroller delays...

http://www.amdoverclock.net/g-skill-ddr4-memory-plans-unveiled/

 

[rmpumper]

This could possibly explain AM3+ Steamroller delays...

http://www.amdoverclock.net/g-skill-ddr4-memory-plans-unveiled/

How? AM3+ has nothing to do with DDR4. It can only hint at AM4 with DDR4 and Steamroller support. But the fact that there is zero info on any new AMD sockets other than FM2+ shows that AMD does not have any Steamroller CPUs other than Kaveri or they do not plan on making them in 2014.

 

[griptwister]

It can only hint at AM4

Exactly... So again, we might see SteamRoller CPUs that support AM3+ and AM4 Platforms. And I think you mean, Steamroller with DDR4 support. AMD said a while back, they are working on a new AM socket...

 

[blackkstar]

This could possibly explain AM3+ Steamroller delays...

http://www.amdoverclock.net/g-skill-ddr4-memory-plans-unveiled/

How? AM3+ has nothing to do with DDR4. It can only hint at AM4 with DDR4 and Steamroller support. But the fact that there is zero info on any new AMD sockets other than FM2+ shows that AMD does not have any Steamroller CPUs other than Kaveri or they do not plan on making them in 2014.

It is looking like, to some people, me included, that Steamroller FX (or replacment) has been pushed back for more HSA, DDR4 or, as mentioned earlier, HSA dGPU support.

Imagine AMD releases Steamroller FX on AM3+ with no HSA support. Now consoles come out and use HSA. Suddenly, the best gaming platform for AMD is APU + dGPU with APU GCN cores doing HSA work. It is self-defeating and now AMD high end CPUs are competing against AMD low end APUs, where APUs provide a superior experience.

AMD might have made their SR FX plans obsolete by snagging all these console design wins. It might make a lot more sense to postpone the AMD enthusiast segment until HSA exists on it in some workable form.

As seronx mentioned on OCN and as I calculated, if AMD uses 32nm HDL, that means 30% die size reduction, which means 6m/12c on about 330mm^2 die. Piledriver is 315mm^2 on 32nm without high density libraries.

That is possible what Warsaw is (16 core is two 4m parts on MCM with 2m disabled per core) 32nm HDL Piledriver 6m parts. So instead of selling highly disabled, large dies as FX 4000 position or FX 6000 position, AMD can stitch them together and sell them for far more than twice as much. Then leave 5m/6m parts to enthusiast desktop starting at $200 and leaving APUs to fill in the lower price segments.

However AMD waiting on SR for HSA with dGPU would be very good. It would mean they would have the only gaming platform where you can use all the HSA physics and particles and all that stuff that's going on in PS4 demos. It would mean you need AMD CPU with AMD platform that supports HSA on chipset as well as AMD dGPU, probably marketed as best served with Radeon Memory and Radeon SSD.

They would basically win gaming completely from Intel and Nvidia, meaning that every console port would more than likely use some sort of HSA and you could only get it on AMD platform. It is what Nvidia could only dream of for PhysX. It also means Intel iGPU is now reduced to OpenCL co--processor and it won't suffice for gaming, if ever, and it'll more than likely best be served by an AMD dGPU.

Of course, when I speculate on what AMD should do, they usually do something a lot worse, so I guess I'm just throwing this out there optimistically.

 

[rmpumper]

However AMD waiting on SR for HSA with dGPU would be very good. It would mean they would have the only gaming platform where you can use all the HSA physics and particles and all that stuff that's going on in PS4 demos.

Sony made a deal with nvidia to use PhysX in PS4. No AMD magic in it.

 

[8350rocks]

However AMD waiting on SR for HSA with dGPU would be very good. It would mean they would have the only gaming platform where you can use all the HSA physics and particles and all that stuff that's going on in PS4 demos.

Sony made a deal with nvidia to use PhysX in PS4. No AMD magic in it.

PhysX is not compatible with AMD hardware...NVidia has *no* presence in the consoles...period.

 

[-Fran-]

However AMD waiting on SR for HSA with dGPU would be very good. It would mean they would have the only gaming platform where you can use all the HSA physics and particles and all that stuff that's going on in PS4 demos.

Sony made a deal with nvidia to use PhysX in PS4. No AMD magic in it.

PhysX is not compatible with AMD hardware...NVidia has *no* presence in the consoles...period.

Its weird to read such ignorant remark on your part, 8350rocks. PhysX is just an API and it can use whatever resources you can feed it. You just need to "port" it like every piece of software out there.

Remember nVidia once approached AMD to license PhysX, but AMD said "no, up yours!". So it can be done if Sony accepted to have PhysX in their console no matter the hardware they sport.

Cheers!

 

[juanrga]

That is possible what Warsaw is (16 core is two 4m parts on MCM with 2m disabled per core) 32nm HDL Piledriver 6m parts.

I think you mean the 16 core Warsaw will be dual 4m, and 12 core Warsaw will be dual 3m (4m with one disabled).

 

[juanrga]

However AMD waiting on SR for HSA with dGPU would be very good. It would mean they would have the only gaming platform where you can use all the HSA physics and particles and all that stuff that's going on in PS4 demos.

Sony made a deal with nvidia to use PhysX in PS4. No AMD magic in it.

PhysX is not compatible with AMD hardware...NVidia has *no* presence in the consoles...period.

http://www.techradar.com/news/gaming/consoles/nvidia-to-offer-physx-support-on-amd-powered-ps4-1136063

http://www.engadget.com/2013/03/07/nvidia-rolls-out-apex-and-physx-developer-support-for-the-ps4/

[strike]ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo[/strike]

Another thing. Charlie's estimation of 1.9GHz for the XboxOne agrees with the idea of 2GHz being the jaguar core maximum beyond which efficiency is lost. I continue without buying the rumour that the PS4 CPU is clocked at 2.75GHz

http://www.cod-mw4.com/playstation-4-fcc-specs-2-75ghz-is-most-likely-not-cpu-ps4-heat-output-size-revealed/

 

[esrever]

However AMD waiting on SR for HSA with dGPU would be very good. It would mean they would have the only gaming platform where you can use all the HSA physics and particles and all that stuff that's going on in PS4 demos.

Sony made a deal with nvidia to use PhysX in PS4. No AMD magic in it.

I wonder how well that cpu physx is going to run on jaguar cores.

 

[8350rocks]

However AMD waiting on SR for HSA with dGPU would be very good. It would mean they would have the only gaming platform where you can use all the HSA physics and particles and all that stuff that's going on in PS4 demos.

Sony made a deal with nvidia to use PhysX in PS4. No AMD magic in it.

PhysX is not compatible with AMD hardware...NVidia has *no* presence in the consoles...period.

Its weird to read such ignorant remark on your part, 8350rocks. PhysX is just an API and it can use whatever resources you can feed it. You just need to "port" it like every piece of software out there.

Remember nVidia once approached AMD to license PhysX, but AMD said "no, up yours!". So it can be done if Sony accepted to have PhysX in their console no matter the hardware they sport.

Cheers!

Poor choice of wording...

PhysX is not the AMD API for physics...Sony could license it...though AMD has a physics API in place that they can supply without outsourcing to an additional vendor.

However, all sources I have encountered speak nothing of PhysX in the consoles...outside of old NVidia video card speculation. Once that rumor died, there was no more discussion of PhysX.

Understandably AMD would tell NVidia, their only real competitor in GPUs, that they would not license and pay a royalty to use an API similar to one they already had in place. It doesn't make sense to make your competition richer in a business world, unless there is a HUGE upside for your own potential gain as well...(and PhysX is falling by the way side as any sort of upside for a GPU as APIs improve)

 

[hcl123]

Charlei is incorrect.

its not the "The blue arrows above are for coherent memory accesses, yellow for non-coherent traffic"... if he had payed attention and not eager to sell more fish out of the same basket, if he had included the slide "GPU and GPU MMU clients"(http://cdn2.wccftech.com/wp-content/uploads/2013/08/Xbox-One-GPU-Architecture-635x481.png )(edt) as seen here http://wccftech.com/microsoft-xbox-one-architecture-detailed-hot-chip-2013-features-5-billion-transistors/, the second yellow/(green) line from the top for the "Host Guest GPU MMU", totally exposed in the "SoC Components" slide he analyses, but without the *comments*, says: "DRAM Access Non-CPU-Cache-Coherent 68GB/sec peak (incl coherent BW)", and that link goes exclusively to the DRAM controller that has 68GB/s peak, meaning all DRAM (system DRAM) is coherent to the GPU caches at max bandwidth possible, its the CPU block the one restricted to 30GB/sec (~half)... so Durango is hUMA...

And Durango is not 1+ year old design, matter of fact compared with PS4 design that uses Garlic and Onions as seen here http://www.vgleaks.com/playstation-4-architecture-evolution-over-time/ seems more advanced than Orbis( not very fond of M$ like Charlei, but skip the phobia)... thought Orbis will perform better at games( but probably not that much)...

Matter of fact the design is pretty identical to "onion + onion+" of Orbis, most included that remarkable piece of Northbridge in the slide "Soc components" (CPU-Cache-Coherent Memory Access)(edt) that Charlei analyses saying: "Microsoft probably had to beef up the L2 to NB links to almost match that of the L1 to L2 links".. it was most most probably AMD NOT MSFT (perhaps for praising AMD, Charlei tung just sticks lol) since exactly the same thing is highly to suspect on the "Liverpool" SoC , just compare to http://www.vgleaks.com/world-exclusive-orbis-unveiled-2/ with http://www.vgleaks.com/world-exclusive-durango-unveiled-2/ (very identical *unified* Northbridge)... which *may* lead to conclude according the particularities, both SoCs will operate ~2Ghz for the CPU...

Also on that slide "SoC Components", the line from the bottom ESRAM to the CPU block, means that the 32MB ESRAM is visible from the CPU, probably as VGleaks suggested is I/O coherent, meaning the CPU can read it, but cannot write it in a coherent way (for this there is another link directly to GPU caches).

So Durango has a kind of large dedicated cache for the GPU (ESRAM), that is visible from the CPU, and is hUMA at total possible DRAM bandwidth... and is more advanced in some ways than Orbis, and could be a good preview for Kaveri.

There is no way that AMD (or Nvidia or ARM or Intel) can implement an Uniform Memory Access with discrete.

Perhaps you should get a job at AMD... they and their HSA friends, supposedly experts from top companies are to embark in an impossibility LOL

http://t1.gstatic.com/images?q=tbn:ANd9GcRvGiOpiosFpbI_dQ0Fhf-2w6RanklsgXec8ZHRWDd0vWt-JvHlSQ

The last thing that is supposed to finish the total specification, foreseen for middle next year (mid 2014 http://www.theregister.co.uk/2013/08/25/heterogeneous_system_architecture_deep_dive/?page=3 ) is exactly "Extend to discrete GPU" for this last push of "system integration" ... just see that image link, damn it lol ... (gee! could it be... HSA dumb juanrga smart!? LOL)

UPDATE :
And according to some analyses ( yes for one thing i would also like more details) http://mygaming.co.za/news/hardware/53750-amds-plan-for-the-future-huma-fully-detailed.html ... its not only for future, but hUMA of sorts already works with Discrete adapters of the HD7000 family

For bonus points, this works with discrete AMD graphics cards from the HD7000 family as well, although there will be some latency issues when accessing GDDR5 memory. Its possible to have the CPU, integrated GPU and the discrete GPU all working on the same thing.

Though it could be, even with PCIe (cc emulated), i think none of the drivers versions so far really supports this.

As I already said, the HSA specification doesn't mention hUMA in any part. In fact, I have just checked the specification again and there is no mention to uniform. The HSA memory model is described as a "unified memory model". Whereas the memory model in both Kaveri APUs and HSA dGPUs will be unified, it will be only uniform in the case of APUs.

unified != uniform

It seems some people (including at AMD) is confounding both concepts.

In fact, the confusion that AMD has introduced about hUMA is incredibly funny. What does hUMA mean? Has PS4 hUMA? Has XboxOne hUMA? Sometimes they have sometimes they don't, depending of the day and who replies emails at AMD.

One day AMD claims that PS4 is better than XboxOne because the PS4 has hUMA

http://www.fudzilla.com/home/item/32310-ps4-is-better-because-it-has-a-sense-of-huma-says-amd

Another day AMD claims that is "inaccurate". Then a supposed dev. who never did heard of hUMA before claims that XboxOne has hUMA or "something" as that

http://www.videogamer.com/news/xbox_one_has_implementation_of_huma_memory_system_just_like_ps4_say_dev.html

Pay attention to his exact words, because he confounds unified with uniform. Has XboxOne a unified memory model? Yes. Has a uniform memory model (UMA)? No.

But it can be funniest. When asked about the PS4/XboxOne controversy, AMD claims that both the PS4 and Xbox One processors are based on Kabini and that Kabini "doesn't support hUMA"

http://www.pcper.com/news/General-Tech/Sony-PlayStation-4-PS4-will-NOT-utilize-AMD-hUMA-Kabini-based-SoC

So [...] there is no support for a true heterogeneous unified memory architecture in either upcoming console platform.

Note that this uses again "unified" instead "uniform". Is this confusing enough? No?

AMD contacted me again to make another comment. Essentially, they said that the correction statement to the original statement claiming hUMA was part PS4 was "inaccurate" but that this correction does NOT mean the opposite claim is true. Even when pressed for a more specific and debate-ending comment, AMD wouldn't give us any more information.

And then more people try to make sense of this pseudo-quantum logic...

http://www.neoseeker.com/news/23716-making-sense-of-who-has-a-sense-of-huma-between-ps4-xbox-one/

by adding more confusion: The XboxOne may not have "AMD's hUMA per se", but does indeed implement a "comparable memory sharing feature".

It seems evident AMD is using two different meaning for hUMA and confounding everyone on Earth about that:

If hUMA is a uniform memory model for heterogeneous processors, then both Kaveri and PS4 have hUMA, whereas XboxOne and HSA dGPU don't.

If hUMA is a unified memory model for heterogeneous processors, then Kaveri, PS4, XboxOne, and HSA dGPU all them have hUMA.

I suspect AMD is using the last meaning, but UMA stands for uniform memory model. No strange all the confusion they are generating...

Yes Kaveri carries the label, though not yet any details... and PS4 and XBO does really follow the model. XBO then is remarkable hUMA model (though they might not call it that way)... it has a direct link for CPU<->GPU cache coherent, and the second point to point link that goes for the mem controller and has the possibility of full bandwidth for this mem controller, is "MEMORY COHERENT"...

Even if charlei in is new article http://semiaccurate.com/2013/08/30/a-deep-dive-in-to-microsofts-xbox-one-gpu-and-on-die-memory/ only wants to see one p to p link for CC and another for DRAM (non cpu CC) that is not coherent, this DRAM link has possibility of coherency traffic(stated in the link comment)... only its not cache, its memory. What Charlei seems to suggest is that XBO will have the old model, the DRAM is partitioned one part for the CPU and another for the GPU block, and though it might have that for legacy concerns, it seems not at all the main approach. NOT AT ALL...

http://semiaccurate.com/2013/08/30/a-deep-dive-in-to-microsofts-xbox-one-gpu-and-on-die-memory/

IMAGE
https://semiaccurate.com/assets/uploads/2013/08/XBox_One_GPU_block_diagram.jpg

If the main DRAM is not partitioned some for CPU and some for GPU, then is already kind of HSA with only that. 2th link says "DRAM Access Non-CPU-Cache-Coherent 68GB/sec peak (incl coherent BW)"... and this link is obviously non-cache, its memory. Memory Coherency was always one of the features of HSA, its necessary for the relaxed memory model of HSAIL... matter of fact in 2011 no one talked yet of cache coherency, they talked of "memory coherency" and IOMMU kind of MMU could provide that, even over a discrete Radeon adapter. That was clearly stated at the presentation of GCN. So hUMA is an evolution of that, cache coherency is a bonus(so to speck) but the model of all those implementations, will be practically identical even if only AMD carries the label hUMA.

Understand ( the main issue is memory coherency not cache ) ?

 

[GOM3RPLY3R]

However AMD waiting on SR for HSA with dGPU would be very good. It would mean they would have the only gaming platform where you can use all the HSA physics and particles and all that stuff that's going on in PS4 demos.

Sony made a deal with nvidia to use PhysX in PS4. No AMD magic in it.

PhysX is not compatible with AMD hardware...NVidia has *no* presence in the consoles...period.

Its weird to read such ignorant remark on your part, 8350rocks. PhysX is just an API and it can use whatever resources you can feed it. You just need to "port" it like every piece of software out there.

Remember nVidia once approached AMD to license PhysX, but AMD said "no, up yours!". So it can be done if Sony accepted to have PhysX in their console no matter the hardware they sport.

Cheers!

About that. Wouldn't make sense to use a Nvidia based graphics solution, basically a GPU in this case if they are going with the AMD Jaguar processor? From what I understand from all the benchmarks and testing done, Phys X has a great advantage when used with Nvidia cards over AMD (even though there are a few select AMD cards that run it great compared to others).

 

[griptwister]

Lol, It'd be better if Sony used TessFX IMO. Also, AMD GPUs don't run PhysX, they run physics (Not Nvidia related and is general). What I think Gomer here is trying to say is some people run PhysX on their CPU; like me.

 

[-Fran-]

I don't know why, but I just lost my wall of text answer to you guys. I'm too lazy to write it again, haha.

Bottom line was: It doesn't matter if nVidia managed to convince Sony or not. They can port the API with little effort to whatever they want. And having hacked drivers is not indicative of how PhysX can run on AMD hardware with a proper software port.

Cheers!

 

[GOM3RPLY3R]

However AMD waiting on SR for HSA with dGPU would be very good. It would mean they would have the only gaming platform where you can use all the HSA physics and particles and all that stuff that's going on in PS4 demos.

Sony made a deal with nvidia to use PhysX in PS4. No AMD magic in it.

PhysX is not compatible with AMD hardware...NVidia has *no* presence in the consoles...period.

Its weird to read such ignorant remark on your part, 8350rocks. PhysX is just an API and it can use whatever resources you can feed it. You just need to "port" it like every piece of software out there.

Remember nVidia once approached AMD to license PhysX, but AMD said "no, up yours!". So it can be done if Sony accepted to have PhysX in their console no matter the hardware they sport.

Cheers!

Poor choice of wording...

PhysX is not the AMD API for physics...Sony could license it...though AMD has a physics API in place that they can supply without outsourcing to an additional vendor.

However, all sources I have encountered speak nothing of PhysX in the consoles...outside of old NVidia video card speculation. Once that rumor died, there was no more discussion of PhysX.

Understandably AMD would tell NVidia, their only real competitor in GPUs, that they would not license and pay a royalty to use an API similar to one they already had in place. It doesn't make sense to make your competition richer in a business world, unless there is a HUGE upside for your own potential gain as well...(and PhysX is falling by the way side as any sort of upside for a GPU as APIs improve)

If this is really the case with Phys X being used, with AMD's ignorance (as stated above), wouldn't they just opt out and not let Sony use any of their equipment? Just speculating.

 

[8350rocks]

I don't know why, but I just lost my wall of text answer to you guys. I'm too lazy to write it again, haha.

Bottom line was: It doesn't matter if nVidia managed to convince Sony or not. They can port the API with little effort to whatever they want. And having hacked drivers is not indicative of how PhysX can run on AMD hardware with a proper software port.

Cheers!

Indeed...it would be a software port and included in middleware if done. However, if I was AMD (though I am not), I would include my physics API in the total package, along with all my other proprietary software and drivers. Outsourcing PhysX, when it has no real clear advantage over the AMD physics API, makes little to no sense from many different angles.

 

[-Fran-]

Indeed...it would be a software port and included in middleware if done. However, if I was AMD (though I am not), I would include my physics API in the total package, along with all my other proprietary software and drivers. Outsourcing PhysX, when it has no real clear advantage over the AMD physics API, makes little to no sense from many different angles.

Part of my wall of text was saying something along those lines... What if publishers are the ones who actually want PhysX in the PS4 (and maybe XB1)? Like it or not, PhysX is a marketing sticker that works.

Also, what's the AMD physics engine? Bullit? Havok?

Cheers!

 

[8350rocks]

Indeed...it would be a software port and included in middleware if done. However, if I was AMD (though I am not), I would include my physics API in the total package, along with all my other proprietary software and drivers. Outsourcing PhysX, when it has no real clear advantage over the AMD physics API, makes little to no sense from many different angles.

Part of my wall of text was saying something along those lines... What if publishers are the ones who actually want PhysX in the PS4 (and maybe XB1)? Like it or not, PhysX is a marketing sticker that works.

Also, what's the AMD physics engine? Bullit? Havok?

Cheers!

Havok, if I am not mistaken...which is a good one in and of itself...

EDIT: Yes, since the P2 architecture has been Havok:

http://www.tomshardware.com/news/AMD-Havok-physics,5646.html

 

[esrever]

Physx will not run on AMD GPUs. Any software implementations would be at cost of the efficiency of the hardware. AMD doesn't need a physics engine since its up to the devs to either implement one or license one. For a dev to choose to use physx is unimaginable in the current situation. If nvidia could have just done gpu physx in software, why wasn't it in the ps3 or 360?

 

[Cazalan]

Bullet it Open Source.

https://en.wikipedia.org/wiki/Bullet_%28software%29


All this HSA talk is mostly marketing hype until some real tools come out for it. It's just in its infancy now.

 

[esrever]

Bullet it Open Source.

https://en.wikipedia.org/wiki/Bullet_%28software%29


All this HSA talk is mostly marketing hype until some real tools come out for it. It's just in its infancy now.

Tools can't come out until the specs are finalized next year.