Wine has a great test suit to prevent regressions during it's development. Currently all the visual test are failing under Intel drivers. They are working excelent Nvidia drivers. So I think there is a lot of room to improvement here. The source is available at: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/d3d9/tests/visual.c I will love to see this test passing as this will bring a lot of games to the Linux world.
Created attachment 31726 [details] Output of the tests
There's pretty much zero chance of us debugging random errors in a 10,000+ line test program that uses D3D. Given the oceans of GL_INVALID_FRAMEBUFFER_OPERATION and GL_FRAMEBUFFER_UNSUPPORTED in the output, it seems likely that Wine is doing something wrong in its framebuffer object use. Seriously... check the frickin' error returns guys!
Created attachment 31759 [details] Failing tests The real issue is that the visual tests are failing and making the whole test suite to exit. I'm attaching the tests and lines that are failing to be more clear. Sorry for the misunderstood.
Adjusting the summary.
So a subset of the 10000 lines of D3D code fails on our OpenGL driver. There are probably some actual bugs in our OpenGL, and there may also be bugs in the testcase. What it'll take to fix it is somebody (probably Wine developers/fans) isolating some OpenGL testcases for inclusion in piglit that will catch the bugs that this D3D test is hitting in OpenGL.
Ok, after asking some help to the Wine devs they point me to the opengl test that the wine test suite has. http://source.winehq.org/source/dlls/opengl32/tests/opengl.c After try this test under current intel drivers there are some failures and some interesting outputs: err:wgl:X11DRV_wglCreateContext Cannot get FB Config for iPixelFormat 0, expect problems! opengl.c:714: OpenGL renderer: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20090712 2009Q2 RC3 x86/MMX/SSE2 opengl.c:715: OpenGL driver version: 2.1 Mesa 7.7-rc2 opengl.c:716: OpenGL vendor: Tungsten Graphics, Inc opengl.c:84: wglGetProcAddress(wglCreateContextAttribsARB) failed opengl.c:90: wglGetProcAddress(wglMakeContextCurrentARB) failed opengl.c:91: wglGetProcAddress(wglGetCurrentReadDCARB) failed opengl.c:98: wglGetProcAddress(wglCreatePbufferARB) failed opengl.c:99: wglGetProcAddress(wglGetPbufferDCARB) failed opengl.c:100: wglGetProcAddress(wglReleasePbufferDCARB) failed do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try adjusting the vblank_mode configuration parameter. err:wgl:internal_SetPixelFormat Invalid operation on root_window opengl.c:242: SetPixelFormat on main device context failed err:wgl:X11DRV_wglShareLists Could not share display lists, one of the contexts has been current already ! opengl.c:317: Test failed: Sharing display lists with a destination context which has been made current failed err:wgl:X11DRV_wglShareLists Could not share display lists because hglrc2 has already shared lists before opengl.c:751: Tests skipped: WGL_ARB_make_current_read not supported, skipping test opengl.c:756: Tests skipped: WGL_ARB_pbuffer not supported, skipping pbuffer test I hope this helps a little bit more. If you need any other info I will be more that glad to provide any log.
> fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED (0x8cdd) > fixme:d3d:context_check_fbo_status Color attachment 0: (0x180f88) WINED3DFMT_B8G8R8X8_UNORM 128x128 > fixme:d3d:context_check_fbo_status Depth attachment: (0x169f58) WINED3DFMT_D24_UNORM_S8_UINT 640x480 I'd say the driver claims to support GL_ARB_framebuffer_object(not the EXT extension), but fails to accept color and depth attachments of different size. I suspect many other failures are follow-up issues of this problem.
(In reply to comment #2) > There's pretty much zero chance of us debugging random errors in a 10,000+ line > test program that uses D3D. Given the oceans of > GL_INVALID_FRAMEBUFFER_OPERATION and GL_FRAMEBUFFER_UNSUPPORTED in the output, > it seems likely that Wine is doing something wrong in its framebuffer object > use. Seriously... check the frickin' error returns guys! > Well, we are checking them, that's why you see them in the log. At the point the application is using a specific framebuffer configuration it's usually too late for us to do something about it though. We check individual formats during wined3d startup, but not combinations of color and depth/stencil attachments. As a general FBO rant, a GLSL-style info log would be a lot more useful than the "This configuration is unsupported, you figure out why." style error reporting that FBOs currently have. That would be useful for stuff like hitting software fallbacks as well, actually. (In reply to comment #5) > So a subset of the 10000 lines of D3D code fails on our OpenGL driver. There > are probably some actual bugs in our OpenGL, and there may also be bugs in the > testcase. What it'll take to fix it is somebody (probably Wine > developers/fans) isolating some OpenGL testcases for inclusion in piglit that > will catch the bugs that this D3D test is hitting in OpenGL. > Pretty much. I did something like that about a year ago for i915, and fixed a couple of bugs in both the tests and Mesa, but I don't currently have the time. (Just for the record, the individual D3D tests aren't more than a few hundred lines each at most, it's the underlying 65000 lines of wined3d code you should be worried about.)
(In reply to comment #7) > > fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED (0x8cdd) > > fixme:d3d:context_check_fbo_status Color attachment 0: (0x180f88) WINED3DFMT_B8G8R8X8_UNORM 128x128 > > fixme:d3d:context_check_fbo_status Depth attachment: (0x169f58) WINED3DFMT_D24_UNORM_S8_UINT 640x480 > > I'd say the driver claims to support GL_ARB_framebuffer_object(not the EXT > extension), but fails to accept color and depth attachments of different size. > It's allowed to do that.
OK, I've brought the failures in visual.c down significantly, by fixing a couple of bugs/implementation deficiencies in FBO handling. Binding a stencil but no depth was failing (though it seems wine doesn't really care whether it works, even though it does it). Also, by binding a packed depth/stencil texture to both depth and stencil separately, the detection of packed depth/stencil failed. There was nothing to do with FBO size mismatch here. And yes, we do really need an infolog for FBOs, since once you enabled the printfs in src/mesa/main/fbobject.c ( s/_mesa_debug(NULL,/_mesa_printf(/ ) and INTEL_DEBUG=fbo it was relatively obvious what was failing. Any remaining issues wine has in this testcase (looks like it's just point sprite junk?) should go into a new bug report.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.