r420 may beat nv40 in doom3 with anti-aliasing
- Thread starter LokeshRay
- Start date
DemoCoder said:
Point taken Democoder.
And when you consier this you have to wonder exactly what the massive interest in shader 3.0 is right now from some quarters. Sadly though, around here you often have trouble enough getting one concept at a time to sink into certain heads, let alone several at once.
whql said:DemoCoder said:
Point taken Democoder.
And when you consier this you have to wonder exactly what the massive interest in shader 3.0 is right now from some quarters. Sadly though, around here you often have trouble enough getting one concept at a time to sink into certain heads, let alone several at once.
Its newest and best thing, Ever heard of boys with toys? No other reason than that
DaveBaumann said:
Actually that's a strange point. NVIDIA doesn't follow ps1.4 specs. PS1.4 range should be at least -8/8. NVIDIA doesn't follow that point because they want to be able to use the fixed unit (range -2/2) of some NV3x.
However because these GPU have PS2.0 support NVIDIA can automatically expose PS1.4 support even without following the specs.
That's a glitch in DX specs. MS probably didn't expect that a GPU won't use the same math unit for ps1.x and for ps2.0. DX spec expect PS1.4 to be computed by the unit that compute PS2.0.
I've checked the online informations and you're right. MS doesn't talk about the requested range for temporary registers / calculations. They only say that this range is defined by the pixelshader1xmaxvalue caps.Clootie said:-8/8 range required only for read-only texture (t#) registers in ps_1_4Tridam said:
That's strange because I'm nearly sure to have read that this caps has to be at least 8 to have ps_1_4 support. I don't remember where (online ressources, SDK or DDK) and when (maybe this detail as been modified by MS) I read this. I also think that I've seen the pixelshader1xmaxvalue saying 8 with nv3x while in practive it was 2.
I've checked this caps with the current drivers. Now it's 1 with nv34. And 2^16 with NV40.
Tridam said:I've checked the online informations and you're right. MS doesn't talk about the requested range for temporary registers / calculations. They only say that this range is defined by the pixelshader1xmaxvalue caps.Clootie said:-8/8 range required only for read-only texture (t#) registers in ps_1_4Tridam said:
That's strange because I'm nearly sure to have read that this caps has to be at least 8 to have ps_1_4 support. I don't remember where (online ressources, SDK or DDK) and when (maybe this detail as been modified by MS) I read this. I also think that I've seen the pixelshader1xmaxvalue saying 8 with nv3x while in practive it was 2.
I've checked this caps with the current drivers. Now it's 1 with nv34. And 2^16 with NV40.
http://msdn.microsoft.com/library/e...241-4f1c-be53-078f60af97e2.xml.asp?frame=true
But maybe this is not longer valid. Who knows?
Demirug said:Tridam said:I've checked the online informations and you're right. MS doesn't talk about the requested range for temporary registers / calculations. They only say that this range is defined by the pixelshader1xmaxvalue caps.Clootie said:-8/8 range required only for read-only texture (t#) registers in ps_1_4Tridam said:
That's strange because I'm nearly sure to have read that this caps has to be at least 8 to have ps_1_4 support. I don't remember where (online ressources, SDK or DDK) and when (maybe this detail as been modified by MS) I read this. I also think that I've seen the pixelshader1xmaxvalue saying 8 with nv3x while in practive it was 2.
I've checked this caps with the current drivers. Now it's 1 with nv34. And 2^16 with NV40.
http://msdn.microsoft.com/library/e...241-4f1c-be53-078f60af97e2.xml.asp?frame=true
But maybe this is not longer valid. Who knows?
Thank you. It means that I'm not having hallucinations
radar1200gs
Regular
The reason PS V1.4 is currently so popular is because it works with R3xx/R4xx's mini ALUs.
You may want to ask yourself why a "DX9" benchmark would use PS V1.4 instead of _PP hinting.
Pixel Shader V1.4... it's the partial precision you have when you don't have a partial precision.
You may want to ask yourself why a "DX9" benchmark would use PS V1.4 instead of _PP hinting.
Pixel Shader V1.4... it's the partial precision you have when you don't have a partial precision.
radar1200gs
Regular
What crap?
PS V1.4 is an DX8.1 class shader model, not DX9 class.
3DMARK03 is billed as a DX9 benchmark, but has almost no DX9 content (and ignores whole DX9 subsytems such as _PP hinting), most of the shaders are PS1.4 or below.
PS V1.4 is an DX8.1 class shader model, not DX9 class.
3DMARK03 is billed as a DX9 benchmark, but has almost no DX9 content (and ignores whole DX9 subsytems such as _PP hinting), most of the shaders are PS1.4 or below.
GT4 requires PS 2.0. You're right, it doesn't use _PP, but that's not a major feature of DX9, the shaders are though. The benchmark also doesn't use floating point textures, good thing for NVIDIA, hmm? How do you suppose the NV3x parts would have fared then?radar1200gs said:
-FUDie
radar1200gs
Regular
I beg to differ about _PP not being a major DX9 feature.
If all DX9 graphics cards supported _PP, you would see more titles using SM2.0 and less using PS V1.4. Like I have said before, the lack of _PP on all cards has held back the adoption of DX9.
Performance wise NV30, NV31 & NV34 would probably hurt a little in 3DMARK03, NV35 NV38 & NV36/7 wouldn't be as badly affected since their mini ALU's are FP16 (_PP capable).
If all DX9 graphics cards supported _PP, you would see more titles using SM2.0 and less using PS V1.4. Like I have said before, the lack of _PP on all cards has held back the adoption of DX9.
Performance wise NV30, NV31 & NV34 would probably hurt a little in 3DMARK03, NV35 NV38 & NV36/7 wouldn't be as badly affected since their mini ALU's are FP16 (_PP capable).
All dx9 cards should support precision hints in the pixel shader. Its only the radeon series upscale the 16bit hints to 24bit and carry out math at the higher accuracy. Not sure with Volari & deltachrome(both 24-bit??), but their drivers should just convert to 24bit also, if thats how they work internally???
As far as im aware, partial precision is handled through the drivers and although it can offer slight performance increases, its not really a major part of the shading features offered in dx9.
Unfortunately the early FX series cards wont benefit a great deal due to the slower shading architecture, and register issues they were designed with. Here is a possible reason why ps1.4 has been used, which can basically run much faster on the slower dx9 cards and r2xx cards. Why would you run all shaders as ps2 when simple ones can run faster when processed as ps1.4(or ps1.1) especially on slower/older cards???
Widespred Dx9 uptake has taken so long because the delays and disappointments of Nvidia, XGI and S3. Nvidia has finally stepped up, so it should be full steam ahead, especially once the geforce6 series spreads to all the markets, now ATI has pushed dx9 down to the low-end also.
As far as im aware, partial precision is handled through the drivers and although it can offer slight performance increases, its not really a major part of the shading features offered in dx9.
Unfortunately the early FX series cards wont benefit a great deal due to the slower shading architecture, and register issues they were designed with. Here is a possible reason why ps1.4 has been used, which can basically run much faster on the slower dx9 cards and r2xx cards. Why would you run all shaders as ps2 when simple ones can run faster when processed as ps1.4(or ps1.1) especially on slower/older cards???
Widespred Dx9 uptake has taken so long because the delays and disappointments of Nvidia, XGI and S3. Nvidia has finally stepped up, so it should be full steam ahead, especially once the geforce6 series spreads to all the markets, now ATI has pushed dx9 down to the low-end also.
Oh yeah, that's right. nVidia not building their card to the actual dx9 spec had nothing to do with it...radar1200gs said:
radar1200gs
Regular
digitalwanderer said:Oh yeah, that's right. nVidia not building their card to the actual dx9 spec had nothing to do with it...radar1200gs said:
Excuse me Please, do show me where you think NV35 and above doesn't meet DirectX specs.
radar1200gs
Regular
Azza, NV30, NV31, NV34 won't get the boost NV35 and above see due to their redesigned mini ALU's, but they can still do _PP regardless, just less efficiently.
What does PS1.x have to do with DX9 gaming? True Dx9 games won't use PS1.x shaders only 2.0 and above.
Both nVidia and ATi have contributed to the current mess where we still use PS1.x. nVidia moved to address this with NV35, ATi hasn't done a thing about it.
What does PS1.x have to do with DX9 gaming? True Dx9 games won't use PS1.x shaders only 2.0 and above.
Both nVidia and ATi have contributed to the current mess where we still use PS1.x. nVidia moved to address this with NV35, ATi hasn't done a thing about it.
Lemme answer your question with a question, why is _PP such a big deal?radar1200gs said:
Please, do show me where you think NV35 and above doesn't meet DirectX specs.
I don't think nV35 or any of the nV3x generation actually are dx9 cards. They may SAY they are, and they might be physically capable of all the dx9 things....but they can't do it at any kind of playable framerate or with any kind of decent AA.
Now that's just my opinion, but it is an opinion I based on my own experiences with my own nV35.
Doomtrooper
Veteran
radar1200gs said:
How does that differ from game production, I suggest you educate yourself. Why would a developer use PS 2.0 for a water effect, you use the lowest common shader to deliver your desired result.
Farcy is being billed/benchmarked as a DX9 game but the water is a simple 3 year old PS 1.1 shader. In fact Far Cry is very close to GT4 in terms of shaders supported, which means Futuremark has done a pretty good job forcasting what a DX9 engine would look like !!
http://firingsquad.com/hardware/far_cry_nvidia/
