GFFX exposes no FP-Textures???

[maven]

Regular
It seems that in current drivers (43.51 as well as Nvidia last "official" release 43.45) do NOT expose neither floating point texture-formats nor render-targets. What's up with that? Too slow?

Might also explains some of the IQ-issues (missing overbrights / what-have-you), depending on how the app is coded...
 
The last time I asked NVIDIA dev-rel about the 'interesting' DX drivers, I got the following answers.

No high precision integer render-targets are going to be supported (8 bit is your limit).
Drivers in future will support 1 channel FP32 and 2 channel FP16 render targets, no others.
No multiple render targets
No multiple elements textures (maybe in Dx9.1 they may support some new METs)
 
DeanoC said:
The last time I asked NVIDIA dev-rel about the 'interesting' DX drivers, I got the following answers.

No high precision integer render-targets are going to be supported (8 bit is your limit).
Drivers in future will support 1 channel FP32 and 2 channel FP16 render targets, no others.
No multiple render targets
No multiple elements textures (maybe in Dx9.1 they may support some new METs)

:oops:
 
So uhm... Why the f'ck has nVidia's PR team been advertising the NV3x's flexibility?
Then DR says differently?
 
Well, those things *are* enabled in OpenGL, I think ( could be wrong though )

Is Jen Hsun Huang in some type of holy crusade against Microsoft, because he thinks that'll get him Sony favors? Eh... Damn, NOW we're in trouble! :D

More seriously though, it does seem like nVidia doesn't like DX's way of exposing their functionality, so they simply say they don't have the functionality. My guess is nVidia thinks DX programmers would program with R300 performance hits in mind, and since some things are horribly slow on the NV30 and not on the R300, then it'd be better simply not to expose them.
Odd strategy, but it could make sense - although it does show the poor performance of the architecture...


Uttar
 
They're coming

Sorry, Deano, you got the wrong info.

A developer I know has a driver that contains fp render targets & texture and MET support. No fp cubemap or volume textures yet, tho.

Fp render targets used to be turned on, but some WQHL problem made them turn 'em off.
 
Re: They're coming

MrNiceGuy said:
No fp cubemap or volume textures yet, tho.

It's not a surprise as nv30 doesn't support these...

martrox said:
And this is what we get from the company with the best driver support?

From the company that used to have the best driver support. :(

Actually best doesn't mean good. ;)
 
It's simply qestion of last time internal DX9 spec changes... MS favor ATI this time and NV got some troubles. also not all working and present inside chip. so practicaly they can enable only part of this and only in OGL :cry:
 
If it's true that they have no plans to support floating point render targets then this is complete BS (sorry for the bluntness, but I haven't eaten mah dinna' yet! ;) ). That's one of the most important features of DX9 and not supporting it is not supporting DX9, it's as simple as that. What good is high-precision internal calculations if you can't store the intermediate results at the correct precision level?

I don't expect fp cubemaps or volume textures, but ATLEAST support D3DFMT_A16B16G16R16F 2D render targets.

Not supporting MRTs annoyed me as well, but I have learned to live without that feature for the [rare] instances where it's useful (it's rather slow anyway).

*grumble* *grumble* *grumble* :devilish:

I really hope MrNiceGuy is right
 
martrox said:
And this is what we get from the company with the best driver support?

I still haven't determined if it's my fault, Microsoft's or the drivers, that I can't get proper Multisampling in neither 43.45 or the beta 43.51 in XP/SP1 and dx9.0a.

Hybrid AA modes looked hilarious; I got only AA from the Supersampling part :D

***edit:

pardon the OT; I'm talking about the NV25 anyway.
 
It's simply qestion of last time internal DX9 spec changes... MS favor ATI this time and NV got some troubles. also not all working and present inside chip. so practicaly they can enable only part of this and only in OGL
Uh *NO*..

Just because something does not work on an Nvidia board does not mean that Microsoft is Favoring ATi. DX9 is DX9 is DX9. Its up to the Hardware companies to or not to.. *Correctly* support it.

Nvidia broadcast to everyone what the Nv30 was *suppsed* to be capable of. If it was able to meet the expectations Nvidia themselves created there would be no troubble at all. They are the ones with non efficient FP32, They are the ones with sub par DX9 Shader performance, They are the ones with... -fill in the blank-
 
Hellbinder[CE said:
]
Just because something does not work on an Nvidia board does not mean that Nvidia is Favoring ATi. DX9 is DX9 is DX9.-

Hell.... I see a problem with this...... :oops:
 
UncleSam DL iXBT said:
It's simply qestion of last time internal DX9 spec changes... MS favor ATI this time and NV got some troubles. also not all working and present inside chip. so practicaly they can enable only part of this and only in OGL :cry:

My understanding of DX is that the spec is known to IHVs and it is up to them to support it. I don't think this is a result of MS favoring ATi but rather a result of Nvidia cutting corners more likely. Nvidia knew that FP24 was to be the min spec for DX9. The problem is that they said they were going to use FP32 and it was too slow to use even on a GFFX 5800 Ultra. Nvidias problem with DX9 stems from their chip design rather then DX9 spec or MS, if you ask me.
 
Back
Top