Bug 11609 - SIN and COS do not support angles outside of -PI to PI.
Summary: SIN and COS do not support angles outside of -PI to PI.
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: git
Hardware: Other All
: low normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-14 20:16 UTC by Chad Page
Modified: 2009-08-24 12:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Patch for both SIN and COS - rounds the angle parameter to -/+ PI (2.07 KB, patch)
2007-07-15 00:18 UTC, Chad Page
Details | Splinter Review

Description Chad Page 2007-07-14 20:16:43 UTC
While SCS only supports angles between -PI and PI, SIN and COS are expected to wrap the angle so that any parameter is used.  The code emitted from the driver does not include the handling for this.  r300 does handle this and it's implementation might be a useful reference for fixing this.
Comment 1 Chad Page 2007-07-15 00:18:42 UTC
Created attachment 10734 [details] [review]
Patch for both SIN and COS - rounds the angle parameter to -/+ PI

I believe this fixes it - I adapted it from the r300 patch but it dosen't do a pi/2 rotation along the way so the rest of the routines are unchanged.
Comment 2 Chad Page 2007-07-15 00:54:54 UTC
I've got a proposed fix up but I doubt it's optimal - it looks as if the beginning of the COS/SIN generators (MUL/MOD/MUL) was an attempt to normalize the angles, and I can run the routines fine without those three instructions... I can't quite figure out what the MOD is doing since it's not used anywhere else in the driver and it's not part of the GL spec.
Comment 3 Roland Scheidegger 2007-07-29 10:46:31 UTC
(In reply to comment #2)
> I've got a proposed fix up but I doubt it's optimal - it looks as if the
> beginning of the COS/SIN generators (MUL/MOD/MUL) was an attempt to normalize
> the angles, and I can run the routines fine without those three instructions...
> I can't quite figure out what the MOD is doing since it's not used anywhere
> else in the driver and it's not part of the GL spec.

Yes, those 3 instructions are for range reduction. The header file says A0_MOD is dst = src0 fmod 1.0, so looks like a float modulo 1.0 to me...
Not sure why the code wouldn't work correctly, seems ok at first look (not sure if the MULs you can use instead of the MADs  with the MOD is actually faster, but it saves some constants at least).
Actually, looks not ok at second look... Should be fixed in git. If not reopen.
Comment 4 Adam Jackson 2009-08-24 12:27:21 UTC
Mass version move, cvs -> git


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.