This is the issue with the test case not with mesa driver. Test is incorrectly computing the expected result colors when the texture is luminance, luminance alpha or intensity. Similar failures were observed in piglit fbo-alphatest-formats (Bug# 47125).

It happens on ivybridge sandybridge pineview and ironlake with mesa master branch and mesa 8.0 branch.

(In reply to comment #1)
> This is the issue with the test case not with mesa driver. Test is incorrectly
> computing the expected result colors when the texture is luminance, luminance
> alpha or intensity. Similar failures were observed in piglit
> fbo-alphatest-formats (Bug# 47125).

47125 looks like unrelated?

I can verify that lu hua's bisect in comment #1 is correct.  Brian's change is when this started failing for LUMINANCE formats.  I can also report that, with newer Mesa, it fails on many more formats (apparently compressed ones).  That bisects down to this:

a36581ccc06693231011c3fe136207e73191b1ce is the first bad commit
commit a36581ccc06693231011c3fe136207e73191b1ce
Author: Brian Paul <brianp@vmware.com>
Date:   Tue May 1 14:46:04 2012 -0600

    mesa: do more teximage error checking for generic compressed formats

    When glTexImage or glCopyTexImage is called with internalFormat being a
    generic compressed format (like GL_COMPRESSED_RGB) we need to do the same
    error checks as for specific compressed formats.  In particular, check if
    the texture target is compatible with the format.  None of the texture
    compression formats we support so far work with GL_TEXTURE_1D, for example.

    See also https://bugs.freedesktop.org/show_bug.cgi?id=49124

    NOTE: This is a candidate for the 8.0 branch.

Sorry for the delay in following up on this bug. Gordon, that was a typo and probably i wanted to quote Bug# 46679. There is a related commit in piglit tests which defines the correct behavior for getting the texture in luminance and luminance_alpha formats using glGetTexImage(): 

commit 5beed3c6524f7881791eef7172ad2e6d4118f984
Author: Brian Paul <brianp@vmware.com>
Date:   Thu Mar 8 08:15:58 2012 -0700

    getteximage-luminance: test readback of GL_LUMINANCE textures
    
    Test various combinations of getting a luminance texture.
    
    v2: also test reading back an RGBA texture as GL_LUMINANCE with glReadPixels.
    
    See https://bugs.freedesktop.org/show_bug.cgi?id=46679

compute_expected() function in pxconv-gettex computes expected luminace value as follows: L = R + G + B. Which is wrong in case of glGetTexImage().
Brian Paul explained this by a comment in bisected commit:
"If we're reading back an RGB(A) texture as luminance then we need
to return L=tex(R).  Note, that's different from glReadPixels which
returns L=R+G+B."

I guess this explains the cause of failures in LUMINANCE and LUMINANCE_ALPHA formats. pxconv-gettex computes expected luminace values incorrectly.

I will continue investigating the cause of failures in compressed texture formats which are reported by Ken.

Can't find commit 5beed3c6524f7881791 on the latest mesa master branch(commit 1597176f7090eea73f41b3114ae2a02a50ac7a12).
Issue still exists.

This commit (5beed3c) was on piglit (not on mesa master).I quoted this commit to support my investigation of failures in glGetTexImage() with LUMINANCE and LUMINACE_ALPHA formats. It's a bug in pxconv-gettex test case, not in mesa. So, the test case will continue to fail.

Following commit fixes the failures in GL_TEXTURE_1D with generic compressed formats:
commit df2c4cbcedb2dcf2aa44adaa6462d9becccbea49
Author: Anuj Phogat <anuj.phogat@gmail.com>
Date:   Tue Aug 21 11:03:48 2012 -0700

    mesa: Fix generic compressed texture formats' handling in glTexImage /  glCopyTexImage
    
    The generic texture formats should be accepted by the <internalformat>
    parameter of TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and
    CopyTexImage2D functions. When the application specifies a generic
    format, the driver is free to pick an uncompressed format.
    
    This patch reverts the changes due to following commit:
    commit a36581ccc06693231011c3fe136207e73191b1ce
    mesa: do more teximage error checking for generic compressed formats
    
    This patch fixes compressed texture format failures in intel oglconform
    pxconv-gettex test case:
    https://bugs.freedesktop.org/show_bug.cgi?id=47220
    
    Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>

Now, this bug can be marked fixed/resolved.

It still fails on Mesa master(commit:a3d9d7ec79d6f7205fab2324e47d8ea185431de0).

As I explained in my previous comments, this is an issue with the oglconform pxconv-gettex test case not with mesa driver. Test case incorrectly calculates the expected color values. We have to ignore failures related to LUMINANCE and LUMINACE_ALPHA formats in this test case.

I noticed a new bug in mesa drivers while fixing the oglconform pxconv-gettex test case. Failures are observed if getting (glGetTexImage) a RGB(A) compressed texture but returning luminance. We need a fix similar to what Brian posted earlier (f5d0ced) for non-compressed formats. I'll soon post a patch on mailing list for review.

Fixed by commit 9ab8962 on mesa master:

mesa: Fix GL_LUMINANCE handling for textures in glGetTexImage
We need to rebase colors (ex: set G=B=0) when getting GL_LUMINANCE
textures in following cases:
1. If the luminance texture is actually stored as rgba
2. If getting a luminance texture, but returning rgba
3. If getting an rgba texture, but returning luminance

A similar fix was pushed by Brian Paul for uncompressed textures
in commit: f5d0ced.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=47220

Observed no regressions in piglit and ogles2conform due to this fix.
This patch will cause failures in intel oglconform pxconv-gettex,
pxstore-gettex and pxtrans-gettex test cases. The cause of failures
is a bug in test cases. Expected luminance value is calculted
incorrectly in test cases: L = R+G+B.

V2: Set G = 0 when getting a RG texture but returning luminance.

Note: This is a candidate for stable branches.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>

A patch has been sent to fix oglconform test cases.

Since we believe Mesa is fixed and a fix is on the way to the test suite, let's close this again.

Case pxconv-gettex(basic.allCases) fixed on master branch. It still fails on 9.0 branch.

Following cases still fail on master and 9.0 branch.
pxstore-gettex(basic.allCases)
pxtrans-gettex(basic.allCases)
pbo(texImage.1PBOChangeInternalFormat)
pbo(getTexImage.1PBOChangeInternalFormat)

(In reply to comment #14)
> Case pxconv-gettex(basic.allCases) fixed on master branch. It still fails on
> 9.0 branch.
> 
> Following cases still fail on master and 9.0 branch.
> pxstore-gettex(basic.allCases)
> pxtrans-gettex(basic.allCases)
> pbo(texImage.1PBOChangeInternalFormat)
> pbo(getTexImage.1PBOChangeInternalFormat)


pbo(texImage.1PBOChangeInternalFormat) and pbo(getTexImage.1PBOChangeInternalFormat) fixed on master and 9.0 branch.


pxstore-gettex(basic.allCases) and pxtrans-gettex(basic.allCases) fixed on ivybridge, sandybridge and ironlake with mesa master branch, and still fail on mesa 9.0 branch.

pxstore-gettex(basic.allCases) and pxtrans-gettex(basic.allCases) still fail on pineview with mesa master and 9.0 branch.

Cherry-picked to the 9.0 branch: b086d9ced7d3ab07afa008aea0253c75e827f392

It will be available in Mesa 9.0.3.

pxstore-gettex(basic.allCases) and pxtrans-gettex(basic.allCases) still fail on pineview with mesa master and 9.1 branch.

Anuj, do you think the remaining pxstore-gettex(basic.allCases) and pxtrans-gettex(basic.allCases) failures due to test case bug? If so, we can close this.

Gordon, I don't have a pineview system to debug the cause of failure. I might be able to comment if lu can post the log of failures on pineview.

Created attachment 77973 [details]
output

./oglconform -suite all -v 2 -test pxstore-gettex basic.allCases

I looked at the error logs in attachment 77973 [details]. All most all of the failures are due to difference in just alpha values. These differences don't look same as I noticed in other oglconform tests which were not handling GL_LUMINANCE properly for textures in glGetTexImage. More investigations are required to find the cause of failure. I've no immediate plan to debug it on pineview. You might want to open a separate bug for pineview.

I guess oglc on pineview is not so interesting at this point. Let's just stop here.