System Environment: -------------------------- Arch: i386 Platform: huronriver Libdrm: (master)2.4.26-18-gcc088f1721eaa5f8f1ba1932723882f92e34c39a Mesa: (master)27de26073b0ab385e57504d77197a33bb7b6c28f Xserver:(master)xorg-server-1.11.0-193-gfb84be47db7cdaff406792c08e34670e8e0cbda9 Xf86_video_intel: (master)2.16.0-205-ga18f559961135fa288dda3b94207abb0b6d4d302 Kernel: (drm-intel-next)64a742fac3a22f57303d8f1b7e347350a1c48254 Bug detailed description: ------------------------- It fails on sandybridge and piketon. Bisect shows the first bad commit is 96db07e28c165610b809a9fd88410a82a24a893e. commit 96db07e28c165610b809a9fd88410a82a24a893e Author: Eric Anholt <eric@anholt.net> AuthorDate: Mon Oct 17 14:34:52 2011 -0700 Commit: Eric Anholt <eric@anholt.net> CommitDate: Wed Oct 26 12:42:23 2011 -0700 intel: Enable stripping of texture borders. This replaces software rendering of textures with the deprecated 1-pixel border (which is always bad, since mipmapping is rather broken in swrast, and GLSL 1.30 is unsupported) with hardware rendering that just pretends there was never a border (so you have potential seams on apps that actually intentionally used the 1-pixel borders, but correct rendering otherwise). This doesn't regress any piglit tests on gen6 (since the texwrap border/bordercolor cases already failed due to broken border color handling), but regresses texwrap border cases on original gen4 since those end up sampling the border color instead of the border pixels. It's a small price to pay for not thinking about texture borders any more. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Brian Paul <brianp@vmware.com> Reproduce steps: ---------------- 1. start X 2. ./oglconform -z -s -suite all -v 2 -D 115 -test fbo renderToTex.1FBOTexBorder
We'll want to look at the exact nature of the failure, but I don't think we care. This involves texture border, and texture borders have never really been supported by our hardware. In addition, texture borders were removed in OpenGL 3.1 and OpenGL ES 2.0. Rendering to a texture with a border should probably generate GL_FRAMEBUFFER_UNSUPPORTED.
idr: We don't consider border-enabled textures incomplete, so we also consider border-enabled FBOs complete. It doesn't seem inconsistent to me, and I'd mark this as "yeah, we acknowledge this and don't plan to change it."
Patch posted to the mesa-dev mailing list. http://lists.freedesktop.org/archives/mesa-dev/2012-February/018555.html
Fixed on 8.0 branch by: commit 65b500857ef9ab8b6bd16bc80e7c9cc869f35750 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Wed Feb 1 10:18:13 2012 -0700 intel: FBOs with texture border are unsupported FBOs differ from textures in a significant way. With textures, we can strip the border and get correct rendering except when the application fetches texels outside [0,1]. With an FBO, the pixel at (0,0) is in the border. The ARB_framebuffer_object spec says: "If the attached image is a texture image, then the window coordinates (x[w], y[w]) correspond to the texel (i, j, k), from figure 3.10 as follows: i = (x[w] - b) j = (y[w] - b) k = (layer - b) where <b> is the texture image's border width..." Since the border doesn't exist, we can never render any pixels in the correct location. Just mark these FBOs FRAMEBUFFER_UNSUPPORTED. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42336 (cherry picked from commit 87b4c9b322dabeba7c9a9d02e9efefd2c89e6625)
It passes on sandybridge, but still fails on Ironlake.
The test passes on SNB and GM45, but it fails on ILK. I'm inclined to believe this is another case of the infamous ILK border color bug (see bug #28942). Based on that, I'm going to reclose it. Also, this test appears to have the problem of expecting an alpha value other than 1.0 from visuals that lack an alpha channel.
(In reply to comment #6) > The test passes on SNB and GM45, but it fails on ILK. I'm inclined to believe > this is another case of the infamous ILK border color bug (see bug #28942). Are you sure about the bug number? It's a telepathy bug.
(In reply to comment #7) > (In reply to comment #6) > > The test passes on SNB and GM45, but it fails on ILK. I'm inclined to believe > > this is another case of the infamous ILK border color bug (see bug #28942). > > Are you sure about the bug number? It's a telepathy bug. Bug #28924. I got the last two digits backwards. Sorry.
Verified it on Ironlake.
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.