February 2015 - Wine-Devel - list.winehq.org

Re: d3d8/tests: Test the return value of CreateVolumeTexture (PVS-Studio)

by Michael Stefaniuc

On 02/21/2015 06:39 PM, Marvin wrote: > 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? Unrelated to my changes. > Full results can be found at > https://testbot.winehq.org/JobDetails.pl?Key=11656 > > Your paranoid android. > > > === w8 (32 bit device) === device.c:1222: Test failed: > TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test > failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: > TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test > failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: > Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test > failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test > failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test > failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: > Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. > device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, > expected 1. device.c:1290: Test failed: Screen width is 640, > expected 800. device.c:1291: Test failed: Screen height is 480, > expected 600. device.c:1297: Test failed: Back buffer width is 640, > expected 800. device.c:1299: Test failed: Back buffer height is > 480, expected 600. device.c:1329: Test failed: Screen width is 640, > expected 1024. device.c:1330: Test failed: Screen height is 480, > expected 768. device.c:2557: Test failed: Expected message 0x7e for > window 0, but didn't receive it. device.c:2562: Test failed: The > focus window is active. device.c:2570: Test failed: Got unexpected > hr 0x88760869. device.c:2576: Test failed: Got unexpect screen size > 800x600. device.c:2591: Test failed: Expected message 0x47 for > window 0, but didn't receive it, i=1. device.c:2600: Test failed: > Got unexpect screen size 800x600. device.c:2613: Test failed: > Expected message 0x7e for window 0, but didn't receive it. > device.c:2621: Test failed: Got unexpect width 640. device.c:2622: > Test failed: Got unexpect height 480. > > bye michael

Feb. 21, 2015

Re: d3d8/tests: Test the return value of CreateVolumeTexture (PVS-Studio)

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=11656 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2557: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2562: Test failed: The focus window is active. device.c:2570: Test failed: Got unexpected hr 0x88760869. device.c:2576: Test failed: Got unexpect screen size 800x600. device.c:2591: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2600: Test failed: Got unexpect screen size 800x600. device.c:2613: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2621: Test failed: Got unexpect width 640. device.c:2622: Test failed: Got unexpect height 480.

Feb. 21, 2015

Re: mshtml/tests: Remove an always true conditional subexpression (PVS-Studio)

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=11654 Your paranoid android. === wvistau64 (32 bit events) === events.c:939: Test failed: unexpected call img_onerror === w7u (32 bit events) === events.c:939: Test failed: unexpected call img_onerror The test timed out

Feb. 21, 2015

Re: Speed of gdi vs opengl DirectDrawRenderer

by Henri Verbeet

It could very well be the case that this happens because we don't properly implement ddraw asynchronous blits. The gdi renderer might mitigate that with the behavior Ken described. If that's the case, the csmt patchset would in theory allow this to be fixed, although I suspect it currently doesn't.

Feb. 21, 2015

Re: Speed of gdi vs opengl DirectDrawRenderer

by Ken Thomases

On Feb 20, 2015, at 5:49 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Feb 20, 2015, at 4:16 PM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: > >> On 19/02/15 21:45, Ken Thomases wrote: >> [snip] >>> Basically, GDI32 and USER32 can overdrive the drawing loop without having to wait for the GPU or the refresh cycle. >> >> Great, thanks for the explanation! That's indeed exactly what this game >> seems to need. It generates and tries to display a new screen per game >> step, but there's no need to display them all. > > If that's the case, then maybe there are unnecessary calls to glFlush() or even glFinish() that can/should be skipped. There is one more thing you could try along these lines, but it's a long shot. Try setting: [HKEY_CURRENT_USER\Software\Wine\Mac Driver] "SkipSingleBufferFlushes"="y" -Ken

Feb. 21, 2015

Re: Speed of gdi vs opengl DirectDrawRenderer

by Ken Thomases

On Feb 20, 2015, at 4:16 PM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: > On 19/02/15 21:45, Ken Thomases wrote: > [snip] >> Basically, GDI32 and USER32 can overdrive the drawing loop without having to wait for the GPU or the refresh cycle. > > Great, thanks for the explanation! That's indeed exactly what this game > seems to need. It generates and tries to display a new screen per game > step, but there's no need to display them all. If that's the case, then maybe there are unnecessary calls to glFlush() or even glFinish() that can/should be skipped. If Stefan has the inclination and the opportunity, I'd wait for him to get a chance to analyze its behavior. Thanks for the log snippets in response to my questions about display modes, but I no longer think that's relevant. -Ken

Feb. 20, 2015

Re: Speed of gdi vs opengl DirectDrawRenderer

by Ken Thomases

On Feb 19, 2015, at 2:12 PM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: > I had a problem with Majesty Gold HD running at glacial speed on my > machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5). > The wiki's wording suggests the gdi renderer is deprecated though. Does > that mean this qualifies as a bug in the OpenGL renderer …? For what it's worth, I think this does qualify for a bug report. It will be easier to keep track of there. -Ken

Feb. 20, 2015

Re: Speed of gdi vs opengl DirectDrawRenderer

by Jonas Maebe

On 20/02/15 10:19, Stefan Dösinger wrote: > Am 2015-02-19 um 21:12 schrieb Jonas Maebe: >> I profiled wine (Instruments time profile) and noticed that most >> time was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing >> that routine with an optimized sse2 version from pixman did not >> make much of a difference. > Is there a demo version of this game somewhere? I am reworking the > d3d blitting code at the moment, and it seems like this would be > an interesting game to look at. There's a demo of the non-HD version of the game available at http://www.cyberlore.com/Majesty/demo.htm . At first sight it exhibits the same symptoms (OpenGL driver monitor shows a lot of cpu waiting time on the GPU). It's hard to verify though, because the demo doesn't allow you to change the in-game speed, unlike the full game (so I can't test whether it would go faster if I'd yank up the game speed). I have actually 2 copies of Majesty Gold HD (one on Gamersgate and one on GOG), but since I've downloaded it already from both I don't think I can gift you one. It's currently also on sale at GOG till Tuesday, so if Codeweavers has $4,99/€4,49 to spare... :) (http://www.gog.com/game/majesty_gold_hd ) > If the game does video memory r5g6b5 to video memory x8r8g8b8 > blits then we should be able to do this on the GPU. It's quite > possible however that this is either a system memory to system > memory blit, in which case doing this in the CPU is the correct > thing. If the game uploads from a system memory r5g6b5 to a video > memory x8r8g8b8 texture then we can in theory let OpenGL do the > work via glTexSubImage2D, but it'll mostly mean that OpenGL > converts the data using the CPU before sending it to the GPU. > > This may be a game bug - you say the game has troubles on Windows > too. Yes. The most common workarounds for slowness under Windows appear to be a) tell the game to use a 32 bit rather than a 16 bit mode (doesn't help in my case for Wine). Note that while the demo contains a gameopt.ini file in which you can change the depth to 32, it will just crash it. Changing this works fine in the full Majesty Gold HD version b) tell the game to use DirectDraw for bliting rather than its internal routines (is already the default) (-useddblit command line parameter -- don't know whether it does anything for the demo) > It may also be a bug in our modesetting code, in the sense that > the game sets the display format to r5g6b5, but we stay at > x8r8g8b8 because X11 (and I think OSX, Ken correct me please) can't > switch the color depth. Ideally OpenGL takes care of the resulting > conversion, but that's not always the case. If you need any more/specific trace output other than what I pasted in my reply to Ken, let me know! Thanks, Jonas

Feb. 20, 2015

Re: Speed of gdi vs opengl DirectDrawRenderer

by Jonas Maebe

On 19/02/15 21:45, Ken Thomases wrote: [snip] > Basically, GDI32 and USER32 can overdrive the drawing loop without having to wait for the GPU or the refresh cycle. Great, thanks for the explanation! That's indeed exactly what this game seems to need. It generates and tries to display a new screen per game step, but there's no need to display them all. > See if the game has a setting for disabling vsync. If it doesn't, try setting: > > [HKEY_CURRENT_USER\Software\Wine\Mac Driver] > "AllowVerticalSync"="n" > > Does that help? The game has an option to disable it, but just to make sure I also added the registry key. It didn't make a (noticeable) difference. > Others would understand better why the OpenGL renderer is slow. Does your system support 16-bit display modes? I don't know: trace:wgl:init_pixel_formats renderer_properties 0: trace:wgl:dump_renderer Renderer ID: 0x00022700 trace:wgl:dump_renderer Buffer modes: trace:wgl:dump_renderer Monoscopic: YES trace:wgl:dump_renderer Stereoscopic: NO trace:wgl:dump_renderer Single buffer: YES trace:wgl:dump_renderer Double buffer: YES trace:wgl:dump_renderer Color buffer modes: trace:wgl:dump_renderer Color size 15, Alpha size 0 trace:wgl:dump_renderer Color size 32, Alpha size 8 trace:wgl:dump_renderer Color size 64, Alpha size 16, Float trace:wgl:dump_renderer Color size 128, Alpha size 32, Float trace:wgl:dump_renderer Accumulation buffer sizes: { 128, } trace:wgl:dump_renderer Depth buffer sizes: { 0, 16, 24, } trace:wgl:dump_renderer Stencil buffer sizes: { 0, 8, } trace:wgl:dump_renderer Max. Auxiliary Buffers: 2 trace:wgl:dump_renderer Max. Sample Buffers: 1 trace:wgl:dump_renderer Max. Samples: 8 trace:wgl:dump_renderer Offscreen: NO trace:wgl:dump_renderer Accelerated: YES trace:wgl:dump_renderer Backing store: YES trace:wgl:dump_renderer Window: YES trace:wgl:dump_renderer Online: YES trace:d3d:wined3d_adapter_init_fb_cfgs iPixelFormat=1, There are also several enumerated pixel formats with 16 as "color depth" (but still 32 as "color bits", so I'm not sure which one counts): trace:wgl:enum_renderer_pixel_formats w/p/a 1/1/1 col 32/8 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 0/0 0000000000000804f remapped from w/p/a 1/0/1 col 15/0 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 0/0 0000000000000801d trace:wgl:enum_renderer_pixel_formats w/p/a 1/1/1 col 32/8 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/2 0000000140000804f remapped from w/p/a 1/0/1 col 15/0 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/2 0000000140000801d trace:wgl:enum_renderer_pixel_formats w/p/a 1/1/1 col 32/8 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/4 0000000240000804f remapped from w/p/a 1/0/1 col 15/0 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/4 0000000240000801d trace:wgl:enum_renderer_pixel_formats w/p/a 1/1/1 col 32/8 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/8 0000000440000804f remapped from w/p/a 1/0/1 col 15/0 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 1/8 0000000440000801d trace:wgl:enum_renderer_pixel_formats w/p/a 1/1/1 col 32/8 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 0/0 0000000000000804f remapped from w/p/a 1/1/1 col 15/0 dp/stn/ac/ax/b/db/str 16/0/0/0/0/0/0 samp 0/0 0000000000000801f (duplicate) All of the "col" values are either 32, 64f or 128f. > Is the game/wined3d actually switching it into one of those? I'm not sure: trace:d3d:init_format_fbo_compat_info Checking if format WINED3DFMT_B5G6R5_UNORM is supported as FBO color attachment... trace:d3d:check_fbo_compat Framebuffer format check call ok utils.c / 1344 trace:d3d:check_fbo_compat Format WINED3DFMT_B5G6R5_UNORM is supported as FBO color attachment. trace:d3d:check_fbo_compat RB attachment call ok utils.c / 1420 trace:d3d:check_fbo_compat Post-pixelshader blending check call ok utils.c / 1468 trace:d3d:check_fbo_compat Format supports post-pixelshader blending. trace:d3d:check_fbo_compat Color output: 0xff7b0000 trace:d3d:check_fbo_compat RB cleanup call ok utils.c / 1500 ... trace:d3d:wined3d_set_adapter_display_mode wined3d 0x11fe50, adapter_idx 0, mode 0x33fcfc. trace:d3d:wined3d_set_adapter_display_mode mode 1024x768(a)0 WINED3DFMT_B5G6R5_UNORM 0. ... trace:d3d:wined3d_get_adapter_display_mode wined3d 0x11fe50, adapter_idx 0, display_mode 0x33fc08, rotation 0x0. warn:d3d:wined3d_get_adapter_display_mode Overriding format WINED3DFMT_B8G8R8X8_UNORM with stored format WINED3DFMT_B5G6R5_UNORM. trace:d3d:wined3d_get_adapter_display_mode Returning 1024x768(a)60 WINED3DFMT_B5G6R5_UNORM 0x1. ... trace:d3d:swapchain_update_render_to_fbo Single buffered rendering. trace:d3d:context_create swapchain 0x161238, target 0x1618f0, window 0x3003a. trace:d3d:context_choose_pixel_format device 0x131748, dc 0x90033, color_format WINED3DFMT_B5G6R5_UNORM, ds_format WINED3DFMT_D24_UNORM_S8_UINT, aux_buffers 0, find_compatible 0. trace:d3d:getColorBits format WINED3DFMT_B5G6R5_UNORM. trace:d3d:getColorBits Returning red: 5, green: 6, blue: 5, alpha: 0, total: 16 for format WINED3DFMT_B5G6R5_UNORM. trace:d3d:getDepthStencilBits format WINED3DFMT_D24_UNORM_S8_UINT. trace:d3d:getDepthStencilBits Returning depthSize: 24 and stencilSize: 8 for format WINED3DFMT_D24_UNORM_S8_UINT. trace:d3d:context_choose_pixel_format Found iPixelFormat=69 for ColorFormat=WINED3DFMT_B5G6R5_UNORM, DepthStencilFormat=WINED3DFMT_D24_UNORM_S8_UINT trace:d3d:context_enter Entering context 0x141f68, level 1. trace:d3d:device_context_add Adding context 0x141f68. trace:d3d:context_set_current Switching to D3D context 0x141f68, GL context 0x31001, device context 0x90033. Jonas

Feb. 20, 2015

Re: [PATCH 2/3] ntdll/tests: Add tests for RtlIpv6StringToAddress (try 3)

by Mark Jansen

Hey, I do not have the intention to rewrite the ipv4 tests now, i do have another few tests lined up for different ipv6 functions (addr2str), i'll look into rewriting the ipv4 then. As for now, few tests are better than no tests, right? On Fri, Feb 20, 2015 at 11:47 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Thanks again for your work and patience! This goes in the right direction in my eyes. The full set of address tests are run against both versions, and it documents the differences between non-ex and ex better. Can you do the same with the ipv4 tests in patch 1? > > Am 2015-02-19 um 23:38 schrieb Mark Jansen: >> +/* ipv6 addresses from https://github.com/beaugunderson/javascript-ipv6/tree/master/test/data */ >> +static const struct >> +{ >> + PCSTR address; >> + NTSTATUS res; >> + int terminator_offset; >> + int ip[8]; >> + int broken; > What is the meaning of broken here? Different behavior among different Windows versions? Or deviation from your source above? Broken means xp pro, 2003, vista and 2008 did not behave correct. > >> + int ex_fails; /* 1 means ex should fail, 2 means skip for ex */ > Style hint: You can use an enum in this case. Yeah, was a last minute change to add the 2. > > I guess you need the skip value because the last test fails on non-ex and succeeds on ex and your expected address does not match. Similarly, the behavior that the function writes to the output address even in case of a failure isn't exactly helpful. > > - From patch 3: >> + if (ipv6_tests[i].ex_fails == 2) /* testing vs ex doesnt >make sense. */ >> + continue; > Please document why, it took me a while to come up with the guess above. (And I'm not even sure it's the real reason). You're also not checking the output IP for the IP tests from the non-ex tests here. Is there a reason for that? Are there any cases where -Ex returns a different IP than non-ex? Because the function will succeed on ex, it is even in the ex-test table. Cases like this are exactly why i didnt want it in one table in the first place. > >> + if (ipv6_tests[i].ip[0] == -1) >> + { >> + for (j = 0; j < 8; ++j) >> + expected_ip.s6_words[j] = 0xabab; >> + } > I guess you want to avoid writing 0xabab 8 times in the table. I don't have any objection, but I can't predict if Alexandre likes it - technically this is redundant code. I'd say keep it for now, if he doesn't like it he will tell you. Indeed. > >> + for (j = 0; j < 8; ++j) >> + expected_ip.s6_words[j] = ipv6_tests[i].ip[j]; > Would this do the right thing on big endian machines? Probably not, but I was under the impression that windows doesnt run on big endian machines. If wine does run on big endian this might need an additional check, however i do not have a b.e. machine to verify it on. > > About some individual tests: >> + { "1111:2222:3333:4444:5555:6666:7777::", STATUS_SUCCESS, 34, { 0x1111, 0x2222, 0x3333, 0x4444, 0x5555, 0x6666, 0x7777, 0 }, 1 }, > Now that's an interesting corner case. Out of curiosity, what does "1111:2222:3333:4444:5555:6666:7777:" do in non-ex and ex (one : removed)? > >> + { "::0:0:0:0:0:0:0", STATUS_SUCCESS, 13, { 0, 0, 0, 0, 0, 0, 0, 0 }, 0, 1 }, >> + { "::0:a:b:c:d:e:f", STATUS_SUCCESS, 13, { 0, 0, 0, 0xa00, 0xb00, 0xc00, 0xd00, 0xe00 }, 0, 1 }, > Here it would be interesting to know what IP -Ex writes before it fails. I don't see why -Ex would fail if -Ex calls non-ex, given that the terminator points way beyond the problematic "::" at the start. Ex doesnt write anything if it fails. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJU5xDbAAoJEN0/YqbEcdMwmEIP/0ti3aPWMeI8yetig2eTIuAG > 2QhNad7bgFgioJBremjKPDuDJViYhkv4XoIwie6bRFSF9VnEECmiv2wObhRz2e0E > MgK1bGkZc0BXs4TiVoa/+JVxWgo3ddWn1Wpj+hyVRAvyEfj4NNfRWvcGaQ+cZmwu > Sd0tx7BqCQLSPnNwyrl53nqVWjkkmARdSF2pLDMgXkwtGXlR2b2irYslYg+Sqgvb > +ORAryKZvVLt8vL6wBclb8ruFWpro7/Rio6eZb8EfoRNH+8YdYWUrdfcoCE4Ui0i > W2xsOnahZuPvuQR9id8zp4etIa+YrlGlVsIfHZrzDzCvbyuBlq+niSeWZxgNwMs+ > IUpHoHj0TYNUZ9A7PB16UPHowsPVE5GYvsdjFr4Rj8rHxQqvftpTwFxRqWuV4qkQ > Qx+achRcfA/qXWWYHksENuQJxF29vIbgiLbpvW256A6zmsAvB/+LlqndeF+BuW4I > 3rQ2H7ADBAMx8IscePSDNLAKd2vsYWj8gFlw7y10HnIE7/zedqtWPIaGocFnS0u5 > QR/ETfUW5uvOr4rqMcyMCxg3yhc/QvYV67LFMrLusJ1IlCBhcfAC4r2B91sECHXr > fJvdfGwL6HBt3tAJ5zxXZjTEwiFc77TGxswbt4lQplhFqTHfi/ZovGUiS/W3nQl6 > vX0zFtoYLTRAK0KtCNiP > =JRkZ > -----END PGP SIGNATURE-----

Feb. 20, 2015