_pp Going Forward

[Geo]

Well, it's coming up on a year since the release of the GF6 line. I seem to recall some speculation at that time on whether GF6 would mean the end of _pp, with some people holding out the possibility that developers would continue to use it even with GF6. The argument being that judicious use would still help performance without hurting IQ.

We are far enuf down the road now that there should be some valid "reports from the field" on this issue. So, what does it look like? Was _pp an FX-blip, now consigned to the trash-heap of history, or is new development still coding it? What, if anything, does this mean for folks who still have midrange FX cards (lots more of those sold than the 58/59 models) for their performance on new apps down the road? Will more developers follow the Valve lead and force them to DX8 rather than spend their limited resources to "code around" their performance foibles?

Please note --*new development*.

 

[Richard]

We are far enuf down the road now that there should be some valid "reports from the field" on this issue.

Although I believe ATi should go for full 32-bit with the R520 they might surprise everyone with a mixed precision pipeline. If so it would influence the adoption of partial precision hints. Also, S3's parts also have a 16/32 precision. Yes, I know S3's cards are either not available or not relevant for this kind of generalisation.

So, what does it look like? Was _pp an FX-blip, now consigned to the trash-heap of history, or is new development still coding it? What, if anything, does this mean for folks who still have midrange FX cards (lots more of those sold than the 58/59 models) for their performance on new apps down the road? Will more developers follow the Valve lead and force them to DX8 rather than spend their limited resources to "code around" their performance foibles?

As a very satisfied Radeon 9800 Pro user I hope developers do NOT follow Valve and invest time and resources in putting pp in their shaders. If there's one qualification I would not give to put a pp hint in shaders is "code around". What's harder is testing to see if it introduces artefacts. But let me ask you, when we had the choice to run at 16 bit or 32 bit colour modes depending on where we wanted more speed/quality respectively was it that bad? Wasn't it nice to have that option? I always chose 32-bit when I upgraded from my VooDoo2 to a TNT2 but I was happy to have the choice there even if it made painfully obvious how ugly it looked.

In games today we have the ability to turn down resolution, disable some shader effects, reduce geometry detail, even to substitute some models with sprites, and even LOD, mipmap quality in the driver panels, etc. etc. etc. PP hints is just another (acceptable IMO) decrease in quality for a gain in performance. I'd personally never use it but I wouldn't want people with lesser cards to be denied that option.

Anyway, I think pp hints are on the way out unless ATi's next card has mixed precision.

 

[991060]

I think it's totally application specific.

If the shaders in the game are very complex, which means even using _pp can not save NV3x, developers will probably drop them into DX8 class. On the other hand, if the shaders are relatively simple(like in doom3), developer will have a reason to use _pp wherever possible.

Also note that even for NV4x, _pp will gain you a few FPS in some situation, developers will be happy to follow the GPU programming guide:

Use partial precision whenever possible. There are two reasons to use partial precision with GeForce 6 Series GPUs. First, the GeForce 6 Series has a special free fp16 normalize unit in the shader, which allows 16-bit floating-point normalization to happen very efficiently in parallel with other computations. To take advantage of this, simply use partial precision whenever appropriate in your programs. The second reason is that partial precision helps to reduce register pressure, potentially resulting in higher performance.

 

[Geo]

But let me ask you, when we had the choice to run at 16 bit or 32 bit colour modes depending on where we wanted more speed/quality respectively was it that bad? Wasn't it nice to have that option? I always chose 32-bit when I upgraded from my VooDoo2 to a TNT2 but I was happy to have the choice there even if it made painfully obvious how ugly it looked.

In games today we have the ability to turn down resolution, disable some shader effects, reduce geometry detail, even to substitute some models with sprites, and even LOD, mipmap quality in the driver panels, etc. etc. etc. PP hints is just another (acceptable IMO) decrease in quality for a gain in performance. I'd personally never use it but I wouldn't want people with lesser cards to be denied that option.

I'm all in favor or more choice. The problem with _pp that I saw, was that the user didn't have choice --the developers, guided often by performance, and sometimes with NV leaning on them, made that choice for the user. If there is a fairly easy user-friendly UI way to do what you are suggesting (i.e. either in the control screens of the driver or the application --no manual editing of .ini files or registry keys!) to do what you suggest, I would be all for it.

My main wonder is if it still being used in new development, and if developers are finding value in it for GF6. . .because if they aren't, the developers cost/benefit analysis of continuing to do that coding for only the FX people going forward is liable to go against them. . .

 

[Geo]

Use partial precision whenever possible. There are two reasons to use partial precision with GeForce 6 Series GPUs. First, the GeForce 6 Series has a special free fp16 normalize unit in the shader, which allows 16-bit floating-point normalization to happen very efficiently in parallel with other computations. To take advantage of this, simply use partial precision whenever appropriate in your programs. The second reason is that partial precision helps to reduce register pressure, potentially resulting in higher performance.

Yes, I remember hearing about this --I'm just wondering if developers are following it, or if given the effort involved (more at the macro level than any individual change) they aren't? Part of what crystalized this issue in my mind was the recent B3D review of the 6600GT comparing it to the FX5900. The 6600 totally bitch-slapped the FX5900. There is such a jump (and, hey, good on NV!) in performance from one generation to the next (this year's mid-range sticking it hard to the previous high-end!)that I really do wonder if developers will continue to find enuf value in _pp to justify the effort, or if they are just generally satisified with the horsepower of the GF6 to provide acceptable performance without it, and the FX folks are just out of luck on this issue going forward.

 

[Richard]

I'm all in favor or more choice. The problem with _pp that I saw, was that the user didn't have choice --the developers, guided often by performance, and sometimes with NV leaning on them, made that choice for the user. If there is a fairly easy user-friendly UI way to do what you are suggesting (i.e. either in the control screens of the driver or the application --no manual editing of .ini files or registry keys!) to do what you suggest, I would be all for it.

IIRC there's a third party util (made by someone from this board AFAIK) that lets you force either full or partial precision. But that's not what I was referring to as the optimal way to do it (since, AFAIK, it forces the chosen precision for ALL shaders regardless of their complexity). Valve has a lot of different material files for water, they have one for DX7 cards, another for DX8 and DX9 (I also think they have one for DX8.1 cards). Developers could simply copy the DX9 shaders and add the pp hint. If it introduces artefacts hey, so did 16-bit colour, or changing the LoD, mipmaps, etc. It's a fact of life people would accept just as they accept that changing texture quality in <insert_name_of_game_here> to lowest makes the textures look like crap.

My main wonder is if it still being used in new development, and if developers are finding value in it for GF6. . .because if they aren't, the developers cost/benefit analysis of continuing to do that coding for only the FX people going forward is liable to go against them. . .

Well, recent games still support DX7 hardware (D3, HL2, FarCry, etc.) which is cute but let's face it 5 years is a long time so technically developers are coding for a lot of (small) niches already. I think developers just want to hit as big a target as they can possibly get away with. And I should know, I had a GF2 GTS 32mb until 6 months ago and I played practically everything I wanted. Having said that I think there's not enough "market value" for pp hints in the eyes of most people even if they are a probably easier to implement than a T&L path to go with your DX9 path and probably don't influence overall development and hinder your main full-impact graphics platform as much as say, supporting 1Ghz CPUs as minimum requirement.

On one hand I shouldn't care because people should read reviews before they buy computer hardware (and read Beyond3D for all their graphics needs) and there's many people who bought a GFFX because they hated ATi in some misguided sense of loyalty towards nVidia but on the other I'm genuinely sorry for GFFX owners who probably got their card as a gift or it came with their new Dell or whatever. I don't like seeing those people getting the shaft just because two years down the line even loyal nVidia fans admit the GFFX was bollocks.

 

[Unknown Soldier]

I don't like seeing those people getting the shaft just because two years down the line even loyal nVidia fans admit the GFFX was bollocks.

That will never happen.

US

 

[repi]

For the next-generation games I'm working on (both PC and consoles) we don't use it at all and I'm guessing most other game developers with similar targets neither will use it.

 

[martrox]

Let's face it, from now on, the FX series will be treated as HL2 treated them....as DX8 cards. So there's no reason for partial PP at all.

 

[Dave Baumann]

There are still uses for it, such as the FP16 normalise function for NV4x, which does make sense when processing with FP16 buffers. However, in the longer term I would expect FP16 to be just as much of stop gap measure as FP24 is - its probably a transition point from integer to fully float processing and as more transistors can be dedicated to such things then the free FP16 functions that are available now may end up becoming free FP32 ones.

Critical points for the future of it will be whether there is any FP16 capabilities in PS3 and what WGF2.0 specifies.

 

[Sigma]

Why shouldn't be used? That is like dropping char and short from C and use only int. Or use double everywhere instead of float.

If my colors and normals come from ubyte/fp16 textures, shouldn't I use half instead of float?
And it is not just an NVIDIA thing. I don't know if ATI's R520 supports them, but if it does, then every user that buys that card will also benefit from fp16. It the card doesn't support it, no problem.

 

[Geo]

For the next-generation games I'm working on (both PC and consoles) we don't use it at all and I'm guessing most other game developers with similar targets neither will use it.

A fact! A fact!! Thank you! Everybody back off slowly so as not to scare it. . .

 

[DegustatoR]

For the next-generation games I'm working on (both PC and consoles) we don't use it at all and I'm guessing most other game developers with similar targets neither will use it.

A fact! A fact!! Thank you! Everybody back off slowly so as not to scare it. . .

Depends on _what_ NG console he is talking about If PS3 GPU will have FP16 precision then i'd say it'll be used very widely

But then we don't know ATM if NV will still be supporting _pp in NV5x series.

And i believe that R520 will be pure FP32 with possible FP16 filtering/blending.

 

[karlotta]

For the next-generation games I'm working on (both PC and consoles) we don't use it at all and I'm guessing most other game developers with similar targets neither will use it.

A fact! A fact!! Thank you! Everybody back off slowly so as not to scare it. . .

Depends on _what_ NG console he is talking about If PS3 GPU will have FP16 precision then i'd say it'll be used very widely

But then we don't know ATM if NV will still be supporting _pp in NV5x series.

And i believe that R520 will be pure FP32 with possible FP16 filtering/blending.

You cant read? hint , he said " ...consoles"

 

[ninelven]

erased

 

[DegustatoR]

You cant read? hint , he said " ...consoles"

So?

 

[KimB]

However, in the longer term I would expect FP16 to be just as much of stop gap measure as FP24 is - its probably a transition point from integer to fully float processing and as more transistors can be dedicated to such things then the free FP16 functions that are available now may end up becoming free FP32 ones.

I don't know, Dave. Consider SSE, for example. It added additional processing power at lower precision than the now standard x87 FPU. You can spend far fewer transistors for the same result if you go with lower precision. FP16 is sure to be enough for many operations, due to the fact that it's higher precision than any reasonable output for PC graphics.

The missing link at the moment are developer tools to gracefully determine when partial precision can and cannot be used. What we need are:

1. Software to automatically detect which instructions in a shader should or should not use partial precision, best with varying levels of aggressiveness.

2. Software that runs robust checks on the shaders to determine visual impact of using partial precision.

Using two such pieces of software with loopback would produce an excellent, automated way to keep performance high while not significantly increasing developer time. If any hardware companies want to actively pursue partial precision hardware for the next generation of hardware and beyond, they should seriously look into developing software such as that above.

Edit: The alternative is the death of hand-made shaders for games, and the birth of optimized shader libraries. Since optimized shader libraries should happen anyway, as a means to allow the artists to customize shaders, this is another potential direction.

 

[Geo]

I would think even some relatively reliable (erring on the side of caution) rules of thumb would be darn helpful, and could turn it into a process you could turn over to an intern. Something like "more than x instructions" or instructions that include x and y. You'd think NV would have some incentive to go at least that far in giving guidance, rather than just dumping it on the developers.

 

[Dave Baumann]

I don't know, Dave. Consider SSE, for example. It added additional processing power at lower precision than the now standard x87 FPU. You can spend far fewer transistors for the same result if you go with lower precision. FP16 is sure to be enough for many operations, due to the fact that it's higher precision than any reasonable output for PC graphics.

And the early talks of Shader Model 4 suggested a Integer instruction set alongside a Floating Point. I suspect that the transistors saving gains in the few FP16 specific instructions there are at the moment will be fairly negligable in future processors.

 

[KimB]

And the early talks of Shader Model 4 suggested a Integer instruction set alongside a Floating Point. I suspect that the transistors saving gains in the few FP16 specific instructions there are at the moment will be fairly negligable in future processors.

Wouldn't that be all the more reason to implement FP16-specific instructions? If those instructions are commonly-used, it seems all the more prudent.