Lima does clear unconditionally for each frame

Created by: anarsoul

Lima driver does clear unconditionally for each frame and it breaks EGL_BUFFER_PRESERVED. As result, weston doesn't work properly - screen has to be repainted completely on each draw.

I believe we need to do clear only when lima_clear() is called.

Created by: koenkooi

Is weston supposed to output something with the current state of mesa-lima or with using your texture branch? In both cases I just get a black screen on s905x/mali450. A rk3328/mali450 board arrived this week, but I didn't have the time yet to boot that yet to rule out meson-drm related issues.

Created by: anarsoul

Yes, it outputs something before you move cursor. Once you move it you'll see black screen with cursor. If you open a terminal (left click in top left corner) - you'll see a terminal window.

From the dump, mali blob driver will do clear even user does not call glClear when EGL_BUFFER_DESTOYED. But when EGL_BUFFER_PRESERVED, lima_pp_wb_reg[0] and lima_pp_wb_reg[1] will be set to different target address, lima_pp_wb_reg[1] is the real target.

https://gist.github.com/yuq/0df522caf1514b4758623fac36088533 https://gist.github.com/yuq/7a0404ce79fbafc25431967ecf5d62fb

Created by: anarsoul

So what is in lima_pp_wb_reg[0] then if it's not a real target?

I have no idea as it's not dumped out, but should be a buffer used for write. Maybe some aux/tmp/mirror buffer? In fact I don't know why there're three wb and what's each wb used for except the single wb case.

Created by: anarsoul

I see. I guess we need better dumping tool - one that can actually parse command stream.

anarsoul asked me to look into how Midgard handles frames-without-clears. I don't think it will help here, but just in case:

< alyssa--> the vertex payload's framebuffer is now a full framebuffer descriptor, not just a partial one (e.g. it includes a pointer
            to the fb itself, the clear info, etc)
< alyssa--> its clear_flags has additional flags set (0xc901100)
< alyssa--> (the tiler payload also shares that full fbd)
< alyssa--> but oddly, the fragment payload's fbd does not have that extra bit set (0xc101100 instead)
< alyssa--> and that seems to be it for significant differences

After the texture merge yesterday I get actual output when running weston, but as @anarsoul says, as soon as you move the mouse the screen goes black and only 'damage' areas will be displayed. Same behaviour on both s905x and rk3328.

Attached screenshot shows the damage area around one terminal, the other terminal and flower are cutoff.

Before the merge I only got a black screen, so progress!

Great! We are one more step close to a functional desktop.

A video of the issue: https://www.youtube.com/watch?v=FDfesXszEC0

From the dump, seems EGL_BUFFER_PRESERVED is implemented like this:

1. draw a frame with two target lima_pp_wb_reg[0] & lima_pp_wb_reg[1], they are mirror
2. draw second frame prefix a draw with the first frame mirror as texture like a wallpaper

Second frame dump: https://gist.github.com/yuq/8ae7961ce678a1279d845f09e839b808

Ouch. Wouldn't it be as expensive as redrawing 2nd frame from scratch?

Depends on how much first frame cost, redraw vs single texture draw. But definitely bad design because the buffer is cleared then get its content back again.

I discussed it with Rob Clark and he suggested that we can try to use the same same resource as texture to sample back and as rendering target - in theory it shouldn't flush tile buffer back to the memory until it's ready

@yuq825 what would be best way to implement that? As far as I understand we need to prepend each draw with drawing a textured quad, but I don't see an easy way to do that - we may have to use precompiled gp and pp shaders for that.

Yes, if we have to do with this method then precompiled gp/pp shader is necessary. But I doubt this kind of implementation is only for double buffer case, maybe it's different for single buffer case. Otherwise the cost of this method will affect every draw. I can do more dump in the following days.

I don't think that we need to care whether double-buffering is in use or not. All we need is to upload contents of current buffer (the one we're rendering to) into tile buffer.

It won't affect any draw if we implement invalidate_resource() callback - if it was called for buffer we don't need to restore old buffer contents.

I mean this wallpaper method maybe only for double buffer case in mali blob driver implementation. If I do another dump for an app which uses single buffer, we may find a way to just disable clear.

I don't think that it's possible to disable clear for tiling GPU (mali4xx is tiling GPU). Tiling buffer (one that is inside of GPU) doesn't have contents of original in-memory buffer, so we need to upload it back.

FWIW, sometimes you need to load the framebuffer into tile memory using the "wallpaper method" even without the window system involved. Imagine that you emit some draw calls with a texture A bound as the framebuffer, switch to a different framebuffer B, emit some more draws that sample from A (commonly done to implement shadows), then you switch back to rendering to A. The draw call that samples from A has to "see" the draw calls to A that happened before it, so we have to stop and emit a fragment job. This fragment job has to happen before A is sampled, so the second fragment job that renders to B has to have a dependency on the first one that renders to A. There's a third fragment job for the subsequent rendering to A, but the second job sampling from A can't see that, so the third job has to depend on the second job (almost like a write-after-read dependency in a scheduler for a compiler backend). The third job has to pick up where the first job left off, so it needs to load A into tile memory at the beginning. I wonder if the blob also ping-pongs between buffers for this case.