Created attachment 21311 [details] xorg.conf System Environment: ---------------------- Host: x-gm45 Arch: i386 OSD: Fedora release 10 (Cambridge) Kernel: 2.6.28-rc8 Libdrm: (master)c86d431fe6174b1c2de531929213ea7dbd92326d Mesa_stable: (intel-2008-q4)0d5b1e591b7fb2cf3109b7e147bb3ea6aa8f8b15 Xserver_stable: (server-1.6-branch)32e81074b967716865aef08b66ec29caf0fec2c5 Xf86_video_intel_stable: (xf86-video-intel-2.6-branch)83f3c376b5942e134047a220e6e5f2432ffc492c GEM Kernel: (for-airlied branch) 88493410cbe68eb267c540fbb0f6809a1a4124d6 Bug Description: --------------------- more than 10 glean cases such as makeCurrent run failed on 945gm and gm45 in UXA mode, and in EXA mode these 10 cases will pass. Reproduce steps: ---------------- 1.enable UXA 2.xinit& 3. run glean cases
Jian, you need list the specific list.
These cases include: basicPerf, makeCurrent, blendFunc, logicOp, readPixSanity, rgbTriStrip, scissor, texCombine, texEnv, texRect. And coloredTexPerf2 and coloredLitPerf2 had the result of warn.
Please retest since commit 9a5082d2920c1a212fe935b5a093013e8035c321 Author: Eric Anholt <eric@anholt.net> Date: Mon Jan 5 23:28:50 2009 -0800 Disable DRI2 buffer tiling on non-965, as those need fence regs for 2D blits This fixes glReadPixels failure on single-channel 915GM, as the software cod for readpixels was actually the only code in the driver doing tiling against these buffers (everything else says "rely on fence registers", since the 2D blits don't have a "don't rely on fence registers" option).
Jian, any update?
I tested with the RC4's code, and it still failed. The log is in attachment. With the following configuration: Mesa: (intel-2008-q4)200fa9165d7078a6f36c5c9d3e0c997c2438bde3 Xorg: 7.2 Xserver: (server-1.6-branch)251d0d8090322b2c9dc0c8b7bef001f338d19433 Xf86_video_intel: (xf86-video-intel-2.6-branch)5cd65d965c8ed388275fe2084553302aad601d4a
Created attachment 22091 [details] glean tests results on gm45 with the 4th quarter release
*** Bug 20291 has been marked as a duplicate of this bug. ***
The glean/makeCurrent test case not only fails but it causes a SEGV in the xserver (at least on my G45, 29-rc6 + ubuntu user land machine).
with the latest driver,these cases as below have got pass now: basicPerf,logicOp,readPixSanity,rgbTriStrip,texEnv,texRect we test them agaist below commit: Libdrm: (master)a1e3ab9e55047c08a4006ec389c1a99b72bc672c Mesa: (mesa_7_4_branch)e8807a14a61a0b9389aa2f2a113da24ab22a364d Xserver: (server-1.6-branch)11db545a86c8933c638a0bc1fcd4f2c65279f617 Xf86_video_intel: (2.7)296a986e5258e2fd13ec494071b7063bd639cd68 Kernel: (qa-branch)ba1d2a9be507cda299c15740ff7e2bb3705a4792
Jian, could you give an updated list for those passed with EXA and now still fail with UXA?
(In reply to comment #10) > Jian, could you give an updated list for those passed with EXA and now still > fail with UXA? UXA nearly has a same performance compared with EXA now. Only coloredTexPerf2, coloredLitPerf2 are passed with EXA and failed with UXA. And texCombine is timeout with both UXA and EXA.
This is half-fixed now, and the tests don't crash but they do read wrong results and complain: commit df70d3049a396af3601d2a1747770635a74120bb Author: Eric Anholt <eric@anholt.net> Date: Fri Jun 19 22:12:52 2009 -0700 intel: Also get the DRI2 front buffer when doing front buffer reading. idr, there's a piglit test called read-front now that catches the glean regression without having to suffer through running the interminable glean test sequence to do so. Any chance you could take a look at it? (be sure to log read-front.c)
commit 5ca800e1006555ea1c5dcbbc56c35838c9f04994 Author: Eric Anholt <eric@anholt.net> Date: Mon Jun 22 16:33:29 2009 -0700 dri2: Refresh the fake front contents after glXSwapBuffers(). Bug #19177. Reviewed by: Ian Romanick <ian.d.romanick@intel.com>
Verified with the following commits: Libdrm: (master)790097c51330090b2b7b90429b9ab8ddf259fd8e Mesa: (mesa_7_5_branch)bb8f3090ba37aa3f24943fdb43c4120776289658 Xserver: (server-1.6-branch)dbac41b624e4aa86a6a184b7ebb52bfdd367bbf0 Xf86_video_intel: (master)f53b3239dbc0ed723774e386e07ac9d8ce96bb89
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.