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

Re: [PATCH 5/8] wined3d: Fixup vertex position in geometry shaders.
by Henri Verbeet 20 Apr '16

20 Apr '16

Do we need this if we have GLSL 1.50 / ARB_fragment_coord_conventions?

2 1

Re: [PATCH 3/8] wined3d: Simplify shader interface matching for SM4+ vertex shaders.
by Henri Verbeet 20 Apr '16

20 Apr '16

On 19 April 2016 at 18:56, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > After some testing it looks like, with SM4+ on Windows: > 1. Output registers have to match with input registers from the > following shader stage (register index and mask). There is no "smart" > matching of semantics like in SM3. > 2. Using uninitialized varyings in SM4+ shaders doesn't give consistent > results. > That means we can simplify the relevant code quite a bit. Applications > shouldn't be able to depend on particular values for uninitialized > varyings so we can avoid explicitly initializing them. > Does that mean we don't need the separate "reorder" shader between the stages? (Even more so if we have separate shader objects.) On 19 April 2016 at 18:56, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > -static void shader_glsl_setup_shader_output(struct shader_glsl_priv *priv, > +static void shader_glsl_setup_vs3_output(struct shader_glsl_priv *priv, > const struct wined3d_gl_info *gl_info, const DWORD *map, > const struct wined3d_shader_signature *input_signature, > const struct wined3d_shader_reg_maps *reg_maps_in, > const struct wined3d_shader_signature *output_signature, > - const struct wined3d_shader_reg_maps *reg_maps_out, const char *out_array_name) > + const struct wined3d_shader_reg_maps *reg_maps_out) > { > struct wined3d_string_buffer *destination = string_buffer_get(&priv->string_buffers); > BOOL legacy_context = gl_info->supported[WINED3D_GL_LEGACY_CONTEXT]; > @@ -5191,7 +5191,7 @@ static void shader_glsl_setup_shader_output(struct shader_glsl_priv *priv, > else if (in_idx == in_count + 1) > string_buffer_sprintf(destination, "gl_FrontSecondaryColor"); > else > - string_buffer_sprintf(destination, "%s[%u]", out_array_name, in_idx); > + string_buffer_sprintf(destination, "%s[%u]", "ps_link", in_idx); > > if (!set[in_idx]) > set[in_idx] = ~0u; > @@ -5243,7 +5243,7 @@ static void shader_glsl_setup_shader_output(struct shader_glsl_priv *priv, > else if (i == in_count + 1) > string_buffer_sprintf(destination, "gl_FrontSecondaryColor"); > else > - string_buffer_sprintf(destination, "%s[%u]", out_array_name, i); > + string_buffer_sprintf(destination, "%s[%u]", "ps_link", i); > > if (size == 1) > shader_addline(buffer, "%s.%s = 0.0;\n", destination->buffer, reg_mask); This looks like you should have just kept it the way it was in the previous patch.

2 1

Re: [PATCH 8/8] d3d11/tests: Add a geometry shader test.
by Józef Kucia 20 Apr '16

20 Apr '16

On Tue, Apr 19, 2016 at 6:56 PM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > dlls/d3d11/tests/d3d11.c | 232 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 232 insertions(+) > > diff --git a/dlls/d3d11/tests/d3d11.c b/dlls/d3d11/tests/d3d11.c > index 713c9cf..0fafaaf 100644 > --- a/dlls/d3d11/tests/d3d11.c > +++ b/dlls/d3d11/tests/d3d11.c > @@ -6569,6 +6569,237 @@ static void test_getdc(void) > ok(!refcount, "Device has %u references left.\n", refcount); > } > > +static void test_geometry_shader(void) > +{ > + static const struct > + { > + struct vec4 position; > + unsigned int color; > + } > + vertex[] = > + { > + {{0.0f, 0.0f, 1.0f, 1.0f}, 0xffffff00}, > + }; > + static const D3D11_INPUT_ELEMENT_DESC layout_desc[] = > + { > + {"SV_POSITION", 0, DXGI_FORMAT_R32G32B32A32_FLOAT, 0, 0, D3D10_INPUT_PER_VERTEX_DATA, 0}, > + {"COLOR", 0, DXGI_FORMAT_R8G8B8A8_UNORM, 0, 16, D3D10_INPUT_PER_VERTEX_DATA, 0}, It would be better to use D3D11 constants. > + static const D3D_FEATURE_LEVEL feature_level = D3D_FEATURE_LEVEL_10_0; Why should we limit this test to feature level 10_0? > + buffer_desc.ByteWidth = sizeof(vertex); > + buffer_desc.Usage = D3D11_USAGE_DEFAULT; > + buffer_desc.BindFlags = D3D11_BIND_VERTEX_BUFFER; > + buffer_desc.CPUAccessFlags = 0; > + buffer_desc.MiscFlags = 0; The "StructureByteStride" field is uninitialized. I suppose it doesn't matter in practice because this field is used only for structured buffers.

2 1

Re: [PATCH ] msvcr120/tests: Add critical section test.(try 2)
by Marvin 20 Apr '16

20 Apr '16

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=22393 Your paranoid android. === w2008s64 (64 bit msvcr120) === Found no trace of the test summary line or of a crash

1 0

Re: [PATCH 1/2] d3drm: Implement IDirect3DRM*::CreateObject (v2).
by Henri Verbeet 20 Apr '16

20 Apr '16

On 18 April 2016 at 19:00, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index a8f9c40..2b0174d 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1269,7 +1269,8 @@ static void test_destroy_callback(unsigned int test_idx, REFCLSID clsid, REFIID > context.test_idx = test_idx; > context.obj = obj; > > - hr = IDirect3DRMObject_AddDestroyCallback(obj, NULL, &context); > + if ((hr = IDirect3DRMObject_AddDestroyCallback(obj, NULL, &context)) != D3DRMERR_BADVALUE) > + return; I don't think we want that. Doing this means we won't notice when the function starts returning the wrong value, and the following tests get effectively disabled too in that case. > + hr = IDirect3DRM_CreateObject(d3drm1, &CLSID_DirectDraw, NULL, &IID_IDirectDraw, (void **)&unknown); > + ok(hr == CLASSFACTORY_E_FIRST, "Expected hr == CLASSFACTORY_E_FIRST, got %#x.\n", hr); > + ok(!unknown, "Expected object returned == NULL, got %p.\n", unknown); It would be better to initialise "unknown" with some known value before calling CreateObject(). Like this, if CreateObject() doesn't touch the value, the test may randomly pass or fail depending on what the initial value of "unknown" ends up being.

2 3

Re: [PATCH] comctl32/tooltips: Protect TTM_ADDTOOLW from invalid text pointers
by Marvin 20 Apr '16

20 Apr '16

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=22377 Your paranoid android. === wxppro (32 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w2003std (32 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === wvistau64 (32 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w2008s64 (32 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w7u (32 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w7pro64 (32 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w8 (32 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w864 (32 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w1064 (32 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === wvistau64 (64 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w2008s64 (64 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w7pro64 (64 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w864 (64 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed! === w1064 (64 bit tooltips) === tooltips.c:471: Test failed: Adding the tool to the tooltip failed!

2 1

Re: [PATCH v3 2/8] wined3d: Implement readback from 2D array textures using glGet[Compressed]TexImage().
by Henri Verbeet 20 Apr '16

20 Apr '16

On 20 April 2016 at 11:42, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -874,7 +879,31 @@ static void surface_download_data(struct wined3d_surface *surface, const struct > return; > } > > - wined3d_texture_get_memory(texture, surface_get_sub_resource_idx(surface), &data, dst_location); > + sub_resource = wined3d_texture_get_sub_resource(texture, sub_resource_idx); Actually, don't use wined3d_texture_get_sub_resource() if you know the index is valid. It does extra validation that's only useful when the index comes from outside of wined3d. > + wined3d_texture_bind_and_dirtify(texture, context, !(sub_resource->locations & WINED3D_LOCATION_TEXTURE_RGB)); This is an unrelated change. In itself it's probably fine to make surface_download_data() bind the texture, but if you do that it becomes inconsistent with surface_upload_data(), wined3d_volume_download_data() and wined3d_volume_upload_data().

1 0

Re: [PATCH 05/10] wined3d: Try to avoid glGetTexImage() for 2D array textures.
by Henri Verbeet 20 Apr '16

20 Apr '16

On 19 April 2016 at 00:01, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > It's inefficient to download a complete miplevel to copy just a single layer from it. > --- Does this happen much in practice? Do you have performance numbers? The patch doesn't really make sense in its current form. surface_download_data() is meant for downloading the data from the texture. If that's not what you want, don't call it. (Also, does this actually work? It looks like it's just reading from the current drawable.)

2 4

Re: [3/3] services: Track services and processes separately.
by Alexandre Julliard 20 Apr '16

20 Apr '16

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > programs/services/rpc.c | 37 ++++--- > programs/services/services.c | 199 ++++++++++++++++++++++++++----------------- > programs/services/services.h | 4 > 3 files changed, 147 insertions(+), 93 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M taskschd.dll -p taskschd_test.exe.so scheduler && touch scheduler.ok scheduler.c:78: Test failed: Connect error 0x80041315 scheduler.c:101: Test failed: Connect error 0x80041315 scheduler.c:151: Test failed: Connect error 0x80041315 scheduler.c:162: Test failed: GetFolder error 0x800704e3 wine: Unhandled page fault on read access to 0x00000000 at address 0x7eff3a5e (thread 0009), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/5] dwrite/tests: Added GetFontSignature() test (resend)
by Sebastian Lackner 20 Apr '16

20 Apr '16

On 19.04.2016 19:10, Nikolay Sivov wrote: > + ok(fontsig.fsUsb[3] == expected_signature.fsUsb[3], "%s: fsUsb[3] %#x, expected %#x\n", wine_dbgstr_w(nameW), > + fontsig.fsUsb[0], expected_signature.fsUsb[3]); ^^^ There is a small typo here.

2 1