Created attachment 75881 [details] output System Environment: -------------------------- Arch: x86_64 Platform: Ivybridge Libdrm: (master)libdrm-2.4.42-4-g41fc2cc8a98a8d02ea7d3635d3103f7dd371de10 Mesa: (master)0b6e72f8d75a31ef233ad5be0c9f59497880657f Xserver:(master)xorg-server-1.13.99.902-5-g90642948cc78834d95f7a3bddaac7ff77b68ed7e Xf86_video_intel:(master)2.21.3-57-gae3531c3a1d72a73b25c5563b4db029f051262cb Cairo: (master)4f00d2344c84a1017a1e7d76ccb2fa552c80a969 Libva: (staging)5514727e22cc4a3eec6845e61dd87eb7811aff89 Libva_intel_driver:(staging)b3139d1a278d9daac40987f0a99c2a797c0db988 Kernel: (drm-intel-nightly) 15caa9b2bad16e0d4bf8c203dcc8325b1894ad09 Bug detailed description: ------------------------- It fails on ironlake sandybridge ivybridge and haswell with mesa master branch. It works well on 9.1 branch. Following cases also fail and have same bisect commit: accum(basic.add) accum(basic.load) accum(basic.mask) accum(basic.mult) api-texcoord(basic.allCases) dlist(basic.allCases)__1Vis drawpix(basic.colorIndex)__1Vis bitmap-transfer(basic.allCases) pxtrans-cidraw(basic.allCases) texenv(basic.allCases) texgen(basic.allCases) colorsum(basic.allCases) api-mtexcoord(basic.allCases) api-fogcoord(basic.allCases) api-seccolor(basic.allCases) pxtrans-copy(advanced.depthTest.noFbo) pxtrans-copy(advanced.dlists) pxtrans-copy(advanced.extendedTransfers.noFbo) pxtrans-copy(advanced.iterateTypeFormats.pixelMaps.noFbo) pxtrans-copy(advanced.iterateTypeFormats.scaleBias.noFbo) pxtrans-copy(advanced.logicOP.noFbo) pxtrans-copy(advanced.stencilTest.noFbo) pxtrans-copy(basic.pixelMaps.noFbo) pxtrans-copy(basic.scaleBias.noFbo) pxtrans-copy(misc.lights.noFbo) Case bitmap-draw(basic.allCases) aborted and has same bisect commit. Bisect shows:e15c21a957b62ab856ab286e8253dd1151a3386e is the first bad commit. commit e15c21a957b62ab856ab286e8253dd1151a3386e Author: Eric Anholt <eric@anholt.net> AuthorDate: Fri Feb 15 07:41:42 2013 -0800 Commit: Eric Anholt <eric@anholt.net> CommitDate: Fri Mar 1 12:10:16 2013 -0800 i965: Make sRGB-capable framebuffers by default. The GLX extension lets you expose visuals that explicitly guarantee you that the GL_FRAMEBUFFER_SRGB_CAPABLE flag will be set, but we can set the flag even while the visual doesn't provide the guarantee. This appears to be consistent with other implementations, as we've seen several apps now that don't require an srgb visual and assume sRGB will work without checking the GL_FRAMEBUFFER_SRGB_CAPABLE flag. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55783 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60633 Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com> Reproduce steps: ---------------- 1. xinit 2. ./oglconform -suite all -v 2 -test accum basic.accum
There are a ton of small bugs (all in sw fallbacks as far as I can see) all mashed together in this bug report, which is why I haven't started working on any one of them.
closing as won't fix.
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.