automatic way to verify rasterization results

[nirradi]

anyone know of an automatic way to verify rasterization results, or at least suggest a good test case trace with "hard triangles". i'd like to verify numeric stability as well as precision
10x

 

[Nick]

For Direct3D there's the WHQL tests, and for OpenGL (ES) there's the conformance tests.

 

[nirradi]

Nick, thanks for the reply – really appreciate it.
Let me get this straight though - a scan conversion algorithm like centerline, not to mention a recursive tiled walk, is implemented in full single precision float and fully pipelined? With all ~24 (4-float) attributes interpolated perspective-correctly it sounds unfeasible in HW.
Moreover, analyzing precision of a floating point implementation (at least one based on IEEE 754) of an iterative walking algorithm over a large triangle is, to say the least, very difficult. And experiments suggest single precision doesn’t seem to cut it for the more demanding resolutions. Using more than 32bit floats sounds insane. How do people in mobile or lower end PC get this done? I don’t see even high end PC/console affording such logic.

 

[nirradi]

OooOps. please forgive my sloppy foruming...please disregard that previuos post which was meant for a different thread...

what I meant to ask was:

just out of curiosity, as i can't seem to find information on this: so these tests actually look at an implementation output and compare it with a referece? what's compared? color buffer pixel colors? does it realy try to cover the "hard" special cases and scenarios?

 

[MDolenc]

This will probably be a good place to start: http://msdn.microsoft.com/en-us/library/cc627092(VS.85).aspx

 

[nirradi]

Thanks for the link. I can certainly use it.
I'm primarily interested in the OpenGL variant of things though. How are the conformance tests done for OpenGL rasterization - are the very similar to the D3D conformance?

 

[Toasty]

Thanks for the link. I can certainly use it.
I'm primarily interested in the OpenGL variant of things though. How are the conformance tests done for OpenGL rasterization - are the very similar to the D3D conformance?

The OpenGL ES conformance test has a reference rasterizeration (pixel coverage) result that it compares to the framebuffer. For each triangle the geometry is generated randomly. It is possible to specify the number of random geometries to test. Therefore one could supposedly let it run all night long and check the result the next morning.

 

[nirradi]

I was wandering exactly how the conformance test results look like. it is my understanding that different GL implementation may differ in rasterization results. one GL might put a pixel where another GL would decide that the pixel is outside a triangle. so the resulting image can be substantially different.
How can the test know pass/fail for that case, does it allow variance in determining triangle insidness? is there more data on the test results and what the variance limit allowed in order to pass?

 

[Davros]

I think photshop has a function to compare 2 images and show the difference - is that any use to you ?

 

[Toasty]

OpenGL specifies exact pixel coverage rules. But rasterization results can still differ due to the following scenarios:
1) the vertex transformation pipeline may have slightly different results across GL implementations
2) clip vertices generated by clipping the primitive against the frustum/guardband can slightly alter the rasterization result

These days I think all IHVs follow IEEE 32-bit float so the vertex transform stages should produce identical results.

As for clipping the ideal solution is to not clip in the first place and design a rasterizer that works for any unclipped geometry. I believe Nvidia does this. Otherwise it can be quite difficult to ensure perfectly consistent rasterization.

The rasterization conformance tests usually include an error tolerance value. When a fragment is lit differently then the reference rasterizer result the distance to the nearest primitive edge is examined. If it is less than some value then the rasterization is not considered to be in error.

 

[chenr]

which solution seems better for high resolution?

Non Homogenous (x/w y/w z/w)
Clip the 3 vertices and all of their ~24 (4 float) attributes and would take a lot of hardware
Traversal from top to bottom interpolating the values using fixed point barycentric coordinates (perspective correct) while trying to minimize the number of fragments to check insideness on.(keeping close to the triangle as I can) Should I be worried of the precision lost due to the clip stage, or does 32bit IEEE float keeps consistency needed?

Homogenous (x y z w)
Done without any clipping to calculate the barycentric coordinates. My question is how do I “scan” the triangle if I don’t know where it is in screen coordinates, I know some recursive method can be used but I don’t know what that practically means and if it’s effiecient to do in hw in spite of longer time it takes to find fragments that are really inside?