[Mesa-dev] [Bug 89586] Drivers/DRI/swrast

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89586

--- Comment #36 from Dan Sebald <daniel.sebald at ieee.org> ---
What is the general thought regarding floating point numerical issues and the
OpenGL formulas?  The reason the swrast-legacy driver is failing one the Piglit
pixelzoom tests is that this computation:

     c1 = imageX + (GLint) ceil((spanX + spanWidth - imageX) *
ctx->Pixel.ZoomX);

has numerical issues when ctx->Pixel.ZoomX is fractional and negative.  (Sign
isn't at the heart of the issue, the fact it is fractional is, i.e., -1 <
ctx->Pixel.ZoomX < 0.)  A few example numbers work out as follows (this is part
of the succession of smaller filled rectangles test):

span.x=160 span.end=400
(c0=-0.000000 c1=-119.000008)=>(-0.000000,-119.000000)

span.x=160 span.end=400
(c0=-0.000000 c1=-117.999992)=>(-0.000000,-117.000000)

span.x=160 span.end=400
(c0=-0.000000 c1=-116.999992)=>(-0.000000,-116.000000)

span.x=160 span.end=400
(c0=-0.000000 c1=-116.000000)=>(-0.000000,-116.000000)

Note how there are two end columns that are shorter than they should be, and
the scaling here isn't very drastic, 1/2.5.

Is there anything about the OpenGL standard that allows for, say, a band of
numerical tolerance for ceil and floor operations?  Or is it supposed to be
that formulas consider GLfloat xfactor and yfactor as though they are real
numbers, i.e., need exactness?

I can make all the swrast tests pass if I put some tolerance in for the ceiling
function.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150325/b0df83ff/attachment.html>