Woot ATI to have SM3.0 on next major card release :P

Enabling HDR in Far Cry causes a 50% performance penalty. Softshadows in riddick are available only on the GF6 series because the developer didn't bother to implement it in SM2 form. Same goes for SC Chaos Theory due to their relationship with nvidia, although they have said they may add an SM2 option.

 

well with the r520 ati will support both which will be nice and hopefully with the n50 or whatever replaces the current nv40 (and not just modified parts ) will support 3dc as its an open standard

 

Well, if they're doing something similar to this demo:
http://download.developer.nvidia.com/developer/SDK/Individual_Samples/samples.html#HLSL_SoftShadows
....then I have doubts that an SM2 codepath would work. In this demo, the SM2 codepath is approximately 1/4th the performance of the SM3 codepath. The SM3 codepath in Chronicles of Riddick is already slow enough.

Chronicles of Riddick is, after all, the first game I've ever seen make use of soft-shadowed stencil shadows. So where's your evidence that it could have been implemented at similar performance with SM2?

As for the performance hit from HDR, well, you're going to have to expect somewhere around a 50% performance hit from that anyway.

 

NV40 already supports 3Dc in drivers since a few betas back. I am not sure how robust this support is, it probably needs some improvement, but this is certainly something Nvidia can work on. I am not sure what limitations are imposed when done on the driver level. The 3Dc demo by Humus shows some anomalies in the normal mapping using 3Dc in the distance, but otherwise it looks ok. Perhaps some more comparisons should be done between X800 with official support and 6800 using driver emulation to determine how well this is functioning currently.

 

Chronicles of Riddick is Opengl isn't it? As far as that game goes its just an nVidia specific extension, or does the game actually use SM3?

 

The soft-shadows in COR I believe use specific GeForce 6 only extensions, thereby not allowing for use on SM2.0 cards (R300, NV30, R420 etc..). RingWraith, Riddick does use OpenGL, and it'd be logical to assume that they're using SM3.0 level extensions.

A 50% performance hit using HDR is expected. You're effectively doubling the colour depth (although the tone mapping pass converts the image to 8 BPC, but this is the only way to do it as long as we have 8 bit displays) that the graphics card has to process and you are also doubling the amount of texture memory that you must use.

Does anyone know if the next ATi chip will be supporting floating point blending and filtering?

 

Well, harken back to the early days of NWN and the "shiny water" issue. At first the blurb was that ATi cards couldn't support shiny water because of the hardware differences between ATi and nV. As we saw, however, that was never the case at all, and the *real problem* was simply that bioware had used nV-specific OpenGl extensions and had to be coaxed by its unhappy customers to confer with ATi so as to learn how to use ATi-specific extensions so that shiny water could render properly on ATi hardware. And that is exactly what happened when NWN shiny water came to ATi--had nothing whatever to do with hardware at all.

I suspect the issues relative to this thread are exactly the same, as "soft shadows" surely does not require SM3.0 hardware (especially the *current* SM3.0 hardware available)...

 

I thought Riddick used SM2.0++? :?

 

Except in this case the effect is also not enabled for the NV3x. So that logic doesn't hold.

Then why, pray tell, has no other game implemented it? Soft shadows are trivial when you're using shadow mapping, but far from it when using stencil shadowing.

 

That's what they call it, but since it can only run on the GeForce6, this may be what they're calling SM3.

 

Dunno. But this is the thing that's bugging me the most at the moment. If HDR rendering using FP blending is such a performance killer, how is Xbox 360 going to achieve this?

I suppose if we take SC:CT's use of FPB-HDR as indicative, supposedly a release title for XBox 360, then it seems likely ATI has the technology.

Perhaps FP-blending for HDR is "too new", so ATI hasn't had time to integrate it into R500. And since SM3 doesn't seem to say anything about FP-blending (does anyone expect SM4 to say anything?) may be it's a wash.

On the other hand, FPB-HDR seems to be quite a fad. Xbox 360 with no HDR would seem to be a mistake.

Though I wonder if Xbox 360 can afford to come to life with a major graphical feature that's essentially "incompatible" with its targetted performance (hi-def resolution support, AA). I only say that judging by the appalling performance hit of FPB-HDR on NV40. If it's unusably slow at 1920x1080 (is that a targetted resolution for Xbox 360?) then will floating pint blending even be included?

Would the "+" in Xbox 360's SM3+ imply the inclusion of floating point blending?

None of ATI's presentations at GDC seemed to mention FPB-HDR (judging by the PDFs), so maybe ATI isn't close to implementing floating point blending.

In fact, curiously, the talk on Irradiance Volumes for Games:

http://www.ati.com/developer/gdc/GDC2005_PracticalPRT.pdf

didn't seem to include any concept of high dynamic range in the modelling of light. Maybe, being pre-computed, HDR simply drops out, anyway.

Jawed

 

If your GPU is fully programmable, you can do *any* effect.

When is a device fully programmable? You would need to be able to access and store random data at all stages (textures in any format, accessible from / to the VS and the PS), make calculations independent of fixed datatypes (bitwise), perform logical calculations (boolean) and do flow control (loop, if..then, case).

What we are talking about in relation to all the different models is: "Are we there yet?"

As of now, the short answer is: "No, but we can think of clever hacks that have the same effect in all cases, as long as we can access the data at all the different stages."

 

fp 16 blending has unintentionally been confirmed to be on all ATIs SM3.0 parts. Additionally there has been indications of support of fp 16 blending for r520 in drivers

fp filtering may not be supported(on r520) though but i guess we have to wait for official information to be sure on that

 

Floating point blending is the best way for fully general High-Dynamic-Range rendering.

Preferably you'd want hardware blending, but there's nothing stopping you from doing it on a DX9 class card without blending, although it may require some extra passes.

EDIT: Floating point blending HDR isn't a "fad". High-Dynamic-Range rendering is the way of the future, and quite simply, to do a (more) accurate representation of real-world lighting simulations, you need the expanded color ranges.

HDR isn't just "bloom" as seen in Half-Life 2, or the overbright possible with Doom 3.

Sure, FarCry's HDR is very overexposed, but thats because the content wasn't really remade for it. Future games on the CryEngine utilizing HDR will look fabulous.

 

Well, one extra pass. The buffers that need to be blended must be input into a shader pass as textures.

 

Not when you're using blending in the scene. Particle effects, for instance, could really balloon the number of required passes.

 

Yeah, I remember reading in JC's plan that it would take and extra texture copy pass or something.

Maybe it may need more for different instances.

 

Ah. . . I stand corrected. I was thinking only of full scene passes.

 

The soft shadows in CoR aren't about SM3.0 at all. The problem, AFAIK, is NV_copy_depth_to_color, an extension that allows to read back depth and stencil to a texture. ATI simply doesn't offer this functionality.

 

"soft shadows" in general may not require it, but their particular algorithm might. That's like saying "shadows" don't require a shadow volume. Yes, it is true that you can implement shadows via multiple algorithms, but developers cannot be expected to implement multiple algorithms for multiple cards (e.g. should Doom3 offer both shadow buffers and shadow volumes?)

Some shadowing algorithms may use early-out branching to sample up to N times on pixels which need it the most, but not to sample N times on every pixel in the whole scene which may be prohibitively expensive. Given budgetary (and time) requirements (see GDC panel), developers might not be able to implement both an SM3.0 dynamic branch *AND* a stencil emulation of it on SM2.0. Some things get left for future patches.