HDR + FSAA confirmed on R520?

Apple740

Gawd
Joined
Oct 21, 2004
Messages
641
Interesting quote from Richard Huddy's latest interview:

"Interesting I've seen David Kirk from NVIDIA saying that in his view some of our new features are years away, so I guess the new hardware could make a bit of a stir. Our focus is always on usable features which run at full speed, so I'm looking forward to the fact that our new hardware will change the games development landscape for the better in ways that games developers will welcome. Indeed the one word which games developers commonly tend to use when we discuss the new hardware with them is simply "Cool!"

The single thing which will make games look better in the next generation is full on HDR. HDR stands for "High Dynamic Range" and what it really means in our context is rendering 3D images using data which is very like that found in the natural world. "HDR" has become the buzzword in the games industry because a few games developers have started to show demos which use HDR and the difference is simply stunning. But the trouble right now is that all the HDR implementations in the market to date are limited in one way or another which makes the decision to use HDR a somewhat painful compromise. We plan to eliminate the compromise and thereby do way with the pain."


Here's what David Kirk from Nvidia said about HDR + AA:
http://www.bit-tech.net/bits/2005/07/11/nvidia_rsx_interview/3.html

edit: sorry, bottom link fixed.
 
Or perhaps he means just getting performance thats not so slow with HDR. As it is now, HDR takes a huge hit, adding AA on top of that, would create some seriously low frames. While it would be cool to have AA and HDR, as thats one of my two main gripes about HDR, is that you cant use AA with it. Having to lower the res to get playable frames, and then not being able to use AA just isnt worth it to me, currently.

Here is hoping that its possible, and they are going to do it. But I wont hold my breath, or expect it.
 
fallguy said:
Or perhaps he means just getting performance thats not so slow with HDR.

What else could Huddy mean with his statement "I've seen David Kirk from NVIDIA saying that in his view some of our new features are years away, so I guess the new hardware could make a bit of a stir."

HDR itself is not "years away", but Kirk said that HDR + AA is (well, he said "not in the immediate future"):
"Maybe at some point, that process (HDR + AA) will be accelerated in hardware, but that's not in the immediate future."
 
fallguy said:
Or perhaps he means just getting performance thats not so slow with HDR. As it is now, HDR takes a huge hit, adding AA on top of that, would create some seriously low frames. While it would be cool to have AA and HDR, as thats one of my two main gripes about HDR, is that you cant use AA with it. Having to lower the res to get playable frames, and then not being able to use AA just isnt worth it to me, currently.

Here is hoping that its possible, and they are going to do it. But I wont hold my breath, or expect it.

The problem with current videocards is that they don't support multisampling on floating point rendertargets.
HDR itself doesn't take a very big hit, but the only way to do antialiasing is supersampling, and that's VERY expensive, so generally games settle for no AA at all with HDR enabled.
 
Apple740 said:
What else could Huddy mean with his statement "I've seen David Kirk from NVIDIA saying that in his view some of our new features are years away, so I guess the new hardware could make a bit of a stir."

HDR itself is not "years away", but Kirk said that HDR + AA is (well, he said "not in the immediate future"):
"Maybe at some point, that process (HDR + AA) will be accelerated in hardware, but that's not in the immediate future."

I dont like to put words in other peoples mouths. The fact is, he didnt say HDR+AA, so I am not going to go head in believing thats what he ment. Could he have ment that? Sure. We dont know for sure though, as he wasnt exact enough with his comments.

Scali said:
The problem with current videocards is that they don't support multisampling on floating point rendertargets.
HDR itself doesn't take a very big hit, but the only way to do antialiasing is supersampling, and that's VERY expensive, so generally games settle for no AA at all with HDR enabled.

I know what the problem is. I disagree that HDR iteself doesnt take a big hit, it makes Farcry unplayable for me. Takes close to a 50% hit on frames. Adding AA on top of that would be even more of a hit. But I guess we'll have to wait for an actual card, and performance numbers to see how much. If this is all true that is.
 
fallguy said:
I know what the problem is. I disagree that HDR iteself doesnt take a big hit, it makes Farcry unplayable for me. Takes close to a 50% hit on frames.

Oh I dunno about actual framerates, but I play it on an overclocked 6800LE in 1024x768, and I didn't notice any slowness when turning it on.
I know that my own HDR code doesn't take a big performance hit at all, so I assumed it'd be the same in FarCry.
At any rate it's safe to assume that HDR takes less of a performance hit than supersampled AA, because using 4xSSAA will quadruple the fillrate requirements.
 
Didnt notice any framerate loss when you enabled HDR in Farcry, with a 6800LE? Heh.

I wouldnt assume that, it takes a HUGE hit in Farcry. As I said, about 50%. FS shows a 6800GT at 83fps at 1024x768 4xAA/8xAF. Then shows the same card at 40fps, at 1024x768 with no AA or AF. It took more than half the frames, when disabling AA/AF, and enabling HDR. Not a trade off I would like.

But to get back on topic.. I dont know if he ment HDR+AA or not. I hope he did, and they can implement that, but Im not going to get too excited about it. Until we have some facts and numbers. My main gripe with HDR as it is now, is that you take such a huge hit in frames, that you have to lower the res. Then you cant enable AA to clean up the game.

I use TA SSAA when I can, I dont think it takes a 50% most of the time. I may be wrong, I havent checked any numbers. I use it in BF2 though, and its still very playable.
 
Somehow I seriously doubt ATi will come out with full OpenEXR HDR with multi-sampling at super high speeds...

I think that it's much more likely that they will introduce a new way of simulating HDR which looks about as good an nVidia's implementation but runs much faster...
 
im expecting an sm2.0b effect myself. I think they devised a way to allow the both to run acceptably, but in how they did it, i think it may require special treatment from game developers. MSAA technically is the lowest hitting performance wise and also one of the least impressive, but its certainly better then none, it would be fantastic if they got it to work without requiring special treatment. SSAA i believe works with HDR but destroys frame rates into single digits and teens.

The actual best guess however, again back to the SM2.0b type thing, is that ATI will be supporting FP10 as well as 16, 24 and 32. FP10 may cause a total image quality loss but it may also allow enough leverage to enable HDR and nice AA, (FSAA) with it at a playable rate.

I have to agree with kirk though that in the distant future, games will simply run their own AA in engine, it really makes no sense to keep forcing different levels of AA through hardware.
 
I don't see why they can't have MSAA on float targets.
If you can do texture filtering and alphablending with floats, MSAA is not that much more difficult.
I don't think ATi will go for FP10. First of all it would be useless quality-wise (think about it... how many bits for mantissa, and how many for exponent? 6.4? That'd already be absolutely horrible, even FP16 is cramped). Secondly, it's not ATi's style to have a complex pipeline supporting multiple formats. I expect them to just have a single FP32 pipeline, which is streamlined and high-performance, just like the FP24 pipes they have now.
Also, HDR doesn't have anything to do with SM2.0 or SM3.0, but solely with the ability to have float targets with alphablending. That will be no faster on SM2.0 than it is on SM3.0.
 
SatinSpiral said:
that would be a sweet deal if they would only offer an agp part ;)
too bad they aren't. At least at first.

-----------------

And the thing isn't that AA + HDR takes too much of a hit, it just can't be technologically done right now. It will be good if they can do it.
 
I've read the article and the impression I'm left with isn't that they've developed some new technique beyond what nVIDIA currently has, but that they've successfully met parity in features.

nVIDIA was basically pointing out that the ATI pipeline was optimized in a 24bit path rather than 32 like nVIDIA's and that ATI may have trouble developing for this. After all nVIDIA was pointing out that it took the FX series first before they got it right in the GeForce 6 series and expected ATI to have similar growing pains.

I suspect that ATI has pulled it off and has a good performance SM 3.0 and FP16 and FP32 modes that are fully up to par with nVIDIA's current gen. This way HDR can be implemented in the full SM 3.0 manner, rather than several of the alternative methods that would have to have been employed to get some HDR effects to work on older R420 and R480 cores. So the choice in the past was, support a borked HDR model that worked on both ATI and nVIDIA products or to only enable it for nVIDIA users. Now that discision has been removed and the "future implementation" of those ATI technologies has been successful in implementation.

So now the results will be:

ATI SM 3.0 per ~= nVIDIA SM 3.0 per on G70 series
ATI FP32 modes ~= nVIDIA FP32 performance

The stir in the market will be that the performance is comparible and only accomplished with 16 pipelines versus nVIDIA's 24. Indicating that ATI may have the more "efficient" core in comparison even if it doesn't defeat the 7800GTX in raw performance. Future editions with even more pipelines will also be quite interesting (although additional pipeline editions from nVIDIA are likely in the works).
 
^eMpTy^ said:
Somehow I seriously doubt ATi will come out with full OpenEXR HDR with multi-sampling at super high speeds...

I think that it's much more likely that they will introduce a new way of simulating HDR which looks about as good an nVidia's implementation but runs much faster...
It would be interesting if ATIs new chip could do both simultaneously. If they came up with some kind of new way though, it would almost have to be ATI proprietary instead of OpenEXR HDR.
 
OpenEXR is a fileformat by the way, by ILM, not a rendering algorithm: http://www.openexr.com/
Even a Radeon 9500 can use OpenEXR textures.
Don't know why everyone talks about OpenEXR as if it is the HDR rendering algo itself. Quite a strong misconception too, I've seen it being used for months like this, everywhere on the net.
 
Scali said:
OpenEXR is a fileformat by the way, by ILM, not a rendering algorithm: http://www.openexr.com/
Even a Radeon 9500 can use OpenEXR textures.
Don't know why everyone talks about OpenEXR as if it is the HDR rendering algo itself. Quite a strong misconception too, I've seen it being used for months like this, everywhere on the net.
You're right. But doesn't the gpu need to be FP16 capable on the hardware level to use the OpenEXR file format correctly?
 
DejaWiz said:
You're right. But doesn't the gpu need to be FP16 capable on the hardware level to use the OpenEXR file format correctly?

FP16 or higher. Even a Radeon 9500 does.
They support FP16 and FP32 textures, and have FP24 shaders.
 
Scali said:
FP16 or higher. Even a Radeon 9500 does.
They support FP16 and FP32 textures, and have FP24 shaders.
Cool. Thanks for the info. I was curious to know.

Couple other things. IIRC, ATI cards do not support FP16 blending, which is required for OpenEXR, correct? Doesn't OpenEXR also require SM3.0 capability to be rendered correctly (even though they are separate technologies)?
 
DejaWiz said:
Cool. Thanks for the info. I was curious to know.

Couple other things. IIRC, ATI cards do not support FP16 blending, which is required for OpenEXR, correct? Doesn't OpenEXR also require SM3.0 capability to be rendered correctly (even though they are separate technologies)?


Right about the fp16 blending but OpenEXR format doesn't require sm 3.0. sm 3.0 helps out a bit with speed by cutting down a pass.
 
DejaWiz said:
Cool. Thanks for the info. I was curious to know.

Couple other things. IIRC, ATI cards do not support FP16 blending, which is required for OpenEXR, correct? Doesn't OpenEXR also require SM3.0 capability to be rendered correctly (even though they are separate technologies)?

As I already said, OpenEXR is a fileformat, not a rendering algo.
A Radeon can support the OpenEXR textureformat. How you use those textures depends on the algo.
You can do HDR in many ways. The one that FarCry happens to use, requires FP16 blending, which no Radeon supports yet. Technically FP16 blending has nothing to do with shader models at all (alphablending is done after shading, not during shading), but SM3.0 hardware supports FP16 blending. Just like it supports geometry instancing, which has nothing to do with shading either.
The Half-Life2 addon has a HDR algo that also works on Radeons.
 
Scali said:
As I already said, OpenEXR is a fileformat, not a rendering algo.
A Radeon can support the OpenEXR textureformat. How you use those textures depends on the algo.
You can do HDR in many ways. The one that FarCry happens to use, requires FP16 blending, which no Radeon supports yet. Technically FP16 blending has nothing to do with shader models at all (alphablending is done after shading, not during shading), but SM3.0 hardware supports FP16 blending. Just like it supports geometry instancing, which has nothing to do with shading either.
The Half-Life2 addon has a HDR algo that also works on Radeons.
So the ATI cards (past and future) fully support HDR rendering, because OpenEXR supports 16-bit unsigned integer (and all the way up to 32-bit floating point data types). Since OpenEXR is free and open source, developers can even develop their own compression methods in order to get the performance they might need out of their software on a given hardware platform.
 
DejaWiz said:
So the ATI cards (past and future) fully support HDR rendering, because OpenEXR supports 16-bit unsigned integer (and all the way up to 32-bit floating point data types). Since OpenEXR is free and open source, developers can even develop their own compression methods in order to get the performance they might need out of their software on a given hardware platform.

OpenEXR is just a fileformat, and in itself has little to do with HDR rendering. It's a way to store images with high dynamic range. So if your HDR rendering method happens to use image-based lighting, you could use OpenEXR to store the textures. You could also use various other formats. Or you can use HDR rendering without image-based lighting at all. The whole OpenEXR thing really doesn't mean anything, but the NVIDIA marketing guys did their job admirably once again.
 
What I'm guessing is that openEXR is like a PFM file format. It's just an image that HDR uses to extract low and high points in teh surrounding area of an object, and applies those highlights and (lowlights?) to the models in the game.

Here is an image of an extraction of highs and lows from the surrounding map, which is a PFM file:
hdr.jpg

Note that this pre-rendering doesnt actually impose the highlights onto the model. That doesn't happen until it's actually rendered. The 'cones' (for lack of a better word) indicate the type of highlight that will be inposed on teh model once its rendered.
/edit
Heres what the .pfm file looks like flattened out. It's just an image, which a program can use to extract dynamic lighting information from.
pfm.jpg

It's teh same image that is stretched across the background in the first picture. It is not required for it to be seen in teh image to extract the dynamic information from, however.
I could be way off on this, let me know if I am.
 
No, OpenEXR is an image format, sorta like PNG, GIF, JPG etc, only with floating point support. It doesn't say anything about what kind of image you store in it, or how you should generate it, or how to use it during rendering. It's just a texture.
 
Yes, the PFM is, I believe, the same thing.
It's that little oval bit down there at the bottom. Nothing more than an image in a certain file format that other software can use to extract dynamic info.
Maybe I wasn't clear on that...
 
Your PFM file is a spherical lightprobe. OpenEXR can store those, but it can store any other image aswell. As I said before, it doesn't say anything about what kind of image, or how to generate or use it.
 
Alright.
So are certain images stored in the openEXR files used for HDR generation in games?
 
Yes, with FarCry, eg the skybox is a lightprobe much like yours (although I believe they use cubemaps, not spheremaps), and it is being used for environment-mapped light effects. The result is a framebuffer with a high dynamic range (not saturated like normal rendering), which is then fed through a post-processing filter, which handles exposure, saturation and bloom effects. Et voila, we have HDR rendering.
 
^eMpTy^ said:
I think that it's much more likely that they will introduce a new way of simulating HDR which looks about as good an nVidia's implementation but runs much faster...
That would be awesome.

DejaWiz said:
<snip> ...it would almost have to be ATI proprietary instead of OpenEXR HDR.
That would suck.
 
Scali said:
Yes, with FarCry, eg the skybox is a lightprobe much like yours (although I believe they use cubemaps, not spheremaps), and it is being used for environment-mapped light effects. The result is a framebuffer with a high dynamic range (not saturated like normal rendering), which is then fed through a post-processing filter, which handles exposure, saturation and bloom effects. Et voila, we have HDR rendering.
That's what I was getting at
;)
 
Scali said:
Yes, but people mistakenly call that OpenEXR HDR. That's what I was getting at.
Right. It's no more HDR than a .pfm file is.
I think you've made it clear. If people still don't get it, then, well, that's on them.
 
eno-on said:
Right. It's no more HDR than a .pfm file is.
I think you've made it clear. If people still don't get it, then, well, that's on them.

I think the general reaction to HDR from a non-technical standpoint is: 'OMG the light in this room is changing while I'm standing still, HAX !!!1111'
 
Scali said:
OpenEXR is just a fileformat, and in itself has little to do with HDR rendering. It's a way to store images with high dynamic range. So if your HDR rendering method happens to use image-based lighting, you could use OpenEXR to store the textures. You could also use various other formats. Or you can use HDR rendering without image-based lighting at all. The whole OpenEXR thing really doesn't mean anything, but the NVIDIA marketing guys did their job admirably once again.
I understand it's a file format and has nothing to do with the rendering itself.

I guess what I'm getting at is: Why haven't there been games that support FP16, 24, or 32 HDR in the past, when the FX and 9000 series gpu's were mainstream (since both are capable of at least FP16 HDR)? Is it because SM3.0 is a more efficient code path than SM1.1/2.0 and allows for a boost in PS/VS performance when HDR is used, so as to not present the user with a (random example: ) 10fps Far Cry experience?
 
DejaWiz said:
Why haven't there been games that support FP16, 24, or 32 HDR in the past, when the FX and 9000 series gpu's were mainstream (since both are capable of at least FP16 HDR)? Is it because SM3.0 is a more efficient code path than SM1.1/2.0 and allows for a boost in PS/VS performance when HDR is used, so as to not present the user with a (random example: ) 10fps Far Cry experience?

Because the FX and 9000 series didn't have floating point texture filtering, which would give rather blocky results... And there was no fp alphablending either, which meant that you'd either have to render opaque surfaces only, or use a slow multipass hack to render translucent stuff.
So basically the hardware wasn't mature enough.
 
Scali said:
Because the FX and 9000 series didn't have floating point texture filtering, which would give rather blocky results... And there was no fp alphablending either, which meant that you'd either have to render opaque surfaces only, or use a slow multipass hack to render translucent stuff.
So basically the hardware wasn't mature enough.
So another question then: Does the ATI X600, the X700, and/or the X8x0 series support FP Texture Filtering and FP Alphablending (and whatever else is needed to quickly render non-blocky, translucent stuff)?
 
DejaWiz said:
So another question then: Does the ATI X600, the X700, and/or the X8x0 series support FP Texture Filtering and FP Alphablending (and whatever else is needed to quickly render non-blocky, translucent stuff)?

No.
 
Scali said:
So, in regards to your previous posts, then it can be said that:

FP16 HDR = needs fp filtering and blending
9000 and FX series = no fp filtering and blending
no fp filtering and blending = hardware is not mature enough
harware is not mature enough = X600, X700, and X8x0 series

:p :p :p

j/k

To get moreso back on topic: Has anyone else heard that the R520 might be able to do HDR + FSAA, but only at FP10 instead of FP16 because of the performance hit?
 
DejaWiz said:
So, in regards to your previous posts, then it can be said that:

FP16 HDR = needs fp filtering and blending
9000 and FX series = no fp filtering and blending
no fp filtering and blending = hardware is not mature enough
harware is not mature enough = X600, X700, and X8x0 series

:p :p :p

j/k

To get moreso back on topic: Has anyone else heard that the R520 might be able to do HDR + FSAA, but only at FP10 instead of FP16 because of the performance hit?
I think someone in this thread or another speculated on that. Someone else said it wasn't likely.
 
Back
Top