System Environment: -------------------------- Arch: i386 Platform: Sugarbay Libdrm: (master)2.4.30-1-g66518ab5653cfdc840cd69e7b653ec05df060584 Mesa: (8.0)c85402aba91755808729fadf57a9f92285f4e61a Xserver: (server-1.11-branch)xorg-server-1.11.3 Xf86_video_intel:(master)2.17.0-478-g35f81005f91d294e61bb4ced7cbddd1a76ccb324 Kernel: (drm-intel-fixes) 8109021313c7a3d8947677391ce6ab9cd0bb1d28 Bug detailed description: ------------------------- It failed on SugarBay(GT2) and MahoBay. It passed on huronriver and sugarbay(GT1). Bisect shows c60ac7b17993d28af65b04f9bbbf3ee74c35358c is the first bad commit. commit c60ac7b17993d28af65b04f9bbbf3ee74c35358c Author: Brian Paul <brianp@vmware.com> AuthorDate: Sat Dec 24 08:54:27 2011 -0700 Commit: Brian Paul <brianp@vmware.com> CommitDate: Sat Dec 24 09:25:41 2011 -0700 swrast: rewrite glDrawPixels(GL_DEPTH) with zoom This gets rid of another renderbuffer->PutRow() call and _DepthBuffer usage. We always work with 32-bit uint Z values now. Reviewed-by: Eric Anholt <eric@anholt.net> Reproduce steps: ---------------- 1. start X 2. ./oglconform -z -s -suite all -v 2 -test depth-stencil basic.read.ds
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.