September 2013 - Wine-devel

D3D command stream patches for testing
by Pierre Franco 05 Sep '13

05 Sep '13

I've tested some games (wine 1.7.1 64-bit for Guild Wars 2 and SCII, 32-bit for Skyrim, no wined3d/d3d patch except the patchset for CSMT). I have a GTX660 (slightly overclocked, +10 Mhz or so) with the 325.15 Nvidia blob and an Intel i5 2500K (overclocked to 4.2 Ghz). #Guild Wars 2(in the Lion's Arch with ~75-100 players, always from the same spot): Quality Options: -Fullscreen Mode -1600x1200 -Animation: High -Anti-aliasing: FXAA -Environment: High -LOD: Excellent -Textures: High -Reflections: Land and Sky(causes high frame rate drops when moving the camera) -Render Sampling: Supersampling -Shadows: High -Shaders: High -Post-processing: High(absolutely doesn't influence frame rate) -No High Res Character Textures -Character model limit/Character model quality: Medium -VSyng: Off -Optimal Texture Filtering: Off(no real effect except reducing the FPS) Without -dx9single(it should use more than one core and DX10 then): -With __GL_THREADED_OPTIMIZATIONS: 30-45 FPS in the login screen, 8-10 FPS when not moving the camera, 3-5 FPS when moving it. -Without __GL_THREADED_OPTIMIZATIONS: 60 FPS in the login screen, 18-20 FPS when not moving the camera, 5-10 FPS when moving it. With -dx9single(the game is far more quicker to load with it): -With __GL_THREADED_OPTIMIZATIONS: >60 FPS in the login screen, 23-24 FPS when not moving the camera, 5-20 FPS when moving it. -Without __GL_THREADED_OPTIMIZATIONS: >60 FPS in the login screen, 23-24 FPS when not moving the camera, 20 FPS when moving it. Conclusion: -dx9single is GOOD and __GL_THREADED_OPTIMIZATIONS is BAD. #Starcraft II Quality Options: Ultra(default mode, also for the textures). The game claims 50-70 FPS, but it seems to lag when moving the camera and the output is only trash (I need to change a graphical setting to be able to see anything). With __GL_THREADED_OPTIMIZATIONS, it's even more laggy and the FPS drop below 40. #Skyrim Quality Options: Very High. I can't see the FPS of the game, but it was running smoothly and is still running smoothly with the patchset. I didn't tried with __GL_THREADED_OPTIMIZATIONS(well, I tried long ago, and that was horribly slow). I also want to say that wine is spamming "Waiting for the cs" in the console (I assume it's nothing really important as the project seems to be WIP, why asking for tester otherwise?) and wgl errors (err:wgl:wglFlush wglFlush). Cordially. P.S. : Sorry for my English, I am still learning it. -- Pierre Franco nob.dir.info(a)gmail.com

1 0

Re: [PATCH 6/6] kernel32/tests: remove several todos in test_waittxempty
by Marvin 05 Sep '13

05 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2023 Your paranoid android. === w7pro64 (32 bit comm) === comm.c:856: Test failed: WaitCommEvent failed with a timeout comm.c:868: recovering after WAIT_TIMEOUT... comm.c:879: Test failed: WaitCommEvent error 0 comm.c:880: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:884: WaitCommEvent for EV_TXEMPTY took 2137 ms (timeout 2133) comm.c:885: Test failed: WaitCommEvent used 2137 ms for waiting comm.c:919: Test failed: WaitCommEvent error 87 comm.c:921: Test failed: WaitCommEvent failed with a timeout comm.c:932: recovering after WAIT_TIMEOUT... comm.c:938: Test failed: WaitCommEvent failed with a timeout comm.c:943: Test failed: WaitCommEvent error 0 comm.c:944: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:948: WaitCommEvent for EV_TXEMPTY took 3151 ms (timeout 2133) comm.c:949: Test failed: WaitCommEvent used 3151 ms for waiting comm.c:1617: test_AbortWaitCts timeout 500 handle 00000130 comm.c:1584: Changing CommMask on the fly for handle 00000130 after timeout 500

1 0

Re: [PATCH 2/5] wait until all data from earlier test has been written in test_waittxempty
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Wolfgang Walter <wine(a)stwm.de> wrote: > > > > > With my patches 1/2 and 2/2 I get: > > > > > > > > > > fixme:iphlpapi:NotifyAddrChange (Handle 0x10ee8e0, overlapped > > > > > 0x10ee8ec): > > > > > stub wine: configuration in '/home/walterw/.wine' has been updated. > > > > > fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented stub > > > > > comm.c:857: Test succeeded inside todo block: WaitCommEvent failed > > > > > with a > > > > > timeout comm.c:881: Test succeeded inside todo block: WaitCommEvent > > > > > error > > > > > 997 comm.c:883: Test succeeded inside todo block: WaitCommEvent: > > > > > expected > > > > > EV_TXEMPTY, got 0x4 comm.c:889: Test succeeded inside todo block: > > > > > WaitCommEvent used 1141 ms for waiting err:comm:set_line_control > > > > > ByteSize > > > > > fixme:ntdll:server_ioctl_file Unsupported ioctl 1b000c (device=1b > > > > > access=0 > > > > > func=3 method=0) comm.c:2036: Tests skipped: interactive tests (set > > > > > WINETEST_INTERACTIVE=1) > > > > > > > > Successes inside of todo_wine blocks are treated as failres. > > > > > > So you think I should remove the wine_todos already here? > > > > No, the source of the failures is still there. > > What do you mean with that? The tests indeed do succeed now and there is a > reason they do: when you call WaitCommEvent() while the tx buffer is not empty > yet the wine code will detect that EV_TXEMPTY correctly: The tests must pass under Wine without any additional "fixes" as they do currently under Windows. If you add some code to the tests which suddenly makes them pass under Wine - that's not a fix, Wine implementation should be fixed instead. -- Dmitry.

3 6

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack() (try 6)
by Alexandre Julliard 05 Sep '13

05 Sep '13

Ralf Habacker <ralf.habacker(a)freenet.de> writes: > +/****************************************************************** > + * test api function AllocateAndGetTcpExTableFromStack() > + * > + * Only specific tests required because the function is based > + * on build_tcp_table() which is covered by test_GetExtendedTcpTable() > + */ The tests are supposed to test the behavior on Windows. The details of the Wine implementation are irrelevant. You can't assume that the functions share an implementation. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll/tests: Add tests for job objects.
by Alexandre Julliard 05 Sep '13

05 Sep '13

Andrew Cook <ariscop(a)gmail.com> writes: > diff --git a/dlls/ntdll/tests/Makefile.in b/dlls/ntdll/tests/Makefile.in > index 10d6674..1903d10 100644 > --- a/dlls/ntdll/tests/Makefile.in > +++ b/dlls/ntdll/tests/Makefile.in > @@ -11,6 +11,7 @@ C_SRCS = \ > file.c \ > generated.c \ > info.c \ > + job.c \ Please put this in an existing file, like om.c > +static DWORD getProcess(PHANDLE handle) { > + STARTUPINFO startup = {}; > + PROCESS_INFORMATION info = {}; > + > + if(!CreateProcessA(NULL, GetCommandLine(), NULL, NULL, FALSE, 0, NULL, NULL, &startup, &info)) { > + ok(FALSE, "CreateProcess: %x\n", GetLastError()); > + return 0; > + } > + > + CloseHandle(info.hThread); > + *handle = info.hProcess; > + > + return info.dwProcessId; > +} You should use the existing winetest support for creating child processes. > + ok(TerminateProcess(hprocess[0], 1), "TerminateProcess: %x\n", GetLastError()); > + Sleep(1000); > + ok(TerminateProcess(hprocess[1], 2), "TerminateProcess: %x\n", GetLastError()); > + Sleep(1000); Don't add sleeps when not necessary. > +static void is_zombie(void) > +{ > + WCHAR val[32] = {0}; > + static const WCHAR envName[] = { 'T','E','S','T',0 }; > + static const WCHAR envVal[] = { 'J','o','b','O','b','j','e','c','t',0 }; > + > + GetEnvironmentVariableW(envName, val, 32); > + > + if(lstrcmpW(envVal, val) == 0) > + /* Wait forever, we've been created for a process handle */ > + while(1) Sleep(INFINITE); > + > + SetEnvironmentVariableW(envName, envVal); > +} That's ugly. Again, check how child processes are handled in other tests. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ws2_32: Cope with invalid protocols in WSAEnumProtocols
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> wrote: > +INT validprotocols[] = { WS_IPPROTO_TCP, > + WS_IPPROTO_UDP, > + NSPROTO_IPX, > + NSPROTO_SPX, > + NSPROTO_SPXII, > + 0 }; This should be 'static const'. -- Dmitry.

2 1

Re: [PATCH 5/5] ddraw: Enumerate DXT2 and DXT4
by Henri Verbeet 05 Sep '13

05 Sep '13

On 5 September 2013 10:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Yes, we don't actually support those, but that's wined3d's problem, not > ddraw's. We do. The difference between DXT2/DXT3 and DXT4/DXT5 is just a convention wrt. storing pre-multiplied alpha or not, there's no difference in the actual encoding.

2 1

Re: [PATCH 5/5] kernel32/tests: remove several todos in test_waittxempty
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Wolfgang Walter <wine(a)stwm.de> wrote: > - ok(!res && GetLastError() == ERROR_IO_PENDING, "%d: WaitCommEvent error %d\n", i, GetLastError()); > + ok(res || (!res && GetLastError() == ERROR_IO_PENDING), "%d: WaitCommEvent error %d\n", i, GetLastError()); This change looks spurious and unrelated. Also todos must be removed in the patch that fixes appropriate behaviour. -- Dmitry.

2 6

Re: [PATCH 3/5] ddraw/tests: Test DDCAPS2_TEXTUREMANAGE compatibility with other flags
by Henri Verbeet 05 Sep '13

05 Sep '13

On 5 September 2013 10:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if(DDSD->ddsCaps.dwCaps2 & DDSCAPS2_TEXTUREMANAGE) Minor formatting error here.

2 1

Re: [PATCH 3/5] ddraw/tests: Test DDCAPS2_TEXTUREMANAGE compatibility with other flags
by Marvin 05 Sep '13

05 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2016 Your paranoid android. === wxppro (32 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x8876014a, case 3. === wvista (32 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (32 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (64 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x80004002, case 2. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw7.c:3694: Test failed: Got unexpected, hr 0x80004002, case 4. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 8. === wxppro (32 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x8876014a, case 3. === wvista (32 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (32 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (64 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 8.

1 0