wine-devel April 2014

wine-devel@winehq.org

61 participants
274 discussions

Re: [PATCH] ntdll: Don't enter uninterrupted section when get_cached_fd hits
by Ken Thomases 06 Apr '14

06 Apr '14

On Apr 5, 2014, at 5:25 PM, Daniel Horn wrote: > The call to server_enter_uninterrupted_section in server_get_unix_fd > was causing 2 million syscalls over the span of several seconds when > launching many popular application suites and it was causing > significant performance overhead. > > Switching those two lines resolves the problem entirely because the > cache is sized such that it nearly never misses. You can't call get_cached_fd() without entering the critical section because the critical section is protecting the fd cache. Your patch opens the code up to race conditions and data inconsistency. -Ken

2 5

Re: [PATCH 5/5] ddraw/tests: Add mipmap locking tests.
by Marvin 04 Apr '14

04 Apr '14

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=6163 Your paranoid android. === w8 (32 bit ddraw2) === Failure running script in VM: timed out waiting for the child process === w8 (32 bit ddraw1) === ddraw1.c:3968: Test failed: Got unexpected refcount 3. ddraw1.c:3987: Test failed: Got unexpected refcount 3. ddraw1.c:3994: Test failed: Got unexpected hr 0. ddraw1.c:3997: Test failed: Got unexpected refcount 3. ddraw1.c:3999: Test failed: Got unexpected refcount 2. ddraw1.c:4005: Test failed: Got unexpected hr 0. ddraw1.c:4008: Test failed: Got unexpected refcount 2. ddraw1.c:4010: Test failed: Got unexpected refcount 1. === w8 (32 bit ddraw7) === ddraw7.c:5604: Test failed: Got unexpected refcount 3. ddraw7.c:5623: Test failed: Got unexpected refcount 3. ddraw7.c:5630: Test failed: Got unexpected hr 0. ddraw7.c:5633: Test failed: Got unexpected refcount 3. ddraw7.c:5635: Test failed: Got unexpected refcount 2. ddraw7.c:5641: Test failed: Got unexpected hr 0. ddraw7.c:5644: Test failed: Got unexpected refcount 2. ddraw7.c:5646: Test failed: Got unexpected refcount 1. ddraw7.c:5648: Test failed: Got unexpected refcount 6. ddraw7.c:5765: Test failed: Failed to set cooperative level, hr 0x8876023b. === wvistau64 (64 bit ddraw7) === Unable to set the VM system time: the "nc -q0 '10.42.42.238' '4242'" command returned 1 === w2000pro (32 bit ddraw4) === Unable to set the VM system time: the "nc -q0 '10.42.42.139' '4242'" command returned 1

1 0

Re: [PATCH 2/2] d3d8/tests: Test locking of mipmap textures.
by Marvin 04 Apr '14

04 Apr '14

1 0

Re: [PATCH 1/2] d3d9/tests: Test locking of mipmap textures.
by Marvin 04 Apr '14

04 Apr '14

1 0

Re: [PATCH 4/5] d3d8/tests: Test locking of mipmap textures.
by Marvin 04 Apr '14

04 Apr '14

1 0

Re: [PATCH 2/5] d3d8/tests: Add a test for (sub-) resource types.
by Marvin 04 Apr '14

04 Apr '14

1 0

Re: [PATCH 3/5] d3d9/tests: Test locking of mipmap textures.
by Henri Verbeet 04 Apr '14

04 Apr '14

On 4 April 2014 11:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirect3DDevice9_CreateTexture(device, 4, 4, 2, 0, D3DFMT_X8R8G8B8, > + D3DPOOL_DEFAULT, &texture_dst, NULL); > + ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); > + hr = IDirect3DTexture9_GetSurfaceLevel(texture_dst, 0, &surface_dst); > + ok(SUCCEEDED(hr), "Failed to get surface level, hr %#x.\n", hr); > + hr = IDirect3DTexture9_GetSurfaceLevel(texture_dst, 0, &surface_dst2); > + ok(SUCCEEDED(hr), "Failed to get surface level, hr %#x.\n", hr); > + This gets two references to the same surface level, is that intentional? > + hr = IDirect3DDevice9_UpdateSurface(device, surface, NULL, surface_dst, NULL); > + ok(SUCCEEDED(hr), "Failed to update surface, hr %#x.\n", hr); > + hr = IDirect3DDevice9_UpdateSurface(device, surface2, NULL, surface_dst2, NULL); > + todo_wine ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); > + Doesn't this just fail because the surface sizes are different? (Although I would have expected this to work.)

2 1

Re: [PATCH] ddraw: add dsurface dimension tests, try 7
by Stefan Dösinger 04 Apr '14

04 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks for the patch. I'll test it on my Windows boxes as soon as they're done with Linux updates (Gentoo...) and report any failures I find. Am 2014-04-03 17:54, schrieb Patrick Rudolph: + window = CreateWindowA("static", "ddraw_test", WS_OVERLAPPEDWINDOW, + 100, 100, 160, 160, NULL, NULL, NULL, NULL); + + if (!(ddraw = create_ddraw())) + { + skip("Failed to create a ddraw object, skipping test.\n"); + return; + } You no longer need the skip check here. The main functions in ddraw1-ddraw7 check if ddraw creation succeeds and skip all tests if it doesn't + + ret = IDirectDraw_SetCooperativeLevel(ddraw, window, DDSCL_NORMAL); + + ddcaps.dwSize = sizeof(DDCAPS); You're not checking the return value here. I also recommend to rename "ret" to "hr" for consistency with other tests. + ret = IDirectDraw_GetCaps(ddraw, &ddcaps, NULL); + if (ret != DD_OK) + { + skip("IDirectDraw_GetCaps failed with %08x\n", ret); + return; + } Do you have hardware where GetCaps fails? If not, a simple ok(SUCCEEDED(hr), ...) should be enough. +#if _WIN64 || __x86_64__ || __ppc64__ + { + MEMORYSTATUSEX statex; + statex.dwLength = sizeof (statex); + GlobalMemoryStatusEx (&statex); + /* on 64bit surfaces with 2GByte+ are possible */ + if(statex.ullAvailVirtual > 0x80000000LL) + tests[10].ret = DD_OK; + } +#endif Is the #if necessary? Afaics GlobalMemoryStatusEx should work on 32 bit as well. In light of the testbot failures I recommend to check for available physical memory as well. I'm also fine with just dropping the SYSMEM out of memory test until we find an application that depends on this behavior. The parenthesis placement after the function call and if are inconsistent. This applies to a few other ifs as well. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPmKGAAoJEN0/YqbEcdMwUwEP/A5NCz4xe855Z9jX6iUBWkhw NDhpM/9Wbk5tdekaR3QcrNyCYGCAHnOl/kUsGXeBDwZxCDzRzpfsdpFp0Nux46m+ L/xtf71bhAMYGikeV9r/C+UVBbCslO4KXFcUmx5K43AXcVQGMq+K1yvzhGtKCGZb 6zNCUmhxI2MlNrU9KDp7W7kNhVWMu2ungAjojT5BmaWDgtvS6TWu10jX1rIwQlYF wMOHSIomIBNvPi2vSr8aXLzPhgFCrMg3g8fERUqS3Vk8LJfmJYWJ87hcfPiMGd5A ntDYedg+mhV0ShTk26XCeKMNBfvjcdwWCnHEi1GYmYQ6H/nRDGxkEO/TskiNLuNn IO/rV2TAO9SfzHzHO/VPCGdb6nISGICAP/oA2ryrhINdXtn6eq1kjqQsGUURlqlk Y46P55qgRleYCtqxHjrjhQXDL4anaKj3ApZjGRa9MVC2/SPvIe3UpjlHjN4oeAix ohiOiq7GL/PXXs0zLOKFeVdUoOYpCIuP7MsR/dX9KcJwYQ2U9GT6OEoQPhZT+/B7 Tpv1maEOnn+UCkvcW6BY2eAt3nsznvlKVb73D5t1tLp/LCbKiSqY+8Dk0f75YTyG hEXkawRFLjhXeA6db8ieb2GdftaAnfq1Vxa7wjF4igAccZIhySInrvdnOFhZ4rp+ djHZm23O6ml1uV8Qt0mW =yrSd -----END PGP SIGNATURE-----

1 1

libwine-print missing when compiling from source
by Alois Schlögl 04 Apr '14

04 Apr '14

When compiling wine from source according to instructions on http://wiki.winehq.org/Wine64 "Building a shared WoW64 setup (most likely what you want)" starting Igor Pro fails in the same way, as if libwine-print is not installed. I'm using debian7:x86_64, and IgorPro is working fine when the debian version of wine (v1.4.1) with libwine-print is installed. What do I need to do in order the have libwine-print when compiling wine from source ? -- Alois

3 4

Re: [1/5] include: Add dxva2api.idl
by Nikolay Sivov 04 Apr '14

04 Apr '14

On 4/4/2014 08:44, Michael Müller wrote: > This first set of patches adds the required interface definitions and > headers which are required for the dxva2 implementation. Please note > that the ugly names of the header files were not my idea, thats exactly > the same name how they're called by MS. Yes, looks like 8.3 rule no longer applies :) > > The last patch of the series implements stub functions for every member > of dxva2.dll, such that applications do not abort anymore when they hit > one of the stub exports. > > --- > include/Makefile.in | 1 + > include/dxva2api.idl | 534 > ++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 535 insertions(+) > create mode 100644 include/dxva2api.idl > +cpp_quote("#if 0") > +typedef DWORD IDirect3DDevice9; > +typedef DWORD IDirect3DSurface9; > + > +typedef DWORD D3DFORMAT; > +typedef DWORD D3DPOOL; > +cpp_quote("#endif") First I thought it's a bit ugly, but apparently that's how it's done in SDK. > +enum > +{ > + DXVA2_PictureParametersBufferType = 0, > + DXVA2_MacroBlockControlBufferType = 1, > + DXVA2_ResidualDifferenceBufferType = 2, > + DXVA2_DeblockingControlBufferType = 3, > + DXVA2_InverseQuantizationMatrixBufferType = 4, > + DXVA2_SliceControlBufferType = 5, > + DXVA2_BitStreamDateBufferType = 6, > + DXVA2_MotionVectorBuffer = 7, > + DXVA2_FilmGrainBuffer = 8 > +}; > + > +enum > +{ > + DXVA2_VideoDecoderRenderTarget = 0, > + DXVA2_VideoProcessorRenderTarget = 1, > + DXVA2_VideoSoftwareRenderTarget = 2 > +}; > + You don't need explicit initializers in this case. > +[ > + object, > + uuid(a0cade0f-06d5-4cf4-a1c7-f3cdd725aa75), > + helpstring("IDirect3DDeviceManager9 Interface"), > + local > +] No need for helpstring(), it's only used definitions participating in typelibs.

1 0

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 April 2014