I mentioned no specific hardware here - I was just giving an example.Chalnoth said:That's a very specific case, and you'd have to cite an example for your point to be of any use. I seriously doubt that many of the "old" unsupported texture addressing modes of either the NV4x or R4xx are terribly useful at all.
If I'm reading this right, he's suggesting (and it makes sense) that calculating the HDR values in-process rather than a post-function blending stage results in a slightly more accurate final image.so I have added a few little
tweaks to the current codebase on the ARB2 path:
High dynamic color ranges are supported internally, rather than with
post-blending. This gives a few more bits of color precision in the final
image, but it isn't something that you really notice.
NV40 has nothing to do with my comment. I was referring to the fact that supporting two float precision formats is more complex than supporting a single format. Thus, I believe it was part of the reason NV30 was late and it contributed to the slower than expected performance.Chalnoth said:The NV40 has shown pretty clearly that FP32/FP16 had nothing to do with the poor floating-point performance of the NV3x line.3dcgi said:I think the possible drawback is a bad product cycle, NV30.
Albuquerque said:My first post, my bazillionth thread that I've read Just a snippet I encountered for you folks bickering on the merits of HDR requiring post-blending:
Per John Carmack on the ARB2 path in D3...
If I'm reading this right, he's suggesting (and it makes sense) that calculating the HDR values in-process rather than a post-function blending stage results in a slightly more accurate final image.so I have added a few little
tweaks to the current codebase on the ARB2 path:
High dynamic color ranges are supported internally, rather than with
post-blending. This gives a few more bits of color precision in the final
image, but it isn't something that you really notice.
Which says to me two things:
#1. Doom 3 will support some form of HDR when in ARB2 render mode
#2. X800's will have no problem running it in "native mode" rather than some form of hack
I am also assuming two more things:
#1. This is Carmack, we all know that many programmers and developers will likely use a similar method to his.
#2. If a floating point framebuffer was previously understood as the only "proper" way to do HDR, I think Carmack is a big enough uber-geek to dispell that myth now.
Obviously there are still problems with doing HDR calcs without a floating point framebuffer, which have been discussed in this thread (real time HDR reflections being a very notable one), but it seems that HDR on R3xx or R4xx hardware is further from a "hack" and more of a methodology change.
Pardon my interruption; let the flaming, bickering and logical fallacies continue
Edit - I apologize, I found that quote in the same plan where he talked about dropping vendor-specific rendering paths and going to only ARB / ARB2.
Being the first game engine to feature Shader Model 3.0 support (enabled only by the nVidia GeForce 6 series) to allow for a host of visual effects including high dynamic-range lighting and FP16 blending, it’s likely that Unreal Engine 3.0 will become the de-facto standard for first-person-shooter titles in 2005 and beyond.
The OpenEXR standard is actually fairly new and has not been around for many years. Since January 2003 to be exact. After R300. ILM developed it internally before that though.
R200 and other such vendor-specific rendering paths and going to only ARB + ARB2),
Seriously doubt it. Since it's not native to any CPU (no common CPU at least), you'd have to do conversions every time it was written to or read from memory, which would be very slow.archie4oz said:The OpenEXR standard is actually fairly new and has not been around for many years. Since January 2003 to be exact. After R300. ILM developed it internally before that though.
Depends on which FP16 format... Rhythm & Hues (and others using CinéPaint) have been using an unsigned 8e8 format for quite a while now too... Anyways I imagine it's only a matter of time before the s5e10 format migrates into the standard C library as a standard type.
Seriously doubt it. Since it's not native to any CPU (no common CPU at least), you'd have to do conversions every time it was written to or read from memory, which would be very slow.
Those are useful formats because they provide more precision than the HW may support, not less. What's the point of doing emulation for a format with less precision than the HW can support?archie4oz said:Ummm, yeah.... Sorta like long longs on non-64-bit processors or extended-precesion floats on any non-x86 hardware? (or quad-precision floats on anything)...Seriously doubt it. Since it's not native to any CPU (no common CPU at least), you'd have to do conversions every time it was written to or read from memory, which would be very slow.
You'd still want to do all the computations in FP32 (at least) to get HW acceleration. If you want to store it in FP16 in a file, then use an image conversion library. No need at all for this to be in libc, like I said before.archie4oz said:Storage primarily... Dunno why it seems all that unfathomable to you, it's pretty common in image processing to deal with all sorts of data formats that are non-native to CPU hardware (and sometimes hardware will gain hardware support for it (e.g. AltiVec's pixel formats)...
Chalnoth said:You're not going to do, for example, 100 blends before the final render in a game.
If you need to combine multiple objects via blending, what choice do you have? Doing it in the pixel shader won't help you as it means you're reading the destination as a texture anyway. The pixel shader can't combine the results of multiple fragments before writing to the framebuffer.Chalnoth said:Um, because it won't be realtime?
If you want to do that much blending, you'd find a way to do it all within the pixel shader, to avoid what would become an extreme memory bandwidth penalty.