March 2013 - Wine-devel - list.winehq.org

RE: d3dx9 [patch 1/2]: Implement D3DXSHEvalSphericalLight
by Nozomi Kodama 14 Mar '13

14 Mar '13

Hello Any problem with the patch http://source.winehq.org/patches/data/94777 and http://source.winehq.org/patches/data/94776 ? Nozomi.

2 2

Re: winegcc: Add support for -Ttext-segment linker flag to set image base of a dll. (try 2)
by André Hentschel 14 Mar '13

14 Mar '13

Am 03.03.2013 16:58, schrieb Tijl Coosemans: > --- > README | 3 +++ > tools/winegcc/utils.h | 3 ++- > tools/winegcc/winegcc.c | 11 ++++++++++- > 3 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/README b/README > index 783e798..75aff5a 100644 > --- a/README > +++ b/README > @@ -40,6 +40,9 @@ support kernel threads may be supported in the future. > > FreeBSD info: > Wine will generally not work properly on versions before FreeBSD 7.0. > + You need GCC with GNU Binutils 2.20 or higher and run configure with > + environment variables like CC, CFLAGS, CXX, CXXFLAGS, CPP, CPPFLAGS, > + LD and LDFLAGS set correctly to use this compiler and linker. > See http://wiki.freebsd.org/Wine for more information. > Do you really need that? is there no script on freebsd to set the compiler toolchain or something? > > enum target_platform > { > - PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS, PLATFORM_WINDOWS, PLATFORM_CYGWIN > + PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS, PLATFORM_ELF, > + PLATFORM_WINDOWS, PLATFORM_CYGWIN > }; > You would rather call it PLATFORM_FREEBSD > + if (opts->image_base && !opts->target && opts->target_platform == PLATFORM_UNSPECIFIED) I'm in doubt here -- Best Regards, André Hentschel

3 5

Re: [PATCH 2/2] ole32: Don't pass CLSCTX_INPROC_SERVER and CLSCTX_INPROC_HANDLER flags to CoCreateInstance in DefaultHandler
by Marvin 13 Mar '13

13 Mar '13

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=24750 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: gdiplus: Ignore gdiplus page and world transformations when creating a gdi32 clipping region.
by Vincent Povirk 13 Mar '13

13 Mar '13

I guess this makes sense, because having the clipping region change with transforms would be weird when drawing recursively and changing the transform. I had assumed clipping regions were in world coordinates because most things are, but I didn't really have any information either way.

1 0

Re: [PATCH 1/2] wined3d: Put local constants into the shader code again
by Henri Verbeet 13 Mar '13

13 Mar '13

On 13 March 2013 02:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This provides a small GPU-side performance boost on dx10+ capable Nvidia > cards - about 5% in World of Tanks on my Geforce 9600, and more in a > dedicated test program. > > This is essentially a revert of cd7825c89374fb9dd4c20aef2dbfd258713efe6a, > with proper precision. > This is probably ok, although one concern is applications setting constants to e.g. NaN or infinity. It may be worth using ARB_shader_bit_encoding when available, or perhaps even only doing this when that extension is available.

2 1

Re: [PATCH 1/2] wined3d: Put local constants into the shader code again
by Stefan Dösinger 13 Mar '13

13 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-03-12 18:19, schrieb Stefan Dösinger: > The test program is available at > https://84.112.174.163/~git/perftest file const_gl/const_gl.cpp. My server is currently turned off (and I should move this to github or somewhere at some point), so I've attached the test program here for reference. Resolution and constant mode are hardcoded into it. Tab/space mixup thanks to Visual Studio. Compile the Linux version with g++ const_gl.cpp -o const_gl -lGL -lglut -lGLEW . A d3d version is attached as well. It does not load the same values when using the global constants, but this doesn't seem to affect performance. I haven't tested ARB shaders, but from the WoT results before and after patch 2, their behavior seems to be the same as GLSL and native d3d. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRP9WcAAoJEN0/YqbEcdMwdmoP/2LvEFpPpmTiZDzxqhp38WfU DKs2S8m1kP86fL55GwLtth289WC9MsQyOosOVOqt8r3YWZyckeisZyhdP2ez2KRV 9kgxMnEXwzcZBtmm/+nrl0FwJghy86AnZ0YJ9PpnCpY0k4VTQYjaWQALlyqtF+qm Uup4UE+m4yR4DoNL/u/161Zxh+OLOA8PXEhWWfDozNL/8yMlRfPs6gzLMN/oKTIL UMA90gesZWPt7/J2Bp0+OeZvMWqNa54A2akxsLvtxVP/rB8baym4iYLn5Y2IPXa2 lBqALc+POMcVk45FCgkzjUw5b/7ck9V5n0PKOw/9Jwrm8/ChHE4i0ZwGEmHzh3So y1d/KydwesYtyCadmlklgJy1J+CxyCd/fNVUmsNtpzDEo6OF7oEagvwBUlTnCdR9 W9B9lmpsDCuBIxEnAy7C3HEZ18o70HdoUsKe5hX8fVn5lnwFPWdp7hBA0nVbO0y0 Fybps006cQmc0Rm9nHJjeJ9JoGzl/iuSX0AnQ5fiJS6fS5RrrGAnFBEb1g2O879X pNSIgBdKUSSfGBoUZKKIy+GZzC+VhDm4UqhtSaYudlUB9pcoMDFYRGQ3Rk48kRuD tJ8Ah2VBYeFUvI+x4Xty9AtOwwFWYejNG+6cNNF3EOALz2JvhFKDEJCI0p7bdmgR XCfPxQyYN7+JGFw8JiO5 =RgiG -----END PGP SIGNATURE-----

1 0

Re: [PATCH] activeds: Exclude unused headers.
by Alexandre Julliard 12 Mar '13

12 Mar '13

Amine Khaldi <amine.khaldi(a)reactos.org> writes: > @@ -28,13 +28,10 @@ > > #include "windef.h" > #include "winbase.h" > -#include "winuser.h" > > #include "objbase.h" > #include "iads.h" > -#include "adshlp.h" > > -#include "wine/unicode.h" > #include "wine/debug.h" It's not worth the trouble, particularly since the file ends up including windows.h anyway. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: ntdll: Make msync() asynchronous in NtFlushVirtualMemory (resubmit with real name)
by Alexandre Julliard 12 Mar '13

12 Mar '13

Mathis Beer <default_357-line(a)yahoo.de> writes: > diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c > index a99bca4..e4f2bb6 100644 > --- a/dlls/ntdll/virtual.c > +++ b/dlls/ntdll/virtual.c > @@ -62,6 +62,10 @@ WINE_DECLARE_DEBUG_CHANNEL(module); > #define MS_SYNC 0 > #endif > > +#ifndef MS_ASYNC > +#define MS_ASYNC 1 > +#endif That's questionable, there's no reason the value would be 1. We defined MS_SYNC to 0 on the theory that it's better to pass 0 than making up values, but probably not calling the function at all would be preferable. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: msvcp60: Avoid signed-unsigned integer comparisons
by larmbr zhan 11 Mar '13

11 Mar '13

On Sun, Mar 10, 2013 at 5:48 AM, Andrew Talbot <andrew.talbot(a)talbotville.com> wrote: > msvcp60: Avoid signed-unsigned integer comparisons. Hi, Andrew Talbot. I find that you are working on these "Avoid signed-unsigned integer comparisons" things recently. I DO agree on that using _ unsigned int _ instead of _ int _(which implies _ signed int _). But I think using size_t maybe more standard-compliant, more efficient, and less bug-prone, . To hold this, I think something has to be clarified... * The overflow behavior is instrinsic because the finite range that a object of INT type can hold. But It behaves different when it is signed or not. According to C Standard, - For the signed case, once it overflows, resulting in representing a negative value . - For the unsigned case, once it overflows, resulting in representing a value reduced modulo the largest value that object could hold. So see this example: --- snip --- size_t num = get_max_object_num(); // which may give a large number. unsigned int i; for ( i = 0; i < num; i++) something_important[i] = vital_evaluate_for(i); --- snip --- For this case, though we use unsinged int ,it still may issue problem if num >= UINT_MAX, which will cause i to wrap to 0, then something_important maybe assigned a invalid value, as like. This problem may occur if using in a 64-bit enviroment, where size_t is typeof 'ed unsigned 64bit while unsigned int is still 32-t wide. Some may argue that in Wine this problem will NEVER happen. I don't doubt it. But * since we have a cleared and more standard-compliant way (which means less bug-prone), and * predictably Wine will support more platforms, portable way shall be taken it account. So I think we should use size_t in this case. -- Cheers, Zhan JIanyu

4 3

Re: ntdll: make NtDelayExecution a bit more efficient
by Alexandre Julliard 11 Mar '13

11 Mar '13

Graham <graham.knap(a)gmail.com> writes: > This patch is vaguely related to bug 24558. It eliminates a few > syscalls in NtDelayExecution: > > 1. If the caller requests a zero-wait yield, then do just that, and > nothing more. That's what the existing code already does. > 2. If you're about to block on select(), then I don't see any point in > preceding that with a call to sched_yield(). This was added for a reason; most likely you'll have to write tests. -- Alexandre Julliard julliard(a)winehq.org

7 7