Futuremarks technical response
- Thread starter Harlequin
- Start date
JF_Aidan_Pryde
Regular
DaveBaumann said:Dave H - Slow down
DaveB - Hurry up
Long List 
I thought I understood this, but others seem to say otherwise and I could use with some confirmation or correction: is floating point output a specification of the shader version, or the DirectX version?
I.e., is there such a thing as a "pixel shader 1.1 program working on floating point values", or does producing/accepting floating point values automatically make it "pixel shader 2.0", regardless of the instructions used?
The language used in, for example, Futuremark's discussion of GT 4, lead me to believe "pixel shader version" is determined by the instruction set and length, and it simply makes sense to me that it would be this way.
I.e., is there such a thing as a "pixel shader 1.1 program working on floating point values", or does producing/accepting floating point values automatically make it "pixel shader 2.0", regardless of the instructions used?
The language used in, for example, Futuremark's discussion of GT 4, lead me to believe "pixel shader version" is determined by the instruction set and length, and it simply makes sense to me that it would be this way.
demalion said:
Ahem.
You can find the info ... if you know where to look.
No it's precompiled unfortunately.
But it wouldn't help much if it was in source because DX 9 HLSL compiler is implemented in D3DX which is linked statically to the app, so Futuremark should have to release a patch anyway to update it.
demalion said:
Neigther.
There's such a thing that "PS1.1 program working on FP values" but it's not specified nor denied by DirectX. The R300 does this (there's no integer shaders in R300).
DirectX requires that PS1.1 should handle at least 8 bit precisity and a range of [-1, 1].
The driver can indicate the highest absolute value it supports in 1.x shaders by the devcaps:
GF3/4: 1.0
R8500/9000: 8.0
GFFX: 2.0
R9500/9700: 340282346638528860000000000000000000000.0
Pixel shader version have to be explicitly specified in the shader source.
For HLSL the version has to be passed to the compiler.
The HLSL compiler has no knowledge of the hardware apart from the PS version passed to it!
The PS specs put certain requirements on the instruction set, number of registers, read ports, instruction limits, etc. as well as they have some numerical requirements.demalion said:
AFAIK PS 1.x only define what numerical range an implementation must support, but no min. precision. It should be perfectly valid to use float values in a PS1.1 implementation.
PS 2.0 however requires float values, at least s10e5 in some areas, and at least s15e8 in others.
JF_Aidan_Pryde
Regular
Hyp-X said:
Joe DeFuria
Legend
I'll expand on Dio's "floating point" response.
NV30 is capped at 2.0 because it uses an "interger pipeline" when doing 1.1 pixel shaders. (And we still don't know, IIRC, what nV30 does with PS 1.4 shaders...)
It can affect overbright lighting, etc, for directX 8.X code However, this would mean that the code is checking the range caps for each card. In other words, using the Radeon 9500/9700 chip, "overbright" and other effects requiring high dynamic range can be performed in DirectX 8 shaders. You must use DX9 shaders on the FX to get the same result.
JF_Aidan_Pryde said:
That's 1.x shaders only.
NV30 has both integer and floating-point shader hardware, 1.x shaders are executed in the integer hw, 2.0 shaders in the fp hardware.
So it doesn't affect it's HDR capabilities as long as you use 2.0 shaders.
(We still don't know how exactly PS1.4 is implemented, my guess is that 1st phase uses FP, while 2nd phase uses integer.)
Edit: Damn I wasn't fast enough.
Joe DeFuria
Legend
Why, because nVidia can't do it? Is there any technical reason not to? If nVidia's PS 2.0 shader path really is as slow as it currently appears, wouldn't it be nice to be able to run some effects in the PS 1.1 path that don't need PS2.0 shaders?
And what would you do with the HDR in ps_1_1? You still have to bring the HDR back in [0,1] range for display you know. You don't even have any fancy texture lookups (as in ps_1_4 and above). What are you going to do with it?Joe DeFuria said:
Pixel shaders 2.0 will run just fine once drivers are optimised.
Joe DeFuria
Legend
Perhaps you're right. PS 1.1 is extremely limiting. Devs won't do much with it at all in terms of really noteworthy features.
so what about PS 1.4? Does FX support high dynamic range in PS 1.4? (And just as important, does the FX, with WHQL drivers, have acceptable speed with PS 1.4?)
As Hyp-x said: We don't know. The obvious guess would be that they have to run at lest firsth phase in float mode (since it deals with texture coordinates, which might get out of [-2,2] range).Joe DeFuria said:
Why wouldn't FX be able to provide acceptable speed with ps_1_4 with WHQL drivers? From what we know about FX it is much more complex then Radeon 9700 (it executes pixel shaders from video memory, TMUs are able to output up to 4 texels per clock if they can fetch in advance,...). I think it's quite obious that NVidia optimised OpenGL NV30 path first (since they are running all their demos on this path), while all other paths were nothing more but working.
