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 what to do! fixme:process:GetLogicalProcessorInformation (0x8ddb40,0x8de350): stub fixme:process:GetLogicalProcessorInformation (0x8ddb40,0x8de350): stub fixme:process:GetLogicalProcessorInformation (0x22e820,0x22f030): stub fixme:process:GetLogicalProcessorInformation (0x22e820,0x22f030): stub fixme:win:EnumDisplayDevicesW ((null),0,0x22e790,0x00000000), stub! err:wgl:has_opengl Failed to load libGL: rgl.so: clase ELF errónea: ELFCLASS32 err:wgl:has_opengl OpenGL support is disabled. Direct3D9 is not available without OpenGL.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #205 from ae aeforeve@mail.ru 2012-09-08 06:43:40 CDT --- (In reply to comment #203)
(In reply to comment #195)
fix bugs and improve
need cp cp rgl.so /usr/lib/ or cp rgl.so /usr/lib32/
for 64bit cp rgl64.so /usr/lib/rgl.so
or contact to me (email)
http://bugs.winehq.org/show_bug.cgi?id=11674
Punkado punkado@riseup.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |punkado@riseup.net
--- Comment #206 from Punkado punkado@riseup.net 2012-09-09 19:12:49 CDT --- Nothing here also...
LD_PRELOAD=/usr/lib32/rgl.so wine Gw2.exe --dx9single
ERROR: ld.so: object '/usr/lib32/rgl.so' from LD_PRELOAD cannot be preloaded: ignored.
http://bugs.winehq.org/show_bug.cgi?id=11674
voidcastr cephryx@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cephryx@gmx.net
--- Comment #207 from voidcastr cephryx@gmx.net 2012-09-10 03:05:41 CDT --- (In reply to comment #206)
Nothing here also...
LD_PRELOAD=/usr/lib32/rgl.so wine Gw2.exe --dx9single
ERROR: ld.so: object '/usr/lib32/rgl.so' from LD_PRELOAD cannot be preloaded: ignored.
Same here, on Ubuntu 12.04 x64.
1. ae, on my platform, there are /usr/lib/ and /usr/lib32/. On you website, there are rgl.so and rgl64.so. Which one do I need to copy to what directory? The obvious solution does not work... Do I need multiple .so files at once?
2. From your last post, I understand that there are situations in which rgl64.so must be RENAMED when copying it... is that correct?
3. Do I need rgl64.so... - even for 32bit windows applications because I'm on Ubuntu x64 OR - only for 64bit windows allpications?
My apologies if these are dumb questions.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #208 from Punkado punkado@riseup.net 2012-09-10 06:28:44 CDT --- Ae told me this patch is only for WoW, so for guild wars 2, we still dont have a Solution...
http://bugs.winehq.org/show_bug.cgi?id=11674
Paul Kramer gitterrost4+winehq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gitterrost4+winehq@gmail.co | |m
http://bugs.winehq.org/show_bug.cgi?id=11674
James Eder jimportal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jimportal@gmail.com
--- Comment #209 from James Eder jimportal@gmail.com 2012-09-10 10:58:04 CDT --- In git there is now an implementation for GetLogicalProcessorInformation on Linux and Mac. Also there has been some work on GL locking in previous Wine releases.
http://bugs.winehq.org/show_bug.cgi?id=11674
chemacg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chemacg@gmail.com
--- Comment #210 from chemacg@gmail.com 2012-09-12 16:19:31 CDT --- I see 4 cores working in gkrellm and htop when running GW2 (though they only run at 50% and i think it's a GW2 problem not wine)
The strangest thing is that this happens with -dx9single enabled, shouldn't this disable multi-core?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #211 from ae aeforeve@mail.ru 2012-09-12 22:57:43 CDT --- multitreads under wine have one main problem - realization of WaitMultipleObject is realized through wineserver on windows it is realized in a kernel and while it do not realize more correctly - through a kernel or ~ in wine - that actively working multithread appendices and will miraculously brake
wow it does not concern - as it has only one actively working thread - other auxiliary
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #212 from voidcastr cephryx@gmx.net 2012-09-13 04:22:46 CDT --- (In reply to comment #210)
The strangest thing is that this happens with -dx9single enabled, shouldn't this disable multi-core?
Actually, we cannot assume that using "-dx9single" is supposed to disable ALL multithreading in GW2 - apparently, this is not the case. The GW2 wiki describes the flag as
"Enables the Direct3D 9c renderer in single-threaded mode. Solves issues with running in Wine, but may be slower." (http://wiki.guildwars2.com/wiki/Command_line_arguments).
But I bet the game engine uses several threads (resulting in load on several cores, in the best case) for more aspects than just rendering. Most likely, the flag does not disable those.
----------
(In reply to comment #211)
Well, from what you say, it seems possible to find a "clean" solution that is not just a hack... but it also seems like that involves a lot of work and deep changes to wine. Do you think a general fix for this can be created?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #213 from Tom fastumzug@fastmail.fm 2012-09-13 17:02:24 CDT --- (In reply to comment #211)
multitreads under wine have one main problem - realization of WaitMultipleObject is realized through wineserver ...
I'm not sure that I understand what you mean, but if this is a major problem of Wine this should be discussed further. As I see the actual situation there may never be a appropriate solution to the multi-thread problem without fixing this issue. I hope, I'm wrong, but maybe someone can explain more. Otherwise if this is game related, I'm going to ask ArenaNet for help. But I fear it's more Wine related than the game, because within Windows I have almost 5 times higher FPS than with Wine.
http://bugs.winehq.org/show_bug.cgi?id=11674
sxe sxxe@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sxxe@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #214 from paolinidiego paolinidiego@gmail.com 2012-09-14 15:17:20 CDT --- I repeat that to make sure that games like wow work perfectly on Linux, it is very important ... for the future of linux ... but those of wine do not see the urgency and do not really understand why .... I myself am quite tempted to go back to windows just to play wow ... and I know many people who do not go to linux just because wow does not have the same performance, wisto that their use is limited to PC wow, this is sad but it is the hard truth .. Linux does not use desktop will emerge as long as there is a greater development in the gaming and non-gaming run back the fuck are crap and frankly does not make sense that they work ... one plays with it every now and then just to spend an afternoon then back to playing his game that is mega wow guildwors2 pes or other titles released now ... not 50 years ago. For me, those of wine are going in the wrong direction ....
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #215 from Jerome Leclanche adys.wh@gmail.com 2012-09-14 15:18:14 CDT --- (In reply to comment #214) WoW works fine on Linux. Keep this crap off Bugzilla please, this bug is off-topic enough as it is.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #216 from paolinidiego paolinidiego@gmail.com 2012-09-14 15:23:05 CDT --- (In reply to comment #215)
(In reply to comment #214) WoW works fine on Linux. Keep this crap off Bugzilla please, this bug is off-topic enough as it is.
then you do not understand anything about gaming .... wow works to 70% in opengl ... you do not know what it means to play a game in pine graphic detail and enjoy the game to the core ... this is essential for gamers sometimes much more of the story.
and then I'll tell you what the raid of 25 and can not get them because they are unplayable.
Jerome Leclanché you are ignorant you are not gamers and do not understand the difference between the game starts the game is playable. You're just full of your convictions and do not listen to what people tell you and you are pointing out.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #217 from Jerome Leclanche adys.wh@gmail.com 2012-09-14 15:26:03 CDT --- (In reply to comment #216) I've been playing wow just fine on wine for years and rarely ever had issues; these days on very high graphics settings and no performance issues in crowded areas.
Regardless this is *not* a discussion for bugzilla. This place is exclusively for bugs. If you want to start a troll thread on the state of wine and gaming on linux, please do so on the forums where at least it won't be off-topic.
http://bugs.winehq.org/show_bug.cgi?id=11674
Claudiu Curca claudiu@coderollers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|claudiu@coderollers.com |
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #218 from paolinidiego paolinidiego@gmail.com 2012-09-14 15:33:57 CDT --- (In reply to comment #217)
(In reply to comment #216) I've been playing wow just fine on wine for years and rarely ever had issues; these days on very high graphics settings and no performance issues in crowded areas.
Regardless this is *not* a discussion for bugzilla. This place is exclusively for bugs. If you want to start a troll thread on the state of wine and gaming on linux, please do so on the forums where at least it won't be off-topic.
then try again to play and make a 25man raid
for me with ati 6950 with 2gb ram oc is unplayable, with the latest version of this patch has become a bit 'more playable in dagon soul for the first 4 bosses then the fps drop to 5 .... and repeat to wow us play more than 24 000 players with at least 30% would use linux only if it worked .... and I repeat now there Gallium3D well you could take advantage of that road but I do not see that it is doing something with them.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #219 from Tom fastumzug@fastmail.fm 2012-09-14 18:14:39 CDT --- (In reply to comment #216)
(In reply to comment #215)
(In reply to comment #214) WoW works fine on Linux. Keep this crap off Bugzilla please, this bug is off-topic enough as it is.
then you do not understand anything about gaming .... wow works to 70% in opengl ... you do not know what it means to play a game in pine graphic detail and enjoy the game to the core ... this is essential for gamers sometimes much more of the story.
I understand what you mean you are also a friend of Linux and you want to see it succeed like everyone else does. Don't you think that all the hard work which Wine developers spend on this project since years is enough to show their commitment? I think, it can't be any stronger than trying to change things by actually doing something.
Wine is an enormous project and without it Linux wouldn't be as far as we see it now. I mean, hey lets be honest without wine we would have any Windows games on Linux. Possibly we wouldn't have any serious independent games looking at Linux as a potential market.
And I'm very very sure without the success of Wine Valve had never ever looked at Linux. So, please I know you are also eager to see faster results, but Wine is a huge project and many developers are working on it in their spare time. They are no wizards. You can help them by motivating them and give help. So please, try your best with finding bugs and try to help to find the reasons for it.
You possibly like Linux as we do. So, please help instead of expressing your anger. Thanks.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #220 from Aigars Mahinovs aigarius@gmail.com 2012-09-15 04:08:57 CDT --- 1. Calm down, everyone.
2. It is true that WoW works just fine for most of the people in most situations, BUT the most demanding aspects of this game are 25 man end game raids. And in that situation the difference between regular Wine and Wine with the rgl patch is very significant, and for many people that is a difference between being able to contribute to the raid or not.
As a benchmark - pick a high population server at a popular game time, go to the Stormwind Trade District bank and expand you field of view as much as you can towards the Auction House. Typically I see around 20 players just sitting outside with around 30 more inside the AH. If at this point you FPS any lower than 25, then you will not be able to do any competitive raiding, because in raid situations you FPS will be dropping below 5 FPS and you will be missing the enviromental effect cues that you must see and react to in order to survive.
This rgl patch doubles my framerate in both of these situations (when it does not crash).
While I fully agree with Wine developers that rgl in its current state is a horrible and ugly hack that has no place in Wine, at the same time we do need something with the similar effect to be able to full use current generation graphics cards in modern games.
ae, could it be possible to write a 'generator' that would pick up all possible GL functions and generate the code to 'remote' all of them, instead of just a subset?
Also you might want to check out game TF2 (free game on Steam) it has an option called 'multicore rendering', see if that stresses your code good enough for easier testing by non-WoW non-raiding developers.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #221 from Tom fastumzug@fastmail.fm 2012-09-15 05:10:52 CDT ---
- It is true that WoW works just fine for most of the people in most
situations, BUT the most demanding aspects of this game are 25 man end game raids. And in that situation the difference between regular Wine and Wine with the rgl patch is very significant, and for many people that is a difference between being able to contribute to the raid or not.
That's quite similar to the situation in Guild Wars 2. I have a NV540m not the best at the market but it runs with 40 FPS in Win7 and only 9 FPS in Wine. I can also switch graphic settings without any effect on its performance.
This rgl patch doubles my framerate in both of these situations (when it does not crash).
I would like to test it. I may do something wrong because GW2 seams not to find DX9 when I activate the patch. ae already said his patch isn't for GW2. I hope, we can get it running for GW2, too.
While I fully agree with Wine developers that rgl in its current state is a horrible and ugly hack that has no place in Wine, at the same time we do need something with the similar effect to be able to full use current generation graphics cards in modern games.
It is a hack which is worth to build on IMHO. If it just helps in the first place then let it be a bit 'ugly'. But we can use it as a basis to build up on. If it just don't work, there will be less testers left, because the play with Windows.
ae, could it be possible to write a 'generator' that would pick up all possible GL functions and generate the code to 'remote' all of them, instead of just a subset?
Write him a mail, too. And if he needs Guild Wars 2 for testing his patch, too. I'm pretty sure we'll get the people together to buy him one :)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #222 from ae aeforeve@mail.ru 2012-09-15 08:02:45 CDT --- my small table testing /console SetTaxiBenchmarkMode(1); fly in Nezershtorm - from up aly point to rigth point - and back min/max/middle min/max/middle (fly) (back fly) see last digit - middle fps
intel dual core 7500 3.5ггрц windows gtx470 d3d 18/143/83 22/87/56.4 opengl 17/219/95 22/139/73
Athlong x2 3.5ггрц linux gtx470 opengl 9/101/45 12/57/31
Athlong x2 3.5ггрц windows gtx470 d3d+rgl 38/220/123 23/116/79 opengl+rgl 24/224/108 28/130/71
Intel PentiumD 3.7ггрц linux opengl 8/70/37 9/42/26
PhenomX6 3.3ghz gtx580 rgl.so 1280x1024 opengl+rgl 51/177/127 58/116/91
Linux Intel Core 2 Quad CPU Q9550 @ 3.41GHz ATI Radeon HD 5870 1024MB (850/1200MHz) opengl+rgl32 46/184/98 42/121/69 opengl+rgl64 48/172/96 43/110/67
opengl 32 25/90/56 25/53/40 opengl 64 26/89/54 24/53/38
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #223 from voidcastr cephryx@gmx.net 2012-09-16 14:22:37 CDT --- ae, could you create an updated patch that can be applied to the current git?
This might be a first step towards a "clean" implementation, just like Tom said. Even if it's just a hack only covering a subset of the relevant functions... it could possibly be improved, expanded and generalized.
For some users, a patch might also work better than employing the LD_PRELOAD path to inject rgl functionality.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #224 from ae aeforeve@mail.ru 2012-09-16 20:13:26 CDT --- the patch nevertheless works for couple of percent in wine than.so quicker but it ,so is simpler for accompanying and applying in work
and I doubt that it as that will receive in wine - my purpose was in that to show in what an essence of such lack of work of WoW well and also - to make to itself gameability
quite possibly that I am mistaken in preconditions - about that a little that it is drivers do "optimization" - but I did not find neither confirmations nor denials
+ to that I heard that Blizzard made for MacOSX smp opengl also the probability that when that - that is great that will be realized for it is realized and for opengl mode version windows
+ attempts of realization for other games did not give it to чему то to the good - in the majority cases the prize was small - or the videocard or other problems connected with smp in wine was slightly given by a full-time job influenced a situation much more
WoW in this regard simple any unique person - in which prize is stable and highest
russian: патчь все же (на пару процентов) быстрее работает в wine чем .so но зато .so куда проще сопровождать и применять в работе
и я сомневаюсь что его как то примут в wine - моя цель была в том чтобы показать в чем суть такого недостатка работы WoW ну и также - сделать себе играбельность
вполне вероятно что я несколько ошибаюсь в предпосылках - о том что это сами драйверы делают "оптимизация" - но я так и не нашел ни подтверждения ни опровержения
+ к тому я слышал что Blizzard сделал для MacOSX smp opengl и велика вероятность что когда то - то что реализована для него будет реализовано и для windows версии opengl mode
+ попытки реализации его для других игр не привели к чемуто хорошему - в большинстве случаях выигрыш был мал - или несильно загружалась работой видеокарта или другие проблемы связанные с smp в wine куда больше влияли на ситуацию
WoW в этом отношении просто какой то уникум - в котором выигрыш стабилен и крайне высок
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #225 from sxe sxxe@gmx.de 2012-09-18 12:28:34 CDT --- Hi there, at first, sry if this is the wrong place to ask but i think only here are all the involved people.
Would it be a viable option to start a kickstarter campaign to fund this feature? I think its just a fundamental part of wine that has to be implemented (As far as i can tell from what i read here). If the limiting factor is a full time developer maybe a kickstarter campaign could help to "motivate" someone. Maybe a developer reads this and things it is a good idea and starts a campaign by himself. I would like to pay for it.
Thx
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #226 from ae aeforeve@mail.ru 2012-09-19 12:39:56 CDT --- precisely - who is guilty - it is possible to tell only by fact definition - who use smp at WoW work on windows wow - drivers or windows
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #227 from sworddragon2@aol.com 2012-09-19 13:21:33 CDT ---
multitreads under wine have one main problem - realization of WaitMultipleObject is realized through wineserver on windows it is realized in a kernel and while it do not realize more correctly - through a kernel or ~ in wine - that actively working multithread appendices and will miraculously brake
Can you explain what WaitMultipleObject(s) is doing exactly and why it has a performance impact because the wineserver realizes it? How could Wine solve this performance problem?
Currently Windows applications can create threads under Linux and now with Wine 1.5.13 they can even get the correct processor informations. Shouldn't this ticket be renamed to a more generic one that points to this problem (like "Multithreading not fully supported")?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #228 from ae aeforeve@mail.ru 2012-09-19 13:26:17 CDT --- reread comment 226 (problem WaitMultipleObject almost wow do not concern) name valid
http://bugs.winehq.org/show_bug.cgi?id=11674
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #229 from Bruno Jesus 00cpxxx@gmail.com 2012-09-19 13:32:08 CDT --- Dear WoW players, could you please help to test bug 31684? Can anyone reproduce the issues there? (post answers there, not here =)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #230 from sworddragon2@aol.com 2012-09-19 13:34:23 CDT --- ae, I don't understand you (especially comment 226). Maybe I have some translation issues with your post. Are you meaning with "wow" World of Warcraft?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #231 from Tom fastumzug@fastmail.fm 2012-09-19 15:18:32 CDT --- (In reply to comment #226)
precisely - who is guilty - it is possible to tell only by fact definition - who use smp at WoW work on windows wow - drivers or windows
Hi ae, sorry I have translation problems. Could you please post your answers in Russian language? So maybe soemone else can translate your comments. I think it's imporant what you have to say.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #232 from Tom fastumzug@fastmail.fm 2012-09-19 15:36:38 CDT --- (In reply to comment #227)
Shouldn't this ticket be renamed to a more generic one that points to this problem (like "Multithreading not fully supported")?
I think, It's a good idea, because if I understand ae right. then it seems to be a general much deeper laying Wine problem. More and more Games will be effected by this bug, because new games often use multicore CPUs. It's an important feature we should solve somehow.
http://bugs.winehq.org/show_bug.cgi?id=11674
Henrik Olsson henrik@fixme.se changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |henrik@fixme.se
http://bugs.winehq.org/show_bug.cgi?id=11674
Samuel Nelson valczir.darkvein@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |valczir.darkvein@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
George Gibbs vash63@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vash63@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr
http://bugs.winehq.org/show_bug.cgi?id=11674
André Fettouhi A.Fettouhi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |A.Fettouhi@gmail.com
--- Comment #233 from André Fettouhi A.Fettouhi@gmail.com 2012-10-05 09:45:14 CDT --- Has anyone tested this patch by ae against Guild Wars 2? If so does it work?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #234 from voidcastr voidcastr@gmail.com 2012-10-05 09:51:11 CDT --- (In reply to comment #233)
Has anyone tested this patch by ae against Guild Wars 2? If so does it work?
yes / no :(
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #235 from Punkado punkado@riseup.net 2012-10-05 10:00:43 CDT --- With patch? All the patch here is for the wow... Im looking for a solution for gw2 also...
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #236 from voidcastr voidcastr@gmail.com 2012-10-05 10:11:41 CDT --- AFAIK, the patch was meant to apply against wine 1.3 and it cannot be applied to any 1.5 series version. So we can only employ the LD_PRELOAD method based around injecting code from the standalone/precompiled .so files. Unfortunately this is not only an extremely ugly solution but it also seems to fail for many users (including WoW players, apparently).
It seems like the only things happening when trying to use the .so files with GW2 are: - An error console output of "Direct3D9 is not available without OpenGL." - It either breaks the launcher completely OR has no effect at all.
However, given that I somewhat understood ae, he thinks about his "rgl" hack as being unlikely to be useful for other games. Whatever the reason.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #237 from ae aeforeve@mail.ru 2012-10-05 14:46:13 CDT --- (In reply to comment #236)
AFAIK, the patch was meant to apply against wine 1.3 and it cannot be applied to any 1.5 series version. So we can only employ the LD_PRELOAD method based around injecting code from the standalone/precompiled .so files. Unfortunately this is not only an extremely ugly solution but it also seems to fail for many users (including WoW players, apparently).
ld_preload the best method in the current situation
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #238 from ae aeforeve@mail.ru 2012-10-16 11:15:38 CDT --- http://www.phoronix.com/scan.php?page=news_item&px=MTIwNzQ
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #239 from voidcastr voidcastr@gmail.com 2012-10-16 11:29:31 CDT --- (In reply to comment #238)
Yeah, already saw that... didn't install it yet, though. Do you think this fixes the issue or at least helps in some regard?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #240 from ae aeforeve@mail.ru 2012-10-16 11:58:45 CDT --- (In reply to comment #239)
Yeah, already saw that... didn't install it yet, though. Do you think this fixes the issue or at least helps in some regard?
after a while completions - completely will correct this problem for a nvidia
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #241 from James Eder jimportal@gmail.com 2012-10-16 12:22:46 CDT ---
From the limited testing I've done it seems to be application dependent. With
the new beta driver, Prey under Wine sees about 20 FPS improvement (GL Doom3 engine). WoW becomes unplayable at 9FPS (For D3D haven't tried GL mode).
Fortunately you can toggle it off (default) and on with an environment variable.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #242 from Aigars Mahinovs aigarius@gmail.com 2012-10-16 14:30:22 CDT --- I've done some testing now with NVidia driver 310.14 and WoW in OpenGL mode. I get slightly more of a framerate boost from setting __GL_THREADED_OPTIMIZATIONS environment variable to "1" than from the rgl patch. Also, no crashes in a couple hours. I'd say that should be the right solution.
The effects are only really visible in heavily graphical environments, such as in a capital city with a lot of players in the line of sight (such as looking a the AH in Stormwind). Basically I get 19 fps with plain wine, 26 fps with rgl and 31 fps with the threaded optimisations (averaged, but numbers are very stable).
From previous tests, this is also very representative of the performance in a
raid boss combat environment, but have not tested the threaded optimisations in a raid, yet.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #243 from André Fettouhi A.Fettouhi@gmail.com 2012-10-16 15:10:57 CDT --- Has anyone tested this new driver with Guild Wars 2?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #244 from Samuel Nelson valczir.darkvein@gmail.com 2012-10-16 20:09:22 CDT --- (In reply to comment #243)
Has anyone tested this new driver with Guild Wars 2?
It seems to help some. I'm not sure of the significance - I'm seeing 5, maybe 10 FPS, on average. It's still an improvement, though, so I'll be playing with it.
The commands I used to run the game:
export WINEDEBUG=-all; LD_PRELOAD="libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 ~/.wine_versions/wine-git-awesomium-rawfix/bin/wine ./Gw2.exe -dx9single
During my short test, I never dropped below 20 FPS (other than the obligatory slowdown during loading).
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #245 from Samuel Nelson valczir.darkvein@gmail.com 2012-10-16 20:12:06 CDT --- D'oh! Make that "5, maybe 10 FPS max," not average. I hate not being able to edit my posts.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #246 from Aigars Mahinovs aigarius@gmail.com 2012-10-17 00:59:15 CDT --- Just to clarify, the LD_PRELOAD part does induce crashes with WoW for me, including a 100% crash in the Launcher.exe. So I run without it, and without any wine debug.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #247 from Samuel Nelson valczir.darkvein@gmail.com 2012-10-17 01:02:59 CDT --- (In reply to comment #246)
Just to clarify, the LD_PRELOAD part does induce crashes with WoW for me, including a 100% crash in the Launcher.exe. So I run without it, and without any wine debug.
The ldpreload part is to force GW2 to use pthreads - I was getting no difference with just the __GL_THREADED_OPTIMISATIONS part, so I read through the documentation included and found something saying that programs that don't use pthreads can be forced to, using the LD_PRELOAD line that I used.
It looks like this is (thus far) going to be a very case-by-case type of thing.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #248 from sworddragon2@aol.com 2012-10-17 01:13:14 CDT --- Wouldn't OpenGL threading just be a workaround instead of a real solution?
- You need to go sure to have a graphics card which supports OpenGL 4.3. - The driver must support it too. - You can't use any DirectX modes (for example in Blizzard games).
All these conditions are not needed on a windows system or have I overseen something?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #249 from sxe sxxe@gmx.de 2012-10-17 05:48:56 CDT --- (In reply to comment #247)
(In reply to comment #246)
Just to clarify, the LD_PRELOAD part does induce crashes with WoW for me, including a 100% crash in the Launcher.exe. So I run without it, and without any wine debug.
The ldpreload part is to force GW2 to use pthreads - I was getting no difference with just the __GL_THREADED_OPTIMISATIONS part, so I read through the documentation included and found something saying that programs that don't use pthreads can be forced to, using the LD_PRELOAD line that I used.
It looks like this is (thus far) going to be a very case-by-case type of thing.
I don't see any difference with __GL_THREADED_OPTIMIZATIONS=1 and adding LD_PRELOAD="libpthread.so.0 libGL.so.1" makes the game horrible laggy. All with the latest nvidia beta drivers (Gforece GTX 275 and i7 quadcore CPU @ 3.6GHz). My framerate is between 15 and 25 most of the time.
Just to make sure. You are not using ae's altered files, right?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #250 from Samuel Nelson valczir.darkvein@gmail.com 2012-10-17 08:13:42 CDT --- Nope, I'm not using ae's altered files.
I will admit, my tests are not scientific. There's every chance that I'm wrong, but I haven't had enough time yet to do a thorough test. Most of the time, I use the Shatterer as my benchmark, and that requires a pretty long period of time to test with. So honestly, I can't even be sure that the threaded optimisations setting is being applied - I may just be fooling myself into thinking that it performs better.
However, my experience in lightly populated (but still populated) areas is: without the LD_PRELOAD and __GL_THREADED_OPTIMISATIONS options, I'm sitting at 25-30 FPS during normal exploration, 20-25 during small fights, and there are many drops to 16 FPS during fights in which there are at least a few other people. With those options, I've got the same 25-30 FPS during normal exploration, but small fights don't have any effect on performance, and the lowest I see it drop to for even a small amount of time around a few other people is 20 FPS.
My specs, for comparison:
CPU: AMD Phenom II x4 965 (currently running at 3.6 GHz) RAM: 16GB DDR 1600 GPU: eVGA GTX 460 (it's the 2Win, but I'm not making use of SLI) OS: Funtoo amd64 Wine Version: roughly 1.5.13 - I did a git clone from around the first release of 1.5.13, and I seem to get slightly more stable performance on that version. Plus, the fix for the launcher transparency worked great when it was first added to git, but a more recent commit (possibly unrelated) makes my xorg-server go nuts and use 100% CPU, causing everything on that display to respond very slowly to user input (I'm planning to make a bug report if/when I can confirm that it's not just my settings acting up somewhere).
If I get a chance, I'll run with the zerg tonight. There are usually at least a couple of fights during the zerg that cause my performance to drop to 10 FPS (assuming a very high number of people are in the zerg). And I'll start the game in a blank X session - both to reduce any differences there might be between runs and to help make sure that those options are being applied.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #251 from gpiez@web.de 2012-10-17 09:27:53 CDT --- I did some testing with the new NVidia driver 310.14 and WoW in Directx mode, because I don't like to use opengl with all the effects missing.
Looking over half of Perlin, I get about 50 fps in Directx9 mode without any further optimizations. While this seems sufficient, in 25 man the framerate tend to drop further, even 20-30 fps, so more fps is always nice to have.
Unfortunately with __GL_THREADED_OPTIMISATIONS=1 the framerate drops to 10 fps. I tried all possible permutations of wow-64 and LD_PRELOAD even the 32 bit libs, to no avail.
I was using 4 AA, 16 Anisotrop, medium water and shadows, no sunrays, no ambient occlusion, everything else on maximum. My system is a i7-2600@5GHz and a GTX460.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #252 from Jerome Leclanche adys.wh@gmail.com 2012-10-17 09:42:57 CDT --- (In reply to comment #251) Can you try with WINEDEBUG=-all?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #253 from gpiez@web.de 2012-10-17 10:51:45 CDT --- (In reply to comment #252)
(In reply to comment #251) Can you try with WINEDEBUG=-all?
WINEDEBUG=-all increases the fps back to a value comparable to __GL_THREADED_OPTIMISATIONS=1, maybe slightly better :-) This needs further testing with some reliable benchmark, e. g. the internal /timetest command.
Another point I noticed: The CPU load increased from the usual 100% so about 150%. Unfortunately the framerate does only increase slightly, if at all.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #254 from gpiez@web.de 2012-10-17 10:52:35 CDT --- Should be __GL_THREADED_OPTIMISATIONS=0 in the text above.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #255 from Samuel Nelson valczir.darkvein@gmail.com 2012-10-18 23:06:39 CDT --- I did a slightly more scientific test today with __GL_THREADED_OPTIMISATIONS (running with the zerg) and aimed for watching for the lowest my FPS got. Luckily, the zerg was actually quite large today - large enough to drop me to the lowest FPS I ever really hit.
Note: This is with all console output disabled. I did notice a massive amount of extra output when running with WINEDEBUG=fixme-all the very first time I ran the game with these flags, and I don't think I even bothered to get past character select because I know how much of an impact console output can make.
With those flags: I saw it drop to 8 once or twice, usually stayed at 10+ (during the massive action sequences, I averaged about 12). Without: I saw it drop to 4 once or twice, usually stayed at 8+ (during the massive action sequences, I averaged about 10).
Conclusion: +5 is actually optimistic - it looks like we should expect +2 on average. This test still isn't comprehensive, but at least suggests that Guild Wars 2 gains something from it.
I also noticed the numbers fluctuating a bit less with the flags enabled. As mentioned, I saw numbers as low as 4 for short periods *without* threaded optimisations enabled, even though it was normally sitting around 9 or 10; *with* them enabled, I never saw a number lower than 8. Stuttering (rare split-second pauses) also seemed less frequent with threaded optimisations, but I wasn't timing it - so I could easily be fooling myself.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #256 from gpiez@web.de 2012-10-19 02:44:48 CDT --- I did some more reliable tests, using the /timetest slash command and flying from Seven Stars to Serpent Spine. This way all moving player/non player characters are not rendered during flight, making the result more repeatable.
The game itself reports the min/max and average framerate after landing, no third party tools needed.
For the first test I did the same run with the very same settings a few times. The error of the measurement of the average framerate seems well below 1% (maybe 0.5%), for the min/max fps the error is more, maybe 5%. So the min/max values should be not compared between different tests.
min/max avg # __GL_THREADED_OPTIMISATIONS=0 wine wow -d3d9 10.0/52.0 39.3 # __GL_THREADED_OPTIMISATIONS=0 wine wow-64 -d3d9 9.3/49.8 39.1
# __GL_THREADED_OPTIMISATIONS=1 wine wow -d3d9 10.0/59.4 42.3 # __GL_THREADED_OPTIMISATIONS=1 wine wow-64 -d3d9 10.7/56.1 41.7
This looks like 8% gain in 64 bit mode and some 6% in 32 bit mode, where both modes are exactly the same speed with threaded optimizations turned off.
I noticed the CPU usage seems to always be around 160%, no matter what, and the total system load about 5% (which is 40% of a single core for a eight core system).
The settings where the way I preferred them (not some not so realistic everything off or all ultra).
Resolution: 1920x1200 AA: 4x vsync: off
Textures: high Anisotrop: 16x (anything less makes my eyes bleed) proj. tex.: on
Shadows: good Water: medium Sunshafts: off (forced by AA 4x) Particles: good (doesn't have much impact, but more and I get blind during raids) SSAO: off (forced by AA 4x)
Viewing Range: Ultra (not sure about translation) Details: Ultra Objects: Ultra
i7-2600@5Ghz, in this test running at about 4.8 GHz because only 2 cores were idle, and GTX 460@750 Mhz running on nvidia-drivers-310.14
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #257 from Jerome Leclanche adys.wh@gmail.com 2012-10-19 02:48:13 CDT --- (In reply to comment #256) Could you try both of those tests with WINEDEBUG=-all? It seems to have more of an impact.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #258 from gpiez@web.de 2012-10-19 03:35:39 CDT --- All those test were run with an "export WINEDEBUG=-all" before. If I do not disable it __GL_THREADED_OPTIMISATIONS=1 becomes a magnitude slower, the framerate is constantly below 10 fps. So yes, this has quite an impact :-)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #259 from paolinidiego paolinidiego@gmail.com 2012-10-23 12:25:25 CDT --- I tried playing with the tread vov ottimization in raid 1 of 10 snaps in the 25 fps drop below 10
say that with my nvidia GTS250's even better rgl.so.
I tried to LD_PRELOAD = "libpthread.so.0 libGL.so.1 rgl.so" __ GL_THREADED_OPTIMIZATIONS = 1
but wow does not work, if you succeed in combining the two solutions I think you could optimize the yield exponential levels with nvidia and opengl.
http://bugs.winehq.org/show_bug.cgi?id=11674
Forest winehq@tibit.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@tibit.com
http://bugs.winehq.org/show_bug.cgi?id=11674
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #260 from Stefan Dösinger stefan@codeweavers.com 2012-12-04 04:10:54 CST --- You mostly noticed this already, but you really have to use WINEDEBUG=-all for benchmarking and playing.
Wine calls glGetError() after every opengl call to report any possible error through ERRs. If you use WINEDEBUG=-all wined3d knows that you won't see those messages and doesn't bother calling glGetError or glCheckFramebufferStatus.
Redirecting stderr to /dev/null has the same effect. Ideally this happens when you launch a game via start menu entries, but in some situations output is redirected to ~/.xsession-errors in that case.
I did some testing myself with Nvidia's threaded optimizations. It seems to be an improvement for apps that just use state changes and draws. My impression is that it doesn't handle buffer uploads properly, and most modern games use dynamic vertex buffers heavily. You may get some performance improvements by commenting out the GL_ARB_map_buffer_range extension in dlls/wined3d/directx.c and maybe GL_ARB_vertex_buffer_object and GL_ARB_pixel_buffer_object as well. This might help in older apps(which run fast enough anyways), in newer apps it seems that there's just too much geometry data to get decent performance without buffer objects.
http://bugs.winehq.org/show_bug.cgi?id=11674
Pierre-Loup Griffais pierreloup.griffais@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pierreloup.griffais@gmail.c | |om
--- Comment #261 from Pierre-Loup Griffais pierreloup.griffais@gmail.com 2012-12-17 14:37:56 CST --- (In reply to comment #260)
You mostly noticed this already, but you really have to use WINEDEBUG=-all for benchmarking and playing.
Wine calls glGetError() after every opengl call to report any possible error through ERRs. If you use WINEDEBUG=-all wined3d knows that you won't see those messages and doesn't bother calling glGetError or glCheckFramebufferStatus.
Redirecting stderr to /dev/null has the same effect. Ideally this happens when you launch a game via start menu entries, but in some situations output is redirected to ~/.xsession-errors in that case.
I did some testing myself with Nvidia's threaded optimizations. It seems to be an improvement for apps that just use state changes and draws. My impression is that it doesn't handle buffer uploads properly, and most modern games use dynamic vertex buffers heavily. You may get some performance improvements by commenting out the GL_ARB_map_buffer_range extension in dlls/wined3d/directx.c and maybe GL_ARB_vertex_buffer_object and GL_ARB_pixel_buffer_object as well. This might help in older apps(which run fast enough anyways), in newer apps it seems that there's just too much geometry data to get decent performance without buffer objects.
Hi Stefan,
You're right that MapBuffer (and by extension, MapBufferRange) is not a fast path for the threaded optimizations. The preferred path for geometry is buffer objects updated through BufferSubData. We actually have optimizations that cause BufferSubData used with dynamic vertex buffer patterns to be faster when threaded optimizations are enabled, which is the preferred path for heavy dynamic uploads in modern games. We can have a chat about it if you'd like, either through email or IRC.
Thanks, - Pierre-Loup
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #262 from Henri Verbeet hverbeet@gmail.com 2012-12-17 19:40:55 CST --- (In reply to comment #261)
You're right that MapBuffer (and by extension, MapBufferRange) is not a fast path for the threaded optimizations. The preferred path for geometry is buffer objects updated through BufferSubData.
Is there a good reason for that, or is that something NVIDIA is going to fix?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #263 from Stefan Dösinger stefan@codeweavers.com 2012-12-20 10:30:01 CST --- Created attachment 42868 --> http://bugs.winehq.org/attachment.cgi?id=42868 wined3d: Use glBufferSubDataARB for dynamic buffer uploads
This patch implements Pierre-Loup's suggestion. It may or may not give you better performance with Nvidia's threaded optimizations. On my system performance is terrible with this patch and threaded optimizations, so I may have done something wrong in the patch - but I have no idea what that might be.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #264 from Stefan Dösinger stefan@codeweavers.com 2012-12-20 14:42:58 CST --- (In reply to comment #263)
On my system performance is terrible with this patch and threaded optimizations
Actually, I forgot WINEDEBUG=-all. The patch does some good now. The games I tested are faster with threaded optimizations. It's not the holy grail, but a 20% to 30% performance gain.
Note that the patch won't go into Wine as-is. It has the potential to make things much worse without threaded optimizations or other drivers. I really hope that NVidia finds a way to improve glMapBuffer(INVALIDATE_BUFFER / UNSYNCHRONIZED) behavior with threaded optimizations.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #265 from Henri Verbeet hverbeet@gmail.com 2012-12-21 03:20:08 CST --- (In reply to comment #264)
Note that the patch won't go into Wine as-is. It has the potential to make things much worse without threaded optimizations or other drivers. I really hope that NVidia finds a way to improve glMapBuffer(INVALIDATE_BUFFER / UNSYNCHRONIZED) behavior with threaded optimizations.
The specific implementation would probably need some work even if it did go in, but as far as I'm concerned it won't go in at all unless it either results in a general improvement on other drivers as well, or NVIDIA can be bothered to at least answer questions. I'm still particularly unhappy about the botched RandR implementation, and NVIDIA's unresponsiveness in general.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #266 from Pierre-Loup Griffais bugs.winehq.org@plagman.net 2012-12-21 11:59:47 CST --- (In reply to comment #265)
The specific implementation would probably need some work even if it did go in, but as far as I'm concerned it won't go in at all unless it either results in a general improvement on other drivers as well, or NVIDIA can be bothered to at least answer questions. I'm still particularly unhappy about the botched RandR implementation, and NVIDIA's unresponsiveness in general.
Hi Henri,
Thanks for your interest; I'm sorry for the confusion, I didn't realize Stefan didn't keep you in the loop following our discussion on that topic. The point I was making is that BufferSubData inherently maps better to dynamic buffer workloads than MapBuffer-based updating in threaded usecases. Since BufferSubData requests can be immediately queued in-band in both commands streams, overhead is kept at a minimum and maximal GPU throughput can be achieved. Stefan pointed out that memory usage was a big concern for Wine, and I also believe this approach maps the best to keeping memory usage low. Having a fast implementation of MapBufferRange is threaded mode would require either more memory/VM or more overhead than directly using BufferSubData, depending on the approach used.
For reference, here are the numbers I get from Stefan's test case which maps to D3D dynamic buffer updating patterns, modified with my recommended path:
Not Threaded Threaded MapBuffer 124 23-67 (very bursty) BufferSubData 156 550
Don't hesitate to contact me should you have any more questions; thanks! - Pierre-Loup
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #267 from Henri Verbeet hverbeet@gmail.com 2012-12-21 13:45:08 CST --- (In reply to comment #266)
Thanks for your interest; I'm sorry for the confusion, I didn't realize Stefan didn't keep you in the loop following our discussion on that topic. The point I was making is that BufferSubData inherently maps better to dynamic buffer workloads than MapBuffer-based updating in threaded usecases. Since BufferSubData requests can be immediately queued in-band in both commands streams, overhead is kept at a minimum and maximal GPU throughput can be achieved.
It doesn't strike me as something that's really inherent in the API, just the specific implementation NVIDIA has. You'd have a point for D3D "static" buffers that would require a synchronized map, but then those aren't really supposed to be modified after they're initially created. (And implicitly that means they're only supposed to be mapped before they're used in any draws, so you should only ever potentially have to wait for the upload to finish before starting a draw, once.) D3D "dynamic" buffers end up using either GL_MAP_UNSYNCHRONIZED_BIT or GL_MAP_INVALIDATE_BUFFER_BIT on glMapBufferRange(), and shouldn't require synchronization with the command stream at all; it's the application's responsibility to ensure all accesses are safe.
Stefan pointed out that memory usage was a big concern for Wine, and
The issue I suspect he's referring to is more about address space than actual memory usage. Regardless, although that consideration does play a role, the main consideration for me is that changing the code here would mean either potentially making things worse for other drivers in order to make things better for NVIDIA, or adding a special codepath for NVIDIA somewhere that's going to bitrot or increase maintenance costs. While the latter at least isn't entirely out of the question, it would require some solid justification.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #268 from Pierre-Loup Griffais bugs.winehq.org@plagman.net 2012-12-21 14:38:00 CST --- (In reply to comment #267)
D3D "dynamic" buffers end up using either GL_MAP_UNSYNCHRONIZED_BIT or GL_MAP_INVALIDATE_BUFFER_BIT on glMapBufferRange(), and shouldn't require synchronization with the command stream at all; it's the application's responsibility to ensure all accesses are safe.
It's still a synchronous API that needs to return a pointer immediately, though, so it stalls the CPU command stream between the main and worker thread in the driver. Which, in turn, can introduce GPU starvation.
The issue I suspect he's referring to is more about address space than actual memory usage.
Yes, and that makes keeping a full mapping of the buffer undesirable compared to pushing all sub-updates in-band and freeing the corresponding chunks of memory as they go through.
Regardless, although that consideration does play a role, the main consideration for me is that changing the code here would mean either potentially making things worse for other drivers in order to make things better for NVIDIA, or adding a special codepath for NVIDIA somewhere that's going to bitrot or increase maintenance costs. While the latter at least isn't entirely out of the question, it would require some solid justification.
You'd think the performance gains I demonstrated (and that Stefan observed in real-world usage) would be justification enough. Since this is the path that maps the best to D3D dynamic buffers (regardless of what current implementations do with it), I believe it makes sense at least have it available somewhere, if not by default yet, and then attempt to improve drivers if performance problems are uncovered (if any). It certainly seems like a better approach than trying to fix drivers to optimize paths for usage patterns that don't make sense at the cost of introducing overhead for usage patterns that do.
Thanks! - Pierre-Loup
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #269 from Henri Verbeet hverbeet@gmail.com 2012-12-21 15:53:02 CST --- (In reply to comment #268)
(In reply to comment #267)
D3D "dynamic" buffers end up using either GL_MAP_UNSYNCHRONIZED_BIT or GL_MAP_INVALIDATE_BUFFER_BIT on glMapBufferRange(), and shouldn't require synchronization with the command stream at all; it's the application's responsibility to ensure all accesses are safe.
It's still a synchronous API that needs to return a pointer immediately, though, so it stalls the CPU command stream between the main and worker thread in the driver. Which, in turn, can introduce GPU starvation.
I'm not sure why you'd want the CS to be involved at all, MapBuffer*() should essentially be a wrapper around ioremap_*().
You'd think the performance gains I demonstrated (and that Stefan observed in real-world usage) would be justification enough.
Well, no.
if performance problems are uncovered (if any). It certainly seems like a better approach than trying to fix drivers to optimize paths for usage patterns that don't make sense at the cost of introducing overhead for usage patterns that do.
If you really feel you can't possibly make ARB_map_buffer_range work correctly, you probably shouldn't expose the extension at all. The fallback path we currently have for that would need some improvements, but that shouldn't be much of a problem.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #270 from Pierre-Loup Griffais bugs.winehq.org@plagman.net 2012-12-21 16:22:03 CST --- (In reply to comment #269)
If you really feel you can't possibly make ARB_map_buffer_range work correctly, you probably shouldn't expose the extension at all. The fallback path we currently have for that would need some improvements, but that shouldn't be much of a problem.
ARB_map_buffer_range works great, I never implied otherwise. It just isn't well-suited for dynamic buffer updates when you force-enable the multi-threaded driver. Keep in mind I'm not trying to fix an NVIDIA performance problem here, there isn't one that I know of. I'm showing you a way to get more performance by using a combination of APIs and functionality that maps better to this use case. You're acting like I'm trying to sneak code into Wine to work around broken driver design. I would definitely recommend using ARB_map_buffer_range for other use cases, where it makes sense.
(In reply to comment #269)
I'm not sure why you'd want the CS to be involved at all, MapBuffer*() should essentially be a wrapper around ioremap_*().
Yes, that's "essentially" what it does. However it does return a value immediately, so it has ensure any GL commands in-flight between the main and worker threads are fully completed before it can be processed. I'll add that before you can perform the mapping ioctl, you have to figure out which context is current, which buffer name is bound, resolve that name, figure out what's the state of the buffer, where it's stored, what rendering is in flight, validate the access modes and plenty of other stuff.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #271 from Henri Verbeet hverbeet@gmail.com 2012-12-22 00:44:38 CST --- (In reply to comment #270)
ARB_map_buffer_range works great, I never implied otherwise.
I'd consider stalling the CS on unsynchronized maps broken, since I think it defeats much of the point of having the extension in the first place. Thinking a bit more about it though, I guess not reporting ARB_map_buffer_range isn't really an option for you because it's core functionality in GL3 and later.
case. You're acting like I'm trying to sneak code into Wine to work around broken driver design.
Not really, but I am detecting a certain amount of "I'm from NVIDIA, trust me on this." and "Other drivers should be 'fixed' to behave the same way we do." in your arguments, and I don't think it's really helping them. I'm really just trying to figure out what the actual issue you're having with unsynchronized maps is.
Yes, that's "essentially" what it does. However it does return a value immediately, so it has ensure any GL commands in-flight between the main and worker threads are fully completed before it can be processed.
I don't think there's any such requirement in the GL spec, at least not for unsynchronized maps.
I'll add that before you can perform the mapping ioctl, you have to figure out which context is current, which buffer name is bound, resolve that name, figure out what's the state of the buffer, where it's stored, what rendering is in flight, validate the access modes and plenty of other stuff.
Well, yes, but most of that applies to any GL call referencing a buffer object, including BufferSubData(). Are you implying that you've moved GL object name resolution (and related calls like DeleteBuffers()) into your worker thread as well? In that case you would indeed have to stall (well, sort of, you could probably avoid actually stalling even in that case, but I suppose it would be more complicated / expensive than you'd like regardless) just to resolve the name (and not so much for the actual map itself). That issue wouldn't so much be inherent to the ARB_map_buffer_range API though, but rather inherent to the specific CS design chosen.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #272 from Pierre-Loup Griffais bugs.winehq.org@plagman.net 2012-12-25 11:36:46 CST --- Please keep in mind all my input so far applies to my original point of leveraging the potential performance gains that the NVIDIA threaded optimizations can provide, not the general case, where I would expect both updating methods to be roughly equivalent (with the small tradeoff of MapBuffer requiring more address space but less copies).
Please see the "Threaded Optimizations" section in the link below for more context:
ftp://download.nvidia.com/XFree86/Linux-x86/313.09/README/openglenvvariables.html
The goal here is to have _minimal_ CPU overhead in the main thread, so the logic there doesn't have any knowledge of the GL state. This greatly improves performance in both CPU-bound and GPU-bound use-cases (since it reduces starvation problems and allows the driver to more easily perform optimizations at the command-stream level, rather than dealing with a single command at a time), at the expense of not interacting well with totally synchronous commands such as all Gets and MapBuffer. Semi-synchronous APIs that were designed with pipelining in mind such as queries are still a fast path.
Currently the only two threading modes exposed are "forced-off" (the default) and "forced-on", which the __GL_THREADED_OPTIMIZATIONS environment variable controls. In the future there will be an "auto" mode similar to Windows where the driver will know to fall out of threaded mode if it detects that the workload uses a large number of synchronous calls, to avoid impairing performance in these cases.
To summarize, I think that in the current state of things, MapBufferRange vs BufferSubData for the regular case are two fast, valid approaches with tradeoffs on each side. If address space is a concern, relying on buffer mappings might be problematic, however.
But to get the best throughput, I recommend enabling the NVIDIA threaded optimizations and using BufferSubData with the invalidation scheme I explained (since it gives the driver similar information to the what the MapBuffer path specifies) to unlock further performance gains and be faster than D3D at dynamic buffers.
I hope you're having a great holiday season; best wishes!
http://bugs.winehq.org/show_bug.cgi?id=11674
Christian christian.frank@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |christian.frank@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #273 from Christian christian.frank@gmx.de 2013-01-02 05:35:14 CST --- Hi guys,
first of all, from a wine end user perspective, thanks to the nvidia dev for showing up and giving tips for improving gameing performance in wine when using their proprietary drivers.Also many thanks to Stefan for providing a small patch to enable the recommended nvidia behavior so that we can do some test with it, which i'm still in the middle of.
I will upload a spreadsheet later with detailed test results.
Overall it looks like the following:
1. I can already improve performance for some games by simply enabling the threaded optimizations in the nvidia driver and using a non patched plain wine. This can lead to 20% perf improvements e.g in 3DMark06.
2. Using the patched BufferSubData patched version of wine for games which already work fine with plain wine + threaded driver optimization didn't futher improve performance for my test cases.
3. BUT, and here i gets very interesting, for Starcraft 2, which behaves worse with threading enabled ( Plain Wine 70fps, Plain Wine+ Threading 60fps) gains a HUGE performance boost using the patch -> 100fps !! So the performance increased from 70fps to 100fps in my testcase which is amazing !
@Pierre-Loup Griffais ->Is this the expected behaviour ?
Please guys, try to be as less political as possible to get the best performance for the wine endusers :) .. If such things can't be enabled per default, please bring in the recommended changes and let us enable them via a reg key. Many of the wine users use nvidia cards with the proprietary driver out there.
@Pierre-Loup Griffais, Offtopic:
- Why does nvidia-smi not show up the gpu utlization of my gtx 560ti. I want to see whats limiting my framerate (cpu or gpu) ?!?
Cu, Christian
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #274 from Pierre-Loup Griffais bugs.winehq.org@plagman.net 2013-01-02 15:25:24 CST --- Hi Christian,
Thanks for giving it a try! The results you're observing look in line with my expectations; apps that make heavy use of dynamic buffers should have no change or even a slight performance hit with threaded optimizations forced on, but a gain with the patch. Other apps should exhibit the same gain before and after the patch.
I should add that if anyone tries to perform the same experiments, make sure to set WINEDEBUG=-all as the synchronous GetError calls completely defeat threaded optimizations otherwise.
Let's take your other question offline to minimize noise in this already cluttered bug.
Thanks! - Pierre-Loup
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #275 from Forest winehq@tibit.com 2013-01-02 20:04:06 CST --- In case anyone would like to test with the "Use glBufferSubDataARB for dynamic buffer uploads" patch, I have applied it to the Ubuntu wine build I maintain for Guild Wars 2 users. Sadly, it doesn't seem to help that game on my system (GeForce 660 Ti, nvidia-current 310.19) but it would be interesting to hear from others.
https://launchpad.net/~foresto/+archive/winepatched/
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #276 from Pierre-Loup Griffais bugs.winehq.org@plagman.net 2013-01-02 20:11:15 CST --- I assume that was with testing with the following?
export WINEDEBUG=-all export __GL_THREADED_OPTIMIZATIONS=1
I've seen it spelled as "OPTIMISATIONS" above, which won't work.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #277 from Forest winehq@tibit.com 2013-01-02 20:18:52 CST --- My launch script looked like this:
export WINEDEBUG=-all export __GL_THREADED_OPTIMIZATIONS=1 export LD_PRELOAD="libpthread.so.0 libGL.so.1" /my/path/GuildWars2/Gw2.exe -autologin
Note that I did not use the game client's -dx9single hack that is normally necessary to see the login screen under wine, since I figured it might get in the way of multithreaded performance. Storing my password and using -autologin allowed me to enter the game anyway.
http://bugs.winehq.org/show_bug.cgi?id=11674
Kol kol@MV8660.spb.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kol@MV8660.spb.edu
--- Comment #278 from Kol kol@MV8660.spb.edu 2013-01-02 21:54:39 CST --- Let me present my results of tests in real applications. Testing some old games I found that the BufferSubData patch is better to use along with the Crysis Memory patch from Bug#18799, which sets WINED3D_BUFFER_DOUBLEBUFFER flag in "buffer_init" function in "dlls/wined3d/buffer.c".
All tests were carried out under Wine 1.5.20 with WINEDEBUG="-all" and with the use of Nvidia proprietary driver 310.19. For each game I estimated the average number of FPS in some fixed scene with distant land and moving objects visible in 4 variants: 1. unpatched Wine with threaded optimisations disabled; 2. unpatched Wine with threaded optimisations enabled; 3. Wine with the BufferSubData patch, threaded optimisations enabled; 4. Wine with the BufferSubData and the Crysis Memory patch, threaded optimisations enabled. The results are TES3:Morrowind 36/47/47/50, TES4:Oblivion 52/57/62/70, TES5:Skyrim 19/22/27/36. For Crysis 1 enabling of threaded optimisations decreases performance but the BufferSubData patch increases it again. To start this game the patch from Bug#18799 is necessary, so I tested variants 1-3 with this patch, FPS are 57/43/77.
The only example of decreasing performance (10 times) with the BufferSubData patch which I saw is Heroes of Might & Magic 5: 70/21/2/2. I think that this is due to WINED3D_BUFFER_DOUBLEBUFFER flag, because under Wine patched only with the Crysis Memory patch the game also shows ~2 FPS.
Also, it seems that all these things have nothing to do with optimisations for multi-processor systems. For example, in Skyrim under Wine with both patches and threaded optimisations enabled the full CPU load by the main process "TESV.exe" for a quad core processor is 110%-120% (must be 300%-400% ?).
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #279 from Christian christian.frank@gmx.de 2013-01-03 02:55:37 CST --- Created attachment 43065 --> http://bugs.winehq.org/attachment.cgi?id=43065 Performance Tests with nvidia patch
Performance data for tests with plain wine, plain wine+threading, plain wine+nvidia patch+threading.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #280 from Christian christian.frank@gmx.de 2013-01-03 03:03:36 CST --- Hi,
as promised i added an pdf file with some more detailed test results including sc2, 3dmark06,hard rest and crysis 1.
Overall the performance increase in these test cases using wine+threading and especially wine+threading+nvidia patch are really great.
You see increases between 20%-45% in my test cases which is amazing. In cases where adding threading alone (plain wine+nvida threading) hurts perf (crysis,sc2) the performance boost when adding the nvidia patch is > 40%.
In cases where adding threading alone already boosts performance, you don't get an additional boost using the nvidia patch in addition.
So, from an end user perspective, wine+nv threading+nvidia patch gives you the best fps right now in all cases i tested (except hard reset which crashed, dunno why)
Should we create a forum thread and publish more resulsts there or are we allowed to upload them here ? Don't want to further spam bugzilla if the info doesn't belong in here.
Cu, Christian
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #281 from Stefan Dösinger stefan@codeweavers.com 2013-01-03 03:30:40 CST --- For those who have Windows installed on the systems you're testing, can you add Windows performance numbers for comparison?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #282 from gpiez@web.de 2013-01-03 06:12:22 CST --- Let me add some further data from the World of Warcraft timedemo benchmark with wine-1.5.20:
vanilla 42.0 fps __GL_THREADED_OPTIMIZATIONS=1 49.3 fps __GL_THREADED_OPTIMIZATIONS=1 + glBufferSubDataARB patch 56.7 fps
So in total a healthy 30% improvement. So from my end user opinion (completely irrelevant, I know :-)), Stefans patch should go in, at least optional. The Crysis memory fix (or more like a hack, as I understand it) didn't make a difference.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #283 from gpiez@web.de 2013-01-03 07:38:56 CST --- I made a /timetest benchmark run under Windows 7 x64, exactly with the same graphical settings: 80,9 fps
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #284 from Christian christian.frank@gmx.de 2013-01-03 09:55:11 CST --- @gpiez: Is this with d3d or opengl in wine ? It's frustrating to see that the diff is still so HUGE :(.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #285 from gpiez@web.de 2013-01-03 18:36:28 CST --- Both above are d3d9.
If I compare opengl/linux with d3d9/windows I need to disable shadows and water reflections, because they are not supported with opengl. I did test with medium water and good shadows, which are reasonable settings.
w/o shadows/water:
linux/d3d9: 81,0 fps linux/opengl: 87,5 fps windows/d3d9: 103,2 fps
Note that opengl is deprecated for the windows version, it is no longer selectable in the interface, but still works with a command line switch. There were already major bugs (map cursor not visible in opengl etc., char screen not working). Additionally it becomes more and more visually unappealing as new effects work only with directx.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #286 from Stefan Dösinger stefan@codeweavers.com 2013-01-04 04:07:55 CST ---
linux/d3d9: 81,0 fps
Is that with the various optimizations enabled?
Can you add windows/opengl, just out of curiosity?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #287 from gpiez@web.de 2013-01-04 07:25:58 CST --- World of Warcraft timetest benchmarks.
With Shadows and Water (opengl not possible):
linux/vanilla wine 42.0 fps __GL_THREADED_OPTIMIZATIONS=1 49.3 fps __GL_THREADED_OPTIMIZATIONS=1 + glBufferSubDataARB patch 56.7 fps windows/d3d9 80.9 fps
w/o shadows/water, linux/wine with all optimizations and patches:
linux/wine/d3d9: 81.0 fps linux/wine/opengl: 87.5 fps windows/d3d9: 108.2 fps (not 103.2, I had a typo above) windows/opengl: 74.8 fps
http://bugs.winehq.org/show_bug.cgi?id=11674
rob mysystemp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mysystemp@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #288 from paolinidiego paolinidiego@gmail.com 2013-01-14 03:38:21 CST --- wined3d: Use glBufferSubDataARB for dynamic buffer uploads (3.71 KB, patch)
users with amd / ati? They can use this patch or are forced to use rgl yet? Then I noticed that the site is no longer accessible rgl, if users with amd / ati should continue to use rgl patch, you can put it available somewhere?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #289 from paolinidiego paolinidiego@gmail.com 2013-01-20 15:36:54 CST --- (In reply to comment #287)
World of Warcraft timetest benchmarks.
With Shadows and Water (opengl not possible):
linux/vanilla wine 42.0 fps __GL_THREADED_OPTIMIZATIONS=1 49.3 fps __GL_THREADED_OPTIMIZATIONS=1
- glBufferSubDataARB patch 56.7 fps
windows/d3d9 80.9 fps
w/o shadows/water, linux/wine with all optimizations and patches:
linux/wine/d3d9: 81.0 fps linux/wine/opengl: 87.5 fps windows/d3d9: 108.2 fps (not 103.2, I had a typo above) windows/opengl: 74.8 fps
sorry but I have tried in every way but I do not do more than 50 fps
my pc is intel i7 950 16 gigs of ram ssd use ubuntu precise tried both 64-bit and i386 nvidia video card I have now dts250 you ZOTAC 1gb dd3 motherboard asus x58 wine soucers also tried both deb packeages ppa foreigner guildqarsIII
I'm going crazy I do not know how to play.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #290 from Tom fastumzug@fastmail.fm 2013-01-22 14:28:18 CST --- I have made a similar experience testing GW2 with the new Nvidia patch presented here. No reasonable improvement in FPS rates :( I suppose, GW2 is simply not using any patch related functions.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #291 from Forest winehq@tibit.com 2013-01-22 15:56:00 CST ---
I suppose, GW2 is simply not using any patch related functions.
Or perhaps it is, but another part of wine is a narrower bottleneck. Either way, I wonder if a new bug report should be opened for Guild Wars 2's inability to benefit from multiple CPU cores in wine.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #292 from paolinidiego paolinidiego@gmail.com 2013-01-23 00:29:34 CST --- The problem is not only in but also Guildwars World of Warcraft in general when I raid of 10 or 25.
but I tried to go back to using even rgl.so but I have always the same problem and I do not understand why.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #293 from Christian christian.frank@gmx.de 2013-02-26 13:39:40 CST --- Hi guys,
the patch still works great for sc2. It doubles my performance with ease.
But i have a big problem:
Using a patched wine version with threading enabled and driver 313.09, everything works great. Performance is perfect.
Switching my driver to 313.18 show the same performance, but starcraft 2 crashes back to desktop. This happens without prior notice. Something has changed in 313.18 which causes this issue, cause rolling back to 313.09 solves it 100%.
Geforce gtx 560 Ti Ubuntu 13.04 (same issue with ubuntu 12.10)
Maybe Pierre-Loup Griffais can help with this issue ?
Many thanks Christian
http://bugs.winehq.org/show_bug.cgi?id=11674
Felix Hellmann privat@cirk2.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |privat@cirk2.de
--- Comment #294 from Felix Hellmann privat@cirk2.de 2013-03-06 19:32:18 CST --- The patch causes Visual distortions in Tomb Raider (2013). Normaly those distortions are fixed by enabling StrictDrawOrder but with it they persist. See bug 33125 (http://bugs.winehq.org/show_bug.cgi?id=33125) for screenshots.
http://bugs.winehq.org/show_bug.cgi?id=11674
hansanthonio hans_anthonio@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans_anthonio@yahoo.com
--- Comment #295 from hansanthonio hans_anthonio@yahoo.com 2013-04-11 03:09:03 CDT --- 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, thank you http://thejakartastory.blogspot.com/2013/03/sekolah-belajar-forex-fbs-indone... http://thejakartastory.blogspot.com/2013/03/acer-iconia-pc-tablet-dengan-win... http://thejakartastory.blogspot.com/ http://downloadgratissource.blogspot.com/ http://www.cebox.biz/
http://bugs.winehq.org/show_bug.cgi?id=11674
Pablo Salgado chatocl@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chatocl@yahoo.com
--- Comment #296 from Pablo Salgado chatocl@yahoo.com 2013-05-09 23:15:02 CDT --- I tested wined3d: Use glBufferSubDataARB for dynamic buffer uploads patch on:
ATI Radeon 6600M I only try SC2, it worked the same way that "standard" wine included in ubuntu. fps were almost the same, graphical quality was the same.
Nvidia 650 ti SC2 fps were higher 20/30% Company of Heroes almost the same fps CivV it crashed after an hour or two. After the crash I run it without the GL_THREADED_OPTIMIZATIONS/ libpthread and it was stable
only for NVIDIA gpu I used a modified start script that includes export __GL_THREADED_OPTIMIZATIONS=1 export LD_PRELOAD="libpthread.so.0 libGL.so.1"
for both I disabled debug
Wine 1.5.29 ubuntu-wineppa Wine 1.5.29 ubuntu+nvidiapatch home compiled Ubuntu 12.04 LTS nvidia drivers 317.19 Catalyst drivers 13.4
I play a lot of starcraft. From now on I will be always using patched wine! if someone start maintaining a ppa I would be happy if the pach is included in wine I will be VERY happy
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #297 from Felix Hellmann privat@cirk2.de 2013-05-10 03:48:50 CDT --- What patch did you use for wine 1.5.29? the patch from comment 263 does not work for me. Apparently the whole mac stuff moved into that file, stopping the patch from applying.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #298 from gpiez@web.de 2013-05-10 04:56:53 CDT --- Created attachment 44420 --> http://bugs.winehq.org/attachment.cgi?id=44420 Patch for using map_buffer
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #299 from gpiez@web.de 2013-05-10 04:58:29 CDT --- I am using the patch attached to the comment above. Works in 1.2.29. If you are using gentoo, place it in /etc/portage/patches/app-emulation/wine and you are golden ;-)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #300 from Felix Hellmann privat@cirk2.de 2013-05-10 05:03:18 CDT --- That patch (which is the same as in comment 263) fails for me against git. error: patch failed: dlls/wined3d/buffer.c:168 error: dlls/wined3d/buffer.c: patch does not apply
I use "git apply" which worked fine until one or two versions ago.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #301 from Stefan Dösinger stefan@codeweavers.com 2013-05-10 05:33:13 CDT --- Fyi, I've done some performance testing with nvidia, r300g and r600g. On r300g and r600g, the glMapBufferRange codepath (i.e., the current one) is a lot faster than glBufferSubData in all tests except 3Dmark2001 (I tested 3dmark2k, 3dmark2k1, half life 2 and my own dynamic buffer test).
On Nvidia, glBufferSubData and glMapBufferRange are pretty equal when the threaded optimizations are off. With threaded optimizations on, glBufferSubData is a lot faster.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #302 from Stefan Dösinger stefan@codeweavers.com 2013-05-10 05:35:04 CDT --- The bottom line of my previous post: The evidence so far does not support merging the glBufferSubData patch. While improving nvidia, it would make other drivers worse.
I'm currently working on our own implementation of a command stream / worker thread, I hope this makes solving this issue easier.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #303 from Pablo Salgado chatocl@yahoo.com 2013-05-10 18:12:29 CDT --- (In reply to comment #297)
What patch did you use for wine 1.5.29? the patch from comment 263 does not work for me. Apparently the whole mac stuff moved into that file, stopping the patch from applying.
I downloaded source from wine PPA
sudo add-apt-repository ppa:ubuntu-wine/ppa apt-get source wine1.5
Then I patched
sudo patch -p1 < xx.patch
patching file dlls/wined3d/buffer.c Hunk #1 succeeded at 166 with fuzz 2 (offset -2 lines). Hunk #2 succeeded at 656 (offset -7 lines). Hunk #3 succeeded at 675 (offset -7 lines).
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #304 from Felix Hellmann privat@cirk2.de 2013-05-10 19:22:50 CDT --- ok it seems to apply properly with patch -p1.
http://bugs.winehq.org/show_bug.cgi?id=11674
John thewidgetman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thewidgetman@gmail.com
--- Comment #305 from John thewidgetman@gmail.com 2013-07-03 00:45:57 CDT --- So is this problem an issue that's always been affecting starcraft 2 under wine performance? I mean, there's an absolutely huge difference between performance on linux and windows for me, and there always has been with a variety of different distributions and hardware.
Is this the final answer we've been looking for to our starcraft 2 under linux wores?
http://bugs.winehq.org/show_bug.cgi?id=11674
fengshaun USKLCPEI@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |USKLCPEI@gmail.com
--- Comment #306 from fengshaun USKLCPEI@gmail.com 2013-08-05 19:44:26 CDT --- Has there been any updates regarding this bug? I see there are many attachments. Do we have an agreement on a workaround or a possible fix?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #307 from Stefan Dösinger stefan@codeweavers.com 2013-08-06 02:58:21 CDT --- The solution is our own worker thread / command stream, similar in nature to Nvidia's threaded optimizations. I am currently working on that, but it will take a few more months to get it upstream. In the next few weeks (most likely after I return from holidays), I plan to post a set of patches for testing on wine-devel.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #308 from sxe sxxe@gmx.de 2013-08-06 12:53:41 CDT --- Hi Stephan, that sound fantastic, do you accept a small donation? I think its important to support the work on this issue.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #309 from Stefan Dösinger stefan@codeweavers.com 2013-08-06 17:47:32 CDT --- (In reply to comment #308)
Hi Stephan, that sound fantastic, do you accept a small donation? I think its important to support the work on this issue.
Thanks for the offer :-) . I am employed by CodeWeavers (http://www.codeweavers.com), so there's no need to donate money to me personally. If you want to support our work on Wine, you can buy a copy of CrossOver. Our work goes back to upstream Wine. (Except of course for dirty hacks Wine won't accept anyway.)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #310 from Stefan Dösinger stefan@codeweavers.com 2013-09-03 03:19:19 CDT --- You may be interested in my command stream work I've posted to http://www.winehq.org/pipermail/wine-devel/2013-September/101106.html . This patchset implements a feature similar to __GL_NV_THREADED_OPTIMIZATIONS in wined3d itself. It isn't complete yet, but it improves a lot of games already and should work on all drivers.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #311 from sxe sxxe@gmx.de 2013-09-03 05:57:46 CDT --- (In reply to comment #310)
You may be interested in my command stream work I've posted to http://www.winehq.org/pipermail/wine-devel/2013-September/101106.html . This patchset implements a feature similar to __GL_NV_THREADED_OPTIMIZATIONS in wined3d itself. It isn't complete yet, but it improves a lot of games already and should work on all drivers.
These patches are awesome. I get a 50% to 100% FPS increase in GW2. I sent you my results per mail.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #312 from Pierre-Loup Griffais bugs.winehq.org@plagman.net 2013-09-04 13:22:46 CDT --- It'd be nice to get the updated buffer strategy change upstream under an optional switch/regkey that NVIDIA users can enable, as it's going to hit optimizations in the driver code that other paths cannot in conjunction with NVIDIA's own threading model. Is this something that you would consider in parallel to the command stream work you're submitting?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #313 from Stefan Dösinger stefan@codeweavers.com 2013-09-04 13:55:50 CDT --- (In reply to comment #312)
It'd be nice to get the updated buffer strategy change upstream under an optional switch/regkey that NVIDIA users can enable, as it's going to hit optimizations in the driver code that other paths cannot in conjunction with NVIDIA's own threading model.
I'd be very unhappy with a registry key to control this. There seems to be no agreement among driver vendors which buffer update mechanism is preferred. You say glBufferSubData, Intel says glMapBufferRange. If the ARB makes a statement about which path is preferred, I'm happy to follow their recommendation. Otherwise this is means burdening users with a driver implementation difference they really shouldn't have to bother about and that shouldn't even exist in the first place.
In CrossOver I have a hack that detects the presence of the Nvidia driver and __GL_NV_THREADED_OPTIMIZATIONS flag. That would work a bit better, because at least the users don't have to worry about it.
In my command stream I'm using glBufferSubData for buffer updates. That's not due to my CS design, but because right now we cannot draw from mapped buffers. GL_ARB_buffer_storage addresses this problem, so the long term idea is to use it if available and fall back to glMapBufferRange otherwise.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #314 from Pierre-Loup Griffais bugs.winehq.org@plagman.net 2013-09-04 14:11:43 CDT --- So changing the buffer update strategy automatically depending on which driver is running isn't an option either?
As you said, buffer_storage should make things a lot easier for everyone, assuming it's used properly.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #315 from Stefan Dösinger stefan@codeweavers.com 2013-09-04 14:38:27 CDT --- What's the point of a standardized API like OpenGL if I have to detect the implementation and use different codepaths to satisfy undocumented constraints to make it work properly?
But I'd prefer to discuss this over a beer than on the backs of our users. I could imagine using a GL extension that allows the driver to communicate its preferred update method. That should be more solid than parsing the vendor string and __GL_NV_THREADED_OPTIMIZATIONS setting.
What is a 'proper' way to use buffer_storage? My rough plan is to create buffers with MAP_READ_BIT | MAP_WRITE_BIT | MAP_PERSISTENT_BIT and use glMapBufferRange to access the buffer. MAP_READ_BIT would be optional and depend on the d3d flags the application sets. I'm not sure about MAP_COHERENT_BIT. If I'm not setting it, and calling MapBufferRange / UnmapBuffer, do I still have to call MemoryBarrier, or does UnmapBuffer take care of it? I don't care if changes made during map/unmap are picked up, I'll only ever draw from buffers mapped with MAP_UNSYNCHRONIZED.
I might also use CLIENT_STORAGE to preserve address space, but that is a lower priority.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #316 from Paul Kramer gitterrost4+winehq@gmail.com 2013-09-04 15:49:02 CDT --- (In reply to comment #310)
You may be interested in my command stream work I've posted to http://www.winehq.org/pipermail/wine-devel/2013-September/101106.html . This patchset implements a feature similar to __GL_NV_THREADED_OPTIMIZATIONS in wined3d itself. It isn't complete yet, but it improves a lot of games already and should work on all drivers.
Is there any way, I can adapt these patches to work with wine-1.7.0?
Currently wine-1.7.1 does not build under gentoo because of a problem with libxml2 being an old version and I'd really like to try out the patches.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #317 from Stefan Dösinger stefan@codeweavers.com 2013-09-04 15:52:08 CDT --- (In reply to comment #316)
Is there any way, I can adapt these patches to work with wine-1.7.0?
The easiest way is probably to apply them to 1.7.1 and copy dlls/wined3d to a 1.7.0 tree. You may also need dlls/ddraw, d3d8, d3d9, d3d10core, d3d10, dxgi, but most likely wined3d is enough.
I've solved that Gentoo problem by compiling an up-to-date libxml2 by hand and installing it to /usr/lib32. That is a better solution IMO.
That said, those bugs have a few known bugs. They'll most likely just crash. I'll send an updated version in the next days.
http://bugs.winehq.org/show_bug.cgi?id=11674
Selman ULUG selman.ulug@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |selman.ulug@gmail.com
--- Comment #318 from Selman ULUG selman.ulug@gmail.com 2013-09-04 16:06:37 CDT --- (In reply to comment #310)
You may be interested in my command stream work I've posted to http://www.winehq.org/pipermail/wine-devel/2013-September/101106.html . This patchset implements a feature similar to __GL_NV_THREADED_OPTIMIZATIONS in wined3d itself. It isn't complete yet, but it improves a lot of games already and should work on all drivers.
tested on an old notebook i5-460M & GT 420M. os is updated arch x86_64. Gw2 graphic settings is near medium. runned between bank and mystic forge about 10 minutes for every tests.
vanilla 12-16fps
44420 + __GL_THREADED_OPTIMIZATIONS=1 15-20fps (rarely spiking to 1fps)
cs + CSMT="disabled" 12-15fps
cs + CSMT="enabled" 18-24fps (but a few minutes later cpu + gpu hot & throttling to 7-8fps)
ps: I think I need a new notebook :)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #319 from Henri Verbeet hverbeet@gmail.com 2013-09-04 16:08:23 CDT --- (In reply to comment #317)
(In reply to comment #316)
Is there any way, I can adapt these patches to work with wine-1.7.0?
The easiest way is probably to apply them to 1.7.1 and copy dlls/wined3d to a 1.7.0 tree. You may also need dlls/ddraw, d3d8, d3d9, d3d10core, d3d10, dxgi, but most likely wined3d is enough.
I've solved that Gentoo problem by compiling an up-to-date libxml2 by hand and installing it to /usr/lib32. That is a better solution IMO.
The really easy way to "fix" it is probably to just put an "#undef LIBXML2_NEW_BUFFER" in an appropriate place in dlls/msxml3/node.c.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #320 from gpiez@web.de 2013-09-04 16:35:10 CDT ---
Currently wine-1.7.1 does not build under gentoo because of a problem with libxml2 being an old version and I'd really like to try out the patches.
You can build wine-1.7.1 under gentoo with USE="-xml" and a renamed 1.7.0 ebuild.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #321 from Austin English austinenglish@gmail.com 2013-09-04 16:37:39 CDT --- (In reply to comment #320)
Currently wine-1.7.1 does not build under gentoo because of a problem with libxml2 being an old version and I'd really like to try out the patches.
You can build wine-1.7.1 under gentoo with USE="-xml" and a renamed 1.7.0 ebuild.
You probably don't want to disable xml support in wine, it's used by a lot of applications.
http://bugs.winehq.org/show_bug.cgi?id=11674
hans grant grantonworldindo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |grantonworldindo@gmail.com
--- Comment #322 from hans grant grantonworldindo@gmail.com 2013-09-04 22:33:22 CDT --- 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 <a href="http://thejakartastory.blogspot.com/2013/05/cipto-junaedy.html">cipto junaedy</a>, <a href="http://www.beritaterkini.web.id/2013/07/cipto-junaedy-sang-fenomena.html">cipto junaedy</a>
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #323 from Dmitry Timoshkov dmitry@baikal.ru 2013-09-04 22:44:32 CDT --- (In reply to comment #322)
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 <a href="http://thejakartastory.blogspot.com/2013/05/cipto-junaedy.html">cipto junaedy</a>, <a href="http://www.beritaterkini.web.id/2013/07/cipto-junaedy-sang-fenomena.html">cipto junaedy</a>
Admin please block this spammer's account.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #324 from Austin English austinenglish@gmail.com 2013-09-05 02:38:15 CDT --- Disabled spammer.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #325 from Pablo Salgado chatocl@yahoo.com 2013-09-05 21:06:44 CDT --- Created attachment 45879 --> http://bugs.winehq.org/attachment.cgi?id=45879 SC2 bad rendering
changing graphics options (lowering them) usually fix the problem. Then changing them up 50% of getting high detail and good rendering
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #326 from Pablo Salgado chatocl@yahoo.com 2013-09-05 21:17:24 CDT --- (In reply to comment #310)
You may be interested in my command stream work I've posted to http://www.winehq.org/pipermail/wine-devel/2013-September/101106.html . This patchset implements a feature similar to __GL_NV_THREADED_OPTIMIZATIONS in wined3d itself. It isn't complete yet, but it improves a lot of games already and should work on all drivers.
tested Starcraft II on i5-3750 & 650 ti. (325.15 prop. drivers) ubuntu12.04 graphic settings is high
"vanilla" ubuntu wine ppa around 40 fps (measuring sec 30 in a replay)
44420 + __GL_THREADED_OPTIMIZATIONS=1 around 60 fps (measuring sec 30 in a replay)
cs + CSMT="enabled" around 80 fps (measuring sec 30 in a replay)
But graphics problems... please see atached screenshoot they can be solved by changing graphics details That happen in a random way for example if I disable 3d portraits usually get the right rendering, enabling 3d portraits again and most of the times good rendering!!?? new game => usually bad rendering => changing 3d portraits and again good rendering an so on.....
Also I have doubts regarding export LD_PRELOAD="libpthread.so.0 libGL.so.1" is that needed now?
Performance is really good (better than with Nvidia pacth) getting closer to native!
Many thanks for working on getting wine better
http://bugs.winehq.org/show_bug.cgi?id=11674
commiethebeastie@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |commiethebeastie@gmail.com
--- Comment #327 from commiethebeastie@gmail.com 2013-09-06 00:30:05 CDT --- Test World of Tanks with CSMT:
Wine 1.7.1 vanilla: 15-20FPS
Wine 1.7.1 CSMT on: 25-60 FPS
Radeon 6850, Mesa-9.3-git, linux-3.11.
But sometimes flickers there.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #328 from fengshaun USKLCPEI@gmail.com 2013-09-06 02:44:02 CDT --- I just tested Starcraft 2 and I get 15-20fps with vanilla wine and 35-50 with wine compiled with the new patchset. 35-50 is what I get on Windows, so I think beyond that it's a hardware issue.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #329 from Stefan Dösinger stefan@codeweavers.com 2013-09-06 03:01:30 CDT --- Broken graphics in StarCraft 2 are a known problem. It's a pretty stupid race condition in volume.c, volume_preload. I expect it to affect many, many games.
The other problem is that drivers don't like it if we call GL from multiple threads. To solve this I'll have to finish moving all GL calls to the worker thread.
The third set of work is cleaning up surfaces so we can get rid of the inefficient surface_map implementation that is holding back games like CoD: MW2.
Fixing those things will take a while. I'll proceed merging my volume cleanup patches, and then surface cleanup patches, and post a new patchset when I think I've fixed all the issues you reported.
http://bugs.winehq.org/show_bug.cgi?id=11674
Mike Ellery mellery@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mellery@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #330 from Felix Hellmann privat@cirk2.de 2013-09-06 11:11:20 CDT --- Short test of the CSMT Patches in Borderlands 2: Wine 1.7.1 + CSMT-Patches + __GL_THREADED_OPTIMIZATIONS=1 + CSMT=disabled : 50fps
Wine 1.7.1 + CSMT-Patches + __GL_THREADED_OPTIMIZATIONS=0 + CSMT=enabled : 75fps
and for the fun of it: Wine 1.7.1 + CSMT-Patches + __GL_THREADED_OPTIMIZATIONS=1 + CSMT=enabled : 75-77fps (fps seem to be more unstable)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #331 from Ema ema.oriani@gmail.com 2013-09-07 03:39:51 CDT --- Hi,
I've compiled 1.7.1 with the patch on Ubuntu 12.04.1 (i686 - virtualized), then tested with SC2 on Ubuntu 12.04.3 x86-64. H/W is Intel Core i7-3770k (HT enabled), 32 GB Ram, GTX 680 2GB VRam (nVidia drivers 325.15); screenshots below are taken in 3600x1080, where the game was running in full screen (1920x1080) on primary display and on secondary display one can see the system monitor; I hope this is useful too. SC2 was executed with all graphical details 'EXTREME' and with Ctrl+Alt+F to display FPS.
SC2 Settings: - http://img826.imageshack.us/img826/950/pfc5.jpg
Vanilla: - http://img5.imageshack.us/img5/3281/gt94.jpg - http://img513.imageshack.us/img513/8489/i8a5.jpg
CSMT: - http://img202.imageshack.us/img202/6923/kpta.jpg - http://img9.imageshack.us/img9/9921/0ubh.jpg
As you can see, results are mind-blowing; in one case it goes from 15 --> 53 FPS, in another 8 --> 24 FPS. I did experience the 'white' background issue when enabling CSMT, but I believe Stefan is already aware of it. I am genuinely speechless.
Cheers, Ema
Ps. Funny thing, I still play SC2 with shaders 'LOW', it's a lot cleaner during proper games :-)
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #332 from gpiez@web.de 2013-09-07 13:48:13 CDT --- Testing Word of Warcraft with /timetest taxi test. Hardware has changed in comparison to my earlier banchmarks Nividia GTX 570, i7 2600 @5.0GHz, 32 GByte Ram. Result errors are about +/- 1 fps.
vanilla wine-1.7.1: 45.3 + __GL_THREADED_OPTIMIZATIONS 55.1 + attachment 44420 72.5
wine + cs patches CSMT disabled 6.7 (!) wine + cs patches CSMT enabled 54.4
So clearly an improvement over vanilla wine, roughly equal in performance with Nvidias __GL_THREADED_OPTIMIZATIONS=1, but using glBufferSubData is still a lot faster.
The performance with CSMT disabled is unplayable.
http://bugs.winehq.org/show_bug.cgi?id=11674
Jimmy Garpehäll epaaj89@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |epaaj89@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11674
K1773R K1773R@darkgamex.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |K1773R@darkgamex.ch
http://bugs.winehq.org/show_bug.cgi?id=11674
DL dredgingthelake@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dredgingthelake@gmail.com
--- Comment #333 from DL dredgingthelake@gmail.com 2013-09-25 01:30:58 CDT --- Deus Ex Human Revolution benchmarks:
Vanilla benchmarks:
wine-1.7.1 vanilla = 72 fps (glitches)
wine-1.7.1 vanilla + threaded-opts = 115 fps (glitches)
wine-1.7.1 vanilla + threaded-opts + StrictDrawOrdering = 51 fps
CSMT benchmarks
wine-1.7.1 csmt disabled = 75 fps (glitches)
wine-1.7.1 csmt enabled = 120 fps
wine-1.7.1 csmt disabled + threaded-opts = 115 fps
wine-1.7.1 csmt enabled + threaded-opts = 114 fps
Given that StrictDrawOrdering is required to remove rather bad graphical glitches, the performance improvement from Vanilla to CSMT is 51 to 120 fps or a 235% performance increase. The big gain is from not having to use SDO in this game since threaded-opts alone approaches CSMT performance (115 fps)
As a side note, the older buffer hack gets around the same performance as vanilla + threaded-opts but has the same graphical glitch issues.
In contrast, I did not notice any performance improvements for CSMT with Skyrim although the older buffer hack did result in a 200% performance increase. This was with an older version of wine (1.5.30) so perhaps there has been a regression for Skyrim, though.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #334 from DL dredgingthelake@gmail.com 2013-09-25 08:56:27 CDT --- Just to elaborate on my previous post here is some hardware/software information:
GPU: 660GT CPU: 2500K@4.4Ghz Gentoo ~AMD64
Here are some more benchmarks:
Witcher 1
1.7.1-csmt = 70 FPS 1.7.1-csmt + threaded-opts = 65 FPS 1.7.1-csmt disabled = 29 FPS 1.7.1-csmt disabled + threaded-opts = 29 FPS
1.7.1-vanilla = 40 FPS 1.7.1-vanilla + threaded-opts = 50 FPS
So 1.7.1 with CSMT enabled is the best result at 70 FPS and 1.7.1 with CSMT disabled is the worst at 29 FPS. Nvidia's threaded opts only helps with vanilla wine in this case
Witcher 2
1.7.1-csmt = 43 FPS 1.7.1-csmt + threaded-opts = 38 FPS 1.7.1-csmt disabled = 32 FPS 1.7.1-csmt disabled + threaded-opts = 34 FPS
1.7.1-vanilla = 23 FPS 1.7.1-vanilla + threaded-opts = 24 FPS (glitches)
1.7.1-csmt is the best result again with 43 FPS and vanilla wine is the worst at 23 FPS. Threaded-opts doesn't really help in either case. Interestingly even with CSMT disabled there is some performance increases over vanilla wine.
Some overall very nice increases for both games, especially when just using CSMT alone.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #335 from DL dredgingthelake@gmail.com 2013-09-28 23:36:31 CDT --- A few more notes, probably last post as I'm not sure this is the correct place for it.
-Skyrim does in fact work with the patch it was just an incorrect registry entry. All Gamebryo engine games seem to benefit decently from CSMT.
-The % increases in my previous posts were calculated incorrectly. They are more like 100% or so increases.
-The Witcher has a graphical bug with multi-threaded CSMT enabled; seems that some textures flicker on and off from correct to very bright. Doesn't occur under any other configuration.
Should I be posting bug reports for CSMT, is it that unnecessary until it's in stock Wine?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #336 from Stefan Dösinger stefan@codeweavers.com 2013-09-29 06:11:45 CDT --- Don't post bug reports for CSMT. So far I have plenty of stuff to work on. I'll post a new patchset once I am done with the feedback so far and can process more. This might be within this week, so keep an eye on wine-devel.
http://bugs.winehq.org/show_bug.cgi?id=11674
Josh manwesulimo2004@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |manwesulimo2004@yahoo.co.uk
http://bugs.winehq.org/show_bug.cgi?id=11674
Viktor Basso viktor.basso@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |viktor.basso@gmail.com
--- Comment #337 from Viktor Basso viktor.basso@gmail.com 2013-10-04 15:39:32 CDT --- The CSMT patch is really cool, I can actually play Skyrim now :)
Skyrim Legendary Edition with most on max I am getting around 30+ fps running outside on my GTX 670.
It was only playable on Medium before.
Pic for those who want: http://basso.pw/wp-content/uploads/2013/10/skyrimcsmttest.jpeg
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #338 from fengshaun USKLCPEI@gmail.com 2013-10-16 21:29:11 CDT --- Any updated patchsets/news?
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #339 from commiethebeastie@gmail.com 2013-10-17 00:13:27 CDT --- (In reply to comment #338)
Any updated patchsets/news?
See http://www.winehq.org/pipermail/wine-devel/
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #340 from ae aeforeve@mail.ru 2013-11-05 13:38:15 CST --- http://aewi.ru/rgl/
fix for new wine
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #341 from paolinidiego paolinidiego@gmail.com 2013-11-05 14:17:45 CST --- roboso@roboso-System-Product-Name:~$ LD_PRELOAD=/usr/lib/rgl64.so wine wow/Wow-64.exe --opengl ERROR: ld.so: object '/usr/lib/rgl64.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object '/usr/lib/rgl64.so' from LD_PRELOAD cannot be preloaded: ignored. fixme:dwmapi:DwmIsCompositionEnabled 0x6b2bdb20 fixme:iphlpapi:NotifyAddrChange (Handle 0x103e208, overlapped 0x103e220): stub ERROR: ld.so: object '/usr/lib/rgl64.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object '/usr/lib/rgl64.so' from LD_PRELOAD cannot be preloaded: ignored. Could not load wine-gecko. HTML rendering will be disabled. ERROR: ld.so: object '/usr/lib/rgl64.so' from LD_PRELOAD cannot be preloaded: ignored. wine: configuration in '/home/roboso/.wine' has been updated. fixme:win:EnumDisplayDevicesW ((null),0,0x22e8b0,0x00000000), stub! err:wgl:has_opengl Failed to load libGL: rgl.so: classe ELF errata: ELFCLASS32 err:wgl:has_opengl OpenGL support is disabled.
roboso@roboso-System-Product-Name:~$ LD_PRELOAD=/usr/lib/rgl64.so wine64 wow/Wow-64.exe fixme:win:EnumDisplayDevicesW ((null),0,0x22e8a0,0x00000000), stub! err:wgl:has_opengl Failed to load libGL: rgl.so: classe ELF errata: ELFCLASS32 err:wgl:has_opengl OpenGL support is disabled.
http://bugs.winehq.org/show_bug.cgi?id=11674
ilaria cucciola86@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cucciola86@gmail.com
--- Comment #342 from Dmitriy dim0n-error@narod.ru 2013-11-06 02:03:51 CST --- (In reply to comment #340) Thank you, ae! It's working again.
According to my tests, opengl+rgl a little bit better than CSMT+d3d. The difference is in processing a hard places with many objects. OpenGL+rgl isn't drop below 17 fps on my machine, but CSMT+d3d shows same result with opengl only.
Mode min/ave/max
opengl+rgl 17/40/80 opengl 14/29/64 CSMT+d3d 14/47/83 d3d 9/16/47
--- Comment #343 from ilaria cucciola86@gmail.com 2013-11-06 04:08:39 CST --- sudo cp rgl64.so /usr/lib/
LD_PRELOAD=rgl64.so wine64 wow/Wow-64.exe -opengl fixme:win:EnumDisplayDevicesW ((null),0,0x22e8a0,0x00000000), stub! err:wgl:has_opengl Failed to load libGL: rgl.so: classe ELF errata: ELFCLASS32 err:wgl:has_opengl OpenGL support is disabled. ilaria@ilaria-System-Product-Name:~$ LD_PRELOAD=rgl64.so wine64 wow/Wow-64.exe -opengl fixme:win:EnumDisplayDevicesW ((null),0,0x22e8a0,0x00000000), stub! err:wgl:has_opengl Failed to load libGL: rgl.so: classe ELF errata: ELFCLASS32 err:wgl:has_opengl OpenGL support is disabled.
wine 1.7.1
nvidia 560ti
driver 331.19
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #344 from Dmitriy dim0n-error@narod.ru 2013-11-06 11:51:22 CST --- (In reply to comment #343)
sudo cp rgl64.so /usr/lib/
LD_PRELOAD=rgl64.so wine64 wow/Wow-64.exe -opengl fixme:win:EnumDisplayDevicesW ((null),0,0x22e8a0,0x00000000), stub! err:wgl:has_opengl Failed to load libGL: rgl.so: classe ELF errata: ELFCLASS32 err:wgl:has_opengl OpenGL support is disabled. ilaria@ilaria-System-Product-Name:~$ LD_PRELOAD=rgl64.so wine64 wow/Wow-64.exe -opengl fixme:win:EnumDisplayDevicesW ((null),0,0x22e8a0,0x00000000), stub! err:wgl:has_opengl Failed to load libGL: rgl.so: classe ELF errata: ELFCLASS32 err:wgl:has_opengl OpenGL support is disabled.
wine 1.7.1
nvidia 560ti
driver 331.19
Seems like, rgl library must be named as rgl.so, and not otherwise.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #345 from paolinidiego paolinidiego@gmail.com 2013-11-16 03:38:36 CST --- Created attachment 46544 --> http://bugs.winehq.org/attachment.cgi?id=46544 problema avvio gioco con rgl.so
using rgl.so not always the game starts correctly but stops and does not go further. I put the screen, I hope that it will be useful to improve the script.
http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #346 from Dmitry Timoshkov dmitry@baikal.ru 2013-11-16 04:26:12 CST --- (In reply to comment #345)
Created attachment 46544 [details] problema avvio gioco con rgl.so
using rgl.so not always the game starts correctly but stops and does not go further. I put the screen, I hope that it will be useful to improve the script.
Please find another place for reporting rgl.so bugs, abusing Wine bugzilla should be avoided. Thanks.
http://bugs.winehq.org/show_bug.cgi?id=11674
Brandon Corujo haku08879@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |haku08879@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=11674
Jonas Jelten jonas.jelten@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jonas.jelten@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=11674
Guillaume R guillaumeraffin@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |guillaumeraffin@free.fr
--- Comment #347 from Guillaume R guillaumeraffin@free.fr --- This problem is now fixed in Guild Wars 2. Tested with wine 1.7.38. See bug 31628.
https://bugs.winehq.org/show_bug.cgi?id=11674
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |performance
--- Comment #348 from Ken Sharp imwellcushtymelike@gmail.com --- How about WoW and SC2?
https://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #349 from paolinidiego paolinidiego@gmail.com --- not fixed...
https://bugs.winehq.org/show_bug.cgi?id=11674
gbillios@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|gbillios@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=11674
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |michael@fds-team.de, | |sebastian@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/wined3d-CSMT_M | |ain
https://bugs.winehq.org/show_bug.cgi?id=11674
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|spetreolle@yahoo.fr |
https://bugs.winehq.org/show_bug.cgi?id=11674
tt_1 herrtimson@yahoo.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |herrtimson@yahoo.de
https://bugs.winehq.org/show_bug.cgi?id=11674
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |stefandoesinger@gmx.at
https://bugs.winehq.org/show_bug.cgi?id=11674
AsciiWolf mail@asciiwolf.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@asciiwolf.com
--- Comment #350 from AsciiWolf mail@asciiwolf.com --- Any news?
https://bugs.winehq.org/show_bug.cgi?id=11674
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #351 from winetest@luukku.com --- (In reply to AsciiWolf from comment #350)
Any news?
Some part of the patches have been merged in wine 2.6 since the changelog included
"Multi-threaded command stream in Direct3D."
I just watched wine-staging patches link and the patches list is long. Staging patches most likely need rebasing and I doubt 2.6 wine still includes all the patches staging has. So I am assuming it takes still some time before this bug can be solved as fixed.
https://bugs.winehq.org/show_bug.cgi?id=11674
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|fastumzug@fastmail.fm |
https://bugs.winehq.org/show_bug.cgi?id=11674
Matthew Toseland toad@amphibian.dyndns.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |toad@amphibian.dyndns.org
https://bugs.winehq.org/show_bug.cgi?id=11674
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #352 from Zebediah Figura z.figura12@gmail.com --- Is this still preset in Wine 3.3+?
https://bugs.winehq.org/show_bug.cgi?id=11674
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=11674
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/wined3d-CSMT_M |er/patches/wined3d-CSMT_Mai |ain |n
https://bugs.winehq.org/show_bug.cgi?id=11674
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=11674
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #353 from joaopa jeremielapuree@yahoo.fr --- No news since 4 years. No download available. Can an administrator close this bug as ABANDONNED?
https://bugs.winehq.org/show_bug.cgi?id=11674
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #354 from Stefan Dösinger stefan@codeweavers.com --- Closing the bug is reasonable. The core CSMT work is upstream now. What's missing are asynchronous resource updates and many games are still held back by that. Matteo is working on this. Once this is in place individual bugs should be opened for games / drivers / hardware configurations that still have performance issues.
https://bugs.winehq.org/show_bug.cgi?id=11674
Nicolas Bourdon nicobzz@gmail.Com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nicobzz@gmail.Com
--- Comment #355 from Nicolas Bourdon nicobzz@gmail.Com --- I have the same problem, but I found a way to resolve it I believe:
I start taskmgr.exe in the same wineprefix, and change the affinity of SC2.exe, for that it's only require to right click on SC2.exe in processus tab, then click on define affinity, then remove a cpu to use and add a cpu to use.
It seems to me that by this way SC2 no more lags when there is lot of units.
I also noticed, that when I found the PID of SC2 (for instance using ps -ax on a terminal) and then lauching:
taskset --pid --cpu-list PID_of_SC2
(taskset show what cpu is used by a process) it shows SC2 only work on 1 cpu, (even if the number return is 2, apparently it means it runs on the cpu with the id 2).
By using taskmgr.exe makes SC2 use 2 cpu also in the:
taskset --pid --cpu-list PID_of_SC2
command
https://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #356 from joaopa jeremielapuree@yahoo.fr --- Following S. Dosinger, this bug can be close as FIXED (see comment 354) Can an administrator close this bug as FIXED?
https://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #357 from André H. nerv@dawncrow.de --- well, there's still a staging patch linked, but I'm not sure if it even get's applied on staging releases...
https://bugs.winehq.org/show_bug.cgi?id=11674
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |dd0ea0a61463db83c647a9367ca | |61e2b69a98eb3 Status|STAGED |RESOLVED Resolution|--- |FIXED
--- Comment #358 from Matteo Bruni matteo.mystral@gmail.com --- This bug has been effectively resolved for a long time, by csmt and then the buffer upload acceleration bits.
https://bugs.winehq.org/show_bug.cgi?id=11674
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #359 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 10.0-rc3.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla