【Modify】 This error only exists on IVB .not HuronRiver.
【Update】 This error just exists on gnome-session with compiz, without compiz, it works well. 
(In reply to comment #0)
> Created an attachment (id=51741) [details]
> Photo for this screen mess
> 
> System Environment:
> --------------------------
> Libdrm:        (master)2.4.26-11-gc82ef03e4c92017bf5644f294ea04e30500f8d4c
>  Mesa:        (master)b095b683f8451b54cca52593dc331f82844c9c30 
>  Xf86_video_intel:(master)2.16.0-93-g6395894ada6b9c14deb62814ccf55848eaa80527
>  Cairo:        (master)82a7eac1de6a9f6896e382e55b2061cd17bf4dd6
>  Libva:        (master)a10fda6e3dcddcebaa9b2f61f194211548f7f9b9
>  Kernel:    (drm-intel-next) 64a742fac3a22f57303d8f1b7e347350a1c48254
> 
> 
> Bug detailed description:
> -------------------------
> Screen mess when running glbenchmark/PRO.It contains a series of demoes when
> runnig PRO.Pls see attached photo.
> It exists only on HuronRiver.
> 
> 
> Reproduce steps:
> -------------------------
> 1.xinit&
> 2.sh glbenchmark.sh

Sorry , update is wrong, Without compiz.,it also has this problem.
(In reply to comment #1)
> 【Update】 This error just exists on gnome-session with compiz, without compiz,

Excellent, thanks for the report.  I'm pretty certain this is due to variable indexing of arrays (and possibly pull constants) not working due to broken Gen7 data port code.  I'm planning on fixing that shortly; hopefully that'll fix this.

Assigned.

Sadly, my Data Port fixes don't seem to have fixed this.

I did notice that:
- it works on Sandybridge
- it works on Ivybridge with the old VS backend (INTEL_OLD_VS=1)

So it's something with the new VS backend on IVB.

Thanks to Carl's awesome work on apitrace trimming, I've managed to create a 2MB apitrace file that only draws the character and only has two shader programs.

No solution yet, but at least I've managed to narrow down the problem a lot.  Current theory (from Ian) is variable indexing.

Fixed in Mesa master.

commit 2e712e41db0c0676e9f30fc73172c0e8de8d84d4
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Wed Jan 18 04:53:40 2012 -0800

    i965/vs: Take attributes into account when deciding urb_entry_size.
    
    Both the VF and VS share space in the URB.  First, the VF stores
    attributes (shader inputs) there.  The VS then reads the attributes,
    executes, and reuses the space to store varyings (shader outputs).
    
    Thus, we need to calculate the amount of URB space necessary for inputs,
    outputs, and pick whichever is greater.
    
    The old VS backend correctly did this (brw_vs_emit.c:408), but the new
    VS backend only considered outputs.
    
    Fixes vertex scrambling in GLBenchmark PRO on Ivybridge.
    
    NOTE: This is a candidate for the 8.0 branch.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41318
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Eric Anholt <eric@anholt.net>

Hi Kenneth, I just use that mesa commit to test the case, but the bug still exists on my machine.

Are you testing on a GT1 or GT2?  It works fine on my GT2...

Chao, can you confirm this still exists on our GT2 machine (like x-ivb12), or just GT1 (x-ivb3)?

Note you need use mesa master.

(In reply to comment #9)
> Chao, can you confirm this still exists on our GT2 machine (like x-ivb12), or
> just GT1 (x-ivb3)?
> Note you need use mesa master.

this bug still exists on GT2 machine. 
My mesa commit is: (master)32b07bb1496f5772ca16e719bb87e1702ceff196

commit 2b4afdba05abe3408f6347be82465b6420f50aab
Author: St茅phane Marchesin <marcheu@chromium.org>
Date:   Wed Jan 18 19:23:48 2012 -0800

I cannot reproduce this anymore with latest mesa 8.0 branch on IVB GT2.

It's also fixed on my machine.

I tested this issue today and found It's fixed on the latest environment:
Kernel_version:		2.6.31.12
Libdrm:		(master)2.4.30-18-gb643b0713aefdc0611e47654e88263b53b0de6f5
Mesa:		(master)f9f8ce3ead04b5334bb323c37ec1f905ca5f58b2
Xserver:		(master)xorg-server-1.11.99.902

(In reply to comment #13)
> I tested this issue today and found It's fixed on the latest environment:
> Kernel_version:        2.6.31.12
> Libdrm:        (master)2.4.30-18-gb643b0713aefdc0611e47654e88263b53b0de6f5
> Mesa:        (master)f9f8ce3ead04b5334bb323c37ec1f905ca5f58b2

Please verify with 8.0 branch.

Hi, Gordon ,on 8.0 branch the issue is still exist.

The 8.0 branch:
Libdrm:		(master)2.4.30-19-g592ac67626f6d69bd8b518a33e80e9c4d223eba2
Mesa:		(8.0)5f60d134e68775d00afca062eec42838e7888358
Xserver:		(server-1.11-branch)xorg-server-1.11.3

This issue has also been resolved on 8.0 branch now. My tested environment :

Kernel_version:		2.6.31.12
Libdrm:		(master)2.4.30-19-g592ac67626f6d69bd8b518a33e80e9c4d223eba2
Mesa:		(8.0)5f60d134e68775d00afca062eec42838e7888358
Xserver:		(server-1.11-branch)xorg-server-1.11.3