Middle Generation Console Upgrade Discussion [Scorpio, 4Pro]

[DieH@rd]

Boost isn't a perfect solution. From their massaging it seems that they expect some inconsistencies that users should take care of them.

It is not perfect.... but GAF tests make it looks like it will be close to perfect:

TOTAL GAMES: 64
GAMES WITH NO IMPROVEMENT SEEN: 8
GAMES REPORTED TO CRASH OR RUN WORSE: 3*
*Note that crashes may be unrelated to Boost mode

GAME LIST: @ http://www.neogaf.com/forum/showpost.php?p=229714867&postcount=3860

And some of those "no improvement seen" games are in fact running "as devs intended" on stock PS4. For example Black Flag is perfect locked 30fps, seeing improvement on that is not going to happen.

 

[iroboto]

I don't see that one would need hardware for that. On Scorpio the flag placing a buffer in the eSRAM when allocating it will simply be ignored (that is a software choice). As the eSRAM is part of the same address space as the rest of the RAM (it's really a unified address space between eSRAM and DDR3) and doesn't have any special features (the GPU can access both as equal citizens, ROPs work on both memory pools, the TMUs can texture from both, the shaders can read and write buffers in both), the software doesn't really see a difference between them (beside the speed). MS could very likely disable the eSRAM of the XB1 with a firmware update without having the games crashing (performance probably tanks, though).

This would imply some sort of emulation though right ? Software wise you are looking for those calls and allocating it elsewhere ? How would this be a better solution over hardware?

 

[Gipsel]

This would imply some sort of emulation though right ? Software wise you are looking for those calls and allocating it elsewhere ? How would this be a better solution over hardware?

This isn't much of an emulation. The addresses formerly mapped to the eSRAM are mapped to the GDDR5 in Scorpio. That's all. I wouldn't know what a hardware solution for this should do. It's naturally something MS will do in the firmware/OS of Scorpio.

 

[iroboto]

I am 100% with you and this is why I am really quite surprised by Boost mode. Sony have never demonstrated any forethought for forward-looking software or hardware design in order to deliver backward compatibility on something in the future.

Me too, me too. But the fact that code written for 2013 hardware even works and works better in different 2016 hardware without patches suggests more than a modicum of forward planning. And it's hard to imagine PS4 Pro not being at least an idea or concept before PS4 launched.

So why change the status quo
I guess what I'm getting at (just woke up mid sleep lol) did we rule out that boost mode could be a method of emulation? Dispel is telling me esram can be firmware patched, no hardware control needed for dealing with the native binaries. I still think it would be faster with some form of a hardware controller managing esram on DDR5 but it's possible it's unnecessary to achieve good performance.

What if it's the same here? They looked at time sensitive code that could break, made firmware to identify and make modifications, and if people identify games with bugs, they will go back and make adjustments to their emulator so that it works?

 

[Gipsel]

They looked at time sensitive code that could break, made firmware to identify and make modifications, and if people identify games with bugs, they will go back and make adjustments to their emulator so that it works?

I would consider code which breaks on some timing changes (on mostly variable latency things in the first place!) a bug or badly programmed these days. We aren't in the old console days anymore, when everything had a fixed latency and one could count clock cycles to the next line drawn on screen or something. One has to do proper synchronization anyway. Which means games are less likely to break (they shouldn't at all in my opinion).

 

[Deleted member 11852]

So why change the status quo
I guess what I'm getting at (just woke up mid sleep lol) did we rule out that boost mode could be a method of emulation?

Maybe Boost mode is doing more rather than lifting the clocks. If games with issues suddenly run better but without issues on future firmware updates (and without any game patches) then that could be a sign that Boost mode is doing something other than lifting the clocks.

Dispel is telling me esram can be firmware patched, no hardware control needed for dealing with the native binaries. I still think it would be faster with some form of a hardware controller managing esram on DDR5 but it's possible it's unnecessary to achieve good performance.

What I believe Gipsel is suggesting is that most Xbox One code written with ESRAM in mind only cares that data placed there can be accessed quicker than DDR3 but if all memory in Scorpio is faster (or as fast as) ESRAM then you don't need to emulate around the lack of ESRAM, old code will be none the wiser. It's in fast RAM but now everything is in fast RAM! ESRAM overflows that caused performance hitches on Xbox One should vanish.

What if it's the same here? They looked at time sensitive code that could break, made firmware to identify and make modifications, and if people identify games with bugs, they will go back and make adjustments to their emulator so that it works?

It depends on how time sensitive code is written. Nobody should be using instruction loops for timing but there may be odd edge cases where it makes sense because it's quicker than using the API functions the OS provides. Everything using API functions can be accommodated but it still relies on game code fundamentally not being written to assume function X will take Y nanoseconds. Writing code without assumptions does require a bit a discipline but judging by the number of games that seemingly work without issue, it looks like the console industry are writing good code - perhaps they always were or perhaps it was a lucky consequence of using 80x86 processors where assumptions won't fly on the myriad of hardare configurations. Whatever it is, it's gratifying to see.

 

[iroboto]

Actually I was thinking more along race conditions.
These consoles are low powered heavily multithreaded machines. Mutex can really slow down code, so when you really are in that deep optimization phase, I imagine that removing Mutex may be part of the final optimization process for games that need it, changing clockspeeds could spell disaster for games shipped like this.

 

[Nisaaru]

The nature of multithreaded machines with all kinds of services running in parallel makes such assumed race conditions extremely unlikely because such software would already be too problematic to run acceptable now.

 

[mrcorbo]

I suspect that Boost mode came about as a result of Sony having had enough time to test a wide range of non-patched titles running on Pro to know how many problems it caused. Once they were able to determine that many games ran without problems, it became a viable option to put the burden of dealing with compatibility problems on the user. Compatibility Mode is still there as a safety net to maintain 100% compatibility and since the default option is to disable Boost Mode, Sony is off the hook if something breaks. It's a good idea and it will probably sell more Pros.

It also seems I was right to not be overly impressed by the One S's ability to run at slightly higher specs and show improved performance in some titles without breaking anything.

 

[mrcorbo]

Actually I was thinking more along race conditions.
These consoles are low powered heavily multithreaded machines. Mutex can really slow down code, so when you really are in that deep optimization phase, I imagine that removing Mutex may be part of the final optimization process for games that need it, changing clockspeeds could spell disaster for games shipped like this.

I'd guess this is why a lot of games have locked framerates.

 

[mrcorbo]

This isn't much of an emulation. The addresses formerly mapped to the eSRAM are mapped to the GDDR5 in Scorpio. That's all. I wouldn't know what a hardware solution for this should do. It's naturally something MS will do in the firmware/OS of Scorpio.

How plausible is it that straight memory move operations in and out of ESRAM could be emulated on Scorpio without doing an actual move by manipulating the address mapping? Or does the fact that those moves could be of an arbitrary amount of data make this non-workable? The move operations are just a waste of bandwidth if you only have the single memory pool.

 

[mpg1]

With kb/m and uwp should be pretty much there for most people.
Wonder if that's why they've held of on releasing general support.
Mix messaging, TV messaging type issue.

Yeah...I guess it is low priority right now...

I mean if it had the normal desktop Microsoft Edge browser with a traditional mouse cursor and mouse support I'd probably consider using it as my 'everything device'...

The current browser still seems to be a 'console version'

 

[Jay]

How plausible is it that straight memory move operations in and out of ESRAM could be emulated on Scorpio without doing an actual move by manipulating the address mapping? Or does the fact that those moves could be of an arbitrary amount of data make this non-workable? The move operations are just a waste of bandwidth if you only have the single memory pool.

don't know how the memory layout works, but I doubt you would actually be moving data around, memory pointer changes, memory table entry changes etc.

Yeah...I guess it is low priority right now...
I mean if it had the normal desktop Microsoft Edge browser with a traditional mouse cursor and mouse support I'd probably consider using it as my 'everything device'...
The current browser still seems to be a 'console version'

i think they could've probably released kb/m long time ago, but managing the message would be hard for them.
with uwp apps available on Xbox now, becomes even harder if kb/m was fully supported. It's using win10 core, probably had to disable kb/m more so than implement it.

 

[mpg1]

i think they could've probably released kb/m long time ago, but managing the message would be hard for them.
with uwp apps available on Xbox now, becomes even harder if kb/m was fully supported. It's using win10 core, probably had to disable kb/m more so than implement it.

yeah I guess they are figuring out how they want to implement it without detracting from the message "Xbox is a gaming console first and foremost"...

 

[mpg1]

It will be interesting to know how developers are going to approach the memory differences between Xbox One and Scorpio...

 

[iroboto]

don't know how the memory layout works, but I doubt you would actually be moving data around, memory pointer changes, memory table entry changes etc.


i think they could've probably released kb/m long time ago, but managing the message would be hard for them.
with uwp apps available on Xbox now, becomes even harder if kb/m was fully supported. It's using win10 core, probably had to disable kb/m more so than implement it.

Right, on paper this sounds good, but it doesn't actually contain the same functionality as dual memory pools. So thinking out loud here;
So while pointer switching is faster than copying, you run into some interesting issues that could arise, which will need to be accounted for

Recall that GPU can write results to DDR or esram
A)
move DDR to ESRAM
gpu consumes esram
write results back to esram

The esram version of that memory location is now modified in esram but perfectly normal on DDR3.

If we pointer redirected to indicate that once a mov statement was made that you just switch a pointer, the GPU is now modifying the original, which if you still depend on the original being there, this could present an issue.

or more probable:

B)
mov DDR to esram
CPU overwrites the memory location in DDR3

A pointer redirect is detrimental here.

While it works with PS4 because developers always had this behaviour (so they know they should not be doing scenario A or B), I don't know if that case can apply freely to XBO.

 

[mrcorbo]

don't know how the memory layout works, but I doubt you would actually be moving data around, memory pointer changes, memory table entry changes etc.

That's what I was thinking, but I wonder if there is a limit to how granular that can be.

i think they could've probably released kb/m long time ago, but managing the message would be hard for them.
with uwp apps available on Xbox now, becomes even harder if kb/m was fully supported. It's using win10 core, probably had to disable kb/m more so than implement it.

I wonder if something similar to this is on the drawing board for Xbox.

Seems like WindowsRT all over again, but maybe they think they've figured out how not to have it be a spectacular failure this time.

 

[mrcorbo]

Right, on paper this sounds good, but it doesn't actually contain the same functionality as dual memory pools. So thinking out loud here;
So while pointer switching is faster than copying, you run into some interesting issues that could arise, which will need to be accounted for

Recall that GPU can write results to DDR or esram
A)
move DDR to ESRAM
gpu consumes esram
write results back to esram

The esram version of that memory location is now modified in esram but perfectly normal on DDR3.

If we pointer redirected to indicate that once a mov statement was made that you just switch a pointer, the GPU is now modifying the original, which if you still depend on the original being there, this could present an issue.

or more probable:

B)
mov DDR to esram
CPU overwrites the memory location in DDR3

A pointer redirect is detrimental here.

While it works with PS4 because developers always had this behaviour (so they know they should not be doing scenario A or B), I don't know if that case can apply freely to XBO.

Those are both copies, not moves. If you move something from one memory location to another, you open up the location you are moving from to future writes, so no program is going to expect the data to still be in the original location after a move. Copies would have to be handled with an actual transfer of data. There's no way around that. I wouldn't expect that copies are very common, though. They are not optimal uses of memory bandwidth or capacity. I expect someone will correct me if I'm wrong about that, though.

 

[Jay]

I'm not going to pretend to know the memory system etc.
especially as this is from vague memory from years ago.
but didn't it use a crossbar, page table layout, also think it could be mapped to memory pool.
the access in x1 bc mode shouldn't be hard to emulate.
only problem I can see is latency or more likely overall contention. But if we accept that they have gotten rid of the esram then the much higher bandwidth must negate it.
maybe even vega tech could lower the bandwidth and contention issue.

 

[sebbbi]

I would consider code which breaks on some timing changes (on mostly variable latency things in the first place!) a bug or badly programmed these days. We aren't in the old console days anymore, when everything had a fixed latency and one could count clock cycles to the next line drawn on screen or something. One has to do proper synchronization anyway. Which means games are less likely to break (they shouldn't at all in my opinion).

Agreed fully.

Modern game code is not level specific. Everything is data driven. Same code is used on multiple levels and multiple scenarios. You can't guarantee timing as data changes from situation to situation. Simply looking at another direction drastically changes timings. Code is broken if it breaks when level designers and artists change things and polish content. Code needs to work with DLCs as well (future unknown content). Even if you don't have a PC build, you run have debug builds with lots of validity checks (slow down). Developers will see lots of different timings during the developing process. Most timing bugs will be cought before shipping the game.

Forward compatibility problems (regarding to timing) should be uncommon in modern games. And definitely not intentional. But it is always possible that some race condition bugs might remain in large code bases that weren't found during development. Running multithreaded code lots of times doesn't prove it is correct. But then again you can't know 100% sure it never crashes on the target hardware either.