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

Fullscreen upscaling

by David Guillen Fandos

Hey there! I was looking into doing some automatic upscale for HiDPI screens (mine is 3200*1800). It would be some knob that allows the user to choose a x2 scaling for fullscreen apps and similar stuff. After reading winex11.drv I saw that it wouldn't be that hard to report 1/2 of the actual monitor resolution and then just upscale whatever gets rendered to the gdi_display (so we would have an unscaled surface and then blit that with a 2x scaling to the gdi_display). I guess that some other modifications would be needed though. Any comments on this? I think it could be useful for some people, nowadays that screens just got lots of pixels. Thanks! David G.F.

April 13, 2016

Re: [v11 1/4] d3dx9: Implement fxlc constants (expressions) in effect.

by Matteo Bruni

> I would prefer to keep FIXME (adding a temporary buffer for proper > check) for now if possible, as adding a support to d3dx_const_tab looks > a bit tricky without any working example of this (which in turn requires > the support in ID3DXConstantTable to be tested). Sure, that's okay. Thinking about it, it might even turn out that in effect files this doesn't happen in practice and the FIXME is just fine. Essentially, depending on its usage in the shader, compiler options and such, a single shader constant can be "instantiated" into more than one register set and d3dx9, when uploading constants, needs to set the value for all the copies. You can try to write a shader using the same constant in some generic math expression and as a loop count / if condition, that might generate one of those "multiple descriptors" constants. You might need to disable loop unrolling or other optimizations though. I'm sure I have some shader like that somewhere but I can't find it right now... With effects a similar end result can be obtained by means of a preshader. I guess it depends on what construction the compiler prefers in such a situation.

April 13, 2016

Re: [v11 1/4] d3dx9: Implement fxlc constants (expressions) in effect.

by Paul Gofman

On 04/13/2016 10:59 PM, Matteo Bruni wrote: > 2016-04-12 11:34 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > >> @@ -369,12 +410,17 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab >> goto err_out; >> } >> count = 1; >> - hr = ID3DXConstantTable_GetConstantDesc(ctab, hc, &cdesc[i], &count); >> - if (FAILED(hr)) >> + if (FAILED(hr = ID3DXConstantTable_GetConstantDesc(ctab, hc, &cdesc[i], &count))) >> { >> FIXME("Could not get constant desc, hr %#x.\n", hr); >> goto err_out; >> } >> + if (count != 1) >> + { >> + FIXME("Unexpected constant descriptors count %u.\n", count); >> + hr = D3DERR_INVALIDCALL; >> + goto err_out; >> + } > Notice that, since you set count to 1 before calling > GetConstantDesc(), the only possible results are 0 or 1 and the 0 case > should be already handled by the "if (FAILED())" branch. > You might use a temporary array of 3 elements and pass 3 as count, > then only copy the first element to the destination so the rest of the > code is unchanged while still giving a chance for the FIXME to > trigger. Not sure it's worth it though, maybe just adding support for > multiple descriptors (even only in struct d3dx_const_tab and the > immediately related code) might be a better plan. > I would prefer to keep FIXME (adding a temporary buffer for proper check) for now if possible, as adding a support to d3dx_const_tab looks a bit tricky without any working example of this (which in turn requires the support in ID3DXConstantTable to be tested).

April 13, 2016

Re: [v10 1/4] d3dx9: Implement fxlc constants (expressions) in effect.

by Matteo Bruni

2016-04-13 22:16 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > On 04/13/2016 10:53 PM, Matteo Bruni wrote: >> >>> BTW I encountered d3ts_dotswiz preshader opcode which can take 6 or >>> 8 arguments. Adding it required the appropriate increase of >>> MAX_INPUTS_COUNT and a bit different handling of op table (not to >>> introduce a variable input count in instructions and not to take back >>> the input arguments count into instruction structure), but >>> ARGS_ARRAY_SIZE remained unchanged. >> Cool. How did you test that 6 and 8 are the only possible argument counts? >> I don't know how you changed the opcode handling but otherwise you >> could probably just use two separate opcodes for dotswiz 6 and dotswiz >> 8. >> > I checked the translation all possible components count constructs like > a.zxyy * b.xxxw. If the components count is 3 or 4, MS compiler > generates d3ts_dotswiz with the respective number of args, and plain > mul/add if less. It does not prove that it is not possible to get > d3ts_dotswiz with 2 though, but I am not sure I should add such until I > will be sweeping all possible opcodes to have all of them in place. > After we finish with this patchset I will summarize the leftovers/TODOs > for preshader/effects I know so we could possibly prioritize them. > > I used two separate entries into op_info with the same opcode and > different args count, and modified search to compare both opcode and > number of arguments. Sounds good, thanks!

April 13, 2016

Re: [v10 1/4] d3dx9: Implement fxlc constants (expressions) in effect.

by Paul Gofman

On 04/13/2016 10:53 PM, Matteo Bruni wrote: > >> BTW I encountered d3ts_dotswiz preshader opcode which can take 6 or >> 8 arguments. Adding it required the appropriate increase of >> MAX_INPUTS_COUNT and a bit different handling of op table (not to >> introduce a variable input count in instructions and not to take back >> the input arguments count into instruction structure), but >> ARGS_ARRAY_SIZE remained unchanged. > Cool. How did you test that 6 and 8 are the only possible argument counts? > I don't know how you changed the opcode handling but otherwise you > could probably just use two separate opcodes for dotswiz 6 and dotswiz > 8. > I checked the translation all possible components count constructs like a.zxyy * b.xxxw. If the components count is 3 or 4, MS compiler generates d3ts_dotswiz with the respective number of args, and plain mul/add if less. It does not prove that it is not possible to get d3ts_dotswiz with 2 though, but I am not sure I should add such until I will be sweeping all possible opcodes to have all of them in place. After we finish with this patchset I will summarize the leftovers/TODOs for preshader/effects I know so we could possibly prioritize them. I used two separate entries into op_info with the same opcode and different args count, and modified search to compare both opcode and number of arguments.

April 13, 2016

Re: [v11 4/4] d3dx9: Implement setting named shader constants in effect.

by Matteo Bruni

2016-04-12 11:34 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > static HRESULT d3dx9_apply_state(struct ID3DXEffectImpl *effect, struct d3dx_pass *pass, > - struct d3dx_state *state, int parent_index) > + struct d3dx_state *state, unsigned int parent_index); > + > +HRESULT d3dx_set_shader_const_fxlc(struct ID3DXEffectImpl *effect, struct d3dx_pass *pass, > + struct d3dx_parameter *param, BOOL vs) Nitpick, the _fxlc suffix doesn't seem correct at this point I think. Just call it d3dx_effect_set_shader_constants() or something similar? The function can probably be static too. > +static HRESULT set_shader_constants_device(struct IDirect3DDevice9 *device, struct d3dx_regstore *rs, > + D3DXPARAMETER_TYPE type, enum pres_reg_tables table) > +{ > + unsigned int start, n; Maybe call it "count" instead of "n"? It's up to you though.

April 13, 2016

Re: [v11 2/4] d3dx9: Add basic opcodes to preshader.

by Matteo Bruni

2016-04-12 11:34 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -3834,11 +3831,16 @@ static void test_effect_preshader(IDirect3DDevice9 *device) > v = i < 8 ? (unsigned int *)&light.Diffuse : (unsigned int *)&light.Ambient; > ok(hr == D3D_OK, "Got result %#x.\n", hr); > for (j = 0; j < 4; ++j) > + { > + unsigned int mask; > + > + mask = ~0u << test_effect_preshader_op_results[i].tolerance_bit_count; > todo_wine_if(test_effect_preshader_op_results[i].todo[j]) > - ok(v[j] == test_effect_preshader_op_results[i].result[j], > + ok((v[j] & mask) == (test_effect_preshader_op_results[i].result[j] & mask), That doesn't seem right. You can just use compare_float() to do a correct float comparison.

April 13, 2016

Re: [v11 1/4] d3dx9: Implement fxlc constants (expressions) in effect.

by Matteo Bruni

2016-04-12 11:34 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -369,12 +410,17 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab > goto err_out; > } > count = 1; > - hr = ID3DXConstantTable_GetConstantDesc(ctab, hc, &cdesc[i], &count); > - if (FAILED(hr)) > + if (FAILED(hr = ID3DXConstantTable_GetConstantDesc(ctab, hc, &cdesc[i], &count))) > { > FIXME("Could not get constant desc, hr %#x.\n", hr); > goto err_out; > } > + if (count != 1) > + { > + FIXME("Unexpected constant descriptors count %u.\n", count); > + hr = D3DERR_INVALIDCALL; > + goto err_out; > + } Notice that, since you set count to 1 before calling GetConstantDesc(), the only possible results are 0 or 1 and the 0 case should be already handled by the "if (FAILED())" branch. You might use a temporary array of 3 elements and pass 3 as count, then only copy the first element to the destination so the rest of the code is unchanged while still giving a chance for the FIXME to trigger. Not sure it's worth it though, maybe just adding support for multiple descriptors (even only in struct d3dx_const_tab and the immediately related code) might be a better plan. > +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 minor, major, major_stride, param_offset; > + BOOL transpose, get_element; > + unsigned int desc_count; > + > + desc_count = 1; > + ID3DXConstantTable_GetConstantDesc(ctab, hc, &desc, &desc_count); > + if (desc_count != 1) > + { > + FIXME("Unexpected constant descriptors count %u.\n", desc_count); > + return D3DERR_INVALIDCALL; > + } Same here, in this case the descriptors are only used locally so both options above should be easier to do. > + if (const_count != param_count) > + { > + FIXME("Number of elements or struct members differs between parameter and constant.\n"); > + return D3DERR_INVALIDCALL; > + } You could print the two counts here. Not a big deal though. Looks good otherwise.

April 13, 2016

Re: [v10 1/4] d3dx9: Implement fxlc constants (expressions) in effect.

by Matteo Bruni

2016-04-12 11:41 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > On 04/11/2016 07:52 PM, Matteo Bruni wrote: >> >>> + if (oi->func_all_comps) >>> + { >>> + if (oi->input_count * ins->component_count > ARGS_ARRAY_SIZE) >>> + { >>> + FIXME("Too many arguments (%u) for one instruction.\n", oi->input_count * ins->component_count); >>> + return E_FAIL; >>> + } >> I think this check should be outside of the if (oi->func_all_comps) block. >> > For 'else' case all the components are not put in this array > together, only oi->input_count arguments at once. I could add such a > check in else but this would effectively be a plain static check that > ARGS_ARRAY_SIZE >= MAX_INPUTS_COUNT, so I left this unchanged for now. Right, I probably misread that. > BTW I encountered d3ts_dotswiz preshader opcode which can take 6 or > 8 arguments. Adding it required the appropriate increase of > MAX_INPUTS_COUNT and a bit different handling of op table (not to > introduce a variable input count in instructions and not to take back > the input arguments count into instruction structure), but > ARGS_ARRAY_SIZE remained unchanged. Cool. How did you test that 6 and 8 are the only possible argument counts? I don't know how you changed the opcode handling but otherwise you could probably just use two separate opcodes for dotswiz 6 and dotswiz 8.

April 13, 2016

Re: [PATCH v2 4/5] d3d9/tests: Add some tests for the properties of the DC returned by surface GetDC().

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=22150 Your paranoid android. === w1064 (32 bit d3d9ex) === d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=1. === w1064 (64 bit d3d9ex) === d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2355: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2357: Test failed: Got unexpected hr 0, i=1. === w864 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f.

April 13, 2016