Miklós Máté mtmkls@gmail.com writes:
Fixes https://bugs.winehq.org/show_bug.cgi?id=40767
Signed-off-by: Miklós Máté mtmkls@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
On 06/20/2016 04:42 PM, Alexandre Julliard wrote:
Miklós Máté mtmkls@gmail.com writes:
Fixes https://bugs.winehq.org/show_bug.cgi?id=40767
Signed-off-by: Miklós Máté mtmkls@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@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.
On 22 June 2016 at 12:31, Miklós Máté mtmkls@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@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@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@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.
-
Alexandre Julliard -
Henri Verbeet -
Miklós Máté -
Stefan Dösinger