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

Re: wineport: Add support for ctz().

by David Laight

On Wed, Mar 16, 2011 at 01:26:31PM -0500, Adam Martinson wrote: > > __builtin_ctz() compiles to: > mov 0x8(%ebp),%eax > bsf %eax,%eax > > (ffs()-1) compiles to: > mov $0xffffffff,%edx > bsf 0x8(%ebp),%eax > cmove %edx,%eax ... > > So yes, there is a reason, ctz() is at least 50% faster. I'm not where you get 50% from! I've read both the intel and amd x86 instruction performance manuals (but can't clain to remember all of it!). The 'bsf' will be a slow instruction (with constraints on where it exectutes, and what can execute in parallel). The 'cmove' has even worse constraints since it can't execute until the 'flags' from the previous instruction are known. cmove is only slightly better than a mis-predicted branch! In this case there will be complete pipeline stall between the 'bsf' and the 'cmove'. ffs would probably execute faster with a forwards conditional branch (predicted not taken) in the 'return -1' path. David -- David Laight: david(a)l8s.co.uk

March 17, 2011

Solution for "Could not find dependent assembly" error

by Alexandru Bolboaca-Diaconu

March 17, 2011

Re: wineport: Add support for ctz().

by Marcus Meissner

On Wed, Mar 16, 2011 at 01:26:31PM -0500, Adam Martinson wrote: > On 03/16/2011 08:34 AM, Alexandre Julliard wrote: > >Adam Martinson<amartinson(a)codeweavers.com> writes: > > > >>@@ -239,6 +243,19 @@ extern int getopt_long_only (int ___argc, char *const *___argv, > >> int ffs( int x ); > >> #endif > >> > >>+#if defined(__GNUC__)&& (GCC_VERSION>= 30406) > >>+ #define ctz(x) __builtin_ctz(x) > >>+#elif defined(__GNUC__)&& (defined(__i386__) || defined(__x86_64__)) > >>+ static inline int ctz( unsigned int x ) > >>+ { > >>+ int ret; > >>+ __asm__("bsfl %1, %0" : "=r" (ret) : "r" (x)); > >>+ return ret; > >>+ } > >>+#else > >>+ #define ctz(x) (ffs(x)-1) > >>+#endif > >There's no reason to add this. Just use ffs(). > > > If I thought ffs() was adequate, I would. I need this for iterating > sparse bitsets. > > __builtin_ctz() compiles to: > mov 0x8(%ebp),%eax > bsf %eax,%eax > > (ffs()-1) compiles to: > mov $0xffffffff,%edx > bsf 0x8(%ebp),%eax > cmove %edx,%eax > add $0x1,%eax > sub $0x1,%eax > > ... Fortunately -O2 catches the add/sub. So yes, there is a reason, > ctz() is at least 50% faster. You are optimizing in the wrong spot. If this is not in performance relevant code, readability is always better than hacks. ciao, Marcus

March 17, 2011

Re: mshtml,shdocvw: Initialize OLEINPLACEFRAMEINFO.cb for IOleInPlaceSite::GetWindowContext (try 2)

by Dmitry Timoshkov

Thomas Faber <thfabba(a)gmx.de> wrote: > ip_frame = NULL; > ip_uiwindow = NULL; > + frame_info.cb = sizeof(OLEINPLACEFRAMEINFO); Using sizeof(frame_info) here and in other places instead of sizeof(OLEINPLACEFRAMEINFO) would be better IMHO. -- Dmitry.

March 17, 2011

Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)

by Adam Martinson

On 03/16/2011 02:55 PM, Alexandre Julliard wrote: > Adam Martinson<amartinson(a)codeweavers.com> writes: > >> On 03/16/2011 02:24 PM, Alexandre Julliard wrote: >>> Adam Martinson<amartinson(a)codeweavers.com> writes: >>> >>>> Look at any d3d app with oprofile. That function is called >>>> EVERYWHERE. In my testing this reduces >>>> IWineD3DDeviceImpl_MarkStateDirty() from 4.8% of wined3d CPU time to >>>> 3.3%. >>> What compiler are you using? I don't see any difference here. >>> >> GCC 4.4.5, running the 3DMark06 batch size tests. > I don't see any difference with 4.4.5 either, the generated code is > basically identical. If gcc really doesn't notice the loop invariant for > you, something is wrong with your setup. > Oh wow... you're correct, I'm retarded xD I have another patch that overwrites these changes, and didn't bench them separately LOL xD Very sorry!

March 16, 2011

Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)

by Alexandre Julliard

Adam Martinson <amartinson(a)codeweavers.com> writes: > On 03/16/2011 02:24 PM, Alexandre Julliard wrote: >> Adam Martinson<amartinson(a)codeweavers.com> writes: >> >>> Look at any d3d app with oprofile. That function is called >>> EVERYWHERE. In my testing this reduces >>> IWineD3DDeviceImpl_MarkStateDirty() from 4.8% of wined3d CPU time to >>> 3.3%. >> What compiler are you using? I don't see any difference here. >> > GCC 4.4.5, running the 3DMark06 batch size tests. I don't see any difference with 4.4.5 either, the generated code is basically identical. If gcc really doesn't notice the loop invariant for you, something is wrong with your setup. -- Alexandre Julliard julliard(a)winehq.org

March 16, 2011

Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)

by Adam Martinson

On 03/16/2011 02:24 PM, Alexandre Julliard wrote: > Adam Martinson<amartinson(a)codeweavers.com> writes: > >> Look at any d3d app with oprofile. That function is called >> EVERYWHERE. In my testing this reduces >> IWineD3DDeviceImpl_MarkStateDirty() from 4.8% of wined3d CPU time to >> 3.3%. > What compiler are you using? I don't see any difference here. > GCC 4.4.5, running the 3DMark06 batch size tests.

March 16, 2011

Re: kernel32: CreateProcessA should not call CreateProcessW directly

by Maarten Lankhorst

Hi Dan, Op 16-03-11 20:06, Dan Kegel schreef: > Does that work when compiling with -O3 ? > Maybe you need a noinline attribute, > http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attribu… I don't think it will ever be inlined because of the calling convention differences. Doing a dumb -O3 to be sure confirms it. Cheers, Maarten.

March 16, 2011

re: kernel32: CreateProcessA should not call CreateProcessW directly

by Dan Kegel

Does that work when compiling with -O3 ? Maybe you need a noinline attribute, http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attribu…

March 16, 2011

Re: winmm DriverCallback with 0 CALLBACK_WINDOW

by Maarten Lankhorst

Hey, Op 16-03-11 15:52, Joerg-Cyril.Hoehle(a)t-systems.com schreef: > Hi, > > Testbot job #9994 proves that Wine and native differ in their handling of a 0 CALLBACK_WINDOW handle. > Wine's PostMessage redirects a 0 handle to PostThreadMessage(currentThreadID()), > while native finds no notification on the thread's queue in such a case. > > (As a consequence, Wine's player thread will send notification messages to itself ...) Considering PostThreadMessage(NULL) is supposed to post to the thread queue this is fine, feel free to fix though. > Alas, the test case does not allow to tell whether the difference in with > - winmm:DriverCallback or > - whether winmm:midiOutOpen sees the 0 handle and remap to CALLBACK_NULL internally, > before ever calling DriverCallback. > > Likewise, a NULL CALLBACK_FUNCTION does not cause a crash since w2k, > but we don't know whether winmm:DriverCallback catches that case (as Wine does nowadays) or > whether winmm:wave/midi/mixer/Open remap that to maybe CALLBACK_NULL and proceed. > > Is there any means to tell the difference, short of writing a real driver with > debug output and installing it on a native system, having native DriverCallback called directly? In that case I wouldn't worry about it, just handle it in DriverCallback to save on duplication. > BTW, why does winealsa.drv:mixer use a custom callback mechanism instead of the > generic DriverCallback that the other winmm drivers use? Historical reasons only? I honestly can't remember. Probably because I only checked with sndvol32, feel free to send in a patch for it though. Cheers, Maarten

March 16, 2011

Re: lifetime of the MIDI/MIXER/WAVEOPENDESC structure?

by Maarten Lankhorst

Hey, Op 16-03-11 16:03, Joerg-Cyril.Hoehle(a)t-systems.com schreef: > Hi, > > MSDN is silent about the lifetime of the MIDI/MIXER/WAVEOPENDESC structure > that is deliverred via the W/MODM_OPEN/MXM_OPEN message to the winmm drivers > (WAVEOOPENDESC is not even documented for MS-Windows (not CE) anymore). > > http://msdn.microsoft.com/en-us/library/ff537518%28v=vs.85%29.aspx MIDIOPENDESC > > IMHO, it would make a lot of sense if the structure remained allocated > for the whole lifetime of the open/close cycle, so the driver need not make a copy of it. > > Is there anybody who knows more about this topic? I wouldn't count on it, the structure is allocated on the stack, see for example winmm.c: WAVE_Open Cheers, Maarten

March 16, 2011

Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)

by Adam Martinson

On 03/16/2011 08:39 AM, Alexandre Julliard wrote: > Adam Martinson<amartinson(a)codeweavers.com> writes: > >> --- >> dlls/wined3d/device.c | 17 ++++++++--------- >> 1 files changed, 8 insertions(+), 9 deletions(-) > You still need to demonstrate that this is an improvement. Compilers are > pretty good nowadays, and doing such micro-optimizations at the source > level is usually futile. > Look at any d3d app with oprofile. That function is called EVERYWHERE. In my testing this reduces IWineD3DDeviceImpl_MarkStateDirty() from 4.8% of wined3d CPU time to 3.3%.

March 16, 2011

Re: wineport: Add support for ctz().

by Adam Martinson

On 03/16/2011 08:34 AM, Alexandre Julliard wrote: > Adam Martinson<amartinson(a)codeweavers.com> writes: > >> @@ -239,6 +243,19 @@ extern int getopt_long_only (int ___argc, char *const *___argv, >> int ffs( int x ); >> #endif >> >> +#if defined(__GNUC__)&& (GCC_VERSION>= 30406) >> + #define ctz(x) __builtin_ctz(x) >> +#elif defined(__GNUC__)&& (defined(__i386__) || defined(__x86_64__)) >> + static inline int ctz( unsigned int x ) >> + { >> + int ret; >> + __asm__("bsfl %1, %0" : "=r" (ret) : "r" (x)); >> + return ret; >> + } >> +#else >> + #define ctz(x) (ffs(x)-1) >> +#endif > There's no reason to add this. Just use ffs(). > If I thought ffs() was adequate, I would. I need this for iterating sparse bitsets. __builtin_ctz() compiles to: mov 0x8(%ebp),%eax bsf %eax,%eax (ffs()-1) compiles to: mov $0xffffffff,%edx bsf 0x8(%ebp),%eax cmove %edx,%eax add $0x1,%eax sub $0x1,%eax ... Fortunately -O2 catches the add/sub. So yes, there is a reason, ctz() is at least 50% faster.

March 16, 2011

Re: d3dx9_36/tests: Replace a malloc() with HeapAlloc()+HeapFree().

by Dylan Smith

On Wed, Mar 16, 2011 at 3:57 AM, Francois Gouget <fgouget(a)free.fr> wrote: > Any reason why we were not freeing glyphmetrics_float? > No reason, just a mistake on my part.

March 16, 2011

Re: windowscodecs: DibDecoder_CreateInstance() is unused so remove it.

by Vincent Povirk

I think this will be needed by d3dx9, though it hasn't been fully wired up yet.

March 16, 2011

Re: kernel32: Implement and test GetVolumePathNamesForVolumeName. (try 2)

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > + for (i = 0; i < output->NumberOfMountPoints; i++) > + { > + if (output->MountPoints[i].DeviceNameOffset) > + { > + const WCHAR *device = (const WCHAR *)((const char *)output + output->MountPoints[i].DeviceNameOffset); > + UINT device_len = output->MountPoints[i].DeviceNameLength / sizeof(WCHAR); > + int drive = map_dos_device( device, device_len ); > + > + if (drive != -1) > + { > + len += 4; > + if (volumepathname && len < buflen) > + { > + path[0] = 'A' + drive; > + path[1] = ':'; > + path[2] = '\\'; > + path[3] = 0; > + path += 4; > + } > + } > + } This won't allow you to support GUID volume names. I think you should query all mount points that match the device, not just the DOS drives. Either way you should use MOUNTMGR_QUERY_POINTS instead of trying every drive one by one. -- Alexandre Julliard julliard(a)winehq.org

March 16, 2011

lifetime of the MIDI/MIXER/WAVEOPENDESC structure?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, MSDN is silent about the lifetime of the MIDI/MIXER/WAVEOPENDESC structure that is deliverred via the W/MODM_OPEN/MXM_OPEN message to the winmm drivers (WAVEOOPENDESC is not even documented for MS-Windows (not CE) anymore). http://msdn.microsoft.com/en-us/library/ff537518%28v=vs.85%29.aspx MIDIOPENDESC IMHO, it would make a lot of sense if the structure remained allocated for the whole lifetime of the open/close cycle, so the driver need not make a copy of it. Is there anybody who knows more about this topic? Thank you, Jörg Höhle

March 16, 2011

winmm DriverCallback with 0 CALLBACK_WINDOW

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Testbot job #9994 proves that Wine and native differ in their handling of a 0 CALLBACK_WINDOW handle. Wine's PostMessage redirects a 0 handle to PostThreadMessage(currentThreadID()), while native finds no notification on the thread's queue in such a case. (As a consequence, Wine's player thread will send notification messages to itself ...) Alas, the test case does not allow to tell whether the difference in with - winmm:DriverCallback or - whether winmm:midiOutOpen sees the 0 handle and remap to CALLBACK_NULL internally, before ever calling DriverCallback. Likewise, a NULL CALLBACK_FUNCTION does not cause a crash since w2k, but we don't know whether winmm:DriverCallback catches that case (as Wine does nowadays) or whether winmm:wave/midi/mixer/Open remap that to maybe CALLBACK_NULL and proceed. Is there any means to tell the difference, short of writing a real driver with debug output and installing it on a native system, having native DriverCallback called directly? Any ideas? Jörg Höhle BTW, why does winealsa.drv:mixer use a custom callback mechanism instead of the generic DriverCallback that the other winmm drivers use? Historical reasons only?

March 16, 2011

Re: Wine Gecko 1.2.0 released

by Jacek Caban

On 3/15/11 10:44 PM, Scott Ritchie wrote: > Do you really mean 1.3.15 or do you mean the upcoming 1.3.16? I meant post-1.3.15, so it's the updcoming 1.3.16, sorry for the confusion. Jacek

March 16, 2011

Re: mshtml, shdocvw: Initialize OLEINPLACEFRAMEINFO.cb for IOleInPlaceSite::GetWindowContext

by Jacek Caban

Hi Thomas, On 3/16/11 11:21 AM, Thomas Faber wrote: > Hi, > > the documentation for the OLEINPLACEFRAMEINFO structure [1] says > that the 'cb' member must be initialized before passing the structure > to IOleInPlaceSite::GetWindowContext (where the rest of it will be > filled). > In addition to the fix, I have updated the corresponding > tests to check this member instead of setting it, and they pass > on Windows as expected [2]. I've used a>= compare for future > version compatibility. Comparing to the exact value is better in this case. If the value will ever change, we want to know that and tests failures will help us notice it. Jacek

March 16, 2011

Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)

by Alexandre Julliard

Adam Martinson <amartinson(a)codeweavers.com> writes: > --- > dlls/wined3d/device.c | 17 ++++++++--------- > 1 files changed, 8 insertions(+), 9 deletions(-) You still need to demonstrate that this is an improvement. Compilers are pretty good nowadays, and doing such micro-optimizations at the source level is usually futile. -- Alexandre Julliard julliard(a)winehq.org

March 16, 2011

Re: wineport: Add support for ctz().

by Alexandre Julliard

Adam Martinson <amartinson(a)codeweavers.com> writes: > @@ -239,6 +243,19 @@ extern int getopt_long_only (int ___argc, char *const *___argv, > int ffs( int x ); > #endif > > +#if defined(__GNUC__) && (GCC_VERSION >= 30406) > + #define ctz(x) __builtin_ctz(x) > +#elif defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) > + static inline int ctz( unsigned int x ) > + { > + int ret; > + __asm__("bsfl %1, %0" : "=r" (ret) : "r" (x)); > + return ret; > + } > +#else > + #define ctz(x) (ffs(x)-1) > +#endif There's no reason to add this. Just use ffs(). -- Alexandre Julliard julliard(a)winehq.org

March 16, 2011

Re: d3dx9_36 [try 3]: Add a few tests for D3DXCreateBox

by Matteo Bruni

Most of the objections from the previous try still stand: check your whitespaces (whitespace after every comma, whitespaces around operators, whitespace after "if" or "for" keywords), you have to be consistent. Comparing indices doesn't make much sense now that you don't check vertices, I think you should drop that too. You could probably instead check for min and max x, y and z vertices coordinates, verifying that the box has the expected dimensions.

March 16, 2011

Re: correct comctl32 implementation

by Andrew Green

I'm not sure how it will only use theming for version 6 without sxs. Will the control have to manually check the manifest? I am a bit familiar with how to use the themes to draw controls and that shouldn't be an issue. At the moment i'm more confused with this window class redirect thing. I've been trying to find someone who knows a bit about it. Without much luck. On Mar 15, 2011 9:19 PM, "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > On 3/15/2011 05:25, Frank Richter wrote: >> On 11.03.2011 10:28, Nikolay Sivov wrote: >>> In version 6 all user32 controls are reimplemented with theme support in >>> comctl32, while user32 classes are kept of course. This is done with >>> specific entries in comctl32 manifest, on load comctl32 all builtin >>> classes are re-registered to the ones from comctl32. I definitely want >>> to see some solution for that, having themed comctl32 controls while >>> scrollbars and buttons are drawn with default appearance makes theme >>> support kind of useless. >> Buttons: technically, I don't think you need SxS class redirection for >> that. The issue with the current “subclassing” is that, well, the button >> can't really be subclassed for theming - IIRC some state changes don't >> trigger a “paint” message but only cause internal painting - this can't >> be caught lass function and breaks theming. >> What MS supposedly did was to simply copy'n'paste the controls code into >> comctl32 and add theming. That would certainly allow properly themed >> buttons. And SxS class redirection... > We need a way to make comctl32 controls available, not always but only > when it's requested to use version 6. > Native does that with class redirection. > > I'm not sure it's ok to use comctl32 always for builtin classes. >> Scroll bars, are, IIRC, a different beast - window scroll bars are not >> controls but handled/drawn by DefWndProc. No idea how native themes >> these. Maybe some mojo to override/hook into DefWndProc? > That's not true. Scrollbar could be a normal control too. I have no idea > how themes work with window scrollbars though. >> -f.r. >> >> >> >> >

March 16, 2011

Re: Wine Gecko 1.2.0 released

by Scott Ritchie

On 03/15/2011 11:02 AM, Jacek Caban wrote: > Hi all, > > The new Wine Gecko release is out and already used by Wine git version. > Let me conclude shortly what has changed (more detailed updates can be > found in my previous mails). It mostly means that you have to download > it from Wine Sourceforge [1] and put it into the right directory [2] as > always after each Gecko update. One important change is that there is > msi file instead of cab file. Also starting with Wine 1.3.15, packages > should be updated to depend on the new Gecko. Packagers may consider > compiling Gecko themselves as building process no longer has ugly > dependencies. > > Thanks to everyone who helped with the release! > > BTW, the nice thing is that accidentally we've released just after IE9. > That's what I call a quick response :) > > Cheers, > Jacek > > [1] https://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0/ > [2] http://wiki.winehq.org/Gecko > > > Do you really mean 1.3.15 or do you mean the upcoming 1.3.16? -Scott

March 15, 2011