Escalated to Bugzilla from IssueTracker
Event posted on 18-06-2009 11:38am IST by spoyarek Description of problem: Base OS: RHEL-5.3 The matrix inversion function (__gluInvertMatrixd) in mesa-glu has an error, which leads to incorrect result with gluUnProject(). This is affecting a customer. Upstream bugzilla for the same: http://bugs.freedesktop.org/show_bug.cgi?id=6748 How reproducible: Always. Steps to Reproduce: 1) Untar test case 2) Use the compileMe script to build test case 3) Execute test case Actual results: read z-buffer:0.795453 Expected results: read z-buffer:0.795455 Additional info: This was fixed upstream in two attempts: http://cgit.freedesktop.org/mesa/mesa/commit/?id=f0a036bad91d5f281f8007e8cddefb3f648f1684 http://cgit.freedesktop.org/mesa/mesa/commit/?id=c2e1ee08b083638a7306e15ca48e9ea516d42dc4 Attached is a patch that combines the two. Customer has confirmed that the fix works for him. This event sent from IssueTracker by rkhadgar [Support Engineering Group] issue 308615
Event posted on 18-06-2009 11:53am IST by spoyarek The reason for second attempt: http://bugs.freedesktop.org/show_bug.cgi?id=12269 Issue escalated to Support Engineering Group by: spoyarek. spoyarek assigned to issue for Production Support (Pune). Category set to: Applications::Bug Fix Internal Status set to 'Waiting on SEG' Status set to: Waiting on Tech This event sent from IssueTracker by rkhadgar [Support Engineering Group] issue 308615
Created attachment 349637 [details] patch based on upstream code thanks to Siddesh for locating this patch.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
3564086 build (dist-5E-qu-candidate, /cvs/dist:rpms/mesa/RHEL-5:mesa-6_5_1-7_9_el5) completed successfully MODIFIED
I followed steps to reproduce and verification failed for me, I compiled the test case from attachment and run it on: # rpm -qa | egrep "mesa|freeglut" freeglut-2.4.0-7.1.el5 mesa-libGL-devel-6.5.1-7.10.el5 mesa-libGL-6.5.1-7.10.el5 mesa-libGLU-6.5.1-7.10.el5 freeglut-2.4.0-7.1.el5 mesa-source-6.5.1-7.10.el5 freeglut-devel-2.4.0-7.1.el5 mesa-libGLU-6.5.1-7.10.el5 mesa-libGLU-devel-6.5.1-7.10.el5 freeglut-devel-2.4.0-7.1.el5 mesa-libGL-6.5.1-7.10.el5 mesa-libGLU-devel-6.5.1-7.10.el5 and result: # ./gluUnProject.nvidia freeglut (./gluUnProject.nvidia): Unable to create direct context rendering for window './gluUnProject.nvidia' This may hurt performance. ./gluUnProject.nvidia - demonstrates use of matrix modes and stacks Escape Key - exit the program read z-buffer:0.795453 read z-buffer:0.795453
I'm seeing the same thing. It's not clear to me whether this means that the fix isn't working as expected or that the reproducer isn't as valid as expected. Ajax: any insights here?
No idea honestly. Possibly this varies by architecture, or based on whether you build with -ffast-math. But that's kind of reaching.
ok .. so this is what I observed: old mesa/new mesa intel: 0.795455/0.795455 nv: 0.795453/0.795453 radeon: 0.795453/0.795453 nvidia 180.44 (this is what customer used) 0.795455/0.795455 nvidia 290.10 (newest one) 0.795455/0.795455 this looks like we are not affected by this bug anymore so here comes the question if we need the patch or it should be reverted. -ffast-math is not changing anything. Going to move to 5.3 to see if I can reproduce the issue there. I am using 01:00.0 VGA compatible controller [0300]: nVidia Corporation NV41 [Quadro FX 3450/4000 SDI] [10de:00cd] (rev a2) Will try to write another reproducer using __gluInvertMatrixd function with values from https://bugs.freedesktop.org/show_bug.cgi?id=6748#c7 for example.. this should tell us if matrix inversion was done correctly or not. Stay tuned...
Created attachment 559055 [details] old/new functions comparison I've written reproducer that uses old and new code and comparing results with http://www.bluebit.gr/matrix-calculator/default.aspx results as we can see there is a difference in cell [0][0] so I suspect that the previous reproducer is not valid as it counts the same values all the time. I think this verification is sufficient. -> VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0288.html