http://bugs.winehq.org/show_bug.cgi?id=16456
Summary: GL_OUT_OF_MEMORY Product: Wine Version: 1.1.10 Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: damron@mytech.wvutech.edu
GL_OUT_OF_MEMORY crashes sins of a solar empire after several minutes.
apply patch to fix... if game gets slow during press ctrl alt f1, then switch back to x using ctrl alt f7 i think. thats another fix for another day
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #1 from doug damron@mytech.wvutech.edu 2008-12-10 16:01:55 --- Created an attachment (id=17813) --> (http://bugs.winehq.org/attachment.cgi?id=17813) fixes GL_OUT_OF_MEMORY
http://bugs.winehq.org/show_bug.cgi?id=16456
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|GL_OUT_OF_MEMORY |Sins of a solar empire: | |GL_OUT_OF_MEMORY
--- Comment #2 from Lei Zhang thestig@google.com 2008-12-10 18:37:46 --- That's not really a fix. Let's diagnose this properly:
a. What Linux distro / Video card / Video driver are you using?
b. Can you reproduce the problem with the sins demo?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #3 from doug damron@mytech.wvutech.edu 2008-12-10 19:16:44 --- (In reply to comment #2)
That's not really a fix. Let's diagnose this properly:
a. What Linux distro / Video card / Video driver are you using?
b. Can you reproduce the problem with the sins demo?
This is more of a workaround, i was incorrect in calling it a fix.
I can say that this problem has happened on several linux distros including gentoo and fedora (8&9), i'm not sure what nvidia drivers where used, but there were multiple versions. Also, it has happened in multiple versions of the game.
http://bugs.winehq.org/show_bug.cgi?id=16456
doug damron@mytech.wvutech.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P4
--- Comment #4 from doug damron@mytech.wvutech.edu 2008-12-10 19:40:03 --- (In reply to comment #2)
That's not really a fix. Let's diagnose this properly:
a. What Linux distro / Video card / Video driver are you using?
b. Can you reproduce the problem with the sins demo?
The error is caused by a memory leak in Sins of a Solar Empire. Presumably, the Windows implementation of Direct3D uses system RAM for textures in the IWineD3DSurface interface. In wine's implementation, it uses pixel buffer objects if the video card supports it. This is because it is faster to do it this way. Unfortunately, video cards have much less memory and therefore this memory leak fills up video memory rather quickly and causes the GL_OUT_OF_MEMORY error when it requests another Pixel Buffer Object. The work around is to simply disable pixel buffer objects for Direct3d Surfaces so that the memory leak occurs in system memory. This will work for every video card that supports pixel buffer objects (which would be any video card that can run Sins of a Solar Empire). This is a fix solely for SoaSE and shouldn't be committed to wine's source tree.
http://bugs.winehq.org/show_bug.cgi?id=16456
Thomas A thomasa88+winebug@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thomasa88+winebug@gmail.com
--- Comment #5 from Thomas A thomasa88+winebug@gmail.com 2008-12-11 15:51:43 --- Even if this is a memory leak in soase shouldn't wine automatically start using the system memory when the video memory is full (for applications that allocates a lot of memory for graphics)? (Or are there other things that needs to go into video memory but can't because it's full?)
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #6 from Thomas A thomasa88+winebug@gmail.com 2008-12-11 16:23:45 --- I can confirm this bug, I also can confirm that this fix seems to work.
Bug info: OS: Gentoo (full system update some months ago) Wine: 1.1.10 Video card: Geforce 9600gt Driver: nvida-drivers-177.82 Soase version: 1.05
Here is head and tail of dump with WINEDEBUG=+opengl,+d3d,+trace
E: shm.c: Invalid shared memory segment size E: shm.c: Invalid shared memory segment size E: shm.c: Invalid shared memory segment size E: shm.c: Invalid shared memory segment size E: shm.c: Invalid shared memory segment size E: shm.c: Invalid shared memory segment size trace:d3d:DllMain WineD3D DLLMain Reason=1 trace:d3d:DllMain Allow pixel shaders trace:d3d:DllMain Use 512MB = 536870912 byte for emulated_textureram trace:d3d:DllMain Allow HW vertex shaders trace:d3d:DllMain If supported by your system, GL Shading Language will be used err:ole:CoGetClassObject class {9a5ea990-3034-4d6f-9128-01f3c61022bc} not registered err:ole:CoGetClassObject no class object {9a5ea990-3034-4d6f-9128-01f3c61022bc} could be created for context 0x1 trace:d3d:InitAdapters Initializing adapters trace:d3d:InitAdapters Initializing default adapter trace:d3d:WineD3D_CreateFakeGLContext getting context... trace:d3d:WineD3D_CreateFakeGLContext incrementing ref from 0 fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers trace:d3d:test_arb_vs_offset_limit OpenGL implementation allows offsets > 63 trace:d3d:test_arb_vs_offset_limit ARB vp offset limit test cleanup call ok directx.c / 480 trace:d3d:IWineD3DImpl_FillGLCaps extension detection call ok directx.c / 1011 trace:d3d:InitAdapters Emulating 512MB of texture ram fixme:win:EnumDisplayDevicesW ((null),0,0x33f90c,0x00000000), stub! trace:d3d:InitAdapters DeviceName: L"\\.\DISPLAY1" trace:d3d:InitAdapters iPixelFormat=1, iPixelType=0x202b, doubleBuffer=1, RGBA=8/8/8/0, depth=24, stencil=8, windowDrawable=1, pbufferDrawable=1 trace:d3d:InitAdapters iPixelFormat=2, iPixelType=0x202b, doubleBuffer=1, RGBA=8/8/8/0, depth=24, stencil=8, windowDrawable=1, pbufferDrawable=1 trace:d3d:InitAdapters iPixelFormat=3, iPixelType=0x202b, doubleBuffer=1, RGBA=8/8/8/8, depth=24, stencil=8, windowDrawable=1, pbufferDrawable=1 trace:d3d:InitAdapters iPixelFormat=4, iPixelType=0x202b, doubleBuffer=1, RGBA=8/8/8/8, depth=24, stencil=8, windowDrawable=1, pbufferDrawable=1
[..............]
trace:d3d:ActivateContext (0x159ea0): Selecting context for render target 0x1754d8, thread 9 trace:d3d:ActivateContext (0x159ea0): Selecting context for render target 0x1754d8, thread 9 trace:d3d:ActivateContext (0x159ea0): Selecting context for render target 0x1754d8, thread 9 trace:d3d:ActivateContext (0x159ea0): Selecting context for render target 0x1754d8, thread 9 trace:d3d:IWineD3DDeviceImpl_CreateTexture (0x159ea0) : Width 256, Height 256, Levels 1, Usage 0 trace:d3d:IWineD3DDeviceImpl_CreateTexture Format 0x15 (WINED3DFMT_A8R8G8B8), Pool 0x1, ppTexture 0x1d6db8e0, pSharedHandle (nil), parent 0x1d6db8d8 trace:d3d:IWineD3DDeviceImpl_AddResource (0x159ea0) : Adding Resource 0x1e0e0950 trace:d3d:IWineD3DDeviceImpl_CreateTexture (0x159ea0) : Created resource 0x1e0e0950 trace:d3d:IWineD3DDeviceImpl_CreateTexture xf(1.000000) yf(1.000000) trace:d3d:IWineD3DDeviceImpl_CreateSurface (0x159ea0) Create surface trace:d3d:IWineD3DDeviceImpl_AddResource (0x159ea0) : Adding Resource 0x6f144b8 trace:d3d:IWineD3DDeviceImpl_CreateSurface (0x159ea0) : Created resource 0x6f144b8 trace:d3d:IWineD3DDeviceImpl_CreateSurface Pool 1 0 1 2 trace:d3d:IWineD3DDeviceImpl_QueryInterface (0x159ea0)->({3c2aebf6-6f30-11d9-c687-00046142c14f},0x33f0bc) trace:d3d:IWineD3DDeviceImpl_CreateSurface (0x159ea0) : w(256) h(256) fmt(21,WINED3DFMT_A8R8G8B8) lockable(0) surf@0x6f144b8, surfmem@0x1ec2c480, 262144 bytes trace:d3d:IWineD3DDeviceImpl_CreateTexture Created surface level 0 @ 0x6f144b8 trace:d3d:IWineD3DDeviceImpl_CreateTexture (0x159ea0) : Created texture 0x1e0e0950 trace:d3d:ActivateContext (0x159ea0): Selecting context for render target 0x1754d8, thread 9 fixme:d3d_surface:surface_prepare_system_memory >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glBufferDataARB @ surface.c / 1013 trace:d3d:ActivateContext (0x159ea0): Selecting context for render target 0x1754d8, thread 9 fixme:d3d_surface:IWineD3DSurfaceImpl_LockRect >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glMapBufferARB @ surface.c / 1160 err:module:load_builtin_dll failed to load .so lib for builtin L"winedos.dll": /usr/bin/../lib32/wine/winedos.dll.so: failed to map segment from shared object: Cannot allocate memory err:dosmem:load_winedos Could not load winedos.dll, DOS subsystem unavailable err:module:load_builtin_dll failed to load .so lib for builtin L"DBGHELP.DLL": /usr/bin/../lib32/wine/dbghelp.dll.so: failed to map segment from shared object: Cannot allocate memory fixme:faultrep:ReportFault 0x33ee50 0x0 stub trace:d3d:DllMain WineD3D DLLMain Reason=0 fixme:winmm:MMDRV_Exit Closing while ll-driver open fixme:winmm:MMDRV_Exit Closing while ll-driver open wine: Unhandled page fault on write access to 0x32ac087e at address 0xf7ccc29e (thread 0009), starting debugger... err:seh:raise_exception Unhandled exception code c000013a flags 0 addr 0xffffe42e
http://bugs.winehq.org/show_bug.cgi?id=16456
enterman enterman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |enterman@gmail.com
--- Comment #7 from enterman enterman@gmail.com 2008-12-20 02:42:34 --- im sorry but I dont quite understand what to do with the patch file listed on this page?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #8 from Austin English austinenglish@gmail.com 2008-12-20 05:11:35 --- (In reply to comment #7)
im sorry but I dont quite understand what to do with the patch file listed on this page?
http://wiki.winehq.org/Patching
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #9 from enterman enterman@gmail.com 2008-12-20 14:32:10 --- (In reply to comment #8)
(In reply to comment #7)
im sorry but I dont quite understand what to do with the patch file listed on this page?
do I just download the attachment file? I dont quite understand what to save exactly. Opening the patch thing just brings me to a page with a lot of text.
http://bugs.winehq.org/show_bug.cgi?id=16456
ddcc d.c.ddcc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d.c.ddcc@gmail.com
--- Comment #10 from ddcc d.c.ddcc@gmail.com 2008-12-20 23:30:35 --- Yes, you save it and name it something like patch.diff. But you need to download wine's source first, then apply the patch. After that, you need to compile wine.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #11 from enterman enterman@gmail.com 2008-12-21 01:31:19 --- well I downloaded and applied the patch but when I tried to compile wine I get errors. These are the last lines in my Terminal:
make_ctests.c makedep.c relpath.c sfnt2fnt.c Makefile: Permission denied make[1]: [Makefile] Error 1 (ignored) make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/enterman/Desktop/wine-1.1.11/tools' make[1]: Entering directory `/home/enterman/Desktop/wine-1.1.11/dlls' make[2]: Entering directory `/home/enterman/Desktop/wine-1.1.11/dlls/acledit' ../../tools/makedep -C. -S../.. -T../.. main.c Makefile: Permission denied make[2]: [Makefile] Error 1 (ignored) ../../tools/makedep -C. -S../.. -T../.. main.c Makefile: Permission denied make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/enterman/Desktop/wine-1.1.11/dlls/acledit' make[1]: *** [acledit/__depend__] Error 2 make[1]: Leaving directory `/home/enterman/Desktop/wine-1.1.11/dlls' make: *** [dlls/__depend__] Error 2
http://bugs.winehq.org/show_bug.cgi?id=16456
Adys adys.wh+winehqdotorg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh+winehqdotorg@gmail.c | |om
--- Comment #12 from Adys adys.wh+winehqdotorg@gmail.com 2008-12-21 02:57:05 --- Is this bug related to bug 16131?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #13 from Austin English austinenglish@gmail.com 2008-12-22 11:21:12 --- (In reply to comment #11)
well I downloaded and applied the patch but when I tried to compile wine I get errors. These are the last lines in my Terminal:
make_ctests.c makedep.c relpath.c sfnt2fnt.c Makefile: Permission denied make[1]: [Makefile] Error 1 (ignored) make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/enterman/Desktop/wine-1.1.11/tools' make[1]: Entering directory `/home/enterman/Desktop/wine-1.1.11/dlls' make[2]: Entering directory `/home/enterman/Desktop/wine-1.1.11/dlls/acledit' ../../tools/makedep -C. -S../.. -T../.. main.c Makefile: Permission denied make[2]: [Makefile] Error 1 (ignored) ../../tools/makedep -C. -S../.. -T../.. main.c Makefile: Permission denied make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/enterman/Desktop/wine-1.1.11/dlls/acledit' make[1]: *** [acledit/__depend__] Error 2 make[1]: Leaving directory `/home/enterman/Desktop/wine-1.1.11/dlls' make: *** [dlls/__depend__] Error 2
Sounds like permissions errors...did you save something as a different user?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #14 from enterman enterman@gmail.com 2008-12-22 21:57:40 --- (In reply to comment #13)
(In reply to comment #11)
well I downloaded and applied the patch but when I tried to compile wine I get errors. These are the last lines in my Terminal:
make_ctests.c makedep.c relpath.c sfnt2fnt.c Makefile: Permission denied make[1]: [Makefile] Error 1 (ignored) make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/enterman/Desktop/wine-1.1.11/tools' make[1]: Entering directory `/home/enterman/Desktop/wine-1.1.11/dlls' make[2]: Entering directory `/home/enterman/Desktop/wine-1.1.11/dlls/acledit' ../../tools/makedep -C. -S../.. -T../.. main.c Makefile: Permission denied make[2]: [Makefile] Error 1 (ignored) ../../tools/makedep -C. -S../.. -T../.. main.c Makefile: Permission denied make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/enterman/Desktop/wine-1.1.11/dlls/acledit' make[1]: *** [acledit/__depend__] Error 2 make[1]: Leaving directory `/home/enterman/Desktop/wine-1.1.11/dlls' make: *** [dlls/__depend__] Error 2
Sounds like permissions errors...did you save something as a different user?
Well I got it working and installed it but now my sound is not working in wine at all. When I went to the audio part of wine it says the alsa driver is gone O.o
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #15 from ddcc d.c.ddcc@gmail.com 2008-12-27 00:11:09 --- Does it work if you retick the alsa box?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #16 from enterman enterman@gmail.com 2008-12-27 21:56:22 --- (In reply to comment #15)
Does it work if you retick the alsa box?
nono you dont understand, alsa sound has simply disappeared from Wine entirely. There is no alsa to tick, just OSS. Currently im using OSS which is working so far but I prefered alsa.
http://bugs.winehq.org/show_bug.cgi?id=16456
Jeffrey Bonggren 7wtjvu302@sneakemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |7wtjvu302@sneakemail.com
--- Comment #17 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-01-17 21:19:27 --- (In reply to comment #4)
The error is caused by a memory leak in Sins of a Solar Empire. Presumably, the Windows implementation of Direct3D uses system RAM for textures in the IWineD3DSurface interface. In wine's implementation, it uses pixel buffer objects if the video card supports it. This is because it is faster to do it this way.
I just ran a test on my Windows machine with all of the effects settings maxed. I had Task Manager up on another screen. There was no evidence of any memory leak. The memory usage stayed around 1.3GB throughout a several-hours long lame.
If there is a memory leak in SoaSE, it is being triggered by Wine, because it just isn't happening on Windows.
I am using wine 1.1.12 (RPM) on Fedora 10 64-bit. My PC is an i7 with 6GB RAM. The vid card is a NVidia 9800gtx+ with 1GB video RAM.
When the effects settings are maxed-out, my games last less than 5 minutes before getting the GL_OUT_OF_MEMORY error. It is hard to believe that whatever leak is going on is eating up 1GB of video RAM that fast!
I am running the latest version of SoaSE. I just updated it yesterday (2009-01-16). I can't find the version number anywhere, so the date is the best I can do!
Below are the first few lines of the Wine output after the failure. I trust they are the same as what everyone else is seeing.
fixme:d3d_surface:surface_prepare_system_memory >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glBufferDataARB @ surface.c / 1031 fixme:d3d_surface:IWineD3DSurfaceImpl_LockRect >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glMapBufferARB @ surface.c / 1178
I have not yet tried the surface_prepare_system_memory workaround patch.
http://bugs.winehq.org/show_bug.cgi?id=16456
amardini14@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #18 from amardini14@yahoo.com 2009-01-18 01:05:52 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=16456
amardini14@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |amardini14@yahoo.com
--- Comment #19 from amardini14@yahoo.com 2009-01-18 01:08:40 --- (In reply to comment #18)
*** This bug has been confirmed by popular vote. ***
I was thinking... This bug still exists, and that patch is just a workaround that, when applied, limits our usage of wine. So if we want this bug solved, it's probably best to vote for it so that it can get the attention of developers.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #20 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-01-18 08:12:29 --- (In reply to comment #19)
I was thinking... This bug still exists, and that patch is just a workaround that, when applied, limits our usage of wine. So if we want this bug solved, it's probably best to vote for it so that it can get the attention of developers.
I think it might get more attention if some of the attributes were changed in the bug summary. I don't have the rights to do this, except by creating a new bug report. Maybe doug is allowed?
The Component should probably be "directx-d3d". The Version should be bumped up to at least version 1.1.12. The Severity should be "Normal". I would also bump the priority to P3. Hardware probably should be something other than "other". The AppDB link should also probably include the newer patched versions of SoaSE.
I went ahead and added a vote, for what it's worth!
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #21 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-01-18 12:45:12 --- Created an attachment (id=18799) --> (http://bugs.winehq.org/attachment.cgi?id=18799) i686-pc-mingw32-objdump -x "Sins of a Solar Empire.exe"
A dump of the PE headers for SoaSE. It shows the DLL dependencies and imported symbols. SoaSE uses d3d9 and d3dx9. The d3d9 imports don't show much because it is COM.
http://bugs.winehq.org/show_bug.cgi?id=16456
Lauri Niskanen ape3000@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ape3000@gmail.com
--- Comment #22 from Lauri Niskanen ape3000@gmail.com 2009-01-19 10:10:01 --- This bug seems to be also affecting Little Fighter 2. It also crashes after a while and outputs the same "GL_OUT_OF_MEMORY" messages. When I limit the video memory with Direct3D registry entry the game crashes sooner, so it's about video memory running out. There is probably a memory leak.
http://bugs.winehq.org/show_bug.cgi?id=16456
doug damron@mytech.wvutech.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal Component|-unknown |directx-d3d Priority|P4 |P3 Version|1.1.10 |1.1.12
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #23 from Lauri Niskanen ape3000@gmail.com 2009-01-19 11:42:09 --- doug damron@mytech.wvutech.edu: You changed the version on the bug details. Shouldn't it be the earliest version where the bug where found?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #24 from Lauri Niskanen ape3000@gmail.com 2009-01-19 11:42:54 --- I can confirm that the patch on this bug did fix the issue with Litte Fighters 2.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #25 from ddcc d.c.ddcc@gmail.com 2009-01-19 12:23:33 --- Yes, I believe the version should be left at the earliest one affected by this bug.
http://bugs.winehq.org/show_bug.cgi?id=16456
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.12 |1.1.10
--- Comment #26 from Vitaliy Margolen vitaliy@kievinfo.com 2009-01-19 15:04:20 --- Don't change Wine version.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #27 from doug damron@mytech.wvutech.edu 2009-01-20 07:42:59 --- (In reply to comment #26)
Don't change Wine version.
What does everyone think the wine version should be, then? The earliest I have found the problem was on wine 1.05.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #28 from Lauri Niskanen ape3000@gmail.com 2009-01-20 08:37:39 --- (In reply to comment #27)
(In reply to comment #26)
Don't change Wine version.
What does everyone think the wine version should be, then? The earliest I have found the problem was on wine 1.05.
What is 1.05? Do you mean 1.0, or maybe 1.1.5?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #29 from doug damron@mytech.wvutech.edu 2009-01-20 13:02:58 --- Sorry, that was a typo... I meant to say 1.1.5.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #30 from Lauri Niskanen ape3000@gmail.com 2009-01-20 13:06:07 --- (In reply to comment #29)
Sorry, that was a typo... I meant to say 1.1.5.
Then you could change the version to 1.1.5 as it's the first version known not to work for sure.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #31 from Vitaliy Margolen vitaliy@kievinfo.com 2009-01-20 21:59:01 --- (In reply to comment #29)
Sorry, that was a typo... I meant to say 1.1.5.
Just don't change the version period.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #32 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-02-01 15:43:59 --- The git version from the evening of Jan 31 still has the problem. FYI
I added some code to keep a running total of the number of IWineD3DSurfaceImpls in existence. I incremented in IWineD3DDeviceImpl_CreateSurface and decremented in IWineD3DSurfaceImpl_Release(ref==0).
The number of surfaces steadily grows as the game runs, but it does stabilize.
Here is an example of the running total I got when I loaded a game that was saved after I won, so I have lots of ships around.
691 opening cinematics 1038 main menu 1076 game setup another 500+ during loading once game starts, climbs steadily to 5288 zooming around a 200-ship fleet gets me up to 5458
The number of surfaces goes up when I zoom in on a new planet area with different ships, etc. It does up and down in groups of 12 after that. Bringing up the various menus during the game increases the surface count.
Interestingly, it doesn't go down much when I end a game and go back to the main menu screens. When I start a new game, the surface count doesnt go up much more, so it is probably reusing the surfaces that weren't freed when I ended the game.
I tried to completely exit the game to see if those surfaces are freed, but it always crashes when I exit, so no luck there.
The number of surfaces doesn't seem related to when I get the GL_OUT_OF_MEMORY error. On one test, I got the surface count up past 6200 before running out of memory.
Depending on the type of graphics card, the graphics memory may be a shared pool or partitioned into specific areas like vertex buffers, frame buffers, and texture memory. This may have an effect on how this bug manifests itself. For what it's worth, I am using a NVIDIA GeForce 9800GTX+ with 1G of video RAM. I am using the 177.82 driver.
http://bugs.winehq.org/show_bug.cgi?id=16456
Anton Birkel sesshomaru_2k3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sesshomaru_2k3@hotmail.com
http://bugs.winehq.org/show_bug.cgi?id=16456
Sebastian Doering moralapostel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |moralapostel@gmail.com
--- Comment #33 from Sebastian Doering moralapostel@gmail.com 2009-03-08 15:52:56 --- Same problem here with wine-1.1.16. As soon as the GL_OUT_OF_MEMORY messages start appearing random text-blocks start disapperaing, etc... Makes the game kind of unplayable
http://bugs.winehq.org/show_bug.cgi?id=16456
Benson btsai@vrwarp.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |btsai@vrwarp.com
http://bugs.winehq.org/show_bug.cgi?id=16456
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dirtbag@gmx.li
--- Comment #34 from Vitaliy Margolen vitaliy@kievinfo.com 2009-03-24 10:05:09 --- *** Bug 17835 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16456
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dirtbag@gmx.li CC| |yast4ik@yahoo.com
--- Comment #34 from Vitaliy Margolen vitaliy@kievinfo.com 2009-03-24 10:05:09 --- *** Bug 17835 has been marked as a duplicate of this bug. ***
--- Comment #35 from Vitaliy Margolen vitaliy@kievinfo.com 2009-03-24 10:05:22 --- *** Bug 16854 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16456
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |puciek@gmail.com
--- Comment #36 from Vitaliy Margolen vitaliy@kievinfo.com 2009-03-24 10:07:52 --- *** Bug 17661 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16456
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |puciek@gmail.com CC| |thefirstkeet@gmail.com
--- Comment #36 from Vitaliy Margolen vitaliy@kievinfo.com 2009-03-24 10:07:52 --- *** Bug 17661 has been marked as a duplicate of this bug. ***
--- Comment #37 from Vitaliy Margolen vitaliy@kievinfo.com 2009-03-24 10:09:04 --- *** Bug 17216 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16456
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.spies@fuceekay.com
--- Comment #38 from Vitaliy Margolen vitaliy@kievinfo.com 2009-03-24 10:11:42 --- *** Bug 16176 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16456
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Summary|Sins of a solar empire: |Games crash with |GL_OUT_OF_MEMORY |GL_OUT_OF_MEMORY error
--- Comment #39 from Vitaliy Margolen vitaliy@kievinfo.com 2009-03-24 10:14:20 --- Adjusting summary to make it generic.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #40 from amardini14@yahoo.com 2009-03-24 12:03:40 --- So apparently there are some other games affected by this bug: Lord of the Rings Online: Shadows of Angmar Prince of Persia 2008 Eve Online Crysis Sacred 2 - Fallen Angel
I added this bug to those games, so hopefully this can get more attention and this issue will be cleared up.
http://bugs.winehq.org/show_bug.cgi?id=16456
N3o diafoirus@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |diafoirus@gmail.com
--- Comment #41 from N3o diafoirus@gmail.com 2009-03-24 14:40:34 --- Hi guys ^^
I cant reproduce this issue with Eve online, I have a 9800GTX+ with 4GB ram, I did test with 1GB or 2GB ram conf too, no problems...
My current nVidia drivers :
NVRM version: NVIDIA UNIX x86 Kernel Module 185.13 Thu Mar 12 17:57:13 PST 2009
Fly safe ^^
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #42 from N3o diafoirus@gmail.com 2009-03-24 14:42:03 --- Hi guys ^^
I cant reproduce this issue with Eve online, I have a 9800GTX+ with 4GB ram, I did test with 1GB or 2GB ram conf too, no problems...
My current nVidia drivers :
NVRM version: NVIDIA UNIX x86 Kernel Module 185.13 Thu Mar 12 17:57:13 PST 2009
Fly safe ^^
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #43 from Rico kgbricola@web.de 2009-03-25 04:53:10 --- For users (e.g. Jeffrey Bonggren and I guess thefirstkeet@gmail.com, too), with x86_64 + nvidia (G80+) + something more than 3GB ram, please have a look here: http://www.nvnews.net/vbulletin/showthread.php?t=127984 and try the workarounds mentioned there. It would be nice, if you could add some system information from your system, where the problem is reproduce able. Hopefully the bug will be fixed soon.
Also have a look at these bugs: bug 10778 bug 13335
And you could also have a look here: http://forum.winehq.org/viewtopic.php?t=4101
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #44 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-03-26 17:09:47 --- (In reply to comment #43)
For users (e.g. Jeffrey Bonggren and I guess thefirstkeet@gmail.com, too), with x86_64 + nvidia (G80+) + something more than 3GB ram, please have a look here: http://www.nvnews.net/vbulletin/showthread.php?t=127984 and try the workarounds mentioned there. It would be nice, if you could add some system information from your system, where the problem is reproduce able. Hopefully the bug will be fixed soon.
The problem mentioned in the nvnews thread is AFAICT unrelated to wine, except to the extent that most (all?) programs run in Wine are 32-bit.
I compiled and ran the two test programs (leaktest.c and leaktest_v2.c) from this post http://www.nvnews.net/vbulletin/showpost.php?p=1945813&postcount=36 in that thread. The glClear()/glFlush() memory leak did not manifest itself on my system.
The only general problem I have had with my NVIDIA card is that I can't start X without instantly hanging the whole system (with my caps and scroll-lock lights turning on!) on any NVIDIA drivers newer than 177.82. I don't want to waste space here troubleshooting my 3D setup. I just want to make clear that it doesn't appear to be relevant to this GL_OUT_OF_MEMORY bug.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #45 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-03-26 18:45:17 --- (In reply to comment #43)
I ran Sins again and this time I watched the memory usage. The virtual memory mapped into Sins peaked around 4087 MB. It got there pretty fast and stayed there. About 10 minutes later I started to see GL_OUT_OF_MEMORY messages.
The Resident stayed around 1400MB, while the Shared stayed around 60MB.
I couldn't help but notice that 4087 is awfully close to the 32-bit limit. However, I can get into the 3GB range for virtual memory just by running notepad.exe. I wasn't aware of this, but I suppose this might just be the way Wine does its memory mappings. I thought I was on to something with the virtual memory size until I ran notepad!
Memory usage (as reported by the kernel) doesn't appear to be the cause of the GL_OUT_OF_MEMORY.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #46 from Anton Birkel sesshomaru_2k3@hotmail.com 2009-03-26 21:48:02 --- An interesting thing to note is that Cedega users claim that Sins runs without issue.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #47 from amardini14@yahoo.com 2009-03-26 23:28:14 --- (In reply to comment #45) I believe the issue is not with system memory, but with graphic memory.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #48 from Rico kgbricola@web.de 2009-03-27 04:36:07 --- @ Jeffrey Bonggren
The problem mentioned in the nvnews thread is AFAICT unrelated to wine, except to the extent that most (all?) programs run in Wine are 32-bit.
Yes, nearly all apps are 32bit for wine (there is a wine64 (see http://wiki.winehq.org/Wine64), but it isn't usable yet).
So you are using driver 177.82 and couldn't reproduce the memory leak from the nvnews forum?
I couldn't help but notice that 4087 is awfully close to the 32-bit limit. However, I can get into the 3GB range for virtual memory just by running notepad.exe.
Yes, I've seen that, too. Probably there is another problem which should be investigated (see http://forum.winehq.org/viewtopic.php?t=4101 32bit 2,6GB vs 64bit 3,6GB). A good starting point is the test attached here http://bugs.winehq.org/show_bug.cgi?id=13335#c140 .
I guess all are different problems which show all the same result. In combination they arrive after a different time. For users which hit all bugs, they couldn't even start a game (see bug 17216) and others which hit only some of them could run the game at least some time. So it's not so easy with the dupes!
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #49 from Tymoteusz Paul puciek@gmail.com 2009-03-30 16:04:53 --- I also confirm this bug with Dark messiah Geforce 9600, nvidia: 180.41
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #50 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-03-30 17:30:04 --- (In reply to comment #48)
So you are using driver 177.82 and couldn't reproduce the memory leak from the nvnews forum?
Yes.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #51 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-03-30 18:09:56 --- (In reply to comment #47)
(In reply to comment #45) I believe the issue is not with system memory, but with graphic memory.
Given that doug's patch (the first attachment above) fixes the GL_OUT_OF_MEMORY error (at the expense of leaking system memory), I agree this must be a GL resource management issue.
I have been troubleshooting this error with the assumption that the bug is in (or is triggered by code in) wine/dlls/d3d9. I suppose the bug could possibly be in the Linux NVIDIA drivers, but I have no other OpenGL driver to test this theory with. Plus, troubleshooting closed-source code is no fun!
My strategy has been to use BuGLe to monitor the GL resource usage of SoaSE in wine. BuGLe works by using LD_PRELOAD to override all of the GL symbols with its own. The LD_PRELOAD doesn't work with Wine, but I was able to build wine/dlls/opengl32 while directly linking against libbugle.so instead of libGL. libbugle is supposed to communicate via pipe with a GUI that can show me what is going on.
The GUI is started on the cmdline similarly to wine. You run the GUI and pass the target program's name and its args as its parameters. The GUI does a pipe()-dup()-fork()-exec() to create the pipe and run the target program.
I run it like this: /usr/local/bin/gldb-gui ~/wine-git/wine ""Sins of a Solar Empire.exe""
The GUI starts up; I select the Run command; it starts Wine SoaSE. SoaSE runs like normal, but I never see anything in the BuGLe GUI. I assume that Wine is somehow interfering with the passing of the pipe, but I haven't spent the time to figure it out.
Has anyone else out there tried to use BuGLe with Wine?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #52 from Jeff Zaroyko jeffz@jeffz.name 2009-03-30 21:21:35 --- Also seems to happen with Battlefield 1942 and CS:S, 1.1.18, nvidia 180.37
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #53 from H. Verbeet hverbeet@gmail.com 2009-03-31 04:42:08 --- (In reply to comment #51)
My strategy has been to use BuGLe to monitor the GL resource usage of SoaSE in wine. BuGLe works by using LD_PRELOAD to override all of the GL symbols with its own. The LD_PRELOAD doesn't work with Wine, but I was able to build wine/dlls/opengl32 while directly linking against libbugle.so instead of libGL. libbugle is supposed to communicate via pipe with a GUI that can show me what is going on.
I haven't tried myself, but I think you'd need to modify the wine_dlopen() call in has_opengl() in dlls/winex11.drv/opengl.c. Or just change SONAME_LIBGL in include/config.h.
http://bugs.winehq.org/show_bug.cgi?id=16456
Bob bob+wine@mcelrath.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob+wine@mcelrath.org
--- Comment #54 from Bob bob+wine@mcelrath.org 2009-04-02 20:22:02 --- It's been mentioned elsewhere, but another symptom of this bug is that if you watch in top, the games will crash when VIRT reaches exactly 4096MB. It seems the program runs out of address space. Presumably some of this is mapped for the video card's frame buffer. However, at startup, Sins starts with VIRT about 3.8GB, so it doesn't take long to reach 4.0GB.
But why is it 3.8GB in the first place? That is a ton of unused address space. I'm not sure how the GL buffers are allocated, but my card has 768MB of video ram, which won't fit between 3.8GB and 4.0GB.
P.S. Since Crysis, Sins, EVE Online, all have this problem, I don't think it's a problem with the games. It's a wine bug.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #55 from amardini14@yahoo.com 2009-04-02 20:49:22 --- (In reply to comment #54)
*snip*It's a wine bug.
I thought this might be fairly obvious, but still, it's best to get this out of the way now so that some real progress can be made. I'm also considering the possibility that it may be an Nvidia issue, so to get that out of the way, we need to look into two scenarios: Can someone replicate this bug on ATI hardware? Can someone replicate this bug on older Nvidia drivers (something released before wine 1.0?)
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #56 from Tymoteusz Paul puciek@gmail.com 2009-04-02 21:02:11 --- I don't know will it help, but i've made little test with dark messiah (which is totaly unplayble on wine because of this bug - crashes in like 5-6 minutes) and i've run it via vmware and it's working perfect so i guess this rules out drivers issue out of the case (since its same system, same drivers and so on, just via vmware layer) ?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #57 from ddcc d.c.ddcc@gmail.com 2009-04-02 21:36:01 --- No, this would mean that the problem is directly related to the NVIDIA drivers, because in a VM you are using VM drivers instead.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #58 from N3o diafoirus@gmail.com 2009-04-03 09:07:10 --- Hi ,
I did test with the last stable driver:
NVRM version: NVIDIA UNIX x86 Kernel Module 180.44 Mon Mar 23 14:59:10 PST 2009
This issue dont reproduce in my system: 9800gtx+ (512MB Vram), 4GB RAM,
I did test with large pvp ops (4h+) intensive battle, 400 pilots in local aprox, etc, no issues...
Note: with 180.44 driver I got more fps ^^
Fly safe
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #59 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-04-03 20:27:20 ---
Can someone replicate this bug on ATI hardware? Can someone replicate this bug on older Nvidia drivers (something released before wine 1.0?)
I gave SoaSE a try with the Mesa driver! It was mildly entertaining, and worked better than I expected. Unfortunately, it MiniDumped halfway through the loading screen after starting a game. I was hoping I could get it to run long enough to trigger the GL_OUT_OF_MEMORY, but no such luck. This tells us nothing except that the Mesa driver is no good for testing this!
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #60 from Bob bob+wine@mcelrath.org 2009-04-12 15:11:09 --- I confirm that EVE Online seems to be fixed using the 180.44 Nvidia driver. It still has a crash related to moving the mouse in and out of the window (and using virtual desktops) but I don't think that is related. EVE now runs for hours where before it could not last for more than ~30 minutes before crashing with GL_OUT_OF_MEMORY. VIRT also stays below 4096m (but above 3500m, which is still disturbing to me).
Sins of a Solar Empire however, still crashes, with exactly the same behavior (memory creeping to 4096m VIRT, followed by GL_OUT_OF_MEMORY).
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #61 from Tymoteusz Paul puciek@gmail.com 2009-04-14 11:54:49 --- Indeed it is fixed for eve online, but sadly i also confirmed this bug with black and white 2.
http://bugs.winehq.org/show_bug.cgi?id=16456
haarp liquitsnake@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |liquitsnake@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #62 from Anton Birkel sesshomaru_2k3@hotmail.com 2009-04-30 18:20:20 --- Does anyone know if the new wine beta (1.1.20) fixes this issue? The changelog says that there were D3D code cleanups - wondering if this helped? Also has anyone tried this with the 185.x series nVidia drivers yet?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #63 from N3o diafoirus@gmail.com 2009-04-30 21:03:34 --- (In reply to comment #62)
Does anyone know if the new wine beta (1.1.20) fixes this issue? The changelog says that there were D3D code cleanups - wondering if this helped? Also has anyone tried this with the 185.x series nVidia drivers yet?
Me, I'm currently running EVE with 185.x Nvidia series + Wine 1.1.20 without issues, no fps drop, just perfect ^^
Fly safe...
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #64 from Tymoteusz Paul puciek@gmail.com 2009-05-01 00:28:45 --- (In reply to comment #63)
(In reply to comment #62)
Does anyone know if the new wine beta (1.1.20) fixes this issue? The changelog says that there were D3D code cleanups - wondering if this helped? Also has anyone tried this with the 185.x series nVidia drivers yet?
Me, I'm currently running EVE with 185.x Nvidia series + Wine 1.1.20 without issues, no fps drop, just perfect ^^
Fly safe...
And did you even have that issue in the first place ? If not then how can you confirm that it's fixed (http://bugs.winehq.org/show_bug.cgi?id=16456#c58)?
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #65 from N3o diafoirus@gmail.com 2009-05-01 15:14:49 ---
And did you even have that issue in the first place ? If not then how can you confirm that it's fixed (http://bugs.winehq.org/show_bug.cgi?id=16456#c58)?
I dont have issues with Eve (in my system) you should read again the comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c58 ) this line :
"This issue dont reproduce in my system: 9800gtx+ (512MB Vram), 4GB RAM, "...
and this line:
"I did test with large pvp ops (4h+) intensive battle, 400 pilots in local aprox, etc, no issues... "
Did you see : No issues....
I cant confirm if this fixed or not, only I say : No issues in my system ...
http://bugs.winehq.org/show_bug.cgi?id=16456
Paulie drakkk@centrum.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |drakkk@centrum.cz
--- Comment #66 from Paulie drakkk@centrum.cz 2009-05-01 15:19:56 --- (In reply to comment #62)
Does anyone know if the new wine beta (1.1.20) fixes this issue? The changelog says that there were D3D code cleanups - wondering if this helped? Also has anyone tried this with the 185.x series nVidia drivers yet?
I did and the issue is still there. I tested SoaSE 1.16 with wine 1.1.20 and 185.18.04 drivers, and it still crashes (Fedora 10, GeForce 9600 GSO, 2GB RAM) i'll give it an another try on my laptop with ati card if I can get a fglrx driver working.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #67 from N3o diafoirus@gmail.com 2009-05-01 16:35:02 ---
I did and the issue is still there. I tested SoaSE 1.16 with wine 1.1.20 and 185.18.04 drivers, and it still crashes (Fedora 10, GeForce 9600 GSO, 2GB RAM) i'll give it an another try on my laptop with ati card if I can get a fglrx driver working.
I forget to add something, this is my current nVidia driver version :
NVRM version: NVIDIA UNIX x86 Kernel Module 180.51 Thu Apr 16 19:02:15 PDT 2009 GCC version: gcc version 4.2.4
185.18.05 is a beta driver, try test with non beta driver version....
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #68 from Paulie drakkk@centrum.cz 2009-05-01 17:12:43 --- (In reply to comment #67)
185.18.05 is a beta driver, try test with non beta driver version....
I actually did, I started with SoaSE 1.11, wine 1.1.18 and 180.51 driver and when it doesn't worked, I updated to newest available.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #69 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-05-02 21:11:08 --- (In reply to comment #62)
Does anyone know if the new wine beta (1.1.20) fixes this issue? The changelog says that there were D3D code cleanups - wondering if this helped? Also has anyone tried this with the 185.x series nVidia drivers yet?
I just built wine from git this evening and I am still seeing the issue with SoaSE. I also applied doug's patch and it doesn't appear to change much. It might be permitting me to play somewhat longer, but there is already so much variation in play time that any difference is lost in the noise. I can't make it through a single game of Point Blank either way.
Given that the patch apparently doesn't fix it for me, perhaps we should be looking somewhere other than surface_prepare_system_memory PBO allocation.
I am using the 177.82 NVIDIA driver, as I have explained previously in this thread.
I would very much like to know if anyone can reproduce this bug on an ATI-based system.
After testing this bug many times, I have noticed some patterns: I have noticed that often (not every time) I can play for a good while after I get the first GL_OUT_OF_MEMORY message on the console. It looks like it often happens the first time I see a new type of game object (ship, facility, etc).
From then on, any instances of that object show up as black silhouettes.
Eventually, I start seeing more and more GL error messages. Presumably these are related to the code that is referring to the resource that failed to allocate.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #70 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-05-04 19:00:16 --- I just had a thought. Would it be useful to try to run SoaSE on Windows using the wined3d Windows driver? If it has the same failure there, I suppose we could then surely blame the wined3d code. If it doesn't fail, well, I'm not sure if that tells us much. Perhaps it would then take running it in Wine on Windows to be sure.
http://bugs.winehq.org/show_bug.cgi?id=16456
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hytek3000@yahoo.com
--- Comment #71 from Ken Sharp kennybobs@o2.co.uk 2009-05-29 11:54:30 --- *** Bug 16949 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16456
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
--- Comment #72 from Ken Sharp kennybobs@o2.co.uk 2009-05-29 11:56:47 --- *** Bug 18539 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #73 from N3o diafoirus@gmail.com 2009-05-30 01:41:10 --- (In reply to comment #69)
I am using the 177.82 NVIDIA driver, as I have explained previously in this thread.
Try upgrade your driver version to last version, currently is :
Linux Display Driver - x86
Version: 180.51 Operating System: Linux x86 Release Date: April 21, 2009
http://www.nvidia.com/object/linux_display_ia32_180.51.html
Sometimes the bugs isn't related with Wine, could be a bug in video driver too.
My suggestion: Try upgrade to last version and test all again
Fly safe
http://bugs.winehq.org/show_bug.cgi?id=16456
ajmklean meanmklean@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |meanmklean@gmail.com
--- Comment #74 from ajmklean meanmklean@gmail.com 2009-06-06 00:55:16 --- GL_OUT_OF_MEMORY while playing Demigod, crashes.
Running Wine 1.1.22 with fglrx 9.5 ATI HD4850 FBO for OffscreenRenderingMode, crashes after about 10-15 minutes of play.
Using pasuspender to limit pulseaudio problems, on Ubuntu 9.05 Jaunty.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #75 from N3o diafoirus@gmail.com 2009-06-06 01:19:30 --- (In reply to comment #74)
GL_OUT_OF_MEMORY while playing Demigod, crashes.
Running Wine 1.1.22 with fglrx 9.5 ATI HD4850 FBO for OffscreenRenderingMode, crashes after about 10-15 minutes of play.
Using pasuspender to limit pulseaudio problems, on Ubuntu 9.05 Jaunty.
Try upgrade to wine 1.1.23 and test again....
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #76 from ajmklean meanmklean@gmail.com 2009-06-06 12:57:22 --- I have tried 1.1.23 with the same result.
Technically with wine 1.1.23 fglrx fbo is crashing on startup for all D3D programs at the moment. That is why I did not report it for 1.1.23, because I modified the vanilla 1.1.23 source to test, for what it is worth.
http://bugs.winehq.org/show_bug.cgi?id=16456
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |justicezero@mailsnare.net
--- Comment #77 from Ken Sharp kennybobs@o2.co.uk 2009-06-09 18:13:13 --- *** Bug 18875 has been marked as a duplicate of this bug. ***
--- Comment #78 from Justice M. justicezero@mailsnare.net 2009-06-09 19:37:14 --- (In reply to comment #55)
(In reply to comment #54) Can someone replicate this bug on ATI hardware?
My bug report was on an ATI Radeon HD 3850 card using the Ubuntu restricted ATI drivers. It still crashed me.
-OpenGL version string: 2.1.8575
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #79 from Paulie drakkk@centrum.cz 2009-06-10 08:12:53 --- problem still there in SoaSE 1.11 with wine 1.1.23 and 185.18.14, (FC11 64bit, GeForce 9600GSO). BUT I have tried five times, four times it crashed as always, i mean after firsts few GL_OUT_OF_MEMORY (like this:
fixme:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexImage2D @ surface.c / 413 fixme:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexSubImage2D @ surface.c / 338 fixme:d3d_surface:surface_prepare_system_memory >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glBufferDataARB @ surface.c / 1100 fixme:d3d_surface:IWineD3DSurfaceImpl_LockRect >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glMapBufferARB @ surface.c / 1244
and some more errs game freezes. But once it didn't crashed at all, there were many similar fixmes and one another i've never seen before (also many times):
fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glUnmapBufferARB @ surface.c / 1398
As soon as GL_OUT_OF_MEMORY began, some text disappeared, but the game didn't crash during gameplay (it crashed when i clicked exit button). I'm pretty sure, i did everything as always, so i don't know why it was different. Is this some improvement or just a luck?
http://bugs.winehq.org/show_bug.cgi?id=16456
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmail.com
--- Comment #80 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-10 15:50:56 --- This is most likely a duplicate of bug 13335.
http://bugs.winehq.org/show_bug.cgi?id=16456
hpestilence hpestilence@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hpestilence@gmail.com
--- Comment #81 from hpestilence hpestilence@gmail.com 2009-06-15 20:17:47 --- I've been getting this error too with eve-online lately, My computer setup is:
Q6600 CPU 4GB ddr2 800 mem ATI HD4850 512MB card and fglrx 9.6 Running Arch Linux x86_64 Daily wine git pull
Running top alongside wine and eve-online shows about 980MBs free after wine initially allocates virtual memory. With OffscreenRenderingMode set to fbo that 980MBs gets eaten away a little over 1MB per 3 seconds by wine until it crashes around 300MBs left (GL_OUT_OF_MEMORY) and that's just leaving the EVE login screen on and doing nothing else.
With backbuffer set, it does it more slowly in that I have to login, load stuff, move around for memory to get allocated before a crash occurs. If I just leave the client alone the virtual memory seems to just stay stable but doesn't get any smaller.
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #82 from hpestilence hpestilence@gmail.com 2009-06-17 17:20:10 --- Figured out my problem I think,
A: I was using a patch to use the latest fglrx with the 2.6.29 kernel, it seems fglrx can't handle video memory issues with the patch to compile with that kernel. Using a 2.6.28 kernel seemed to get rid of my GL_OUT_OF_MEMORY error.
B: It seems that there are some reserved addresses for virtualization (for example 0x00000484) and when they're read from an unhandled exception occurs. However I'm not entirely sure it's wine's fault, or the graphics driver's fault. I recieved the option to disable virtualization in my BIOS recently but before I think it was auto enabled. I think it only occurs when it's enabled in the BIOS instead of the kernel.
http://lkml.org/lkml/2008/6/24/117
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #83 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-18 03:14:05 --- Please check bug 13335 for the memory issues. I think this is just a duplicate of it.
Roderick
http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #84 from N3o diafoirus@gmail.com 2009-06-19 12:50:12 --- Is still present this bug in current version (1.1.24) if not, please close it...
http://bugs.winehq.org/show_bug.cgi?id=16456
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
--- Comment #85 from Robert Andersson roband@pobox.com 2009-06-22 02:56:46 --- Problem is still there: Wine 1.1.24 Nvidia GTX 285, 1GB RAM, software version 185.18.14 Intel I7 920, 6GB RAM Ubuntu 9.04 32bit-server-kernel Tested using World of Warcraft in D3D-mode
Game works in low-level graphics settings, but as soon as you bump the settings to max the error kicks in.
I agree with Roderick Colenbrander in comment #83, fix bug #13335 and this and a whole bunch of related bugs will go away.
Robert.
http://bugs.winehq.org/show_bug.cgi?id=16456
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE
--- Comment #86 from Roderick Colenbrander thunderbird2k@gmail.com 2009-06-22 02:59:16 --- Marking this bug as a duplicate.
*** This bug has been marked as a duplicate of bug 13335 ***
http://bugs.winehq.org/show_bug.cgi?id=16456
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #87 from Vitaliy Margolen vitaliy@kievinfo.com 2009-06-22 08:25:46 --- Closing dup.
-
wine-bugs＠winehq.org