June 2011 - Wine-Devel - list.winehq.org

Re: [4/4] d3dx9/tests: Add tests for D3DXLoadMeshFromXInMemory.

by Dylan Smith

I can't seem to reproduce this patch apply failure. Is there a way to check if the wine testbot is building against origin (currently commit 5bf7622fc3ad043cb17accfefcaf5b6371f80a8e)? Because the apply failure is completely consistent with applying my patchset against yesterdays last commit (441f735f418f347ded3ba3f2cfa1643cc449fac9). On Tue, Jun 7, 2011 at 7:55 PM, Marvin <testbot(a)testbot.winehq.org> wrote: > > 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 > http://testbot.winehq.org/JobDetails.pl?Key=11553 > > Your paranoid android. > > > === WINEBUILD (build) === > Patch failed to apply

June 8, 2011

Re: [4/4] d3dx9/tests: Add tests for D3DXLoadMeshFromXInMemory.

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 http://testbot.winehq.org/JobDetails.pl?Key=11553 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

June 7, 2011

Re: wined3d performance patches

by Emanuele Oriani

Hi Stefan/Matteo, Thanks very much for the effort. I'd like to contribute/help but I don't have a lot of time at the moment to patch and recompile. If you have the wined3d.dll.so saved somewhere I could try it with Starcraft II and let you know (at the moment I have wine-1.3.21 installed). Cheers, Emanuele On 07/06/11 00:26, Stefan Dösinger wrote: > On Monday 06 June 2011 17:55:43 Stefan Dösinger wrote: >> Feedback is welcome. I'm also interested in test results, e.g. if the >> changes break a game, or the performance impact. If those patches cause a >> 5% performance increase I am happy. > Here are some results from my Radeon test machine: http://bit.ly/mi0i5J . It's > about a 1% increase in the real Windows apps, much less than I hoped for. I'll > test on Nvidia tomorrow, and manually test a few more (newer) apps for which I > don't have PTS tests yet. > > For the curious, these are the URLs to my nightly trackers: > Radeon 5750: > http://openbenchmarking.org/result/1106056-GR-WINE1321145&track_view=20 > Geforce 7600: > http://openbenchmarking.org/result/1106064-GR-WINE1321175&track_view=20 > > Watch out for the result ordering. Basically the results are ordered from > newest to oldest(left to right), but the Radeon test is a bit more confusing. > Openbenchmarking.org orders it in the order I uploaded the results. The Nvidia > box boots automatically, the Radeon box is booted manually. So I forgot about > the radeon box a few days and tested the older Wine versions a few days later. > This is something Michael Larabel and I still have to work on. > > Also the uptick in the Radeon tests is the test I ran with my performance > patches applied. I forgot to change the result identifier, so OB.org picks it > up like a normal nightly test. > > Note that the Unigine Heaven tests are using the opengl backend right now. The > other tests are D3D-based. > > The source code for the d3d_clear, d3d_streamsrc and d3d_drawprim tests is > available at https://84.112.174.163/~git/perftest (This is a git repo). I hope > the server is stable finally. > > Stefan > > >

June 7, 2011

Re: [PATCH 5/5] wined3d: Rename IWineD3DDeviceImpl_LoadLogo() to device_load_logo().

by Henri Verbeet

On 7 June 2011 20:40, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Tuesday 07 June 2011 19:44:49 Henri Verbeet wrote: >> if (wined3d_settings.logo) >> - IWineD3DDeviceImpl_LoadLogo(device, wined3d_settings.logo); >> + device_load_logo(device, wined3d_settings.logo); > Does the logo stuff still work? I thought about removing it, I don't think it > has any use. > I don't know, I'm just fixing the naming here. I'm not terribly attached to that code, if you want to remove it that's fine with me.

June 7, 2011

Re: [6/7] server: Implement RegisterHotKey/UnregisterHotKey.

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 http://testbot.winehq.org/JobDetails.pl?Key=11551 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 7, 2011

Re: [5/7] user32: Do not check the last error on succeeding hotkey calls.

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 http://testbot.winehq.org/JobDetails.pl?Key=11550 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 7, 2011

Re: [4/7] user32: Test registering the same hotkey hwnd/id pair twice.

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 http://testbot.winehq.org/JobDetails.pl?Key=11549 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 7, 2011

Re: [3/7] user32: Add test showing hotkeys change the async key state.

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 http://testbot.winehq.org/JobDetails.pl?Key=11548 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 7, 2011

Re: [2/7] user32: Ignore paint messages in hotkey tests.

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 http://testbot.winehq.org/JobDetails.pl?Key=11547 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 7, 2011

Re: [PATCH 5/5] wined3d: Rename IWineD3DDeviceImpl_LoadLogo() to device_load_logo().

by Stefan Dösinger

On Tuesday 07 June 2011 19:44:49 Henri Verbeet wrote: > if (wined3d_settings.logo) > - IWineD3DDeviceImpl_LoadLogo(device, wined3d_settings.logo); > + device_load_logo(device, wined3d_settings.logo); Does the logo stuff still work? I thought about removing it, I don't think it has any use. The original intentions were for debugging(Is wined3d used on Windows?) and for making nice and fancy screenshots, but I don't think anyone uses it.

June 7, 2011

Re: [1/7] user32: Add test for flags on keyboard messages.

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 http://testbot.winehq.org/JobDetails.pl?Key=11546 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 7, 2011

Re: Various locale tests for wine

by Austin English

On Tue, Jun 7, 2011 at 11:05, Akihiro Sagawa <sagawa.aki(a)gmail.com> wrote: > Hi, > I have a problem about testing wine where specific to locales (or ANSI > code pages). Because test bots don't seem to test wine in non-English > locales. I'd like to get wine's test results in various locale > environments from test.winehq.org. > > Firstly, as a wine intended to handle locale properly, all tests should > succeed in any locales. We could discover locale-depended failure in > other locales. Secondly, if I add a locale specific test, it easy to > prove the issue to others. > > In my opinion, adding Russian, Japanese and Chinese would be better. > They are tested by existing XP bots. So how about adding non-English > wine environments to the testbot farm? The testbot currently doesn't run on wine machines. If/when that happens, this is a reasonable request, however. I'll try to get my wine test scripts back up as soon as possible. Once that's done, adding some other locales shouldn't be too difficult... -- -Austin

June 7, 2011

Various locale tests for wine

by Akihiro Sagawa

Hi, I have a problem about testing wine where specific to locales (or ANSI code pages). Because test bots don't seem to test wine in non-English locales. I'd like to get wine's test results in various locale environments from test.winehq.org. Firstly, as a wine intended to handle locale properly, all tests should succeed in any locales. We could discover locale-depended failure in other locales. Secondly, if I add a locale specific test, it easy to prove the issue to others. In my opinion, adding Russian, Japanese and Chinese would be better. They are tested by existing XP bots. So how about adding non-English wine environments to the testbot farm? -- Best Regards, Akihiro Sagawa

June 7, 2011

Re: [PATCH 2/5] wined3d: Just enable ARB_shader_texture_lod if it's available.

by Matteo Bruni

2011/6/7 Henri Verbeet <hverbeet(a)gmail.com>: > On 7 June 2011 14:39, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>> Well, it may be, but the instruction we care about here is texldl. I >>> could of course add a usestexldl condition, but afaik there isn't any >>> reason not to enable ARB_shader_texture_lod if it's available. >>> >> >> Actually, there is already a usestexldl flag around. Unlikely that it >> would make any practical difference though... >> > Yes. In case it wasn't entirely clear, what I meant was adding > "reg_maps->usestexldl" to the existing "reg_maps->usestexldd" > condition for enabling the extension. > Yep, I misunderstood...

June 7, 2011

Re: [PATCH 2/5] wined3d: Just enable ARB_shader_texture_lod if it's available.

by Henri Verbeet

On 7 June 2011 14:39, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> Well, it may be, but the instruction we care about here is texldl. I >> could of course add a usestexldl condition, but afaik there isn't any >> reason not to enable ARB_shader_texture_lod if it's available. >> > > Actually, there is already a usestexldl flag around. Unlikely that it > would make any practical difference though... > Yes. In case it wasn't entirely clear, what I meant was adding "reg_maps->usestexldl" to the existing "reg_maps->usestexldd" condition for enabling the extension.

June 7, 2011

Re: [PATCH 2/5] wined3d: Just enable ARB_shader_texture_lod if it's available.

by Matteo Bruni

2011/6/7 Henri Verbeet <hverbeet(a)gmail.com>: > On 7 June 2011 11:16, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> On Tuesday 07 June 2011 11:06:25 Henri Verbeet wrote: >>> - if (gl_info->supported[ARB_SHADER_TEXTURE_LOD] && >>> reg_maps->usestexldd) >> Why is reg_maps->usestexldd not true in pixel shaders? >> > Well, it may be, but the instruction we care about here is texldl. I > could of course add a usestexldl condition, but afaik there isn't any > reason not to enable ARB_shader_texture_lod if it's available. > Actually, there is already a usestexldl flag around. Unlikely that it would make any practical difference though...

June 7, 2011

Re: testbot flakiness?

by Frédéric Delanoy

On Mon, Jun 6, 2011 at 03:17, Dan Kegel <dank(a)kegel.com> wrote: > https://testbot.winehq.org/JobDetails.pl?Key=11509 shows failures and > crashes, but the nearly identical > https://testbot.winehq.org/JobDetails.pl?Key=11510 does not. (The latter one > just adds a call to GetProcessMemoryInfo() in the xyz() logging function.) > > And the failure shown by the first patch has a last error > on creating the batch file of 8, ERROR_NOT_ENOUGH_MEMORY, which is suspicious. > > Not quite sure what's going on there. I made some tests to get a minimal patch where this occurs, and it's rather weird: problem occurs when the "rem" line precedes the "call :setError 0" call WORKS https://testbot.winehq.org/JobDetails.pl?Key=11540 +echo -----------Testing mkdir ----------- +call :setError 0 + https://testbot.winehq.org/JobDetails.pl?Key=11539 +echo -----------Testing mkdir ----------- +rem Creating an already existing directory must fail + DOES NOT WORK https://testbot.winehq.org/JobDetails.pl?Key=11538 +echo -----------Testing mkdir ----------- +rem Creating an already existing directory must fail +call :setError 0 +

June 7, 2011

Re: [PATCH 2/5] wined3d: Just enable ARB_shader_texture_lod if it's available.

by Stefan Dösinger

On Tuesday 07 June 2011 11:43:17 Henri Verbeet wrote: > On 7 June 2011 11:16, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > On Tuesday 07 June 2011 11:06:25 Henri Verbeet wrote: > >> - if (gl_info->supported[ARB_SHADER_TEXTURE_LOD] && > >> reg_maps->usestexldd) > > > > Why is reg_maps->usestexldd not true in pixel shaders? > > Well, it may be, but the instruction we care about here is texldl. I > could of course add a usestexldl condition, True, my bad. In that sense the usestexldd condition was broken anyway. > but afaik there isn't any reason not to enable ARB_shader_texture_lod if > it's available. Yep, at least not unless there's some driver bug that triggers a slowdown like with enabling GL_NV_fragment_program* in ARB shaders. I guess my nightly tests will tell us tomorrow. Fwiw, I don't expect ARB_shader_texture_lod to cost anything at least on Nvidia because their GLSL compiler enables NVfp anyway and it provides support for TXL in any case.

June 7, 2011

Re: [PATCH 2/5] wined3d: Just enable ARB_shader_texture_lod if it's available.

by Henri Verbeet

On 7 June 2011 11:16, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Tuesday 07 June 2011 11:06:25 Henri Verbeet wrote: >> - if (gl_info->supported[ARB_SHADER_TEXTURE_LOD] && >> reg_maps->usestexldd) > Why is reg_maps->usestexldd not true in pixel shaders? > Well, it may be, but the instruction we care about here is texldl. I could of course add a usestexldl condition, but afaik there isn't any reason not to enable ARB_shader_texture_lod if it's available.

June 7, 2011

Re: [PATCH 2/5] wined3d: Just enable ARB_shader_texture_lod if it's available.

by Stefan Dösinger

On Tuesday 07 June 2011 11:06:25 Henri Verbeet wrote: > - if (gl_info->supported[ARB_SHADER_TEXTURE_LOD] && > reg_maps->usestexldd) Why is reg_maps->usestexldd not true in pixel shaders?

June 7, 2011

Re: wined3d performance patches

by Stefan Dösinger

On Monday 06 June 2011 17:55:43 Stefan Dösinger wrote: > Feedback is welcome. I'm also interested in test results, e.g. if the > changes break a game, or the performance impact. If those patches cause a > 5% performance increase I am happy. Here are some results from my Radeon test machine: http://bit.ly/mi0i5J . It's about a 1% increase in the real Windows apps, much less than I hoped for. I'll test on Nvidia tomorrow, and manually test a few more (newer) apps for which I don't have PTS tests yet. For the curious, these are the URLs to my nightly trackers: Radeon 5750: http://openbenchmarking.org/result/1106056-GR-WINE1321145&track_view=20 Geforce 7600: http://openbenchmarking.org/result/1106064-GR-WINE1321175&track_view=20 Watch out for the result ordering. Basically the results are ordered from newest to oldest(left to right), but the Radeon test is a bit more confusing. Openbenchmarking.org orders it in the order I uploaded the results. The Nvidia box boots automatically, the Radeon box is booted manually. So I forgot about the radeon box a few days and tested the older Wine versions a few days later. This is something Michael Larabel and I still have to work on. Also the uptick in the Radeon tests is the test I ran with my performance patches applied. I forgot to change the result identifier, so OB.org picks it up like a normal nightly test. Note that the Unigine Heaven tests are using the opengl backend right now. The other tests are D3D-based. The source code for the d3d_clear, d3d_streamsrc and d3d_drawprim tests is available at https://84.112.174.163/~git/perftest (This is a git repo). I hope the server is stable finally. Stefan

June 6, 2011

re: GSoC: dinput8 Action Mapping

by Dan Kegel

Lucas asked: > Should I correct the tabs and align the > parameters in the function prototype when I implement them? If you do a significant rewrite of a function, or are implementing it for the first time, I think it's ok to use more standard code style in your new code, or to update the style of adjacent old code (like a prototype) related to your change.

June 6, 2011

Re: GSoC: dinput8 Action Mapping

by Lucas Zawacki

Just a simple doubt. Should I correct the tabs and align the parameters in the function prototype when I implement them? For instance SetActionMap and BuildActionMap have a lot of them. Thanks

June 6, 2011

Re: wined3d: Enable blit stretching for 64 bpp

by André Hentschel

Am 05.06.2011 02:47, schrieb Stefan Dösinger: > On Saturday 04 June 2011 18:24:39 André Hentschel wrote: > >> + case 8: >> + STRETCH_ROW(DWORD64); >> + break; > 64 bit formats can be floating point formats too, like ARGB16F, or RG32F. But > Roderick's comment catches the more important issue: This code shouldn't be > called for 64 bit formats at all since they are only supported with FBOs which > bring hardware blitting support. > > > > Hi Stefan and Roderick, is should stop trying to send "3D" patches :) either they are wrong or lead to regressions... -- Best Regards, André Hentschel

June 6, 2011

Re: [3/3] kernel32/heap: Add registry caps for reported memory. (resend)

by Adam Martinson

On 06/06/2011 11:22 AM, Andrew Nguyen wrote: > On 06/06/2011 11:03 AM, Adam Martinson wrote: >> + /* Only check this once */ >> + if (!cache_lastchecked) >> + { >> + HMODULE hadvapi32 = LoadLibraryA("advapi32.dll"); >> +#define ADVAPI32_GET_PROC(func) typeof(func) * p ## func = (void*)GetProcAddress(hadvapi32, #func) >> + ADVAPI32_GET_PROC(RegOpenKeyExA); >> + ADVAPI32_GET_PROC(RegCloseKey); >> + ADVAPI32_GET_PROC(RegGetValueA); > I think you want to use NtCreateKey and NtQueryValueKey instead of > dynamically loading advapi32 for registry functionality. > > > > Hmm, ye I think you're right, thanks.

June 6, 2011