is there a way to disable the P.S. 1.4 support of NV3X?

[OpenGL guy]

OGL Guy:

IIRC, in terms of gaming, the only thing PS1.4 offers is speed improvements (in Radeon series, anyway) due to being able to do a lot more in a single pass.

As I said, speed improvements due to doing more per pass.

Note that my last comments were directed strictly at Chalnoth.

But, as I said, PS 1.1-1.3 can not do everything PS 1.4 can do: Multipassing doesn't count! Also, how do you get high dynamic range in PS 1.1-1.3?

Well, I believe for PS 1.4 to work properly, it needs higher than 12-bit integer precision (I think the R200 actually uses 16-bit integer?). This means that when running PS 1.4, the GeForce FX must use nothing but floating-point calculations (since the integer calcs are too low-precision), leaving the FX at approximately only 1/3 of its execution units running. The possible speed boost available from dropping to 1.1-1.3 should be obvious.

So, even though you may get correct results by using PS 1.1-1.3 in place of PS 1.4, speed is all that matters? If you want speed, I'll give you a driver that renders nothing! Then you can brag about some really obscene benchmark results

 

[Xmas]

Also, how do you get high dynamic range in PS 1.1-1.3?

Exactly the way you get it in PS 1.4

 

[K.I.L.E.R]

Also, how do you get high dynamic range in PS 1.1-1.3?

Exactly the way you get it in PS 1.4

LMFAO!!! I remember people running 3dmark with a wireframe image and the monitor turned off.

Turning off the monitor gives a speed boost? I laughed my ass off.

 

[Humus]

Also, how do you get high dynamic range in PS 1.1-1.3?

Exactly the way you get it in PS 1.4

What about the [-8, 8] range in ps1.4? In ps1.3 and below you can't even have constants larger than 1.

 

[Xmas]

What about the [-8, 8] range in ps1.4? In ps1.3 and below you can't even have constants larger than 1.

Range
The range is the maximum and minimum register data value. The ranges vary based on the type of register. The ranges for some of the registers can be queried from the device caps using GetDeviceCaps.

Name Type                 Range                                            Versions 
cn   Constant register    -1 to +1                                         All versions  
rn   Temporary register   - MaxPixelShaderValue to + MaxPixelShaderValue   All versions 
tn   Texture register     - MaxPixelShaderValue to + MaxPixelShaderValue   1_1 to 1_3  
tn   Texture register     - MaxTextureRepeat to + MaxTextureRepeat         1_4  
vn   Color register                                                        1_4

Early pixel shader hardware represents data in registers using a fixed-point number. This limits precision to a maximum of approximately eight bits for the fractional part of a number. Keep this in mind when designing a shader.

For pixel shader version 1_1 to 1_3, MaxTextureRepeat must be a minimum of one. For 1_4, MaxTextureRepeat must be a minimum of eight.

PS1.4 guarantees [-8, 8] for texture coordinates only (i.e. the first phase). PS1.1 is not implicitly limited to [-1, 1].

 

[Bambers]

If you want to talk multipass, that's a different story. However, for you to claim that multipass doesn't have a performance impact (as your original post about PS 1.1-1.3 being faster seemed to imply) is ridiculous. If there's no performance impact, please explain why the GeForce 4 series is so slow at GT2 and GT3 in 3D Mark 2003?

8500 isn't exactly speedy at it either. 8.7 and 10.2 fps respectively at 300/300.

I have noticed that Ps1.4 performance got a prod recently though.

3dmark2001 APS test used to be ~ 79fps with ps1.1 and 89fps with ps1.4, that score went up to 110fps with one of the recent drivers, might have been the same boost that put 3dmark03 gt2 and 3 up.

 

[Nick[FM]]

Sorry to cram in here, but if you guys want to test some PS1.1 vs. PS1.4 performance, you can now force PS1.1 in 3DMark03 GT2 and GT3. Using the new patch, of course..

 

[antlers]

Like I said, PS 1.1-1.3 can't do everything that PS 1.4 can do...

Every gaming situation I've yet seen states otherwise. The only improvements in using PS 1.4 that I've yet heard about in games have been from the improved dynamic range of PS 1.4, not from the added features.

Even the 3DMark01 "Advanced Pixel Shader" test had a fallback that looked exactly like the PS 1.4 solution.

You could make a software fallback for every GPU feature (except frame-buffer depth) that would look "exactly the same". That doesn't mean the features aren't desirable or necessary. NVidia had the fairy running on their emulation drivers before the FX was available, after all (just not very quickly).

 

[Tagrineth]

You could make a software fallback for every GPU feature (except frame-buffer depth) that would look "exactly the same". That doesn't mean the features aren't desirable or necessary. NVidia had the fairy running on their emulation drivers before the FX was available, after all (just not very quickly).

...except that we aren't talking about software fallbacks, we're talking about falling back to previous PS versions.

 

[OpenGL guy]

You could make a software fallback for every GPU feature (except frame-buffer depth) that would look "exactly the same". That doesn't mean the features aren't desirable or necessary. NVidia had the fairy running on their emulation drivers before the FX was available, after all (just not very quickly).

...except that we aren't talking about software fallbacks, we're talking about falling back to previous PS versions.

But it does require software intervention, right?

 

[demalion]

You know what I'd be really curious about? The performance and image quality of 8500/9000 cards with a multipassed PS 1.4 implementation of 3dmark 03's GT 4 and the PS 2.0 test. Hmm...the precision of look up would be good enough for the Sin function in the PS 2.0 test, right?

 

[MrNiceGuy]

dx9 changes 1.x

Under dx9, the max range for #s under ps.1.x is in a cap bit.

For nv3x it's either [-1,1] or [-2,2)

So, you can't rely on ps.1.4 having [-8,8] range.

 

[Testiculus Giganticus]

Mmm, PS 1.4 is usefull, undoubtedly, but it is not going to be usefull in replacing PS 2.0 through multipassing, as you suggest.There is not enough precision to compensate for the losses that come with multipass, and some functions are also too high-precision to do.So i don`t see why such a comparison would be so interesting...?

 

[demalion]

MrNiceGuy:

Not for FX cards, true.
But if you're going to consider custom coded speed enhancements and quality reductions for the FX, why can't you consider speed enhancements and quality enhancements, within an already established cross vendor standard, for the 8500-9200 cards?

You just seem to be pointing out that the 8500/9000 can do things that even a GF FX using PS 1.4 does not seem to be capable of, and do it with good performance.

Hmm...if programs can check for capabilities that aren't relevant to their tasks, why can't they check for capabilities that are?

 

[demalion]

Mmm, PS 1.4 is usefull, undoubtedly, but it is not going to be usefull in replacing PS 2.0 through multipassing, as you suggest.

Indeed?

There is not enough precision to compensate for the losses that come with multipass, and some functions are also too high-precision to do.

Ok, the first reminds me of certain observations made of GF FX cards in those tests. As to how it differs from that, that was the nature of my question: for example, what is the maximum buffer output the 8500/9000 are capable of?

The second, hmm...you're sure about that? That's the question I asked.

So i don`t see why such a comparison would be so interesting...?

Hmm...you don't seem to be able to establish for certain that it is not possible, you're questioning my interest in seeing the results and comparing the quality of the output. Well, despite your lack of interest, I, personally, still manage to be interested somehow. Now, if we can establish something is not possible, that would address my interest, but that's why I asked that question. Do you have a more useful answer to it?

 

[Xmas]

MrNiceGuy:
Hmm...if programs can check for capabilities that aren't relevant to their tasks, why can't they check for capabilities that are?

What caps exactly do you mean?

 

[demalion]

Hmm...should I have quoted MrNiceGuy's mention of cap bits, or are you asking for examples of programs checking for capabilities that aren't relevant to the featureset they decide to deliver after checking?

 

[Testiculus Giganticus]

Hmm, that`s a rather nasty reaction Well, as far as i know, in ps 1.4 you can only do dependatn texture reads once meaning that you work on a texture and you have only ONE chance to use that texture in its modified state as a base for more work-in PS 2.0 you don`t have that limitation.On the other hand, PS 1.4 means INT12, while PS 2.0 means at least FP24-a quite considerable precision delta, wouldn`t you say?You could perhaps cut a LOT of corners, and make it work more or less-but it wouldn`t be a comparison-that was my point.You can`t compare a wireframe render to a textured one, can you?

 

[Xmas]

Hmm...should I have quoted MrNiceGuy's mention of cap bits, or are you asking for examples of programs checking for capabilities that aren't relevant to the featureset they decide to deliver after checking?

Ah sorry, I didn't get your question was a rhetorical one

Of course if some app relies on a range greater than [-2, 2], it could use ps2_0 on DX9 hardware and ps1_4 on ATI DX8 hardware. But frankly, I don't expect this to happen very often.

 

[Lezmaka]

Maybe I'm wrong, but does any card company other than ATI have support for PS1.4? and I'm not talking about being able to run PS1.4 via PS2.0