1548131 - Assertion failure during texture cache reallocation

Status: RESOLVED FIXED

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

Description

[Kartikaya Gupta (email:[e-mail])]

Running the wrench reftests on Android (7.0 emulator) I can reproduce an assertion failure at this line. The call site is here and is happening during texture cache reallocation. Apparently the new texture we create has a layer_count of 4, while the old one we're replacing has a layer_count of 16 (in at least the one instance I'm debugging).

I'll continue investigation tomorrow but if anybody has thoughts offhand why this might be feel free to drop a comment here. Note that the emulator's GLES implementation is not the greatest so it might be returning us some garbage at some point, causing this failure as a result.

Comment 1

[Bobby Holley (:bholley)]

That's weird. layer_count is application-managed and shouldn't be dependent on the driver.

That code path is only supposed to fire in the case where we're growing the texture cache. The texture cache only shrinks when we invoke clear and drop it entirely. So seems like maybe the commands are occurring out of order somehow, maybe related to document splitting? Bug 1538540 also just came across my desk, which seems potentially related.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

It's coming from here - the picture_texture.slices gets truncated to length 4, which gets turned into the layer_count in the reallocation request. So this is basically intentionally requesting a realloc with a smaller layer count, presumably to free stuff?

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I don't know this code well enough to know what the right fix here is. Dzmitry, any suggestions?

Comment 4

[Dzmitry Malyshau [:kvark]]

I think we should invalidate all the picture caches and not do any blitting in case the clear_picture stuff happens. Stealing the bug.

Comment 5

[Bobby Holley (:bholley)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #2)

It's coming from here - the picture_texture.slices gets truncated to length 4, which gets turned into the layer_count in the reallocation request. So this is basically intentionally requesting a realloc with a smaller layer count, presumably to free stuff?

The semantics of the TextureCacheAllocation commands are that you can't realloc something smaller - you need to first free then allocate.

Comment 6

[Dzmitry Malyshau [:kvark]]

Attachment: WR reset texture allocation

Introduce a new texture allocation operation "reset", which acts like a "realloc" but without the contents preserved.
Use it for the picture texture cache.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c0f3a0adee3c
WR reset texture allocation r=gw

Comment 8

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/c0f3a0adee3c