[Bug 14038] New: Max Payne 2: bullet time screen filled with solid color
http://bugs.winehq.org/show_bug.cgi?id=14038 Summary: Max Payne 2: bullet time screen filled with solid color Product: Wine Version: 1.0.0 Platform: PC-x86-64 URL: http://www.rockstargames.com/maxpayne2/mp2_downloads.htm l OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: liquid.acid(a)gmx.net CC: alexd4(a)inbox.lv Created an attachment (id=14249) --> (http://bugs.winehq.org/attachment.cgi?id=14249) max payne 2 demo: screen when entering bullet time Hi there, entering bullet time mode in Max Payne 2 (tested with the demo), results in a screen with solid color. The game scene itself isn't visible anymore, so you have no control about movement and aiming direction. For details see the screenshot. I think it's a problem with the post-processing effects. Graphics setting are set to high (every option, except for anti-aliasing which is disabled). Resolution was 640x480 in 32 bit color mode. For logs see: http://bugs.winehq.org/show_bug.cgi?id=14031 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=14038 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jb.faq(a)gmx.de Keywords| |download -- 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=14038 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal --- Comment #1 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-06-21 12:44:46 --- Setting to normal because gameplay becomes really hard without bullet 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=14038 --- Comment #2 from Jan Buecken <jb.faq(a)gmx.de> 2008-06-22 08:23:11 --- Created an attachment (id=14271) --> (http://bugs.winehq.org/attachment.cgi?id=14271) not the same issue, maybe similar Don't have the problem with ati mobility radeon hd 2600 and ati-drivers 8.501, but I have glitches or something on the bottom. Don't know if this occurs in windows. Its playable. -- 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=14038 --- Comment #3 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-06-25 09:56:52 --- (In reply to comment #2)
Created an attachment (id=14271) --> (http://bugs.winehq.org/attachment.cgi?id=14271) [details] not the same issue, maybe similar
Don't have the problem with ati mobility radeon hd 2600 and ati-drivers 8.501, but I have glitches or something on the bottom. Don't know if this occurs in windows. Its playable.
I tested the game today on Jan's system and now the "glitched" part was not at the bottom, but a stripe at the right of the screen. Looked like some texture clamp issue. This was with "post-processing effects" set to "medium" in the MP2 options. OffscreenRenderingMode was left default (backbuffer). The glitch went away after switching "post-processing effects" to high. Setting OffscreenRenderingMode to fbo solved the problem also in the "medium" setting. I don't know about my system though, going to try it there with a non-default OffscreenRenderingMode this evening. 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=14038 --- Comment #4 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-06-25 15:50:51 --- Now for my Geforce FX 5900 based system. Again, the bug reported by me here appears when "post-processing effects" is set to "high" in the options menu. The OffscreenRenderingMode is "backbuffer". Here the entire screen is a solid color mess. Switching "post-processing effects" completly off solves the problem, but you don't get the additional eye candy ;-) Switching "post-processing effects" to "medium" kinda works, but results in a visual error like the one Jan reported. Going to attach another screenshot for that one. ------------------------------------- Now setting OffscreenRenderingMode to "fbo": "post-processing effects" = "medium": This configuration works, the scene is displayed with a sepia (?) filter. That's what I looks like when playing MP2 on a native Windows system. "post-processing effects" = "high": Same artifacts like OffscreenRenderingMode set 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=14038 --- Comment #5 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-06-25 15:52:32 --- Created an attachment (id=14361) --> (http://bugs.winehq.org/attachment.cgi?id=14361) Max Payne 2 demo: bullettime (partially working) this is with OffscreenRenderingMode = "fbo" and "post-processing effects" = "medium" Notice that the sepia filter works, but is cut off at the right. Also see the screenshot Jan posted, there the cutoff is at the bottom and a "texture clamping thing" is going on. -- 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=14038 --- Comment #6 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-08 16:58:10 --- I noticed a similar problem when playing Half-Life 2. During the intro sequence where the gman talks to you I don't see thing, it's simply a flickering solid color screen. As soon as this sequence ends and you sort of "wake up" in the train the graphics work again. I tried this both with backbuffer and fbo ORM, neither of them works. So HL2 probably triggers the same problem like MP2 with "postprocessing" set to high. Cheers, 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=14038 --- Comment #7 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-17 13:08:22 --- I just updated from nvidia-drivers-100.14.19 to version 173.14.09, and the problem is still there. I doubt this is a driver problem, trying to figure now if it's a regression. Also reconfirming with wine-1.1.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=14038 --- Comment #8 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-17 13:28:57 --- HL2 is equally impressed of the new driver -> gman is still hidden behind solid color wall. -- 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=14038 --- Comment #9 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-17 13:58:32 --- Also happens with wine-0.9.56, going back to wine-0.9.25 for the next test. -- 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=14038 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression --- Comment #10 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-17 15:01:25 --- wine-0.9.25: Works with post-processing set to high. But it is incredibly slow. So it seems like it's a regression... (adding 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=14038 --- Comment #11 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-17 15:08:33 --- Testing HL2 with wine-0.9.25 doesn't work since it won't start at all (some junk about unimplemented functions). Seems like I can only rely on MP2 for regression testing... -- 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=14038 --- Comment #12 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-18 14:10:57 --- wine-0.9.45: Works, but the rendered screen is confined to a subarea of the visible screen. Sepia effect is working 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=14038 --- Comment #13 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-18 14:14:45 --- wine-0.9.30: Same effect like 0.9.45 - regression testing 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=14038 --- Comment #14 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-18 14:20:45 --- Short note: Tested with current wine git master snapshot. Works now, but it is even slower than with wine-0.9.25 - like a frame every 5 seconds. -- 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=14038 --- Comment #15 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-18 14:22:01 --- Forgot to add: Everytime a frame is generated I can see this message on the console: fixme:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glReadBuffer @ surface.c / 917 -- 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=14038 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan(a)codeweavers.com --- Comment #16 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-18 19:27:31 --- Regression testing between wine-0.9.45 and wine-1.0.0: [d09cbcec91561186bee77aaba55b29cbf2d7e7ef] wined3d: Activate GL_ARB_texture_rectangle. Adding Stefan Dösinger to CC... I'm also gonna do a regression testing between git master and wine-1.0.0 to find out which commit brought back correct rendering (but left framerate crippled). But now I'm going to bed! :) 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=14038 Stefan Dösinger <stefandoesinger(a)gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger(a)gmx.at --- Comment #17 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2008-07-18 21:33:09 --- I guess the problem is related to conditional non power of two (NP2) textures and shaders, in which case c088edeae7fed4645fa3f34fb5bacc1eeaa87706 should have fixed the problem. Nvidia Geforce 6+ cards and Radeon HD 2000+ cards were never affected of the issue because they have unconditional NP2 support. If the game runs slow during the rendering of the former broken scenes, I can think of two possibilities: * There is a screen readback done which takes ages * There is a bug which causes Wine to overstep the limits of conditional NP2 textures, thus causing the driver to fall back to software rendering Since the bug report indicates that it was slow before the regression, and is even slower since the fix, I guess it's both cases. -- 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=14038 --- Comment #18 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 05:13:38 --- (In reply to comment #17)
If the game runs slow during the rendering of the former broken scenes, I can think of two possibilities: * There is a screen readback done which takes ages * There is a bug which causes Wine to overstep the limits of conditional NP2 textures, thus causing the driver to fall back to software rendering Since the bug report indicates that it was slow before the regression, and is even slower since the fix, I guess it's both cases.
No! You misread my report. I said it works with wine-0.9.25 and is slow there. The performance is quite good with wine-0.9.45, the only problem there is that the screen isn't filled completly. I can create a screenshot that shows that. So performance is only a problem with wine-0.9.25 and wine git master. We shouldn't look at wine-0.9.25 because the performance issue seemed to be solved between version 25 and 45. I can of course also regression test between 25 and 45 to find out where the performance improved (and where the screen shrink bug entered). -- 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=14038 --- Comment #19 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 05:29:42 --- To summarize current situation: - 0.9.25: Rendering in bullettime works, but is incridibly slow ---- performance is improved & subarea bug is introduced ---- - 0.9.45: Rendering works, performance OK, but rendered area is confined in subarea of visible screen ---- rendering breaks by introducing commit d09cbcec91561186bee77aaba55b29cbf2d7e7ef - 0.9.56: Rendering broken, flashing solid color is rendered to the screen - 1.0.0: Same as 0.9.56 - 1.1.0: Same as 1.0.0 ---- rendering is fixed, but performance is cripplied (*) - git master: Rendering works, but performance is worse than 0.9.25 (*) still have to find out which commit caused that @Stefan: Would it be helpful to also regress between 25 and 45, or is it useless? 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=14038 Frank Roscher <onety-three(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #20 from Frank Roscher <onety-three(a)gmx.net> 2008-07-19 05:34:56 --- *** This bug has been confirmed by popular vote. *** -- 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=14038 --- Comment #21 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 05:42:10 --- @Frank: Can you supply info about graphics card and drivers? 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=14038 Frank Roscher <onety-three(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |onety-three(a)gmx.net --- Comment #22 from Frank Roscher <onety-three(a)gmx.net> 2008-07-19 06:00:21 --- I'm on a GeForce FX 5700, driver version 169.12. The problem occurs for me not only in Max Payne 2, but also in FIFA 08; in current git the solid color has indeed been replaced by the proper 3D graphics, but the performance is very bad here as well. Curiously, Max Payne 2 now crawls (several seconds per frame) even on a "medium" postprocessing level - and in situations that had been running perfectly for a long time (about the start of the 0.9 series, I guess). -- 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=14038 --- Comment #23 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 06:43:47 --- (In reply to comment #22)
I'm on a GeForce FX 5700, driver version 169.12. The problem occurs for me not only in Max Payne 2, but also in FIFA 08; in current git the solid color has indeed been replaced by the proper 3D graphics, but the performance is very bad here as well. So maybe this is a problem only affecting the FX series... hmm, I don't have FIFA08 - so I cannot test this. Do yoo know if there is a demo out there, to reproduce the bug?
Curiously, Max Payne 2 now crawls (several seconds per frame) even on a "medium" postprocessing level - and in situations that had been running perfectly for a long time (about the start of the 0.9 series, I guess).
Hmm, I really didn't check this, but this would break MP2 a lot. Gonna do a test later this day... 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=14038 --- Comment #24 from Frank Roscher <onety-three(a)gmx.net> 2008-07-19 08:08:47 --- (In reply to comment #23)
So maybe this is a problem only affecting the FX series... hmm, I don't have FIFA08 - so I cannot test this. Do yoo know if there is a demo out there, to reproduce the bug? Google spat out this link: http://fifa2008.wordpress.com/fifa08-demo/ I just tested it, at least the first link there works. When I started a game there was some strange picture-in-picture action going on that maybe could be part of the problem. Didn't see this in my previous testing, though.
Hmm, I really didn't check this, but this would break MP2 a lot. Gonna do a test later this day... I'm referring specifically to the first scene of the game, with the wobbly screen implying Max' bad state of health.
-- 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=14038 --- Comment #25 from Frank Roscher <onety-three(a)gmx.net> 2008-07-19 09:12:16 --- I'm going to do a regression test for the performance regression in Max Payne 2 when using "medium" post-processing now. Probably I won't be able to finish it today, there's a lot of revisions to test and my CPU is fairly weak. I just wanted to mention it so that nobody else wastes his time doing 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=14038 --- Comment #26 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 10:00:45 --- The missing commit id is: [c088edeae7fed4645fa3f34fb5bacc1eeaa87706] wined3d: Use GL_ARB_texture_non_power_of_two emulation. This one fixes the rendering issue, but cripples performance ((*) in comment #19). Gonna do another test between 24 and 45 to complete the summary of the bug. NOTE that all the tests were done with post-processing effects set to high. 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=14038 --- Comment #27 from Frank Roscher <onety-three(a)gmx.net> 2008-07-19 11:26:34 --- Wow, my regression test is already finished. The result is exactly the same as in Tobias' test: c088edeae7fed4645fa3f34fb5bacc1eeaa87706 is first bad commit commit c088edeae7fed4645fa3f34fb5bacc1eeaa87706 Author: Stefan Dösinger <stefan(a)codeweavers.com> Date: Tue Jul 8 18:59:10 2008 -0500 wined3d: Use GL_ARB_texture_non_power_of_two emulation. So the performance regression when using "medium" post-processing effects (which worked before) has the same reason as the bad performance in the scenes that weren't rendered correctly before. By the way, I get the same message in the log that Tobias gets: fixme:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glReadBuffer @ surface.c / 917 -- 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=14038 Stefan Dösinger <stefandoesinger(a)gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|stefan(a)codeweavers.com | -- 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=14038 --- Comment #28 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2008-07-19 11:51:17 --- I don't think looking at old wine versions will help here. The patches pointed out switch the conditional NP2 support between different codepaths; Knowing which switch caused which behavior doesn't really give me further information. What would be useful to know is this: * Does your card support GL_ARB_texture_non_power_of_two? * Which opengl version does your driver advertise? Both informations can be queried with glxinfo. I suspect the answer to question 1 is NO, and the opengl version is 2.0. What the recent patch changed was that WineD3D now knows that OpenGL 2.0 implies GL_ARB_texture_non_power_of_two support in the driver. However, the Geforce 5 series do not support this. They only support GL_ARB_texture_rectangle, which is conditional support for NP2 textures. Thus if we assume unconditional support, we get software fallbacks. WineD3D has code to detect situations in which GL_ARB_texture_non_power_of_two is emulated, but so far only for ATI cards. This code is in directx.c, in the function fixup_extensions(), around line 3715 in today's git. The two important lines are: gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO] = FALSE; gl_info->supported[WINE_NORMALIZED_TEXRECT] = TRUE; For testing purposes, you can modify the code to run them unconditionally(ie, remove the if conditions around them), and see if that improves your performance. If it does, then you can modify the if conditions to blacklist ARB_TEXTURE_NON_POWER_OF_TWO and enable WINE_NORMALIZED_TEXRECT on GeForce FX cards. -- 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=14038 --- Comment #29 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 11:56:45 --- (In reply to comment #28)
I don't think looking at old wine versions will help here. The patches pointed out switch the conditional NP2 support between different codepaths; Knowing which switch caused which behavior doesn't really give me further information. OK, it don't bisect then :)
What would be useful to know is this: * Does your card support GL_ARB_texture_non_power_of_two? * Which opengl version does your driver advertise? My Geforce FX 5900 only provides (with driver version 173.14.09) the GL_ARB_texture_rectangle/GL_NV_texture_rectangle extension. The NPOT extension is not in the extension string. OpenGL version string: 2.1.2 NVIDIA 173.14.09
WineD3D has code to detect situations in which GL_ARB_texture_non_power_of_two is emulated, but so far only for ATI cards. This code is in directx.c, in the function fixup_extensions(), around line 3715 in today's git.
The two important lines are: gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO] = FALSE; gl_info->supported[WINE_NORMALIZED_TEXRECT] = TRUE;
For testing purposes, you can modify the code to run them unconditionally(ie, remove the if conditions around them), and see if that improves your performance. If it does, then you can modify the if conditions to blacklist ARB_TEXTURE_NON_POWER_OF_TWO and enable WINE_NORMALIZED_TEXRECT on GeForce FX cards.
I'm going to try that out. 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=14038 --- Comment #30 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 12:36:58 --- Removed the if-condition, so it's now always gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO] = FALSE; gl_info->supported[WINE_NORMALIZED_TEXRECT] = TRUE; Doesn't fix the performance though. It's even worse -> the intro videos now also have low performance. Going to try with postprocessing effect set to medium. -- 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=14038 --- Comment #31 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 12:43:39 --- First of all, the fixme:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glReadBuffer @ surface.c / 917 messages are still there. Every time a frame is rendered in bt mode. With PPE set to medium the problem remains. Removing the hack: PPE=medium: Doesn't make any difference, performance is equally worse than with high PP effects. So the hack only makes the bug worse, any other 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=14038 --- Comment #32 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 12:50:21 --- For reference, it resetted ORM to "backbuffer" to see what kind of differences the last wined3d commits make. Hack is still removed: PPE=medium: See http://bugs.winehq.org/attachment.cgi?id=14361 for the effect Performance is OK PPE=high: Rendering OK, but performance BAD Comparing to ORM=FBO the backbuffer performance is a bit better Testing with hack applied 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=14038 --- Comment #33 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 12:56:07 --- Hack is applied (ORM=backbuffer): PPE=medium: Intro video performance BAD, bt screen same like without hack PPE=high: Intro video performance BAD, bt screen same like without hack Like with fbo the hack makes it worse with 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=14038 --- Comment #34 from Frank Roscher <onety-three(a)gmx.net> 2008-07-19 13:17:36 --- My extensions and the OpenGL version string are the same as Tobias' (with the exception of a different driver version), and the hack seems to have no positive or negative effect on 3D performance whatsoever. As noted the intro video in Max Payne 2 doesn't work anymore when the hack is applied. -- 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=14038 --- Comment #35 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 13:19:48 --- Needless to say the commits also break HL2 beyond playability, since you cannot skip the gman intro sequence... -- 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=14038 --- Comment #36 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-19 14:06:17 --- (In reply to comment #34)
As noted the intro video in Max Payne 2 doesn't work anymore when the hack is applied. It's no working anymore completly for you? For me it works, but like the bt mode it's REALLY slow and takes an insane amount of time to show up (and draw the next frame).
-- 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=14038 --- Comment #37 from Frank Roscher <onety-three(a)gmx.net> 2008-07-19 14:34:36 --- (In reply to comment #36)
It's no working anymore completly for you? For me it works, but like the bt mode it's REALLY slow and takes an insane amount of time to show up (and draw the next frame). Sorry, yes, it's very slow but it works. Probably doesn't make much of a difference for the bug itself, 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=14038 --- Comment #38 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-22 15:40:39 --- Hi there! To summarize the state of the problem with latest wine git master: (1) ORM=backbuffer, PPE=medium: performance is OK, screen is cropped (http://bugs.winehq.org/attachment.cgi?id=14361) no messages emitted to console (2) ORM=backbuffer, PPE=high: performance is BAD, screen is rendered OK no messages emitted to console (3) ORM=fbo, PPE=medium: performance is BAD, screen is rendered OK fixme message is emitted to console "fixme:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glReadBuffer @ surface.c / 917" (4) ORM=fbo, PPE=high: Same as (3) So the only way to get any decent gameplay is using backbuffer ORM and living wit the cropped screen. @Frank: Can you verify this with latest git? 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=14038 --- Comment #39 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-22 15:50:08 --- Further info: The cropping bug does not only affect the bullettime post-processing effect, but all cutscenes where PP effects are 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=14038 --- Comment #40 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-22 16:36:41 --- Created an attachment (id=14990) --> (http://bugs.winehq.org/attachment.cgi?id=14990) WINEDEBUG=+d3d_surface trace I made a trace with ORM=fbo and PPE=medium. Since the gl error appears in surface.c I enabled the d3d_surface channel. trace:d3d_surface:surface_get_gl_buffer (0x146768) : swapchain 0x15a1b0 trace:d3d_surface:surface_get_gl_buffer Returning GL_BACK trace:d3d_surface:read_from_framebuffer_texture Locking 0x405 buffer fixme:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glReadBuffer @ surface.c / 917 trace:d3d_surface:surface_allocate_surface (0x146768) : Creating surface (target 0xde1) level 0, d3d format WINED3DFMT_X8R8G8B8, internal format 0x8051, width 800, height 600, gl format 0x80e1, gl type=0x8367 Seems like glReadBuffer doesn't like GL_BACK 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=14038 --- Comment #41 from H. Verbeet <hverbeet(a)gmail.com> 2008-07-23 01:58:49 --- The problem there is that glReadBuffer(GL_BACK) isn't valid when an FBO is bound. The deeper cause has to do with the order of apply_fbo_state(), ActivateContext() and LoadLocation() in places like Clear() and DrawPrimitive(). I've got some patches for this in my tree, and they'll likely fix this 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=14038 --- Comment #42 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-23 04:19:00 --- Hi Henri, can you possibly attach the patches so I can test them? Could it also be that the patches fix the performance problems? At least with ORM set to fbo, since with ORM=backbuffer the GL errors don't appear at all (and performance is also bad). Thanks, 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=14038 --- Comment #43 from H. Verbeet <hverbeet(a)gmail.com> 2008-07-23 07:00:41 --- The patches need some cleaning up, but I'll attach them later today for you to try out. I doubt they'll do much to improve performance though. I suspect the GeForce FX is simply hitting a software fallback somewhere. -- 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=14038 --- Comment #44 from Frank Roscher <onety-three(a)gmx.net> 2008-07-23 07:37:57 --- (In reply to comment #38) I get the same results with one exception: In case (1) everything is rendered correctly for me, no cropped screen. -- 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=14038 --- Comment #45 from H. Verbeet <hverbeet(a)gmail.com> 2008-07-23 15:50:39 --- Created an attachment (id=15013) --> (http://bugs.winehq.org/attachment.cgi?id=15013) FBO fixes -- 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=14038 --- Comment #46 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-23 18:05:09 --- Thanks Henri, I tested your patch and it seems to remove the error message. But: (i) As you said the performance problem in bullettime is untouched by this (ii) Performance is now worse (**) (iii) There is now a new GL error message displayed (*) (*) Even without bullettime mode, the console is filled with this errors: fixme:d3d_shader:shader_glsl_deselect_depth_blt >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glUseProgramObjectARB @ glsl_shader.c / 3411 (**) As soon as the window area of the first hospital room comes into view the performance collapses (See the last screenshot or get the demo). If the windows are not in the field of view then performance is normal. I'm trying to find a few other places that also have this effect. I could imagine that the window glass is also rendered with some kind of FB postprocessing effect.... So to make it short, it's not really working for me with the patch. Seems like we're opening a Pandora box here :( 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=14038 --- Comment #47 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-23 18:14:45 --- I disabled PPE in the MP2 options completly and the problem remains. - the console messages are still generated (***) - when a window comes into FOV performance goes "out the window" *g* - cutscenes are also affected by the slowdown (***) Seems like the messages are not generated every frame, still trying to figure out what triggers them. I could see new ones appearing during the cutscenes. I also encountered these ones: err:d3d_surface:IWineD3DSurfaceImpl_LoadLocation Reading back render target but SFLAG_INDRAWABLE not set 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=14038 --- Comment #48 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-23 18:20:25 --- My next check with PPE=high: Screen turns black as soon as I press the bt key, only the HUD is displayed, nothing more. Also a lot of these message fill up the console: fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glDrawElements @ drawprim.c / 269 fixme:d3d:check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED_EXT (0x8cdd) fixme:d3d:check_fbo_status Color attachment 0: (0x12da178) WINED3DFMT_A8R8G8B8 800x600 fixme:d3d:check_fbo_status Depth attachment: (0x12da298) WINED3DFMT_D24S8 800x600 fixme:d3d:check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED_EXT (0x8cdd) fixme:d3d:check_fbo_status Color attachment 0: (0x12da178) WINED3DFMT_A8R8G8B8 800x600 fixme:d3d:check_fbo_status Depth attachment: (0x12da298) WINED3DFMT_D24S8 800x600 I'm now switching to ORM=backbuffer and check what the patch does 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=14038 --- Comment #49 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-23 18:28:28 --- ORM=backbuffer: PPE=off: Performance OK, no strange messages on console, rendering OK (no sepia effect of course) PPE=medium: Performance OK, no console messages, rendering OK apart from the cropping issue (sepia works) PPE=high: Performance OK for normal gameplay, Performance BAD as soon as FB effect are used, like bullettime or the cutscenes, no console messages, rendering OK and no cropping So backbuffer mode isn't touched by the patch. 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=14038 --- Comment #50 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-07-24 10:17:45 --- With current git and ORM=fbo everything is working for me. Everything at the maximum except anti-aliasing = off. This is with demo not the full game. Can you confirm you are testing this with demo? Henri's patch has no affect for me except removal of these messages: fixme:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glReadBuffer @ ../../../wine.git/dlls/wined3d/surface.c / 920 -- 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=14038 --- Comment #51 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-24 11:24:13 --- (In reply to comment #50) > With current git and ORM=fbo everything is working for me. Everything at the > maximum except anti-aliasing = off. Gonna check this evening. What do you mean with "everything"? I have a lot of bugs with the game: - shadow volume border bug - bullettime/postprocessing bugs - pixelshader skin bug Only to name a few... > This is with demo not the full game. Can you confirm you are testing this with > demo? Yeah, read my first post. I can check with the full game if Stefan or Henri want it, but I think as long as the demo does perform so bad like it currently does it's no use to begin playing the real one... > Henri's patch has no affect for me except removal of these messages: > > fixme:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> > GL_INVALID_ENUM (0x500) from glReadBuffer @ > ../../../wine.git/dlls/wined3d/surface.c / 920 > Negative, like I mentioned above the patch kills them but brings new/different ones.. Cheers, 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=14038 --- Comment #52 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-24 13:02:23 --- Latest git master snapshot: It's even worse (tested with ORM=fbo). Now even PPE=medium does emit these messages I already mentioned in comment #48. Screen doesn't go black though. PPE=high also does emit these messages, but screen is black there. I figured out that this message block is emitted in PPE=high mode each time a frame is rendered (you still see the HUD so you know when the screen should be updated): fixme:d3d:check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED_EXT (0x8cdd) fixme:d3d:check_fbo_status Color attachment 0: (0x1456a8) WINED3DFMT_X8R8G8B8 800x600 fixme:d3d:check_fbo_status Depth attachment: (0x1513d8) WINED3DFMT_D24S8 800x600 fixme:d3d_shader:shader_glsl_deselect_depth_blt >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glUseProgramObjectARB @ glsl_shader.c / 3446 fixme:d3d:check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED_EXT (0x8cdd) fixme:d3d:check_fbo_status Color attachment 0: (0x3ef04f8) WINED3DFMT_A8R8G8B8 800x600 fixme:d3d:check_fbo_status Depth attachment: (0x3ef0618) WINED3DFMT_D24S8 800x600 fixme:d3d:IWineD3DDeviceImpl_ClearSurface >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glClear @ device.c / 5130 fixme:d3d:check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED_EXT (0x8cdd) fixme:d3d:check_fbo_status Color attachment 0: (0x3ef04f8) WINED3DFMT_A8R8G8B8 800x600 fixme:d3d:check_fbo_status Depth attachment: (0x3ef0618) WINED3DFMT_D24S8 800x600 fixme:d3d:IWineD3DDeviceImpl_ClearSurface >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glClear @ device.c / 5130 fixme:d3d:check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED_EXT (0x8cdd) fixme:d3d:check_fbo_status Color attachment 0: (0x3ef04f8) WINED3DFMT_A8R8G8B8 800x600 fixme:d3d:check_fbo_status Depth attachment: (0x3ef0618) WINED3DFMT_D24S8 800x600 fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glDrawElements @ drawprim.c / 269 fixme:d3d:check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED_EXT (0x8cdd) fixme:d3d:check_fbo_status Color attachment 0: (0x3ef04f8) WINED3DFMT_A8R8G8B8 800x600 fixme:d3d:check_fbo_status Depth attachment: (0x3ef0618) WINED3DFMT_D24S8 800x600 (repeats a lot) fixme:d3d_draw:drawStridedSlow >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glEnd and previous calls @ drawprim.c / 572 fixme:d3d:check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED_EXT (0x8cdd) fixme:d3d:check_fbo_status Color attachment 0: (0x3ef0c30) WINED3DFMT_A8R8G8B8 800x600 fixme:d3d_draw:drawStridedSlow >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glEnd and previous calls @ drawprim.c / 572 fixme:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glReadBuffer @ surface.c / 920 fixme:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glCopyTexSubImage2D @ surface.c / 943 -- 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=14038 --- Comment #53 from Alexander Dorofeyev <alexd4(a)inbox.lv> 2008-07-24 15:03:39 --- My experiences with current git (all details / effects on high, no antialiasing and no triple buffering, card geforce 6100): 1) I see no problems with bullet time or with screen cropping in either backbuffer or fbo. Everything looks ok with the exception of known bugs - shadow and character lightening. 2) Performance with fbo - very bad indeed. I have these 0.5-1 sec freezes like every second or so, between them everything is relatively smooth. I know my card isn't a gaming powerhouse, but I see nothing like that in backbuffer mode. FBO mode is several times worse because of these stalls all the time, kinda strange as it's supposed to be faster (?). I think I have also experienced a similar annoyance in HL2 / fbo (need to retest, I didn't compare it to backbuffer there). 3) Henri's patch makes GL_INVALID_ENUM message go away, but another message starts to appear as Tobias also mentions (Reading back render target but SFLAG_INDRAWABLE not set). Doesn't seem to change much else. Performance stays as it was too. Could it be that these older cards just suck at supporting fbo? So all of the rendering issues appear to be specific to geforce 5 (5 and below?) series. -- 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=14038 --- Comment #54 from Frank Roscher <onety-three(a)gmx.net> 2008-07-24 15:42:47 --- (In reply to comment #53)
So all of the rendering issues appear to be specific to geforce 5 (5 and below?) series. I'd like to emphasize again that I don't get any rendering issues anymore either, and that's on a 5 series card.
The only problem left is the abysmal performance - and as already noted above it has gotten even worse in current git. Probably there are two or more bugs (or however you want to call them) responsible for that now, one specific to the 5 series and one that is more general. Anyway, the original issue this bug report was concerned with has been fixed; we're still discussing here because the fix seems to be responsible for a part of the performance problems. -- 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=14038 --- Comment #55 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-07-24 16:14:04 --- (In reply to comment #51)
Gonna check this evening. What do you mean with "everything"? This bug is about BT only. So that is what I'm talking about.
This is with demo not the full game. Can you confirm you are testing this with demo? Yeah, read my first post. Just double-checking - some bugs are different between demo and full game. And some were present in the full game only.
The only messages I see are the SFLAG_INDRAWABLE. It seems like you are hitting a different problem here (in combination to FBO maybe). Also don't forget that with FBO most games select different code paths because of more advanced features available. What video drivers do you currently have? I can't say anything about the performance - 8800GT handles everything just fine. -- 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=14038 --- Comment #56 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-25 08:08:33 --- (In reply to comment #55)
What video drivers do you currently have? nvidia-drivers-100.14.19, updating to version 169.09-r1 doesn't change a bit for me.
My point is that it was working before. At least with PPE=medium, but now even that isn't possible. -- 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=14038 --- Comment #57 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-07-26 13:56:25 ---
nvidia-drivers-100.14.19, updating to version 169.09-r1 doesn't change a bit for me. Latest driver version is 173.14.09. Please upgrade and retest.
-- 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=14038 --- Comment #58 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-27 13:05:03 --- (In reply to comment #57)
Latest driver version is 173.14.09. Please upgrade and retest. No change at all.
-- 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=14038 --- Comment #59 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-28 14:52:47 --- Anyway should I close this one (and resolve to FIXED) and open a new one with updated 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=14038 --- Comment #60 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-28 16:26:43 --- @Frank Roscher: Remember the cropping issue in backbuffer mode that I had? The one you couldn't reproduce. I think it's dependent on ingame resolution. It tried ORM=backbuffer and PPE=medium. With 800x600 the cropping is there in bullettime mode (and also when fb effects are used in the cutscenes). With 1024x768 the issue is gone. Could you possible check this on your card? I'm also going to check the other resolutions you can select in the launcher. 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=14038 --- Comment #61 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-28 16:35:46 --- The rest of the tests: 640x480: cropping, but now the black bar is at the bottom 1152x864: cropping, again at the bottom 1280x1024: no cropping This leaves me with two working res: 1024x768 and 1280x1024 Notice that cropping is either done from the right or from the bottom. Also note that both working res have a POT dimension in 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=14038 --- Comment #62 from Frank Roscher <onety-three(a)gmx.net> 2008-07-29 02:59:31 --- (In reply to comment #61) I can confirm your results using virtual desktop (either the nVidia drivers or my monitor suck, I'll need to create custom modelines for the other resolutions) I just noticed I still had ORM=fbo and GLSL=disabled... switching to ORM=backbuffer fixes the performance problems with medium postprocessing, switching to GLSL=enabled makes the postprocessed scenes (plus Max in normal scenes) solid colored again. It's quite a mess, splitting up into different bug reports would probably be a good idea. -- 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=14038 --- Comment #63 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-29 08:21:04 --- I splitted the ORM backbuffer cropping issue of into bug #14686. 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=14038 --- Comment #64 from Alexander Dorofeyev <alexd4(a)inbox.lv> 2008-07-29 11:37:56 --- I can reproduce this problem on my card (bullet time filled with solid color) with git by commenting out the line with GL_ARB_texture_non_power_of_two in wined3d/directx.c or doing gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO] = FALSE; Also lots of these messages appear: fixme:d3d:transform_texture Non-power2 texture being used with generated texture coords Not sure if it means anything :/. Considering that it's not supposedly fixed on geforce5 that doesn't have this extension, this confuses 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=14038 --- Comment #65 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-29 12:27:09 --- (In reply to comment #64)
I can reproduce this problem on my card (bullet time filled with solid color) with git by commenting out the line with GL_ARB_texture_non_power_of_two in wined3d/directx.c or doing
gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO] = FALSE;
Also lots of these messages appear:
fixme:d3d:transform_texture Non-power2 texture being used with generated texture coords
Not sure if it means anything :/. Considering that it's not supposedly fixed on geforce5 that doesn't have this extension, this confuses me.
Hmm, wasn't there an issue with non_power_of_two textures on the FX? I think it was not explicitly advertised in the GL extensions string, but the OpenGL version reported by the driver indicated that the extension should be supported (since it's core in this version). However the FX only supports the texture_rectangle with good performance. Does this seem correct? At least that's what I read from Stefan Dösinger in comment #28. ------------------------------------------------- Like already explained in bug #14686 I could test this issue today on a Radeon card (thanks to Jan again!): Graphics card: ATI Mobility Radeon HD2600 Drivers: ati-drivers-8.512 (=8.7, =8.51.3) (fglrx) Test was done with latest wine git master (snapshot from today): last commit = 6a21ab270b2a9dc04ad38714f410e1ab27872f02 ORM is fbo, GLSL is disabled for the application. Ingame settings: PPE=medium pixel shader skins=off I tested all resolutions available (640x480, 800x600, 1024x768, 1280x800) and all of them work (no crop issue), BUT: (i) Performance is slower than backbuffer (ii) Console is flooded with FIXMEs (*) This doesn't change when switching PPE to high. Performance still is worse and FIXMEs are still there (and the same). (*): fixme:d3d_surface:read_from_framebuffer_texture >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glReadBuffer @ surface.c / 920 Since we didn't have that much time I only made one performance comparison. ORM=fbo, PPE=high, res=1024x768: normal mode: around 19 fps bullettime mode: around 13 fps OK, that's with fbo mode and is already kinda slow (in bt mode). Switching to backbuffer: ORM=backbuffer, PPE=high, res=1024x768: normal mode: around 21 fps bullettime mode: around 21 fps As you can see switching to bt mode with backbuffer ORM doesn't affect the performance in any way. Consider now that fbo should deliver an improvement to the performance. Test was done from nearly the same ingame position. And even if it was not exactly the same: it's the difference between the fps values. In fbo mode the FB processing increases frame rendering time from 52.6 to 76.9 ms. That's a plus of 24.3 ms, a lot if you ask me. 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=14038 --- Comment #66 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-08-01 20:11:07 --- I opened a new bug here: http://bugs.winehq.org/show_bug.cgi?id=14724 It should only focus on the performance issues with ORM=fbo. Still there are also performance problems with backbuffer, so I keep this one open for a while. 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=14038 Tobias Jakobi <liquid.acid(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #67 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-08-04 09:05:17 --- This bug is mostly about performance issues, furthermore it grew quite large because of lots of other issues found out by regression testing. Since the major problem (the performance issue) is now fixed, I'm resolving this one to FIXED. I'm going to open new bugs for the remaining issues, like the now resurrected solid color bug. Hopefully this time with a clearer bugreport. 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=14038 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #68 from Alexandre Julliard <julliard(a)winehq.org> 2008-08-22 10:47:27 --- Closing bugs fixed in 1.1.3. -- 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