PS2.0 Quality

[JohnH]

All this is predicated on it being a precision bug, which I think is incorrect. Why would system cache be involved and why would the result look like *point sampling*

System cache???

Actally looking at the images again, you may be correct...

John.

 

[Humus]

All this is predicated on it being a precision bug, which I think is incorrect. Why would system cache be involved and why would the result look like *point sampling*

I have written many shaders where the result looks like point sampling when the problem is something else. Skipping normalisation of the normal can give results like that. Commenting out the normalisation line in the shader in my Portals demo gives this result:

 

[KimB]

Using normals that aren't normal? What were you thinking?

Anyway, it's either performance optimizations being too aggressive (_pp), a simple bug, or a cube map lookup being used with point sampling. Either way it should be fixable with little to no performance hit.

 

[Kaotik]

Using normals that aren't normal? What were you thinking?

Anyway, it's either performance optimizations being too aggressive (_pp), a simple bug, or a cube map lookup being used with point sampling. Either way it should be fixable with little to no performance hit.

Little to no performance hit on NV40 perhaps, but on NV3x, I doubt it (doubt it, since the problem was introduced with patch which gave nice speed bump on NV3x's)

 

[KimB]

Little to no performance hit on NV40 perhaps, but on NV3x, I doubt it (doubt it, since the problem was introduced with patch which gave nice speed bump on NV3x's)

No, I think it would even be little to no performance hit on the NV3x.

If it's a _pp problem, then it's likely removing _pp on just a couple of instructions would fix the problem, which shouldn't dramatically effect performance.

If it's a texture point sampling problem, then simply switching to linear sampling will fix the problem, which should cause no performance hit.

 

[Kaotik]

Little to no performance hit on NV40 perhaps, but on NV3x, I doubt it (doubt it, since the problem was introduced with patch which gave nice speed bump on NV3x's)

No, I think it would even be little to no performance hit on the NV3x.

If it's a _pp problem, then it's likely removing _pp on just a couple of instructions would fix the problem, which shouldn't dramatically effect performance.

If it's a texture point sampling problem, then simply switching to linear sampling will fix the problem, which should cause no performance hit.

Then why was the "bug" introduced in the first place? Knowing how deep nVidia has their hands on FarCry (well, I don't actually, but I just pretend I know and then pretend I'm right too), I doubt that kinda bug could have just "slipped there unnoticed", if one can fix it without practicly any performance loss.

 

[KimB]

Then why was the "bug" introduced in the first place?

Wait for the next patch. I see no reason to believe that it was placed deliberately.