Re: [PATCH] winex11: fix destroying of top-level windows
Miklós Máté <mtmkls(a)gmail.com> writes:
Fixes https://bugs.winehq.org/show_bug.cgi?id=40767
Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> --- dlls/winex11.drv/opengl.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c index d89a193..27ddd79 100644 --- a/dlls/winex11.drv/opengl.c +++ b/dlls/winex11.drv/opengl.c @@ -1314,6 +1314,9 @@ static void free_gl_drawable( struct gl_drawable *gl ) { switch (gl->type) { + case DC_GL_WINDOW: + pglXDestroyWindow( gdi_display, gl->drawable ); + break;
Actually this one has some issues too: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok device.c:2250: Tests skipped: could not create device, IDirect3D9_CreateDevice returned 0x8876086c device.c:6312: Tests skipped: This GPU supports SM3, skipping unsupported shader test. device.c:6724: Tests skipped: D3DFMT_A32B32G32R32F supports filtering, skipping tests. device.c:7747: Tests skipped: Failed to create cube texture for format R8G8B8 (hr 0x8876086c), skipping tests. device.c:8450: Tests skipped: Dynamic D3DFMT_YUY2 textures not supported, skipping mipmap test. device.c:8450: Tests skipped: Dynamic D3DFMT_UYVY textures not supported, skipping mipmap test. X Error of failed request: GLXBadWindow Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 32 (X_GLXDestroyWindow) Serial number of failed request: 8900 Current serial number in output stream: 8901 Makefile:208: recipe for target 'device.ok' failed -- Alexandre Julliard julliard(a)winehq.org
On 06/20/2016 04:42 PM, Alexandre Julliard wrote:
Miklós Máté <mtmkls(a)gmail.com> writes:
Fixes https://bugs.winehq.org/show_bug.cgi?id=40767
Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> --- dlls/winex11.drv/opengl.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c index d89a193..27ddd79 100644 --- a/dlls/winex11.drv/opengl.c +++ b/dlls/winex11.drv/opengl.c @@ -1314,6 +1314,9 @@ static void free_gl_drawable( struct gl_drawable *gl ) { switch (gl->type) { + case DC_GL_WINDOW: + pglXDestroyWindow( gdi_display, gl->drawable ); + break; Actually this one has some issues too:
../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok device.c:2250: Tests skipped: could not create device, IDirect3D9_CreateDevice returned 0x8876086c device.c:6312: Tests skipped: This GPU supports SM3, skipping unsupported shader test. device.c:6724: Tests skipped: D3DFMT_A32B32G32R32F supports filtering, skipping tests. device.c:7747: Tests skipped: Failed to create cube texture for format R8G8B8 (hr 0x8876086c), skipping tests. device.c:8450: Tests skipped: Dynamic D3DFMT_YUY2 textures not supported, skipping mipmap test. device.c:8450: Tests skipped: Dynamic D3DFMT_UYVY textures not supported, skipping mipmap test. X Error of failed request: GLXBadWindow Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 32 (X_GLXDestroyWindow) Serial number of failed request: 8900 Current serial number in output stream: 8901 Makefile:208: recipe for target 'device.ok' failed
The v2 I sent to the list fixes the test, but I'm fairly sure that the critical section is wrong. I tried to run the d3d11 test to see if it better exercises multithreading, but it skipped all tests ("None of the requested D3D feature levels is supported on this GPU with the current shader backend." even though Mesa 11.2 supports GL 4.1 core profile on my hw). Is it an acceptable solution to not leave the critical section until the XSaveContext line? MM
Miklós Máté <mtmkls(a)gmail.com> writes:
The v2 I sent to the list fixes the test, but I'm fairly sure that the critical section is wrong. I tried to run the d3d11 test to see if it better exercises multithreading, but it skipped all tests ("None of the requested D3D feature levels is supported on this GPU with the current shader backend." even though Mesa 11.2 supports GL 4.1 core profile on my hw).
Is it an acceptable solution to not leave the critical section until the XSaveContext line?
That should be OK. -- Alexandre Julliard julliard(a)winehq.org
On 22 June 2016 at 12:31, Miklós Máté <mtmkls(a)gmail.com> wrote:
The v2 I sent to the list fixes the test, but I'm fairly sure that the critical section is wrong. I tried to run the d3d11 test to see if it better exercises multithreading, but it skipped all tests ("None of the requested D3D feature levels is supported on this GPU with the current shader backend." even though Mesa 11.2 supports GL 4.1 core profile on my hw).
You'll need to set "MaxVersionGL" to 0x00030002 to enable wined3d core profile support. The d3d11 tests mostly pass with core profiles, but test_draw_depth_only() for example fails. Alternatively, you can hack the "shader_model" value in shader_glsl_get_caps(). The d3d11 tests don't do much for multithreading however. The "CSMT" patch set (https://github.com/stefand/wine/tree/master) is much better for that, and unfortunately still fails with the latest version of the patch. That patch set is not currently part of proper Wine, but I can send you a version rebased onto either 1.9.12 or current git if you're interested.
On 06/23/2016 09:00 AM, Henri Verbeet wrote:
On 22 June 2016 at 12:31, Miklós Máté <mtmkls(a)gmail.com> wrote:
The v2 I sent to the list fixes the test, but I'm fairly sure that the critical section is wrong. I tried to run the d3d11 test to see if it better exercises multithreading, but it skipped all tests ("None of the requested D3D feature levels is supported on this GPU with the current shader backend." even though Mesa 11.2 supports GL 4.1 core profile on my hw).
You'll need to set "MaxVersionGL" to 0x00030002 to enable wined3d core profile support. The d3d11 tests mostly pass with core profiles, but test_draw_depth_only() for example fails. Alternatively, you can hack the "shader_model" value in shader_glsl_get_caps(). The d3d11 tests don't do much for multithreading however. The "CSMT" patch set (https://github.com/stefand/wine/tree/master) is much better for that, and unfortunately still fails with the latest version of the patch. That patch set is not currently part of proper Wine, but I can send you a version rebased onto either 1.9.12 or current git if you're interested.
Hi, I couldn't reproduce that test failure. I cloned Stefan's repository (master branch), applied my glx 1.3 patches that are in 1.9.12, and v2 of this patch, and I set the registry keys for CSMT (csmt=enabled, strictdrawordering=disabled). The d3d9 tests all pass. Did I miss something? Is there a way to tell if CSMT is in use? MM
On 25 June 2016 at 01:26, Miklós Máté <mtmkls(a)gmail.com> wrote:
I couldn't reproduce that test failure. I cloned Stefan's repository (master branch), applied my glx 1.3 patches that are in 1.9.12, and v2 of this patch, and I set the registry keys for CSMT (csmt=enabled, strictdrawordering=disabled). The d3d9 tests all pass. Did I miss something? Is there a way to tell if CSMT is in use?
Mostly by messages like "fixme:d3d:context_acquire Acquiring a GL context from outside the CS thread." The d3d9 tests do pass here, but e.g. ddraw7 from the ddraw tests fails with a GLXBadWindow from X_GLXDestroyWindow. WINEDEBUG=+synchronous makes it work. There's also a "failed to create drawable" message that I didn't investigate.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-28 um 11:43 schrieb Henri Verbeet:
On 25 June 2016 at 01:26, Miklós Máté <mtmkls(a)gmail.com> wrote:
I couldn't reproduce that test failure. I cloned Stefan's repository (master branch), applied my glx 1.3 patches that are in 1.9.12, and v2 of this patch, and I set the registry keys for CSMT (csmt=enabled, strictdrawordering=disabled). The d3d9 tests all pass. Did I miss something? Is there a way to tell if CSMT is in use?
Mostly by messages like "fixme:d3d:context_acquire Acquiring a GL context from outside the CS thread."
The d3d9 tests do pass here, but e.g. ddraw7 from the ddraw tests fails with a GLXBadWindow from X_GLXDestroyWindow. WINEDEBUG=+synchronous makes it work. There's also a "failed to create drawable" message that I didn't investigate. FYI, the CSMT patches currently have a race condition when setting up / tearing down devices. I had a hacky workaround for that previously that fixed the random GLXBadWindow failures. I haven't included this patch yet in my "new" rebase because it was somewhat convoluted.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXcrNhAAoJEN0/YqbEcdMwsXEQAIZ8+4dahYho6RxBa5DsQiMj sqTTXZdEK9strUkVcFjqi0ercm8yU6ubhLMHFgumh+caAGGLiC8TaYQNVQvN6s40 KN9qJ1Vi7Ae11GqWwFVV/MIL6YwYmXnWsgaFlBB8itn50Cv6CT9VyYsJRmw97b7Y 0TRpOhTsaYqsGGWNK1dbfI5LWPKY4cAUCPOMcDY8xpEJUZhcNzg0kHilJn1gQQfh E5klKtq9HQ3qd/xljHvTxdwtTqh/i2QmrDdxONg9546er4QoHHZK4hJ+xu/VOjv0 PVvegnRu8eZKU3V1N/JxN9t3cxL6XXtNmhCik8tfExZGPb6PZCHETqx2xQO9y+hA qV50C6EuQN89AqNwITKaE4NydQ/sDBGg96ld2VKmPsSemvWYgIzswwWeFRVu8zXy HYMMsxNDKjC4nwvLwYuWVuzXQ3vTuYgBk2DxT78huWljDCnuxPf4KpzcQjMNUr4c 3UoO3gZsVH2uGFElD8PTSjzUUR9C4HN94MiwNZ63pqCUSqt2PN68hjZesfdh3bTD 2ljznN/P51PimHKUsaCFdEUdGQnk2vpVovTGt1OQGzIKn51FP9mr4Sf5ltoOPmY0 IkAFE45pcxlZccKjN/Mi7tmSZsizCJ0lUX+vYLm4eC3J7PoRAD6b7+eyDQQr2yG8 AIUTCs57/kr5fbM28x9A =9yQa -----END PGP SIGNATURE-----
participants (4)
-
Alexandre Julliard -
Henri Verbeet -
Miklós Máté -
Stefan Dösinger