WHQL Spec for Drivers concerning DX9

[Brent]

I've been searching on MS's site for documentation about the WHQL spec for drivers to be compliant with DX9 requiring FP24 as a minimum. I haven't been able to find what I'm looking for.

If anyone here knows where I can read documentation on the WHQL requirenments for Drivers and DX9 I'd really appreciate it, I want to look at all that from their site.

Thanks!

 

[Toasty]

I also could not find any direct DX9 documentation relating to your question on MS's website, but I can tell you that the test kit which verifies full DX9 compliance for display adapters is DCTDX9 and can be downloaded from this link:

http://www.microsoft.com/hwdq/hwtest/devices/default.asp?area=DisplayAdapter

If you install it, I recommend you do so on a computer that can easily be reimaged as opposed to uninstalling the application afterwards. Also, once you install DCTDX9 it enables a system service called Driver Verifier which is used by the test kit to 'monitor' what the driver is doing. This will reduce D3D/2D benchmark scores. Run "verifier.exe" from the Run prompt to disable Driver Verifier and restore performance. All DCT tests will still run after this change, it's just no longer a valid WHQL submission if you wanted to send it to Microsoft

 

[Dave Baumann]

There's numerour references to the minimum precision for partial precision in the DX9 SDK C++ docs:

Partial Precision
The partial precision hint (represented as _pp in the assembly) can be used by the application to indicate to the device that the operation can be performed and the result stored at a lower precision (at least s10e5). This is a hint and many implementations might ignore it.

 

[sonix666]

I have found a Microsoft korea presentation that has the Direct3D 9 core as subject. It states that for the pixel shaders the ALU has to correspond to the following rules to be Direct9 compliant:

- All color data (I expect red, green, blue and alpha) has to be FP16 at minimum.
- All non-color data (I think things like texture coordinates) has to be FP24 at minimum.

The link for the full presentation:
http://www.microsoft.com/korea/events/directx/ppt/Direct3DCore.ppt

Other than that I have not seen any publically released official specs of DirectX 9 from which we can make sure wheter FP24 is the minimum requirement for everything in pixel shaders 2.0 or what I have just quoted from the presentation.

Looking at the data types of the high level language shaders I would find it very strange if FP24 was required for even color data, because why on earth would they introduced a half datatype which is a 16 bit floating point.

 

[Arun]

I have found a Microsoft korea presentation that has the Direct3D 9 core as subject. It states that for the pixel shaders the ALU has to correspond to the following rules to be Direct9 compliant:

- All color data (I expect red, green, blue and alpha) has to be FP16 at minimum.
- All non-color data (I think things like texture coordinates) has to be FP24 at minimum.

The link for the full presentation:
http://www.microsoft.com/korea/events/directx/ppt/Direct3DCore.ppt

Other than that I have not seen any publically released official specs of DirectX 9 from which we can make sure wheter FP24 is the minimum requirement for everything in pixel shaders 2.0 or what I have just quoted from the presentation.

Looking at the data types of the high level language shaders I would find it very strange if FP24 was required for even color data, because why on earth would they introduced a half datatype which is a 16 bit floating point.

So, basically...
nVidia is going to get the 43.45 WHQL certified, and they're perfectly legal DX9 drivers?!
Damn, *now* I'm scared...


Uttar

 

[nutball]

You'd think someone@ATI would be able to point to this, wouldn't you

 

[LeStoffer]

So, basically...
nVidia is going to get the 43.45 WHQL certified, and they're perfectly legal DX9 drivers?!
Damn, *now* I'm scared...

Uttar

Hold on a second there, that presentation might not reflect that Microsoft change the specs on the FP16 vs FP24 issue after the DX9 launch (it was an error that it didn't got fixed in the docs apparently). AFAIR we still don't know whether Microsoft will really strongarm nVidia on this one or not. Deano C got some partial confirm if I remember correctly.

 

[sonix666]

Ofcourse, Microsoft will change specs when they just feel like it when hardware vendors have already been developping hardware on the previous specs a year back. I don't really buy that. It's just to bad that the official Microsoft specs for DirectX 9 are not publically available. That would clear up things once and for all. Where did the fact/rumour originally came from that it was a typo and should have been FP24? Do you have an URL for me?

 

[Brent]

I also could not find any direct DX9 documentation relating to your question on MS's website, but I can tell you that the test kit which verifies full DX9 compliance for display adapters is DCTDX9 and can be downloaded from this link:

http://www.microsoft.com/hwdq/hwtest/devices/default.asp?area=DisplayAdapter

If you install it, I recommend you do so on a computer that can easily be reimaged as opposed to uninstalling the application afterwards. Also, once you install DCTDX9 it enables a system service called Driver Verifier which is used by the test kit to 'monitor' what the driver is doing. This will reduce D3D/2D benchmark scores. Run "verifier.exe" from the Run prompt to disable Driver Verifier and restore performance. All DCT tests will still run after this change, it's just no longer a valid WHQL submission if you wanted to send it to Microsoft

Sweet Thanks! I do have a test system I can install this on and check out, which I will do. Thanks for the heads up on that info.

There's numerour references to the minimum precision for partial precision in the DX9 SDK C++ docs:

Partial Precision
The partial precision hint (represented as _pp in the assembly) can be used by the application to indicate to the device that the operation can be performed and the result stored at a lower precision (at least s10e5). This is a hint and many implementations might ignore it.

Thanks Dave! I have the SDK but I haven't sat down and read the documents it came with etc... I will check that one out for sure.

Thanks sonix666 and LeStoffer for the info as well


I agree, I wish we could know for 100% certainty with some documentation we could point at and say here is at least the minimum FP format the drivers have to be doing to meet WHQL spec for DX9.

 

[Reverend]

Brent, you can forget about scanning the SDK wrt what you're looking for -- the SDK is basically a tutorial more than anything else... it is assumed you're a developer who has been kept up-to-date by MS regarding the progress of DX9... so the SDK may be useless for you in this regard With DirectX, there isn't so much of a formal spec as a bunch of conversations between Microsoft, IHV's, and ISV's with summary documents written from time to time with varying degrees of detail.

As for your original question... all I can say is that we're looking at pretty muddy waters. I know you want "cut-and-dry" answer(s) to your question but it isn't as simple as it may seem... it depends on the type of instructions, not a "overall" thing. [edit]And I absolutely agree with this because we're talking about different types of effects we want[/edit]

 

[RussSchultz]

http://www.microsoft.com/hwdq/hwtest/default.asp

Probably more information than you'll ever want to know. Maybe what you're looking for is buried deep inside there somwehre?

 

[DeanoC]

It has been confirmed to me by both MS and NVIDIA that except for constant registers, precision must be FP24 (constant register precision can be FP16) unless the _PP flag is set.

While I haven't seen the complete spec, Amar Patel (the guy at MS who does this stuff) posted to DirectXDev mailing list the relevant portion, which I cut and pasted below (yes I'm geeky enough to have the entire DirectXDev mailing list archive).

Basically the entire trouble was caused by me I didn't agree with the presentation NVIDIA gave at Dusk To Dawn, so I brought it up and MS agreed with me. NVIDIA argued but MS stuck to there guns (much to NVIDIA annoyance), this was confirmed by a NVIDIA DevRel to me a couple of weeks ago (I won't post the email as it private). The matter is officially closed, PS_2_0 is FP24 minimum without the partial precision flag, the SDK update (coming soon) will have an optional FORCE_PARTIAL_PRECISION flag that can be passed to the HLSL compiler to force all floats into halfs but thats a developer's choice. If you use HLSL half or _pp you will get the FP16 paths on GFFX (but no difference on ATI R3x0 cards).


A quote from Amar Patal from MS
"Here's a cut&paste from our spec, with the one typo in it corrected
(noted with **).

[from ps_2_0 section]
---Begin Paste---
Internal Precision
- All hardware that support PS2.0 needs to set
D3DPTEXTURECAPS_TEXREPEATNOTSCALEDBYSIZE.
- MaxTextureRepeat is required to be at least (-128, +128).
- Implementations vary precision automatically based on precision of
inputs to a given op for optimal performance.
- For ps_2_0 compliance, the minimum level of internal precision for
temporary registers (r#) is s16e7** (this was incorrectly s10e5 in spec)
- The minimum internal precision level for constants (c#) is s10e5.
- The minimum internal precision level for input texture coordinates
(t#) is s16e7.
- Diffuse and specular (v#) are only required to support [0-1] range,
and high-precision is not required. ---End Paste ---

For ps_3_0 the requirements are the same, however interpolated input
registers are now defined by semantic names. Inputs here behave like t#
registers in ps_2_0: they default to s16e7 unless _pp is specified
(s10e5).

Note that specifying _pp on an input register only affects how they are
read into temp registers or what precision ALU math might run on an op
reading an input as a parameter. However texld* instructions that take
in unmodified texture coordinates will not be affected by the _pp
modifier, as the texture coordinate iterators are of fixed precision.


amar
"