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

Re: [v5 8/8] d3dx9: Implement setting named shader constants in effect.
by Matteo Bruni March 22, 2016

March 22, 2016

2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > +HRESULT d3dx_set_shader_const_fxlc(struct ID3DXEffectImpl *effect, struct d3dx_pass *pass, > + struct d3dx_parameter *param, unsigned int vs) Using a BOOL for the vs flag seems nicer. > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index fec9de4..1770046 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -242,7 +242,7 @@ static void regstore_set_values(struct d3dx_regstore *rs, unsigned int table, vo > static unsigned int regstore_is_val_set_reg(struct d3dx_regstore *rs, unsigned int table, unsigned int reg_idx) > { > return rs->table_value_set[table][reg_idx / PRES_BITMASK_BLOCK_SIZE] & > - (1ul << (reg_idx % PRES_BITMASK_BLOCK_SIZE)); > + (1u << (reg_idx % PRES_BITMASK_BLOCK_SIZE)); When you end up changing stuff introduced in a previous patch in the series you know there is something wrong ;) I guess it's a rebase glitch (by any chance, was this a remnant of a try with the uint_ptr idea you mentioned earlier?) > +HRESULT d3dx_param_eval_set_shader_constants(struct IDirect3DDevice9 *device, struct d3dx_param_eval *peval) > +{ > + HRESULT hr, res; > + struct d3dx_preshader *pres = &peval->pres; > + struct d3dx_regstore *rs = &pres->regs; > + > + TRACE("device %p, peval %p, param_type %u.\n", device, peval, peval->param_type); > + > + if (FAILED(hr = set_constants(rs, &pres->inputs))) > + return hr; > + if (FAILED(hr = execute_preshader(pres))) > + return hr; > + if (FAILED(hr = set_constants(rs, &peval->shader_inputs))) > + return hr; > + > + #define SET_TABLE(table, func_suff, type) \ > + { \ > + unsigned int is, n; \ > + \ > + is = 0; \ > + while (is < rs->table_sizes[table]) \ > + {\ > + n = 0; \ > + while (is < rs->table_sizes[table] && !regstore_is_val_set_reg(rs, table, is)) \ > + is++; \ > + while (is + n < rs->table_sizes[table] && regstore_is_val_set_reg(rs, table, is + n)) \ > + n++; \ > + if (!n) \ > + continue; \ > + TRACE("setting %u consts at %u.\n", n, is); \ > + hr = IDirect3DDevice9_##func_suff(device, is, \ > + (const type *)rs->tables[table] + is * table_info[table].reg_component_count, n); \ > + if (FAILED(hr)) \ > + { \ > + ERR(#func_suff " failed, hr %#x.\n", hr); \ > + res = hr; \ > + } \ > + is += n; \ > + } \ > + regstore_reset_table(rs, table); \ > + } > + res = D3D_OK; > + if (peval->param_type == D3DXPT_VERTEXSHADER) > + { > + SET_TABLE(PRES_REGTAB_OCONST, SetVertexShaderConstantF, float); > + SET_TABLE(PRES_REGTAB_OICONST, SetVertexShaderConstantI, int); > + SET_TABLE(PRES_REGTAB_OBCONST, SetVertexShaderConstantB, BOOL); > + } > + else if (peval->param_type == D3DXPT_PIXELSHADER) > + { > + SET_TABLE(PRES_REGTAB_OCONST, SetPixelShaderConstantF, float); > + SET_TABLE(PRES_REGTAB_OICONST, SetPixelShaderConstantI, int); > + SET_TABLE(PRES_REGTAB_OBCONST, SetPixelShaderConstantB, BOOL); > + } > + else > + { > + FIXME("Unexpected parameter type %u.\n", peval->param_type); > + return D3DERR_INVALIDCALL; > + } > + #undef SET_TABLE This is certainly hard to handle nicely because of the multiple similar d3d9 functions with slightly different signatures but I think it's better to avoid macros (especially such large ones) as much as possible. There are multiple ways to achieve that. Perhaps the easiest one is to turn SET_TABLE into a function taking an array of enum PRES_REG_TABLES (which, btw, should be lowercase) and the shader type as additional parameters, loop over the tables and call the correct d3d9 function by using two levels of switches (or ifs). The type isn't really necessary, you can calculate the offset with table_info[].component_size.

2 2

Re: [v5 1/8] d3dx9: Add test for preshader in effect.
by Matteo Bruni March 22, 2016

March 22, 2016

2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > +struct test_struct > +{ > + float3 v1; > + float fv; > + float4 v2; > +}; > + > +test_struct ts1[1] = {{{9, 10, 11}, 12, {13, 14, 15, 16}}}; > +test_struct ts2[2] = {{{0, 0, 0}, 0, {0, 0, 0, 0}}, {{1, 2, 3}, 4, {5, 6, 7, 8}}}; Is it also possible to create a struct with an array field? And an array of those structs? > + static const struct > + { > + const char *comment; > + BOOL todo[4]; > + unsigned int result[4]; > + } > + test_effect_preshader_op_results[] = > + { > + {"1 / op", { TRUE, TRUE, TRUE, TRUE}, {0x7f800000, 0xff800000, 0xbee8ba2e, 0x00200000}}, > +#if __x86_64__ > + {"rsq", { TRUE, TRUE, TRUE, TRUE}, {0x7f800000, 0x7f800000, 0x3f2c985d, 0x1f800000}}, > +#else > + {"rsq", { TRUE, TRUE, TRUE, TRUE}, {0x7f800000, 0x7f800000, 0x3f2c985c, 0x1f800001}}, > +#endif > + {"mul", { TRUE, TRUE, TRUE, TRUE}, {0x00000000, 0x80000000, 0x40d33334, 0x7f800000}}, > + {"add", {FALSE, TRUE, TRUE, TRUE}, {0x3f800000, 0x40000000, 0xc0a66666, 0x7f7fffff}}, > + {"lt", {FALSE, FALSE, TRUE, FALSE}, {0x3f800000, 0x3f800000, 0x00000000, 0x00000000}}, > + {"ge", { TRUE, TRUE, FALSE, TRUE}, {0x00000000, 0x00000000, 0x3f800000, 0x3f800000}}, > + {"neg", { TRUE, TRUE, TRUE, TRUE}, {0x80000000, 0x00000000, 0x400ccccd, 0xff7fffff}}, > + {"rcp", { TRUE, TRUE, TRUE, TRUE}, {0x7f800000, 0xff800000, 0xbee8ba2e, 0x00200000}}, > + {"frac", {FALSE, FALSE, TRUE, FALSE}, {0x00000000, 0x00000000, 0x3f4ccccc, 0x00000000}}, > + {"min", {FALSE, TRUE, TRUE, TRUE}, {0x00000000, 0x80000000, 0xc0400000, 0x40800000}}, > + {"max", { TRUE, TRUE, TRUE, TRUE}, {0x3f800000, 0x40000000, 0xc00ccccd, 0x7f7fffff}}, > +#if __x86_64__ > + {"sin", {FALSE, TRUE, TRUE, TRUE}, {0x00000000, 0x80000000, 0xbf4ef99e, 0xbf0599b3}}, > + {"cos", { TRUE, TRUE, TRUE, TRUE}, {0x3f800000, 0x3f800000, 0xbf16a803, 0x3f5a5f96}}, > +#else > + {"sin", {FALSE, TRUE, TRUE, TRUE}, {0x00000000, 0x80000000, 0xbf4ef99e, 0x3f792dc4}}, > + {"cos", { TRUE, TRUE, TRUE, TRUE}, {0x3f800000, 0x3f800000, 0xbf16a803, 0xbe6acefc}}, > +#endif > + {"den mul",{ TRUE, TRUE, TRUE, TRUE}, {0x7f800000, 0xff800000, 0xbb94f209, 0x000051ec}}, > + {"dot", {FALSE, TRUE, TRUE, FALSE}, {0x00000000, 0x7f800000, 0x41f00000, 0x00000000}}, > +#if __x86_64__ > + {"prec", { TRUE, TRUE, TRUE, FALSE}, {0x2b8cbccc, 0x2c0cbccc, 0xac531800, 0x00000000}} > +#else > + {"prec", { TRUE, TRUE, FALSE, FALSE}, {0x2b8cbccc, 0x2c0cbccc, 0x00000000, 0x00000000}} > +#endif > + }; I don't like those #ifdefs much although apparently I don't have nicer suggestions.

2 2

Re: [v5 5/8] d3dx9: Implement fxlc constants (expressions) in effect.
by Matteo Bruni March 22, 2016

March 22, 2016

2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > +static unsigned int regstore_is_val_set_reg(struct d3dx_regstore *rs, unsigned int table, unsigned int reg_idx) > +{ > + return rs->table_value_set[table][reg_idx / PRES_BITMASK_BLOCK_SIZE] & > + (1ul << (reg_idx % PRES_BITMASK_BLOCK_SIZE)); > +} Actually you don't want "ul" here, just "u". > +static void regstore_set_float(struct d3dx_regstore *rs, unsigned int table, unsigned int offset, float v) > +{ > + BYTE *p; > + unsigned int reg_idx; > + > + p = (BYTE *)rs->tables[table] + table_info[table].component_size * offset; > + switch (table_info[table].type) > + { > + case PRES_VT_FLOAT : *(float *)p = v; break; > + case PRES_VT_DOUBLE: *(double *)p = v; break; > + case PRES_VT_INT : *(int *)p = roundf(v); break; > + case PRES_VT_BOOL : *(BOOL *)p = !!v; break; > + } > + reg_idx = OFFSET2REG(table, offset); > + rs->table_value_set[table][reg_idx / PRES_BITMASK_BLOCK_SIZE] |= > + 1ul << (reg_idx % PRES_BITMASK_BLOCK_SIZE); Same here. > +static HRESULT set_constants_param(struct d3dx_regstore *rs, struct d3dx_const_tab *const_tab, > + D3DXHANDLE hc, struct d3dx_parameter *param) > +{ > + ID3DXConstantTable *ctab = const_tab->ctab; > + D3DXCONSTANT_DESC desc; > + unsigned int const_count, param_count, i, j, n, table, start_offset; > + unsigned int nminor, nmajor, major_stride, inp_ind; Nitpick, also rename nmajor/nminor to major_size or just major (resp. minor). inp_ind also feels like it has room for improvement, although I don't have any good suggestion. > +#define ARGS_ARRAY_SIZE 8 > +static HRESULT execute_preshader(struct d3dx_preshader *pres) > +{ > + unsigned int i, j, k; > + float args[ARGS_ARRAY_SIZE]; Doesn't this need to be double to preserve the precision of the immediate operands / literals? I guess that means the regstore should also be able to return doubles.

1 0

Re: [v5 3/8] d3dx9: Implement preshader parsing.
by Matteo Bruni March 22, 2016

March 22, 2016

2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > +enum PRES_VALUE_TYPE Please use lowercase for type names. > +#define OFFSET2REG(table, offset) ((offset) / table_info[table].reg_component_count) I think this could be a function instead, that's usually preferred to macros when possible. Not sure about the name, maybe get_reg_offset(). > +static HRESULT regstore_alloc_table(struct d3dx_regstore *rs, unsigned int table) > +{ > + unsigned int sz; Nitpick, I would just spell out "size", it's pretty short anyway. > +static void regstore_set_values(struct d3dx_regstore *rs, unsigned int table, void *data, > + unsigned int start_offset, unsigned int count) > +{ > + unsigned int reg_idx; > + > + if (!count) > + return; > + > + memcpy((BYTE *)rs->tables[table] + start_offset * table_info[table].component_size, > + data, count * table_info[table].component_size); > + for (reg_idx = OFFSET2REG(table, start_offset); reg_idx <= OFFSET2REG(table, start_offset + count - 1); > + ++reg_idx) > + rs->table_value_set[table][reg_idx / PRES_BITMASK_BLOCK_SIZE] |= > + 1u << (reg_idx % PRES_BITMASK_BLOCK_SIZE); This might be optimized, enabling each bit one by one doesn't seem very efficient. > +} > + > +static void dump_bytecode(void *data, unsigned int size) > +{ > + unsigned int *bytecode = (unsigned int *)data; > + unsigned int i, j, n; > + > + size /= 4; Nitpick, sizeof(*bytecode).

1 0

Re: [v4 2/6] d3dx9: add preshaders to effect.
by Matteo Bruni March 22, 2016

March 22, 2016

2016-03-17 12:59 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > +enum PRES_REG_TABLES > +{ > + PRES_REGTAB_NONE, > + PRES_REGTAB_IMMED, /* immediate double constants from CLIT */ > + PRES_REGTAB_CONST, > + PRES_REGTAB_VERTEX, /* not used */ > + PRES_REGTAB_OCONST, > + PRES_REGTAB_OBCONST, > + PRES_REGTAB_OICONST, > + PRES_REGTAB_REG, > + PRES_REGTAB_MAX, > + PRES_REGTAB_FIRST = PRES_REGTAB_IMMED, > + PRES_REGTAB_LAST = PRES_REGTAB_REG, > +}; You can drop PRES_REGTAB_NONE unless it's going to be used. > +++ b/dlls/d3dx9_36/preshader.c > @@ -0,0 +1,627 @@ > +/* > + * FX preshader parsing & execution, setting shader constants > + * from effect parameters. > + * It looks like that kind of general file description is omitted in newer source files. Maybe drop it? I don't particularly care though. > + /* TODO: use double precision for x64 arch */ > + {sizeof(float), 4, PRES_VT_FLOAT } /* PRES_REGTAB_REG */ Nitpick, just mention "64 bit" or something, we don't want to make all the non-Intel archs angry ;) > +#define PRES_VS_BITS_PER_WORD (sizeof(unsigned int) * 8) What does the _VS_ part of the name mean? I'm also a bit thrown off by the _WORD part, mostly because in Win32 WORD is a 16 bit while DWORD is 32 bit and unsigned int is also 32 bit. Maybe it's just me, I don't know. > +static void dump_shader_bytecode(void *data, unsigned int size) > +{ > + unsigned int *words = (unsigned int *)data; Same here. I guess you could call it "bytecode" or such. > +static unsigned int *find_bytecode_comment(unsigned int *ptr, unsigned int fourcc) > +{ > + while ((*ptr & 0xFFFF) == 0xFFFE) A couple leftover uppercase hexadecimal constants. > + hr = D3DXGetShaderConstantTable(byte_code, &ctab); > + if (FAILED(hr) || !ctab) > + { > + TRACE("Could not get CTAB data, hr %#x.\n", hr); > + /* returning OK is not a typo */ > + return D3D_OK; > + } Sorry, back to that comment again. I guess it would be better to spell out why that's the intended return value instead (e.g. "Not returning an error, shaders without a CTAB are valid."). > +static void dump_arg(struct d3dx_regstore *rs, struct d3dx_pres_operand *arg, int component_count) > +{ > + static const char *xyzw_str = "xyzw"; > + unsigned int i, table; > + > + table = arg->table; > + if (table == PRES_REGTAB_IMMED) > + { > + TRACE("("); > + for (i = 0; i < component_count; ++i) > + TRACE(i < component_count - 1 ? "%lf, " : "%lf", > + ((double *)rs->tables[PRES_REGTAB_IMMED])[arg->offset + i]); %lf is not right, %f already expects a double. I'd just use %.16e (which has the added benefit of showing something different from 0 in the "precision" test from the previous patch). Another option would be to use the same format used by MS when disassembling shaders, although this seems to be a case where it's worth diverging. > +static void dump_ins(struct d3dx_regstore *rs, struct d3dx_pres_ins *ins) > +{ > + unsigned int i; > + > + TRACE(" %s ", pres_op_info[ins->op].mnem); > + dump_arg(rs, &ins->output, pres_op_info[ins->op].func_all_comps ? 1 : ins->component_count); > + for (i = 0; i < pres_op_info[ins->op].input_count; ++i) > + { > + TRACE(","); With a blank after the comma it would be prettier. There is still some inconsistent formatting (e.g. "== NULL" vs "!", uppercase hexadecimals, cnt vs count). A possible idea to split this patch further: what if you move the addition of (most of) the contents of the various functions in preshader.c to a separate patch? That is, make a patch which adds the various calls to d3dx_create_param_eval(), d3dx_free_param_eval() and similar (i.e. most if not all the changes to effect.c) but only introduces a skeleton implementation of those functions in preshader.c. Those are actually fleshed out only in the next patch. Many of the new preshader-related definitions can probably also go into the second patch. The traces of the disassembled preshader can also potentially go to a separate patch (leaving only dump_shader_bytecode() in the initial implementation - btw, I think it should be called dump_preshader_bytecode() given the renaming of the other stuff).

2 2

Re: [tools 1/2] Handle "midl_pragma warning" statement in parser
by Nikolay Sivov March 22, 2016

March 22, 2016

On 20.03.2016 13:11, Bolotov Sergey wrote: > Signed-off-by: Bolotov Sergey <bolotov.s.s(a)yandex.ru> > --- > tools/widl/parser.h | 2 ++ > tools/widl/parser.l | 25 +++++++++++++++++++++++++ > tools/widl/parser.y | 38 +++++++++++++++++++++++++++++++++++++- > tools/widl/widltypes.h | 7 +++++++ > 4 files changed, 71 insertions(+), 1 deletion(-) > > diff --git a/tools/widl/parser.h b/tools/widl/parser.h > index 1bcc3c1..c15d874 100644 > --- a/tools/widl/parser.h > +++ b/tools/widl/parser.h > @@ -45,6 +45,8 @@ void pop_import(void); > > int is_type(const char *name); > > +int do_warning(char *toggle, warning_list_t *wnum); > + > extern char *temp_name; > > #endif > diff --git a/tools/widl/parser.l b/tools/widl/parser.l > index 5c2dcab..65e0f45 100644 > --- a/tools/widl/parser.l > +++ b/tools/widl/parser.l > @@ -164,6 +164,7 @@ UUID *parse_uuid(const char *u) > yy_pop_state(); > } > <PP_PRAGMA>[^\n]* parser_lval.str = xstrdup(yytext); yy_pop_state(); return aPRAGMA; > +<INITIAL>^{ws}*"midl_pragma warning" return tPRAGMA_WARNING; > <INITIAL,ATTR>\" yy_push_state(QUOTE); cbufidx = 0; > <QUOTE>\" { This is wrong, any number of spaces is allowed before 'warning'. > yy_pop_state(); > @@ -555,3 +556,27 @@ void abort_import(void) > for (ptr=0; ptr<import_stack_ptr; ptr++) > unlink(import_stack[ptr].temp_name); > } > + > +static void warning_disable(int warning) > +{ > + printf("disable %d\n", warning); > +} > + > +static void warning_enable(int warning) > +{ > + printf("enable %d\n", warning); > +} > + > +int do_warning(char *toggle, warning_list_t *wnum) > +{ > + warning_t *warning; > + if(!strcmp(toggle, "disable")) > + LIST_FOR_EACH_ENTRY(warning, wnum, warning_t, entry) > + warning_disable(warning->num); > + else if(!strcmp(toggle, "enable")) > + LIST_FOR_EACH_ENTRY(warning, wnum, warning_t, entry) > + warning_enable(warning->num); > + else > + return 0; > + return 1; > +} You remove this in next patch, I think it'd be enough to add parser support first, so widl does not fail on such construct, and add handling as 2/2. Why do you need this in a first place? Is it to process some third party idls?

1 0

Re: [PATCH 1/6] ddraw/tests: Rewrite blt_test().
by Marvin March 22, 2016

March 22, 2016

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=21588 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w8 (32 bit visual) === visual.c:1387: Test failed: unexpected colortable on offscreen surface === w864 (32 bit visual) === visual.c:1387: Test failed: unexpected colortable on offscreen surface === 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:1387: Test failed: unexpected colortable on offscreen surface === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Student interested in GSoC 2016 implementing D3DX9 API idea
by Xu Zhao March 22, 2016

March 22, 2016

Hello Wine Community, First congrats that Wine Project get accepted into GSoC 2016 summer organization! I am currently a PhD student in University of Toronto and I am interested in the D3DX9 API implementation task. Mainly because I would like to see more games can run in wine because of my work! My research field is operating system so I am a pretty good C/CPP programmer. However I am not very familiar with DirectX related programming and hopefully I can get some help from the community, like where to start. I have read the wiki entry of D3DX9 API and want to get some help in selecting a reasonable sized API list, maybe someone can reply and provide some help? Thank you! Regards, - Xu -- Xu Zhao i(a)xuzhao.net

2 2

Server Downtime 2016-03-16 19:00 CDT
by Jeremy Newman March 22, 2016

March 22, 2016

WineHQ.org and all related websites will be offline for maintenance and upgrades on 2016-03-16 starting at 19:00 CDT. This downtime should last 1-2 hours. Some websites may remain offline longer if they need additional work. I'll reply to this post when everything looks to be back online. -N

4 6

Re: [PATCH 2/6] ddraw/tests: Get rid of the unused "d3d" variable in test_shademode().
by Marvin March 22, 2016

March 22, 2016

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=21589 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH] vulkan-icd: Add stub dll.
by Roderick Colenbrander March 22, 2016

March 22, 2016

Hi Gabríel, Thanks for your patch. Depending on the direction where you intend to take this, I'm not sure if we need this dll. Note I haven't done much with Vulkan myself yet, but following the analogy of opengl32, the ICD portion should be inside winex11.drv (and our other drivers). It is what should export this function call ultimately and similar needs to host the x11 related vulkan code, which has to live in here as well, because such code is not supposed to live outside winex11.drv. Thanks, Roderick On Mon, Mar 21, 2016 at 8:26 PM, Gabríel Arthúr Pétursson <gabriel(a)system.is> wrote: > Signed-off-by: Gabríel Arthúr Pétursson <gabriel(a)system.is> > --- > configure.ac | 1 + > dlls/vulkan-icd/Makefile.in | 2 ++ > dlls/vulkan-icd/vulkan-icd.spec | 1 + > 3 files changed, 4 insertions(+) > create mode 100644 dlls/vulkan-icd/Makefile.in > create mode 100644 dlls/vulkan-icd/vulkan-icd.spec > > diff --git a/configure.ac b/configure.ac > index 77c54c8..04ddb54 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -3310,6 +3310,7 @@ WINE_CONFIG_DLL(vnbt.vxd,enable_win16) > WINE_CONFIG_DLL(vnetbios.vxd,enable_win16) > WINE_CONFIG_DLL(vssapi) > WINE_CONFIG_DLL(vtdapi.vxd,enable_win16) > +WINE_CONFIG_DLL(vulkan-icd,,[implib]) > WINE_CONFIG_DLL(vwin32.vxd,enable_win16) > WINE_CONFIG_DLL(w32skrnl,enable_win16) > WINE_CONFIG_DLL(w32sys.dll16,enable_win16) > diff --git a/dlls/vulkan-icd/Makefile.in b/dlls/vulkan-icd/Makefile.in > new file mode 100644 > index 0000000..c41bf8f > --- /dev/null > +++ b/dlls/vulkan-icd/Makefile.in > @@ -0,0 +1,2 @@ > +MODULE = vulkan-icd.dll > +IMPORTLIB = vulkan-icd > diff --git a/dlls/vulkan-icd/vulkan-icd.spec b/dlls/vulkan-icd/vulkan-icd.spec > new file mode 100644 > index 0000000..db3616e > --- /dev/null > +++ b/dlls/vulkan-icd/vulkan-icd.spec > @@ -0,0 +1 @@ > +@ stub vk_icdGetInstanceProcAddr > -- > 2.7.0 > > >

2 3

Re: services: Make release_process() static.
by Sebastian Lackner March 22, 2016

March 22, 2016

On 22.03.2016 11:26, Francois Gouget wrote: > Signed-off-by: Francois Gouget <fgouget(a)free.fr> > --- > programs/services/services.c | 12 ++++++------ > programs/services/services.h | 1 - > 2 files changed, 6 insertions(+), 7 deletions(-) > I do not mind if this patch is accepted, but follow patches would have to undo this change again. We also need the function from other services files.

1 0

Re: [PATCH 2/2] ddraw/tests: Use SetRect() instead of open coding it.
by Marvin March 22, 2016

March 22, 2016

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=21571 Your paranoid android. === w864 (32 bit d3d) === d3d.c:2311: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2311: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2311: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2311: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2492: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2636: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2636: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2636: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2636: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit d3d) === d3d.c:2311: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2311: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2311: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2311: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2492: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2636: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2636: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2636: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2636: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w8 (32 bit visual) === visual.c:1478: Test failed: unexpected colortable on offscreen surface === 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:1478: Test failed: unexpected colortable on offscreen surface === 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:1478: Test failed: unexpected colortable on offscreen surface

2 1

Failing mshtml:xmlhttprequest test
by Francois Gouget March 22, 2016

March 22, 2016

Since the WineHQ.org upgrade the mshtml:xmlhttprequest test has been failing on all platforms: xmlhttprequest.c:448: Test failed: Expect Server: Apache, got L"Apache/2.4.10 (Debian)" Due to: 583 static const struct HEADER_TYPE expect_headers[] = { 584 {"Server", "Apache"}, 585 {"Accept-Ranges", "bytes"}, Fixing the failure is easy, but maybe the test should be more flexible? It could be annoying to have to upgrade it with each minor server upgrade. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Theory is where you know everything but nothing works. Practice is where everything works but nobody knows why. Sometimes they go hand in hand: nothing works and nobody knows why.

2 1

Re: [PATCH 1/2] ddraw/tests: Fix copy&paste errors in open coded SetRect()
by Marvin March 22, 2016

March 22, 2016

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=21570 Your paranoid android. === w8 (32 bit visual) === visual.c:1486: Test failed: unexpected colortable on offscreen surface === 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:1486: Test failed: unexpected colortable on offscreen surface === 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:1486: Test failed: unexpected colortable on offscreen surface

2 1

Re: [PATCH] msctf/tests: Fix a crash on unsupported interface
by Marvin March 22, 2016

March 22, 2016

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=21569 Your paranoid android. === w864 (32 bit inputprocessor) === inputprocessor.c:787: Test failed: Deactivation came unexpectedly === w1064 (64 bit inputprocessor) === inputprocessor.c:787: Test failed: Deactivation came unexpectedly

1 0

Re: [PATCH 2/2] msctf: Added stub ITextStoreACPServices support for context ITextStoreACPSink
by Marvin March 22, 2016

March 22, 2016

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=21563 Your paranoid android. === w864 (32 bit inputprocessor) === inputprocessor.c:793: Test failed: Deactivation came unexpectedly

2 1

Re: [PATCH 1/2] d3drm: Move struct d3drm_texture to header for global access.
by Henri Verbeet March 21, 2016

March 21, 2016

On 20 March 2016 at 19:24, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -1038,12 +1029,11 @@ static const struct IDirect3DRMTexture3Vtbl d3drm_texture3_vtbl = > d3drm_texture3_SetValidationCallback, > }; > > -HRESULT Direct3DRMTexture_create(REFIID riid, IUnknown **out) > +HRESULT d3drm_texture_create(struct d3drm_texture **texture) > { > struct d3drm_texture *object; > - HRESULT hr; > > - TRACE("riid %s, out %p.\n", debugstr_guid(riid), out); > + TRACE("out %p.\n", texture); You'll also want to fix the TRACE message here.

2 1

Re: [PATCH] include: Use fixed stack size for rbtree.
by Henri Verbeet March 21, 2016

March 21, 2016

On 20 March 2016 at 21:05, Gabríel Arthúr Pétursson <gabriel(a)system.is> wrote: > struct wine_rb_stack > { > - struct wine_rb_entry ***entries; > size_t count; > - size_t size; > + struct wine_rb_entry **entries[2 * sizeof(void *) * 8]; > }; Why do you think this is a good idea?

4 12

Re: shell32: Don't return argified string in FindExecutable
by Alexandre Julliard March 21, 2016

March 21, 2016

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -698,10 +698,15 @@ static UINT SHELL_FindExecutable(LPCWSTR lpPath, LPCWSTR lpFile, LPCWSTR lpVerb, > > if (retval > 32) > { > - DWORD finishedLen; > - SHELL_ArgifyW(lpResult, resultLen, command, xlpFile, pidl, args, &finishedLen); > - if (finishedLen > resultLen) > - ERR("Argify buffer not large enough.. truncated\n"); > + if (exec_only) > + lstrcpynW(lpResult, command, resultLen); > + else > + { > + DWORD finishedLen; > + SHELL_ArgifyW(lpResult, resultLen, command, xlpFile, pidl, args, &finishedLen); > + if (finishedLen > resultLen) > + ERR("Argify buffer not large enough.. truncated\n"); > + } That's not much of an improvement, and I don't see why it should be limited to FindExecutable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: bcrypt: Added BCryptHash function.
by Hans Leidekker March 21, 2016

March 21, 2016

On Fri, 2016-03-18 at 09:26 -0700, Patrick Armstrong wrote: > +NTSTATUS WINAPI BCryptHash( BCRYPT_ALG_HANDLE algorithm, UCHAR *secret, ULONG secretlen, > + UCHAR *input, ULONG inputlen, UCHAR *output, ULONG outputlen ) > +{ > + NTSTATUS status; > + BCRYPT_ALG_HANDLE handle; This should be BCRYPT_HASH_HANDLE. > + TRACE( "%p, %p, %u, %p, %u, %p, %u\n", algorithm, secret, secretlen, > + input, inputlen, output, outputlen ); > + > + status = BCryptCreateHash( algorithm, &handle, NULL, 0, secret, secretlen, 0); > + if (status != STATUS_SUCCESS) > + { > + goto cleanup_bcrypt_hash; > + } There's no need for cleanup here. > + status = BCryptHashData( handle, input, inputlen, 0 ); > + if (status != STATUS_SUCCESS) > + { > + goto cleanup_bcrypt_hash; > + } >+ > + status = BCryptFinishHash( handle, output, outputlen, 0 ); > + if (status != STATUS_SUCCESS) > + { > + goto cleanup_bcrypt_hash; > + } > + > + return BCryptDestroyHash( handle ); > + > +cleanup_bcrypt_hash: > + > + BCryptDestroyHash( handle ); > + > + return status; > +} I don't think this goto is better than repeated BCryptDestroyHash calls.

1 0

Re: [v4 3/6] d3dx9: implement fxlc constants (expressions) in effect.
by Matteo Bruni March 21, 2016

March 21, 2016

2016-03-17 12:59 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -2616,7 +2630,7 @@ static void d3dx9_set_material_parameter(enum MATERIAL_TYPE op, D3DMATERIAL9 *ma > D3DCOLORVALUE c = *(D3DCOLORVALUE *)value; > > TRACE("%s, value (%f %f %f %f).\n", material_tbl[op].name, c.r, c.g, c.b, c.a); > - *(D3DCOLORVALUE *)((char *)material + material_tbl[op].offset) = c; > + *(D3DCOLORVALUE *)((BYTE *)material + material_tbl[op].offset) = c; > break; > } > default: While you're at it, you could change the format strings to use %.8e for the float values. > +static void regstore_reset_table(struct d3dx_regstore *rs, unsigned int table) > +{ > + unsigned int sz; > + > + sz = rs->table_sizes[table] * table_info[table].reg_component_count * table_info[table].component_size; > + > + memset(rs->tables[table], 0, sz); > + memset(rs->table_value_set[table], 0, > + sizeof(*rs->table_value_set[table]) * > + ((rs->table_sizes[table] + PRES_VS_BITS_PER_WORD - 1) / PRES_VS_BITS_PER_WORD)); > +} This function is unused and the compiler should throw a warning about it. > + rs->table_value_set[table][reg_idx / PRES_VS_BITS_PER_WORD] |= > + 1 << (reg_idx % PRES_VS_BITS_PER_WORD); That should be "1u", otherwise here shifting by 31 is technically undefined behavior and there are some compilers that complain about it. The line continuation is also misindented. > + while (param->member_count && param->element_count) > + { > + if (param->element_count > 1) > + { > + FIXME("Unexpected param having both elements and members.\n"); > + return D3DERR_INVALIDCALL; > + } > + param = &param->members[0]; > + } I don't quite understand what you're trying to do here but it doesn't look right. > + TRACE("%s rows %u, par columns %u, par class %u, par flags %u, par bytes %u, c rows %u," \ > + "c columns %u, c class %u, c bytes %u, transpose %u.\n", > + desc.Name, param->rows, param->columns, param->class, param->flags, param->bytes, > + desc.Rows, desc.Columns, desc.Class, desc.Bytes, transpose); I would make two separate TRACEs for parameter and constant info. Also the string comes from the application so you should use debugstr_a(). Something like: TRACE("Constant %s rows %u, columns %u, class %u, bytes %u.\n", debugstr_a(desc.Name), desc.Rows, desc.Columns, desc.Class, desc.Bytes); TRACE("Parameter rows %u, columns %u, class %u, flags %#x, bytes %u, transpose %#x.\n", param->rows, param->columns, param->class, param->flags, param->bytes, transpose); Gmail will probably mangle the code but you get the point.

2 2

Wine fonts
by Jens Reyer March 21, 2016

March 21, 2016

Hi, I'm currently working on the correct Debian packaging of the fonts. Afaik vanilla wine installs the following ttf-fonts: marlett.ttf symbol.ttf tahomabd.ttf tahoma.ttf wingding.ttf I realize that these are indeed necessary for the fon-fonts to display correctly. However in the source there are additionally the following ttf: courier.ttf fixedsys_jp.ttf fixedsys.ttf ms_sans_serif.ttf small_fonts_jp.ttf small_fonts.ttf system.ttf Shouldn't these be installed, too? I haven't noted any difference, but that could be because I don't know how to test this. Can anybody with more knowledge enlighten me? Thanks in advance! jre

2 1

Re: winscard: add stubs for SCardListReadersA/W (try 4)
by Nikolay Sivov March 21, 2016

March 21, 2016

Spec file needs fixing too.

1 0

Re: winscard: add stubs for SCardListReadersA/W (try 3)
by Nikolay Sivov March 21, 2016

March 21, 2016

> +LONG WINAPI SCardListReadersA(SCARDCONTEXT context, const CHAR *groups, char *readers, DWORD *buflen) > +{ > + FIXME("(%lx, %s, %s, %p) stub\n", context, debugstr_a(groups), debugstr_a(readers), buflen); > + return SCARD_F_INTERNAL_ERROR; > +} > + > +LONG WINAPI SCardListReadersW(SCARDCONTEXT context, const WCHAR *groups, WCHAR *readers, DWORD *buflen) > +{ > + FIXME("(%lx, %s, %s, %p) stub\n", context, debugstr_w(groups), debugstr_w(readers), buflen); > + return SCARD_F_INTERNAL_ERROR; > +} 'readers' is an out buffer.

1 0