On Tue, May 08, 2012 at 08:40:03AM -0700, Ian Romanick wrote: > On 05/08/2012 02:51 AM, Olivier Galibert wrote: > > The apparent cost of the calibration is eaten by the constant > > propagation optimization pass. > > Is the underlying problem that the constant in the acos implementation > just didn't have enough precision? Would adding more digits to the > literal constant help?
Not sure it could. Not every floating point value can be represented reliably in decimal, and the final value yield by the polynomial implementation of asin may vary depending on systems too, theorically. > There is still a danger here. You (we) are assuming that asin on the > CPU and asin on the GPU produce the exact same result. This may or may > not be the case. Yup, the code makes that assumption. OTOH, one can hope */+ on floats behave identically on the CPU and the GPU (decent assumption on amd64 because of sse, probably wrong on i386 because of the 80-bits fpu). And that, in any case, acos(1) being stricly equal to 0 is probably irrelevant outside of constant expressions. One could argue that not having asin/acos/atan/etc GLSL IR ops is the issue. Not sure how extensive the instrinsic support is in modern gpus. Best, OG. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
