[Mesa-dev] Project ideas [was Re: Gallium3D and Glide]

[Keith Whitwell]

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