DX9.0c available

digitalwanderer said:
DeanoC said:
This has HLSL compiler for SM2.0B and SM3.0 (X800 and NV40 respectively). This is the biggy, the HLSL compiler now understand loops, vertex texturing etc.
Will that help with present games or just future games? :|
Just future, D3DX (the bit where HLSL lives) is statically linked so it takes a recompile to get any benefit.
 
DeanoC said:
Just future, D3DX (the bit where HLSL lives) is statically linked so it takes a recompile to get any benefit.

Well, if the compiler turns out to be really good I guess a patch here and there would be a decent thing to do in some cases.

Which get me a bit off topic: How much does a HLSL recompile influence the present drivers? Is optimizations that was good for the last HLSL not quite so good anymore?
 
So the GF-FX finally gets floating point texture support under D3D.

Funny how most of the perceived limitations/shortfalls of GF-FX turn out to have nothing to do with the silicon or nVidia in the end...
 
radar1200gs said:
So the GF-FX finally gets floating point texture support under D3D.

Funny how most of the perceived limitations/shortfalls of GF-FX turn out to have nothing to do with the silicon or nVidia in the end...

Thanks for that radar :)
 
radar1200gs said:
So the GF-FX finally gets floating point texture support under D3D.

Funny how most of the perceived limitations/shortfalls of GF-FX turn out to have nothing to do with the silicon or nVidia in the end...
:oops:

nag.gif
 
radar1200gs said:
So the GF-FX finally gets floating point texture support under D3D.

Funny how most of the perceived limitations/shortfalls of GF-FX turn out to have nothing to do with the silicon or nVidia in the end...
*spits out metaphorical coffee*
 
radar1200gs said:
So the GF-FX finally gets floating point texture support under D3D.

Funny how most of the perceived limitations/shortfalls of GF-FX turn out to have nothing to do with the silicon or nVidia in the end...

Actually GF FX already supports floating point textures in the latest drivers even in DX9.0b. It has nothing to do with the new D3D AFAIK.
 
I'd be highly surprised if that were the case. The software simply couldn't query the appropriate cap bits if the user had an earlier runtime.
 
Well, it did show two floating point texture formats in the CapsViewer before I installed the new DX runtime. There are some more floating texture formats after the new runtime, though.
 
The GF-FX situation is a bit like centroid sampling on R3xx. Always present but not able to be properly detected and used because the capability is part of a higher DX9 SM than currently publiclly supported.
 
radar1200gs said:
The GF-FX situation is a bit like centroid sampling on R3xx. Always present but not able to be properly detected and used because the capability is part of a higher DX9 SM than currently publiclly supported.

No, they have specific limitations and the caps bit is there to say that these float textures can be supported with these limitations - this is not something that would have been included had these limitations not existed.
 
Yeah, that explained the new texture formats. It appears that GF FX's FP16/FP32 ARGB format can't do wrapping and MIP mapping. However, in earlier DX runtime, there is no such usage query. On the other hand, FP16 GR format and R32F can do wrapping and MIP mapping, so they are supported in earlier DX runtime.
 
Back
Top