On Tue, 2011-03-01 at 12:32 -0800, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/01/2011 05:36 AM, Keith Whitwell wrote: > > > Create an automated bug-finder for gallium drivers. > > > > Step one: create a "split and compare" gallium driver (perhaps based on > > failover) which runs the same set of commands on two different gallium > > drivers (eg softpipe and r600g). At each frame, compare the two images > > and see if there are differences. > > For non-trivial rendering, that had better be an awful fuzzy "compare."
The compare would have to have some fuzziness built into it, agreed. There's probably a little research right there in finding a good measure, but at worst you downsample and compute PSNR or SSIM of the two images and find a threshold by trial and error. Note that you're only going to bother doing this when you know there's a bug, or for regression testing. In both cases it should be trivial to find an appropriate threshold, and this can be done case-by-case. The motivation is to isolate bugs which result in gross misrenderings, like incorrect texturing, malformed objects, black bars across the screen, and so forth - in other words the threshold can be quite low. > All of the 3D rendering specs allow a large amount of variation in > rasterization rules and precision rules. > Have you ever looked at OpenGL's line drawing rules? Line locations can vary > by +/- a pixel in > any direction. Yes, in great detail. Hui & I took a close look at it while implementing llvmpipe's half-plane based line rasterization. The +/- 1 pixel business is there, agreed, but the preferred implementation (bresenham/diamond exit rule) is clear. The diamond-exit rule is fairly well specified and modern hardware will likely follow it exactly as it's the requirement for DX10 line rasterization as well. Hardware isn't quite as diverse as it might have been historically thanks to DX10 which specifies rasterization precisely and tests it by image comparison against the reference rasterizer in exhaustive (or at least exhausting) detail. Llvmpipe is pixel-exact against nVidia's hardware for triangle, quad and point rasterization. In OpenGL line rasterization I believe nVidia have a bug where they forget that GL's idea of "top" is different to DX's and hence get the diamond logic slightly wrong. I suspect if GL tightened up its spec & had a proper test suite for rasterization they'd notice that & fix it quickly. Keith _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
