To support Floating-Point is meanless,isnt it?

[KimB]

In a certain way, this lends credibility to the notion that NV35 will use the ARB2 path and not the NV30 path. I can't see it defaulting to a mode which compromises IQ (even slightly) if it gains little to no performance benefit from doing so. Given that NV30 never had a significant retail presence, the GPUs that will run the NV30 path are really the NV31 and NV34, where the slight IQ drop may be considered more acceptable because they don't claim to be top-of-the-line.

The ARB2 path doesn't support FP16, which the NV35 excels at. Perhaps JC will make a path for the NV35 that simply changes all FX12 instructions to FP16 ones (According to Uttar's benches, that shouldn't drop performance significantly), and allow options for these various optimizations to be used.

Anyway, as far as specific features of the ARB2 and NV30 paths, we'll have to wait until the game comes out, as things can (and probably will) change.

 

[Dave H]

The ARB2 path doesn't support FP16, which the NV35 excels at.

Why not? Won't ARB_precision_hint_fastest select FP16 on NV3x hardware? (This is an honest question, BTW; I don't know the answer, but such was my impression.)

Perhaps JC will make a path for the NV35 that simply changes all FX12 instructions to FP16 ones (According to Uttar's benches, that shouldn't drop performance significantly), and allow options for these various optimizations to be used.

If the NV30 path approximates the specular calculations with different methods (e.g. cubemap for normal vector normalization instead of calculating it), then simply changing FX12->FP16 won't make it calculate the normalization arithmetically all of a sudden. It'll require a new path. Or the use of the ARB2 path assuming it can be made FP16-friendly (which I don't think should be a problem).

Anyway, as far as specific features of the ARB2 and NV30 paths, we'll have to wait until the game comes out, as things can (and probably will) change.

True. Hyp-X was the one who asserted what would and wouldn't be in the final paths, not me. I meant to question his assertion with my post, but once I started writing it started making more sense to me.

But to be clear: as far as I know, the ARB2 path having those extra features was only true as of Carmack's .plan, and could change in the final game. In fact, I would be surprised if that didn't change in the final game, unless there is some good reason why the NV30 path can't support them. My totally uninformed guess is that the reason it might not change is because of NV30/31/34's affinity for FX12. If that's the reason, I would guess that those features will be enabled for NV35 cards, either through having NV35s use the ARB2 path (which I think would work without giving up too much performance, and which Carmack has hinted at), or perhaps through a new NV35 path as you propose.

 

[AndrewM]

The ARB2 path doesn't support FP16, which the NV35 excels at.

Why not? Won't ARB_precision_hint_fastest select FP16 on NV3x hardware? (This is an honest question, BTW; I don't know the answer, but such was my impression.)

Perhaps JC will make a path for the NV35 that simply changes all FX12 instructions to FP16 ones (According to Uttar's benches, that shouldn't drop performance significantly), and allow options for these various optimizations to be used.

If the NV30 path approximates the specular calculations with different methods (e.g. cubemap for normal vector normalization instead of calculating it), then simply changing FX12->FP16 won't make it calculate the normalization arithmetically all of a sudden. It'll require a new path. Or the use of the ARB2 path assuming it can be made FP16-friendly (which I don't think should be a problem).

Anyway, as far as specific features of the ARB2 and NV30 paths, we'll have to wait until the game comes out, as things can (and probably will) change.

True. Hyp-X was the one who asserted what would and wouldn't be in the final paths, not me. I meant to question his assertion with my post, but once I started writing it started making more sense to me.

But to be clear: as far as I know, the ARB2 path having those extra features was only true as of Carmack's .plan, and could change in the final game. In fact, I would be surprised if that didn't change in the final game, unless there is some good reason why the NV30 path can't support them. My totally uninformed guess is that the reason it might not change is because of NV30/31/34's affinity for FX12. If that's the reason, I would guess that those features will be enabled for NV35 cards, either through having NV35s use the ARB2 path (which I think would work without giving up too much performance, and which Carmack has hinted at), or perhaps through a new NV35 path as you propose.

There's no reason that it cant be done with NV_fragment_program.
Using a cube normal map isnt really an _approximation_ as such, also.

 

[KimB]

Why not? Won't ARB_precision_hint_fastest select FP16 on NV3x hardware? (This is an honest question, BTW; I don't know the answer, but such was my impression.)

Here's an answer from the ARB_fragment_program extension:

    (22) Should we provide applications with a method to control the 
    level of precision used to carry out fragment program computations?

      RESOLVED:  Yes.  The GL implementation ultimately has control over 
      the level of precision used for fragment program computations.  
      However, the "ARB_precision_hint_fastest" and 
      "ARB_precision_hint_nicest" program options allow applications to 
      guide the GL implementation in its precision selection.  The 
      "fastest" option encourages the GL to minimize execution time, 
      with possibly reduced precision.  The "nicest" option encourages 
      the GL to maximize precision, with possibly increased execution 
      time.

      If the precision hint is not "fastest", GL implementations should
      perform low-precision operations only if they could not 
      appreciably affect the final results of the program.  Regardless 
      of the precision hint, GL implementations are discouraged from 
      reducing the precision of computations so aggressively that final 
      rendering results could be seriously compromised due to overflow
      of intermediate values or insufficient number of mantissa bits.

      Some implementations may provide only a single level of precision, 
      in which case these hints may have no effect.  However, all
      implementations will accept these options, even if they are 
      silently ignored.

      More explicit control of precision, such as provided in "C" with 
      data types such as "short", "int", "float", "double", may also be 
      a desirable feature, but this level of detail is left to a 
      separate extension.

Anyway, what you should get out of this is that it appears the precision hint is a global variable that is set. It is not an instruction-level control, which is required for optimal usage (It just isn't possible to properly-detect the precision that should be used in every shader, and a relatively short shader written properly for FX12/FP16 shouldn't display any loss in quality).

But to be clear: as far as I know, the ARB2 path having those extra features was only true as of Carmack's .plan, and could change in the final game.

And remember, it wasn't even stated. It was just implied. He said nothing more than he was playing around with the ARB_fragment_program extension.

 

[Dave H]

There's no reason that it cant be done with NV_fragment_program.

Right. My question is whether it will be done with the NV30 path. Hyp-X seemed to assert it won't; Carmack's .plan only said that it wasn't being done four months ago, but also didn't seem to imply that would change. The only reason I can't think of why it wouldn't is if that path uses FX12 for performance purposes.

So assuming the NV30 path continues to normalize with cubemaps, there are two ways NV35 hardware could normalize with math (by default): either code a new "NV35" path (using NV_fragment_program), or have it use the ARB2 path.

Using a cube normal map isnt really an _approximation_ as such, also.

As I understand it, it's a point sampled version of a continuous function, right?

 

[andypski]

Using a cube normal map isnt really an _approximation_ as such, also.

As I understand it, it's a point sampled version of a continuous function, right?

I assume that he has bilinear filtering on, so it would be a piecewise linear approximation to a continuous function.

 

[Humus]

Still an approximation though. With low-precision results I might add.

 

[Ostsol]

Still an approximation though. With low-precision results I might add.

Well, unless it's a huge, floating point cubemap. . . Icky. . .

 

[AndrewM]

Sorry, I should clarify what I'm getting at. It's not such a _bad_ approximation.

 

[Humus]

Still an approximation though. With low-precision results I might add.

Well, unless it's a huge, floating point cubemap. . . Icky. . .

It doesn't matter. You're still getting 8bit/channel output. Unless you're using a floating point texture, but then you're not getting any filter.

 

[KimB]

Sorry, I should clarify what I'm getting at. It's not such a _bad_ approximation.

Approximations always fall into the same category:
They're only bad in specific situations.

How bad the approximation is depends on your situation.

As JC stated, the cube map lookup can look quite bad on large quads, requiring significant tessellation for proper specular.