| Summary: | [bisected ] oglc depth-stencil(basic.read.ds) regressed on SNB DT GT2 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | fangxun <xunx.fang> |
| Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | major | ||
| Priority: | high | CC: | brianp, chadversary |
| Version: | git | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 42993 | ||
|
Description
fangxun
2012-01-19 20:37:55 UTC
With Brian's renderbuffer-cleanups-v2 branch merged, this test passes on master and 8.0-rc2 on my SNB GT2 mobile (8086:0126 (rev 09)). System Environment: -------------------------- Libdrm: (master)2.4.30-18-gb643b0713aefdc0611e47654e88263b53b0de6f5 Mesa: (8.0)caebd7929dca802ece8ef36b0f85094d66133b57 Xserver: (server-1.11-branch)xorg-server-1.11.3 Xf86_video_intel: (master)2.17.0-599-gca252e5b51d7b2f5a7b2c2e0d8fdb024b08096db verify with mesa 8.0 branch, this case passed on huronriver(GT2, mobile), but still failed on Sugarbay(GT2, desktop) (In reply to comment #1) > With Brian's renderbuffer-cleanups-v2 branch merged, this test passes on master > and 8.0-rc2 on my SNB GT2 mobile (8086:0126 (rev 09)). reopening (In reply to comment #2) > System Environment: > -------------------------- > Libdrm: (master)2.4.30-18-gb643b0713aefdc0611e47654e88263b53b0de6f5 > Mesa: (8.0)caebd7929dca802ece8ef36b0f85094d66133b57 > Xserver: (server-1.11-branch)xorg-server-1.11.3 > Xf86_video_intel: > (master)2.17.0-599-gca252e5b51d7b2f5a7b2c2e0d8fdb024b08096db > verify with mesa 8.0 branch, this case passed on huronriver(GT2, mobile), but > still failed on Sugarbay(GT2, desktop) Xun, can you confirm this is pure hw difference, with the same disk? This issue happens on Sugarbay GT2, it doesn't happen on huronriver GT2. This case has Bug 49772 on huronriver. I can't make any sense of this bug report. Comment 5 says "This issue happens on Sugarbay GT2, it doesn't happen on huronriver GT2.", but also links to a bug report saying that it *does* happen on huronriver. Of course, there is no excerpt of the testcase's failure report, which might be a way that comment 5 could make sense -- if there is a difference in the failure mode between the two. But a developer has no way to tell from the bug report given. (In reply to comment #6) > I can't make any sense of this bug report. Comment 5 says "This issue happens > on Sugarbay GT2, it doesn't happen on huronriver GT2.", but also links to a bug > report saying that it *does* happen on huronriver. They are two issues, at least from the happening time. - when this bug (#44963) filed, huronriver got pass. - later huronriver regressed, so we tracked that at bug#49772. > Of course, there is no excerpt of the testcase's failure report, which might be > a way that comment 5 could make sense -- if there is a difference in the > failure mode between the two. But a developer has no way to tell from the bug > report given. It's a gray area if we are allowed to publish oglconform output. I hope developers could also try reproducing. If you can't reproduce, we may communicate the output in another way. I don't believe in a distinction between Huron River or Sugar Bay. I've never seen a real bug that occurred on one but not the other. In my experience, they behave identically: the only distinction that matters is GT1/GT2. Regardless, the test is broken on master on Sandybridge GT2. Bug #49772 tracks the failing test case, and is much less confusing---and therefore more useful. Marking this as a duplicate. We don't need two parallel bugs for the same test case failing on Sandybridge platforms. *** This bug has been marked as a duplicate of bug 49772 *** |
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.