February 2014 - Wine-Devel - list.winehq.org

Wine at LinuxTag in Berlin

by Michael Stefaniuc

Hello guys, to follow up to Jeremy's email on doing more Wine "evangelism" the idea quickly came up to do something for LinuxTag which happens from 8th to 10th May in Berlin / Germany http://www.linuxtag.org/2014/en/ . Talks: ------ The deadline for proposals is the 7th February. - I will submit a talk proposal: "Is Wine Still Relevant?" with a a subtitle along the lines of "A Wine status update focusing on current use cases and new exciting developments". Needs more buzzwords, I know ;) - Marcus had other ideas for talks, of course somebody would need to hold them. <_Marcus_> and a Playing Windows games with Wine could be seperate if necessary /& wanted... would surely also be interesting <_Marcus_> and Wine on Android , which I was surprised to have it fill the room ;) <_Marcus_> and a pipelight talk ... that would surely pull folks. - We're open to other talk proposals. Please don't hesitate to reply if you're interested. Booth: ------ - I'm still trying to figure out the deadline for the registration of a booth. - With 3 days this is a significant time investment. - Needs around 3-4 people to man the booth. - We could share a booth with an other project but we will still need at least 2 persons for that, 3 or more is better. - Let me know if somebody is interested in this. bye michael

Feb. 5, 2014

Re: Fixing conflicts between WineD3D and WGL

by Ken Thomases

On Jan 30, 2014, at 6:34 AM, Henri Verbeet wrote: > On 29 January 2014 22:34, Ken Thomases <ken(a)codeweavers.com> wrote: > >> The point of this extension is just for restoring the app's GL context. It would not necessarily be used to make a WineD3D context current, it would only be used to restore the app's WGL context to be current. It doesn't take a DC so that this works even for the case where the original DC was destroyed/released. >> > Right. I was under the impression it would be used by > wined3d_caps_gl_ctx_create() to avoid changing the current WGL DC. If > it's only for restoring the application's GL context, I'm not sure how > that's effectively much different from just making the application's > GL context current on wined3d's DC? (I'd have to look into the details > again, but IIRC that wasn't enough for bug 28869, even as a hack.) Well, it would be different because it wouldn't change the app's GL context to point at a potentially-different drawable. Which, by the way, is actually happening in bug 28869. The app does GL against a top-level window but uses ddraw/wined3d on a child window of that window. So, your hack wouldn't work because it would make the app's GL context current on a window that's destroyed soon after. I was investigating that bug further and discovered that it doesn't actually have anything to do with the DC having been deleted. There's a place in wined3d where it clears the GL context and doesn't save the information necessary to restore the app's GL context. So, it just leaves the app with no current GL context so its GL calls all do nothing. Removing that one call fixes that bug. That bug was the main motivation for this extension. Still, the general principle of being able to restore the GL context even after its DC was destroyed remains. In experimenting with implementing the extension and making wined3d use it, I discovered a complication. At the same point where wined3d attempts to restore the app's GL context, it also tries to restore the pixel format on the app's DC. On the one hand, my extension doesn't help with that which undermines its rationale since the DC is still required. On the other hand, that's the wrong thing for wined3d to try to do there! Wined3d has set the pixel format on its target window (through a DC it obtained itself). In many cases, the app will be targeting the same window with its GL context, but not always (as we've seen). So, wined3d should be trying to restore the pixel format of the window it modified, not the window the app's GL context may be targeting. This is a separate bug that should be fixed. Probably, wined3d should keep track of the window on which it set the pixel format and set that window's pixel format back before returning control. (It can use any DC for that window to do that, even one it obtains just for that purpose.) -Ken

Feb. 5, 2014

Re: [PATCH 3/3] ws2_32: Add an interactive test for interface change notifications (resend).

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4612 Your paranoid android. === wxppro (32 bit sock) === sock.c:557: Test failed: oob_server (af4): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:557: Test failed: oob_server (750): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:557: Test failed: oob_server (750): unexpectedly at the OOB mark: 0

Feb. 5, 2014

Re: Profiling CS:GO

by Brock York

>Quick reply from my phone: wglShareLists on Windows had to be called with neither context being current. I once hacked a workaround >together that created 20 extra contexts in advance with the primary one before making the first context current in one thread Is this why WineD3D can't be used multithreaded under wine in CS:GO? I don't know much about how OpenGL and DirectX let alone their windows counterparts but I'm trying. >One more thing: there are a few issues with the nvidia driver on the command stream. For testing, try to remove vertex buffer objects and >pixel buffer objects from the extension table in directx.c, disable glsl and enable the game's multithreading. That got me pretty decent >performance in cs:s. This is for running and testing WineD3D under windows for testing that I should remove the VBO's and PBO's? Or is this for getting better performance when under wine in linux? Thanks, Regards Brock York. On Wed, Feb 5, 2014 at 5:29 PM, Stefan Dösinger <stefandoesinger(a)gmail.com>wrote: > One more thing: there are a few issues with the nvidia driver on the > command stream. For testing, try to remove vertex buffer objects and pixel > buffer objects from the extension table in directx.c, disable glsl and > enable the game's multithreading. That got me pretty decent performance in > cs:s. > Am 05.02.2014 10:24 schrieb "Stefan Dösinger" <stefandoesinger(a)gmail.com > >: > > Quick reply from my phone: wglShareLists on Windows had to be called with >> neither context being current. I once hacked a workaround together that >> created 20 extra contexts in advance with the primary one before making the >> first context current in one thread >> Am 04.02.2014 17:23 schrieb "Brock York" <twunknown(a)gmail.com>: >> >>> >>> >>> >>> On Mon, Feb 3, 2014 at 10:46 PM, Stefan Dösinger < >>> stefandoesinger(a)gmail.com> wrote: >>> >>> >>>> >> Hey list >>>> >> >>>> >> I'm trying to find out why CS:GO is slower under wine then windows. >>>> >> When running a benchmark in CS:GO Win8 gets ~134fps and wine ~51fps. >>>> >Overall 50% performance is about what you get on average on dual core >>>> machines, depending on the game and driver. The Nvidia binary Linux >driver >>>> gives you roughly 60%, the open source radeon driver approaches 30%-40%. >>>> This depends a lot on the game as well. >>>> >>> >>>> >Did you have a look at my command stream patches? They address a major >>>> shortcoming in wined3d - it adds the ability to move major parts >of the >>>> CPU side work (The OpenGL calls) into a different thread. Windows had this >>>> since many years, and my (not yet upstream) work adds >it to Wine. I >>>> recommend to search the Wine-devel archives, I've written a lengthy mail >>>> about it somewhen in January. The single-threaded >nature of WineD3D is >>>> most likely where your 50% CPU usage (Dual Core?) comes from. >>>> >>> >>> I hadn't heard of your command stream patches so I found the emails you >>> were talking about, cloned your repository and tested it today. It does >>> help but I haven't got any solid numbers yet. But this is what i've got so >>> far: >>> https://docs.google.com/spreadsheet/ccc?key=0AmPNQYtpuejodDVQc2ctc084cjVISE… >>> >>> I should have mentioned that I'm running this on a quad core (Intel Core >>> 2 Quad Q6600) and was getting 50% accross all four cores compared to >>> windows 65-75% accross the four cores. The interesting thing being that so >>> far in my single test. WineD3d with multicore disabled is faster then >>> windows with WineD3d multicore disabled. >>> >>> >> I've been following Stefan Dösingers guide ( >>>> http://wiki.winehq.org/Performance) and have >>>> >>> >> compiled wined3d for windows and tryed running CS:GO using wined3d >>>> under win8 but it just crashes while loading the map. At a guess I'd >>say >>>> once it trys to do 3D rendering. >>>> >Did you define USE_WIN32_OPENGL? It is needed to adjust the calling >>>> convention to Win32's WINAPI convention. I think it is explained in >the >>>> Wiki article, but I cannot check at the moment because I am drafting this >>>> mail in an airplane. >>>> >>>> I followed this guide (http://wiki.winehq.org/WineD3DOnWindows) so I >>> did use USE_WIN32_OPENGL. I found out what the problem was. I was able to >>> use WineD3D with Counter-Strike source but not CS:GO on windows. Turns out >>> if the multicore option is enabled so it uses more then one thread then >>> CS:GO and CS:S will crash when using WineD3D under windows. >>> >>> I also compiled WineD3d with your command stream patches and ran them >>> under windows once I figured out it was the multicore option causing the >>> crashes. >>> >>> Which now I have no idea how to debug why it crashes when it is using >>> multiple threads. >>> >>> Thanks for your time and your reply. >>> Regards Brock YOrk. >>> >>>

Feb. 5, 2014

Re: [PATCH] shell32/tests: Remove some assertions in test code

by Nikolay Sivov

On 2/5/2014 15:09, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://newtestbot.winehq.org/JobDetails.pl?Key=4602 > > Your paranoid android. > > > === wxppro (32 bit shlexec) === > shlexec.c:1204: Test failed: expected 1 args, got 4 > shlexec.c:2247: Test failed: argcA expected 5, but got 4 > > === w2008s64 (32 bit shlexec) === > shlexec.c:1545: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt28F.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt28F.tmp\test file.shlexec' > shlexec.c:2623: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt28F.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt28F.tmp\test2.exe' > shlexec.c:2636: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt28F.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt28F.tmp\test2.exe' > shlexec.c:2648: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt28F.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt28F.tmp\test2.exe' > > === w2008s64 (64 bit shlexec) === > shlexec.c:1545: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt176.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt176.tmp\test file.shlexec' > shlexec.c:2623: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt176.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt176.tmp\test2.exe' > shlexec.c:2636: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt176.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt176.tmp\test2.exe' > shlexec.c:2648: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt176.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt176.tmp\test2.exe' I don't think this has anything to do with my patch. Looks like some short/long path comparison, I'll try to fix some assertions first and then we'll see what happens to test results.

Feb. 5, 2014

Re: [PATCH] shell32/tests: Remove some assertions in test code

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4602 Your paranoid android. === wxppro (32 bit shlexec) === shlexec.c:1204: Test failed: expected 1 args, got 4 shlexec.c:2247: Test failed: argcA expected 5, but got 4 === w2008s64 (32 bit shlexec) === shlexec.c:1545: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt28F.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt28F.tmp\test file.shlexec' shlexec.c:2623: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt28F.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt28F.tmp\test2.exe' shlexec.c:2636: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt28F.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt28F.tmp\test2.exe' shlexec.c:2648: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt28F.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt28F.tmp\test2.exe' === w2008s64 (64 bit shlexec) === shlexec.c:1545: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt176.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt176.tmp\test file.shlexec' shlexec.c:2623: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt176.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt176.tmp\test2.exe' shlexec.c:2636: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt176.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt176.tmp\test2.exe' shlexec.c:2648: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt176.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt176.tmp\test2.exe'

Feb. 5, 2014

Re: Profiling CS:GO

by Stefan Dösinger

One more thing: there are a few issues with the nvidia driver on the command stream. For testing, try to remove vertex buffer objects and pixel buffer objects from the extension table in directx.c, disable glsl and enable the game's multithreading. That got me pretty decent performance in cs:s. Am 05.02.2014 10:24 schrieb "Stefan Dösinger" <stefandoesinger(a)gmail.com>: > Quick reply from my phone: wglShareLists on Windows had to be called with > neither context being current. I once hacked a workaround together that > created 20 extra contexts in advance with the primary one before making the > first context current in one thread > Am 04.02.2014 17:23 schrieb "Brock York" <twunknown(a)gmail.com>: > >> >> >> >> On Mon, Feb 3, 2014 at 10:46 PM, Stefan Dösinger < >> stefandoesinger(a)gmail.com> wrote: >> >> >>> >> Hey list >>> >> >>> >> I'm trying to find out why CS:GO is slower under wine then windows. >>> >> When running a benchmark in CS:GO Win8 gets ~134fps and wine ~51fps. >>> >Overall 50% performance is about what you get on average on dual core >>> machines, depending on the game and driver. The Nvidia binary Linux >driver >>> gives you roughly 60%, the open source radeon driver approaches 30%-40%. >>> This depends a lot on the game as well. >>> >> >>> >Did you have a look at my command stream patches? They address a major >>> shortcoming in wined3d - it adds the ability to move major parts >of the >>> CPU side work (The OpenGL calls) into a different thread. Windows had this >>> since many years, and my (not yet upstream) work adds >it to Wine. I >>> recommend to search the Wine-devel archives, I’ve written a lengthy mail >>> about it somewhen in January. The single-threaded >nature of WineD3D is >>> most likely where your 50% CPU usage (Dual Core?) comes from. >>> >> >> I hadn't heard of your command stream patches so I found the emails you >> were talking about, cloned your repository and tested it today. It does >> help but I haven't got any solid numbers yet. But this is what i've got so >> far: >> https://docs.google.com/spreadsheet/ccc?key=0AmPNQYtpuejodDVQc2ctc084cjVISE… >> >> I should have mentioned that I'm running this on a quad core (Intel Core >> 2 Quad Q6600) and was getting 50% accross all four cores compared to >> windows 65-75% accross the four cores. The interesting thing being that so >> far in my single test. WineD3d with multicore disabled is faster then >> windows with WineD3d multicore disabled. >> >> >> I've been following Stefan Dösingers guide ( >>> http://wiki.winehq.org/Performance) and have >>> >> >> compiled wined3d for windows and tryed running CS:GO using wined3d >>> under win8 but it just crashes while loading the map. At a guess I'd >>say >>> once it trys to do 3D rendering. >>> >Did you define USE_WIN32_OPENGL? It is needed to adjust the calling >>> convention to Win32’s WINAPI convention. I think it is explained in >the >>> Wiki article, but I cannot check at the moment because I am drafting this >>> mail in an airplane. >>> >>> I followed this guide (http://wiki.winehq.org/WineD3DOnWindows) so I >> did use USE_WIN32_OPENGL. I found out what the problem was. I was able to >> use WineD3D with Counter-Strike source but not CS:GO on windows. Turns out >> if the multicore option is enabled so it uses more then one thread then >> CS:GO and CS:S will crash when using WineD3D under windows. >> >> I also compiled WineD3d with your command stream patches and ran them >> under windows once I figured out it was the multicore option causing the >> crashes. >> >> Which now I have no idea how to debug why it crashes when it is using >> multiple threads. >> >> Thanks for your time and your reply. >> Regards Brock YOrk. >> >>

Feb. 5, 2014

Re: Profiling CS:GO

by Stefan Dösinger

Quick reply from my phone: wglShareLists on Windows had to be called with neither context being current. I once hacked a workaround together that created 20 extra contexts in advance with the primary one before making the first context current in one thread Am 04.02.2014 17:23 schrieb "Brock York" <twunknown(a)gmail.com>: > > > > On Mon, Feb 3, 2014 at 10:46 PM, Stefan Dösinger < > stefandoesinger(a)gmail.com> wrote: > > >> >> Hey list >> >> >> >> I'm trying to find out why CS:GO is slower under wine then windows. >> >> When running a benchmark in CS:GO Win8 gets ~134fps and wine ~51fps. >> >Overall 50% performance is about what you get on average on dual core >> machines, depending on the game and driver. The Nvidia binary Linux >driver >> gives you roughly 60%, the open source radeon driver approaches 30%-40%. >> This depends a lot on the game as well. >> > >> >Did you have a look at my command stream patches? They address a major >> shortcoming in wined3d - it adds the ability to move major parts >of the >> CPU side work (The OpenGL calls) into a different thread. Windows had this >> since many years, and my (not yet upstream) work adds >it to Wine. I >> recommend to search the Wine-devel archives, I’ve written a lengthy mail >> about it somewhen in January. The single-threaded >nature of WineD3D is >> most likely where your 50% CPU usage (Dual Core?) comes from. >> > > I hadn't heard of your command stream patches so I found the emails you > were talking about, cloned your repository and tested it today. It does > help but I haven't got any solid numbers yet. But this is what i've got so > far: > https://docs.google.com/spreadsheet/ccc?key=0AmPNQYtpuejodDVQc2ctc084cjVISE… > > I should have mentioned that I'm running this on a quad core (Intel Core 2 > Quad Q6600) and was getting 50% accross all four cores compared to windows > 65-75% accross the four cores. The interesting thing being that so far in > my single test. WineD3d with multicore disabled is faster then windows with > WineD3d multicore disabled. > > >> I've been following Stefan Dösingers guide ( >> http://wiki.winehq.org/Performance) and have >> > >> compiled wined3d for windows and tryed running CS:GO using wined3d >> under win8 but it just crashes while loading the map. At a guess I'd >>say >> once it trys to do 3D rendering. >> >Did you define USE_WIN32_OPENGL? It is needed to adjust the calling >> convention to Win32’s WINAPI convention. I think it is explained in >the >> Wiki article, but I cannot check at the moment because I am drafting this >> mail in an airplane. >> >> I followed this guide (http://wiki.winehq.org/WineD3DOnWindows) so I did > use USE_WIN32_OPENGL. I found out what the problem was. I was able to use > WineD3D with Counter-Strike source but not CS:GO on windows. Turns out if > the multicore option is enabled so it uses more then one thread then CS:GO > and CS:S will crash when using WineD3D under windows. > > I also compiled WineD3d with your command stream patches and ran them > under windows once I figured out it was the multicore option causing the > crashes. > > Which now I have no idea how to debug why it crashes when it is using > multiple threads. > > Thanks for your time and your reply. > Regards Brock YOrk. > >

Feb. 5, 2014

Re: Temporary Directories

by Stefan Dösinger

I have my temporary stuff (global and user) in Z:\\tmp, which is shmfs, and never had any issue with this. Am 05.02.2014 06:40 schrieb "Vincent Povirk" <madewokherd(a)gmail.com>: > I'm not sure it would be accurate to report any of Wine's directories > as temporary, since they are not really volatile storage on Windows. > Rumor has it that some apps rely on their "temporary" files being > preserved across reboots. > > For Time Machine, this would mean that the files wouldn't be restored, > and some apps could be broken by a backup/restore. > > >

Feb. 5, 2014

Re: server: Fix generic access mapping for a thread.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4597 Your paranoid android. === wvista (32 bit security) === security.c:4990: Test failed: 4: expected 0x1f03ff, got 0x1fffff === w2008s64 (32 bit security) === security.c:4990: Test failed: 4: expected 0x1f03ff, got 0x1fffff === w7pro64 (32 bit security) === security.c:4990: Test failed: 4: expected 0x1f03ff, got 0x1fffff === w2008s64 (64 bit security) === security.c:4990: Test failed: 4: expected 0x1f03ff, got 0x1fffff === w7pro64 (64 bit security) === security.c:4990: Test failed: 4: expected 0x1f03ff, got 0x1fffff

Feb. 5, 2014