Nice summary Ethomaz,
I'd just add that the problem is not that SteamBoxes are 'incapable' of Mantle compatability,
there's no reason a Linux game shouldn't be able to target Mantle just as well as Windows box can,
(with Mantle being a graphics API promising lower level optimization than available thru DX/GL)
but that SteamBox is not a homogenous platform, it's basically just software compatability for Linux PCs.
Steamboxes already comprise a WIDE range of specs, including different CPU and GPU OEM's.
So you simply can't make the same type of narrowly applicable optimizations,
NVIDIA is simply not Mantle compatable even if AMD makes noise about it being hypothetically possible,
NVIDIA is not currently on board and hasn't done what's needed to make that happen...
Even if a Steambox game has a Mantle code-path for AMD GPUs, it also needs a separate codepath for NVIDIA,
so the same amount of dev resources is going to be split/weakened, not to mention that making a few 'generic'
Mantle optimizations for any and all AMD GPUs is far different than maxing out one specific GPU/CPU/RAM combo.
This is besides the difference in GCN 1.0 vs. 1.1*, which certainly should make a difference in such things,
as well as things simply not possible on Steambox, such as integrated memory and deeper optimization
than even Mantle can't offer (even if just targetting one specific AMD GPU):
if it was equivalent, then Sony would have just USED Mantle as their API, but they went further than that.
That said, most of the above advantages of PS4 are really only likely to show up in exclusive games, anyways.
For crossplatform games, it should be pretty damn similar experience to PS4,
probably slightly better at this point (of software optimization) although even crossplatforms should soon make better optimization for PS4
If Steambox picks up 'steam' as a viable platform for PC gaming, this looks like it could be a good
deal for anybody interested in that and happy with performance similar to PS4...
* From Anandtech: (me in bold)
As such the bulk of the changes that come with GCN 1.1 are compute oriented, [re: GPGPU/ ACEs] and clearly are intended to play into AMD’s plans for HSA by adding features that are especially useful for the style of heterogeneous computing AMD is shooting for.
The biggest change here is support for flat (generic) addressing support, which will be critical to enabling effective use of pointers within a heterogeneous compute context. [integrating threads on CPU with GPCPU threads on GPU sharing data between them both ways] Coupled with that is a subtle change to how the ACEs (compute queues) work, allowing GPUs to have more ACEs and more queues in each ACE, versus the hard limit of 2 we’ve seen in Southern Islands. The number of ACEs is not fixed – Hawaii has 8 while Bonaire only has 2 – but it means it can be scaled up for higher-end GPUs, console APUs, etc. Finally GCN 1.1 also introduces some new instructions, [more types of programs to run on GPU] including a Masked Quad Sum of Absolute Differences (MQSAD) and some FP64 floor/ceiling/truncation vector functions.
