From: <bug...@fr...> - 2008-06-25 16:51:35
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 Summary: [i915] texture corruption in wine / Max Payne demo Product: Mesa Version: CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri...@li... ReportedBy: liq...@gm... problem: rainbow color like texture artifacts on some game character models (Max Payne demo through wine). Bugreport already posted on wine bugtracker: http://bugs.winehq.org/show_bug.cgi?id=14121 Screenshots are attached there. Corruption not static, changes ramdomly - most of the time Max's trousers are affected, sometimes his weapon. Didn't see the upper part of his body affected though. libdrm, DRM kernel module and mesa are up-to-date (GIT snapshot from today). Hardware is Intel i915 (lspci): 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) uname -a: Linux leena 2.6.25-gentoo-r5 #1 PREEMPT Thu Jun 19 20:27:19 CEST 2008 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux Thanks, Tobias -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-07-07 08:59:45
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #1 from Tobias Jakobi <liq...@gm...> 2008-07-07 01:59:41 PST --- 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? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-07-07 09:01:20
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #2 from Tobias Jakobi <liq...@gm...> 2008-07-07 02:01:13 PST --- Created an attachment (id=17561) --> (http://bugs.freedesktop.org/attachment.cgi?id=17561) savegame to reproduce visual artifacts put into your savegame directory and select from savegame loading menu -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-07-09 16:29:04
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #3 from Tobias Jakobi <liq...@gm...> 2008-07-09 09:28:59 PST --- 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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-07-11 14:37:18
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #4 from Tobias Jakobi <liq...@gm...> 2008-07-11 07:37:15 PST --- 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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-03 01:18:04
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #5 from Tobias Jakobi <liq...@gm...> 2008-09-02 18:17:59 PST --- 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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-18 17:47:38
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #6 from Tobias Jakobi <liq...@gm...> 2008-09-18 17:47:33 PST --- 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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-18 18:58:37
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #7 from Dan Nicholson <dbn...@gm...> 2008-09-18 18:57:32 PST --- 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. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-18 19:02:51
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #8 from Tobias Jakobi <liq...@gm...> 2008-09-18 18:59:30 PST --- 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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-18 19:27:15
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #9 from Tobias Jakobi <liq...@gm...> 2008-09-18 19:27:13 PST --- 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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-18 22:49:26
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #10 from Guillaume Melquiond <gui...@gm...> 2008-09-18 22:49:20 PST --- 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. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-19 00:06:26
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 Guillaume Melquiond <gui...@gm...> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gui...@gm... | |m --- Comment #11 from Guillaume Melquiond <gui...@gm...> 2008-09-19 00:06:21 PST --- 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. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-20 08:46:37
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #18 from Guillaume Melquiond <gui...@gm...> 2008-09-20 01:29:42 PST --- 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. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-20 18:07:11
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #19 from Tobias Jakobi <liq...@gm...> 2008-09-20 11:06:47 PST --- (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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-21 02:44:01
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #20 from Tobias Jakobi <liq...@gm...> 2008-09-20 19:43:42 PST --- 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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-21 07:43:43
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 Guillaume Melquiond <gui...@gm...> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #19013|0 |1 is obsolete| | --- Comment #21 from Guillaume Melquiond <gui...@gm...> 2008-09-21 00:42:44 PST --- Created an attachment (id=19048) --> (http://bugs.freedesktop.org/attachment.cgi?id=19048) 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. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-21 16:46:01
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #22 from Tobias Jakobi <liq...@gm...> 2008-09-21 09:45:55 PST --- 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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-22 09:23:42
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 Gordon Jin <gor...@in...> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jie...@in... --- Comment #23 from Gordon Jin <gor...@in...> 2008-09-22 02:23:35 PST --- *** Bug 17707 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-22 15:24:57
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 Tobias Jakobi <liq...@gm...> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[i915] texture corruption in|[i915 i945 i965] tex |wine / Max Payne demo |corruption with Max Payne / | |ut2004 / WoW --- Comment #24 from Tobias Jakobi <liq...@gm...> 2008-09-22 08:24:47 PST --- 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? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-23 01:29:07
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #25 from lin, jiewen <jie...@in...> 2008-09-22 18:28:54 PST --- (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. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-23 21:16:49
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #26 from Tobias Jakobi <liq...@gm...> 2008-09-23 14:16:37 PST --- 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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-24 16:45:48
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #27 from Tobias Jakobi <liq...@gm...> 2008-09-24 09:44:24 PST --- 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 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-25 08:50:41
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #28 from lin, jiewen <jie...@in...> 2008-09-25 01:44:09 PST --- It is worse with gem-classic now,more black textures,not only weapons. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-28 21:02:13
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #29 from Tobias Jakobi <liq...@gm...> 2008-09-28 14:02:00 PST --- 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. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
From: <bug...@fr...> - 2008-09-29 10:06:08
|
http://bugs.freedesktop.org/show_bug.cgi?id=16520 --- Comment #30 from Gordon Jin <gor...@in...> 2008-09-29 03:06:00 PST --- (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. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |