http://bugs.winehq.org/show_bug.cgi?id=13313
Summary: Half life 2 hangs with a high cpu usage at a certain point in the game Product: Wine Version: 1.0-rc1 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: asraniel@fryx.ch
Playing Half life 2 works fine, but at one point where alex wants to show me something on a computer screen (we just visited her father in prison), the game becomes extremely slow and i can't play anymore. The wine error messages give this message (multiple times): fixme:d3d_surface:fb_copy_to_texture_direct Doing a pixel by pixel copy from the fra mebuffer to a texture, expect major performance issues err:d3d_surface:fb_copy_to_texture_direct Texture filtering not supported in direct blit
Sadly this bug makes Half life 2 incomplete, since you can't play it from the start to the end.
http://bugs.winehq.org/show_bug.cgi?id=13313
Beat Wolf asraniel@fryx.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |asraniel@fryx.ch
http://bugs.winehq.org/show_bug.cgi?id=13313
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor
--- Comment #1 from Lei Zhang thestig@google.com 2008-05-19 17:48:41 --- what video card / driver version are you using?
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #2 from Beat Wolf asraniel@fryx.ch 2008-05-20 03:14:42 --- Hi, i'm using kubuntu 8.04 with wine rc1, i have a nvidia quadro nvs 140m card and i'm using the latest nvidia binary drivers (the one that ship with kubuntu 8.04, should be the latest)
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #3 from Beat Wolf asraniel@fryx.ch 2008-05-25 07:43:05 --- I could reproduce the bug with wine-rc2 But i found a "workaround". Waiting 2-3 minutes at that point in game brings back the normal speed, so i can finish playing hl 2.
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #4 from Austin English austinenglish@gmail.com 2008-11-23 15:42:44 --- Is this still an issue in current (1.1.9 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=13313
Sergei Vasilyev nolar@nolar.info changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nolar@nolar.info
--- Comment #5 from Sergei Vasilyev nolar@nolar.info 2009-01-09 11:37:59 --- This still an issue with 1.1.12 in Half-Life-2 Episone One (where that girl sees that reaction is out of control and says they specially did this, right at the moment when room with lift opens).
Restarting HL does not help. Everything fine until game is loaded. Then it begans to lag again. Waiting does not help (I've even passed this scene till lift goes down; this took ~30min for one room; but nothing changed).
Outout is exactly the same as in report above.
$ lspci | grep -i nvi 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600M GT (rev a1)
$ uname -r 2.6.27-9-generic
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 8.10 Release: 8.10 Codename: intrepid
$ dpkg-query -l wine* ii wine 1.1.12~winehq0~ubuntu~8. Microsoft Windows Compatibility Layer (Binary Emulator and Libra ii wine-dev 1.1.12~winehq0~ubuntu~8. Microsoft Windows Compatibility Layer (Development files) un wine-doc <нет> (описание недоступно) ii wine-gecko 0.9.0-0ubuntu1~hardy~ppa Microsoft Windows Compatibility Layer (Web Browser) un wine-utils <нет> (описание недоступно) un winesetuptk <нет> (описание недоступно)
(installed from http://wine.budgetdedicated.com/apt/).
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #6 from Sergei Vasilyev nolar@nolar.info 2009-01-09 12:42:20 --- PS#1: Appling the patch http://bugs.winehq.org/attachment.cgi?id=18409 from http://bugs.winehq.org/show_bug.cgi?id=12453 did not helped (though changed colors and textures in few places).
PS#2: When lift achieved its bottom position, speed had normalized by its own. I think there was some object or texture or something else near that point, and it triggered these errors:
fixme:d3d_surface:fb_copy_to_texture_direct Doing a pixel by pixel copy from the framebuffer to a texture, expect major performance issues err:d3d_surface:fb_copy_to_texture_direct Texture filtering not supported in direct blit fixme:d3d:state_zfunc D3DCMP_NOTEQUAL and D3DCMP_EQUAL do not work correctly yet fixme:d3d_surface:fb_copy_to_texture_direct Doing a pixel by pixel copy from the framebuffer to a texture, expect major performance issues err:d3d_surface:fb_copy_to_texture_direct Texture filtering not supported in direct blit ...
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #7 from Austin English austinenglish@gmail.com 2009-07-13 11:57:27 --- Is this still an issue in current (1.1.25 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=13313
Ralf Merkel bigbearman@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bigbearman@gmx.de
--- Comment #8 from Ralf Merkel bigbearman@gmx.de 2009-08-12 21:59:48 --- confirmin this bug with wine version 1.1.27. (self-compiled without patches) Details: Geforce 8600 GT (6600 GT also) driver is NVIDIA-Linux-x86-185.18.31-pkg1.run DX-lvl in hl2 is: 9.0
Game slows down extremly (0~1 FPS) when Alex shows the incoming forces on a screen, like said in first comment. After one minute the game is playable again. Drop me a line if you need further details.
http://bugs.winehq.org/show_bug.cgi?id=13313
Night Nord NightNord@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |NightNord@gmail.com
--- Comment #9 from Night Nord NightNord@gmail.com 2009-08-17 14:11:01 --- Just a note: This is a so-called "Monitor bug" and encountered every time you are watching on real remote camera display. That is - when object you are looking at is located in same map sector as you are and a monitor actually is a "portal" (gamedev terminology meaning, eh... camera re-projection point?) to another location. This is not affect camera-monitors in nova-prospect, as they are showing some kind of scripted scenes from other sectors and seems to be based on another algorithm.
Easiest workarond - lower dxlevel to minimal version and go ahead from this point. Bug was appearing, dissapearing and then re-appearing multiple times from wine-1.0_rc*. Interesting fact - on some dxlevel there is an image on the monitor, but no lags (maybe dxlevel 7?).
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #10 from Austin English austinenglish@gmail.com 2010-05-19 16:45:29 --- This is your friendly reminder that there has been no bug activity for 6 months. Is this still an issue in current (1.1.44 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #11 from Night Nord NightNord@gmail.com 2010-05-22 09:17:59 --- Yeap. It still caused on 44 wine. But it's impossible to be sure, as I'm running opensource radeon drivers, so there is tons of other problems, which may or may not interlace with that one.
http://bugs.winehq.org/show_bug.cgi?id=13313
Alexey Loukianov mooroon2@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mooroon2@mail.ru
--- Comment #12 from Alexey Loukianov mooroon2@mail.ru 2010-06-09 15:26:56 --- I can confirm that this bug still present in "Half-Life 2: Episode One", as described in comment #5. There's a workaround to get playable FPS: set the ORM to "fbo".
Unfortunately setting it to "fbo" breaks some game shaders when using Wine d3d miltisample (MSAA 2x or 4x, or any other level that may be forced using GPU drivers control panel) and causes some odd effects when playing with the HDR on like ones that were reported by Christoph Haag in comments section of the HL2:EP1 APPDB page.
http://bugs.winehq.org/show_bug.cgi?id=13313
Sense Hofstede qense@ubuntu.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |qense@ubuntu.com
--- Comment #13 from Sense Hofstede qense@ubuntu.com 2010-08-21 09:05:33 --- I can still confirm this bug on Wine 1.3 (wine-1.3.0) on Ubuntu 10.10 alpha, 64bit. The version of the closed Nvidia video drivers I'm using is '256.44-0ubuntu1', my video card is an Nvidia Geforce 9600GT.
http://bugs.winehq.org/show_bug.cgi?id=13313
Peter M Dodge twicescorned@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |twicescorned@gmail.com
--- Comment #14 from Peter M Dodge twicescorned@gmail.com 2010-12-12 21:00:15 CST --- I have experienced minor slowdowns in these animated monitor screens mentioned in this report, however, they are minimal ( <10fps ) My machine is Fedora 14 with the latest nVidia drivers compiled against kernel. It is worth noting that I have used winetricks to get the d3d drivers, which may affect the result.
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #15 from uuyns4tfez@snkmail.com 2011-03-02 00:36:53 CST --- Created an attachment (id=33500) --> (http://bugs.winehq.org/attachment.cgi?id=33500) Use fb_copy_to_texture_hwstretch in more cases.
The attached patch allows fb_copy_to_texture_hwstretch() to work in these situations, eliminating the need to use the per-pixel copying in fb_copy_to_texture_direct(). I have no idea what it does for Half Life 2, but it brings NWN2 from several seconds per frame to an almost playable ~5 fps or so when using "OffscreenRenderingMode"="backbuffer".
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #16 from Henri Verbeet hverbeet@gmail.com 2011-03-02 08:00:44 CST --- (In reply to comment #15)
The attached patch allows fb_copy_to_texture_hwstretch() to work in these situations, eliminating the need to use the per-pixel copying in fb_copy_to_texture_direct(). I have no idea what it does for Half Life 2, but it brings NWN2 from several seconds per frame to an almost playable ~5 fps or so when using "OffscreenRenderingMode"="backbuffer".
I haven't reviewed that patch properly, but the basic approach makes sense to me. Note that the size limitation is caused by the framebuffer size, not the source surface size.
http://bugs.winehq.org/show_bug.cgi?id=13313
uuyns4tfez@snkmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33500|0 |1 is obsolete| |
--- Comment #17 from uuyns4tfez@snkmail.com 2011-03-03 00:09:15 CST --- Created an attachment (id=33511) --> (http://bugs.winehq.org/attachment.cgi?id=33511) Use fb_copy_to_texture_hwstretch in more cases. (v2)
Updated version of the patch that actually copies into the right place in the destination, as well as eliminating some of the looping overhead.
http://bugs.winehq.org/show_bug.cgi?id=13313
uuyns4tfez@snkmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |uuyns4tfez@snkmail.com
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #18 from uuyns4tfez@snkmail.com 2011-03-03 00:14:53 CST ---
me. Note that the size limitation is caused by the framebuffer size, not the source surface size.
Not being at all familiar with this code, I'm not sure where to get the framebuffer size. The function sets:
UINT fbwidth = src_surface->currentDesc.Width; UINT fbheight = src_surface->currentDesc.Height;
I updated the patch to use those variables, even though they have the same values I was using before.
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #19 from Henri Verbeet hverbeet@gmail.com 2011-03-03 02:08:56 CST --- (In reply to comment #18)
Not being at all familiar with this code, I'm not sure where to get the framebuffer size. The function sets:
"src_surface->get_drawable_size(context, &fbwidth, &fbheight);" should do. I'm not sure the current code (before your patch) would handle this correctly though. I think fb_copy_to_texture_hwstretch() was written with the idea that it would always be used for copying the backbuffer to some other texture, but it may also be used for copying from some offscreen render target. The difference would mostly be significant when doing something like stretching from a small offscreen surface to the backbuffer to create a blur effect.
http://bugs.winehq.org/show_bug.cgi?id=13313
--- Comment #20 from Alexey Loukianov mooroon2@mail.ru 2011-09-11 05:56:53 CDT --- Looks like this bug had been fixed with following commit:
f58e55ec6c19d65689b273938f168287797362da is the first bad commit commit f58e55ec6c19d65689b273938f168287797362da Author: Henri Verbeet hverbeet@codeweavers.com Date: Mon Aug 22 21:02:42 2011 +0200
wined3d: Move arbfp based color blits from IWineD3DSurfaceImpl_BltOverride() to wined3d_surface_blt().
:040000 040000 691c677bfa118951a0ebe7ad76500a190f05370e 5370aba8157cc4e6b91ba1a8b19555e402e77a77 M dlls
Unfortunately I had come with a huge price: before this commit I had been way better FPS in HL2/EP1/HP2 in areas, not unaffected by this bug (i.e. at almost all places throughout mentioned games). When I say "way better" I mean FPS drop from around 150-200 down to 45-50. Should I report it as a new bug?
http://bugs.winehq.org/show_bug.cgi?id=13313
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #21 from Austin English austinenglish@gmail.com 2011-09-12 02:40:31 CDT --- (In reply to comment #20)
Looks like this bug had been fixed with following commit:
Fixed.
Unfortunately I had come with a huge price: before this commit I had been way better FPS in HL2/EP1/HP2 in areas, not unaffected by this bug (i.e. at almost all places throughout mentioned games). When I say "way better" I mean FPS drop from around 150-200 down to 45-50. Should I report it as a new bug?
Yes, please.
http://bugs.winehq.org/show_bug.cgi?id=13313
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org 2011-09-23 12:59:28 CDT --- Closing bugs fixed in 1.3.29.
http://bugs.winehq.org/show_bug.cgi?id=13313
Vitaliy Margolen vitaliy-bugzilla@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |f58e55ec6c19d65689b273938f1 | |68287797362da