http://bugs.winehq.org/show_bug.cgi?id=11674
Summary: Dual-core not being correctly supported in World of Warcraft (WOW) Product: Wine Version: 0.9.55. Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs@winehq.org ReportedBy: austinenglish@gmail.com
+++ This bug was initially created as a clone of Bug #6383 +++
Running World of Warcraft in wine on a multicore/SMP system results in multiple threads being used, however, only one CPU is given significant tasks. The others have very little to no CPU load.
http://bugs.winehq.org/show_bug.cgi?id=11674
Luke Bratch l_bratch@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch@yahoo.co.uk
http://bugs.winehq.org/show_bug.cgi?id=11674
Aneurin Price aneurin.price@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aneurin.price@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
Markus Golser elmargol@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |elmargol@googlemail.com
--- Comment #1 from Markus Golser elmargol@googlemail.com 2008-04-09 11:33:04 --- I have the same problem on ubuntu hardy (dualcore)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #2 from Tijl Coosemans tijl@ulyssis.org 2008-05-05 15:28:59 --- Maybe the threads block on wineserver?
http://bugs.winehq.org/show_bug.cgi?id=11674
Mike pmike2001@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pmike2001@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
Jason Rosenberg smitty_the_smith@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |smitty_the_smith@yahoo.com
http://bugs.winehq.org/show_bug.cgi?id=11674
Chadwick Ferguson chadwick@clan-mac.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chadwick@clan-mac.com
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #3 from Chadwick Ferguson chadwick@clan-mac.com 2008-12-07 21:59:43 --- Confirmed BLOCKER.
http://bugs.winehq.org/show_bug.cgi?id=11674
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #4 from Keith Constable kccricket@gmail.com 2008-12-15 17:52:14 --- Created an attachment (id=17971) --> (http://bugs.winehq.org/attachment.cgi?id=17971) Graph of CPU usage while running wow.exe
Dual core Athlon 64 X2; kernel 2.6.27 SMP; Ubuntu 8.10; Wine 1.1.10
As you can see, the usage of one core is inversely proportional to the usage of the other. If I run something else in the background, say WinXP in VMware, then both cores are utilized fully.
http://bugs.winehq.org/show_bug.cgi?id=11674
Anders Aagaard aagaande@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aagaande@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #5 from Claudiu Curca Alexstrasza2@gmail.com 2009-01-06 04:26:41 --- Created an attachment (id=18521) --> (http://bugs.winehq.org/attachment.cgi?id=18521) An executable which simulates a hard-working win32 threaded app.
http://bugs.winehq.org/show_bug.cgi?id=11674
Claudiu Curca Alexstrasza2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Alexstrasza2@gmail.com
--- Comment #6 from Claudiu Curca Alexstrasza2@gmail.com 2009-01-06 04:27:07 --- Confirmed on Gentoo 2008.0, running kernel 2.6.27-gentoo-r7 and wine 1.1.10 on an AMD Turion64 X2
The CPU load for Wow.exe is 105% max during gameplay. It spikes up to 140% during instance load-time, but once it's loaded it goes down to ~100% using only one single core.
Setting the ProcessAffinityMask in Config.wtf to "3" or any other value seems to not have any effect.
Also tested on a DUAL processor Intel Pentium III at 1GHz each, using Debian Etch and wine 1.1.12 compiled from sources. The behavior is exactly the same as described above.
Out of curiosity, I've tested the threading capabilities of wine and found them to be (not surprisingly) in working condition.
To do this, I've compiled a 'worker' app in visual studio. Basicly, it's a simple exe which spawns 2 threads and simulates 'working' in them. The exe is called HardWorker.exe and it's attached to this comment.
(Note: To run it you may need the Visual C 2005 Runtime (roughly 2MB). download it from http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-... and install it with wine.)
The results were clear. HardWorker.exe bites ~195% of the CPU time when ran. This suggests that the problem may be the way in which threading is implemented in World of Warcraft, but to study this is kinda out of my reach.
http://bugs.winehq.org/show_bug.cgi?id=11674
Andrew Mitchell ajmitch@ubuntu.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ajmitch@ubuntu.com
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #7 from Jeff Zaroyko jeffz@jeffz.name 2009-01-06 05:16:36 --- (In reply to comment #6)
This suggests that the problem may be the way in which threading is implemented in World of Warcraft, but to study this is kinda out of my reach.
Either that it could be that either WoW decides not to schedule as much work as it does on Windows
I don't know if it'll be useful, but maybe something can be spotted if you add traces to dlls/kernel32/thread.c for some of the functions which don't have traces (CreateThread, SuspendThread, ResumeThread, SetThreadPriority, SetThreadPriorityBoost, SetThreadAffinityMask, SetThreadIdealProcessor) which print the function parameters using the TRACE macro then attach a +thread,+tid log here.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #8 from Claudiu Curca Alexstrasza2@gmail.com 2009-01-06 07:38:11 --- Created an attachment (id=18524) --> (http://bugs.winehq.org/attachment.cgi?id=18524) Status of the threads in Wow.exe after running a few minutes
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #9 from Claudiu Curca Alexstrasza2@gmail.com 2009-01-06 07:38:54 --- Created an attachment (id=18525) --> (http://bugs.winehq.org/attachment.cgi?id=18525) Trace log of the threads while running Wow.exe
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #10 from Claudiu Curca Alexstrasza2@gmail.com 2009-01-06 07:44:54 --- (In reply to comment #7)
(In reply to comment #6)
This suggests that the problem may be the way in which threading is implemented in World of Warcraft, but to study this is kinda out of my reach.
Either that it could be that either WoW decides not to schedule as much work as it does on Windows
I don't know if it'll be useful, but maybe something can be spotted if you add traces to dlls/kernel32/thread.c for some of the functions which don't have traces (CreateThread, SuspendThread, ResumeThread, SetThreadPriority, SetThreadPriorityBoost, SetThreadAffinityMask, SetThreadIdealProcessor) which print the function parameters using the TRACE macro then attach a +thread,+tid log here.
I've followed your advice and dug a bit deeper. Unfortunately, I found out a sad thing.
By the looks of it, World of Warcraft does NOT use multiple threads for rendering or analysis during gameplay. I started the game, entered the world and played for a few minutes.
As you can see from the snippet of the status of the threads yielded by "ps alm", only ONE thread has been using CPU time (the one with 5:29). The rest are clearly there, but they are not used for extensive operation.
But then why does it work on Windows? I think i can answer that too.
By looking at the snippet of the wine log you can see that there's one specific thread that's being thrown from one CPU to the other (using the SetThreadAffinityMask function). On windows this might cause the "illusion" that 2 threads are actually using one core each. I might be wrong, but I don't know how else to demonstrate the windows behavior.
I will try to install wine on a windows machine (if i can get one) and see if the behavior is the same. Maybe it can shed a bit more light on the subject.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #11 from Anders Aagaard aagaande@gmail.com 2009-01-06 08:10:11 --- When windows juggles threads I believe task manager shows each cpu at 50%, with a total of 100% cpu usage.
Now you'll never see 100% utilization of all cores in world of warcraft, it's a game, so a lot of things rely on eachother, so multithreading it efficiently is hard.
Now looking at the original bug report "only one CPU is given significant tasks", I wouldn't consider this a bug unless it's different on windows. I'd assume it uses one cpu for most tasks, and multithreading for extra things (loading seems to be one thing where they fork work into multiple threads).
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #12 from Austin English austinenglish@gmail.com 2009-01-06 13:04:43 --- (In reply to comment #5)
Created an attachment (id=18521)
--> (http://bugs.winehq.org/attachment.cgi?id=18521) [details]
An executable which simulates a hard-working win32 threaded app.
Source would help.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #13 from Claudiu Curca Alexstrasza2@gmail.com 2009-01-06 13:20:47 --- Created an attachment (id=18535) --> (http://bugs.winehq.org/attachment.cgi?id=18535) Source code for HardWorker.exe
This is the source code for the HardWorker.exe attachment (the essential part... left out the Visual Studio project files since they were pretty large).
http://bugs.winehq.org/show_bug.cgi?id=11674
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
http://bugs.winehq.org/show_bug.cgi?id=11674
Steve McKnelly denali@shadowforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |denali@shadowforge.net
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #14 from Steve McKnelly denali@shadowforge.net 2009-01-06 16:08:37 --- I'm not certain if this remains true with version 3.0.x of the WoW client, but under 2.x.x, they didn't offload much in the way of threads to other cores/CPUs.
http://forums.worldofwarcraft.com/thread.html?topicId=4311170475&sid=1&a...
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #15 from Aneurin Price aneurin.price@gmail.com 2009-01-18 09:35:10 --- Created an attachment (id=18794) --> (http://bugs.winehq.org/attachment.cgi?id=18794) WoW CPU usage in Windows
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #16 from Aneurin Price aneurin.price@gmail.com 2009-01-18 09:35:59 --- Created an attachment (id=18795) --> (http://bugs.winehq.org/attachment.cgi?id=18795) WoW CPU usage in Windows when at FPS cap
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #17 from Aneurin Price aneurin.price@gmail.com 2009-01-18 09:42:35 --- I've added screenshots of the Windows task manager shortly after tabbing out of WoW in Windows. It should be pretty obvious in both of them when the game was minimised. In the first image I was just playing normally in an outdoor area, getting a framerate around 45fps, and I *believe* it's GPU-bound. In the second, I was just looking at the ground so as to get my framerate capped (the same behaviour is seen when playing indoors or other areas which are simpler to draw), which shows a slightly different pattern.
This should be enough to show that there is definitely more than one core in use by the game in Windows, beyond what would be seen by simply moving one thread from core to core.
http://bugs.winehq.org/show_bug.cgi?id=11674
Markus Amsler markus.amsler@oribi.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markus.amsler@oribi.org
--- Comment #18 from Markus Amsler markus.amsler@oribi.org 2009-02-17 11:22:54 --- I'm investigating the memory alloction performance of wine. With 1 thread, one core goes at 100% the other stays at 0%. With 2 thread both are between 40-60% and total around 105%. That's for a simple test program that just HeapAllocs/HeapFrees. That's exact the same behaviour as Wow. I also profiled wow, and with many objects heap_findfreeblock consumes up to 25% cpu time, and that's within a CriticalSection. So I'm quite convinced this is memory management issue. Unfortunately it looks like the memory manager needs another algorithm to not suck in a multi threaded environment.
http://bugs.winehq.org/show_bug.cgi?id=11674
Aaron Slunt tonglebeak@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tonglebeak@gmail.com
--- Comment #19 from Aaron Slunt tonglebeak@gmail.com 2009-05-04 20:17:06 --- Just wondering if there's an update to this? Thanks.
http://bugs.winehq.org/show_bug.cgi?id=11674
Norbert Lataille nonal@freesurf.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nonal@freesurf.fr
--- Comment #20 from Norbert Lataille nonal@freesurf.fr 2009-05-27 05:05:40 --- Hi,
As mentioned by may people here, WoW starts multiple threads but most of them are not doing a lot (offloading network, sound, some struct updates). When using GL engine, you have mainly one thread - CPU limited - and multiple others idle threads doing sideband things.
That's a game design limitation (I have not checked DX engine to see if it does graphics work with more threads - will do). But basically wine is not guilty here.
However, following some oprofiles and RDTSC traces, I tested some things in wine code to help FPS performance.
a/ Local optimizations in wine libs: timezone code cleaning (17 million cycles per tz conversion !), Event/Semaphore speed improvement (done through SHM), etc... => This brings some FPS to the game, but is not the main limiting factor
b/ Threading in opengl.dll.so Using NV drivers, I can see these are not threaded on Linux. Basically some runs show : 65% in the game, 35% in libGL.so
What I have done is to thread opengl.dll.so driver, ie still using one gl context, but the thread calling libGL is no longer the game one (basically this is serializing non-sync GL calls).
Preliminary tests have shown a quite interesting FPS improvement (remember seeing x3 once in raid 25 conditions), but all of this is quite experimental, and is not ready for general use.
http://bugs.winehq.org/show_bug.cgi?id=11674
jcorcoran@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jcorcoran@gmail.com
--- Comment #21 from jcorcoran@gmail.com 2009-05-30 16:29:35 --- (In reply to comment #20)
That's a game design limitation (I have not checked DX engine to see if it does graphics work with more threads - will do). But basically wine is not guilty here.
This struck me as very interesting. As we all know, WoW's OpenGL performance in Windows is a lot poorer than when using DX. It would make sense that the threading for DX is better written.
I love the idea of threading opengl.dll.so. It makes sense as to why we're getting such slowdowns when in high performance environments.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #22 from Norbert Lataille nonal@freesurf.fr 2009-06-02 07:42:59 ---
This struck me as very interesting. As we all know, WoW's OpenGL performance in Windows is a lot poorer than when using DX. It would make sense that the threading for DX is better written.
Well, I am not sure.
DX11 will bring better multi threading granularity to programmers, but Wow is not using this API...
I assume that wow code is modular with a DX or GL backend, non-mutlithreaded in both cases. To be confirmed. We need to check if when see 2 threads on Windows these are: 1/ display driver and 2/ Wow main thread. Running WoW in DX mode on wine would also show it.
However there is an option I would like to explore next. What I have seen on traces is that main thread (MT) hands over control to another thread (ST), and waits for completion of ST before continuing, and drawing next frame. There could be an implementation bug here (wine implementation of SetEvent/ClearEvent/WaitForxxx being too synchronous) but I doubt it.
I love the idea of threading opengl.dll.so. It makes sense as to why we're getting such slowdowns when in high performance environments.
GL is quite asynchronous. Most issues are coming from data/arrays you are sending to GLcore (you need to copy/use them before they are changed by the application), but VBO helps a lot here. In general I don't understand where this "pseudo-optim" to disable VBO came from (crappy ATI drivers ?)... For my tests I enable VBOs, it is far more efficient to indicate what data is (where, data size, give management options to the application for non-deformable vertex arrays !).
http://bugs.winehq.org/show_bug.cgi?id=11674
Elmoe scherpo@earlham.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scherpo@earlham.edu
--- Comment #23 from Elmoe scherpo@earlham.edu 2009-07-25 15:34:53 --- (In reply to comment #22)
Norbert, any update on your work on opengl.dll.so? Thanks!
http://bugs.winehq.org/show_bug.cgi?id=11674
Elmoe scherpo@earlham.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scherpo@earlham.edu
Aigars Mahinovs aigarius@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aigarius@gmail.com
--- Comment #23 from Elmoe scherpo@earlham.edu 2009-07-25 15:34:53 --- (In reply to comment #22)
Norbert, any update on your work on opengl.dll.so? Thanks!
--- Comment #24 from Aigars Mahinovs aigarius@gmail.com 2009-10-03 08:38:52 --- Any updates on this one. With 4 core processors we are now wasting 75% of the system's resources. With HT we have 8 cores and wasting 7/8th of the system resources by not being able to use it here.
http://bugs.winehq.org/show_bug.cgi?id=11674
JC jcorcoran@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|jcorcoran@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #25 from Norbert Lataille nonal@freesurf.fr 2009-10-06 15:00:51 --- (In reply to comment #23)
(In reply to comment #22)
Norbert, any update on your work on opengl.dll.so? Thanks!
Hi,
Stopped WOW sometime ago, before this work was polished enough for general use... Gave it to a friend (who using NV) in August to check on his side, and he was seeing some graphic corruption on his computer which means there are things not ironed on one (or multiple) calls.
As my wife subscribed to Aion, and I am looking forward to restart this work on the Aion side now (probably starting by a general look at performance hot spots on wine vs. windows on Aion). My understanding is that this threading work will benefit to the OpenGL implementation of DX3D. That's a general issue.
Thanks,
http://bugs.winehq.org/show_bug.cgi?id=11674
psychok9 psychok9@libero.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |psychok9@libero.it
--- Comment #26 from psychok9 psychok9@libero.it 2009-11-01 08:41:25 --- I've noticed the same problem: On Windows I'm using more cpu cores/cycles (48-50% of an Intel Quad Core cpu), on Wine/Ubuntu only 1 core with peak of 27% of cpu (1/4).
http://bugs.winehq.org/show_bug.cgi?id=11674
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
--- Comment #27 from Vitaliy Margolen vitaliy@kievinfo.com 2010-03-11 09:01:23 --- *** Bug 21994 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11674
CommonOddity EtherealTouch@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |EtherealTouch@gmail.com
--- Comment #28 from CommonOddity EtherealTouch@gmail.com 2010-08-06 09:25:26 --- I don't mean to rush anyone or apply pressure- far from, but out of curiosity is there anything new in regards to this bug? I've two machines that are dual core, both running WoW.
And thank you for all the great work! :D <3
http://bugs.winehq.org/show_bug.cgi?id=11674
Vitaliy ngsupb@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ngsupb@yahoo.com
--- Comment #29 from Vitaliy ngsupb@yahoo.com 2010-08-18 02:44:22 --- (In reply to comment #28)
I don't mean to rush anyone or apply pressure- far from, but out of curiosity is there anything new in regards to this bug? I've two machines that are dual core, both running WoW.
And thank you for all the great work! :D <3
Seems to be nothing new. I have got the same problem too.
http://bugs.winehq.org/show_bug.cgi?id=11674
Sergey albibek@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |albibek@yandex.ru
--- Comment #30 from Sergey albibek@yandex.ru 2010-09-07 02:10:27 CDT --- Is there any tempopary workaround we can do here? Something like disabling SMP(will the kernel use only one core with this option?) or setting affinity maybe?
http://bugs.winehq.org/show_bug.cgi?id=11674
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #31 from Wylda wylda@volny.cz 2010-09-07 02:45:26 CDT --- (In reply to comment #30)
Is there any tempopary workaround we can do here? Something like disabling SMP(will the kernel use only one core with this option?) or setting affinity maybe?
For sticking on CPU i use schedtool -a 0x1 -e wine app.exe //stick on first CPU
Then (to my understanding): schedtool -a 0x2 -e wine app.exe //stick on 2nd CPU schedtool -a 0x3 -e wine app.exe //stick on 1st + 2nd CPU ...
http://bugs.winehq.org/show_bug.cgi?id=11674
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|lukasz.wojnilowicz@gmail.co | |m |
http://bugs.winehq.org/show_bug.cgi?id=11674
Rudolf Mayerhofer rm@eightyfive.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rm@eightyfive.net
--- Comment #32 from Rudolf Mayerhofer rm@eightyfive.net 2010-09-16 08:18:31 CDT --- I've noticed something interesting on the 4.0.1 PTR today. Everytime that i got into a heavy load area WoW tries to get the current logical processor information, which is currently not implemented in Wine, giving the follwing error:
fixme:process:GetLogicalProcessorInformation (0x211e394,0x211e994): stub
MSDN describes GetLogicalProcessorInformation as "Retrieves information about logical processors and related hardware.".
My guess is that WoW tries to balance it's workload on the all available logical processors reported by GetLogicalProcessorInformation. Due to that being a stub in Wine the logical processor information can't be retrieved, which might result in WoW assuming that there's only one logical processor and not balancing it's workload at all.
http://bugs.winehq.org/show_bug.cgi?id=11674
ae aeforeve@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeforeve@mail.ru
--- Comment #33 from ae aeforeve@mail.ru 2010-09-16 11:04:20 CDT --- wine wow cataclysm smp cpu fix
--- dlls/kernel32/process.c_old 2010-08-20 23:23:50.000000000 +0600 +++ dlls/kernel32/process.c 2010-09-16 19:24:22.000000000 +0600 @@ -3333,11 +3333,36 @@ */ BOOL WINAPI GetLogicalProcessorInformation(PSYSTEM_LOGICAL_PROCESSOR_INFORMATION buffer, PDWORD pBufLen) { - FIXME("(%p,%p): stub\n", buffer, pBufLen); - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); - return FALSE; + *pBufLen=sizeof(SYSTEM_LOGICAL_PROCESSOR_INFORMATION)*3; + if(buffer==NULL){ + SetLastError(ERROR_INSUFFICIENT_BUFFER); + return FALSE; + } + + buffer[0].ProcessorMask=3; + buffer[0].Relationship=1; + buffer[0].NumaNode.NodeNumber=0; + buffer[0].Reserved[0]=0; + buffer[0].Reserved[1]=0; + + buffer[1].ProcessorMask=1; + buffer[1].Relationship=0; + buffer[1].ProcessorCore.Flags=0; + buffer[1].Reserved[0]=0; + buffer[1].Reserved[1]=0; + + buffer[2].ProcessorMask=2; + buffer[2].Relationship=0; + buffer[2].ProcessorCore.Flags=0; + buffer[2].Reserved[0]=0; + buffer[2].Reserved[1]=0; + +// FIXME("(%p,%p): stub\n", buffer, pBufLen); + return TRUE; }
+ + /*********************************************************************** * GetLogicalProcessorInformationEx (KERNEL32.@) */
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #34 from Rudolf Mayerhofer rm@eightyfive.net 2010-09-16 12:58:09 CDT --- Created an attachment (id=30805) --> (http://bugs.winehq.org/attachment.cgi?id=30805) Partial Implementation of GetLogicalProcessorInformation
After seeing the patch from ae, which is for dual-core only, i decided to start up my Windows 7 VM and try the simple test program for GetLogicalProcessorInformation provided by the MSDN.
This patch tries to replicate the Windows 7 behaviour as close as possible. The cache and logical processor handling is currently not in this patch as i haven't found a simple way to retrieve those infos.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #35 from ae aeforeve@mail.ru 2010-09-16 13:53:16 CDT ---
My guess is that WoW tries to balance it's workload on the all available logical processors reported by GetLogicalProcessorInformation. Due to that being a stub in Wine the logical processor information can't be retrieved, which might result in WoW assuming that there's only one logical processor and not balancing it's workload at all.
no no Only is it is used in drawing installations - without 2 core it is impossible to put quality of texture the maximum
At WoW all also ONLY really working thread - ~10 threads all others - service Both on linux and on Windows
And mine patch it is simple for fast correction of impossibility of sample of the maximum quality of texture
And real correction in a code - as in your patch - that is good - but it is necessary at the analysis /proc/cpuinfo in dlls/ntdll/nt.c to check and establish not only number of processors but also number hypertreading-a
http://bugs.winehq.org/show_bug.cgi?id=11674
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=11674
philippe.gislard@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |philippe.gislard@gmail.com
--- Comment #36 from philippe.gislard@gmail.com 2010-09-21 14:10:22 CDT --- (In reply to comment #33)
wine wow cataclysm smp cpu fix
--- dlls/kernel32/process.c_old 2010-08-20 23:23:50.000000000 +0600 +++ dlls/kernel32/process.c 2010-09-16 19:24:22.000000000 +0600 @@ -3333,11 +3333,36 @@ */ BOOL WINAPI GetLogicalProcessorInformation(PSYSTEM_LOGICAL_PROCESSOR_INFORMATION buffer, PDWORD pBufLen) {
- FIXME("(%p,%p): stub\n", buffer, pBufLen);
- SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
- return FALSE;
- *pBufLen=sizeof(SYSTEM_LOGICAL_PROCESSOR_INFORMATION)*3;
- if(buffer==NULL){
SetLastError(ERROR_INSUFFICIENT_BUFFER);
return FALSE;
}
- buffer[0].ProcessorMask=3;
- buffer[0].Relationship=1;
- buffer[0].NumaNode.NodeNumber=0;
- buffer[0].Reserved[0]=0;
- buffer[0].Reserved[1]=0;
- buffer[1].ProcessorMask=1;
- buffer[1].Relationship=0;
- buffer[1].ProcessorCore.Flags=0;
- buffer[1].Reserved[0]=0;
- buffer[1].Reserved[1]=0;
- buffer[2].ProcessorMask=2;
- buffer[2].Relationship=0;
- buffer[2].ProcessorCore.Flags=0;
- buffer[2].Reserved[0]=0;
- buffer[2].Reserved[1]=0;
+// FIXME("(%p,%p): stub\n", buffer, pBufLen);
- return TRUE;
}
/***********************************************************************
GetLogicalProcessorInformationEx (KERNEL32.@)
*/
Does this patch has an impact on WoW performances on dual core processors ?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #37 from ae aeforeve@mail.ru 2010-09-22 02:03:28 CDT ---
Does this patch has an impact on WoW performances on dual core processors ?
No WoW in itself isn't able to use effectively smp and while blizzard won't make it in a code - any patches not to help
This patch only for inclusion of possibility of sample in betta cataclysm the maximum quality graphics
http://bugs.winehq.org/show_bug.cgi?id=11674
Rudolf Mayerhofer rm@eightyfive.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30805|0 |1 is obsolete| |
--- Comment #38 from Rudolf Mayerhofer rm@eightyfive.net 2010-10-01 06:50:40 CDT --- Created an attachment (id=31045) --> (http://bugs.winehq.org/attachment.cgi?id=31045) Linux/SysFS based Implementation of getLogicalProcessorInformation
I just updated my implementation of GetLogicalProcessorInformation to use the data provided in /sys/devices/system/
This gives me at least a subjective performance increase while playing WoW.
If anyone wants to give it a try, here's the full patch. I'm also planning to split it and send it to wine-patches as soon as i have some free time.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #39 from philippe.gislard@gmail.com 2010-10-01 08:54:42 CDT --- (In reply to comment #38)
Created an attachment (id=31045)
--> (http://bugs.winehq.org/attachment.cgi?id=31045) [details]
[...]
This gives me at least a subjective performance increase while playing WoW.
[...].
Wow Cataclysm or Wow 3.3.5 ?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #40 from Rudolf Mayerhofer rm@eightyfive.net 2010-10-01 09:01:05 CDT --- (In reply to comment #39)
(In reply to comment #38)
Created an attachment (id=31045)
--> (http://bugs.winehq.org/attachment.cgi?id=31045) [details] [details]
[...]
This gives me at least a subjective performance increase while playing WoW.
[...].
Wow Cataclysm or Wow 3.3.5 ?
Both, tried 4.0.1 PTR and 3.3.5 Live. In both cases running/flying around in Dalaran and other heavy graphic areas (like Grizzly hills) seemed much smoother.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #41 from philippe.gislard@gmail.com 2010-10-01 09:11:04 CDT --- (In reply to comment #40)
(In reply to comment #39)
(In reply to comment #38)
Created an attachment (id=31045)
--> (http://bugs.winehq.org/attachment.cgi?id=31045) [details] [details] [details]
[...]
This gives me at least a subjective performance increase while playing WoW.
[...].
Wow Cataclysm or Wow 3.3.5 ?
Both, tried 4.0.1 PTR and 3.3.5 Live. In both cases running/flying around in Dalaran and other heavy graphic areas (like Grizzly hills) seemed much smoother.
What about the CPU load ? Did you see any change ? Does it load more than 50% on both cores ?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #42 from Rudolf Mayerhofer rm@eightyfive.net 2010-10-01 09:52:18 CDT --- (In reply to comment #41)
What about the CPU load ? Did you see any change ?
CPU load didn't change notably.
Does it load more than 50% on both cores ?
No, definitely not. It's the same as on Windows, one core at almost 100%, the other(s) idle around 0-25% once the game has loaded. I guess there might be some WoW internal optimization going on with the Data provided by GetLogicalProcessorInformation (which is called rather often, esp. in heavy load areas / during times with heavy load) thus the smoother feeling but thats all speculation from my side.
http://bugs.winehq.org/show_bug.cgi?id=11674
Wes Garner wesgarner@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wesgarner@gmail.com
--- Comment #43 from Wes Garner wesgarner@gmail.com 2010-10-01 13:23:27 CDT --- (In reply to comment #39)
(In reply to comment #38)
Created an attachment (id=31045)
--> (http://bugs.winehq.org/attachment.cgi?id=31045) [details] [details]
[...]
This gives me at least a subjective performance increase while playing WoW.
[...].
Wow Cataclysm or Wow 3.3.5 ?
Looks good - tons O whitespaces though lol if anyone is too lazy to really go through the patching and etc, I posted the source + this patch on github: http://github.com/wesgarner/wine
http://bugs.winehq.org/show_bug.cgi?id=11674
Rudolf Mayerhofer rm@eightyfive.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #31045|0 |1 is obsolete| |
--- Comment #44 from Rudolf Mayerhofer rm@eightyfive.net 2010-10-03 09:58:57 CDT --- Created an attachment (id=31091) --> (http://bugs.winehq.org/attachment.cgi?id=31091) Updated implementation of GetLogicalProcessorInformation
This an update to my implementation (also on wine-patches now), which avoids changing the NT SystemClass.
http://bugs.winehq.org/show_bug.cgi?id=11674
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #45 from Jerome Leclanche adys.wh@gmail.com 2010-11-22 17:29:42 CST --- (In reply to comment #44)
Created an attachment (id=31091)
--> (http://bugs.winehq.org/attachment.cgi?id=31091) [details]
Updated implementation of GetLogicalProcessorInformation
This an update to my implementation (also on wine-patches now), which avoids changing the NT SystemClass.
Hi Rudolf
I see you haven't sent a new patch attempt for a while. Can you give details on what's still missing and where the latest patch is?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #46 from Rudolf Mayerhofer rm@eightyfive.net 2010-11-27 11:20:33 CST --- (In reply to comment #45)
(In reply to comment #44)
Created an attachment (id=31091)
--> (http://bugs.winehq.org/attachment.cgi?id=31091) [details] [details]
Updated implementation of GetLogicalProcessorInformation
This an update to my implementation (also on wine-patches now), which avoids changing the NT SystemClass.
Hi Rudolf
I see you haven't sent a new patch attempt for a while. Can you give details on what's still missing and where the latest patch is?
Unfortunately i'm too busy to work on this patch at the moment(I am currently writing my master thesis, which takes lots of time, and my job takes the rest). I'll update the patch in this bug with my latest version, which supports everything Windows offers for GetLogicalProcessorInformation (as far as i could test).
http://bugs.winehq.org/show_bug.cgi?id=11674
Rudolf Mayerhofer rm@eightyfive.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #31091|0 |1 is obsolete| |
--- Comment #47 from Rudolf Mayerhofer rm@eightyfive.net 2010-11-27 11:22:55 CST --- Created an attachment (id=32177) --> (http://bugs.winehq.org/attachment.cgi?id=32177) Updated implementation of GetLogicalProcessorInformation (2010-11-27)
requires wine >=1.3.5
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #48 from Vitaliy ngsupb@yahoo.com 2010-12-25 03:12:42 CST --- (In reply to comment #47)
Created an attachment (id=32177)
--> (http://bugs.winehq.org/attachment.cgi?id=32177) [details]
Updated implementation of GetLogicalProcessorInformation (2010-11-27)
requires wine >=1.3.5
Hi Rudolf,
Is this patch already added into Wine? Do I need to patch it manually?
thank you
http://bugs.winehq.org/show_bug.cgi?id=11674
Dmitrii dim0n-error@narod.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dim0n-error@narod.ru
--- Comment #49 from Dmitrii dim0n-error@narod.ru 2010-12-26 04:32:49 CST --- (In reply to comment #47)
Created an attachment (id=32177)
--> (http://bugs.winehq.org/attachment.cgi?id=32177) [details]
Updated implementation of GetLogicalProcessorInformation (2010-11-27)
requires wine >=1.3.5
What makes this patch? I installed it on Wine 1.3.9, and nothing has changed. So it should be?
http://bugs.winehq.org/show_bug.cgi?id=11674
Devin Cofer ranguvar@archlinux.us changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ranguvar@archlinux.us
--- Comment #50 from Devin Cofer ranguvar@archlinux.us 2010-12-30 13:24:54 CST --- (In reply to comment #48)
(In reply to comment #47)
Created an attachment (id=32177)
--> (http://bugs.winehq.org/attachment.cgi?id=32177) [details] [details]
Updated implementation of GetLogicalProcessorInformation (2010-11-27)
requires wine >=1.3.5
Hi Rudolf,
Is this patch already added into Wine? Do I need to patch it manually?
thank you
This patch is not in Wine -- if it were, the patch would not apply when you try, would it?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #51 from Devin Cofer ranguvar@archlinux.us 2010-12-30 13:32:18 CST --- Never mind, the patch does not apply to latest -git. Now I feel silly. I don't think it's in the main source though.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #52 from ae aeforeve@mail.ru 2011-02-14 17:02:14 CST --- http://www.aewi.info/rgl/wine-1.3.13_rgl.patch.gz
patch (hack) optimizing operation World of Warcraft in Wine The request test - the gain fps should be to 2 times on two-core and above to system (in 2 times it is a theoretical maximum) This patch sharpens wine on WoW - another 3д the program most likely simply won't go with it wine
Operation essence - it is primary WoW shorthands logic and deduces a drawing in one flow (as works under Windows I do not know)
patch - does the following - collects all calls opengl func from the main flow in буффер and sends on execution to the second flow
Thereby the such triple frame buffer is reached The first frame considers logician WoW - and all commands gather for an output in the buffer The second frame - an additional flow sends on a video card And the third frame - that that shows videocart
Lack of operation WoW in linux in comparison with Windows - very much and very ancient - why so - i do not know
Productivity in game it is possible to measure precisely a trace a method - after a command /script SetTexiBenchmarkMode (1); the trace weeds by a taxi in the end will produce statistics Also it is possible for those testing
Comments are welcomed :)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #53 from Devin Cofer ranguvar@archlinux.us 2011-02-14 19:54:29 CST --- (In reply to comment #52)
http://www.aewi.info/rgl/wine-1.3.13_rgl.patch.gz
patch (hack) optimizing operation World of Warcraft in Wine The request test - the gain fps should be to 2 times on two-core and above to system (in 2 times it is a theoretical maximum) This patch sharpens wine on WoW - another 3д the program most likely simply won't go with it wine
Operation essence - it is primary WoW shorthands logic and deduces a drawing in one flow (as works under Windows I do not know)
patch - does the following - collects all calls opengl func from the main flow in буффер and sends on execution to the second flow
Thereby the such triple frame buffer is reached The first frame considers logician WoW - and all commands gather for an output in the buffer The second frame - an additional flow sends on a video card And the third frame - that that shows videocart
Lack of operation WoW in linux in comparison with Windows - very much and very ancient - why so - i do not know
Productivity in game it is possible to measure precisely a trace a method - after a command /script SetTexiBenchmarkMode (1); the trace weeds by a taxi in the end will produce statistics Also it is possible for those testing
Comments are welcomed :)
I just really wish I understood this better :( I'm sorry, I know this probably isn't your native language.
I will try the patch though.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #54 from Devin Cofer ranguvar@archlinux.us 2011-02-14 22:14:47 CST --- The patch seems to cause major sound stuttering problems from the login screen on, reliably. This is using latest -git, ALSA backend.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #55 from Vitaliy ngsupb@yahoo.com 2011-02-15 00:08:33 CST ---
Comments are welcomed :)
Thanks ae! I will try to apply the patch.
/wave from Ukraine
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #56 from Dmitriy dim0n-error@narod.ru 2011-02-15 05:18:32 CST --- Created an attachment (id=33302) --> (http://bugs.winehq.org/attachment.cgi?id=33302) log
http://bugs.winehq.org/show_bug.cgi?id=11674
Dmitriy dim0n-error@narod.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33302|log |Thanks! FPS has grown till description| |50-60, but instead of the | |screen of an input I have | |received the black screen.
http://bugs.winehq.org/show_bug.cgi?id=11674
Dmitriy dim0n-error@narod.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33302|Thanks! FPS has grown till |black screen log after description|50-60, but instead of the |patching wine 1.3.13 |screen of an input I have | |received the black screen. |
--- Comment #57 from Dmitriy dim0n-error@narod.ru 2011-02-15 05:21:13 CST --- (From update of attachment 33302) Thanks! FPS has grown till 50-60, but instead of the screen of an input I have received the black screen.
http://bugs.winehq.org/show_bug.cgi?id=11674
Rudolf Mayerhofer rm@eightyfive.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|rm@eightyfive.net |
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #58 from ae aeforeve@mail.ru 2011-02-15 05:57:51 CST --- Dmitriy про этот глюк патча знаю - но как исправить пока не знаю это изза синхронизации доступа к видеокарте из двух потоков
грубо говоря - при запуске вов - не переключайся туда сюда по окнам - тогда нормально будет а 60 fps - это синхронизация кадровая включена - у меня на стартовом дракончике 500-550 фпс (без патча около 300 было)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #59 from Aigars Mahinovs aigarius@gmail.com 2011-02-15 06:11:34 CST --- (Translation of comment #58)
Dmitriy про этот глюк патча знаю - но как исправить пока не знаю это изза синхронизации доступа к видеокарте из двух потоков
грубо говоря - при запуске вов - не переключайся туда сюда по окнам - тогда нормально будет а 60 fps - это синхронизация кадровая включена - у меня на стартовом дракончике 500-550 фпс (без патча около 300 было)
(For the benefit of the English speaking subscribers) [..] The stuttering and blacks screen [..] are known issues of this patch, but I don't yet know how to fix them. This is caused by two threads compeating for access to the video card.
For now (with this patch) when you launch WoW, don't switch windows too much, then the bug is less prominent. If you get 60 fps, that means you have VSync enabled. I get around 500-550 fps on the login screen with the patch (had 300 without it).
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #60 from Dmitriy dim0n-error@narod.ru 2011-02-15 06:39:56 CST --- (In reply to comment #58)
Dmitriy про этот глюк патча знаю - но как исправить пока не знаю это изза синхронизации доступа к видеокарте из двух потоков
грубо говоря - при запуске вов - не переключайся туда сюда по окнам - тогда нормально будет а 60 fps - это синхронизация кадровая включена - у меня на стартовом дракончике 500-550 фпс (без патча около 300 было)
да я даже мышкой не двигаю, не говоря уже об окнах. пробовал оконный и полноэкранный режимы, игрался с настройками, в результате заметил: - при включении вертикальной синхронизации WoW вылетает с 132ой ошибкой. - в полноэкранном режиме через раз просто вылетает, а на другой раз опять черный экран. - через 30-40 секунд черного экрана процесс становится зомби с ожиданием в ядре do_exit, но при этом звук не прекращается, только пропадает реакция на элементы управления.(в том числе и клавиатуру)
до патча мой фпс на драконе был около 10. =) но это видюха просто не особо хорошая.(Intel 945GM). по миру на пределе видюхи выходило около 30, но по факту выходило меньше из-за процессора(точнее использования одного его ядра). синхронизация в игре у меня отключена.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #61 from Nikolay Sivov bunglehead@gmail.com 2011-02-15 06:53:52 CST --- Guys, this bugzilla is English speaking only. You're always able to chat on email.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #62 from ae aeforeve@mail.ru 2011-02-15 06:57:59 CST --- (In reply to comment #60)
(In reply to comment #58)
Dmitriy
до патча мой фпс на драконе был около 10. =) но это видюха просто не особо хорошая.(Intel 945GM). по миру на пределе видюхи выходило около 30, но по факту выходило меньше из-за процессора(точнее использования одного его ядра). синхронизация в игре у меня отключена.
Intel 945GM It is not absolutely suitable video card for the test :)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #63 from Vitaliy ngsupb@yahoo.com 2011-02-15 07:43:37 CST --- (In reply to comment #52)
Comments are welcomed :)
I have tested the patch.
Guys, dunno what this patch does, but appears it works...
Staying on the same place without moving I get around 15 fps with the default wine. Upgrading to the patched wine gives 20-21 fps on the same place in the game, something like +30% fps boost for me :)
It was tested on my notebook's GS 8400m, with the 1920*1080 resolution, so numbers aren't large.
But I had the following problems:
1) Sound issue 2) For some reason most of the time I couldn't start wow at all. Without any reason it starts sometimes. 3) Got a few times segfault 4) Alt+tab crashes wow
Very unstable, but it does work.
ae, please keep up doing the magic!:)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #64 from ae aeforeve@mail.ru 2011-02-16 18:58:35 CST --- http://www.aewi.info/rgl/wine-1.3.13_rgl.patch.gz
new verison patch bugfix bugfix
1) Sound issue (fixed) 2) For some reason most of the time I couldn't start wow at all. Without any reason it starts sometimes. (fixed) 3) Got a few times segfault (fixed (not 100%)) 4) Alt+tab crashes wow (fixed)
not fixed issue - crash before change video setting in WoW
please testing
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #65 from Vitaliy ngsupb@yahoo.com 2011-02-17 09:17:55 CST --- (In reply to comment #64)
http://www.aewi.info/rgl/wine-1.3.13_rgl.patch.gz
new verison patch bugfix bugfix
- Sound issue (fixed)
- For some reason most of the time I couldn't start wow at all. Without any
reason it starts sometimes. (fixed) 3) Got a few times segfault (fixed (not 100%)) 4) Alt+tab crashes wow (fixed)
not fixed issue - crash before change video setting in WoW
please testing
Thanks AE!
works much better now. I got a few times segfault at the beginning but it worked fine during the last tests I made.
So my results by using /script SetTaxiBenchmarkMode(1); on the same place.
8400m gs 128mb, 1280*800:
Default wine 21-25 FPS Patched wine 31.9 FPS Windows DirectX 31.6 FPS.
So the funniest thing - it gives for me the same performance as directX on Windows 7 with directx.
have AE added something that makes working openGL on multicore in similar way as directX?
Would be nice to see tests from other guys since my video card isn't so good to see much difference. But I am happy anyway:)
http://bugs.winehq.org/show_bug.cgi?id=11674
gbillios@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gbillios@gmail.com
--- Comment #66 from gbillios@gmail.com 2011-02-19 03:17:32 CST --- (In reply to comment #64)
http://www.aewi.info/rgl/wine-1.3.13_rgl.patch.gz
new verison patch bugfix bugfix
- Sound issue (fixed)
- For some reason most of the time I couldn't start wow at all. Without any
reason it starts sometimes. (fixed) 3) Got a few times segfault (fixed (not 100%)) 4) Alt+tab crashes wow (fixed)
not fixed issue - crash before change video setting in WoW
please testing
Just amazing! I've set the fps cap to 45 and while in ogrimmar it almost never drops below 45!
I see at least 2 cores working over 60% and in general the load is shared between the cores.
Haven't tested it yet more extensively but I will and report back any new findings. Thanks for this great patch!
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #67 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-19 04:01:38 CST --- (In reply to comment #64)
http://www.aewi.info/rgl/wine-1.3.13_rgl.patch.gz
new verison patch
This patch looks like a complete overkill and disaster. It's full of a not necessary formatting, space changes, and commented out debugging code.
What is it about? Is it about the GetLogicalProcessorInformation() hack? Or about ENTER_GL()/LEAVE_GL() removal? Or perhaps it's about new fancy GL calls thunking/locking?
Author, please try to clearly separate the issues you are trying to work on, and figure out first what changes really make the difference. Then try to separate the changes into distinct patches, and add clear comments (basically for yourself) what you are trying to achieve with every change.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #68 from ae aeforeve@mail.ru 2011-02-19 04:48:01 CST ---
Author, please try to clearly separate the issues you are trying to work on, and figure out first what changes really make the difference. Then try to separate the changes into distinct patches, and add clear comments (basically for yourself) what you are trying to achieve with every change.
:) yes - looks like a complete overkill and disaster - But it has worked !
ENTER_GL ()/LEAVE_GL () cosmetic functions - completely idle when are drawn by one thread
And that here to divide? I have completely described that as for what and for what idea this is made патчь (hack)
We collect all вызыва opengl and it is played back them in the second thread
That's all
(rus version) а чего тут разделять то - просто так достали тормаза в вов - что пришла в голову такая идея - и я сделал патчь чтоб ее проверить - и сработало
собирает вызывы опенгл-а в одной нити и воспроизводим их во второй - спец созданной для этого нити - и это сработало нетолько возрос фпс но и пропали те самые (№;%№;%;:) постоянные подлагивания
до полного уровня винды это недоведет - там еще куча мест что уменьшает производительность - одно то что вайн при работе под вов-ом делает около 50 тысяч контент свитчей (отчасти изза винесервер) - привносит достатчьно приличное падение (5-10%)
и яж говорю - это скорее не патчь - это хак - для проверки идеи
http://bugs.winehq.org/show_bug.cgi?id=11674
gpiez@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gpiez@web.de
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #69 from gpiez@web.de 2011-02-19 09:17:10 CST --- ae, really great patch.
My fps goes up by a large amount and finally wow uses more than one core. But every change of the video settings ingame causes a crash for me.
Now you only need to sort out the remaining bugs and make it somewhat less intrusive. What about redefining BEGIN_GL() and END_GL() instead of removing it everywhere?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #70 from Devin Cofer ranguvar@archlinux.us 2011-02-19 21:22:46 CST --- Using the revised patch, there are still some issues for me. In certain areas, my FPS nosedives -- I think there was one in Orgrimmar, but there's definitely one inside the inn at Cenarion Refuge in Zangarmarsh. Walking around inside the inn gives me 43-60fps with vanilla Wine, but with the patch, I get about 13fps. These are reliable results.
I'm using an NVIDIA GeForce 9600 GT with 512MiB of RAM, blob driver v270.26. Resolution 1920x1200, 4x anti-aliasing, CPU is a quad-core Intel Core 2 Q6600.
If you could take a look? Thanks very much.
http://bugs.winehq.org/show_bug.cgi?id=11674
Vidar Haarr vhaarr+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vhaarr+wine@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
Dmitry dmitry923@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry923@gmail.com
--- Comment #71 from Dmitry dmitry923@gmail.com 2011-03-06 03:19:33 CST --- (In reply to comment #64)
First of all thanks for the great work. The performance boost is great but there are some problems as well. Here's the results of my benchmarking. I used a taxi in Twilight Highlands flying by the same route. Tested on ATI HD 5870, Intel Q9550 (average fps): Wine - 70 Wine patched - 117.8 (+68,2%) Windows d3d11 - 158.2 Windows d3d9 - 170.4 Windows OpenGL - 70.8
As for the bugs: 1)I tested the patch on a notebook with Nvidia 8400m G, Intel T5250 as well. I managed to start WoW normally with Nvidia, but with ATI I got the following output ( http://pastebin.com/Z1NPaQ13 ). I managed to start WoW with the following command: "WINEDEBUG=+wgl wine Wow.exe -opengl". 2)Changing video options in game causes it to crash, but you can change them at the login screen (that with the dragon). 3)Sometimes the game crashes especially when a lot of new objects load (going from one location to another, telepoting, entering the world). Changing texture quality to minimum seems to solve that problem. 4)Making a screenshot causes the game to hang. 5)Some minor graphical glitches with reflections http://img825.imageshack.us/img825/2602/screenshot201103061444.png 6)The game freezes randomly (usually every 10-15 minutes). The cursor can be moved but the image is frozen. Alt+tabing doesn't help. Sometimes switching to console and back (alt+ctrl+f1, alt+ctrl+f7) revives the game till the next freeze. Tried launching the WoW in a separate X session but it didn't help.
If not for the latter bug, I would use the patched wine on a regular basis. All other bugs can be lived with but the unpredictable freezes ruin the joy of the performance boost completely.
Russian: В первую очередь большое спасибо за отличный патч. Производтельность здорово возросла, но есть и проблемы. Тестировал полетами на такси в Сумеречном нагорье, летая по одному маршруту, на ATI HD 5870, Intel Q9550 (средний fps): Wine - 70 Wine patched - 117.8 (+68,2%) Windows d3d11 - 158.2 Windows d3d9 - 170.4 Windows OpenGL - 70.8
Нашел следующие баги: 1)Также попробовал патченный вайн на ноуте с Nvidia 8400m G, Intel T5250. Там ВоВ запустился сразу, а на десктопе с АТИ он сегфолтился со следующим выводом ( http://pastebin.com/Z1NPaQ13 ). Запустить получилось командой "WINEDEBUG=+wgl wine Wow.exe -opengl" 2)Перелючение видео опций в игре приводит к вылету, но их можно менять на старте в меню с драконом. 3)Временами игра вылетает, когда много новых объектов загружается (при пересечении границ локаций, телепортировании, при заходе в мир). Если снизить качество текстур до минимума, то вроде проблема пропадает. 4)Попытка сделать скриншот в игре ее вешает. 5)Небольшие глюки с отображением отражений в некоторых местах http://img825.imageshack.us/img825/2602/screenshot201103061444.png 6)Временами игра зависает (обычно каждые 10-15 минут). Курсор при этом двигается, но картинка висит. Иногда получается ее оживить до следующего раза, если переключиться в консоль и обратно (alt+ctrl+f1, alt+ctrl+f7). Пробовал запускать в отдельной Х сессии, не помогло.
Если бы не последний глюк, то можно было бы смело использовать патченный вайн на постоянной основе. С остальными глюками вполне можно жить, но неожиданные зависания портят всю радость от прироста производительности.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #72 from ae aeforeve@mail.ru 2011-03-21 04:49:40 CDT --- new verison rgl patch
http://www.aewi.info/rgl/rgl.patch.gz pliz test
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #73 from Vidar Haarr vhaarr+wine@gmail.com 2011-03-21 05:53:49 CDT --- When launching WoW with the latest rgl patch, wine doesn't seem to find a suitable 3D device; fixme:win:EnumDisplayDevicesW ((null),0,0x32ed7c,0x00000000), stub! err:d3d_caps:IWineD3DImpl_FillGLCaps Received a NULL GL_RENDERER. err:d3d:InitAdapters Failed to initialize gl caps for default adapter Direct3D9 is not available without OpenGL. err:d3d_caps:IWineD3DImpl_FillGLCaps Received a NULL GL_RENDERER. err:d3d:InitAdapters Failed to initialize gl caps for default adapter Direct3D9 is not available without OpenGL.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #74 from gbillios@gmail.com 2011-03-21 07:20:43 CDT --- (In reply to comment #73)
When launching WoW with the latest rgl patch, wine doesn't seem to find a suitable 3D device; fixme:win:EnumDisplayDevicesW ((null),0,0x32ed7c,0x00000000), stub! err:d3d_caps:IWineD3DImpl_FillGLCaps Received a NULL GL_RENDERER. err:d3d:InitAdapters Failed to initialize gl caps for default adapter Direct3D9 is not available without OpenGL. err:d3d_caps:IWineD3DImpl_FillGLCaps Received a NULL GL_RENDERER. err:d3d:InitAdapters Failed to initialize gl caps for default adapter Direct3D9 is not available without OpenGL.
I had this issue on previous versions of the patch also but it only affects D3D applications and not opengl, thats why I have two versions of wine on my system one with the patch and one vanilla.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #75 from ae aeforeve@mail.ru 2011-03-21 07:46:40 CDT --- Has checked up in separate assemblage at itself - works
This version - in difference from last - it is possible to name a patch (instead of hack)
From known glitches - falls at play video from a starting page
Check on stability is necessary - is better if the situation which is precisely reproduced - that it was possible to search for a problem in code
russian version: проверил в отдельной сборке у себя - работает
эта версия - в отличии от прошлой - можно назвать патчем (а не хаком)
из известных глюков - падает при попытке воспроизведении видео со стартовой странички
нужна проверка на стабильность - лучше всего если будет найдена ситуация которая точно воспроизводиться - чтоб можно было искать проблему в коде
http://bugs.winehq.org/show_bug.cgi?id=11674
Wouter de Geus benv-wine.org@junerules.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |benv-wine.org@junerules.com
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #76 from gpiez@web.de 2011-03-23 12:40:58 CDT --- With the first try I got the start screen with the dragon, but the game was frozen. No input possible. I tried several time after that and only got a black screen so far.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #77 from gbillios@gmail.com 2011-03-23 13:37:28 CDT --- (In reply to comment #75)
Has checked up in separate assemblage at itself - works
This version - in difference from last - it is possible to name a patch (instead of hack)
From known glitches - falls at play video from a starting page
Check on stability is necessary - is better if the situation which is precisely reproduced - that it was possible to search for a problem in code
russian version: проверил в отдельной сборке у себя - работает
эта версия - в отличии от прошлой - можно назвать патчем (а не хаком)
из известных глюков - падает при попытке воспроизведении видео со стартовой странички
нужна проверка на стабильность - лучше всего если будет найдена ситуация которая точно воспроизводиться - чтоб можно было искать проблему в коде
Checking this version with wine 1.3.3 a couple of days now, lvling through hyjal has been a pleasure, also flighting around and across different zones hasn't crashed the game as with the previous version.
very very good up to now.
http://bugs.winehq.org/show_bug.cgi?id=11674
Juho Teperi teeepeli@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |teeepeli@gmail.com
--- Comment #78 from Juho Teperi teeepeli@gmail.com 2011-03-23 15:11:45 CDT --- Tried patch with wine 1.3.16. Worked fine for few hours at Stormwind but crashed when I took portal to Deepholm and has crashed after that every time when I try to login into that character. Alt on Ironforge works fine though.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #79 from Devin Cofer ranguvar@archlinux.us 2011-03-23 17:46:54 CDT --- This patch needs far better (English) documentation, and needs to be split up into each piece of the overall job, so each piece can be confirmed stable or causing a problem.
I love the performance boost, but it's just too unreliable and I fear it will be lost in time once its developer gives up on it rather than its ideas being looked at further.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #80 from ae aeforeve@mail.ru 2011-03-23 20:18:21 CDT --- Created an attachment (id=33793) --> (http://bugs.winehq.org/attachment.cgi?id=33793) rgl patch
new patch
bugs fix - the error leading to falling is found and corrected
http://bugs.winehq.org/show_bug.cgi?id=11674
Macie macie@linuxfusion.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |macie@linuxfusion.net
--- Comment #81 from Macie macie@linuxfusion.net 2011-03-28 18:58:09 CDT --- The performance improvement is quite nice. However, I also have the freezing problem mentioned above (every 10 to 30 minutes) which either requires CTRL to be pressed to unfreeze, or CLT+ALT+F1, or a game restart after force quitting.
After several hours of play that is the only major bug I noticed, and if resolved, can be quite an feat for at least WoW.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #82 from Jerome Leclanche adys.wh@gmail.com 2011-03-28 19:07:12 CDT --- (In reply to comment #81)
The performance improvement is quite nice. However, I also have the freezing problem mentioned above (every 10 to 30 minutes) which either requires CTRL to be pressed to unfreeze, or CLT+ALT+F1, or a game restart after force quitting.
After several hours of play that is the only major bug I noticed, and if resolved, can be quite an feat for at least WoW.
The freezing issues happen to me on vanilla wine, they may not be related to this patch.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #83 from Macie macie@linuxfusion.net 2011-03-28 19:39:20 CDT --- (In reply to comment #82)
(In reply to comment #81)
The performance improvement is quite nice. However, I also have the freezing problem mentioned above (every 10 to 30 minutes) which either requires CTRL to be pressed to unfreeze, or CLT+ALT+F1, or a game restart after force quitting.
After several hours of play that is the only major bug I noticed, and if resolved, can be quite an feat for at least WoW.
The freezing issues happen to me on vanilla wine, they may not be related to this patch.
Don't have freezing issues with vanilla wine 1.3.16 running Gentoo 64bit w/ kernel 2.6.38, and most recent nvidia drivers. But the performance is not as solid.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #84 from ae aeforeve@mail.ru 2011-03-28 20:45:19 CDT --- http://www.aewi.info/rgl/rgl.patch.gz
new version patch
fix bugs small improve performance (alfa) support d3d in WoW
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #85 from Devin Cofer ranguvar@archlinux.us 2011-03-29 14:07:23 CDT --- Works fine with wine-1.3.16, needs update for current -git.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #86 from ae aeforeve@mail.ru 2011-03-29 16:22:37 CDT --- Actually - this bugs can be closed
wine normally supports smp in WoW
And the reason of slow operation is very simple - on Windows - in drivers of video cards - at Nvidia and Ati - there is such section - optimization for specific applications is called
And if to ungear this optimization in Windows - WoW starts to work on 1 kernel And if to include - that on two
Here and all error
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #87 from ae aeforeve@mail.ru 2011-03-31 16:54:45 CDT --- http://www.aewi.info/rgl/rgl.patch.gz
new version
fix work ATI videocard (test Radeon HD5570)
http://www.aewi.info/rgl/rgl_max.patch maximization performance (~10%) decrease content switch from 45000-55000 to 10000-20000 in second
http://bugs.winehq.org/show_bug.cgi?id=11674
facilbeatboxer facilbeatboxer@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |facilbeatboxer@gmail.com
--- Comment #88 from facilbeatboxer facilbeatboxer@gmail.com 2011-04-01 00:28:06 CDT --- Hello im new on linux and i have this problem i have the patch but i dont know hoe to patch wine if someone can help me please?
my email : facilbeatboxer@gmail.com
thx
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #89 from Jerome Leclanche adys.wh@gmail.com 2011-04-01 00:57:08 CDT --- (In reply to comment #88)
Hello im new on linux and i have this problem i have the patch but i dont know hoe to patch wine if someone can help me please?
my email : facilbeatboxer@gmail.com
thx
This bugzilla is not a support forum. Use the Wine forum for that.
http://bugs.winehq.org/show_bug.cgi?id=11674
Fresno acafresna@ono.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |acafresna@ono.com
--- Comment #90 from Fresno acafresna@ono.com 2011-04-01 01:50:27 CDT --- When compiling the latest patch to 64 bits in amd64 according to http://wiki.winehq.org/Wine64 I get the following error when doing «make»:
opengl_glx.o: In function `rGL_glXCreateContextAttribsARB': /home/cuni/wok/parche/wine-1.3.16/dlls/opengl32/opengl_glx.c:60: undefined reference to `glXCreateContextAttribsARB' opengl_glx.o: In function `wine_glXCreateContextAttribsARB': /home/cuni/wok/parche/wine-1.3.16/dlls/opengl32/opengl_glx.c:77: undefined reference to `glXCreateContextAttribsARB' opengl_glx.o: In function `rGL_glXSwapIntervalSGI': /home/cuni/wok/parche/wine-1.3.16/dlls/opengl32/opengl_glx.c:321: undefined reference to `glXSwapIntervalSGI' opengl_glx.o: In function `wine_glXSwapIntervalSGI': /home/cuni/wok/parche/wine-1.3.16/dlls/opengl32/opengl_glx.c:338: undefined reference to `glXSwapIntervalSGI' collect2: ld returned 1 exit status winegcc: /usr/bin/gcc-4.5 failed make[1]: *** [opengl32.dll.so] Error 2 make: *** [dlls/opengl32] Error 2
Also why are there two patches now? maximization performance and the gzipped. I only used the gzipped.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #91 from ae aeforeve@mail.ru 2011-04-01 05:38:47 CDT --- reread patch
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #92 from Macie macie@linuxfusion.net 2011-04-01 15:44:10 CDT --- (In reply to comment #87)
http://www.aewi.info/rgl/rgl.patch.gz
new version
fix work ATI videocard (test Radeon HD5570)
http://www.aewi.info/rgl/rgl_max.patch maximization performance (~10%) decrease content switch from 45000-55000 to 10000-20000 in second
The rgl_max patch fixed the freezing that I was getting (mentioned above). Without it it's still there. I do occasionally get a black screen flash in WoW, when entering buildings mostly, but it's quick and not gameplay hindering. Starcraft 2 runs nicely as well.
Be aware that when compiling on Gentoo amd64 it fails QA check -------- * QA Notice: Package has poor programming practices which may compile * but will almost certainly crash on 64bit architectures. * * Function `wine_glGetString_' implicitly converted to pointer at /home/extra/tmp/portage/app-emulation/wine-1.3.16/work/wine-1.3.16/dlls/opengl32/wgl.c:654 --------
I have to bypass install_qa_check() to get wine installed successfully (if using portage for compilation and installation), but I haven't seen any crashes/instability yet.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #93 from gbillios@gmail.com 2011-04-02 03:02:31 CDT --- (In reply to comment #87)
http://www.aewi.info/rgl/rgl.patch.gz
new version
fix work ATI videocard (test Radeon HD5570)
http://www.aewi.info/rgl/rgl_max.patch maximization performance (~10%) decrease content switch from 45000-55000 to 10000-20000 in second
This patch works very well but in Starcraft (D3D) if I set the Shaders option to anything other than low, everything is blur. This doesn't happen with vanilla wine.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #94 from Fresno acafresna@ono.com 2011-04-06 04:04:09 CDT --- My test results using: AMD Athlon II x3 445 2,9 Ghz. Ati Radeon HD5670 1Gb. wine 1.3.16 running in opengl. Applied both patches, the gzipped and the performance prior to compiling in amd64.
Very good results: Fps outdoors from around 25 rise to 30. Indoors from 46 fps to 60 fps. The differences I guess comes from having the distance view set to high. No freezes nor blocks. Only the black screen flash once in a while, the same that Macie has commented, happens mostly when starting the game and getting into buildings or changing to new zones, but I'm not very sure about it. I'll test it some more.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #95 from Aigars Mahinovs aigarius@gmail.com 2011-04-07 06:00:07 CDT --- BTW, I have created a Ubuntu PPA to help test this patch - https://launchpad.net/~aigarius/+archive/aigarius-winepulse . That includes PulseAudio patch, GetLogicalProcessorInformation patch and both rgl patches.
Getting pretty good stability and performance with it (on an ATi video card). There is a split-second black screen when environments switch, but that is not too intrusive.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #96 from Aigars Mahinovs aigarius@gmail.com 2011-04-10 19:20:11 CDT --- Weird glitch - complete darkness when inside the Skybreaker (Alliance flying ship in Icecrown Citadel, Northrend). The UI is shown fine, but the world image is completely black as soon as I am inside the ship and moving along with it. The blackness does not happen on the top deck or if I am flying stationary inside the ship but not with it.
Also a question - does the patch allow multiple operations to be queued up? I am afraid that if it just returns from the function call before the operation is complete, we can not use the in0game fps counter to measure performance as you are returning execution back to the code faster than the acutual action completes. While in fact the actual graphical performance might be worse than normal. I have now seen instances when the fps counter showed 60+ fps while the actual redreaw was visually very, very slow.
I have a theory that the inter-thread communication and the accounting might eat up more resources that waiting for the video card to complete the operation. But I do not know how to verify that.
If the rGL only allowed one operation in the queue and when you tried a second operation it would block until the first one is completed, then we'd be able to trust the in-game fps meter and we'd be able to compare performance better, IMHO.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #97 from Chadwick Ferguson chadwick@clan-mac.com 2011-04-10 20:45:12 CDT --- rgl breaks eve online. eve is directx oriented. Not sure if I should even bother with debug. let me know +what channels to turn on winedebug. thanks
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #98 from ae aeforeve@mail.ru 2011-04-10 23:11:44 CDT --- Aigars Mahinovs
Don't use rgl_max.path It is a patch with "losses" - errors in a sound and screen flicker at movement in some locations and dungeon Personally it doesn't hinder me
Failure on Skybreaker really is :) and is caused rgl_max.patch-em
use only rgl.patch
Chadwick Ferguson
And about EVE - there it is precisely necessary such патчь? That is there there is no productivity of one kernel?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #99 from Chadwick Ferguson chadwick@clan-mac.com 2011-04-11 01:09:33 CDT --- ae-
I'm not sure if EVE online is doing SMP correctly in vanilla wine, however your rgl patch causes EVE online to crash, just a regression.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #100 from Aigars Mahinovs aigarius@gmail.com 2011-04-11 15:16:40 CDT --- Right, removing rgl_max.patch helped for the Skybreaker bug. I have put a new version on the PPA.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #101 from ae aeforeve@mail.ru 2011-04-15 08:22:47 CDT --- I try to apply патчь the to other programs Also has faced a problem
Practically all d3d programs very strongly use the processor and use a video card very little
If who that knows - whether can explain to me - such occurs from for that that in a code wine d3d-> opengl the converter counts on cpu very much?
Or it is feature of all d3d programs and on win?
That is a question in the following - it is how much strong envelopes in wine d3d-> opengl adds time?
If added time essential - whether that tells it about that as work of this converter needs to be transferred on a separate kernel of the processor?
russian: я пробую применить патчь свой для других программ и столкнулся с проблемой
практически все d3d программы очень сильно используют процессор и весьма мало используют видеокарту
если кто то знает - может ли пояснить мне - такое происходит из за того что в коде wine d3d -> opengl конвертер весьма много рассчитывает на cpu ?
или это особенность всех d3d программ и на win ?
то есть вопрос в следующем - насколько сильно конвертов в wine d3d->opengl добавляет времени ?
если добавленное время существенное - то говорит ли это о том что и саму работу этого конвертера нужно перенести на отдельное ядро процессора ?
http://bugs.winehq.org/show_bug.cgi?id=11674
Jordan K project.neotokyo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |project.neotokyo@gmail.com
--- Comment #102 from Jordan K project.neotokyo@gmail.com 2011-04-24 21:37:54 CDT --- Dear ae,
This patch worked flawlessly on Ubuntu, now here's my problem:
I was using 64-bit Arch Linux with my own kernel, stripped for my systems needs. The patch would let me get about 1-2 seconds of gameplay and then completely freeze. I could get play back for about 3 seconds if I used CTRL+ALT+F# combinations, and then pressed a key in another application where WoW wasn't focused, but then it would freeze up after trying to play again.
This same issue is now present in 64-bit Gentoo Linux, also with my own stripped kernel. I am about to try the patch on a monolithic kernel by using genkernel, but I have no idea what the effect will be.
Both wine versions were 1.3.17 (the same that worked on Ubuntu) the only difference between those versions is mine is vanilla wine + the rgl patch, not every other patch described in aigarius' version.
If anyone has any suggestions as to what this could be, please, do inform me. It's been driving me nuts for a week now. WoW works in vanilla wine, but it's just not the same without the RGL patch. I've seen the light, and I want it back!
Regards, J
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #103 from Dmitry dmitry923@gmail.com 2011-04-25 11:15:58 CDT --- (In reply to comment #102) I use x86_64 Arch and the patch works great. Maybe the cause of your problem is your custom kernel, try to use a vanilla kernel. You and other Archlinux users can also try to build the patched wine with my AUR script: http://aur.archlinux.org/packages.php?ID=48462 .
To ae: I have 2 feauture requests if you have time for them. 1) Could you please upload your patch with .md5 file for the security reasons? 2) You offered great support for dual-core CPUs. Maybe you could add support for 3,4 and more cores as well? We would get better performance than on Windows then.
Russian: к ae: У меня 2 просьбы, если есть на это время. 1) Мог бы ты выкладывать .md5 файл вместе с патчем? Все-таки правильнее было бы делать проверку на целостность перед патчем. 2) Твой патч здорово работает на двух ядрах. Может получится задействовать также 3х 4х и т.д. ядерные процессоры на полную мощность? Тогда бы у нас была производительность выше, чем под Windows.
http://bugs.winehq.org/show_bug.cgi?id=11674
Chris G chrismog@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chrismog@gmail.com
--- Comment #104 from Chris G chrismog@gmail.com 2011-05-05 04:14:01 CDT --- (In reply to comment #102)
Dear ae,
This patch worked flawlessly on Ubuntu, now here's my problem:
I was using 64-bit Arch Linux with my own kernel, stripped for my systems needs. The patch would let me get about 1-2 seconds of gameplay and then completely freeze. I could get play back for about 3 seconds if I used CTRL+ALT+F# combinations, and then pressed a key in another application where WoW wasn't focused, but then it would freeze up after trying to play again.
This same issue is now present in 64-bit Gentoo Linux, also with my own stripped kernel. I am about to try the patch on a monolithic kernel by using genkernel, but I have no idea what the effect will be.
Both wine versions were 1.3.17 (the same that worked on Ubuntu) the only difference between those versions is mine is vanilla wine + the rgl patch, not every other patch described in aigarius' version.
If anyone has any suggestions as to what this could be, please, do inform me. It's been driving me nuts for a week now. WoW works in vanilla wine, but it's just not the same without the RGL patch. I've seen the light, and I want it back!
Regards, J
I'm having the same issues with 64-bit Gentoo as well. I've tried all sorts of kernel config options with no luck. I don't get the freezes with the rgl_max patch, but I would love to figure out how to do without it.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #105 from Aigars Mahinovs aigarius@gmail.com 2011-05-06 07:02:56 CDT --- Quick note - I started getting a lockup of the graphics in Ubuntu 11.04 natty with this patch applied to wine 1.3.19. The sound continues to play, but the video freezes in to login screen. Anyone else get that as well?
http://bugs.winehq.org/show_bug.cgi?id=11674
Philipp Reuters philipp.reuters@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |philipp.reuters@gmail.com
--- Comment #106 from Philipp Reuters philipp.reuters@gmail.com 2011-05-06 09:58:17 CDT --- Can confirm that. Lockups in login-screen and ingame, about 5 times per minute while sound output continues regularly. Switching to a TTY an then back again (i.e. strg+alt+F1 and then strg+alt+F7) will bring the graphics back to live. But not for long. Already tried messing around with some settings, but couldn't find anything reliable. The game's output does not say anything.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #107 from ae aeforeve@mail.ru 2011-05-06 15:46:57 CDT --- Philipp Reuters Aigars Mahinovs Chris G
What processor at you? Type and mark
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #108 from Chris G chrismog@gmail.com 2011-05-06 16:42:05 CDT --- (In reply to comment #107)
Philipp Reuters Aigars Mahinovs Chris G
What processor at you? Type and mark
AMD Phenom II X4 945 (3.0 GHz) NVIDIA 9500GT (270.41.03 drivers) Kernel 2.6.38.5 amd64
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #109 from Philipp Reuters philipp.reuters@gmail.com 2011-05-06 17:09:48 CDT --- (In reply to comment #107)
Philipp Reuters Aigars Mahinovs Chris G
What processor at you? Type and mark
AMD Athlon X2 4000+
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #110 from Aigars Mahinovs aigarius@gmail.com 2011-05-06 17:55:23 CDT --- Intel Core i5 750 (4 cores, 2.66 Ghz), NVidia video card (same with ATi too). Note that I use the GetLogicalProcessorInformation function implementation from the Mayerhofer patch here and not from the rgl patch.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #111 from ae aeforeve@mail.ru 2011-05-06 19:31:01 CDT --- At me phenom II 945 + 580gtx - that didn't do but to achieve as from you effect it does not turn out in any way Even a hint on the such
Try the new version of a patch - probably given error was included into number of those which has corrected
The new version of a patch 1) some errors leading to falling are corrected 2) it is refined support d3d 3) modifed support CoD:Modern Warfare
Not corrected known problems 1) some "blinking" the image in d3d a mode
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #112 from ae aeforeve@mail.ru 2011-05-06 19:31:57 CDT --- http://www.aewi.info/rgl/rgl.patch.gz
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #113 from Devin Cofer ranguvar@archlinux.us 2011-05-06 20:18:48 CDT --- ae, I wish you would make more of an effort to document/explain/split apart your patches.
I've seen this situation before -- this work can never be merged into mainline due to its "giant blob" nature, and I worry it will fall into disrepair therefore.
Nevertheless, thanks.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #114 from Chris G chrismog@gmail.com 2011-05-06 20:55:37 CDT --- (In reply to comment #111)
At me phenom II 945 + 580gtx - that didn't do but to achieve as from you effect it does not turn out in any way Even a hint on the such
Try the new version of a patch - probably given error was included into number of those which has corrected
The new version of a patch
- some errors leading to falling are corrected
- it is refined support d3d
- modifed support CoD:Modern Warfare
Not corrected known problems
- some "blinking" the image in d3d a mode
Tried the new patch. The freezing issue is still there, but now I am unable to revive WoW by switching TTYs like I could before.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #115 from Dmitry dmitry923@gmail.com 2011-05-07 09:11:02 CDT --- (In reply to comment #114)
Tried the new patch. The freezing issue is still there, but now I am unable to revive WoW by switching TTYs like I could before.
Try patching earlier version of Wine. I use 1.3.16 and have no freezing issues. Though I faced them before, but they were solved for me in one of the further patches.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #116 from ae aeforeve@mail.ru 2011-05-07 10:23:28 CDT --- Devin Cofer
I strongly doubt that it needs to be included generally in the main wine Its operation where is closer to video to the driver - than to API
In Windows this code to be in the video card driver/libraries - and vendors(nvidia,ati or game developers) test and finish the code for each new program And for which those programs isn't present in the list - they use standard elements
In my judgement it so
Despite the size - my patch is extremely simple - and doesn't carry any especially artful algorithms and receptions
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #117 from ae aeforeve@mail.ru 2011-05-07 15:57:44 CDT --- Those at whom are watched friezes with my patch - what version xserver at you? Very similar on that that on the server 1.9.5 and above - this problem (but it is inexact while) is watched
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #118 from ae aeforeve@mail.ru 2011-05-08 15:07:47 CDT --- http://www.aewi.info/rgl/rgl.patch.gz new version
1) bugs fix 2) At whom friezes are observed - I ask to check up Use for assemblage wine - gcc 4.4 And at the test try to on and off hardware cursor
need test
As far as I understand problems arise on very new systems - type slackware - with the newest versions of programs
http://bugs.winehq.org/show_bug.cgi?id=11674
pandaroux@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pandaroux@gmail.com
--- Comment #119 from pandaroux@gmail.com 2011-05-09 16:53:12 CDT --- I have test in Ubuntu 11.04 with an old wine with rgl.patch, same effect. Freeze after a while.
But I have a message:
err:ntdll:RtlpWaitForCriticalSection section 0x7dc6e940 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0029, blocked by 0009, retrying (60 sec)
I think is a problem with X11 ?
Hope this help.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #120 from pandaroux@gmail.com 2011-05-10 00:58:04 CDT --- (In reply to comment #119)
I have test in Ubuntu 11.04 with an old wine with rgl.patch, same effect. Freeze after a while.
But I have a message:
err:ntdll:RtlpWaitForCriticalSection section 0x7dc6e940 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0029, blocked by 0009, retrying (60 sec)
I think is a problem with X11 ?
Hope this help.
New test, in Ubuntu 11.04 with new wine with rgl.patch, old kernel (2.6.36), same effect: freeze after a while with same message:
err:ntdll:RtlpWaitForCriticalSection section 0x7dc6e940 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0029, blocked by 0009, retrying (60 sec)
xorg version 7.6+4ubuntu3 nvidia 270.41.06
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #121 from pandaroux@gmail.com 2011-05-10 01:22:31 CDT --- (In reply to comment #120)
(In reply to comment #119)
I have test in Ubuntu 11.04 with an old wine with rgl.patch, same effect. Freeze after a while.
But I have a message:
err:ntdll:RtlpWaitForCriticalSection section 0x7dc6e940 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0029, blocked by 0009, retrying (60 sec)
I think is a problem with X11 ?
Hope this help.
New test, in Ubuntu 11.04 with new wine with rgl.patch, old kernel (2.6.36), same effect: freeze after a while with same message:
err:ntdll:RtlpWaitForCriticalSection section 0x7dc6e940 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0029, blocked by 0009, retrying (60 sec)
xorg version 7.6+4ubuntu3 nvidia 270.41.06
and Wine 1.3.19
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #122 from pandaroux@gmail.com 2011-05-11 12:24:56 CDT --- (In reply to comment #121)
(In reply to comment #120)
(In reply to comment #119)
I have test in Ubuntu 11.04 with an old wine with rgl.patch, same effect. Freeze after a while.
But I have a message:
err:ntdll:RtlpWaitForCriticalSection section 0x7dc6e940 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0029, blocked by 0009, retrying (60 sec)
I think is a problem with X11 ?
Hope this help.
New test, in Ubuntu 11.04 with new wine with rgl.patch, old kernel (2.6.36), same effect: freeze after a while with same message:
err:ntdll:RtlpWaitForCriticalSection section 0x7dc6e940 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0029, blocked by 0009, retrying (60 sec)
xorg version 7.6+4ubuntu3 nvidia 270.41.06
and Wine 1.3.19
and xserver 1.10.1
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #123 from pandaroux@gmail.com 2011-05-12 17:39:19 CDT --- No more freez with wine 1.3.16 and last patch on Ubuntu 11.04.
This is a wine bug with Ubuntu 11.04. Sorry
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #124 from Philipp Reuters philipp.reuters@gmail.com 2011-05-12 23:47:50 CDT --- (In reply to comment #123)
No more freez with wine 1.3.16 and last patch on Ubuntu 11.04.
This is a wine bug with Ubuntu 11.04. Sorry
no freezes with wine 1.3.19 clean install and Ubuntu 11.04, but it keeps freezing with the latest patch an wine 1.3.16 as well.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #125 from ae aeforeve@mail.ru 2011-05-14 17:58:46 CDT --- http://www.aewi.info/rgl/rgl.patch.gz new version
1) bugs fix 2) support gcc 4.6
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #126 from Dmitry dmitry923@gmail.com 2011-05-24 07:25:53 CDT --- (In reply to comment #125)
http://www.aewi.info/rgl/rgl.patch.gz new version
- bugs fix
- support gcc 4.6
With the patched wine 1.3.20 I faced a bug. When turning around the camera with the mouse, the camera jumps randomly about 90-180 degrees clockwise and counterclockwise thus making impossible to move straight. With the patched wine 1.3.16 and unpatched 1.3.20 everything is fine.
Russian: Столкнулся с глюком после того как пропатчил wine 1.3.20 - при повороте мышки камера скачет на произвольный угол где-то в пределах 90-180 градусов в разные стороны. Из-за этого бежать прямо вообще невозможно. В пропатченном wine 1.3.16 и в оригинальном 1.3.20 все в порядке.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #127 from Aigars Mahinovs aigarius@gmail.com 2011-05-24 07:31:40 CDT --- I am pretty sure that is "Option to clip the mouse inside fullscreen windows." feature of 1.3.20, have not checked yet by disabling that.
http://bugs.winehq.org/show_bug.cgi?id=11674
Geoff Rivell grivell@comcast.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |grivell@comcast.net
--- Comment #128 from Geoff Rivell grivell@comcast.net 2011-05-24 14:21:14 CDT --- (In reply to comment #126)
With the patched wine 1.3.20 I faced a bug. When turning around the camera with the mouse, the camera jumps randomly about 90-180 degrees clockwise and counterclockwise thus making impossible to move straight. With the patched wine 1.3.16 and unpatched 1.3.20 everything is fine.
http://bugs.winehq.org/show_bug.cgi?id=27156
It has nothing to do with this patch. If you want a working mouse in 1.3.20 you need to compile with --without-xinput2
http://bugs.winehq.org/show_bug.cgi?id=11674
Alan J Richardson ajrich@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ajrich@earthlink.net
--- Comment #129 from Alan J Richardson ajrich@earthlink.net 2011-06-06 19:22:30 CDT --- (In reply to comment #110)
Intel Core i5 750 (4 cores, 2.66 Ghz), NVidia video card (same with ATi too). Note that I use the GetLogicalProcessorInformation function implementation from the Mayerhofer patch here and not from the rgl patch.
Did you have any difficulty applying the Mayerhofer patch? I have a git branch on the 1.3.5 tag checked out, but when I try patch --dry-run -p0 <sysfs-logicalprocessor-impl.patch All 5 hunks in nt.c fail, and the first hunk processor.c fails with a "patch unexpectedly ends in middle of line."
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #130 from ae aeforeve@mail.ru 2011-06-11 03:31:01 CDT --- http://www.aewi.info/rgl/rgl.patch.gz new version
1) bug fix 2) normal support d3d in WoW
http://bugs.winehq.org/show_bug.cgi?id=11674
David david.gidwani@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david.gidwani@gmail.com
--- Comment #131 from David david.gidwani@gmail.com 2011-06-13 18:00:10 CDT --- Applied the rgl patch to 3 different wine versions, but WoW crashes at startup with a 'memory cannot be "read"' error. I'm on Archlinux 2.6.39-ck, using nvidia 270.41.19. Tried downgrading to earlier nvidia drivers, rebuilding and reinstalling the latest driver after installing wine again, but no dice. Any ideas?
Here's the crash dump: http://pastebin.com/Z9qHzgw3
http://bugs.winehq.org/show_bug.cgi?id=11674
spiralofhope@lavabit.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spiralofhope@lavabit.com
http://bugs.winehq.org/show_bug.cgi?id=11674
Nelson Marques nmarques@opensuse.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nmarques@opensuse.org
--- Comment #132 from Nelson Marques nmarques@opensuse.org 2011-06-21 12:19:14 CDT ---
Hi,
You have left a post on my blog about this and I've decided to build a test package for this, but there's a few issues with the code itself. To be honest I don't really have much time to work them out myself, so I'm leaving the log in attachments in case you wanna fix them.
In a quick way:
* Potential buffer overflow: wine arraysubscript pen.c:296, 427; * Fix prototypes on rgl.c; * 64bit Portability issues: - wine 64bit-portability-issue opengl_norm.c:1844, 1861, 10507, 10524, 12285, 12302 - wine 64bit-portability-issue rgl.c:679, 2008, 2010, 2012, 2014, 2084, 2087, 2090, 2093, 2096, 2099, 2102, 2105, 2199, 2202, 2205, 2208 * wine no-return-in-nonvoid-function rgl.c:1716
Prototypes are a easy fix, the portability issues are probably also a 10 min task and the potential loop overflow I'm not sure.
I haven't got much time to take a serious look at the code, but those warnings/errors have been identified by the openSUSE Build scripts, and for most of the cases they are pretty much accurate.
The full build log is available here: http://www.marques.so/wp-content/uploads/2011/06/rawlog.zip
Let me know if you fix those issues so I can try a build against the latest build.
Nelson
http://bugs.winehq.org/show_bug.cgi?id=11674
wineDevUser@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wineDevUser@gmail.com
--- Comment #133 from wineDevUser@gmail.com 2011-07-01 14:10:39 CDT --- Using the latest patch from aewi.info applied against git cloned on July 1, 2011, I frequently have Wow.exe get stuck on 'futex_wait_queue_me' thus hanging the program. This problem occurs primarily when I open in game menus (even from the login screen) or when I swap back and forth from the Wow.exe window to another window (ie: Console).
I have been unsuccessful in capturing a trace log up to the point of failure. Any attempt to set WINEDEBUG=+wgl changes the program timing to the point that I can no longer cause the error to occur.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #134 from Jordan K project.neotokyo@gmail.com 2011-07-17 23:14:34 CDT --- (In reply to comment #131)
Applied the rgl patch to 3 different wine versions, but WoW crashes at startup with a 'memory cannot be "read"' error. I'm on Archlinux 2.6.39-ck, using nvidia 270.41.19. Tried downgrading to earlier nvidia drivers, rebuilding and reinstalling the latest driver after installing wine again, but no dice. Any ideas?
Here's the crash dump: http://pastebin.com/Z9qHzgw3
I'm having the same problem he is. This is the output in my terminal of running wine "C:\Program Files\World of Warcraft\Wow.exe" -opengl
And here is the output of WINEDEBUG=+wgl wine "C:\Program Files\World of Warcraft\Wow.exe" -opengl http://www.mediafire.com/?849wkn58aa2z5qx
I had to put it on mediafire as it was too big for pastebin.
The system running is Wine 1.3.24, AMD Phenom II X3 @ 2.10 GHz, ATI Radeon HD5650.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #135 from Chris G chrismog@gmail.com 2011-10-15 23:28:10 CDT --- Not sure if anything is still happening with this, but with the latest NVIDIA binary drivers (285.05.09) I am unable to run WoW 4.2 on my Arch Linux x86-64 system. I get the error "Failed to find a suitable display device. Exiting program." The Wine bug shows "Direct3D9 is not available without OpenGL." Going back one revision of drivers fixes the problem, but this is not the best solution. Anyone else seeing this?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #136 from gbillios@gmail.com 2011-10-16 03:20:22 CDT --- I'm experiencing the same issue, at first I thought it was an error with the initial 285.x driver but now I realize it is something else, something changed.
@ae: is it possible to update the patch for the newer nvidia driver?
thanks
http://bugs.winehq.org/show_bug.cgi?id=11674
Ema ema.oriani@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ema.oriani@gmail.com
--- Comment #137 from Ema ema.oriani@gmail.com 2011-11-02 10:52:28 CDT --- Hi AE/all,
I guess the same issues are to be experienced when playing SC2 (Blizzard engine etc etc); we have a bug http://bugs.winehq.org/show_bug.cgi?id=28459 for this reason.
I fundamentally have a couple of questions:
1) What in AE's patch is the major boost performance? The implementation of GetLogicalProcessorInformation (which lets the game know about n cores) or the fact that we use a separate Direct3D->OpenGL renderer thread?
2) AE, if I'm correct, I've read your patch for approx 15 minutes and the rGL idea is that (via pipe/files) the wine_opengl functions will send their calls to a thread renderer. Is there anything else important happening behind the scenes, from an architectural point of view? Whilst conceptually simple, it's still 5 MB but unfortunately doesn't look like to be 'productionized' code :-(
3) What other games have their performance improved by the rGL patch?
I was in a discussion with someone from the main wine development team and even internally they were going/had developed a prototype thread renderer. As AE showed, even if from a theoretical point of view the detached Direct3D->OpenGL thread renderer is simple, it might be a mess to maintain if not properly implemented.
If the detached thread renderer is the way to go then we might build consensus and ask the main wine dev team to think about implementing it.
Let me know, Cheers
http://bugs.winehq.org/show_bug.cgi?id=11674
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fade@wanadoo.fr
--- Comment #138 from Jerome Leclanche adys.wh@gmail.com 2011-11-02 12:18:46 CDT --- *** Bug 28459 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11674
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Dual-core not being |Dual-core unsupported in |correctly supported in |WoW and SC2 |World of Warcraft (WOW) |
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #139 from gpiez@web.de 2011-11-02 12:38:53 CDT --- I can at least answer the first part of your question: An working implementation of GetLogicalProcessorInformation does not affect the performance at all (at least on my box), where the whole patch gives a huge performance boost.
I tried it on my box, which has some more cores (AEs implementation returns a fixed dual core) with an fleshed out patch and it did not improve performance. The reason might be that wow runs on several threads, of which only one does really do something.
I think the reason that doing the rendering in an separate thread yields a performance boost is that you are essentially offloading the opengl->d3d overhead to an otherwise unused core. I admit this is based on pure speculation ;-)
http://bugs.winehq.org/show_bug.cgi?id=11674
Aaron Slunt tonglebeak@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|tonglebeak@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #140 from Ema ema.oriani@gmail.com 2011-11-02 14:26:07 CDT --- What we experience in SC2 (which imho should be _very_ similar) is that there's one rendering thread, but we have a huge amount of wait time/active Sleep/SleepEx calls on a lot of threads and many context switches. I think Linux scheduler then gets in the way trying to load balancing the CPUs. I have 4 cores and paradoxically when I force the affinity of SC2.exe to _one_ core only the FPS gets boosted by +100% (from 25 FPS to 50+ FPS). My guess is that the huge context switching introduced by the fact we have to protect from calls from multiple threads (i.e. ENTER_GL/LEAVE_GL) is _heavy_ on Direct3D rendering. Having only one thread serializing calls will make the life easier and a lot less context switches. Now this patch, if understand correctly, implements synchronisation via pipes (or better lets the OS to deal with that), but there might be better ways of doing this.
Anyway if having this rendering thread proves to be very beneficial then we should ask wine core developers to perhaps take a look at that?
Cheers
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #141 from ae aeforeve@mail.ru 2011-11-03 02:29:29 CDT --- (In reply to comment #140)
Essence GetLogicalProcessorInformation consisted in that is nevertheless to persuade a cursor paralel work on a drawing On windows it nevertheless paraleling (including in opengl a mode) - and the reason why it it doesn't do it in wine - isn't clear
When I tested - and I tested and did basically for WoW - the game engine very essential time was in opengl dll - and this one thread on 2 - and has raised productivity
In SC2 I simply haven't seen those sites which are slow - that that I saw - there were approximately 80-90 % in game - 10-20 % in the schedule Such relation or is caused D3D-> opengl by the translator (that it that that does that long) - or d3d And in difference from WoW - here I also haven't received special acceleration
My patch - is extremely extremely simple Its size - result mechanical (through a script) transformations of functions from direct runing - runing through the buffer
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #142 from Ema ema.oriani@gmail.com 2011-11-04 15:24:48 CDT --- Thanks for the replies.
Do we have good benefit in other games too? What is the consensus? Should we ask core devs to implement such rendering thread?
Cheers
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #143 from Aigars Mahinovs aigarius@gmail.com 2011-11-04 16:23:30 CDT --- I would have grave suspicions about timing and synchronization errors as the draw functions return much sooner that programs expect them to and also return before anything is actually drawn. This could also lead to games falsely claiming higher FPS that is actually shown in cases where you can accept 100 frames per second worth of draw requests, but you can't actually manage to show all of them in that time, so the queue just grows until you start getting huge latency between an action happening in the game and actually showing up on the screen. The games measure FPS exactly for the purpose of preventing that - frames are dropped so that the time between an action happening in the game engine and showing it on screen is never delayed by a queue of frames to be rendered.
I'd rather see the multi-core identification issue fully solved. If WoW does not manage to figure out that there is more than one core, then they actually turn off all the multi-core optimizations that they already have in there.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #144 from Ema ema.oriani@gmail.com 2011-11-05 05:00:21 CDT --- (In reply to comment #143)
I would have grave suspicions about timing and synchronization errors as the draw functions return much sooner that programs expect them to and also return before anything is actually drawn...
I don't quite agree with this. I've used OpenGL for quite a while and all commands are always to be considered deferred, in the sense that the API, once you call any, will send the command to the driver and then, unless you call:
glFlush -> http://www.opengl.org/sdk/docs/man/xhtml/glFlush.xml glFinish -> http://www.opengl.org/sdk/docs/man/xhtml/glFinish.xml ARB Sync extension -> http://www.opengl.org/registry/specs/ARB/sync.txt
You _never_ know when a command will be or executed or completed by the host (the videocard). For this reasons all OpenGL developers, please correct if I'm wrong, have not to assume nothing when they execute their API calls.
If AE discovered that there's a lot of context switching and possibly delegating the work to one thread offloads the other threads, less locking, this should be the way to go.
And please consider that both Direct3D and OpenGL are fundamentally monothread APIs, so if we have one OpenGL thread executor (for each OpenGL context) things should definitely speed up because this would free a lot of resources. And this is what happens in WoW (and AFAIK in other games too).
Basically having a separate OpenGL renderer thread (per context) will catch two birds with a stone (as long as we implement the three above specifications correctly - i.e. waiting): 1) Less context switching (introduced by ENTER_GL/LEAVE_GL) 2) Offloading the caller thread from interacting with OpenGL driver (nVidia/AMD) thus making the application more responsive.
Cheers
Some more references: http://stackoverflow.com/questions/2143240/opengl-glflush-vs-glfinish
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #145 from Aigars Mahinovs aigarius@gmail.com 2011-11-05 05:27:45 CDT --- (In reply to comment #144)
(In reply to comment #143)
I would have grave suspicions about timing and synchronization errors as the draw functions return much sooner that programs expect them to and also return before anything is actually drawn...
I don't quite agree with this.
I see. After looking at that. I does look like you are right.
In such case the biggest problem is passing data from primary thread to a rendering thread in a way that they can be on different processors or cores and not spend too much time on the synchronisation between processors. If both CPU would need to get the same lock to read or write data to a common location, then they would spend so much time waiting for the lock and flushing their CPU caches that any processing off-loading benefit would be easily destroyed by that.
And at the same time all this fancy lockless IPC mechansm needs to not hold on to the data for too long, so that the flushes, finishes and page swaps are not too delayed.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #146 from ae aeforeve@mail.ru 2011-11-05 11:53:43 CDT --- Understand - the main task to understand - through what mechanism on Windows work in 2 streams is carried out
It is a basic question!!!
On Windows on Nvidia 2 thread (opengl and d3d), ATI 2 or 1 thread (1 in opengl, 2 in d3d)
Most that interesting - on Windows on 2 processor - if at start WoW the program which 100 % works loads one kernel - that WoW is started ALWAYS in 1 stream Also it is not switched in 2 - if loading to clean
Schedules http://www.aewi.info/wow/2threadWoW.jpg http://www.aewi.info/wow/1threadWoW.jpg
If we understand - through what mechanism WoW works in 2 streams - we can understand that what further to do
1) if it to be carried out through game - that needs to be found the reason - on which on wine she doesn't want to use 2 streams 2) if it do the driver - that a question why it so doesn't work on linux 3) (most probable) it occurs from for that that in drivers and in system there is no very big piece of a code which optimization under the concrete appendix is called That that is on Windows - and isn't present in линуксе If it so - that an exit - to develop rGL патчь - to do it more correctly working
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #147 from ae aeforeve@mail.ru 2011-11-05 12:19:13 CDT --- I in the beginning long tried to define - from for what doesn't work in 2 flows - but couldn't On logs in WoW me so have got - that it has made patch such what now and is
Ema this patch also works and on other applications - but in opengl many functions - and not all from them can be automatically transformed For many functions to have to do wrapper - that they could work correctly Here the list релизованных
From the list it is specified in dlls/opengl32/compsize.h
And and their implementation also is made in dlls/opengl32/rgl.c
Here an example of the biggest implementation of function http://pastebin.com/bqNypuug
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #148 from Ema ema.oriani@gmail.com 2011-11-05 20:43:15 CDT ---
(In reply to comment #147)
I in the beginning long tried to define - from for what doesn't work in 2 flows
- but couldn't
On logs in WoW me so have got - that it has made patch such what now and is
Ema this patch also works and on other applications - but in opengl many functions - and not all from them can be automatically transformed For many functions to have to do wrapper - that they could work correctly Here the list релизованных
From the list it is specified in dlls/opengl32/compsize.h And and their implementation also is made in dlls/opengl32/rgl.c
Here an example of the biggest implementation of function http://pastebin.com/bqNypuug
I see that you're allocating/freeing memory for buffers (as expected). And, if I'm correct, in this example there's a bit of complexity because you have to determine the layout/size based on stride/etc etc...
Is this operation (allocating/copying/freeing) so expensive? I guess this was well worth the implementation, right? What is the average performance gain in WoW and other games? Is it around +50% FPS, +20% or more +5%?
Cheers
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #149 from ae aeforeve@mail.ru 2011-11-06 01:38:41 CST --- Why this operation should be road? At all isn't present - it isn't great Without it all the same not to manage - after all between function invocation - and its execute in other flow - the data that it uses application quite can change
Whether to avoid it it is possible at multisequencing in the application (game) - native
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #150 from Fresno acafresna@ono.com 2011-11-06 04:30:06 CST --- Well if it improves performance I can't think of a good reason of not doing it. In my case, wow's performance was increased from 30 fps to 60 with the nice ae patch.
I'd like to suggest to please not use automatic translation to write here. I mean, avoid things like bablesfish or google translator because it's hard to understand. Human language is (fortunately) not computable.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #151 from Ema ema.oriani@gmail.com 2011-11-06 09:46:25 CST --- To escalate this to core developers, to ask them to make it at least and experimental feature, we should show that other applications/games benefit from the deferred rendering thread.
Any other example apart Blizzard games?
Cheers
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #152 from gpiez@web.de 2011-11-06 10:43:46 CST --- @ema: For me the performance gain was at least +50% fps, in other situations more like +100% fps in WoW. Unfortunately, the patch was never really stable for me, it crashed after a few minutes.
One thing I noted was the graphics card I had back then (a Nvidia GT 8800) did stay in power saving mode (half clock speed) most of the time. I first thought it was a bug in the driver, so I did override the power saving mode to make it stay at full clock speed all the time - which didn't give me a single fps more (standing in a crowded area in Stormwind).
After the patch I noticed the graphics card went to full clock speed by itself immediatly, and further it was actually getting hot. So at this time (about a year ago) the frame rate in WoW direct3d mode was clearly cpu bound, and ae's patch did help to alleviate this.
Another data point is that going from an Q9550 to an i7 2600k @4.7 GHz did increase the frame rate noticeably. I have no exact measurements, but it is clearly in the +50% range too.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #153 from Aigars Mahinovs aigarius@gmail.com 2011-11-10 07:49:01 CST --- I have now tried to compile wine 1.3.32 with the rgl patch, but only got a segmentation fault. Do you have an updated version of it by any chance? Could you please put it as an attachment to this bug replacing the old version?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #154 from Aigars Mahinovs aigarius@gmail.com 2011-11-11 15:59:29 CST --- Created attachment 37453 --> http://bugs.winehq.org/attachment.cgi?id=37453 rgl patch by ae, updated at 11-11-2011
Working on wine 1.3.32
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #155 from Aigars Mahinovs aigarius@gmail.com 2011-11-11 16:00:53 CST --- Ignore my last comment, I tried patched with the patch attached to the bug report and not the one from the later provided link. Works fine in wine 1.3.32. Attached the file here too so others don't get confused.
http://bugs.winehq.org/show_bug.cgi?id=11674
a.metaphysical.drama@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |a.metaphysical.drama@gmail. | |com
--- Comment #156 from a.metaphysical.drama@gmail.com 2011-11-12 03:57:32 CST --- I'm not able to run any OpenGL executable using this patch
From the little debugging i made i found that the OpenGL glXCreateContext
function hangs up (Does not even return NULL) and so execution results in a "err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems" Using wine without this patch works fine
I'm using Archlinux 3.1.0-4 with nvidia drivers 285.05.09
http://bugs.winehq.org/show_bug.cgi?id=11674
Chris_9 jukeller@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jukeller@gmx.de
--- Comment #157 from Chris_9 jukeller@gmx.de 2011-11-16 09:38:05 CST --- Same problem, i am not able to run any executable using this patch. Wine and/or wow.exe doesn't seem to find a suitable 3D device.
Using Ubuntu 11.10 mit nvidia drivers 285.05.09
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #158 from gbillios@gmail.com 2011-11-16 11:55:10 CST --- This happens with every NVidia driver after the 280 series and this patch. Maybe ae can provide an explanation/resolution.
http://bugs.winehq.org/show_bug.cgi?id=11674
Ahmed W. oneofone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oneofone@gmail.com
--- Comment #159 from Ahmed W. oneofone@gmail.com 2011-11-18 15:19:49 CST --- I can confirm that the GetLogicalProcessorInformation patch from #c44 gives me ~9fps boost in Skyrim.
AE's patch break wine's OpenGL subsystem completely, at least with nvidia 285.x .
I'm using wine-1.3.32-372-gc27a568.
http://bugs.winehq.org/show_bug.cgi?id=11674
Martín Perazzo rechapita@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rechapita@hotmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
Nicos900 nicolas.p.schwartz@wanadoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nicolas.p.schwartz@wanadoo. | |fr
--- Comment #160 from Nicos900 nicolas.p.schwartz@wanadoo.fr 2011-12-02 13:27:47 CST --- Same problem with openGL. I'm running mint 12 with an ati 6870 and catalys 11.11.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #161 from Nicos900 nicolas.p.schwartz@wanadoo.fr 2011-12-02 13:28:40 CST --- I'm using wine 1.3.33 with latest rgl patch.
http://bugs.winehq.org/show_bug.cgi?id=11674
Pavel Ondračka pavel.ondracka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pavel.ondracka@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #162 from ae aeforeve@mail.ru 2012-01-09 14:16:35 CST --- http://www.aewi.info/rgl/rgl.patch.gz
fix for new nvidia drivers (ati not tested)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #163 from Dmitry dmitry923@gmail.com 2012-01-10 09:02:02 CST --- (In reply to comment #162)
http://www.aewi.info/rgl/rgl.patch.gz
fix for new nvidia drivers (ati not tested)
When I try to patch wine 1.3.33, 1.3.35 or 1.3.36, I get the following: http://pastebin.com/u4qHWwfn
It seems that the patch is for a different version of wine. Could you please tell me which version of wine this patch is designed for.
Russian: Когда пробую пропатчить вайн версий 1.3.33, 1.3.35 или 1.3.36, то получаю следующее: http://pastebin.com/u4qHWwfn Похоже, что этот патч не для этих версий. Подскажи пожалуйста с какой версией вайна нужно его использовать.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #164 from ae aeforeve@mail.ru 2012-01-10 10:12:57 CST --- (In reply to comment #163)
(In reply to comment #162)
git version
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #165 from Dmitry dmitry923@gmail.com 2012-01-11 10:21:28 CST --- With ATI HD 5870 and Catalyst 11.12-1 WoW crashes at startup with ERROR #132 Fatal exception that the memory cannot be "read". The last lines of the terminal output are here: http://pastebin.com/PR9fk6gB WoWError shows the following: http://pastebin.com/rRxCQSMS Tried deleting ".wine" to no avail. I also tried to use some earlier versions of the patch and I faced the same problem. The latest working for me version of the patch was downloaded on 26th November. Unfortunately I don't have the patch itself. Only the wine binary.
Russian: С ATI HD 5870 и Catalyst 11.12-1 WoW валется сразу на старте с ERROR #132 Fatal exception that the memory cannot be "read". Вот последние линии вывода терминала: http://pastebin.com/PR9fk6gB WoWError показывает следующее: http://pastebin.com/rRxCQSMS пробовал удалять ".wine", но не помогло. Я также попробовал несколько предыдущих версий патча с тем же исходом, т.е. проблема появилась несколько раньше. Последнюю рабочую на моем железе версию патча я скачал 26 ноября. К сожалению у меня не осталось самого патча, только бинарник вайна.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #166 from ae aeforeve@mail.ru 2012-01-11 12:26:26 CST --- (In reply to comment #165)
With ATI HD 5870 and Catalyst 11.12-1 WoW crashes at startup with ERROR #132 Fatal exception that the memory cannot be "read". The last lines of the terminal output are here: http://pastebin.com/PR9fk6gB WoWError shows the following:
это больше похоже на ошибку в звуковой подсистеме
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #167 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2012-01-11 20:04:25 CST --- This is English bugzilla, please use English so everyone else can understand.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #168 from Dmitry dmitry923@gmail.com 2012-01-13 08:27:41 CST --- You were right about the troubles in the sound subsystem. Disabling sound in wine helped to launch the WoW. And that is not the problem of the patch. In vanilla git version of wine I faced the same problem. However I found a new small bug. When you strafe your character animation becomes jerky and I could not reproduce this bug in vanilla git version of wine. I will stick to a previous version of the patched wine so far.
Rissian: Да, проблема была со звуком. Когда отключил звук в wine, то WoW сразу запустился. И это не проблема патча. В текущем git все точно также. Однако заметил еще один небольшой баг, которого раньше не было. Если стрейфиться, то анимация персонажа начинает дергаться в конвульсиях. В текущем git такого нет. Поэтому пока посижу на предыдущей рабочей версии пропатченного wine.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #169 from ae aeforeve@mail.ru 2012-01-13 15:33:09 CST --- (In reply to comment #168)
However I found a new small bug. When you strafe your character animation becomes jerky and I could not reproduce this bug in vanilla git version of wine. I will stick to a previous version of the patched wine so far.
this not bugs :) reread patch
http://bugs.winehq.org/show_bug.cgi?id=11674
Sergey s@swa.org.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |s@swa.org.ru
--- Comment #170 from Sergey s@swa.org.ru 2012-01-14 09:51:10 CST --- Thanks for the awesome patch! I see a huge performance boost. The only problem so far - after a few hours of playing (WoW) the graphical artifacts starting to appear. It's no problem for me, restart of WoW fixes everything, but there must be some leak. Thanks again!
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #171 from ae aeforeve@mail.ru 2012-01-14 12:06:37 CST --- (In reply to comment #170)
Probably overheating from for the big operation of video of a subsystem and the processor At me such it is not watched Specify system parameters
russian: возможно просто перегрев изза более напряженного работы видео и cpu ? укажи что за видео и cpu - у меня такого ненаблюдаеться
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #172 from Sergey s@swa.org.ru 2012-01-14 12:35:55 CST --- GTS250 (In reply to comment #171)
(In reply to comment #170)
Probably overheating from for the big operation of video of a subsystem and the processor At me such it is not watched Specify system parameters
GTS 250 The system is FreeBSD, using proprietary nvidia drivers.
If it would overheating, it shouldn't getting fixed by WoW restart, right? The temperature is abit higher than usual, but nothing critical (was ~55, now it's around 60 C).
http://bugs.winehq.org/show_bug.cgi?id=11674
paolinidiego paolinidiego@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |paolinidiego@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #173 from paolinidiego paolinidiego@gmail.com 2012-02-07 12:12:19 CST --- ASUS 1366 SABERTOOTH X58 X58 DDR3 ATX INTEL Core i7 950 3.06Ghz 8MB 1366 Bloomfield 130W BOX DDR3 1600Mhz PC12800 12GB Corsair Vengeance 1.5V CL9 ATI HD6950 MSI 2GB Twin Frozr III Power Edition/OC Corsair Enthusiast Series CMPSU-850TXV2EU 850W
ubuntu oneiric 32bit wine 1.4-rc2
patched compiled, she does well, but the cpu is not yet get 100%
ubuntu oneiric 64bit not works. Bad job even on the client win7 64bit.
http://bugs.winehq.org/show_bug.cgi?id=11674
Erik wine@erikdokter.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@erikdokter.nl
http://bugs.winehq.org/show_bug.cgi?id=11674
Sam Fourman Jr. sfourman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sfourman@gmail.com
--- Comment #174 from Sam Fourman Jr. sfourman@gmail.com 2012-03-02 16:44:54 CST --- (In reply to comment #162)
http://www.aewi.info/rgl/rgl.patch.gz
fix for new nvidia drivers (ati not tested)
I tried your patch on FreeBSD 10x
it fails to compile and I think this is why, any way I can fix it?
gmake[1]: Entering directory `/usr/ports/emulators/wine/work/wine-1.4-rc5/dlls/qmgrprxy' ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -DWINE_REGISTER_DLL -u -o qmgrprxy_i.c qmgrprxy.idl rgl.c: In function 'rGLSync': rgl.c:119:6: warning: implicit declaration of function 'printf' [-Wimplicit-function-declaration] rgl.c:119:65: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default] rgl.c: At top level: rgl.c:181:6: warning: function declaration isn't a prototype [-Wstrict-prototypes] rgl.c: In function 'rGLDestroyThread': rgl.c:183:15: warning: unused variable 'rGLthread' [-Wunused-variable] rgl.c:182:9: warning: unused variable 'i' [-Wunused-variable] rgl.c: In function 'wine_glXCreateContext': rgl.c:208:13: warning: unused variable 'rGLthread' [-Wunused-variable] rgl.c: In function 'wine_glXMakeCurrent': rgl.c:279:1: warning: format '%x' expects argument of type 'unsigned int', but argument 8 has type 'struct thread_state *' [-Wformat] rgl.c: In function 'rGL_glXSwapBuffers': rgl.c:385:2: warning: incompatible implicit declaration of built-in function 'printf' [enabled by default] rgl.c:365:31: warning: variable 'rGLt3' set but not used [-Wunused-but-set-variable] rgl.c: In function 'wine_glGenBuffersARB': rgl.c:674:51: warning: assignment makes integer from pointer without a cast [enabled by default] rgl.c: In function 'rGL_glGenBuffers': rgl.c:693:3: warning: implicit declaration of function 'glGenBuffers' [-Wimplicit-function-declaration] rgl.c: In function 'wine_glGenBuffers': rgl.c:713:51: warning: assignment makes integer from pointer without a cast [enabled by default] ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -DWINE_REGISTER_DLL -p -o qmgrprxy_p.c qmgrprxy.idl rgl.c: In function 'rGL_glDeleteBuffersARB': rgl.c:736:33: warning: comparison between pointer and integer [enabled by default] rgl.c:736:5: warning: passing argument 1 of 'free' makes pointer from integer without a cast [enabled by default] /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/include-fixed/stdlib.h:107:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c: In function 'wine_glGenProgramsARB': rgl.c:1133:1: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'struct context_state *' [-Wformat] rgl.c: In function 'wine_glClientWaitSync': rgl.c:1412:8: error: 'GL_ALREADY_SIGNALED' undeclared (first use in this function) rgl.c:1412:8: note: each undeclared identifier is reported only once for each function it appears in rgl.c: In function 'rGL_glBindBuffer': rgl.c:1726:5: warning: implicit declaration of function 'glBindBufferARB' [-Wimplicit-function-declaration] rgl.c: In function 'wine_glBindBuffer': rgl.c:1761:5: warning: implicit declaration of function 'glBindBuffer' [-Wimplicit-function-declaration] rgl.c: In function 'rGL_glVertexAttribPointer': rgl.c:1810:49: warning: initialization from incompatible pointer type [enabled by default] rgl.c:1812:3: warning: implicit declaration of function 'glVertexAttribPointer' [-Wimplicit-function-declaration] rgl.c: In function 'wine_glVertexAttribPointer': rgl.c:1819:1: warning: format '%d' expects argument of type 'int', but argument 10 has type 'GLvoid *' [-Wformat] rgl.c:1828:40: warning: assignment makes integer from pointer without a cast [enabled by default] rgl.c: At top level: rgl.c:1966:229: warning: no semicolon at end of struct or union [enabled by default] rgl.c: In function 'rGL_glDrawElementsInstanced': rgl.c:1971:3: warning: implicit declaration of function 'glDrawElementsInstanced' [-Wimplicit-function-declaration] rgl.c: In function 'rGL_glEnableVertexAttribArray': rgl.c:2191:53: warning: initialization from incompatible pointer type [enabled by default] rgl.c:2192:3: warning: implicit declaration of function 'glEnableVertexAttribArray' [-Wimplicit-function-declaration] rgl.c: In function 'wine_glEnableVertexAttribArray': rgl.c:2201:10: warning: assignment from incompatible pointer type [enabled by default] rgl.c: In function 'wine_glMapBufferARB': rgl.c:2267:6: warning: return makes pointer from integer without a cast [enabled by default] rgl.c:2269:6: warning: return makes pointer from integer without a cast [enabled by default] rgl.c:2271:6: warning: return makes pointer from integer without a cast [enabled by default] rgl.c:2273:6: warning: return makes pointer from integer without a cast [enabled by default] rgl.c: In function 'rGL_glMapBuffer': rgl.c:2303:3: warning: implicit declaration of function 'glMapBuffer' [-Wimplicit-function-declaration] rgl.c:2303:22: warning: assignment makes pointer from integer without a cast [enabled by default] rgl.c: In function 'wine_glMapBuffer': rgl.c:2314:6: warning: return makes pointer from integer without a cast [enabled by default] rgl.c:2316:6: warning: return makes pointer from integer without a cast [enabled by default] rgl.c:2318:6: warning: return makes pointer from integer without a cast [enabled by default] rgl.c:2320:6: warning: return makes pointer from integer without a cast [enabled by default] rgl.c:2338:28: warning: assignment makes pointer from integer without a cast [enabled by default] rgl.c: In function 'wine_glBufferDataARB': rgl.c:2376:54: warning: comparison between pointer and integer [enabled by default] rgl.c:2376:6: warning: passing argument 1 of 'free' makes pointer from integer without a cast [enabled by default] /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/include-fixed/stdlib.h:107:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2378:51: warning: assignment makes integer from pointer without a cast [enabled by default] rgl.c:2379:6: warning: passing argument 1 of 'memcpy' makes pointer from integer without a cast [enabled by default] /usr/include/string.h:62:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2382:62: warning: comparison between pointer and integer [enabled by default] rgl.c:2382:6: warning: passing argument 1 of 'free' makes pointer from integer without a cast [enabled by default] /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/include-fixed/stdlib.h:107:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2384:59: warning: assignment makes integer from pointer without a cast [enabled by default] rgl.c:2385:6: warning: passing argument 1 of 'memcpy' makes pointer from integer without a cast [enabled by default] /usr/include/string.h:62:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2388:59: warning: comparison between pointer and integer [enabled by default] rgl.c:2388:6: warning: passing argument 1 of 'free' makes pointer from integer without a cast [enabled by default] /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/include-fixed/stdlib.h:107:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2390:56: warning: assignment makes integer from pointer without a cast [enabled by default] rgl.c:2391:6: warning: passing argument 1 of 'memcpy' makes pointer from integer without a cast [enabled by default] /usr/include/string.h:62:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2394:61: warning: comparison between pointer and integer [enabled by default] rgl.c:2394:6: warning: passing argument 1 of 'free' makes pointer from integer without a cast [enabled by default] /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/include-fixed/stdlib.h:107:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2396:58: warning: assignment makes integer from pointer without a cast [enabled by default] rgl.c:2397:6: warning: passing argument 1 of 'memcpy' makes pointer from integer without a cast [enabled by default] /usr/include/string.h:62:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c: In function 'rGL_glBufferData': rgl.c:2415:3: warning: implicit declaration of function 'glBufferData' [-Wimplicit-function-declaration] rgl.c: In function 'wine_glBufferData': rgl.c:2440:54: warning: comparison between pointer and integer [enabled by default] rgl.c:2440:6: warning: passing argument 1 of 'free' makes pointer from integer without a cast [enabled by default] /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/include-fixed/stdlib.h:107:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2442:51: warning: assignment makes integer from pointer without a cast [enabled by default] rgl.c:2443:6: warning: passing argument 1 of 'memcpy' makes pointer from integer without a cast [enabled by default] /usr/include/string.h:62:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2446:62: warning: comparison between pointer and integer [enabled by default] rgl.c:2446:6: warning: passing argument 1 of 'free' makes pointer from integer without a cast [enabled by default] /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/include-fixed/stdlib.h:107:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2448:59: warning: assignment makes integer from pointer without a cast [enabled by default] rgl.c:2449:6: warning: passing argument 1 of 'memcpy' makes pointer from integer without a cast [enabled by default] /usr/include/string.h:62:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2452:59: warning: comparison between pointer and integer [enabled by default] rgl.c:2452:6: warning: passing argument 1 of 'free' makes pointer from integer without a cast [enabled by default] /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/include-fixed/stdlib.h:107:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2454:56: warning: assignment makes integer from pointer without a cast [enabled by default] rgl.c:2455:6: warning: passing argument 1 of 'memcpy' makes pointer from integer without a cast [enabled by default] /usr/include/string.h:62:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2458:61: warning: comparison between pointer and integer [enabled by default] rgl.c:2458:6: warning: passing argument 1 of 'free' makes pointer from integer without a cast [enabled by default] /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/include-fixed/stdlib.h:107:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2460:58: warning: assignment makes integer from pointer without a cast [enabled by default] rgl.c:2461:6: warning: passing argument 1 of 'memcpy' makes pointer from integer without a cast [enabled by default] /usr/include/string.h:62:7: note: expected 'void *' but argument is of type 'GLuint' rgl.c:2421:10: warning: unused variable 'func_glBufferData' [-Wunused-variable] rgl.c: In function 'rGL_glBufferSubData': rgl.c:2518:3: warning: implicit declaration of function 'glBufferSubData' [-Wimplicit-function-declaration] rgl.c: In function 'wine_glUnmapBufferARB': rgl.c:2570:6: warning: passing argument 4 of 'wine_glBufferSubDataARB' makes pointer from integer without a cast [enabled by default] rgl.c:2486:13: note: expected 'GLvoid *' but argument is of type 'GLuint' rgl.c:2573:6: warning: passing argument 4 of 'wine_glBufferSubDataARB' makes pointer from integer without a cast [enabled by default] rgl.c:2486:13: note: expected 'GLvoid *' but argument is of type 'GLuint' rgl.c:2576:6: warning: passing argument 4 of 'wine_glBufferSubDataARB' makes pointer from integer without a cast [enabled by default] rgl.c:2486:13: note: expected 'GLvoid *' but argument is of type 'GLuint' rgl.c:2579:6: warning: passing argument 4 of 'wine_glBufferSubDataARB' makes pointer from integer without a cast [enabled by default] rgl.c:2486:13: note: expected 'GLvoid *' but argument is of type 'GLuint' rgl.c: In function 'rGL_glUnmapBuffer': rgl.c:2611:3: warning: implicit declaration of function 'glUnmapBuffer' [-Wimplicit-function-declaration] rgl.c: In function 'wine_glUnmapBuffer': rgl.c:2623:6: warning: passing argument 4 of 'wine_glBufferSubDataARB' makes pointer from integer without a cast [enabled by default] rgl.c:2486:13: note: expected 'GLvoid *' but argument is of type 'GLuint' rgl.c:2626:6: warning: passing argument 4 of 'wine_glBufferSubDataARB' makes pointer from integer without a cast [enabled by default] rgl.c:2486:13: note: expected 'GLvoid *' but argument is of type 'GLuint' rgl.c:2629:6: warning: passing argument 4 of 'wine_glBufferSubDataARB' makes pointer from integer without a cast [enabled by default] rgl.c:2486:13: note: expected 'GLvoid *' but argument is of type 'GLuint' rgl.c:2632:6: warning: passing argument 4 of 'wine_glBufferSubDataARB' makes pointer from integer without a cast [enabled by default] rgl.c:2486:13: note: expected 'GLvoid *' but argument is of type 'GLuint' ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -DWINE_REGISTER_DLL -h -o qmgrprxy.h qmgrprxy.idl rgl.c: In function 'wine_glDrawRangeElements': rgl.c:2846:1: warning: format '%d' expects argument of type 'int', but argument 10 has type 'GLvoid *' [-Wformat] ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -DWINE_REGISTER_DLL -r -o qmgrprxy_r.res qmgrprxy.idl ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -DWINE_REGISTER_DLL --dlldata-only -o dlldata.c qmgrprxy.idl gcc46 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DWINE_REGISTER_DLL -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o qmgrprxy_i.o qmgrprxy_i.c gmake[1]: *** [rgl.o] Error 1
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #175 from Dmitry Timoshkov dmitry@baikal.ru 2012-03-02 20:18:02 CST --- There is an "attach" functionality in this bugzilla, it's worth a try.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #176 from ae aeforeve@mail.ru 2012-03-31 07:43:12 CDT --- http://aewi.info/rgl/rgl.patch.gz
small update for WoW - Pandarea
http://bugs.winehq.org/show_bug.cgi?id=11674
Del delonly@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |delonly@gmail.com
--- Comment #177 from Del delonly@gmail.com 2012-06-02 06:21:24 CDT --- ae, your web-site is down. Please make the patch available, e.g., by uploading it as an attachment here.
http://bugs.winehq.org/show_bug.cgi?id=11674
Alexey Loukianov mooroon2@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mooroon2@mail.ru
--- Comment #178 from Alexey Loukianov mooroon2@mail.ru 2012-06-12 21:22:03 CDT --- I'm not sure if this bug is _de_facto_ obsolete or not, but the observed behavior of the Diablo III running under Wine exactly fits under definitions of this bug: under Wine I've got several D3 threads but only one of them uses CPU (around 90-95% of one core), rest are mostly idle. Under native OS with the same D3 installation I've got entirely different CPU usage situation: with "default" affinity D3 process utilizes 4 of 8 cores, each core is hogged for about 50%. When I change CPU affinity of D3 process myself limiting it to only use CPU 0 and 2 (i.e. I want the game to use two cores of my AMD FX CPU that do not share the same FP blocks) the game tasks both of these cores to around 80-85%.
I believe that this is one of the core reasons the game performing under Wine way worse than it performs on native producing low FPS that seems to be CPU limited (i.e. it remains almost the same when I switch from 1680x1050 down to 800x600 resolution while standing near waypoint at the middle of the Act I town).
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #179 from ae aeforeve@mail.ru 2012-06-13 02:02:37 CDT --- (In reply to comment #178)
I'm not sure if this bug is _de_facto_ obsolete or not, but the observed behavior of the Diablo III running under Wine exactly fits under definitions of this bug: under Wine
diablo3 - loads the video card very little all loading goes on the processor
besides - under Linux - communication of wine and wineserver-and - is the highest - under 200 thousand contex-switch
r b swpd free buff cache si so bi bo in cs us sy id wa 2 0 35556 527408 251852 4972084 0 0 11 6 1 1 3 1 97 0 2 0 35556 526920 251852 4972324 0 0 212 0 190426 232234 18 16 66 0 3 0 35556 526796 251864 4972324 0 0 0 160 183518 224966 19 16 65 0 2 0 35556 526672 251864 4972324 0 0 0 4 175773 216426 19 14 67 0 2 0 35556 524688 251864 4972352 0 0 92 0 186229 225506 18 15 66 0
russian: диабло крайне мало нагружает видеокарту - изза этого даже под виндой не особо виден тот поток который работает с ней (по нагрузке невиден) ну и под линуксом общение с видеокартой идет в тойже нити что и основной процесс - отличий с wow тут нет кроме того - wine и wineserver крайне сильно "общаються"
--- Comment #180 from Alexey Loukianov mooroon2@mail.ru 2012-06-13 03:05:59 CDT --- Short version of the comment: IMO this one should be CLOSED WONTFIX/NOTABUG.
Long version:
I have to second words posted (in previous comment and in comment #86) by ae and state the following:
a) Looks like observed behavior has nothing to do with Wine (at least I had confirmed it for SC2 and D3, can't test WoW as I haven't got it but I'm pretty sure the same states for it as well). Slight signs of SMP usage that might be observed under native OS are the results of the SMP optimization made by GPU drivers. In case I turn off SMP optimization for SC2 or D3 binaries under Windows 8 (this setting is accessible through nVIDIA control panel) game's CPU usage flatlines to be slightly less 50% for 2 CPU PC, 25% for 4 CPU PC or 12.5% for 8 CPU PC. Turning GPU driver SMP optimization back "on" greatly affects SC2 CPU usage (might be as big as 85-90% for 2 CPU case) and somewhat affects D3 - 75-80% CPU usage for 2 CPU PC.
b) D3 is extremely CPU bound. I've done the test by limiting my CPU into using 2 cores out of 8, disabling Turbo Core and fixing working frequency to as low as 1.4GHz using MB BIOS, and then tried playing the game under both Linux/Wine and native. FPS turned out to be low under both OS, but it remained about 1.5x-2x higher under native compared to what I get under Wine (~22 FPS native vs. ~12 FPS Wine). So it looks like the game uses much more CPU power under Wine, but that's another bug (might be related to the context switching thing ae had mentioned) that should be reported separately.
To summarize, IMHO this bug should be CLOSED NOTABUG as it is not a bug in Wine actually and de-facto this report had been used as a playground for an off-tree patch - and that's not what Bugzilla is meant to be used for. As far as I know ae maintains a separate webpage for his patch that could be found at http://www.aewi.info/rgl/, so people who want to use this patch should find it there and not in this bug report.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #181 from ae aeforeve@mail.ru 2012-06-13 05:29:46 CDT --- whether is insufficiency of a functionality - an error? look at the comment 86 http://bugs.winehq.org/show_bug.cgi?id=11674#c86
Actually - this bugs can be closed wine normally supports smp in WoW And the reason of slow operation is very simple - on Windows - in drivers of video cards - at Nvidia and Ati - there is such section - optimization for specific applications is called"
that you see that in load of the processor - actually is display of ineffective operation of "semaphores" (WaitForMultipleObjects) - from for which the capacity of one kernel on useless a content switches practically is for nothing spent as a result there is an erratic impression that games really normally use many threads
and effective operation 3d subsystems - it will be possible only when finishing a piece of a code - similar to my patch - wine-developers (that hardly) or nvidia/amd (that hardly during short-range time)
my patch became for WoW - and it showed - what method it is possible to correct this mistake - a method the extremely difficult and wasteful
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #182 from Alexey Loukianov mooroon2@mail.ru 2012-06-13 07:39:30 CDT --- ae, sorry, but your English seems to be so bad so I can hardly understand what you write (and, TBH, your Russian isn't too good either - lots of grammar and spelling errors, but at least there are no problems with understanding the meaning of the sentences), but if I got your point correctly, by "whether is insufficiency of a functionality - an error?" you mean that this bug might be treated as a "feature request" for Wine to support OpenGL (and, possibly, Direct3D) rendering offloading into separate thread.
I can hardly believe that such enhancement - if implemented - would ever be accepted into Wine by core devs (AJ, Henri, Stefan, name other yourself) as it wouldn't be targeted at implementing native-specific behavior but rather implementing a set of "clever hacks, specific to a set of the apps it is targeted at". I might be wrong on this point, but in any case this bug remains invalid IMO - games in question (WoW, SC) seems not to be multicore-optimized, and utilize only one core when executed on both under native and Wine unless there's some third party software that adds SMT optimization to these apps (GPU drivers for native case, cleverly hacked winelib opengl.dll by your rgl patch for Wine).
So Wine seems to be is fine with regards to its SMT support vs. apps in question, thus this bug is invalid. Finding a way to improve Wine/wineserver so WaitFor* usage won't cause excessive context switches is a good and valid thing to think about, but it is unrelated to this bug and should be discussed elsewhere (new bug rep, wine-devel mailing list, some other place).
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #183 from ae aeforeve@mail.ru 2012-06-13 08:28:03 CDT --- english: floood
russian: 1) на входе имеем - оно тормазит - на винде не тормазит - это ошибка? 2) сделал патчь - который это исправляет - правдо почти только для WoW 3) ну и чего с этим делать дальше ? панятия не имею - по английски я только translate.ru :)
суть патча в том - что он требует ручной настройки практически на каждую новую программу - что наверняка и делаеться в фирменных драйверах на винде для Диаблы я патчик доделал - но изза того что крайне слабо юзает видеокарту - плюса почти нет а в SC2 оно нормально работала год-два назад - но в каком то патче в SC2 много поменяли - и пришлось переделывать - при которой натолкнулся на проблему которую не знаю как решить - да и не играю особо в SC2 WoW Pandaria - оттестирована - нормально работает
а ошибка эта должна быть закрыта когда оно будет работать также как и на винде - и нераньше - чтоб была видна причина этого
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #184 from Alexey Loukianov mooroon2@mail.ru 2012-06-13 08:57:09 CDT --- Excerpt from the latest ae comment: "а ошибка эта должна быть закрыта когда оно будет работать также как и на винде - и нераньше - чтоб была видна причина этого"
Rough translation: "this bug shouldn't be closed until the moment it would work the same way it works under native"
Answer: Actually its a decision to be made by core Wine devs, including original reporter. I just had posted my humble opinion based on the experience I had about the way such bugs are usually treated in Wine's Bugzilla. IMO for this case we don't have a well defined "it works this way on native" situation - it might work differently depending on some third party software, GPU drivers namely, and for generic "GPU driver without app-specific hacks" under native it works the same way as it works under Wine. I tend to treat is as a NOTABUG situation, but in any case I think we should stop this unrelated flood about your patch and just wait for core devs to do the final resolution.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #185 from ae aeforeve@mail.ru 2012-06-13 09:22:58 CDT --- еще причина в том - в неопределенности в неопределенности того КТО должен обеспечивать туже функциональность что и на винде
in Windows App -> windows -> drivers -> videocart
in linux App -> wine -> Linux -> drivers -> videocart
на линуксе - wine подменяет windows - но должна ли она подменять/включать функциональность драйверов ? если на винде - драйверы "видят" что за приложение их юзает то на линуксе драйверы видят что с ними работает только wine
я уверен что должно - и поэтому это бугз
http://bugs.winehq.org/show_bug.cgi?id=11674
Markus Golser elmargol@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|elmargol@googlemail.com |
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #186 from paolinidiego paolinidiego@gmail.com 2012-06-13 10:54:09 CDT --- Alexey Loukianov seems to me the same story, a poor man, becomes three to solve a problem that has solved very well, but the community that the project follows this guy is not funny, and I do not even listen, do not give weight to his work. So it would be better than those who follow the Wine project to make available some resources to assist those in pe and finish the job started and improve it.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #187 from Del delonly@gmail.com 2012-06-13 12:10:28 CDT --- Created attachment 40530 --> http://bugs.winehq.org/attachment.cgi?id=40530 rgl patch by ae, updated 31st March 2012
Please avoid personal attacks. I for one deeply appreciate Alexey's work. Alexey may very well be right, but in any case I uploaded the latest patch to keep this bug report self contained. Being a potential patch to Wine with performance increase in multiple games, I do believe the modest disk usage is justified.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #188 from Alexey Loukianov mooroon2@mail.ru 2012-06-13 19:34:30 CDT --- paolinidiego, I'm not sure it I've got your message right (no surprise, English ins't a native language for most of us here), but if you're about "do not blindly close, improve the patch and include it upstream" - I'm totally agree that having something that makes APPs behave better under Wine is a good thing, but if you would look around bugzilla or wine-patches mailing list you would be surprised about amount of patches that are refused for reasons that might seem obscure at a first glance. In-proc wineserver, PA, pipes - there are a lot of them hanging around, producing a lot of flame in related discussions and having almost no chances to be included in upstream tree with currently used patch accept policies.
From what I've seen over the years I follow Wine project, for rgl patch to be
included it should (a) be a generic solution that works with every app, (b) closely mirrors GL lib behaviour as observed from native code side (i.e. it should behave the same way this API behaves on native, and produce the same measurable results), (c) do not cause extra maintenance burden (having tweak patch each time to maintain per-app compatibility is not a way to go) - core Wine devteam manpower is a limited thing, and (d) patch should be splitted into series of small ones well structured changes that would look convincingly good for AJ and core devs of that part of the Wine that are affected.
I would be happy to be wrong on this, but as far as I can see this patch can't be redone in a way that would comply with above points (and patch author confirms it by telling "суть патча в том - что он требует ручной настройки практически на каждую новую программу" - translation is "main point of the patch is that it requires manual tweaking [to work] for almost every new application") and that means that at best it would be left as it is - as an out of tree patch helping some apps to work better. Looking at the other bugzilla reports then end up being used as a chat + OOT patch hosting, general tendency for them to being mostly ignored and/or closed as WONTFIX or NOTABUG. Nothing more, nothing less. It's not my personal rant against this patch, it's just the general tendency I had spotted over the years I've been using this bugzilla.
Well, it looks like enough flood for me, and so far I had written way more than I wanted to write here initially, thus I simply shut up and hope for the best.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #189 from Fresno acafresna@ono.com 2012-06-14 13:44:02 CDT --- I am trying last patch with wine 1.5.6, which it patches perfectly but when trying to run wow I get the error 132: ERROR #132 (0x85100084) Fatal exception!
Program: C:\Program Files\World of Warcraft\Wow.exe ProcessID: 86 Exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:7E587EB7
The instruction at "0x7E587EB7" referenced memory at "0x000004D0". The memory could not be "read".
I've been reading the comments and I understand that this can be solved by disabling sound in wine. But I don't want to play wow without sound. I tried the patch with the latest git but it gives errors with the patch and won't compile. What is now the right version of wine that can be patched and played with sound? Or am I doing something wrong? TIA
http://bugs.winehq.org/show_bug.cgi?id=11674
randomei mail@randomei.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@randomei.com
--- Comment #190 from randomei mail@randomei.com 2012-06-17 04:29:15 CDT --- Thanks ae very march for your work. Can this patch be modified that way, that it will work only for, say, two apps: WoW and Diablo III? This will take much less maintenance... And may be after that it will be good enough to convince core devs to include it into the main stream?
Огромное спасибо ae за проделанную работу. А можно ли модифицировать патч таким образом, чтобы он влиял только на wow и, скажем, дьяблу 3? Таким образом не потребуется его вручную настраивать под море других приложений. Может в таком виде его примут разработчики wine?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #191 from Austin English austinenglish@gmail.com 2012-06-18 19:11:15 CDT --- (In reply to comment #190)
Thanks ae very march for your work. Can this patch be modified that way, that it will work only for, say, two apps: WoW and Diablo III? This will take much less maintenance... And may be after that it will be good enough to convince core devs to include it into the main stream?
Hacks for specific applications are not acceptable in wine.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #192 from Fresno acafresna@ono.com 2012-07-04 12:40:11 CDT --- (In reply to comment #189)
Well I give up this patch now. I keep getting error 132 everytime I start wow. I tried disabling sound in wine, pulseaudio, different versions of wine (1.5.6, 1.5.0, 1.4.1, 1.3.32, the latest from git), upgrading from ubuntu amd64 10.10, 11.04 and 11.10, upgrading the ati driver and it makes no difference. It used to work but not anymore and there seems to be no help around. :(
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #193 from ae aeforeve@mail.ru 2012-08-12 18:56:44 CDT --- http://aewi.info/rgl/rgl.so http://aewi.info/rgl/rgl.tgz
Instruction: wget http://aewi.info/rgl/rgl.so cp rgl.so /usr/lib/ LD_PRELOAD=rgl.so wine Wow.exe -opengl
wine recompile not need pliz test
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #194 from paolinidiego paolinidiego@gmail.com 2012-08-13 05:34:42 CDT --- not works
wine 1.5.10 ubuntu i386 ati6950 i7
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #195 from ae aeforeve@mail.ru 2012-08-28 14:34:29 CDT --- http://aewi.info/rgl/rgl.so http://aewi.info/rgl/rgl64.so 64bit http://aewi.info/rgl/rgl_intel.so for intel video http://aewi.info/rgl/rgl.tgz source
fix bugs and improve
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #196 from paolinidiego paolinidiego@gmail.com 2012-08-28 14:42:07 CDT --- hello ... but with i7 installing the amd64 I see a performance increase?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #197 from paolinidiego paolinidiego@gmail.com 2012-08-31 16:00:56 CDT --- roboso@roboso-System-Product-Name:~$ LD_PRELOAD=rgl64.so wine Wow.exe -opengl ERROR: ld.so: object 'rgl64.so' from LD_PRELOAD cannot be preloaded: ignored.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #198 from paolinidiego paolinidiego@gmail.com 2012-08-31 16:04:50 CDT --- roboso@roboso-System-Product-Name:~$ LD_PRELOAD=rgl64.so wine Wow.exe -opengl ERROR: ld.so: object 'rgl64.so' from LD_PRELOAD cannot be preloaded: ignored.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #199 from gpiez@web.de 2012-08-31 17:05:57 CDT --- If you want to use the 64 bit version, you need to run 64 bit wow with 64 bit wine.
wine64 wow-64.exe
If you don't have a wine64 you need to install it.
http://bugs.winehq.org/show_bug.cgi?id=11674
a.metaphysical.drama@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|a.metaphysical.drama@gmail. | |com |
http://bugs.winehq.org/show_bug.cgi?id=11674
sworddragon2@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sworddragon2@aol.com
http://bugs.winehq.org/show_bug.cgi?id=11674
Tom fastumzug@fastmail.fm changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fastumzug@fastmail.fm
--- Comment #200 from Tom fastumzug@fastmail.fm 2012-09-07 17:00:10 CDT --- It seems that Guild Wars 2 is also affected by this bug. Is there any planned fix for this issue?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #201 from Tom fastumzug@fastmail.fm 2012-09-07 18:04:12 CDT --- (In reply to comment #195)
http://aewi.info/rgl/rgl.so fix bugs and improve
When I run Guild Wars 2 with your patch :
make cp rgl.so /usr/lib export LD_PRELOAD=/usr/lib/rgl.so wine "path/to/Guildwars.exe" --dx9single --opengl
I get the following error:
"Direct3D9 is not available without OpenGL."
without LD_PRELOAD everything works well. Any idea? Btw. do you want to publish your source at www.github.com ? It's free and easy and others can help you. Also with translation.
I read http://bit.ly/Ogx3x6 but I couldn't find a solution.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #202 from sworddragon2@aol.com 2012-09-07 22:58:38 CDT --- As I know in Guild Wars 2 command line arguments must have only one - (-dx9single instead of --dx9single) and there is no -opengl argument.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #203 from Fresno acafresna@ono.com 2012-09-08 02:17:24 CDT --- (In reply to comment #195)
fix bugs and improve
I am also getting the «Direct3D9 is not available without OpenGL.» in wow.
Tried the m32 library with wine32 (1.5.5) and then the m64 with wine64 (1.5.12) in oneiric 64 bits. In both cases the same result.
My commands: LD_PRELOAD=/home/gg/rgl/rgl.so wine "C:\Program Files\World of Warcraft\Wow.exe" -opengl (and now compiling with m64 and new ~/.wine tree) LD_PRELOAD=/home/gg/rgl/rgl.so ./wine64 "C:\Program Files\World of Warcraft\Wow-64.exe" -opengl
In Config.WTF there is the line SET gxApi "OpenGL"
Works ok without the LD_PRELOAD.
http://bugs.winehq.org/show_bug.cgi?id=11674
Fanatos pastisbuenris@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pastisbuenris@hotmail.com
--- Comment #204 from Fanatos pastisbuenris@hotmail.com 2012-09-08 03:25:25 CDT --- same error here
@: LD_PRELOAD=/usr/lib/rgl64.so wine64 Wow-64.exe -opengl .............. fixme:process:GetLogicalProcessorInformation (0x8ddb40,0x8de350): stub fixme:process:GetLogicalProcessorInformation (0x8ddb40,0x8de350): stub fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know