Tobias, is this a recent regression (i.e. from my vbuf changes) or should I punt it to mesa? If you can identify it as a regression a bisection would be most valuable.

No, like the random polygon error this one was also present before your patchset.

Reconfirming with latest mesa git master (08d1c91e6c185a186e49189b7ed48629f35a4659)

Unigine Tropics Benchmark also has this bug.

Reconfirming with latest mesa git master
(339544f4bbef9be1b4b3465f28482b9699a99692)

This problem is not present on Intel GMA 4500. Quake 4 is not suffering from this bug on Intel GMA 4500.

Intel GMA 4500 rather has this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=36374

What Intel graphics card are you using.

Ubuntu 10.10
Linux 2.6.38-02063807-generic
libdrm 2.4.24
Xserver 1.9.3
xf86-video-intel 2.14.0
Mesa 7.11-devel mesa-ef59049c5242a1be7fa59a182d342191185dd62b

Read the report before posting. Your bug #36374 is unrelated, since it was (according to your bisect) introduced by Chris Wilson's patchset in February.

As I already pointed out in comment #2 this bug is not related to the patchset and was already present long before.

(In reply to comment #1)
> Tobias, is this a recent regression (i.e. from my vbuf changes) or should I
> punt it to mesa? If you can identify it as a regression a bisection would be
> most valuable.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=36374

is introduced by the commit

559435d9152acc7162e4e60aae6591c7c6c8274b

http://cgit.freedesktop.org/mesa/mesa/commit/?id=559435d9152acc7162e4e60aae6591c7c6c8274b

still present in git.

Thank you

Issue is still present with uptodate mesa git master (7ed1826e2e2a5b5c4840821c92ef7273efe32e24).

Issue is still present with recent mesa git master (120d71a45cfda1edfa8cd6b1732e209eb98b53d8).

Looks like cubemaps are getting layed out incorrectly when using S3 texture compression.  (In particular, Quake 4's skybox appears to be using DXT1.)  I can now reproduce the issue and shift the cube faces around, I'm just not sure how to adjust the formulas to get the proper result yet.

If that's related to texture compression, then it makes sense why it also happens with FEAR. The Jupiter engine also seems to make full use of texture compression (before s3tc support was introduced in r600g no textures worked).

Yep, it's definitely a S3TC cubemap layout issue.

If you change src/mesa/drivers/dri/i965/brw_tex_layout.c:52 from
          GLuint align_h = 2;
to
          GLuint align_h = mt->compressed ? 4 : 2;

then Quake 4 works.  But, from my reading of the documentation, I don't quite buy that this is the correct/complete solution.  Feel free to use that as a workaround in the meantime while we come up with the final solution.

I can verify that this also fixes the skybox problems in FEAR. It also eliminates some additional issues I had with lighting sources in FEAR (seems like these also used cubemaps to achieve effects).

Issue is still present with latest mesa git master (82fff5f3edfd2f6396a872a12d753b2ab90edd7b).
But I think I've seem a (proper?) patch by Kenneth for this issue on the mailing list. Wonder why it still hasn't surfaced in master?

commit 477b74e85be8e468c63af9f2f3fe788e486764ce
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Mon Aug 15 12:04:37 2011 -0700

    i965: Use proper texture alignment units for cubemaps on Gen5+.
    
    In particular, S3TC compressed textures need align_h == 4.
    
    Fixes skybox errors in Quake 4 and FEAR.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34628
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

Thanks Kenneth!