July 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 6/6] d3d11/tests: Add visual tests for locking vertexbuffers

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 https://testbot.winehq.org/JobDetails.pl?Key=24541 Your paranoid android. === wvistau64 (32 bit d3d11) === d3d11: unhandled exception 0000087c at 75A2E743 === w2008s64 (32 bit d3d11) === d3d11: unhandled exception 0000087c at 7680E743 === w7u (32 bit d3d11) === d3d11: unhandled exception c0000005 at 004022D6 === w7pro64 (32 bit d3d11) === d3d11: unhandled exception c0000005 at 004022D6 === w8 (32 bit d3d11) === d3d11: unhandled exception c0000005 at 004022D6 === w864 (32 bit d3d11) === d3d11: unhandled exception c0000005 at 004022D6 === w1064 (32 bit d3d11) === d3d11: unhandled exception c0000005 at 004022D6 === wvistau64 (64 bit d3d11) === d3d11: unhandled exception 0000087c at 000000007765674D === w2008s64 (64 bit d3d11) === d3d11: unhandled exception 0000087c at 0000000076EA674D === w7pro64 (64 bit d3d11) === d3d11: unhandled exception c0000005 at 000000000040217C === w864 (64 bit d3d11) === d3d11: unhandled exception c0000005 at 000000000040217C === w1064 (64 bit d3d11) === d3d11: unhandled exception c0000005 at 000000000040217C

July 26, 2016

Re: [PATCH 5/6] d3d10core/tests: Add visual tests for locking vertexbuffers

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 https://testbot.winehq.org/JobDetails.pl?Key=24540 Your paranoid android. === wvistau64 (32 bit device) === device: unhandled exception 00000879 at 75A2E743 === w2008s64 (32 bit device) === device: unhandled exception 00000879 at 7680E743 === w7u (32 bit device) === device: unhandled exception c0000005 at 00406895 === w7pro64 (32 bit device) === device: unhandled exception c0000005 at 00406895 === w8 (32 bit device) === device: unhandled exception c0000005 at 00406895 === w864 (32 bit device) === device: unhandled exception c0000005 at 00406895 === w1064 (32 bit device) === device: unhandled exception c0000005 at 00406895 === wvistau64 (64 bit device) === device: unhandled exception 00000879 at 000000007765674D === w2008s64 (64 bit device) === device: unhandled exception 00000879 at 0000000076EA674D === w7pro64 (64 bit device) === device: unhandled exception c0000005 at 0000000000405C40 === w864 (64 bit device) === device: unhandled exception c0000005 at 0000000000405C40 === w1064 (64 bit device) === device: unhandled exception c0000005 at 0000000000405C40

July 26, 2016

Re: [PATCH 4/6] ddraw/tests: Add visual tests for locking vertexbuffers

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 https://testbot.winehq.org/JobDetails.pl?Key=24539 Your paranoid android. === w8 (32 bit visual) === visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_DISCARDCONTENTS. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_READONLY. dwCaps = 0x10000. === w864 (32 bit visual) === visual.c:307: Test failed: Clear rectangle 3(pos, neg) has color 0000ff00 visual.c:309: Test failed: Clear rectangle 1(pos, pos) has color 0000ff00 visual.c:311: Test failed: Clear rectangle 4(NULL) has color 0000ff00 visual.c:313: Test failed: Clear rectangle 4(neg, neg) has color 0000ff00 visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_DISCARDCONTENTS. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_READONLY. dwCaps = 0x10000. === w1064 (32 bit visual) === visual.c:307: Test failed: Clear rectangle 3(pos, neg) has color 0000ff00 visual.c:309: Test failed: Clear rectangle 1(pos, pos) has color 0000ff00 visual.c:311: Test failed: Clear rectangle 4(NULL) has color 0000ff00 visual.c:313: Test failed: Clear rectangle 4(neg, neg) has color 0000ff00 visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_DISCARDCONTENTS. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_READONLY. dwCaps = 0x10000.

July 26, 2016

Re: [PATCH] msxml2: Share source with msxml3

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Since msxml2/4/6 all point to msxml3, having to install native > msxml3 will cause all the rest to fail. As an example, mdac28 > requires msxml3 to be installed (msxml3 has an incomplete IXMLParser > implementation, so native has to be used). I would change msxml4/6 as > well, so that installing any of the native msxml DLL wouldn't affect the > others. > > We could just use my previous patch, which would also resolve the issue > of registry entry. That scenario is > 1. Clean prefix. > 2. Install native msxml3 > 3. Force update of bottle (e.g. wine update) > The msxml2.DOMDocument registry entry is now incorrect. That's a corner case that I don't think justifies duplicating such a large dll 4 times. It should be easy to avoid by using native for the other ones too. And of course fixing builtin would be even better... -- Alexandre Julliard julliard(a)winehq.org

July 26, 2016

Re: [PATCH] msxml2: Share source with msxml3

by Alistair Leslie-Hughes

On 26/07/16 20:43, Alexandre Julliard wrote: > Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > >> Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> >> --- >> dlls/msxml2/Makefile.in | 49 ++++++++++++++++++++++++++++++++++++-- >> dlls/msxml2/main.c | 63 ------------------------------------------------- >> dlls/msxml2/msxml2.spec | 2 +- >> 3 files changed, 48 insertions(+), 66 deletions(-) >> delete mode 100644 dlls/msxml2/main.c > > Is there a real need for this? > yes and no. Since msxml2/4/6 all point to msxml3, having to install native msxml3 will cause all the rest to fail. As an example, mdac28 requires msxml3 to be installed (msxml3 has an incomplete IXMLParser implementation, so native has to be used). I would change msxml4/6 as well, so that installing any of the native msxml DLL wouldn't affect the others. We could just use my previous patch, which would also resolve the issue of registry entry. That scenario is 1. Clean prefix. 2. Install native msxml3 3. Force update of bottle (e.g. wine update) The msxml2.DOMDocument registry entry is now incorrect. (this would still fail if you want to create an Msxml2.DOMDocument.4.0 object) Best Regards Alistair Leslie-Hughes

July 26, 2016

Re: [PATCH] msxml2: Share source with msxml3

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/msxml2/Makefile.in | 49 ++++++++++++++++++++++++++++++++++++-- > dlls/msxml2/main.c | 63 ------------------------------------------------- > dlls/msxml2/msxml2.spec | 2 +- > 3 files changed, 48 insertions(+), 66 deletions(-) > delete mode 100644 dlls/msxml2/main.c Is there a real need for this? -- Alexandre Julliard julliard(a)winehq.org

July 26, 2016

Re: [PATCH 3/8] wined3d: Implement SM5 deriv_rtx_coarse instruction.

by Józef Kucia

On Tue, Jul 26, 2016 at 1:41 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > What about using the generic dFdx()/dFdy() builtins (maybe with a > WARN) for the coarse and fine variants when ARB_derivative_control > isn't supported? > I don't know that it's particularly relevant in practice, it just > seems something we don't need to strictly depend on. I have no idea if this is issue in practice but wined3d currently requires ARB_derivative_control for SM5. I guess we can add a fallback to dFdx()/dFdy() if we find an OpenGL implementation which is otherwise capable to support SM5 but doesn't expose ARB_derivative_control.

July 26, 2016

Re: [PATCH 3/8] wined3d: Implement SM5 deriv_rtx_coarse instruction.

by Józef Kucia

On Mon, Jul 25, 2016 at 12:48 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > It doesn't matter that much, but is there any reason > shader_glsl_map2gl() can't handle these? I've introduced shader_glsl_derivative() mostly to make the check for ARB_derivative_control simpler. I could have reordered patches as well to avoid introducing shader_glsl_derivative() at all, but I wasn't sure if someone won't be in favor of replacing the patch 124699 - "wined3d: Require ARB_derivative_control for SM5." with a fallback to dFdx()/dFdy().

July 26, 2016

Re: [v2 PATCH] ucrtbase: Implement _get_narrow_winmain_command_line/_get_wide_winmain_command_line

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +char* CDECL _get_narrow_winmain_command_line(void) > +{ > + static char *narrow_command_line; > + char *s; > + > + if (narrow_command_line) > + return narrow_command_line; > + > + s = GetCommandLineA(); > + if (*s == '"') > + { > + /* skip all leading quotes */ > + while (*++s == '"') > + ; > + /* skip everything up to next quote */ > + while (*s && *s++ != '"') > + ; > + } > + else > + { > + while (*s && *s != ' ' && *s != '\t') > + { > + /* allow embedded quoted blocks */ > + if (*s == '"') > + { > + s++; > + while (*s && *s++ != '"') > + ; > + } > + else > + s++; > + } > + } > + while (*s == ' ' || *s == '\t') > + s++; > + > + return narrow_command_line = s; > +} Once again: Where did you get an idea of such an implementation? Is this copied from some place or based on some other implementation? Why for instance simple 'return GetCommandLineA()' is not enough as an initial implementation? -- Dmitry.

July 26, 2016

Re: [PATCH 3/8] wined3d: Implement SM5 deriv_rtx_coarse instruction.

by Matteo Bruni

2016-07-22 12:28 GMT+02:00 Józef Kucia <jkucia(a)codeweavers.com>: > + if (!gl_info->supported[ARB_DERIVATIVE_CONTROL]) > + { > + FIXME("OpenGL implementation does not support ARB_derivative_control.\n"); > + return; > + } What about using the generic dFdx()/dFdy() builtins (maybe with a WARN) for the coarse and fine variants when ARB_derivative_control isn't supported? I don't know that it's particularly relevant in practice, it just seems something we don't need to strictly depend on.

July 25, 2016