Who says they're not allowed? We've taken VGleaks documents as pretty much fact for XB1 and PS4 because they were independently corroborated by trusted sources at the time and have been shown to be accurate.Out of curiosity if Xbox one vgleaks diagrams are not allowed
Out of curiosity if Xbox one vgleaks diagrams are not allowed how come they are gospel if showing PS4 ?
Surely the same skepticism should be given to both vgleaks documents or you would have to conclude the Xbox dual GPU is true as it's from the same source ?
That also may have been confusion with VGChartz (sales data) and VGLeaks.Oh OK cool, I stand corrected, on a previous post it was mentioned that vgleaks were unproven and should not be referred to
On the Xbox Diagrams from vgleaks it shows each CU or SC as they refer to it having it's own L1 cache but on the PS4 dev slides shows it's shared between 3 CU units, what advantages or disadvantages does this have or could it point to those CU having come from another range of cards. That might be where some of the R&D money went to and not the dual threading ? just an idea.
That the 2nd GCP is for the OS system makes sense. Occam's Razor and all . . . .
We console developers stay far away from this thread. For obvious reasons.I wish we could get sebbbi to speculate/prognosticate/pontificate about what uses a dual GCP setup would enable. Unfortunately, it's likely NDA territory.
It seems you guys have decided what you believe the purpose is for the dual GCP is. I was curious if it could be used by another OS other than the apps OS. If it's true that multiple cores will be able to talk to GPU with DX12, would you be able to run one game OS that handles the objects like the player characters and collision detection and things. Then a second could run a persistent world for those things to interact with.
Say the world OS is calculated and built by the cloud and loaded to the RAM or the embedded memory on the chip. The other runs everything else involved in creating the scene. One set of cores using one GCP for it's OS, the other GCP used by the rest for the remaining cores.
When a collision occurs, the local OS does all of the immediate physics work and sends a report of what happened to the cloud. The cloud calculates the results and sends it back to the cloud OS on the console. Latency may cause a delay of a frame or two buy if the local OS creates enough smoke and particle effects to hide the impact, it might give the cloud enough time to work out the proper physics to make the explosion look more realistic. A magicians smoke and mirrors.
You can absolutely do that. The first system you described is an authoritative server. You leave the server to handle all the game operation and it tells the clients what's happening where for them to draw. The problem there is the input latency of pressing a button to contacting the server to getting a response. Alternatively, you have the clients compute locally and inform each other what they're doing. The server relays messages, but also will need to check on outcomes to make sure everything lines up and nobody's cheating.You wouldn't do things on both server and locally, if that makes sense cause that would create some really awkward inconsistencies AFAIK.
You can absolutely do that. The first system you described is an authoritative server. You leave the server to handle all the game operation and it tells the clients what's happening where for them to draw. The problem there is the input latency of pressing a button to contacting the server to getting a response. Alternatively, you have the clients compute locally and inform each other what they're doing. The server relays messages, but also will need to check on outcomes to make sure everything lines up and nobody's cheating.
The idea of running a cloud OS is just adding crazy complexity to all this with zero benefit. Writing two executables to run on two different OSes and synchronise their visuals, with one of those OSes having to handle latencies that might spikes into the tenths of seconds, would be a miserable job for a developer!
Sounds like something titanfall, quake, and the Call of Duty models are based on, hit scan style guns, with only a few weapon types with an actual velocity.It gives a far more responsive game though, essential for fast multiplayer.