System Environment: -------------------------- Arch: i386 Platform: Sandybridge Libdrm: (master)libdrm-2.4.41-3-g303ca37e722e68900cb7eb43ddbef8069b0c711b Mesa: (master)85c2e99039394292474b1a84e3dcb2fee30a0836 Xserver: (master)xorg-server-1.13.99.901-36-g70b127c9f1c53bdb42f078265e67f76b464deae2 Xf86_video_intel:(master)2.20.19-14-g10f549332e315cfe2cc86aadab94a95ae6757c34 Cairo: (master)ed2fa6b16b03fccc3e21598cdb9157cbcebd1d37 Libva: (staging)21649988d6b532cc96f633db017d1e4369f640e9 Libva_intel_driver:(staging)d206b47a6ac86c089149ecd71b01eea6ebda5796 Kernel: (drm-intel-nightly) 418ccc855c65e0e90f81012bbc34de20b9f45cbd Bug detailed description: ------------------------- It fails on pineview ironlake sandybridge and ivybridge with mesa master branch. It works well on mesa 9.0 branch. Following cases also fail and have same bisect commit: glx_glx-multithread-makecurrent-2 glx_glx-multithread-makecurrent-3 glx_glx-multithread-makecurrent-4 Bisect shows:75b7e1df139676f2456fea4d3a57cf0044d8409e is the first bad commit. commit 75b7e1df139676f2456fea4d3a57cf0044d8409e Author: Ian Romanick <ian.d.romanick@intel.com> AuthorDate: Sun Jan 20 20:39:54 2013 -0500 Commit: Ian Romanick <ian.d.romanick@intel.com> CommitDate: Mon Jan 21 13:34:34 2013 -0500 intel: Don't expose XRGB8888 visuals any more There really isn't any point. There is no resource savings, and we have to do gymnastics in the driver to make it work. There are also bad interactions with multisampling and OpenGL ES 3.0. In ES3, a multisample-to-singlesample blit must have identical source and destination format. This means a multisample RGBA8 to singlesample RGB8 (window) blit will generate an error. Also in ES3, RGB8 is not a renderable format. This means that the application CANNOT make an RGB8 multisample renderbuffer. As a result, if an application gets an RGB8 window and wants to do multisample FBO rendering, it will probably break. "Fixes" gles3conform framebuffer_blit_functionality_multisampled_to_singlesampled_blit test on RGB8 visuals. v2: Fix 'formats' array size. Suggested by Ken. output: Probe at (10,10) Expected: 0.000000 1.000000 0.000000 1.000000 Observed: 0.000000 1.000000 0.000000 0.000000 Probe at (30,10) Expected: 0.000000 0.000000 1.000000 1.000000 Observed: 0.000000 0.000000 1.000000 0.000000 Probe at (50,10) Expected: 0.000000 1.000000 0.000000 1.000000 Observed: 0.000000 1.000000 0.000000 0.000000 PIGLIT: {'result': 'fail' } Reproduce steps: ---------------- 1. xinit 2. ./bin/glx-multithread-makecurrent-1 -auto
The tests are actually broken. They draw 0.0 to the alpha buffer, but expect to read 1.0 back. When the test gets an RGB visual, this happens to work. Patches will be sent to the piglit list soon.
Fixed by piglit commit: commit 7a1892c8b0bcb83a8bd792ecd48046dc6e905441 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Mon Jan 28 15:33:26 2013 -0800 glx-multithread-makecurrent-*: Write the expected value for alpha The tests would previously write 0.0 to the alpha and expect to read 1.0 back. If the test got a visual without alpha (and it doesn't request alpha), this would happen to work. However, drivers are not required to expose visuals without alpha, so the test might get an RGBA visual afterall. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59738 Reviewed-by: Brian Paul <brianp@vmware.com>
Verified it on mesa master and 9.1 branch with latest piglit.
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.