HDR - The Halo Way * Spin-Off

Status
Not open for further replies.
That's said, keyn does seem to have a valid question. 2xAA is free - so why isn't it used? GeOW didn't use it because of UE3's lighting engine. Why isn't H3 using free AA?
 
I thought this was evident. Using 2xAA requires double the amount of memory for the multisample buffer. If Halo3 uses two full screen buffers for the HDR implementation, then there's no space left in the EDRAM for that - in fact they'd need 20MB of EDRAM for AA...
 
(all of this should be in the other thread!)

So they're fitting both RT's into the eDRAM simultaneously?
 
IIRC nao32 (aka funky colorspace) doesn't work well on 360?

HS developers have confirmed it ? We know it may need a GPU which Pixel-shader performance is really good,but it did not conclude that C1 cannot do this well.

Btw,NT is totally a second-party developers owned by SCE,It means they could not have much time or chance to verify what 360 could do.
 
1) nAo32 doesn't need a GPU with really good pixel shader performance - as long as it's SM2+, it can do nAo32. The hit on the GPU will be more noticeable with lower performance hardware, but depending on the choice of art direction and cost of pixel shaders, nAo32 may be an option even on medium spec hardware.

2) 'Second Party' doesn't really exist. Ninja Theory is an independent developer who started work on HS and Sony paid them to develop it for PS3 exclusively. I don't know if the contract was extended to further games or not. Verification that XB360 can handle nAo32 comes from looking at the released specs. If you can run SM2+ shaders, you can use nA032, which Xenos can.
 
(all of this should be in the other thread!)

So they're fitting both RT's into the eDRAM simultaneously?

Yes, it seems so. For some reason, they have decided against the additional geometry and draw call load which comes with tiled rendering.
 
1) nAo32 doesn't need a GPU with really good pixel shader performance - as long as it's SM2+, it can do nAo32. The hit on the GPU will be more noticeable with lower performance hardware, but depending on the choice of art direction and cost of pixel shaders, nAo32 may be an option even on medium spec hardware.

iirc NAO32 requires like a meager 5 extra cycles (or was it 4?).

2) 'Second Party' doesn't really exist. Ninja Theory is an independent developer who started work on HS and Sony paid them to develop it for PS3 exclusively. I don't know if the contract was extended to further games or not. Verification that XB360 can handle nAo32 comes from looking at the released specs. If you can run SM2+ shaders, you can use nA032, which Xenos can.

I am pretty sure nAo lobbied for the idea that even 360 devs could benefit from NAO32.
 
Encoding to a different color space can be done in many ways, NAO32 was a first implementation and I tried to make it as good as Fp16, but the vast majority of games can use simpler implementations that use less cycles.
 
IIRC nao32 (aka funky colorspace) doesn't work well on 360?

It's not that it "doesn't work well", the issue is "do you need it when your target GPU already supports MSAA and blending for a 32-bit floating-point format?".
 
As I understand, having two render targets means that Halo3 has the following options:

- Keep both buffers in EDRAM, render in single pass. Both buffers have to fit into 10MB and rendering doesn't have to use the main bandwith at all. They can even combine the two buffers together and stay in the EDRAM.

- Keep a single buffer in EDRAM, render in two passes. Once the first pass is finished, it has to be copied into the external memory, and combining the two buffers will require external bandwith as well, same goes for post process motion blur. Framerate is basically cut in half because they have to render the scene two times.

- I'm not sure if this can work: keep a single buffer in the EDRAM, a single buffer in external RAM, and render in a single pass. Ass the ROPs are on the daughter die, I don't know if they can do this. Anyway, this would require a very large amount of external bandwith, causing a very large drop in frame rate.

- Keep both buffers in EDRAM as in the first case, but revert to tiling. I also think that they can't do any post effects or even combining the two buffers until the rendering is finished, so this would also require some additional external bandwith, and extra memory to accomodate the two buffers. Then there's the overhead of re-submiting the geometry.

I believe that Bungie has a working implementation of the last method for the engine, but for some reason - pixel shader performance, bandwith, geometry, whatever - it wasn't stable enough, and they've decided to go for a better frame rate.

Now I'm not a programmer and I'm not that proficient in the inner workings of the x360, so any developer comments are more then welcome.

I also wonder how many PS3 users would have preferred Heavenly Sword to render at 640p with a more stable framerate. This is no flamebait or an attack against the devs, I highly respect their work and consider the game's graphics to be one of the best of this generation so far. But I've heard a lot of people moan about the game, and especially because of the 4xAA, it would be a far better candidate for scaling. Although I think the PS3 hardware scaler couldn't help there... right?
 
It's not that it "doesn't work well", the issue is "do you need it when your target GPU already supports MSAA and blending for a 32-bit floating-point format?".
Xenos doesn't support 32 bit floating point blending
 
I also wonder how many PS3 users would have preferred Heavenly Sword to render at 640p with a more stable framerate.

Not I. The frame rate was fine for the game play, only the cutscenes stuttered sometimes. Some reviewers reviewed non-final copies, I think Gamespy even re-reviewed it and raised the score since the frame rate was improved.

Heavenly sword is the best looking title out ATM IMO. I wouldn't change a thing with the graphics.
 
I also wonder how many PS3 users would have preferred Heavenly Sword to render at 640p with a more stable framerate.
Probably many users would have liked such a trade off, even though I doubt it would have made the game run that much faster.
 
Not I. The frame rate was fine for the game play, only the cutscenes stuttered sometimes. Some reviewers reviewed non-final copies, I think Gamespy even re-reviewed it and raised the score since the frame rate was improved.

I'm talking about local guys here; practically every single one of them, no matter how big a Sony fan, has complained about the frame rate.
 
I'm talking about local guys here; practically every single one of them, no matter how big a Sony fan, has complained about the frame rate.

If you say so. Did you also play the game, or are you just cherry picking other's opinions and generalizing? I finished the game and in no way did the frame rate interfere with the game play.
 
As I understand, having two render targets means that Halo3 has the following options:
The question is, why use this method for HDR? What's wrong with FP10 or FP16? The choice to fit two separate renders at the same time seems a strange compromise. Also why not use tiling to render both buffers with AA in pieces? Also couldn't MEMEXPORT directly export an HDR component to a separate buffer?
 
Folks,
Topic: Halo & HDR

Allowed: the specific implementation in Halo or different possible implementations

Rest = no-no
 
If you say so. Did you also play the game, or are you just cherry picking other's opinions and generalizing? I finished the game and in no way did the frame rate interfere with the game play.

Again: it was a completely shared opinion, not picking anything here. And I've been talking about these opinions, not yours.
 
The question is, why use this method for HDR? What's wrong with FP10 or FP16? The choice to fit two separate renders at the same time seems a strange compromise. Also why not use tiling to render both buffers with AA in pieces? Also couldn't MEMEXPORT directly export an HDR component to a separate buffer?

The problems with tiling and why many devs avoid using it have been well documented. Simply put, it's slower. And Bungie want to keep 30fps with all of the other stuff they are doing!

As for why there are two separate buffers.. it's to do with their Linear Lighting model, and is explained in the slides, though I don't understand much of it myself.

What would be good is for someone who did to explain the advantages of that model compared to HDR modes that have been mode commonly used.

Also, nAo suggested earlier that they don't necessarily need two buffers for this method. I'd like to hear more about that too.
 
The question is, why use this method for HDR? What's wrong with FP10 or FP16? The choice to fit two separate renders at the same time seems a strange compromise. Also why not use tiling to render both buffers with AA in pieces? Also couldn't MEMEXPORT directly export an HDR component to a separate buffer?

Read the slides again they explain their choice : FP16 is great but Xenos can't use it with blending enabled, on the other hand FP10 didn't have the 5 stop exposure range they wanted without color banding. MEMEXPORT can't be used for this kind of situation you would need to render a full frame directly to memory, it would take the whole bandwidth away from the CPU. MEMEXPORT is good for exporting vertex work in memory not pixel stuff I think.
 
Status
Not open for further replies.
Back
Top