HDR on an ATI card? i didn't think that they could....

DFI Daishi

2[H]4U
Joined
Feb 14, 2005
Messages
2,839
hmm.....i thought that only nVidia cards could pull of HDR.

http://www.daionet.gr.jp/~masa/rthdribl/

i'll admit that i have not done ANY researc on this subject, i just saw the link on machall web comic.

the app says that i am seeing HDR effects, and having seen HDR enabled farcry on my friend's overclocked 6800 GT, i can honestly say that what this demo is doing when the camera faces the light looks the same.
 
Brent_Justice said:
ATI DX9 cards can do integer based HDR with a pixel shader.
Which is how Half-Life 2: Lost Coast, Day of Defeat:Source, and Half-Life 2: Aftermath will be doing it.

:p

Nothing like HDR with FSAA :D :D
 
DX9 ATI cards can emulate HDR, however they don't have the specific hardware to do true hardware accelerated HDR. The next generation of ATI cards is supposed to support FP16 hardware accelerated HDR, the same way that the NVIDIA 6xxx & 7xxx series do.

There was a tech demo written years ago using HDR that ran on older cards....
http://www.daionet.gr.jp/~masa/rthdribl/
 
PRIME1 said:
DX9 ATI cards can emulate HDR, however they don't have the specific hardware to do true hardware accelerated HDR. The next generation of ATI cards is supposed to support FP16 hardware accelerated HDR, the same way that the NVIDIA 6xxx & 7xxx series do.

There was a tech demo written years ago using HDR that ran on older cards....
http://www.daionet.gr.jp/~masa/rthdribl/

You are misusing the term "hardware accelerated".

Using pixel shaders rendered by the card is "hardware accelerated".

If it were doing it in software then it wouldn't be hardware accelerated.

ATI DX9 cards using integer based HDR with a pixel shader are very much doing HDR.
 
You've got HDR, and OpenEX HDR. nVidia cards do the latter, ATi's current cards do not. They are totally different implimentations of the same style effect. The latter of course being better.
 
Sir-Fragalot said:
You've got HDR, and OpenEX HDR. nVidia cards do the latter, ATi's current cards do not. They are totally different implimentations of the same style effect. The latter of course being better.

Misuse of terms detected again ;)

OpenEXR is simply a data storage format which can be used for HDR, it is not what makes the HDR on the NV series pretty, what makes it pretty is the support for floating point 16 blending in the framebuffer, which the ATI cards don't have

So you have INT HDR and FP HDR, ATI cards do INT HDR (through pixel shaders) NV cards can do both INT HDR and FP HDR (in the framebuffer)
 
mashie said:
How can it be better if it require anti alias to be disabled (unless that only happened in Far Cry)?

The non support of MSAA is a hardware issue with the current NV cards not allowing it when FP16 framebuffer blending is in use. However, INT HDR used with pixel shaders would allow AA.
 
Brent_Justice said:
You are misusing the term "hardware accelerated".

Using pixel shaders rendered by the card is "hardware accelerated".

If it were doing it in software then it wouldn't be hardware accelerated.

ATI DX9 cards using integer based HDR with a pixel shader are very much doing HDR.

Yes, I should have clarified the differences between using INT HDR & FP HDR.
 
Brent_Justice said:
OpenEXR is simply a data storage format which can be used for HDR, it is not what makes the HDR on the NV series pretty, what makes it pretty is the support for floating point 16 blending in the framebuffer, which the ATI cards don't have

I never had a good grasp of what ATI's proprietary "3dc" data storage format did....could IT store FP16-precision texture data? Or, is it strictly a compression algorithm for regular textures?
 
dderidex said:
I never had a good grasp of what ATI's proprietary "3dc" data storage format did....could IT store FP16-precision texture data? Or, is it strictly a compression algorithm for regular textures?

it's simply a compression algorithm for normals
 
Christ, where is that clue stick?
HDR is not a specific algorithm, let alone that it is a specific feature of hardware.
NVIDIA sure put a spell on all you ignorant people with its flashing of OpenEXR and HDR buzzwords.
I coded bloom-effects on my GF2... ofcourse ATi cards can do it!
 
Sir-Fragalot said:
You've got HDR, and OpenEX HDR. nVidia cards do the latter, ATi's current cards do not. They are totally different implimentations of the same style effect. The latter of course being better.

No you don't. OpenEXR is a file format, and not a method of HDR rendering. You're just being tricked by NVIDIA's spindoctors.
 
PRIME1 said:
DX9 ATI cards can emulate HDR, however they don't have the specific hardware to do true hardware accelerated HDR. The next generation of ATI cards is supposed to support FP16 hardware accelerated HDR, the same way that the NVIDIA 6xxx & 7xxx series do.

There was a tech demo written years ago using HDR that ran on older cards....
http://www.daionet.gr.jp/~masa/rthdribl/

RTHDRIBL only uses opaque objects, hence not requiring alphablending, hence not requiring an FP16 alphablender that only 6xxx and 7xxx series have.
It's still 100% pure FP16 HDR.
 
Scali said:
Christ, where is that clue stick?
HDR is not a specific algorithm, let alone that it is a specific feature of hardware.
NVIDIA sure put a spell on all you ignorant people with its flashing of OpenEXR and HDR buzzwords.
I coded bloom-effects on my GF2... ofcourse ATi cards can do it!
you know, i think that i said in my post that i had not done research on the subject. i found something linked on one of the webcomics that i read, written by a guy who is in software eng (if i remember correctly) that the author said was neat. i tried it, and also thought that it was neat. that's it.

okay, so i have only heard about HDR in conjunction with nVidia's marketing, in conjunction to how great their cards are because they can do it, and how ATI cards are inferior because they can't. i don't spend time here in video cards, learning about the fine points of what they are, and what they can and cannot do.

i research how well the games that i play run on ATI cards vs. nVidia cards, how well they overclock, how to effectively cool them, what their power requirements are and sometimes how hard and/or beneficial volt modding them is. that's it. i don't code graphics, i don't plan to get into that.

i have heard about the ATI vs nVidia pissing contest that is ongoing around here, and as a result, i just avoid posting in this forum. i guess that you must be frustrated by all of the people posting false info, thinking that they are authorities on the subject. fine. fair enough. i'm simply asking you to step back for a second before you post in response to someone who is not constantly posting BS, and answer things in a SLIGHTLY lower-key manner.

if you've coded this stuff, you know more than the guy who saw it being done, and was suprised by it. take that into account, and chill out a bit.
 
Scali said:
RTHDRIBL only uses opaque objects, hence not requiring alphablending, hence not requiring an FP16 alphablender that only 6xxx and 7xxx series have.
It's still 100% pure FP16 HDR.
okay, this may not be QUITE what you are talking about, however there are modes in that demo that have a rotating object with optical properties like glass being rotated around.

are you meaning to say that the demo does't do HDR effects THROUGH the glass, or that it doesn't do HDR while there is a glass object on-screen?
 
DFI Daishi said:
you know, i think that i said in my post that i had not done research on the subject.

It wasn't aimed at you, but at pretty much everyone who responded, since pretty much everyone got things wrong.
And it annoys me, because this is the umpteenth topic about HDR, and the same misinformation keeps popping up, even though I did try to explain before.
 
DFI Daishi said:
okay, this may not be QUITE what you are talking about, however there are modes in that demo that have a rotating object with optical properties like glass being rotated around.

are you meaning to say that the demo does't do HDR effects THROUGH the glass, or that it doesn't do HDR while there is a glass object on-screen?

It does HDR in the same way as always. Just switch the material to glass with the moving balls. You'll see that if a ball moves behind another one, you can't see it through the ball that is in front.
Then again, this is not really a good example, since you would need refraction with this kind of glass effect, so just using alphablending won't help here.
You'd need to render dynamic environment maps and use those for the refraction. Funny enough you don't need alphablending anymore if you do it that way.
But when you have flat glass or other translucent materials, then you can use alphablending, and you'd need at least FP16 blending to get good HDR results. That's something that ATi doesn't support yet, and NVIDIA does.
Ofcourse you could use a method similar to the dynamic envmaps aswell. Not as efficient, but then you can still get the effert on ATi cards.
 
Brent_Justice said:
Misuse of terms detected again ;)

OpenEXR is simply a data storage format which can be used for HDR, it is not what makes the HDR on the NV series pretty, what makes it pretty is the support for floating point 16 blending in the framebuffer, which the ATI cards don't have

So you have INT HDR and FP HDR, ATI cards do INT HDR (through pixel shaders) NV cards can do both INT HDR and FP HDR (in the framebuffer)

Thanks for the information Brent. I stand corrected. :cool:
 
AUUUUGHH SO MUCH MISINFORMATION!!

ATI DX9 cards can do integer based HDR with a pixel shader.

Actually, they don't. ATi cards can store floating point framebuffers (i.e. HDR), and use them on a pixel shader. If you want proof, I'm using a floating point framebuffer for my shadow mapping on a lighting demo that I'm developing - and I'm using an X800 Pro.

Which is how Half-Life 2: Lost Coast, Day of Defeat:Source, and Half-Life 2: Aftermath will be doing it.

Nothing like HDR with FSAA

Again, no. The reason why Valve is able to use AA with HDR is because of a function introduced in the DirectX 9.0c spec called "StretchRect", which, when used properly can allow for AA'd HDR, which Sim Dietrich discusses in this GDC 2004 presentation: http://download.nvidia.com/developer/presentations/GDC_2004/D3DTutorial_Sim.pdf

DX9 ATI cards can emulate HDR, however they don't have the specific hardware to do true hardware accelerated HDR. The next generation of ATI cards is supposed to support FP16 hardware accelerated HDR, the same way that the NVIDIA 6xxx & 7xxx series do.

There was a tech demo written years ago using HDR that ran on older cards....
http://www.daionet.gr.jp/~masa/rthdribl/

Again, ATi's R300 and R400 cards are using real HDR directly on the hardware. The reason why RTHDRIBL works on SM2.0 cards is because more passes are done to calculate the average luminance in the scene (which is used for exposure adjustment and tone mapping). At a consumer level, we've only seen HDR with SM3 cards because the longer shaders allow for fewer passes, but it is entirely possible to do that with SM2, as RTHDRIBL and Valve's HDR technology demonstrate.

ATI DX9 cards using integer based HDR with a pixel shader are very much doing HDR
Just for further emphasis, ATi's cards aren't using integer based HDR, they're using full floating point HDR.

You've got HDR, and OpenEX HDR. nVidia cards do the latter, ATi's current cards do not. They are totally different implimentations of the same style effect. The latter of course being better
OpenEXR is only a standard in computer graphics for balancing the number of bits devoted to the mantissa and the exponent. Go to http://en.wikipedia.org/wiki/Floating_point for more information on floating point formats at the bit level.

So you have INT HDR and FP HDR, ATI cards do INT HDR (through pixel shaders) NV cards can do both INT HDR and FP HDR (in the framebuffer)

Oh ffs, I'm just going to come out and say it. INTEGER BASED HDR DOES NOT EXIST ..as a native hardware feature. If you can find some texture/backbuffer format in this page http://msdn.microsoft.com/library/d...tx/graphics/reference/d3d/enums/d3dformat.asp that is completely integer based and uses more than 8 bits per channel, then I'll be amazed. If I recall correctly, there have been experiments though where HDR has been simulated using an old 8-bit per channel texture, but I highly doubt that any game has used that.

The non support of MSAA is a hardware issue with the current NV cards not allowing it when FP16 framebuffer blending is in use. However, INT HDR used with pixel shaders would allow AA

It's a software issue that has been 'solved' before Far Cry even came out. See the above GDC'04 presentation. Oh, and integer based HDR doesn't exist.

Yes, I should have clarified the differences between using INT HDR & FP HDR.
INT HDR doesn't exist.

I never had a good grasp of what ATI's proprietary "3dc" data storage format did....could IT store FP16-precision texture data? Or, is it strictly a compression algorithm for regular textures?

It is only intended for use with normal maps, but I've never seen anyone experiment with storing other texture formats with 3dc (they'd probably crap out, since 3dc would depend on certain aspects of normal maps, such as normalized vectors at every point).

Forgive me for not looking at the link but I presume he is on about using the 'lesser' INT HDR method, no?

INT HDR doesn't exist.

HDR is not a specific algorithm, let alone that it is a specific feature of hardware.
NVIDIA sure put a spell on all you ignorant people with its flashing of OpenEXR and HDR buzzwords.
I coded bloom-effects on my GF2... ofcourse ATi cards can do it!

This guy isn't wrong, but I think further clarification is required.
HDR implies using a floating point buffer, e.g. the D3DFMT_A16B16G16R16 format from the MSDN article linked above, which has to be supported on the hardware. Bloom, tone mapping, and other benefits of HDR are a software algorithm.
NVIDIA sure did.
And damn, how did you do the bloom on a GF2?!

RTHDRIBL only uses opaque objects, hence not requiring alphablending, hence not requiring an FP16 alphablender that only 6xxx and 7xxx series have.
It's still 100% pure FP16 HDR.
Wha? Some of the materials are translucent. It is fully possible to emulate alpha blending on the PS.

are you meaning to say that the demo does't do HDR effects THROUGH the glass, or that it doesn't do HDR while there is a glass object on-screen?

He was referring to the incapacity of <=R400 and <=NV30 cards not support alpha blending directly to the floating point texture natively on the hardware. As I said earlier, it's possible to simulate alpha blending on the pixel shader.

It wasn't aimed at you, but at pretty much everyone who responded, since pretty much everyone got things wrong.
And it annoys me, because this is the umpteenth topic about HDR, and the same misinformation keeps popping up, even though I did try to explain before.

*high five*

You'll see that if a ball moves behind another one, you can't see it through the ball that is in front.
! I never noticed that before. Well, consider my ass corrected.



*breathes* There, I think that covers everything.
 
Cypher19 said:
And damn, how did you do the bloom on a GF2?!

Oldest trick in the book?
You render to texture, then do some post-processing to emphasize highlights (basically comes down to raising all pixels to a certain power. That way all the stuff that is saturated (or nearly saturated, depending on the function you use) will basically get promoted to an extended range). Then you apply your bloom filter, and blend the resulting image over the original framebuffer.

http://bohemiq.scali.eu.org/forum/viewtopic.php?t=36

Cypher19 said:
Wha? Some of the materials are translucent. It is fully possible to emulate alpha blending on the PS.

Yes, it's possible, as I said myself. But they're not doing it :)

Cypher19 said:
! I never noticed that before. Well, consider my ass corrected.

Told you so ;)
 
Yeah, but how can you do the post-processing on a GF2? The only way I can imagine it is if you pass the texture back to the CPU and perform the bloom THERE.
 
Cypher19 said:
Yeah, but how can you do the post-processing on a GF2? The only way I can imagine it is if you pass the texture back to the CPU and perform the bloom THERE.

Ever heard of render-to-texture? :)
 
Of course, the texture sent back to the CPU that I was referring to is what was rendered TO.
 
Just doing a separable blur filter or even a box filter for bloom is quite easy to do on a GF2. You have multitexturing and bilinear filtering. You just feed the same texture to both stages, and use the texture coordinates to align the pixels so that you can sample two pixels from that texture, and blend them. By using subpixel info, you can use the bilinear filter to blend between pixels horizontally and vertically aswell.
You can get reasonably high quality blur like this in just a few passes.
 
Yea well, these effects are far older than shaders themselves, so obviously people have tried to do them even without shaders :)
Talking about lack of features... the shadowmap in my glowball demo is actually a texture with 8-bit alpha, in which the depth-info is stored, where alphatesting makes for the actual in-shadow comparison.
 
Back
Top