[Bug 15644] New: Morrowind: Waterplane/sprite flickering with ORM=fbo
http://bugs.winehq.org/show_bug.cgi?id=15644 Summary: Morrowind: Waterplane/sprite flickering with ORM=fbo Product: Wine Version: 1.1.4 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: liquid.acid(a)gmx.net Hi there, this is a regression introduces between wine-1.1.3 and wine-1.1.4 It affects Morrowind version 1.2.0722, when OffscreenRenderingMode is set to fbo. GLSL settings don't seem to have any effect on the issue. Console output doesn't seem to be related to the problem. I get a lot of those though on my Nvidia NV35: fixme:d3d_shader:shader_glsl_deselect_depth_blt >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glUseProgramObjectARB @ glsl_shader.c / 3450 I'm currently bisecting and these msgs also appear when the state is good, so they're probably not really related. How does the issue look like: The Waterplane (pixel shader water is on) and the sprites flicker a lot when moving through the terrain. Sprites also does include parts of the trees and e.g. lillies in the various pools outside of Seyda Neen. Interesting observation: When pressing ESC, which does bring up the ingame menu (Save, Load, Exit - you get the idea) the graphics are perfect. Always. Posting bisect info later. Greets, Tobias -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hverbeet(a)gmail.com --- Comment #1 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-16 19:14:56 --- d37c6fc0a94b3ac3b4cce58afeafbdf225107b80 is first bad commit commit d37c6fc0a94b3ac3b4cce58afeafbdf225107b80 Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Wed Sep 3 16:25:44 2008 +0200 wined3d: Depth stencil tracking depends on the value of This->render_offscreen. :040000 040000 3541a357c05d4e97e4f89f84ccb25b94dcfbf717 2e7eabd89f0ace15bc99bb13a3e7247ccb2bf56a M dlls URL: http://source.winehq.org/git/wine.git/?a=commit;h=d37c6fc0a94b3ac3b4cce58afe... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #2 from Austin English <austinenglish(a)gmail.com> 2008-10-16 21:44:07 --- A +d3d,+d3d_draw trace would help. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 H. Verbeet <hverbeet(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|hverbeet(a)gmail.com | --- Comment #3 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-17 01:47:51 --- I don't have the game, I'm afraid. Could you figure out where/why the GL error is generated? It might not be the cause of the problem, but it would be nice to eliminate it, for a start. Does the isInDraw flag have any effect on the behaviour? Please make sure that reverting the patch fixes the issue in current git. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #4 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-17 01:50:45 --- Created an attachment (id=16696) --> (http://bugs.winehq.org/attachment.cgi?id=16696) patch Does this patch make any difference? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #5 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-17 02:52:00 --- (In reply to comment #2)
A +d3d,+d3d_draw trace would help. I can do this later.
(In reply to comment #3)
I don't have the game, I'm afraid. Could you figure out where/why the GL error is generated? You mean by using a debugger and dumping the callstack, or something like that?
It might not be the cause of the problem, but it would be nice to eliminate it, for a start. The thing is that this message is not only generated with Morrowind, but also e.g. with Max Payne 2 or F.E.A.R. I also see a lot of FBO issues there, but nothing like this flickering problem.
Does the isInDraw flag have any effect on the behaviour? Please make sure that reverting the patch fixes the issue in current git. Will do! (but also later)
(In reply to comment #4)
Created an attachment (id=16696) --> (http://bugs.winehq.org/attachment.cgi?id=16696) [details] patch
Does this patch make any difference? Going to check later.
Greets, Tobias -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #6 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-17 03:19:06 --- (In reply to comment #5)
(In reply to comment #3)
I don't have the game, I'm afraid. Could you figure out where/why the GL error is generated? You mean by using a debugger and dumping the callstack, or something like that?
checkGLcall() is just a wrapper around glGetError(). That means it will dump any GL errors generated since the last time checkGLcall() was called. So while the error could be caused by the glUseProgramObjectARB() call, it's rather unlikely. shader_glsl_deselect_depth_blt() is called from depth_blt() in drawprim.c. depth_blt() is called from surface_load_ds_location() in surface.c, but is preceeded by a checkGLcall() in both cases, so the GL call that generates the error happens somewhere between the start and end of depth_blt(). Just adding a few more checkGLcall()'s to depth_blt() should be enough to narrow it down to a specific call. Note that the error could also be generated by shader_glsl_select_depth_blt() though, since that's called by depth_blt(). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Jan Buecken <jb.faq(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jb.faq(a)gmx.de --- Comment #7 from Jan Buecken <jb.faq(a)gmx.de> 2008-10-17 06:22:50 --- (In reply to comment #4)
Created an attachment (id=16696) --> (http://bugs.winehq.org/attachment.cgi?id=16696) [details] patch
Does this patch make any difference?
no, not for me and git 30-45 min ago on ati -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #8 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-17 14:29:19 --- OK, just tried the patch and it does indeed change something. The waterplane and sprites are now gone completly when looking straight forward. One way to bring them back (again flickering) is to look at the ground. The 'open menu' technique still works and all looks good there. Patch was applied on top of latest git master. Next: Attaching trace like Austin English proposed (for this I'm going to remove the patch again). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #9 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-17 15:49:17 --- d3d, d3d_draw trace of Morrowind: http://www.math.uni-bielefeld.de/~tjakobi/wine/morrowind_debug.log.bz2 Had to bzip2 this log, because it go rather huge. Shows again that the engine sucks (uses too much API calls). Note that I couldn't reproduce the flickering while the trace logging was on (the game was really slow with it). Instead of flickering the waterplane and sprites were never rendered at all (even not when looking at the ground). The 'game menu' technique again worked here again. Greets, Tobias -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #10 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-17 16:59:46 --- Bisection verification: Reverting the commit on top of current git master produces the same behaviour like the patch by Henri. Checking out the tree with latest commit d37c6fc0a94b3ac3b4cce58afeafbdf225107b80 produces: Issue there! Reverting the commit on top of that: Issue gone! So something happens between d37c6fc0a94b3ac3b4cce58afeafbdf225107b80 and git master tip that changes behaviour of the code in such a way, that reverting the commit does not fix the problem. Next thing: Check isInDraw flag and the GL error, that is produced. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #11 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-18 08:27:26 --- Hi there, I have sort of isolated the problem. It's the glBindTexture(GL_TEXTURE_2D, texture) call in depth_blt that fails. According to the OpenGL reference there are two possible ways to trigger such a failure: (i) GL_INVALID_OPERATION is generated if texture was previously created with a target that doesn't match that of target. (ii) GL_INVALID_OPERATION is generated if glBindTexture is executed between the execution of glBegin and the corresponding execution of glEnd. I highly doubt that (ii) is the cause, since that would also cause some other OpenGL calls to fail as well. Leaves us with (i). I'm currently trying to figure out if GL_TEXTURE_2D is not always the correct target to use with the supplied texture id. Note that (as Henri stated) the depth_blt function gets called from surface_load_ds_location. There are two calls there, only the second one (the "Copying depth texture to onscreen depth buffer" one) fails. The other one doesn't seem to cause any trouble. Major difference: The first one is called with device->depth_blt_texture as texture id, the second one with This->glDescription.textureName. AFAIK we can be sure that device->depth_blt_texture has a 2D target if it has been created inside surface_load_ds_location by the glGenTextures(1, &device->depth_blt_texture) call. That's because the first target where a tex id is bound to specifies the target of the texture object (that's what the OpenGL reference tells me). I dunno where else it could be created, but at least for now I don't see why we can ALWAYS assume that it has target GL_TEXTURE_2D. Can anyone comment on that? The same applies for This->glDescription.textureName, as it may have a different target. That's my research so far. I'm currently trying to figure out the correct target for the texture object passed to depth_blt and also pass this info to depth_blt as well, so it can be correctly handled there. We'll see if that fixes the problem. Greets, Tobias -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #12 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-18 09:22:44 --- Yes, "texture" can potentially be a cube or rect texture. depth_blt_texture should always be a GL_TEXURE_2D, although that might actually be a problem in some cases if the card doesn't support NPOT textures (ie, might cause a software fallback). This->glDescription.textureName depends on the type of the surfaces used for the depth stencil, and can be either GL_TEXTURE_2D, GL_TEXTURE_RECT, or a cube face. The other issue that's less obvious, is that the depth blit shader needs to be modified as well. It currently always uses texture2D to sample (in case of GLSL), but that's incorrect if the texture is a cube or rect texture, of course. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #13 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-18 09:32:11 --- Created an attachment (id=16719) --> (http://bugs.winehq.org/attachment.cgi?id=16719) [wined3d] use correct texture target in depth_blt Hi there, this patch fixes the GL errors mentioned in this bugreport. It does NOT fix the flickering/disappearing issue. It's (the patch) currently not going into wine because the issue lies much deeper. For the GLSL path create_glsl_blt_shader() is flawed, because it assumes a 2D target (so it uses sample2D, texture2D, and so on) which is not always the case. The attached patch currently handles normal 2d, cubemap and rect targets. According to Henri Verbeet the other targes (1d and 3d) don't appear in combination with depthstencil stuff. So code must also be fixed in create_glsl_blt_shader (probably creating two more functions which handle cubemaps and rects). The same would have to be done for the ARB shader path. Introduces more problems: - Selection of the correct face for cubemap textures - Non-normalized texcoords for rect textures (problem when generating texcoords in vertex shader) Note: The information from above is a summary of what Henri told me on IRC :) Greets, Tobias -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #16719|0 |1 is obsolete| | --- Comment #14 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-18 10:03:10 --- Created an attachment (id=16720) --> (http://bugs.winehq.org/attachment.cgi?id=16720) [wined3d] use correct texture target in depth_blt -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #16720|0 |1 is obsolete| | --- Comment #15 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-18 10:07:29 --- Created an attachment (id=16721) --> (http://bugs.winehq.org/attachment.cgi?id=16721) [wined3d] use correct texture target in depth_blt now with less debug code... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #16721|0 |1 is obsolete| | --- Comment #16 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-18 10:18:16 --- Created an attachment (id=16722) --> (http://bugs.winehq.org/attachment.cgi?id=16722) [wined3d] use correct texture target in depth_blt Remove junk, now it should compile again :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|patch | --- Comment #17 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-18 17:14:23 --- @Austin: I recommend not adding the patch keyword. We don't know yet if the GL error has something to do with the actual issue described in this bugreport. For example Jan has the same issue but he has neither the GL error from depth_blt popping up on the console nor does my patch change anything for him. So this patch might be TOTALLY unrelated to the issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #18 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-19 12:13:50 --- Created an attachment (id=16748) --> (http://bugs.winehq.org/attachment.cgi?id=16748) depth_blt patch How does this work? It should fix the GL error, but chances are it won't solve the rest of the problem. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #19 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-19 13:54:39 --- (In reply to comment #18)
How does this work? It should fix the GL error, but chances are it won't solve the rest of the problem. Hi Henri,
the patch does work, however with a slight modification. You forgot to enable ARB_texture_rectangle in the GLSL program. const char *blt_pshader_RECT[] = { "#version 120\n" "#extension GL_ARB_texture_rectangle : enable\n" "uniform sampler2DRect sampler;\n" "void main(void)\n" "{\n" " gl_FragDepth = texture2DRect(sampler, gl_TexCoord[0].xy).x;\n" "}\n" }; This is how it should look like. Without this modification I get again a lot of GL errors from shader_glsl_deselect_depth_blt. But guess what. After modifying the patch it works. Which means the GL errors are gone and the scene renders without any flickering and disappearing sprites/waterplane. Performance also increased. Going to check what kind of difference that makes in Max Payne 2. @Jan: Check this out on your ATI and report if it helps. Greets, Tobias -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #20 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-19 14:18:08 --- Note: Leave this open because it's only fixed for the GLSL shader path and not for the ARB one. Still flickering with ARB shaders plus I get Henri's new FIXME message :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #21 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-19 15:30:31 --- I'm wondering where depth_blt_glsl_program_id is initialized properly. Is this even done at all? Henri? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #22 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-19 15:31:40 --- Yeah, I only properly implemented RECT textures with GLSL. I wasn't sure if the GLSL extension string was strictly required, issue 15 of the ARB_texture_rectangle spec seems to imply it isn't. I'll clean it up and submit a patch in a couple of days. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #23 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-19 15:34:22 --- (In reply to comment #21)
I'm wondering where depth_blt_glsl_program_id is initialized properly. Is this even done at all? Henri?
It's initialized with zeroes in shader_glsl_alloc(). (the HeapAlloc() with HEAP_ZERO_MEMORY) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #24 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-19 16:51:35 --- Created an attachment (id=16749) --> (http://bugs.winehq.org/attachment.cgi?id=16749) [wined3d] henri's patch plus my port for the arb path Description already says it. I took a look at henri's patch, added the ARB_tex_rect extension stuff and ported the changes to GLSL over to the ARB path. I don't think everything is correct there, but at least it works for me now. So if someone feels like he wants to test this, it's available now. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #25 from Jan Buecken <jb.faq(a)gmx.de> 2008-10-19 17:49:58 --- Created an attachment (id=16750) --> (http://bugs.winehq.org/attachment.cgi?id=16750) log with Tobias patch and GLSL I tested Tobias version of the patch with newest git on ati with fglrx-driver (8.542). In all cases ORM=fbo 0) no patch: regression: I can only see the water if I stand in it and look down, then it is flickering (I call this regression because I can see the waterplane with 1.1.6) 1) with patch, GLSL disabeld: like 0), only fixme and one err message 2) with patch, GLSL enabled: like 1), but with a GLSL errors, for this I attached the relevant part of the command line output. With other words, I can't see differences with or without Tobias patch. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #26 from Jan Buecken <jb.faq(a)gmx.de> 2008-10-19 18:09:51 --- Sorry, but I want to make clear that I test my the cases 1) and 2) without the patch, too! And the output is the same. Hence the patch makes really no difference for me (in this game) including outputs. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com Keywords| |patch --- Comment #27 from Austin English <austinenglish(a)gmail.com> 2008-10-19 19:11:29 --- Henri's patch seems to be a real one, so readding keyword. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #28 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-20 04:09:04 --- Yeah, it least it fixes the issue for me (NV35 hardware). We'll see about Jan. I'm also going to check this on my Intel i915, I think it should be able to run Morrowind. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #16749|0 |1 is obsolete| | --- Comment #29 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-23 16:06:20 --- Created an attachment (id=16829) --> (http://bugs.winehq.org/attachment.cgi?id=16829) [wined3d] Henri's patch plus my port for the ARB path Rebased against current git master, should now again apply cleanly. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #16722|0 |1 is obsolete| | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 H. Verbeet <hverbeet(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #16696|0 |1 is obsolete| | Attachment #16748|0 |1 is obsolete| | --- Comment #30 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-26 19:30:22 --- Created an attachment (id=16914) --> (http://bugs.winehq.org/attachment.cgi?id=16914) Another patch Could you give this patch a try? If it works I'll submit it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #16829|0 |1 is obsolete| | --- Comment #31 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-27 05:27:20 --- Created an attachment (id=16929) --> (http://bugs.winehq.org/attachment.cgi?id=16929) [wined3d] Corrected version of Henri's patch Fixes some pointer casting issues that lead to an early crash. Should compile fine. Fixes the flickering issue for both GLSL and ARB mode for me. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #32 from Jan Buecken <jb.faq(a)gmx.de> 2008-10-28 09:39:04 --- Created an attachment (id=16946) --> (http://bugs.winehq.org/attachment.cgi?id=16946) log with tobias patches Hi, one new log with git, Tobias patch, and his debug patch from here http://bugs.winehq.org/attachment.cgi?id=16903 Same bug. New ideas? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #33 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-28 10:08:11 --- Could you post a +d3d8,+d3d,+d3d_shader log? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #34 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-28 12:35:15 --- Created an attachment (id=16951) --> (http://bugs.winehq.org/attachment.cgi?id=16951) [wined3d] dump GLSL shader to console on error -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #35 from Jan Buecken <jb.faq(a)gmx.de> 2008-10-28 13:38:48 --- New log with Tobias [wined3d] dump GLSL shader to console on error and [wined3d] Corrected version of Henri's patch patches and +d3d8,+d3d,+d3d_shader Because it is more than 4 MB after bzip2, I stored it here www.math.uni-bielefeld.de/~jbuecken/log_new_debug_patch_and_winedebug.bz2 Hope this help. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #36 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-28 15:16:09 --- Those GL errors are caused by the debug patch. You should first check the object type (GL_OBJECT_SUBTYPE_ARB) before trying to get the shader source, since obj can be a program as well. Just to be sure, is d37c6fc0a94b3ac3b4cce58afeafbdf225107b80 also the patch that causes the regression for you? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #37 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-28 16:18:27 --- (In reply to comment #36)
Those GL errors are caused by the debug patch. You should first check the object type (GL_OBJECT_SUBTYPE_ARB) before trying to get the shader source, since obj can be a program as well. Hmm, don't you mean calling glGetObjectParameterARBiv with GL_OBJECT_TYPE_ARB and checking whether it is GL_SHADER_OBJECT_ARB or GL_PROGRAM_OBJECT_ARB?
AFAIK subtype only returns if the shader is a fragment or vertex one. I'm also not quite sure how to deal with the case when it's a program object (and not a shader object, I think the shader ones can be dumped correctly with my current code). Do I need to get the attached shader objects and dump them as well? Or is this functionality already implemented somewhere else in the code? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #38 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-28 16:56:20 --- (In reply to comment #37)
(In reply to comment #36)
Those GL errors are caused by the debug patch. You should first check the object type (GL_OBJECT_SUBTYPE_ARB) before trying to get the shader source, since obj can be a program as well. Hmm, don't you mean calling glGetObjectParameterARBiv with GL_OBJECT_TYPE_ARB and checking whether it is GL_SHADER_OBJECT_ARB or GL_PROGRAM_OBJECT_ARB?
Probably :-)
I'm also not quite sure how to deal with the case when it's a program object (and not a shader object, I think the shader ones can be dumped correctly with my current code). Do I need to get the attached shader objects and dump them as well? You probably don't need to do anything for program objects.
Or is this functionality already implemented somewhere else in the code?
+d3d_shader will show the source as it's being generated. Finding the source for a program is then a matter of searching back in the log for the shader objects that are linked into a program. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #39 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-30 17:35:28 --- Just wanted to confirm that latest git master fixes the problem entirely in GLSL mode for me. Flickering is gone and no errors are produces on the console. It's a bit different in ARB mode, here I'm hitting this (new) fixme, which is continously printed on the console: fixme:d3d_shader:shader_arb_select_depth_blt Unsupported tex_type 0x4 However it's not flickering in ARB mode either. Leaving this open because it's not working for Jan and because of the FIXME (maybe we can remove this as well). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #40 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-10-30 18:04:40 --- @Henri: This line in shader_arb_select_depth_blt: if (tex_type != tex_2d) FIXME("Unsupported tex_type %#x\n", tex_type); Isn't that already implemented? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #41 from H. Verbeet <hverbeet(a)gmail.com> 2008-10-31 02:05:20 --- Oops. Yeah. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #16951|0 |1 is obsolete| | --- Comment #42 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-11-01 11:36:33 --- Created an attachment (id=17030) --> (http://bugs.winehq.org/attachment.cgi?id=17030) [wined3d] dump GLSL shader to console on error Fixed what Henri told me. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #16929|0 |1 is obsolete| | --- Comment #43 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-11-01 11:39:33 --- (From update of attachment 16929) Now obsolete, since code is in git master. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #44 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-11-03 13:30:56 --- Issue now completly fixed for me with latest git master. The remaining FIXME is gone. A big thanks goes to Henri for looking into this! :) Leaving open so Jan can fix his variant of the issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #45 from Tobias Jakobi <liquid.acid(a)gmx.net> 2009-01-29 15:53:57 --- Bumping this for Jan. I saw current state (with wine-1.1.13) on his system today and it's gotten worse. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #46 from Tobias Jakobi <liquid.acid(a)gmx.net> 2009-03-11 13:42:26 --- I took a look at Jan's log from comment #35 to find out what GLSL shader object #37 consisted of. Looks like it consists of objects #38, #36 and #35. 35 is a fragment program and 36 is the vertex shader. 38 isn't found anywhere - which is kinda strange (probably the problem??). To cite the error message from object #37: ERROR: Varying gl_TexCoord[1] read in fragment shader, but not written That here is #35: #version 120 #extension GL_ARB_draw_buffers : enable uniform vec4 PC[8]; uniform sampler2D Psampler0; uniform sampler2D Psampler3; vec4 T0 = gl_TexCoord[0]; vec4 T1 = gl_TexCoord[1]; vec4 T2 = gl_TexCoord[2]; vec4 T3 = gl_TexCoord[3]; vec4 R0; vec4 R1; vec4 tmp0; vec4 tmp1; uniform vec4 PLC5; uniform vec4 PLC1; void main() { T0.xyzw = (texture2D(Psampler0, T0.xy).xyzw); tmp0.x = dot(T2.xyz, (2.0 * (T0.xyz - 0.5))); tmp0.y = dot(T3.xyz, (2.0 * (T0.xyz - 0.5))); T3.xyzw = (texture2D(Psampler3, tmp0.xy).xyzw); T1.xyzw = (PC[2].xyzw * (2.0 * (T0.xyzw - 0.5))); R1.xyzw = (vec4(dot(T1.xyz, (2.0 * (gl_Color.xyz - 0.5))))); R0.xyz = (T3.xyz * PC[4].xyz); R0.w = ((R1.w * PLC1.w) + PLC1.w); R1.xyzw = ((2.0 * (gl_Color.xyzw - 0.5))); R0.xyz = (mix(R0.xyz, PC[6].xyz, R1.www)); R0.w = (R0.w * R0.w); R0.w = (R0.w + -PC[7].w); gl_FragData[0] = R0; float Fog = clamp(gl_FogFragCoord * gl_Fog.start + gl_Fog.end, 0.0, 1.0); gl_FragData[0].xyz = mix(gl_Fog.color.xyz, gl_FragData[0].xyz, Fog); } To me the GLSL compiler error makes no sense at all since T1 is never read before it's overwritten with data that comes from elsewhere. So it's in fact written, not not read?! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #47 from Jan Buecken <jb.faq(a)gmx.de> 2009-03-12 10:13:56 --- For me, this bug is a combination between wine and the ati driver: Some time ago, I test this and wine 1.0.1 worked, but with new ati-driver (8.552 or higher, I use 8.528): wine 1.0, 1.0.1, 1.1.1 1.1.2 crashes with unhandeld pagefault. With 1.1.3 or higher this bug holds (and the new ati-drivers causes new errors, the menu filckers, too, I think I post a new bug for this). New log with ati-driver 8.528 +d3d8,+d3d,+d3d_shader newest git (wine version = 1.1.16-367-gae1802d) fbo glsl enabled 9,1 MB => http://www.math.uni-bielefeld.de/~jbuecken/wine-1.1.16-367-gae1802d_fbo_GLSL... (Behavior doesn't change with backbuffer or glsl disbabled) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #48 from Tobias Jakobi <liquid.acid(a)gmx.net> 2009-03-12 13:11:44 --- Looks like the problem is consisting of two components. The first thing is the handling of "optimizable code" by the ATI GLSL compiler. What do I mean by that. Well, the problem is that one GLSL shader program (id #35 in Jan's latest log) doesn't get compile properly, because of the (already known) error: Fragment shader(s) linked, vertex shader(s) linked. WARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supported WARNING: built-in varying gl_TexCoord [1] has mismatched access semantics between the vertex and fragment shader ERROR: Varying gl_TexCoord[1] read in fragment shader, but not written There are three shader objects linked to the program #35. These are #36, #37 and #38. I could identify #36 as the vertex shader and #38 as the fragment shader. That is #38, the fragment shader: #version 120 #extension GL_ARB_draw_buffers : enable uniform vec4 PC[8]; uniform sampler2D Psampler0; uniform sampler2D Psampler3; vec4 T0 = gl_TexCoord[0]; vec4 T1 = gl_TexCoord[1]; vec4 T2 = gl_TexCoord[2]; vec4 T3 = gl_TexCoord[3]; vec4 R0; vec4 R1; vec4 tmp0; vec4 tmp1; uniform vec4 PLC5; uniform vec4 PLC1; void main() { T0.xyzw = (texture2D(Psampler0, T0.xy).xyzw); tmp0.x = dot(T2.xyz, (2.0 * (T0.xyz - 0.5))); tmp0.y = dot(T3.xyz, (2.0 * (T0.xyz - 0.5))); T3.xyzw = (texture2D(Psampler3, tmp0.xy).xyzw); T1.xyzw = (PC[2].xyzw * (2.0 * (T0.xyzw - 0.5))); R1.xyzw = (vec4(dot(T1.xyz, (2.0 * (gl_Color.xyz - 0.5))))); R0.xyz = (T3.xyz * PC[4].xyz); R0.w = ((R1.w * PLC1.w) + PLC1.w); R1.xyzw = ((2.0 * (gl_Color.xyzw - 0.5))); R0.xyz = (mix(R0.xyz, PC[6].xyz, R1.www)); R0.w = (R0.w * R0.w); R0.w = (R0.w + -PC[7].w); gl_FragData[0] = R0; float fogstart = -1.0 / (gl_Fog.end - gl_Fog.start); float fogend = gl_Fog.end * -fogstart; float Fog = clamp(gl_FogFragCoord * fogstart + fogend, 0.0, 1.0); gl_FragData[0].xyz = mix(gl_Fog.color.xyz, gl_FragData[0].xyz, Fog); } The problematic line is "vec4 T1 = gl_TexCoord[1];" The compiler considers this reading from gl_TexCoord[1] even though this line could probably be optimized into "vec4 T1;" without the initialization through data from gl_TexCoord[1]. T1 is never read before it is fully overwritten through "T1.xyzw = (PC[2].xyzw * (2.0 * (T0.xyzw - 0.5)));" Now taking a look at the vertex shader (#36): #version 120 uniform vec4 VC[107]; uniform vec4 posFixup; void order_ps_input(); vec4 R4; vec4 R5; vec4 R6; vec4 R7; vec4 R8; vec4 R9; attribute vec4 attrib0; attribute vec4 attrib1; vec4 tmp0; vec4 tmp1; void main() { gl_Position.x = (dot(attrib0.xyzw, VC[2].xyzw)); gl_Position.y = (dot(attrib0.xyzw, VC[3].xyzw)); gl_Position.z = (dot(attrib0.xyzw, VC[4].xyzw)); gl_Position.w = (dot(attrib0.xyzw, VC[5].xyzw)); R5.xyzw = (vec4(dot(attrib0.xyzw, VC[4].xyzw))); R5.xyzw = (R5.xyzw + -VC[54].xxxx); gl_FogFragCoord = ((-R5.x * VC[54].z) + VC[54].w); R4.xyzw = (-attrib0.xyzw + VC[6].xyzw); R9.xyzw = (R4.xyzw); R4.z = (VC[30].x); R4.w = (dot(R4.xyz, R4.xyz)); R4.w = (inversesqrt(R4.w)); R4.xyz = (R4.xyz * R4.www); R6.xyzw = (R4.xyzw); R6.z = (VC[30].y); R5.xyzw = (VC[30].xxzx); R8.xyzw = (R5.yzxw * R4.zxyw); R8.xyzw = ((-R4.yzxw * R5.zxyw) + R8.xyzw); R8.z = (VC[30].y); R7.xyzw = (R6.xyzw); R7.y = (R8.x); R8.x = (R6.y); R9.w = (dot(R9.xyz, R9.xyz)); R9.w = (inversesqrt(R9.w)); R9.xyz = (R9.xyz * R9.www); R9.z = (max(R9.z, -R9.z)); R5.xyzw = (VC[1].xyzw + -R9.zzzz); R5.xyzw = (R5.xyzw * R5.xyzw); R5.xyzw = (R5.xyzw * VC[30].yyyy); R7.z = ((R5.z * R4.x) + R7.z); R8.z = ((R5.z * R4.y) + R8.z); R7.xy = (R7.xy * VC[53].xy); R8.xy = (R8.xy * VC[53].xy); gl_TexCoord[2].xyzw = (R7.xyzw); gl_TexCoord[3].xyzw = (R8.xyzw); gl_FrontColor.xyzw = ((R9.xyzz * VC[30].yyyy) + VC[30].yyyy); gl_TexCoord[0].xy = (attrib1.xy); order_ps_input(); gl_Position.y = gl_Position.y * posFixup.y; gl_Position.xy += posFixup.zw * gl_Position.ww; gl_Position.z = gl_Position.z * 2.0 - gl_Position.w; } As you can see gl_TexCoord[1] is never accessed (more important: written to) in the vshader. Just inserting a "gl_TexCoord[1] = vec4(0.0, 0.0, 0.0, 0.0);" line after "void main() {" solves the compiler error, but sadly the flickering remains. However I suspect something else to be a more critical source of the flickering, that's the second component: One of the first errors from OpenGL is this one: fixme:d3d:IWineD3DDeviceImpl_CreateSwapChain >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glDrawBuffer(GL_BACK) @ device.c / 1838 Later the console is flooded with these kind of errors: fixme:d3d:apply_draw_buffer >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glDrawBuffers() @ context.c / 1445 Please note that not "everything" is affected by the flickering. It's the ingame waterplane, the ingame menu and the main menu. And some part of the vegetation (leafage of trees e.g.). The main ingame geometry is unaffected. Looks like that the flickering is happening because no backbuffer is existant for these parts. Which sounds logical: No backbuffer so everything is always rendered to GL_FRONT, resulting is vsync-like flickering artifacts. Also note that the GL_BACK problem didn't always exist. It looks like it doesn't depend on the wine version, but on the version of the ATI driver. In comment #32 e.g. I can't see any of these messages (like the swapchain one) in the logs. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #49 from Tobias Jakobi <liquid.acid(a)gmx.net> 2009-03-12 13:22:10 --- And that's the surface making all the trouble: trace:d3d:IWineD3DDeviceImpl_CreateSurface (0x19ed58) : w(1024) h(768) fmt(3,WINED3DFMT_X8R8G8B8) lockable(0) surf(a)0x1b0880, surfmem(a)0xe20020, 3145728 bytes SwapChain fails here and it's also the surf that makes apply_draw_buffer break. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 --- Comment #50 from Jan Buecken <jb.faq(a)gmx.de> 2009-03-29 20:35:07 --- fixed with wine-1.1.18 and ati-catalyst-9.3 (=8.593) I'll delete the external logs (links above) in the near future. Thanks for your help! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #51 from Tobias Jakobi <liquid.acid(a)gmx.net> 2009-03-30 06:45:29 --- Reported as FIXED. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15644 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #52 from Alexandre Julliard <julliard(a)winehq.org> 2009-04-10 11:19:30 --- Closing bugs fixed in 1.1.19. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org