On 22 August 2013 00:31, Ian Romanick <i...@freedesktop.org> wrote: > Section 2.1.1 (Floating-point computation) says: > > "The result of providing a value that is not a floating-point > number to such a command is unspecified, but must not lead to > GL interruption or termination. In IEEE arithmetic, for > example, providing a negative zero or a denormalized number > to a GL command yields predictable results, while providing a > NaN or an infinity yields unspecified results." > > I /think/ this qualifies for the "unspecified results" clause. An argument > could probably be made the other way, however. > Well, the application doesn't directly provide the +INF here, so in that sense I don't think this text really applies. The bit right below that about implied divisions by zero probably does though.
Still, I'd argue that +INF or perhaps FLT_MAX would be a more reasonable value than 1.0f, and more importantly that using gl_Fog.scale should give (approximately) the same result as calculating "1.0 / (gl_Fog.end - gl_Fog.start)" in the shader. > Have you tried it on older GPUs? r300? i915? > The patch fixes the relevant Wine D3D tests on AMD RS480 (On top of 9.1.6 anyway, last time I tried r300g just died very early with master. I hope to look into that, eventually.), and NVIDIA NV43. IIRC neither of those has proper IEEE, and just flushes things to +/-FLT_MAX. I don't have full piglit runs for those, but could get them if needed. I'm afraid I don't have much else in terms of older hardware that I can run tests on. I have an i915 and a nv18 or so, but can't run tests on either of those at the moment. > Could we get a simple piglit test case that reproduces the issue? > Sure. It might take a couple of days before I get to it though. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
