We found an LCD layout and will use it as our test file. It is not likely to be as dense as our client's modern LCD layouts but it should have similar polygonal characteristics.
You can see a snapshot of the LCD2.GDS file below. Of course, the geometry is too dense to see any details at the full zoom level.
LCD2.GDS: 2480 mm x 2184 mm
2480 x 2184 mm
32.5 MB
Layer 6,30,35
Detail of LCD2.GDS: 700 x 550 um window
To match the client's request we used a tile size of 5 x 5 mm with a pixel size = 0.315 um (81,500 DPI) This results in a bitmap of 16,000 x 16,000 pixels for each tile.
| Thread Allocation E x R | Number of Tiles | Total Clock Time | Avg Time per Tile | Image Size (pixels) | Image Buffer (MB) | Polys/Tile (Average) | Vertices/Tile (Average) | Vertices/Sec (Average) |
|---|---|---|---|---|---|---|---|---|
| 16x1 | 217,189 | 11,990 s | 55 ms | 16K x 16K | 32 | 2,052 | 115,161 | 275.6K |
1. We experimented with different combinations of exploder threads and raster threads; the best throughput was achieved using 16 (out of 16) exploder threads and 1 raster thread per exploder.
2. On average, QisMRaster required 55 msec to complete each tile against a target of 100 msec. So it appears to meet the required target -- at least for this sample file.
3. The number of polygons per tile, 2052, is considerably lower than the value indicated by our client. They wanted this kind of throughput with polygon densities of 200K polygons/tile.
On the next page (3) we report results where the polygon count is close to 200K.