Bug 25432 - Wine test suite is failing with Intel drivers
Summary: Wine test suite is failing with Intel drivers
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: lowest normal
Assignee: Eric Anholt
QA Contact:
URL: http://source.winehq.org/git/wine.git...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-03 18:15 UTC by Jaime Rave
Modified: 2009-12-28 19:28 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Output of the tests (16.57 KB, text/plain)
2009-12-03 19:22 UTC, Jaime Rave
Details
Failing tests (2.89 KB, text/plain)
2009-12-04 18:06 UTC, Jaime Rave
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaime Rave 2009-12-03 18:15:02 UTC
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.
Comment 1 Jaime Rave 2009-12-03 19:22:48 UTC
Created attachment 31726 [details]
Output of the tests
Comment 2 Ian Romanick 2009-12-04 16:19:38 UTC
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!
Comment 3 Jaime Rave 2009-12-04 18:06:10 UTC
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.
Comment 4 Jaime Rave 2009-12-04 18:07:23 UTC
Adjusting the summary.
Comment 5 Eric Anholt 2009-12-09 16:14:51 UTC
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.
Comment 6 Jaime Rave 2009-12-09 21:09:57 UTC
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.
Comment 7 Stefan Dösinger 2009-12-10 01:56:03 UTC
> 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.
Comment 8 Henri Verbeet 2009-12-10 02:08:12 UTC
(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.)
Comment 9 Henri Verbeet 2009-12-10 02:10:07 UTC
(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.
Comment 10 Eric Anholt 2009-12-28 19:28:21 UTC
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.