Digital Foundry Article Technical Discussion Archive [2015]

Status
Not open for further replies.
Yea, I just googled it, you guys are correct. It is triple buffered @ 30fps.
So the remaster is quite a bit faster in latency, but I suppose one could say equivalent to triple buffered 60fps ;)

So, I am assuming input lag = controller lag.

http://www.eurogamer.net/articles/digitalfoundry-lag-factor-article

As Neversoft itself is responsible for most of the latest Guitar Hero games, where latency is hugely important, it is perhaps not surprising that Mick West took such an interest in this subject, and his conclusions are intriguing.

  • The lowest latencies a video game can have is 50ms (three frames) - the PS3 XMB runs at this rate, but few games reach it.
  • Most 60FPS games have a 66.67ms latency - Ridge Racer 7, for example.
  • 30FPS games have a minimum potential lag of 100ms, but many exceed this.
  • Game developers should test their own games using the camera technique in order to weed out bugs - West says that Heavenly Sword's response slows down to 300ms just by turning the character, and reckons it's a technical issue that should have been resolved before going gold with the game.
  • Citing GTAIV as an example, West suggests that a 166ms response is where gamers notice controller lag, which could also explain the Killzone 2 furore too.
  • Game reviewers should accurately measure latency for their reviews where controller lag is an issue, in the hope that sloppy game response times come under far more scrutiny.

Arwin, why no PS3 TLoU on your site :p
 
pornhub10.jpg
 
Those of us working in cluster and server farm environments knew this 15 or so years ago. Even then the writing was on the wall; it was more economical to go wider than faster. It was interesting reading developer's issues with PlayStation 3 architecture, particularly parallelisation (or 'jobyifying') a basic problem into many parallel jobs. As always with parallelism, the wider you go, the more latency becomes a technical barrier. If you think managing L1 and L2 cache is difficult, pan out and try managing L4 and even L5 cache.
Halleluja.
Managing data access and dependencies have been key in performance critical computing for a very long time. It has mostly been the simplicity of consumer computer hardware that has shielded the majority of coders from this fact, plus of course the fact that a lot of code just isn't performance critical, at least when viewed in isolation.
However.
Since I'm not interested in computation per se, but in science, I find it depressing to see so many bright minds trying to fit old approaches to problems to more demanding computer architecture, and feel that this reduces the work put into finding new approaches to problems that use more intelligence, since it introduces data dependencies that do not map well to current hardware trends. Simple algorithm+massive computational load seems, for whatever reason, to have higher status than complex algorithm+lower computational load. Maybe it's because of the sex appeal of FLOPS, maybe it's because of the deeper understanding of the underlying problem required for the second option. It doesn't really matter. But since science fundamentally revolves around increasing understanding, and then applying that to solving relevant problems, I'm a bit saddened to see bright scientific minds being diverted towards fitting simplistic approaches to the limitations of current hardware. Maybe it's just my field, maybe it carries over into the entire industry. I don't know.
 
Science is always limited by business. If you need results now, you can't afford the luxury of investing in R&D to develop new coding paradigms that'll be ready who-knows-when. Games are a great example of this. When PS3 came out, devs were just trying to get something out the door and weren't going spend a year or three developing a new mindset and architecutres. This gradually happened, helped by a cooperative effort among devs to advance the field.

I've known of academics coming in to a company with a view to changing the coding practices and architectures of the systems. What they prescribed would have resulted in lovely code, but no products for a few years and no means to support existing products.

That's basically why we have academia, to pootle about with new ideas without the constraints of operating a functional business. Short of a complete societal transformation towards an egalitarian society focussed on advancing mankind rather than operating around the structure of commerce, that's not going to change. With our current structures, advancement will come from academia, entrepreneurs (very limited in what they can do in computing paradigm shifts!) and big business investing in lucrative future markets.
 
Arwin, why no PS3 TLoU on your site :p

Heh, you took the hint, nicely done. :) I made the PS4 version a child of the PS3 version, so you get the info from both side-by-side when you look at that version, and I updated and linked information from the original DF article. Now I should also update some info on the PS4 version from the GDC presentation and link that.

EDIT: and from the DF article on the next-gen version, etc. Really wasn't very complete yet, but now it's much better.
 
Last edited:
Bit of a noobie question, but I can't seem to find an answer for it. On the topic of multithreaded-job dispatches wrt: I guess in this case, Naughty Dog's presentation & Insomniac's presentation.

Insomniac leveraged a lot of SIMD instructions to handle a lot of their code on the CPU. It's 256 bits wide IIRC, so essentially 4x64 bit vectors, they were able to speed up their code quite quickly.

Now I've gotta ask about the multithreaded case:

Is it 1 SIMD register per core on Jaguar? Or is it 1 SIMD register for the whole CPU?
I only ask because I want to know if in a dispatch/multithreaded engine, if multiple threads can access their own SIMD, or do they need to wait until it's free

Thanks,
 
Managing data access and dependencies have been key in performance critical computing for a very long time. It has mostly been the simplicity of consumer computer hardware that has shielded the majority of coders from this fact, plus of course the fact that a lot of code just isn't performance critical, at least when viewed in isolation.
I am not sure what you mean by simplicity. If you mean simplicity in terms of what architectures present to the programmer--that was intentional, or simplicity in terms of what they are internally--that is not the case.

Simple algorithm+massive computational load seems, for whatever reason, to have higher status than complex algorithm+lower computational load.

Maybe it's because of the sex appeal of FLOPS, maybe it's because of the deeper understanding of the underlying problem required for the second option. It doesn't really matter.
There are a number of ways to interpret this, since computational load vs complexity can be seen in one area as a trade-off between ALU work and memory accesses and additional levels of flow control.
Given that ALU throughput is the element that is scaling best with process transitions, sometimes additional ALU consumption can avoid expending energy on other sources of complexity.
I would also ask about the properties of the more complex algorithm versus the simpler competition. What is the scaling factor? What is the fixed cost? How consistent is it? What is its worst-case? How hard is it to validate? Is the improvement significant?
A lot of fancy solutions have turned out to be problematic when these questions get asked, and they do get asked when it comes time to deploy them in a commercial project.

That aside, there is a workload that desperately wants more FLOPS, and it pays the money that makes it even possible to have the system in question. One works with what one can get.

But since science fundamentally revolves around increasing understanding, and then applying that to solving relevant problems, I'm a bit saddened to see bright scientific minds being diverted towards fitting simplistic approaches to the limitations of current hardware. Maybe it's just my field, maybe it carries over into the entire industry. I don't know.
Isn't making use of what is available subject to design constraints and economics engineering?
They could expend their limited time and resources on fitting approaches to the limitations of hardware that doesn't exist, if that somehow brings in the money, nor do I think this is particularly fair assessment of what it took to bring the current hardware to market. These architectures are the output of large-scale semiconductor manufacturing, and years-long efforts to design chips that are unbelievably more complex than the highest-end devices less than a decade ago.
 
No denying it, Naughty Dog loves challenging themselves and finding (creating) the paths on achieving their goals. Developer Gods they are... :yep2:

Not to take anything away from ND, but I was chuckling as I was reading that presentation as they arrived a solution similar to what I've been working with for years.

The most impressive part was how much they got done in a short amount of time without shipping a broken game.
 
Status
Not open for further replies.
Back
Top