RSX aren't capable of HDR+FSAA?

[PSman]

Sorry if this is a dumb question but, this kinda bug me for a while now, hopefully some one here can help me clear this up

I've been hearing about how RSX can't do HDR+FSAA, so does this mean that PS3 games will lack AA and will have more jaggies?. Will this be a big disadvanatge for the RSX?

Thanks

 

[Mmmkay]

Every damn week, I swear.

 

[London Geezer]

Sorry if this is a dumb question but, this kinda bug me for a while now, hopefully some one here can help me clear this up

I've been hearing about how RSX can't do HDR+FSAA, so does this mean that PS3 games will lack AA and will have more jaggies?. Will this be a big disadvanatge for the RSX?

Thanks

Yeah it's a dumb question, not because it's dumb in itself, but because we've been through it a trillion times...

RSX can do both HDR and AA at the same time, as you'll see. Just not FP16HDR, other kinds of HDR that are pretty much as effective as what's considered "real" HDR.

 

[Shifty Geezer]

HDR comes in different flavours than just floating point buffers. RSX apparently (unconfirmed but likely given G70 and G71 specs) can't handle FP16 and MSAA. It can handle supersampling, which is very expensive and unlikely to be used. It can also manage HDR through non-FP buffers. Heavenly Sword is using a custom HDR format using a non-standard (not RGB) colourspace, and we are told by the guys developing this that at the moment HS is running at '720p with a nice amount of AA'. So it is possible.

 

[expletive]

I thought these HDR+FSAA implementations utuilized the Cell though?

 

[London Geezer]

I thought these HDR+FSAA implementations utuilized the Cell though?

Nope...

 

[Shifty Geezer]

NAO32 uses pixel shader instruction to do the conversion to and from different colour spaces. Of course there's more than one way to skin a cat, and no doubt someone could come up with a Cell utilizing method instead. Fafalada seemed keen on that notion!

 

[expletive]

NAO32 uses pixel shader instruction to do the conversion to and from different colour spaces. Of course there's more than one way to skin a cat, and no doubt someone could come up with a Cell utilizing method instead. Fafalada seemed keen on that notion!

Gotcha, so in the case of HS theyre trading Shader ops for AA? If so, its interesting that they can afford to throw those things to AA instead of 'graphics'.

 

[Titanio]

The cost is very small, AFAIK. The bandwidth savings might also buy them more in terms of texture/vertex fetch, which would be more related to graphical richness vs image quality. The trade would seem worthwhile if FP16 dynamic range is largely preserved, as claimed, and they can manage their transparencies cleverly.

 

[PSman]

Yeah it's a dumb question, not because it's dumb in itself, but because we've been through it a trillion times...

RSX can do both HDR and AA at the same time, as you'll see. Just not FP16HDR, other kinds of HDR that are pretty much as effective as what's considered "real" HDR.

I apologize, I'm pretty new here and I forgot to search through the topic.

The main reason why i created this topic is because looking at this got me worry

http://www.bjorn3d.com/Material/ReviewImages/X1000/fc_noHDR.jpg

http://www.bjorn3d.com/Material/ReviewImages/X1000/fc_HDR.jpg

 

[Shifty Geezer]

Gotcha, so in the case of HS theyre trading Shader ops for AA? If so, its interesting that they can afford to throw those things to AA instead of 'graphics'.

Yes. It trades shader ops for bandwidth, halving bandwidth demands for a reasonably small demand for the conversion. This HDR format (YUV based) also doesn't work with standard alpha blending, so there's swapping back and forth between colour spaces as needed. I recommend you search out the thred and read about the pros and cons. Try searching for NAO32 and DeanoC as the author.

 

[scooby_dooby]

Gotcha, so in the case of HS theyre trading Shader ops for AA? If so, its interesting that they can afford to throw those things to AA instead of 'graphics'.

I think Deano said something about how by using NAO32 they save enough bandwidth to implement AA. So by using that method it gets by the technical limitation of no HDR+AA on the GPU, and also frees up enough framebuffer bandwidth to actually be able to implement AA. Great example of developing to a systems strengths, though it does show devs are already hitting a wall w/ the 128bit bus.

 

[Titanio]

Great example of developing to a systems strengths, though it does show devs are already hitting a wall w/ the 128bit bus.

I'm sure many are saturating bandwidth, I'd expect that to happen, but given that AA was not possible for more fundamental reasons that bandwidth - because they were using a FP16 framebuffer - you can't really say they took their new approach because of bandwidth. They said before that it was working fine with the FP16 buffer, but obviously you couldn't get any AA.

 

[Shifty Geezer]

I think Deano said something about how by using NAO32 they save enough bandwidth to implement AA. So by using that method it gets by the technical limitation of no HDR+AA on the GPU, and also frees up enough framebuffer bandwidth to actually be able to implement AA. Great example of developing to a systems strengths, though it does show devs are already hitting a wall w/ the 128bit bus.

That's not an accurate assessment. The actual discussion said a fair bit on the improved quality over FP16 framebuffers in most situations, the fact that this method can be used on all and any SM3.0 (SM2.0 even, probably) achitectures with the same benefit of considerable BW savings, not just RSX, and that it was a better solution than truncated FP formats like Xenos's FP10. To me, it was more about finding a different solution to the existing HDR methods for several reasons. RGB isn't a good model for HDR, as I've said often on this board when viewing HDR screens. The limitations of RSX in the BW department may well have helped encourage them to look for a solution. Dunno. Marco would have to comment on why he was experimenting in that department. Maybe he was trying to save BW, and maybe he was just looking for a YUV implementation and the BW saving was a nice extra? But the benefits and costs of these forms of conversions are applicable to 3D realtime rendering in general and are not at all platform specific. They definitely recommended XB360 using NAO32 over FP10, for example.

 

[scooby_dooby]

That's not an accurate assessment. The actual discussion said a fair bit on the improved quality over FP16 framebuffers in most situations, .

I don't remember anything about it being improved quality over FP16, simply as good, and we're taking them at their word on that, we'll have to see what the final game really looks like.

They definitely recommended XB360 using NAO32 over FP10, for example.

Except NAO32 is not going to work for all games, it's simply a good solution for HS's specific lighting requirements. For example, the KZ devs stated it simply would not work for them, so it obviously has limitations.

 

[Shifty Geezer]

I don't remember anything about it being improved quality over FP16, simply as good, and we're taking them at their word on that, we'll have to see what the final game really looks like.

As nAo said

Quality/precision is not affected at all, in fact I discovered several cases where FP16 falls short of precision while the color space we're using is doing a much better work.
Nonetheless there are other trade offs, hardly ever in this world you have win-win situations :smile:

As for only having their word for it, first why would they be untrustworthy? Unless you think nAo is egotistical and wants to think everything he does is better than alternatives, surely it's fair to take these developers comments on their observations as valid for their product. If nAo saw problems with the HS engine using FP16 that weren't there with NAO32, I think it safe to say he wasn't hallucinating And secondly, when you consider what HDR is trying to achieve, RGB makes no sense. A YUV colourspace is going to produce better illumination results with less saturation problems. As Deano described it...

But RGB space is shit for lighting calculations, its simple the wrong place. Why? Originally RGB colour space was defined on the range [0,1] for each channel. With a 1 being the most strongest pure colour *POSSIBLE* in that channel. So RGB<0,1,0> is the most purest green possible. RGB was designed (long long time ago) as an absolute colour space. But even a trivial look tells you as you move to simple HDR (allow values above 1) its a vast waste of space. What exactly does the colour RGB<0,1000,0> mean? Something that 1000x purest green?

The reason is because you haven't sepereated hue (colour) from lumonsity. When we talk about HDR we not talking about more colour range but more lumonsity. So we change the colour space to one where lumonsity can go very high but the colour range just keeps the same range as before.

Except NAO32 is not going to work for all games, it's simply a good solution for HS's specific lighting requirements. For example, the KZ devs stated it simply would not work for them, so it obviously has limitations.

Of course it's not a cure-all. Alpha heavy graphics (particles) can't operate in this colourspace and RGB is needed for blending. But you can swap between formats, rendering in NAO32 for the opaque stuff and FP16 for the particles. The actual recommendation of NAO32 over FP10 was from Deano...

Its clever software beating hardware, you'd probably want to use this on PC, X360 (its much better then FP10), PS3, Rev etc. Its simple a better HDR method... Its beats FP16 HDR in almost all cases, so as I've said why wouldn't you use it?

Ironincally for the X360 ******s its even more relevant on X360... X360 sucks at FP16 HDR, particular because of the tiling (64 bit framebuffers use twice as many tiles). Swap to our colour space and the X360 gets FP16 HDR quality without the lose in speed it suffers from if you use real FP16 HDR.

It's not worth having another NAO32 versus FP16 debate, as that's been had. But you might want to revisit the original thread to see what exactly Deano and nAo had to say which covers the limitations of the format too. This subject starts on this page...
http://www.beyond3d.com/forum/showthread.php?t=26484&page=5

There's a little more here...
http://www.beyond3d.com/forum/showthread.php?t=26960

Personally I'm pleased as punch someone's using a YUV/HSV type colour space, because saturation errors in HDR rendering really bugs me! I'd love to see hardware support in GPUs for HSV/HSL buffers too.

 

[Brimstone]

Sorry if this is a dumb question but, this kinda bug me for a while now, hopefully some one here can help me clear this up

I've been hearing about how RSX can't do HDR+FSAA, so does this mean that PS3 games will lack AA and will have more jaggies?.
Thanks

From a real-world practicle level HDR+FSAA seems a serious challenge for the RSX. A recent example would be Oblivion for the PC and 360. On the 360 you get both HDR+AA, while on the PC you have to choose. Another example would be Ghost Recon: Advanced Warfighter which might run into the issue on the PS3. I don't think the NAO32 approach would work with GRAW, but I'm sure I'll be corrected if this isn't the case.

Microsoft and ATI built a custom GPU for not only for the High Definition era, but also to usher in the HDR era.

 

[Titanio]

From a real-world practicle level HDR+FSAA seems a serious challenge for the RSX. A recent example would be Oblivion for the PC and 360. On the 360 you get both HDR+AA, while on the PC you have to choose. Another example would be Ghost Recon: Advanced Warfighter which might run into the issue on the PS3. I don't think the NAO32 approach would work with GRAW, but I'm sure I'll be corrected if this isn't the case.

What does options available in PC software have to do with RSX? The incentive may not be there to implement a solution for a select few nVidia cards in the PC space, but in a closed box, you can tune your approach to one set of hardware you know everybody has.

It's worth remembering that while RSX cannot support FP16 HDR with MSAA, neither can Xenos. It simply has a hardware-supported buffer format with its own tradeoffs, no less significant IMO, than any of the tradeoffs attached to shader-based solutions in RSX. Indeed, purely in terms of HDR, dynamic range, with something like NAO32 there is no tradeoff, in fact perhaps only improvement over FP16 (which itself offers more range than FP10). And still, even if a dev did use a FP16 buffer without AA on RSX, if you're just talking about HDR, that's still more dynamic range! There's no question about the HDR capability either way, just how you achieve AA.

 

[nAo]

As already stated many time on these boards HDR rendering can be done in many different ways.
Most games use FP16 render targets: this is the most straightforward and simple way to do it, quality is also very good, though unfortunately FP16 render targets require a lot of memory and bandwidth: every pixel needs 8 bytes in video ram to store its color data.
On the other hand colors can be represented (different color spaces) and encoded (different layout in memory) in many different ways.
We use a 4 bytes per pixel format that has the same luminance range of a default FP16 format, though it's completely scalable changing some costants in a fragment shader.
The quality is outstanding, I was never been able to reproduce a single case where FP16 had a better quality than our funky color space.
I silently ran the game over a week using FP16 on the upper half of the screen and funky colors on the lower half..and I was randomly asking question about the image quality to people in the office that were occassionaly standing close to my desk: no one has ever noticed any difference.
It's also very easy to bring FP16 on its knee on night light scenes, very low luminance (close to zero!) produced noticeable banding (but this effect can also be a function of a particular tone mapping operator), the 4 bytes per pixel version was much better, banding was still present though.
Also we don't use YUV or HSV color spaces, we went for a custom CIE Luv space.

Except NAO32 is not going to work for all games, it's simply a good solution for HS's specific lighting requirements. For example, the KZ devs stated it simply would not work for them, so it obviously has limitations.

AFAIK KZ renderer is fairly different from HS renderer and makes perfctly sense for them to not use our color space, but it's not an issue related to lighting requirements, in fact we support a VERY broad (and accurate!) range , thousand times broader than FP10 on Xenos.

 

[nAo]

It's worth remembering that while RSX cannot support FP16 HDR with MSAA, neither can Xenos.

I can comment on Xenos since I haven't signed any NDA with Microsoft: Xenos supports FP16 HDR with MSAA, but it can't automatically resolve the frame buffer whilst dumping it out to the external memory.
One needs to download that tile into main ram and to resolve it using a pixel shader.

with something like NAO32 there is no tradeoff, in fact perhaps only improvement over FP16 (which itself offers more range than FP10).

Unfortunately this is not true, the most noticeable tread off we made is trading ALU ops for memory storage and bandwidth.