Experiment with tessellation shaders for text runs and tiled backgrounds

[pcwalton]

We spend a lot of time—probably most of our time—building batches for text runs and tiled backgrounds, because those display items are common and have a lot of vertices. It would be nice if we had a way to dramatically reduce the number of vertices we have to build for each of those. OpenGL 4.0 tessellation shaders seem like a possible solution here, because tessellation shaders leverage the GPU's parallelism to construct multiple vertices for a single input patch.

A rough sketch of the idea—details are to be determined:

• If tessellation shader support is available, don't build quads for each glyph in a text run and tiling of an image in a tiled background. Instead, build a single patch for the text run or background's bounding box, and mark it with a special attribute value so that the tessellation shader knows it should subdivide it.
• In the Tessellation Control Shader, subdivide the bounding rect into the correct number of glyphs or image repeats.
• In the Tessellation Evaluation Shader:
  • For tiled images, simply adjust the vertex positions and texture coordinates appropriately so that the size of each quad is equal to the size of the image (except around the edges).
  • For text runs, what to do here is somewhat less clear. One potential approach would be the following: First, during rasterization, build a lookup table (LUT) texture that defines the metrics and uv coordinates for each rasterized glyph in the font. Next, supply a per-text-run LUT that specifies glyph IDs and advances for each glyph. In the TES, use the value of gl_TessCoord to index into the second LUT to get the glyph ID, and using that index into the first LUT to determine the glyph metrics. The major unknown here is how to efficiently provide the second LUT—the per-text-run LUT—to the TES.

Before embarking on this, it would be good to get some numbers to verify that we are indeed spending most of our time in tiled background and text run vertex construction on most pages.

[pcwalton]

Perhaps a Uniform Buffer Object would be the best solution for storing the glyph and text run data.

[pcwalton]

I'm now thinking that a geometry shader would be almost as good: for unclipped glyphs, just pack glyphs and advances into the vertex attribute data and have a GS expand that into a fixed number of quads (maybe 4-6, depending on how tightly we can pack the data) by consulting a LUT for the font texture uvs and glyph offsets. This should be fast because each vertex expands into a fixed number of quads, so branch divergence should be pretty low and we should be able to extract a decent amount of GPU parallelism from the VS. Geometry shaders have the advantage of much wider hardware support (~40% of Android devices on the market I believe).

[glennw]

Not relevant with wr2.