Strange behavior after several stencil operations

[jomega]

I am using the following algrothim to draw a series of arcs across the screen:

void draw_arc(int x, int y)

{

 GD.Clear(0, 1, 0);

 GD.ColorMask(0, 0, 0, 0);

 GD.StencilOp(INCR, INCR);

 GD.StencilFunc(ALWAYS, 255, 255);

 GD.Begin(EDGE_STRIP_L);

 GD.Vertex2f(x + 800, y + 1600);

 GD.Vertex2f(x + 800, y + 0);

 GD.Begin(EDGE_STRIP_A);

 GD.Vertex2f(x + 0, y + 800);

 GD.Vertex2f(x + 1600, y + 800);

 GD.ColorMask(255, 255, 255, 0);

 GD.StencilFunc(GEQUAL, 1, 255);

 GD.Begin(POINTS);

 GD.PointSize(800);

 GD.ColorRGB(255, 255, 255);

 GD.Vertex2f(x + 800, y + 800);

 GD.PointSize(600);

 GD.ColorRGB(0, 0, 0);

 GD.Vertex2f(x + 800, y + 800);

 GD.StencilFunc(ALWAYS, 0, 255);

 GD.Clear(0, 1, 0);

}



void display() {

 GD.DLStart();

 GD.ClearColorRGB(0,0,0);

 GD.Clear(1,1,1);



 for (int y = 0; y < 2; y++) {

   for (int x = 0; x < 5; x++) {

     draw_arc(x * 1600, y * 1600);

   }

 }


 GD.finish();
 GD.swap();
}
The output should look like this:



However, the result is this. It work correctly if I reduce the number of arcs drawn on the screen to less than 7.



Any idea of what is happening?

[jamesbowman]

Right, this is the GD2/3 hardware running out of render time because of display list complexity.

More detail: the FT8xx generate the output image on-the-fly at 60 Hz. If the display list is long or complicated, it can start to "underrun" and the graphics engine doesn't finish each raster
line before it's sent out to the LCD.

GD3X has "adaptive framerate" enabled which slows down scanout when instead of "underrun".

So, I think one way of making draw_arc() less expensive is to use ScissorXY() and ScissorSize() to reduce drawing to just those pixels that are part of the arc.

Right now each arc is clearing the whole screen, and drawing many pixels outside the arc's square.

Something like:


void draw_arc(int x, int y)

{
 GD.SaveContext();
 GD.ScissorXY(x, y);
 GD.ScissorSize(100, 100);

 GD.Clear(0, 1, 0);
...
 GD.RestoreContext();
}


[jomega]

Thanks jamesbowman for the quick reply. Your suggestion fixed the problem.

I was reading this in the "Performance" section of the FT800 series programming manual (page 31):

The graphics engine has no frame buffer: it uses dynamic compositing to build up each display line during scan out. Because of this, there is a finite amount of time available to draw each line. This time depends on the scan out parameters (REG_PCLK and REG_HCYCLE) but is never less than 2048 internal clock cycles.

Some performance limits:
- The display list length must be less than 2048 instructions, because the graphics engine fetches display list commands one per clock.
- The graphics engine performance rending pixels is 4 pixels per clock, for any line with 2048 display commands the total pixels performance drawn must be less than 8192.
- For some bitmap formats, the drawing rate is 1 pixel per clock. These are TEXT8X8, TEXTVGA and PALETTED.
- For bilinear filtered pixels, the drawing rate is reduced to ¼ pixel per clock. Most bitmap formats draw at 1 pixel per clock, and the above formats (TEXT8X8, TEXTVGA and PALETTED) draw at 1 pixel every 4 clocks.

This seems to suggest that the limitation is capped at 2048 instructions. Per my count, my display list is ~200 instructions. Can you comment on this?

[jamesbowman]

Right,

The crucial number is how long the display list takes to render. This is a function of both the display list length and the instructions in the display list.

For example PointSize is a fast instruction, single-cycle. Clear takes much longer, on the GD2 is takes 480/4 = 120 cycles.

So just a few Clear instructions are enough to cause underrun, for example.