Digital Foundry Article Technical Discussion [2018]

And ?How does it work exactly ?

 

Only if Sony could force AF (anisotropic filtering) too, considering how many PS4 games are still missing it.

 

I dunno, don't have an XBX

I would appreciate 1440p output on Ps4 Pro though.

 

Likely as it does with the difference between 4K or 1080p.

Plug in the monitor to Xbox, instead of outputting 4K DSR to native 1080p, it does 4K DSR to native 1440p.

Resolution above your native display should always DSR down to your display.

 

unexpected article. but fun to watch

 

Article layout as well.

Why waste the additional silicone or even select that particular GPU (Polaris) if this was [is] going to be an issue?

My take from the article is that Microsoft took their time (a learned lesson from XB1) and selected the appropriate hardware, then optimally configured the X hardware on utilizing more of the silicone strengths, in essence providing a more powerful design. The Pro just seems rushed in retrospect. Not dumping on it (I own one, as well as an X), not at all. Just that Sony could have made smarter choices on Pro's overall architectural approach.

 

Nature of the BC, I gather. Also, there are some passes (e.g. shadow) that can still make use of the extra depth fillrate due to compression efficiencies.

 

I'm sure you know each and every game. Speaking of which, are there any post 2016 missing AF? That drama seems to be over (except to BRiT who is scarred).

 

If this is the case, any proof of concept? Meaning, are there any current Pro enhanced games that are actual performing this (i.e., providing better frame-rates than X in certain scenarios)? Games such as GTA V or The Witcher 3, would be a great comparison (if patched) of such methods.

 

Really noob question, but would the checkerboard rendering perhaps need the additional ROPs for performance reasons?

 

The Depth ID stuff probably does, since they're rendering to a full res depth for tagging.

Not off-hand, but I'm only referring to depth passes, which only make up part of the frame. There are some games where heavy action scenes appear to give trouble on the X, but sometimes it's hard to tell given the complex nature of a scene & mismatches in rendering load comparison, especially with dynamic res making things all sorts of weird + whatever the intermediate buffers are made to run at. Naturally, if the X is forced to run at a higher res, bottlenecks can change; for instance, Titanfall 2's post-processing buffers were originally made to run at much higher res in the first OneX patch, but it'd have been difficult to analyze that from screenshots.

 

Architecturally, GCN has a fixed relationship between ROPs and shader engines. Once the choice was made to create a GPU that could turn half of its engines off in order to maintain compatibility with the older two-engine GPU, it meant that there would be more than 32 ROPs.
One half had to have 32 for compatibility mode, and while some non-standard ways of handling Neo mode were speculated, the most straightforward way of handling things would be a straightforward doubling of ROP count.

I have a theory as to which blocks would be related to the ROP hardware, although the die shot shows more significant variation in unit layout than average. There's variation in the CUs on both halves, and even within the left half. I think there could be RBEs on both the left and right, with different layouts. There's potentially divergent layouts even for the hardware on the right.
I think it's more clear with a larger GPU like Fiji where the RBEs are, which makes me think that the layout changes may be related getting everything to fit in the more cramped SOC of the console.

The other item I'm still hazy on is whether the Polaris assumption entirely holds true for either console. I noted the article makes that statement, but compatibility has certain challenges due to some notable shifts in the ISA with the generations after Sea Islands.

I recall the article on Scorpion mentioning that the extra year factored into what they could achieve. Something like the Pro seems to be what was practical in the time frame and price point, possibly due to process maturation and the timing of newer SOC features.

 

Hey 3dilettante,
Question: what is it about shutting off 1/2 the shader engines to perform capability? This seems common between both the 4Pro and 1X.
If next generation is to occur (and use GCN), and they require backwards compatibility for 4Pro/1X enhanced editions, will they also need to shut off 1/2 their shader engines to support it?

And if this condition cannot be worked around... then we're looking at a possible double the shader engines (72/80) to have compatibility with the mid gen refreshes?

 

If the designers want to be as consistent as they can be with regards to backwards compatibility, shutting down two engines keeps geometry throughput equivalent. There may be some subtle synchronization and tiling assumptions built in as well, which could show up in corner cases at a lower or system level when running legacy code. Scorpio's OOO Rasterization feature could some have correlation to the more complex behaviors in the wider front end, which would fall back to a more restricted version in compatibility mode.
One possible scenario I've seen mentioned, though not fully elaborated publicly, is low-level access giving developers options regarding how many CUs may be used for geometry processing or compute. The allocations could require that pre-existing code be reviewed prior to enabling the additional CUs and front ends.

One dependence in modern hardware is in the Vega ISA for primitive shaders, regarding shader engine screen space coverage. The math for determining which shader engine is responsible for which screen tile changes when hopping from 1 to 2 to 4 engines. Some of the patches that are starting to cover the tiling and primitive setup changes indicate different settings are needed based on the shader engine count and resources per engine.
Whether there's a low-level hook with similar exposure in the consoles hasn't been covered, although there are high-level similarities with some features like the PS4's culling methods that might indicate shared behavior.
Some ROP tiling tricks for particle rendering might behave differently as well.

Depending on what happens with GCN architecturally, the same rules could apply. The mid-gen consoles have maxed out the number of shader engines (4), and with the DF article we have evidence the PS4 Pro has maxed out the number of ROPs.
If by 72/80 you mean CU count, that is something that cannot happen unless something else changes with GCN architectural limit of 64.

 

i.e. 8 shader engines.

 

It can't fully utilize them but it's sill faster than only 32ROPs in most cases, around 50%-65% faster (instead of ~100% faster if bandwidth was there). So they were right to include 64Rops because 32Rops would have created a bottleneck comparatively to base PS4.

In others cases (see @AlNets post) improvement can be noticeably higher than 65%.

 

That would be something of an architectural change, with the ceiling of 4 SE per GPU, 16 CUs per SE, and 4 RBEs (4 ROPs in an RBE) per SE.

Backwards compatibility with the mid-gen consoles could imply compatibility with the base consoles as well.
One scenario that can be simplified by shutting down SEs is if there's a fixed CU reservation for a 12 or 18 CU GPU. 8 SEs might conceivably subdivide resource limits to the point that they fall below the granularity the larger GPU can allocate, and the console could opt to shut down engines to avoid that or other headaches.
Shutting down SEs when trying to maintain compatibility with the mid-gen architectures could avoid hazards with reserved resources as well. That aside, the base and mid-gen GPUs currently have front ends that follow the same set of rules as GCN as we know it. A new GPU that breaks those assumptions may have larger differences, or may need to break them in order to provide significant improvement in the future.

I'm curious as to the full reason for why the CUs in the Pro's GPU vary so much. One idea for why some are measurably larger could be that some have extra hardware due to having to juggle two different architectural revisions, although if that were the case for Neo it doesn't seem like it needs to apply for Scorpio.
An 8 SE GPU may opt to limit the hardware cost by putting any prior-generation features on a limited subset, although this could mean limited options for enabling the rest of the GPU in legacy mode.

In the long run, if it's truly a new generation with more CPU grunt and a chance at a fresh GPU architecture, perhaps it would be better to inject a similar compatibility layer for the current gen as that introduced with Scorpio.

 

I'm more curious about the real reason why Sony disabled 4 CUs. Although DF alludes to Sony not wanting to waste chips because of a few bad CUs (quantity Vs. better performance). I'm not so sure that I believe that. I haven't heard or read any particular yield issues with the Polaris architecture, or production problems with them. Though the Pro version is slightly more customized than it's PC brethren, it still doesn't really add up. I'm more inclined to believe the 4 were disable for TDP purposes. Lowering thermal temps within Pro's design. Or maybe disabling them because of memory/system bandwidth constraints. But the yield issue sounds more like guessing, rather than first-hand knowledge.

 

Yield is necessarily the reason for disabling CUs, today all GPUs and all consoles disable CUs for yield. The consoles however cannot resell the perfect chip at a higher margin, so they have a compromise to make. I.e. the additional area used for redundancy ends up less expensive than the yield hit of requiring perfect chips.

 

The existence of a 470/570 SKU means there are chips with defects or other issues keeping them from the top specification. The console APU only has one bin, and as a component of a complete system it has to compete for a share of the overall cost.
Even if Polaris at this point has highly mature yields, they would have been lower early in the product life cycle. The console chip's specification is constant from the time of least mature yields until it stops production.

GCN chips also appear to usually disable CUs in increments that are a multiple SE count, so it may be that this is the least that can be disabled.