More "baseless" talk from the Inq?

[KimB]

Well, fortunately the bias shouldn't be so bad that it will change that dramatically from frame to frame. Most of the time it should hover quite close to the center of the frame.

 

[BRiT]

Well, fortunately the bias shouldn't be so bad that it will change that dramatically from frame to frame. Most of the time it should hover quite close to the center of the frame.

I imagine for some games it wont be near the center at all. The games with constant HUDs, flight canopy, car dashboard, or open areas with simple sky or backdrops would easily skew the workload middle-point by quite a bit. It'll be interesting to see how they've decided to handle the situation.

 

[jvd]

Wouldn't a problem come up if say your in a fire fight and 8 or so rockets went off on the lower half of the screen ?

 

[KimB]

I imagine for some games it wont be near the center at all. The games with constant HUDs, flight canopy, car dashboard, or open areas with simple sky or backdrops would easily skew the workload middle-point by quite a bit. It'll be interesting to see how they've decided to handle the situation.

But in games like those, the scenes are also much more consistent from frame to frame, or the cases where the scenes change a lot ("open area with simple sky or backdrops") are cases where the worst-case is normal play, meaning any sudden changes (looking up/down) really won't hurt.

 

[KimB]

Wouldn't a problem come up if say your in a fire fight and 8 or so rockets went off on the lower half of the screen ?

I don't know when that would happen. But regardless, the thing that slows down a system with the rockets is the smoke, and that tends to linger, so only one frame will be a bit slow, the rest would be quite fast.

 

[Dave Baumann]

I imagine for some games it wont be near the center at all. The games with constant HUDs, flight canopy, car dashboard, or open areas with simple sky or backdrops would easily skew the workload middle-point by quite a bit. It'll be interesting to see how they've decided to handle the situation.

But in games like those, the scenes are also much more consistent from frame to frame, or the cases where the scenes change a lot ("open area with simple sky or backdrops") are cases where the worst-case is normal play, meaning any sudden changes (looking up/down) really won't hurt.

I think you’ll find that, generally speaking, even it FPS’s the majority of the complexity and overdraw is at the lower half of the screen, meaning the bias will almost always be at the one board rendering a greater portion of the screen than the other.

In a twich game you'll often be looking in one place at one time and thn forced to look up, or somewhere else another, which can redistribute the requirements very quickly.

 

[trinibwoy]

In a twich game you'll often be looking in one place at one time and thn forced to look up, or somewhere else another, which can redistribute the requirements very quickly.

Wouldn't the latency caused by the load balancing logic be the same regardless of the delta in the workload between frames. Why should it matter whether the scene changed a lot or not at all? Even in a twitch game a rapid up/down movement should consist of several frames during which the balance should be gradually changing. The balancing ratio will definitely be chasing the frames but the ratio for frame x shouldn't be that off from x+1 even in a rapidly changing scene with high fps.

I'm more interested in understanding how Nvidia plans to evaluate a scene quickly enough to determine the busiest part while trying to maximize the potential of both cards.

 

[Xmas]

I'm more interested in understanding how Nvidia plans to evaluate a scene quickly enough to determine the busiest part while trying to maximize the potential of both cards.

The driver knows how fast each card finished rendering its share. So, let's say they split 50/50, and the upper half is finished twice as fast, then the next frame will be split 67/33 or similar. This won't be perfect, but it's quite good really.

Even in a fast-paced game, the load doesn't shift much from frame to frame. In fact, our visual system pretty much requires that there be no big changes per frame, because otherwise it looks jerky. So a fast-paced game requires more fps, but the workload shift is still small.

 

[trinibwoy]

The driver knows how fast each card finished rendering its share. So, let's say they split 50/50, and the upper half is finished twice as fast, then the next frame will be split 67/33 or similar. This won't be perfect, but it's quite good really.

Assuming were talking about the screen split solution, then the load balancing is probably going to be judged according to the prior frame - i.e. on frame 1 it measured that board 1 finished xx milliseconds before board 2, hence on this frame due to be rendered next I'll bias the frame to render xx more lines on board 1 and xx less on board two.

Hmmmm, that should work quite well actually. And the latency for such a calculation woud be insignificant. Thanks.