October 2015 - Wine-devel - list.winehq.org

Re: [PATCH 2/2] dxgi/tests: Add test for IDXGIAdapter::CheckInterfaceSupport().
by Marvin 12 Oct '15

12 Oct '15

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=17277 Your paranoid android. === w1064 (32 bit device) === device.c:1188: Test failed: Got unexpected hr 0, test 16. device.c:1242: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1242: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1242: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1242: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1188: Test failed: Got unexpected hr 0, test 39. device.c:1242: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1242: Test failed: Got usage 160, expected 60, test 42, buffer 15. === w1064 (64 bit device) === device.c:1188: Test failed: Got unexpected hr 0, test 16. device.c:1188: Test failed: Got unexpected hr 0x87a0001, test 39.

1 0

Re: [PATCH 3/3] ws2_32: Add asynchronous support for TransmitFile (resend).
by Marvin 12 Oct '15

12 Oct '15

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=17267 Your paranoid android. === w7pro64 (32 bit sock) === sock.c:7346: Test failed: bytesReturned isn't supposed to be 1 sock.c:7370: Test failed: GetOverlappedResult failed, error 0

1 0

Speed of gdi vs opengl DirectDrawRenderer
by Jonas Maebe 11 Oct '15

11 Oct '15

Hi, 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). I'm using wine 1.7.35, but I've had similar problems with older wine versions. It's a DirectDraw7 game that has been partially remastered to run on modern systems, but still uses DirectDraw7. This is a common problem on Windows too, but generally can be resolved by telling the game to use the DirectDraw blitter (instead of blitting itself). That didn't help on Wine though. 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. Then I discovered that if I told the game to render to a 16 bit instead of to a 32 bit surface, wine would let OpenGL handle the colour conversion. Unfortunately, while this significantly reduced wine's cpu usage, it by no means made the game any faster. Looking at the OpenGL Driver Monitor stats, it seems the cpu was simply waiting all the time on the GPU, probably while it was blitting all of those 1920x1080 images to the screen. Reducing the resolution to the lowest supported by the game (800x600) made it slightly faster, but not much. Next, I added the DirectDrawRenderer registry key and set it to gdi. Now, while it's still slow at 1920x1080, the game runs much faster at 800x600 and even still at 1024x768. Profiling the gdi renderer shows that it has way higher cpu usage than the OpenGL renderer (virtually all in convert_to_8888), but it seems that for some reason it has causes much less traffic to the GPU. The wiki's wording suggests the gdi renderer is deprecated though. Does that mean this qualifies as a bug in the OpenGL renderer (maybe it tries to update the screen more often than necessary, saturating the bus that way?), and are there any things I can try to narrow down why the gdi renderer is so much faster? I didn't immediately see where it blits things actually to the screen. Thanks, Jonas

4 10

Total bugs in WWN Issue 400
by Mathew Hodson 11 Oct '15

11 Oct '15

How is it that in WWN Issue 400, https://www.winehq.org/wwn/400, the total number of bugs has decreased? Was that an error or have some bugs been deleted? -- Sincerely, Mathew Hodson

4 4

wiki.winehq.org is down
by Austin English 11 Oct '15

11 Oct '15

Thought it may be my connection while travelling, but isup.me confirms it's down: http://isup.me/wiki.winehq.org could you please have a look? Thanks, -Austin

3 2

Re: [PATCH 1/6] d3d8: make use of wined3d_texture_map in d3d8_surface_LockRect
by Stefan Dösinger 11 Oct '15

11 Oct '15

2 1

stack realignment
by Marcus Meissner 11 Oct '15

11 Oct '15

Hi, (as small heads up) As we have this problem with the Win64 code calling us with non-16 byte aligned stacks, the gcc folks have now commited code to trunk gcc that allows -mincoming-stack-boundary=3 on October 7th. Uros also plans a backport for gcc 5. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66697 $ cat xx.c #include <stdio.h> int f(int a,int b) { printf("a=%d, b=%d\n", a, b); } -O2 build: 0000000000000000 <f>: 0: 89 f2 mov %esi,%edx 2: 31 c0 xor %eax,%eax 4: 89 fe mov %edi,%esi 6: bf 00 00 00 00 mov $0x0,%edi b: e9 00 00 00 00 jmpq 10 <f+0x10> -O2 -mincoming-stack-boundary=3 0000000000000000 <f>: 0: 4c 8d 54 24 08 lea 0x8(%rsp),%r10 5: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 9: 89 f2 mov %esi,%edx b: 31 c0 xor %eax,%eax d: 89 fe mov %edi,%esi f: bf 00 00 00 00 mov $0x0,%edi 14: 41 ff 72 f8 pushq -0x8(%r10) 18: 55 push %rbp 19: 48 89 e5 mov %rsp,%rbp 1c: 41 52 push %r10 1e: 48 83 ec 08 sub $0x8,%rsp 22: e8 00 00 00 00 callq 27 <f+0x27> 27: 48 83 c4 08 add $0x8,%rsp 2b: 41 5a pop %r10 2d: 5d pop %rbp 2e: 49 8d 62 f8 lea -0x8(%r10),%rsp 32: c3 retq It is more code emitted, but we can at least fix it without generating our own thunks. Ciao, Marcus

2 2

WineConf 2015 decisions
by Alexandre Julliard 10 Oct '15

10 Oct '15

Over the last few months there have been a lot of discussions about how to improve our development process. I've been gathering feedback, and last week at WineConf I summarized the suggestions in my keynote presentation; the slides can be viewed at http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=winecon… We've then had a lot of constructive discussions about the various points. The major decisions we've agreed on are: - Wine-staging is now considered an integral part of the Wine development process, and will be used as a mechanism to enable more patches to meet the requirements for inclusion in the main tree. We will all be working together as a team. - Bugs reported against wine-staging will be accepted in the WineHQ bug tracker; there will be a way to distinguish bugs specific to Staging, and bugs that are fixed in Staging but not yet in main Wine. The Staging bug tracker will be retired. Austin English is in charge of implementing the necessary changes in Bugzilla. - We will switch to a time-based stable release, on a yearly schedule. The code freeze will start every year in the fall. Michael Stefaniuc will be maintaining the stable branch starting with 1.8. - We will start enforcing a Signed-Off-By header on patches, to make it possible to better distribute reviewing responsibility, and to allow multiple authors to cooperate on a patch. - We will keep a list of maintainer contact information for the various submodules; developers will be encouraged to go through the respective maintainer before submitting to wine-patches. - There will be a group of people who volunteer to be assigned patches to review, to make sure that no patch goes unreviewed. Going through Staging first will also be encouraged for unfinished or risky patches. - The patch tracker will send automated emails when a patch status changes; this will also serve to encourage discussion rather than despair when a patch is not approved. - We will start building and distributing binary packages for all distros that don't have readily available packages. The packaging scripts and control files will be maintained in git, so that people can review them and submit improvements. These changes will be implemented over the next few weeks. I'm hoping that this will make the development process more pleasant for everybody, and enable us to better respond to users' needs. Once these changes are in place, I'll also encourage everybody who had given up in disgust to give us another chance; and if things are still not satisfactory, please send us feedback. This is a work in progress, and we will continue to listen and work on making things better. -- Alexandre Julliard julliard(a)winehq.org

9 17

Re: kernel32: add a stub for GetCurrentProcessorNumberEx (try 2)
by Sebastian Lackner 09 Oct '15

09 Oct '15

On 09.10.2015 12:15, Austin English wrote: > Try 2: > move implementation to ntdll.RtlGetCurrentProcessorNumberEx with a > forward from kernel32. > Initialize Group/Processor to 0. > > For https://bugs.winehq.org/show_bug.cgi?id=39376 > > +/********************************************************************** > + * RtlGetCurrentProcessorNumberEx [NTDLL.@] > + */ > +VOID WINAPI RtlGetCurrentProcessorNumberEx(PPROCESSOR_NUMBER processor) I think its preferred to use PROCESSOR_NUMBER * here. > +{ > + processor->Group = 0; > + processor->Number = 0; The ->Number member could be initialized to the result to NtGetCurrentProcessorNumber(). Initializing ->Group to 0 is correct because Wine supports max 64 processors. According to MSDN, the struct also has a ->Reserved member, which probably should be set to zero. > + > + FIXME(":%p stub\n", processor); It might be better to print the FIXME before accessing the pointer, this allows to see if applications pass garbage pointers before the crash happens. ;) > +}

2 1

Re: [PATCH 5/5] maintainers: Update Direct3D-related sections.
by Stefan Dösinger 09 Oct '15

09 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-10-09 um 15:55 schrieb Matteo Bruni: > Stefan, I'm putting d3drm under the general Direct3D section at > the moment. Feel free to change that as you see fit. Fine with me :-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWF8a0AAoJEN0/YqbEcdMw96oP/j1MyVZNxrVNRFg7v6K1b6Zn mTbnDc17oZbrJOnUYTNs+FJhaCvffj5wFRh8dB1piX6ayMpvItzoTOFnYzhYowIS iElwL/V7iYr8x4fojbrn8OestiaI7j41Rv4jlTNLfcnMtbbBYonM3oxDkFxJhQPp lsKw5/qOPfDpw2RFry5d3FTbhpKcy6vdQHPcCa4fb0E/pHvvCtwCH00pje5TIO7b fV2FUl8YEbMHpP1W1zY9m2jWDuPk3ke14g/KsGBXcB3PVZUtqPw4Tb4hCjBsXEzr WMyv3LqLw3vvWwtGpN49pLSAE0jHiSMCbH1fq4kNsZkT7TdB3he7vce1ckzRQWKh cvL1DmrL4TfVv1nH3bENX9I80I5SDRlg8EFWI/BYQZgNGun4fXweslHZISBz4CqZ VpZO/PpDOtM6DJhDXn0WDgYqNKC7GsLsx8TPsNpLPt+f/aSM+0ozZUmwDWtZW1HX m0lwn2sXoJzVwZ858ukmLRh8KtXJhl3Nupp0Eppa3IbYCwZOWERcwyhSDV6CB5gD lLmff2NPBirX7/yAC3D5NXEcvIxEk7nJPi01EY+b8iofIlrIUHzfrNeKkEpDAv89 oM9DwD7ZwzO5ga8EDYMdDGV/UhmZlFRAWyYC9oz4M8QGyiHwmtuA6VGgGiYtCYjy /jvROBtdjkiTTUpb24i4 =mAJR -----END PGP SIGNATURE-----

1 0