1633912 - Support efficient perspective rendering for SWGL

Status: RESOLVED WORKSFORME

(Core :: Graphics: WebRender, task, P3)

Description

[Glenn Watson [:gw]]

Background

We want to support perspective efficiently in SWGL, without adding overhead to the common non-perspective rendering case.

The end goal is:

• SWGL supports rendering perspective when the PERSPECTIVE feature is enabled (DONE, or mostly done).
• WR sets the PERSPECTIVE feature when drawing in perspective.
• We reduce the number of shaders and cases where we require perspective in WR (for performance and memory).

The last goal is achieved by:

• Moving most 3d content to establish a raster root, drawing content in local-space.
• Only apply perspective transform when drawing into the parent, via the image shader.

Implementing this is conceptually simple, but has some complexities:

• The existing raster root and local scaling code is relatively untested, and may need some fixes.
• It's possible to set an arbitrary perspective transform on any element, outside of a 3d rendering context. We don't generally create a picture here during scene building, and we don't know about the transform value until frame building (due to property animation). There's a few potential ways to work around this, but it needs some thought and investigation.

Plan

So, I think we can break this into two incremental steps, to unblock work along the way:

(1) For every shader that currently might require perspective, we declare that to SWGL both with/without the PERSPECTIVE feature. We change WR to set the PERSPECTIVE feature when drawing, based on the current transform value.

(2) We work on the WR support above to reduce the number of shaders that require perspective.

Motivation

Implementing (1) is straightforward, while (2) is going to take some time to get right. If we implement (1) now, that means:

• We unblock any correctness work in SWGL - it's possible to move forward with ensuring all tests are correct.
• Although perspective performance in SWGL won't be great, we can do reliable performance profiling / work in SWGL for the common non-perspective case.

At the same time, we can develop the best possible solution for (2) without worrying about it blocking progress in SWGL.

Comment 1

[Lee Salzman [:lsalzman]]

What shaders currently can potentially be supplied with primitives that require perspective?

Comment 2

[Glenn Watson [:gw]]

Since you can set an arbitrary transform on any primitive without declaring a 3d context, I think that would be possible on any of the current primitive types, which would imply:

• brush_ - 10 of these
• ps_text_run
• cs_clip_ - 3 of these

Comment 3

[Lee Salzman [:lsalzman]]

(In reply to Glenn Watson [:gw] from comment #2)

Since you can set an arbitrary transform on any primitive without declaring a 3d context, I think that would be possible on any of the current primitive types, which would imply:

• brush_ - 10 of these
• ps_text_run
• cs_clip_ - 3 of these

Keeping in mind that every brush_ shader has several permutations, and each of these would require a PERSPECTIVE variant of that, I think that might rapidly cause combinatorial explosion and become a bit untenable. Each brush shader is already making 5 variations of itself in the constructor...

Comment 4

[Glenn Watson [:gw]]

(we discussed this further in matrix with some extra context - adding some conclusions here)

We can reduce the number of permutations on most of those shaders (text/image are the only ones that require dual source/advanced blend, we could remove debug overlay). However, there will still be extra combinations of shaders and explicit management of them in WR.

Lee had another idea that we could use:

• SWGL could check the W coord of output vertices and implicitly select a perspective / non-perspective FS based on that.

We also discussed that we could pass some information from WR to SWGL (via a known SWGL uniform or some other non-standard method) as a hint whether to use perspective. This would mean that SWGL doesn't need to check the W coordinates of each vertex.

So, an alternative plan could be:
(1) SWGL implements the implicit selection of a (non) perspective FS based on the W coords of the vertices.
(2) Optionally, if we consider that a performance issue, explore WR providing a hint based on transform to the batcher which is passed to SWGL.
(3) Continue to work on the WR optimizations to reduce the use of perspective as discussed above.

With this plan, there is extra SWGL work to be done, but nothing in WR blocks current work on SWGL correctness, and each time we do (2) or (3) we see performance improvements without blocking other work.

Comment 5

[Lee Salzman [:lsalzman]]

It seems like the solution in bug 1634447 has been adequate and that for the moment we don't need a more complicated solution to this. Closing this for now. Can be reopened if we ever need to revisit it.