1419871 - Large opaque overlapping rectangles in each of the MotionMark tests

Status: RESOLVED INCOMPLETE

(Core :: Graphics: WebRender, defect, P2)

Description

[Dzmitry Malyshau [:kvark]]

Attachment: 01-overdraw.png

Every one of the 9 standard MotionMark tests starts the main pass with 12 opaque rectangles. Most of them are large (half/full screen, centered), and they seem to share the same depth, which strikes as inefficient to me.

Ironically, those rectangles take so much GPU time that they dominate the profile of roughly half (!) of those MotionMark tests. See picture attached for timings and overdraw visuals by RenderDoc.

Comment 1

[Nicolas Silva [:nical]]

It's interesting that they share the same depth. The depth appears to be automatically computed from the primitive index in tiling.rs/frame_builder.rs so that should probably be investigated on the WebRender side.

I am not sure how to read the screen shot in attachment. Are the 12 rectangles including the chrome at the bottom? Are several of them overlapping with the same size? in the content?

I assume that there is one that covers the entire window (is that how we clear it?), one that covers the content area and then the one in the middle would be the "stage" div in the page.

Comment 2

[Dzmitry Malyshau [:kvark]]

> It's interesting that they share the same depth. 

It might be the limited precision of RenderDoc display. I'll get a closer look at them for sure.

> I am not sure how to read the screen shot in attachment. Are the 12
> rectangles including the chrome at the bottom? Are several of them
> overlapping with the same size? in the content?

> I assume that there is one that covers the entire window (is that how we
> clear it?), one that covers the content area and then the one in the middle
> would be the "stage" div in the page.

That might very well be the case.

Comment 3

[Dzmitry Malyshau [:kvark]]

Attachment: Linux/GL Capture of the first MM test with batching disabled

The draw calls in question are EID 828 and below.

It appears that the whole 7 digits of precision were needed to distinguish the difference between the Z values, but it's there :)

The quads are really big, and even though our depth test prevents overdraw, we must be hitting the rasterizer too hard. Interestingly, some of them are drawn twice (with the same color). That's something that Gecko may need to check for the draw list it provides.

On WR side, we need to figure out if there is a better way to avoid rasterizer abuse. Ironically, this is where tiling would help, given that we'd figure out what tiles are fully overwritten by each quad.

Comment 4

[Nicolas Silva [:nical]]

I had a look through apitrace with batching disabled and the rectangles are drawn front to back in the opaque pass as expected, and they all have different depths in the z_buffer. So we shouldn't be getting crazy amounts of overdraw. The most outstanding source of overdraw seems to be that we glClear the buffer and then cover all of it with solid color rectangles (see bug 1410030).

Comment 5

[Dzmitry Malyshau [:kvark]]

> So we shouldn't be getting crazy amounts of overdraw.

As I clarified in the previous comment - yes, we are drawing the front-to-back Z correctly (sorry if that was unclear:)) but the problem is not just about clears vs opaque quads. The large quads I see are drawn twice in a row. This could be worked around by simply checking in WR batcher if the previous quad is larger than the current one. But this would only hide the real problem: WR backend/client shouldn't really submit the work that ends up with those quads. So that's my next step to look at.