Created attachment 43718 [details]
Intel Corporation Arrandale Integrated Graphics Controller
libdrm, mesa and xf86-video-intel git master
More quake4 problems.
Linux demo can be found here:
medium quality settings
Attached screenshots illustrate the problems with the skybox rendering.
Problem not present on r600g with my Radeon HD4750.
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
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:
What Intel graphics card are you using.
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.
is introduced by the commit
still present in git.
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;
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?
Author: Kenneth Graunke <firstname.lastname@example.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.
Signed-off-by: Kenneth Graunke <email@example.com>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.