Support NeoGAF

[Negotiator]

UVD/VCE is fixed-function hardware, aka not programmable to support new codecs with a software update. That's why hardware revisions exist.

It's also in the GPU (APU), not in the southbridge (apparently Jeff still doesn't get this). PVR needs access to the main memory (GDDR5/DDR3) pool. That's where videos are stored (unless you download them to your HDD). That's why the PS4/XB1 console OSes need ~3GB of RAM allocation (among other things).

 

[inpHilltr8r]

videos stored in ram, that's a good one

 

[Henrar]

videos stored in ram, that's a good one

Isn't the 15 minutes video from the Share button kept in PS4's RAM?

 

[Negotiator]

videos stored in ram, that's a good one

That's where they are being recorded all the time. 15min of H.264 720p30 video recording requires ~1GB of RAM.

 

[Negotiator]

Personally I would prefer it if they used the HDD for that constant recording process (this could also allow us to have longer PVR duration, depending on the free HDD space), but maybe they deemed it would cause too much tear & wear on the HDD... it would be nice to give an extra 1GB of RAM to the game devs if it was technically possible.

 

[Negotiator]

Wow: http://www.neogaf.com/forum/showpost.php?p=213811560&postcount=1020

There's no way in hell they're using RAM for 60min PVR... so, did they release 1GB RAM for game devs?

 

[jeff_rigby]

UVD/VCE is fixed-point hardware, aka not programmable to support new codecs with a software update. That's why hardware revisions exist.

It's also in the GPU (APU), not in the southbridge (apparently Jeff still doesn't get this). PVR needs access to the main memory (GDDR5/DDR3) pool. That's where videos are stored (unless you download them to your HDD). That's why the PS4/XB1 console OSes need ~3GB of RAM allocation (among other things).

VCE is a fixed hardware encoder with VCE 3 able to encode HEVC with low latency for game streaming. VCE is In both the XB1 and PS4 APU. VCE is not on the ARM bus so there is no VCE/UVD combo hardware, they are separate blocks with VCE totally an AMD design and UVD from Cadence.

According to some papers, the XB1 is almost entirely a Cadence design except for the Jaguar CPU and GCN GPU. Memory controllers and special blocks are all Cadence IP.

UVD is a Software decoder using Xtensa processors on a AXI ARM bus controlled by a Trustzone processor. In the XB1 it's in the APU and in the PS4 I believe it's in Southbridge. The different versions of UVD are primarily differences in performance and efficiency. Codecs need to be compiled for the UVD version they run on but the same UVD version can handle multiple codecs.

UVD running in the PS4 APU using the GDDR5 memory will use about an extra 10 watts over running in Southbridge with 256MB DDR3. I assume after Firmware update 4.0 that with full screen video the GPU is turned off and GDDR5 is in self refresh mode so that only Southbridge is running with streaming media using less than 20 watts. The XB1 will do something similar with power islands in the APU.

I HOPE WE ARE ON THE SAME PAGE NOW.

 

[Negotiator]

UVD running in the PS4 APU using the GDDR5 memory will use about an extra 10 watts over running in Southbridge with 256MB DDR3. I assume after Firmware update 4.0 that with full screen video the GPU is turned off and GDDR5 is in self refresh mode so that only Southbridge is running with streaming media using less than 20 watts. The XB1 will do something similar with power islands in the APU.

I strongly doubt this, unless someone can prove it with a watt-o-meter...

 

[Adam Tyner]

UVD is a Software decoder using Xtensa processors on a AXI ARM bus controlled by a Trustzone processor.

AMD defines UVD as "a fixed function hardware block". AMD expressly uses the phrase "in hardware" when discussing decoding HEVC via UVD6. This also jives with the way Stacey Spears and Masayasu Ito refer to hardware/dedicated HEVC decoding that the launch consoles lack.

Since you sneer at Spears and Ito as being liars or incompetent, does that mean the same holds true for AMD?

Are you arguing that Spears, Ito, and company are wrong and that the launch Xbox One and PS4 are both capable of decoding 100Mbps UHD HEVC video?

Codecs need to be compiled for the UVD version they run on but the same UVD version can handle multiple codecs.

Who's arguing otherwise? No one's saying that decoding, say, both AVC and HEVC is mutually exclusive.

 

[inpHilltr8r]

That's where they are being recorded all the time. 15min of H.264 720p30 video recording requires ~1GB of RAM.

Or 1GB of drive space that is being continually written to out of a much much smaller buffer in memory.

 

[Negotiator]

Or 1GB of drive space that is being continually written to out of a much much smaller buffer in memory.

No, it doesn't work like that (not sure about the latest beta FW update), otherwise the PS4 Orbis OS wouldn't require 3.5GB of RAM.

 

[Steiner84]

this thread man, it just keeps on giving

 

[Stinkles]

this thread man, it just keeps on giving

We're all in the TrustZone now.

 

[Negotiator]

We're all in the TrustZone now.

#TeamTrustJeff

 

[EvB]

We're all in the TrustZone now.

Is it safe to take off my Hypervisor?

 

[CosmicQueso]

We're all in the TrustZone now.

 

[Lady Gaia]

I have doubled my 3 year old investment this year and I expect another 50% at a minimum by 2017. Depending on China another 100% by 2019.

All of which is conveniently unverifiable, unlike the actual subject of this thread where you have been demonstrably wrong time and again. It's one thing to speculate and be wrong, it's another to insist that you know what you're talking about and other people do not when the opposite is manifestly the case.

 

[inpHilltr8r]

No, it doesn't work like that (not sure about the latest beta FW update), otherwise the PS4 Orbis OS wouldn't require 3.5GB of RAM.

Riiiiiight. Otherwise it would only require 2.5GB of RAM, and that's all completely accounted for. There's really no other explanation is there.

 

[Negotiator]

Riiiiiight. Otherwise it would only require 2.5GB of RAM, and that's all completely accounted for. There's really no other explanation is there.

Instead of being needlessly sarcastic, perhaps you could offer some kind of evidence about your claims. Otherwise you're becoming like Jeff.

I can clearly hear my HDD when it's writing data (i.e. downloading stuff), but I certainly don't hear it all the time like you're suggesting (continuously writing videos to a 1GB HDD buffer).

 

[inpHilltr8r]

Instead of being needlessly sarcastic, perhaps you could offer some kind of evidence about your claims. Otherwise you're becoming like Jeff.

I can clearly hear my HDD when it's writing data (i.e. downloading stuff), but I certainly don't hear it all the time like you're suggesting (continuously writing videos to a 1GB HDD buffer).

Fair enough, I'll throttle back the incredulity a tad.

I can believe you can hear the head seeking across the drive during downloading. I've spent quite a bit of time listening to optical drives seek while optimising data streaming operations, and while it's a much bigger head, and it's not in a sealed unit, the principle is the same. However, it's not going to be seeking very much if it's continuously writing to the same 1GB. If only it had an access light eh?

 

[Negotiator]

Fair enough, I'll throttle back the incredulity a tad.

I can believe you can hear the head seeking across the drive during downloading. I've spent quite a bit of time listening to optical drives seek while optimising data streaming operations, and while it's a much bigger head, and it's not in a sealed unit, the principle is the same. However, it's not going to be seeking very much if it's continuously writing to the same 1GB. If only it had an access light eh?

Yeah, It would help if there was a HDD LED (just like in the PS3), but Sony thought they had to remove it from the PS4 (due to cost cutting or whatever).

Honestly, I'd love to be wrong and maybe Sony changed this in the latest SDK/beta (v4.00) where the PVR supports up to 60min videos.

Also, I didn't mean that the OS and the PVR consume all that space (3.5GB). Obviously some of it is reserved "just in case". We don't know how much is the OS footprint in the latest SDK (could be a lot less than 3.5GB).

 

[Vashetti]

Yeah, It would help if there was a HDD LED (just like in the PS3), but Sony thought they had to remove it from the PS4 (due to cost cutting or whatever).

Bit of trivia:

The final PS3 model (CECH-4300) removed the HDD light.

 

[Chû Totoro]

I use the research and reading to target investments so what I pass on to the threads is making me money. I have doubled my 3 year old investment this year and I expect another 50% at a minimum by 2017. Depending on China another 100% by 2019.

lol
Actually, you seem to be a really cool guy ^^

 

[EvB]

I use the research and reading to target investments so what I pass on to the threads is making me money. I have doubled my 3 year old investment this year and I expect another 50% at a minimum by 2017. Depending on China another 100% by 2019.

Are you betting against yourself being right?

 

[jeff_rigby]

AMD defines UVD as "a fixed function hardware block". AMD expressly uses the phrase "in hardware" when discussing decoding HEVC via UVD6. This also jives with the way Stacey Spears and Masayasu Ito refer to hardware/dedicated HEVC decoding that the launch consoles lack.

Since you sneer at Spears and Ito as being liars or incompetent, does that mean the same holds true for AMD?

Are you arguing that Spears, Ito, and company are wrong and that the launch Xbox One and PS4 are both capable of decoding 100Mbps UHD HEVC video?

Who's arguing otherwise? No one's saying that decoding, say, both AVC and HEVC is mutually exclusive.

I did not sneer at Spears, I said that he had statements that showed he was not part of the Trustzone hardware group and he could not have knowledge on the internal workings. He could only repeat what he had heard and since his statement came after the XB1 Slim announcement, he was just repeating it. X-86 CPU and GCN GPU can not be used for a Netflix HEVC codec which he said they were attempting. You keep distorting what I said

UVD, as stated by AMD, handles decoding of H.264/AVC, and VC-1 video codecs entirely in hardware.

The UVD technology is based on the Cadence Tensilica Xtensa processor,

Before tapeout the Xtensa DSP block has configurable logic which in the UVD after tapeout are special hardware accelerator blocks created with Cadence IP. If you design it to only handle codecs it is a fixed function block able to handle any codec that was compiled to run on it and it was designed to support. The Xtensa processor is like Cell's Power PC CPU controlling up to 64 blocks of sub processors that may have dedicated logic like DSP blocks or Microsoft's HEVC DXVA's 5 accelerator blocks. h.264 and more so with h.265, break up a frame into blocks that are assigned to sub processors. A codec that handles DRM required commercial media must be in a TEE that now complies with TMP 2.0.

Sony CTO in 2012 describes the architecture needed in the PS4 in broad terms: "You are talking about powerful CPU and GPU with extra DSP and programmable logic

AMD APUs after 2013 now support "Extras" Like face detection and gesture recognition that also must be protected in the TEE with security outlined in TMP 2.0 papers. This is done with Xtensa DSP hardware which is either the UVD or Trueaudio (Xtensa HiFi DSP) take your pick. Many of the special accelerator blocks in UVD can also be used for vision processing.

"AMD defines UVD as "a fixed function hardware block". AMD expressly uses the phrase "in hardware" These terms imply a Xtensa DSP block designed to handle codecs and nothing else as compared to a CPU or GPU being used for codecs. As I stated, DRM media can not use hardware outside the control of the TEE like the X-86 CPU and GCN GPU. Block diagrams and descriptions of hardware blocks for consumers do not give us enough information and confusion in what terms mean is to be expected. When does a Xtensa DSP block become a fixed function UVD hardware block, when it can't be used for any other function. What provides the gesture recognition in APUs without impacting game performance?

UPCOMING AMD APUS FEATURE BUILT-IN GESTURE CONTROL POWERED BY EYESIGHT

Israel, January 7th 2013 – Following hot on the heels of today’s AMD news, eyeSight today announces that its leading gesture control technology has been pre-integrated into AMD’s newest Accelerated Processing Unit (APU) family, Richland; intended primarily for PCs, laptops and tablets. With eyeSight’s gesture recognition closely optimized and pre-integrated, Richland APU devices are able to process gestures with optimal speed, accuracy and efficiency. Along with eyeSight’s gesture technology AMD is providing an ideal solution to the snowballing demand for intuitive gesture-capabilities in both business and consumer devices.

eyeSight’s software has been optimized for the AMD APU parallel computing architecture, and has been pre-integrated as software-on-chip, allowing the rapid processing of simple hand-gestures and hand tracking for virtual-mouse point-and-click.

Where eyeSight’s software is run on a CPU, it takes around 150ms to process a frame of video. On the Richland APU family with eyeSight pre-integrated, this same task takes 7.5m; a speed improvement of 20x!

Eyesight is ARM middleware pre-loaded on APU TEE internal ROMs and also used in Many ARM phones. 20X speed improvement over CPU is Xtensa DSP. Face detection is also a function that requires security and must be in the TEE and mentioned in TPM 2.0 papers.

OK, back to game consoles that are designed to support Virtual Reality. They must have DSP blocks with configurable logic (Xtensa DPU). Many of the functions needed for codecs are also used in vision processing. Is UVD a subset of a larger Xtensa block also designed to support VR/Gesture/Face/Head tracking? (The Xtensa DPU supports direct access micro DMA internal memory transfers CPU scratchpad to CPU scratchpad inside the Xtensa DPU bypassing the IOMMU and the AXI bus.) Are they separate DSP blocks with duplication? My guess is the former and I can be wrong. The description AMD uses for UVD implies it is a separate block in AMD APUs and the latter.

 

[Negotiator]

AFAIK, gesture recognition uses GPGPU code.

 

[Adam Tyner]

I did not sneer at Spears

Really?

How to explain the ignorance in the Spears statements? Is it really Spears or someone impersonating him with some outdated knowledge.

Spears saying the Launch XB1 uses CPU or GPU for HEVC is so wrong on many levels.

Adam, how much more do you need to confirm at least Spears is talking out of his hat.

Which makes Spears statement that the XB1 CPU and GPU were nearly maxed out doing HEVC bullshit which I pointed out.

Oh, you think the Bink HEVC codec middle ware is false advertising while Spears is accurate. c0de, what do you think? Did you post false advertising? Is Spears talking out of his hat trying to impress by claiming special knowledge?

Gesh, ADAM, Spears and Ito have been PROVEN to be WRONG!!!!!!!!!

herod, apply the same strict judgement on Ito and Spears statements and comment on that. If you don't this is a one sided argument not worthy of thinking people.

Spears and Ito comments have within them serious errors that are easily confirmed. They also directly conflict with Sony and Microsoft letters as well as a report by an independent lab that the PS4 and XB1 are UHD capable. Yet you continue to defend those statements by Spears and Ito which requires you to ignore/dismiss and claim the official letters are not reliable.

(Do remember that everything that Stacey Spears said about the hardware upgrades in the Xbox One S was eventually proven correct.)

He could only repeat what he had heard and since his statement came after the XB1 Slim announcement, he was just repeating it.

What a bizarre, outlandish assertion on your part. Nothing even vaguely resembling what Spears posted had been stated by anyone before that point. You find the timing suspicious, but of course people are going to be talking about the Xbox One S after the Xbox One S is announced!

Show me interviews by Phil Spencer from June 13th or 14th that:

• Reference hardware HEVC decoding
• Indicate that any sort of software UHD HEVC decoder was in development
• Reference the strain said software decoder put on system resources
• Mention HDMI/HDCP upgrades

There are interviews where Spencer speaks about a new optical drive being a part of the Xbox One S, which Spears more explicitly says is necessary to read triple-player media.

Your insistence that everything Spears says is based on echoing/misinterpreting Phil Spencer's interviews is not the least bit grounded in reality (like most everything you post).

X-86 CPU and GCN GPU can not be used for a Netflix HEVC codec which he said they were attempting.

You've been wrong about absolutely everything up to this point, and Stacey Spears did, of course, work at Microsoft on this project at the time and is widely acknowledged as an expert in this field. Sorry for putting more stock in his words:

While we were able to get SW UHD HEVC playback working, it used all of the CPUs on the box to make it happen. They were going to launch UHD Netflix last year with the software decoder, but that was cut due to limited resources after the layoff.

The software HEVC used all of the CPUs and the GPU to function. Now it just uses a HW HEVC decoder, so no CPU or GPU is used. The software could only do Netflix 24p UHD at 15Mbps. It could not handle UHD BD bitrates or framerates at all.

...especially since everything else that Spears said in this same breath -- which you dismissed out of hand -- has been proven correct!

"AMD defines UVD as "a fixed function hardware block". AMD expressly uses the phrase "in hardware" These terms imply a Xtensa DSP block designed to handle codecs and nothing else

So when you see the phrase "in hardware", your kneejerk reaction is "Xtensa DSP block designed to handle codecs and nothing else"? Wow!

You insist that the launch Xbox One and PS4 can be upgraded to support HEVC decoding on the level that UHD BD demands with a software update. Prove it. Maybe you could point out the many other examples of UVD being upgraded with a software update on this scale.

My guess is the former and I can be wrong.

You can be wrong? With your spectacular track record in this thread to date? Astonishing!

 

[Negotiator]

Using Jaguar CPU cores for H.265 decoding seems inefficient to me. GPGPU code could handle it better, but then again, the old HDMI standard cannot output more than 24p, so probably not worth it.

 

[BreakAtmo]

Riiiiiight. Otherwise it would only require 2.5GB of RAM, and that's all completely accounted for. There's really no other explanation is there.

Isn't about a gig of that only being held back just in case of unforeseen future features? That's what I remember hearing, at least.

 

[w0s]

Man at what point does Jeff pull the ripcord and just not open this thread? You were wrong about seemingly everything and just can't let it go.

 

[jeff_rigby]

Using Jaguar CPU cores for H.265 decoding seems inefficient to me. GPGPU code could handle it better, but then again, the old HDMI standard cannot output more than 24p, so probably not worth it.

Besides DRM requirements the GPU and CPU are on power islands and are turned off when doing full screen video in later AMD (2013) APUs. This is a Energy Star computer requirement or the computer can not be sold to the US government. Game consoles are not held to the same standards but have volunteered to comply with best practice (efficientgaming.eu) which includes this.

Yes, I have a watt meter and did test the PS4 after launch and was surprised that it used 90 watts for video streaming when the PS3 used 68 watts. Notice the Efficientgaming.eu cap for video streaming is 90 watts with the cap 70 watts after 2016. 70 watts is to still allow the PS3 with the XB1 and PS4 dropping well below that.

• The power caps for navigation mode are the same for High and Ultra-high definition consoles (90 Watts from 2014 and 70 Watts from 2017).
• For Media Playback the power caps for High definition consoles are the same level as in Navigation mode (90 Watts from 2014 and 70 Watts from 2017)

Why did the PS4 2013 use 90 watts when full screen video with GPU off and GDDR5 in self refresh using only the Southbridge with it's own 256 MB could do it with less than 20 watts? We now have the answer, TMP 2.0 (The developer tweet I cited.) was finalized middle of 2015 and it is not backwardly compatible with older security schemes. The bios and trusted boot were not able to support DRM till after a firmware update for TMP 2.0 which happened for Microsoft August 2016 and with the XB1 Slim.

Same applies to the 2013 XB1 as it has power islands but has to use main memory DDR3 with special cadence supplied IOMMU controllers making the DDR3 memory part of the TEE. And yes the PS4 APU has a IOMMU to PCIe which connects to the Southbridge with it's 256MB of DDR3 memory and we were told a Arm Trustzone processor is in Southbridge for Network standby. Network standby includes Miracast and DLNA requests as well as Key phrase voice turn-on which Xtensa HiFi DSP supports and we were told is in the PS4 to support True Audio.

A ARM TEE duplicating a ARM TEE in southbridge could be in the PS4 APU using that memory but examining the PS4 APU die shots I could find no block that resembled ARM blocks with true audio similar to 2013 and later AMD APUs or the XB1 APU. You also must understand that the PS4 camera has no pre-processing like the XB1 Kinect and raw video going up the PCIe to the APU from the camera and VCE encoded video coming down the PCIe to the hard disk creates a constant load that is not necessary if pre-processing with DSP occurs in Southbridge.

Regardless of support for UHD media, the XB1 and PS4 will support TMP 2.0 as it's necessary for HDCP 2.2 which is used for Miracast and 1080P Vidipath which both plan to support.

 

[Negotiator]

Jeff, I hate to break it to you, but the Orbis OS (and the lite Windows 10 OS) require the CPU/GPU/main RAM to function, even for video decoding. I also doubt that 256MB of RAM (and a pretty slow one at that because of it being 1 chip DDR3 16-bit bus) with a single slow ARM CPU core is enough for video decoding, let alone 4K high bitrate one.

Did you know that rest mode activates the APU Jaguar CPU (which requires access to the GDDR5 pool) while downloading stuff? Yeap, the ARM core can't even do simple http downloading (even 486 PCs could do that). It's that weak.

It's just the way it is. If you care about power efficiency while watching Netflix, then maybe you should buy a dedicated device for that instead of a gaming device.

ps: If you're able to earn profit in stock market based on your far-fetched theories, then good for you, although I doubt it TBH.

 

[Negotiator]

You also must understand that the PS4 camera has no pre-processing like the XB1 Kinect and raw video going up the PCIe to the APU from the camera and VCE encoded video coming down the PCIe to the hard disk creates a constant load that is not necessary if pre-processing with DSP occurs in Southbridge.

Sony used Cell SPUs for camera processing in the PS3.

Guess what they use in the PS4 this time around? The equivalent of Cell SPUs: Radeon CUs, aka GPGPU code.

Since you care about tech stuff, you should read Mark Cerny's interview about the internal PS4 architecture: http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php

 

[jeff_rigby]

Jeff, I hate to break it to you, but the Orbis OS (and the lite Windows 10 OS) require the CPU/GPU/main RAM to function, even for video decoding. I also doubt that 256MB of RAM (and a pretty slow one at that because of it being 1 chip DDR3 16-bit bus) with a single slow ARM CPU core is enough for video decoding, let alone 4K high bitrate one.

Did you know that rest mode activates the APU Jaguar CPU (which requires access to the GDDR5 pool) while downloading stuff? Yeap, the ARM core can't even do simple http downloading (even 486 PCs could do that). It's that weak.

It's just the way it is. If you care about power efficiency while watching Netflix, then maybe you should buy a dedicated device for that instead of a gaming device.

ps: If you're able to earn profit in stock market based on your far-fetched theories, then good for you, although I doubt it TBH.

Yes Orbis OS does not NOW use the ARM blocks for commercial media for DRM reasons, same for Firmware updates.

A ARM trustzone block contains dedicated cryptographic hardware that is easily able to handle encryption/decryption on the fly and easily supports HDCP 2.2. In Hindsight with the TMP 2.0 update, DRM using those Trustzone blocks was not enabled for ANY DRM use. It will after Firmware 4.0 and full screen video will be enabled. This will be easily testable with watt meter.

Xtensa DSP blocks used for video contain their own internal RAM and minimum 32 sub processors that in parallel codec decode a frame. A Xtensa DSP decoding h.264 can run at 350 Mhz for power efficiency reasons so the 16 bit 256 mb DDR 3 is not an issue for HD media.

The Xb1 and PS4 now use openCV which does not use Xtensa DSP blocks. OpenVX is also a 2015 Khronos published standard using DSP hardware as accelerators which complement OpenCV. Developers would not use this till PCs were using it and Xtensa DSP is on the ARM TEE and everything on the TEE appears delayed till after TMP 2.0 for security reasons.


My speculation is colored by early 2009-2012 Sony statements to the EU power board arguing against 35 watt navigation and less for Media chosen because the WiiU can support that. Sony said that would require a separate Apple like SoC...which appears to be the Southbridge. Because of this I assumed the PS3 was getting a new Southbridge also.

There's also another custom chip to put the system in a low-power mode for background downloads. "To make it a more green hardware, which is very important for us, we have the ability to turn off the main power in the system and just have power to that secondary custom chip, system memory, and I/O -- hard drive, Ethernet. So that allows background downloads to happen in a very low power scenario. We also have the ability to shut off everything except power to the RAMs, which is how we leave your game session suspended."

Secondary custom chip = Southbridge which for lowest power mode is always on and GDDR5 is in self refresh. I believe the XB1 has key phrase voice activation from low power and the PS4 will have the same (Special port for the Camera supplies power to the Mic) which requires the Xtensa HiFi DSP to be in Southbridge.

 

[Negotiator]

Using secondary processors along with primary ones is one thing.

Shutting down primary processors and using the secondary one exclusively is quite another and as I said, it's not technically possible.

http://n4g.com/news/1394790/ps4-con...t-uses-the-main-apu-and-not-just-the-arm-chip

Even Sony confirmed this. Your southbridge-only operation wet dream will never come true, I'm afraid.

Keep in mind that http downloading is a lot easier than H.264 decoding... as I said, even 486 PCs could do that with ease 20+ years ago.

 

[Vashetti]

It will after Firmware 4.0 and full screen video will be enabled. This will be easily testable with watt meter.

Loads of people have 4.0 now from the beta, so this can be tested.

 

[Negotiator]

Loads of people have 4.0 now from the beta, so this can be tested.

So, basically Jeff is suggesting that the entire Orbis OS is shut down during full screen video playback thanks to southbridge-only operation

Spoiler

Secret Sauce™

...

ps: 256MB 16-bit bus DDR3 RAM is too slow to provide enough bandwidth for (U)HD decoding. There's no internal RAM in the chip, unless you're talking about caches (measured in KBs).

 

[Adam Tyner]

So, basically Jeff is suggesting that the entire Orbis OS is shut down during full screen video playback thanks to southbridge-only operation

Don't forget that, according to Jeff, 4.0 is a near-total rewrite, and many/all apps will have to be completely rewritten accordingly as well:

I've repeatedly said that nearly the entire OS needs to be rewritten, all the apps will be replaced using APIs from the ARM TEE including the PS4 Media Player. DLNA, Miracast, WMDRM, Playready, Playready ND, HTML5 <video> MSE EME, Codecs, HDCP2.2, HDR and more will be 100% in southbridge with network standby, it all comes with Firmware 4.0 and embedded Playready.

PS4 firmware update 4.0 this August (8th month) or October should enable UHD media, ooVoo, HTML5 <video> MSE EME in the browser, ALL third party apps rewritten to use the the PS4 software stack, File dialog boxes from the browser (a more open PS4), Vidipath and full DLNA support from southbridge with likely network standby, CD support, Dolby digital audio from the Media player for music and more.

PS4 plus firmware 4.0
4 + 4 = 8

The point is that nearly every app will need to be rewritten for the PS3, PS4 and Vita to take advantage of embedded DRM and the published APIs for Southbridge. I'm assuming Sony is waiting to do it all at one time on every platform.

 

[NeOak]

Don't forget that, according to Jeff, 4.0 is a near-total rewrite, and many/all apps will have to be completely rewritten accordingly as well:

Breaking compatibility with all current games that won't be "patched".

lol jeff pls

 

[jeff_rigby]

Breaking compatibility with all current games that won't be "patched".

lol jeff pls

Games call APIs and have no DRM issues with streaming so they won't be impacted on the PS3, PS4 or Vita.

 

[Stinkles]

I believe the XB1 has key phrase voice activation from low power .

This is true for Kinect. But I am not sure if the Kinect is doing that independent of the console. It has some memory obviously.

 

[Negotiator]

This is true for Kinect. But I am not sure if the Kinect is doing that independent of the console. It has some memory obviously.

The XB1 doesn't have an ARM co-processor in the southbridge. It keeps the APU on at a low power state in "Instant On" mode. The Jaguar CPU does the voice processing.

 

[Nictel]

Well 4.0 isn't a total rewrite. Seeing that it does not come with a load of app updates, you can downgrade back to the previous version and with 296MB it is not considerably larger than previous firmwares.

 

[Yurikerr]

Wow, this thread is still going?

I tried to read the OP 3 times and couldn't understand how jeff reach all this conclusions.

 

[jeff_rigby]

Well 4.0 isn't a total rewrite. Seeing that it does not come with a load of app updates, you can downgrade back to the previous version and with 296MB it is not considerably larger than previous firmwares.

Current apps are much larger than they should be. The DLNA/Media player is a temporary without DRM and uses 690 MB when, if it is using the PS4 OS stack should be MUCH less. DLNA is about 2 MB and VLC is 28 MB and contains everything for streaming over the home network. So these current PS4 apps can run on any OS version as they are almost totally self contained.

DLNA is also a routine that should be able to be called from network standby like my Sony Receiver can and Vidipath requires. Vidipath (DLNA with DRM) requires HDCP 2.2 to support Playready ND (DTCP-IP for 1080P and higher media and several DLNA modes allow a phone running a DLNA APP to control the DLNA/Vidipath player including volume.

No TMP 2.0 so no HDCP 2.2 thus no Playready ND thus no DLNA for commercial Media = the current temporary DLNA media player we now have. This applies to all features of the PS4 that require security like firmware updates.

HDCP is essentially applying a number stream to the data using Xor logic. The numbers are generated by a key and a AES-128 hardware accelerator in the TEE. Neither operation is CPU intensive. HDCP 2.2 is primarily about the negotiation and security of the KEYs and TMP 2.0 about the hardware security supporting the routines used for HDCP 2.2. (Trusted boot - TEE)

Ito-san explained that initially Sony attempted to have background download performed exclusively by the secondary sub-system ARM chip (as it was announced during the console’s presentation in February), in order to keep the main APU powered down, but that proved not to be fully possible.

The download process is too heavy for the ARM chip alone, so the Jaguar-based CPU of the main APU (Accelerated Processing Unit, that includes CPU and GPU) is called into action to do the heavy lifting and protocol processing.

I have several issues with this statement:

1) The entire PS4 hardware went through testing using FPGA hardware before tapeout. It was announced as a coming feature at the Launch presentation. If it slipped by testing before tapeout, it wasn't tested before the launch announcement when developers had hardware using the final version of the PS4 for months?????
2) ARM phones supported HDCP 2.2 in 2012 on batteries for Miracast which means they can stream Playready encrypted media from a cloud server, unencrypt it then encrypt it using HDCP 2.2 for Miracast WiFi to a TV or STB REALTIME.
3) Cerney said the Southbridge has a always running ARM processor primarily for Network standby but the PS4 pulls slightly more than 6 watts in Standby when other STBs with network standby use 500 mw. The PS4 is going to support Vidipath which means it needs to support DLNA with network standby and at 20 watt power levels with full screen video APU off.
4) Firmware updates do not need to be realtime so there is no performance issue and since all data and media goes through Southbridge in any case, the statement that the download process is too heavy for Southbridge does not make sense.
5) A Trustzone TEE contains cryptographic accelerators and can handle real time video decryption including that needed for Blu-ray (AACS) decryption and HDCP encryption at the same time!

6) The 2015 PS4 has a new Southbridge and still no background download.

Cerney: "So that allows background downloads to happen in a very low power scenario."
Ito: "The download process is too heavy for the ARM chip alone, so the Jaguar-based CPU is called into action to do the heavy lifting and protocol processing. While this is the situation with the present design, Ito-san specified that it could change with further iterations of the console’s design."

 

[kvn]

I use the research and reading to target investments so what I pass on to the threads is making me money. I have doubled my 3 year old investment this year and I expect another 50% at a minimum by 2017. Depending on China another 100% by 2019.

Just when one thought it couldn't get any better.

 

[Kyoufu]

That's where they are being recorded all the time. 15min of H.264 720p30 video recording requires ~1GB of RAM.

How much RAM for 60 minutes of video? Because the latest PS4 firmware allows that much to be recorded.

Elgato's devices also write to disk, not RAM.

 

[Negotiator]

How much RAM for 60 minutes of video? Because the latest PS4 firmware allows that much to be recorded.

The beta notes say that it may reduce quality (bitrate, resolution, fps), so maybe it takes the same amount of space.

Elgato's devices also write to disk, not RAM.

Elgato is an external device, not a console.

 

[Kyoufu]

The beta notes say that it may reduce quality (bitrate, resolution, fps), so maybe it takes the same amount of space.


Elgato is an external device, not a console.

I'm gonna need Jeff's final word on this matter before I'm convinced.

 

[JonathanPower]

UVD/VCE is fixed-function hardware, aka not programmable to support new codecs with a software update. That's why hardware revisions exist.

It's also in the GPU (APU), not in the southbridge (apparently Jeff still doesn't get this). PVR needs access to the main memory (GDDR5/DDR3) pool. That's where videos are stored (unless you download them to your HDD). That's why the PS4/XB1 console OSes need ~3GB of RAM allocation (among other things).

No they are always stored on the HDD, according to Mark Cerny.

http://www.theverge.com/2013/8/22/4646696/ps4-mark-cerny-interview-gamescom-2013

As to the hardware recording, we knew we needed to put in full video encoding and decoding into the hardware because all these media features are so important for a next-generation console. I think the only cost you can really point to is that we need a small buffer on the hard drive to store the data.