HDR+AA...Possible with the R520?

[Xmas]

Xmas: speaking of which, are there any screenshots examples of FP24 precision banding? When you say "long shaders" what's the instruction count ball-park you're referring to?

100+, I'd say.

Care to explain it so that I also get it?

[-32, 32] is the range from -32 to 32.

 

[_xxx_]

Ok, that wasn't really what I got from that

What's the step/increment size then?

EDIT: nevermind, just saw Thowllly's post

 

[overclocked]

Xmas wrote:

ATI does the same. Besides, I do think FP24 is a limiting factor for long shaders, and especially when you do texture reads dependent on complex math.

Yes and i agree with that
Btw are you saying we are seeing artifacts at 100~instructions with FP24?

 

[{Sniping}Waste]

Dosen't the R300 and up can do HDR and AA with out FP blending? The first set of demos for the R300 has a HDR demo that AA works on.

 

[overclocked]

Thats with shaders i think.

 

[OpenGL guy]

For FP24 (SM2.x) I think the shader length is 512? For SM3.0 .. it's supposed to be unlimited.

Or am I wrong?

You can't have an unlimited number of instructions: Where would you store such a program? The driver reports back the number of instruction slots that are available. Of course, with looping, the number of executed instructions can exceed the amount of storage, just like on CPUs.

 

[Richard]

Xmas: speaking of which, are there any screenshots examples of FP24 precision banding? When you say "long shaders" what's the instruction count ball-park you're referring to?

100+, I'd say.

Hmm... well, doesn't SM 2.0's caps call for 96 max instructions? And doesn't SM 3.0 (with a minimum of 512 instructions) require FP32 precision? If this is correct then generally speaking you'd only see banding on SM 2.0b which allows from 96 to 512 instructions right?

 

[Arun]

Well, you could store it in video memory - or evantually system memory - and then use a technology along the lines of the F-Buffer. Now, if that wouldn't be enough, you could store it on the Hard Drive with prefetching mechanisms, and if that doesn't work, you could save it on OTHER Har Drives through a network system.
For the sake of simplicity though, I completely agree with you that practically unlimited instructions is worthless, and from another pov you could stay it's also stupid because you cannot have infinite shading precision either; but the F-Buffer can still be a big step in the right direction Obviously, 10000+ instruction programs are VERY rare, but for GPGPU usage for example it's nice to support it.

Uttar

 

[Reverend]

Xmas: speaking of which, are there any screenshots examples of FP24 precision banding? When you say "long shaders" what's the instruction count ball-park you're referring to?

Is "banding" the most worrisome issue regarding FP24?

 

[Mintmaster]

But film *print* (what's used to play back your movie) must be able to store the entire range that any of the negatives could have been exposed at, because analog film projectors can't dynamically adjust their iris/lightsource (this info is not recorded by analog cameras on 35mm film for the projector playback to use) So Kodak film-quality *print* film has to be HDR to hold the entire range of what possible negative exposure settings are used. In this case, the projector/human eye is the "tone mapper". The adjustment of the camera aperture/exposure settings is the "scaling" stuff, but note, it takes significant effort to get exposure right! It's difficult to "develop".

That last part is the key, DC. Significant effort? What are you planning to do with your FP16 buffer? You still have to somehow decide what scaling factor you'll use in the tone mapping. In the TV industry, it's the cameraman. With FP10 you have to use the previous frame's data so you can scale into the [-32,32] range, and with FP16 you can do all your rendering beforehand, but that's a moot point. Usually you want a time delay anyway, e.g. rthdribl.

In the case of HDR buffers, the HDR exists not just to prevent saturation, but to preserve local contrast differences. That's why tone mapping algorithms can be so complex, because the challenge is to model how the human eye views local contrast as well as global contrast. See http://www.cs.virginia.edu/~gfx/pubs/tonemapGPU/

The eye is capable of distinguishing a 10,000:1 contrast ratio at any given time because of this very phenomenon, with logarithmic levels. Note that FP10 gives you a ratio of 32 / (1/256) = 8192. That's plenty high for local contrast simulation. Anyway, being able to reach photo-quality real-time graphics would be an admirable achievement, and cameras don't have this local contrast ability. You're talking about better than photorealistic - slow down there! Thanks for the link to the paper by the way.

These tricks to fit the range into a non-true-HDR buffer are not likely to account for all of the aspects of real tone map range compression.

I never said they would. However, they will be very effective. Remember, my central point is that going from FX8 to FP10 will be a much bigger step in quality than FP10 to FP16 or even FP32. Yes, I think there will be some banding artifacts here and there, but for potentially twice the performance and high speed MSAA to boot, it's a very good compromise.

I don't see why you think this will be such a headache for developers. Many applications will be able to get away with a simple format change for the framebuffer. Even the scaling issue will probably only need to be considered if you want to really simulate HDR accurately instead of just making it look convincing.

I do agree with you, however, that sRGB (i.e. shared exponent) would probably have been a better option. Transistor overhead appears to be limited to just a few comparision and bit-shifting circuits, which is nothing compared to the blending logic.

EDIT: fixed some inaccuracies about eye levels

 

[Bob]

The eye is capable of distinguishing around 10,000 level of contrast at any given time because of this very phenomenon. Note that FP10 gives you a ratio of 32 / (1/256) = 8192.

The *range* ratio is 8192. The actual number of distinct contrast levels for a e3s7 floating-point format is 1024 (cause, you know, there are only 10 bits).

Edit:

my central point is that going from FX8 to FP10 will be a much bigger step in quality than FP10 to FP16 or even FP32.

I don't disagree, although I would have liked to see FP11/FP11/FP10 instead of FP10/FP10/FP10/2.

 

[Hellbinder]

So the question is....ATi ......implement it in the R520

Considering

A] ATi have said they would not do shader model 3 till 90nm so as they could do it properly,

and

B] Those forum members who would actually know suggest the pipe count has not increased over X850,

would suggest the transistor budget would have room for features like antialaised HDR.

/Pure armchair speculation of coarse.

Well, They are wrong.

Pipes Does not account for much anymore anyway. look at the GTX. The R520 is similar in concept.

 

[Mintmaster]

The eye is capable of distinguishing around 10,000 level of contrast at any given time because of this very phenomenon. Note that FP10 gives you a ratio of 32 / (1/256) = 8192.

The *range* ratio is 8192. The actual number of distinct contrast levels for a e3s7 floating-point format is 1024 (cause, you know, there are only 10 bits).

Oops, used the wrong wording. The eye is similar in its logarithmic interpretation of brightness levels. Something like 1,000,000,000:1 is the total range of light we can distinguish, but 10,000:1 at once using local contrast. I fixed it in my original post.

 

[Unknown Soldier]

For FP24 (SM2.x) I think the shader length is 512? For SM3.0 .. it's supposed to be unlimited.

Or am I wrong?

You can't have an unlimited number of instructions: Where would you store such a program? The driver reports back the number of instruction slots that are available. Of course, with looping, the number of executed instructions can exceed the amount of storage, just like on CPUs.

Ah I see .. I'm getting confused with Shader Length and Instruction Counts\Input Registers Etc..

 

[Hubert]

When looking at the first two sets of pictures, ask yourself: When did the moon become a mini-Sun?

http://www.firingsquad.com/hardware/far_cry_1.3/images/18.jpg
http://www.firingsquad.com/hardware/far_cry_1.3/images/17.jpg

http://www.firingsquad.com/hardware/far_cry_1.3/images/15.jpg
http://www.firingsquad.com/hardware/far_cry_1.3/images/16.jpg

http://www.hardocp.com/images/articles/1098809904DJ7a6BZMfd_4_6_l.jpg
http://www.hardocp.com/images/articles/1098809904DJ7a6BZMfd_4_5_l.jpg

Judjing HDR on still images is misleading. You forget the time factor. Moving around in a scene with both strong lights and deep shadows, gives the real athmosphere. The brain stores consecutive visual experiences, perception is one thing but it is followed by very quick processing "understanding". Also there is a certain delay until the eye will adapt itself to different levels of brightness and darkness.
I am sure if you look at a bright Moon on a dark night, you see almost what the linked picture shows. But because the surrounding area is mostly dark, and you move your eyes, your head, your body, the overall perception of darkness will be much stronger. HDR is not just about having larger brightness level ranges on a still; it is also about consecutive perceptions. Of course this is level design related, still, if I understand well, the hardware range limits can be easily taylored to fit different environments.

 

[ZoinKs!]

I am sure if you look at a bright Moon on a dark night, you see almost what the linked picture shows. But because the surrounding area is mostly dark, and you move your eyes, your head, your body, the overall perception of darkness will be much stronger.

Sometimes I go for walks at night. I need to shield my eyes from the glare of the moonlight in order to peer into the darkness under the trees.

However, the effect in those pics is overstated. (I still need to see it in motion to judge. I've seen lots of pics of HDR; anyone have in game movies of it?) I suspect it'll take a while for artists/programmers to get familiar enough with HDR to make it look really good. Until then, there'll be a bunch of overdone and even gaudy effects.

 

[trinibwoy]

Well, They are wrong.

Pipes Does not account for much anymore anyway. look at the GTX. The R520 is similar in concept.

HB, it might be prudent to prefix such posts with an IMO or "I think". The way you state them could lead someone to think that you actually had real info that led you to these conclusions.

 

[bloodbob]

For FP24 (SM2.x) I think the shader length is 512? For SM3.0 .. it's supposed to be unlimited.

Or am I wrong?

You can't have an unlimited number of instructions: Where would you store such a program? The driver reports back the number of instruction slots that are available. Of course, with looping, the number of executed instructions can exceed the amount of storage, just like on CPUs.

Same place it goes on the CPU in memory or paged to disk? Sure you can't have an unlimited program but for all intensive purposes it can be unlimited seeing as I don't know why you would need a shader more then several million instructions long.

 

[OpenGL guy]

For FP24 (SM2.x) I think the shader length is 512? For SM3.0 .. it's supposed to be unlimited.

Or am I wrong?

You can't have an unlimited number of instructions: Where would you store such a program? The driver reports back the number of instruction slots that are available. Of course, with looping, the number of executed instructions can exceed the amount of storage, just like on CPUs.

Same place it goes on the CPU in memory or paged to disk?

Still not unlimited storage.

Sure you can't have an unlimited program but for all intensive purposes it can be unlimited seeing as I don't know why you would need a shader more then several million instructions long.

Pretty sure thats "intents and purposes"

Anyway, very long is not the same as unlimited.

 

[KimB]

Is "banding" the most worrisome issue regarding FP24?

Well, it'll probably manifest itself in that way. Any problems with FP24 that do crop up will be as a result of a series of calculations in a space other than color space (i.e. normal space, texture coordinate space, or something else). This can lead to banding in color space depending upon how these calculations are translated to color space.