April 2011 - Wine-Devel - list.winehq.org

Re: ddraw: Fix filtering of enumerated display modes by bits per pixel

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 http://testbot.winehq.org/JobDetails.pl?Key=10648 Your paranoid android. === WNT4WSSP6 (32 bit ddrawmodes) === ddrawmodes.c:520: Test failed: EnumDisplayModes returned: 80070057 === W7PROX64 (64 bit ddrawmodes) === Timeout

April 30, 2011

Re: D3D performance debugging report

by Stefan Dösinger

On Saturday 30 April 2011 17:18:54 Stefan Dösinger wrote: > 9-11) Distributor / End use choice. Note that some compiler > flags(especially the framepointer one) can break apps and copy protection > systems. Forget about -O3. I can't get any Windows game working with that. Apparently I am already lucky that I can get winecfg up.

April 30, 2011

Re: D3D performance debugging report

by Emanuele Oriani

Hi Stefan, What do you think about using inline spinlocks (in asm code maybe) to implement locks? Clearly an optimized spinlock would mean different code for different compilers/architectures, but shouldn't it be the best solution? For your reference, once I commented out the GL locks to see StarCraft 2 performance, but it crashed straight away. What do you reckon? Cheers, P.s Keep up with this fantastic work! :-) On 30/04/11 16:18, Stefan Dösinger wrote: > Hi, > Here's another update. > > First I expanded my performance tests at https://84.112.174.163/~git/perftest > a bit. The old tests were renamned to streamsrc_d3d and streamsrc_gl, and I > added another set of tests that just tests the draw overhead without ever > changing any states: drawprim_d3d and drawprim_gl. Here are the performance > results from Windows 7: > > drawprim_gl: ~1154 fps > drawprim_d3d: ~1160 fps > > In Wine the D3D version gets 165.67fps fps. The Linux native GL version gets > 1791 fps. The GL windows version in Wine gets about 600 fps(FIXME!). Don't > worry too much about the GL performance, this is mostly locking overhead. More > about that later. > > I ran my usual d3d performance hacks through the d3d version. The hacks are > pretty much the same as with the stremsrc test, except that I don't need the > redundant vertex shader apply hacks. I attached a tarball with the hacks and a > file listing their performance impact. > > The plan forward is still the same: Write more of those tests(especially tests > that test non-draw stuff like resource loads), improve the tests and hope that > real apps profit. > > The optimistic scenario is that this works out. So far we've seen slow > movementin real apps with the two fixes we've made(context_validate and FBO > application, the latter isn't in Wine yet). This is expected to a certain > extend, because the performance is reversely proportional to the number of > performance bugs we have. So we'll have to remove a lot of them before we see > big movement. > > The pessimistic scenario is that those tests have nothing in common with the > performance bugs in real apps and the fixes only end up making the code more > complex. > > To that end I think I'll create a github repo where I try to get the hacks > into a somewhat usable state - not commitable to wine, but good enough that > they don't break apps, so they can be tested against real world apps. That way > we can find out how much they really improve real games without clogging our > codebase without certainty that the changes help. > > Here are again some descriptions of the hacks I tested: > > 2) End-user business, fairly harmless. Should always be used if performance is > important > > 3, 4) Will break stuff. Can be fixed, but would be rather ugly. Probably > interesting once we run out of easier fixes > > 5) Could go into Wine sooner or later. Does improve real games on its own > already > > 6) Easy to clean up, I'll send a patch today. we can skip validation if FIXMEs > are off since nobody will see them. > > 7) I tried to find out if removing one call level helps, but it doesn't even > improve this locking overhead sensitive test app. Forget about it > > 8) Doable, but pretty uninteresting. I doubt we'll get a noticeable > improvement in a real app > > 9-11) Distributor / End use choice. Note that some compiler flags(especially > the framepointer one) can break apps and copy protection systems. > > 12) Distributor / End user choice too, but harmless. Not much gain compared to > WINEDEBUG=-all though > > 13) Doesn't improve performance a whole lot once debug msgs are compiled out. > > 14) We should be able to limit calls to this functions to cases where the > textures were changed or vertex texture fetch is used. We may be able to > eliminate it entirely when we have enough samplers available > > 15, 16) I caution against too much optimism here. We won't be able to get rid > of the locking anytime soon. Maybe the EnterCriticalSection / > LeaveCriticalSection performance can be improved. A part of the problem is > call overhead, but I think the biggest issue are the locked increment and > decrement operations in RtlEnterCriticalSection / RtlLeaveCriticalSection. > Orig performance: 178 fps > Interlocked ops replaced with normal inc/dec: 244 fps > Lock calls removed from wined3d: 293 fps > (this is just to give you some idea where the time is spent) > > 17) Forget about this one until we run out of other optimizations > > 18) It's interesting how much this gives without all the other optimizations. > My app doesn't use any textures, so this is just the call overhead and loping > over the fragment samplers. > > 19) My app renders to a too small window, so swapchain render_to_fbo triggers. > It's interesting that getting rid of it makes performance worse > > 21) Removing that and other checks in drawPrimitive() barely speeds up the > test. I got a total of 7-8 fps out of the compatibility or error checks in > drawPrimitive, this won't show up in any real app. > > Stefan > > >

April 30, 2011

Re: D3D performance debugging report

by Stefan Dösinger

Hi, Here's another update. First I expanded my performance tests at https://84.112.174.163/~git/perftest a bit. The old tests were renamned to streamsrc_d3d and streamsrc_gl, and I added another set of tests that just tests the draw overhead without ever changing any states: drawprim_d3d and drawprim_gl. Here are the performance results from Windows 7: drawprim_gl: ~1154 fps drawprim_d3d: ~1160 fps In Wine the D3D version gets 165.67fps fps. The Linux native GL version gets 1791 fps. The GL windows version in Wine gets about 600 fps(FIXME!). Don't worry too much about the GL performance, this is mostly locking overhead. More about that later. I ran my usual d3d performance hacks through the d3d version. The hacks are pretty much the same as with the stremsrc test, except that I don't need the redundant vertex shader apply hacks. I attached a tarball with the hacks and a file listing their performance impact. The plan forward is still the same: Write more of those tests(especially tests that test non-draw stuff like resource loads), improve the tests and hope that real apps profit. The optimistic scenario is that this works out. So far we've seen slow movementin real apps with the two fixes we've made(context_validate and FBO application, the latter isn't in Wine yet). This is expected to a certain extend, because the performance is reversely proportional to the number of performance bugs we have. So we'll have to remove a lot of them before we see big movement. The pessimistic scenario is that those tests have nothing in common with the performance bugs in real apps and the fixes only end up making the code more complex. To that end I think I'll create a github repo where I try to get the hacks into a somewhat usable state - not commitable to wine, but good enough that they don't break apps, so they can be tested against real world apps. That way we can find out how much they really improve real games without clogging our codebase without certainty that the changes help. Here are again some descriptions of the hacks I tested: 2) End-user business, fairly harmless. Should always be used if performance is important 3, 4) Will break stuff. Can be fixed, but would be rather ugly. Probably interesting once we run out of easier fixes 5) Could go into Wine sooner or later. Does improve real games on its own already 6) Easy to clean up, I'll send a patch today. we can skip validation if FIXMEs are off since nobody will see them. 7) I tried to find out if removing one call level helps, but it doesn't even improve this locking overhead sensitive test app. Forget about it 8) Doable, but pretty uninteresting. I doubt we'll get a noticeable improvement in a real app 9-11) Distributor / End use choice. Note that some compiler flags(especially the framepointer one) can break apps and copy protection systems. 12) Distributor / End user choice too, but harmless. Not much gain compared to WINEDEBUG=-all though 13) Doesn't improve performance a whole lot once debug msgs are compiled out. 14) We should be able to limit calls to this functions to cases where the textures were changed or vertex texture fetch is used. We may be able to eliminate it entirely when we have enough samplers available 15, 16) I caution against too much optimism here. We won't be able to get rid of the locking anytime soon. Maybe the EnterCriticalSection / LeaveCriticalSection performance can be improved. A part of the problem is call overhead, but I think the biggest issue are the locked increment and decrement operations in RtlEnterCriticalSection / RtlLeaveCriticalSection. Orig performance: 178 fps Interlocked ops replaced with normal inc/dec: 244 fps Lock calls removed from wined3d: 293 fps (this is just to give you some idea where the time is spent) 17) Forget about this one until we run out of other optimizations 18) It's interesting how much this gives without all the other optimizations. My app doesn't use any textures, so this is just the call overhead and loping over the fragment samplers. 19) My app renders to a too small window, so swapchain render_to_fbo triggers. It's interesting that getting rid of it makes performance worse 21) Removing that and other checks in drawPrimitive() barely speeds up the test. I got a total of 7-8 fps out of the compatibility or error checks in drawPrimitive, this won't show up in any real app. Stefan

April 30, 2011

re: comctl32: realloc or free and alloc

by Dan Kegel

Alexey wrote: > i currently digg in comctl32 to find why my app fails. I found that > string conversation AtoW in some places silently fails. The problem is > that the destination for string is just a fresh pointer (not NULL). > Str_SetPtrAtoW check if it is NULL pointer and if not it trys to > ReAlloc. There was no Alloc before so ReAlloc returns NULL The code looks like it assumes that pointer is always managed by Alloc/ReAlloc/Free. In what context is the destination a fresh, non-Alloc'd pointer? Perhaps that's where the bug lies. Your proposed solution would pass a non-Alloc'd pointer to Free, which doesn't seem good. - Dan

April 30, 2011

Re: [Bug 26975] configure can't find OSSv4 (both Wine and OSSv4 is current from git and mercurial respectively)

by Brock York

Interestingly enough I just had this error and it was solved by sudo apt-get install oss4-base oss4-dev

April 30, 2011

Re: gecko and native msvcrt

by Jacek Caban

On 4/30/11 3:05 PM, Eric Pouech wrote: > Le 30/04/2011 12:15, Jacek Caban a écrit : >> On 4/29/11 11:58 PM, Eric Pouech wrote: >>> Le 29/04/2011 23:07, Dan Kegel a écrit : >>>> While testing a game with current gecko, I saw the error >>>> >>>> wine: Call from 0x7bc4ad90 to unimplemented function >>>> msvcrt.dll._snwprintf_s, >>>> aborting >>>> >>>> The game needed a native msvcrt, so I had installed one with >>>> winetricks, >>>> and it didn't export that function. >>>> >>>> So it seems that new gecko is incompatible with old msvcrt, >>>> and using native msvcrt as a workaround for bugs in wine's >>>> version is going to be harder than it used to be. >>>> >>>> Time to fix more of them msvcrt bugs, I guess... >>>> And/or find a more up to date msvcrt.dll for winetricks. >>>> >>>> >>>> >>> or link gecko against msvcr80 or msvcr90 instead of msvcrt >> >> It's harder than it seems, esp. because it's not well supported by >> mingw-w64. Also even if we did it, Wine would still forward these >> calls to msvcrt, so one would need another native DLL. Given that, we >> need more serious reason for the change than supporting hackish >> winetricks verb. Fixing our msvcrt implementation is the way to go IMO. > I don't agree on your last point > in native msvcrt, there is none _snwprintf_s function (it only exists > in msvcrN where N>=8 (didn't really check all versions)) > _snwprintf_s is implemented in our msvcrN (which forwards them to msvcrt) > the point here is that one tries to run gecko with native msvcrt which > doesn't contain this function > so if gecko needs it, it shouldn't link to msvcrt but to msvcrN is we > want to maintain compat with native DLLs I've checked my Win7 msvcrt.dll version and it exports _snwprintf_s (that's why Dan mentioned finding more up to date msvcrt.dll as an alternative solution). My point of fixing msvcrt was not related to _snwprintf_s, I was talking about the reason someone wants to use msvcrt in the first place (it's an app that requires it due to other bug, not Gecko). We use mingw-w64 msvcrt import library which doesn't contain Wine extensions to msvcrt.dll, so we're safe from accidentally using Wine-only APIs. BTW, mingw-w64 contains limited support for some msvcrN dlls-only function in its crt (we link it statically), which was enough for our needs so far. Jacek

April 30, 2011

Re: gecko and native msvcrt

by Eric Pouech

Le 30/04/2011 12:15, Jacek Caban a écrit : > On 4/29/11 11:58 PM, Eric Pouech wrote: >> Le 29/04/2011 23:07, Dan Kegel a écrit : >>> While testing a game with current gecko, I saw the error >>> >>> wine: Call from 0x7bc4ad90 to unimplemented function >>> msvcrt.dll._snwprintf_s, >>> aborting >>> >>> The game needed a native msvcrt, so I had installed one with >>> winetricks, >>> and it didn't export that function. >>> >>> So it seems that new gecko is incompatible with old msvcrt, >>> and using native msvcrt as a workaround for bugs in wine's >>> version is going to be harder than it used to be. >>> >>> Time to fix more of them msvcrt bugs, I guess... >>> And/or find a more up to date msvcrt.dll for winetricks. >>> >>> >>> >> or link gecko against msvcr80 or msvcr90 instead of msvcrt > > It's harder than it seems, esp. because it's not well supported by > mingw-w64. Also even if we did it, Wine would still forward these > calls to msvcrt, so one would need another native DLL. Given that, we > need more serious reason for the change than supporting hackish > winetricks verb. Fixing our msvcrt implementation is the way to go IMO. I don't agree on your last point in native msvcrt, there is none _snwprintf_s function (it only exists in msvcrN where N>=8 (didn't really check all versions)) _snwprintf_s is implemented in our msvcrN (which forwards them to msvcrt) the point here is that one tries to run gecko with native msvcrt which doesn't contain this function so if gecko needs it, it shouldn't link to msvcrt but to msvcrN is we want to maintain compat with native DLLs A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 30, 2011

Re: [PATCH] dinput: Mark internal symbols as hidden

by Marcus Meissner

On Sat, Apr 30, 2011 at 12:48:49PM +0200, Stefan Dösinger wrote: > On Saturday 30 April 2011 12:31:28 Marcus Meissner wrote: > > As distribution packager I wonder if I should build without debug or not. > > A special package (wine-nodebug)? > > Or just leave out TRACE() messages? > Is there a configure option for disabling debugging? I couldn't find any when I > was looking for one and edited a header file manually Quick look, short of CPPFLAGS="-DWINE_NO_TRACE_MSGS -DWINE_NO_DEBUG_MSGS" ...CFLAGS... ./configure ... Apparently not. Ciao, Marcus

April 30, 2011

Re: [PATCH] dinput: Mark internal symbols as hidden

by Stefan Dösinger

On Saturday 30 April 2011 12:31:28 Marcus Meissner wrote: > As distribution packager I wonder if I should build without debug or not. > A special package (wine-nodebug)? > Or just leave out TRACE() messages? Is there a configure option for disabling debugging? I couldn't find any when I was looking for one and edited a header file manually

April 30, 2011