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

Re: [2/2] comctl32/mru: Ignore size field when creating with -W calls

by Nikolay Sivov

On 5/2/2011 14:45, Alexandre Julliard wrote: > Nikolay Sivov<nsivov(a)codeweavers.com> writes: > >> @@ -210,11 +210,11 @@ typedef INT (CALLBACK *MRUStringCmpFnA)(LPCSTR lhs, LPCSTR rhs); >> typedef INT (CALLBACK *MRUStringCmpFnW)(LPCWSTR lhs, LPCWSTR rhs); >> typedef INT (CALLBACK *MRUBinaryCmpFn)(LPCVOID lhs, LPCVOID rhs, DWORD length); >> >> -typedef struct tagCREATEMRULISTA >> +typedef struct tagMRUINFOA >> { >> DWORD cbSize; >> - DWORD nMaxItems; >> - DWORD dwFlags; >> + UINT uMax; >> + UINT fFlags; >> HKEY hKey; >> LPSTR lpszSubKey; >> union > Please do the renamings as a separate patch. Done.

May 2, 2011

Re: D3D performance debugging report

by Henri Verbeet

On 2 May 2011 13:20, Emanuele Oriani <emaentra(a)ngi.it> wrote: > Hi, let me agree with you... probably there might be one or two fixes > somewhere which will make performance go better, but apparently the idea is > that now, if "early optimization is the root of all evils" was true a while > a go, I guess we're at a place where all the small optimizations should take > place. There's a difference between "early" and "premature", but I guess it's subtle. I don't agree with the concept of "Anything goes as long as it improves performance for someone, somewhere." > For example, the main issue with SC2 is that if you don't set the affinity > of all threads to one core, the game will go slower by 40%; for this reason > I think this game suffers of other issues related to other wine components > (than D3D) and/or Linux scheduler. > The main issue with SC2 is that setting different shaders level will heavily > impact the game; and I'm running on a 470 GTX: this shouldn't be the case. > Should we probably looking into the way we generate shaders (both GLSlang > and ARB ones)? > Another point, what about how we handle offscreen buffers? All FBO etc etc? > Most of it really does come down to careful debugging / benchmarking, I'm afraid. There's plenty of speculation, but at some point someone just has to do the actual work. > If I remember correctly someone was working on a worker thread for D3D. Did > we abandon tis project? Not as such, but to my knowledge nobody is currently actively working on that. This is also one of those things that's a lot harder than it looks.

May 2, 2011

Re: [PATCH 2/2] wined3d: Turn off message filtering temporarily in the Reset() method to allow certain messages (e.g. WM_ACTIVATEAPP) through.

by Henri Verbeet

On 2 May 2011 13:18, John Edmonds <pocketcookies2(a)gmail.com> wrote: > Toki Tori and RUSH both depend on receing WM_ACTIVATEAPP before they will start. These messages are currently getting filtered out. > This resolves bug #25640. It doesn't look right to me to filter messages during IWineD3DDevice_ReleaseFocusWindow() but not IWineD3DDevice_AcquireFocusWindow(). Maybe it just shouldn't filter at all.

May 2, 2011

Re: [PATCH 1/2] d3d9/tests: Added a test for resetting an invisible, inactive window to fullscreen mode.

by Henri Verbeet

On 2 May 2011 13:18, John Edmonds <pocketcookies2(a)gmail.com> wrote: > + /*Pull all currently available messages. We don't care about messages generated after this loop exits.*/ > + while(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) > + { > + TranslateMessage(&msg); > + DispatchMessage(&msg); > + } You should probably use flush_events() for that.

May 2, 2011

Re: [PATCH 2/2] wined3d: Turn off message filtering temporarily in the Reset() method to allow certain messages (e.g. WM_ACT

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=10678 Your paranoid android. === WXPPROSP3 (32 bit device) === device: unhandled exception c0000005 at 0040320F === W2K3R2SESP2 (32 bit device) === device: unhandled exception c0000005 at 0040320F === WVISTAADM (32 bit device) === device: unhandled exception c0000005 at 0040320F === W2K8SE (32 bit device) === device: unhandled exception c0000005 at 0040320F === W7PRO (32 bit device) === device: unhandled exception c0000005 at 0040320F === W7PROX64 (32 bit device) === device: unhandled exception c0000005 at 0040320F === W7PROX64 (64 bit device) === Timeout

May 2, 2011

Re: [PATCH 1/2] d3d9/tests: Added a test for resetting an invisible, inactive window to fullscreen mode.

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=10677 Your paranoid android. === WXPPROSP3 (32 bit device) === device: unhandled exception c0000005 at 0040320F === W2K3R2SESP2 (32 bit device) === device: unhandled exception c0000005 at 0040320F === WVISTAADM (32 bit device) === device: unhandled exception c0000005 at 0040320F === W2K8SE (32 bit device) === device: unhandled exception c0000005 at 0040320F === W7PRO (32 bit device) === device: unhandled exception c0000005 at 0040320F === W7PROX64 (32 bit device) === device: unhandled exception c0000005 at 0040320F === W7PROX64 (64 bit device) === Timeout

May 2, 2011

Re: D3D performance debugging report

by Emanuele Oriani

Hi, let me agree with you... probably there might be one or two fixes somewhere which will make performance go better, but apparently the idea is that now, if "early optimization is the root of all evils" was true a while a go, I guess we're at a place where all the small optimizations should take place. To confirm, SC2 performance difference without the D3D lock and the x11 spinlock, compared to current wine (1.3.19) is basically not noticeable. On top of this, be aware that apparently the D3D lock IS recursive (when using the non recursive spinlock a CPU was going 100% and application was stuck). For example, the main issue with SC2 is that if you don't set the affinity of all threads to one core, the game will go slower by 40%; for this reason I think this game suffers of other issues related to other wine components (than D3D) and/or Linux scheduler. The main issue with SC2 is that setting different shaders level will heavily impact the game; and I'm running on a 470 GTX: this shouldn't be the case. Should we probably looking into the way we generate shaders (both GLSlang and ARB ones)? Another point, what about how we handle offscreen buffers? All FBO etc etc? If I remember correctly someone was working on a worker thread for D3D. Did we abandon tis project? Given OpenGL doesn't (didn't?) support calls from multiple threads, should we be proceeding through this route? Cheers, On 01/05/11 15:10, Stefan Dösinger wrote: > On Sunday 01 May 2011 14:34:53 Emanuele Oriani wrote: >> Indeed, I've written a spinlock with GCC extension and replaced the >> EnterCriticalSection in the x11 drv file. >> Apart that the lock has got to be recursive, so I implemented a quick >> (but incorrect) recursive spinlock for the purpose of running SC2 and >> difference was barely negligible. > How much was the difference? > >> The biggest issue imho is that in this case we have to call a >> function... > I don't think so. I did some tests for the call overhead, and it is fairly > small. Specifically I tried to export the wined3d lock from wined3d and call > EnterCriticalSection / LeaveCritSection directly from d3d9. The difference > wasn't even measurable with my hyper-sensitive self-written test apps. > >> I can try a spinlock for the BKL-like which is wined3d lock. I hope this >> hasn't got to be recursive, right? >> I'm asking this because in case of a recursive lock I'm performing an >> extra syscall: > The wined3d lock doesn't have to be recursive I think. But note that getting > those changes committed into Wine are next to zero. It's more likely to get an > optimization of EnterCriticalSection / LeaveCriticalSection itself into wine. > >> Please keep in mind this is a test code, but apparently it's working. >> Again, performance in case of SC2 isn't that much... but probably should >> test better/with other games? > No, as I explained in my mail the individual optimizations don't magically fix > all the performance woes we have. We'll probably have to collect a dozen or > more such little fixes to start seeing movement. >

May 2, 2011

Re: wininet: Use test.winehq.org for post tests

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=10676 Your paranoid android. === WVISTAADM (32 bit http) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

May 2, 2011

Re: [PATCH 1/5] mmdevapi: Add InitializeDriver() method to drivers

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > Wine is already plagued by deadlocks in the MM drivers initialization that > interfere with the loader's lock. Explicit initialization after LoadLibrary > returns should help getting rid of these. Considering that the MM drivers don't implement DLL_PROCESS_ATTACH at all at the moment, I don't think avoiding it is going to fix anything... -- Alexandre Julliard julliard(a)winehq.org

May 2, 2011

Re: [PATCH 1/5] mmdevapi: Add InitializeDriver() method to drivers

by Paul Chitescu

On Monday 02 May 2011 01:32:59 pm Alexandre Julliard wrote: > Andrew Eikum <aeikum(a)codeweavers.com> writes: > > @@ -72,11 +73,19 @@ static BOOL load_driver(const WCHAR *name) > > } > > > > #define LDFC(n) do { drvs.p##n = (void*)GetProcAddress(drvs.module, > > #n);\ - if(!drvs.p##n) return FALSE; } while(0); > > + if(!drvs.p##n) { FreeLibrary(drvs.module); return FALSE; } } > > while(0); + LDFC(InitializeDriver); > > LDFC(GetEndpointIDs); > > LDFC(GetAudioEndpoint); > > #undef LDFC > > > > + hr = drvs.pInitializeDriver(); > > + if(FAILED(hr)){ > > + TRACE("Driver initialization failed: %08x\n", hr); > > + FreeLibrary(drvs.module); > > + return hr; > > + } > > If you are going to call it on load, you could just as well do the init > in the driver on DLL_PROCESS_ATTACH and avoid the extra method. Wine is already plagued by deadlocks in the MM drivers initialization that interfere with the loader's lock. Explicit initialization after LoadLibrary returns should help getting rid of these.

May 2, 2011