Bug 42336

Summary:	[bisected Ilk]oglc fbo(renderToTex.1FBOTexBorder) fails on Ironlake
Product:	Mesa	Reporter:	fangxun <xunx.fang>
Component:	Drivers/DRI/i965	Assignee:	Ian Romanick <idr>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	high	CC:	eric
Version:	git
Hardware:	All
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	42993

Description fangxun 2011-10-28 02:42:50 UTC

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

Comment 1 Ian Romanick 2012-01-16 10:35:25 UTC

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.

Comment 2 Eric Anholt 2012-01-26 18:06:44 UTC

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."

Comment 3 Ian Romanick 2012-02-01 10:21:30 UTC

Patch posted to the mesa-dev mailing list.

http://lists.freedesktop.org/archives/mesa-dev/2012-February/018555.html

Comment 4 Ian Romanick 2012-02-03 10:21:25 UTC

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)

Comment 5 fangxun 2012-02-08 01:26:28 UTC

It passes on sandybridge, but still fails on Ironlake.

Comment 6 Ian Romanick 2012-02-08 12:32:00 UTC

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.

Comment 7 Gordon Jin 2012-02-08 16:43:53 UTC

(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.

Comment 8 Ian Romanick 2012-02-09 14:59:48 UTC

(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.

Comment 9 fangxun 2012-03-14 21:40:34 UTC

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.