Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Unreal Renders a Frame

interplayoflight.wordpress.com

Post reply on HN
Print view View original

131–140 of 167 posts

Re: How Unreal Renders a Frame

#131

Post by katastic »

ilaksh wrote: post #130

I personally believe much of this will become passe within five years or so. I have seen a few demos of real-time path tracing software running on GPUs. I know GPUs are fast, but I wonder if there is a way to do the same math on an ASICs or FPGA that could be even faster? The main issue with existing things seems to be being able to do enough iterations to get a clear picture. Anyway I believe a lot of the tricks rel…

Perhaps. Too bad we hit a GHZ wall, so the only thing we can do now is add more cores.

FYI: For 6K and 8K, both nVidia and AMD tech reps have said that "multi-GPU" (not CORE) solutions will be required to reach those. But they also said once they hit 16K, they'll have "real eye quality" in terms of DPI which comes with lots of extra "realism" for free. Like, watch the new Jungle Book in 4K and certain scenes of mountains will blow your mind and feel "real" (without any 3d glasses) and your brain is like "holy shit, I'm not watching a movie (for this split second), this is something real." But most scenes still don't. We're so close to photorealistic, I can taste it! (Like that GTA 5 photorealism mod on HN yesterday.)

That's why they're all moving to Vulkan. OpenGL is single-threaded and a PITA to easily exploit multiple GPU solutions. (Global state, one draw thread.)

Re: How Unreal Renders a Frame

#132

Post by looki »

iainmerrick wrote: post #100
sho_hn wrote: post #97

Earlier quoted context omitted.

> Do game engines make heavy use of threads though? Boy do they, yes.

Can you go into more detail? (Or point me at some up-to-date books or blog posts!) I'm specifically curious about CPU-intensive stuff that is sharded out to multiple threads. That's your classic multithreaded programming, the sort of thing you'd do in scientific computing, but I always got the impression games people were skeptical about it, due to unpredictable performance and the high risk of bugs.

A bit older but this presentation about Killzone 2's usage of the PS3's Cell architecture was pretty neat https://www.guerrilla-games.com/read/the-playstation-3s-spus...

Re: How Unreal Renders a Frame

#133

Post by iainmerrick »

wlesieutre wrote: post #115
iainmerrick wrote: post #100

Earlier quoted context omitted.

Can you go into more detail? (Or point me at some up-to-date books or blog posts!) I'm specifically curious about CPU-intensive stuff that is sharded out to multiple threads. That's your classic multithreaded programming, the sort of thing you'd do in scientific computing, but I always got the impression games people were skeptical about it, due to unpredictable performance and the high risk of bugs.

Not an expert, but the version of it that I've heard is your main game loop handles all interaction with the game state to avoid issues. You can offload rendering into another thread pretty safely, and anything that alters game state would queue up its state changes for batch processing. That way if you're running a multithreaded physics simulation you can get two separate bullet collision detections on one object, a…

UE4 in particular I know handles all game logic in a single thread, and you can't touch UObjects from outside of that.

Yeah, that's the kind of thing I was thinking of when I said games programmers seemed skeptical of threads.

Some of that coarse-grained parallelism could possibly be done in JS with Web Workers, but those have their own problems. (See the recent discussion here about the "tasklets" proposal: https://news.ycombinator.com/item?id=15511519)

Re: How Unreal Renders a Frame

#134

Post by Jach »

maccard wrote: post #70
hyperpallium wrote: post #43

Earlier quoted context omitted.

Minor nit: some of those needn't run every frame (ai/pathfinding, gameplay logic). It's also possible to calculate future points and interpolate between them per frame. A nasty trick is to have shadows running at a half framerate (Crysis did this).

I don't really think it's minor, or a nit! But at the same time, I had to simplify or I'd never have stopped writing.

Brandon Bloom simplified it best I think: "You have to solve every hard problem in computer science, 60 times a second."

Re: How Unreal Renders a Frame

#135

Post by robbies »

iainmerrick wrote: post #100
sho_hn wrote: post #97

Earlier quoted context omitted.

> Do game engines make heavy use of threads though? Boy do they, yes.

Can you go into more detail? (Or point me at some up-to-date books or blog posts!) I'm specifically curious about CPU-intensive stuff that is sharded out to multiple threads. That's your classic multithreaded programming, the sort of thing you'd do in scientific computing, but I always got the impression games people were skeptical about it, due to unpredictable performance and the high risk of bugs.

Modern game engines parcel out work via a job system, where functional tasks are dispatched to the cores in a system. This is opposed to the idea of 'one core/thread will own a task for the lifetime of the application, while checking in with a master core/thread'. Actually, most games have a hybrid model. Usually one thread/core is dedicated to rendering, another thread/core is dedicated to high priority tasks/jobs, and then the remaining resources are used by whatever jobs are left.

http://fabiensanglard.net/doom3_bfg/threading.php

Re: How Unreal Renders a Frame

#136

Post by robbies »

pfranz wrote: post #96
2sk21 wrote: post #6

So all of this processing happens for one frame? And this is going on at 60 Hz?

(I havent read the whole article, but havent seen other replies mention this) Unreal uses an architecture called deferred rendering[1]. It's more complex, but allows for a lot more tricks and the main benefit is that lighting performance is closer to constant, instead of increasing or decreasing with how many lights you have. Forward rendering is the simpler alternative[2]. For Unreal, they had a forward renderer for…

But now the industry is moving away from pure deferred, as it scales poorly with higher resolutions. 4K, high res mobile devices, VR...

Re: How Unreal Renders a Frame

#137

Post by iainmerrick »

corysama wrote: post #120
iainmerrick wrote: post #100

Earlier quoted context omitted.

Can you go into more detail? (Or point me at some up-to-date books or blog posts!) I'm specifically curious about CPU-intensive stuff that is sharded out to multiple threads. That's your classic multithreaded programming, the sort of thing you'd do in scientific computing, but I always got the impression games people were skeptical about it, due to unpredictable performance and the high risk of bugs.

Motivation: The Xbox360 pretty much forced gamedevs into heavy threading if they wanted to get anything done. It had 3 PowerPC cores with 2 hardware threads each. The cores had huge memory latency and no out-of-order execution. IBM's attitude about OOE was "Statically compile for a fixed target" and "Run 2 threads per core and that that'll cut the effective stall cycles per thread in half". The PS3 had only 1 of thos…

Cool, thanks!

I never got to program one but I remember being fascinated by the weird architectures of the PS2 and PS3.

It occurs to me that there are some similarly weird architectures in mobile right now -- it's not uncommon to see Android flagship phones with 8(!) cores, which is just ludicrous. And there are lots of asymmetric "big.LITTLE" designs with a mix of high-speed and low-power cores.

Maybe I'm just reading the wrong blogs, but I've barely seen any discussion on how to optimize code for those crazy Android multicore CPUs, even though it seems like there's potentially a lot of upside. I guess Android is so fragmented and fast-moving that it's a tougher challenge than optimizing for two or three specific games consoles; also Android app prices are low so there probably isn't as much motivation.

Also, Apple is miles and miles ahead of everybody else in mobile performance, and they've consistently gone with just 2-3 cores. Their mobile CPUs and GPUs are very smartly designed, really well-balanced.

Re: How Unreal Renders a Frame

#138

Post by iainmerrick »

robbies wrote: post #135
iainmerrick wrote: post #100

Earlier quoted context omitted.

Can you go into more detail? (Or point me at some up-to-date books or blog posts!) I'm specifically curious about CPU-intensive stuff that is sharded out to multiple threads. That's your classic multithreaded programming, the sort of thing you'd do in scientific computing, but I always got the impression games people were skeptical about it, due to unpredictable performance and the high risk of bugs.

Modern game engines parcel out work via a job system, where functional tasks are dispatched to the cores in a system. This is opposed to the idea of 'one core/thread will own a task for the lifetime of the application, while checking in with a master core/thread'. Actually, most games have a hybrid model. Usually one thread/core is dedicated to rendering, another thread/core is dedicated to high priority tasks/jobs,…

That threading style potentially fits OK with the JS "Web Worker" / "isolate" model, as long as you can pass messages around between threads/isolates very efficiently (probably not the case in current JS implementations).

Re: How Unreal Renders a Frame

#139

Post by izym »

pfranz wrote: post #96
2sk21 wrote: post #6

So all of this processing happens for one frame? And this is going on at 60 Hz?

(I havent read the whole article, but havent seen other replies mention this) Unreal uses an architecture called deferred rendering[1]. It's more complex, but allows for a lot more tricks and the main benefit is that lighting performance is closer to constant, instead of increasing or decreasing with how many lights you have. Forward rendering is the simpler alternative[2]. For Unreal, they had a forward renderer for…

In deferred rendering the cost of lighting is still dependent on the number of lights. In forward rendering it is dependent on both the number of lights as well as the scene geometry. You can apply various additional techniques to make each light much cheaper though.

Re: How Unreal Renders a Frame

#140

Post by staticelf »

goos wrote: post #40
staticelf wrote: post #31

Earlier quoted context omitted.

I think it depends a lot of which company you work for and where in the world you work. For example, there is a lot of game companies in my country and it's illegal to require people to work more than 40 hours a week. I think some may do it anyway by free will or by social pressure, but these people are probably pretty rare. In my country (Sweden) we don't really have a culture where companies pressure people into wo…

As a fellow Swede, I think that's slightly disingenuous. Sure, companies can't officially force you to work overtime, but for sure there are many instances where people are encouraged to bring work home or pull some extra hours to make a deadline – especially at smaller companies.

Yeah sure, but it's far from the work environment in the states or even in other countries in europe. Require people to do some extra hours sometimes is often part of every contract but I have never been required to do so.

Once I had a boss that wanted me to work overtime "unofficially" but I refused. Needless to say, I left that place pretty quickly.

I don't work in the game industry, but I know some people who do and they never work overtime.

Post reply on HN