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

Re: D3D performance debugging report

by Stefan Dösinger

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 1, 2011

Re: D3D performance debugging report

by Emanuele Oriani

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. The biggest issue imho is that in this case we have to call a function... it would be great to inline all that code, but again, probably the best thing is to limit the number of calls. 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: static volatile pid_t x11_lock = 0; static volatile int x11_lock_cnt = 0; /*********************************************************************** * wine_tsx11_lock (X11DRV.@) */ void CDECL wine_tsx11_lock(void) { pid_t th_id = syscall(SYS_gettid); // This might be expensive! // I don't like recursive locks for this reason! while (th_id != __sync_val_compare_and_swap(&x11_lock, 0, th_id)); ++x11_lock_cnt; asm volatile("lfence" ::: "memory"); } /*********************************************************************** * wine_tsx11_unlock (X11DRV.@) */ void CDECL wine_tsx11_unlock(void) { if(!--x11_lock_cnt) x11_lock=0; asm volatile("sfence" ::: "memory"); } 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? Let me know, Cheers, On 01/05/11 09:33, Stefan Dösinger wrote: > On Saturday 30 April 2011 18:26:04 Emanuele Oriani wrote: >> 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? > I am usually pessimistic about hand-written assembler optimizations. You can > give it a try, but compilers are pretty clever these days. > > I think trying to optimize the lock calls is a more promising way. We can't > simply drop the ENTER_GL/LEAVE_GL calls, as you found out in SC2. We may be > able to reduce the number of those calls by moving blocks of opengl calls > closer together. > > There's also the wined3d lock, which is somewhat like the big kernel lock. > There's room for improvement there as well, if we soften the "you must call > wined3d under lock" rule. However the wined3d lock is the smaller problem > compared to the X11 lock.

May 1, 2011

re: comctl32: realloc or free and alloc

by Alexey Fisher

On So, 2011-05-01 at 07:43 +0200, Alexey Fisher wrote: > Am Samstag, den 30.04.2011, 14:41 +0000 schrieb 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. > > We do not need to save anything what was in the target. Even the old > code ReAloocate it and then rewrite. In most contexts the pointer is a > fresh one. If it is not, it should be freed before this func. > > > Your proposed solution would pass a non-Alloc'd > > pointer to Free, which doesn't seem good. > > So probably best solution is to forbid using not a NULL pointer in this > func. The programmer should decide where to Free it before. > There is a new patch in the attachment. -- Regards, Alexey

May 1, 2011

Re: [PATCH 4/5] winecoreaudio.drv: Implement IAudioSessionControl::GetState

by Ken Thomases

Hi, On Apr 29, 2011, at 3:50 PM, Andrew Eikum wrote: > + LIST_FOR_EACH_ENTRY(client, &This->session->clients, ACImpl, entry){ > + OSSpinLockLock(&client->lock); > + if(client->playing == StatePlaying){ > + *state = AudioSessionStateActive; I think the session should be considered active if a client is in StateInTransition, too. Regards, Ken

May 1, 2011

Re: D3D performance debugging report

by Stefan Dösinger

On Saturday 30 April 2011 18:26:04 Emanuele Oriani wrote: > 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? I am usually pessimistic about hand-written assembler optimizations. You can give it a try, but compilers are pretty clever these days. I think trying to optimize the lock calls is a more promising way. We can't simply drop the ENTER_GL/LEAVE_GL calls, as you found out in SC2. We may be able to reduce the number of those calls by moving blocks of opengl calls closer together. There's also the wined3d lock, which is somewhat like the big kernel lock. There's room for improvement there as well, if we soften the "you must call wined3d under lock" rule. However the wined3d lock is the smaller problem compared to the X11 lock.

May 1, 2011

Re: ddraw: Add a few tests for Setcooperativelevel

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=10649 Your paranoid android. === WNT4WSSP6 (32 bit ddrawmodes) === ddrawmodes.c:800: Test failed: SetCooperativelevel(DDSCL_SETFOCUSWINDOW) returned: 80070057 ddrawmodes.c:803: Test failed: SetCooperativelevel(DDSCL_CREATEDEVICEWINDOW | DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN) returned: 80070057 ddrawmodes.c:828: Test failed: SetCooperativelevel(DDSCL_SETFOCUSWINDOW) returned: 80070057 === W7PROX64 (64 bit ddrawmodes) === Timeout

May 1, 2011

re: comctl32: realloc or free and alloc

by Alexey Fisher

Am Samstag, den 30.04.2011, 14:41 +0000 schrieb 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. We do not need to save anything what was in the target. Even the old code ReAloocate it and then rewrite. In most contexts the pointer is a fresh one. If it is not, it should be freed before this func. > Your proposed solution would pass a non-Alloc'd > pointer to Free, which doesn't seem good. So probably best solution is to forbid using not a NULL pointer in this func. The programmer should decide where to Free it before.

May 1, 2011