[Bug 21708] New: d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture
http://bugs.winehq.org/show_bug.cgi?id=21708 Summary: d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture Product: Wine Version: 1.1.38 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: suokkos(a)gmail.com ARB_depth_texture (and ARB_shadow) was moved to opengl core only in 1.4. radeon r200 cards don't have hw support or depth textures so mesa r200 driver only supports 1.3. If I run 3DMark2001 in wine with r200 I get INVALID_ENUM errors for call to glTexParameter(GL_DEPTH_TEXTURE_MODE_ARB). The problematic demo is the high detail lobby. If directx 8 did require something similar to ARB_shadow and ARB_depth_texture then it would be interesting to know if ati did support them in windows driver. -- 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=21708 Roderick Colenbrander <thunderbird2k(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k(a)gmail.com --- Comment #1 from Roderick Colenbrander <thunderbird2k(a)gmail.com> 2010-03-21 17:05:01 --- These extensions were not offered on these cards in GL mode (see http://ati.amd.com/developer/atiopengl.pdf). I don't know much about this area of wined3d, so can't help. It might be that they used software emulation or used some GPU features which are not exposed through OpenGL. -- 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=21708 --- Comment #2 from Roderick Colenbrander <thunderbird2k(a)gmail.com> 2010-04-28 06:33:23 --- The only place where we are making such call is in surface.c: glTexParameteri(bind_target, GL_DEPTH_TEXTURE_MODE_ARB, GL_LUMINANCE); Is this the offending call in your case? If it is then I find it a bit surprising since that path is only used when FBOs are around. Do your drivers offer GL_EXT_framebuffer_object / GL_ARB_framebuffer_object? (typically this extension is only around on OpenGL 2.0 capable cards) The code won't be entered if you set the OffscreenRenderingMethod to backbuffer. -- 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=21708 --- Comment #3 from Roderick Colenbrander <thunderbird2k(a)gmail.com> 2010-04-28 06:34:44 --- I forgot to ask does it result in rendering errors? -- 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=21708 --- Comment #4 from Pauli Nieminen <suokkos(a)gmail.com> 2010-05-02 22:04:41 --- Replying with email doesn't work :/
--- Comment #2 from Roderick Colenbrander <thunderbird2k(a)gmail.com> 2010-04-28 06:33:23 --- The only place where we are making such call is in surface.c: glTexParameteri(bind_target, GL_DEPTH_TEXTURE_MODE_ARB, GL_LUMINANCE);
Is this the offending call in your case? If it is then I find it a bit surprising since that path is only used when FBOs are around. Do your drivers offer GL_EXT_framebuffer_object / GL_ARB_framebuffer_object? (typically this extension is only around on OpenGL 2.0 capable cards) The code won't be entered if you set the OffscreenRenderingMethod to backbuffer.
Yes. Open source radeon supports FBOs even with older hw (r100 and r200 that are only GL1.3/1.5 hardware). But FBO support is missing depth textures because of no texture format for depth buffer in the old hw.
I forgot to ask does it result in rendering errors?
And I see that error when testing 3DMark2001SE lobby demo. It used to render correctly but now it fails to render characters. I don't know if incorrect rendering is caused by the error 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=21708 Stefan Dösinger <stefandoesinger(a)gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger(a)gmx.at --- Comment #5 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2010-05-10 11:47:48 --- I haven't done any serious work on my ATI radeon 9000 for a while. It sounds as if depth testing is working fine with a GL_DEPTH_COMPONENT texture attached to a FBO, but since GL_ARB_depth_texture isn't supported it can't be used for sampling from the texture. This would be a reasonable thing in terms of hardware support. FBOs without depth buffers are useless, but it's just fine to use the texture for the depth test only, and not for shadows. However, I'm not quite sure how legal this is from a GL API perspective, because technically DEPTH_COMPONENT cannot be used for creating a texture without depth_texture support. I can see 3 possibilities: 1) We can use renderbuffers(not texturable GL surfaces) 2) We make this a driver quirk and just test for the depth texture mode set error 3) The Mesa devs push out a new extension to clarify the situation I think (1) is the best thing to do(if it works), but it's a lot of infrastructure work. We need it for multisampling though. -- 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=21708 --- Comment #6 from Austin English <austinenglish(a)gmail.com> 2012-03-19 14:53:07 CDT --- This is your friendly reminder that there has been no bug activity for 650 days. Is this still an issue in current (1.4 or newer) wine? -- 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=21708 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan(a)codeweavers.com --- Comment #7 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-03-20 04:53:53 CDT --- I don't know of anything that would have fixed this bug, but I'd prefer to hear from someone who is still using an r200 GPU. -- 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=21708 Rafał Mużyło <galtgendo(a)o2.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo(a)o2.pl --- Comment #8 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-11-17 19:34:02 CST --- (In reply to comment #7)
I don't know of anything that would have fixed this bug, but I'd prefer to hear from someone who is still using an r200 GPU.
I'm not sure about this bug in itself, but I've got an r200 and in some of the cases I can see significant difference between fbo (with black texture covering the window) and backbuffer (looking mostly OK). The errors are about fixme:d3d_surface:surface_allocate_surface No GL internal format for format WINED3DFMT_D16_UNORM. This seems to relate somewhat to ARB_DEPTH_TEXTURE (according to dlls/wined3d/utils.c), so if there are some simple tests I could run, I'd try to give some useful feedback. -- 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=21708 --- Comment #9 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-11-18 05:10:37 CST --- Created attachment 42534 --> http://bugs.winehq.org/attachment.cgi?id=42534 wined3d: Remove ARB_depth_texture requirement for D3DFMT_D16_UNORM (HACK) Out of curiosity, does this hack make it any better? It's by no means a correct fix, but it might just be enough to get those games going. -- 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=21708 --- Comment #10 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-11-18 06:48:57 CST --- I checked the capabilities the d3d driver of my r250 GPU advertises on Windows. It supports D16, D24S8, D24X8 and D16_LOCKABLE as depth stencil surfaces, but not as textures. That matches the capabilities of depth renderbuffers. -- 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=21708 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|stefandoesinger(a)gmx.at | -- 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=21708 --- Comment #11 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-11-18 08:58:14 CST --- (In reply to comment #9)
Created attachment 42534 [details] wined3d: Remove ARB_depth_texture requirement for D3DFMT_D16_UNORM (HACK)
Out of curiosity, does this hack make it any better? It's by no means a correct fix, but it might just be enough to get those games going.
Well, for the display, it makes no difference. For the console output, it does. err:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexImage2D @ surface.c / 2748 fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6) fixme:d3d:context_check_fbo_status Location SFLAG_INTEXTURE (0x40000). fixme:d3d:context_check_fbo_status Color attachment 0: (0x194730) WINED3DFMT_B8G8R8X8_UNORM 800x600 0 samples. fixme:d3d:context_check_fbo_status Depth attachment: (0x194888) WINED3DFMT_D16_UNORM 800x600 0 samples. err:d3d:device_clear_render_targets >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glClear @device.c / 777 fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6) fixme:d3d:context_check_fbo_status Location SFLAG_INTEXTURE (0x40000). fixme:d3d:context_check_fbo_status Color attachment 0: (0x194730) WINED3DFMT_B8G8R8X8_UNORM 800x600 0 samples. fixme:d3d:context_check_fbo_status Depth attachment: (0x194888) WINED3DFMT_D16_UNORM 800x600 0 samples. err:d3d:device_clear_render_targets >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glClear @ device.c / 815 fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6) fixme:d3d:context_check_fbo_status Location SFLAG_INTEXTURE (0x40000). fixme:d3d:context_check_fbo_status Color attachment 0: (0x194730) WINED3DFMT_B8G8R8X8_UNORM 800x600 0 samples. fixme:d3d:context_check_fbo_status Depth attachment: (0x194888) WINED3DFMT_D16_UNORM 800x600 0 samples. err:d3d_draw:drawStridedSlow >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glEnd and previous calls @ drawprim.c / 310 fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6) fixme:d3d:context_check_fbo_status Location SFLAG_INTEXTURE (0x40000). fixme:d3d:context_check_fbo_status Color attachment 0: (0x194730) WINED3DFMT_B8G8R8X8_UNORM 800x600 0 samples. fixme:d3d:context_check_fbo_status Depth attachment: (0x194888) WINED3DFMT_D16_UNORM 800x600 0 samples. This 4 types now flood the console. -- 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=21708 --- Comment #12 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-11-18 10:15:11 CST --- Created attachment 42536 --> http://bugs.winehq.org/attachment.cgi?id=42536 wined3d: Always use a renderbuffer for the depth stencil attachment(HACK) The GL errors you get make sense. They confirm that the driver indeed doesn't support depth textures, and not just forgot to advertise the extension. Can you try this patch on top of the previous one? It forces the use of a render buffer rather than a texture for the depth stencil surface. I haven't tested it, so it might be totally broken. -- 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=21708 --- Comment #13 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-11-18 11:22:00 CST --- Now the window is still black, but instead of previous errors, there's only this one printed repeatedly: fixme:d3d_surface:surface_load_ds_location Not supported with fixed up depth stencil. -- 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=21708 --- Comment #14 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-11-18 11:24:24 CST --- ...and it might be of interest, that there's one constant fixme present regardless of the changes, appearing once before others: fixme:d3d:state_zenable Z buffer disabled, but ARB_depth_clamp isn't supported. -- 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=21708 --- Comment #15 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-11-18 11:41:39 CST --- Which game are you testing by the way? (In reply to comment #14) > fixme:d3d:state_zenable Z buffer disabled, but ARB_depth_clamp isn't supported. This FIXME is harmless in most games. The interesting question is why the Z buffer is disabled. Either the game explicitly disables it(ok), or there is no depth buffer(maybe ok, maybe not). Can you check if there's a line "No Z buffer - disabling depth test" in a +d3d log? (In reply to comment #14) > Now the window is still black, but instead of previous errors, there's only > this one printed repeatedly: > fixme:d3d_surface:surface_load_ds_location Not supported with fixed up depth > stencil. This fixme is a side effect of the hack. It may cause rendering problems, but I suspect something else is broken. Please try(on top of my two hacks) to set the following registry key: HKEY_CURRENT_USER/Software/Wine/Direct3D/AlwaysOffscreen = "disabled" -- 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=21708 --- Comment #16 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-11-18 12:15:32 CST --- (In reply to comment #15) > (In reply to comment #14) > > fixme:d3d:state_zenable Z buffer disabled, but ARB_depth_clamp isn't supported. > This FIXME is harmless in most games. The interesting question is why the Z > buffer is disabled. Either the game explicitly disables it(ok), or there is no > depth buffer(maybe ok, maybe not). Can you check if there's a line "No Z buffer > - disabling depth test" in a +d3d log? > No such line in the log. > (In reply to comment #14) > > Now the window is still black, but instead of previous errors, there's only > > this one printed repeatedly: > > fixme:d3d_surface:surface_load_ds_location Not supported with fixed up depth > > stencil. > This fixme is a side effect of the hack. It may cause rendering problems, but I > suspect something else is broken. > > Please try(on top of my two hacks) to set the following registry key: > HKEY_CURRENT_USER/Software/Wine/Direct3D/AlwaysOffscreen = "disabled" With this regkey, it seems to be displayed correctly. -- 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=21708 --- Comment #17 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-11-18 12:18:26 CST --- Ok, so at least the swapchain present blit is broken. That should be fixable. Depending on your game, setting this key is probably enough to get it working. My patches only matter if the game uses offscreen rendering itself. What game(s) are you trying to run? -- 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=21708 --- Comment #18 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-11-18 12:39:59 CST --- Indeed, after reverting the hacks, the regkey does suffice. As for the game, it's nothing widely used. -- 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=21708 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #19 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-11-23 03:13:54 CST --- I had a quick look at the FBO capabilities of the r200 driver. A depth renderbuffer seems to work as expected(the depth test works ok) and overall EXT_fbo functionality is there as well. There's no ARB_fbo or EXT_fbo_blit support though. The non-fbo-blit swapchain present code is broken. The first problem I identified is that we don't bind the backbuffer texture when we try to draw the textured quad onto the window. With that fixed, the d3d sdk samples show the clear background color rather than black. There is some other problem that seems to prevent draws from succeeding, and I haven't found this yet. Making wined3d use renderbuffers instead of textures for the depth stencil will be harder. I probably won't implement this for this card alone, unless a lot of people who still use this card or a r100 one show up. There are other motivations for using rbs, like possible performance improvements. If/when the time comes to do this work I'll keep the r200 GPU in mind. Also the performance of the r200 driver is still crap, compared to the performance it had prior to the introduction of KMS. That applies to Wine and Linux-native games. -- 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=21708 --- Comment #20 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-12-05 15:50:08 CST --- Commit 7b95df03c683e52b31d0e6a9e9e81072139c8f14 should improve the situation with AlwaysOffscreen = enabled somewhat. Depending on your application, you might run into https://bugs.freedesktop.org/show_bug.cgi?id=57842 . If you don't hit that bug, things might work with AlwaysOffscreen=enabled and my two hacks. However, AlwaysOffscreen=enabled is mostly an academic exercise. On r200, not rendering to an FBO is faster anyway, unless the application renders to offscreen surfaces itself. -- 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=21708 --- Comment #21 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-12-10 10:51:44 CST --- Well, I've just tested things with 1.5.19. Things are both better and worse. The display is correct now. However, it became quite crashy on kernel level.
From dmesg: [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer ! [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! a crash follows.
"No GL internal format for format WINED3DFMT_D16_UNORM." is still present without the regkey, but the crash happens regardless of 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=21708 --- Comment #22 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-12-10 11:19:39 CST --- Did you apply the two hacks I attached to this bug report? -- 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=21708 --- Comment #23 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-12-10 12:03:00 CST --- (In reply to comment #22)
Did you apply the two hacks I attached to this bug report?
No - I was under impression that they were no longer needed. With those two hacks applied, it's not crashy, but a few textures aren't displayed and the warning from comments 13 and 14 are back. -- 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=21708 --- Comment #24 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-12-21 18:10:39 CST --- A little note regarding 1.5.20 or rather something I've failed to notice in the earlier test (this is without using the source hacks): while the regkey helps in that it doesn't almost instantly crash, it still crashes under certain conditions with a different warning just before the crash err:d3d_surface:surface_set_compatible_renderbuffer >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from set_compatible_renderbuffer @ dlls/wined3d/surface.c / 2778 This most likely is yet another hardware limitation of r200, but is it the same one ? -- 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=21708 --- Comment #25 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-12-22 05:16:26 CST --- (In reply to comment #24)
err:d3d_surface:surface_set_compatible_renderbuffer >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from set_compatible_renderbuffer @ dlls/wined3d/surface.c / 2778 I think the application tries to do offscreen rendering itself. That's what the two hacks are intended to address.
You mentioned "missing textures" with my hacks. Can you attach a screenshot of the problem, and, if possible, a screenshot of the correct rendering? -- 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=21708 --- Comment #26 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-12-22 12:36:12 CST --- Created attachment 42904 --> http://bugs.winehq.org/attachment.cgi?id=42904 correct display Here you go: this is the correct display... -- 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=21708 --- Comment #27 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-12-22 12:38:17 CST --- Created attachment 42905 --> http://bugs.winehq.org/attachment.cgi?id=42905 incorrect display ...and this has missing 'background'. On not quite related note: it seems I've stumbled upon yet another font 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=21708 --- Comment #28 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-12-22 14:39:06 CST --- Created attachment 42907 --> http://bugs.winehq.org/attachment.cgi?id=42907 wined3d: hack: disable culling Can you try this hack on top of the other two hacks? It is a workaround for https://bugs.freedesktop.org/show_bug.cgi?id=57842 . -- 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=21708 --- Comment #29 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-12-22 16:46:19 CST --- Created attachment 42909 --> http://bugs.winehq.org/attachment.cgi?id=42909 a broken cursor Indeed, this additional hack helped. So, you're saying that this part is basically a driver bug ? Though independent of this new hack, there's a different problem: look at this screenshot, notice cursor - one in many instances. For some reason, those two previous hacks have occasionally, but reproducibly this effect on the cursor. -- 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=21708 --- Comment #30 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-12-22 17:35:04 CST --- The cursor symptom looks like the background is not redawn correctly. This could be a side effect of the hacks, or because the hacks are incomplete solutions. The missing background fixed by attachment 42907 is a driver bug. The issues addressed by the other patches are legitimate driver limitations that aren't handled correctly by Wine. -- 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=21708 --- Comment #31 from Rafał Mużyło <galtgendo(a)o2.pl> 2012-12-22 18:32:45 CST --- Could the fact that r200 has only GL_EXT_framebuffer_object, not GL_ARB_framebuffer_object, play a role in the driver bug ? -- 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=21708 --- Comment #32 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-12-23 04:13:46 CST --- No, that's not the reason for the driver bug. The GPU chip behaves somewhat strange. The driver code looks ok, but for some reason the GPU decides to discard all geometry if the viewport dimensions are not inverted. I don't have the GPU docs to see what the intended behavior is. Maybe the driver has to be changed to always invert the viewport, and invert all geometry when rendering offscreen to cancel out the y coordinate flip. That'd be a pain with vertex shaders though. -- 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=21708 --- Comment #33 from Stefan Dösinger <stefan(a)codeweavers.com> 2012-12-23 04:15:45 CST --- Fwiw, the lack of ARB_fbo is the reason for the "fixme:d3d_surface:surface_load_ds_location Not supported with fixed up depth stencil." line. But due to the hacky nature of my hacks even having ARB_fbo wouldn't help. Proper handling of depth renderbuffers would be needed here. -- 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=21708 --- Comment #34 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-02-08 17:35:35 CST --- I'm a bit late again. There has been regression in wine 1.5.23, that's sort of, but not quite is related to this bug, in the way, that most likely it can happen only on cards as old as r200. I've bisected it to 3f21757702239f1c254cdc860d71e76e9929d409. The problem happens to be if (wined3d_settings.vs_mode == VS_NONE && wined3d_settings.ps_mode == PS_NONE) return &none_shader_backend; It seems that on an r200 only one of those conditions is false, leading to select_shader_backend returning arb_program_shader_backend instead of none_shader_backend. That in turn leads to completely corrupted display. Alternatively, if (gl_info->supported[ARB_VERTEX_PROGRAM] && gl_info->supported[ARB_FRAGMENT_PROGRAM]) &arb_program_shader_backend; could be the problem/solution, as toggling the condition && <-> || in *either* seems to fix 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=21708 --- Comment #35 from Stefan Dösinger <stefan(a)codeweavers.com> 2013-02-08 17:53:29 CST --- Does http://source.winehq.org/patches/data/94198 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=21708 --- Comment #36 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-02-08 19:40:45 CST --- (In reply to comment #35)
Does http://source.winehq.org/patches/data/94198 help?
Seems it does, thanks. -- 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=21708 --- Comment #37 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-05-24 23:04:52 CDT --- Well, once again I haven't been checking for a few wine versions and - predictably - got bitten by a corner case again. At 1.5.28 things worked as good/bad as they were, at 1.5.31 all I get from the testcase is: err:d3d:wined3d_adapter_init_gl_caps Received a NULL GL_RENDERER. err:d3d:wined3d_adapter_init Failed to initialize GL caps for adapter 0x138c48. followed by a crash. ... yay... Is this progress or regression ? On one hand, it only worked somewhat sanely due to hacks, on the other, it *did* work. -- 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=21708 --- Comment #38 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-05-26 13:35:17 CDT --- OK, bisected it - it dates back to 1.5.29. Unfortunately, it's not really clear what goes wrong. Bisect stops on 5115f55eebe5cb91f13896862275e236a4954744 (wined3d: Use WGL_ARB_create_context when available.) -- 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=21708 Rafał Mużyło <galtgendo(a)o2.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hverbeet(a)gmail.com --- Comment #39 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-05-26 14:34:35 CDT --- OK, I might have found a fix, but it looks a bit odd. It simply delays wined3d_create_fake_gl_context_attribs call in wined3d_adapter_init a few lines. I'm not sure it's a corect solution, so I'm not sending the patch yet. -- 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=21708 --- Comment #40 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-05-26 14:51:48 CDT --- Created attachment 44564 --> http://bugs.winehq.org/attachment.cgi?id=44564 fix for the crash This is the change I was talking about. I can't really tell, if that's what it was supposed to be in the first place or is it simply a hack. -- 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=21708 --- Comment #41 from Henri Verbeet <hverbeet(a)gmail.com> 2013-05-26 15:04:46 CDT --- That patch doesn't really make sense, though it does suggest something goes wrong with the wglCreateContextAttribsARB() call. From what you posted it seems it doesn't create a context / creates a broken context, but doesn't return an error either. -- 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=21708 --- Comment #42 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-05-26 21:51:50 CDT --- Well, the patch works, so it looks as before it, wine can create a situation where device->contexts[0]->glCtx exists, but device->context_count is zero. Well, at least that's my guess, that the patch was based upon, before it tested positively. Perhaps one of the functions isn't initializing all of the fields ? -- 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=21708 --- Comment #43 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-06-08 11:46:47 CDT --- One way or the other, if any fixes for this were merged into 1.6_rc1, they aren't working - the hack still seems to be. On a semi-related note: a fix for 6ab04040e52465e77558a067309e8a54bdc0f32c regression would be nice too (as my hack/partial revert got rejected awhile ago). -- 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=21708 --- Comment #44 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-06-30 23:26:15 CDT --- The problem noted in comment 37 is still present in 1.6_rc4. -- 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=21708 Rafał Mużyło <galtgendo(a)o2.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #44564|0 |1 is obsolete| | --- Comment #45 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-07-02 20:01:54 CDT --- Created attachment 45080 --> http://bugs.winehq.org/attachment.cgi?id=45080 updated hack I've tried to figure out where exactly things fail, but the only part I understood was that without the hack it behaves as if glGetString was called outside active context. -- 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=21708 --- Comment #46 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-08-02 16:06:05 CDT --- As of 1.7.0, there's nothing new to report - whatever was broken with wined3d_adapter_init, still is, the hack still works. No new ideas from me at this time. -- 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=21708 --- Comment #47 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-08-31 18:02:28 CDT --- So, after being informed about bug 34238, I've tried the testcase. The results: ./main_linux 1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" 3: renderer="(null)" vendor="(null)" version="(null)" (different version entry comes likely from the fact that I've updated mesa today) ./main.exe 1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" 3: renderer="(null)" vendor="(null)" version="(null)" LIBGL_ALWAYS_SOFTWARE=1 ./main_linux 1: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa 9.2.0" 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" 3: renderer="(null)" vendor="(null)" version="(null)" LIBGL_ALWAYS_SOFTWARE=1 ./main.exe err:winediag:X11DRV_WineGL_InitOpenglInfo The Mesa OpenGL driver is using software rendering, most likely your 32-bit OpenGL drivers haven't been installed correctly (using GL renderer "Software Rasterizer", version "2.1 Mesa 9.2.0"). 1: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa 9.2.0" 2: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa 9.2.0" 3: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa 9.2.0" -- 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=21708 --- Comment #48 from Rico <kgbricola(a)web.de> 2013-09-01 08:22:36 CDT --- Created attachment 45801 --> http://bugs.winehq.org/attachment.cgi?id=45801 glxtest (use direct rendering) Well, there is a bug in my native linux test case. Requesting an indirect context with glXCreateContextAttribsARB after a direct in glXCreateContext seems to always fail later. I'm not sure it should... the ARB_create_context spec isn't clear in this case (this may be a bug in mesa). Though we may test this on nvidia and fglrx. I improved the test case a bit. This first point is not the problem you are seeing. In your case we may fall into creating an indirect (or in another way incompatible) context and then fail in mesa. Your log looks a bit question able...
1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" 3: renderer="(null)" vendor="(null)" version="(null)"
Do you have multiple mesa version installed? The spec says it may create an indirect context, even if you request a direct one (as wine does). Could you please run the new test (only "./main_linux" and "wine main.exe")? -- 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=21708 --- Comment #49 from Henri Verbeet <hverbeet(a)gmail.com> 2013-09-01 08:29:55 CDT --- (In reply to comment #47)
So, after being informed about bug 34238, I've tried the testcase.
Thanks, I've added those results to bug 34238. It's probably best to continue any discussion about that issue there. -- 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=21708 --- Comment #50 from Rafał Mużyło <galtgendo(a)o2.pl> 2013-09-01 08:42:18 CDT --- (In reply to comment #48)
(different version entry comes likely from the fact that I've updated mesa today)
./main_linux 1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" direct 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" indirect 3: renderer="(null)" vendor="(null)" version="(null)" indirect 4: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" indirect 5: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" indirect ./main.exe 1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" 3: renderer="(null)" vendor="(null)" version="(null)" -- 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.
https://bugs.winehq.org/show_bug.cgi?id=21708 --- Comment #51 from Austin English <austinenglish(a)gmail.com> --- This is your friendly reminder that there has been no bug activity for 1 year. Is this still an issue in current (1.7.31 or newer) wine? If so, please attach the terminal output in 1.7.31 (see http://wiki.winehq.org/FAQ#get_log). -- 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.
https://bugs.winehq.org/show_bug.cgi?id=21708 --- Comment #52 from Rafał Mużyło <galtgendo(a)o2.pl> --- (In reply to Austin English from comment #51)
This is your friendly reminder that there has been no bug activity for 1 year. Is this still an issue in current (1.7.31 or newer) wine? If so, please attach the terminal output in 1.7.31 (see http://wiki.winehq.org/FAQ#get_log).
Well, unless the other r200 cards spontaneously mutated... Seriously, though, things got worse. With wine 1.7.31. With 'fbo' either black texture (AlwaysOffscreen = "disabled") or noise (otherwise) is displayed. In the console, a flood of: Mesa: User error: GL_INVALID_FRAMEBUFFER_OPERATION in glBegin(incomplete framebuffer) err:d3d:wined3d_debug_callback 0x1e72a0: "GL_INVALID_FRAMEBUFFER_OPERATION in glBegin(incomplete framebuffer)". Mesa: User error: GL_INVALID_OPERATION in glEnd err:d3d:wined3d_debug_callback 0x1e72a0: "GL_INVALID_OPERATION in glEnd". err:d3d_draw:drawStridedSlow >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glEnd and previous calls @ dlls/wined3d/drawprim.c / 339 With 'backbuffer', it initially looks OK, but it dumps a few "err:d3d:buffer_find_decl no converted attributes found, old conversion map exists, and no declaration change?", and crashes a bit later. On the other hand, I haven't been testing it for quite awhile, so the crash might be unrelated. ...and that's with native, cause with builtin what I get is a few series of "fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5." followed by fixme:d3dx:D3DXLoadMeshHierarchyFromXInMemory Loading user data not implemented fixme:d3dx:D3DXLoadMeshHierarchyFromXInMemory Animation controller creation not implemented wine: Call from 0x7ec5f7a1 to unimplemented function d3dx9_36.dll.D3DXComputeNormals, aborting -- 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.
https://bugs.winehq.org/show_bug.cgi?id=21708 --- Comment #53 from Stefan Dösinger <stefan(a)codeweavers.com> --- Created attachment 51086 --> https://bugs.winehq.org/attachment.cgi?id=51086 Set of patches to improve Wine on r200 I've had some spare time yesterday and today and written a few patches that improve Wine on r200. They fix the use of depth textures, but unfortunately this part of the patch series is still broken and needs a lot more work. I've also improved color conversion support in the ATI fragment shader backend and fixed some bugs there. The tests run fairly well now on this card. Tests that need a vertex pipeline replacement still have problems, and tests that need GL_ARB_framebuffer_object (as opposed to just GL_EXT_framebuffer_object) still fail. Even beyond a vertex pipeline replacement there are some fog problems that won't be easy to fix, mostly because the driver always evaluates the fog equation in the vertex pipeline. There are some defines in the headers that suggest the hardware should be able to do fragment side fog, but this is not as easy as just setting a flag and I don't have the hardware documentation. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=21708 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de -- 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.
https://bugs.winehq.org/show_bug.cgi?id=21708 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |28af7b407bb926953a73c373eb5 | |36449d1110e82 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #54 from Stefan Dösinger <stefan(a)codeweavers.com> --- This should be fixed by 28af7b407bb926953a73c373eb536449d1110e82. Wined3d now no longer uses GL depth textures for d3d depth surfaces if GL_ARB_depth_texture is not supported and uses renderbuffers instead. d3d depth textures are reported as unsupported to the application in this situation and creating them generates an error. There's still a GL error about setting GL_DEPTH_TEXTURE_MODE on sampler objects. This is a Mesa bug. I have sent a patch a while ago but need to do more pushing to get it reviewed and committed. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=21708 --- Comment #55 from Stefan Dösinger <stefan(a)codeweavers.com> --- Also note that r200 seems to have some problems with depth render buffers of some sizes. Some parts of the buffer are placed incorrectly, causing rendering artefacts. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=21708 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #56 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.7.45. -- 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