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

Re: [PATCH 4/6] d3d8/tests: Add a test for D3DUSAGE_WRITEONLY.

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=7398 Your paranoid android. === w8 (32 bit device) === device.c:2397: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:3039: Test failed: Expected wndproc 0x412780, got 0x412780.

June 3, 2014

Re: [3/3] msvcrt: Implement 4k block flushing behavior.

by Piotr Caban

On 06/03/14 01:16, Grazvydas Ignotas wrote: > I guess defaulting to 4K buffer and flushing it if it's full on > fwrite() exit would be closer to how msvcrt operates, even though not > entirely correct. Do you prefer this solution, or perhaps something > entirely different? I would like to have it implemented as similar as possible to native dll. So taking in account that two 2k block writes doesn't flush output I don't want to do it in wine. I've added following call to your test (just after the file is opened): setvbuf(file, NULL, _IOFBF, 512); It causes following test failures on windows 7: file.c:2250: Test failed: unexpected flush by 512 byte write file.c:2250: Test failed: unexpected flush by 1024 byte write file.c:2250: Test failed: unexpected flush by 1536 byte write ... This shows that your code should depend on buffer size instead of MSVCRT_WRITE_BLOCK_SIZE. Note: keep in mind that wine's implementation of setvbuf is quite broken, it's not allocating new buffer if second argument is NULL. Thanks, Piotr

June 3, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Henri Verbeet

On 3 June 2014 08:13, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > No, because without ARB_shader_texture_lod we only support SM 2.0, > leading to inconsistencies between caps and PCI ID. > And without e.g. ARB_geometry_shader4 we can only do SM3. You'll always have that issue unless you either use the computed D3D caps to guess a card, or copy the code used to compute them. > We can also decide that we don't care about such consistency. In this > case the version logic can be removed entirely, or just used when we > cannot match the GL renderer string and have to guess a GPU. > That's the only place where this function actually does something anyway. There are calls to d3d_level_from_gl_info() in select_card_nvidia_binary() and select_card_amd_binary() for historic reasons, but at this point removing them wouldn't alter the behaviour of those functions in a significant way. (Hypothetic future versions of the proprietary drivers that remove extensions aside.)

June 3, 2014

Re: [PATCH 0/4] Improve compilation with musl libc

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-06-01 11:29, schrieb Felix Janda: > The first two patches merely fix warnings because of use of > deprecated headers. So they are not strictly necessary. The patches > should also update configure but why is configure at all in the git > repo? You don't have to update configure in your patches. Alexandre takes care of this when he commits them. I am not certain why we have configure in the git repo, but I suspect it's either for convenience or because some external autoconf macros are needed to generate configure that may not be installed on every developer's machine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTjWnDAAoJEN0/YqbEcdMwbS4P/ROVbg69Ive22j6U6eU3iEum oMWWaUpklTmg3AsGjeJv/lMPNhptAPK5oG1u4YEtUbYFDM96kS0kCgbSpu2Khfe0 nVVnIG1l5eeM/koNST6LxoSzFcDQl+v13MsTUUJlccHhMHdZ2uIvEVMXVH6i6oby +YD384rLi+iBqZtz5obzdsJWuALL9RZrLB9CA0bQ5W0sAiwqnXld/nn4OpcvDA1H fyEk/Ebh9AiRFa0rK2WclCwQhIiQxmvPQdDBht7jZ3YIsHIAyFX5KAVn83zp5fTw 6H1Ap5t+cJDUWDArScDyrgqcNeeal4bcCxNp98fDZfrBN09qjUrW24WHD+BXFzhH 25UIp5hJrZ0YzNj9LRFbB8Z83MfvyW7OgZtWp4EhQ4BbL/DwZ4KhvVoDglHtoz+o FHqnwiFWjq0OhBi8PKJvAQVwRjr0KCX4lt3Sf7cIhojKKTVb2rhf4sT1fCL7DdPo o08fBv4/k0Ve3XT+NqbqXuiNCyvVFMs2AcXS+3mHjg8JUBW7kDG/Yzzfa1m6cHlg 3nfGPJgx4vItKb3mnpIFzZ7AvGyyIc4YgGKN5WFSuMJXrqQc+7xBs1G14xvCOfeJ NNaYUGOe3qJVfIOb9rOZGa3tx87i5BqxnKsjokUUd7XJTa77ZUNxr0s8cbIWqbQv htChu9mjcagNeMEAi8iO =18zQ -----END PGP SIGNATURE-----

June 3, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-06-02 23:11, schrieb Henri Verbeet: > You're right, I mixed up 1.30 and 1.50 there. I probably should > have actually checked before writing a reply. (We'll probably end > up using 1.50 for e.g. geometry shaders on Mesa, but that aside.) > Checking for ARB_shader_texture_lod as well is redundant in that > case though. No, because without ARB_shader_texture_lod we only support SM 2.0, leading to inconsistencies between caps and PCI ID. We can also decide that we don't care about such consistency. In this case the version logic can be removed entirely, or just used when we cannot match the GL renderer string and have to guess a GPU. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTjWeUAAoJEN0/YqbEcdMw814P/jKrZAcCMRHwzdLcSYMOSPa4 miKtuup9xaj0ZL0mVvUw8jgSEVGw5lOIvZ4s6o2BshzQbgHlBu9+lEN/nDIWg+gG WKjiJIaN1Q4FOjRbkqNaNJ2kwMeMNwccb5l5Y+swEDZUWeyjPNdqwrubvbMvJme9 IU3DyeQdk3+G3KgC6tf0FQp54qSbRMTnNQABWoBJRLMeLKd6FGP113++jk+ah4kU k6g/aSfVUtbMkrep8N40GIMSGo2Y0j7OZxukzC/pWkR+GIa3YP1fodN2VUGgF9Gs jvjhhsXOc4V/VBq/Ohm+V6ULWyAZNY3bTh3TIbjx/Sxq7f2vyJkiuqZWe4yy8CVr 6smDLGNHRs3jSj95+/m+mn2bI5bivuAQCTNQ2dZhAo4kHEoOe9wrTKzShCH+2Heg fRAA00filFFtHNjaJJFt91AJJDU8mnWvKU2miWZO+YkTN7ScbnHLQ39woDxKA0ZL fw6fo+oa0Lx5gQZfs9M90sRoCzsJIBAWFzKqwFashuy2xHGxzvUAcZ0QgFcI5XBW 9GuesTjbwk1uWRFm6Bojs4cbGSUK0wWhGST5aUTVg8+/3RtipxNDX04C84N58X19 uYvsMcON6fVxEEcZE6BPY1f1tuIjvVAVP7VUMPazh+XdUguWUbqpgqnmceFU/uFj APLf/3sGfFai4Q6iYNzr =Vmzt -----END PGP SIGNATURE-----

June 3, 2014

Re: [3/3] msvcrt: Implement 4k block flushing behavior.

by Grazvydas Ignotas

On Sun, Jun 1, 2014 at 12:38 PM, Piotr Caban <piotr.caban(a)gmail.com> wrote: > On 05/31/14 01:00, Grazvydas Ignotas wrote: >> >> + } else if(wrcnt >= MSVCRT_WRITE_BLOCK_SIZE) { >> + if(msvcrt_set_write_direction(file) != 0) >> + break; >> + >> + if(file->_bufsiz && file->_ptr != file->_base) >> + if(msvcrt_flush_buffer(file) == MSVCRT_EOF) >> + break; >> + >> + if(MSVCRT__write(file->_file, ptr, MSVCRT_WRITE_BLOCK_SIZE) >> <= 0) { >> + file->_flag |= MSVCRT__IOERR; >> + break; >> + } >> + written += MSVCRT_WRITE_BLOCK_SIZE; >> + wrcnt -= MSVCRT_WRITE_BLOCK_SIZE; >> + ptr = (const char*)ptr + MSVCRT_WRITE_BLOCK_SIZE; > > This doesn't look right for me. It doesn't make sense to have some special > size blocks written in different way. > > I think this is caused by 2 differences in native and wine's implementation > of fwrite: > - if you check file->_bufsiz value on windows it's set to 4096 (on wine > it's 512), this is probably causing the flash to be done when 4096 bytes are > written I don't think so, as doing 2K fwrites 2 times (for example) doesn't trigger the flush, only a single write >= 4K does. > - probably there's some kind of optimization that writes integral number of > buffers directly to file Yes and this is what I'm trying to implement/simulate here.. > - I was not checking it but maybe native flushes the output when buffer is > full, wine will exit fwrite with full buffer in this case As mentioned above, no it does not. Doing it this way would fix IDA, but I fear it may break something else. IDA does 8K writes at random offsets of it's database file, then does fileno() and some lseeks, after that it goes back to using stdio (does fseek() first), but at that point the flush will go to last lseek it did and corrupt it's database. I guess defaulting to 4K buffer and flushing it if it's full on fwrite() exit would be closer to how msvcrt operates, even though not entirely correct. Do you prefer this solution, or perhaps something entirely different? -- Gražvydas

June 2, 2014

Re: [PATCH 1/4] Use <poll.h> instead of <sys/poll.h>

by Juan Lang

On Mon, Jun 2, 2014 at 3:01 PM, Felix Janda <felix.janda(a)posteo.de> wrote: > Juan Lang wrote: > > Hi Felix, > > > > On Sun, Jun 1, 2014 at 1:16 AM, Felix Janda <felix.janda(a)posteo.de> > wrote: > > > > > This patch changes includes of <sys/poll.h> to <poll.h>, removes > > > the configure test for <sys/poll.h> and makes the whitespace of > > > the includes consistent. > > > > > > > Patches should be sent to wine-patches(a)winehq.org, not wine-devel(a). See > > http://wiki.winehq.org/SubmittingPatches. Also, the maintainer is on > > vacation, so don't expect a quick response. > > Thanks for your reply. I was unsure where to send the mails because of > the discussion in the cover letter (see [PATCH 0/4]). Should I resend > the patches? > Yes, please do. If they disappear into the ether, try again in a couple of weeks. --Juan

June 2, 2014

Re: [PATCH 1/4] Use <poll.h> instead of <sys/poll.h>

by Felix Janda

Juan Lang wrote: > Hi Felix, > > On Sun, Jun 1, 2014 at 1:16 AM, Felix Janda <felix.janda(a)posteo.de> wrote: > > > This patch changes includes of <sys/poll.h> to <poll.h>, removes > > the configure test for <sys/poll.h> and makes the whitespace of > > the includes consistent. > > > > Patches should be sent to wine-patches(a)winehq.org, not wine-devel(a). See > http://wiki.winehq.org/SubmittingPatches. Also, the maintainer is on > vacation, so don't expect a quick response. Thanks for your reply. I was unsure where to send the mails because of the discussion in the cover letter (see [PATCH 0/4]). Should I resend the patches? Thanks, Felix

June 2, 2014

Re: Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Henri Verbeet

On 2 June 2014 18:51, Andrei Slavoiu <andrei.slavoiu(a)gmail.com> wrote: > Actually, it does. No SM3 card can expose GLSL 1.30. You're right, I mixed up 1.30 and 1.50 there. I probably should have actually checked before writing a reply. (We'll probably end up using 1.50 for e.g. geometry shaders on Mesa, but that aside.) Checking for ARB_shader_texture_lod as well is redundant in that case though. > Like you say, the extensions are arbitrary, so why not use GLSL version as > well? GLSL 1.30 also adds support for integers and bitwise operations. All Sure, checking the GLSL version is fine. > The reason I prefer to improve the fallback instead of simply adding the PCI > ID for my card to the list of known cards is that with the current model there > will always be cards that are not recognized by wine and a good fallback will > prevent the experience for a newbie being "nothing works, wine sucks". Sure. The number of applications that really cares about the name of the card returned etc. should be fairly limited though, and I'm a bit surprised that World of Warcraft does. Are you sure the issue is really with the reported card, as opposed to e.g. the amount of video memory associated with it? CARD_AMD_RADEON_9500 has 64MB, which really isn't a lot by today's standards.

June 2, 2014

Re: ntdll: Use lockfree implementation for get_cached_fd.

by Ken Thomases

Hi, On May 31, 2014, at 2:13 PM, Sebastian Lackner wrote: > What do you think about the alternative (slightly slower, but much > easier to verify) solution attached to this mail? It looks good except for one issue. The assert() macro should never contain meaningful work. If NDEBUG is defined, the whole macro becomes (void)0. The expression is not evaluated. As expected, the thread-safety of this approach is much more easily analyzed and looks good to me. The ugliness for support for PowerPC is unfortunate, but probably still less ugly than the other approach with all necessary barriers inserted. -Ken

June 2, 2014