Suppose a ray just barely hits/misses a sphere. Depending on the GPU arithmetic and whether the outcome is a hit or miss, the resulting pixel color could be completely different.
A per-pixel error margin won't account for this. But as you suggested, if you allow a certain number or percent of pixel comparisons to fail, that might do the job here. How about implementing that? I'd also suggest putting the comparison code into a new piglit utility function (or at least put the code in a separate function that could be promoted to piglit-util.c someday). BTW, the piglit_probe_pixel_rgb() function should really take a tolerance parameter, rather than it being hard-coded inside the function. Another piglit utility function to compute tolerances from various parameters would be good... but that's another project. -Brian RALOVICH, Kristóf wrote: > Brian, > > you are right, maybe more freedom should be allowed, but > piglit_probe_pixel_rgb() already uses 0.01 as threshold which should > be enough if the ray directions do not have large FP differences. > > As a short term goal with the test vsraytrace was, that it should not > take my GM4500 down. > > As a longer term solution we can allow e.g. 15% of pixels to even fail > piglit_probe_pixel_rgb() too. I can extend the patch with this if > you'd like it. > > Kristof > > On Wed, Apr 14, 2010 at 16:49, Brian Paul <bri...@vmware.com> wrote: >> It looks like the piglit tests use an image comparison to determine >> pass/fail, right? >> >> That may not be too reliable since different drivers will produce slightly >> different results. >> >> Is there any way that the rendering can be checked for correctness without >> relying on an exact image comparison? >> >> -Brian >> >> >> RALOVICH, Kristóf wrote: >>> Would someone please have a look at this piglit tests? >>> >>> Thanks, >>> Kristof >>> >>> On Sun, Mar 28, 2010 at 17:52, RALOVICH, Kristóf >>> <kristof.ralov...@gmail.com> wrote: >>>> Eric, >>>> >>>> please see the attached patch for piglit. The patch includes 2 new >>>> tests based on the demos I provided for mesa. >>>> >>>> Let me know if I can further help! >>>> >>>> Thanks, >>>> Kristof >>>> >>>> On Wed, Mar 24, 2010 at 16:33, Eric Anholt <e...@anholt.net> wrote: >>>>> On Wed, 24 Mar 2010 11:10:47 -0400, RALOVICH, Kristóf >>>>> <kristof.ralov...@gmail.com> wrote: >>>>>> Brian, >>>>>> >>>>>> that was fast! Who do you think I should bug, to get these working on >>>>>> i965? >>>>>> >>>>>> Also as my time allows, I am planning to extend them with mouse input >>>>>> for orientation and arrow keys for moving to camera to become more >>>>>> interactive. >>>>> Make a testcase for piglit, and I'd love to fix your bug. >>>>> >> ------------------------------------------------------------------------------ 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
