January 2014 - Wine-Devel - list.winehq.org

Re: Cross-regressions between wine and mesa: how to handle them?

by Henri Verbeet

On 30 January 2014 22:22, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > I don't know about the extend this card support pixel shaders. There > may be a way for the driver and/or wine to work without falling back > to software. But overall I disagree with the premise of this patch. > There's a point in shipping a < GL 2.0 driver for hardware that just > doesn't support GL 2.0. But there is no point in requiring the > application to magically know if the driver's GL 2.0 is really 2.0 or > just something rigged with software fallback mines. > > Can you file a Mesa bug about this issue? I think we should ask the > Mesa devs about their opinion. > I don't know if that's specifically the issue here, but GL 2.0 also introduced point sprite coordinate origin switching. We need that when rendering offscreen, and I seem to recall i915 hitting a software fallback for that. Without GL 2.0 we'd just render incorrectly instead. It should be easy enough to rule that out by commenting out the "glPointParameteriNV(GL_POINT_SPRITE_COORD_ORIGIN, origin);" call in psorigin(). It's also generally useful to set INTEL_DEBUG=perf when investigating these kinds of things.

Jan. 30, 2014

Re: Cross-regressions between wine and mesa: how to handle them?

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-01-27 21:14, schrieb Ruslan Kabatsayev: > Bisection gives this (with Mesa $(git > describe)=snb-magic-15798-g4df1b98): > 09443f14e75e134328643b5d33aff61bdf4dca32 is the first bad commit > commit 09443f14e75e134328643b5d33aff61bdf4dca32 Author: Henri > Verbeet <hverbeet(a)codeweavers.com> Date: Wed Jul 18 21:32:34 2012 > +0200 > > wined3d: Enable "AlwaysOffscreen" by default. > > :040000 040000 c37d9d0fe4165e09a89c9e22066e3acc17537bbb > 0dd4d64233f4441ab3613327e86d9fe8187ec4ed M dlls Does the GPU support GL_ARB_depth_texture? If not this is potentially a duplicate of bug 21708. > 1) The one making wine 1.5.17 slow: > 97217a40f97cdeae0304798b607f704deb0c3558 is the first bad commit > commit 97217a40f97cdeae0304798b607f704deb0c3558 Author: Eric Anholt > <eric(a)anholt.net> Date: Wed Apr 17 13:55:08 2013 -0700 > > i915: Always enable GL 2.0 support. > > There's no point in shipping a non-GL2 driver today. I don't know about the extend this card support pixel shaders. There may be a way for the driver and/or wine to work without falling back to software. But overall I disagree with the premise of this patch. There's a point in shipping a < GL 2.0 driver for hardware that just doesn't support GL 2.0. But there is no point in requiring the application to magically know if the driver's GL 2.0 is really 2.0 or just something rigged with software fallback mines. Can you file a Mesa bug about this issue? I think we should ask the Mesa devs about their opinion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS6sKnAAoJEN0/YqbEcdMwTBsP/RpDjFuVxxv8+0LvkdT+LH62 9q/PfdsxBGQLCBpfJtuNjLP/2fsZ49SNs4cVY5tEj0FCU9lG8o14tPakBNfvxjXJ R4TE6ENzSZuv2pxilG5FS3ZGMks5bKQL6lcOjBmo3QPypHNZHtu0P9b6SotvWSrU VObpkayQGcY+hRgGvIABKvdtyJVXVeDGwbRbu+OKpFQZC27NhVx/V6lzkcBTHoAo K2OXuLLn7ESE9YtYNewaf4l7n5BHn/Dm2GDtSdsEFbpmyO0NtWLDqLHormz7W0Wz GPgFRgMs3/k9j+8MpT+UmbtFxgnT22afHE3f0TkS0yE145JdG5NHYuRQNUwjN5d+ dGZP05J5KiG8CDACDiNOhxDlx3sRDCCRvHSbjH6Ob3wz7ns2KK3kwHkvmMCwTjE3 AxB4bXxXzjr+LMUaeoRog0loF9mikDvLdDfejq9xGP68KIjisAzpH4rKkrMBESAc VSpn373igEcoGO19SyQwrmlRnvXzM1ewgrG4XetsmhYy7JwCZH5+x07o/FMw9mKV atV2CWqU4aTF5NKfzu1V0ys4GrtbGGvPsMuXyhq20G2q+t8xOKT/ARCGX9w6rQGX jhr0QnaCgziQxGeQ+WRTcL76uzc231QMH/EGZujfuiZKenutVqnnHrNrxLPxcDqO fxPnD37dUw4QnTZbLdzA =iPQ/ -----END PGP SIGNATURE-----

Jan. 30, 2014

Re: [PATCH] oleaut32: Fix RecordCopy()/RecordClear() behavior (try2)

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://newtestbot.winehq.org/JobDetails.pl?Key=4552 Your paranoid android. === build (build) === Make failed

Jan. 30, 2014

Re: [PATCH] oleaut32: Fix RecordCopy()/RecordClear() behavior

by Nikolay Sivov

On 1/30/2014 22:38, Alexandre Julliard wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> writes: > >> --- >> dlls/oleaut32/recinfo.c | 75 +++++++++++++++++++++- >> dlls/oleaut32/tests/test_tlb.idl | 6 +- >> dlls/oleaut32/tests/vartype.c | 130 +++++++++++++++++++++++++++++++++++++++ >> dlls/oleaut32/usrmarshal.c | 3 +- >> dlls/oleaut32/variant.h | 2 +- >> 5 files changed, 210 insertions(+), 6 deletions(-) > It breaks the tests: > > ../../../tools/runtest -q -P wine -T ../../.. -M oleaut32.dll -p oleaut32_test.exe.so typelib && touch typelib.ok > typelib.c:3977: Test failed: typeattr->cbSizeInstance expected 4 got 16 > make: *** [typelib.ok] Error 1 > Right, sorry. I'll send a fixed one in a moment.

Jan. 30, 2014

Re: [PATCH] oleaut32: Fix RecordCopy()/RecordClear() behavior

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > --- > dlls/oleaut32/recinfo.c | 75 +++++++++++++++++++++- > dlls/oleaut32/tests/test_tlb.idl | 6 +- > dlls/oleaut32/tests/vartype.c | 130 +++++++++++++++++++++++++++++++++++++++ > dlls/oleaut32/usrmarshal.c | 3 +- > dlls/oleaut32/variant.h | 2 +- > 5 files changed, 210 insertions(+), 6 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M oleaut32.dll -p oleaut32_test.exe.so typelib && touch typelib.ok typelib.c:3977: Test failed: typeattr->cbSizeInstance expected 4 got 16 make: *** [typelib.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2014

Re: [PATCH 2/2] wmp: Added 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 https://newtestbot.winehq.org/JobDetails.pl?Key=4551 Your paranoid android. === build (build) === Recreation of tests/Makefile failed

Jan. 30, 2014

Re: Fixing conflicts between WineD3D and WGL

by Henri Verbeet

On 29 January 2014 22:34, Ken Thomases <ken(a)codeweavers.com> wrote: > My point is that the current GL context is exposed through WGL but it also affects the behavior of GL functions (of course). So, while we might be able to hide the change of the current GL context from wglGetCurrentContext(), that doesn't do us any good because we need GL functions to target the right context. There's just no getting around switching the current GL context to WineD3D's when WineD3D needs to call GL functions and then back to the app's when control is returned to it. (Except Chris's point of doing all GL on a different thread.) > > Do you know what makes wglMakeCurrent() expensive? For X11, we'll still have to use glXMakeCurrent(), which sets the context drawable, even for my proposed wglMakeContextCurrentWINE(). Maybe it's the setting of the drawable that's expensive. For the Mac, we can just make the context current without setting the drawable again. That might be less expensive, although maybe there's a lot of thread state inside the GL engine that has to be swapped in and out. (I would hope that that would all be stored in the context and switching contexts would be just a matter of swapping a pointer somewhere.) > I'm not sure. I have the impression most of the time is inside the driver instead of e.g. winex11 though. >> Maybe. Note that some of the quirk detection code renders to this >> context. I think all rendering there goes to FBOs, so in that regard >> it's probably safe, but it does feel a bit fragile. For regular >> wined3d rendering we do of course need a drawable, although this may >> work out in practice. > > I'm not sure I understand. "quirk detection code renders to this context" – to which context do you refer? > The one created by wined3d_caps_gl_ctx_create(). Quirk detection code like match_broken_arb_fog() uses that context for rendering. (But only ever renders to a FBO.) > The point of this extension is just for restoring the app's GL context. It would not necessarily be used to make a WineD3D context current, it would only be used to restore the app's WGL context to be current. It doesn't take a DC so that this works even for the case where the original DC was destroyed/released. > Right. I was under the impression it would be used by wined3d_caps_gl_ctx_create() to avoid changing the current WGL DC. If it's only for restoring the application's GL context, I'm not sure how that's effectively much different from just making the application's GL context current on wined3d's DC? (I'd have to look into the details again, but IIRC that wasn't enough for bug 28869, even as a hack.)

Jan. 30, 2014

Re: [3/4] msxml3: Add separate QueryInterface implementation for IEnumVARIANT interface exported by IXMLElementCollection. Resend.

by Henri Verbeet

On 30 January 2014 06:07, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > + FIXME("interface %s not implemented\n", debugstr_guid(riid)); > + return E_NOINTERFACE; I don't know about xmlelem_collection_IEnumVARIANT_QueryInterface() specifically, but in general QueryInterface() should set *ppvObj to NULL on failure.

Jan. 30, 2014

Re: wininet: InternetGetConnectedStateExW must return TRUE for success (try 2)

by Bruno Jesus

On Thu, Jan 30, 2014 at 8:22 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 29 January 2014 23:01, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >> Citavi relies on == TRUE comparison so return TRUE instead of != FALSE >> > I think that in general this kind of change benefits from a comment > indicating that the extra compare is on purpose, mostly to avoid > someone from removing it again in the future. OK, I'll send an updated version later. Thanks, Bruno

Jan. 30, 2014

Re: [2/2] kernel32: Don't leak extrabuf when HeapReAlloc fails

by Henri Verbeet

On 29 January 2014 23:41, André Hentschel <nerv(a)dawncrow.de> wrote: > - extrabuf = HeapReAlloc( GetProcessHeap(), 0, extrabuf, ebufsize ) ; > + if (newbuf = HeapReAlloc( GetProcessHeap(), 0, extrabuf, ebufsize )) > + extrabuf = newbuf; > + else > + break; This will introduce a warning: computername.c: In function ‘dns_gethostbyname’: computername.c:90:9: warning: suggest parentheses around assignment used as truth value [-Wparentheses] I happen to think + if (!(newbuf = HeapReAlloc( GetProcessHeap(), 0, extrabuf, ebufsize ))) + break; + extrabuf = newbuf; would be slightly nicer anyway.

Jan. 30, 2014