Digital Foundry Article Technical Discussion [2017]

Status
Not open for further replies.
shadows are fairly computationally expensive, so low resolution shadows are fairly standard. As I understand it, very high resolution shadows are fairly high cost without specific hardware like conservative rasterization.

This is where next gen should have stronger solutions to this if we move to GPU side dispatch coupled with conservative rasterization.
I don't see how concervative rasterization could help speed up shadow-map rendering... I could see it be used to do analytical AA on edges along with depth peeling to reduce the blockyness, but that's about improving the quality of low res shadows, not making them higher res (well you can make them seem higher res thar way), and there are workarounds to do that without concervative rast. and no dev has implemented that yet. Traditional shadow maps are by essence a very brute-force solution.
 
I don't see how concervative rasterization could help speed up shadow-map rendering... I could see it be used to do analytical AA on edges along with depth peeling to reduce the blockyness, but that's about improving the quality of low res shadows, not making them higher res (well you can make them seem higher res thar way), and there are workarounds to do that without concervative rast. and no dev has implemented that yet. Traditional shadow maps are by essence a very brute-force solution.
a poor choice of words on my behalf, I referred to high res; when I mean anti aliased as you noted.
I'm referring to the nvidia demos here:
https://www.geforce.com/whats-new/g...guide#tom-clancys-the-division-shadow-quality
 
this completely tosses out any and all alpha theories.

Obviously... The X has much higher bandwidth than the Pro. The Pro seems to not even have enough bandwidth to feed its GPU in every conditions.

If there is a bandwidth bottleneck on X, it's either because it uses higher settings or runs the game at a much higher resolution.
 
Last edited:
Any indication that the performance differences are API related?
Impossible to tell.
The performance of the title is going to be mainly about how they coded it, algorithms, memory usage etc, total saturation etc.
And whatever tools they use to get there, so that includes the API of choice. Obviously GNM will get them the best result on PS4 Pro. We can't compare it against DX12, this is a near impossible task as we can't get PS4 to run DX12, or Xbox to run GNM.
 
Yesterday I had to register in this forum, I couldn't bare anymore seeing you people here theorizing this and that based on the assumption that the PS4Pro have 64 ROPs. This is absolutely not true.
I'd imagined that this misunderstanding would be cleared fast, but days passed and I'm still seeing people insisting in this wrong fact.
Not, the PS4Pro have only 32 ROPs, like base PS4.
 
Yesterday I had to register in this forum, I couldn't bare anymore seeing you people here theorizing this and that based on the assumption that the PS4Pro have 64 ROPs. This is absolutely not true.
I'd imagined that this misunderstanding would be cleared fast, but days passed and I'm still seeing people insisting in this wrong fact.
Not, the PS4Pro have only 32 ROPs, like base PS4.

I believe the SDK leaks are not allowed to be linked, posted on this forum.
 
There is only really one person theorising that PS4 Pro has 64 ROP's..and from what I can tell it's based on looking at the DF findings and working backwards to fit the theory rather than definitive facts or evidence about the hardware itself. I don't really have a problem with it as that's a lot of what goes on in this subforum. But as far as I can tell no one from Sony has stated how many ROP's PS4 Pro has..
 
I believe the SDK leaks are not allowed to be linked, posted on this forum.

Yes. No links to it or copy and pasting from it.

However from what I've seen posted by others elsewhere ... its from a single test in a specific scenario (discard mode) that processes at 64 pixels/clock. It's not able to hit those nunbers in a write test. The memory bottlenecks to lower performance.
 
Yes. No links to it or copy and pasting from it.

However from what I've seen posted by others elsewhere ... its from a single test in a specific scenario (discard mode) that processes at 64 pixels/clock. It's not able to hit those nunbers in a write test. The memory bottlenecks to lower performance.
Overall much higher throughput than results of base...
 
Benched > 1.5x px/s tahn base even with bndwidth bottleneck

Benched max px/s > theoretical max px/s 8th astrological sign
 
There is only really one person theorising that PS4 Pro has 64 ROP's..and from what I can tell it's based on looking at the DF findings and working backwards to fit the theory rather than definitive facts or evidence about the hardware itself. I don't really have a problem with it as that's a lot of what goes on in this subforum. But as far as I can tell no one from Sony has stated how many ROP's PS4 Pro has..
I'm not sure what specific findings would work back towards the ROP count, but when I've speculated on the Pro's hardware it's from Sony's description of how it transitions between compatibility and Pro mode by activating half of the shader engines.
That pairs with GCN's hard-wired association of ROPs to their shader engine. A succession of GCN architectures and some of the Vega patches for its graphics hardware show a continued association between shader engines and their RBEs.

If the Pro has 32 ROPs with everything on, turning half of the GPU off doesn't standardly lend itself well to having 32 in compatibility mode. I'd imagine that would be noticeable for some legacy titles. There's no iron law that the design couldn't take special measures to change this behavior, just a question about what choice Sony made in a range of possible solutions.

It'd be straightforward to just go with doubled hardware, since Sony's gone ahead and doubled things anyway. It might be something of a waste, although even if bandwidth weren't changed there are some specific scenarios where the doubled hardware and additional caches could be used without immediately hitting the memory bus, or the additional paths could be re-purposed if Sony desired.

However from what I've seen posted by others elsewhere ... its from a single test in a specific scenario (discard mode) that processes at 64 pixels/clock. It's not able to hit those nunbers in a write test. The memory bottlenecks to lower performance.
I suppose the question is whether any tests got results at least substantially above 32/clock, as there tend to be other utilization barriers even in optimal cases.
There are ways of getting more out of the ROPs than memory might allow, some of which have been discussed in other architecture threads. Going back a ways, there were tests done showing particle effects could be ramped up beyond memory bandwidth limits with careful tiling of the pass to fit the small color caches. The ROP caches would miss/evict less often, while the full internal bandwidth of the ROP caches would be in play. It's a possible optimization that would be less sensitive to the modestly improved GDDR5 bus or variable benefits of compression (DCC should interact at the miss handling portion of the pipeline). Having more RBEs means there could be more pixel tiles being evaluated.

On the other hand, many ROP-based methods have lost ground to compute-based solutions, which would seemingly favor an L2 that can host more tiles or thrash less often. If my understanding of the Orbis GPU L2 is correct, that's where Neo would have a shortfall versus Scorpio. It would be an area where the two architectures might have different inflection points.
 
As everyone expected, the Quantum Break upgrade brings higher resolution and visual however there are artifacts. What was unexpected was the artifacts dont seem to be from their rendering approach --DF wonder how it made it past QA.

http://www.eurogamer.net/articles/digitalfoundry-2017-quantum-break-xbox-one-x-analysis


Out of the many Xbox One X upgrades we tested during the preview period, Quantum Break was one of the most intriguing, featuring the choice between 1080p and '4K' modes - both a leap over the base Xbox One's 720p - along with enhanced detail. Visually, it offered a night and day improvement over the existing version of the game, moving more into line with the PC release running on mid to high-end hardware. There was just one problem - performance. The good news is that frame-rate problems are essentially a non-issue in the final release, but the bad news is that several distracting visual bugs have been introduced: distracting artefacts that weren't in the port when we first looked at it.
...
All of which brings us back to our earlier thoughts - this patch has a lot of good news for players. The resolution is higher, texture filtering is enhanced, detail is improved, and the overall frame-rate is now very steady. These elements all result in a game that looks and plays better than it did on the original Xbox One. But the visuals bugs detract from the polish and were never a part of the experience - and how they made it past QA is a bit of a mystery, because they are so glaringly obvious. This is not the original vision Remedy intended for its game, but we remain hopeful that Microsoft will go back in, resolve the issues and finish the job - Quantum Break is still a really cool game and deserves the extra attention.
 
Shame about Quantum Break. Hopefully they fix it. I still think it's one of the most visually interesting games this gen, despite the image quality issues from release until now.
 
Shame about Quantum Break. Hopefully they fix it. I still think it's one of the most visually interesting games this gen, despite the image quality issues from release until now.
Well QB was a bummer for me, too. The patch is really buggy. Textures did not load for minutes ins some parts of the game.
 
Wonder if they shouldn't have just optimized it for native 1080p with a toggle for the temporal reconstruction (their 4-frame accumulation).
 
Status
Not open for further replies.
Back
Top