Hardware for Media Hub features in both the XB1 and PS4 "kinda confirmed"

#53
It's not for the devs to code for, it's OS level'
And if people will read the posts, Page 2 here has reference to routines already part of the DPU instructions that would be used for AA.
Bilateral Filter
• Highly selective, edge preserving filter
o Noise reduction, edge preserving blur, 3D depth filtering and many other apps
• Uses dot product of two kernels:
Xtensa processor instructions are already optimized for video and when custom designed by Sony, more for games can be added. These instructions should make a game developers job easier and off-load from the CPU and GPU
 
#54
I'll add that threads like this always make me a little upset because people gather information from them and then repeat it as though its gospel.

There is nothing new here and there is no secret sauce. Sure, there is built in logic for decoding audio/video/peripheral support but that is totally commonplace and expected in any modern hardware (seriously, look at a block diagram for any modern SoC).

You aren't going to see more power unlocked or crazy AA solutions. That's just nonsense.

If you want s real idea what the second ARM CPU is for just go back to the original PS4 unveiling:

A healthy dose of skepticism and an open mind is always a must in these types of threads. That said, if you do your homework on Cadence Tensilica Xtensa DPUs and understand that Nvidia and AMD have signed contracts to use Xtensa processors in their GPUs in addition to Sony and Microsoft (2004 AMD (early UVD), 2007 Sony (blu-ray players), NVIDIA 2005) it answers all the wild speculation on secret sauce.

Edit: The ARM processor is there for background processes and as a Trustzone DRM processor which securely manages code for the Player and Codecs. It will handle secure boot and Playready 3.0 requirements.

Wild rumors from MisterXmedia of a XB1 second GPU (a Xtensa video DPU can act as a second SMALLER low power GPU) and it being a "Stereo" GPU (two video DPUs) with 2.5TFlops/sec of processing performance can be understood if "moles" misunderstood the specs in that 2 IVP DPUs could provide 2 Tops/sec...notice the missing "F" Floating point ops/sec is not the same as Ops/sec. Page 3 here.. TDP (heat/leakage) in a 2.5TF GPU at even 20nm is not possible in the XB1 GPU.
 
#55
Better quote for OpenVX final release Oct 20, 2014:

With today’s announcement, however, OpenVX officially becomes an industry standard that can be commercially deployed within products and developed for immediately. This finalized and ratified OpenVX 1.0 version brings a laundry list of features that help abstract the underlying computer vision interaction with hardware in order to make cross-platform implementations more possible.

Keep in mind that OpenVX is an API abstraction that makes implementing computer vision easier and more vendor agnostic while also giving more tools to improve performance and optimize power consumption.

there are now two implementations of OpenVX that prove the design, one being a Khronos sample implementation that will be available opne source by the end of the year, and another from Nvidia that is already working in the alpha phase as part of the VisionWorks vision SDK.
Again Nvidia and AMD have signed contracts with Tensilica to use their DPUs in GPUs to support OpenVX. As of this month Nvidia is still in alpha phase so even if dGPUs have DPUs the OpenVX drivers are not likely done. Until AMD and Nvidia implement this, only Game consoles are likely to have support for OpenVX using embedded hardware.

So the PS4 and XB1 will likely have OpenVX support before PCs and any program using OpenVX ported to PCs will be after it's seen on a console.
 
#56
OpenKCAM projected for ratification 1Q2015 is the last Khronos open standard needed after OpenVX (10/20/2014) for complete vision support from camera through dedicated low power hardware for VR and Skype/Chat programs. It's speculated by Khronos that OpenCL, OpenVX and OpenKCAM will become W3C extensions to HTML5.

I suspect that the PS4 and PS3 will get Skype support 1Q2015. 6/2014 Sony posted 150 job listings and most involved Internet servers and HTML5 apps. When should those jobs first produce HTML5 apps for Sony products... late this year or 1Q2015. I only bring this up because it shows a timeline for VR and Vision games starting in 2015 which should be the same for the XB1.

I supect the Dec 6th Playstation experience in Las Vegas will tout what's coming in VR and casual games using the camera and Move accessories. If they do then 2.0 likely contained OpenVX APIs using dedicated accelerators (Xtensa DPUs) rather than OpenCL and using the GPU.

Game consoles will peak in sales when they offer features that the average consumer will want not for the small percentage of the population that want's AAA games. In my opinion, this generation game console is going to peak in sales late 2015-2016 when casual games with gesture control or Move or accessories make it easier to play and when IoT, VR, Innovative new forms of information, apps are HTML5 and the DLNA CVP2 ecosystem takes off.

Everyone will need a STB or Smart TV by 2017+ when Cable TV moves to all IPTV and the three network convergence is implemented (VOIP, IPTV and IP) as well as for ATSC 2.0 OTA. This is why there are 10 game consoles being released (including the XB1 and PS4 and might include the PS3 and Xbox 360) by the end of 2014. They are all STBs that can support the DLNA CVP2 ecosystem and some are priced in the $99 -$149 price range (Accessories like game controller and Camera extra).
 
#57
Sony Job posting 10/31/2014 Principal Engineer specializing in PlayReady

The primary role involves securing a well-known DRM solution to be used on PLAYSTATION®3, PlayStation®4 and PSVita™ for multimedia applications. You will be part of a small team composed of other software engineers based in London. You will work with this team to enhance the implementation and support integration. This is a contract role with the possibility to extend its duration.

Responsibilities
• Porting and securing of software components on multiple platforms such as PLAYSTATION®3, PlayStation®4 and PSVita™.
• Keeping implementation on target to meet a tight schedule
• Supporting the integration of software components with client applications being designed and implemented on parallel schedules
"enhance the implementation and support integration."

DRM in HTML5 <video>ME and modern IPTV apps have three parts: 1) at the lowest level embedded routines only the platform holder knows which include the codec, hidden keys and Metadata routines the player must run under. 2) Middle ware that exposes APIs to Javascript for the Media Extensions and to the 3) Playready DRM in IPTV apps. The DRM Middleware and Playready routines are routinely changed to keep them secure but the embedded routines usually stay the same and every effort is used to keep them secure by the platform owner.

So PS4 Middleware (nearly done) and embedded routines are likely done (had to wait till the Xtensa DPU routines were in place with I think Firmware 2.0) but the full DRM scheme is not finished . In any case DLNA CVP2 certification comes after Playready and WMDRM10 DRM are in place. Since Vita got DLNA support it likely is further along and has Playready Middleware and embedded routines finished.

The PS4 and XB1 as media hubs will be special cases as they can Playready sideload and stream inside the home using DTCP-IP and likely stream outside the home using Playready. This will use the Encoder that Share 2.0 exposes for games.

A significant OS change is coming for Playstation platforms PS3, PS4 and Vita with all current IPTV apps not using the Playstation software stacks for DRM except possibly Sony apps.

In the PS4 it means all IPTV apps were/are X-86 and didn't use the DPU codecs and Trustzone processor. DLNA should be a low power app and not use the X-86 CPUs or AMD GPU, same for the blu-ray player and IPTV apps as well as DLNA CVP2 which additionally should use a second low power GPU for the UI which Xtensa DPUs can support. This is the reason for the PS4's unexpectedly high power use, same for the XB1. They are both at nearly the same state for Players, codecs and DRM.

In the PS3 it means all the DTCP-IP DRM routines tied to the DLNA player and DRM for the IPTV player are being changed. To reduce the OS size and insure DRM the DLNA player, HTML5 player and blu-ray-DVD player should be the same using the same Metadata rules and DRM. It's not clear when or if this has already been done. Edit: According to DRM today; the PS3 is still using Marlin which means a significant firmware update to the PS3 is coming or DRM today is out of date.

If DRMtoday is accurate the coming firmware update should have DLNA and HTML5 updates to support DLNA CVP2. For DLNA it means the three box model with the PS3 able to be controlled by a second screen DLNA controller. The PS3 XMB may be updated to a openGL desktop like the PS4 (my prediction since late 2011) or the DLNA CVP2 app and browser only will support OpenGL.
 
#58
Sony Job posting 10/31/2014 Principal Engineer specializing in PlayReady



"enhance the implementation and support integration."

DRM in HTML5 <video>ME and modern IPTV apps have three parts: 1) at the lowest level lembedded routines only the platform holder knows which include the codec, hidden keys and Metadata routines the player must run under. 2) Middle ware that exposes APIs to Javascript for the Media Extensions and to the 3) Playready DRM in IPTV apps. The DRM Middleware and Playready routines are routinely changed to keep them secure but the embedded routines usually stay the same and every effort is used to keep them secure by the platform owner.

So PS4 Middleware (nearly done) and embedded routines are likely done (had to wait till the Xtensa DPU routines were in place with I think Firmware 2.0) but the full DRM scheme is not finished . In any case DLNA CVP2 certification comes after Playready and WMDRM10 DRM are in place. Since Vita got DLNA support it likely is further along and has Playready Middleware and embedded routines finished.

The PS4 and XB1 as media hubs will be special cases as they can Playready sideload and stream inside the home using DTCP-IP and likely stream outside the home using Playready. This will use the Encoder that Share 2.0 exposes for games.

A significant OS change is coming for Playstation platforms PS3, PS4 and Vita with all current IPTV apps not using the Playstation software stacks for DRM except possibly Sony apps.

In the PS4 it means all IPTV apps were/are X-86 and didn't use the DPU codecs and Trustzone processor. DLNA should be a low power app and not use the X-86 CPUs or AMD GPU, same for the blu-ray player and IPTV apps as well as DLNA CVP2 which additionally should use a second low power GPU for the UI which Xtensa DPUs can support. This is the reason for the PS4's unexpectedly high power use, same for the XB1. They are both at nearly the same state for Players, codecs and DRM.

In the PS3 it means all the DTCP-IP DRM routines tied to the DLNA player and DRM for the IPTV player are being changed. To reduce the OS size and insure DRM the DLNA player, HTML5 player and blu-ray-DVD player should be the same using the same Metadata rules and DRM. It's not clear when or if this has already been done. Edit: According to DRM today; the PS3 is still using Marlin which means a significant firmware update to the PS3 is coming or DRM today is out of date.

If DRMtoday is accurate the coming firmware update should have DLNA and HTML5 updates to support DLNA CVP2. For DLNA it means the three box model with the PS3 able to be controlled by a second screen DLNA controller. The PS3 XMB may be updated to a openGL desktop like the PS4 (my prediction since late 2011) or the DLNA CVP2 app and browser only will support OpenGL.
Does this mean power draw will be reduced? Will this increase performance of the PS4? So many words, so little I understand:(
 
#61
Well, if media apps run off of the APU right now, and then were moved to the DSP in the future, wouldn't that mean that both Sony and MS could free up one of the reserved cores for the OS and use it for games then? Just thinking out loud here.

Edit: changed dpu to dsp
 
#64
OnQ123 posted in BY3D on Features in Share Firmware 2.0:

So yes Firmware 2.0's major features for games are Vision Libraries but using OpenCL (GPU Compute) not OpenVX low power routines with a Xtensa video DPU. Not described but part of the Vision libraries are OpenKcam features which have to take place in the Southbridge.

Some of the OpenCL routines can be replaced with OpenVX low power dedicated hardware in the Southbridge, some must be done in the GPU because of latency. Panajev2001a as usual is correct and it's too soon for OpenVX to be in PS4 firmware. (some of the vision routines using OpenCL will eventually be replaced with OpenVX APIs).
 
#65
There has been a firestorm created by this article: New 4K-Capable PS4 And Xbox One Consoles Coming This Year, Predicts Netflix. What's not understood is that both Microsoft and Sony designed their consoles to be media hubs and 4K blu-ray players....the current version supports everything needed for 4K streaming and 4K blu-ray with a firmware update. That's a strong statement from me and I'll support it:

1) PS4 is Feature-proved" means they have a list of coming features with the hardware designed/proved to be able to support those features.

2) There is a patent from Sony describing how they might implement 4K blu-ray and the issue is that older drives can support it but not reliably. Their fix is to invert the track info on 4 K disks so older drives can't support 4K but 4K drives can still support standard blu-ray. The patent is from 2010 and likely is about the BD-R whitepaper specs to allow BDXL among other things (4 layer Recordable which is harder to read than the coming 3 layer with Panasonic tweak Read only masters). Proof developed here.

3) 4K Blu-ray Confirmed, Coming in Late 2015

4) Movie industry requirements for DRM that Playready and HDCP 2.2 follow

5) Tee Level DRM requirements for on-line transactions. XTV is going to support On-line transactions. This requires the greatest level of security, "TEE level DRM"

6) Game console power regulations Applies to newer Consoles but speculation on older all wrong.

7) Game consoles to replace cable boxes and the connected home starts in 2014

8) Sony second GPU patent. Mentioned in the leaked Xbox 720 powerpoint and in a Microsoft 2 GPU patent as well as letters to the EU power board.

The PS4 has a custom Panasonic HDMI chip. Why custom if not to support HDMI 2 and HDCP 2.X. HDCP can take place in the PS4 southbridge where the Trustzone processor and Cadence-Tensilica Xtensa DPU stream processors reside. The HEVC codec in both the XB1, PS4, Kaveri and Carrizo, in fact all codecs, compression and streaming DRM are software based on Xtensa processors. (not officially confirmed)

Xtensa DPU processors will be in new 4K connected Blu-ray players and some handheld chipsets for OpenVX, Codecs, DRM, upscaling, post processing, Gesture and voice recognition. These same features are supported by Xtensa processors in AMD APUs and Game consoles.

If you read the Movie industry requirements for DRM, it requires a firmware update-able, revocable DRM with watermarking. Further, encryption from Source to Sink and for streaming DRM, that's Playready into the PS4 southbridge and HDCP 2.X out of the southbridge. Having unencrypted video from southbridge to a HDMI chip would violate best practice and Content provider guidelines. Further TEE level DRM for on-line purchases also requires the GPU (for customer assurance ICONs) to be inside the same SoC with all IO and everything managed by a Trustzone like processor (protected virtual processes). The Xtensa DPU can also be used as a low power GPU.

So a low power GPU for TEE customer assurance icons and watermarking the video is needed in the same IC with the encryption. A low power GPU is also needed when the PS4 is acting as a Vidipath (DLNA CVP2) client or in nearly all IPTV power modes and app modes except for when playing a game and then there are recommended IDLE power standards. A Low power GPU is not needed for a RUI (DLNA CVP2) server but is needed for a RVU server.

Edit: A GPU is not needed for a RVU client, it's a Pixel accurate picture of the menu that is sent from server to client. A PS3 can only be a RVU client at this time. After Playready certification, work on the PS3 browser to support WebGL, DLNA and other W3C extensions and likely a XMB upgrade to support a browser desktop, it should support everything but power modes.

If Sony designed the PS4 to be a media hub then the above is already supported by the PS4 design. The same applies to a Xbox 360 and PS3 refresh if coming and is the basis of my speculation on how this would be accomplished.

Further as predicted in 2011, the PS4 has a browser desktop with everything loaded in memory to support HTML5 which supports APPs and nearly instant support for TV (DLNA CVP2) streamed from a Media gateway (First DVRs then Cable Modems). I predicted the PS3 would have the same for the same reason but it appears there is a openGL security issue that might be fixed and if so that is still coming.

The above is obvious if you understand how BIG this three network convergence - DLNA CVP2 ecosystem will become.
 
#66
Hey Jeff,
I remember you linking a video where I believe it was an american cable provider that was demoing a PS4 app that streamed video over the local network to the PS4 from a receiver box. With a guide overlay.

Has that been released yet?
 
#67
Hey Jeff,
I remember you linking a video where I believe it was an american cable provider that was demoing a PS4 app that streamed video over the local network to the PS4 from a receiver box. With a guide overlay.

Has that been released yet?
RVU Dish Joey which is a subset of RUI (DLNA CVP2) has been released but it's just with DISH DVRs so no, Tivo sued the FCC and that moved the FCC DLNA CVP2 mandate to June 2015. RUI =Vidipath=DLNA CVP2 has to be certified and will work with all cable TV companies and allows copying media from certified platform to certified platform. Vidipath platforms will also support WebRTC which supports video chat between all vidipath platforms.

There are other snags like Microsoft-Google-Erricson not agreeing on some of the WebRTC standards and since it was delayed Sony wanting to include HEVC support which is a BIG feature that allows Playstation Vue to be viable considering the state of the Cable industry internet bandwidths and Caps.

Latest quote from Sony in their quarterly report is that Vue will be mainstream March 2015. Which is also when "rumors" have DLNA and Friend Notification which are also low level routines in Southbridge. So suspend resume should come when Sony publishes the APIs to southbridge routines to APP developers. That comes after Sony certifies the PS4 with DTLA and DLNA and that should occur before June 2015.

http://gamingbolt.com/sony-looking-at-providing-smaller-more-frequent-ps4-updates#LMs85W3KM7QuYlq6.99 said:
Speaking about the PS4&#8217;s update situation to VentureBeat, SCEA&#8217;s Shawn Layden said that Sony was looking into doing smaller, more frequent PS4 firmware updates, and at adding more and more features to it in 2015-
 
#69
*edit* responded to a month old post because of the necrobump.
Not trolling, I'm documenting and supporting my statements with walls of text so that you can easily find and trash me if I'm wrong:

=Shin Johnpv said:
You're wrong, you don't understand the consumer or what you're talking about, and all you do is write walls of text. Just stop.

you're not the technoNostradamus that you think you are either. Every one of your threads is you typing out paragraphs of technobabel and making wild predictions that never come true. Anyone who tries to debate you just gets walls of text of more babel that shows a lack of truly understanding what you're talking about.
Coming PS4 Remote credit GraphiteGB

 
#73
The full text should be posted with that, because it seems to me that its not coming.

Re: PS4 BD Remote
OPTIONS
Nov 13, 2014
SCEI announced in October 2013 that they SCEI were NOT making any BT extras for the PS4...

And that if third parties want to they could buy a Officail license for access to the PS4 BT...
Emulation of the BD player controlls on DS4 requires a license...

They have licensed BD remotes but NONE of them have ever shown up for sale ... they have all been with drawn from sites by their makers ...
The LAST FULL officail licensed remote to show up was a clone of a HDTV remote with extra PS4 buttons...
PDP-Universal-Media-Remote-for_PS4_03.jpg
PDP-Universal-Media-Remote-for_PS4_02.jpg
But SCEI altered the BD controlls from the PS3 version and added extra options on triangle recently which requires TIMED controll signals... to trigger new menu
The BD player button mapping is also the reverse of normal controlls with circle being play now not close...

O and even IF the remote is released the App makers can break support for it Just like the broke the use of HDMI-CEC by not using just the D-pad and enter/ok for every thing....
Keywords in there are "...even IF the remote is released...."
 
#74
The full text should be posted with that, because it seems to me that its not coming.
Keywords in there are "...even IF the remote is released...."
GraphiteGB is a beta tester in the UK and knowledgeable. I've had many interesting discussions with him for the last three years. A BD remote should not be necessary if you have a TV that supports CEC and a multi-function remote, PS4 camera and use voice and gesture or have a phone or tablet which can be used as second screen and remote. This known since very early on, years before the 2013 Sony statement you cited so why is there a picture of a finished PS4 BD remote? It's a cheap and easy to produce product for those who do not have a PS4 camera and do not have a phone or tablet. When will it be needed...sometime late 2015 which is when another thread on the same forum stated it was coming. This is when 4K blu-ray is being released with the PS4 and XB1 in the same position the PS3 was in 2006-2008 as the best blu-ray player for the money and firmware updateable, this time 4K blu-ray.

Edit: It's possible that a newer design supporting touchpad is making the older BD remotes obsolete. It's not just 4K Blu-ray that is coming, it's XTV too and that requires some way to interface with a browser. That's why the touchpad on the PS4 controller.

RE: Sony supporting DLNA CVP2=RUI=Vidipath

https://www.linkedin.com/jobs2/view/13896747 said:
This Software Project Manager is responsible for attending and representing Sony in multiple industry forums, such as working closely with MSOs (Cable TV providers) on Regulation and standardization for DLNA, HTML5 RUI, CVP2, HDMI, MHL, and other related technologies.

Solid experience in HTML5, DLNA, and UPnP
Solid knowledge of HDMI and MHL technologies
Solid knowledge of DLNA CVP2 certification process
Provide knowledge to W3C on testing and specifications related to HTML5
Solid understanding of DTCP encrypted MP4 DASH content
But in 2013 Sony ALSO said the PS4 would not support MP3 and DLNA. But the MP3 Software license is listed in the PS4 and the above 1 year old job posting is to represent Sony on DLNA RUI = DLNA CVP2=Vidipath and that posting 2 months after Sony said they would not support DLNA on the PS4.

Notice it mentions HDMI likely referring to HDMI 2 with special attention to the new HDCP.

Don't believe everything you read or hear from Sony, RESEARCH for yourself and read the links I cite. Don't believe me, read the cites...I can be wrong but I ALWAYS cite.

Re: 2.5D stacked memory...I cited several papers from Industry sources stating the game consoles would have stacked memory and they and I were wrong...likely 2 years too early. 2.5D interposers were needed for the Yukon version of the XB1 to have a Xbox cpu for backward compatibility and that didn't happen either. 2.5D interposers, HBM and 3DS are ready as of late 2013 with custom controllers coming that use the same DRAM stack that HBM uses.
 
#76
Lots of products are made, beta tested and never make it to market. Again key words from the dude himself are "...even IF the remote is released....".

There's a lot of variables up there, if they have a certain tv type, or the camera, or this. Alot of people don't and a cheap remote would probably make those people happy.

You do realize that Sony is a giant electronics company, they make all kinds of home products that make use of things like MP3 playback, DLNA, and other such things. Just because they're hiring for some one to work on software that supports that, doesn't in anyway suggest its for the PS4. I just bought a cheap Sony bluray player that supports MKV playback, and yet that's not something the PS4 can do.

It doesn't matter what you cite, you jump to Nostradamus like conclusions on everything. That's why you've been wrong on pretty much everything you've predicted for the PS4.


Just because Sony is hiring software people for something, or looking into some new hardware design doesn't instantly mean its going into the Playstation 4. Look at this thread, claiming there's secret media hub chips on the motherboard, and trying to use a generic Sony electronics job ad, and a probably not going to happen BD remote to prove it.

There's no secret chips on the PS4 or XB1 that we don't already know about.
 
#77
RVU Dish Joey which is a subset of RUI (DLNA CVP2) has been released but it's just with DISH DVRs so no, Tivo sued the FCC and that moved the FCC DLNA CVP2 mandate to June 2015. RUI =Vidipath=DLNA CVP2 has to be certified and will work with all cable TV companies and allows copying media from certified platform to certified platform. Vidipath platforms will also support WebRTC which supports video chat between all vidipath platforms.
This has been out for about 9-10 months. It's a Dish app that acts as a Virtual Joey (paired with a Hopper). I have it on my PS3 (it was released for the PS4 at the same time) and gives you all the functionality of a Joey but in software-form, including guide and VOD functionality. I use it almost daily and it works flawlessly.

Know that video apps on the PS3 are currently locked at 720p (don't know if it's the same restriction for the PS4) which is the only limitation. The app even does PCM surround sound.
 
#79
Lots of products are made, beta tested and never make it to market. Again key words from the dude himself are "...even IF the remote is released....".

There's a lot of variables up there, if they have a certain tv type, or the camera, or this. Alot of people don't and a cheap remote would probably make those people happy.

You do realize that Sony is a giant electronics company, they make all kinds of home products that make use of things like MP3 playback, DLNA, and other such things. Just because they're hiring for some one to work on software that supports that, doesn't in anyway suggest its for the PS4. I just bought a cheap Sony bluray player that supports MKV playback, and yet that's not something the PS4 can do.

It doesn't matter what you cite, you jump to Nostradamus like conclusions on everything. That's why you've been wrong on pretty much everything you've predicted for the PS4.

Just because Sony is hiring software people for something, or looking into some new hardware design doesn't instantly mean its going into the Playstation 4. Look at this thread, claiming there's secret media hub chips on the motherboard, and trying to use a generic Sony electronics job ad, and a probably not going to happen BD remote to prove it.

There's no secret chips on the PS4 or XB1 that we don't already know about.
RE: MKV playback MKV container, MP3 & AVC (Audio) as well as AVCHD (Video codec) are HTML5 standards that will be supported by all Vidipath platforms and HTML 5.0 FACT. This is again just an example of the firmware updates from Sony being slow.

RE: BD remote. I'm not trying to prove anything with the BD remote. I just found it in one of GraphiteGB posts and posted it here. I tried to find the thread where he states it's coming and couldn't...I don't think it's of enough interest to spend time on a search but if you notice the picture I provided is not from the thread I immediately found and you cited. There is enough to put this coming in doubt....

RE: you've been wrong on pretty much everything you've predicted for the PS4

I'm not the only one that has this information! "They also both use Cadence Tensilica Xtensa video DSPs for the video playback (AMD's UVD). "

The point is we know about the Xtensa DPUs as Trueaudio supported by Tensilica dsps but unless you do the research (onQ123) you don't put together that the DSP is inside a Xtensa DPU. The only speculation I'm making is that the XB1 and PS4 are using Xtensa video processors which are a more powerful version of the HiFi DSP and also in AMD's Kaveri for h.265. This is in the OP as the GPU-like Compute module mentioned by Eurogamer.

Many are making the assumption that the codecs in AMD APUs are in the XB1 and PS4 APU. This supports Xtensa video DPUs in both...are they wrong? I early on disagreed with this in that I believe the codecs for the PS4 are in the Southbridge chip as they are designed for a ARM buss. IPTV requires a low power mode and Sony using GDDR5 with the PS4 APU can't support a low power mode like the XB1 can which uses DDR3 not the higher power and performance GDDR3 or GDDR5. Sony moved the ARM IP out of the APU and put it in the Southbridge with it's own 256MB DDR3 and with the next revision I hear it will be LPDDR3.

You do know that suspend-resume is nearly useless with the current IPTV APPS. Please follow:

1) If the APP uses GDDR5 and the AMD APU then everything must remain on and suspend-resume is only a quick power on mode for games.
2) When running an app or game everything is on pulling 90+ watts
3) The wait for suspend resume makes no sense in this case as suspend resume in this model is just moving a memory pointer in a CPU and GPU (simplistic explanation but nearly correct).

Suspend resume will have APPs running in the Southbridge with the AMD GPU off and GDDR5 in self refresh, this requires a second low power GPU in Southbridge. This is why there are two nearly seperate SoCs/APUs with two operating systems and two seperate memory pools with 256MB DDR3 for the Southbridge, an extreme overkill for just Network Standby features.

RE: two GPUs

8) Sony second GPU patent. Mentioned in the leaked Xbox 720 powerpoint and in a Microsoft 2 GPU patent as well as letters to the EU power board.

If you read the Sony patent it talks about "Graphics processing in a computer graphics apparatus having architecturally dissimilar first and second graphics processing units (GPU) is disclosed. Graphics input is produced in a format having an architecture-neutral display list. One or more instructions in the architecture neutral display list are translated into GPU instructions in an architecture specific format for an active GPU of the first and second GPU." Architecturally dissimilar I took early on to be small APU + dGPU and ARM GPU + AMD APU but always understood it was about a low power mode for apps and IPTV.

The Xtensa DPU GPU compute like feature can be used as a low power GPU. If you look at the block diagrams it's similar to Cell in that there is a controller and up to 32 simplier processor blocks. GPU shaders are very simple CPUs just as Cell SPUs and Cell can act like a GPU.



The following slide is from the Yukon version of the XB1 and it has two GPUs, one is always on and the larger 3X faster GPU with CPUs can be turned off.

 
#81
I have to say ... I have no freaking idea what the hell is going on in this thread.
In the OP, Xtensa IVP and Hifi can provide all the LOW POWER features needed by a STB and Blu-ray player including acting as a second smaller GPU. They can do AR and VR as well as gesture and voice recognition.

Xtensa IVP and Hifi are in the XB1 and PS4. Some don't believe this and some don't believe Sony designed the PS4 as a Media Hub to support Vidipath, 4K streaming and blu-ray with just a firmware update.

Xtensa IVP and HiFi are the DSPs for AMD when they talk HSA/HSAIL for CPU, GPU, DSP and FPGA and are in Kaveri and Carrizo. Everyone should be up on this soon. Presently BY3D and Semiaccurate en masse are clueless as are most industry reporters.
 
#82
Cadence IP



Notice it's ARM/X86 in the block diagram above! They provide a custom IOMMU 2 (2.X supports HSAIL/HSA) that interfaces an ARM bus with AMD X-86 bus. The XB1 APU blocks are Cadence IP designs with the exception of the GCN GPU, SRAM cache and Jaguar CPUs. All the features touted by AMD like Displayport, multiple monitor support, HDMI port, codecs and more are cadence IP. In newer APUs, more of the Northbridge becomes Cadence-Xtensa ARM IP and Southbridge the same moved into the APU which becomes a SoC.

Using configurable Xtensa processors and custom software IP, Cadence can support multiple features needed in current and future embedded designs including HDCP 2.2.

Their SerDes IP can support PCIe, Ethernet, USB, SATA and in the future HMC (Hybrid Memory cube). Is it now understood that the PS4 southbridge can EASILY be nearly all Cadence IP using off the shelf Cadence IP and Xtensable CPUs. Cadence IP can also support High Bandwidth Memory.

IF the PS4 used HBM then it could support GDDR5 speed and also support a low power memory mode equal to LPDDR3. Sony would not have needed to move the low power ARM IP out of the PS4 APU into Southbridge with it's own 256MB DDR3 to support low power modes. I'd guess that sometime around 2016-2017, Southbridge functionality will be moved into the PS4's APU using HBM. PS4's APU will look something like the XB1's which had to use DDR3 to support low power modes with the ARM blocks in the XB1 APU. The XB1 will move it's southbridge into the APU also and both become cheaper SoCs. With the availability of HBM, the XB1 shouldn't need the 32MB SRAM cache or they will use 3DS memory and keep the expensive Cache.
 
#83
What&#8217;s confusing everyone is the slow progress in updating the Firmware to support new features including 4K Blu-ray. As mentioned by Sony, there are some features that can&#8217;t be incrementally implemented&#8230;.they will come in larger blocks.

The need for a IPTV power mode and secure DRM for both the XB1 and PS4 required them to have a ARM block with multiple virtual engines (3) in the XB1 and two separate SoCs with their own OS in the PS4. This is NEW territory with standards being created almost as they are implemented in both consoles. For example, PS3 then PS4 firmware updates to support HTML5 occur after the GTKwebkit Linux updates because Sony uses GTKwebkit APIs which are also used by Comcast and Cable Labs for DLNA CVP2 RDKs.

Both consoles are complying with multiple standards so that they can become part of a NEW world wide ecosystem called Vidipath=DLNA CVP2 using DLNA, HTML5 with multiple W3C extensions and in the US, Playready DRM. Inside this ecosystem platforms can web chat with each other, share DRM media, stream games and media as well as support the connected home and Internet of things with common cross platform languages like Javascript and Java.

OpenGL/WebGL is part of this and Microsoft quietly moved to supporting OpenGL for their desktop, browser and apps for Windows just as Sony is supporting a OpenGL desktop in the PS4 and of course Android uses OpenGL and 2015 Sony TVs will use Android L as their OS. OpenGL security vulnerabilities were discovered in the PS3 and the Playstation store for instance doesn't use OpenGL for the browser, it uses a game engine supporting the same APIs that OpenGL would support. The PS4's and XB1's newer hardware is designed to support OpenGL without those security vulnerabilities.

Sony had plans for the PS3 which were delayed, maybe shelved, and that creates an impression in some peoples minds (Shin Johnpv being one of them) that Playstation platforms won't support the same features (DLNA CVP2) that other Sony platforms are also designed to support. I have a disconnect with those of like mind to Shin Johnpv as the research and reading I've done CLEARLY supports what I cite for the entire Sony line including Playstation platforms.

I suspect knowing the impatience of the average consumer which includes me, Sony and Microsoft don&#8217;t announce features until they are ready to implement them&#8230;.other wise we bombard them with &#8220;is it done yet&#8221; similar to children asking; &#8220;are we there yet&#8221; when on a long road trip. As a game and to partially assuage my impatience, I try to guess what&#8217;s coming and when based on what I know as the end game. I consistently underestimate the complexity and time it takes often by a year or more. Intel for instance did research on Gstreamer (IPTV Player used by Gnome/GTKwebkit) and the hardware resources it would need to IPTV stream in 2006. Sony sent a PS3 developer kit to Collabora which integrated Gstreamer into HTML5 with bindings to Cairo in 2007. Prior to that Cairo (used by GTKwebkit) was developed as a cross platform SVG language by IBM for use in a browser.

All the industry major players have seen the endgame (in the late 90&#8242;s) and have helped steer both hardware and software to support the three network convergence (TV as IPTV, Phone as VOIP and the Internet as IP) coming to the Living room and spreading to the rest of the home as the connected home.

Media and games play a major part which we have already seen and XTV (browser support from TV programming) with targeted commercials and the ability to support buying products from your TV which requires TEE level security, is driving new business models. Amazon has been creating regional warehouses to support one day delivery when ordering on-line and now has a negative cash flow that has been criticized as a bad business move. These analysts are ignorant of the impact XTV and targeted advertising is going to have. Amazon is preparing for the future but &#8220;it&#8217;s not there yet&#8221;.
 
#85
Could this be the secret sauce that affords us a decent VR experience on PS4?

o_O
The Xtensa IVP and HiFi in the PS4 is in the Southbridge, so while it will be used primarily for IPTV, DRM, low power Voice and gesture recognition, pre-processing for VR and AR and some of the OpenVX routines, the fine grained compute and larger GPU in the PS4 APU is key to AR. The XB1 Kinect camera has the pre-processing built into it that the Xtensa processors in the PS4 southbridge must do for it's camera.

For the XB1, it contains two Xtensa IVP DPUs in the APU which can use the 32 MB SRAM cache and I suspect what Cadence says can be supported with multiple IVP processors using tiling to work on a video frame in the cache. It helps level the playing field with the PS4.

Both will support low power Key Voice phrase detection to turn on the XB1 and PS4 from Network standby mode which requires the Xtensa HiFi DPU in a super low power mode. Later this year a new version of the Xtensa processor with much greater efficiency will be in a new Southbridge that can use LPDDR3. Latest Tensilica Processors Deliver Up to 75% Memory Power and Area Savings LPDDR3 is from leaks and that requires a redesigned Southbridge of which Low Power DDR3 is only needed to reduce power and I suspect the new Xtensa designs will also be used to reduce power. There is a serious push by government agencies for IPTV and Standby power efficiencies. As long as Game consoles continue to use best practice-best hardware the government will leave them alone.

Xtensa IVP from Literature:

IVP and IVP-EP are suitable for mobile imaging as well as consumer (DTV, gaming)
Significant performance boost for both image/video pixel filtering, as well as computer vision algorithms requiring extensive frame analysis
Optimized performance and power for computer vision and pixel processing applications that span a large range of data types from 8b to 32b, such as face detection, object detection, lens distortion correction, and many more advanced applications
In the PS4, the video frame can be processed in the Southbridge by an Xtensa IVP for use in a Occulus Rift type of display.
 
#88
This is what I feel like when reading this thread:

http://youtu.be/S90VPU62_FM
Think about the features you commented on in a previous post: "It's a Dish app that acts as a Virtual Joey (paired with a Hopper). I have it on my PS3 (it was released for the PS4 at the same time) and gives you all the functionality of a Joey but in software-form, including guide and VOD functionality." and expand that to include:

video chat: which is supported by a W3C extension to HTML5 called WebRTC
controlling the Hopper AND SOON a Cable TV DVR: W3C Web TV extension to HTML5
Discovery and sharing games and media over the home network: Which is a W3C DLNA extension to HTML5 where the software stack to support WebRTC and DLNA are used
Trick play Video and DRM: which is HTML5 <video> with ME Media Extension using APIs to Playready in the US.
VR using OpenVX and OpenCL: which will be W3C extensions to HTML5
Audio and Video gesture recognition using OpenVX and OpenCL: which will be W3C extensions to HTML5
Supporting game controllers: using W3C extensions to HTML5
Network drive support: which is a W3C extension to HTML5 using the Linux Samba network drive standard.

See the pattern? HTML5 and the W3C are adopting standards proposed by the industry using Khronos as the standards body. OpenVX was just ratified Oct 2014 as a Khronos Standard. It still needs to be adopted by the W3C before Sony will publish a API for Netflix to use. They will use it internally for Playroom on the PS4 and the apps they write for the ps4.

Going one step further I'm posting about the hardware that supports those standards and the need for low power support for those standards. Playready as the DRM for DLNA CVP2 supports multiple new ways to use and at the same time protect Media. With Playready supporting media DRM the media can be copied between and streamed between certified platforms as well as saved to a network drive.

** Web standards needed for AR slide show shows us the WebRTC native routines will be leverage to support AR. In the PS4 and even XB1 this creates issues as RTC is for Real time Communication or WebChat between platforms and that leverages the HTML5 <video> player which is a LOW POWER player in the Southbridge but VR will be using low power openVX routines from Southbridge and high power OpenCL/openVX routines in the AMD APU. So WebRTC must have two parts and work on two GPUs (8 below) where Sony must also turn on and off the high power GPU as needed. Do you begin to see the issues which might be causing the delays?

8) Sony second GPU patent. Mentioned in the leaked Xbox 720 powerpoint and in a Microsoft 2 GPU patent as well as letters to the EU power board.

As an example of my being correct and everyone else wrong and not understanding the state of the art in GPU technology and the issues this created for Microsoft and Sony is this thread on Semiaccurate. I would guess this leaves the impression in Shin Johnpv mind that I was wrong as the thread was closed before the XB1 hardware breakdown occured and a entire ARM subsystem discovered co-existing with the AMD APU for low power. Futher, only recently do we know that ALL AMD APUs contain an ARM sub-system with Xtensa processors for the UVD video decode with later APUs, more Cadence ARM IP for more features.

I believe HSA/HSAIL which automatically chooses the best CPU (CPU/GPU/DSP/FPGA) for the job is designed to also automatically power gate these CPUs on and off when needed. With such a system using HSAIL to write code, the manufacturer of a PC or System OS doesn't need to do this for themselves. This should be coming with HBM which can be used as low power and high power memory and eliminates the memory starved bandwidth issues that APUs currently have.
 
#89
And this is an example of how I get infractions for thread derailing. If you read the last paragraph it leads directly into this post even though it's a week later. You can't separate hardware designed to support Vidipath platforms and their power needs from how it's implemented. You can't support that Vidipath (DLNA CVP2) is changing everything without providing examples. This all ties together and the industry is undergoing a transformation to support this.

A thread was recently started on Neogaf that states that Microsoft will be supporting Apps by third parties (small independent startups too) and that started me wondering how they would provide access to both the low and high power architectures in the XB1.

How do you manage to provide a common IS-D-A (Instruction set for a dissimilar architecture) when you have a x-86 CPU, a GCN GPU that can be used as a CPU and a ARM bus with it's own CPU and Xtensa processors with DSP blocks that can also be used as a GPU or CPU? AMD will be using HSAIL, a virtual engine like Mono or Java or even Javascript that compiles on the fly to native code but it goes further than that if you look deeper like in the Sony patent for a 2 GPU system with architecturally dissimilar GPUs. You have all hardware running their own virtual engines that have a common instruction set. For the Sony 2 GPU patent both GPUs create common OpenGL (OpenGL requires CPU and GPU) instructions and a CPU managing which is used based on power mode and performance reqired (QOS).

You have a third program that manages which block can run the instructions more efficiently or has the performance to do so (QOS). This is HSAIL and the Sony 2 GPU patent. This is also the XB1 with 3 virtual engines running under Windows 10 which is 100% cross platform between ARM and X-86. The difference here is that the XB1 is a 2016+ AMD PC design (minus the HBM) but HSAIL is not ready.

Why do they need to do this? Because the large and powerful GPU even with Zero clock pulls more than 40 watts and there are or will be regulations requiring IPTV power modes of less than 21 watts which requires a ARM block with it's own GPU and the main GPU powered OFF not zero clock. Best practice and competition is moving into providing the power to play games yet use the minimum power to support Connected home apps. The computer will have to provide QOS to support applications from less than .5 watts to the max the platform can support or in excess of 100 watts. EU and US power boards will not allow a future computer to run at these high power levels all the time. Currently AMD supports small GPUs in APUs and automatic switching between the smaller and a large dGPU but those are similar architectures and current software wants to use the same CPU and will not switch from X-86 to ARM as needed nor will it switch from ARM CPU&GPU to X-86 CPU&GCNGPU or a Xtensa DPU as GPU or maybe even emulating a ARM CPU & GPU (A Xtensa processor is like Cell which can emulate a GPU and is a CPU).

For Sony the GPUs can be managed by both supporting a common OpenGL but what about CPUs and GPGPU compute I.E. OpenCL? Common instruction set running on a virtual engine like Javascript, Mono and Java?

If you do a Google search for "Instruction set for a dissimilar architecture" the first three listings are:

Heterogeneous Architecture - Gartner IT Glossary Dissimilar architectures but using a common memory (XB1)

Heterogeneous computing - Wikipedia, the free encyclopedia

Patent US20100253690 - Dynamic context switching ... which is the Sony 2 GPU patent.

The XB1 is a HSA design and the PS4 might be if there is a HSA IOMMU on either side of the PCIe between the APU and Southbridge. The 32MB SRAM cache in the XB1 APU and the PS4 moving the ARM block out of the APU with it's own DDR3 memory will not be needed with HBM as it can support both low power and high performance. When HBM is available then AMD's HSAIL will be used and APUs will have more than 4CU GPU blocks.
 
#90
A thread was recently started on Neogaf that states that Microsoft will be supporting Apps by third parties (small independent startups too) and that started me wondering how they would provide access to both the low and high power architectures in the XB1.

How do you manage to provide a common IS-D-A (Instruction set for a dissimilar architecture) when you have a x-86 CPU, a GCN GPU that can be used as a CPU and a ARM bus with it's own CPU and Xtensa processors with DSP blocks that can also be used as a GPU or CPU? AMD will be using HSAIL, a virtual engine like Mono or Java or even Javascript that compiles on the fly to native code but it goes further than that if you look deeper like in the Sony patent for a 2 GPU system with architecturally dissimilar GPUs. You have all hardware running their own virtual engines that have a common instruction set. For the Sony 2 GPU patent both GPUs create common OpenGL (OpenGL requires CPU and GPU) instructions and a CPU managing which is used based on power mode and performance reqired (QOS).

You have a third program that manages which block can run the instructions more efficiently or has the performance to do so (QOS). This is HSAIL and the Sony 2 GPU patent. This is also the XB1 with 3 virtual engines running under Windows 10 which is 100% cross platform between ARM and X-86. The difference here is that the XB1 is a 2016+ AMD PC design (minus the HBM) but HSAIL is not ready.

Why do they need to do this? Because the large and powerful GPU even with Zero clock pulls more than 40 watts and there are or will be regulations requiring IPTV power modes of less than 21 watts which requires a ARM block with it's own GPU and the main GPU powered OFF not zero clock. Best practice and competition is moving into providing the power to play games yet use the minimum power to support Connected home apps. The computer will have to provide QOS to support applications from less than .5 watts to the max the platform can support or in excess of 100 watts. EU and US power boards will not allow a future computer to run at these high power levels all the time. Currently AMD supports small GPUs in APUs and automatic switching between the smaller and a large dGPU but those are similar architectures and current software wants to use the same CPU and will not switch from X-86 to ARM as needed nor will it switch from ARM GPU to X-86 or a Xtensa DPU emulating a GPU.

For Sony the GPUs can be managed by both supporting a common OpenGL but what about CPUs and GPGPU compute I.E. OpenCL? Common instruction set running on a virtual engine like Javascript, Mono and Java?
So much text and... what again was the question? MS has an abstraction layer to make "unified" apps possible, most likely on x86-64. But what are you hinting at? And what about the power usage? Currently, PS4 can't even handle downloads in standby via the ARM processor. And AFAIR we don't even know if Xbone has an ARM processor. And how would we know this Xtensa stuff is even present in the consoles? And where is it?
 
#91
So much text and... what again was the question? MS has an abstraction layer to make "unified" apps possible, most likely on x86-64. But what are you hinting at? And what about the power usage? Currently, PS4 can't even handle downloads in standby via the ARM processor. And AFAIR we don't even know if Xbone has an ARM processor. And how would we know this Xtensa stuff is even present in the consoles? And where is it?
Hardware for Media Hub features in both the XB1 and PS4 "kinda confirmed" The XB1 has a massive ARM block inside the APU...it has 15 functional blocks which is Microsofts way of describing what the blocks do not the hardware that performs those functions.

AMD's Kaveri also has Tensilica HiFi (less powerful Xtensa processor with a DSP block) and Xtensa IVP which is a very powerful Video processor block called a DPU which since all video is already in digital form does not need a DSP. It has a Controller CPU like Cell and 32 blocks (read simpler cpus with other function blocks). AMD has been using the Xtensa processors on a ARM bus inside AMD APUs since day one. The Kaveri Xtensa processor is the first powerful enough to not need the shaders for post processing. Kaveri's Xtensa processor can do h.265 decoding by it'self.

Microsoft is AMD's trustzone partner and has been supporting the AMD ARM block features with Windows 8. The ARM block in even early APUs using the Xtensa processor supported eye-sight gesture recognition middleware which is ARM code in a Flash block inside the APU without using the GPU.

I'm not hinting, I'm flat out saying the XB1 has a 2016+ AMD APU minus the HBM. It has a Microsoft custom version of something similar to AMD's HSAIL. The abstraction layers are more that that. They also must support QOS power scaling when using HSA.

"PS4 can't even handle downloads in standby via the ARM processor" The firmware is not done. The PS4 ARM block as Southbridge has a Trustzone processor and Xtensa audio and video DPUs. The Xtensa DPUs are very powerful but I expect the early PS4 firmware tried to use the ARM CPU by it'self which is much weaker. Xtensa DPUs are stream processors and can handle real time h.265 or 300 MP3 streams at the same time (from Sony for the Tensilica Xtensa HiFi DSP). They are designed to also support encrypting and decrypting for DRM streams or codec encoding and decoding video and audio streams.
 
#92
Hardware for Media Hub features in both the XB1 and PS4 "kinda confirmed" The XB1 has a massive ARM block inside the APU...it has 15 functional blocks which is Microsofts way of describing what the blocks do not the hardware that performs those functions.

AMD's Kaveri also has Tensilica HiFi (less powerful Xtensa processor with a DSP block) and Xtensa IVP which is a very powerful Video processor block called a DPU which since all video is already in digital form does not need a DSP. It has a Controller CPU like Cell and 32 blocks (read simpler cpus with other function blocks). AMD has been using the Xtensa processors on a ARM bus inside AMD APUs since day one. The Kaveri Xtensa processor is the first powerful enough to not need the shaders for post processing. Kaveri's Xtensa processor can do h.265 decoding by it'self.

Microsoft is AMD's trustzone partner and has been supporting the AMD ARM block features with Windows 8. The ARM block in even early APUs using the Xtensa processor supported eye-sight gesture recognition middleware which is ARM code in a Flash block inside the APU without using the GPU.

I'm not hinting, I'm flat out saying the XB1 has a 2016+ AMD APU minus the HBM. It has a Microsoft custom version of something similar to AMD's HSAIL. The abstraction layers are more that that. They also must support QOS power scaling when using HSA.

"PS4 can't even handle downloads in standby via the ARM processor" The firmware is not done. The PS4 ARM block as Southbridge has a Trustzone processor and Xtensa audio and video DPUs. The Xtensa DPUs are very powerful but I expect the early PS4 firmware tried to use the ARM CPU by it'self which is much weaker. Xtensa DPUs are stream processors and can handle real time h.265 or 300 MP3 streams at the same time (from Sony for the Tensilica Xtensa HiFi DSP). They are designed to also support encrypting and decrypting for DRM streams or codec encoding and decoding video and audio streams.
Thanks for the reply! There are still too many buzzwords for me but let's summarize:

- Both consoles feature arm processors in their apu (Is it really in PS4's case? I always thought it would be "outside")
- Or is this the Xtensa DPU?
- The Xtensas are arm processors which are surrounded by stream processors?
- Of course there is a layer that you can "communicate" with the additional hardware but what other features are gaming related? I only see use-cases for console security and codec acceleration currently.

All the information is nothing very concrete and explicit, in my opinion. I also didn't find anything regarding this in the leaked XDK from MS.
Do we have any teardowns of the apu like we had for WiiU's processor where we can spot the arm cpu?
 
#93
Thanks for the reply! There are still too many buzzwords for me but let's summarize:

- Both consoles feature arm processors in their apu (Is it really in PS4's case? I always thought it would be "outside")
- Or is this the Xtensa DPU?
- The Xtensas are arm processors which are surrounded by stream processors?
- Of course there is a layer that you can "communicate" with the additional hardware but what other features are gaming related? I only see use-cases for console security and codec acceleration currently.

All the information is nothing very concrete and explicit, in my opinion. I also didn't find anything regarding this in the leaked XDK from MS.
Do we have any teardowns of the apu like we had for WiiU's processor where we can spot the arm cpu?
This is a picture of the PS4 APU and XB1 APU dies. The ARM block with a AX! buss can be recognized in the XB1 only because it's so large and all the ARM IP should be as close as possible to each other. It's in the extreme upper right just to the left of the upper SRAM block.

The PS4 does not have such a block and since the PS4 APUs memory is GDDR5 and ARM is being used for Trustzone DRM normally used with IPTV DRM we should expect it to use a memory than can support less than 21 watt IPTV and .5 watt AOAC standby...GDDR5 can't do that so ARM blocks in the PS4 are not in the APU they are in the Southbridge with it's own DDR3..

Both have Power Island, clock scaling, Temp sensing and IO blocks (PCIe and more) using transistors that distinguish themselves from the GPU and CPU transistors. IO is always on the edge of the die and some effort is made to distribute high heat components.

Xtensa processors are designed for an ARM bus but they are not ARM processors. They are very similar in concept to Cell with many smaller CPUs and specialized accelerators and only one 3 issue controller. There is a picture of a block diagram a few posts above this one. The many accelerators inside the DPU, it's own memory and the advanced ARM AXI buss allow it to process a data stream in real time even with clock speeds of 300 Mhz which allow it to be VERY energy efficient compared to any other CPU be it ARM or X-86.

There is some confusion in naming. The entire package of memory, Xtensa processor and accelerators is a DPU but many just name the package an Xtensa Processor. A DPU (Xtensa processor + accelerators and memory) can have a DSP block added to it to support conversion of Analog audio to digital and the reverse. This is a Cadnece Tencelica Xtensa HiFi DSP and has been confirmed as in both game consoles and Kaveri to support True Audio. Video is always digital so a DSP block is not needed but video codecs including h.265 require a very much more powerful Xtensa processor than audio does.

For possible uses please read the OP and follow the links. This picture from Cadence has features than can be supported by Xtensa processors in Red and the grey is Intellectual Property Cadence owns, some of which is also in the XB1 APU. Most of the touted features in AMD APUs and dGPUs are provided by Cadence IP with more in later designs including HBM. Note: Imaging/Video also includes small extremely power efficient GPU emulation.

 
#96
I doubt the final aesthetic design of the PS4 was decided upon in 2011.
Of the Sony products we know of so far, only some of the PS3 (with blu-ray drive loaders) and all PS4 so far can be positioned upright. The small size of the blocked out 4K Media server is also a clue. Third, why block out the image of the PS4 if it's some other Sony media Player...because it's a PS4 and the final design is not locked, it's a mockup and 2011 too early to start the hype as it would impact PS3 sales.

 
#98
There's nothing to get. That stuff above is a standard part of any GPU nowadays because of the need to be HDMI compatible. Jeff is trying too hard to find something which doesn't exist.
So you think the Xtensa processor in Kaveri is for HDMI 2.0 and not for h.265 as documented by AMD? Or are you picking some of the Cadence IP on the ARM buss that is used for the HDMI port which is also now possible and with Carrizo and future AMD APUs which become SoCs with southbridge included HIGHLY likely. IF you are talking dGPUs then I don't know when AMD moved to Cadence IP for the HDMI port. That I think is not yet public. The VCE and HDMI/Display port can be AMD or Cadence IP.

Using a Xtensa processor for the HDMI 2.0/HDCP 2.2 encryption assumes a Panasonic 2.0 HDMI chip or whoevers does not handle the encryption internally as HDMI 1.4 chips do. Sony using the Xtensa processor in the PS4 southbridge with a custom Panasonic HDMI chip I thought was a way to get 4K 60Hz HDMI2 with HDCP 2.2 when HDMI 2.0 chips weren't ready. Do you have an inside track and know that HDMI/HDCP 2.2 encryption doesn't now happen in the HDMI transmitter chip?
 
#99
So you think the Xtensa processor in Kaveri is for HDMI 2.0 and not for h.265 as documented by AMD? Or are you picking some of the Cadence IP on the ARM buss that is used for the HDMI port which is also now possible and with Carrizo and future AMD APUs which become SoCs with southbridge included HIGHLY likely. IF you are talking dGPUs then I don't know when AMD moved to Cadence IP for the HDMI port. That I think is not yet public. The VCE and HDMI/Display port can be AMD or Cadence IP.

Using a Xtensa processor for the HDMI 2.0/HDCP 2.2 encryption assumes a Panasonic 2.0 HDMI chip or whoevers does not handle the encryption internally as HDMI 1.4 chips do. Sony using the Xtensa processor in the PS4 southbridge with a custom Panasonic HDMI chip I thought was a way to get 4K 60Hz HDMI2 with HDCP 2.2 when HDMI 2.0 chips weren't ready. Do you have an inside track and know that HDMI/HDCP 2.2 encryption doesn't now happen in the HDMI transmitter chip?
Sure it is for encoding - you have to be able to encode the signal to be HDMI compatible. You read too much into this. Using something that potentially can do more than it is used for is a standard thing in this industry. A lot of building blocks are unified because it's wiser to have one common part covering the most applications in different products targeted at different markets.

I'm not saying that they won't find a mean to use that in some unexpected way - since these are consoles which are fixed in hardware for a lot of years this does happen on them from time to time - but as of right now this is there just to be able to output the video/audio and nothing more.
 
Sure it is for encoding - you have to be able to encode the signal to be HDMI compatible. You read too much into this. Using something that potentially can do more than it is used for is a standard thing in this industry. A lot of building blocks are unified because it's wiser to have one common part covering the most applications in different products targeted at different markets.

I'm not saying that they won't find a mean to use that in some unexpected way - since these are consoles which are fixed in hardware for a lot of years this does happen on them from time to time - but as of right now this is there just to be able to output the video/audio and nothing more.
Think about what a Media Hub has to support and then please read the links in the OP. You are not alone and are many steps behind in understanding what the design goals were for the Consoles and the hardware that supports the design goals. I've followed your posts but apparently you don't have the big picture.

For instance, why is HSAIL necessary for AMD and on the roadmap for when HBM is used with APUs? I've already posted the reason in this thread but you likely haven't connected the dots or even read the posts. Why do only the XB1 and PS4 APUs contain 12-18 CUs plus 2 as CPUs and the largest AMD APU (Kaveri) has 6 + 2 as CPUs? Why does Kaveri use an ARM block and a Xtensa IVP DPU for the UVD which can decode h.265 without needing the GPU? What problems does having 14-20 CUs create for the game console APUs; the answer to this contains the reason for HSAIL for the first sentence in this paragraph.

If you are to support IPTV and XTV then you need a power mode of less than 21 watts. You can't do that and have the large GCNGPU on so you need a low power GPU and codec and southbridge and northbridge....for Voice and Gesture control in a IPTV power mode you also need something like low power Xtensa DPUs. AMD APUs with 2-4 GPU CUs can meet the power needs but anything with a GCN GPU larger than 4 CUs can't. There is currently a memory botttleneck issue for APUs with more than 4 CUs also but you can't use GDDR5 as that uses too much power. HBM is going to fix the APU bandwidth issue and it can be used in low power IPTV and high power modes. But with two GPUs how do you manage scaling to high performance GPU needs from low power XTV modes.

The answer is to run everything under HSAIL's engine and let it manage using the best CPU, GPU, DSP, FPGA for the job and at the same time manage power gating those blocks. This is essentially the Sony 2 GPU patent and part of why three virtual engines make up Windows 10 on the XB1. Each block runs it's own virtual engine with a common "HSAIL" HSA Intermediate Language with a HSA controller that turns on and passes control to the block that can perform the tasks given parameters of QOS and power mode. The Sony 2 GPU patent does the same with dissimilar GPU architecture by using a common intermediate language or "architecture-neutral display list". AAA games don't need power modes but the OS supporting the game still does for background tasks. The game developer still has to comply with future power regulations but the OS should transparently support this.

EDIT: HSA's IL does not address graphics and a few days ago we heard at GDC about Vulcan and SPIR-V with SPIR-V the intermediate language for GPU Compute AND SPIR the Standard Portable Intermediate Representation for graphics which the Sony 2 GPU patent calls the "architecture-neutral display list".. I believe this is the missing piece known about by Khronos; "NVIDIA, Epic Games, Oculus, Sony, and ARM are among the many vendors backing Vulkan and SPIR-V". Also it's not a coincidence in naming conventions that AMD's Mantle and Volcanic Islands have an association with Khronos's Vulcan name.

8) Sony second GPU patent. Mentioned in the leaked Xbox 720 powerpoint and in a Microsoft 2 GPU patent as well as letters to the EU power board.

If you read the Sony patent it talks about "Graphics processing in a computer graphics apparatus having architecturally dissimilar first and second graphics processing units (GPU) is disclosed. Graphics input is produced in a format having an architecture-neutral display list. One or more instructions in the architecture neutral display list are translated into GPU instructions in an architecture specific format for an active GPU of the first and second GPU."
HSAIL's controller engine will always run on the ARM block as that block is the only one that is always running, and that ARM block will also be the Northbridge and Southbridge of the SoC. To meet IPTV, AOAC and support IOT, future PCs with larger CU blocks in the SoC must support a SoC as described with HSAIL. Currently both Intel and AMD have ONLY APUs with small GPUs and there is no X-86 PC able to play AAA games and meet all power mode requirements. That changes with the XB1 and PS4 when they are finally firmware updated this year and for AMD PCs after HBM and HSAIL are implemented in 2016.

The Living room PC will always be an affordable mid performance PC for fan noise issues and for the next 4-6 years about the same performance as the XB1 and PS4 but starting in 2016+ can be cheaper as a single SoC using HBM & HSAIL similar to the XB1 but without a 32MB SRAM block. The minimum HBM size supporting about 200 GB/sec is 8GB (Same as the XB1's and PS4's APU memory). Windows 10 and DX12 should have features and a roadmap to support HSAIL with the coming AMD SoCs. To support HSA all hardware must use the same memory or support HSA IOMMU V2 contollers on either side of PCIe (SerDes) or USB or Ethernet....

OK if you understand the above, AMD stock is a bargain at $3.00 and a long term hold. It should double sometime after 2016 and AMD has moved their debt out past 2017, stock options for employees mature after 2017 also. Add to this that ATSC 2.0 and DLNA CVP2 have a need for a Media Hub and central storage which likely will be supported first with the XB1 and PS4 then later 2016+ PCs.