some are.
engines take time to change.
the more cpu is the bottle neck the quicker they'll invest to update engine to make use of it on consoles.
pc, easier to not worry about it as much, they'll just have to have a better cpu
Digital Foundry Microsoft Xbox Scorpio Reveal [2017: 04-06, 04-11, 04-15, 04-16]
- Thread starter iroboto
- Start date
-
- Tags
- digital foundry microsoft
engines take time to change.
the more cpu is the bottle neck the quicker they'll invest to update engine to make use of it on consoles.
pc, easier to not worry about it as much, they'll just have to have a better cpu
I'd just hazard a guess that in terms of 3rd party games (multiplatform), the only ones that are going to do patches for 4k are probably the same ones that patched PS4 Pro, or games that will end up patching for both. So I think the PS4 Pro will probably end up determining whether Scorpio uses checkerboard or not. I know the APIs are not the same, but that's probably the trivial part compared to figuring out generally how to implement it. Bunch of PS4 Pro games are just doing 1440p or whatever, so I expect those games would just be higher res on scorpio.
I think he's referring to PC specifically. I don't think he was suggesting that multiplatform console games forgo cpu, gpu features because they are unavailable on the PC.
monstercameron
Newcomer
Puma+ can hit 2.4ghz easily, as seen in Carrizo-L products.
It remains to be seen is how the lack of ID Buffer (if scorpio doesn't have anything equivalent) impacts either IQ or requires additional processing to be on par. It's really not clear from the Frostbite presentation, but since they still plan to use checkerboard even on the original PS4/XB1, it might be a win on all platforms regardless.
Apparently, it only takes a couple weeks from one programmer to implement checkerboard. So difficulty in implementation will probably not be a big deal for any AAA developers. They'd probably try both.
Last edited:
Apparently Scorpio has hardware support for Checkerboard rendering. What that is still remains a mystery that DF will probably expound upon in a future article.
Sebbbi is never wrong
Most games come with DX11 as well. But that often handicaps DX12 games as a result as most
folks rewrite DX12 to emulate a DX11 pipeline when they shouldn't be.l (on PC)
On console you only have a choice between DX11 or DX12 for Xbox one. They removed fast semantics, so all new games must be dx12. That being said if you want any sort of performance on XBO you cannot use dx11. And if you make a game with a dx12 pipeline only, then translating it PC would be forced w10 but it would be easier.
Makes the XPA initiative seem more desirable to engage in, not a lot of effort and more exposure and more purchasing.
As for specific functions I believe he is referring to specific feature levels. The features described by MS for Scorpio all still reside within FL12_0 which is the lowest baseline for 12 and also this console generation.
They don't. Even if they did (which I doubt), the customization looks for D3D12 API calls which PS4 doesn't support.
edit: Most console games are GPU limited, so that's why this won't have much of an effect. Until games are CPU limited we can start talking like this feature matters
Last edited:
1172 MHz x 32 ROPs x 8 Bytes = 300 GB/s for RGBA16F, right?
Ah yeah. I flipped the 2 and 7.
280GB/s
(1024 B per kB etc etc)
Edit:
*grumble -ibibytes*
300GB/s ala 326GB/s
Last edited:
yep, thats why I never assumed it meant removing esram code.
memory alignment could mean expanding esram emulation size, and aligning memory to that.
not saying it is the case, just that I don't have a clue how easy it is to change renderer to not be esram based.
any devs like to chime in which is easier to do and why?
2days compared to 2 weeks, unless the x1 code is already checker boarding, I don't see why a dev would go with that than just native, even if they don't hit native 4k.
I'm still talking about patching old/current games.
Last edited:
Are you sure it's hardware support?
yep, it will remain to be seen.
but there is a big difference between couple days and couple weeks if a studio was going to decide if they are going to patch a game or not.
checker boarding also doesn't give consistent results, depends on implementation.
so simpler, quicker, deterministic results, leads me to believe that the go to patch method will be native res patch.
if the game on x1 isn't already checker boarded.
Another thing to throw into the mix is the possible hit from contention with the CPU. PS4 developer slides showed CPU prioritised accessed slicing up to 40 GB/s from the PS4's real world BW figures. If that were to scale with clockspeed, and there were no mitigating factors, could we be seeing PS4 Pro losing up to ~53 GB/s and Scorpio losing up to 58 GB/s from real world available BW for the GPU?
As I understand it (or potentially misunderstand it), in addition to higher total BW, a wider bus might be more likely to keep at least some needed data flowing to the GPU and therefore avoiding stalls ... though I'm not certain, and have even less idea if a potential theoretical advantage from additional width would make a real world difference.
Whatever, based on BW alone, Scorpio would seem to be in a better place to keep the CUs in the GPU busy even under adverse conditions due to CPU conditions. Speaking theoretically. And naively. And possibly ignorantly.
Ah, nice. I guess we'll get details soon.
Having independent channels to spread the load over would help reduce the chance that one controller's ability to schedule accesses is exceeded.
It would be nice to revisit that graph with the new consoles with the introduction of DCC.
The main benefit is that the compression saves memory transactions, which would 1) provide more room for the CPU's accesses and 2) potentially lower the GPU's utilization percentage since there are more gaps in its access stream.
The level of traffic associated with the metadata path wouldn't have been a factor back then, either.
Actually measuring this may be tricky if the tools used to measure bandwidth cannot tell which accesses they've sent off actually generated the expected number of DRAM accesses, or how one tests differing levels of compression.
Another point I'm curious about is the bonus feature of forcing all filtering to AF (ed: for older titles), in case some code using bilinear and trilinear is actually depending on behaviors from that level of filtering.
Anarchist4000
Veteran
Not accounting for DCC or other compression techniques, although I'm not sure how much HDR benefits from compression.
Another possibility is ROPs working on L2 as a Scorpio customization like in Vega. That might make sense if Microsoft anticipated more compute in the future and added bandwidth. More DF articles would be nice.
Ike Turner
Veteran
Heads up for those who don't know yet: Gamasutra will have an exclusive in-depth breakdown of Project Scorpio this Wednesday (this time from a software/gamedev perspective). They were invited by MS like Richard so it will be brand new stuff not rehash of last week's info.
https://twitter.com/gamasutra/status/851557447416168448
https://twitter.com/gamasutra/status/851557447416168448
Similar threads
