On tilers, it can be beneficial to grow the scissor rect to be aligned on a tile boundary, to avoid read-modify-write operations. We don't really have logic to plumb that information, though.

BTW, are you talking about cc here? We should already be setting the scissor rect, see DirectRenderer::DrawRenderPass (computes the scissor rect) -> GLRenderer::PrepareSurfaceForPass -> GLRenderer::SetScissorTestRect which sets (and enables) the scissor rect.

Is there a way to get the tile size in GLES?

On the other hand, I would imagine that tilers could scissor the tile as they write it back to the framebuffer. It's a simple operation that the tile dma engine could implement with write masking or such.

Not through a standard API in GL. Maybe some extensions, or, basically, behind-the-scenes knowledge. Note that the tile size may depend on the framebuffer configuration (number and format of attachments, multisampling, etc.).

There is an API in Vulkan (https://www.khronos.org/registry/vulkan/specs/1.0/man/html/vkGetRenderAreaGranularity.html), so the information is "there" but not necessarily accessible via GL.

@#5 the hardware may or may not be able to do so (one of the reasons this was added to Vulkan).

@#2, yes, cc. I was just tracing all calls to glScissor on the GPU process side and didn't see a call that matched the damage rect.

I think we end up with SURFACE_INITIALIZATION_MODE_PRESERVE in GLRenderer::PrepareSurfaceForPass and as a result no call to glScissor. I'll investigate more.

@6 yes, exactly, I was looking for an extension that would expose something like that for GLES.

Sorry, this bug is incorrect. When cleaning up my patch I broke it and that's what was causing scissor rect to not be set correctly. Seems like we're setting the scissor rect correctly in ToT when partial updates are used. Closing this bug. If we want to do something to grow the scissor rect to be aligned on a tile boundary then we can open another bug for that.