Updated wine bugreport with a new screenshot.

Also I found a way to reproduce the problem. I'm attaching a savegame from the game...

Steps to reproduce:
1) Use wine-1.1.0 (that's the version I'm currently using - but I suppose it's also happening with different versions)
2) Install Max Payne demo (version 1.05), link is supplied in the wine bugreport
3) Copy attached savegame to you savegame directory (for me this is "~/Documents/Max Payne Demo Savagames", this may vary though depending how you setup wine)
4) Start game and load savegame
5) Problem should appear immediately

Note however that for me it's now not only the "imfamous colored trousers bug": I managed to get Max entirely affected by the errors.

Greets,
Tobias

PS: Why is there no testcase keyword?

Created attachment 17561 [details]
savegame to reproduce visual artifacts

put into your savegame directory and select from savegame loading menu

This is a fog related problem.

I found out that disabling "fogging" in the game graphic options menu solved the problem. You can see that in the scene from the savegame you end up in an area with lots of steam. The steam doesn't disappear when fogging is off, but maybe some other things are changed.

I can exactly reproduce that. When fog is on and I load the savegame Max has the colorful trousers. When fog is off the problem is not there and I didn't find a way to get the visual artifacts to appear on Max, the bad guys or on anyone else.

Anything I can further do to encircle the source of the problem?

Greets,
Tobias

I was going to try the MesaDemos-7.0.3 but it seems like they won't compile for me (some missing file that is included in the makefile). I dunno how to fix this and if the missing file is crucial at all.

I tested MP with the mesa software renderer (LIBGL_ALWAYS_SOFTWARE=yes), it works with it and shows no visual errors (but is kinda slow).

Greets,
Tobias

News on the bug. Latest wine version (1.1.3) fixes the bug, but probably not the real problem.

The fixing commit between 1.1.2 and 1.1.3 implements a ARB_fp pipeline and it seems that the pipe is used on my Intel i915 after the commit.

So either the other pipe (the one that was used before ARB_fp) is somehow broken or the problem is in the driver itself.

Now that we know that the problem is somewhere in (or caused by) the fragment pipeline it should be easier to figure out the real cause.

Greets,
Tobias

Update and new information:

The bug returns with wine when forcing the use of the ffp_fragment_pipeline, this is the fixed-function variant.

My current tests were all done with the mesa-7.1 release, which still has this bug. However when forcing the use of the Mesa software rasterizer (LIBGL_ALWAYS_SOFTWARE=1) the texture corruptions disappear.

For me this is a strong indication that there is no bug in the ffp_fragment_pipeline implementation of wine, but in the i915 DRI driver.

I then upgraded to the recent pre-release mesa-7.2_rc1 and the appearance of the bug changed. The texture corruption with mesa-7.1 and older versions was always colorful.

Now with mesa-7.2_rc1 the corrupted texture parts are completly white. Some commit between 7.1 and 7.2_rc1 must have changed how the bug operates.

I'm still trying to figure out how to bisect this commit. I would appreciate some help, since I'm trying to avoid using "make install". Maybe some preloading method is best?

Greets,
Tobias

Use the LIBGL_DRIVERS_PATH environment variable to point to location of your in-tree dri driver. And LD_LIBRARY_PATH if you need to specify the in-tree libGL, too.

I can't seem to reproduce the changing behaviour outside of my distro's package manager (gentoo's portage).

When using mesa-7.1, installed through portage, the corruptions are colorful.
When using mesa-7.2_rc, installed through portage, the corruptions are white.

I checked the configure options portage passes for mesa-7.1:
./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --with-driver=dri --disable-ttm-api --enable-glx-tls --with-dri-drivers=,swrast,i810,i915,i965 --disable-asm --disable-glut --without-demos --disable-xcb --disable-debug --disable-glw --disable-motif --build=i686-pc-linux-gnu

The configure options string for mesa-7.2:
./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --with-driver=dri --disable-ttm-api --enable-glx-tls --with-dri-drivers=,swrast,i810,i915,i965 --enable-asm --disable-glut --without-demos --disable-xcb --disable-debug --disable-glw --disable-motif --build=i686-pc-linux-gnu

The only (significant) difference I see there is the use of the asm optimizations.

Furthermore I did this:
Compiled a fresh git clone (mesa-7.2 branch) with only passing the DRI drivers list (swrast and i915, I don't need more) to configure.
That also produced white texture corruptions.

I recheck this, but as far as I can see the asm code seems to cause trouble...

Greets,
Tobias

Summary:

mesa branch: mesa_7_2_branch
last commit: 3dd48d903f85a0e0a01d8b9f4b524b3dec67370b (
document _tnl_InvalidateState() fix)

First run:
./configure --with-driver=dri --disable-ttm-api --enable-glx-tls --with-dri-drivers=i915 --disable-asm --disable-glut --without-demos --disable-xcb --disable-debug --disable-glw --disable-motif && make clean && make && make install

LD_PRELOAD=/usr/local/lib/libGL.so LIBGL_DRIVERS_PATH=/usr/local/lib/dri/ LD_LIBRARY_PATH=/usr/local/lib/ ~/wine-git/wine MaxPayneDemo.exe

Results in colorful texture corruptions.

Second run:
./configure --with-driver=dri --disable-ttm-api --enable-glx-tls --with-dri-drivers=i915 --enable-asm --disable-glut --without-demos --disable-xcb --disable-debug --disable-glw --disable-motif && make clean && make && make install

(same wine call)

Results in white texture corruptions.

What components of mesa do use asm code at all?

Greets,
Tobias

I have experienced this bug (some random-colored triangles with old Mesa, going white with new Mesa) with other 3D applications running on Wine, for instance World of Warcraft. Note that it happens both in emulated Direct3D mode and in plain OpenGL mode for WoW, so the bug is presumably in Mesa. Unfortunately, I haven't found a native application that exhibits this issue yet.

As for your question about which parts of Mesa are using assembly code, these are mostly the matrix-vector transformations, I think. See the src/mesa/x86 directory. Perhaps you could try setting the a combination of the MESA_NO_ASM and MESA_NO_MMX and MESA_NO_3DNOW and MESA_NO_SSE environment variables, just to check if you can reproduce the behavior change without compiling.

I did find a few minutes to check myself: Exporting MESA_NO_SSE changes the behavior from white triangles to random-colored ones.

As a side note, the title of this report is a bit misleading: The textures are not corrupted; It is more like vertex-based lighting gone horribly wrong, as if some random (or white) specular colors were interpolated over the triangles.

I have experimented a bit further and I have now reached the mesa/tnl/t_vertex_sse.c file. In other words, exporting or unsetting the MESA_NO_CODEGEN environment variable decides whether the triangles are randomly colored or bright white in WoW. I will look a bit more at the issue tomorrow now that I know where to look. (Thanks Tobias for noticing the effect of --disable-asm!)

Created attachment 19013 [details] [review]
Fix random/white color overlays.

It seems some part of the Mesa code expects the padding bytes to be set to zero. I haven't been able to find it, but I have at least found where the padding bytes are set to non-zero values. This patch fixes World of Warcraft for me.

Note that the patch modifies only the SSE codegen path. As a consequence, if the generic path is taken, padding bytes will still have random values, hence causing the psychedelic triangles to strike back.

The patch also fixes two other issues I noticed while going through the code. In the generic path, an undefined input value was used for insert_3f_viewport_2. In the SSE codegen path, the EMIT_3UB_3F case was disabled due to a typo.

Hi Guillaume!

Thanks for the patch. I just tried it out and applied it to mesa-7.2_rc1.
Compiled with --enable-asm and tested it with wine-1.1.4

The look of the bug changed again. It's now only visible (sometimes) at the feets of the player. I'm going to attach two screenshots.
All in all the patch lowered the severity of the corruptions.

I also hacked three small patched against wine-1.1.4 so you can reproduce the problem with the Max Payne 1 demo (version 1.05) on your system.

Using wine-1.1.4 without the patches doesn't show the bug because recently a fragment pipeline based on arb_fp was added. This is now used by default when available. The first patch forces the use of OpenGL fixed-function calls.

Uploaded the three patches here:
http://www.math.uni-bielefeld.de/~tjakobi/wine/

The two other patches are for debugging. Patch 2 forces clearing the backbuffer to cyan color, this is good for subframe debugging in wine. However this leads to tiny pixel artifacts in the levels (looking like T-junction errors). Just don't be distracted by the dots that appear, they also appear on Windows with Direct3D runtime libs.

Patch 3 enables subframe dumping to /tmp when /tmp/wine/DUMP exists. With this method I managed to match the wine trace against the (faulty) rendered geometry.
This is also documented in the wine bugreport.

Seems like there is still some work to do to get this right, especially since the non-asm code is still (fully) broken.

Greets,
Tobias

Created attachment 19021 [details]
corruptions after the patch (1)

Bug now only affects the feets of the character.

Created attachment 19022 [details]
corruptions after the patch (2, different color)

I think I have to make my latest post clearer. I didn't say that I fixed the bug, quite the contrary in fact. As I said, I haven't found where Mesa relies on the padding bytes being cleared.

Moreover, my patch doesn't clear all the padding bytes for the SSE code, only the ones that made a difference for WoW. From the point of view of Mesa code, I have only cleared the padding bytes when there are three of some before one single byte of attribute. All the other padding bytes are left with random values. Moreover, these three bytes are only cleared when all the attributes can be handled by the SSE code. If one single attribute can't, no padding bytes will be cleared.

A part of my patch fixed a typo that prevented code for EMIT_3UB from being generated. I guess this code has never been exercised, and as it happens, it is probably wrong. In particular, the "make room for incoming value" comment could be probably state "who cares about the previous values, let's override them" instead (by definition of movss). I doubt it will fix your flashing trousers issue though. But just in case, can you comment out the block from line 515 to 540 in tnl/t_vertex_sse.c? So that the case "3UB + 1UB" fails and goes through the error code.

Anyway, independently and just to be sure your issue is still related to non-zero padding bytes, you can try applying the following patch and running with the environment variable MESA_NO_CODEGEN (so that the generic code is executed instead of the SSE one).

diff --git a/src/mesa/tnl/t_vertex_generic.c b/src/mesa/tnl/t_vertex_generic.c
index c52da25..22324ab 100644
--- a/src/mesa/tnl/t_vertex_generic.c
+++ b/src/mesa/tnl/t_vertex_generic.c
@@ -961,6 +961,7 @@ void _tnl_generic_emit( GLcontext *ctx,
    const GLuint stride = vtx->vertex_size;
    GLuint i, j;
 
+   _mesa_memset(v, 0, stride * count);
    for (i = 0 ; i < count ; i++, v += stride) {
       for (j = 0; j < attr_count; j++) {
         GLfloat *in = (GLfloat *)a[j].inputptr;


PS: Your webserver gives a 403 error.

(In reply to comment #18)
> Anyway, independently and just to be sure your issue is still related to
> non-zero padding bytes, you can try applying the following patch and running
> with the environment variable MESA_NO_CODEGEN (so that the generic code is
> executed instead of the SSE one).
> 
> diff --git a/src/mesa/tnl/t_vertex_generic.c b/src/mesa/tnl/t_vertex_generic.c
> index c52da25..22324ab 100644
> --- a/src/mesa/tnl/t_vertex_generic.c
> +++ b/src/mesa/tnl/t_vertex_generic.c
> @@ -961,6 +961,7 @@ void _tnl_generic_emit( GLcontext *ctx,
>     const GLuint stride = vtx->vertex_size;
>     GLuint i, j;
> 
> +   _mesa_memset(v, 0, stride * count);
>     for (i = 0 ; i < count ; i++, v += stride) {
>        for (j = 0; j < attr_count; j++) {
>          GLfloat *in = (GLfloat *)a[j].inputptr;
> 
OK, I did this first. Reverted your previous patched and only added the memset to t_vertex_generic.c

Compiled with:
./configure --with-driver=dri --disable-ttm-api --enable-glx-tls --with-dri-drivers=i915 --enable-asm --disable-glut --without-demos --disable-xcb --disable-debug --disable-glw --disable-motif

Started wine with MESA_NO_CODEGEN set.
This results in the same visuals your first patch does produce (corruptions only affecting the trousers of the player model in certain viewing angles).

(In reply to comment #18)
> A part of my patch fixed a typo that prevented code for EMIT_3UB from being
> generated. I guess this code has never been exercised, and as it happens, it is
> probably wrong. In particular, the "make room for incoming value" comment could
> be probably state "who cares about the previous values, let's override them"
> instead (by definition of movss). I doubt it will fix your flashing trousers
> issue though. But just in case, can you comment out the block from line 515 to
> 540 in tnl/t_vertex_sse.c? So that the case "3UB + 1UB" fails and goes through
> the error code.
> 
OK, so I removed the memset again and reapplied your patch. Then I commented out the block at the lines you specified.

It looks now like this:
	 else /*if (j < vtx->attr_count - 1 &&
		  a[1].format == EMIT_1UB_1F &&
		  a[1].vertoffset == a->vertoffset + 3) {
	    get_src_ptr(p, srcECX, vtxESI, a);
	    emit_load(p, temp, 3, x86_deref(srcECX), a->inputsize);
	    update_src_ptr(p, srcECX, vtxESI, a);

	    // Make room for incoming value:
	    sse_shufps(&p->func, temp, temp, SHUF(W,X,Y,Z));

	    get_src_ptr(p, srcECX, vtxESI, &a[1]);
	    emit_load(p, temp, 1, x86_deref(srcECX), a[1].inputsize);
	    update_src_ptr(p, srcECX, vtxESI, &a[1]);

	    // Rearrange and possibly do BGR conversion:
	    if (a->format == EMIT_3UB_3F_BGR)
	       sse_shufps(&p->func, temp, temp, SHUF(W,Z,Y,X));
	    else
	       sse_shufps(&p->func, temp, temp, SHUF(Y,Z,W,X));

	    emit_pack_store_4ub(p, dest, temp);
	    j++;		// NOTE: two attrs consumed
	 }
	 else*/ {

I hope this how you meant it.
Recompiled and started wine (this time without MESA_NO_CODEGEN). However commenting out the block doesn't change the visuals. They look like the one with only your first patch applied.
The only difference is the "Can't emit 3ub" message from mesa appearing on the console while playing.

(In reply to comment #18)
> 
> PS: Your webserver gives a 403 error.
> 
Strange, it should work. I tested it just now and I can access and download the patches. Also checked the permissions of the dir and files and they're also correct. Can you try again fetching them?
If that doesn't work I can try uploading it somewhere else (nopaste, pastebin, etc.)

Greets,
Tobias

I further investigated the fogging stuff.

Since disabling the ingame option 'fogging' kinda "fixes" the problem (at least I don't see the corruptions when this is off) I was curious what the engine does differently then.

I hacked the wine source (dlls/wined3d/state.c) and disabled the state_fog function by letting it always disable GL_FOG and then return.

This also makes the corruptions go away.

So there is probably also a problem in the fogging code respectively some of the bug is originating from fogging code. Maybe... :)

Greets,
Tobias

Created attachment 19048 [details] [review]
Fix random-colored / white overlays.

Here is the latest iteration of my patch. It avoids an undefined input value from being used in insert_3f_viewport_2. It clears the vertex buffer beforehand in the hardwired and in the generic case. In the SSE code, it enables the EMIT_3UB_3F code that was disabled by a typo. It fixes the EMIT_1UB_1F case that was duplicating its value over the previous padding bytes. It speeds up the load2F_1 function. It fixes the load3f_* function so that the last component is not a spurious 1 that would be written as a padding byte in the 3UB+PAD1 case. It fixes the 3UB+1UB case by using a second temporary register so that the color contained in the first one is not destroyed while loading the next component.

Unfortunately, I doubt the patch will fix your remaining issue, as it may be somewhere else. (One part of the code is still reading bytes it shouldn't. For now, I have fixed the case where it reads the padding bytes. But if it also reads non padding-bytes or bytes outside the buffer, the same bug will still happen.) You may still give it a go, as now it also clears the buffer in the third path, the hardwired one.

Your bug may not be related to the fog setting, as it may only change the layout of the vertex buffer, hence causing other bytes to be read by the buggy code. But at least it may give us a clue at which specific part of the buffer is affected, and hence which code is using it. Hopefully.

As for your webserver, it now works. I haven't had time to play with it yet though.

Just tested this patch:

For reference I used the mesa-7.2_rc1 compile (with assembler enabled).
With MESA_NO_CODEGEN: Colorful artifacts
Without MESA_NO_CODEGEN: White artifacts, but "light corruptions" (in the sense that they're not so severe) shining through the "white" from some viewing angles.

mesa-7.2 + your latest patch:
With MESA_NO_CODEGEN: Only "light corruptions"
Without MESA_NO_CODEGEN: Only "light corruptions"

So this already fixes a lot of the corruption I get with 7.2_rc1, both with asm and non-asm.

Is there anything else I can test?
And thanks for your help! :)

Greets,
Tobias

*** Bug 17707 has been marked as a duplicate of this bug. ***

I changed the summary to reflect that not only Max Payne 1 is affected by the issues. Current list of games that are affected:
- Max Payne 1 demo (version 1.05) (through wine) (downloadable)
- UT2004 (no further information at the moment about version, etc.)
- World of Warcraft (through wine) (both D3D and OGL mode affected)

I'm not sure if I can get UT2004 to run on my system (too low specs), but there is a demo version available, so other people can test this.

@Jiewen: Any special settings I have to do ingame?

(In reply to comment #24)
> I changed the summary to reflect that not only Max Payne 1 is affected by the
> issues. Current list of games that are affected:
> - Max Payne 1 demo (version 1.05) (through wine) (downloadable)
> - UT2004 (no further information at the moment about version, etc.)
> - World of Warcraft (through wine) (both D3D and OGL mode affected)
> 
> I'm not sure if I can get UT2004 to run on my system (too low specs), but there
> is a demo version available, so other people can test this.
> 
> @Jiewen: Any special settings I have to do ingame?
> 


No, just start the game and play it ,the issue would be saw.

Sorry, but I can't test ut2004. I'm hitting this input bug, which makes it impossible to even get ingame:
https://bugs.freedesktop.org/show_bug.cgi?id=15473

Thanks to Michel Dänzer I can now get ut2004-demo running (Export SDL_VIDEO_X11_DGAMOUSE=0 to fix stuck input).

Like Jiewen said the problem is immediately apparent on the weapon models. For me the weapon appear to have a shiny black textures, something that looks like oil...

I'm now doing my tests with mesa git master, and yes, the issue is still there. Also with Max Payne.

Greets,
Tobias

It is worse with gem-classic now,more black textures,not only weapons.

What's gem-classic?

I further checked the ingame gfx options in the ut2004 demo and found out that the only option that "toggles" the artifacts is "world detail".

Setting it to low kills the corruptions and the weapon model texture is drawn correctly. Setting it to normal or high returns the black tex corruption.

(In reply to comment #29)
> What's gem-classic?

It means mesa with gem (master or intel-2008-q3 branch) while kernel without gem, so it falls into classic mode.

Hi there,

I just managed to install libdrm git master and mesa git master to my university account (using some prefix tricks and LD_LIBRARY_PATH mods) and can now test this with a (glxinfo output):
Mesa DRI Intel(R) Q35 20080716 x86/MMX/SSE2

Sadly the kernel isn't GEM-enabled, so it's only classic mode I can test here. However even here Max Payne is not working correctly. Additionaly to the white/colorful trousers issue after some time a lot of the level texture just turn black.

The bug is still there with mesa git master.

Anybody still working on this one?

I pushed the parts of this patch that weren't related to keeping pad bytes zeroed.  It seems like if something else is using pad bytes, that should be fixed, rather than increasing the overhead of this code.

Is this bug ready to be marked fixed at this point?  There are too many apps and chipsets listed in it, so I wouldn't even be able to test and confirm since it's probably about a whole pile of different issues.

Comment on attachment 19048 [details] [review]
Fix random-colored / white overlays.

marking obsolete as most of the patch is committed.

No, don't close it yet.

I'm going to check later if the issue is still there with ut2004 and Max Payne. However I don't think it's fixed yet. The last time I had ut2004 running the weapon models were still drawn incorrectly.

It could take some time to retest this for Max Payne, since I have to compile a modified wine for that (forcing the fixed function pipeline code, instead of ARBfp).

Report 1: ut2004-demo still suffering from black weapon model issue. Hardware is an Intel i915 chip, driver is mesa git master.

Is ut2004-demo the app you want this bug to be about?  Pick one.

*confused*

The bug is about all three games. Guillaume crafted the patches by checking what effect they had on WoW (OpenGL mode I think). I confirmed (and still can) that the patches also have effect on the Max Payne issue (softening the artifacts, but not removing them completly).
At least here the connection is clearly visible.

I dunno exactly about ut2004-demo, since it was Jiewen who suggested that the black weapon model was also also a result of the problem described here.

I strongly disagree that this bugreport is split. The source of the visuals issues on MP and WoW is most likely the same.
However both apps are non-native. Even worse, MP is D3D only and therefore we also have the wined3d layer between app and OpenGL.

I found it fair to try to also have a native application here. It's probably easier to do debugging there. So Brian, you should ask Jiewen about this - after all the ut2004-demo stuff was his idea ;)

We retested ut2004 on our gm45 and 945gm again, the weapons in it are drawn incorrectly: black on gm45 and colorful mess on 945gm.

Thanks for applying the fixes. I no longer use an Intel chipset; That's why I have been silent on this issue lately. But I will make a last post to summarize what I found at that time.

"When does it happen?" I have experienced the bug with WoW, both in native OpenGL mode and in emulated-by-Wine Direct3D mode. Looking at Tobias' screenshots, I'm sure that the bug he is experiencing with Max Paine is the same. I don't know about UT2004.

"What is the bug?" Some triangles are overlaid with a colored gradient. The behavior is completely deterministic: It's always the same triangles in the same situations that will fail. The vertex colors depend (at least in part) on the values of the padding bytes in the vertex. I experimented that setting the padding bytes to various values forces a deterministic behavior instead of having random vertex colors.

Note that my patches make part of these buggy overlays disappear since they set some of the padding bytes to zero. However, they don't erase all the padding bytes, and they only erase padding bytes inside the vertex buffer, not the ones just before or after the buffer. That may be why it didn't completely fix Max Paine.

Note also that the bug only applies to a few triangles on a given scene. So there may be an additional factor for the issue to be noticeable; Perhaps it only happens when there are too many triangles to display, or only on the triangles of a given OpenGL primitive, or...

"How to fix it?" Find which parts of the driver assume that uninitialized bytes in the vertex buffer are set to zero.

Retested with latest mesa git master and Max Payne, issue is still there.

I had a similar issue with Yo Frankie and fixed it in mesa master. Could you retest it with Max Payne?

Hi,

just retested with patched wine-1.1.11 + Max Payne demo and the graphical errors are gone. Looks like this part of the issue is finally fixed :)

Also did test with ut2004-demo, but the black weapon model issue remains there.

Since the originally reported problem has been fixed, I'm closing this one. Tobias, thanks for tracking this down.
Let's track ut2004 issue in bug#17707.

Mass version move, cvs -> git