Digital Foundry Article Technical Discussion Archive [2014]

[liolio]

It would have been interesting if Amazon worked his ass off so a game like X-com enemy unknown have seen an almost simultaneous release on Fire TV and Android.
It is more interesting as it is a "real game" coming to mobile platform. I think we are going to see it happens more and more in the upcoming years.

 

[HTupolev]

A CRT has discrete RGB pixels, certainly horizontally. You can't define an image pixel value between discrete pixels and have it rendered correctly. Potentially, vertical resolution had no fixed resolution on a Trintron style monitor, but very many older monitors used fixed ordered grid or hexagonal/pentile grid matrices.

So a 1024x768 monitor had 1024 RGB pixels horizontally and 768 pixels vertically. Drawing 800x600 or even 640x480 on that monitor resulted in upscaling and a blurry image, but the analogue change of the drawing meant the steps weren't discrete as on LCDs. 800x600 on an early 1024x768 monitor had nearest neighbour scaling which is why it looked crap, with some pixels being double height/width.

Modern LCD's scale the signal to the display much like a CRT did naturally with interpolated values. It can still look terrible because it'll be blurred, but that's exactly what CRTs did. They just had smaller screens so we didn't notice it as much.

Not exactly.

CRT's do have discrete color elements, but it would never have been realistic to target the electron beam element-for-element. Hence the way they actually work is by sending the several colour beams toward the screen from several angles. Using a metal mask behind the phosphors, they ensure that only the beam for a certain colour hits the phosphor for that colour (even though each beam is wide enough that it's hitting several groups of phosphor display elements).

What this means is that you can (and do) usually use far more colour elements than you're displaying "native" pixels. It's why dot pitch (the distance between phosphor elements) is marketed as a totally separate value from display resolutions. It's, despite VGA using various resolutions on both axes, why CRTs without modern scalers are entirely capable of displaying the various signals. It's why CRTs sometimes have analog knobs for things like tilt, fishbowling, and zoom, and why these don't affect the core image quality much.

The overall impact is that CRTs wind up scanning something that approximates a gaussian-ish path across the screen. It's analogous to using an image scaler on an LCD, but it's like using a really amazing scaling algorithm onto a screen that's usually pretty high-resolution for the signal. Which makes it a very delicious image reconstruction filter.

There's no "nativeness" to 1024x768 on a "1024x768 CRT" that goes away when you use 640x480. 640x480 will look less sharp, of course, but that's the inevitable result of sending less data.

Incidentally, you probably couldn't find a CRT whose phosphor mask could actually be exactly described in terms of rectangular-grid resolutions, like what is typically meant by "1024x768." Aperture grilles have no discreteness on the vertical axis, and shadow masks and slot masks both use staggered triad patterns that don't lie on a rectangular grid.

 

[DavidGraham]

x86 has relatively little to do with it. It's an ISA, so it imposes substantial influence on the available registers and operations, but it doesn't have any strict control over the pipeline structure.

I would characterize it as the benefits of having a non-sucky CPU. There are PPC cores more capable than Jaguar, and nothing inherent to x86 that Jaguar does much better than Xenon.

Yes, I tried to be clear that I was talking about old in-order PPC cores only. Modern out-of-order PPC/POWER cores are very much comparable to modern x64 cores.

Sorry, recent advances in PPC architectures must have slipped my mind. So if the choice between comparable specifications, would you rather have an X86 CPU or a PPC CPU in consoles?

 

[HTupolev]

Sorry, recent advances in PPC architectures must have slipped my mind.

It's not just "recent advances," even. Xenon and CELL were always exotic and lopsided architectures.

Look at something like the GameCube's CPU, which also uses a PPC ISA. It has some degree of things like out-of-order execution despite a much shorter pipeline, and it's not very SIMD-heavy. Much less focus on floating-point throughput, and lower clock (even relative to the process node), but it's probably much easier to get good IPC on a thread. Paradigmatically, Gecko and Jaguar have some things in common compared with Xenon and CELL (not that Gecko and Jaguar are particularly similar as a whole).

 

[3dilettante]

The contemporaneous PPC core for Xenon was POWER5, which in many aspects would rival or best Jaguar, although it predates the expansion of vector widths and power management that the x86 core has had a decade of progress to benefit from.

At the time, it would have been massively over-engineered for a console, but it would be indicative of the level of implementation quality IBM was capable of--and what did not happen for Xenon.

 

[Shortbread]

Talk about poorly optimized: Daylight on PS4 and PC

Speaking of performance, despite missing out on many perks, the PS4 still struggles to even lock down 30fps at points. In the very first hub area we get easily repeatable stutters to 0fps, resulting from auto-saving and background level streaming (the fps counter in the video below updates at the beginning and end of the dip, so you don't see a 0fps update but we can confirm 70 duplicate frames there). The majority of the game is better than that, but fluctuations between 30-40fps still leave the game's controls feeling very off-kilter, with spikes to well over 130ms in frame-time obviously having a substantial impact on controller latency. Given the power of the PS4's GPU we expected much, much better from Unreal Engine 4 - and with so much of the world obscured anyway, we're barely seeing the visual pay-off.

PC performance is hardly better. Slotted into a test rig equipped with an Intel i7-3770K processor clocked at 4.3GHz per core, with 16GB of DDR3 RAM, a lower-end card like the HD 7790 gives very poor returns. In fact, we get a permanent 20fps reading from the card while playing at full 1080p with all settings maxed out and v-sync active, which is hard to believe given the visual quality is hardly cutting-edge.

To bring performance back up to PS4-levels, we need to scale down lighting, shadow, and resolution upscale settings to medium (circa 768p), which results in a variable 40fps performance overall. But for the locked 60fps holy grail, the only way forward is to drop this resolution upscale option all the way to very low, pushing out the blurriest image possible. Playing this way is far from recommended - a £220 price-tag for the Nvidia GTX 770 being necessary for true 1080p60 play - but even then the major hub areas slow down to 50fps.

 

[London Geezer]

Sometimes it does make you wonder how certain titles go through quality control....

 

[Shortbread]

Sometimes it does make you wonder how certain titles go through quality control....

Sony must have been scratching their ass when this came down the pipeline for review.

 

[Deleted member 13524]

I think The Amazon Fire TV looks quite good actually. It's capable of running almost Xbox 360 level graphics at a lower price.

Haha. No.

I wonder how this device compares to iPad Air / Retina Mini in performance.

Why don't you see for yourself?

The Fire TV uses a standard Snapdragon 600 from early 2013 coupled with dual-channel LPDDR2 for ~8.5GB/s total bandwidth (CPU+GPU), just like the HTC One.
It has about half the 3D performance of an apple A7 and it's very far away from the X360.
The first ultra-mobile SoC to ever reach close to PS360 performance is the Tegra K1, which is about 4x faster than the Snapdragon 600 in 3D rendering.
Combine that with the years-old optimizations that were made for the X360 and you get even further away results.

Amazon clearly didn't design the Fire TV with gaming as a primary concern.

Sony must have been scratching their ass when this came down the pipeline for review.

Sony must have been desperate to release anything that isn't the typical creative/retro 2D Indie game for the PS4.

 

[Davros]

Zombie Studios forges a terrifying experience

It certainly does..

 

[chris1515]

http://www.eurogamer.net/articles/digitalfoundry-2014-child-of-light-face-off

DF face off Child of light

 

[Shortbread]

What is bottlenecking the XB1 that it can't keep pace (consistent framerate) with even the older systems? That's bad...

 

[iroboto]

What is bottlenecking the XB1 that it can't keep pace (consistent framerate) with even the older systems? That's bad...

I thought both next gen consoles are super sampled at 1440p back down to 1080p according to the article?

Correct me if wrong, but wouldn't the lack of ROPs have an effect in this scenario?

 

[Shortbread]

I thought both next gen consoles are super sampled at 1440p back down to 1080p according to the article?

Correct me if wrong, but wouldn't the lack of ROPs have an effect in this scenario?

That could be part of it ...but fluid physics as well.

 

[chris1515]

http://www.eurogamer.net/articles/2014-05-13-the-witcher-3-may-run-better-on-ps4-than-xbox-one

Not a Digital Foundry article but CDprojekt told to Eurogamer the PS4 version of Witcher 3 may run slightly better than the Xbox One version...

 

[taisui]

/shrug, with all that 50% more CU and 100% more ROP it better runs better.

 

[Arnold Beckenbauer]

Tech Analysis: Half-Life 2 and Portal on Android

First up, the bad news. Loading up Half-Life 2, we discover a game that is very much a stripped-down version of the PC original, bereft of the Lost Coast enhancements and running with the equivalent of what appear to be low settings. There's no anti-aliasing whatsoever, resolution is pared back to 600p, texture filtering is pretty hideous with no anisotropic support, while the lack of shadows in some areas can be quite disconcerting.

It's more a port from the Xbox360's version (Orange Box):
http://www.youtube.com/watch?v=tYLvzCGJ2jM
The Orange Box
We pit EA's port against PC and 360.

...

Half-Life 2 frame-rates are also disappointing, as you can see from the analysis video - in common with many Android games, Half-Life 2 runs completely unlocked, with anything from 20fps to 60fps action depending on the complexity of the scene. Most of the time the game runs north of 30fps, which sounds great in theory, but keep an eye on frame-time - here we see a frequent lurching between 16ms, 33ms and 50ms updates, producing a highly inconsistent, juddering effect. The end result is a game that doesn't feel particularly good to control - even though the actual hardware end is well taken care of owing to the excellent Shield pad design. We also note occasional fleeting freezing issues, characterised by split-second repeat audio.

 

[liolio]

They should make a comparison between the shield version and HL2 running on one if those 8" windows 8.1 tablets.

 

[Deleted member 13524]

Those results seem odd.
The Geforce 7900GTX is supposed to be a bit worse than Tegra 4 in raw pixel shader and vertex shader performance. The 7900GTX used to soar Half Life 2 Lost Coast over 60 FPS at 1600*1200 maxed out.
The largest difference would be memory bandwidth and number of ROPs (~50GB/s 16ROPs for the 7900GTX vs. 15GB/s 4 ROPs for Tegra 4), but would that make a big difference on a resolution as low as 1066*600?

CPU performance shouldn't be the issue either.. back in 2005 the top-end would be a 2.4GHz single-core Athlon 64.
A quad Cortex A15 shouldn't be much slower, not even in single-threaded performance.

So either the ports were poorly optimized or the Source Engine just doesn't bode well in ARM CPUs compared to Unreal Engine and id Tech4/5.



EDIT: Here's Lost Coast running @ 720p in medium settings in the Asus T100 (Intel BayTrail, 16GB/s bandwidth, 4ROPs too I think):
https://www.youtube.com/watch?v=pUVNy1_k8Xs
So I guess it's not bandwidth nor fillrate.

 

[AlNom]

Those results seem odd.
The Geforce 7900GTX is supposed to be a bit worse than Tegra 4 in raw pixel shader and vertex shader performance.

Is it (bearing in mind the definition of core versus old shaders)

My memory is a bit fuzzy, but for G71, ignoring the mini-alu/scalar unit, I thought the raw flops was

24 PS* vec4 * 2 ALU * 2 flops/ALU *650Mhz = ~250 GFLOPs
8 VS * vec4 *1ALU * 2flops/ALU * 650MHz = ~42 GFLOPs

224 madd/clk

Whereas, Tegra4 should be

4 PS * vec4 * 3 ALU * 2 flops/ALU * 672 MHz = ~64 GFLOPs
6 VS * vec4 * 1 ALU * 2 flops/ALU * 672 MHz = ~32 GFLOPs

72 madd/clk

where ALU <-> MADD.

They're also only using bilinear filtering, so they seem to be lacking in texture fill.

That said...

So either the ports were poorly optimized or the Source Engine just doesn't bode well in ARM CPUs compared to Unreal Engine and id Tech4/5.

EDIT: Here's Lost Coast running @ 720p in medium settings in the Asus T100 (Intel BayTrail, 16GB/s bandwidth, 4ROPs too I think):
https://www.youtube.com/watch?v=pUVNy1_k8Xs
So I guess it's not bandwidth nor fillrate.

The impression I got from the performance analysis video was issues related to physics & objects (e.g. larger view distance outside, barrels indoor, overdraw).

Anyways, Source seems bad all around, mmmkay.