September 2013 - Wine-devel

Re: wininet: Don't start the next chunk if the read is satisfied.
by Jacek Caban 04 Sep '13

04 Sep '13

Hi Hans, On 09/04/13 09:22, Hans Leidekker wrote: > --- > dlls/wininet/http.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c > index 1832b4f..521e4aa 100644 > --- a/dlls/wininet/http.c > +++ b/dlls/wininet/http.c > @@ -2795,7 +2795,7 @@ static DWORD chunked_read(data_stream_t *stream, http_request_t *req, BYTE *buf, > chunked_stream_t *chunked_stream = (chunked_stream_t*)stream; > DWORD read_bytes = 0, ret_read = 0, res = ERROR_SUCCESS; > > - if(chunked_stream->chunk_size == ~0u) { > + if(!chunked_stream->chunk_size || chunked_stream->chunk_size == ~0u) { > res = start_next_chunk(chunked_stream, req); > if(res != ERROR_SUCCESS) > return res; > @@ -2835,7 +2835,7 @@ static DWORD chunked_read(data_stream_t *stream, http_request_t *req, BYTE *buf, > chunked_stream->chunk_size -= read_bytes; > size -= read_bytes; > ret_read += read_bytes; > - if(!chunked_stream->chunk_size) { > + if(size && !chunked_stream->chunk_size) { > assert(read_mode != READMODE_NOBLOCK); > res = start_next_chunk(chunked_stream, req); > if(res != ERROR_SUCCESS) This patch breaks two assumptions: - chunk_size outside chunked_read means the end of the stream - READMODE_SYNC should read as much data as possible There is longer story about the way it's implemented the way it is. Native IE in the past considered zero-length reporting data in INTERNET_STATUS_REQUEST_COMPLETE to be an error. If you stop reading in the end of chunk and the next chunk is the last one, then you will send such report asynchronously. That's why we read the whole chunk only if we can start reading the next one (and we can't if we don't want to block). Now I think that the failure could possibly be caused by a combination of returning zero size and some other bug and the behaviour that I described could just hide the problem. Commit 851866e22a731141da7e3cbd2550c67c59968959 fixed a problem that could potentially be the other one. This means that I'm not entirely sure that we really shouldn't report zero size data. This is illogical to begin with, but we even have tests for that: ok(!on_async, "Returned zero size in response to request complete\n"); I think we should try harder to have a test reporting zero size data (this may be tricky to write one for Wine tests, but if we could just observe such occasional notifications, that would be enough). And this would need more testing with native IE. This all means that intention of the patch may be right, but it needs more work. Thanks, Jacek

2 2

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack()
by Bruno Jesus 04 Sep '13

04 Sep '13

On Wed, Sep 4, 2013 at 8:02 AM, Ralf Habacker <ralf.habacker(a)freenet.de> wrote: > > - added test case (update) > > Signed-off-by: Ralf Habacker <ralf.habacker(a)freenet.de> > --- > dlls/iphlpapi/iphlpapi.spec | 1 + > dlls/iphlpapi/ipstats.c | 33 +++++++++++++++++++++++++++++++++ > dlls/iphlpapi/tests/iphlpapi.c | 32 ++++++++++++++++++++++++++++++++ > 3 Dateien geändert, 66 Zeilen hinzugefügt(+) > + // WinXP SP3 crashes on this test > + //ret = pAllocateAndGetTcpExTableFromStack( 0, FALSE, GetProcessHeap(), HEAP_ZERO_MEMORY, AF_INET ); > + //ok( ret == ERROR_INVALID_PARAMETER, "got %u\n", ret ); C++ comments are not allowed. You could use if(0) {} to make sure the code compiles. You are still missing the (try X) at the end of the email subject. Regards, Bruno

1 0

Re: atl90: Add new DLL
by Zhenbo Li 04 Sep '13

04 Sep '13

Sorry, I've made a typo. This patch is for bug 34432 2013/9/4 Zhenbo Li <litimetal(a)gmail.com> > This patch could fix bug 34431, which is caused by missing atl90.dll > > --- > configure | 1 + > configure.ac | 1 + > dlls/atl90/Makefile.in | 7 ++++ > dlls/atl90/atl90.c | 93 ++++++++++++++++++++++++++++++** > ++++++++++++++++++++ > dlls/atl90/atl90.spec | 52 ++++++++++++++++++++++++++++ > include/atlbase.h | 1 + > tools/make_specfiles | 1 + > 7 files changed, 156 insertions(+) > -- Have a nice day! Zhenbo Li

1 0

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack()
by Marvin 04 Sep '13

04 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=1995 Your paranoid android. === wxppro (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 76D6EFE7

1 0

Re: [PATCH 1/3] riched20: Use codepage in ME_ToUnicode.
by Phil Krylov 04 Sep '13

04 Sep '13

Hello, >- ME_EndToUnicode(unicode, wszText); >+ unicode ? ME_EndToUnicode(1200, wszText) : ME_EndToUnicode(CP_ACP, wszText); Personally I dislike this stuff in C code. Especially when you could make it shorter: ME_EndToUnicode(unicode ? 1200 : CP_ACP, wszText) -- Ph.

2 1

Adding an appcompat/appshim bugzilla keyword
by Austin English 04 Sep '13

04 Sep '13

Anastasius mentioned at http://bugs.winehq.org/show_bug.cgi?id=32673#c6 that a keyword for bugs that are caused by applications using broken/deprecated behavior might be useful. I'm in favor of it, but wanted some more opinions (and potentially a better naming scheme). Comments/opinions? -- -Austin

2 1

Re: [PATCH 2/5] d3d9: Check for support before creating textures
by Henri Verbeet 03 Sep '13

03 Sep '13

On 3 September 2013 14:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I'm checking this in d3d9/d3d8/ddraw because we create textures for > everything nowadays, even stand-alone surfaces. For ddraw that's not true yet, but I think my preferred way to handle this would be to introduce a WINED3DUSAGE_TEXTURE usage flag, and then handle the format restrictions in resource_init() in wined3d. Note that I have a couple of patches for enforcing render target and depth stencil format restrictions for bug 34284 that should go in later this week. It may be best to hold this of until after that's in.

2 3

Re: ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 2)
by Alexandre Julliard 03 Sep '13

03 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> writes: > try 2: > Narrow the loop for the specified protocol > Add a new test for invalid sockets Considering what WSAEnumProtocols does, the loop doesn't seem necessary at all. -- Alexandre Julliard julliard(a)winehq.org

3 8

D3D command stream patches for testing
by Stefan Dösinger 03 Sep '13

03 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In the past months I have been working on a command stream / worker thread for wined3d. It moves most OpenGL calls into a separate thread to improve performance (bug 11674) and fix some bugs that are otherwise hard to fix (24684). You can test the attached patches by applying them (git am /path/to/patches/*) and setting HKCU/Software/Wine/Direct3D/CSMT = "enabled". Make sure to disable StrictDrawOrdering. It is no longer required with those patches and will destroy any performance gains. (It might be useful for debugging though). The patches apply on top of Wine 1.7.1. Please test those patches with your games. I'm interested in any successes or failures and performance differences. Performance numbers with plain Wine 1.7.1, this patchset with CSMT off and on, and Wine 1.7.7 + bugzilla attachment 44420 and __GL_THREADED_OPTIMIZATIONS would be greatly appreciated. A notes for non-developers: *) GPU limited games don't see any improvement. If you're GPU limited heavilly depends on your hardware *) So far I have not tested anything but Nvidia hardware. It should work on all GPUs and drivers though. *) Yes, this is essentially the same as Nvidia's __GL_THREADED_OPTIMIZATIONS. Just driver independent, under our control, and thus easier to fix bugs. *) A lot of games see 50%-100% performance improvements and now run as fast as on Windows or even faster. Examples are Source-Engine based games, StarCraft 2, 3DMark 2001. *) Call of Duty Modern Warfare 2 is improved a lot because you no longer need StrictDrawOrdering. It's still not as good as it could be, because it uses dynamic surfaces, which aren't properly implemented in the patchset yet. *) Some games have CPU-side bottlenecks outside d3d. Mass Effect 2 seems to be one of those. *) Some games have CPU-side bottlenecks in the GL driver, and comparably little game logic on their own. I think this applies to Civ V, which doesn't see much improvement with those patches. Some implementation notes: *) One of the big design decisions is to do all OpenGL calls from one thread, including resource creation and buffer maps. This is faster than using glFlush calls to synchronize anything we do from the main thread, and easier than trying to sync everything in a performant fashion with ARB_sync. This means I need the priority command queue. This is not yet fully implemented though, so you see GL calls from the main thread as well. *) There seem to be driver bugs when calling into GL from two threads, even though those are two different contexts. Remember, we don't have the GL lock any longer. *) The other controversial design decision is that the command stream does not hold any references to objects stored in pending commands or its own state structure. This prevents the client libraries and applications from "seeing" the CS via delayed destruction of objects and freeing of application private data. *) Currently resource destruction waits for the CS to execute all pending commands. The goal is to handle private resources and removal from the device's resource list in the main thread and freeing of GL resources, freeing of resource->heap_memory and freeing of the main structure in the worker thread. *) A big issue that needs fixing is that there isn't a clear separation between functions that are called from the main thread and functions that are called from the worker thread. The plan is to introduce comments similar to those that clarify who is responsible for context activation. *) Buffers are double-buffered and use glBufferSubData when the multithreaded CS is in use. This is necessary because we can't draw from a mapped buffer. In the long run GL_ARB_buffer_storage should be able to fix this. *) You can roughly see how surface and volume handling is going to work in the volume code. I am not entirely happy with the code yet, I hacked it together in the past few days... *) The plan behind wined3d_device_get_bo and wined3d_device_release_bo is to cache created GL BOs. Before I do that I have to write a benchmark for dynamic volumes to verify that this is really a performance improvement. *) Before this can be merged, surfaces need a cleanup similar to volumes. It's going to be a lot trickier though. *) The tests should run with the single-threaded and multi-threaded command stream. *) There should not be any temporary regressions with the single-threaded CS. If something's broken, git bisect should work with CSMT off. *) With CSMT on, there are a few known regressions and test failures. The d3d9 and ddraw tests fail between patch 18 and 71. Occlusion queries are broken between 22 and 108. In general nothing's working right between 80 and 99. Some of those problems can be fixed or their impact reduced, but I will not be able to completely avoid them. The ddraw test failure is a driver bug and GL occlusion queries break by design when used from a different thread. So if you try to bisect a regression in this patch series with CSMT on YMMV. *) This work was originally started by Henri. Some patches in the series are from him and either unmodified or with minor adjustments. Some patches are based on his work, but with heavy modifications. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJJjDAAoJEN0/YqbEcdMw1VMP/i4OvTg/HT+jJhZFDzbmtB8o aHIFslhkH9CJDCTGzZExGnPoM+0gLokzzk6ppodQiyC0bJ4jLzeulIhfaUs0sgxy srWpryXYfpeoG/A/MJQlbUQEiMpqdKLvM1j3UupjMY2IsGbECronAYdUi0PTh0Oo RqlWQ64bTARpFXtywO22goNfi57e3UKf2r8Q3Q4f20eH0CwvvVC1YU/sAZ2iyvbR c0fcfergDsPSRQsw+EgEwD4N11/Z+At2XfTeXMC9MyHlZR7bfJfOYMiu6AXfy9gB uFKLgNrXXJho5UsPLjcsCw+UczR98dsyX7B5BZOfG9eyn1Du5YAAVEZ7QCHvUbLj 0WMR86q4GiCZVd5q7GZ7YH3wdNE3R1kEMQA3JRHTP7jLPpSfODUlTxP5NDk220OI +fiPSr5a0BpLqua+dNRjAQvW1Qhrk+7EgLqfwrq8632x/6sInSTnlE84UQ4FJiH6 Wql7PxPPfOJv2qG6l1nqffT7fCbiEHnemoF/4GEvG22MZbMXYTnpkLC6Y1aLUJN5 WXxAICXcy7S2dk5Io/t1IKUm4fwtWnI59MX5rPbfDpY3GGePnlo40pNLlGVv8lc8 ktDS4dvf1Lx/JKrLzu1G/1TYBePFHEVQRvJjzCw0YhNOW7sUOLbf5rgHmAeyOxvD Zdq+l22uJ1Se8m9iAbtF =lm4e -----END PGP SIGNATURE-----

2 3

Re: [PATCH 1/5] d3d8/tests: Add cnd instruction test.
by Henri Verbeet 03 Sep '13

03 Sep '13

On 2 September 2013 23:04, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + float quad1[] = { > + -1.0, -1.0, 0.1, 0.0, 0.0, 1.0, > + 0.0, -1.0, 0.1, 1.0, 0.0, 1.0, > + -1.0, 0.0, 0.1, 0.0, 1.0, 0.0, > + 0.0, 0.0, 0.1, 1.0, 1.0, 0.0 > + }; I think that should be static const, and could do with an 'f' suffix on the literals. > + ok(hr == D3D_OK, "IDirect3DDevice8_BeginScene returned %08x\n", hr); > + if(SUCCEEDED(hr)) > + { I think the if block is pointless. > + /* 1.1 shader. All 3 components get set, based on the .w comparison */ > + color = getPixelColor(device, 158, 358); > + ok(color == 0x00ffffff, "pixel 158, 358 has color %08x, expected 0x00ffffff\n", color); > + color = getPixelColor(device, 162, 358); > + ok( (((color & 0x00ff0000) >> 16) <= 0x01) && (((color & 0x0000ff00) >> 8) <= 0x01) && ((color & 0x000000ff) <= 0x01), > + "pixel 162, 358 has color %08x, expected 0x00000000\n", color); I think that should use color_match(). I realize those are all present in the original test, but that's more of a reason to fix the original instead of copying it.

2 1