[Patch for piglit/tests/glean/tpbo.cpp attached]
On 03/08/2010 12:12 AM, Ian Romanick wrote:
> Török Edwin wrote:
>
>> I've run the piglit tests using tests/r500.tests, with glean in quick mode.
>
>> With patch: 620/686 pass
>> Without patch: 614/679 pass (I opened a bugreport about these failures
>> here: https://bugs.freedesktop.org/show_bug.cgi?id=26933)
>
>> The pbo tests results are:
>> glean/pbo: fail
>> general/pbo-teximage-tiling: pass
>> general/pbo-read-argb8888: pass
>> general/pbo-teximage-tiling-2: pass
>> general/pbo-drawpixels: pass
>> general/pbo-readpixels-small: pass
>> general/object_purgeable-api-pbo: skip
>> general/pbo-teximage: pass
>> fbo/fbo-pbo-readpixels-small: pass
>
> Okay. I'm convinced. I'll leave it up to the r600 maintainers to make
> the final call. However, they really need to do it before RC1 (March 12th).
Thanks!
>
>> The glean/fbo fail looks like some FP tolerance being too strict (1.0 vs
>> 1.00000). Is there a way to accept 1.00000 for 1.0 in the piglit tests?
>
>> pbo test: Test OpenGL Extension GL_ARB_pixel_buffer_object
>
>> FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028)
>> (1, 0) = [1.000000, 1.000000, 1.000000], should be [1.0, 1.0, 1.0]
>> pbo: NOTE perf[0] = 372.891 MB/s, which is in normal mode
>> pbo: NOTE perf[1] = 261.088 MB/s, which is using PBO
>> pbo: FAIL rgba8, db, z24, s8, win+pmap, id 33
>> 9 tests passed, 1 tests failed.
>
> That's pretty weird. I was pretty sure that glean checked for equality
> by making sure the difference was below some threshold. As far as I can
> tell, fabs(1.000000 - 1.0) should be below any reasonable threshold.
> There's clearly something else going wrong.
Yeah, I looked at the code: it is checking one thing and reporting
another :)
exp is black/white alternatively for every 2nd iteration:
if (i & 1)
exp = black;
else
exp = white;
if (i < 10 && j < 10) {
if (!equalColors(&buf[(j * windowSize + i) * 3], exp)) {
REPORT_FAILURE("glGetPolygonStipple failed");
printf("(%d, %d) = [%f, %f, %f], ", i, j,
buf[(j * windowSize + i) * 3],
buf[(j * windowSize + i) * 3 + 1],
buf[(j * windowSize + i) * 3 + 2]);
printf("should be [1.0, 1.0, 1.0]\n");
^However the message reports 1.0 always.
Attached patch fixes error reporting in piglit, and then I get this message:
FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028)
(1, 0) = [1.000000, 1.000000, 1.000000], should be [0.000000, 0.000000,
0.000000]
pbo: NOTE perf[0] = 372.431 MB/s, which is in normal mode
pbo: NOTE perf[1] = 262.693 MB/s, which is using PBO
pbo: FAIL rgba8, db, z24, s8, win+pmap, id 33
9 tests passed, 1 tests failed.
Best regards,
--Edwin
>From fa7b3da2f3b43486bd42a6c67b2bc1163e4c0358 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?T=C3=B6r=C3=B6k=20Edvin?= <edwinto...@gmail.com>
Date: Mon, 8 Mar 2010 11:01:22 +0200
Subject: [PATCH] Fix error reporting in glean/tpbo to report what it checks.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Previously it was always reporting that it expects 1.0 or 0.0,
instead of what it actually checked for.
Signed-off-by: Török Edvin <edwinto...@gmail.com>
---
tests/glean/tpbo.cpp | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/glean/tpbo.cpp b/tests/glean/tpbo.cpp
index 7d86279..5f7d587 100644
--- a/tests/glean/tpbo.cpp
+++ b/tests/glean/tpbo.cpp
@@ -1030,7 +1030,7 @@ bool PBOTest::testPolygonStip(void)
buf[(j * windowSize + i) * 3],
buf[(j * windowSize + i) * 3 + 1],
buf[(j * windowSize + i) * 3 + 2]);
- printf("should be [1.0, 1.0, 1.0]\n");
+ printf("should be [%f, %f, %f]\n", exp[0],exp[1],exp[2]);
return false;
}
}
@@ -1041,7 +1041,7 @@ bool PBOTest::testPolygonStip(void)
buf[(j * windowSize + i) * 3],
buf[(j * windowSize + i) * 3 + 1],
buf[(j * windowSize + i) * 3 + 2]);
- printf("should be [0.0, 0.0, 0.0]\n");
+ printf("should be [%f, %f, %f]\n", exp[0],exp[1],exp[2]);
return false;
}
--
1.7.0
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
