wine-devel May 2017

wine-devel@winehq.org

52 participants
182 discussions

Re: d3d11/tests: Add test for the SM4 instruction continuec.
by Henri Verbeet 16 May '17

16 May '17

On 16 May 2017 at 17:47, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > To get fxc to output continuec_z/continuec_nz instead of an if-block > with a normal continue inside, the shaders have been compiled with > the /Gfa flag. > Could you add that as a comment in the code itself?

1 0

Re: [PATCH 4/4] server: Don't change clipboard sequnce number on delayed data rendering
by Marvin 16 May '17

16 May '17

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=30988 Your paranoid android. === w8 (32 bit clipboard) === clipboard.c:399: Test failed: GlobalGetAtomNameA should fail clipboard.c:400: Test failed: err -559038737

1 0

Re: [PATCH 1/3] ws2_32: Don't try to match host name in getaddrinfo if AI_NUMERICHOST hint is specified.
by Marvin 16 May '17

16 May '17

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=30982 Your paranoid android. === w7u (32 bit sock) === sock.c:6146: Test failed: Expected event sequence [FD_READ(0)], got []

1 0

Re: wined3d: Implement SM4 continuec opcode.
by Henri Verbeet 16 May '17

16 May '17

On 14 May 2017 at 18:54, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > Works just like breakc and retc. > > Signed-off-by: Sven Hesse <drmccoy(a)drmccoy.de> > --- > dlls/wined3d/arb_program_shader.c | 1 + > dlls/wined3d/glsl_shader.c | 2 ++ > dlls/wined3d/shader.c | 1 + > dlls/wined3d/shader_sm4.c | 3 +++ > dlls/wined3d/wined3d_private.h | 1 + > 5 files changed, 8 insertions(+) > Thanks. I'll take this as it is, although a small test using the instruction would be nice.

2 1

Re: rpcrt4: Use standard Wine list to store connections in RpcServerProtseq.
by Alexandre Julliard 16 May '17

16 May '17

Jacek Caban <jacek(a)codeweavers.com> writes: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/rpcrt4/rpc_binding.h | 2 +- > dlls/rpcrt4/rpc_server.c | 18 ++++---- > dlls/rpcrt4/rpc_server.h | 2 +- > dlls/rpcrt4/rpc_transport.c | 110 > +++++++++++++++----------------------------- > 4 files changed, 50 insertions(+), 82 deletions(-) This breaks the Windows build: i686-w64-mingw32-gcc -c -o rpc_transport.o ../../../wine/dlls/rpcrt4/rpc_transport.c -I. -I../../../wine/dlls/rpcrt4 \ -I../../include -I../../../wine/include -D__WINESRC__ -D_RPCRT4_ -DMSWMSG -D_REENTRANT -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla \ -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer \ -g -O2 -fno-diagnostics-show-caret -D_WIN32 In file included from ../../../wine/include/windef.h:266:0, from ../../../wine/include/windows.h:37, from ../../../wine/include/winsock.h:110, from ../../../wine/include/winsock2.h:47, from ../../../wine/include/ws2tcpip.h:22, from ../../../wine/dlls/rpcrt4/rpc_transport.c:40: ../../../wine/dlls/rpcrt4/rpc_transport.c: In function ‘rpcrt4_protseq_sock_get_wait_array’: ../../../wine/dlls/rpcrt4/rpc_transport.c:1767:37: error: ‘RpcServerProtseq {aka struct _RpcServerProtseq}’ has no member named ‘conn’ ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ ../../../wine/dlls/rpcrt4/rpc_transport.c:1772:46: error: ‘RpcConnection {aka struct _RpcConnection}’ has no member named ‘Next’; did you mean ‘exp’? ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ ../../../wine/dlls/rpcrt4/rpc_transport.c:1789:37: error: ‘RpcServerProtseq {aka struct _RpcServerProtseq}’ has no member named ‘conn’ ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ ../../../wine/dlls/rpcrt4/rpc_transport.c:1803:46: error: ‘RpcConnection {aka struct _RpcConnection}’ has no member named ‘Next’; did you mean ‘exp’? ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ ../../../wine/dlls/rpcrt4/rpc_transport.c: In function ‘rpcrt4_protseq_sock_wait_for_new_connection’: ../../../wine/dlls/rpcrt4/rpc_transport.c:1846:41: error: ‘RpcServerProtseq {aka struct _RpcServerProtseq}’ has no member named ‘conn’ ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ ../../../wine/dlls/rpcrt4/rpc_transport.c:1850:50: error: ‘RpcConnection {aka struct _RpcConnection}’ has no member named ‘Next’; did you mean ‘exp’? ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ Makefile:737: recipe for target 'rpc_transport.o' failed -- Alexandre Julliard julliard(a)winehq.org

4 6

Re: [PATCH 3/6] d3dx9: Match native out of bounds array selector index handling.
by Matteo Bruni 16 May '17

16 May '17

2017-05-12 14:24 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index 9c07f9c..21aa5d7 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -1051,7 +1051,9 @@ static HRESULT d3dx9_get_param_value_ptr(struct d3dx_pass *pass, struct d3dx_sta > FIXME("Preshader structure is null.\n"); > return D3DERR_INVALIDCALL; > } > - if (update_all || is_param_eval_input_dirty(param->param_eval)) > + /* According to the tests, native d3dx handles the case of array index evaluated to -1 > + * in a specific way. */ > + if (state->index == 0xffffffffu || is_param_eval_input_dirty(param->param_eval, pass->update_version)) Hmm, so that's the index value set at initialization, thus getting a -1 in the first evaluation ends up breaking the "selector changed" check in native? You might want to spell that out in some form in the comment. AFAIU there is no other way a -1 is stored in state->index, correct?

2 3

Re: [PATCH 2/6] d3dx9: Use versioned parameter updates instead of 'dirty' flags.
by Matteo Bruni 16 May '17

16 May '17

2017-05-12 14:24 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Looping through shared parameters in set_dirty() which is removed by this patch > has a major performance impact on parameter update for applications creating a > lot of effects and sharing parameters between them, which is a common case. > Using versioned scheme also allows for some further optimization. > > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> I don't have serious issues with this patch but I also have a number of questions so I don't feel like signing it off either. Sorry :/ > @@ -163,6 +163,7 @@ struct d3dx_const_tab > unsigned int const_set_size; > struct d3dx_const_param_eval_output *const_set; > const enum pres_reg_tables *regset2table; > + ULONG64 update_version; > }; Is it necessary? Could you do without it, using the pass version instead? > struct d3dx_shared_data; > > @@ -213,6 +214,8 @@ struct d3dx_parameter > UINT bytes; > DWORD runtime_flags; > DWORD object_id; > + ULONG64 update_version; > + ULONG64 *update_version_counter; I don't like the "update_version_counter" name that much but I don't have particularly good suggestions. pass_update_version? current_update_version? parent_update_version? new_update_version? > +static inline ULONG64 get_update_version_counter(ULONG64 *update_version_counter) > +{ > + return ++*update_version_counter; > +} Maybe it's just me but it's a bit surprising to see this get_x() function having side effects. Not sure how to call it. next_update_version()? inc_update_version_counter()? > +static inline BOOL is_param_dirty(struct d3dx_parameter *param, ULONG64 update_version) > +{ > + struct d3dx_shared_data *shared_data; > + > + if ((shared_data = param->top_level_param->u.shared_data)) > + return update_version < shared_data->update_version; > + else > + return update_version < param->top_level_param->update_version; > +} Did you try if a unified update_version pointer looks any nicer? Especially considering that you have a more or less matching *update_version_counter at the moment. > HRESULT d3dx_evaluate_parameter(struct d3dx_param_eval *peval, > - const struct d3dx_parameter *param, void *param_value, BOOL update_all) DECLSPEC_HIDDEN; > + const struct d3dx_parameter *param, void *param_value) DECLSPEC_HIDDEN; I guess this has to do with the update_version in struct d3dx_const_tab. I might be missing something, in that case please clue me. > +static ULONG64 get_effect_update_version_counter(struct d3dx9_base_effect *base) > +{ > + return get_update_version_counter(get_update_version_counter_ptr(base)); > } Same naming caveat here. > -static void clear_dirty_params(struct d3dx9_base_effect *base) > +static void set_dirty(struct d3dx_parameter *param) > { > - unsigned int i; > + struct d3dx_shared_data *shared_data; > + struct d3dx_parameter *top_param = param->top_level_param; > + ULONG64 new_update_version = get_update_version_counter(top_param->update_version_counter); > > - for (i = 0; i < base->parameter_count; ++i) > - base->parameters[i].runtime_flags &= ~PARAMETER_FLAG_DIRTY; > + if ((shared_data = top_param->u.shared_data)) > + shared_data->update_version = new_update_version; > + else > + top_param->update_version = new_update_version; > } Another option would be NOT to increment the effect / pool counter on each set_dirty() but instead only increment it in BeginPass() and CommitChanges(), after you're done with the update (or well, it's fine at almost any point given that we don't have to care about races). It seems a bit better to me, unless I'm overlooking something and it won't work. > static HRESULT set_string(char **param_data, const char *string) > @@ -3078,6 +3074,7 @@ static HRESULT d3dx9_apply_pass_states(struct ID3DXEffectImpl *effect, struct d3 > unsigned int i; > HRESULT ret; > HRESULT hr; > + ULONG64 new_update_version = get_effect_update_version_counter(&effect->base_effect); > > TRACE("effect %p, pass %p, state_count %u.\n", effect, pass, pass->state_count); > > @@ -3109,7 +3106,7 @@ static HRESULT d3dx9_apply_pass_states(struct ID3DXEffectImpl *effect, struct d3 > } > effect->material_updated = FALSE; > > - clear_dirty_params(&effect->base_effect); > + pass->update_version = new_update_version; > return ret; > } Right, here is where I'd update the counter.

2 3

Re: wrc: Allow quotes in resource nameID.
by Alexandre Julliard 16 May '17

16 May '17

Artur Świgoń <artur.swigon(a)gmail.com> writes: > @@ -138,6 +142,14 @@ static int wbufalloc = 0; > > static int current_codepage = -1; /* use language default */ > > +/* Used for differentiating between single- and double-quoted nameID's */ > +static int id_dblquote = 0; > + > +/* Used for catching first (quoted) nameID before wanted_id is set. > + * This variable is reset to 0 once the first ID (quoted or not), string or > + * data has been encountered */ > +static int id_initial = 1; That's a bit hackish. Couldn't you simply set the initial state appropriately instead of introducing a separate variable? > @@ -402,8 +414,30 @@ static unsigned long xstrtoul(const char *nptr, char **endptr, int base) > 0[oO][0-7]+[lL]? { parser_lval.num = xstrtoul(yytext+2, 0, 8); > return (yytext[yyleng-1] == 'L' || yytext[yyleng-1] == 'l') ? tLNUMBER : tNUMBER; } > > +<tkid_dbl>[A-Za-z_0-9./\\\']+\" | > +<tkid_sgl>[A-Za-z_0-9./\\\"]+\' { There are more characters that should be allowed. Nested quotes are also supposed to work. -- Alexandre Julliard julliard(a)winehq.org

2 2

winetricks alldlls=builtin update based on wine-2.7
by wylda＠volny.cz 16 May '17

16 May '17

______________________________________________________________ > Od: Austin English <austinenglish(a)gmail.com> > Komu: wylda(a)volny.cz > Datum: 20.02.2017 07:07 > Předmět: Re: winetricks alldlls=builtin update based on wine-2.2 > > CC: <wine-devel(a)winehq.org> On Sun, Feb 19, 2017 at 7:51 AM, <wylda(a)volny.cz> wrote: > Hi, > in case you find it useful... > > W. Hi Wylda, Please send a pull request to https://github.com/Winetricks/winetricks/ -- -Austin GPG: 14FB D7EA A041 937B ______________________________________________________________ Hi Austin, i updated alldlls=builtin function for wine-2.7 and also fixed few things: - generates properly indentioned library list - removed nonsensical library names like "./dlls" - script generates override list matching 1:1 to wine-2.7 available list Unfortunately i not able to create pull request in github even though i have created github account right now. It's still grey out and i don't know different way to upload a patch. Anyway is there a different way to get it in, so i don't need to maintain locally? (spent whole day on this and i have no plans to learn git "details" in near futures). Best regards, W.

2 1

Re: [PATCH] user32: add GetPhysicalCursorPos/SetPhysicalCursorPos stubs (try 2)
by Dmitry Timoshkov 16 May '17

16 May '17

Austin English <austinenglish(a)gmail.com> wrote: > +BOOL WINAPI GetPhysicalCursorPos(POINT *point) > +{ > + FIXME("(%p) semi-stub: forwarding to GetCursorPos\n", point); > + return GetPhysicalCursorPos(point); > +} A copy/paste bug. -- Dmitry.

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
19
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2017