[Mesa-dev] [PATCH 1/1] mesa: Properly set the fog scale (gl_Fog.scale) to +INF when fog start and end are equal.
Henri Verbeet
hverbeet at gmail.com
Thu Aug 22 00:39:44 PDT 2013
On 22 August 2013 00:31, Ian Romanick <idr at 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.
More information about the mesa-dev
mailing list