Middle Generation Console Upgrade Discussion [Scorpio, 4Pro]

[iroboto]

VM or directX can't really help against a race condition or other obscure bug linked to execution speed, or some cache behaviour issues?

It could be a good idea to have a robust compatibility mode as a fail safe. It doesn't have to be applied to all unpatched games, just the untested ones. As they get tested they can flag them off the compat list in bulk.

Not going to pretend as though I'm fully sure. My biggest concern could be the CPU. I think GPU wise, it should be alright. But I use a lot of executables that are compiled for different CPUs and OS and they work fine via VM. I dunno, I may not fully understand it, but I think it should work, getting good performance (or how they would get it) may be another topic.

When concerning whether or not MS or developers need to be involved, if I understand BC right, it's MS manipulated.

To that extent, I imagine that X360 to XBO is a much greater difference than XBO -> Scorpio. They could be spending the next year prepping patches for all games. But it doesn't sound like it.

 

[Silent_Buddha]

Yeah I thought that too but between:

http://www.windowscentral.com/project-scorpio
"Our source told us that Project Scorpio dev kits will be a "one-stop shop" for all Xbox platform development. Project Scorpio will be able to mimic an Xbox One at a hardware level so developers can test how their games scale between different power levels. This system is known internally as Project Helix."

and

http://stevivor.com/2016/11/phil-sp...cal-wizardry-360-one-backwards-compatibility/
“We’ve very specifically designed it [on Scorpio] so Xbox games just run,” he said, referring to both Xbox 360 and Xbox One titles. It’s nothing like Xbox 360 backwards compatibility right now — there’s a lot of technical wizardry involved in that. We didn’t want to have to do that again.”

I am wondering if they are going to use a hardware trick on Scorpio for BC. Also by mimicking the hardware of Xbox One on Scorpio you'd theoretically kill two birds with one stone by not having to change much with existing 360 BC that is already running on Xbox One hardware no?

This part

It’s nothing like Xbox 360 backwards compatibility right now — there’s a lot of technical wizardry involved in that. We didn’t want to have to do that again.

Seems to imply that they aren't going to do much special in terms of compatibility of XBO titles on Project Scorpio.

It makes me think that it's going to be more of a PC approach. It'll run how it'll run. At most maybe there'll be in framerate caps if it's, for example, a 30 FPS game that would freak out if it ran at higher than 30 FPS and the developer didn't release a patch that allowed it to work at higher than 30 FPS for Project Scorpio. A great example of something like that is one of the Need For Speed games that when ported to PC initially freaked out if it ran at higher than 30 FPS because of the way it was coded as they stuck very close to the XBO code which didn't account for that due to the hardware limiting performance on the XBO.

But something like that would be relatively simple. AMD's drivers on PC already allow you to set framerate limits for games. At most, IMO, they'll put in something that allows for the ESRAM to be emulated on Project Scorpio and/or GPU commands if Project Scorpio doesn't support all GPU commands of the XBO GPU on the Project Scorpio GPU.

As to the Dev. kits, that just means they can test how it would run on XBO hardware without actually having to have an XBO.

Regards,
SB

 

[Jay]

is that really a concern on console?
if a game was made to have a fps lock it would be coded with it. So it wouldn't run faster than that lock anyway.
if it could run faster than that lock it must've been coded with an unlocked frame rate which means if can handle it.
the pc port was taking a locked frame rate and just unlocking it wasn't it?
I'd be amazed at any Xbox game being made so dependent on cpu cycles like that. As they never really ever let you program to the metal in general. Not the Xbox way.
it could be why the x1s didn't get a cpu boost at all though.

 

[Silent_Buddha]

is that really a concern on console?
if a game was made to have a fps lock it would be coded with it. So it wouldn't run faster than that lock anyway.
if it could run faster than that lock it must've been coded with an unlocked frame rate which means if can handle it.
the pc port was taking a locked frame rate and just unlocking it wasn't it?
I'd be amazed at any Xbox game being made so dependent on cpu cycles like that. As they never really ever let you program to the metal in general. Not the Xbox way.
it could be why the x1s didn't get a cpu boost at all though.

Yeah I'm not sure, I just know there were programs that had a rough port to PC due in some cases to the framerate. Dark Souls 2 for example had weapons degrade twice as quickly on PC due to running at 60 FPS versus 30 FPS. It'd make sense to lock the framerate, however. So yeah, not sure. Emulation of ESRAM is likely to be the only major hurdle.

Regards,
SB

 

[Arwin]

But it is not out of the question that the consumer hardware will work similarly?

 

[iroboto]

But it is not out of the question that the consumer hardware will work similarly?

Well let's look at 4Pro for a moment. Boosted clocks and memory frequencies on both GPU, CPU and memory and some changes to their CUs.

In the end, to enable compatibility mode, they only needed to enable some feature that cut their CUs by 1/2 and ran at a slower clock rate.

From this information already we know that CPU shouldn't be an issue, so we can focus elsewhere for now. Leaving us with GPU clock speeds. But we know already that X1BS has faster GPU clock speeds and we don't see an issue there either. We haven't heard of any crashing caused by the increase in clock speed; so this is unlikely.

Leaving the majors hurdles to be; changes in architecture and esram.

As for whether The Dev kit and retail unit having the same hardware; it would not surprise me that it were the same (given their past history with XBO) but it would not surprise me it would be different either (given the history of most Dev kits). We may need to wait on more information on this front.

 

[Jay]

In the end, to enable compatibility mode, they only needed to enable some feature that cut their CUs by 1/2 and ran at a slower clock rate.

I thought it clocked down the cpu also in compatibility mode?
Pretty sure that the comparisons has shown no improvement in either gpu or cpu limited situations.

 

[mpg1]

I thought it clocked down the cpu also in compatibility mode?
Pretty sure that the comparisons has shown no improvement in either gpu or cpu limited situations.

It is. CPU is downclocked to 1.6GHz in compatibility mode.

 

[iroboto]

It is. CPU is downclocked to 1.6GHz in compatibility mode.

Oh right thanks for the fix. So my original viewpoint on VM was still valid. I thought it wasn't lol. That's what happens when you wake up and post.

 

[mpg1]

This is sort of addressed explicitly in the eurogamer article on PS4 Pro:

http://www.eurogamer.net/articles/d...tation-4-pro-how-sony-made-a-4k-games-machine
"But what about deploying the additional Pro GPU power in base PS4 mode, similar to the Xbox One S? Or even just retaining the 111MHz GPU frequency boost? For Sony, it's all about playing it safe, to ensure that the existing 700 titles just work.

I've done a number of experiments looking for issues when frequencies vary and... well... [laughs] I think first and foremost, we need everything to work flawlessly. We don't want people to be conscious of any issues that may arise when they move from the standard model to the PS4 Pro."

 

[Jay]

I've not looked at the sdk's or developer guidelines.
But it wouldn't surprise me if the Xbox is more tolerant to those sort of changes.
4pro may also be ok to clock higher for 99.9% of games, but if their guidlines and docs don't highlight certain best practices or bad practices, then they may not want to risk the odd games having issues.

 

[mpg1]

"But what about deploying the additional Pro GPU power in base PS4 mode, similar to the Xbox One S? Or even just retaining the 111MHz GPU frequency boost? For Sony, it's all about playing it safe, to ensure that the existing 700 titles just work." -Mark Cerny

"We’ve very specifically designed it [on Scorpio] so Xbox games just run" - Phil Spencer

Both are saying the same thing essentially. The hardware compatibility mode seems to be the easiest/safest route so why wouldn't Microsoft use that approach? Even if the software can handle different gpu clock they might still run it on only 12 CU's.

 

[iroboto]

"But what about deploying the additional Pro GPU power in base PS4 mode, similar to the Xbox One S? Or even just retaining the 111MHz GPU frequency boost? For Sony, it's all about playing it safe, to ensure that the existing 700 titles just work." -Mark Cerny

"We’ve very specifically designed it [on Scorpio] so Xbox games just run" - Phil Spencer

Both are saying the same thing essentially. The hardware compatibility mode seems to be the easiest/safest route so why wouldn't Microsoft use that approach? Even if the software can handle different gpu clock they might still run it on only 12 CU's.

If I were to take a stab at answering your question, it may revolve around the fact that a software based solution for backwards compatibility would not compromise the hardware to run its intended performance target.

Or in simpler terms, they can unrestrictedly use hardware that doesn't chain them to older ones so that Scorpio can operate as a completely new generation should MS desire that. Where it is obvious that 4Pro is chained to PS4, as it is hardware wise.

For a company who has managed backwards conpatibilty for x360 to XBO, this seems rather trivial, especially since XBO titles have been running in containers since launch.

 

[iroboto]

One last note; I have little doubt that while XBO is FL12_0, Scorpio will be FL12_2. That distinction is going to be an important requirement in selling DX12 (thus w10) to the masses.

If Scorpio has access to Conservative Rasterization and other features, and it's leveraged, Scorpio will have legs well beyond what Compute and bandwidth changes could accomplish. PC gamers stand to benefit largely from this; as much as everyone talks and loves resolution and aliasing, we could really use some high quality shadows.

 

[Jay]

"But what about deploying the additional Pro GPU power in base PS4 mode, similar to the Xbox One S? Or even just retaining the 111MHz GPU frequency boost? For Sony, it's all about playing it safe, to ensure that the existing 700 titles just work." -Mark Cerny

"We’ve very specifically designed it [on Scorpio] so Xbox games just run" - Phil Spencer

Both are saying the same thing essentially. The hardware compatibility mode seems to be the easiest/safest route so why wouldn't Microsoft use that approach? Even if the software can handle different gpu clock they might still run it on only 12 CU's.

Sounds like similar statements, but context and where their coming from is a bit different Imo.
Phil Spencer was talking about it in relation to what they have to do for 360 bc games.
They don't want to go through anything even close to that for the Scorpio.
Bit like xo games just run on x1s, just so happens that there's a performance boost.
They need to tweak, configure and improve the bc emulator almost on a game by game basis.
Scorpio, may be about making the game os/hypervisor support xo. "So games just work."
One time effort in getting it to that level.

But I wouldn't rule out a cpu compatibility mode simply because there wasn't an up clock at all for the x1s. If there was one, would have made this a slam dunk in my eyes.
Same way it's proven that a gpu up lock is handled ok.

 

[mpg1]

If I were to take a stab at answering your question, it may revolve around the fact that a software based solution for backwards compatibility would not compromise the hardware to run its intended performance target.

Or in simpler terms, they can unrestrictedly use hardware that doesn't chain them to older ones so that Scorpio can operate as a completely new generation should MS desire that. Where it is obvious that 4Pro is chained to PS4, as it is hardware wise.

For a company who has managed backwards compatibility for x360 to XBO, this seems rather trivial, especially since XBO titles have been running in containers since launch.

I get what you are saying but what has me confused is the way Spencer worded "It’s nothing like Xbox 360 backwards compatibility right now — there’s a lot of technical wizardry involved in that. We didn’t want to have to do that again."

Isn't 360 BC software based? If you doing a software based compatibility again for XBO on Scorpio why would you word it like that?

The only thing I can figure is he is referring to having to essentially run the entire Xbox 360 OS on Xbox One hardware just to get games to work. Maybe that is what he is referring to by "do that again".

Edit: But still this doesn't answer how easily 360 BC will translate to Scoprio? Or how to emulate esram?

 

[Jay]

also downclocking cpu only makes sense if we believe it will have exactly the same jaguar cpu.
is that what people are expecting?

edit: Also the fact that Sony wasn't able/willing to run the gpu a bit faster in compatibility mode may show that their set up is more dependant on such things than Xbox.
that would've been an easy win to say all games run the same or better.

Esram is really a factor if latency is a huge benefit.
even then due to other things running faster overall it may just end up not being a big deal to emulate it in faster memory.
pretty big unknown there.

 

[AlNom]

That's what happens when you wake up and post.

Better check your BIOS. :V

 

[Rikimaru]

edit: Also the fact that Sony wasn't able/willing to run the gpu a bit faster in compatibility mode may show that their set up is more dependant on such things than Xbox.
that would've been an easy win to say all games run the same or better.

I think it's a matter of perfect compatibility and good enough. Not having per title hacks in OS is a huge plus for maintaining code.
Windows is known to have a lot of "not a bug but a feature" to maintain compatibility.

 

[Jay]

I think it's a matter of perfect compatibility and good enough. Not having per title hacks in OS is a huge plus for maintaining code.
Windows is known to have a lot of "not a bug but a feature" to maintain compatibility.

yea, I think that they won't be going for those kind of hacks though.
by having a thin layer between game and hardware I think it will help them moving forward.
that and good dev guidelines.